“文档写得很完整，但还是没法直接测。”

这句话不是来自业务方，而是测试负责人在评审会上的结论。更扎心的是，这版需求稿已经不是我纯手工写的，而是我把旧版 PRD、接口说明、缺陷单摘录和会议纪要整理后，交给 ChatGPT 5.6 Sol 做了第一轮重构。

那几天一直在折腾文档流，反复试过不少模型和工具。真正让人改观的，不是“哪个模型更强”，而是发现一个关键问题：需求文档场景里，最容易出错的环节并不是生成，而是把“看起来完整”误判成“可以交付”。

这篇文章不讲模型神话，也不讲万能 Prompt。只复盘一个具体问题：国内团队怎么低门槛把 ChatGPT 5.6 Sol 放进需求分析、技术文档、测试协作这条链路里，而且尽量少返工。结论有点反直觉：长上下文和高完成度，恰恰可能让团队更晚发现问题。

那次返工是怎么发生的

场景是一个遗留系统改造，业务不复杂，但规则碎：

• 老系统审批流沿用了很多年
• 新版要细化角色权限
• 历史数据要导入，不能简单清空重来
• 不同部门看到的字段和操作不一致
• 测试需要尽快补回归用例
• 研发希望需求别再出现“口头规则”

一开始的策略很直接：把资料一次性喂给 ChatGPT 5.6 Sol，让它先整理出一版可评审文档，再由人工修订。

第一版出来时，老实说有点惊喜。它做对了很多事：

• 把几份风格完全不同的材料统一成了一份顺畅的结构化文档
• 章节组织很稳，角色、流程、异常、验收范围都写到了
• 行文非常像一个有经验的人写的内部说明，不乱，也不散
• Markdown 和表格控制很省心，复制进知识库几乎不用重新排版

问题在第二天暴露。测试同事开始拆测试点，连续问了三次：

1. 审批回退到底是谁能发起？
2. 历史数据导入失败后，是允许局部重试还是整批回滚？
3. 同名角色在不同事业部权限不一致，这版是统一口径还是保留差异？

翻回文档一看，相关段落都“写了”，但每一条都写得太顺，顺到把歧义盖掉了。

举个最典型的例子。原始会议纪要里有一句模糊表述：

管理员可在特殊情况下回退流程节点。

模型生成后的版本是：

管理员在满足异常处理条件时，可对审批流执行节点回退，并保留操作日志。

这句话读起来很像标准规则，但问题在于，“特殊情况”原本就是未定义项。它可能是人员离岗、配置错误、数据填错，也可能是跨部门审批路径失效。不同原因，对应的权限、日志要求、回退边界完全不同。模型不是胡编，它只是把模糊区“抛光”成了完整句子。

这就是第一次返工的根因：文档成熟度高于事实成熟度。

后来保留了 ChatGPT 5.6 Sol，但换了用法

被打回之后，没有放弃这条链路。因为问题不在于它不能做，而在于让它做得太早、太满了。

ChatGPT 5.6 Sol 本身在这类任务上，确实有几个适合需求和技术文档的点。

长上下文很适合遗留系统，但不是材料越多越好

GPT-5.6 Sol 的 256K 上下文窗口，对“碎材料重组”特别有用。老项目往往没有一份真正完整的规范，只有：

• 旧 PRD
• 飞书或邮件纪要
• Jira 或缺陷单
• 接口说明
• 若干截图
• 研发口头补充

这些信息过去最耗时的不是写，而是找冲突、找遗漏、找谁说过什么。长上下文能把这些东西拉到同一个分析面里，这是它的价值。

但吃过一次亏后，反而不再把所有东西一把塞进去。因为上下文越大，模型越容易倾向于“归一化表达”，会主动消弭冲突，让文档变得顺滑。而需求梳理里，冲突不是噪音，冲突本身就是待确认事项。

所以现在会分批喂：

• 第一轮：当前版本必须生效的规则
• 第二轮：历史遗留约束和兼容条件
• 第三轮：让它只找冲突，不写成文档

