通用型产品文档编写

解决什么问题

PRD 最常见的问题不是没写，而是写得像对了，研发和测试读起来却补不出实现细节。一份文档里写着「支持筛选」「权限可控」「默认选中合理」，等产品上线，交互稿、字段规则、异常分支和验收标准往往散落在评审记录、群聊和个人笔记里。团队在评审时感觉都懂了，进入开发才陆续发现：这个 tab 默认展示哪一项？状态流转失败后回到哪里？谁有权限看到这个字段？回归范围包含哪些路径？本技能把这些模糊地带提前摆到纸面上，让产品、设计、研发和测试基于同一套问题清单完成对齐。

技能如何工作

本技能围绕 PRD 起草、优化和质量评审三种任务展开。使用前先阅读 references/prd-writing-guide.md，再判断当前工作属于新建文档、补充已有文档，还是执行评审。

起草或优化时，PRD 需要先回答五个问题：

• 为什么要做：业务问题、用户问题和预期价值
• 范围内包含什么：功能边界、主路径和必要的次级路径
• 范围内不包含什么：明确被排除的事项，避免范围漂移
• 产品应该如何表现：正常态、加载态、空态、只读态、选中态等关键状态
• 如何验证：验收标准、测试范围和成功判断

在具体功能描述中，技能要求先识别命中的对象、组件、字段、状态和联动目标，再在同一功能块内补齐以下内容：

• 组件实例规则：页面结构、容器行为、展示优先级和默认选中/聚焦状态
• 字段级规则：数据类型、来源、默认值、必填性、格式、权限、校验、持久化、边界值和异常提示
• 状态与联动规则：状态流转、触发条件、失败回退、副作用和跨组件影响
• 验收映射：可从业务规则追溯到具体页面、字段和测试路径

规则优先使用确定性描述，不使用「合理」「尽量」「友好」「灵活」这类无法验证的表述。若某个标签页、表单默认值、切换行为或字段校验只在组件清单中出现，而在对应功能描述中缺失，文档需要重写，而不是继续补充第二份清单。

评审时，技能从四个视角检查完整性：

• 产品视角：问题是否成立、范围是否清楚、优先级和风险是否可执行
• 设计视角：页面、弹窗、组件状态和交互参考是否足够支持设计落地
• 研发视角：功能拆解、数据来源、字段规则、状态流转、权限边界和副作用是否有实现依据
• 测试视角：主路径、分支路径、权限路径、异常路径、边界用例、回归范围和验收矩阵是否可执行

评审结果先列出主要问题，再给出可操作的改进建议。例如应指出「字段 X 缺少空值和超长字符的处理规则」，而不是笼统地要求「写清楚一点」。

适用边界与注意点

这个技能适合通用产品需求文档，尤其是需要跨团队对齐并进入研发、测试环节的 PRD。它不负责生成营销文案、产品上线公告或技术架构设计；也不会自动猜测业务背景，真正的业务假设仍需要作者提供。

使用时应避免把规则压缩成一句概述：一个功能块只写「包含筛选」是不够的，至少要说明筛选对象、条件来源、默认状态、权限范围、失败提示和验收方式。涉及表单、表格、抽屉、弹窗和多步骤流程时，字段规则和组件实例规则也应写进对应功能块，而不是只在整份文档末尾补充附录。

对于高风险流程，如支付、权限变更、数据删除、批量操作和跨系统联动，建议先补充状态流转和异常回退方案，再进入详细字段规则。本技能提供的是结构化检查框架，无法替代具体业务决策。