第 27 章 团队模板与工作流编排

本章目标：把"每次临时拉一队人"升级成"一句话启动一支现成的队"。你会看到 3 套内置模板的完整拆解，以及模板背后的编排机制——它为什么能自动把上一步的产出喂给下一步。

27.1 从"召唤队友"到"固化队形"

第 8 章讲过怎么临时召唤一支 AI 团队。但如果你每周都要做同一类事，每次都要：

1. 想清楚要几个角色；
2. 一个个分配任务；
3. 手动把上一步的产出复制给下一步……

这套动作重复三遍以上，就该固化了。

团队模板要解决的就是这个：把"角色组合 + 分工顺序 + 交付物传递"打包成一个可复用的模板。

维度	临时组队	团队模板
启动方式	每次口头描述	一句话 / 一个按钮
角色配置	现场想	预置好
步骤顺序	你来盯	模板写死
产出传递	手动转述	自动注入
可复用性	低	高
适合	一次性复杂任务	周期性、有固定套路的工作

27.2 一个团队模板由什么组成

一套模板 = 角色表（roles） + 工作流（workflows）。

模板
├── 角色表 roles[]
│   ├── 后端架构师  ⚙️   (slotIndex 0)
│   ├── 快速原型师  ⚡   (slotIndex 1)
│   └── 现实检验者  🎯   (slotIndex 2)
│
└── 工作流 workflows[]
    └── 步骤 steps[]
        ├── ① plan      由角色 0 执行 → 产出 plan_doc
        ├── ② implement 由角色 1 执行 → 依赖 plan，产出 code
        └── ③ review    由角色 2 执行 → 依赖 implement，产出 review_result

两个细节值得注意：

• 角色有槽位（slotIndex），步骤通过 roleIndex 指向角色——所以"谁做哪一步"是设计好的，不是随机分配；
• 每个步骤有输出键（outputKey），后面的步骤可以直接引用。

27.3 三套内置模板

模板	分类	难度	角色数	步骤数	适合谁
软件开发标准流程	通用	进阶	5	5	要正经交付一个软件/系统功能
一人公司·做内容	通用	进阶	5	5	个人或小团队做内容运营
Codex + Claude Code 协作编程（极简版）	开发	中级	3	3	要快速验证一个技术想法

27.3.1 软件开发标准流程（5 角色 · 5 步）

这是最值得学的一套，因为它模拟的就是真实软件团队的交付链路：

步	步骤码	谁来做	产出	依赖
1	clarify	📦 产品经理	需求规格 spec	—
2	design	🏛️ 软件架构师	技术方案 plan	clarify
3	implement	👨💻 高级开发者	代码 code	design
4	review	👀 代码审查员	审查意见 review	implement
5	verify	🎯 现实检验者	验收结论 acceptance	review

它的流程逻辑是：

产品经理把需求问清楚（clarify）
   ↓ 需求规格自动传给架构师
架构师出技术方案（design）
   ↓ 方案自动传给开发者
开发者写代码（implement）
   ↓ 代码自动传给审查员
审查员挑问题（review）
   ↓ 审查意见自动传给检验者
检验者做最终验收（verify）

为什么这个顺序是"对的"？

因为它杜绝了两种最常见的返工：

• ❌ 需求没澄清就写代码 → 做得越快，废得越彻底
• ❌ 代码没审查就上线 → 出问题才发现没人复核

这套模板最大的价值不是"AI 帮你写代码"，而是它强迫你走完一个专业流程。哪怕你自己是资深工程师，借它跑一遍也能发现漏掉的环节。

补充：这套模板支持把产出真正落地成文件（materialize 模式）——最后的代码不是"聊天里的代码块"，而是写到工作区里的真实文件。

27.3.2 一人公司·做内容（5 角色 · 5 步）

这套非常适合个人创作者和小团队，它模拟的是一个内容公司的完整班底：

步	步骤码	谁来做	干什么	产出
1	ceo_position	🧭 老板/CEO	定内容方向与商业定位	定位 position
2	audience	🔍 用户研究员	分析目标读者在想什么	受众洞察
3	topics	✍️ 内容策划	出选题与内容框架	选题清单
4	script	🎵 编导	写脚本/文案	脚本
5	calendar	📱 运营	排发布节奏与分发	发布日历

