Affirm 工程效能高级总监 Daniel Martin 在 Affirm Tech Blog 复盘了他们如何用一周——内部称 AI Retooling Week——把一个 800 人的工程组织整体推上 agentic 工作流，从需求到提交 PR 全程跑通。核心问题：当已经有几十个工程师被 agentic 工具彻底改变工作方式、并和其余 800 人快速拉开差距时，怎么把这套方式规模化到整个组织。

出发点：差距正在拉大，不能慢慢来#

到 2025 年 12 月，Affirm 已经有 80% 以上的工程师每周在用某种 AI 辅助工具。但真正让他们下决心的是另一件事：随着 Anthropic Opus 4.5 这类模型把"搜代码 → 规划 → 写代码 → 跑测试 → 自己修"这条链路打通，已经有几十个工程师在用 agentic 工具，并且工作方式被彻底改变了——

那几十个用得很好的人，和剩下 800 个人之间的差距，正在快速拉大。

他们选择"集中一周"而不是"慢慢铺开"，本质是一个 forcing function（倒逼机制）：靠自愿、靠"有空就试试"很难迈过那道坎。1 月中旬公司总裁发了一封全员信，把 agentic 开发定为"今后怎么造软件的核心方式"，并定下 AI Retooling Week 的日期：那一周暂停所有非必要会议、推迟交付日期，要求每个工程师和经理都跑通一条完整的 agentic 工作流——从需求到提交 PR。

一周之前：九个人先把"地基"打好#

Retooling Week 之前，他们组了一个九人工作组，任务很明确：两周内产出一条可复制的 agentic 工作流，让普通工程师不需要专家知识、不需要定制配置就能自动化掉大部分编码工作。

这个工作组定了三个决定，后面所有事情都建立在这三条上：

  1. 单一默认工具链——选定 Claude Code 作为默认 agentic 编码工具，整套工作流就照着它的原语来写，让工程师第一天就有明确起点。
  2. 本地优先（local-first）——因为当时业界还没收敛出统一的中心化平台，他们要让人立刻就能干活，而不是等平台。
  3. 显式的人类检查点——在"提供意图、批准计划、评审代码、合并"这几个判断真正重要的环节保留人，其余能安全去掉的杂活尽量自动化。

文章强调，“默认"不等于"强制”。默认的意思是"降低上手摩擦"，而不是"只准用这个"。偏好别的工具的人，可以复用大部分同样的产物，只做轻量翻译；默认方案不合适的地方，由各团队的 Tech Lead 负责适配。

他们教给大家的心智模型简单且与工具无关：Plan → Review → Execute → Verify → Review → Deliver。

那条工作流：一个任务 = 一次 agent 会话 = 一个 PR#

工作流的核心原则是 one task = one agent session = one PR。关键洞察是把决策往前移：与其在实现阶段反复和 agent 拉扯，不如在规划阶段就把架构和范围决策定下来，然后把一个边界收得很紧的任务交给 agent。这样工程师就能在多个独立的 worktree 上并行推进多个任务，每个都是自包含的工作单元。

他们给每个环节都做了定制工具：

  • Plan（规划）——一个 agent 辅助的规划 skill，把需求转成结构化的实现计划，并拆成边界清晰的小任务。
  • Review（评审计划）——工程师在写任何代码之前先评审并批准计划。
  • Execute（执行）——agent 在一个专用 worktree 上实现单个任务。
  • Verify（验证）——agent 跑测试和 linter，自己修，自己 review 自己的代码；CI 挂了就去拉构建日志、关联失败、提出修复，这个循环一直到 CI 通过。
  • Review（评审代码）——工程师评审并修改 agent 的产出。这里有一条他们写得很死的规矩：绝不把没人 review 过的 AI 产物丢给同事。 评审者也用 agent（把 review 工具指向 PR，再喂上团队的架构上下文），但人要真的读代码、用自己的判断、抓 agent 漏掉的东西。
  • Deliver（交付）——拿到人工批准后合并。

支撑这一切的，是一套分布在代码库多个层级的 context 文件：约定、领域知识、团队决策，都放在 agent 能找到的地方。工具本身通过一个内部插件分发，配一个中心化的 marketplace，让各团队自己造、自己共享 skill。

这一周里发生了什么#

