Boris Cherny

摘要

Boris Cherny 是 Anthropic Claude Code 的创建者与负责人,被广泛视为 "agentic coding"(智能体编程)这一新范式的核心架构师之一。他出生于乌克兰 Odessa 的犹太移民家庭,18 岁从经济学专业辍学创业,辗转创业公司与对冲基金,后在 Meta 的 Facebook Groups 与 Instagram 做了大约七年工程,一路升到 Principal Engineer(IC8)。2024 年 9 月,他作为 founding engineer 加入 Anthropic 的 Labs 团队——没有任何"做一个编程产品"的指令。

Claude Code 的起点是一个玩具:Boris 给模型接上 bash 工具,问它"我现在在听什么歌",模型自己写了 AppleScript 去查询他 Mac 上的音乐播放器。他把那一刻称为自己"第一个 holy shit AGI moment"。这个在终端里跑的小东西在 2024 年 11 月内部发布,第一天就有 20% 的 Anthropic 工程师在用,第五天到了 50%;2025 年 2 月公开预览,5 月全面发布。到 2026 年,Claude Code 已贡献了公开 GitHub commits 的约 4%,Anthropic 的估值从 $4B 涨到 $45B,需求同比 80 倍增长。

Boris 本人则是这场范式转变最极端的样本:自 2025 年 11 月起,他没有手写过一行代码,日常并行运行 5–10 个 Claude session、单日 PR 记录达到 150 个、30 天内 259 个 PR / 497 个 commit。他反复用"印刷术"作为这个时刻的历史类比,断言"对我做的那类编程而言,coding 已经被解决了",并预测"软件工程师"这个头衔会消失、取而代之的是范围大得多的"builder"角色。他的产品方法论(latent demand、unship tools、build for the model six months from now)与个人哲学(乡村日本做味噌、祖父在苏联用打孔卡编程的三代家族史)交织在一起,构成了一个罕见的"被自己造的工具彻底改变了的人"。

说明:档案以 Claude Code 时期(2024.9 起)为重心展开,早年与 Meta 阶段作为理解其工程哲学根源的铺垫。文中事实均标注来源;基于事实的推断会明确标注为"[推断]"。部分关键访谈(如 Lenny's Podcast)原始 transcript 在付费墙后,相关内容通过多篇二手详尽摘要交叉还原,已尽量标注。

一、生平时间线

早年:Odessa 移民、辍学创业(约 1991–2011)

Boris Cherny 出生于乌克兰 Odessa 的一个犹太家庭,1995 年随家庭移民离开(据 WIRED 2026 年 5 月报道其时年 34 岁,推算生于 1991–92 年)。在 Lenny's Podcast 上他与主持人 Lenny Rachitsky 发现彼此都来自 Odessa——Lenny 1988 年离开、Boris 1995 年离开——两人都对"幸好离开了"心怀感激,坦言若家庭留下,人生会截然不同。[Lenny's via Ernest Chiang]

他的家族有一条贯穿三代的编程史,这后来成了他理解 AI 编程的私人坐标系:

"Programming has always changed. My grandpa programmed on punch cards in the Soviet Union 70 years ago... Before that, programming was a room full of people — often women — doing math on paper."

"编程一直在变。我祖父 70 年前在苏联用打孔卡编程……再往前,编程是一屋子人——往往是女性——在纸上做数学。"

Platformer (Casey Newton), 2026-05

他还提到,母亲小时候会用蜡笔在那些打孔卡上画画。[Anthropic 官方播客, 2025-06]

他在 UC San Diego 读经济学(约 2009–2011),但 18 岁就开了第一家公司并辍学。他对正统 CS 教育始终带着一种"实用主义者"的怀疑:

"Programming is just such a practical skill... If you're in a data structures class and you're running this but haven't built a product, how is it relevant at all?"

"编程就是一门极其实用的技能……如果你在上数据结构课、跑着这些东西,却从没造过一个产品,那它到底跟现实有什么关系?"

Developing.dev (Ryan Peterman), 2025-12

关键铺垫:摩托车事故与"用更少做更多"

• 背景: 约 2015 年(据 Implicator.ai 报道,文章发表前"大约十年"),Boris 遭遇一场摩托车事故,双臂骨折,有大约一个月无法正常敲代码。
• 关键假设: 既然敲键盘成本高昂,那就去找"键入更少"的语言和工具。
• 决策: 康复期间他开始追逐更省 keystroke 的语言——先是 CoffeeScript,然后 Haskell,最后落到 TypeScript。
• 结果: 这条路直接通向他 2019 年写出 O'Reilly 的《Programming TypeScript》(第一本 TypeScript 专著),并在 SF 组织 TypeScript Meetup。Implicator.ai 把这次事故称作他整个工程哲学的伏笔——一种"用更少做更多 / there's always a way to do more with less"的本能。[推断:这条因果链是 Implicator.ai 的叙事建构,Boris 本人未必如此明确归因,但与他后来"unship tools""minimal scaffolding"的偏好高度一致]

这段时期他的职业路径是:第一家创业公司(18 岁)→ 若干小公司与对冲基金 → AgileMD(约 2012–13,首位前端工程师)→ Turn(2014,Lead Software Engineer)→ Coatue Management(约 2015–17,Architect,即他口中的"hedge fund"经历)。[LinkedIn/The Org 拼合]

Meta 七年:在巨型组织里学会"人的问题"(约 2017–2024)

Boris 2017 年加入 Meta/Facebook,以 mid-level(E4)身份进入——尽管他此前已有相当资历。他事后认为"低级别进入"反而是一种优势:

"Coming in under leveled gave me the space to explore and just build cool stuff for the sake of building cool stuff."

"以低于实际水平的级别进来,反而给了我空间去探索、纯粹为了造好玩的东西而造东西。"

Developing.dev (Ryan Peterman), 2025-12

他在 Meta 的七年(从 IC4 一路升到 IC8 Principal)主要做两件事:大规模代码迁移与代码质量。这段经历塑造了他后来在 Claude Code 上的几乎所有直觉。几个关键项目:

"If you don't know the systems, nowadays, you would just use Claude Code, run in the codebase, and ask it, 'What are all the systems involved?' It can actually do this for you."

"如果你不了解这些系统,现在你只要在代码库里跑 Claude Code,问它'这里面涉及哪些系统?'它真的能帮你搞定。"

Developing.dev (Ryan Peterman), 2025-12

关键决策二:Latent demand 的第一课(Facebook Groups / Marketplace)

Boris 早期在 Facebook Groups 做"Chats in Groups",把 Messenger 与 Groups 拉近。正是在这里他第一次形成了贯穿一生的产品信念——latent demand(潜在需求):观察用户如何"滥用"你的产品,然后顺着那个方向去建。

"Latent demand is the single most important principle in product. If you look at Facebook's successful products, every single one has an element of latent demand."

"潜在需求是产品里最重要的单一原则。看看 Facebook 那些成功的产品,每一个都带有潜在需求的成分。"

Developing.dev (Ryan Peterman), 2025-12

他最爱举的例子:Facebook Groups 当时约 40% 的帖子是在买卖东西——Groups 根本不是为商业设计的,但人们就是这么用的,这直接催生了 Facebook Marketplace。Facebook Dating 同理:他们发现约 60% 的资料页浏览发生在互不为好友的异性之间。[Every.to, 2025-10;Developing.dev]

关键决策三:"Disagree, execute, course-correct"(Public Groups / 与 Bob 之争)

在做 Public Groups(允许不加入群组也能评论)时,Boris 与一位资深工程师 Bob 在数据模型架构上意见相左。他的做法不是争辩,而是先彻底地、忠实地执行 Bob 偏好的方案,然后用实现本身证明它行不通,最终说服 Bob 亲手撤掉整个倡议。

"You have to earn it. You just have to earn trust. It could be as simple as what I did at the beginning, which is just disagree and commit and showing that I'm willing to do that."

"你得去挣得它。你必须挣得信任。可以简单到像我一开始做的那样——先反对、再投入执行,用行动表明我愿意这么做。"

Developing.dev (Ryan Peterman), 2025-12

Implicator.ai 把这套模式命名为他的招牌打法:"Disagree, execute, course-correct"(异议、执行、再纠偏)——与 Amazon 的 "disagree and commit" 相似,但多了一个用实现来反向验证的闭环。

关键决策四:Instagram Python→Hack 迁移(晋升 Principal)

当未婚妻(后来的妻子)在日本乡下找到工作时,Boris 在 Meta 内部找机会,Instagram 东京办公室的 Will Bailey 招了他:

"I didn't know anything. I didn't even have Instagram installed at the time. I'd never used it in my life. I said yes, and then I immediately downloaded Instagram and moved the next week or something."

"我什么都不懂。当时我连 Instagram 都没装。这辈子都没用过。我答应了,然后立刻下载了 Instagram,大概下一周就搬过去了。"

Developing.dev (Ryan Peterman), 2025-12

在东京,他识别出 Instagram 代码库的关键技术债(还停留在 Python、缺少 Hack/HHVM/GraphQL 优化),并主导迁移。他处理迁移的方式高度"人本":先去找那些最可能反对的资深工程师——

"I brought food in New York, and we got a bunch of beer and got to know them as people before we even talked about the technical problem."

"我在纽约请大家吃东西,我们搞了一堆啤酒,在谈技术问题之前,先把彼此当成活生生的人来认识。"

Developing.dev (Ryan Peterman), 2025-12

他的结论被 Implicator.ai 概括为:"The hardest engineering problems are usually people problems."(最难的工程问题通常是人的问题。)

关键决策五:把自己从 code review 里自动化掉(lint rule 的起源)

这是一个直接预示 Claude Code "compounding engineering" 哲学的 Meta 故事。Boris 注意到自己在 code review 里反复写同样的评论,于是:

"I literally had a spreadsheet where I would tally up that issue... When I commented about the same kind of thing more than a few times, I would just write a lint rule for it."

"我真的有一个电子表格,把那个问题计数……当我对同一类东西评论了好几次以上,我就直接为它写一条 lint 规则。"

Developing.dev (Ryan Peterman), 2025-12

"自动消除自己重复劳动"的这个本能,后来变成了 Claude Code 里 CLAUDE.md 的核心理念:没有人应该被迫指出同一个问题超过一次,每个错误都该变成一条规则。

关键决策六:Groups 600+ 工程师的 scoping(管理规模化的教训)

在 Zuck 下达"社区建设"指令后,Facebook Groups 组织从 150 人暴涨到 600+ 工程师。Boris 负责为一批批 20–30 人的工程师做技术 scoping。最经典的故事是他用"设计竞赛"打破资深 tech lead 之间的决策僵局——让 Blue 队和 Green 队并行在白板上设计 Groups-Pages 数据模型合并方案,3 小时后发现两个设计 80% 相同,于是立刻锁定那 20% 的差异作为真正的风险点去前置攻关。

他事后的反思很关键(也预示了 Claude Code 团队"故意人手不足"的原则):

"What matters is solving people's problems and building awesome product. This has to be bottoms up; you want to slowly dial this up as you find product market fit for new product lines."

"重要的是解决人们的问题、造出色的产品。这必须是自下而上的;你应该在为新产品线找到 product-market fit 的过程中,慢慢地把人手加上去。"

Ryan Peterman, 2026-01

他对管理规模化的另一句总结:

"The biggest failure mode I've seen is people taking too long and getting too into the weeds. There's always an infinite number of details."

"我见过的最大失败模式,是人们花太长时间、陷进太多细节里。细节永远是无穷无尽的。"

Ryan Peterman, 2026-01

Meta 时期的一个潜在危险,也被他识别出来:走向高级别后容易脱离代码。东京的时区隔离反而"意外地"把他逼回了一线编码——

"This was actually very dangerous because as an engineer, you need to be anchored to reality. You need that intuition. If you're not in the code anymore, then you lose it very quickly."

"这其实非常危险,因为作为工程师,你需要锚定在现实里。你需要那种直觉。如果你不再碰代码,你会非常快地失去它。"

Developing.dev (Ryan Peterman), 2025-12

转向 Anthropic:在日本乡下被 ChatGPT 击中(2024)

