Anthropic访谈了15家明星公司，整理的AI编程教程公开了！

Anthropic 最近采访了 15 家正在大规模使用 Agentic Coding 的科技公司，其中包括 ClickHouse、Harvey、Cognition、Clay 等明星公司。Cognition、ClickHouse 和 Harvey 的估值都已超过 100 亿美元，也是目前采用 AI 编程最积极的一批公司。

基于这些访谈，Anthropic 整理出了一份实操指南。所谓 Agentic Coding，就是让 Agent 深度参与代码开发。指南虽然以 Claude Code 为主，其中提到的技能、计划模式和 worktree 也都是 Claude Code 的功能，但背后的工作方法同样适用于其他 Agentic Coding 工具。

https://claude.com/blog/claude-code-guide-for-startups

这篇文章按教程结构重新组织：五条规则是什么，为什么顺序不能打乱，每条怎么做，以及哪里容易踩坑。

一、当代码不再稀缺，旧研发流程还成立吗？

传统公司的研发流程是为稀缺设计的。代码评审、需求排期、架构规划、分阶段放量，这些机制的存在前提是工程师时间稀缺。评审要排队，排期要协商，规划要谨慎，因为每个环节消耗的都是稀缺资源，浪费不起。

代码生产的边际成本掉下来之后，这些机制的前提就不成立了。ClickHouse 报告功能交付量提升了 30%，Artemis Security 一周合并 6000 多个 PR，Clay 把缺陷分诊（bug triage，指对 bug 分类、定优先级、分派处理）全部交给了 agent。

这些数字看着像用了 AI 所以更快。真正的变化是成本结构。做数据库的 ClickHouse 敢让 agent 成为主力贡献者，是因为测试覆盖率是它的稀缺项，而 agent 修测试的边际成本已经低于人修。

稀缺项变了，流程就得跟着重设计，下面五条规则是流程重设计之后产生的。

五条规则分别是：人人皆可交付、自动化繁琐工作、信任但验证、为重构而构建、原型自用产品化。

二、先释放生产力：让更多人交付，让 Agent 接管重复劳动

1、让最懂问题的人直接做出第一版

降低交付门槛，让真正理解问题的人直接产出第一版。

做医疗 AI 的 Heidi 描述了一个"传话游戏"问题。一个新想法过去要走一条链：提出想法的人告诉产品经理，产品经理告诉设计师，设计师再告诉工程师。到上线的时候往往已经不是当初那个东西了，而且要花几周。

agentic coding 工具去掉了这条链上的中间环节。真正理解问题的人可以直接提 PR，只在需要专业能力的地方把设计师和工程师拉进来。

做 AI 律所的 Crosby 把 agent 接到了律师日常在用的工具上。负责人的说法是，律师有最好的产品洞察，因为他们就是用户。

分工并没有消失。市场部还是做市场，开发还是做开发。发生变化的是从 0 到 1 这一步，也就是把想法变成可运行原型的环节，对所有人开放了。

要把这件事做成机制，靠三个配套动作。

接上工具和数据源。agent 看不到的东西就无法理解。给它接上团队日常在用的系统，让它和工程师在同一份事实基础上工作。有成熟命令行工具的场合，直接走命令行接入往往更省 token。

给创意开一条进入排期的通道。产品经理的创意天然能进正式排期，其他人的不能。做销售自动化平台的 Clay 每季度做一次原型评审，原型式创意可以由此进入正式路线图。做商业智能的 Omni 则开了一个专门放 agent 生成原型的 Slack 频道，贡献者包括资深技术人员。

把团队标准沉淀成共享的技能库。原型式的东西多了之后，拼起来容易变成一堆互不相关的碎片。技能（skill）是可复用的指令文件，把设计规范、公司上下文、常见工作流程写进去，agent 每次接任务时读取。新人第一天就能用上，产出的东西也能保持一致。做应用构建平台的 Emergent 的做法是接受上下文文件略微过期，只要 agent 能自己验证和纠正。

