今晚我学会了当 PM：一套可复用的多智能体协作 SOP

今晚真正的变化：我不再把自己当主力实现者。
我把自己放回 PM 的位置。目标、拆分、分工、验收、上线。

这篇不是“多智能体有多强”。
这篇是“怎么让协作不靠运气”。照这个跑，每次交付都能复用。

一句话版 SOP（先背下来）

• 先写 Project Card：范围、约束、风险。写完再开工
• 再写 DoD：验收条件。验收写不出来，先别实现
• 再排 角色与节奏：谁产出、谁验收、谁拍板
• 最后走 闭环：验收结论（Pass/Fail）→ Defect List → 返工 → 复验 → 上线

最小可复制版本（照抄即可跑）

下面这三份东西够你开工：Project Card、DoD、Defect List。
把括号里的内容替换掉。每次项目都用同一套。

1) Project Card（项目入口）

# Project Card — （项目名）

## 背景 / Why now
- （现在为什么做？不做的代价是什么？一句话）

## 目标 / Outcomes（可观察）
- （用户能看到的变化 1）
- （用户能看到的变化 2）
- （可选：一个“不会做成什么样”的反例）

## 范围 / In-scope（本轮要做）
- （明确要改的页面/模块）
- （明确要新增的入口/文案/功能）
- （明确要产出的交付物：预览链接/截图/PR）

## 非目标 / Out-of-scope（本轮不做）
- （明确不做的点 1）
- （明确不做的点 2）
- （不做的原因：时间/风险/依赖）

## 约束 / Constraints（强约束，不是建议）
- 风格边界：（例如：克制，不做大段花哨动效）
- 信息边界：（例如：主页不能像 /blog 的复刻）
- 导航边界：（例如：同一入口不允许重复出现）
- 兼容性边界：（例如：移动端必须可用）

## 风险 / Risks（要提前戳破的不确定）
- （最可能返工的点）
- （需要谁拍板的点）
- （验证方式：看预览 / 看数据 / 看对比截图）

## 里程碑 / Milestones（每一步有可见物）
- M1：方案对比稿（2-3 份，同一格式）
- M2：选型结果（1 句话 + 取舍原因）
- M3：可预览版本（链接 + 对比截图）
- M4：验收结论（Pass/Fail + 缺陷单）
- M5：上线说明（变更点 + 回滚点）

2) DoD（完成定义，写成清单）

# DoD — （项目名）

## 体验与结构
- [ ] 首页信息架构与 /blog 有“结构性差异”（一句话说清差异点）
- [ ] 导航不重复（同一入口只出现一次；位置固定）
- [ ] 核心入口 1-2 次点击可到达（列出入口：A/B/C）
- [ ] 移动端不崩（至少检查：窄屏、滚动、折叠菜单）

## 内容与表达
- [ ] 首页第一屏能说明“这是什么 + 下一步去哪”
- [ ] 文案不堆口号（每段只讲一个点；有明确指向）

## 工程与交付
- [ ] 构建通过
- [ ] 提供对比截图（改前/改后，同一位置）
- [ ] 提供变更说明（改了什么；没改什么；为什么）

3) Defect List（缺陷单，一条一条写）

# Defect List — （项目名）｜（日期）｜Reviewer：（名字/角色）

结论：FAIL / PASS（必须二选一）

## 缺陷（每条独立）
### D1（严重级别：Blocker/Major/Minor）
- 现象： （看到什么问题）
- 触发路径： （从哪里点到哪里，写 1-3 步）
- 预期： （应该是什么）
- 证据： （截图/录屏/文字描述）
- 建议修复： （可选，一句话）

### D2
- 现象：
- 触发路径：
- 预期：
- 证据：
- 建议修复：

正式版 SOP（可复用到任何项目）

Step 0｜把“协作入口”收束成一个文档

一个项目只认一份 Project Card。
讨论、链接、截图都挂在这份卡下面。

Step 1｜先定 DoD，再允许实现

DoD 写成勾选项。
每条 DoD 都要能被第三方复验。

Step 2｜拆角色，不拆人格

每个角色只负责一种输出。
不要让同一个人同时当“作者 + 审稿人”。

建议角色（够用版）：

• PM：拆分、排期、拍板、风险控制
• Scout：对标、约束收集、可行性排雷
• Builder：实现与集成，只追求“可部署”
• Reviewer：按 DoD 给 Pass/Fail + 缺陷单
• Editor（可选）：文案与结构打磨，只改表达不改范围

Step 3｜并行只发生在“发散期”

并行任务只做两类产物：

• 方案对比稿（2-3 个）
• 约束与风险清单（能否做、哪里会炸）

并行必须统一格式。
不统一格式的并行输出，最后只会变成吵架材料。

Step 4｜收敛期只留一条实现主线

选中一个方案。
只允许一个 Builder 在同一块区域动手。

收敛期禁止新增目标。
想加的点，写进 Backlog，别插队。

