# Requirement Prd Writer

> Write or update Chinese PRD/需求说明 Markdown with a mandatory requirement-knowledge-base preflight, a user-confirmed 待确认问题口径, and a user-confirmed writing方案 before formal generation. Use when the user asks to 编写需求文档, 生成新需求说明, 生成新需求, 基于知识库写PRD, 更新需求说明, or turn rules into a testable product requirement document. Before writing any formal PRD, find and read an existing 需求知识库 or get explicit user confirmation to proceed without one; never create or update a formal knowledge base unless the user explicitly asks to 建立/创建/更新/同步知识库; then present 待确认问题 and wait for user confirmation, then present the proposed PRD方案 and wait for user confirmation before generating or updating the formal requirement document. Trigger phrases include: $requirement-prd-writer, 需求文档, 新需求说明, 新需求, PRD, 基于知识库写需求.

- Skill: `ewancy/requirement-prd-writer` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add ewancy/requirement-prd-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ewancy/requirement-prd-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: ewancy (https://skillmd.com/u/ewancy)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/ewancy/requirement-prd-writer

---


# requirement-prd-writer / 需求说明文档编写

## 调用原则

只在用户目标是“写或改需求说明/PRD”时使用本 Skill。所有正式 PRD 必须先完成知识库门禁：找到并只读对应需求知识库，或获得用户明确确认“本次不需要知识库”；随后必须先向用户输出“待确认问题”并等待用户确认问题口径，再输出“需求编写方案”并等待确认，确认后才生成或更新正式 PRD。

本 Skill 不得在 PRD 编写流程中自动创建、覆盖或更新正式知识库。只有用户明确说“建立知识库 / 创建知识库 / 更新知识库 / 同步知识库 / 沉淀到知识库”等写入意图时，才允许调用 `$requirement-kb-creator` 或 `$requirement-kb-updater` 落盘正式知识库；否则只能输出知识库缺口、禅道检索摘要、待更新草稿或本轮规则摘要。
本 Skill 不负责制作 HTML 原型；如果用户要求原型，应在 PRD 完成后使用 `$html-interactive-prototype`。

## 方案确认规则

正式需求说明必须先确认问题口径，再确认方案，不要在用户首次提出“写需求/生成 PRD”后直接落盘 PRD。

中文说明：问题确认是为了先校准不确定口径，方案确认是为了再校准需求范围、业务假设、前后端拆分和章节组织，避免 AI 直接把不确定内容写成正式规则。知识库门禁仍然优先执行，但在用户未明确要求写入知识库前只能只读知识库或整理草稿，不能先完成正式知识库沉淀；正式 PRD 文件必须等用户确认问题口径和方案后再生成。

- 完成知识库门禁和输入梳理后，先输出“待确认问题”，等待用户明确确认问题口径；用户可以逐条回答，也可以回复“按默认处理”。
- 待确认问题应聚焦会影响需求口径的内容，包含问题、影响、建议默认处理方式；不要把不影响需求落文的闲聊问题列入阻断项。
- 用户确认问题口径后，再输出一份简短的“需求编写方案”，等待用户明确回复确认、继续、按这个写、没问题等同义表达。
- 用户未确认问题口径和方案前，不要创建、覆盖或更新正式 `...需求说明.md`；也不要输出完整正式 PRD 正文。
- 方案应包含：
  - 需求名称：拟生成的 PRD 标题。
  - 关联知识库：主知识库、次要知识库，或用户确认不需要知识库的口径。
  - 本次目标：1-3 条核心目标。
  - 拟写章节：说明是否沿用精简默认章节；默认顺序为 `需求概述`、`功能改动`、`规则与边界`、`页面截图`、`待确认问题`、`版本记录`，默认不写 `改动范围`、`验收标准`、`数据与接口`。
  - 关键规则假设：基于用户输入和知识库推导出的规则，标明“已确认/待确认”。
  - 待确认问题处理结果：列出用户已确认的关键问题口径；如仍有非阻断问题，说明建议默认处理方式。
  - 输出路径：拟生成文件路径。
- 如果用户在同一轮明确说“无需确认，直接生成”“按默认方案直接写”“问题和方案都按默认处理”等，仍需完成知识库门禁，但可以跳过问题确认和方案等待，直接生成 PRD，并在最终回复说明用户已授权跳过确认。
- 如果用户只要求“先给我方案/大纲/思路”，只输出方案，不生成 PRD。
- 如果用户对待确认问题或方案提出修改，先更新本轮问题口径或方案；只有用户明确要求“更新/同步知识库”时，才把修改写入正式知识库。

## 知识库前置规则

需求编写必须基于并关联知识库。没有知识库时，不要直接写 PRD。

中文说明：知识库是需求事实来源，用来沉淀历史规则、业务边界和已确认口径。PRD 只能基于用户明确输入、已有 PRD、知识库或已抽取的禅道材料编写，不能跳过知识库直接生成。

- 写 PRD 前先识别功能点，并在当前工作区查找 `功能点/<功能点名称>/<功能点名称>需求知识库.md` 或用户指定的 `...需求知识库.md`。
- 如果存在多个相关功能点，PRD 必须在“关联知识库”中列出主功能点和次要功能点知识库。
- 读取知识库时检查 `需求来源` / `关联任务/记录` 是否包含禅道历史检索记录；如果知识库没有记录“已查禅道历史需求/未命中/复用记录/检索失败原因”，不要直接改写知识库，应输出“知识库来源缺口/建议补查项”，并在 PRD 方案中标明该风险。
- 如果找不到对应知识库，不能自动新建正式知识库；先询问用户是否需要建立知识库，或取得用户确认本次不需要知识库。
- 知识库补齐流程：
  - 只有用户明确要求“建立/创建/更新/同步知识库”时，才使用 `$requirement-kb-creator` 或 `$requirement-kb-updater` 落盘正式知识库。
  - 功能点名称清晰但用户未要求写入知识库时，只能整理“知识库待补草稿/本轮规则摘要/禅道检索摘要”，不得写入正式 `...需求知识库.md`。
  - 已有知识库但缺少本次规则、禅道历史检索记录或来源摘要时，只提示建议更新知识库；除非用户明确同意更新，否则继续保持只读。
  - 功能点归属不清、候选知识库过多、用户明确不想建库，或创建知识库会引入不确定历史口径时，先向用户确认。
- 如果用户确认不需要知识库，则按“独立新功能”继续编写正式 PRD；PRD 的“关联知识库”写明 `无，用户确认本次按独立新功能处理`，并在规则与边界中说明后续如该功能持续迭代再补充知识库沉淀。

## 推荐口令

- `$requirement-prd-writer 基于 xxx需求知识库.md 生成新需求说明`
- `需求文档：根据这些变更点写一份 PRD`
- `基于知识库补充新需求说明，不要写数据与接口章节`
- `帮我设计一个需求：xxxx`

## 工作流程

1. **确认并读取知识库**
   - 先根据需求标题、用户描述和目录结构识别涉及功能点。
   - 查找并读取相关 `...需求知识库.md`；没有知识库时询问用户是否建立知识库，或取得用户明确豁免。
   - 检查知识库是否有可追溯的禅道历史检索记录；如果没有且用户未明确要求跳过禅道，只输出来源缺口和建议补查项，不得自动写入正式知识库。
   - 确认已有知识库、用户明确要求并已通过知识库技能建立/更新知识库，或用户确认本次不需要知识库并按独立新功能处理后，才进入 PRD 编写。
   - 门禁自检：如果准备落盘 PRD 时仍没有“主知识库”或“用户确认不需要知识库”的依据，立即停止写 PRD，先补齐知识库。

2. **读取输入**
   - 优先读取用户指定的知识库或已有需求文档。
   - 如果用户直接给变更点，先识别背景、目标、范围、规则、验收口径。
   - 将用户补充规则与知识库规则对齐；冲突内容写入待确认或本轮规则摘要。只有用户明确要求“更新/同步知识库”时，才按用户最新明确口径更新正式知识库。

3. **输出待确认问题并等待确认**
   - 按“方案确认规则”先输出待确认问题表，包含问题、影响、建议默认处理方式。
   - 明确说明“确认问题口径后，我再输出需求编写方案”。
   - 在用户确认问题口径前停止，不要输出需求编写方案，不要落盘正式 PRD。
   - 用户确认后再继续执行方案步骤；如果用户补充新口径，先同步到本轮规则摘要。只有用户明确要求“更新/同步知识库”时，才写入正式知识库。

4. **输出方案并等待确认**
   - 按“方案确认规则”输出需求编写方案。
   - 明确说明“确认后我再生成正式需求说明”。
   - 在用户确认前停止，不要落盘正式 PRD。
   - 用户确认后再继续执行后续步骤；如果用户要求调整方案，先修改方案或本轮规则摘要，再等待确认；不得顺手更新正式知识库。

5. **组织结构**
   - 参考 `references/prd-template.md`。
   - 默认章节顺序：需求概述、功能改动、规则与边界、页面截图、待确认问题、版本记录。
   - `页面截图` 默认放在 `规则与边界` 后面；只有用户明确要求截图前置时才调整位置。
   - 默认不要写 `改动范围`、`验收标准`、`数据与接口` / `接口与数据字段`，不要写技术实现字段、接口名、数据库字段或代码变量，除非用户明确要求技术方案。
   - `功能改动` 合并前端和后端描述，按功能点、页面或配置入口组织，用产品/业务语言写页面、配置、交互、保存和生效口径，避免重复和技术实现细节。
   - `规则与边界` 只写跨页面、权限优先级、兼容、不处理范围、一致性、风险等全局规则；不要重复 `功能改动` 已写清的页面字段和交互步骤。
   - `需求概述` 中必须包含“关联知识库”，列出本次 PRD 使用的知识库名称；如果用户确认不需要知识库，写明 `无，用户确认本次按独立新功能处理`。

6. **写需求详情**
   - 优先精简：需求概述控制在 3-6 条，功能点说明只保留可测试、可配置、用户可感知的规则。
   - 同一规则只落一个主位置：入口/字段/交互写在 `功能改动`；权限优先级/兼容/不处理范围写在 `规则与边界`；截图说明只描述截图对应页面和改动位置。
   - 对用户明确要求的规则必须逐条落文档，但不要在概述、功能改动、规则与边界、截图说明中反复表达同一句规则。
   - 对不确定内容写入风险/待确认，不要写成确定规则。
   - 表格用于表达待确认问题、版本记录、截图清单等结构化信息；能用短列表表达的内容不要强行表格化。
   - 版本记录默认只保留关键版本和当前版本，避免保留大量已被推翻的中间口径；如需完整审计记录，保留在知识库或禅道动态中。

7. **校验**
   - 章节编号连续。
   - 已关联至少一个需求知识库；如果没有知识库，必须能追溯到用户确认“不需要知识库，按独立新功能处理”的口径。该项是阻断项，不满足时不得交付正式 PRD；不得通过未授权新建/更新知识库来绕过。
   - 已获得用户对待确认问题口径和方案的明确确认，或用户已明确授权跳过问题确认和方案确认；该项是阻断项，不满足时不得生成或更新正式 PRD。
   - 不包含改动范围、验收标准、接口章节、技术实现字段、数据库字段或代码变量，除非用户明确要求。
   - 用户给出的每条需求都能在文档中找到对应描述；同一规则没有不必要的重复表达。
   - 本地文档不能包含密码、token、cookie。
   - `页面截图` 位于 `规则与边界` 后面，除非用户明确要求其他位置。
   - 如果这份 PRD 准备提交到禅道，正文中的原型/图片/流程图不得保留 `/Users/...`、`/home/...`、`C:\...`、`file://...`、`localhost`、`127.0.0.1` 等本地路径或临时地址；默认通过 `.md` 附件承载本地截图，用户明确要求内嵌图片时再上传图片并使用禅道 `webPath` 直连地址。

## 原型与图片引用规则

- 本地交付：可以在最终回复中列出绝对路径，方便用户在当前电脑打开。
- PRD 正文：如果后续要提交禅道，默认写 `需求文档：查看禅道附件 <需求说明>.md`，不要默认引用原型 ZIP。
- 页面截图：本地评审版可用 Markdown 图片；提交禅道时默认不上传截图附件。只有用户明确要求图片显示在禅道正文时，才上传图片并转成 `<img src="https://<禅道域名><webPath>" style="max-width:100%;" />`；此时禅道附件列表会出现图片附件；不要用 `<a><img /></a>` 包图。若需要查看大图，提交流程应在图片下方增加 `mouse=left` 禅道预览链接，避免点击图片被禅道改写为下载。
- 页面截图章节默认放在 `规则与边界` 后面，固定为“页面 / 截图 / 说明”三列；说明只写页面用途和本次改动位置，不重复统计口径、权限优先级等正文规则。
- 多个原型/流程图/截图：默认保留在 `.md` 需求文档中，不作为禅道独立附件；用户明确要求上传时再逐项处理。
- 不要把本机绝对路径、`file://`、本地 HTTP 服务地址写进会同步到禅道的 PRD 正文；如果无法拿到可访问图片地址，则正文写“查看需求文档附件”。
- 如果已有 PRD 含本地路径且用户要求提交/变更禅道，先替换为“查看需求文档附件”后再提交。
- 如果用户已明确计划提交禅道，默认只确保 `.md` 需求文档文件名与正文引用一致；图片/原型附件名只有在用户明确要求上传时才需要逐项匹配。

## 输出约定

推荐文件名：`<需求名>需求说明.md` 或 `<需求名>优化需求说明.md`

- 问题确认阶段：只输出待确认问题、影响和建议默认处理方式；不要输出需求编写方案或正式 PRD 路径作为已完成结果。
- 方案阶段：只输出需求编写方案、已确认问题口径和拟输出路径；不要输出正式 PRD 路径作为已完成结果。
- 生成阶段：最终回复列出文档路径和覆盖的关键变更点。

- 禅道提交注意：当前禅道会清洗 base64 图片，正文需要显示图片时无法做到“无图片附件”。如用户要求附件只保留 `.md`，则禅道正文不能直接显示截图，只能在 `.md` 文档内查看。
- 禅道正文截图建议使用固定宽度等比例 `<img width="520">` 缩略图；不要使用背景图裁切方案。