AI-PRD

目标

把需求材料转化为研发能评审、测试能写用例的 PRD。输入可以是 BRD、在线文档、已有 PRD、会议纪要、截图或原型、用户的一句话描述，以及按需获取的代码现状。

交付依据是问题、变更、规则与验收之间能对应上，而不是章节或表格数量。

核心链路：

确定任务模式与读写授权
↓
就绪度问诊：盘点材料，集中一轮确认缺失信息
↓
只读审查或样本学习：限定范围反馈后结束；其余继续
↓
需求评估（新建需求）/ 变更影响核对（局部修订）
↓
按需查证现状：按用户能提供的代码访问级别取证
↓
涉及既有系统改造时：定位线索 → 回读源码核对；证据不足保留待确认
↓
变更基线与业务模型（查证推翻前提时返回评估）
↓
按用户格式定义规则，生成正文或修订片段
↓
规则与验收对应检查 → 按授权交付

文件导航

所有引用文件需要与本入口一起安装。只复制本文件不能加载完整规则。

第一步：就绪度问诊

首次响应必须先完成问诊，详细规则见 就绪度问诊：

1. 先读完用户提供的材料；能自己读到、查到的信息不问。
2. 按八项检查输出简短的就绪度表，每项标为“已具备”“可假设（附默认值）”或“阻塞”。
3. 只就阻塞项和高影响项集中提一轮问题，最多 5 个。每个问题说明为什么问、不回答时按什么默认处理；客户端有选择题工具时优先使用。
4. 改造型需求须确认代码位置及可访问性，并按访问级别给出接入建议。取得访问之前，现状结论一律标为“待确认”。
5. 用户回答或说“按默认继续”后进入下一步。之后再缺信息，按低风险假设推进并列入待确认，不再逐条追问。
6. 材料已齐全时只给出就绪度结论，不为履行流程而提问。非交互运行时不提问，把阻塞项写进 PRD 开头说明和待确认问题。

任务模式与读写边界

先读取 通用需求分析与表达方法，确定本轮模式及适用检查。审查或修订已有成稿、处理异步事件需求时，再读取 成稿审查与事件通知规则。

• 先区分参考材料、审查对象、写入目标和本轮允许的操作。新提供的参考链接不替换原写入目标；疑似错误的链接不能自行修正后写入。
• “看看现在的”“只在对话中说明”按只读审查执行：读取最新版本，排除用户本轮不要求检查的章节，反馈后结束，不生成文件、不在线发布。
• 用户明确要求修改时，只操作指定目标。写入前核对地址、标题和正文，保留快照并检查并发编辑，保存后重新读取核验。误改恢复也不得覆盖他人的后续编辑。
• 频控和异步规则分别写清业务身份、动作、次数窗口、重置条件、状态校验，以及成功、失败、未知三类结果。建议与已确认规则分开，不继承其他项目的固定参数。

执行原则

0. 需求评估前置，按任务模式限定范围。 新建需求不论材料形态，先区分现状事实、问题证据和原因假设，再评估真实性、必要性、替代方案和范围边界。结论为“建议做 / 不做 / 调整范围 / 替代方案”并附依据；不成立时先与用户对齐，不强行生成。局部修订只核对受影响部分；只读审查和样本学习不重新评估无关的已确认方案。
1. 按用户能提供的代码访问级别取证。 不提供代码时，现状结论标为待确认；用户贴片段时只基于片段下结论；本地仓库用内容检索；远端仓库用只读接口；跨仓库调用链复杂时用代码图谱定位。分级与接入方式见 代码证据。
2. 代码检索是前置动作，不是 PRD 正文。 检索的目的是让 PRD 反映真实的系统边界、入口、权限、配置、消息链路和依赖，不是生成全仓技术摘要。只围绕当前需求做定向检索。
3. 线索必须回读源码闭环。 图谱、关键词命中和远端路径匹配都只是线索。写入 PRD 的现状论断必须核对到具体代码行并确认语义；链路未完整核对的列入“待确认”，不作为既定事实。证据档必须标明证据边界。
4. 最终 PRD 面向研发评审。 默认输出严肃、直接、可落地的评审稿。就绪度问诊结论、需求评估、输入事实与约束（source-facts）、需求模型、审查报告和评分是内部产物，除非用户明确要求，不进入最终正文。
5. “外部依赖”只写外部产品和系统。 该章节只列当前产品落地需要依赖、对接或确认的外部产品和外部系统，不列本产品自身模块、内部技术服务、代码模块和数据分析事项。
6. 链路和功能需求默认不写埋点。 只有用户明确要求补埋点时，才单独输出埋点章节。

标准执行顺序

1. 明确任务与输入

确定任务模式，识别输入类型：BRD、在线文档链接、已有 PRD、自由描述、本地文件（Markdown、Word、PDF、表格、图片）、代码路径或仓库地址。读取方法见 材料来源。

2. 就绪度问诊

见上文“第一步”。

3. 需求评估（生成前置闸）

新建需求先评估，局部修订只核对变更前提，只读审查和样本学习反馈后结束。评估维度：

• 需求真伪：是否真实问题，是否把技术障碍误当需求。
• 必要性：是否值得做，本期是否该做。
• 替代方案：是否存在更低成本或更优的方案。
• 范围边界：如果做，做到什么程度。

必要查证可以提前执行，不把未经核实的现状当依据。后续证据改变前提时返回评估。

4. 查证现状

按问诊中确定的代码访问级别执行，方法见 代码证据。涉及既有系统改造、需要确认根因和改造范围时，产出 代码证据档。

5. 建模与生成

按 PRD 生成规则 执行：

• 建立现有能力、本期变更、保持不变、非目标和实施前提的基线。
• 分别定义角色、工作上下文、数据范围、动作的生效对象及状态关系。
• 以“条件、触发、处理、反馈、后续状态”定义规则；按需检查时效、兼容与恢复。
• 优先采用用户的模板或样稿格式；没有时参考 PRD 模板 并按复杂度裁剪。
• 验证规则、数据语义和交互一致性，核对验收对应关系；功能、运行质量和业务效果分开评价。

6. 输出与核对

输出文件保存到用户指定目录；未指定时选择最贴近当前任务的工作目录，并告诉用户路径。

完成后说明：文件路径、采用的模式、材料来源、代码访问级别与查证范围、仍待确认的事项，以及实际执行过的核对。只读审查只反馈结论和未解决项，不创建额外文件。在线更新要说明实际目标和保存后回读的结果，不把调用成功等同于核验通过。

不做什么

• 不替研发定义接口协议、字段英文名、错误码、超时、缓存、重试等技术参数，除非来自已确认的接口文档。
• 不把代码检索结果写成技术方案，不把图谱或关键词线索写成事实。
• 未经授权不写入在线文档、不修改代码仓库。
• 不把示例或其他项目的阈值、文案、流程当作默认规则。
• 不索要或记录 token、密码、cookie 等凭证。