Prd Writer

PRD Writer

Overview

按 7 节标准结构 产出 AI 产品 PRD（Summary / Problem & Goals / Scope / Design / Rollout & Risks / Quality / Appendix）。

结构源自作者 V0.5 实际使用版本，借鉴 Amazon Working Backwards / Basecamp Shape Up / Google Design Doc / Linear spec / Atlassian Poster 等社区现代产品文档模式，将原 V2.x 的 13 节压缩为 7 节，治理元信息（修订/评审/参考链接）移到 frontmatter，业务核心 Design 章节权重从 1/13 提升到 1/7。

配套交付 · 角色切片：每次产出全本 PRD 后，自动派生 stories/ 目录（研发 AI 编码用：00-overview.md + 按 story 拆分的 ST-XXXX 卡片）+ 3 个只读切片（for-qa / for-bi / for-ops，与 stories/ 合计 4 类角色产物）—— 解决"一份 PRD 撑 6 个消费者互相污染"的问题。AI 编码 agent 每次只读 00-overview.md + 单个 story 卡片，上下文最小化。

核心原则：

1. 全本 7 节是 source of truth · 切片自动派生 · 切片只读
2. 章节"按场景必填"而非"全员必填"—— 不适用的节就删而不是标 N/A
3. AI 产品必备的 6 大缺口（业务目标 / 用户故事 / 数据埋点 / 评测指标 / 灰度上线 / 验收清单）仍然覆盖 · 仅重组归类

何时使用

• 写一份新版本的 PRD（如 "V0.9 需求"、"下个迭代的 PRD"）
• 把一段需求描述 / 会议纪要 / Figma 链接结构化为正式文档
• 升级旧 PRD 到 7 节标准结构
• ⭐ 从已有高保真原型反推 PRD（HTML 原型 / Figma 链接 / 设计稿截图 / 多页面 demo）
• 用户问 "AI 产品 PRD 怎么写" 这类元问题

何时不用

• ❌ 一次性技术调研 → 用 doc-coauthoring
• ❌ 内部 RFC / 决策记录 → 用 doc-coauthoring
• ❌ 客户营销文档 → 直接 frontend-design 写 HTML
• ❌ 单个功能的 spec（ 旧版"11 项必填"已分层。不适用的章节直接删除，不要保留 N/A（保留 N/A 会污染 AI 编码切片）。

🔴 核心必填（任何 PRD 都要 · 10 项）

• [ ] Stage 0 完成：如探测到 wiki 根（docs/wiki/ → docs/pm/wiki/ 顺序），已读 index.md + 相关页（两处均不存在才注明"项目无 wiki"）
• [ ] Stage 0.5 完成：如用户提供了高保真原型，已按反推映射表提炼 + 与用户确认（如未提供则注明"无原型输入"）
• [ ] frontmatter 完整：含 version / status / owner / revisionlog / reviewlog / links 完整字段
• [ ] §1 Summary 3-5 bullets
• [ ] §2.4 非目标：明确写"不做什么"
• [ ] §2.5 端到端流程图：mermaid flowchart 必填
• [ ] §3.1 需求清单按 P0/P1/P2 排序（不按系统排）
• [ ] §4.1 业务对象关系（5 子段：总览 / 关系图 mermaid / 生命周期 / 业务规则 / 对象-页面映射）· 业务视角不是技术字段
• [ ] §4.2 页面功能 7 段（业务场景 / 页面布局 / 关键字段 / 交互动作 / 状态变化 / 异常处理 / 验收点）
• [ ] §7.2 ADR 至少 1 条关键决策记录

🔴 决策闭环自检（核心必填 · 写完通读一遍）

> 防"7 节齐全、却不驱动决策"——结构完整 ≠ 闭环。逐条自问：