这比一次性生成慢一点，但返工少很多。

它的文风太“像成品”，反而要主动制造粗糙感

这话听起来有点怪，但是真的。

GPT-5.6 Sol 的文风比很多旧模型更稳，尤其在内部文档、需求说明、测试范围整理这类任务上，很容易写出一份“像样的稿子”。对新人来说，这很有帮助；对团队协作来说，也很容易埋雷。

因为大家会默认：写得这么完整，应该已经定过了。

现在反而会强制它保留不完整性。比如在指令里明确写：

对材料中没有明确依据的规则，不要补全；
对存在冲突的权限定义，保留并列写法；
对无法确认的业务口径，统一标注为“待业务确认”；
不要为了文档连贯性自行消解歧义。

这类约束并不高级，但非常有用。需求文档不是文学作品，局部“不顺”有时比“顺到发亮”更诚实。

版本差异也会影响工作流，不只是“谁更聪明”

这次主要用的是 GPT-5.6 Sol。它比偏经济型的版本更适合这种材料重组任务，原因不只是“能力更强”，还有两点很实际：

• 长文逻辑更稳，跨章节定义不容易前后打架
• 对复杂约束的保持能力更好，尤其是在多角色、多流程、多异常的文本里

如果是 GPT-5.5 Instant 这一类更紧凑的路子，用来压缩会议纪要、出同步摘要、写短说明非常舒服，但在复杂需求文档里，有时会过度精简，把灰区缩掉。如果换成偏推理型的模式，它可能会很努力地“解释为什么”，但不一定适合大量日常交付。

这也是现在的一个判断：不是最强模型就适合所有文档场景，需求分析里，格式稳定和约束保持，有时比“更聪明”更值钱。

现在怎么拆这类任务：先问题树，再验收，再成文

真正把返工压下来的，不是某个 Prompt，而是把流程改成了三段。

第一段，不生成 PRD，先逼它列“问题树”

以前会说：“请根据以下材料输出完整需求文档。”现在第一轮只让它做需求拆解，而且不允许它“写漂亮”。

输出结构大概是这样：

• 已确认规则
• 角色与权限映射
• 主流程
• 异常流程
• 兼容条件
• 冲突描述
• 待补问题

这个阶段最重要的不是产出文档，而是把信息断点暴露出来。

比如它会列出这种很烦、但很值钱的问题：

• 历史单据撤回后是否重走审批？
• 同一用户兼具两种角色时，字段展示按并集还是优先级规则？
• 导入失败是业务失败还是技术失败，谁负责重试？
• “可编辑”是页面可改，还是保存后不触发审计？

这些问题如果没被列出来，后面再漂亮的文档都不稳。

第二段，不继续扩写，而是先做测试检查表

这是后来最依赖的一步。

很多人把 AI 用在需求上，盯的是“写得快不快”，但真正决定交付的是测试能不能测。所以问题树出来后，不会马上让它扩成正文，而是让它先生成一份测试检查表。

一份可复用的检查表示例

这个表的价值不在于格式，而在于它把“文档完整性”翻译成了“可验证性”。

非共识观察就在这里：输出越长，不一定越容易交付；能不能验，往往比写得像不像更重要。

第三段，最后才生成正式文档，而且必须带“待确认区”

只有前两段跑完，才会让 ChatGPT 5.6 Sol 输出正式需求文档。

而且现在一定保留一个很多人嫌丑的区块：

本版文档保留项

• 已确认规则
• 待业务确认项
• 默认假设
• 不纳入本期范围
• 测试前置条件
• 需要人工复核的专业口径

这东西会让文档看起来没那么“完美”，但很适合思否这种偏技术协作读者关心的落地场景：它让研发、测试、产品一眼知道哪些能开工，哪些不能拍脑袋。

一个失败样本：模型写对了通用流程，却写错了组织现实

这里放一个匿名处理过的片段。

原始规则是：

提交人可在审批完成前撤回申请。

