PRD Writer

这个 Skill 用来把零散业务信息整理成符合用户既有文档风格的中文 PRD。目标不是学习某个具体业务领域，而是复用样例 PRD 的写作格式、拆解粒度和表格表达方式，让新文档看起来像同一个人/同一套团队规范写出来的。

这个目录里有什么

• SKILL.md：主说明文件。告诉 Codex 什么时候使用这个 Skill，以及写 PRD 的工作方法。
• references/prd-template.md：从两个样例 PRD 抽象出的文档模板。需要从 0 起草 PRD 时读取。
• references/prd-quality-checklist.md：按样例格式整理出的质量检查清单。需要补全、评审、润色已有 PRD 时读取。
• agents/openai.yaml：界面展示信息。用于 Skill 列表里的名称、简介和默认提示词。

后续怎么使用

把 prd-writer 放到 Codex 可发现的 skills 目录后，可以这样提需求：

使用 $prd-writer，根据这份会议纪要帮我写一版 PRD。

使用 $prd-writer，参考这个旧 PRD 的写法，把下面的新需求整理成 PRD。

使用 $prd-writer，检查这份 PRD 有没有缺字段、按钮逻辑、权限、状态流转和待确认项。

如果 Skill 还没有放到全局 skills 目录，也可以直接说：

参考 D:DesktopPRD.skillprd-writer 这个 Skill，帮我写一版 PRD。

工作流程

1. 先读取用户提供的全部资料。遇到 .docx 时同时抽取段落和表格，因为很多需求细节藏在表格里。
2. 先识别业务域、用户角色、平台范围、核心对象、主流程，再开始写正文。
3. 用户要“新写/起草 PRD”时，读取 references/prd-template.md。
4. 用户要“优化/补全/评审 PRD”时，读取 references/prd-quality-checklist.md。
5. 已知事实必须保留原意；缺失的信息标为 待确认，不要擅自编业务规则。
6. 页面类需求先保留 原型文件/页面现有截图/UI 占位，再写页面用途、字段、按钮、列表、查询条件、状态、权限、校验和统计口径。
7. 字段、按钮、列表、查询条件、状态、权限、校验、统计口径优先用表格表达，保持样例 PRD 的“表格化拆解”风格。
8. 聚焦 PRD 写作，不输出代码、工程结构或具体开发实现方案；如需技术约束，只写到接口、数据来源、兼容范围、验收口径等 PRD 必要层面。
9. 用中文业务语言写，但逻辑要精确到研发和测试可以执行。

输出风格

• 使用清晰的编号标题，例如 1. 业务背景、2. 痛点说明、6. 需求描述。
• 大需求按“模块 > 页面/流程 > 字段/按钮/规则”拆解。
• 每个模块尽量包含：功能描述、业务流程、应用场景、原型文件/页面现有截图、页面与功能拆解、状态流转、校验规则、数据权限、数据来源、看板口径、验收标准。
• PC 网页和小程序行为不一致时，分开描述。
• 看板指标必须写清楚分子、分母、时间范围、统计维度、权限范围、导出规则和边界情况。
• 状态流转必须写清楚状态名称、进入条件、可执行操作、下一状态。

从样例抽象出的格式规范

两个样例 PRD 体现出两种常用结构。写新 PRD 时按需求复杂度选择其一，或组合使用。

结构 A：完整业务 PRD

适合较大的项目、跨角色流程、需要说明背景和收益的需求。

• 1. 业务背景
• 2. 痛点说明
• 3. 期望上线时间
• 4. 业务需求方
• 5. 预期收益 ROI
• 6. 需求描述
• 6.x 模块名称
• 6.x.1 业务流程
• 6.x.2 PRD需求说明
• 页面入口、原型文件/页面现有截图、新增/列表/看板/明细等页面拆解
• 人员/主数据/权限等配套方案
• 待确认事项

结构 B：功能模块 PRD

适合单个模块或功能点，强调页面字段、按钮和业务规则。

• 功能描述
• 流程图
• 应用场景
• 功能拆解
• 页面原型/UI 截图
• 页面结构设计
• 数据来源说明
• 按钮
• 查询条件
• 列表字段
• 唯一性校验
• 排序
• 数据权限

表格表达规则

• 应用场景使用 场景 / 对象 / 场景描述。
• 原型/UI 截图区使用 原型编号 / 页面名称 / 端类型 / 原型位置或截图占位 / 说明，先放图或占位，再写页面规则。
• 字段说明使用 列表名称或区域 / 字段名 / 字段类型 / 是否必填 / 字段含义。
• 按钮说明使用 所属页面 / 按钮名称 / 显示逻辑 / 按钮逻辑（业务控制逻辑/校验逻辑）。
• 查询条件使用 列表字段 / 逻辑说明。
• 列表页字段使用 列表字段 / 逻辑说明。
• 看板或统计类需求必须写清楚计算口径；如果口径来自 Excel，标注“具体计算口径见 Excel”并补充已知规则。
• 规则类信息放在模块末尾，例如：唯一性校验、取值优先级、初始化、PC 网页/小程序互通、排序、数据权限。

什么时候要追问

只有当答案会明显影响 PRD 结构或业务规则时才追问。否则先合理假设，并在文档里标 待确认。

优先追问这些问题：

• 目标平台是 PC 网页、小程序，还是两端都要做。
• 具体用户角色和数据权限边界。
• 审核、稽核、激励是否在本期范围。
• 上线时间、分期范围和本期不做内容。
• 现有系统、来源数据和接口/同步约束。

完稿前检查

交付前检查 PRD 是否包含：

• 谁在什么场景下使用，解决什么业务问题。
• 每个关键页面/列表/表单是否有字段、按钮、显示和置灰规则。
• 必填项、候选范围、默认值、校验提示是否明确。
• 状态流转和操作权限是否完整。
• 数据权限、排序、导入、导出是否明确。
• 看板指标是否有公式和统计维度。
• 不确定事项是否统一放在 待确认事项。