当 AI 成为你的同事：Anthropic 内部报告揭示的新工程范式
一、一个反直觉的发现
Anthropic 最近发布了一份报告，叫《How Anthropic teams use Claude Code》。乍一看，这好像是一家 AI 公司在展示自家产品有多好用。但仔细读完，我发现它真正讲的是一件更有趣的事——
软件工程正在从一门“确定性手艺”变成一种“概率性博弈”。
我们过去写代码的逻辑很简单：想清楚，写下来，测一测，上线。每一步都是确定的。但当 AI 深度介入开发流程之后，游戏规则变了。Anthropic 的 RL（强化学习）工程团队在报告里坦诚地说：让 Claude Code 独立完成一个小到中等的 PR，“一次就成”的概率大约只有三分之一。
三分之一。这个数字非常关键。
它意味着你不能像指挥一个靠谱工程师那样指挥 AI——“去把这个功能做了”，然后等着交付。你得换一种完全不同的思路。
Anthropic 自己的 10 个团队，从数据基础设施到法务，从安全工程到增长营销，各自独立地摸索出了一套新方法。把这些方法叠在一起看，你会发现它们指向同一个底层规律。
这篇文章就来讲讲这个规律。
二、老虎机式工作法
Anthropic 的数据科学团队发明了一个绝妙的说法，叫“老虎机式工作法”（slot machine approach）。
做法很简单：你先保存好当前进度（checkpoint），然后让 Claude Code 自由发挥 30 分钟——写代码、跑测试、自我修正。30 分钟后你回来一看：如果结果不错，恭喜你赚到了；如果一团糟，你直接回滚到 checkpoint，重新来一次。
这听起来荒唐。传统工程思维里，你遇到错误应该去修它、去 debug、去逐步逼近正确答案。回滚重来？那不是浪费前面所有的工作吗？
但这恰恰是概率式系统的反直觉真相：当生成器有随机性时，重新开始有时比逐步修补更便宜。
想象你在走迷宫。如果你能看到迷宫全貌，那当然应该逐步修正路线。但如果你蒙着眼睛走，每一步都有随机性，那么当你发现走到死胡同时，最聪明的做法不是原路返回再试一条岔路——而是直接传送回起点，重新走。因为 AI 每次生成的路径不一样，“重新走”有真实概率走出一条更好的路。
RL 工程团队用的也是同一套策略：先让 Claude 一次性跑完整个任务（one-shot），成了就赚到；没成就切换到“协作引导模式”，人在旁边一步一步带。他们甚至把 Claude 常犯的错误记录下来写进文档（Claude.md），比如“不要乱 cd 目录”、“pytest 路径要写对”——下次它就不会犯同样的错了。
这整套东西——checkpoint、回滚、重新尝试、记录错误——不是什么小技巧。它是一种新的工程范式。
三、概率式协作的三根支柱
当我把 10 个团队的做法叠在一起看时，我发现它们虽然各自独立探索，却不约而同地搭建了同一套基础设施。我把它概括成三根支柱：上下文、控制、反馈。
第一根：上下文。 你得告诉 AI 它在哪、该怎么做、有哪些约束。
数据基础设施团队写了一份详细的 Claude.md，里面包含数据管道的依赖关系、上游数据源、dashboard 的对应关系。新人入职时，不用再拉着老员工讲半天——让 Claude 读 Claude.md 就行了。
更妙的是，他们让每次 Claude 工作 session 结束时自动生成总结，然后把总结回写到 Claude.md 里。这意味着这份文档会越来越完善——AI 在使用过程中不断改进自己的“使用说明书”。
设计团队也写了自定义 memory 文件，但内容不一样：“我是设计师，不是工程师，请用小步骤解释每一步改动。”
第二根：控制。 你得确保 AI 搞砸的时候你能回到安全地带。
产品研发团队的规矩是：永远保持干净的 git 状态，频繁做 checkpoint。这不是代码洁癖，这是生存策略。当你让一个概率性系统自由发挥时，“可以随时撤销”就是你最重要的安全网。
数据科学的老虎机工作法也是同一个思路：先 commit，再放手。
第三根：反馈。 你得让 AI 自己知道它做得对不对。
产品研发团队有一个核心实践叫“自给自足循环”（self-sufficient loop）：让 Claude 写完代码后自动跑 build、test、lint。如果测试挂了，它自己修；lint 有问题，它自己改。你不需要一行一行盯着看——让系统自己告诉它哪里错了。
这三根支柱缺一不可。
没有上下文，AI 不知道该做什么，你就会反复纠错。没有控制，你不敢放手，AI 只能做最简单的活。没有反馈，你只能靠人肉 review 来判断质量，那 AI 的速度优势就打了折扣。
很多团队觉得“AI 不够聪明”，其实不是。你缺的不是更强的模型，而是这三根支柱中的某一根。
四、风险分层：一种新的工程治理模型
产品研发团队给出了一个特别清晰的分类法：
- 外围功能、原型、批量替换、测试生成 → 异步自治：开 auto-accept，让 Claude 自己写、自己跑、自己改，你事后来 review。
- 核心业务逻辑、关键修复、安全相关 → 同步监督：你在旁边实时盯着，prompt 要非常具体，随时纠偏。
他们甚至有一个真实案例：Claude Code 的 Vim mode 功能，最终实现中大约 70% 来自 Claude 的自治工作。但这 70% 全部是在“外围功能”范畴内。核心逻辑仍然是人写的。
这不是技巧问题，这是治理模型。你用“监督强度”来对冲不确定性——风险越高，人介入越深；风险越低，AI 自主权越大。
安全工程团队更是把这个思路用到了极致。他们让 Claude Code 审查 Terraform plan——“这个变更会做什么？有没有后悔风险？”——安全审批的速度一下子快了很多，研发团队不用再排队等安全团队一行一行 review。但注意：Claude 给出的是“分析”，最终 approve 仍然是人按的按钮。
这就是风险分层的精髓：不是不信任 AI，而是按风险等级分配信任。
五、被严重低估的三件事
读完 10 个团队的实践，有三件事被严重低估了。
第一件：截图的价值。
数据基础设施团队排查 Kubernetes 问题时，直接把云控制台的截图喂给 Claude Code。设计团队和法务团队也大量使用“截图→反馈→迭代”的循环。
这件事被低估了。对于很多“界面/状态/配置”类问题，截图比文字描述快 10 倍，也准 10 倍。你不需要费劲把一个 dashboard 的状态用文字翻译出来——贴张图就行了。视觉输入让“人与 AI 对齐”的成本大幅降低。
第二件：组织记忆的工程化。
数据基础设施把 session 总结回写文档。安全团队把散落在各处的知识压缩成 runbook。增长营销团队甚至搭了一套“实验记忆系统”——上一轮广告测试的结果会自动传递给下一轮生成，形成自我改进的闭环。
这些做法共同指向一个结论：把组织经验写成机器可消费的形式，模型才会越用越好，团队才会越用越一致。 否则 AI 永远只是“个人的随机助手”，无法规模化。
第三件：非技术岗位的“跨界”。
增长营销团队只有一个人。这个人不是工程师。但他用 Claude Code 写了 Google Ads 自动化脚本、Figma 批量变体插件、Meta Ads 分析工具。文案制作从 2 小时降到 15 分钟，创意产出提升 10 倍，一个人像一个小团队一样运作。
法务团队更厉害——一位律师用 Claude Code 在一小时内做出了一个预测文本加语音输出的辅助沟通应用，帮助有语言障碍的家人。
产品设计师也不再只做“视觉微调”了。他们开始直接修改状态管理逻辑、梳理 error state、全站替换合规措辞——这些过去都要找工程师才能做的事。
这意味着 Claude Code 在组织里扮演的角色，不是“更强的 IDE”，而是一个翻译层——它把不同角色的意图（业务的、设计的、合规的）翻译成可执行的代码变更。这会改变“谁能做什么”的边界。
六、真正贵的是“上下文税”
API 团队说了一句很精辟的话：Claude Code 最大的价值不是“帮我写代码更快”，而是“帮我省掉了把代码片段搬到另一个窗口、再解释半天背景”的那段时间。
这句话点出了一个被忽视的真相：在大组织里，真正昂贵的不是写代码的速度，而是“上下文税”。
什么是上下文税？就是你为了理解一件事所付出的所有隐性成本——
- 切换到一个陌生的子系统，要读一个下午的代码才能开始动手
- 轮岗到新团队，要好几周才能有效贡献
- 每次提 bug 要把前因后果解释一遍
- 跨团队协作时反复对齐上下文
Inference 团队说，过去理解一个 ML 概念要 Google 搜索加读文档一小时，现在问 Claude 只要 10-20 分钟，研究时间降低了 80%。安全工程师说，过去手动扫代码定位问题要 10-15 分钟，现在 5 分钟搞定。
这些看起来是“个人效率提升”，但放到组织层面就不一样了：当上下文税降低，跨界协作的摩擦也跟着降低。 新人上手更快，轮岗更顺滑，跨团队求助减少——这些复利效应远比“单次写代码快 20%”更有价值。
七、一种张力
法务团队在报告最后说了一段意味深长的话。他们一方面鼓励大家分享不完美的原型——“因为原型会激发跨部门创新”；另一方面又警告说，MCP 深度集成的安全影响不容小觑，“合规工具要跟上能力扩张的速度”。
这不是一个孤立的担忧。它指出了未来几年很多组织都会遇到的真实矛盾：
当 AI 把“做事”的门槛降到足够低，每个部门都能直接连到系统和数据。这是创新的巨大加速器——也是风险扩散的巨大加速器。
过去，“不是工程师所以碰不了系统”本身就是一道天然防火墙。现在这道墙正在消失。数据基础设施团队建议敏感数据场景用 MCP server 代替直接 CLI，以便做权限和审计控制。法务强调要给非技术用户设定“更严格的安全默认值”。
能力越强，治理就越不能停留在“提醒大家小心”。它必须工程化——最小权限、审计日志、隔离环境、审批门槛。
这是 AI 民主化的代价。也是不得不付的代价。
八、这份报告真正在说什么
让我把这篇文章的核心论点串起来——
Anthropic 10 个团队的实践，表面上是“我们怎么用 Claude Code 的”，底层其实是一个范式转移的缩影：
软件工程从确定性走向概率性。 你不能指望 AI 每次都对，但你可以设计一个“从不确定性中持续获利”的流程——checkpoint、回滚、重试。这和传统工程直觉相反，但在概率系统里经常成立。
生产力提升的杠杆点在于“三闭环”（上下文、控制、反馈），不在于模型本身。很多人抱怨“AI 不够好”，其实是缺了其中一环。
组织效率的核心瓶颈在于上下文税，不在于代码产出速度。 AI 真正值钱的地方，是把跨角色、跨项目、跨学科的摩擦成本压低。
AI 正在把“谁能做什么”的边界重新画一遍。 非技术岗位能写代码，设计师能改状态管理，一个人能像一个团队。但这意味着权限、审计和安全机制必须同步升级。
组织记忆必须工程化。 Claude.md、runbook、实验日志——把组织经验变成机器可消费的形式，是 AI 工具从“个人提效”迈向“团队规模化”的关键一步。
这份报告最大的价值不在于展示了哪些酷项目。它展示的是一种新的协作方式：把 AI 当成一个概率式的合作伙伴，用工程手段（而不是美好愿望）把它的不确定性变成可控的收益。
这才是“AI 改变工作”的真正意思。