2、把重复劳动交给 Agent

让 agent 接管生命周期里机械的那部分，工程师把时间留给真正需要判断的部分。

做数据库的 ClickHouse 把几乎每个研发阶段都做成了自动循环。两个专门修不稳定的测试（flaky test，指有时通过有时失败的测试）和补测试覆盖率的 agent，现在是仓库的第 2 和第 3 大贡献者。

做医疗信息化的 Commure 展示了并行的规模。一个工程师发起约 13 个工单，每个工单派一个 subagent 并行处理，每个 subagent 拥有自己的工单和 PR。subagent 是从主 agent 派生出来的子 agent。这种并行度在传统流程里不可能出现，因为它要求有人同时盯 13 条线。

多个 agent 一起干活，需要编排模式。原文给了六种可复用的工作流模式，包括分类执行、扇出综合、对抗验证、生成过滤、锦标赛、循环直到完成。

分类执行适合任务类型已知、处理路径不同的场合。扇出综合适合需要多角度覆盖的场合。对抗验证让多个审查者互相挑错，适合代码审查这类容易自我确认偏差的场合。生成过滤是先生成一批候选，再用过滤器筛掉不合格的。锦标赛让候选两两比较，逐轮淘汰。循环直到完成则适合停止条件明确的场合，agent 反复迭代直到达标。

三、代码越容易生成，验证就越昂贵

产能提上去之后，问题换了个位置。写代码不再是瓶颈，验证变成了瓶颈。

验证环节以前是附属的。产能上去之后，它变成了主要瓶颈。写代码的成本掉了，验证的成本没掉。Artemis Security 一周合并 6000 多个 PR，人工评审的吞吐不会跟着产能一起涨。产能越往上提，验证越跟不上。

没有验证能力，产能提升只会让问题积累得更快。

1、验证不是抽查，而是一套闭环

做医疗编码的 Cainex 是一个极端的场景。它用 agent 读病历并生成计费编码，联合创始人兼 CTO 先说了一个约束条件："医疗编码里，一个错误的编码不是笔误，是计费和合规事件。这一条事实决定了我们怎么构建。"

这个约束决定了他们不能接受"agent 生成，人抽查"。他们建了一条完整的检查流程。

第一步，agent 批量处理，审计员审查输出。审查的对象不只是编码结果，还有模型的推理过程，审计员对两者都批注。所有内容版本化、可审计。

第二步，agent 读回原始预测和所有批注，找出是哪一段指令出的错。每条批注都按编码类型打了标签，agent 据此判断自己在看的是诊断问题、手术问题还是其他类别，直接跳到对应那一类的指引。

第三步，改指令本身，不改具体案例。他的表述是"修复原则，不修复案例"。每次改动都在版本化的指令集上进行，并且在之前出错的记录上做测试。

第四步，回测。医疗记录可能存在多个可接受编码，所以不能做字符串匹配。检查结合语义匹配和一个判定器，判定器是专门用来判断对错的模型，它要回答的问题是"这是一个真错误，还是一条不同的合法路径"。改动要在一组验证过的问题答案对（golden set）加上随机样本上跑一遍，把回归情况报告出来才允许上线。

返回给工程师的是一份短清单：建议的修改、无法判定的记录、需要回答的问题。

这条流程是一个循环：agent 处理一批任务，评估模型检查结果是否达标，达标就结束，不达标就打回去重做。停止条件要写得足够明确，agent 才能自己判断什么时候该停。

修不稳定的测试是最适合做成循环的场景，因为停止条件清晰且自包含：agent 改完代码，重跑测试，通过了就停。

2、Cainex 踩过的坑：补案例不等于修规则

Cainex 的联合创始人兼 CTO 交代了第一版是怎么失败的：

"一开始没这么干净。我们的第一版过拟合了。它靠编码具体案例来'修复'问题，结果只是在攒补丁，没有变得更聪明。我们改了方法，强制它走通用原则，并且限制一次改动里能进入多少具体细节。"