它的精妙之处在于顺序：

先定方向（CEO 视角），再研究人（研究员视角），然后才是内容和排期。

对比一下大多数人的做法——一上来就想"这周发什么"，结果发了一堆没人看的东西。这套模板解决的不是"写不出来"，而是"写错了方向"。

它还支持变量注入：启动时你只填一句"我要做什么方向的内容"，这个变量会贯穿后面所有步骤。

27.3.3 Codex + Claude Code 协作编程（极简版）（3 角色 · 3 步）

最小可用的技术验证队：

步	步骤码	谁来做	任务模板
1	plan	⚙️ 后端架构师	做技术规划：实现思路、模块拆分、验收标准（输入：）
2	implement	⚡ 快速原型师	严格按规划与验收标准实现代码（输入：）
3	review	🎯 现实检验者	对照验收标准复核代码（输入： + ）

注意第 3 步的任务描述：它同时引用了第 1 步的验收标准和第 2 步的代码。

这就是模板的威力：审查者手里同时拿着"承诺"和"交付"，对照着看。 这在人工协作里往往做不到——因为没人记得把原始标准翻出来。

27.4 编排机制：模板为什么能自动接力

这一节稍微技术一点，但理解了它你就能改模板。

27.4.1 四个关键字段

字段	作用	例子
outputKey	这一步的产出叫什么名字	plan_doc、code、review_result
dependsOn	这一步要等谁完成	["plan"]
dependsMode	依赖怎么算满足	all（全部完成）
maxIterations	这一步最多重试几次	1

它们合起来实现了"接力"：

① plan 产出 plan_doc
② implement 的 dependsOn=["plan"] 满足 → 启动
   任务里写 {{plan_doc}} → 自动替换为第①步的实际产出
③ review 的 dependsOn=["implement"] 满足 → 启动
   任务里写 {{plan_doc}} 和 {{code}} → 两个产出都注入

27.4.2 变量注入：模板可复用的关键

任务文本里可以写占位符：

占位符	来源
、	你启动模板时填的
、	前面步骤的产出

这两种变量的区别非常重要：

• 前者让模板通用（同一个模板能做不同的内容）；
• 后者让步骤接力（不用你手动搬运）。

27.4.3 并发控制

工作流有一个 concurrency 字段，模板整体也有 maxConcurrent。

意思很简单：同时最多几个队友在干活。

• 设成 1 → 严格串行，一步接一步（结果最可控）
• 调高 → 允许并行的步骤同时跑（速度快，但要小心依赖关系）

实践建议：先用默认值，确认流程跑得顺了再调并发。 并行不是越快越好，顺序敏感的步骤并行反而会乱。

27.5 什么时候该做自己的模板

判断标准很简单——同一套"多人配合流程"你走了三次以上，就该固化。

你的情况	建议
一次性复杂任务	临时组队（第 8 章）
偶尔做、但流程固定	让队友记住分工即可
周期性 + 多角色 + 有固定交付物	✅ 做成模板
只是重复同一个单人动作	别做模板，做成 Skill（第 17 章）

常见的自建模板场景：

• 每周的行业情报汇总（研究员 → 分析师 → 编辑）
• 每月的经营分析（数据整理 → 财务模型 → 汇报 PPT）
• 客户提案（需求澄清 → 方案 → 报价 → 复核）
• 内容日历（选题 → 脚本 → 视觉 → 排期）

区分口诀：一个人反复做 → Skill；一队人按顺序做 → 团队模板。

27.6 本章练习

1. 跑一遍内置模板：挑"软件开发标准流程"或"一人公司·做内容"，用一个真实需求走完全程，留意每一步的产出是怎么传到下一步的。
2. 找你的固定套路：写出你工作里"至少三个人、按固定顺序、周期性地"要走的流程。
3. 设计你的第一套模板：只需写出三样——角色有谁、步骤有哪些、每步产出叫什么名字。剩下的可以交给我。

---

小结：团队模板把"人 × 顺序 × 产出"固化下来，让专业流程变成一键可复用的资产。你重复三次的协作方式，就值得变成一套模板——这是从"用 AI 干活"到"用 AI 组队"的分界线。