• [ ] 目标↔设计↔验收 可追溯：能为每条 §3 需求 / §2.3 KR 指出"哪个 §4 设计交付它 + 哪个 §6 指标或埋点验证它"吗？指不出 = 缺口（不强求 1:1 硬绑，但要指得出；埋点字段也要够验证 KR）
• [ ] 内部无矛盾：§2.4 非目标不与 §3 / §4 打架（如"不做率值"却画进度条）；通读全文无自相矛盾
• [ ] 展示指标口径完整：每个 KPI / 进度条 / 率值都写明公式——分子 / 分母 / 各状态枚举如何归桶（杜绝"画了进度条却没说分母是什么"）
• [ ] 取最新 / 去重 / 归并类规则三件套：凡"按 key 取最新 / 去重 / 唯一 / 归并"的规则，写明 去重键 + 排序键 + 并列 tie-break（如"endpoint 取最新"要说清：按什么键去重、按什么排序取首、并列取谁）——缺一即口径不完整、留给实现猜

🟡 场景必填（视项目特点）

• [ ] 涉及对外生成式 AI → §4.3（6 小节）+ §3.2 AI 合规子段 + §5.5 成本预算
• [ ] 涉及多端 / 多角色 → §2.2 含权限矩阵列
• [ ] 涉及 LLM 时延敏感 → §3.2 性能 P99 阈值
• [ ] 涉及埋点上报 → §6.1 事件清单 5 列结构
• [ ] 涉及灰度 → §5.1 灰度计划 + §5.2 回滚预案
• [ ] 数据驱动视图（KPI / 列表 / 看板从数据派生） → §5.3 业务级数据依赖契约：刷新口径 / 权限过滤 / 数据延迟 / 能否"单源（一个列表）派生全部 KPI 与分组"（仍不写 API path/schema，只写业务语义）
• [ ] 交付研发 AI 编码 → stories/ 目录派生完成 + 每个 story 过 prd-reviewer 分级关卡（spec_test: passed → ai-passed）+ 研发 48h 走查过才标 ready

🟢 推荐填写（可选 · 留空不算违规）

• [ ] §2.3 北极星 + KR（业务方关心，编码无关）
• [ ] §2.6 Open Questions（待评审决议）
• [ ] §6.2 评测指标（涉及 AI 时由算法侧补，不强制 PM 一稿包圆）
• [ ] §6.3 验收清单（QA 主导）

🚫 永远不写（PRD 不该有的）

• [ ] ❌ 技术 API / 数据库 schema / UML 图（属工程文档）
• [ ] ❌ 任何 N/A 占位章节（不适用就删除，不要保留）

反模式（不要这样做）

