8月21日，Anthropic发布了一份《The AI-Native SDLC Playbook》。我原本以为这又是一篇Claude Code最佳实践，真正读完以后，最让我在意的反而是开头那句话：Code is no longer the bottleneck，代码已经不再是瓶颈。
这句话放在两年前多少有点夸张，但放在Anthropic自己身上已经不完全是宣传。截至今年5月，Anthropic称超过80%的合并代码由Claude编写；到了2026年第二季度，典型工程师每天合并的代码量大约是2024年的8倍。这里当然要注意，代码行数不等于生产率，Anthropic本身也是最适合Claude Code发挥的特殊样本，但至少说明一件事：当写代码这件事真的突然快了几倍以后，原来围绕“人写代码”建立起来的那套软件开发流程，开始跟不上了。
我自己做AI产品时也有类似感受。现在日常开发里，绝大部分代码已经交给Coding Agent完成，DoseLoop甚至做到了没有手写代码。模型会不会写一个页面、改一个API，对我来说已经很少是最耗时间的问题。更费时间的往往是先把需求想清楚，告诉Agent为什么这么做、哪些地方不能动，最后再判断它交出来的东西到底是不是我真正想要的。
所以这份Playbook真正有意思的地方，不是Anthropic又教大家怎样多生成一些代码，而是它开始处理代码之外的部分：Plan、Design、Build、Test、Deploy、Maintain，整条软件开发链路都要重新适配Agent。
当代码变快以后，慢下来的开始是组织
Anthropic设计了一条很具体的链路。一个想法先被写成intent.md，产品负责人确认后，Claude生成spec.md，再由工程师和Claude一起形成plan.md。接下来才是代码和测试，PR合并以后进入部署，生产环境的指标如果越过预设控制线，又可以重新生成一个新的intent.md，进入下一轮循环。Anthropic把它描述成一个从Plan最终回到Plan的连续闭环，每个阶段都留下版本化的artifact，前一个阶段的输出直接成为下一个阶段的输入。
如果只看这些Markdown文件，好像没有什么革命性。企业过去也有PRD、设计文档、Jira、Wiki和各种审批流程。区别在于，以前这些东西主要是写给下一个“人”看的，人会补上下文，会去找同事问一句，也会知道某条规定虽然这么写，但这个项目可能有例外。现在接手工作的可能是Agent，它不会天然知道这些隐含信息。
Spotify今年公开的一组数据很能说明这个变化。超过99%的工程师每周都在使用AI Coding工具，94%认为AI提高了自己的生产率，PR频率提高了76%。结果是，代码生产能力上去了，公司突然多出76%的PR需要处理。Spotify自己的总结也很直接：随着Coding速度提升，瓶颈正在向human decisions转移，他们开始重新决定哪些PR可以自动合并，哪些地方必须留下人的判断。
这其实是AI Coding发展到今天一个很容易被忽略的变化。以前企业提高研发效率，主要是在想怎样让程序员更快地写代码。现在执行能力突然便宜以后，问题变成了：公司能不能足够清楚地告诉Agent，到底应该做什么。
公司经验，开始从“文档”变成Agent的运行环境
我觉得整份Playbook里最重要的内容，其实是CLAUDE.md、Skills、Evals和Hooks这些看上去最不起眼的东西。
Anthropic对CLAUDE.md的定义很有意思：它应该包含一个新员工第一天需要知道的东西，包括构建和测试命令、架构约定，以及团队最常见的错误。它甚至给了一个很实用的规则：Claude同一个错误犯两次，就把纠正方法写进CLAUDE.md。这个文件进入Git，所有人共享，修改它和修改代码一样可以被Review。过去存在于老员工脑子里或者散落在Wiki里的经验，就这样一点点变成Agent每次工作前都会读取的上下文。
Skills再往前走了一步。Anthropic直接把它称为让“institutional knowledge”变得operational的方式。比如公司的安全规范、API设计标准、品牌规则、合规要求，都可以变成带版本控制的Skill，在需要的时候自动进入Agent上下文。Evals则负责另一类更难的问题：怎样判断Agent做得好不好。Anthropic把持续Eval视为AI-native版本的阶段式QA，每次模型、Prompt或者Agent配置发生变化，都可以重新验证结果是否仍然达到原来的标准。
但光告诉AI“应该怎么做”还不够。真正不能违反的规则，Anthropic建议交给Hooks。Hook可以在Claude行动之前直接allow、ask或者block，例如禁止它在修Bug时修改测试文件，或者在没有指定Release Authorization时阻止Production部署。关键规则因此不再只是员工手册里的一句话，而开始变成系统实际执行的边界。
把这些东西放在一起看，我觉得“机器可读”才是这份Playbook里比AI写代码更大的变化。当然，这个词不能理解成把公司的所有规章制度都转成Markdown，而是公司的意图、经验、规范、验收标准和权限边界，正在逐渐被整理成Agent能够读取、系统能够验证，其中一部分还能够直接执行的组织资产。
过去做知识管理，很大一部分目标是让员工在需要的时候“找到答案”。Agent进入工作流以后，仅仅找到答案已经不够，它还需要根据这个答案采取行动。这两者之间的差别，比看起来大得多。
这并不是Claude自己的特殊玩法
如果只有Anthropic在这么做，我会更谨慎地把它理解成Claude Enterprise的一套产品方法论。但我后来又看了一下其他Coding Agent，大家正在往非常相似的方向走。
Cursor的Project Rules保存在.cursor/rules里，可以和代码一起版本控制，用来记录项目领域知识、工作流程和架构约定。GitHub Copilot现在也支持repository instructions、path-specific instructions，以及AGENTS.md、CLAUDE.md、GEMINI.md这些Agent instruction文件。换句话说，不同公司的模型和Agent可以不一样，但代码仓库里正在出现一层新的内容：除了给编译器和人看的代码，还要有一套长期、可复用的说明告诉Agent“我们这里是怎么工作的”。
Spotify的实践更能说明为什么这件事最终不只是几个配置文件。它发现，在技术栈和设计模式比较统一的代码库里，Claude表现明显更好；代码越碎片化，Agent效果越差。Spotify还把内部Backstage平台的能力通过MCP和命令行开放给Agent，让它能够查询一个组件归谁负责、读取相关文档，甚至在Slack里找到对应团队。过去为人类开发者建设的标准化和内部平台，突然也变成了Agent工作的基础设施。
这也解释了为什么同一个模型放进不同公司，效果可能完全不同。过去那些看起来只是工程洁癖的事情——统一技术栈、清晰的组件归属、可靠文档、可运行测试和明确权限——到了Agent时代，都开始直接影响模型表现。AI并没有绕开组织工程，反而会把原来含糊和混乱的地方放大出来。
这让我更倾向于认为，所谓AI-native公司，不能只看员工装了多少AI工具，或者多少代码由AI生成。模型本身会越来越容易获得，Claude、Codex、Gemini或者未来别的模型都可以换，但一家公司的客户知识、产品逻辑、历史决策、安全边界、工作习惯和Eval体系不会跟着模型一起买回来。
过去我们讨论Context Engineering，更多是在讲怎么给一个Agent准备更好的上下文。现在它可能正在慢慢变成一种Organizational Engineering：公司要开始认真管理“我们到底知道什么，以及怎样把这些东西提供给机器”。
机器可以读懂规则，但公司仍然需要人决定规则
当然，我并不认为公司最后真的可以把自己全部写成代码。Anthropic自己的Playbook其实也一直在提醒这条边界。
intent.md需要产品负责人确认，spec.md仍然由人签字，高风险改动要交给技术负责人，Production部署即使已经自动化到最后一步，也要求Release Manager授权。Anthropic明确写道，需要判断的决定仍然由人负责；Agent可以一路工作到Production Gate，但不能自己越过这个Gate。
原因并不复杂。很多组织里最有价值的知识，本来就很难完全说清楚。一个客户嘴上说想要某个功能，他真正愿不愿意买；两个产品方案都符合规范，哪个更符合公司的长期方向；安全、体验和收入发生冲突时应该牺牲哪一个，这些问题很难靠一个Skill或者Eval完整表达。
所以我更愿意把“机器可读公司”理解成一个方向，而不是终点。Agent越能执行，公司越需要区分三件事：哪些经验应该被写出来让机器读取，哪些规则必须变成系统强制的边界，哪些判断仍然需要留给人。
回到Anthropic那句“Code is no longer the bottleneck”，我现在觉得它真正提醒企业的可能不是赶快让AI再多写一点代码。当执行越来越容易，隐藏在组织内部那些过去可以靠人自己补全的模糊信息，会越来越明显地暴露出来。
一家公司的数字化，过去主要是把客户、订单、库存和流程变成机器可以记录的数据。Agent时代又往前走了一步：机器开始参与行动以后，公司还得把“我们为什么这么做、通常怎么做、什么算做好、什么绝对不能做”讲清楚。
AI越能工作，公司可能越要先学会把自己说清楚。真正开始变得“机器可读”的，也不是公司本身，而是这家公司究竟是怎样运转的。
