这几天，我开始认真想一个问题：
一个人，究竟怎么承担一家公司的工作？
这个问题听起来很像效率问题。
再往前一步，很容易变成：
- 一个人要承担多个岗位；
- 产品、设计、开发、运营都得会；
- AI 可以帮你多干一点；
- 最后把一个人武装成一支队伍。
这也是我过去经常听到的一套说法。
但今天和 Mira 聊下来，我们突然发现，这个方向里藏着一个危险的前提：
一个人承担一家公司的责任，是否就意味着，一个人应该承担一家公司的全部过程？
答案可能是否定的。
1#
我最近一周的工作其实并不复杂。
早上，用 AI 评审前一天自己想出来的需求，整理 PRD，拆任务卡，再把任务交出去。
中午又进来一个新需求。
重新理解需求，补 PRD，再拆任务。
中间穿插开会。
开会不只是“参加会议”，还要记住新的要求，判断哪些是明确需求，哪些只是讨论中的想法。
下午继续和 Codex、Mira 评审施工结果。
晚上又收到 UI 评审任务，需要看设计、指出问题，有时还要向其他人解释为什么这样设计。
如果按照传统公司岗位来数，我可能同时在做：
产品经理、项目经理、设计负责人、技术负责人、需求分析、会议记录、任务调度和验收。
听起来像“一人多岗”。
但仔细看以后，我发现真正反复发生的，其实只有一条链：
输入 → 判断 → 转译 → 分派 → 验收
需求进来。
我判断它是什么。
把它翻译成 PRD。
再翻译成任务卡。
交给人或者 AI 去施工。
施工完成以后，我再回来判断做得对不对。
看起来很多岗位，其实所有道路最后都经过同一个节点：
我。
2#
问题可能就在这里。
一个人的工作量当然有限，但比工作量更容易把人压垮的，是不断切换上下文。
我正在评审一个需求。
会议开始了。
会议里出现另外两个需求。
回来以后继续写 PRD。
突然有人需要设计评审。
评审过程中又发现一个技术问题。
于是一天结束的时候，会产生一种很奇怪的感觉：
明明一直在做事，却始终没有真正离开工作现场。
因为脑子里同时挂着很多没有关闭的线程。
所以“一人公司”的第一个问题，可能并不是：
怎样让一个人工作得更快？
而是：
怎样让大部分事情不再必须经过这个人？
这是两个完全不同的问题。
前者追求的是个人效率。
后者讨论的是系统设计。
3#
这让我重新理解“一人公司”。
它不应该是：
一个人扮演一家公司的所有员工。
而应该更接近：
一个人承担最终责任，但不亲自承担所有过程。
这个区别很重要。
方向要不要做，我可能必须判断。
需求边界怎么定，我可能必须参与。
关键设计怎么取舍，我可能要决定。
最后结果能不能接受，我也必须负责。
但会议记录为什么必须由我整理？
PRD 第一稿为什么必须由我写？
任务卡为什么每次都要我重新拆？
施工过程为什么一定要我不断盯着？
代码和 UI 为什么不能先经过机器检查，只有出现异常的时候再回来找我？
这些工作并没有消失。
只是它们未必应该始终由“最终负责人”亲自完成。
4#
于是我们画出了一个非常粗糙的框架。
所有输入——会议、老板的要求、自己的想法、临时反馈——先进入一个统一入口。
系统先整理信息。
然后只有真正需要判断的东西来到我面前。
我决定：
做，还是不做。
优先级是什么。
边界在哪里。
一旦决定完成，后面的 PRD 初稿、任务拆分、执行、自动检查，应尽可能自己向前流动。
理想状态下，我只在两个地方长期出现：
Decision。
以及：
Final Review。
中间的大部分过程，都应该逐渐离开我。
当然，这句话说起来很好听。
真正做的时候马上会遇到很多麻烦。
AI 会不会把会议里的随口讨论脑补成正式需求？
PRD 自动生成以后，谁来保证它没有理解错？
Codex 拿到任务卡以后，如果上下文不足，是不是还是会不断回来问？
自动施工越来越快以后，会不会反而在晚上堆出一大批等我验收的东西？
一个自动化系统如果每天还需要我去管理它，那它并没有真正减少工作，只是把我从执行者变成了 AI 项目经理。
所以我们给这套探索加了一条约束：
任何新工具，如果增加了我的管理负担，就先视为失败。
5#
我手下还有一个很有意思的变量。
一个态度很好、愿意干活的人。
但他的时间并不稳定，经常会被别的事情叫走。
传统管理思路里，这很麻烦。
因为一旦关键任务交给一个不稳定的人，他突然离开，整个链路就会卡住。
但换一个角度看，他并不是“一个岗位”。
他可以只是一个弹性的执行资源。
适合他的任务应该有这些特点：
边界清楚。
不在关键路径。
随时可以停。
回来以后容易继续。
结果容易验收。
这样他今天有空，就多拿几张任务卡。
明天没空，整个系统也不会因此停下来。
这个变化让我意识到：
未来的一人公司，也许不应该围绕“岗位”来设计。
而应该围绕：
任务、责任、资源和决策权。
人是一种资源。
AI 也是一种资源。
Codex 是施工资源。
自动化是执行资源。
而我真正应该保留的，是那些不能轻易外包的判断权。
6#
这又引出了另外一个问题：
工具到底应该怎么选？
我们目前的结论很克制。
不准备先造一个所谓的“一人公司操作系统”。
也不准备养十几个 Agent。
因为十个 Agent 如果每天都来问我：
“下一步做什么？”
“这个需求是什么意思？”
“这个结果你满意吗？”
那我只是从一个人做十份工作，升级成了一个人带十个下属。
系统没有减少负担，只是换了一种更高级的方式消耗注意力。
所以现在更现实的方向是：
先利用已经成熟的工具。
会议工具负责捕获。
GitHub 负责留下需求、任务和状态。
Codex 负责施工。
AI 负责整理、转译、拆分和初审。
真正需要我们自己设计的，反而不是工具，而是几种“工作方法”。
例如：
怎样从一段会议记录里区分：
事实、决定、正式需求和未确认的问题。
怎样把一个模糊需求转成 PRD，但禁止 AI 自己补充未经确认的业务规则。
怎样判断一个任务应该交给 Codex、人类，还是必须由我亲自处理。
怎样在施工完成以后，先让系统判断是否真的需要把我叫回来。
这些东西更像 Skill。
工具提供手脚。
Skill 保存公司的工作方法。
而真正的一人公司系统，可能只是让这些东西能够顺畅连接起来。
7#
我们现在还没有答案。
甚至不知道这套思路最后是不是成立。
所以这不是一篇“一人公司方法论”。
更像是一份实验记录。
接下来我们准备做的事情很简单：
每拆掉一个由我亲自参与的节点，就观察它是不是真的减少了我的时间、决策次数和上下文切换。
如果原来一个需求从收到到可以施工，需要我投入六十分钟。
引入 AI 以后变成五十分钟。
那这件事其实没有什么值得兴奋的。
如果它能稳定变成十五分钟，而且没有明显增加返工，那这个节点才算真正从我身上拆了下来。
一点一点拆。
直到最终只剩下那些真正需要我做的事情。
我现在越来越觉得，一人公司的核心问题可能不是：
一个人能做到多少事。
而是：
一家公司的多少事情，可以在不需要这个人持续介入的情况下自行运转。
如果最后这条路能走通，那么“一人公司”也许并不是把一个人训练成万能员工。
而是反过来：
把一家公司设计到，只需要一个人承担那些真正无法被替代的部分。
这件事，我们准备继续往下试。