| 反模式 | 为什么不行 | 怎么做 | |---|---|---| | 用户给一段话直接动笔写 | 跳过 Stage 1，业务背景必然空泛 | 先问 6 个核心问题 | | 业务目标写「提升体验」 | 不可验收 | 用具体百分比 / 数值 / 频率 | | 评测章节写「具体指标待定」 | 把工作丢给下游 | 给可挑战的初稿（如 Golden ≥ 85%），让 QA 改 | | 埋点章节只写「需要埋点」 | BI 没法建表 | 列 5 列事件表，每行可执行 | | 保留全空章节 / 标 N/A | N/A 章节污染 AI 编码切片噪音 | 不适用就删除；如需保留思考线索用一行 HTML 注释 ` | | 把所有需求都标 P0 | 等于没排优先级 | 至少有 1 个 P2，强制取舍 | | **自创全本章节名（如改成 "Goals" / "Stories"）** | 跟模板不一致，切片派生失败 | 严格沿用 §1-§7 中文章节名 | | **PRD 写 REST API 接口清单（path/method/params）** | 技术细节 · 业务方看不懂 · 与工程文档重复 | 在 §4 业务对象段简述业务概念 · API 留 OpenAPI yaml | | **「数据模型」段写 PK/FK/字段类型/JSON schema** | 技术视角 · 业务方读不懂业务关系 | 改用「业务对象关系」+ mermaid erDiagram 仅写业务概念 | | **「核心页面」只列文件名+简述** | 开发不知做什么 · QA 不知验什么 | 每页 7 段标准模板 | | **AI 章节对内部 AI 依赖也详化 6 小节** | 评测引擎 LLM-Judge 不是对外功能 · 详化浪费篇幅 | 区分对外生成式 AI（详化）vs 内部 AI 依赖（在 §5.3 简述）| | **本期不做 / 仅登记的需求塞进 §1 核心变化或 §3 Scope** | 干扰评审范围理解、研发误判工作量（"以为本期有活"） | 移入 §2.6 Open Questions 或 §7 后续需求池；§1/§3 只放本期真做的 | | **占位 / 未实现功能不定呈现态** | 埋点 / 交互 / QA 各做各的（disabled？toast？隐藏？） | 明确呈现态（禁用 / 隐藏 / 可点提示），且埋点与交互与该态一致 | | **流程图 / 状态机 / 业务对象图 用文字描述代替** | 文字难懂 · 评审说不清 | mermaid 必填 | | AI 模块没写兜底策略 | 上线后 LLM 挂会被骂 | §4.3.5 必明写：超时 / 低置信 / 错误 三种兜底 | | **手工编辑 slices/ 或 stories/ 的派生文件** | 派生产物手工改会被下次重新生成覆盖；研发改 story = 双头真相源 | 改全本 PRD，重新派生；研发发现问题回流 PM | | **PRD 全本 + 切片"包山包海"** | 一份给所有人看反而谁都看不清 | 全本是 source of truth · 各角色读对应切片 | | **小改动强拆成标准 story** | 文案修正拆出 4 story 16 AC 是杀鸡用牛刀（SDD 粒度错配） | 用 story-template-lite.md，3 节搞定 | | **把一个页面/组件按 UI 层（框架 / 行 / 区域）水平拆成多卡** | 卡间互相依赖、谁都不能独立交付，造出现实里不存在的集成缝（"行怎么插进框架"）；prd-reviewer 第二关会判高风险 | 按**垂直价值增量**切（每片穿透 UI+逻辑+数据、独立可交付/验收）；一页通常=1 卡，可拆 MVP→增强等垂直增量，但切不出第二个独立价值块就别拆 | | **story 未过评审关卡直接给研发** | 歧义靠"被迫执行"暴露，不靠"读着通顺"；带歧义的 story 让 AI 自由发挥 | 跑 prd-reviewer 分级关卡 → ai-passed，研发走查过才 ready` | | story 里写"友好提示""加载较快" | AI 无法客观判定，编码各凭理解 | AC 全部 Given-When-Then + 可观察结果 | | story 正文点兄弟 story_id 描述对方职责 | 双向点名（ST-A↔ST-B）= 隐性耦合，改一个要改俩；依赖散落正文难维护 | 依赖只在 overview 索引表「依赖」列声明（单向集中）；story 正文「依赖与边界」只说本 story 自身边界，不点兄弟 ID |

Red Flags — STOP and 检查

看到以下信号立刻停下复查：

• 跳过 Stage 1 直接进 Stage 2
• 业务目标全是定性描述（"提升满意度" / "优化体验"）
• 优先级列全是 P0 或全空
• 文档里有 N/A 章节（应该直接删）
• §5.2 回滚说「按需回滚」而没具体步骤
• 用户已经明确说了"非目标"但 PRD 没有 §2.4
• 文件只生成了 .md 没生成 .html
• 写完全本 PRD 没生成 stories/ 目录 + 3 个角色切片
• story 标了 ready 但 frontmatter 还是 spec_test: pending

好 vs 坏对照

业务目标

| ❌ 不可用 | ✅ 可用 | |---|---| | "提升 AI 采纳率" | "AI 回复采纳率从 35%（基线：BI 看板）提升到 50%（KR1）" | | "优化客服体验" | "客服平均响应时长从 90s 降到 60s（KR3）" |

埋点事件

| ❌ 不可用 | ✅ 可用 | |---|---| | "记录 AI 回复使用情况" | 事件 ID ai_reply_send / 上报时机「点击发送（未编辑）」/ 扩展字段 trace_id, no_edit=true |

