Anthropic分享：Agentic Coding研发实操指南

近期行业调研覆盖了15家大规模使用智能代码助手的科技企业，其中包括多家行业头部公司，有三家企业估值已超百亿美元，也是当前AI编程落地最积极的一批实践者。基于这些访谈，行业总结出了一套智能编程时代的研发实操指南，这套方法不仅适用于专用的AI编程工具，也可以迁移到其他同类智能开发辅助场景中。

研发流程的底层逻辑正在重构

传统企业的研发流程本质上是为“工程师时间稀缺”设计的，代码评审排队、需求排期协商、架构规划谨慎推进，每个环节都在珍惜稀缺的人力成本。但当代码生产的边际成本大幅下降后，这套流程的前提已经不再成立。

多家企业的数据印证了这种变化：某数据库企业的功能交付量提升了30%，安全团队一周合并了六千多个PR，还有企业将缺陷分诊工作完全交给了智能助手。这些数字背后真正的改变是成本结构的切换——当代码产出不再受限，测试覆盖率等环节成为了新的稀缺资源，就像这家数据库企业选择让智能助手成为主力代码贡献者，因为智能工具修复测试问题的边际成本已经远低于人力修复的成本。

当稀缺项发生变化，研发流程也必须随之调整，这套指南总结的五条核心规则，正是适配智能编程时代的全新研发逻辑。

释放生产力：降低交付门槛，接管重复劳动

让最懂问题的人直接产出第一版

智能编程工具最大的价值之一，是砍掉了创意到落地的中间传递环节。曾经的新想法需要经过“提出者-产品经理-设计师-工程师”的链条，等到上线时往往已经偏离了最初的设想，整个过程可能需要数周时间。而智能编程工具可以让真正理解业务问题的人直接提交代码修改，只在需要专业技术能力的环节，再邀请设计师和工程师介入。

有AI律所团队将智能助手接入了律师日常使用的工具中，团队负责人表示，律师本身就是产品的最终用户，他们拥有最直接的产品洞察。这种模式并没有取消分工，市场、开发等专业角色依然各司其职，但从0到1的原型搭建环节，已经对所有团队成员开放了。

要让这种模式成为稳定的机制，需要三个配套的落地动作：

首先是接入团队的日常工具和数据源，智能助手无法理解它看不到的信息，将团队常用的系统和命令行工具接入，可以让它和工程师在同一套事实基础上开展工作，对于有成熟命令行工具的场景，直接通过命令行接入还能节省token消耗。

其次是为创意开辟专属的排期通道，传统模式下只有产品经理的创意能顺利进入正式排期，其他人员的想法很难落地。可以通过定期原型评审、专属沟通频道等方式，让来自不同岗位的创意都能进入正式的产品路线图。

最后是沉淀团队的共享技能库，当越来越多的原型被快速搭建后，很容易出现零散混乱的问题。可以将团队的设计规范、业务上下文、常见工作流程整理为可复用的指令文件，让智能助手在每次接任务时都能读取参考，这样新成员入职后也能快速上手，产出的内容也能保持统一的标准。

让智能助手接管重复劳动

智能编程的另一个核心价值，是将研发生命周期中机械重复的工作交给智能工具，让工程师可以把时间留给需要专业判断的环节。

某数据库企业几乎将每个研发阶段都做成了自动循环，两个专门负责修复不稳定测试和补充测试覆盖率的智能助手，已经成为了仓库的第二和第三大代码贡献者。还有医疗信息化团队展示了智能并行处理的能力：一名工程师发起十三个工单，每个工单都会派生出一个子智能助手独立处理，每个子助手都拥有自己的工单和代码合并请求，这种并行处理的模式在传统流程中是不可能实现的，因为人力无法同时跟进十多条并行的开发任务。

多个智能助手协同工作需要合理的编排模式，行业总结了六种可复用的工作流模式：分类执行适合任务类型明确、处理路径不同的场景；扇出综合适合需要多角度覆盖的任务；对抗验证适合代码评审这类容易出现自我确认偏差的环节，可以让多个审查者互相挑错；生成过滤是先批量生成一批候选方案，再通过过滤器筛选出不合格的内容；锦标赛模式则是让候选方案两两对比，逐轮淘汰；循环直到完成模式适合有明确停止条件的场景，智能助手会反复迭代直到达到目标。

验证成为新的核心瓶颈

当代码产出的速度大幅提升后，研发的瓶颈也随之转移——写代码不再是阻碍，验证环节变成了最关键的瓶颈。代码生产的成本下降了，但验证的成本并没有同步降低。某安全团队一周合并六千多个PR，但人工评审的吞吐能力并不会随着代码产出速度同步增长，产能越高，验证环节的压力就越大，如果没有足够的验证能力，产能提升只会让问题积累得更快。

验证不是抽查，而是一套闭环流程

医疗编码团队的案例非常具有代表性，他们用智能助手读取病历并生成计费编码，团队的联合创始人兼CTO提出了明确的约束条件：医疗编码中的错误不仅是笔误，还会引发计费和合规问题，这个约束直接决定了他们的验证逻辑。

他们没有采用“智能生成+人工抽查”的简单模式，而是搭建了一套完整的闭环验证流程：

第一步，智能助手批量处理任务，审计人员不仅要审查编码结果，还要审查模型的推理过程，对所有内容进行批注并留存版本记录，确保整个过程可审计。

第二步，智能助手回读原始预测结果和所有批注，根据批注的编码类型标签，判断当前处理的是诊断问题、手术问题还是其他类别，直接跳转到对应的指引流程，定位出错的指令环节。

