个人外挂很爽，团队一上就翻车——交付侧要把验证权拿回来
现场记录 · 腾讯云架构师城市沙龙·深圳 2026-07-18
分享：储诚益（MenuSifu 架构总监 / 合肥同盟）·《AI Coding Agent：从个人外挂到团队生产力》
角色视角：老李 · 架构师 / 研发 Leader —— Harness 先在编码交付侧立住，再复制到业务变更链路
封面：外挂到生产力，中间隔着一整套护栏
一个人爽，不叫组织能力。
上午讲「数字员工本体与编排」；这场储诚益几乎不聊 IDE 选型，直接问：AI 很快但不靠谱，团队怎么把偶发成功变成必然结果？
老李要的答案很具体：编码交付流水线先可控，业务系统改库、改接口时才能套同一套门禁，而不是每人一个外挂。
一、痛点：代码量起飞，Review 成考古
周五下午的 PR，谁看谁崩溃。
| 挑战 | 表现 | Leader 体感 |
|---|---|---|
| PR 效率 | 代码量激增，Review 变慢 | 考古式 Review 更狠 |
| 上下文 | 逻辑分散 | Agent 改五文件，人要读十文件 |
| 心智模型 | 工具复杂 | 新人不知道听哪份规矩 |
| 质量底线 | 关键审查被淹没 | 鉴权漏了才发现「AI 写的也能合」 |
AI 是概率引擎：意图漂移、上下文割裂、「假自洽」。瓶颈从执行翻到构思与设计。极客暴力撞上机器暴力——锅在人身上。
四不对称：速度、语义、信任、状态。人类持意志与问责；AI 不背结果。
小结：个人拼 Prompt；团队拼有没有人敢说——验证权不能交给模型。
二、是什么：交付侧五层护栏（别和上午六层混读）
提效归模型，可交付归纪律。
心法：AI 负责提效，护栏负责可交付。
| 层 | 职责 | 研发落地 | 辐射业务时 |
|---|---|---|---|
| Context | 绑定意图 | 唯一规则真源 + 任务卡 | 业务变更单同样写清边界 |
| Tools | 统一工具 | 白名单脚本/连接器 | 业务工具也走白名单 |
| Guardrails | 拦截熔断 | 写入须审批 | 生产变更熔断同构 |
| Verification | CI/测试/人审 | 验证权在人 | 业务验收脚本进流水线 |
| Observability | PR/ADR/案例账 | 成败可复制 | 业务事故可复盘 |
上午是「本体 + 元技能」视野；这场是编码与交付流水线。两套图不要硬揉成一张 PPT。
三、为什么用：5800 PD → 704 PD
数字比口号硬。
商品中心重构：10+ 年老系统、467 功能点、7 人 4 个月。5800 PD → 704 PD，约 8 倍。 靠多 Agent 编制 + 护栏，不是换模型。
决策域 Orchestrator + 产品/设计/架构等 Agent；实施域前端/Java/DB/QA/文档——镜像真人编制。单体 Agent 包打天下，否。
老李立刻想到：自家中台有外挂，缺编排器，缺案例账。业务侧若上「数字员工改配置」，没有同一套 Verification，等于把外挂直接捅进生产。
适合：存量加功能、跨模块重构、规范进版本库。
不适合：需求糊成团、一次性脚本、禁止 AI 碰的高安全模块。
四、架构：案例账 → Playbook → 闭环改进
成功要能抄作业，失败不许二刷。
Good/Bad Case → 案例账 → Playbook → 团队学习能力
控制平面（SICA Runner 一类）：反馈 → 失败分析 → 沙箱改进 → 策略与硬门控 → 受控应用 → 循环学习。
三原则：成熟经验复刻；模型出方案、落地靠交付；错误不重蹈。
五、最小团队护栏（今晚就能排期）
不买新平台，也能先立规矩。
项目根/
├── 项目宪法.md # 唯一规则真源
├── 构建验证说明.md # 测什么、怎么算过
├── 场景规则/ # 切片，禁止第二套真源
├── 案例账/ # 成败各写一条
└── scripts/
└── check-rules.sh # CI：规则文件在且含禁止项
PR 人审四项死磕：鉴权、事务边界、幂等、日志脱敏。风格交给静态检查。
六、实战：交付七步（业务变更可同构）
流程长一点，返工少一半。
- 任务卡写清改什么 / 不改什么 / 验收
- 长链路 Agent 按宪法跑大改造
- IDE 精修关键路径与鉴权
- 本地全量测试——AI 代码无豁免
- PR 标注 AI 参与范围与人工修改比例
- CI + 人审四项边界
- 合并后写案例账一条
业务系统「改配置 / 改规则」也可以套 1→6→7，只是工具换成业务连接器。
七、洞见三条
洞见 1：验证权是人权
让 Agent 自评后合并——三个月内等事故。
洞见 2：度量 Cycle Time 与缺陷率，别考核行数
现场 8 倍提效，分子是功能点交付，不是 token。
洞见 3：个人外挂的终点是 Playbook
外挂经验进案例账，才算组织资产；否则 Leader 永远在救火。
八、总结
先把交付侧纪律立住，业务侧才接得住。
| 阶段 | 特征 | Leader 动作 |
|---|---|---|
| 个人外挂 | Prompt 在聊天里 | 允许探索 |
| 规则对齐 | 真源进版本库 | 禁三套规矩 |
| 五层护栏 | 验证权在人 | CI+人审 |
| 团队生产力 | 案例账→Playbook | 组织学习 |
| 辐射业务 | 变更链路同构 | 业务验收进门禁 |
方法论速查表
| 维度 | 做法 | 反模式 |
|---|---|---|
| 规则 | 一份真源 | Wiki/聊天/工具三套 |
| 分工 | 长链路+精修+补全 | 三人三制 |
| 门禁 | CI+人审四项 | 只跑编译 |
| 度量 | Cycle Time/缺陷/违规 | 考核行数 |
| 资产 | 案例账→Playbook | 经验进个人笔记 |
行动号召： 下一个 AI 参与的 PR，必须留一条案例账。没有账，就没有团队生产力。
现场印证问答
Q1：统一规则扼杀创造力？
扼杀的是风格混乱。创造力该花在构思与设计，不是救 AI 埋的雷。
Q2：多工具是不是浪费？
浪费的是多工具却共享不了 Context / Verification / 案例账。
九、金句提炼
| # | 金句 | 老李怎么用 |
|---|---|---|
| 1 | AI 很快，但也很不靠谱——偶发成功如何变必然结果？ | 交付门禁的命题句 |
| 2 | 验证权不能交给模型 | PR/上线否决权在人 |
| 3 | AI 负责提效，护栏负责可交付 | 分工写进流程，不写进口号 |
| 4 | 人机四不对称：速度 / 语义 / 信任 / 状态 | Review 重点盯这四项错位 |
| 5 | 5800 PD → 704 PD（约 8×） | 用功能点交付谈提效，别用行数 |
| 6 | Good/Bad Case → 案例账 → Playbook | 个人外挂变组织资产的路径 |
| 7 | 模型出方案，落地靠交付 | Agent 产出 ≠ 可合并 |
| 8 | 没有案例账，就没有团队生产力 | 合并必留痕 |
十、概念与工具速查
| 概念 / 工具 | 完整定义（简述） | 常见种类 / 同类工具 |
|---|---|---|
| AI Coding Agent | 能多步读改代码、跑命令、开 PR 的编程助手，区别于单行补全 | 长链路终端型：Claude Code、Codex CLI、Aider、Cline；IDE 结对型：Cursor Agent、Windsurf；补全型（非完整 Agent）：GitHub Copilot、Tabnine |
| 交付侧五层护栏 | Context→Tools→Guardrails→Verification→Observability，把概率产出关进可交付流水线 | 与「数字员工六层」不同构：这边偏 CI/PR/案例账，那边偏 本体/MetaSkill |
| Context（意图绑定） | 让 Agent 加载同一套意图与规矩的真源配置 | 项目宪法、任务卡、Issue 模板；工具侧 rules / instructions 文件 |
| Guardrails | 权限、拦截、高危熔断，防止 Agent 越权写入 | 审批 elicitation、分支保护、密钥只读、路径白名单 |
| Verification | 用测试/静态检查/人工审查判定「能不能合」 | CI：GitHub Actions、GitLab CI、Jenkins；质量：SonarQube、Checkstyle、单测/集成测 |
| Observability（交付侧） | 让一次 Agent 运行可回放、可审计 | PR 描述、ADR、案例账、构建日志；平台级再叠加 OpenTelemetry |
| Playbook | 从成败案例沉淀的可复用操作手册 | 运维 Runbook、事故复盘模板、Agent 成功路径清单 |
| SICA Runner（现场称谓） | 反馈→分析→沙箱改进→策略门控→受控应用的闭环控制平面 | 同类思路：评测台 + 沙箱回归 + Policy as Code（OPA）+ 受控发布 |
| Orchestrator / 多 Agent 编制 | 用编排器拆分产品/设计/架构/实现/QA 等角色 Agent | LangGraph Supervisor、CrewAI、AutoGen、企业自研编排器 |
| Cycle Time | 从工作项创建到合并主干的时长 | 同类度量：Lead Time、变更失败率、MTTR（DORA 四指标家族） |
| ADR | Architecture Decision Record，架构决策一页纸记录 | 工具：adr-tools、Markdown 仓库约定；同类：RFC、设计评审纪要 |
| PD（人天） | Person-Day，估算/核算工作量单位 | 同类：Story Point（相对）、工时（绝对） |
十一、小结：模型之上的工程与架构
怎么理解这场。 编码场景里，「模型之上」落在交付流水线：Context 绑意图、Tools 收工具面、Guardrails 熔断、Verification 拿回验证权、Observability 让成败可抄作业。架构不是选哪个 IDE，而是把个人外挂收编成组织护栏——多 Agent 按真人编制拆分，案例账滚成 Playbook，偶发成功变成可预期交付。
收获提炼。
- 验证权是人权，不能交给模型自评后合并。
- 提效看 Cycle Time 与缺陷率，别考核代码行数；现场 8× 是功能点账。
- 个人外挂的终点是 Playbook，合并必留案例账。
- 业务变更链路可同构五层护栏：同一套门禁语言，从研发 PR 复制到生产变更。
现场照片：
images/2/raw/raw_*.png（原图全量嵌入正文）
关键数据：商品中心 5800 PD → 704 PD（约 8×，演讲者现场披露）