评测门槛

| ❌ 不可用 | ✅ 可用 | |---|---| | "回归测试通过" | "Golden 集通过率 ≥ 85%（LLM-as-judge）+ 对抗集 100% 通过 + 不低于上一版" |

风格约定（沿用 V0.5 字风格 · 节号简化）

• 二级标题用「一、二、三、...」中文序号 + 英文副标题（如「一、Summary 版本说明」）—— 中英双标方便 AI 识别意图
• 三级标题用「2.1 / 2.2 / 4.1.1」阿拉伯数字 + 小数点（替代旧版「1、2、3」纯数字）
• 需求范围表 6 列：序号 / 系统 / 功能 / 类型 / 优先级 / 摘要
• frontmatter 字段：product / version / status / owner / revision_log / review_log / links
• 字段说明用粗体起头 + 冒号 + 描述（例：全局开关： 控制项目维度...）
• 埋点事件表（全本 §6.1）5 列：事件 ID / 上报时机 / 扩展字段 / 公共字段 ✓ / 备注

常见 rationalization（agent 自查）

| 借口 | 反驳 | |---|---| | "用户没给完整信息，先写占位符" | Stop. 回 Stage 1 问 6 个核心问题。占位符 PRD 比没 PRD 还糟 | | "评测章节具体数值还没定，先写待定" | 给可挑战的初稿（如 P99 ≤ 3s），让算法 / QA 改 | | "本期没 AI，§4.3 / §6.2 可以删" | 可以删（这是 v2.3 改进点）—— 不适用的章节直接删，不要保留 N/A | | "灰度策略和回滚太繁琐，简化" | 不简化。回滚预案必须能在 5 min 内执行 | | "7 节还是太多，合并一些" | 严禁。7 节是给所有消费者覆盖的最小集；切片机制已经解决"研发觉得多"的问题，让研发读 stories/ 即可 | | "story 拆完直接给研发，评审下个版本再说" | 不行。三关评审 ~20 分钟/story，比研发拿着歧义 spec 跑偏一轮便宜得多 | | "用户没提非目标，可以不写 §2.4" | 必填。让用户在评审会现场补，比上线后扯皮便宜 | | "切片手工改一行没事" | 不行。切片是派生产物，下次重新生成会覆盖。改全本 |

文件清单

prd-writer/
├── SKILL.md                                # 本文件
├── templates/
│   ├── prd-template.md                     # 7 节全本模板（frontmatter + 业务核心）
│   ├── story-overview-template.md          # ⭐ v2.4 stories/00-overview.md 模板
│   ├── story-template.md                   # ⭐ v2.4 标准 story 卡片模板（≤100 行）
│   ├── story-template-lite.md              # ⭐ v2.4 小改动 lite 模板
│   ├── prd-template-coding-slice.md        # 编码切片模板（legacy · 被 stories/ 替代，保留兼容）
│   ├── prd-example-filled-v0.5.md          # V0.5 内容填充示例（学风格 · legacy 旧 13 节结构，仅供参考语言风格）
│   ├── page-design-template.md             # 页面 7 段标准模板
│   ├── eval-set-requirements.md            # 评测集需求模板（QA / 算法切片附属）
│   └── tracking-table-template.csv         # 埋点表 CSV（给 BI · 9 列口径）
├── tests/
│   ├── test-prompts.md                     # ⭐ 测试套件（6 条 × 四件套：T1-T4 行为/产物 + T5-T6 抬天花板硬题）
│   └── baseline-record.md                  # ⭐ v2.4.3 裸基线对照记录
└── references/
    ├── slice-generation.md                 # ⭐ stories/ 与 3 个只读切片的生成规则
    ├── ai-product-checklist.md             # AI 产品 7 维度 checklist
    └── tracking-events-spec.md             # 埋点字段规范 + 看板 SQL

Self-Evolving Protocol（每次写完 PRD 主动评估）

本 skill 是 living document。每次写一份新 PRD 都可能产生可复用的新经验，必须显式回流。

