从 glob 替代 RAG、本地运行替代沙箱、Member of Technical Staff 同 title 制,到 Claude 4 release 后删掉一半 system prompt —— Claude Code $500M ARR 的背后,是一套跟工程界默认假设全反的选择。
Boris Cherny(创建人/Head)、Sid Bidasaria(工程师 #2)、Catherine Wu(创始 PM)接受 Pragmatic Engineer、Lenny's Newsletter 等多次访谈,公开了一组反直觉数据:Claude Code 90% 代码自己写,每次模型升级删一半 system prompt,80% Anthropic 工程师每天用,18 个月内做到 $500M ARR。每一个工程决策都跟"复杂工程 = 强 agent"的默认假设相反。
2024 年 9 月,Boris Cherny 加入 Anthropic 的第一周搞了个原型 —— 接 AppleScript 让 Claude 报"我现在在听什么歌"。19 个月后,这个原型变成了 $500M ARR、90% 代码自己写、80% Anthropic 工程师每天用的 Claude Code。2026 年 5 月,工程团队复盘了构建过程 —— 不是炫耀,是把所有"反工程默认假设"的选择列出来。
这种复盘很罕见。绝大多数 SaaS 公司在 $500M ARR 时会拒绝公开"我们怎么做到的" —— 因为这本身就是护城河。Anthropic 的逻辑反过来:Claude Code 的护城河不是工程复杂度,是反复杂度。把账本公开,反而能放大它对整个 agent 生态的影响。
这份复盘里没有"我们用了多 fancy 的架构",而是反复强调三件事:少代码、少层级、少角色。Boris 一句金句把它说完:"Every time there's a new model release, we delete a bunch of code." 模型升级 = 工程减负,而不是工程加负。
过去 12 个月,所有 agent 框架 / IDE 工具(Cursor、Aider、Continue、Devin、Cline)都在试图证明 "agent = 复杂工程"。Claude Code 的复盘是第一份系统反驳这个假设的内部数据。
不是说"我们也 fancy",是说"我们刻意不 fancy,而且效果更好"。当一个 $500M ARR 产品的工程团队公开自己"删代码"的实践,这就是行业级 framing 转变。
Claude Code 的技术栈选择,在工程师圈一开始被嘲笑过 —— TypeScript + React + Ink(终端 React)+ Bun + Yoga(Meta layout 引擎)+ npm。"为什么终端 CLI 要用 React?为什么不用 Go / Rust 这种'真正的系统语言'?"
Boris 的回答非常清楚:"We wanted a tech stack which we didn't need to teach: one where Claude Code could build itself." 选 React + TypeScript 不是因为开发者熟悉,而是 Claude 在训练数据里见过太多 React + TypeScript,它能高效地 build 自己。
这个判断有个专门名字:"On Distribution"。模型对一种语言/框架的能力,不是 marketing 决定的,是训练数据决定的。用 Claude 见过的栈,Claude 就强;用 Claude 没见过的栈,Claude 就弱。Claude Code 选 React + TypeScript,本质上是选择了让模型站在自己最强的能力分布上。
| 组件 | 常见选择 (工程师视角) | Claude Code 选择 (on distribution) | Boris 给的理由 |
|---|---|---|---|
| 语言 | Go · Rust · C++(终端工具) | TypeScript | Claude 训练数据里 TS 最多 |
| UI Framework | tview · bubbletea · 原生 ANSI | React + Ink | "Claude 能写 React,就能写终端 UI" |
| Layout 引擎 | 自己撸 / ncurses | Yoga(Meta OSS) | constraint-based · 可变终端尺寸 |
| Build Tool | Webpack / Vite | Bun | 速度优先 · npm 兼容 |
| 分发 | brew / 二进制下载 | npm | Node 生态全覆盖 |
| 沙箱 | Docker / VM / WASM | 本地直接运行 | "安全靠权限,不靠隔离" |
| 代码检索 | 向量数据库 / RAG | glob + grep | "simple search beats sophisticated RAG" |
"With an off-distribution stack, the model can still learn it.
But you have to show it the ropes. We wanted a tech stack which we didn't need to teach."
这句话拆解了 90% 的 agent 工具选型问题。当你选了一个"工程师喜欢但 Claude 不熟"的栈,你就需要花 prompt token 教 Claude 怎么用它。每次 task,都在重复教学。当你选 React + TypeScript + Bun,Claude 直接跳过教学,把所有 token 用在解决问题上。
"On distribution" 不是"用流行栈",是用模型最强的能力分布。流行 ≠ 训练充分。Claude 训练数据里 Rust 不少,但 React + TypeScript 多得多 —— 所以选 React。
这条原则也会随时间漂移。如果未来 Claude 训练数据里某种新框架增加 5×,那么从"on distribution" 角度,新框架可能在某个时点超越 React。技术栈选型从此变成跟踪模型训练分布的运营问题,而不只是一次性的工程决策。
除了"on distribution"这个底层哲学,Claude Code 还做了三个具体的反向决策。每一个都跟同期 agent 工具的"行业最佳实践"相反。
2024–2025 整年,agent 工具的"标准做法"是 RAG + 向量数据库 + chunking + reranking。Cursor、Continue、Sourcegraph Cody 都是这条路线。Claude Code 选了相反的方向:让模型自己 grep / glob 找文件,没有任何 vector index。
"Plain glob and grep driven by the model outperformed local vector databases and recursive model-based indexing for codebase navigation." — Boris Cherny · 2026.03 · 多次访谈
这个判断在 2025 年初是异端 —— "向量数据库怎么可能不如 grep?"但实际效果是,Claude Code 在百万行 codebase 上的 navigation 精确度,比基于 RAG 的方案更好。原因:RAG 会损失上下文,grep 不会。Claude 是个能推理的模型,它自己会写更好的查询,而不是依赖 reranker 的猜测。
2025 年 agent 安全的"行业共识"是沙箱化:Docker、WASM、cloud VM、microVM。Devin 跑在 cloud VM 里,Cursor 用 limited workspace,各种 agent 框架都默认 isolation-first。Claude Code 选择本地直接跑,只用权限系统作为唯一防护。
Boris 给的解释:"Our most important principle is this: if you start running Claude Code, it shouldn't change things on your system without permission." 这是 trust model 的差异 —— 不是限制 agent 能做什么,而是要求每个动作都过权限。
第三个反向决策是组织设计:Anthropic 所有人都是同一个 title —— "Member of Technical Staff"。没有 "Senior PM"、"Staff Engineer"、"VP of Design"。Boris 的解释:
"It kind of inverts this relationship between people, even if you don't know each other well yet." — Boris Cherny · 关于 Member of Technical Staff 实践
"反向" 体现在:当所有人都是同一个 title,默认假设就是"每个人都做所有事":产品、设计、基础设施、研究。这跟硅谷主流的"清晰职责 / 严格分工"组织设计相反。Claude Code 团队 10 天造出 Claude Cowork 这个 case,就是这种 fluid 结构的产物 —— 没有 PRD,没有 design 评审,Boris 自己同时做了 product 和工程。
这三个决策不是"故意反范式" —— 是 给定"让模型能力直接显露"这个目标下,推导出的工程结论。RAG 会损失上下文 → 模型能力打折扣 → 选 grep。沙箱限制 agent 行为 → 模型能力打折扣 → 选权限。角色分工切割 task → 模型能力被人为切割 → 选同 title。
抓住这个 "减少 model-product 之间的中介层" 的原则,三个反向决策都是必然结果。复刻 Claude Code 的关键不是抄它的栈,是抄它的"减少中介层"思维。
这是 Boris 在多次访谈中重复的一句话,也是整个复盘里最反工程直觉的一条。大多数产品的 release 节奏是"加功能 / 加代码"。Claude Code 是"减代码"。
具体数据:Claude 4.0 release 后,Claude Code 的 system prompt 被砍掉一半。原因是 Claude 4 在 instruction following、tool calling、context management 几个维度都比 Claude 3.5 强 —— 之前 system prompt 里那些"教 Claude 怎么用工具"的 explicit instructions 不再需要,Claude 自己会做了。
| 模型升级时点 | 被删的代码 / instructions | 原因 |
|---|---|---|
| Claude 3.5 → 3.6 | 大段的"如何选择正确工具"的引导 | 3.6 在 tool selection 已经更准 |
| Claude 3.6 → 3.7 | 多步任务的 "thinking step by step" 模板 | 3.7 自带 extended thinking |
| Claude 3.7 → 4.0 | System prompt 整体减半 | 4.0 在 instruction following、agent skill 全面提升 |
| 4.x 期间 | 各种 fallback 错误处理代码 | Claude 自己能 recover,不需要 deterministic fallback |
| 所有 release | 对"边缘情况"的 explicit 提示 | 模型自己开始处理 edge cases |
这个观察跟 Boris 的另一个判断绑在一起:"product overhang" —— AI 业界讨论的概念,指 模型能力远超当前产品所能 expose 的能力。Boris 直接说:
"We have this belief the model can do much more than products today enable it to do." — Boris Cherny · 关于 Claude Code 的工程哲学
"删代码"的本质就是减少产品对模型的过度引导。每删一行 system prompt,就是承认"我们之前低估了 Claude" + 给它更多空间去 surprise 用户。Claude Code 的 90% 自我编写率,本质就是这种逻辑的极致表现:让 Claude 自己写自己,而不是 Anthropic 工程师写 Claude Code。
这条原则的字面意思是"代码行数减少",但深层意思是把 deterministic 行为(每一行 prompt / fallback / instruction)替换成 model-determined 行为。代码总量没有减少,只是从工程师写的代码 → Claude 自己生成的代码。
这跟"low-code" 不一样。Low-code 是把代码替换成 GUI 配置。Claude Code 的"删代码"是把代码替换成模型的 inference。当模型升级,inference 变强,所以"能 delete 的代码"也变多。
读完 Claude Code 的复盘,实际选型问题是:我下一个 agent 该走哪条路? 当前 agent 工具市场分化出三条主要路径,Claude Code 只是其中一条。每条路径都有 trade-off,但只有一条能跟着模型升级"变强"。
"用工程复杂度补足模型能力"
"让模型能力直接显露"
"LLM 是 workflow 里的一个 node"
代表:Cursor、Continue、Sourcegraph Cody、Devin 早期版本。核心假设:模型能力有限,工程层补足。问题:每次模型升级,工程层的"补足"价值都贬值,但你已经投入了几十万行代码维护它。
代表:Claude Code、Aider(较接近)。核心假设:模型会持续变强,把工程层做薄,让模型能力直接显露。每次模型升级 = 工程价值增加,而不是减少。
代表:n8n、Zapier、Make.com、各种行业 specific RPA 工具。核心假设:LLM 只是 workflow 里的一个 step,大部分决策由 deterministic logic 做。
三个问题快速定位:
① 你愿意把产品长期 bet 在"模型会持续变强"吗? 是 → 走 Claude Code 模式;不是 → 走 Workflow-First 模式。
② 你的客户能容忍 agent 偶尔犯错吗? 能 → minimal harness;不能 → workflow first。
③ 你已经在 Heavy Engineering 路径上投了多少工程债? < 6 个月 → 现在改向 minimal harness;> 12 个月 → 评估迁移成本,可能需要分阶段。
这份复盘公开的不是 trade secret,是一种新的 agent 工程哲学:模型升级 = 工程减负;复杂度 = 中介层 = 模型能力衰减器;agent product = 让模型能力直接显露的最薄一层 harness。
对比同期 Cursor 等"Heavy Engineering"路径:Claude Code 用 10× 少的代码、10× 少的中介层、10× 少的角色定义,做到了 $500M ARR + 80% 内部日活。这不是路径有优劣,是路径选择会决定你能否跟随模型升级"复利变强"。
Q1 答案:真的删了。具体:Claude 3.5 → 3.6 删 tool selection 引导 / 3.6 → 3.7 删 thinking step by step 模板 / 3.7 → 4.0 system prompt 整体减半 / 4.x 期间删各种 fallback 错误处理。共同特征:"教 Claude 怎么做"的代码,Claude 自己学会后删掉。
Q2 答案:真的能,但有边界。Boris 说法是在 100k–1M 行 codebase 上,glob/grep 比 RAG 准。原因:Claude 自己写 query 比 vector reranker 准。> 10M 行规模目前没公开数据,推测会引入分层 indexing,但"模型自己做检索"这条原则不变。
Q3 答案:权限模型够用,但要求清晰。Claude Code 每个"修改系统状态"动作都过权限;读操作不需要权限。Boris 原话:"if you start running Claude Code, it shouldn't change things on your system without permission." 出问题责任在权限授予者,不在 agent。
Q4 答案:核心是 Anthropic 特有,但可以部分复制。Anthropic 全员同 title 是文化基础,大多数公司不可能照搬。可复制的部分:Claude Code 这种 10 人以内的 founding team,故意不分工 / 不写 PRD / prototype-first。
Q5 答案:取决于你的 model bet。如果你 bet 模型会持续变强(并且产品场景容忍偶发错误)→ 学 Claude Code 路径;如果你的场景必须每步可解释 / 合规要求高 → 走 workflow-first;不要走 Heavy Engineering(Cursor 模式)—— 那是模型不够强时代的产物,正在贬值。
Q6 答案:Anthropic 工程师正在变成 "Claude 的 reviewer + architect"。Boris 自己每天产出 20-30 PRs,实际编码 < 10%,大部分时间在 plan / review / context switch。这跟 Anthropic 12 月公开的内部研究一致:工程师角色重心从"写"转到"审 + 系统判断"。
你正在最幸运的位置 —— 还没有工程债,可以直接走 Claude Code 路径。具体行动:① 选栈走 on distribution(TypeScript + React 类),不要因为"工程师喜欢 Rust" 选 Rust;② 不要建 RAG / 向量数据库 / chunking pipeline,先用 glob + grep + Claude 自己 search;③ 不要建沙箱,用权限系统;④ 团队 < 10 人时,不要分工种 / 不要写 PRD,所有 spec 都是 working prototype。
关键纪律:当你的工程师说"我们应该建一个 X(RAG / 微服务 / orchestrator / 沙箱)"时,先问 "Claude 5 / 6 会不会让这个 X 失效?" 如果答案是 "会",就不要建。Claude Code 的核心方法论 = 不为现在的模型能力建工程层,只建跟模型能力升级方向一致的部分。
你已经有 RAG / 向量数据库 / 多层 prompt scaffolding / 沙箱。完全推倒重建不现实,但 Claude 4 / 5 的能力已经让你工程层的部分价值贬值。具体行动:audit 每一层 scaffolding —— ① 这层在 Claude 3.5 时代必须吗?② Claude 4 之后还必须吗?③ Claude 5 之后会不会完全多余?如果答案是 "Claude 5 之后会多余",现在就开始减薄它,不要等。
关键纪律:不要把 Claude Code 路径当成"反 Cursor 的政治正确"。它是工程决策,不是品牌站队。如果你的工程层在为客户提供真实价值(合规 / 可解释性 / 数据隔离 / 特定行业需求),保留;如果它只是"补足模型能力不足",抓紧减薄。模型每升级一次,你的工程债就涨一次。
Claude Code 复盘对你最大的启发不是技术,是 组织设计。Anthropic 的 "Member of Technical Staff" 同 title 制是文化基础 —— 你很难直接复制,但可以学习它的实质:在 founding team 阶段(< 10 人),刻意不引入"PM / Designer / Engineer / DevOps" 等角色分工,让每个人在 Claude 辅助下做所有事。这能产生 "10 天造出 Cowork" 这种速度。
关键纪律:不要在团队 > 20 人之前引入 role-based silos。一旦引入,你就回不到 Claude Code 那种 fluid 速度。这条原则的代价是:你需要招"能在 Claude 辅助下做多种事"的 generalist,而不是某个 domain 的 specialist。这种人在硅谷招聘市场上少,但回报高。
| # | 信号 | 触发判断 / 动作 |
|---|---|---|
| 1 | Claude 5 release 时 Claude Code system prompt 是否再次减半 | 减 = "删代码" ritual 持续 / 不减 = 模型升级红利在收窄 |
| 2 | Cursor / Continue 是否开始公开"减薄 RAG"实践 | 跟进 = 行业级 framing 转变 · Heavy Engineering 路径在收缩 |
| 3 | Claude Code 是否引入 vector index(打脸自己) | 引入 = glob/grep 路径有边界 / 不引入 = 路径继续 |
| 4 | Anthropic 是否开始公开 Claude Code 内部 telemetry | 公开 = 内部研究文化形成 · 复盘 ritual 持续 |
| 5 | Boris Cherny 的"5 parallel Claudes / 20-30 PR/day"是否在外部公司复现 | 复现 = 工程师工作流真的在重构 / 不复现 = Anthropic 特有 |
| 6 | "Member of Technical Staff" 实践是否在其他 AI 公司出现 | 出现 = 组织 framing 扩散 · 角色分工时代结束 |
| 7 | Claude Cowork 增长曲线 vs Claude Code 当年 | 持续陡 = 非工程师采用率验证"用户范围"扩展 |
| 8 | Devin / Manus 等 cloud-VM agent 是否转向本地运行 | 转向 = 沙箱路径在收缩 / 不转 = 安全 / 合规需求维持 |
| 9 | Anthropic 是否公开 system prompt 内容 | 公开 = "可被复刻"的 transparency / 不公开 = 还有商业敏感 |
| 10 | Claude Code "on distribution" 栈选择是否被 Gemini Code / GPT-5 Code 复制 | 复制 = "on distribution" 成为行业级原则 · Rust / Go 写 agent 工具的浪潮结束 |
"复杂工程不是 agent 的护城河,
是 agent 的工程债。Claude Code 用 19 个月证明了这件事。"
· "How Claude Code is built" · Gergely Orosz · The Pragmatic Engineer · 2025.09.23 · newsletter.pragmaticengineer.com
· "Building Claude Code with Boris Cherny" · Gergely Orosz · 2026.03.04 · newsletter.pragmaticengineer.com
· "Head of Claude Code: What happens after coding is solved" · Lenny's Newsletter · Boris Cherny 访谈 · lennysnewsletter.com
· "How to Use Claude Code Like the People Who Built It" · Every · Boris Cherny + Sid Bidasaria + Catherine Wu 访谈 · every.to
· "Anthropic Co-founder: Building Claude Code" · YC Startup Library · ycombinator.com
· "How AI Is Transforming Work at Anthropic" · Saffron Huang 等 · 2025.12.03 · anthropic.com
· Anthropic Engineering Blog · 多篇 Claude Code 相关 postmortem · anthropic.com/engineering