PRD 规范写手

问题在哪

业务需求往往散落在会议纪要、.docx、口头说明和截图里；研发与测试需要的是结构稳定、可执行的中文 PRD，而不是又一份「各写各的」文档。更麻烦的是：团队往往已有两三份「标准样例」，新人或 Agent 写出来的稿子格式、拆解粒度和表格表达都对不上，评审时要花大量时间改版式。

技能如何工作

这个 Skill 的定位是 PRD Writer：不替你「学会某个垂直行业」，而是复用你提供的样例 PRD 的写法——编号标题、模块拆解、以及「字段 / 按钮 / 查询条件 / 状态」的表格化表达。

典型流程可以概括为：

• 先吃全资料：汇总用户给出的全部输入；遇到 .docx 时同时抽取段落与表格（很多规则藏在表里）。
• 先建模再写正文：识别业务域、用户角色、平台范围、核心对象与主流程，再落笔。
• 按任务选参考：新写 / 起草时读 references/prd-template.md；优化 / 补全 / 评审时读 references/prd-quality-checklist.md。
• 事实与缺口分开：已知信息保留原意；缺的地方标 待确认，不擅自编业务规则。
• 页面类需求：先保留原型文件、现有截图或 UI 占位，再写用途、字段、按钮、列表、查询、状态、权限、校验与统计口径。

输出上支持从样例抽象的两类结构：结构 A（完整业务 PRD）适合跨角色、需背景与收益的大需求；结构 B（功能模块 PRD）适合单模块，强调页面字段与业务规则。PC 与小程序行为不一致时分开写；看板指标要写清分子、分母、时间范围、维度与权限边界。

边界与注意点

• 聚焦 PRD 写作：不输出代码、工程结构或具体实现方案；技术内容只写到接口、数据来源、兼容与验收等 PRD 必要层面。
• 只有在答案会明显影响结构或业务规则时才追问（平台、角色权限、本期范围、上线分期、现有系统与数据约束等）；其余可先合理假设并标 待确认。
• 语言用中文业务表述，但逻辑需足够精确，让研发和测试能直接照着测。