触发评估时机

| 完成动作 | 评估问题 | 归档路径 | |---|---|---| | 完成一份 PRD（任何 V0.X） | 这次有没有遇到现有模板未覆盖的章节 / 字段？ | 新章节模板 → templates/；新评测维度 → references/ai-product-checklist.md | | 用户拒绝某段写法（"不要这样写 / 删掉"） | 这条否定是不是普适规则？ | 反模式表（SKILL.md 内；条目积累过多时再拆独立 references 文件） | | 业务方提出新埋点字段 / 新事件类型 | 项目特例还是通用模式？ | references/tracking-events-spec.md | | 发现新 rationalization | 高频？要不要进自查表？ | SKILL.md 末段「常见 rationalization」 | | 遇到新 AI 产品形态（agent / RAG / fine-tune / 多模态） | 7 节够覆盖吗？ | 主文档调整 or references/ai-product-checklist.md 加维度 |

更新约束

• ❌ 不要默默更新 skill —— 必须告诉用户「本轮新增 N 条 X」让用户有否决权
• ❌ 不要等到 10+ 个 PRD 后再一次性蒸馏 —— 错过太多上下文
• ❌ 不要把项目特定字段当通用规则 —— 跨 ≥2 个项目验证过的才进 references
• ✅ 更新时必须在 SKILL.md 末尾 ## Changelog 加一行

30 秒自检清单（写完 PRD 后）

增长驱动（有没有新东西要加）：

• [ ] 本次 PRD 有没有新 AI 模块类型？（RAG / agent / tool-use / 多模态）
• [ ] 埋点表里有没有 tracking-table-template.csv 没覆盖的字段？
• [ ] 评测集设计有没有新维度？（jailbreak / hallucination / bias / latency）
• [ ] 灰度策略有没有新切流维度？（用户分群 / 项目 / 渠道 / 设备）

简化驱动（有没有可以砍的 · v2.3 新增 · 防止模板单调膨胀）：

• [ ] 本轮 PRD 哪些章节实际 0 内容 / 应该删？这类章节是否要从「核心必填」降级为「场景必填」或「推荐填写」？
• [ ] 本轮 DoD 哪一项是「为了凑完整性」而非真的产生价值？是否要从必填降级？
• [ ] 本轮反模式表有没有自相矛盾 / 已不适用的条目？

任一项勾选 → 显式回头更新 skill + 告知用户。简化驱动至少与增长驱动同等优先。

写完 PRD 后：建议 ingest 到项目 wiki

如果当前项目装了 pm-wiki-maintainer 且探测到 wiki 根（docs/wiki/ 或 docs/pm/wiki/），写完 PRD 后额外做一项：

- [ ] 本次 PRD §7.2 ADR 中有几条新决策？
- [ ] §2.2 用户角色有没有新增 / 画像更新？
- [ ] §3.1 需求范围引入了几个新功能模块概念？
- [ ] §4.3 AI 模块特化里有没有新维度？

任一项 ≥ 1，主动提示用户：

> 「本轮 PRD 含 N 条新 ADR / M 个新概念，建议执行 ingest PRD 到 wiki，下次 V0.x+1 写作时 Stage 0 能自动加载这些上下文。是否现在 ingest？」

用户同意后 → 调用 pm-wiki-maintainer 的 ingest 流程。

Bottom Line

好 PRD = 业务方一眼能看懂目标 + 开发能直接拿走干活 + QA 知道怎么验收 + BI 知道埋什么点 + SRE 知道怎么灰度回滚。

关键演进（v2.3 → v2.4）：不再追求"一份 PRD 满足所有人"，而是"一份全本 + stories/ + 切片"。AI 编码 agent 读 00-overview.md + 单个 story 卡片，QA 读 for-qa.md，BI 读 for-bi.md，SRE 读 for-ops.md —— 各取所需，互不干扰。

如果你的 PRD 让任何一个角色还要问"我该做什么？"，回 Stage 1。

🌐 跨平台支持（codex / cursor / antigravity / gemini / copilot）

