企业官网建设流程全解析

Subagent 工作流实战：我如何用"AI 实习生团队"把交付周期砍一半

上一篇《搞懂"上下文工程"和"Token 经济学"》里留了一句话：“Subagent 就是你的实习生。”

评论区炸了，问得最多的一个是：道理我懂了，但具体怎么落地？

这篇是系列第三篇，纯实战。我把过去三个月真实项目里跑通的 Subagent 工作流完整拆开：什么活该外包、怎么派活、实习生交上来的活怎么验收、以及踩过的一堆坑。看完今天就能用。

一、为什么单个 AI 会话干不了大活？

先回忆我们为什么要用 Subagent。一个主会话（下面叫"主对话"）有三个结构性缺陷：

1. 上下文污染：聊得越久，失败尝试、过期方案、无关探索堆得越多，模型被噪音带偏，表现断崖式下跌；
2. 注意力稀释：200K 窗口塞到 80% 时，模型对关键约束的遵守率肉眼可见地变差；
3. 串行等待：一个人干活，查资料和写代码只能排队来。

Subagent 的机制恰好对症：它是一个独立上下文的 AI 实例。主对话给它一段任务简报，它在自己的"房间"里烧自己的上下文干活，最后只把结论汇报回来。

用公司结构类比就是：

你 = CEO，只做决策和验收 主对话 = 你身边的 Chief of Staff，拆解任务、分派、汇总 若干 Subagent = 各部门实习生，各干各的，互不干扰

关键认知：Subagent 的价值不是"更强的 AI"，而是"上下文隔离 + 并行"。它的模型和你一样，但它烧的是自己的预算、污染的是自己的桌面。

二、什么活该派给实习生？一张分工表

不是所有活都值得外包。派活的判断标准就两条：这个活会产生多少"过程噪音"？结论和过程的可分离度高不高？

一条经验法则：预计产生超过 2000 token 过程输出、而结论不超过 500 token 的任务，一律外包。

三、派活的技巧：像给真实习生写工单

实习生干不好活，90% 是因为工单写得太烂。给 Subagent 的任务简报同理，我固定用四段式模板：

【背景】这个项目是 Vue3 + FastAPI 小程序，登录鉴权用 JWT。 【任务】找出所有前端调用用户信息接口的位置，确认哪些没有处理 401 过期跳转。 【要求】只调查，不改代码。报告格式：文件路径 + 行号 + 是否已处理。 【交付】500 字以内结论，超过说明你跑题了。

四个段落各司其职：

• 背景：实习生没有你脑子里的项目全景，必须给（但只给相关的）；
• 任务：一个简报只放一个目标，写两个目标 = 实习生只能干完第一个；
• 要求：明确"只读"还是"可写"，防止它自作主张改代码污染工作区；
• 交付：限定汇报长度是最重要的一条——不限制，实习生会把 3 万 token 的探索过程原样倒回你的主对话，隔离就白做了。

另一个实战技巧：并行派发独立任务。同一轮消息里把"后端接口实现"“前端页面开发”"测试用例补充"三个互相独立的简报同时发出去，三份工单同时开工，主对话只做汇总。串行 3 小时的活，并行往往 1 小时内收工。

四、验收：实习生的产出必须过"三道门"

这是全文最容易被忽略、也最救命的一节。

Trust, but verify.实习生的汇报说的是"它以为它干了什么"，不代表真干对了。我的三道门：

1. 跑测试：它说改完了？先跑一遍相关测试，绿灯才算数；
2. 抽查 diff：结论里提到的文件，随机点开 1~2 个亲眼确认改动存在且合理；
3. 警惕"顺手改"：明确查一下它有没有越权改动工单之外的文件（git diff --stat扫一眼），越界的改动一律要求回滚——今天敢顺手改一个文件，明天就敢顺手"重构"你的核心模块。

血泪教训：两个 Subagent 并行时，务必让它们负责互不重叠的文件。我曾经让一个写接口、一个写页面，结果它俩都"顺手"改了同一个路由注册文件，合并时冲突 + 逻辑互相覆盖，排查了半小时。规则很简单：一张工单圈定一片领地，领地之间只准通过"接口契约"说话。

五、完整实战：一个真实需求的 90 分钟

需求：给内部小程序加"操作日志查询"功能（数据范围全放开），涉及 DB 查询、后端接口、前端页面三块。

第 0 步｜主对话定契约（15 分钟）
不写代码，只产出方案文档：表结构、接口出入参、页面清单。这份文档就是三个实习生共同的"图纸"。

第 1 步｜并行派三张工单（并行执行）

• 实习生 A：按方案实现后端查询接口 + SQL 索引建议，交付 = 文件清单 + curl 自测结果；
• 实习生 B：按方案实现前端页面 + Mock 数据联调，交付 = 文件清单 + 交互说明；
• 实习生 C：探索现有代码里权限校验的写法（给 A/B 对齐用），交付 = 200 字结论 + 参考文件路径。

第 2 步｜主对话集成验收（30 分钟）
跑测试、过三道门、把 A 的接口接到 B 的页面上。发现 B 的 Mock 字段和 A 的实际返回有两处对不上——因为两份交付物都在主对话里，冲突 5 分钟就定位了。

第 3 步｜收尾工单
把验收发现的问题打包成一张小工单派回去修，主对话继续保鲜。

账本：三个实习生的探索、试错、报错日志全部烧在各自上下文里；主对话自始至终只有"方案 + 结论 + 验收结果"，全程上下文不到 30K，零污染。同样的需求我用野生单会话方式做过一次：4 小时起步，且收尾时上下文 150K+，第二天迭代时 AI 已经开始犯失忆症。

六、翻车集锦：五个坑和对策

1. 实习生互相踩脚→ 工单圈定文件领地，跨领地只走契约；
2. 汇报注水（把过程日志全倒回来） → 工单里写死交付字数上限；
3. 它说"已完成"但其实没改→ 三道门验收，测试 + 抽查 diff；
4. 重要决策外包给了实习生→ 架构取舍永远留在主对话，实习生只提供情报不提供判断；
5. 为派而派→ 一行代码的活自己改，派活的 token 和时间成本比活儿本身贵。

七、把团队跑起来：三句话心法

1. 主对话是稀缺资产——只做决策、集成、验收，脏活累活全部外包；
2. 工单质量决定交付质量——背景/任务/要求/交付四段式，一条都别省；
3. 不验收的汇报等于没汇报——跑测试、看 diff、查越界，一道都别漏。

回头看这个系列的逻辑其实是一条线：

Skill 把"经验"封装成能力 → 上下文工程把"资源"用在刀刃上 → Subagent 把"产能"并行放大。

三件套齐了，你指挥的就不是一个 AI，而是一支有组织、有纪律的 AI 团队。

如果这个系列对你有用，点赞、收藏、关注三连支持下——系列持续更新，你的三连直接决定我下周先写哪篇。

下一篇二选一：A.《MCP + Skill + Subagent 合体：搭一套全自动发布流水线》；B.《AI 团队协作的度量：我用这 4 个指标评估 AI 产出质量》。评论区扣 A 或 B，人数多的先写。