GPT-5.6 Sol 生成后的版本是：

在审批未结束前，提交人可发起撤回，单据恢复为草稿状态，并通知当前审批节点处理人。

如果这是一个通用 OA 场景，它大概率没问题。但在当时的系统里，真实规则是：

• 到财务节点后，普通提交人不允许撤回
• 涉及金额字段变更时，撤回后必须重新生成审计记录
• 跨部门审批单撤回后不能回草稿，只能新建副本
• 某些已同步外部系统的单据，只能申请作废，不能撤回

注意，这不是模型“幻觉”，也不是它编了不存在的字段。它只是按常识生成了一个合理流程，但组织内的非标准限制被吃掉了。

所以把这类错误单独建了个失败样本库，专门存两种东西：

1. 看起来对，但不能上线的规则
2. 逻辑上通顺，但不符合组织现实的流程

这是后面做需求和测试协作时最有价值的材料，比继续追求一次成稿更管用。

这套方法顺手也能迁移到 Bug 排查，但边界要更严

后来也把这套流程的一部分迁到了缺陷分析和测试用例补全里，不过不会完全照搬。

适合让它做的：

• 把日志、报错、需求说明拼成问题时间线
• 根据已有缺陷单补充回归测试点
• 从接口文档中抽取前后置条件
• 给研发和测试生成同一份影响范围摘要

不适合直接交给它拍板的：

• 线上事故根因确认
• 安全漏洞定级
• 金融、医疗、政务场景的专业结论
• 面向外部的合规说明

尤其是日志分析，一定先脱敏。账号、手机号、姓名、证件号、订单号、公司名、病历信息，只要带真实身份线索，就不要原样送进去。AI 可以帮你整理，不等于它该直接接触全部原始数据。对外输出前也必须人工复核，特别是涉及行业规范的内容。

现在给同事的一个小 SOP

不是标准答案，但非常适合低门槛落地。

如果你要用 ChatGPT 5.6 Sol 整理需求或技术文档，先过这 6 步

1. 先脱敏，再喂材料
   删掉客户名、账号、手机号、证件信息、内部系统路径。
2. 材料分层，不要一次塞满
   先当前规则，再历史兼容，最后让它找冲突。
3. 第一轮只出问题树，不出正文
   目标是找缺口，不是写漂亮。
4. 第二轮先做测试检查表
   看能不能测，再看能不能写。
5. 第三轮才生成正式文档
   并保留“待确认区”。
6. 评审时只盯三类问题
   权限边界、异常路径、历史兼容。

这 6 步里，没有哪一步很“高级”，但它们共同解决了一个核心问题：避免把模型的表达能力误当成需求的确定性。

现在对“低门槛使用大模型”的理解，和半年前不一样了

半年前会觉得，国内团队要把 ChatGPT、Claude、Gemini、DeepSeek、Grok 这类模型用起来，关键是先找到稳定的调用方式，再解决接入成本。现在更倾向于另一个答案：真正的低门槛，不是能不能用上，而是能不能把它放进现有协作流程后不制造额外返工。

ChatGPT 5.6 Sol 很适合做这些事：

• 遗留系统规则整理
• 多份材料合并成可读文档
• 技术说明的结构化改写
• 测试前的影响范围梳理
• 跨部门同步稿压缩

但只要任务进入这些区域，会明显收紧：

• 权限与责任边界
• 合规审查
• 行业专业判断
• 对外承诺文本
• 真实生产数据分析

这些场景里，AI 只能辅助整理，不能做最终判断。尤其在金融、医疗、政务、教育、合同等高责任任务里，专业人员确认不是补丁，而是主流程的一部分。

现在宁愿接受一份“带待确认项的半成品”，也不想再拿一份“像成品的错误答案”去评审。如果要给这篇复盘留一个最具体的结论，那就是这句：

在需求和技术文档场景里，先让模型暴露不确定性，再让它生成完整性；顺序反了，返工通常只是延后，不会消失。