2026 年 2 月，Affirm 做出了一个大胆的决定：暂停正常工程交付一周，让超过 800 名工程师使用 Agentic AI 工具完成从需求到代码审查的全流程。到 2026 年 4 月，其超过 60% 的 Pull Request 已由 Agent 辅助生成，周均合并 PR 数量同比增长 58%。这一案例不仅展示了金融科技企业在高合规要求下推进 AI 落地的可行性，更揭示了 Agentic 开发模式对现有工程基础设施带来的结构性挑战。
实施背景与动机
Affirm 运行着一个年处理 1.3 亿笔交易的信用网络，业务规模持续扩大的同时，工程交付能力面临多重约束。作为处理真实资金的金融平台，代码质量具有合同级别的非违约要求；同时，其基于十二年历史单体代码库的开发流程存在多项结构性瓶颈：测试套件臃肿、代码审查依赖人工、CI 管道不稳定、部署基础设施无法匹配所需交付节奏。
在 2025 年期间，Affirm 的开发者生产力团队已投入 AI 辅助开发，到 12 月超过 80% 的工程师每周使用 AI 辅助开发工具。然而，新一代模型（如 Anthropic 的 Opus 4.5）使得 Agentic 开发跨越了实用门槛：编码 Agent 可以可靠地搜索代码库、规划方案、编写代码、运行测试并在失败时迭代修正。数据显示，数十名工程师已有效使用这些工具，但如何将这种效率提升扩展到另外 800 名开发者成为关键问题。
2026 年 1 月中旬，Affirm 总裁发出全员消息：Agentic AI 开发将成为核心开发方式，并设定了具体的重新工具化周（Retooling Week）。所有非必要会议暂停，产品交付日期推迟，每位工程师和管理者需在周末前完成一个完全 Agentic 的工作流 —— 从任务到提交的 PR。
前期准备：三项关键决策
在重新工具化周之前，Affirm 组建了一个九人工程师工作组，其使命是在两周内构建一个可重复的 Agentic 工作流，使普通开发者无需定制化设置或专业知识即可自动化大部分编码工作。工作组做出了三个关键决策，塑造了后续所有实践。
第一项决策是采用单一默认工具链。Affirm 选择 Claude Code 作为默认 Agentic 编码工具，并围绕其原语构建完整工作流，为工程师在第一天提供明确的起点。尽管这被定位为 “默认” 而非 “强制”，但它显著降低了入门门槛。偏好其他工具的工程师可以在轻度适配后复用大部分相同组件，Tech Lead 负责为团队处理不适用默认工具的场景。
第二项决策是本地优先开发。由于工具领域尚未收敛到集中式平台，团队选择让工程师在本地环境中立即产生生产力，避免等待集中式平台就绪的延迟。
第三项决策是设置显式的人工检查点。团队明确识别了需要人类判断的环节：提供意图、审批方案、审查代码、合并代码。除这些检查点外，尽可能安全地自动化苦差事。这一设计理念被概括为简单且工具无关的心智模型：计划（Plan）、审查（Review）、执行（Execute）、验证（Verify）、审查（Review）、交付（Deliver）。
工作流设计：六阶段方法论
Affirm 构建的工作流遵循一个核心原则：一个任务等于一个 Agent 会话等于一个 PR。关键洞察是将决策提前 —— 不是在实现时与 Agent 来回交互，而是在规划阶段就完成架构和范围决策，然后将高度聚焦的任务交给 Agent。这使得工程师可以通过独立的 Git Worktree 并行处理多个任务，每个任务都是一个独立的工作单元。
工作流各阶段有明确的工具和检查机制。计划阶段使用 Agent 辅助规划技能，将需求转换为结构化实施计划并拆分为良好范围的任务。审查阶段由工程师审核并批准计划，确保方向正确后再进入编码。执行阶段在专用 Worktree 上实现单个任务，Agent 获取相关代码上下文后生成实现。验证阶段Agent 运行测试和 Linter，修复发现的问题，审查自身代码。当 CI 失败时，Agent 获取构建日志、关联失败并提出修复方案，此循环重复直到 CI 通过。审查阶段由工程师审查和编辑 Agent 输出。Affirm 明确设定了一条规则：不要将未经审查的 AI 输出发送给同事。审查者也使用 Agent 工具，将审查工具指向 PR 及其团队架构上下文，但必须自行阅读代码、运用判断并捕获 Agent 遗漏的问题。交付阶段在获得人工批准后合并代码。
在此基础上，Affirm 在代码库多个层级维护上下文文件：约定、领域知识和团队决策，Agent 可以在其中找到这些信息。工具通过内部插件分发，设有中央市场，团队可以构建和分享自己的技能。
执行过程与组织保障
重新工具化周的日程设计平衡了学习与实践。周一开场为领导层 kickoff 和全流程实时演示。周二举办 “可能性艺术” 现场和远程演示，工程师可以看到工具在实际任务上的表现。周三为专注时间。周四为团队主导演示。周五为大型展示：由工程领导者选出的本周最佳作品进行全组织演示和投票。
组织保障方面，团队按 timezone 设立专门支持通道，运行帮助台会议帮助受阻工程师，并跟踪各团队的 Agentic PR 提交排行榜。团队承认进度会参差不齐，某些代码库和任务类型会更困难，因此要求团队相互给予宽容，强调实验而非完美。
资金投入方面，Affirm 为该周设置了接近 20 万美元的预算（约每位工程师 250 美元），每日监控支出，调查异常模式，最终支出约为预算的 70%。到周末，92% 的工程组织（包括管理者）提交了至少一个 Agentic PR，大多数人提交了多个。
暴露的工程瓶颈
重新工具化周产生了最宝贵的输出：一幅关于什么不 work 的坦诚画像。多项瓶颈浮出水面。
变更审查流程是工程范围调查中单点提及最多的摩擦点，约 40% 的受访者主动提出。PR 经常在此阶段停留数天，随着数量增加，人工审查流程成为瓶颈。CI 速度和可靠性是主要约束。p75 单元测试套件运行时间约 8 分钟，但完整端到端回归套件在临时测试环境上需要超过 100 分钟。这种设计无法满足 Agentic 开发所需的变更 - 验证 - 修复 - 再验证循环。工具集成产生意外摩擦。工程师希望将 Agent 连接到内部系统，需要数十个 MCP（Model Context Protocol）。集中管理这些集成是安全要求，但请求数量淹没了审查流程。每个新集成都扩展了需要仔细评估的安全表面。CLI 在许多任务上被证明比 MCP 更可靠，但缺乏标准化配置、所有权和服务水平协议，本应增强 Agent 能力的集成反而成为拖累。文档可访问性阻碍进展。Affirm 超过十年的技术和产品规范分布在多个文档平台和代码中。这种碎片化对人类尚可 navigable，但 Agent 需要清晰、整合的上下文才能产生质量输出。部分平台有 MCP 集成，部分没有，体验不一致导致工程师频繁需要手动填补空白。本地验证不足导致 CI 压力。没有快速本地验证，工程师将信号推送到 CI。足够多的 Agent 快速提交 PR 增加了 Buildkite 压力，导致队列等待时间延长。重新工具化周数周后，一次负载导致内部测试隔离服务和 CI 管道宕机。
根本结论是：Agentic 编码放大了开发管道中每一个现有的摩擦点。当代码生成接近即时时，人工审查、难以获取的文档、弱的本地测试和缓慢的 CI 从开发者会容忍的烦恼变成了阻碍因素。
后续改进方向
重新工具化周后，Affirm 启动了专门的计划来弥合这些差距，重点聚焦三个领域：上下文、赋能和验证。
在集中上下文与最佳实践方面，团队希望 Agent 从更好的输入开始。如果架构决策、领域上下文和最佳实践在实现开始前就存储在 Agent 可以找到的地方，输出质量会提升，审查负担会降低。架构组正在领导这项工作。
在赋能与治理方面，运行重新工具化周的 sprint 团队转变为永久团队。他们的职责是随着采用增长保持工具健康：管理集成、改善工具可发现性、构建支持模型、确保理解支出来源并验证支出是否产生价值。
在Agent 友好的持续集成方面，验证是最大投资领域。Agent 可以快速产生代码，但只有能快速有效地验证才有意义。首要解决的是 CI 噪声问题：当构建失败时，工程师需要立即知道是代码问题、不稳定测试还是基础设施问题。目前这需要人工调查。团队正在自动化该分类，使 Agent 和人类可以在不翻阅日志的情况下对失败采取行动。同时正在成熟本地测试，为 Agent 和工程师在任何内容到达 CI 前提供信号。还在合理调整测试套件，使大部分覆盖率存在于更快、更便宜的代码近端层。
一个特别值得关注的问题是 Agent 生成代码的独立验证。当 Agent 在同一会话中生成实现和测试时，对需求的误解可能产生相互确认错误的代码和测试。测试通过，覆盖率看起来不错，但缺陷已发货。团队正在试点一个系统，将 PR 差异与验收标准和多个模型进行交叉引用作为独立检查。
可落地参数与监控要点
从 Affirm 案例中提取的可落地工程参数包括：每位工程师 250 美元的单周 Token 预算基准；目标是在一周内实现超过 90% 的组织采用率（含管理者）；CI 管道需支持 p75 端到端测试在 30 分钟以内完成，否则应分层测试策略；MCP 集成审查需在 48 小时内完成，否则成为采用阻碍；本地 Worktree 并行度建议控制在 3-5 个任务以避免资源竞争。
关键监控指标应包括：Agentic PR 占比（目标 >60%）、周均 PR 合并量同比增长（Affirm 报告 58%）、Token 消耗速率与预算比率、各工作流阶段的通过率与回退率、CI 队列等待时间变化。金融科技场景下的特殊监控点包括：代码审查通过率中的 Agent 生成代码占比、测试覆盖率在引入 Agent 前后的变化趋势、安全扫描在 Agent 生成代码上的误报率。
经验总结
Affirm 的案例验证了多个关键原则。强制函数有效：带有暂停会议和领导层支持的专门一周在五天内创造的采用率超过数月渐进式推广。赋能团队与工具同样重要：热情的工程师团队构建 paved path、配备支持、在反馈上迭代，仅给出工具访问和 Wiki 页面是不够的。选择单一工具并围绕其构建工作流：工程师需要清晰答案使用什么工具、良好工作流什么样、从哪里开始，同时为团队留出适配空间。警惕二阶问题：扩大 Agent 生成代码的规模引入了随时间复合的失败模式：代码库膨胀、审查和发布瓶颈、技能和上下文蔓延、对运营系统的人类理解侵蚀。文化设定上限：领导层信念、明确期望、实验心理安全和对结果的清晰问责创造了工程师愿意改变工作方式的条件。
Agentic 开发现已永久改变 Affirm 构建软件的方式。窗口期正在打开，模型能力足够且成本较低，这个窗口不会永远开放。提前行动的企业将保持领先，等待者将被超越。
资料来源：本文核心事实与数据来自 Affirm 高级工程总监 Daniel Martin 在 Affirm Technology Medium 博客发布的《How Affirm Retooled its Engineering Organization for Agentic Software Development in One Week》，该文于 2026 年 4 月 23 日发布，详细记录了 2026 年 2 月的重新工具化周实施过程、遇到的问题及后续改进方向。