整周的安排是"学和做"两头平衡：

  • 周一：领导层 kickoff + 在真实任务上现场演示完整工作流。
  • 周二：“art of the possible” 专场（线上线下都有），让大家看工具在真实任务上跑。
  • 周三：埋头干（heads-down）。
  • 周四：各团队自己的 demo。
  • 周五：重头戏——全组织范围的 demo，由工程负责人挑出本周最佳、全员投票。

整周还按时区配了专门的支持频道、开了 helpdesk、维护了一个各团队 agentic PR 提交量的排行榜。他们明确告诉大家"进展会参差不齐、有些代码库和任务会更难，请互相多给点宽容"，强调实验优先于完美。

钱也算得很细：这一周的 token 预算定在接近 20 万美元（约 250 美元/人），每天盯花销、查异常模式，最后落在预算的 70% 左右。结果是——92% 的工程组织（含经理）至少提交了一个 agentic PR，大多数人不止一个。

他们撞到的坑#

作者把这一周的产出分成两类：一类是采用率和 PR 数量，另一类是关于"什么不 work"的问题清单。几个瓶颈比较集中：

  • 变更评审（code review）是头号瓶颈。 在全员调查里，约 40% 的人没被问就主动提到它。PR 经常一卡好几天，量一上来，人工 review 直接成了堵点。
  • CI 的速度和可靠性是大约束。 单测套件 p75 大约 8 分钟，但跑在 ephemeral 测试环境上的全量端到端回归要 100 分钟以上——这套东西根本不是为 agentic 开发那种"改—验—修—再验"的高频循环设计的。
  • 工具集成带来意料之外的摩擦。 工程师想把 agent 接到几十个内部系统（一堆 MCP），但中心化管理这些集成是安全硬要求，请求量直接压垮了审查流程；而且CLI 在很多场景下比 MCP 更可靠——缺了标准化配置、归属和 SLA，本该让 agent 更强的集成反而成了拖累。
  • 文档可达性卡住进度。 Affirm 十多年的技术和产品 spec 散在多个文档平台和代码里——人能勉强导航，但 agent 需要清晰、合并好的上下文才能产出高质量结果。
  • 缺了快速的本地验证，大家就把 CI 当信号源。 足够多的 agent 在短时间内连续提 PR，Buildkite 的压力被推高、排队时间暴涨；Retooling 之后几周的一次，负载甚至搞挂了内部的 test quarantine 服务和 CI 流水线。

作者把这一切总结成一句话：

Agentic coding amplified every existing friction point in the development pipeline.

当代码生成几乎是瞬时的，原本可以被流程吸收的人工评审、不可达的文档、薄弱的本地测试、缓慢的 CI，都会变成更明显的系统瓶颈。换句话说，agentic 开发不会凭空制造新问题，但会放大流水线里已有的摩擦点。

他们怎么补这些洞：context、enablement、validation#

Retooling Week 结束后，他们带着一张清晰的问题清单和"组织上想修"的意愿，启动了一个专门的项目，分三个方向：

1. Context：把最佳实践集中到 agent 找得到的地方#

让 agent 从更好的输入开始。如果架构决策、领域上下文、最佳实践都存放在 agent 在实现之前就能找到的位置，产出质量会上去、评审负担会下来。这块由架构组牵头。

2. Enablement & Governance：把临时小队变成常设团队#

他们把跑 Retooling Week 的那个 sprint 小队转成了常设团队。职责是在采用规模变大时让工具链保持健康：管集成、提升工具的可发现性、建支持模型、搞清楚钱花在哪、花得值不值。

3. Validation：最大的一笔投入#

作者明说验证是最大的投入——agent 能快速产出代码，但只有当你能又快又有效地验证它时这才有意义。具体在做几件事：

  • 先治 CI 噪声：构建挂了，要立刻知道是你的代码、flaky 测试、还是基础设施问题。他们在自动化这个分类，让 agent（和人）不用翻日志就能行动。
  • 把本地测试做厚，让信号在进 CI 之前就给出来。
  • 给测试套件"瘦身/分层"，让大部分覆盖落在离代码更近、更快更便宜的层上。
  • 给 agent 生成的代码做独立验证：当 agent 在同一次会话里同时生成实现和测试，对需求的一个误解会让代码和测试互相印证彼此的错误——测试全绿、覆盖率好看，但缺陷照样发布。他们在试点一个系统，用 PR diff 去交叉比对验收标准，并用多个模型做独立检查。

这条"实现和测试同源会互相背书"的失效模式，是整篇里很锐利的一个观察。

