如何给公司做AI赋能-- 任务拆解与协作:Work from small——当团队里既有人、也有 agent
目录
《给公司做 AI 赋能》系列第 3 篇
一个新问题:怎么给”不知疲倦但没有上下文”的队友派活
这一篇讲的经验有点特殊:它既来自我们在公司里带团队做 DE 平台整个 demo 的代码主体是由 AI agent 团队写出来的,我扮演架构师、调度者和唯一的集成者。六个里程碑、七个执行波次、数十次子任务派发,最后是一个带 55+ 测试、能在笔记本上端到端跑通的系统。
这次实验让我确信:**给 AI 拆任务和给人拆任务,底层原则是同一套——只是 AI 把你原本可以蒙混过去的管理债,全部变成了立刻爆炸的显性问题。**给人类派活时说”你看着办”,他会来问你;给 agent 说”你看着办”,它真的会看着办,然后你收获一个自信满满、方向全错的 PR。
先写规格,再写计划,最后写代码
demo 的构建顺序是:先有一座完整的规格文档库(约 4600 行,按层分目录:总览、脚手架、实例、技能、评估、桥接、控制台、运维),再有一份执行计划(build-plan),最后才开始产码。执行计划的开头就立了规矩:“按顺序完成里程碑;每个里程碑有显式验收标准;依赖未通过不得开工。”
每个里程碑长这样——以 M1(脚手架)为例,验收标准不是”脚手架可用”,而是五条可执行的检查:
- 对坏的
instance.yaml,validate报出字段级错误;对样例通过; - 一个 fixture 实例能构建出
runtime/,manifest 标注每个文件的来源; - 实例文件遮蔽基座文件 → 构建必须报
BuildConflictError; - 实例试图放宽基座权限 → 构建必须报
MonotonicityError; - 用一条注入攻击提示词管进 hook,exit code 必须是 2。
**验收标准写到”一条命令+一个期望输出”的粒度,是人机混编团队里最值钱的投资。**对人,它消灭了”我以为你要的是这个”的返工;对 agent,它直接就是可以自动跑的验收脚本。反过来说,如果一个任务你写不出这种粒度的验收标准,说明你自己还没想清楚——这个任务还不该被派出去,无论派给谁。
拆解的本质是定义边界上流动什么
任务能安全并行的前提,是把组件之间的**接缝(seam)**先钉死。我们的全局设计文档里有一节叫”接缝契约”,逐条固定了跨边界流动的一切:CLI 怎么调 builder(精确到命令行形态和退出码语义:0 成功 / 1 运行失败 / 2 用法错误)、构建产物长什么样(哪个 JSON、哪些字段、谁消费)、评估框架怎么认定”技能被触发”、桥接的 wire 协议(HMAC 放哪个 header、常数时间比较、先验签后解析)。
配套一张职责矩阵,每层不仅写”拥有什么”,还写**“绝不允许做什么”**:桥接层”不得解释策略、不得触碰实例仓库”;控制台”不得成为第二事实来源、不得原地编辑实例目录”;技能”不得持有写凭证”。
经验:**“must never do” 这一栏比 “owns” 那一栏更能防事故。**职责重叠通常只是低效,职责越界才是事故。这条对人类组织同样成立——只是我们很少好意思把它写进人的职责说明书里,而对 agent,你必须写。
波次执行:并行、串行,与”一个目录一个writer”
有了契约和验收标准,执行就可以排波次:能并行的并行(技能移植和 CI 门禁脚本互不触碰,同波派两个 agent),有依赖的严格串行(builder 没过验收,实例任务不开工)。demo 一共排了七个波次,对应六个里程碑,依赖图明确画出。
三条协作纪律,每条背后都有一次教训:
- **一个目录一个writer。**每个波次里,任何目录只有一个 agent 有写权;跨目录的共享文件(全局设计文档、顶层 README)只有集成者本人动。这是防止合并地狱最朴素也最有效的规则。
- **失败先诊断,再派发;子 agent 拿到的是”要应用的 diff”,不是”你去查查”。**早期我犯过懒:测试挂了直接把任务丢回给 agent”修一下”。它会重跑全链路、重读所有文档、大面积重构——烧掉可观的 token,还引入新问题。后来立规:集成者先定位根因,把修复描述成精确的变更,agent 只负责执行。开放式探索是调度者的工作,不是执行者的。
- **离线验收与在线验收分离。**大部分验收(lint、构建、单测)不消耗模型调用,随做随验;需要真实 agent 对话的验收(触发测试、端到端会话)被集中成三个”live batch”,一次性把 mock 全拉起来跑完。因为每次在线验收都烧真金白银的 token——完整跑一遍全部在线验收要几百个 agent 轮次。把贵的验证攒批跑,是 AI 时代新的工程成本意识。
边界拓展:偏差登记簿
demo 对完整规格做了删减(没有真正的密钥管理、CI/MR 是 mock、转录不外发),这很正常——所有工程都在删减。危险的不是删减,是不留痕的删减。我们的做法是一张偏差记录本:每条偏差编号(D1–D8),标注类别——simplified-for-demo(简化,方案已知)还是 deferred-with-note(推迟,并说明生产环境必须补什么)——并且最终 README 里的治理清单必须逐条回答这些偏差。
这个工具在公司项目里同样好用:立项时的目标和交付时的现实之间,永远有一条缝。用登记簿把缝变成清单,项目就保持诚实;藏起来,缝就变成惊喜。
集成者:人类在 agent 团队里的新岗位
整个实验里我最大的个人体感是角色变化。我几乎没写业务代码,但我做了所有这些事:写规格、切波次、写验收标准、诊断每一次失败、做每一次集成、跑每一个 live batch、维护偏差登记簿。传统 tech lead 的技能没有一项浪费——它们只是全部前移到了”代码产生之前”和”代码合入之时”。
如果你在为团队引入 agent 协作,我的建议是:**不要把 agent 当成更快的工程师,把它当成需要极清晰任务书的新同事。**你为它写清楚边界、验收和契约的每一分钟,都会以数倍的返工时间省回来。而且说到底——把任务的边界、验收和依赖想清楚再交给别人,对人类同事,难道不也是同样的尊重吗?我们只是终于遇到了一种不肯替我们兜底的队友。
本篇清单
- 你的任务有”一条命令+期望输出”粒度的验收标准吗?
- 组件的接缝契约写下来了吗?”绝不允许做什么”写了吗?
- 谁是唯一集成者?共享文件谁有写权?
- 贵的验证(在线 agent 验收)攒批了吗?预算算过吗?
- 范围删减有登记簿吗,还是靠记忆?