# AI写到3万字后开始偷懒，我让它学会了分工


昨天，我让 AI 修改一份产品宣传文档。

这份文档由 Future、PRD 等资料整合而来，先归纳产品亮点，再把亮点分成功能组，最后拆成功能点，一共有三层结构、八个章节。写到第四版时，全文已经超过 3 万字。

我要改的并不是格式，而是内容。我调整了部分结构，又要求它结合原始资料，把每个功能点继续写细。

刚开始还好，越往后越不对。尤其把第七章和第八章放在一起看，会发现不少内容似曾相识：句子看起来完整，术语也都正确，但绕来绕去还是那些关键词。读起来又啰嗦又没内容，AI 味很重。

我查看它的处理过程，发现它写了一个脚本。它没有逐段理解产品功能，而是找到相近的关键词和句式，再批量组织出一些看上去冠冕堂皇的文字。

这不是我第一次遇到这种情况。以前我做过一个从需求生成文档的 Skill，短文档效果不错，一旦放进很长的需求文档，它也会转向脚本处理，最后的质量差到没法用。

现在想想，我也能理解。面对一份 3 万字的文档，还要逐章补充细节，AI 不偷懒才怪。我们嘴上告诉它“不要急，慢慢来”，但它接收到的任务仍然是：尽快把八个章节处理完。于是，它找到了一条成本更低的路。

脚本本身没有错。统一格式、检查字段、批量替换，脚本往往比人还可靠。问题在于，这次需要的是语义理解，它却用关键词匹配代替了思考。

发现这一点以后，我没有继续要求它“认真一点”，而是直接改变了它的工作方式。

我把模型切换到 Sol，明确告诉它：我不接受脚本批量处理，需要重新拆分任务。由 Sol 负责规划、质量把关和最终整合，再把各章节的细化工作交给 Terra 并行完成。

它把八个章节拆成三个子任务。几个 Terra 分头处理，完成后交回 Sol。Sol 检查它们的结果，发现不对的地方再亲自修改，最后重新组装成第五版。

第四版用脚本处理，花了 14 分钟。第五版并行处理，花了 21 分钟。时间增加了 50%，全文则从 3 万字增加到接近 4 万字。更重要的是，各功能点开始根据真实的产品资料展开，不再翻来覆去地改写同一组关键词。

多花七分钟，得到的是一份真正可以继续使用的文档。这笔账很划算。

这个办法，其实是我从 AI 写代码的过程中学来的。

前两周我写过，真正可靠的超长任务，不该是一个 Agent 永远不停地跑，而应该变成一系列可以检查、暂停和重新规划的短任务。当时更多还是一种判断，这次处理长文档，算是把它变成了一个可以复用的办法。

前段时间，我们接触了 Open Spec。最初大家有些嗤之以鼻：模型已经这么强了，直接把任务交给它不就行了吗，为什么还要写规范、拆步骤、设检查点？

真正做过大工程以后才发现，模型能力变强，并没有让这些过程失去意义。任务越大、周期越长，越需要先拆清楚，再把具体工作交给不同模型，最后由能力更强的模型严格验收。

不过，拆解和并行不是一回事。

拆解是把一件模糊的大事变成几件明确的小事，解决的是准确性；并行是让这些已经明确、彼此独立的小事同时发生，解决的是效率。任务不先拆开，并行只会让几个 AI 同时制造混乱。只有拆得足够清楚，并行才真正有用。

这次处理长文档，让我把代码里的方法搬到了文字工作中：

```text
大任务先拆解
具体任务并行处理
强模型统一审查
最后重新整合
```

当然，不是所有任务都需要这样做。短文档交给一个模型更省事；高度依赖上下文的内容切得太碎，也可能前后矛盾。适合并行的，是那些规模大、能够分块，而且每一块都能单独检查的任务。

以前我们使用 AI，更像是在找一个无所不能的助手：把要求说给它，等它把结果交回来。现在我越来越觉得，面对复杂任务，只会提要求还不够。

你要决定怎么拆，什么工作可以交给普通模型，哪里必须使用强模型，谁负责检查，以及什么结果才算真的完成。

我们不只是在使用 AI，也开始在管理一支 AI 团队。


---

> 作者: [RoverTang](https://rovertang.com)  
> URL: https://rovertang.com/posts/ai/20260807-ai-long-document-parallel-workflow/