AI 写的需求文档,研发说＂看完不知道想干嘛＂

那天研发看完我用 AI 写的需求文档，跟我说了一句：“看完了，不知道你想干嘛。”

我当时有点懵。因为那份文档在我看来挺“完整”——背景、目标、方案都有，字也不少。但后来复盘，我发现研发说得对，而且这是一个特别典型的问题。

先说结论：问题是信息堆在一起了，研发抓不住这次到底要改什么。

原因一：AI 写的东西，其实不适合人读

第一眼的问题就是——字太多了。密密麻麻一大片，读起来非常累，而且一张图都没有。

可你想想，人在写需求文档的时候其实是很精简的，不会堆一大堆废话。而且人会配图：截一张系统页面的截图，把要改的地方框出来，直接标注“这里要改，改成什么样”。这种图，研发一眼就看懂了。

AI 不会这么干。它默认输出的是一大段通顺但冗长的文字。看起来面面俱到，研发却得自己从里面找重点。

原因二：看着很完整，其实没重点

研发那句“看完不知道要怎么办”，戳中的是另一个问题：文档表述看上去很完整，但没有把最核心的东西讲出来——这次要改哪些点、为什么改、改成什么样。

再往根上刨一层：因为我自己没说清楚，AI 也就说不清楚。它就像拿着一个模板，把一件事写得“看起来很漂亮”。文档写得再顺，研发不知道从哪一处开始改，也等于没写清楚。

后来我是怎么做的：带着 AI 写

现在我会先把改动想明白，再让 AI 帮我整理成文档。主要就两步：

1.先自己把方案想清楚，再去跟 AI 说。自己都没想明白的时候，先别急着让它动笔。

2.在 prompt 加一串“基本原则”+“注意清单”，专门管住它爱发散、爱堆字的毛病。

就这么几条，生成出来的内容会短很多，也更聚焦这次改动。

最后，送你一段可以直接抄的 prompt，下次让 AI 写需求文档时，把这段加上：

基本原则：1. PRD 是给设计、开发、测试执行的，不是汇报材料。2. 只写页面表现、业务规则、数据来源、交互和边界。3. 不写无法指导执行的价值描述和总结性废话。4. 不允许自行补充业务规则。5. 未明确的内容标记为【待确认】。6. 每条规则只表达一个意思。7. 能用列表表达时，不写长段落。8. 本次未变化的既有逻辑，不重复展开。9. 如与现有规则冲突，单独列出，不要擅自选择方案。10. 输出前自检并删除所有不影响设计、开发、测试的句子。请注意：1. 避免抽象价值描述。2. 避免重复表达。3. 避免没有对应页面、数据、逻辑或验收动作的句子。4. 避免根据经验自行补充的内容。5. 将长段落拆成单条规则。6. 对没有明确依据的内容标记为【待确认】。7. 只写这次需要改动的地方，已有的、不涉及本次变更的内容一律不要写。8. 避免任何技术性的表达： 8.1 不写前端、后端、接口、数据库、缓存、字段结构、组件、代码逻辑、技术框架等内容。 8.2 不使用“调用接口、返回数据、传参、判空、遍历、监听、渲染、缓存、异步、触发请求”等技术性词语。 8.3 数据来源只说明业务来源，例如“取商品配置中的活动名称”，不要写接口名称、字段路径或数据结构。 8.4 页面逻辑只描述业务规则，不推测具体技术方案。 8.5 除非我明确要求，否则不要输出技术方案、接口设计、数据表设计和开发实现建议。

说到底，AI 负责整理，你负责把需求想明白。研发看完能知道改哪里、怎么改，这份文档才算有用。