产品 PRD 开发视角自查
使用这个 skill，从“开发能否正确实现、测试能否正确验收”的角度检查产品需求文档。
目标不是润色文案，也不是替产品脑补方案；目标是找出会导致开发、测试、数据、上下游系统或上线切换需要猜测的问题，并输出给产品修正文档。
当前协作默认包含 AI 开发代理，因此 PRD 还必须能被 AI 稳定理解、拆解和执行。
问题归属原则
审查时必须区分“产品 PRD 必须补充”和“技术方案必须明确”，不要把所有实现细节都要求产品写进 PRD。
- 产品 PRD 必须补充：业务目标、需求范围、用户可见行为、页面交互、状态/字段业务含义、数据生产方和消费方、验收口径、上线业务约束、是否复用以及复用对象的可定位信源和业务差异。
- 技术方案必须明确：表结构和存储位置、接口设计和报文、组件复用实现方式、缓存/幂等/重试/补偿、历史数据迁移脚本、BI 读取技术路径、代码层现有逻辑解读、公共组件影响回归方案。
- 跨团队待确认：BI、SAP、第三方系统、外部接口、数据平台、审计或财务等非产品单方能决定的口径；PRD 只需说明业务期望和依赖关系，具体字段/接口可在技术方案或对接文档中闭环。
- 如果 PRD 已经说明业务期望、影响对象和验收口径，缺少的是实现方式，不要升级为 P0/P1 产品缺陷；应放入“技术方案需明确”或“跨团队确认”。
- 如果缺少业务决策会导致技术方案无法选择，例如是否产出数据、是否展示给用户、是否影响任务完成、是否进入报表统计，则仍属于产品需补充。
- 原型/UI 不是所有 PRD 的必需项。仅当需求涉及用户可见页面、交互、展示、导出、操作路径或复用现有界面时，才把原型、截图标注、页面路径或 UI 说明作为必要材料；纯后端、数据、接口、定时任务或系统集成类需求，应按流程、字段、接口契约、异常处理和验收口径审查。
调用方式示例
用户可以用以下方式触发本 skill：
使用 product-prd-review 检查这份 PRD <文档链接>帮我从开发实现视角自查这份需求文档 <文档链接>复查新版 PRD，看看旧问题是否修掉了 <文档链接>这份 PRD 能不能进入开发？帮我做开发准入审查 <文档链接>帮我找出这份原型/导出模板/验收草稿里会阻断开发的问题
版本与更新策略
- 本 skill 发布源：
https://skillhub.cn/skills/product-prd-review。 - 正常 PRD 审查时不要自动联网检查或更新本 skill，避免干扰审查、引入网络依赖或静默覆盖用户本地修改。
- 只有当用户明确要求“检查/更新 product-prd-review skill”时，才提示或执行更新操作。
- 更新前必须提醒用户本地 skill 可能有未提交改动；如需执行更新，应先检查本地差异并避免静默覆盖。
- 使用 SkillHub CLI 更新时，可提示用户按实际 registry / namespace 调整命令，例如：
skillhub install product-prd-review --agent codex --force。
守门人原则
审查时采用守门人心态：宁可多挑问题，不可漏过缺陷。
- 不因为“看起来能理解”就放过含糊表述；只要开发或测试需要猜，就列为问题。
- 不替产品补业务背景、目标、现状、优先级或边界；文档没写清楚，就要求补充。
- 不只检查功能怎么做，还要检查为什么做、是否值得做、谁受影响、是否能验收。
- 不只检查新增逻辑，还要检查对存量流程、上下游、报表、权限、数据和运营动作的影响。
- 对内部矛盾、术语不一致、优先级不合理、利益相关方遗漏保持敏感，即使不一定阻断开发，也要提示产品修正文档。
- 站在 AI 开发协作视角检查文档：如果 AI 需要靠猜上下文、翻图片、补术语、推断字段或自行决定边界，就要求产品补充。
工作流程
-
完整读取需求材料。
- 如果用户提供在线文档、Wiki、PRD、原型或导出模板链接，例如飞书文档、Notion、Confluence、Figma、墨刀等，并且有对应工具，读取最新版内容。
- 如果文档中嵌入电子表格、多维表、数据表、图片、导出模板、字段表或引用文档，需要继续下钻读取会影响开发和测试的部分。
- 如果无法直接读取，让用户补充 PRD 正文、字段表、导出模板或关键链接内容；仅在需求涉及用户可见页面或交互时，要求补充原型截图、页面路径或 UI 说明。
- 记录可用的版本依据，例如文档标题、业务版本号、版本历史、在线文档 revision_id、更新时间、审查时间。
- 如果用户要求复查新版文档，或文档版本号 / revision_id / 版本历史显示发生更新，必须检查是否有上一版审查报告、旧版文档内容或版本历史作为对比基线；有基线则对比旧问题状态和新增变更，无基线则明确写“无可对比基线，仅审查当前版本”。 -
先确认开发边界，再检查细节。
- 检查业务背景是否清晰，是否能回答“为什么要做、解决什么问题、当前现状是什么、目标收益是什么”。
- 检查业务现状描述是否准确，是否有数据、流程、角色、系统现状支撑；如果无法从文档验证，要列为待确认。
- 识别本次做什么、不做什么、延期什么、人工处理什么、依赖什么系统。
- 检查 PRD 是否明确影响的端、仓库/服务/模块、页面、接口、定时任务、数据表、字典、权限点、导入导出、配置项和上下游系统。
- 检查变更影响是否完整评估：直接影响、间接影响、存量数据、历史流程、报表导出、权限、运营动作、上线切换。
- 检查是否遗漏利益相关方：产品、研发、测试、运营、业务、数据、审计、财务、客服、客户、合作方、第三方系统或其他消费方。
- 如果缺少影响闭环，要转成产品确认问题：谁产出数据、谁消费数据、哪些逻辑变更、哪些保持兼容、是否需要上线开关或人工切换。
- 标题、功能清单、正文、字段表、导出模板之间有冲突时，必须列为问题；涉及界面时，还要检查原型、截图或页面说明是否与正文冲突。
- 检查术语使用是否前后一致，需求描述是否内部矛盾，优先级标注是否与影响范围、紧急程度和依赖关系匹配。
- 检查是否需要流程图：跨角色、跨系统、审批/状态流、异步任务、复杂分支、异常回退、导入导出链路、上下游联动、旧复杂逻辑改造等复杂流程必须有流程图、时序图、状态图或流程表。
- 如果用户额外给出范围约束，以用户约束优先，例如“费用不做”“旧流程人工停”“只做 APP 不做 PC”。 -
按开发实现视角审查。
- 每条业务规则都要追到数据来源、字段、字典/枚举值、触发时机、权限、页面、导出、状态流转和异常分支。
- 遇到状态、类型、原因、分类、来源等值时，检查是否明确使用已有字典值、后端枚举、数据库 code，还是需要新增。
- 遇到“复用”“参考”“同某功能”“按原逻辑”“保持现状”“和 XX 一致”等表述，必须检查是否给出可定位的复用信源，例如文档链接、页面路径、原型链接、接口名、字段表、现有规则说明，并检查本次业务差异、适用范围和不复用部分是否明确；具体如何复用组件、接口和代码逻辑可归入技术方案。
- 遇到跨系统共用状态，例如已开票、已审核、已结算、已推送、已回写、处理中、失败、作废等，必须检查各系统来源字段、状态值、业务含义、展示文案和后续动作是否一致。
- 遇到资金、费用、积分、额度、库存、订单、凭证、贷项、冲销、退款等可分配或可抵扣对象，必须检查分配顺序、承载对象、剩余量处理、审计记录、对账字段和回滚/补偿规则是否明确。
- 遇到外部接口或跨系统接口，必须检查接口契约是否可联调：字段名、类型、必填、数组层级、批量映射、状态码/错误码、空结果、幂等键、重试和示例报文是否完整且一致。
- 遇到“BI 读取路径、保存到哪张表、接口怎么设计、公共组件怎么改”等实现问题，先判断产品是否已经给出业务消费方、统计口径和验收结果；若已经给出，则列为技术方案需明确，不要求产品在 PRD 里写技术实现。
- 遇到“实时”“自动”“同步”“推送”“导出”“随机”“去重”“生效”等词，要检查触发条件、边界、失败处理和可追踪性。
- 只输出会影响实现正确性的问题，不输出单纯语病、排版、风格建议。 -
按 QA 验收视角审查。
- 检查正常路径、边界值、重复数据、配置启停、编辑删除、权限差异、空数据、异常数据、跨周期数据和历史数据。
- 检查验收标准是否可观察、可复现、可用测试数据验证。
- 先判断本需求是否涉及用户可见界面、交互、展示、导出或操作路径；不涉及时，UI/原型检查标为“不适用”，不要因为缺少原型或 UI 设计而扣分或阻断开发。
- 涉及界面时，检查 UI 原型和需求描述是否一致：页面路径、字段名、按钮、校验、默认值、展示值、导出列、交互状态是否对齐。
- 涉及界面时，判断哪些原型页面需要 UI/UX 设计介入，哪些属于简单后台/配置/列表页面，可参考现有组件、原型和历史 UI 风格直接开发。
- 涉及界面但 PRD 缺少页面复杂度、交互复杂度、视觉要求或设计交付物说明时，列为产品确认问题，避免开发自行补设计决策。 -
输出可直接发给产品的问题清单。
- 报告必须先讲重点：在详细分级问题前先给“结论先行”，说明能否开发、能否进入技术方案、最主要阻断点和下一步动作。
- 如果是在复查新版文档，先列“版本更新检查”和“已明确/无需再问”的点。
- 复查时必须标注旧问题状态：已关闭 / 部分关闭 / 未关闭 / 新增问题 / 无法判断，并说明判断依据。
- 再列“阻断开发的问题”和“需要产品确认的问题”。
- 必须把问题按后续处理归属分开：产品需补充、技术方案需明确、跨团队确认。不要把技术方案项包装成产品必须补 PRD 的问题。
- 问题要具体到产品能改文档，避免笼统写“逻辑不清楚”。
- 不要替产品做未确认的业务决策；可以给出建议选项，但要标注“请确认”。 -
检查 PRD 是否适合 AI 开发协作。
- 检查文档是否有稳定结构：背景、目标、范围、非范围、业务规则、字段、流程、异常、验收。
- 检查关键口径是否用文本表达，而不是只藏在图片、截图、聊天记录或原型标注里。
- 检查规则是否能被拆成明确任务，字段是否能被定位，示例是否覆盖正常、边界和异常。
- 检查是否存在“同上”“见图”“按原逻辑”“参考 XX”“同 XX”“系统自动处理”“正常展示”等 AI 难以落地的模糊表达；如果是复用已有能力，必须能从文档定位到被复用逻辑和差异边界。
- 检查是否明确哪些结论已确认、哪些仍待产品/业务/研发/三方确认，避免 AI 把猜测当决议。 -
给出开发准入与 AI 开发准备度结论。
- 必须在报告末尾明确判断当前 PRD 是否可以进入编码开发、是否可以进入技术方案详细设计、AI 是否可以开始拆任务/写开发计划。
- 结论不能只写“存在问题”；必须给出可执行状态：可以开发 / 可先做技术方案详细设计 / 仅可做预研或影响评估 / 暂不建议开发。
- 如果存在 P0，默认结论为“暂不建议开发”；除非 P0 与当前开发范围无关，必须说明为什么不阻断。
- 如果存在影响实现边界、数据口径、接口契约、权限、保存结果、复用差异、验收标准的 P1，默认不建议直接编码，但可以判断是否允许先做技术方案详细设计。
- 如果允许 AI 先做开发计划或技术方案，必须列出计划/方案可覆盖的范围，以及仍需产品确认后才能编码的阻塞项。
必查重点
完整自查或复杂 PRD 必须读取 references/checklist.md。
如果需求属于某个已有业务系统或具体项目，还必须读取 references/project-checklist.md，结合项目特性检查技术方案可行性和影响范围，但不要要求产品提供具体代码实现。
如果用户要求生成 PRD 模板或补正文档结构，优先使用 references/prd-template-with-examples.md，并按实际需求删除不适用章节。
始终检查这些方向：
- 业务背景：为什么做、现状是什么、问题是否真实、目标和收益是否清晰。
- 开发边界：端、页面、服务、接口、任务、表、字典、配置、权限、导入导出。
- 变更影响：直接/间接影响、存量数据、历史流程、利益相关方、上线切换。
- UI/原型适用性：先判断需求是否涉及用户可见页面、交互、展示、导出或操作路径；纯后端、数据、接口、定时任务或系统集成类需求标为“不适用”，不因缺原型/UI 阻断。
- UI/原型一致性：涉及界面时，页面路径、字段、按钮、状态、校验、展示、导出是否和 PRD 对齐。
- UI 设计介入判断：涉及界面时，判断复杂新流程、移动端关键体验、跨端体验、新组件/新交互、数据可视化、品牌/营销展示、用户高频操作等是否需要 UI/UX；普通后台列表、配置表单、详情页、导出页、字段微调等是否可按现有风格直接开发。
- 复用与参考边界：复用已有页面、组件、接口、流程、配置、原型或“按原逻辑”时，是否提供文档链接/页面路径/接口名/字段表/规则说明，并列清本次复用范围、差异点、不复用内容和回归范围。
- 流程图完整性：复杂业务流程或旧复杂逻辑改造是否有流程图、时序图、状态图或流程表；流程节点、角色、系统、触发条件、异常分支、终态是否和正文一致；旧逻辑哪些保留、替换、废弃、兼容是否说清楚。
- 文档一致性：术语、优先级、标题、功能清单、正文、原型、字段表是否互相矛盾。
- 业务规则：公式、阈值、包含/不包含、四舍五入、上限、优先级、随机、去重。
- 数据口径：来源表、字段、字典值、枚举 code、时间窗口、去重维度、历史/当前值。
- 跨系统状态口径：同一业务状态在各系统、页面、接口、报表、导出中的来源字段、状态值、业务含义和后续动作是否一致。
- 分配与抵扣可审计性：资金、费用、额度、订单、贷项、凭证、库存等分配逻辑是否有确定顺序、承载规则、剩余处理、审计字段、对账口径和补偿方案。
- 接口契约可联调性：字段名、类型、必填、数组层级、批量请求与响应映射、错误码、空结果、幂等、重试、超时和示例报文是否可直接用于联调。
- 生命周期：新增、编辑、启用、停用、删除、导入、生效时机、历史数据处理。
- 上下游闭环：数据生产方、消费方、接口、任务、消息、报表、导出、通知、兼容影响。
- 调度与异步：定时节点、补偿、重试、并发、延时推送、人工切换。
- 权限：角色名称与角色编码、菜单权限、按钮权限、数据权限、组织架构范围、谁可见、谁可配、谁可操作、谁可导出。
- 导出报表：按钮位置、导出范围、列含义、空值、示例数据和字段说明是否一致。
- 验收标准：是否有可验证口径、边界样例、异常样例、测试数据前置条件。
- AI 开发协作：结构是否稳定、上下文是否完整、规则是否可拆解、字段是否可定位、图片信息是否有文字说明、待确认项是否显式标出。
- 项目上下文专项：影响端、技术可行性前提、菜单权限、字典/配置、上下游协作、外部/AI 能力依赖、Web/移动端差异、数据验收、上线风险。
问题写法规则
问题要让产品能直接回答和修正文档。
好：
同一业务对象在同一周期命中多个规则时，是否只处理一次？如果只处理一次，处理记录归属哪个规则？
不好：
去重逻辑不清楚。
不要问产品回答不了的纯代码问题。把它转换成业务口径：
“已审核/已复审/已驳回”是否是本需求最终使用的状态集合？这些状态是否沿用系统已有字典值？
如果问题应该由技术方案承接，不要硬转成产品问题，直接标注：
技术方案需明确：在不改变产品口径的前提下，陈列项内商品与商品列表的最终保存位置、接口提交字段和 BI 读取路径由技术方案闭环。
问题分级
默认按以下级别归类问题：
- P0 严重问题：不确认就无法正确开发、验收或上线；会导致范围错误、数据错误、权限越权、核心流程不可用、依赖不可控。
- P1 重要问题：会明显影响开发方案、排期、联调、测试覆盖或上线风险；需要产品补正文档后再进入实现。
- P2 一般问题：不一定阻断开发，但会造成理解偏差、测试遗漏、边界不清或后续返工。
- P3 提示：文档可读性、AI 协作友好度、验收补充、表达优化等建议。
开发准入默认影响：
- 存在 P0 时，默认阻断编码开发，除非该 P0 与当前开发范围无关且已写明临时约束。
- 存在 P1 时，需要判断是否影响核心技术方案；若影响数据口径、接口、权限、保存结果、复用差异或验收标准，默认不建议直接编码。
- 仅存在 P2/P3 时，不应默认判定“不建议开发”；P2 可在开发中同步澄清，P3 仅作为优化建议。
- 如果多个 P2 集中在同一核心流程，叠加后会影响验收、数据正确性或开发方案，应升级为 P1。
- P3 原则上不影响开发准入，除非暴露出文档结构导致 AI 或研发无法定位关键规则，此时应改判为 P2/P1。
输出格式
默认输出以下格式的审查报告：
# PRD 审查报告
## 审查概览
| 项目 | 结果 |
|------|------|
| 文档名称 | [标题] |
| 审查时间 | YYYY-MM-DD HH:mm |
| 审查深度 | 快速/标准/深入 |
| 版本依据 | 业务版本号 / revision_id / 版本历史 / 无 |
| 审查类型 | 首次审查 / 复查新版 / 无基线复查 |
| 问题总数 | X 个 |
| P0 严重 | X 个 |
| P1 重要 | X 个 |
| P2 一般 | X 个 |
| P3 提示 | X 个 |
## 结论先行
| 结论项 | 判断 |
|--------|------|
| 是否建议进入编码开发 | 可以 / 不建议 / 待补充后再评估 |
| 是否建议进入技术方案详细设计 | 可以 / 部分可以 / 不建议 |
| AI 是否可以开始开发计划/任务拆解 | 可以 / 部分可以 / 不建议 |
### 最主要阻断点
1. ...
2. ...
3. ...
### 建议下一步
- 产品需先补充：...
- 研发/AI 可先推进：...
## 问题归属与后续承接
| 类型 | 内容 | 建议承接方 | 处理时机 |
|------|------|------------|----------|
| 产品需补充 | ... | 产品/业务 | 编码前 |
| 技术方案需明确 | ... | 研发/AI | 技术方案阶段 |
| 跨团队确认 | ... | 产品牵头 + 相关团队 | 联调前 |
## 版本更新检查
| 项目 | 结果 |
|------|------|
| 当前版本依据 | ... |
| 对比基线 | 上一版审查报告 / 旧版文档 / 版本历史 / 无 |
| 版本变化摘要 | ... |
| 旧问题处理状态 | 已关闭 X / 部分关闭 X / 未关闭 X / 无法判断 X |
| 新增风险 | ... |
如果是首次审查或没有旧版基线，写明“无可对比基线，仅审查当前版本”。
## P0 严重问题
| # | 问题 | 位置 | 建议修复 |
|---|------|------|----------|
| 1 | ... | 章节/字段/原型/表格 | ... |
## P1 重要问题
| # | 问题 | 位置 | 建议修复 |
|---|------|------|----------|
| 1 | ... | 章节/字段/原型/表格 | ... |
## P2 一般问题
| # | 问题 | 位置 | 建议修复 |
|---|------|------|----------|
| 1 | ... | 章节/字段/原型/表格 | ... |
## P3 提示
| # | 问题 | 位置 | 建议修复 |
|---|------|------|----------|
| 1 | ... | 章节/字段/原型/表格 | ... |
## 审查通过项
- ...
## UI 设计介入判断
| 页面/原型 | 判断 | 原因 | 产品需补充 |
|----------|------|------|------------|
| ... | 需 UI 介入 / 可直接开发 / 待确认 | ... | ... |
| 无用户可见界面 | 不适用 | 纯后端/数据/接口/任务类需求 | 无 |
## 流程图检查
| 流程/场景 | 是否需要流程图 | 当前情况 | 产品需补充 |
|----------|----------------|----------|------------|
| ... | 必须 / 建议 / 不必 | 已有 / 缺失 / 与正文不一致 | ... |
## 开发准入与 AI 开发准备度
| 评估项 | 结论 | 理由 |
|--------|------|------|
| 是否可以进入编码开发 | 可以 / 不建议 / 待补充后再评估 | ... |
| 是否可以进入技术方案详细设计 | 可以 / 部分可以 / 不建议 | ... |
| AI 是否可以开始开发计划/任务拆解 | 可以 / 部分可以 / 不建议 | ... |
### 准入判断
- 当前建议：可以开发 / 可先做技术方案详细设计 / 仅可做预研或影响评估 / 暂不建议开发。
- 可先推进的范围：...
- 进入编码前必须补齐：...
- 主要风险：...
## 反推 PRD Skill 改进建议
基于本次审查发现的问题，列出可沉淀到本 skill 的检查点或模板优化建议。
如果某个级别没有问题，写“未发现”。如果用户要“发给产品的版本”，仍保留上述报告结构，但去掉内部推理和审查过程，只保留产品可读的问题、位置和建议修复。
