# 产品需求文档模板（PRD Template for Codex） **文档用途**：本模板用于后续编写产品需求文档（PRD），要求既能供人类团队进行需求评审，也能作为 AI / Codex 进行设计、代码生成、测试设计时的输入文档。 **适用范围**：新产品、版本迭代、功能模块新增、轻量改版、前后端交互类产品需求。 **使用原则**：填写人必须优先补充业务目标、范围边界、用户用例、规则约束；技术实现方案仅在必要时作为参考信息提供。 --- # 修订记录（必须位于文档前部） > 本节用于记录需求文档的变更历史，必须放在文档前部，位于标题与基本说明之后、正文规范和需求正文之前。 > 每次修改需求文档时必须新增或更新修订记录；重大需求变更必须单列一条，非重大需求变更可以合并为一条。 | 版本/序号 | 日期 | 变更类型 | 变更摘要 | 备注 | |-----------|------|----------|----------|------| | v0.1 | YYYY-MM-DD | 初始创建 | 创建本文档初稿 | ___ | 填写规则： - 所有需求文档版本号从 `v0.1` 开始记录，不从 `v1.0` 开始。 - 版本递增规则：重大需求变更必须递增一个小版本号，例如 `v0.1` -> `v0.2`；非重大需求变更可以合并记录在当前版本或同一条修订记录的备注中，不强制递增版本号。 - 修订记录统一按升序排列，初始创建记录在最上方，后续记录按时间和版本顺序向下追加。既有旧文档的历史排序不用强制调整，新建或后续新增记录按本规则执行。 - 修订记录不要求记录修订人；必要时可在备注中补充来源、依据或背景。 - 重大需求变更必须单列，不得与其他修改合并。重大需求变更包括：范围边界、核心功能、业务规则、权限规则、流程状态、验收标准、数据口径、对外承诺等变化。 - 非重大需求变更可以合并记录，例如：错字修正、措辞优化、格式整理、引用同步、局部说明补充等。 - 修改正文时必须同步检查本节；不能只改正文而不留修订记录。 --- ## 文档与原型同仓规范 > 当本 PRD 需要配套前端原型时，默认采用需求文档与原型同仓方式；如果本需求只交付文档或分析结论，不强制创建原型结构。 填写规则： - 创建、检查或修复文档与原型同仓仓库时，必须使用 `/Users/tanglei/.codex/skills/prototype-docs-same-repo/SKILL.md`。 - 推荐源码结构为：根入口 `index.html`、原型入口 `prototype/index.html`、原型源码 `src/`、Markdown 文档 `documents/`。 - 发布访问路径应提供 `/`、`/prototype/`、`/docs/`；线上只发布一个 `dist/`，构建命令固定为 `pnpm build`。 - 文档正文默认不在站内渲染，`/docs/*.md` 直接提供原始 Markdown 文件。 - 修改需求文档后，如影响页面结构、交互、状态或验收口径，必须评估是否同步修改原型；修改原型后，如改变需求口径，必须同步更新需求文档和修订记录。 --- ## DeepSeek 产品专家评审规范 > 新建或重构正式 PRD、重大需求文档、对外交付需求稿时，交付前必须至少进行一次 DeepSeek `pm` 产品专家评审；普通局部修改、格式整理、修订记录补充、已确认结论同步不强制调用 DeepSeek。 填写规则： - DeepSeek 评审应重点检查范围边界、对象定义、用户场景、业务规则、异常流程、验收标准和跨模块影响。 - DeepSeek 只作为第二意见、评审者或规划助手；最终需求结论必须由 Codex 结合本地资料和用户已确认口径复核。 - 不把未核验的 DeepSeek 意见直接写成已确认需求；如 DeepSeek 意见与现有资料冲突，应在待确认事项或评审说明中标明。 - 敏感材料应优先摘要或脱敏后再发送给 DeepSeek，除非用户明确授权发送完整原文。 --- # 0. Codex 使用规范（必须遵守） > 本节为 Codex / AI 使用本 PRD 时的统一规范，默认适用于所有基于本模板编写的需求文档。 ## 0.1 Codex 允许做的事 - 基于 PRD 拆分页面、模块、组件 - 生成前端 / 后端 / 配置 / 测试相关实现方案 - 推导状态管理、交互逻辑、显隐规则、异常流 - 生成 Demo、测试用例、验收检查清单 - 对“实现参考信息”进行结构化整理，并提出技术设计建议 ## 0.2 Codex 不允许做的事 - 不得擅自扩展 PRD 未明确写出的产品功能 - 不得将“待确认事项”视为已确认需求 - 不得将“示例”误当成最终实现 - 不得把技术实现方案反向写成产品需求 - 不得忽略“明确不做 / 不包含 / 边界限制”中的内容 ## 0.3 Codex 生成结果时的优先级 1. 业务目标与产品范围 2. 核心用户用例 3. 交互与状态规则 4. 验收标准 5. 实现参考信息 6. 待确认事项 ## 0.4 Codex 输出要求 - 如存在信息缺失，必须标注“待产品确认” - 如存在规则冲突，必须显式指出冲突点 - 如需要补全实现方案，必须以“建议方案”形式输出，不得伪装成已定需求 - 所有实现方案必须以本 PRD 的边界和目标为前提 - 执行完当前指令后，必须提供建议的下一步操作，给出后续方向的指导建议，帮助用户判断继续推进、补充确认、验证结果或收束任务的最佳路径 --- # 1. 文档目的 > 说明本文档希望解决什么问题，以及面向谁使用。 ## 1.1 本文档用途 - [填写：如“用于需求评审 / 用于指导设计开发 / 用于 AI 代码生成”等] ## 1.2 适用对象 - [填写：产品] - [填写：设计] - [填写：开发] - [填写：测试] - [填写：AI / Codex] --- # 2. 产品概述 ## 2.1 背景 [填写背景说明，包括： - 当前业务问题 - 目标场景 - 为什么要做这个版本 - 与现有产品/版本的关系] ## 2.2 目标 [按条列出本版本目标，例如： - 目标1 - 目标2 - 目标3] ## 2.3 关联文档 - MRD：[有 / 无 / 链接] - 用户故事集：[有 / 无 / 链接] - 功能用例集：[有 / 无 / 链接] - 设计稿：[有 / 无 / 链接] - 技术方案：[有 / 无 / 链接] ## 2.4 产品结构说明 [填写产品的总体结构、依赖关系、底层能力复用情况，例如： - 哪些能力沿用旧系统 - 哪些能力为新封装 - 本版本是新产品还是现有产品的升级 / 裁剪 / 独立版] --- # 3. 版本范围与边界 ## 3.1 本版本包含 - [模块 / 功能1] - [模块 / 功能2] - [模块 / 功能3] ## 3.2 本版本不包含 / 明确不做 - [明确不做项1] - [明确不做项2] - [明确不做项3] ## 3.3 范围说明 [填写版本范围判断原则，例如： - 只实现本 PRD 列出的功能 - 未提及功能默认不做 - 边界外需求进入后续迭代] > **填写规范**： > - 本章必须写清楚“做什么”和“不做什么” > - 所有容易被误扩展的内容必须写入“不包含 / 明确不做” > - Codex 必须优先遵守本章 --- # 4. 用户角色与使用场景 ## 4.1 目标用户 [填写目标用户类型，例如： - 用户类型1 - 用户类型2 - 用户类型3] ## 4.2 核心使用场景 [填写主要使用场景，例如： - 场景1：用户如何进入系统 - 场景2：用户如何完成核心操作 - 场景3：运营 / 管理角色如何配置] > **填写规范**： > - 不要求写非常完整的画像，但至少要写清“谁会用、在什么场景下用” > - 如果有不同角色，请区分终端用户 / 管理用户 / 内部运营用户 --- # 5. 用户用例（必须重点补齐） > 说明：本章是 Codex 最关键的输入之一。 > 每个核心功能至少对应一个标准化用户用例。 > 推荐格式：目标、前置条件、主流程、结果、规则、异常 / 边界。 --- ## UC-001：[用例名称] ### 目标 [填写用户通过该用例想达成什么目标] ### 前置条件 - [条件1] - [条件2] ### 主流程 1. [步骤1] 2. [步骤2] 3. [步骤3] ### 结果 - [预期结果1] - [预期结果2] ### 规则 - [规则1] - [规则2] ### 异常 / 边界 - [异常场景1] - [边界情况2] --- ## UC-002：[用例名称] ### 目标 [填写] ### 前置条件 - [填写] ### 主流程 1. [填写] 2. [填写] 3. [填写] ### 结果 - [填写] ### 规则 - [填写] ### 异常 / 边界 - [填写] --- ## UC-003：[用例名称] [按同样结构继续补充] --- > **填写规范**： > - 不要只写一句概述，必须补全主流程 > - 必须把“异常 / 边界场景”写出来 > - 若存在配置缺失、权限不足、非法访问、空数据、关闭状态等情况，必须单独写成用例或边界 > - 用户用例优先覆盖真实行为路径，而不是系统内部实现逻辑 --- # 6. 功能需求矩阵 | 功能ID | 功能名称 | 关联用例 | 优先级 | 状态 | |--------|---------|---------|--------|------| | F001 | [功能名称] | [UC-001] | P0/P1/P2 | 待设计/待开发/已完成 | | F002 | [功能名称] | [UC-002] | P0/P1/P2 | 待设计/待开发/已完成 | | F003 | [功能名称] | [UC-003] | P0/P1/P2 | 待设计/待开发/已完成 | > **填写规范**： > - 每个功能应尽量关联至少一个用例 > - 功能矩阵只做总览，不承担细节说明职责 > - 名称应与后续详细说明保持一致 --- # 7. 功能详细说明（推荐按“目标 / 规则 / 交互 / 边界”填写） > 每个功能都按统一结构描述，方便评审和 AI 理解。 --- ## 7.1 [功能模块名称] ### F001：[功能名称] **功能目标** [填写该功能存在的目的] **交互流程** 1. [步骤1] 2. [步骤2] 3. [步骤3] **强约束 / 规则** - [规则1] - [规则2] - [规则3] **展示 / 显示要求** - [展示要求1] - [展示要求2] **明确不做** - [不做项1] - [不做项2] **待确认** - [如有缺失、冲突、待评审项，写在这里] --- ## 7.2 [功能模块名称] ### F002：[功能名称] **功能目标** [填写] **交互流程** 1. [填写] 2. [填写] **强约束 / 规则** - [填写] **展示 / 显示要求** - [填写] **明确不做** - [填写] **待确认** - [填写] --- > **填写规范**： > - 功能目标写“为什么需要这个功能” > - 交互流程写“用户如何使用 / 系统如何响应” > - 强约束写“必须遵守的规则” > - 明确不做写“不能被实现进去的内容” > - 待确认写“当前不能确定但不能乱补的内容” --- # 8. 交互与状态规则（集中归纳） ## 8.1 切换规则 - [规则1] - [规则2] - [规则3] ## 8.2 显隐规则 - [规则1] - [规则2] - [规则3] ## 8.3 状态规则 - [规则1] - [规则2] - [规则3] > **填写规范**： > - 凡是在多个功能中重复出现的规则，都要在本章集中归纳 > - Codex 应优先使用本章作为“统一规则源” > - 若本章与单个功能描述冲突，必须在待确认项中指出 --- # 9. 数据与配置说明（实现参考，非主需求） > 本章用于保留必要的数据基础、字段参考、配置说明。 > 若本项目不需要写数据层信息，可只保留大纲。 > 本章不是主需求约束，不应替代业务规则。 ## 9.1 基础数据 - [说明当前数据来源] - [说明是否复用旧版本数据] - [说明是否新增必要字段] ## 9.2 原始数据结构参考 ### 9.2.1 基础配置项 - [字段1] - [字段2] - [字段3] ### 9.2.2 列表 / 资源字段 - [字段1] - [字段2] ### 9.2.3 状态 / 交互字段 - [字段1] - [字段2] > **填写规范**： > - 仅在业务已明确提及数据基础时填写 > - 不要把未确定的数据模型硬写死 > - 若没有把握，请写章节标题，不补内容 --- # 10. 验收标准 | AC 编号 | 功能 | Given | When | Then | |---------|------|-------|------|------| | AC-001 | [功能名] | [前提] | [操作] | [结果] | | AC-002 | [功能名] | [前提] | [操作] | [结果] | | AC-003 | [功能名] | [前提] | [操作] | [结果] | > **填写规范**： > - 验收标准必须覆盖核心功能、关键边界、异常场景 > - 不要只写“能正常使用”这类模糊描述 > - 优先覆盖：入口、主流程、切换规则、空数据、非法访问、显隐规则、多端适配、语言适配等 --- # 11. 执行计划 | 里程碑 | 日期 | 内容 | |--------|------|------| | Phase 1 | [日期] | [内容] | | Phase 2 | [日期] | [内容] | | Phase 3 | [日期] | [内容] | > **填写规范**： > - 日期可以精确到天，也可以写“X月计划” > - 若计划未确定，可先写阶段目标，不强行写时间 --- # 12. 风险与依赖 | 风险/依赖 | 类型 | 影响 | 应对 | |-----------|------|------|------| | [风险项1] | 风险/依赖 | 高/中/低 | [应对方式] | | [风险项2] | 风险/依赖 | 高/中/低 | [应对方式] | > **填写规范**： > - 风险包括：需求不清、素材不足、规则缺失、兼容性问题、边界膨胀等 > - 依赖包括：设计稿、接口、第三方能力、后台配置、业务资源等 --- # 13. 待确认事项清单 1. [待确认事项1] 2. [待确认事项2] 3. [待确认事项3] > **填写规范**： > - 所有缺失、冲突、疑似误写内容都必须进入本章 > - Codex 只能把本章内容当作“待确认事项”，不能当成已定需求 > - 若某项缺失会影响开发，需标明影响范围 --- # 14. 供 Codex 使用的执行说明 ## 14.1 Codex 允许做的事 - [项目级允许事项1] - [项目级允许事项2] ## 14.2 Codex 不允许擅自扩展的内容 - [禁止事项1] - [禁止事项2] ## 14.3 Codex 输出时必须遵守的优先级 1. [优先级1] 2. [优先级2] 3. [优先级3] > **填写规范**： > - 如第 0 章已足够明确，可简写或复用 > - 若项目有特殊限制，例如“不得改动旧版逻辑”“必须兼容某引擎”“不得自动补齐某模块”，需在这里再次强调 --- # 15. 附录（可选） ## 15.1 原文保留说明 [如需要说明本版是从旧 PRD 重构而来，可写在这里] ## 15.2 术语说明 - [术语1]：[解释] - [术语2]：[解释] ## 15.3 参考资料 - [资料1] - [资料2] --- # 附：PRD 编写总规范（长期复用） ## A. 必填项 以下章节默认必须填写： - 2. 产品概述 - 3. 版本范围与边界 - 5. 用户用例 - 6. 功能需求矩阵 - 7. 功能详细说明 - 8. 交互与状态规则 - 10. 验收标准 - 13. 待确认事项清单 - 14. 供 Codex 使用的执行说明 ## B. 可选项 以下章节可按项目复杂度决定是否详细填写： - 4. 用户角色与使用场景 - 9. 数据与配置说明 - 11. 执行计划 - 12. 风险与依赖 - 15. 附录 ## C. 写作原则 1. 先写业务目标，再写功能，不要反过来 2. 先写边界，再写实现参考，不要把实现方案冒充需求 3. 不清楚的内容不要脑补，统一放入“待确认事项” 4. 同一规则如在多个地方出现，必须在“交互与状态规则”中汇总 5. 所有“明确不做”的内容必须单独写出来 6. 所有核心功能都应被用户用例和验收标准覆盖 ## D. 交给 Codex 前的检查清单 - [ ] 是否写清楚“本版本做什么 / 不做什么” - [ ] 是否每个核心功能都有对应用户用例 - [ ] 是否把边界场景、异常场景写出来 - [ ] 是否把待确认事项单独列出 - [ ] 是否把重复规则统一汇总 - [ ] 是否避免把技术实现误写成产品需求 - [ ] 是否给出了 Codex 明确的禁止事项与优先级