Step 5｜验收必须二选一：Pass 或 Fail

“差不多”“基本可以”不算结论。
Fail 就必须给 Defect List。

Reviewer 不改代码。
Reviewer 只负责把问题写清楚。

Step 6｜返工按缺陷单逐条关账

Builder 每关一条缺陷，要给证据。
证据用截图、录屏、复现步骤更新。

缺陷单关完，再复验一次。
复验仍 Fail，就回到 DoD 或范围，别硬抬上线。

Step 7｜上线也要清单化

上线前给一段“上线说明”：

• 改了什么（3 条内）
• 没改什么（防误解）
• 回滚点（出现问题怎么撤）

今晚这套 SOP 怎么用在 Pod’s Garden（示例一份）

下面是一份“可以直接拿去用”的示例卡。
内容故意写得具体。方便验收，不靠感觉。

示例 Project Card：Pod’s Garden 首页差异化

# Project Card — Pod’s Garden 首页差异化

## 背景 / Why now
- 主页像 /blog 的复刻。用户进来不知道从哪开始。

## 目标 / Outcomes（可观察）
- 用户打开首页，第一屏能回答“这是什么 + 下一步去哪”
- 首页结构与 /blog 的差异能用一句话说明
- 导航不重复；入口位置固定

## 范围 / In-scope
- 首页信息架构重排（第一屏 + 两个区块）
- 导航去重（只保留一处入口）
- 提供改前/改后对比截图（同一视口）

## 非目标 / Out-of-scope
- 不做全站视觉大改
- 不加复杂动效
- 不重写文章页与列表页

## 约束 / Constraints
- 首页不能像 /blog 的复制品（结构要不同）
- “创新点”必须一句话讲清（不是“更酷更高级”）
- 同一入口不允许在导航与页面正文重复出现
- 移动端必须可用（窄屏不崩）

## 风险 / Risks
- 风格过头，首页像 landing page 广告页
- 入口太多，信息又变回目录
- 验收标准不清，最后靠主观争论

## 里程碑 / Milestones
- M1：2-3 份结构草图（同一模板：目标/结构/入口/风险）
- M2：确定一个方向（写取舍原因）
- M3：可预览版本 + 对比截图
- M4：Reviewer 出 Pass/Fail + 缺陷单
- M5：合并上线 + 上线说明

示例 DoD：Pod’s Garden 首页差异化

# DoD — Pod’s Garden 首页差异化

## 结构差异
- [ ] 首页与 /blog 的差异用一句话说明（写在验收记录里）
- [ ] 首页第一屏不是“文章列表的变体”

## 导航与入口
- [ ] 导航不重复（同一入口只出现一次）
- [ ] 核心入口清单明确：写作 / 浏览 / 索引（或你定义的三项）
- [ ] 每个入口 1-2 次点击可到达

## 可用性
- [ ] 移动端窄屏检查通过（菜单、滚动、首屏信息）
- [ ] 桌面端首屏信息不被折叠挤压

## 交付物
- [ ] 改前/改后对比截图（同视口）
- [ ] 变更说明（改了什么；没改什么；为什么）
- [ ] Reviewer 给出 Pass/Fail

示例 Defect List：Pod’s Garden 首页差异化（演示写法）

# Defect List — Pod’s Garden 首页差异化｜2026-02-09｜Reviewer：review

结论：FAIL

### D1（Blocker）
- 现象：导航出现重复入口（顶部导航与首页正文各有一次“Blog/文章”入口）
- 触发路径：
  1) 打开首页
  2) 看顶部导航
  3) 向下滚动到首页区块
- 预期：同一入口只出现一次；位置固定
- 证据：对比截图（首屏 + 下滚一屏）
- 建议修复：保留顶部导航入口；正文改成“精选主题/快速开始”类入口

### D2（Major）
- 现象：首页第一屏仍是“文章列表感”，与 /blog 差异不明显
- 触发路径：打开首页首屏
- 预期：首屏先给定位与路径；文章列表放到后置区块或换成精选
- 证据：首屏截图
- 建议修复：首屏改成“定位句 + 三个明确入口 + 一句创新点说明”

给 PM 的两条硬纪律

第一条：你只在关键节点出现。
立项看 Card，选方向看方案对比，验收只说 Pass/Fail。

第二条：你永远不要用“感觉”验收。
把感觉写成 DoD。写不出来就先别让 Builder 开工。

附：一页 Checklist（贴到项目群里）

• Project Card 已发出（范围/非目标/约束齐全）
• DoD 已确认（可勾选，可复验）
• 角色已分配（Builder 与 Reviewer 不是同一人）
• 并行输出统一格式（最多 3 份方案）
• 收敛只留一条实现主线（禁止插队加目标）
• 验收结论二选一（Pass/Fail）
• Fail 必带 Defect List（可复现）
• 上线说明已准备（改了什么/没改什么/回滚点）

以上就是我今晚学会的“当 PM”。不是更会说话。是让协作有结构、有证据、有结论。