过拟合，指只记住了见过的具体案例，换个新案例就不会了。

这套流程最重要的是它背后的那条规则：改原则，不改案例。

这段话说明这条流程不是一次设计出来的，是从一个失败版本改过来的。失败的原因是审计员的批注被直接写成了规则，规则越来越多，系统没有获得任何泛化能力。改法是强制走通用原则，并且给单次改动的具体细节设上限。

这条规则落到执行上：不要让人工反馈直接变成规则。反馈要经过抽象这一步，变成原则，才能进指令集。

3、给 Agent 划出不能越过的边界

做医疗信息化的 Zingage 早期给 agent 完全自主权，"它做了 AI 会做的事，快速产出了看起来能跑的代码。问题是它在一些看起来正确、实际不符合架构的地方偏离了原设计"。

他们的应对是把所有不变量写下来。不变量就是必须始终成立的条件，包括怎么框定问题、什么必须成立、怎么证明一件事有效。这些全部写下来是 567 行，Victor 把它称作"这个团队如何思考"。

不变量要写在 agent 每次会话都会读的文件里，架构规则、安全边界、不可妥协的条款跟着每一次会话走。写不下来的部分，等于没有约束。

四、能验证，才有资格推倒重来

验证能力建起来之后，一件以前不敢做的事变得可行了。

第四条规则：为重构而构建。模型能力在持续变化，几乎没有什么是永久的。

做销售自动化平台的 Clay 的说法是："你在 Clay 做的事是，建一次，再建一次，再建一次。第四次你建的时候，你就知道需要什么了，你能做对。"

做医疗信息化的 Commure 补充了一条判断：重建完成不是新路径上线的时候，是新路径上线且旧路径消失的时候。他举了个例子。feature flag 是功能开关，用来控制某个功能是否对用户开放。以前拆除旧代码这件事永远在优先级排序里输掉，因为它繁琐而且不交付功能。现在一个工程师只要调用一个技能，说"给每个已经全量发布的功能开关开一个 PR，把开关和关联代码一起删掉"，然后审查返回的结果。以前要吃掉大量开发周期的迁移，现在是一个计划加一次并行分发，几个小时做完。

做法律 AI 的 Harvey，其应用研究负责人说："如果你六个月前来问我我们的架构长什么样，我会给出一个和今天完全不同的答案。"

这几句说的是同一件事：重建的难度一直没变，变的是重建的风险。以前没有评估测试（evals，用来量化改动的影响），重建完不知道是变好了还是变坏了，那就只能不重建。

验证能力补上之后，重建这笔账就变了。保留旧架构以前是为了降低风险，现在只会积累惰性。重建的边际成本已经低于保留成本。

1、把重建变成一次可控实验

用 worktree 在仓库的独立副本里做重建，当前版本不受影响。

worktree 是仓库的独立副本，可以和主版本并行存在。v2 和 v1 并行跑，评估测试对比，新的赢了才合并。这就是"建四次"变便宜的原因。

复杂一点的重写，在动手之前进计划模式，让 agent 先探索代码库、提出重建方案，人批准或纠正。计划模式是 Claude Code 里的一种模式，agent 只读代码、给方案，不动文件。这是最便宜的把关点。

一次重构完成的标准定为旧路径消失，避免新旧两套长期共存。

五、写在最后：一份可以照着做的清单

第五条规则是原型自用产品化。先用 agentic coding 工具搭内部用的 agent，内部自用，验证通过再推给客户。

这一条可以看作是前面四条都成立之后的自然结果。内部 agent 自用，等于在自己的真实场景里跑验证。验证通过再推给客户，等于重建的风险已经在小范围里消化过了。

如果要挑三件事先做。

把不可变的东西写下来。架构规则、安全边界、团队的工作方式，写成 agent 每次会话都会读的文件。

给关键场景建验证集。每次改动都拿它回测，防止回归分不出来。

算一下重建成本。如果一次重构要花掉一个开发周期，那说明验证能力还没跟上。