文章总结的几条经验（What We’ve Learned）#

文章结尾把这一周的经验收成几条：

  • 倒逼机制有效（forcing functions work）。 暂停会议 + 领导背书的一周，比几个月的渐进铺开带来的采用更多。它给了工程师专注学习的空间，也给了整个组织一个共享的基线。
  • Enablement 团队和工具一样重要。 一群有热情的工程师铺好"paved path"、值守支持、实时迭代反馈——没有这个团队，就回到了"发个工具、贴篇 wiki、然后听天由命"。
  • 选一个工具，把工作流照着它写。 工程师需要明确答案：用哪个工具、好的工作流长什么样、从哪开始。给出这些答案（同时给团队留适配空间）是杠杆最高的决策之一。
  • 要盯住二阶问题。 一阶效果是写代码变快了，但规模化 agent 写代码会引入会不断累积的二阶失效模式：代码库膨胀、评审与发布瓶颈、skill 和 context 泛滥、以及人对系统理解的退化。
  • 文化决定上限。 领导层的信念、明确的预期、敢于实验的心理安全感、以及对结果清晰的问责——这些才是让工程师愿意改变工作方式的前提。

结果：四个月从近乎零到 60%#

  • 截至 2026 年 4 月，Affirm 超过 60% 的 PR 是 agent-assisted——作者补了一句"meaning very likely entirely written by Claude（很可能完全由 Claude 写）"，而这在四个月前还几乎是零。
  • 每周合并的 PR 量同比增长 58%，还在涨。

作者对时间窗的判断：

The window to retool is now open, while the models are capable and the costs are low. That window will not stay open forever.

几点笔记（个人观点）#

把这篇当作我们项目落地 AI 编码的参考，筛出这几条可操作的 takeaway：

  1. 用一个倒逼机制破冰，而不是渐进铺开。 可以是缩小版的"retooling 半天/一天"：暂停部分会议，要求每个人跑通一条 task → PR 的完整 agentic 流程，结尾搞一场 demo + 投票。共享基线比个别高手重要。
  2. 先组个小工作组，两周内产出一条"可复制的默认工作流"。 选定一个默认工具，照它的原语把 Plan → Review → Execute → Verify → Review → Deliver 写成文档 + skill；默认不等于强制，给团队留适配口子。
  3. 把决策前移、一个任务一个 PR、用 worktree 并行。 别在实现阶段和 agent 拉扯，规划阶段把范围钉死——真正的杠杆在实现之前，而不是实现之中（这点和 prompt-driven vs spec-driven 的判断一致）。
  4. 提前把"被放大的旧伤口"列出来排期。 几乎可以照抄 Affirm 的清单：人工 review 是不是堵点、CI/回归套件多久、本地验证够不够快、文档 agent 能不能读、内部集成有没有 owner 和 SLA。 这些不修，agentic 只会把它们一起放大。
  5. 把"实现和测试同源会互相背书"当成一类专门的质量风险。 至少做到验收标准与实现分开来源，让 review（人或独立 agent）拿验收标准去比对 diff，而不是只看"测试是不是绿的"。
  6. 保留人类检查点 + 一条铁规：不把没 review 的 AI 产物丢给同事。 几乎零成本，但能挡住大量低质量 PR 冲击评审。
  7. 把临时推动小队转成常设的 enablement 团队，否则热度一过就回到原点。

也保留几分怀疑（参考 Hacker News 上的讨论）：

  • “60% agent-assisted” 的口径偏宽——agent 参与过就算，离"一次成型、不靠反复人工 review 的生产代码"还有距离，别被百分比迷惑。
  • AI 代码常常"看起来能干、实则暗藏微妙 bug"，这正是 Affirm 把 validation 列为最大投入的原因；既没有像样的本地测试、也没有独立验证的组织，把这套推上去反而更危险。
  • 金融这类强约束行业，guardrail 的投入要和提速的投入同步，不能只追采用率。

我的取舍：值得抄的是"组织怎么动"——倒逼机制、默认工具链、enablement 团队、把旧伤口列清单去修；而那几个亮眼数字（60%、58%）更适合当方向，而不是当 KPI 直接压下去。先把验证和评审这两条腿养壮，再谈提速，才不会把"看起来很快"变成"实际很脆"。其中"二阶问题"里的**“人对系统理解的退化”**，和 读 Anthropic《AI 如何影响编程能力的形成》是同一条线，可以放一起看。

参考资料#