AI 写了 35 页需求文档,错在我自己说的一个词

一、我把这次交付当成一次长程任务

五点二十一分，我把任务发了出去：给一套外呼线索管理系统写需求规格说明书。

这个活以前是我带人做的：读方案、对原型、截图、逐节写、再评审。这次我打算整个交出去。

交之前，我把能准备的都准备了。参考文档、业务流程图、原型、上一期的规格书、配套的方案和问卷设计书，全部指给它。要求写了八条，其中三条是：

· 格式最终需要 docx

· 画面需要截图，对照截图说明内容

· 最好不需要我的参与，可以完整做完这份规格书

这三条里最后一条，是我那天的原话。

我想试的不是"AI 能不能写出文档"，这个我已经验证过。我想试的是长程任务：给足素材，让它在没有人在场的情况下，从头跑到尾。

五点四十三，我又补了一句：

然后我就下班了。

二、它确实跑完了

十八点三十三，它发来完成消息。从交代到交付，七十二分钟。

那时候我已经走了，消息是第二天早上才看到的。九点半打开电脑，它交的是一份 35 页的需求规格说明书，外加一份待确认事项清单。一共提交了四次：一次主提交，另外三次分别修了换行符、图片路径和评审记录。

三、第一处要改的，是我自己写的词

这套系统的业务是：顾客留下联系方式，形成线索；坐席按名单逐个打电话，也就是外呼；打完把结果回传。

上午十点三十九，我指出最要紧的一处：

这两个词差在哪：

· 线索合并：同一个顾客的多条线索，合成一条

· 外呼合并：同一个顾客的多条线索，一条不少地一起分配进同一个外呼任务

一个是减行，一个是不减行。方向正好相反。

规格书在这一节后面还写了四条业务约束：

· 只要有一条线索分到外呼任务，同一顾客的其他线索一并分配

· 外呼执行画面逐条显示，不做线索合并

· 回传时每条线索各回一条

· 下一轮再来新线索，重新分配，执行画面仍能看到历史线索和外呼履历

如果按"线索合并"去实现，库里的线索会少掉几条，回传数量对不上，执行画面也查不到顾客当初的原始线索。即使其余 34 页都没问题，依赖这一节的实现、用例和回传也会跟着错。

它当天把这一节改完。文档从 35 页长到 38 页。

交付时那 35 页里，我逐字读完的只有业务规则这几节。

四、这个词是我说的

我往上翻自己五点二十一分写的那段任务说明。八条要求里，第八条的结尾是：

"合并线索"这四个字，是我写的。

而且就紧挨着"一起呼出"。"一起呼出"才是对的。我要的是这些线索一起外呼、但各自保留，落到笔上却变成了"合并线索"。

核心概念上，它完全没有自作主张——我说的"合并"，它一个字没改。但在我没交代的细节上，它按自己的理解补全了：哪些线索归到一组、组内结果怎么共享、下一轮怎么处理。补得很完整。

补得越完整，错得越完整。

五、它问不出来的那一句

不是它不问。它没有中途打断我，而是把问题攒成了一份 9 页的待确认清单，13 项：意向等级怎么分、车型配置从哪来、标签体系、三张报表的口径、法务结论、省市门店的编码对照……

13 项里，没有一项是关于"合并"的。

这些问题它问得出来，因为它们是信息缺口——材料里没有答案，它知道该问我。而"合并线索"和"一起呼出"在它读来并不矛盾：前者是主概念，后者是补充说明。两个说法撞上时，默认主概念是规格。

这才是最要命的地方。它能问出"报表口径是什么"，问不出"你说的合并，是不是这个合并"。前者是缺信息，后者要它先认定我有错——它没有这个立场。

不是我给的素材不够。上一期的规格书、方案、问卷设计书都在里面。但它读材料的方式是：材料当参考，我的话当规格。两者打架时，服从的是我。

改完这一节之后，它继续改别的部分。我手动精简了几处，它逐段比对我改过的版本，把我删掉的每一处都标了出来，一处没加回去。

它能把我删掉的东西一处不漏找出来。但它不会问我，那句话本身对不对。

六、错误会顺着交付链往下走

AI 会犯错，这不是新闻。长程任务把错误带到了多远，这才是新的问题。

这个词从一句任务说明，变成了 35 页里的第 3.3.1 节。它自己那三次修正都在格式和记录层面，没有一次回到这个词。

这个错误还会往下走：业务方确认、开发照着实现、测试按它写用例。如果我没有在第二天逐条读业务规则，这份文档会一路走下去。等到执行画面查不到线索的那一天，没有人会想到，根因是一句话里的一个词。

所以长程任务要准备的，不只是素材。素材决定它能不能写；描述得准不准，才决定它写的是不是那件事。

七、歧义避不开，怎么办

歧义不可能事先消灭。能做的是让它早点露出来，而且露出来的时候你看得见。

现在这种活交出去之前，我会做三件事。第一件，先让它复述。

先不给它写文档，让它用三四行字说清楚它理解的几个关键业务动作。"我说'合并'，你理解成什么？是多条线索变成一条，还是一条不少地挂到同一个任务下面？"

这一步只花两分钟。它答对了再让它写；答错了，改的是我的表述。改完再答错，就说明是它没理解，需要换问法，或者人工兜底。

第二件，定名。同一个业务动作，在我嘴里、在方案里、在开发文档里，必须是同一个词。以前这件事靠人——团队里总会有人问一句"你说的合并是哪个合并"。现在中间没有人，这句话就没人问了。

第三件，验收方式。35 页我不可能每句都看，但有三样我一定看：核心业务动作的定义、关键判定表、回传字段。这三样错一个，依赖它的实现和回传就会错。

八、一句话

长程任务不是把活交出去就完了。是出发前把话说准，交付后知道该验哪一句。

内容是我的实战和思考，Claude 帮我把它们写清楚。— 本文由我与 Claude 协作完成 —