一份有用的 PRD 应让设计、研发与测试对同一件事作出相同理解，而不是把模板所有栏目填满。这里用虚构的社区维修站“预约改期”功能，演示从会议共识到初稿、从状态建模到竞品证据的工作。案例中的规则由示例团队假定，正式项目必须由实际负责人决定；本文没有声称已经开发或验证系统。
先整理输入：共识、证据与待决定事项
一句“让用户方便改期”隐藏了很多问题：谁能操作、多久以前允许改、技师是否重新确认、原名额何时释放、通知失败怎么办。先收集现有预约流程、客服反馈、技术限制和会议纪要，给每份输入一个来源编号和日期。把已决定规则、个人建议、未经验证的假设与开放问题分开，避免 Agent 把讨论中的一句话升级成正式承诺。
建立决策日志，记录问题、当前决定、理由、参与角色、适用版本与被替代的旧决定。比如 D-01 规定用户可在预约开始前改期，具体截止时间仍待运营确认；在确认前用“待定”占位，不让模型补成看似合理的两小时。评审后的变更要注明影响到的规则、图和用例，保留旧版本供追溯。
先交付问题清单与一页范围说明：目标用户、当前障碍、预期改善、首期功能、非目标、依赖与验收办法。维修站首期只处理单次预约改期，不处理套餐退款与技师排班系统重建。设计师可以先画核心结构草图，但不把尚未决定的业务规则固化进精美界面。
场景一：从范围说明写出可评审的初稿
把范围拆为用户任务和系统责任。用户选择新时段、确认改期并查看结果；系统重新校验可用性、保存变更并记录通知状态。每个需求给稳定编号，如 R-01 查看可改时段，R-02 提交改期，R-03 重复提交处理。功能说明必须指向来源与决定，缺证据的需求放入提议区，不混入已承诺范围。
为主用例填写角色、前置条件、触发、主流程、后置条件与替代路径。前置条件包括用户已登录且有权操作此预约；后置条件应描述持久化结果，不只写“出现成功提示”。分别说明用户点确认、服务端接受请求、变更已提交、通知已发送四个时刻，它们并不天然相同。
数据字典可以从 appointment_id、requested_slot_id、revision、request_id、updated_at 开始。逐项定义类型、是否必填、允许值、空值语义、显示规则及责任来源。时间字段需明确时区与比较基准；界面显示本地时间时保留可核对的原始时间。不得让模型编造不存在的 API 字段、数据表或已经接通的外部服务。
权限单列：预约本人可以申请改期，工作人员是否可代改由实际规则决定；只知道预约编号不能取得操作权。埋点也写清目的和最小字段，例如查看、提交、结果，不在分析事件中附完整联系方式。初稿产物包含需求卡、用例、数据字典、权限表与未决问题，篇幅由复杂度决定。
场景二：用图找出文字遗漏的状态与交接
先选要回答的问题，再选图。业务流程图说明用户和工作人员经过哪些步骤；时序图说明界面、服务与通知组件如何交换消息；状态图说明预约允许怎样变化；用例模型说明角色可以做什么。不要把页面导航、数据库状态和通知状态塞进同一张图，造成“箭头很多所以完整”的错觉。
维修站可以把预约业务状态与通知状态分别记录。预约从 confirmed 经过受控改期仍回到 confirmed，但其时段与版本发生变化；通知则可能 pending、sent 或 failed。若把 failed 通知当作改期失败，重试可能重复改动已经提交的预约。图与文字必须明确事务边界、重试条件以及向用户展示的实际结果。
可用 Mermaid 的可编辑文本保存状态和转移。它是 MIT 许可的开源绘图方案，文档与图类型适合纳入版本管理；选择它是因为源码可比较、容易修改，而不是因为绘图成功能证明业务正确。实际文档系统是否支持 Mermaid、支持哪个版本以及怎样导出，都要在目标环境检查，不能承诺粘贴到任何 Markdown 都会渲染。
建图时给节点稳定标识，标签使用团队理解的词，转移注明触发事件与守卫条件。图太大时按“查可用时段”“确认改期”“通知补偿”拆开，并用同一需求编号交叉引用。交付图源、目标环境可读的导出和图例；渲染错误先用最小图定位语法与版本差异，不能为了通过渲染删除异常路径。
实操：把最后一个名额争用写进验收
设两个用户同时选择仅剩一个名额。R-02 的验收应要求最多一个请求成功取得名额，另一个得到可理解的冲突结果且保留原预约。不能只写“不能重复预约”，要说明由哪一层作最终校验、失败后界面如何恢复，以及是否需要重新查询时段。
再加入连续点击确认、请求超时但服务端已提交、用户刷新页面、预约被工作人员同时修改、目标时段被关闭等情形。request_id 与 revision 只是可选设计概念，是否使用、如何生成和过期由技术评审决定。PRD 应规定重复请求的业务结果和冲突规则，不把某一种数据库实现冒充唯一方案。
一个可交给 Agent 的请求是：“只依据会议纪要 M-01 和范围说明 S-01，起草预约改期需求。先列冲突、遗漏和待决定事项，再写主流程、替代路径、字段字典及验收矩阵。所有规则附来源或标明提议。输出可编辑图源，不连接生产服务，不声称测试已经运行。”先审范围和状态，再让它扩写细节，比一次生成十几页更容易纠偏。
验收矩阵至少包含规则编号、初始条件、操作、预期持久化状态、用户可见结果和验证方式。示例中通知失败不撤销已成功的改期，界面需区分“改期完成，通知待重试”；这是示例决定，不是对所有系统的通用要求。测试负责人据此设计检查，实际运行结果另存，不能用规格中的预期替代测试证据。
场景三：用竞品研究检验需求，而非复制功能
先定义比较问题，例如“如何让用户理解改期冲突”。选可比产品、地区、套餐与观察日期，分别记录官方帮助页说明、实际可访问界面行为、营销说法和未知项。没有账号或付费权限时留空，不让 Agent 猜测后台功能。竞品存在某按钮，不证明自家用户需要同样功能。
比较表可包含操作入口、截止规则展示、名额冲突提示、通知失败说明和可访问性线索。每项附来源定位、短摘要与核实状态。随后把证据转成用户故事：特定角色在特定条件下为了什么完成何种动作；故事必须补验收，不能只留下“作为用户我想方便改期”。
SWOT 适合梳理假设和限制，不是自动得出战略真相的计算器。MoSCoW 中的 Must 应由首期目标及必要依赖支持；使用 RICE 时，覆盖、影响、信心和成本都写口径，缺数据标未知。比较偏重用户影响和偏重实现成本的排序，说明排名变化；工程估时请研发给范围，模型输出不能当排期承诺。
评审产物是证据表、排序理由与保留/推迟清单。为被拒绝的功能也记录理由，避免下一轮重新争论。最终 PRD 应说明哪些输入改变了决定，以及仍需通过访谈、原型或实际试验验证哪些假设。竞争研究并不能替代用户反馈和技术可行性检查。
Skill 选择与文档整理的边界
Writing Guidelines 适合在需求决定已有来源后，整理技术 PRD 的结构、措辞和可读性。它需要目标文档源文件及访问所链接写作手册的网络权限；先取得手册并确认适用的读者与风格，再给已批准的术语、规则编号和原稿，要求保留约束与未知项；输出变更清单，逐项确认没有把“可能”“待定”改成承诺。它不能代替竞品采集、需求授权、绘图引擎或验收测试。
对原文提到但本次未取得可核验匹配记录的 PRD、竞品和绘图技能，不制作猜测链接。未来发现候选时检查来源、版本、许可证、依赖、文件和网络权限，再用同一份脱敏维修站案例比较输出。技能许可不等于模型或工具调用免费；安装、发现、执行和验收都分别记录。无需一次装齐所有名称，已有文档工具能完成的步骤可以直接做。
故障排查与 FAQ
初稿仍然像模板怎么办？检查是否给了具体用户、规则、失败路径与非目标，删去不影响决策的空栏目。研发总说漏边界怎么办？沿每个状态问重复、并发、超时、取消、越权、依赖失败和恢复，并把回答映射到用例；不能只扩大篇幅。
不会 UML 必须先学整套工具吗？先用团队能读懂的角色清单、状态表和小图，语义一致比图形复杂重要。图能渲染就算验收吗？只能说明当前渲染器接受语法，仍要核对规则、可达状态和异常路径。AI 是否一定提效一倍？没有这样的通用保证，记录初稿耗时、评审返工、遗漏规则和总交付时间，再比较同等难度任务。
如何避免每次会议推翻全部内容？给决定和需求稳定编号，标明变更负责人和生效版本，保留问题日志。关联技能如何保鲜？定期用固定样例复查来源和输出，替换失效候选时记录原因，同时确认图源与正文仍使用同一规则版本。最终交付应能让另一位同事理解“为什么这样做、如何失败、怎样判断完成”。