本 skill 的核心知识（PRD 章节、反模式、切片规则）跨平台通用。Self-Evolving Protocol 的执行能力因宿主而异：

| 平台 | 安装路径 | Self-Evolving 触发方式 | |---|---|---| | Claude Code / Desktop | ~/.claude/skills/prd-writer/ | 🟢 全自动 | | Cursor | /.cursor-plugin/skills-songshishuang/prd-writer/ | 🟡 半自动（用户提示自检） | | Codex CLI / App | ~/.codex/plugins/songshishuang-skills/skills/prd-writer/ | 🟡 半自动 | | Gemini CLI / Antigravity | gemini extensions install github.com/songshishuang/Skills | 🟡 半自动 | | GitHub Copilot CLI | gh copilot marketplace add songshishuang/Skills | 🟡 半自动 | | ChatGPT Web / 本地小模型 | 复制 SKILL.md 到 instructions | 🔴 仅建议 |

半自动平台的触发咒语（写完 PRD 后手动发给 AI）：

请按本 skill 的 Self-Evolving Protocol 自检本轮 PRD，
评估有没有新反模式 / 新 AI 章节 / 新埋点字段要进 references/，
以及有没有章节应该砍 / DoD 应该降级（简化驱动）。

一键安装脚本见仓库根 INSTALL-MULTI-PLATFORM.md。

Changelog