第三步，修改指令本身而非具体案例，团队的原则是“修复原则，不修复案例”，所有的改动都在版本化的指令集上进行，并在之前出错的记录上进行测试验证。

第四步，进行回测验证，医疗记录可能存在多个合法的编码结果，因此不能通过简单的字符串匹配来判断对错，验证需要结合语义匹配和专门的判定模型，这个判定模型需要回答“这是一个真实错误，还是一条不同的合法路径”。改动需要在经过验证的标准问题答案集和随机样本上运行，并输出回归情况报告，只有通过验证的改动才能正式上线。

最终返回给工程师的是一份精简的清单，包括建议的修改内容、无法判定的记录以及需要回答的问题。这套流程本质上是一个循环：智能助手处理一批任务，评估检查结果是否达标，达标则结束流程，不达标则返回重新调整，只有明确的停止条件，才能让智能助手自主判断何时完成任务。

修复不稳定的测试是最适合做成循环的场景，因为停止条件清晰且自包含：智能助手修改代码后，重新运行测试，通过后即可停止迭代。

避免常见的验证陷阱

这个医疗编码团队的联合创始人也分享了第一版方案的失败教训：最初的版本出现了过拟合的问题，智能助手只是通过记忆具体案例来“修复”问题，结果只是不断堆积补丁，并没有获得真正的泛化能力。后来他们调整了方法，强制要求智能助手遵循通用原则，并限制单次改动中可以加入的具体细节数量。

过拟合指的是智能助手只能记住见过的具体案例，当遇到新的场景时就无法正确处理。这套验证流程背后最核心的规则是：不要将人工反馈直接转化为规则，反馈需要经过抽象提炼，变成通用原则后，才能纳入智能助手的指令集。

为智能助手划定不可逾越的边界

有医疗信息化团队早期给了智能助手完全的自主权，结果智能助手虽然快速产出了看起来可以运行的代码，但在一些看似正确、实际不符合整体架构的地方偏离了原始设计。

团队的应对方案是将所有不可变的规则都记录下来，这些不可变规则就是必须始终成立的条件，包括问题的定义方式、必须满足的要求、如何证明方案的有效性等，最终整理出了567行的文档，团队负责人将其称为“这个团队的思考方式”。

这些不可变规则需要写入智能助手每次会话都会读取的文件中，确保架构规则、安全边界、不可妥协的条款始终跟随每一次会话。如果无法将规则书面化，就相当于没有真正的约束。

拥有验证能力，才能大胆重构

当验证能力建立起来后，以前不敢尝试的重构工作变得可行了。第四条核心规则是“为重构而构建”，随着模型能力的持续迭代，几乎没有什么架构是永久不变的。

某销售自动化平台的团队负责人表示：“在我们这里，你需要不断地重建系统，第一次、第二次、第三次，到第四次的时候，你才会真正清楚需要什么，才能做对。”

医疗信息化团队补充了一个判断标准：重构完成的标志不是新路径上线，而是新路径上线且旧路径彻底消失。以前拆除旧代码的工作总是在优先级排序中靠后，因为这项工作繁琐且不直接交付新功能，但现在一名工程师只需要调用一个智能技能，就能为每个全量发布的功能开关提交代码合并请求，删除开关和关联的旧代码，审查返回的结果即可。以前需要消耗大量开发周期的迁移工作，现在只需要一次计划和并行分发，几个小时就能完成。

法律AI团队的应用研究负责人也表示：“如果你六个月前来问我们的架构是什么样的，我会给出一个和今天完全不同的答案。”

这种变化的核心是重构的风险发生了改变。以前没有量化的评估测试时，重构完成后无法确定是变好了还是变坏了，因此只能选择不重构。而当验证能力补上后，重构的成本账就发生了变化：以前保留旧架构是为了降低风险，现在保留旧架构反而会积累技术惰性，重构的边际成本已经低于保留旧架构的成本。

将重构变成可控的实验

可以通过代码仓库的独立副本来开展重构工作，确保当前的生产版本不受影响。智能助手可以在独立副本中完成重构，和原有版本并行运行，通过评估测试对比两者的表现，只有新的方案胜出后才会合并到主分支。这也是“多次重构”成本降低的核心原因。

对于复杂的重写工作，可以在动手之前进入计划模式，让智能助手先探索代码库，提出重构方案，再由人工进行批准或纠正。计划模式是智能编程工具中的一种模式，智能助手只会读取代码、提出方案，不会直接修改文件，这是成本最低的把关环节。

重构完成的标准应该定为旧路径彻底消失，避免新旧两套系统长期共存带来的维护成本。

原型自用，再推向客户

第五条核心规则是先内部使用智能编程工具搭建内部助手，验证通过后再推向外部客户。这条规则可以看作是前四条规则落地后的自然结果。

内部使用智能助手相当于在真实的业务场景中完成验证，当验证通过后再对外交付，就已经在小范围场景中消化了大部分风险。

如果需要快速启动智能编程的落地，可以优先完成三件事：

第一，将团队的不可变规则书面化，包括架构规则、安全边界、团队的工作方式等，写成智能助手每次会话都会读取的文件。

第二，为关键场景建立验证集，每次改动都需要在这个验证集上进行回测，防止出现无法察觉的回归问题。

第三，计算重构的成本，如果一次重构需要消耗一个完整的开发周期，说明团队的验证能力还没有跟上，需要先完善验证环节。