一个人做三个人的活，靠的不是快，是"不用等"
一句话结论：一个人的产出上限，很少被"手速"卡住，多数时候是被"等待"卡住——等资料、等生成、等下一步。把这些等待从主线里挪出去，一天能多出两三个小时。
一个很典型的工作日
早上八点半坐下，你要同时推进三件事：
- 一份给客户的需求回复，要查上周的三份会议记录
- 一篇要发的内容，要翻资料、要改三版
- 一个产品的杂事清单，十几条小事，每条都不难，但都要动手
看起来是"活太多"。实际干起来你会发现，时间是这么没的：
查会议记录 → 等自己翻完 → 写回复 → 卡在一句话上 → 思路断了 → 回头重看。
你并没有一直在干活。你一直在切换，而每次切换都要重新加载一遍上下文。
瓶颈不在产能，在串行
一天 8 小时，真正高效的时间可能只有 3 小时，剩下的是：
| 消耗 | 具体表现 |
|---|---|
| 串行等待 | A 的产出要等 B 做完才能开始，但 B 其实不需要你盯着 |
| 上下文重载 | 切回来要重新看一遍刚才写到哪、为什么这么写 |
| 杂事打断 | 一条小事打断一次心流，回来要 10 分钟才接得上 |
这三样里，只有"杂事打断"需要你自己治；前两样是可以交出去的。
改法：把"需要判断、但不连续"的活挪到后台
判断一下手上这些活的性质：
| 适合交出去 | 不适合交出去 |
|---|---|
| 需要判断，但不需要你全程在场 | 需要你连续决策的事 |
| 有明确输入、明确产出 | 目标本身还没想清楚 |
| 出错成本可控、可回退 | 一步错就不可逆（对外发布、付款） |
| 一次性拿不到结论、要跑多轮 | 需要跟你实时来回讨论 |
举例：把"翻三份会议记录，整理出客户提过的所有诉求，按时间排"交出去——它有明确输入、明确产出，跑十分钟你也不用守着。这十分钟你继续写内容。
关键不是"让它替你想"，是"让它替你先跑一遍"。
一天能省下多少
不需要精确到分钟，看结构变化：
- 原来：写回复 → 翻记录 → 写回复（串行，中途断了三次）
- 现在：把整理诉求的活丢到后台 → 继续写内容 → 十分钟后摘要回来 → 写回复时直接引用
省下的不是那十分钟，是三次上下文重载。这才是大头。
最容易踩的三个坑
- 什么都想交出去。 结果是你得写一堆说明，比自己干还慢。判断标准：写清需求的时间，超过自己干的时间，就别交。
- 交出去就不管了。 后台跑跑偏了没人拦，回来发现全废。至少要能看"它现在跑到哪一步"。
- 不设回退。 让它直接改你的正式文件、直接对外发消息——第一次出事你就再也不敢用了。先让它产出草稿，人来按发送键。
怎么开始（最小一步）
别一上来就搭工作流。第一周只做一件事：
每天挑一件"要跑十分钟以上、且不用你守着"的活，交出去。
一周后你会知道：哪些活它接得住、哪些接不住。到那时候再谈自动化，才有意义——先有真实体感，再谈流程。
Lyncore 的对话页是按"你继续聊、任务后台跑"做的，正好覆盖上面这套用法：个人版能力全貌。
结论
一个人做三个人的活，不是把自己变成三个人。
是把"等"这件事从你的时间里拿掉——你的时间只花在需要你判断的地方，剩下的交给能并行跑的东西。