• 2026-06-18 · v2.4.7 — MaaS V0.3.2 stories 重派生后 prd-reviewer 二关回流（3 高风险驱动，全做含 reviewer）：① slice-generation 加"验收数据自包含"护栏 + Anti-pattern 表 +1——研发只读 overview+story，故 AC 引用的 golden fixture / 期望值 / 枚举对照必须内联到 overview/story（治"fixture 留在全本 §6.2、AC 引用却研发不可复跑"的致命缺口；根因=派生规则砍 §6.2/§6.3 却没给"被 AC 引用部分"开例外）；② 决策闭环门加"取最新/去重/归并类三件套"（去重键 + 排序键 + 并列 tie-break，治"endpoint 取最新没说按什么键去重/并列取谁"）。纪律沿用：单点回流落 references/DoD 不开大章节；②属同项目第 2 次浮现但跨场景通用性高（列表去重/版本取最新通吃）故纳入闭环门，若后续证伪可降级。
• 2026-06-18 · v2.4.6 — MaaS V0.3.2 全本 PRD 三视角评审回流（产品总监/架构师/主研发 11 条意见）。根因诊断：skill 重"结构完整(7 节齐不齐)"、轻"决策闭环 + 口径精度"，且回溯式 PRD(已上线功能反推)无护栏→退化成 release note。经逐条自审去险后（砍与口径项重复的"进度条无分母"反模式行、去"status 绝不用 Released"绝对化、不造"需求池"新节改用已有 §2.6/§7、追溯改自检问句不强绑 1:1）落地：① DoD 增「决策闭环自检」门（目标↔设计↔验收可追溯 / 内部无矛盾[非目标 vs 设计] / 展示指标口径完整[分子·分母·状态枚举归桶]）；② §4.1.2 关系图加"标重数 + 多版本/重测/历史→展示最新/当前/全部口径"；③ 场景必填加"数据驱动视图→§5.3 业务级数据依赖契约(刷新/权限/延迟/可否单源派生·不写 API)"；④ Stage 0.5 加回溯护栏(status 诚实反映用途·实现史归 §7·正文按问题→决策→验收)；⑤ 反模式 +2(本期不做/仅登记项移出 §1/§3→§2.6/§7、占位功能须定呈现态且埋点一致)。prd-reviewer 模式 B 因"按 DoD lint"自动继承闭环门(+1 行显化)。纪律：单项目单点→落 DoD/反模式不开大章节，闭环门待第 2 项目验证再固化；约半数评审点(KR 弱/实现史前置)属执行错非 skill 错，靠遵守 skill 解决、不改 skill。
• 2026-06-17 · v2.4.5 — MaaS V0.3.2 实战回流（story 过度拆分事故）：把一个单文件页面沿"骨架/行明细"水平拆成两卡，被 prd-reviewer 第二关判高风险 D5（跨 story 行渲染契约不存在）→ 合并为单卡。经自审去险后新增净缺口而非搬整套 INVEST（现有"可独立交付闭环"已覆盖 I/V）：slice-generation 拆分粒度补 2 条——拆分轴=垂直价值增量(非水平 UI 层)(沿 MVP→增强/流程/CRUD/角色/主路异常/多端切，禁按页面 UI 层拆，一页通常=1 卡但可拆数个垂直增量) + 反向自检(卡需描述"怎么插进兄弟卡内部"=过度拆分→合并)；反模式表 +1 行。自审驳回了原提案的"单页绝不拆"绝对化表述(与 MVP→增强自洽冲突)。单项目单次教训，按 Self-Evolving Protocol 落反模式+slice 规则、未开大章节。
• 2026-06-17 · v2.4.4 — 营造（yingzao v1.11）二轮大修，「抬天花板」式：上一轮装载版已 29/30 撞顶现有测试集 → 勘验判定 headroom 不在提分而在抬高测试天花板。新增 T5/T6 硬题（完整 7 节 PRD 端到端 + stories/ 派生契约，各埋技术 schema / lite 粒度对抗诱饵）破除虚高：隔离重测装载版 T5/T6=18/20 vs 裸基线 0/20（skilllift +9/+9），暴露 2 个此前未测出的真实输出分缺口。采纳改进②（story 正文不点兄弟 storyid、依赖只在 overview 索引列单向声明——slice-generation + 反模式表）；改进①（§3.1 每条需求带价值假设）评估为与"摘要精炼"原则冲突、有臃肿风险，未采纳。crossover 本轮不触发（单方向确定性规则补充、无互补区块）。测试集 4 条 → 6 条。
• 2026-06-12 · v2.4.3 — 营造（yingzao）首次大修，四轮细作（双盲评 65→72.5，访例 32 对标确认生态位）：① 新增 tests/ 测试资产——test-prompts.md 4 条四件套套件（正触发/负触发诱饵/时间压力纪律诱饵/小切片产物契约）+ baseline-record.md 裸基线对照（4 条全部非永真，含 T2 防回归适用性说明）；② 一致性修复 19 处——工作流标题"4 阶段"→6 阶段、Q 编号矛盾、断链引用、外围资产旧 13 节编号残留（§6.x→§4.x ×5、"第七章/八.1"→§6.1/§6.2、"3、埋点上报设置"→6.1.3）、CSV 与第五节示例表对齐 9 列双口径（删"事件名称"列+补"公共字段"列）、"反模式 25"悬空引用 ×3、DoD"9 项"→10 项、文件清单补 tests/、切片口径统一、产物内相对路径加防留提醒 ×2、去除对外部 CLAUDE.md 偏好的依赖；③ 同日完成：§4.x 节序重排（§4.1/§4.2 互换为正序并标注"Stage 2 附属规范 A/B"消除阶段流打断）+ 装载版对比实测（隔离运行+独立评委：装载版 29/30 vs 裸基线 11/30，分差 18 显著优于，Pareto 无单点崩坏，记录入 tests/baseline-record.md）；下一轮入口：stories/ 派生产物契约测试、7 节填充示例
• 2026-06-12 · v2.4.2 — 第二轮评审修复(外围资产与主契约对齐):① Stage 0 wiki 根改探测式(docs/wiki/ → docs/pm/wiki/ 顺序,MaaS 命中后者);② 输出位置改「沿用项目既有 PRD 目录」(MaaS: docs/pm/prd/),默认 02_PRD/ 仅限无既有结构的新项目;③ prd-template §7.4 切片链接 for-coding.md → stories/(清死链);④ 埋点口径统一双轨:全本 5 列 → BI 9 列显式转换(事件描述/页面路径/页面名称/告警阈值为 BI 扩展列),tracking-events-spec 旧「8 列」废弃;⑤ overview 模板正文 PRD 链接去硬编码(引 frontmatter prd_source)
• 2026-06-12 · v2.4.1 — 研发侧 NOT-READY 评审 7 条驱动的契约修订：模板路径去硬编码（以 story 文件位置为基准 + lint 强校验可解析 + prototype_url 跨仓稳定入口）；状态机拆双权属（spec 状态 draft/ai-passed/ready 归 PM 仓 · 交付状态 pending/in-dev/done 归研发仓 delivery-status.md，重派生不覆盖签收）；lite 模板补 title/spec_test 并限 ≤30 行；spec_test: passed 语义 = 分级关卡全过；self-consistency 纪律：模板与样例必须能过自己的门禁
• 2026-06-11 · v2.4 — 编码切片升级为 stories/ 目录（按 story 拆分 · 源自 MaaS 项目研发分工讨论 + 2026-06 行业 SDD 调研）
• for-coding.md 单文件 → stories/ 目录：00-overview.md（版本目标 + story 索引 + 公共约定）+ 按 story 拆分的 ST-XXXX 卡片（≤100 行，AC 全 Given-When-Then，「不做」边界必填）；研发 AI 每次只喂 overview + 单个 story，上下文最小化
• 粒度弹性：新增 story-template-lite.md，小改动不强拆（吸收 Martin Fowler 对 SDD 粒度错配的批评）
• 与 prd-reviewer 衔接：story 默认 draft，过分级关卡（标准=三关，lite=两关）spec_test: passed → ai-passed，研发 48h 走查过 → ready；spec 状态（PM 仓）与交付状态（研发仓 delivery-status.md）分仓分权属
• 新增文件：templates/story-overview-template.md + templates/story-template.md + templates/story-template-lite.md；prd-template-coding-slice.md 转 legacy
• 行业对标：story 卡片 ≈ AWS Kiro requirements.md（user story + EARS）；overview ≈ Kiro steering + Spec Kit Constitution；干跑自测 ≈ Anthropic "spec 合格 = AI 能直接建出来"
• 完整方案见 MaaS 仓 docs/pm/specs/2026-06-11-story-spec-workflow.md
• 2026-05-21 · v2.3 — 重大重构：13 节 → 7 节 + 角色切片机制
• 结构压缩：原 13 节合并为 7 节（Summary / Problem & Goals / Scope / Design / Rollout & Risks / Quality / Appendix），中英双标章节名；治理元信息（修订记录 / 评审记录 / 参考链接）移到 frontmatter；总行数 ~548 → ~314（-43%）
• 新增角色切片机制：每份 PRD 默认派生 4 个切片（for-coding / for-qa / for-bi / for-ops），AI 编码 agent 只读 for-coding.md（约 150 行 · 仅业务核心），解决"一份 PRD 撑 6 个消费者互相污染"问题
• DoD 分层：原 11 项"必填"重排为「核心必填 9 项 / 场景必填 5 项 / 推荐填写 4 项 / 永远不写 2 项」
• 反模式反转：删除"保留 N/A 章节"反模式，改为"不适用就删除"（N/A 会污染 AI 编码切片）；删除"13 节太多合并"严禁约束，改为"7 节是最小集 + 切片解决冗余"
• Self-Evolving Protocol 加反向问题：30 秒自检清单加 3 条「简化驱动」问题（哪些章节应删 / 哪些 DoD 应降级 / 哪些反模式过时），防止模板单调膨胀
• 社区参考：借鉴 Amazon Working Backwards / Basecamp Shape Up / Google Design Doc / Linear spec / Atlassian Poster
• 新增文件：templates/prd-template-coding-slice.md + references/slice-generation.md
• 保留：Stage 0 / 0.5 工作流 + page-design-t

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: songshishuang
• Source: songshishuang/Skills
• License: MIT
• Homepage: https://github.com/songshishuang/Skills

Install and usage instructions live in the source repository linked above.