「本期不做」写在范围声明里，正文却详细描述了它的交互 · 研发按正文实现，范围争议回到产品头上
文档与评审 · 真实业务触发
找茬预演（DC-01）改完的 PRD 提交前，江晓还有最后一道担心：改过六轮的文档，前后还一致吗？她记得自己在第二轮把「批量导出」挪进了「本期不做」，但第四轮改权限章节时好像又引用了批量导出的交互。研发的习惯是按正文写代码、不读范围声明 —— 一旦矛盾，实现的就是「做了说不做的」。这类问题她自己读三遍都未必能挑出来，因为作者永远看不出自己的笔误。
不是流程描述，是调研出来的真痛点 —— 每条可点开核对出处
变化不在「快」，在「参与的角色」和「覆盖的范围」
5 步 · 每一步的产出都是下一步的输入
痛感 3 × AI 适配 5 ÷ 落地难度 2 = 7.5
最大差异点 · 不要求文档格式规范。任何格式的 PRD 扔进来 —— 矛盾点逐处定位（章节+段落），三分钟看完一份终审报告。
评分口径：痛感看「这事没做好谁会生气、生气到什么程度」； AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」； 落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。
判断标准只有一个：这份东西能不能直接进企业的流程
不做「自动改写文档」—— 终审只标矛盾与位置，怎么改、改哪头，是产品经理的判断（改声明还是改正文，往往涉及范围决策）。
Live Demo 里有一个完整案例的每一步，包括 Agent 在哪一步拦住了