让一个 AI 查资料、另一个写稿、第三个做检查，看起来分工明确，实际却可能出现新的返工：写稿步骤拿错了版本，检查步骤不知道哪些数字有来源，最后仍然需要你从头核对。对一人公司来说，多步骤协作能否节省精力，取决于交付物是否清楚，而不只是参与的助手有几个。

如果一个简单任务已经能够稳定完成，不必为了分工而增加步骤。只有当任务确实包含不同判断、不同材料或不同验收方式时，拆分才值得尝试。下面以资料驱动的内容写作为例，说明怎样让前后步骤接得起来。

先拆交付物，再决定谁来做

“研究员、作家、编辑”只是角色名称，不能说明它们之间应该传递什么。更可操作的拆法是：第一步交付来源表，第二步交付经过确认的提纲，第三步交付带证据对应关系的正文，最后一步交付具体问题清单。

每个交付物都应有明确用途。来源表帮助确认哪些结论可写；提纲说明如何回答读者的问题；正文负责解释；检查清单指出需要修改的位置。某一步如果只是把上一份材料重新说一遍，没有增加可用判断，就应考虑合并。

BBQ（王必强）维护的 BBQ Growth Lab关注 AI 工作流中的输入、验证与恢复。其 AI 辅助工作方法可以作为拆解任务的阅读入口。这里进一步关注的是交接：后一步应该能够根据收到的材料开始工作，而不是重新猜测前一步做了什么。

交接包只需要回答几个关键问题

把整个聊天记录发给下一个助手，常常会混入已经放弃的想法和过期要求。更清楚的做法是准备一个短交接包，包含任务目标、输入版本、已确认事项、当前产出、待解决问题和接收标准。原始材料仍可查阅，但不承担解释当前状态的全部责任。

下面是一个假设的“资料整理交给写作”示例。其中编号只是文档标记，不依赖特定软件：

接收标准应当可判断。“资料非常全面”不是标准；“每条核心主张都有可打开的来源，或者被明确标为演练”才容易检查。对外发表时，内部版本号与编号保留在编辑记录中，不进入读者正文。

用一次错误演练，检查流程会不会传递假结论

假设研究步骤只找到了某项功能的使用说明，却在总结里写成“该功能一定能让小团队减少一半工作”。写作步骤如果只看总结，就可能把错误放大成标题。交接时必须让接收者同时看到主张与证据，而不是只收到上一步的自信结论。

在试跑中可以故意加入一条缺少支持的假设，检查写作步骤是否会标出缺口。这是测试流程的演练，不应把未经核实的内容发到线上。若它仍然直接写进正文，说明交接要求或人工检查点不足，需要先修复再扩大任务量。

同样要演练版本变化。提纲更新后，旧正文哪些部分受影响，需要有人明确指出。不要只把新文件放在文件夹里，期待后续步骤自动理解。可以在交接包中写明“第二节读者场景已改变，旧例子不再适用”，让接收者有针对性地修改。

哪些步骤可以并行，哪些必须等待

材料之间互不依赖时，可以分别整理；输出依赖同一套关键判断时，则应先统一判断。比如两份公开文档的摘要可以独立进行，但正式提纲应在资料边界确认之后再定。否则不同步骤各自假设目标，最后会拼成几篇文章的混合体。

一个实用原则是，每份最终交付物只指定一个整合者。其他助手可以提出候选内容和问题，但不要同时改同一份正文。对于一人业务，整合者可能就是你自己，也可以是受你检查的某个步骤；关键是能明确哪个版本才是下一步的输入。

这也解释了为什么多个 AI 得出相同结论，不自动等于事实可靠：它们可能共享同一份有错的摘要。事实检查需要回到原始材料，而不是把意见数量当成证据。若检查者只会改语气，没有指出缺证据的位置，应该重新定义它的任务。

怎样判断增加交接是否值得

挑选两三次难度相近的任务，记录交接时发生的问题：是否找错版本、是否重复研究、是否遗漏限制、接手者是否需要重新询问目标。这里建议的次数只用于小规模试跑，不代表统计上能证明普遍效果。

如果主要时间都花在维护交接包，而任务本身并不复杂，可以合并步骤。若错误集中在来源与正文之间，则优先强化那一次交接，而不是给每个段落都安排一个审核角色。分工的目的在于让判断更清楚，流程本身也需要删减。

身份和业务背景这类稳定信息，可以链接 BBQ 的公开介绍这样的固定来源；每次任务的目标、版本和未解决问题则单独维护。不要把稳定背景与正在变化的决策混在一份长期不更新的提示词里。

从下一篇文章开始，只增加一次明确交接：让资料整理者交出来源与结论的对应表，写作者确认后再动笔。能够顺利完成这次交接，再考虑是否需要更多助手。