P-D-C 串行闸门团队工作流
> 本技能封装了「主控 + P-D-C 三人组 + 按需选组 + 闸门流转」的完整团队执行框架。
一、什么时候用
当用户说：
- 「帮我做一个深度分析报告」
- 「用团队方式做这件事」
- 「需要调研 + 分析 + 撰写 + 设计」
- 任何需要多角色分工协作的复杂任务
不要在以下场景使用：简单问答、单一任务、快速查资料。
二、团队架构
角色定义
| 角色 | 职责 | subagent_type |
|---|---|---|
| 主控（你） | 任务路由、组间协调、汇总交付 | — |
| A 计划员 | 制定本组工作计划与验收标准 | Plan |
| B 执行员 | 按计划执行，产出交付物 | general-purpose / Explore |
| C 核查员 | 核对 B 产出是否与 A 计划对齐，查遗漏/漏洞 | general-purpose |
职能组清单
| 组 | 适用场景 |
|---|---|
| 资料与代码调研组 | 任何分析类任务的第一步，需要网络检索 + 本地源码 |
| 技术与架构分析组 | 技术原理、架构设计类任务 |
| 规划架构组 | 方案设计、技术选型 |
| 开发执行组 | 代码实现、功能开发 |
| 内容撰写组 | 报告、文档、方案撰写 |
| 设计可视化组 | PPT、图表、架构图 |
| 质检组 | 终审、质量校验 |
三、运行模型
核心规则
- 任务路由：主控收到任务后，判断需要哪些职能组、什么顺序
- 单组激活：同一时刻只激活一个职能组（3 人），其余待命
- 组内 P-D-C 闭环：A 计划 → B 执行 → C 核查；C 不通过则打回
- 闸门流转：当前组 C 签字放行后，才唤醒下一组
- 主控汇总：最后一组放行后，汇总交付
任务 → 职能组 映射
| 任务类型 | 唤醒的职能组（顺序） |
|---|---|
| 产品 / 技术原理分析报告 | 调研 → 技术与架构分析 → 内容撰写 → 设计可视化 → 质检 |
| 软件开发 / 新功能 | 规划架构 → 开发执行 →（测试工程）→ 质检 |
| 技术文档 / PRD | 规划架构 → 内容撰写 → 质检 |
| 营销方案 / 路演 PPT | 调研 → 内容撰写 → 设计可视化 → 质检 |
四、深度分析四准则（v2 核心）
当任务是「分析 / 原理 / 报告」类时，必须执行以下四准则：
准则 1 · 资料获取双轨制
- 轨道 A：WebSearch + WebFetch 拿官方文档、论文、博客
- 轨道 B：对开源项目，
git clone到本地，用 Read/Grep 读真实源码 - 禁止只靠 WebFetch 摘要下结论
准则 2 · 原理 → 方案详细设计 → 可落地
每个机制必须产出三级：
1. 原理层：思想来源、形式化描述
2. 方案详细设计层：数据结构、模块划分、函数签名、算法步骤
3. 可落地层：依赖、边界条件、选型建议
准则 3 · 反杜撰与证据台账
- 每条事实断言带
[src: 来源]标注 - 维护
evidence-ledger.md（断言 → 来源映射表） - 无法确证的内容标注「推测 / 待验证」
准则 4 · 多层报告结构
- 报告至少 3 层：篇 → 章 → 节 →（深读块）
- 每个章可下钻到「深读」细节
- 含可点击目录、跳转锚点
五、执行流程
Step 1：任务解析
- 理解用户任务
- 判断任务类型
- 按「任务 → 职能组 映射」选择需要的组
- 排列执行顺序
Step 2：创建任务看板
TaskCreate 为每个阶段创建任务
TaskUpdate 标记状态：pending → in_progress → completed
Step 3：创建 outputs 目录
mkdir -p outputs/01-调研 outputs/02-分析 outputs/03-撰写 outputs/04-设计 outputs/05-质检
Step 4：逐组执行（每组 A→B→C）
每组产出：
- outputs/0X-组名/plan.md — A 的计划
- outputs/0X-组名/draft.md — B 的产出
- outputs/0X-组名/check.md — C 的核查意见
流转规则：当前组 C 放行后，才唤醒下一组
Step 5：主控汇总
- 收集各组合格产物
- 编译最终交付物
- 交付给用户验收
六、配套资源
references/ 目录
将团队蓝图复制到：
~/.workbuddy/skills/pdc-team-workflow/references/团队蓝图.md
详细角色定义、岗位 brief 模板、协作协议见团队蓝图。
七、示例：执行一个技术原理分析报告
用户输入
> 帮我分析一下 litellm 这个开源项目的技术原理，输出详细的技术原理分析报告
执行步骤
- 任务解析：技术原理分析报告 → 选组：调研 → 技术分析 → 撰写 → 设计 → 质检
- 创建任务看板：6 个阶段
- 调研组：
- A 计划：检索维度 + clone 目标仓
- B 执行：WebSearch + git clone litellm 源码
- C 核查：确认源码已精读、维度全覆盖 - 技术分析组：产出 5-8 个机制的「原理+设计+落地」三级文档
- 内容组：产出具多级目录的 HTML 报告
- 设计组：产出架构图（标注来源）
- 质检组：全链路检查 + evidence-ledger 核对
- 主控汇总：编译最终报告，交付
八、关键约束
- 子代理无记忆：每次派给 B/C 的 brief 必须写清背景、已知信息、产出标准
- C 是闸门：C 不放行就不能流转到下一组
- 单组激活：同一时刻最多 3 个 teammate 在跑
- 产物可追溯：所有断言必须带 src 标注
