上一版三角色手册发布后，收到两类反馈：①"需求的问题没人兜底"——AI 拿到一句话就开写，还特别爱加戏，你要个"保存按钮"，它给你顺手做了撤销、重做和自动同步；②"技能还是繁琐"——10 个技能记不住，2 份自建文件嫌多。这一版两个动作一次到位：新增产品经理角色，把"要什么"从架构师手里独立出来；同时全线收敛——10 个技能压到 7 个，自建文件从 2 份减到 1 份。
TL;DR
- 四个角色 = 四个技能包 = 7 个技能，每包 1–2 个，好记：
- 👤 产品经理（1 个）：圈需求——定价值、划边界、写场景
- 🏗️ 架构师（2 个）：探方案 → 定方案
- 🔨 开发（2 个）：按纪律实现 → 交证据
- 🧪 测试（2 个）：把关 → 验收
- OpenSpec 四件套有了三个主人：proposal.md 归产品、design.md + tasks.md 归架构、specs/ 由产品起草、测试把关——每个交付物都有明确责任人，需求问题不再悬空。
- 现成技能覆盖 6 个，自建只需 1 份 Markdown（文末模板）。
- 口诀升级为四句："为什么做？不做什么？"——"方案想清楚了吗？"——"对照的是哪条 spec？"——"测试全绿吗？证据呢？"
一、为什么必须有产品经理这个角色
前两版把"想清楚"都压在架构师身上，实际操作时 AI 会把两类问题混在一起：
- 要不要做（价值判断）：用户真的需要吗？范围多大？哪些明确不做？——这是产品的问题；
- 怎么做（技术判断）：方案选型、影响面、和现有代码兼不兼容——这才是架构的问题。
混在一起的后果很具体：AI 在 brainstorming 阶段问你的是技术选型，而不是"你要解决谁的什么问题"；在提案阶段顺手塞进一堆"听起来合理"的需求膨胀——而你没有角色有权力说"这个不做"。
AI 编码的翻车源头，一半在需求：
- 一句话需求直接开写——AI 没问"为什么做"，你也没想清楚；
- AI 爱加戏——你要 A，它给你 A+B+C，每一项单看都合理，合起来是范围失控；
- 验收无标准——做完之后拿什么判断"做对了"？没有用户场景，只有开发自己的感觉。
产品经理技能包解决的就是这三个问题。
四角色总览
| 角色 | 一句话职责 | 技能 | 管住什么 | 核心产出 |
|---|---|---|---|---|
| 👤 产品经理 | 定价值：做对的事 | 圈需求 | 需求不漂移 | proposal.md + specs/（用户场景） |
| 🏗️ 架构师 | 定方案：想明白怎么做 | 探方案 → 定方案 | 方案不跑偏 | design.md + tasks.md |
| 🔨 开发 | 守纪律：照契约实现 | 按纪律实现 → 交证据 | 过程有纪律 | 干净分支 + 全绿测试 |
| 🧪 测试 | 管验收：证据说话 | 把关 → 验收 | 完成有证据 | 用例清单 + 验证报告 + 归档确认 |
验收权和生产权分离的原则不变：开发可以自评，但终审在测试；而在这之上再加一层——需求变更的审批权在产品，AI 无权替你决定"要不要做"。
二、四件套三个主人：新增 PM 后最漂亮的映射
OpenSpec 的 /opsx:propose 产出四个工件。四角色下，它们不再"一把抓"，而是各有主人：
openspec/changes/add-dark-mode/
├── proposal.md # 为什么做、做什么、不做什么 ★ 产品经理
├── specs/ # WHEN/THEN 用户场景 ★ 产品起草 → 测试把关
├── design.md # 技术方案 ★ 架构师
└── tasks.md # 实现清单（2–5 分钟粒度） ★ 架构师
这张表的价值在于：需求问题有了明确的追责线。场景写模糊了打回产品；方案和代码打架打回架构；任务粒度太粗打回架构；实现有偏差打回开发——每个门后面都有人。
三、👤 产品经理技能包（1 个技能）：定价值
P1 圈需求（brainstorming 现成 + 提案起草）
解决什么：一句话需求直接开写、AI 加戏、验收无标准——三大需求侧翻车点。
怎么做：
- 苏格拉底式提问，逼出真实意图（
brainstorming的看家本领）：为什么做？给谁用？成功长什么样？——禁止在这个阶段讨论任何技术方案； - 起草 proposal.md：为什么做、做什么、不做什么。"不做清单"是这个技能的灵魂——范围边界写死在纸面上，AI 再想加戏，先撞这堵墙；
- 起草 specs/ 用户场景：从用户视角写 WHEN/THEN——"WHEN 用户点击保存 THEN 设置立即生效"是场景，"体验流畅"不是。
产出与验收门：proposal.md + specs/ 初稿。门：一句话说清"为什么做"；有不做什么清单；每条场景都能从用户价值出发讲通。
⚠️ 忌讳：产品经理别碰技术方案（那是 A1/A2 的活），也别替开发拆任务。你只回答"要什么、不要什么"。
四、🏗️ 架构师技能包（2 个技能）：定方案
A1 探方案（/opsx:explore 现成）
解决什么：拍脑袋选型、方案与现有代码打架。
怎么做：拿到需求共识后，让 AI 读真实代码库——权衡技术方案、评估影响范围、盘点风险点。零风险试错，不产出任何代码。
产出与验收门：方案与影响面评估。门：你能用自己的话把方案复述出来，复述不出来 = 没想明白，禁止进入 A2。
A2 定方案（/opsx:propose 修订 + 任务拆解）
解决什么：方案只活在讨论里、任务粒度太粗给 AI 留自由发挥空间。
怎么做：
- 修订 design.md：定下"怎么做"，并自查三件事——与现有代码兼容吗？影响面闭环吗？风险有预案吗？
- 拆解 tasks.md：每个工作项 2–5 分钟粒度，每个任务带三件套——精确文件路径、完整代码、验证步骤。
产出与验收门：design.md + tasks.md 定稿。门：每条任务有文件路径与验证步骤；与 specs/ 场景一一对应，无遗漏无加戏。
⚠️ 忌讳：一个变更一个文件夹。 三个功能塞进一个 change，tasks.md 会变成执行不完的巨无霸，评审也失去焦点。
五、🔨 开发工程师技能包（2 个技能）：守纪律
拿到 A2 的细粒度 tasks.md，开发不再自己定计划——照单执行，按纪律实现。（对比上一版：writing-plans 的拆解纪律上移给了架构师 A2，开发侧少一个技能。）
D1 按纪律实现（TDD × 子代理 × 双阶段评审，链路核心）
解决什么：测试后补、上下文污染、瞎试调试——实现侧三大翻车点。
怎么做：
- 第 0 步备战场：开 worktree 隔离分支，跑一遍基线测试确认全绿（基线红了先修基线，不许带病开工）；
- 然后每个任务走同一套循环：
- 派全新子代理执行——上下文干净，不被前序杂音污染；
- TDD 红绿重构：先写失败测试 → 看它失败 → 最小实现 → 通过 → 提交；
- 测试红了走四阶段根因分析——过程压过猜测，禁止"改一下试试"；
- 双阶段评审：先规格符合度（对照 specs/ 逐场景核对），再代码质量（Critical / Major / Minor 分级）；
- Critical = 0 才进下一任务，这个门是硬的。
产出与验收门：逐任务的代码 + 测试 + 评审记录。门：每个任务双阶段全过、Critical=0。
⚠️ 忌讳：进入实现前清一次上下文。 规格落盘的最大红利就是新会话读规格即可恢复约束，别让脏上下文糟蹋了它。
D2 交证据（verification-before-completion + finishing-a-development-branch）
解决什么："我觉得修好了"——声明不等于证据。
怎么做：跑完整验证（lint、单测、构建、必要的 E2E）留输出；验证后选择合并 / 提 PR / 保留 / 丢弃，清理工作树。
产出与验收门：全绿测试 + 验证证据 + 干净分支。门：证据齐了才交给测试包 T2。
六、🧪 测试工程师技能包（2 个技能）：管验收
T1 把关（可测性审查 + 用例转换，自建）
解决什么：模糊需求没法验收（"表现正确"），验收标准凭感觉（用例来自开发的口头解释而非规格）。
怎么做：
- A2 阶段就介入：逐条检查 specs/——每个 WHEN/THEN 都能转成自动化测试吗？模糊表述打回产品重写；
- 规格冻结后转用例清单，标注三类：正向场景、边界 case、异常分支。可与开发并行。
产出与验收门：可测性报告 + 用例清单。门：100% 场景可转化，用例只来自 specs/。
T2 验收（独立终审 + 完整验证 + 归档）
解决什么：考生批自己的卷子；归档不做，AI 读到的"当前事实"越来越模糊。
怎么做：
- 独立终审，两段：对照 specs/ 逐场景核对实现（无缺失、无私自扩需求）；TDD 纪律三查——测试先于实现？断言强度够？边界 case 有覆盖？（对照 T1 用例清单）
- 独立跑完整验证，证据说话；
- 通过后执行
/opsx:archive：变更沉档，openspec/specs/更新为唯一事实源； - 终极验收：归档后新开会话，问 AI"这个功能的行为契约是什么"。
产出与验收门：评审结论 + 验证报告 + 归档确认。门：发现"绿灯造假"直接打回；新会话能从 specs/ 复述行为契约，答不上来 = 归档没做好。
⚠️ 忌讳：archive 是纪律不是仪式。
七、一条流水线上的接力
7 个技能放回 SOP 四阶段：
| SOP 阶段 | 👤 产品 | 🏗️ 架构 | 🔨 开发 | 🧪 测试 | 过闸条件 |
|---|---|---|---|---|---|
| Explore | P1 圈需求（提问澄清） | A1 探方案 | — | — | 能复述"为什么做"+"方案" |
| Propose | P1 落纸面（proposal + specs） | A2 定方案（design + tasks） | — | T1 审可测性 | 不做清单在场、场景零模糊 |
| Apply | （改需求走 P1 重新澄清） | （A3 纪律：改方案必更新文档） | D1 按纪律实现 | T1 转用例（并行）→ T2 终审 | 每任务双阶段全过，Critical=0 |
| Verify & Archive | — | — | D2 交证据 | T2 验证·归档 | 全绿 + 新会话能复述契约 |
四条硬规则贯穿全程：
- 验收门不过，不许进下一步；
- specs/ 是四个角色的唯一握手点——产品写它、架构对齐它、开发对照它实现、测试对照它验收；
- 谁产出，谁不终审——开发可自评，判定过测试；
- 需求加戏，产品说了算——AI 和开发都无权决定"要不要做"，只能提出、由 P1 裁决。
八、落地：现成的 6 个 + 自建的 1 份
技能来源对照表
| # | 技能 | 来源 | 用在哪 |
|---|---|---|---|
| P1 圈需求 | brainstorming + /opsx:propose 起草 | Superpowers + OpenSpec（现成） | 产品 |
| A1 探方案 | /opsx:explore | OpenSpec（现成） | 架构 |
| A2 定方案 | /opsx:propose 修订 + 拆解 | OpenSpec（现成） | 架构 |
| D1 按纪律实现 | TDD / subagent-driven-development / requesting-code-review / systematic-debugging | Superpowers（现成） | 开发 |
| D2 交证据 | verification-before-completion + finishing-a-development-branch | Superpowers（现成） | 开发 |
| T1 把关 | 可测性审查 + 用例转换 | 自建 | 测试 |
| T2 验收 | 独立终审 + /opsx:archive（验证复用现成技能） | 自建 + OpenSpec | 测试 |
三步装好
# ① 装 OpenSpec（Node 20.19+）
npm install -g @fission-ai/openspec@latest
openspec init # 选择你的 AI 工具
# ② 装 Superpowers（Claude Code）
/plugin install superpowers@claude-plugins-official
# ③ 放入 1 份自建技能（见下），四角色包即完整
唯一的自建技能：acceptance-guard（给测试，覆盖 T1 + T2）
---
name: acceptance-guard
description: 规格冻结后、开发提交任务产出时、归档前触发。
测试工程师以独立评审人身份执行，判定不接受开发自评结果。
---
# 验收守护
## T1 把关
- 逐条检查 specs/：每个 WHEN/THEN 都能转自动化测试吗？
模糊表述（"流畅""正确"）打回产品重写。
- 用例清单只来自 specs/，标注：正向 / 边界 / 异常。
## T2 验收
- 独立终审：对照 specs/ 逐场景核对实现，无缺失、无私自扩需求
（对照 tasks.md 查"顺手多做了什么"）。
- TDD 三查：测试先于实现？断言强度够？边界 case 有覆盖？
- 发现"绿灯造假"直接打回。
- 独立跑完整验证（lint / 单测 / 构建 / E2E），保留证据。
- /opsx:archive 后，新开会话问"这个功能的行为契约是什么"，
AI 必须能从 specs/ 直接回答，否则归档验收不通过。
团队口诀（四句，贴 wiki 用）
- 动手前："为什么做？不做什么？"（P1 的门）
- 编码前："方案想清楚了吗？"（A1/A2 的门）
- 实现中："对照的是哪条 spec？"（D1 的门）
- 收尾时："测试全绿吗？证据呢？"（T2 的门）
九、总结
这一版把三角色手册升级为四角色、7 个技能，一次解决两类反馈：
- 需求问题有人兜底了：产品经理用"不做清单"挡住 AI 加戏，用用户场景让"做对了"有定义；四件套三个主人，每个门后面都有人；
- 上手成本降下来了：每包 1–2 个技能，现成覆盖 6 个，自建只剩 1 份 Markdown，口诀四句话。
角色链一句话记住：产品定价值，架构定方案，开发守纪律，测试管验收。
SDD 的本质没变——把"动手前对齐"这件软件工程里最便宜的事捡回来。变的只是：现在从"想做什么"的第一秒起，每个问题都有角色、有技能、有门。
下次你的 Agent 说"我做完了"，按包追问四句：为什么做？方案清楚吗？对照哪条 spec？证据呢？
参考链接：
- OpenSpec：github.com/Fission-AI/…
- Superpowers：github.com/obra/superp…
如果这篇文章对你有帮助，点个赞收藏一下，你的三连是我写下去的动力。