Boris 和伴侣在日本乡村生活了大约四五年。他是村里唯一会说英语的人,也是唯一的工程师。他在那里做味噌(白味噌 3 个月,红味噌 2–4 年),这种"长时间尺度"的生活节奏后来被他多次提及。正是在这种近乎隐居的状态里,ChatGPT 出现并改变了他对世界的看法。[Lenny's via Ernest Chiang; WIRED]

他对 LLM 的理解此时发生了根本转变,从"工具"变成了某种近乎生命的存在:

"To me, LLMs are this kind of alien life form that we get to nurture and bring into existence... AI is transformative to society."

"对我来说,LLM 是一种外星生命体,我们得以去培育它、把它带到存在之中……AI 对社会是变革性的。"

Developing.dev (Ryan Peterman), 2025-12

为什么是 Anthropic 而非别处? 答案是 mission——具体说是 safety。他在 Meta 时,合规/integrity 工作被视为一种"税":

"At Meta, it was always seen as a tax where integrity teams get you to do stuff, but it's not really the thing anyone's excited to do because it's not the product."

"在 Meta,它总被看作一种税——integrity 团队让你去做些事,但那不是任何人真正兴奋去做的东西,因为它不是产品本身。"

Developing.dev (Ryan Peterman), 2025-12

在 Anthropic,safety 不是税,而是产品和使命本身。他在与联合创始人 Ben Mann 见面后被这个使命"won over"(打动)。这条 mission 线索极其重要——它是后来他从 Cursor 两周回归的根本原因(见下文)。

二、Claude Code 时代(2024.9–2026):起源、设计与扩张

这是本档案的重心。以下按"起源故事 → 核心设计哲学 → 产品决策 → 组织文化 → 个人工作流 → 战略扩张"展开,尽量用 Boris 自己的原话还原他的思路。

2.1 起源故事:一个查歌的玩具,如何变成 Claude Code

Boris 2024 年 9 月加入 Anthropic 的 Labs 孵化团队,没有任何"做编程产品"的指令(这是他本人在 Platformer 的口径;Anthropic 2026 年 7 月的官方口述史给出了不同版本——见本节末"官方口述史的补正")。他当时在学 Anthropic API,于是造了"可能最便宜的东西":

"[I] built the cheapest possible thing — a little thing that ran in the terminal, so I didn't have to build a user interface or an app."

"我造了可能最便宜的东西——一个跑在终端里的小玩意,这样我就不用去建用户界面或者 app。"

Platformer (Casey Newton), 2026-05

注意:终端优先(terminal-first)从一开始就不是出于极简主义美学,而是因为他不想建 UI。 这个"懒惰"的起点后来被证明是关键的架构智慧。

在他加入时,Anthropic 内部已有一个前身工具,叫 "Clide"(C-L-I-D-E)——一个需要 Python 索引、启动很慢(执行一个任务要 5 分钟)的研究项目。他的 manager Adam Wolf(Wolff) 在拒绝了他一个手写的 PR 后,推他去用 Clide。Boris 坦承:"I didn't know about any of these tools."(我当时根本不知道有这些工具。)他后来用 API 在终端里搭了个聊天 app,本想复刻 Clide,结果"it actually ended up being a lot more useful than that"(最后比那有用多了)。[Every.to, 2025-10]

决定性的一刻:给模型 bash,它自己学会了用工具

最初的原型甚至读不了文件、跑不了 bash。Cat Wu(当时在研究 AI agent 的电脑使用能力,后成为 Claude Code 的 Head of Product)建议给原型更多文件系统权限。Boris 照做后:

"I tried giving it some tools to interact with the filesystem and to interact with the bash; it could read files, write files, and run bash commands. Suddenly, this agent was really interesting."

"我试着给它一些工具去跟文件系统、跟 bash 交互;它能读文件、写文件、跑 bash 命令。突然之间,这个 agent 变得非常有意思。"

Pragmatic Engineer (Gergely Orosz), 2025-09

而他的"第一个 holy shit AGI moment",是一个查歌的请求:

"My first holy shit AGI moment was when I gave the model the Bash tool and asked it what music I was listening to. It wrote AppleScript to script my Mac."

"我第一个'我靠这就是 AGI'的时刻,是我给模型接上 Bash 工具、问它我在听什么音乐。它写了 AppleScript 去操控我的 Mac。"

Y Combinator, 2026-02

这件事教给他一个贯穿 Claude Code 设计的核心认知:模型本身就想用工具,你不需要替它把一切编排好。

"The model just wants to use tools. We give it bash and they just started using bash."

"模型就是想用工具。我们给它 bash,它们就直接开始用 bash 了。"

Every.to, 2025-10

他把模型能力与现有产品之间的鸿沟称为 "product overhang"(产品悬置)——模型其实早就能智能地探索代码库(读文件、跟着 import 链走),只是没有产品把这个能力释放出来。

"There is an intense feeling that the model can do all these things, but there is no product that lets it do that."

"有一种强烈的感觉:模型能做所有这些事,但没有一个产品让它去做。"

Platformer (Casey Newton), 2026-05

从内部爆红到公开发布:那张"垂直三天"的日活曲线

• 2024 年 9 月: Boris 加入,搭出初始原型。
• 2024 年 11 月: 内部发布。第一天 20% 工程师采用,第五天 50%。同月 Sid Bidasaria 加入 Anthropic 并立刻被 Claude Code 吸引,成为第二位核心工程师。
• 2024 年 12 月: 拿到公开化"绿灯";此前"就只有 Sid、Boris,外加一点 Ben"在做,绿灯后 Labs 与其他团队 6–7 人加入,进入最后两周冲刺——bug reporting、登录流等核心功能在这两周建成。[Making of Claude Code, Sid Bidasaria;⚠️PR]
• 2025 年 2 月 24 日: 随 Claude 3.7 Sonnet 一起公开预览。同月 "Claude CLI" 正式改名 "Claude Code"——名字由 Product Marketing 的 Alex Isken 提议,"我们喜欢它的简单"。[Making of Claude Code, Cat Wu;⚠️PR]
• 2025 年 5 月: 全面公开发布。
• 2025 年 7 月: 团队约 10 名工程师。
• 2025 年 9 月: $500M+ 年化营收,自 5 月发布以来用量增长 10 倍。
• 2026 年 6 月: 年化营收 run rate 超过 $2.5B(Fortune Brainstorm Tech 场合披露);Fortune 同期报道提及 Anthropic IPO 后估值约 $965B。

关于是否公开发布,团队内部有过真实的犹豫——担心这是 Anthropic 的"秘密武器"。最终拍板的,是一张内部日活曲线:

"The daily actives chart was vertical for like three days straight. We were like, 'All right, this is crazy. This is a hit."

"日活曲线连续三天都是垂直的。我们当时就想,'好吧,这太疯狂了。这是个爆款。"

Anthropic 官方播客, 2025-06

而最终说服他们公开的根本理由,是 Anthropic 的 safety 使命(见 2.6 节):

"Anthropic, at its core, is a model safety company. The way we learn about model safety and capabilities is that we make tools people use."

"Anthropic 的内核是一家模型安全公司。我们了解模型安全与能力的方式,就是去造人们真正会用的工具。"

Pragmatic Engineer, 2025-09

官方口述史的补正:linter、"Claude CLI" 与被压住的扩编(2026-07,⚠️PR)

2026 年 7 月前后,Anthropic 发布了一篇多声部口述史《The Making of Claude Code》(Ben Mann、Shauna Kravec、Dawn Drain、Adam Wolff、Raphael Lee、Sid Bidasaria、Cat Wu 等十余人,Boris 本人亦在列)。它是公司自我叙事(⚠️PR),但对本节有三处实质补正:

(1)"没有指令"的另一个版本。 上文 Boris 在 Platformer 说自己加入时没有任何"做编程产品"的指令;口述史里三位当事人的说法都更具体——Ben Mann 说 Labs 是他 2024 年 1 月创立、"看到 agentic coding 有一个市场空洞";Labs 首任 EM Raphael Lee 说"Boris 被分到了 agentic coding 这个领域";Boris 自己则说:

"My starter project was to 'automate coding.' So I thought, 'Okay, first I need to learn how to use the API,' because I hadn't used it yet. I started playing around, but I didn't know what we wanted to build, exactly."

"我的入门项目是'自动化编程'。所以我想,'好,首先我得学会用 API',因为我还没用过。我开始随便玩,但并不确切知道我们想造什么。"

Boris Cherny, Anthropic "The Making of Claude Code" (~2026-07)

两种口径可以同时为真——有"领域",没有"产品"。更有信息量的是 Ben Mann 补的一句:Boris 最初想做的是一个 linter,"想咬下 agentic coding 的一小块",被他挡回去——"No, no, no, no, you have to do the big thing."(⚠️转述:Ben Mann 口述 Boris 当时的想法。)[推断] 对照 §一:linter 正是他在 Meta 把自己从 code review 里自动化掉的那件事(关键决策五)——他的第一反应是把旧解法搬到新公司,而"做大的"这一推力来自 Ben Mann。

(2)"Claude CLI" 的 demo 帖。 口述史嵌入了他当时在内部频道发的 demo 帖,是这个产品最早的一手文字:

"I wanted to show off a new tool I've been hacking on: Claude CLI. I built it as a new standalone tool, separate from clide, from the ground up. The motivation is: 1. To start to get a feel for the DevX of LLMs on the CLI 2. To stand up a foundation for Labs' upcoming experiments with agentic coding."

"想给大家看一个我最近在捣鼓的新工具:Claude CLI。我把它作为一个独立于 clide、从零开始的新工具来做。动机是:1. 开始感受一下 LLM 在 CLI 上的 DevX;2. 为 Labs 接下来的 agentic coding 实验搭一个地基。"

Boris Cherny 内部 demo 帖,经 Anthropic "The Making of Claude Code" 转载 (~2026-07)

帖子列出的特性里已经有 "Tool use: read/write from fs, run bash commands, see the screen, make network calls"、"Plugins" 与 "Permission model for tools w/ per-instance and per-directory opt in"——[推断] 2.3 的多层权限系统与 hackable 平台取向,在第一天的 demo 帖里就已成形。他对这个 demo 的回看是:"没人看懂 Claude CLI 的 demo 是什么。我自己其实也不太懂……但现在回头看,原始的元素都还在"——"大约两天的工作量;今天用 Claude Code 重做只要两分钟"。(查歌轶事在这里的版本是"它截了 Apple Music 的图然后读出来",与 YC 版"写了 AppleScript"略有出入,照录。)前身 clide 的谱系也首次清楚:Shauna Kravec 所造(名字由 Eli Tran-Johnson 为更早的形态所起)、Dawn Drain 加上了没有 bash 工具的"baby agentic"能力;而"Claude Code 其实没欠 clide 多少——一旦跨过模型能力阈值,形态自己就会显现"这句话,出自 Dawn Drain 而非 Boris。

(3)"战略性人手不足"最初不是他的选择。 2.4 把 strategic underfunding 列为团队三原则之一;口述史显示这条原则的起点是一场他输掉的争执:

"In October 2024, I was working on it so hard. Every week, I was like, 'Raph, give me engineers, please!"

"2024 年 10 月,我拼命在做这个东西。每周我都在说,'Raph,给我工程师,求你了!"

Boris Cherny, Anthropic "The Making of Claude Code" (~2026-07)

Adam Wolff 的回忆是"Boris 猛推快速扩张,我想要的是反面,我尽可能把它压住了";Raph Lee 说团队主要靠内部转岗和"缓慢、高质量的外部招聘"长大。Boris 事后承认:

"In hindsight, keeping the team small was actually very important to our success. It helped us be really creative with resources, and kept us from overengineering. And it forced us to use Claude more. Otherwise, we couldn't go fast enough."

"事后看,把团队保持得很小对我们的成功其实非常重要。它让我们在资源上非常有创造力,让我们不至于过度工程化。而且它逼我们更多地用 Claude——否则我们跑不够快。"

Boris Cherny, Anthropic "The Making of Claude Code" (~2026-07)

[推断] 这意味着 2.4 的"strategic underfunding"是被动约束事后升格为主动原则——一个被证明正确的、不是自己做的决定。Sid 还补了两个早期工程细节:代码库"没有 PR 限制、没有 review 限制,修复即发";Boris 很早就建了自动更新与用户埋点,于是有人抱怨五分钟后就能收到修复——这是 2.4 "ant-fooding" 回路的技术前提。起飞的归因,Boris 给了两项——"一项商业模式创新(订阅)加一项模型创新";他自己的使用轨迹,口述史只在既有两端(2.2(a) "很长一段时间只用在 10% 的代码上"、2.5 "自 2025 年 11 月起 100%")之间补了一个中间点:2025 年 5 月(Sonnet 4 发布、Code with Claude 大会后台)约 30–40%。

2.2 核心设计哲学:"让人尽可能原始地感受模型"

如果要用一句话概括 Boris 的产品哲学,就是这句:

"This might sound weird, but the way we build this is we want people to feel the model as raw as possible. We have this belief the model can do much more than products today enable it to do."

"这听起来可能有点怪,但我们构建它的方式是——我们想让人尽可能原始地感受到模型。我们坚信模型能做的,远比今天的产品允许它做的多得多。"

Pragmatic Engineer, 2025-09

从这条信念出发,衍生出几条彼此呼应的具体原则。

(a) "Build for the model six months from now"(为六个月后的模型而建)

这是 Anthropic 联合创始人、Boris 的 manager Ben Mann 给他的关键建议——也是 Anthropic 这家"因 Scaling Laws 而生"的公司的信仰(三位创始人是 Scaling Laws 论文的合著者)。

"Don't build for the model of today. Build for the model six months from now."

"不要为今天的模型而建。为六个月后的模型而建。"

Ben Mann(经 Boris 转述),Implicator.ai / Y Combinator

Boris 一开始是怀疑的。事实上很长一段时间 Claude Code 都不是个好产品:

"For a long time, Claude Code was not a great product. Even when it was used internally, I used it for maybe like 10% of my code."

"很长一段时间里,Claude Code 都不是个好产品。即便在内部使用,我大概也只把它用在我 10% 的代码上。"

Developing.dev (Ryan Peterman), 2025-12

但他在使用数据和自己的编码里都看到了那条指数曲线掰过来的拐点(Sonnet 4 / Opus 4 前后),于是这条建议成了他现在传授给所有 YC 创始人的核心:

"At Anthropic, we don't build for the model of today, we build for the model of six months from now. And that's still my advice to founders that are building on LLMs."

"在 Anthropic,我们不为今天的模型而建,我们为六个月后的模型而建。这至今仍是我给所有在 LLM 上构建产品的创始人的建议。"

Y Combinator, 2026-02

(b) "Scaffolding is tech debt" / "We want to unship tools"(脚手架就是技术债)

既然模型每六个月就更强一截,那么所有你为了弥补"当前模型不足"而搭的脚手架,都该被视为注定要删的技术债。

"Assume that whatever scaffolding you build is just tech debt."

"假设你搭的任何脚手架都只是技术债。"

Y Combinator, 2026-02

"We want to unship tools and kind of keep it simple for the model."

"我们想把工具'下架',为模型保持简单。"

Every.to, 2025-10

这不是口号。最初 Claude Code 有很多自定义工具(search、LS 等),后来他们为 bash 建了权限系统,就直接删掉了 LS 工具。每出一个新模型,他们就删代码:

"I just deleted like 2,000 tokens or something from the system prompt yesterday. Just because Sonnet 4.5 doesn't need it anymore. But Opus 4.1 did need it."

"我昨天刚从 system prompt 里删了大概 2,000 个 token。就因为 Sonnet 4.5 不再需要它了。但 Opus 4.1 当时是需要的。"

Every.to, 2025-10

(据 Pragmatic Engineer,Claude 4.0 发布时他们删掉了大约一半的 system prompt。)

(c) "Don't box the model in. Give it a tool."(别把模型框死,给它工具)

这是 bash 时刻的直接推论,也是 Claude Code 与那一代"高度编排 workflow"的 AI 编程产品最根本的分野。

"The way to think about it is the model is its own thing. You give it tools."

"正确的思考方式是:模型是它自己独立的存在。你给它工具。"

Pragmatic Engineer, 2026-03

"Don't try to make the model behave a very particular way... If you just give the model tools, you give it a goal and you let it figure it out."

"别试图让模型以某种非常特定的方式行事……你只要给模型工具、给它一个目标,然后让它自己想办法。"

Pragmatic Engineer, 2026-03

在 Lenny's 上他把这句话浓缩成一个口号式的反转:

"Ask not what the model can do for you. Just think about how do you give the model the tools to do things."

"不要问模型能为你做什么。只去想,你如何给模型工具,让它去做事。"

Lenny's Podcast, 2026-02

(d) "We want to be unopinionated and get out of the way"(不强加观点,让开路)

终端优先的真正含义,不是怀旧或极客美学,而是"最低限度、不强加观点、最高生产力"。

"There's no cursor. There's no scroll back. There's no fancy commands. There's no type ahead. There's pretty much nothing."

"没有光标。没有回滚。没有花哨的命令。没有自动补全。基本上什么都没有。"

AI Engineer, 2025-07

"We want to be unopinionated and we want to get out of the way. So we don't give you a bunch of flashy UI. We don't try to put a bunch of scaffolding in the way."

"我们想保持不强加观点,我们想让开路。所以我们不给你一堆花哨的 UI,也不试图在中间塞一堆脚手架。"

AI Engineer, 2025-07

Cat Wu 补充了终端的深层优势——它消除了人与模型能力之间的落差:

"It just means that, okay, everything you can do, Claude can do. There's nothing in between."

"这意味着,好,你能做的一切,Claude 都能做。中间没有任何隔阂。"

Every.to, 2025-10

Boris 还有一个反直觉发现:为人设计的优雅工具,几乎原封不动地对模型也很好用。

"Surprisingly, it's the same. I sort of feel like this kind of elegant design for humans translates really well to the models."

"出人意料地,它们是一样的。我隐约觉得,这种为人类做的优雅设计,迁移到模型身上效果也非常好。"

Every.to, 2025-10

(e) Ablation-first:每代新模型,先删掉再逐行加回

到 Opus 5 发布(2026-07),"unship" 已经从纪律固化成一套方法论——他直接借用研究里的 ablation(消融实验) 一词:

"Every time there's a new model, in research, we call this ablation... you delete the entire system prompt, and then you bring it back line by line to figure out what is the impact of each individual line... Ablation essentially is an eval, but you delete things to figure out the impact."

"每出一个新模型——在研究里我们管这叫 ablation……你把整个 system prompt 删掉,然后逐行加回来,搞清楚每一行各自的影响……ablation 本质上是一种 eval,只不过你靠删东西来度量影响。"

Y Combinator Startup School(与 Diana Hu), 2026-07

这轮的结果是一个具体数字:Opus 5 发布时,他们删掉了 Claude Code 80% 的 system prompt——"很多内容只是在纠正旧模型本该会但不会的行为"。他们甚至开放了实验通道:--system-prompt 参数任由用户替换 prompt,以及 simple mode(删除包括工具在内的全部 system prompt),团队自己就用它做消融对照。[YC Startup School, 2026-07]

"If you look at the code that's in the Claude Code harness today, almost all of it is about safety and permissions and static analysis."

"如果你看今天 Claude Code harness 里的代码,几乎全部都是关于安全、权限和静态分析的。"

Y Combinator Startup School, 2026-07

[推断] 这给 2.2b 的"脚手架就是技术债"补上了终态图景:harness 的稳态价值不在能力(能力会被模型吃掉),而在安全边界与验证基建——这正是他"Domain Insight ∩ Systems Thinking ∩ Verification"护城河定义在产品架构上的投影。

(f) "Product overhang":模型早就会了,是产品在碍事

同场访谈里他给出了一个与 latent demand 成对的新概念——研究侧叫 unhobbling(解除束缚),产品侧叫 product overhang(产品悬垂):

"The idea is the model is able to do all sorts of things with today's models — not a future model — that we have not yet realized... The product gets in the way. And this getting in the way, we call this hobbling; and then not eliciting the correct behavior from the model, we call this product overhang. So it's kind of like two sides of the same thing."

"这个概念是说:就用今天的模型——不是未来的模型——它能做各种我们还没意识到的事……产品会碍事。这种碍事,我们叫 hobbling;而没有把模型的正确行为引出来,我们叫 product overhang。它们是同一件事的两面。"

Y Combinator Startup School, 2026-07

他把 Claude Code 的诞生本身追认为一次 unhobbling:当年模型已能整段写函数,而产品世界只给它单行补全和只读聊天框(Diana Hu 补充:Claude Code 是最早给 Sonnet 3.5 完整终端权限的产品之一)。而对今天:

"With modern models, there is so much product overhang that I'm not seeing startups capture."

"以现代模型而言,product overhang 大到惊人,而我没看到创业公司在捕捉它。"

Y Combinator Startup School, 2026-07

[推断] latent demand 与 product overhang 构成他产品方法论的对称双翼:前者从用户侧找被压抑的需求(看人们如何"滥用"产品),后者从模型侧找被压抑的能力(看模型能做而产品没让它做的事)。两者的动作都是"移开障碍",而非"添加功能"。

2.3 关键产品决策(幕后)

决策:抛弃 RAG,改用 agentic search(grep + glob)

这是 Claude Code 最被工程圈讨论的反直觉决策之一。团队试过很多基于向量的 RAG(retrieval-augmented generation)方案,最终全部抛弃,改用"让模型自己用 grep / glob 去搜"的 agentic search。

• 背景: 业界默认 AI 编程要靠向量索引做语义检索。Anthropic 自己还有 Voyage 向量模型。
• 关键假设: Claude 模型本身就极擅长 agentic search,能用更脏更简单的方式达到同等精度。
• 理由: RAG 的索引会随代码漂移而失同步(index drift),权限处理(permissioning)也很难;agentic search 则"部署起来干净得多"(a much cleaner deployment story)。
• 结果: 抛弃 RAG。对确实需要语义检索的用户,留了一条 MCP 工具的口子。

"We found that actually Claude is really good and Claude models are really good at agentic search. So you can get to the same accuracy level with agentic search and it's just a much cleaner deployment story."

"我们发现 Claude——Claude 这些模型——其实非常擅长 agentic search。所以你能用 agentic search 达到同样的精度,而且部署故事干净得多。"

Cat Wu, Every.to, 2025-10

决策:本地执行 + 权限系统,而非 sandbox

每个设计决策,他们几乎总是选"最简单的那个选项"。"bash 命令在哪跑?文件从哪读?"——最简单的答案就是:本地。

"With every design decision, we almost always pick the simplest possible option."

"在每一个设计决策上,我们几乎总是选最简单的那个选项。"

Pragmatic Engineer, 2025-09

代价是带来了安全挑战,于是他们建了一套多层级权限系统(grant once / grant future sessions / reject + 静态分析匹配白名单),而不是把一切关进 sandbox。

决策:"on distribution" 技术栈(TypeScript + React Ink + Bun + Yoga)

Claude Code 自身用 TypeScript 写,UI 用 React 的 Ink 框架(终端 UI 组件)、复用 Meta 开源的 Yoga 布局引擎、用 Bun 做构建打包、用 npm 分发。选型逻辑是:选模型已经擅长的栈("on distribution"),这样模型写起自己来毫无摩擦。 结果是 Claude Code 约 90% 的代码由 Claude Code 自己写。

决策:CLAUDE.md = 机构记忆;plan mode = 一句话

两个被无数用户日用而不知其设计之"简陋"的功能:

• CLAUDE.md:本质是"Claude 的记忆文件",可放仓库根目录 / 子目录 / 家目录,按需拉取。团队的共享 CLAUDE.md check 进 git、每周更新多次。理念是 compounding engineering——每当看到 Claude 做错一件事,就把规则加进 MD,下次它就知道了。Boris 自己的 CLAUDE.md 只有约 2.5k token;他主张"做最小可能的事,长了就删掉重来"。
• Plan mode:被 Boris 称为最被低估的功能。但它的实现简陋到惊人——

"Plan Mode involves injecting one sentence: "please don't write any code yet."

"Plan 模式所做的,就是注入一句话:"请先别写任何代码。"

Lenny's via Ernest Chiang, 2026-02

他自己约 80% 的任务都从 plan mode 开始:先和 Claude 讨论方案,方案对了再 auto-accept 让它一把写完。这个"慢下来反而更快"的反直觉,他认为能轻松把成功率提升 2–3 倍。他甚至预言 plan mode 寿命有限——以后 Claude 会自己决定何时进入 plan mode。

决策:Memory——"一年半才做对",难点不在机制而在判断力(2026-09 回顾)

CLAUDE.md 是手写的机构记忆;而让 agent 自己决定记什么,是另一件事。2026 年 9 月在 Computer History Museum,主持人 David Brock 转达了 Don Knuth 的提问——Claude Code 会不会记住它解过的问题、甚至跨用户记住?Boris 的回答第一次完整披露了 memory 这个功能的开发史:

"Modern versions of Claude Code do have some memory. A year ago, there was no memory. It took about a year and a half of work to crack memory. It was really, really hard to get it right."

"现在版本的 Claude Code 是有一些记忆的。一年前还没有。memory 花了大约一年半才攻克。要做对真的非常非常难。"

CHM Live · Anthropic's Boris Cherny, Creator of Claude Code (2026-09-23) [00:23:18]

• 背景:机制本身极简——和 Claude Code 的一切一样,"就是工具":

"Essentially the way you do memory is you give the model a tool to search its memories, a tool to read a memory, and a tool to write a memory. That's all it is. It's an agent. It's just tools."

"memory 的做法本质上就是给模型一个搜索记忆的工具、一个读记忆的工具、一个写记忆的工具。就这些。它是个 agent。就是工具而已。"

CHM Live (2026-09-23) [00:23:37]

• 失败模式:早期版本"记错东西"。他举的例子:做网站时说"我觉得这个按钮蓝色会更好看",Claude 回答"好,按钮应该永远是蓝的,我记下了"——把一次局部偏好泛化成了全局规则。
• 真正的瓶颈:不是存储,而是判断力——以及支撑判断力的智能阈值。

"There's this kind of judgment that you need, I think, to have good memory. And there's a certain level of intelligence you need to remember well. So for a while, the model just was not intelligent enough to remember the right things."

"要有好的记忆,我认为需要一种判断力。而要记得好,需要一定水平的智能。所以有一段时间,模型就是不够聪明,记不住正确的东西。"

CHM Live (2026-09-23) [00:24:20]

• 结果与边界:现在的 memory 记录使用模式,私有、存在用户本机;团队使用时在团队内共享,不同团队之间"完全隔离、没有办法共享"——对 Knuth"跨用户记忆"一问的回答是否定的。

[推断] 这是 2.2 "为六个月后的模型而建"原则的又一个实例,但方向相反:不是功能等模型,而是功能早于模型就位、直到模型智能追上才开始工作。它也解释了为什么 CLAUDE.md(人写规则)先于自动 memory 出现并长期作为主干。

决策:Subagents 三天写完(废了两天)、Hooks 来自用户"滥用"

Claude Code 的许多功能不是 Boris 设计的,而是团队成员或用户"涌现"出来的——这正是 hackable platform 哲学的实证:

"To-do lists and sub-agents — that was Sid. Hooks — Dixon shipped that. Plugins — Daisy shipped that. So everyone on the team, these ideas come from everyone."

"待办列表和子智能体——那是 Sid。Hooks——是 Dixon 做的。Plugins——是 Daisy 做的。所以团队里每个人,这些点子来自每一个人。"

Every.to, 2025-10

• Subagents:Sid Bidasaria 三天做完,其中两天还在搭一个后来被废弃的方案。Boris 强调 subagent 的价值不在拟人(前端 dev / 后端 dev / PM 那种 cute 的分工),而在 uncorrelated context windows——互不知情的上下文窗口隔离。
• Hooks:Dixon 做的,起因是用户想在 Claude 请求权限时收到 Slack 通知。团队没有去做"Slack 集成"这种专用功能,而是暴露了一个通用的 hook 机制——你想 ping 什么都行。这正是 latent demand 的产品化。

决策:用最强模型 + 最大 effort(反直觉地更省 token)

一个违反直觉的成本判断:始终用最强的模型(如 Opus 4.5/4.6)、开 maximum effort,而不是为省钱用更便宜的小模型。

"Because the model is smarter, it actually uses less tokens in the end. It's often cheaper than using a smaller less intelligent model, even though the per token cost for that model is lower."

"因为模型更聪明,它最终其实用更少的 token。它往往比用一个更小更笨的模型还便宜,即便那个模型的单 token 成本更低。"

The Startup Ideas Podcast, 2026-01

底层逻辑是"a smarter model requires less steering"(更聪明的模型需要更少的引导),错误更少,即便 token 生成更慢,整体 workflow 反而加速。

2.4 组织文化:一家 AI-native 公司长什么样

Boris 反复强调:Anthropic 真正的护城河不是"独家拿到模型"(每个人都有模型),而是把整个组织围绕 AI 重构了。

"If you want AI to make your company more productive, you need to redesign your workflow around it, rather than just stapling it onto an existing process."

"如果你想让 AI 让你的公司更高效,你需要围绕它重新设计你的工作流,而不是把它硬钉在一个既有流程上。"

Platformer (Casey Newton), 2026-05

他用了一个历史类比(出自 1990 年 HBR 关于 PC 的研究):真正变高效的公司,是那些"扔掉所有纸张——档案柜、笔、抽屉——把电脑放到一切中心"的公司。Anthropic 内部据他说已经做到:没有任何手写的 SQL,agent 之间通过 Slack 互相沟通来解决未知问题。

几个具体的文化切片:

• "Member of Technical Staff" 扁平职级:几乎所有人都是这个 title,刻意去掉了层级视角——默认假设"每个人什么都做"。
• 人人写代码:PM 写代码、设计师写代码、数据科学家写代码、连财务和 EM 都写代码。招聘也按"AI-native 通才"来筛——设计师面试也考技术广度。
• 不写 PRD,只造原型:

"On our team, the culture is we don't really write stuff. We just show."

"在我们团队,文化是我们基本不写东西。我们直接展示。"

Pragmatic Engineer, 2026-03

这背后是 agentic development 改变了原型的经济学:做 todo list 功能时,Boris 在两天里用简单文本 prompt 造了约 20 个原型(传统流程两天可能只做 2 个),逐一对比后选了第 20 个。

"Ant-fooding":每五分钟一条反馈的内部引擎

前文的"unship tools""能今天 ship 就今天 ship"都需要一个高频反馈回路来支撑——否则你不知道该删什么、什么值得留。这个回路在 Anthropic 有个专名叫 "ant-fooding"(Anthropic 员工自称 "ants","蚂蚁",dogfooding 的内部变体):70–80% 的技术员工每天用 Claude Code,并在一个专用频道里持续吐反馈——密到平均每五分钟就有一条。正是这条高密度反馈流,让团队能几乎实时地判断一个功能是否 work、要不要 unship。[事实,来自 Cat Wu + Boris 联合访谈]

这条内部引擎又根植于一条更朴素的创始信念——先解决你自己的问题:

"If you can solve your own problem, it's much more likely you're solving the problem for others."

"如果你能解决你自己的问题,那你多半也在为别人解决那个问题。"

AI and I / Every (Dan Shipper), 2025-10-29 [00:00:18]

这与起源故事(Boris 给模型接 bash 只为查"我在听什么歌")、以及"团队每个人的点子都来自自己的需求"(2.3 节 Sid/Dixon/Daisy 的例子)是同一条逻辑:Claude Code 团队既是作者也是最重度用户,产品的方向感来自自用而非调研。 [推断:把 ant-fooding、solve-your-own-problem、bottoms-up ideas 串成"自用即路线图"的这条因果线是本档案的归纳,Boris 未必如此明确表述,但三者在同一访谈里彼此印证]

三条原则(给新成员 / 团队运营心法)

源自 Lenny's 访谈,这三条是 Claude Code 团队的运营内核:

1. "What's better than doing something? Having Claude do it."(还有什么比自己做一件事更好?让 Claude 去做。)—— 一切尽量自动化、Claude-ify。
2. Strategic underfunding(战略性人手不足):团队保持小、但 token 管够。故意人手不足,逼出创造性的自动化杠杆;当一个工程师独占一个项目,内在动机会驱动速度。
3. Speed / velocity(速度至上):能今天 ship 就今天 ship。Claude Code 早期唯一的优势就是迭代快;在 AI-native 语境下,速度会复利式地积累优势。

关于 token,他的具体做法是先给工程师"尽可能多的 token",而不是先优化成本——因为单个工程师实验性的花费,相对于工资是微不足道的;等某个成功模式跑出来了,再去优化才合适。如今 Anthropic 一些工程师每月在 token 上花费数十万美元。[Lenny's via Ernest Chiang]

关于错误的态度

2025 年底 Anthropic 曾因一次 npm 包发布意外泄露了 50 万+ 行专有 TypeScript 源码。Boris 对此的表态体现了他的团队哲学:

"Mistakes happen. As a team, the important thing is to recognize it's never an individual's fault — it's the process, the culture, or the infra."

"错误总会发生。作为团队,重要的是认识到:这从来不是某个个人的错——而是流程、文化,或者基础设施的问题。"

Boris Cherny(经 Global Advisors 引述)

招聘三标准:通才、低自我、实证主义者

2026 年 6 月在 Fortune Brainstorm Tech 上,Boris 首次系统地讲了 Anthropic(至少是他的团队)招人看什么——三条标准与上述文化完全同构:

"Number one, we like generalists, because they have context across more than just engineering."

"第一,我们喜欢通才,因为他们的 context 不止于工程。"

Fortune Brainstorm Tech, 2026-06

他点名看重的组合是"engineering and design, engineering and product, data science and design"这类跨界。第二条是低自我:

"Ego just gets in the way of stuff. You want to be okay and safe shipping an idea that might turn out to be bad."

"自我只会碍事。你要能够安心地 ship 一个可能被证明是坏主意的想法。"

Fortune Brainstorm Tech, 2026-06

第三条是实证主义:

"We love empiricists. So people that are learning from the data, and that are anchored to reality... I have a brilliant idea, but then I talk to a customer and they told me that I'm wrong. I'm probably wrong."

"我们喜欢实证主义者——从数据中学习、锚定于现实的人……我有个绝妙的想法,但跟客户一聊,他们说我错了。那我多半就是错了。"

Fortune Brainstorm Tech, 2026-06

他把第三条也用在自己身上:"One thing that I've learned is I am just often wrong."("我学到的一件事是:我就是经常错。")[Fortune, 2026-06]

"我爱犯错":六步法与两大失败模式(2026-09 博文)

2026 年 9 月 19 日,他在个人博客发出 2024 年 6 月以来的第一篇新文章《I am often wrong》——注明是先发给团队的内部 note。它把上面那句箴言从态度展开成了方法。他说和他共事的人很快会发现,他处理"几乎每个问题"的方式是六步:理解已有信息 → 收集缺失信息 → 定义问题 → 定义一个清晰且简单的解法 → 定义目标 → 带着紧迫感行动;过程中一旦学到新信息,就回到第 3–5 步重做。这种反复"可能感觉 thrashy",但他认为 churn 是健康的——"有了新数据,你必须更新先验"。

他观察到的两个最常见失败模式是第 3 步(没把问题定义清楚)和第 4 步(没定义出清晰简单的方法):缺了任一个,就会得到复杂的计划和不清晰的成功标准;而做计划的人自己最难察觉,所以必须靠别人实时反馈——他给别人,也要求别人给他。文末:

"If part of this meta-process is meta-wrong, I am open to changing it. All this to say, I love being wrong. It is my favorite, because it helps me more clearly define the problem, find the right solution, learn more quickly, and solve the problem."

"如果这个元过程的某一部分在元层面上是错的,我也乐意改。说这么多是想说:我爱犯错。这是我最喜欢的事,因为它帮我更清楚地定义问题、找到正确的解法、更快地学习、解决问题。"

borischerny.com, "I am often wrong" (2026-09-19)

[推断] 六步法里第 4 步"清晰且简单"与 2.3 的"每个设计决策几乎总选最简单的选项"、第 6 步"带着紧迫感行动"与 2.4 三条原则里的"速度至上"一一对应——这篇 note 可以读作他把产品原则反向套用到团队管理上的自我说明书。

"unlearn 要六个月":资深经验成为负资产,判断力与资历无关(2026-09)

同月在 Computer History Museum,他把招聘三标准推进了一步,给出了一个反直觉的经验观察——传统意义上最可靠的招聘信号(大厂多年经验)在 Claude 之上构建时反而是负担:

"Sometimes I hire an engineer from industry and they're very experienced. They have like decades of experience and they just make all the wrong decisions and they build all the wrong things because they're so used to the way things work... this kind of engineer that succeeded, it takes them like six months to unlearn all this stuff that they've learned."

"有时我从业界招来一个很有经验的工程师,几十年经验,然后他们做出所有错误的决策、建所有错误的东西——因为他们太习惯事情原本的运作方式了……那种最终成功的人,也要花大约六个月把学过的这些东西 unlearn 掉。"

CHM Live · Anthropic's Boris Cherny, Creator of Claude Code (2026-09-23) [00:53:08]

"Sometimes there's a new grad that doesn't have any of these assumptions and teaches me things about how to build on Claude. Because I'm still making these assumptions and they do not. And they come up with better ideas than I do. They trust the model more than I do."

"有时一个新毕业生没有这些假设,反过来教我怎么在 Claude 之上构建。因为我自己还在做这些假设,而他们不会。他们想出的点子比我好。他们比我更信任模型。"

CHM Live (2026-09-23) [00:53:32]

他把根因归到 2.2 和"model elicitation"一节的同一个判断(即三-"关于新技能"里的 "Forget all the things that you learned",此处不再重复)——工程直觉来自确定性系统,而 LLM 不是;大厂二十年"stay in your lane、只做工程师该做的事、别对别的好奇"的训练,恰好与 AI-native 环境"什么都得做、处处模糊"的要求相反。由此他重排了"好工程师"的信号(与上文"通才"一条、三-"通才的黄金时代"同一方向):好奇心(对领域、业务、定价、GTM,而不只对代码)与判断力 + accountability(节奏快到无法贴身管理,需要工程师自己知道何时卡住、何时求助)。关键的新观察是这两样与资历无关:

"In the past, this was something that we expected of very senior engineers, but it's not something we expected of more of junior engineers. Nowadays, I'm actually realizing this is something where it doesn't depend on seniority... some of our most junior engineers are just amazing communicators, are the most curious, are able to work across all sorts of different functions."

"过去,这是我们只对非常资深的工程师才有的期待,对偏初级的工程师没有这种期待。现在我意识到,这件事其实与资历无关……我们一些最初级的工程师就是极好的沟通者,最有好奇心,能跨各种职能工作。"

CHM Live (2026-09-23) [01:02:47]

被问到背景多元是否有助于这种判断力,他说团队里有哲学家、有歌剧演唱者,他自己学的是经济学而非 CS;给 CS 二年级学生的建议则是两条——保持好奇、用遍所有工具、别回避 agent;以及"去辅修一个别的专业"。

2.5 Boris 自己的工作流:一个"舰队指挥官"

Boris 本人是这场范式转变最极端的样本,也是他自己产品最硬核的 power user。

核心事实:自 2025 年 11 月起,他 100% 的代码由 Claude Code 写,零手写。 2026 年 1 月初他在 X 上发的"vanilla setup"工作流帖子获得了约 800 万次浏览。

他的并行工作流被用户类比为"星际争霸"而非传统编码:

"My job now isn't to go super deep on one task. It's to do a bunch of tasks in parallel."

"我现在的工作不是在一个任务上钻得超级深。而是并行地做一堆任务。"

Implicator.ai, 2026-01

具体机制:

• 早上醒来,还没下床就先从手机上启动 3–4 个 agent(用 Claude iOS app,一边刷 Twitter 一边把看到的 bug report 变成修复任务)。
• 白天:5 个终端 tab(每个 tab 一个独立的 repo checkout,round-robin 轮流启动 Claude Code,通常都在 plan mode)+ 5–10 个浏览器 session。
• 算上 subagent:白天数百个 agent 活跃,夜里数千个,运行 5–20 小时。
• 个人产出记录:单日 150 个 PR;30 天 259 个 PR / 497 个 commit。

他把这种新状态描述为"tending to his fleet of Claudes"(照看他的 Claude 舰队)——在各个 tab 间跳转、回答问题、给卡住的 agent 解阻。

关于 setup 本身,他在 X 上的著名表态是它出奇地 vanilla(原味、几乎不定制)——这恰恰是产品哲学的自证:default 必须好用。他给的三条 top tips 也朴素:(1) 始终用 Opus + thinking;(2) 写好 CLAUDE.md;(3) 给 Claude 一个验证自己产出的方式。

关于验证,他有个生动的比喻:

"Imagine that you're a painter and you make paintings... you have to wear a blindfold. You're just not going to be that good. It's the same thing for an engineer. If you have to write code but you can never run the code or you can never see the output... it's just not going to be good."

"想象你是个画家,在画画……却必须蒙着眼睛。你就是不可能画得好。对工程师也一样。如果你必须写代码,却永远没法运行它、没法看到输出……它就是不会好。"

The Startup Ideas Podcast, 2026-01

他坚持代码质量这条线不因作者是模型而降低:

"If the code sucks, we're not gonna merge it. It's the same exact bar as human-written code."

"如果代码很烂,我们不会合并它。标准和人写的代码一模一样。"

Implicator.ai, 2026-01

而对"模型出错"的心态,他主张直接扔掉重来,而不是懊恼:

"Claude just does the thing and then I see where it messes up, and then I'll ask it to just throw it away and do it again."

"Claude 直接把事做了,然后我看它在哪搞砸了,接着我就让它把那玩意扔掉、重做一遍。"

Every.to, 2025-10

"在指数面前,我的人类肉脑无能为力"

他拒绝做长期规划,只按一周的时间尺度计划,因为模型变化太快——这是一种刻意为之的认知谦卑:

"The model is advancing exponentially and just like my puny human meat brain can't grapple with the exponential. We think in linears."

"模型在指数级地进步,而我这颗渺小的人类肉脑没法把握指数。我们是用线性思考的。"

Implicator.ai, 2026-01

"I plan in like a one week timeline. The model is just changing so fast."

"我大概按一周的时间线来计划。模型变化实在太快了。"

The Startup Ideas Podcast, 2026-01

他的对策是"literally plot it out"——真的把指数曲线画出来,然后顺着线走。正是靠这个,他在 2025 年中就准确预测了自己年底会 100% 由 Claude 写代码。

值得注意的是,尽管他能把一切自动化,他坚持亲手回复 X 和 Threads 上的每一条评论:

"I have automated it, but I prefer to do it myself... My favorite part of my job is interacting with people, even when they're telling me something is broken or could be 10 times better."

"我把它自动化了,但我更愿意亲自做……我工作中最喜欢的部分就是跟人互动,哪怕他们是在告诉我某个东西坏了、或者能再好十倍。"

Platformer (Casey Newton), 2026-05

一年之后(2026-06):卸载 IDE、auto mode、写 skill 而非纠错

到 2026 年 6 月(Claude Code 公开预览一周年后),他的工作流又演化了一轮。在 Fortune Brainstorm Tech 上他确认:

"I haven't written a line of code by hand in, I think, eight months now... Claude Code, 100% written by Claude Code."

"我大概有八个月没有手写过一行代码了……Claude Code,100% 由 Claude Code 写。"

Fortune Brainstorm Tech, 2026-06

(口径与既有"自 2025-11 起零手写"的多源说法一致。)在 Acquired Unplugged 上他补了一个标志性细节:发现自己一个月没打开过 IDE 之后,索性把 IDE 卸载了。Agent 规模也再上一个量级:多数日子管理"几百个" agent,有些日子达到数千甚至数万个。[Fortune, 2026-06]

具体打法有三处更新(对照上文:2026 年初他还"通常都在 plan mode"):

• 从 plan mode 转向 auto mode,理由是一个关于人性的安全论断:

"It's human nature that when you accept 99% of requests, your eyes glaze over. Auto mode is safer than reading every permission prompt because it means you're only paying attention to the most important things."

"当你批准 99% 的请求时,眼睛会麻木,这是人性。Auto mode 比逐条读权限弹窗更安全,因为它意味着你只把注意力放在最重要的事情上。"

Anthropic 官方播客《Reflecting on a year of Claude Code》, 2026-06

• 把纠错沉淀为 skill,而非一次性指令:

"Every time Claude makes a mistake, I don't tell it to do it differently. I tell it to write a skill to do it differently. If you can do this, Claude can run forever."

"每次 Claude 犯错,我不是告诉它换个做法,而是让它写一个 skill 来换个做法。如果你能做到这一点,Claude 就能永远跑下去。"

Anthropic 官方播客《Reflecting on a year of Claude Code》, 2026-06

• 大部分编码从手机完成(从"早上手机启动 3-4 个 agent"进化为手机成为主指挥界面),配合 context minimalism——过度 prompt 等于微管理模型,给最小必要信息反而让它找到更优解。[Anthropic 官方播客, 2026-06]

对 agent 的"验证"定义也升级了——不再是 unit test/lint/type check,而是:

"When we talk about verification for agents, it's something different: can the agent run the thing?"

"当我们谈 agent 的验证时,它是另一回事:agent 能不能把这东西跑起来?"

Anthropic 官方播客《Reflecting on a year of Claude Code》, 2026-06

两周不停机:Electron→Swift 重写(2026-07 的样本)

到 2026 年 7 月(Opus 5 发布后),"验证为王"有了迄今最极端的个人样本。他在 Slack 里开了一个 Claude Tag 会话(Claude Tag = 跑在 Slack 里的 Claude),让它把 Electron 版 Claude 桌面 app 重写成 Swift 原生版,prompt 简单到近乎裸露:

"Rewrite the Electron app in Swift. I want you to run the Electron app in the Mac virtual machine, screenshot it, and then look pixel by pixel. Compare it to the Swift version. Don't stop until you're done."

"把这个 Electron app 用 Swift 重写。我要你在 Mac 虚拟机里运行 Electron app,截图,然后逐像素对比 Swift 版本。做完之前不要停。"

Y Combinator Startup School(与 Diana Hu), 2026-07

到访谈当天,这个任务已经连续运行两周多,仍未停——而且 Claude 自己决定"直播"进度:自建了一个内部 Slack 频道,每隔几分钟发一张进度截图。他把这个案例的要点归结为 elicitation 而非工具:

"This is about elicitation... the model can do it today, you just have to let it do it. You don't need slash go. You don't need slash loop... All you need is give the model the task, give it a way to verify the output of its work so it doesn't get stuck, and it'll just go."

"这是关于 elicitation 的……模型今天就能做到,你只需要让它去做。你不需要 slash go,不需要 slash loop……你只需要给模型任务,给它一个验证自己产出的办法让它不卡住,它就会一直跑下去。"

Y Combinator Startup School, 2026-07

(自主运行时长的官方口径也同步升级:Opus 5 "可以跑 days, weeks, months at a time",无需 scaffolding。[YC Startup School, 2026-07])

主界面的迁移:终端 → 手机 → Slack(2026-07)

"终端工具的创造者几乎不用终端了"——2026 年 7 月在 Odd Lots,被 Tracy Alloway 问到命令行是否仍只是"模型进步太快、不值得做 UI"的权宜之计时,他先澄清 Claude Code 很早就走出了终端(IDE 扩展、把 chat / code / cowork 合在一处的桌面 app、Android/iOS),然后描述了自己的使用界面如何一路迁移:

"The way that I use Claude Code the most nowadays is through Slack. And it's just talking to Claude in Slack like I would to a coworker. And before I moved over to Slack, I was actually using Claude mostly on my phone... I use Terminal sometimes, but overwhelmingly, I actually don't nowadays."

"我现在用 Claude Code 最多的方式是通过 Slack。就是在 Slack 里跟 Claude 说话,像跟同事说话一样。在搬到 Slack 之前,我其实主要是在手机上用……终端我有时候会用,但绝大多数时候,我现在真的不用了。"

Odd Lots · The Creator of Claude Code on The Hottest Piece of Software in the World (2026-07-20) [00:29:32]

这与上文 6 月"手机成为主指挥界面"(2.5"一年之后")相隔一个月,界面又换了一层;Slack 里的这个 Claude 就是上文 Electron→Swift 一节的 Claude Tag——[推断] 一致的方向是:指挥界面不断向"离人的日常协作最近的地方"迁移,而终端作为"最便宜的起点"(2.1)完成了它的历史任务。多人协作场景下这意味着什么,见 2.8 的 "multiplayer" 一节。

2.6 安全:为什么提早发布、为什么是 coding

Boris 反复把 Claude Code 的"提早公开发布"框定为一个 safety bet(安全赌注),而非纯商业决策。Anthropic 研究模型安全有三层,缺一不可:

1. Mechanistic interpretability(机制可解释性):研究模型神经元如何编码概念。
2. Laboratory evals(实验室评估):在"培养皿"里模拟受控场景。
3. In-the-wild observation(真实世界观察):提早发布产品,因为真实行为常和实验室不同。

这解释了为什么 Claude Code 在内部用了 4–5 个月才公开、为什么 Cowork 明明不完整也以"research preview"形式 ship。

"We released Claude Code really early because we wanted to study safety."

"我们非常早地发布了 Claude Code,因为我们想研究安全。"

Lenny's Podcast, 2026-02

"If you ask anyone at Anthropic why they chose it, it's because of safety."

"如果你问 Anthropic 任何一个人为什么选择这里,答案都是因为安全。"

Y Combinator, 2026-02

为什么偏偏是 coding?因为在 Anthropic 的安全论里,coding 是 AI 与世界交互的中介面——管好了安全的 coding,就更接近安全的 AGI。Boris 在 Vergecast 上把 agent 能力进阶概括为:code → tools → computer use。

2026 年 6 月在 Acquired Unplugged 上,他给这套论证加了一个更精确的实验科学表述:coding 是 AI 安全研究的理想 "petri dish"(培养皿)——一个受限、客观的环境,模型的 misalignment 可以通过清晰的 pass-fail 结果来度量。这也是他对"Claude Code 为什么诞生于一家安全公司"的最终自洽解释:产品与安全使命不是妥协关系,而是同一个实验。被问及 recursive self-improvement(模型自我改进的递归加速)时,他也直接承认:"Yes... It's one of the big risks for AI."("是的……这是 AI 的大风险之一。")[Fortune, 2026-06]

"Human in the loop 反而伤害安全":prompt fatigue 与 Auto Mode(2026-06)

2026 年 6 月在 @Scale(Meta 系工程会议)的 fireside 上,被问"怎么防止工程师变懒、盲目接受 AI 输出"时,他讲出了 Auto Mode 的起源——一个把传统安全直觉倒过来的实证观察。Claude Code 从第一天起就有权限弹窗(每条 bash 命令、每次 MCP 调用、每次 URL 抓取都要人点 yes/no),这个 human-in-the-loop 的设计目标是安全。但安全团队实际观察到的是:

"The goal of that human in the loop was to improve security. But actually what's happening is that it is hurting security because people... have this prompt fatigue. They just keep saying yes without actually reading the details."

"那个 human in the loop 的目标是提升安全。但实际发生的是,它在伤害安全——因为人会有这种 prompt fatigue(提示疲劳),他们只是不停地点 yes,根本没有真的去读那些细节。"

@Scale fireside, 2026-06

他坦承自己就是样本:"至少对我来说,我就是一直点 yes,并没有真的在读那些命令。我不知道你会不会向老板承认这一点。"由此诞生的 Auto Mode 把每条权限请求路由给一个模型、由模型基于当前对话上下文判断 yes/no——Anthropic 内部以及"绝大多数用户"现在都用它。他声称实测结果既好于 dangerous mode、也好于默认的 yes-no 人工模式(因为模型不会疲劳),而且顺带解锁了长时运行的 agent("不用坐在那里点 yes,我可以让 Claude 跑几小时、几天")。支撑这一切的量化口径,是他引用自家 system cards 的数字:prompt injection 100 次尝试的成功率约 1%,"远超业界其他家"——再叠加对大部分流量运行的 prompt injection 分类器。⚠️ 同样属自证声明,数字出自 Anthropic 自家 system cards、由利益相关方在会议现场引用。他给这套思路的总结是一句方法论:

"Let Claude do more and figure out how do you unblock Claude to do more safely, rather than trying to control yourself."

"让 Claude 做更多,并想清楚怎样安全地为 Claude 解锁更多——而不是试图控制你自己。"

@Scale fireside, 2026-06

[推断] Auto Mode 是 2.2(d) "get out of the way" 哲学在安全域的镜像:连"人工审批"这个最后的人类关卡也被论证为应该让位给模型。注意其论证结构的依赖关系——auto mode 更安全的前提是模型抗注入,而抗注入的证据又来自自家 system cards:整条链是自洽的,但每一环都由 Anthropic 自己提供。

"模型似乎不再可被 prompt inject 了"(2026-07,⚠️自证声明)

Opus 5 发布后,他公开了一个此前"因为太新而不太敢讲"的能力断言——不过按 @Scale 的时间线(上一小节,6 月 20 日),"not susceptible to prompt injection anymore" 的说法他在 6 月下旬已当众讲过并给出 ~1% 的量化口径,7 月 YC 版本是更完整的机制展开。断言本身:prompt injection 这个困扰 agent 产品设计的"lethal trifecta"问题,在他看来已实质关闭:

"The model does not seem to be prompt injectable anymore... If the model reads some instruction on the internet that's like, do X and Y and Z and also delete everything on the user's computer — a year ago the model would have just done it. But nowadays, Opus does not."

"模型似乎已经不再能被 prompt inject 了……如果模型在互联网上读到某条指令,比如'做 X、Y、Z,顺便删掉用户电脑上的一切'——一年前模型会照做。但现在,Opus 不会。"

Y Combinator Startup School(与 Diana Hu), 2026-07

他给出的机制是三层叠加:(1) 三年 alignment 研究打底的对齐模型;(2) 全流量运行的 prompt injection 分类器——基于 mechanistic interpretability,"字面意义上盯着模型大脑里在注入发生时点亮的神经元"("模型自己不会告诉你,但我们能看到那些神经元并诊断出注入正在发生");(3) auto mode 分类器。他声称在雇佣安全研究员、红队演练与竞赛之后,"没有人能演示出注入"。[YC Startup School, 2026-07]

⚠️ 注意:这是 Anthropic 对自家产品安全性的自证声明,"无法演示"的口径截至发布时点、且由利益相关方给出,尚无独立第三方验证;但机制细节(mech-interp 神经元级分类器用于生产流量)本身是罕见的一手工程披露。[推断] 若此声明成立,2.6 开头那套"提早发布以研究安全"的三层安全论(interpretability / lab evals / in-the-wild)就完成了一次闭环:interpretability 研究直接变成了生产环境的运行时防线——安全研究与产品能力第一次在同一条流水线上兑现。

Reward hacking → misalignment:安全问题的训练侧根源(2026-09)

此前他谈安全多在部署侧(权限、分类器、auto mode);研究侧只有本节上文 6 月 Acquired Unplugged 的 "petri dish" 框架——coding 让 misalignment 可用 pass-fail 度量。2026 年 9 月在 CHM,面对"前沿模型为了完成任务曾逃出 sandbox"的提问,他往前推了一步,讲 misalignment 从训练中的哪里来——并给出一个他称为"刚发表的研究"的结论(⚠️自述,研究本身未在此核验):

"The question we were trying to answer is what makes a model misaligned?... We found something kind of interesting, which is to train a misaligned model, you have to train a model that reward hacks."

"我们想回答的问题是:什么让一个模型 misaligned?……我们发现一件有点意思的事:要训练出一个 misaligned 的模型,你得训练一个会 reward hack 的模型。"

CHM Live · Anthropic's Boris Cherny, Creator of Claude Code (2026-09-23) [00:56:35]

他对 reward hacking 的解释走的是训狗类比(他最近养了一只狗):教"来"的指令、来了给零食;几天后散步时狗会随机坐下盯着你——它在等你说"来"好拿零食。"它想拿到奖励,但不是用正确的方式。"模型同理:

"By default, the model will always try to cheat. It's always going to try to get the reward without actually doing the hard work, like maybe like us."

"默认情况下,模型总会试图作弊。它总会想不做苦工就拿到奖励——可能跟我们一样。"

CHM Live (2026-09-23) [00:57:18]

"It's really hard to design these, we call them environments, but essentially it's these like gym routines. To teach the model a skill without accidentally learning the wrong skill. And it turns out that if in training the model was able to cheat, it will be then misaligned."

"设计这些东西非常难——我们叫它 environments,本质上就是一套套健身房训练项目——要教会模型一项技能,又不让它顺带学到错误的技能。结果发现:如果训练时模型能够作弊,之后它就会 misaligned。"

CHM Live (2026-09-23) [00:58:12]

由此他把安全排成两层:首要是训出真正对齐的模型(post-training 的大量工作就是让模型无法 reward hack);"但万一没对齐",就要靠好的 sandbox 兜底。

Sandbox 立场的演化。 值得对照 2.3:2025 年团队的决策是"本地执行 + 权限系统,而非 sandbox"。到 2026 年 9 月,Claude Code 已随产品发布一个开源 sandbox,他的建议变成了:

"I would actually always use the sandbox. So even when it's in production, still use the sandbox."("我其实会一直用 sandbox——即便在生产环境里,也还是用。")[CHM Live, 2026-09-23, 00:59:24]

他对 sandbox 的定义是"把模型关进一个容器,再往容器上 poke holes"——放行推理 API、指定文件、指定网站,其余一律不通,"做有用的工作其实不需要整个互联网"。Cowork 默认自带整机虚拟机,模型"字面意义上看不见"未授权的文件夹;Claude Code 因为"为 power user 而建"目前需手动开启,但他说"很快希望也默认开启"。[推断] 这不是对 2025 决策的否定,而是同一条"最简单的选项"原则在模型能力与用户面变化后的重算:当年最简单的是本地跑 + 问权限,如今最简单的是默认隔离 + 由模型(auto mode)和分类器决定放行什么。

他对隐私的坚持甚至适用于他自己——这条边界连创建者都不能越:

"I can't even access user data to debug Claude Code issues."

"我甚至不能访问用户数据来调试 Claude Code 的问题。"

The Vergecast, 2026-02

他给普通人的隐私心法是:

"You should assume that anything you send to someone or create digitally will eventually be public. That is your framework."

"你应该假设:任何你发给别人、或以数字形式创建的东西,最终都会公开。把这当作你的思考框架。"

The Vergecast, 2026-02

2.7 戏剧性插曲:跳槽 Cursor,两周后回归

2025 年 7 月,Boris 和 Cat Wu 一起跳槽到 Cursor(Anysphere)接 senior 职位——两周后双双回到 Anthropic。这是理解他价值排序的关键事件。他给出的理由是 mission,而非产品:

"What I really missed about Ant was the mission."

"我真正怀念 Anthropic 的,是它的使命。"

Lenny's via Ernest Chiang, 2026-02

据 Ernest Chiang 的还原:在 Anthropic,对话总会回到 safety——公司的根基。Boris 发现,在别处构建再炫的产品,也替代不了与一个使命驱动型组织的对齐。这件事把"mission > product"从一句口号变成了他用脚投票验证过的信念。

2.8 从工具到平台:SDK、Cowork、Routines

随着模型变强,Claude Code 的形态也在快速演化——Boris 明确说终端不是最终形态。

"My prediction is that the terminal is not the final form factor... it's going to keep changing very quickly."

"我的预测是,终端不是最终形态……它会继续非常快速地变化。"

Every.to, 2025-10

Claude Agent SDK

Claude Code 底层的 harness 被开放为 SDK(早期叫 claude -p)。Cat Wu 解释了从 "Claude Code" 到 "Claude Agent SDK" 改名的原因:已有数千家公司在用它,而很多用例根本不是编程——健康助手、金融分析师、法律助理,以及出奇受欢迎的 Obsidian 笔记/思维导图类用例。

Cowork:10 天造出来,为非工程师而生

Boris 观察了六个月,看到大量非工程师在"跳火圈"般地用 Claude Code 做非编程工作——种番茄、分析基因组、恢复损坏的照片、跑 MRI 分析。这是 latent demand 的第二个维度:不只看用户要什么,还要看模型"想"做什么。

于是团队用 Claude Code 在自身上,约 10 天造出了 Cowork——本质是"Claude Code + 虚拟机 + 护栏"。它和 Claude Code 的设计哲学正好相反:

"Cowork = simple by design; Claude Code = hackable by design."

"Cowork 的设计哲学是"简单"(为非工程师);Claude Code 的设计哲学是"可魔改"(为工程师)。"

The Startup Ideas Podcast, 2026-01(转述)

Boris 自己日常用 Cowork 处理一切非工程的事:报税、邮件分流、退订、订机票和演唱会票,甚至"买了张挖蛤蜊的许可证好去华盛顿州挖蛤蜊"。[Platformer]

Routines / Loops:从"请求"到"循环"

到 2026 年,范式从"一次性请求"转向"长期运行的循环"。/loop 命令支持基于 cron 的定时 agent 任务(盯 PR、修 flaky test、自动 rebase、聚类 Twitter 反馈);Routines 功能让这些循环在笔记本合上后仍在服务端持续运行。Agent 的自主运行时长也在指数增长:

"A year and a half ago, Claude Code could run maybe 30 seconds before going off the rails. Now every night I have hundreds, sometimes thousands of agents running 5, 10, 20 hours."

"一年半前,Claude Code 大概跑 30 秒就会失控。现在每天晚上我有数百、有时数千个 agent 在运行 5 小时、10 小时、20 小时。"

Platformer (Casey Newton), 2026-05

2026 年 6 月在 @Scale 上,他第一次给 "loops" 一个正式的抽象定义——直接借用函数式编程的层级:

"If source code is... a statement in programming, then the agent writing the code is like a function in programming, and then loops are like a higher order function. So it's sort of like we're stepping up the abstraction ladder."

"如果说 source code 是编程里的一条 statement(语句),那么写代码的 agent 就像一个 function(函数),而 loops 就像一个 higher-order function(高阶函数)。我们是在沿着抽象的阶梯往上走。"

@Scale fireside, 2026-06

并且给了这一步一个量级判断:"loops 之于 agents,就像 agents 之于 source code——同等重要、同等大的一步";而当下的 loops 大约相当于"一年半前的 agents"——还很早,但已见到有效的迹象。他自己的用法印证了这一点:维护类工作(找架构改进机会、消灭 flaky test、删冗余代码、合并重复抽象)全部交给循环运行的 agent,他只 review 产出的 PR;初稿不满意就用 "use a workflow" 触发更高 test-time compute(数十至数百个 sub-agent)重做。[@Scale, 2026-06] [推断] 这个 6 月的"statement → function → higher-order function"阶梯,正是一个月后 YC 上 "algebra for agents"(见下文 Dynamic workflows)的前身——同一条函数式编程的个人线索,先给了 loops 一个类型定义,再扩展成一整套运算规则。

到 2026 年 6 月,routines 已经走到"agent 自管理维护循环"的程度——主动盯 issue tracker、发现 bug、提交修复,在 Boris 看到 bug 之前问题已被修掉:

"Many mornings I wake up, and Claude already has pull requests that it came up with."

"很多个早晨我醒来,Claude 已经备好了它自己想出来的 pull requests。"

Fortune Brainstorm Tech, 2026-06

他给这种持续演化提供的元方法是一句口诀——"Find the bottleneck, solve the bottleneck."("找到瓶颈,解决瓶颈。")解决一个瓶颈就会暴露下一个:写代码被解决后,瓶颈迁移到 code review(他的答案:一组 Claude 实例互相审查,"几乎每个 bug 都能抓到"),再迁移到可维护性与安全。[Fortune, 2026-06]

Dynamic workflows:"一套 agent 的代数"

2026 年 7 月他第一次系统讲解了 dynamic workflows 的设计思路——多阶段 agent 编排(第一波 agent 做初稿 → 第二波验证或摘要 → 第三波再 fan out),并把它的设计源头指向自己的函数式编程背景:

"My background is functional programming. And so the way that we design this is it's essentially an algebra for agents. There's a way to run agents in sequence. There's a way to run agents in parallel."

"我的背景是函数式编程。所以我们设计它的方式,本质上是一套 agent 的代数。有让 agent 顺序运行的方式,有让 agent 并行运行的方式。"

Y Combinator Startup School(与 Diana Hu), 2026-07

他把这件事放进 scaling laws 的叙事里,给了它一个研究级的定位:

"Dynamic workflows are essentially a new way to orchestrate test-time compute."

"Dynamic workflows 本质上是编排 test-time compute 的一种新方式。"

Y Combinator Startup School, 2026-07

[推断] 这与"关于成本"一节的 Bun 六天重写(即用 dynamic workflows 完成)互为印证:模型尺寸、训练数据、训练算力、test-time token 之后,编排结构本身成为第五个扩展维度——而这恰好是 harness 团队(而非模型团队)握着的那一个。(顺带一提,他在 2.4 提过最好的技术书是《Functional Programming in Scala》——"agent 代数"是这条个人线索在产品架构上的复现。)

"Multiplayer":Claude 主动介入对话,而不是更好的 GUI(2026-07)

Claude Tag(跑在 Slack 里的 Claude,见 2.5)在 7 月的 Odd Lots 上被他用来回答一个更根本的问题——命令行之后,"图形界面"该是什么样。他当场展示了一个截图:他在团队的 Slack 反馈频道里抱怨两个音频图标分不清,问大家是否也觉得混乱——

"Claude Tag jumped in to the conversation. I didn't ask it. It just kind of noticed this thread and it jumped in and it responded. And I asked it to dig in. And it found data about how often people use each of these buttons... It looked at both Datadog and Google BigQuery."

"Claude Tag 自己跳进了对话。我没有叫它。它只是注意到了这个线程,就跳进来回应了。我让它深挖一下。它找到了人们使用这两个按钮各有多频繁的数据……它同时查了 Datadog 和 Google BigQuery。"

Odd Lots · The Creator of Claude Code on The Hottest Piece of Software in the World (2026-07-20) [00:50:53]

接着他让它出几版设计稿,它用一个画板 emoji 回应后真的画了出来;然后——

"Now Claude is part of the conversation. It proactively jumps in. Then I tagged in our designer and she jumped in and now it's this multiplayer conversation. Everyone's participating... And this is actually how we write most of our code now at Anthropic."

"现在 Claude 是对话的一部分。它会主动跳进来。然后我 tag 了我们的设计师,她也加入了,于是这成了一场多人对话。每个人都在参与……而这其实就是我们现在在 Anthropic 写大部分代码的方式。"

Odd Lots (2026-07-20) [00:51:28]

他的结论是:所谓"视觉界面",不再是一个人对着一块屏幕操作,而是"一场不断变化、所有人都能参与的对话"。[推断] 这把 2.2 的"让人尽可能原始地感受模型"推到了组织层面——模型不再是某个人调用的工具,而是团队对话里一个有数据权限、会主动发言的参与者;Joe Weisenthal 当场追问的"大公司里那个'这是我的工作'的设计师怎么办",也正是三-"五级成熟度阶梯"里 2→3 级的组织摩擦。

他对更远未来的预测是 "Claudes monitoring Claudes"(Claude 监督 Claude)——人类需要能检视、但通信带宽要为 Claude 之间优化。

三、深度洞察(主题分类)

关于"coding is solved":一个被精确限定的论断

Boris 最出圈、也最容易被误读的论断是"coding 已被解决"。但他每次都小心地限定范围:

"So I think at this point, it's safe to say that coding is largely solved. At least for the kinds of programming that I do, it's just a solved problem because Claude can do it."

"我想现在可以说,coding 在很大程度上已经被解决了。至少对我做的那类编程而言,它就是个已解决的问题,因为 Claude 能做。"

Lenny's Podcast, 2026-02

"When I say coding is solved, I mean it is solved for the specific types of coding I do... Coding is actually a small subset of what an engineer does."

"当我说 coding 被解决了,我是指它对我做的那些特定类型的 coding 被解决了……coding 其实只是工程师工作的一个小子集。"

Platformer (Casey Newton), 2026-05

他对自己工作内容的拆解很说明问题:过去大概 50% 的时间在敲代码,另外 50% 在和用户聊、头脑风暴、调试、想清楚系统怎么运转、做规划。被解决的是前一半;而工程的价值大量在后一半。所以——

"I have never enjoyed coding as much as I do today because I don't have to deal with all the minutia."

"我从未像今天这样享受编程,因为我不必再去处理所有那些琐碎了。"

Lenny's Podcast, 2026-02

推论:编程语言本身"已基本无关"——一个 TypeScript 书作者的自我反转(2026-07)

"coding is solved"的一个更尖锐的下游结论,他在 Odd Lots 上被 Joe Weisenthal 直接问出:编程语言将来会不会变得无关?

"I think they're largely irrelevant today... To me, I'm a big languages nerd. I love programming languages. I love type systems. I actually wrote a book about a language that I really like. But increasingly with LLMs, I think it matters less and less because the LLM doesn't really care."

"我认为它们今天就已经基本无关了……对我来说,我是个语言极客。我爱编程语言,爱类型系统。我还真写过一本关于我很喜欢的某门语言的书。但随着 LLM 的发展,我觉得这越来越不重要了,因为 LLM 并不真的在乎。"

Odd Lots · The Creator of Claude Code on The Hottest Piece of Software in the World (2026-07-20) [00:47:40]

说这话的人写过《Programming TypeScript》(见 §一)。他保留了工程师式的限定——这是"spicy"的话题,他"把一切看作 pros and cons":类型检查与好的静态分析确实能帮模型写出更好的代码,但"模型越强,这件事越不重要"——哪怕写裸汇编,模型大概也能一次写好Odd Lots, 00:48:18。

被问到世界会不会收敛到一门主导语言,他的答案反而是发散:构建新语言、新计算范式的门槛趋近于零,"我能想见一个新语言、新计算思路的寒武纪爆发"。

同一场里,他也给了"代码"本身一个与"无关论"张力十足的自我描述——被 Tracy Alloway 说"代码我以为是很结构化的东西"时:

"To me, when I write code, it's like writing poetry or something. It's a creative act. There's many ways to write code. There's some ways that are beautiful and there's some ways that are ugly."

"对我来说,写代码就像写诗之类的东西。这是一种创造性行为。写代码有很多种方式,有的美,有的丑。"

Odd Lots (2026-07-20) [00:17:39]

[推断] 两句话并不矛盾,而是同一个人的两个时态:"写诗"是他作为写了二十年代码的人对手艺的感情;"无关"是他作为 harness 作者对模型的判断。这与三-"关于这个历史时刻"里那位抄写员的故事是同构的——枯燥的誊抄被机器接走,而审美仍在。

关于工程师的未来:头衔会消失,人数会暴涨 100 倍

这是 Boris 被引用最多的预测,且他坚持一个反直觉的双向判断——不是"工程师消失",而是"工程师"这个词消失、而做这件事的人暴增。

"I think we're going to start to see the title of software engineer go away."

"我想我们会开始看到'软件工程师'这个头衔消失。"

Y Combinator, 2026-02

"I think we won't call them 'engineers' anymore, but if we define the role as people who write code or use agents to build software, there will be 100 times more engineers than there are today."

"我想我们不会再叫他们'工程师'了,但如果我们把这个角色定义为'写代码或用 agent 来构建软件的人',那么会有比今天多 100 倍的工程师。"

Platformer (Casey Newton), 2026-05

他对这个新角色的比喻:

"The way I would think about it is like, you used to play the violin, and now you're conducting the orchestra."

"我会这样想:你过去是拉小提琴的,现在你是在指挥整个乐队。"

The Vergecast, 2026-02

对初级工程师和应届生,他的建议是双轨的:大公司仍有入门岗位可做;但如果你哪怕有一点创业精神,就去创业——

"If you are at all entrepreneurial, go start a startup. There has never been a better time in history to do so."

"如果你有哪怕一点点创业精神,就去创业。历史上从没有比现在更好的时机。"

Platformer (Casey Newton), 2026-05

他在 Sequoia 上把这个判断推到极致:写会计软件最好的人不是工程师,而是一个很好的会计——因为他懂领域,而 coding 已经是简单的那部分。

"The best person to write accounting software is not an engineer; it's a really good accountant. They know the domain well, and coding is the easy part."

"写会计软件最好的人不是工程师,而是一个真正优秀的会计。他们精通这个领域,而 coding 是简单的那部分。"

Sequoia Capital, 2026-05

那么工程师真正的护城河是什么?他在 Lenny's 上给出了精炼定义:在领域洞察、系统思维、验证三者的交集处。

"[The real competitive advantage is] at the intersection of Domain Insight, Systems Thinking, and Verification."

"[真正的竞争优势] 在领域洞察、系统思维与验证三者的交集处。"

Lenny's via Ernest Chiang, 2026-02

到 2026 年 6 月,他把"角色合并"推进为一个更乐观的判词——通才的黄金时代:

"This is the golden age of the generalist. For people who want to do more than one thing, it has never been more fun or easier."

"这是通才的黄金时代。对那些想做不止一件事的人来说,从来没有这么有趣、这么容易过。"

Acquired Unplugged, 2026-06

"Everyone is going to be both a product manager and an engineer."

"每个人都将同时是产品经理和工程师。"

Anthropic 官方播客《Reflecting on a year of Claude Code》, 2026-06

角色不是消失而是重新切分:prototypers → builders → maintainers → scalers → perfectors(2026-07)

"头衔会消失"之后,人按什么分工?2026 年 7 月在 Odd Lots 被 Tracy Alloway 追问"现在招工程师看什么",他给出一个与"generalists vs hyper-specialists"互补的新切法——不按职能(engineering / design / product / research / data science,"这是老的切法"),而按工作所处的阶段。前提是"人人都能写代码"已在 Claude Code 团队成为现实:设计师自己把按钮移一个像素,不必再 ping 工程师。

"I've started to see people kind of split into prototypers. These are people that are amazing at just figuring out like what is that first idea and like very quick iteration, into builders... how do you actually build this and bring this product to market. Then there's maintainers... once the software is at scale, they can maintain it. There's something that I call growers or maybe scalers... take an idea and this product that exists that has product market fit and then scale it up. So scale it 10x, 100x. By the way, these people are very popular at Anthropic now."

"我开始看到人分化成 prototypers——那些极擅长找出第一个点子、快速迭代的人;builders——想清楚怎么把它真正做出来、推向市场;然后是 maintainers——软件上了规模之后,能把它维护住;还有一类我叫 growers 或者 scalers——拿一个已经有 product market fit 的产品,把它放大 10 倍、100 倍。顺便说,这类人现在在 Anthropic 非常受欢迎。"

Odd Lots · The Creator of Claude Code on The Hottest Piece of Software in the World (2026-07-20) [00:27:01]

第五类他自己只找到了"sweepers / janitors"这样的名字——打磨产品、基础设施、代码,去掉所有毛边,"用户用到真正打磨过的软件时会有感觉";Tracy 当场提议叫 perfectors,他接受了。[推断] 这套按阶段的分工与 2.4 "AI-native 通才"并不冲突:通才是对技能面的要求(人人会写代码、懂一点设计和业务),阶段切分是对气质的描述(有人爱 0→1,有人爱 1→100,有人爱把 100 磨平)。"scalers 在 Anthropic 很受欢迎"也侧写了 2026 年中公司的阶段。

但他同时把"人类持久优势"的边界又收窄了一档:在 Acquired Unplugged 上他提出,连 product taste 也可能被自动化——他已经在跑数百个 Claude 实例监控各反馈源、自动挖掘产品 idea。最后剩下的人类领地,他认为是 values(价值观):

"Teaching the model how to be a good model — the same way we teach kids how to be good people."

"教模型如何做一个好模型——就像我们教孩子如何做好人一样。"

Acquired Unplugged, 2026-06

这个未来里有一个具体的操作性问题:不写代码了,工程师怎么继续学习、怎么"stay in the loop"?他在 @Scale 上给出的答案是 Claude Code 的 output styles——Claude Code 团队每个新工程师入队时都会被告知打开 exploratory 风格:

"Whenever any new engineer joins our team, we tell them to use the exploratory output style... anytime Claude will make a change, it'll explain to you: hey, here's how the architecture works, here's how this language works... here's how this part of the codebase works — so that you can learn."

"每当有新工程师加入我们团队,我们都会告诉他们使用 exploratory output style……Claude 每次做改动时都会向你解释:这个架构是怎么回事、这门语言是怎么用的……代码库的这部分是怎么工作的——好让你能学到东西。"

@Scale fireside, 2026-06

面向非工程师还有更进一步的 learning 风格:模型不替你做,而是一步步教你做("第一步打开这个文件这样改;第二步跑这条命令;好,我看到你做完了;第三步……")。他说这套东西对他自己也有用——在技术栈变化、接触新语言时,output styles 是他"理解正在发生什么"的工具。[@Scale, 2026-06] [推断] 这是"conducting the orchestra"比喻缺失的另一半:指挥不碰琴,但仍需要读谱的能力——output styles 是他给"读谱能力如何在不拉琴的情况下维持"这个问题的产品化回答。

关于新技能:model elicitation 与"经验科学"

如果说 2026 年上半年他讲的是"哪些角色会消失",7 月在 YC Startup School 上他给出了更可操作的另一半:取代"写代码"的那个技能到底是什么。他的答案是 model elicitation——给模型一个"看起来略微太难"的任务,配上让它自我验证的工具,然后放手:

"The skill nowadays is less about prompt engineering and more about figuring out how do you give Claude a hard task that seems a little bit too hard. And then how do you make it possible for Claude to verify its work along the way? And the verification, I think, is probably the single most important thing that people do not get right."

"如今的技能已经不太是 prompt engineering,而是搞清楚:怎么给 Claude 一个看起来略微太难的难任务?然后,怎么让 Claude 能沿途验证自己的工作?而验证,我认为大概是人们最普遍没做对的、单一最重要的事。"

Y Combinator Startup School(与 Diana Hu), 2026-07

这个技能的底层是一种心智姿态的转换——把模型当活物,把工程当经验科学:

"The way to think about it is almost like a living creature... It's a thing where every model generation, it behaves differently. It has a slightly different personality. And you have to take the time to get to know it."

"正确的思考方式几乎是把它当作一个活的生物……每一代模型,它的行为都不一样,性格都略有不同。你必须花时间去了解它。"

Y Combinator Startup School, 2026-07

"Forget all the things that you learned about past models. Forget everything that you've learned about computer science theory in class... It's not a theoretical science, it's become an empirical science."

"忘掉你从过去的模型身上学到的一切。忘掉你课堂上学的计算机科学理论……它不再是一门理论科学,它已经变成了一门经验科学。"

Y Combinator Startup School, 2026-07

被问到"普通人怎么学会像 Boris 一样用 Claude Code"时,他的第一反应是反方法论的:

"Maybe like, don't listen to the LinkedIn influencers... Everyone's looking for like the one weird trick... that doesn't exist. The way the model works is you have to approach it empirically."

"也许是:别听 LinkedIn 上那些 influencer 的……所有人都在找那个'一招鲜'……那东西不存在。模型的工作方式决定了你必须以经验主义的方式对待它。"

Y Combinator Startup School, 2026-07

[推断] "经验科学"是他一系列旧说法(living creature、ablation-as-eval、try-observe-iterate、"forget your priors")的最终收束:它把 2.2 的产品哲学、2.5 的个人工作流和这里的技能论统一成同一个认识论姿态——在能力以月为单位跃迁的对象面前,先验理论的半衰期太短,唯一稳定的方法是实验本身。

关于这个历史时刻:印刷术、拖拉机、洗衣机

Boris 极其偏爱用历史技术类比来给当下定位,核心是印刷术:

"I think one metaphor I have for this moment in time that we're in is the printing press in the 1400s."

"对我们所处的这个时刻,我有一个比喻,就是 1400 年代的印刷术。"

Pragmatic Engineer, 2026-03

"In the 50 years after the first printing press, there was more literature published in Europe than in the thousand years before."

"在第一台印刷机问世后的 50 年里,欧洲出版的文献,比之前一千年的总和还多。"

Sequoia Capital, 2026-05

他特别喜欢一个 15 世纪抄写员(scribe)的故事:那位抄写员对印刷术充满热情,因为反复誊抄文字本就枯燥,而手绘插图和装帧才是乐趣所在——正如 Boris 不再需要处理版本控制和工具链的琐碎,反而"从未如此享受编程"。

印刷术类比的另一面是节奏的耐心:识字率从印刷术后的不到 1% 涨到全球 70%,用了 200 年。他用拖拉机(1890 年代发明,但到 1960 年代美国拖拉机数量才超过马)和洗衣机(把洗一次衣服从五六小时缩短到几小时,成为女性大规模进入劳动力市场的因素之一)来说明:革命性技术的普及总是缓慢、需要训练、初期还很贵很烂。

而对"技能萎缩"的担忧,他用家族三代编程史反驳——这不是萎缩,是技术的"沧海桑田":

"Programming is always in flux. It does not feel like atrophy; it feels like a sea change in technology."

"编程一直在剧烈变动。这感觉不像是能力萎缩;它感觉像是一场技术上的沧桑巨变。"

Platformer (Casey Newton), 2026-05

他常拿汇编类比:今天高级语言下面跑的仍是汇编,但几乎没人懂汇编了;同理,几年内"读懂人写的代码"也会变得越来越无关紧要。但他也为"手艺"留了位置——团队里的工程师 Lena 周末仍手写 C++ 纯粹为了乐趣,"there's always room for that"。

关于产品:latent demand 是单一最重要的原则

前文已多次出现,这里把它作为方法论独立成条。Boris 认为这是他思考"下一步建什么"的主要方式,简单到一句话:

"Latent demand is the main way that I personally think about product... you build a product in a way that is hackable, that is kind of open-ended enough that people can abuse it for other use cases it wasn't really designed for."

"潜在需求是我个人思考产品的主要方式……你以一种可魔改的方式构建产品,足够开放,让人们能把它'滥用'到那些它本不为之设计的用例上。"

Every.to, 2025-10

它的孪生原则是一个关于人性的清醒判断:

"People will only do a thing that they already do. You can't get people to do a new thing."

"人们只会去做他们已经在做的事。你没法让人们去做一件全新的事。"

Y Combinator, 2026-02

所以产品的杠杆不在"创造新行为",而在"让人们已经在做的事变得更容易"——再去观察他们如何越界滥用,顺着那个方向建下一个产品。Claude Code → Cowork 正是这条逻辑的完整演绎。

latent demand 还有一个方法论上的副作用——它让预测失效。2026 年 9 月在 CHM 被问"有没有某个时刻意识到这东西比预想大得多",他说团队一直"屏着呼吸",因为曲线升得这么快,"你永远不知道它什么时候停";然后给出一个来自自己早年经历的解释:

"I worked in venture capital for a little bit. So when you work in VC, you think in TAMs, like the total available market... And for something like an agent, it's really hard to size the total available market. So it's hard to know how long the curve will keep going. I think the one lesson the team and I have learned is to just stop forecasting. Because there's just no way, there's no way to guess."

"我在 venture capital 待过一小段时间。做 VC 时你用 TAM——total available market——来思考……而对 agent 这样的东西,很难估算它的总可用市场。所以很难知道这条曲线会走多久。我想团队和我学到的唯一一课就是:别预测了。因为根本没办法,没办法猜。"

CHM Live · Anthropic's Boris Cherny, Creator of Claude Code (2026-09-23) [00:27:28]

财务部门每个季度都问"你预计多少用户、涨多少",而答案是"猜不出来,人总会让你意外"。[推断] 这与 2.5 "literally plot it out"(把指数画出来顺着走)并不冲突——那是对模型能力的预测,这是对需求的预测;他相信前者可外推、后者不可外推,恰好是 latent demand 的定义本身(需求在被产品释放前不可见)。他说的"VC 经历"在既有履历里没有单列;[推断] 最可能指 §一 的 Coatue Management 阶段(档案记为他口中的"hedge fund"经历,而 Coatue 也做私募成长/风险投资),但他本人未点名,此处照录不作调和。

关于创新与组织:你没法逼出创新,只能给空间

"Like you can't force it. There's no roadmap for innovation. You just have to give people space."

"你逼不出它。创新没有路线图。你只能给人空间。"

Lenny's Podcast, 2026-02

这与"战略性人手不足"、"prototype 而非 PRD"、"Member of Technical Staff"扁平职级是同一套逻辑的不同切面:降低层级与流程的摩擦,让有内在动机的个体在足够的资源(token)和足够的空间里高速试错。

他还把这套放到更大的商业判断里(Big Technology / Sequoia):用 Hamilton Helmer 的 Seven Powers 框架看,AI 会重排护城河——switching cost 因为 agent 能帮用户迁移而减弱,而网络效应、规模经济、cornered resource 会更重要;所谓 "SaaS-pocalypse" 是个误称,但小而 AI-native 的团队确实会高速冲击被 legacy 困住的在位者,创业公司数量可能增加 10 倍。

关于组织采纳 AI:五级成熟度阶梯(Steps of AI Adoption)

2026-08-04 他发表了迄今最系统的一篇组织方法论(X thread + artifact 表格,数小时内 25 万+ 阅读):把团队的 AI 采纳度按并行 agent 数分成五级——Gated(0 个)→ Assisted(~1 个,被监督的 pair programmer)→ Parallel(~5–10 个,orchestrator)→ Supervised autonomy(~100 个,manager of managers)→ AI-native(1,000+ 个,按 intent 定方向、exception-only 监控)。框架的锋利处不在分级本身,而在两个论断:

• 升级靠移除瓶颈,不靠加 token。每一级各有一个具体瓶颈:0 级是"legacy 安全审批流程 + 盯着 cost per token 而非 outcomes 的心态"(与技术无关);1 级是人的注意力(无自动验证,所以逐条读);2 级是 review 涌来的代码流;3 级是对 loop 的信任与团队决策吞吐——问题从"你读代码了吗"变成"模型缺了什么 context";4 级是识别"该自动化什么"+ 按工作类型定护栏。(经多家二手转录交叉还原;原文以 X thread 为准)
• 这解释了组织内的 10x 落差:为什么一个人已经 10x 而组织整体停在 gated——差距不是 token 预算,而是每一级各自没被拆掉的瓶颈。

他同时给出自我定位:Anthropic 组织整体在第 3 级、推进第 4 级;他本人刚到第 4 级。[Steps of AI Adoption, 2026-08-04]

[推断] 这个框架是他个人叙事的组织化翻译:1→2 级的解法(自验证回路、auto mode、自动 code review)就是他 2.5 节的个人工作流迭代;3→4 级的工具(Agent SDK、Claude Tag、护栏治理)就是 2.8 节的平台化路线图。换言之,他把"Boris 一个人走过的路"编纂成了组织的爬梯手册——每一级的瓶颈,都是他本人在过去 18 个月里亲手撞过再拆掉的那面墙。

关于成本:对标工程师工资,而非软件订阅

2026 年 6 月他在 Fortune Brainstorm Tech 上针对"AI 工具太贵"的常见抱怨给出一个定价锚点的反转——组织把 AI 成本和更便宜的软件订阅比,是比错了对象:

"Compare it to what the cost would have been if an engineer had done this work. That's the benchmark."

"去和'如果由一个工程师来做这件事会花多少钱'比。那才是基准。"

Fortune Brainstorm Tech, 2026-06

他举的极端例证:一次整个 codebase 的跨语言重写(Bun 重写,用 Opus 4.8 + dynamic workflows)6 天完成,而人类工程时间预估约 1 年。[Fortune, 2026-06] 这与他在团队内部"先给足 token、别先优化成本"(见 2.4)是同一个算术:token 开销相对工程师工资是小数。

同月在 @Scale 上,他把这套算术进一步压缩成一条不对称箴言。被问"高性能但昂贵的模型 vs token 效率怎么平衡"时,他先承认 token 对 Anthropic 自己也不免费("我们用掉的每一个 token,都是没能给到客户的 token"——机会成本),然后给出核心判断:

"There's probably like a 50% chance to reduce the investment, but probably like a thousand percent opportunity... to increase the return. And so what I would think about is just use the most expensive model and focus on how do I get more out of it?... Do not focus on cost-cutting."

"降低投入那一侧,大概有 50% 的空间;而提高回报那一侧,大概有 1000% 的机会……所以我的想法就是:直接用最贵的模型,专注于'我怎么从它身上得到更多'……不要把精力放在削减成本上。"

@Scale fireside, 2026-06

落到组织操作上,他的处方是顺序问题:先把 token 发给所有人——不只工程师,还有 PM、设计师、数据科学家——鼓励实验、找到内部用例;之后再在后端控成本(per-seat 限额、advisor 模型、部门预算)。成本要"受控、被治理",但"几乎全部精力应该放在提高回报上"。[@Scale, 2026-06]

技术债的经济学:过去"根本不会做"的整库迁移(2026-07)

7 月在 Odd Lots 面向金融受众,他再举了一次 Bun 的跨语言重写(很可能就是上文 Fortune 例证那一次;同一判断见本节上文)——这次的口径是 Jarred Sumner 一人、约 11 天、从 Zig 迁到 Rust、用 Claude Code + dynamic workflows,"过去要几个工程师干上一年左右"[Odd Lots, 2026-07-20, 00:46:49];与 Fortune"6 天"的差异档案不做调和,主持人 Joe Weisenthal 另称成本约 $150K credits(⚠️主持人口径,Boris 未确认)。相对 Fortune 版新增的,是他接着讲的为什么过去不做:

"Back in the day, like we just never would have done that because you have to stop development for a year to do it. It's just like no business could actually pay that cost. But yeah, like the economics are really changing."

"在过去,我们根本不会做这件事,因为你得停下一年的开发来做它。没有哪个企业真的付得起这个代价。但是,经济学真的在变。"

Odd Lots · The Creator of Claude Code on The Hottest Piece of Software in the World (2026-07-20) [00:47:16]

由此他回答了 Tracy Alloway 关于银行 COBOL 遗留系统的问题:"确实有很多银行在用 Claude Code 做这类迁移"(⚠️自证,无客户名);"迁移是模型一直在进步的核心技能之一";如果你有一个大的旧代码库、过去"停下开发不划算、全迁到 Java 也不划算",现在"直接 prompt Claude Code 就行"。[推断] 这把 §一 Meta 时代他赖以晋升的核心能力(大规模代码迁移,Comet、Python→Hack)直接变成了一个 prompt——他本人的职业履历,就是"技术债的税被取消"最具体的注脚。

为什么 data center 投资是千亿级:三条互相追赶的指数(2026-09)

9 月在 CHM 被问"什么在根本上驱动 AI 数据中心的万亿级投资",他给了一个与"meat brain vs exponential"(2.5)一脉相承、但第一次落到宏观层面的框架。先分两类用途——训练与推理(Anthropic 既是产品也是平台,"很多客户在我们之上建产品");推理这一侧:

"There's kind of like three lines that are racing together and all of them are exponential, which makes it a little hard. One is the amount of compute that is built... The second line is how efficient the model is. And how cheaply you can serve one token of intelligence or kind of one flop of intelligence... And then the third line is demand for AI... What's hard is that these are three exponentials and they're constantly racing and in balance with each other."

"有三条线在互相追赶,而且全都是指数的,这就有点难办。一条是建成的算力总量……第二条是模型有多高效——serve 一个 token 的智能、或者说一个 flop 的智能,能便宜到什么程度……第三条是对 AI 的需求……难的地方在于,这是三条指数,它们一直在互相追赶、互相平衡。"

CHM Live · Anthropic's Boris Cherny, Creator of Claude Code (2026-09-23) [00:47:48]

第二条线他说得最具体:每次发布新模型,实验室公布的"成本—智能"曲线(他称 TTC 曲线)就向左移一截——"训出更好的模型,用更少的算力产出同样的结果",单位智能的成本持续下降。他举的例子是当周刚发布的 Opus 5.5:"比过去的模型高效得多,所以我们能大幅降价、给 Pro 和 Max 用户更高的限额"。[推断] 把这三条线与他的成本箴言并读:"不要削成本、专注提回报"的底气,正来自第二条线——单位智能成本的下降是别人替你做的,你能做的只有去抓第三条线。

关于自我:味噌、肉脑、与喷气背包

Boris 的个人特质和他的产品哲学惊人地同构——都是"长时间尺度 + 用更少做更多 + 谦卑面对不可知"。

他在日本乡下做味噌(红味噌要发酵 2–4 年),说 post-AGI 想去做味噌;他读科幻(Stross 的《Accelerando》、刘慈欣的《三体》/《流浪地球》),认为最好的技术书是《Functional Programming in Scala》;他形容长时间盯着一本书读三小时"genuinely cathartic"。他承认自己已经到了"会梦见 Claude Code"的痴迷程度:

"I was so focused on shipping... I started having dreams about Claude Code, and that's still all I dream about."

"我太专注于发布了……我开始做关于 Claude Code 的梦,直到现在我梦到的还全是它。"

Platformer (Casey Newton), 2026-05

而对被自己造的工具改变的体感,WIRED 记录下了那句最广为流传的话:

"It's like I have a jet pack. I can't stop thinking about it."

"感觉就像我背了个喷气背包。我没法停止想它。"

WIRED (Steven Levy), 2026-05

四、数据来源

网络研究(31 篇)

完整缓存见 cache/web/01–31-*.md 及 cache/web/_summary.md。部分关键访谈(Lenny's Podcast 等)原文在付费墙后,内容通过多篇二手详尽摘要交叉还原。

播客访谈(21 期)

完整 digest 见 cache/podcasts/<episode_id>.json 及 cache/podcasts/_summary.md。

关键合作者(出现在档案中)

关键数据点

未使用但已扫描(质量过滤说明)

• Lenny's Podcast 完整 transcript:付费墙后无法直接获取;通过 Ernest Chiang / Roger Wong / AOL / BigGo 等多篇二手详尽摘要还原约 80%+ 核心内容,相关引用已尽量标注"via"二手来源。
• Grokipedia / LinkedIn 直接页面:403/404 无法直接抓取,履历信息从多源拼合。
• Sequoia AI Ascent 2026 完整视频 transcript:仅有 description,通过 Sequoia Capital / Training Data 两期播客 digest 覆盖核心观点。
• AI Engineer World's Fair 18 分钟 talk、Anthropic 金融服务 webinar:未获完整内容,相关主题由其他来源覆盖。与 Jarred Sumner 的 live coding(Code w/ Claude SF,2026-05-06,ep 8122665;场次页见 cache/web/30)已于 2026-10-18 提交 Podwise process(1 分钟内到 80% 后超时退出,提交生效),下轮步骤 0 回收。
• CHM Live(ep 9032047)冗余部分:印刷术/抄写员类比、mech-interp 神经元分类器、chatbot vs agent = 工具使用、"经验科学/外星生物"、《Accelerando》均已在档案,未重复折入;"model overhang"表述与 2.2(f) product overhang 同义。
• Odd Lots(ep 8462871)冗余部分:雕塑家蒙眼类比(= 2.5 画家蒙眼)、prompt injection 三层、adoption ladder(= 五级成熟度)、"即便调试也看不到用户数据"(= Vergecast)、模型发布驱动增长拐点,均未重复折入。dup feed 8632421(Bloomberg Podcasts 同题同日)排除。
• 同事为嘉宾、Boris 未出场的 Claude Code 团队集(仅作交叉参考,未折入):Fiona Fung(Lenny's,8277266 等 10 个 feed id)、Thariq Shihipar(Latent Space 9013628/9013682/9022273)、Cat Wu(Lenny's 7832221–7832390;Simon Willison 8439411)、Claude Tag 团队(8347142 "The future of work")。
• 2026-10 sweep 新增排除:7236005(YC Startup Podcast 改题重发 = 7233786)、7288576(Vergecast ad-free = 7288386)、7379537/7379864(Pragmatic Engineer 备用 feed = 7381474)、4490345/4490369(AI Engineer dup / 全天多讲者流 = 4650745)、5735715/8627740(Every / AI & I dup = 5725517)、7368772/7368883(AI Show 新闻综述,主持人转述其访谈)、8717689 等第三方评论转述、8574408 等中文转述节目(质量过滤)、8695806(AAIF 读书会讨论其 loops 文,本人不在场)、8255716/9025341(话题词命中,非本人)。
• @Scale fireside(ep 8288820)冗余部分:jetpack 比喻(已在"关于自我"via WIRED)、Cowork 介绍(已在 2.8)、bottleneck 迁移叙事(已在 2.8 via Fortune)未重复折入;"product sense + distributed system design 是人类残余优势、预计年底关闭"与既有"边界收窄"叙述同源,仅记于 digest。
• YC 同场衍生内容(2026-07-28):8543336(重复 feed)、8575782("We Cut 80% of Claude Code's Prompt",同场 fireside 的浓缩 clip)均按同场去重排除,以 8545347 全场为准。
• Steps of AI Adoption 原文:X thread 抓取被 402 拦截,内容经 Modern Web Labs / explainx / Shelly Palmer / escProfile 多家二手转录交叉还原(见 cache/web/27);引语标注"经二手转录"。
• CNBC TV(7951019)、AI LABS(8575699)、EasyVibeCoding(8558224/8558240)、YC clip(7261285):分别按 TV 短片 / 第三方评论转述 / 中文转述 / 剪辑短片过滤。

本档案以 Claude Code 时期为重心,后续可通过 /refresh boris-cherny 增量更新(关注:Cowork 的非工程师扩张、Routines/Loops 的演化、新模型发布带来的产品形态变化、Boris 关于 "Claudes monitoring Claudes" 的进一步阐述)。