很多人说，在 AI 时代，品味是人类最后的护城河。但 Boris Cherny 不这么认为。
他是 Anthropic 的技术成员，Claude Code 的核心建设者之一。他每天都在用模型写代码，也在用模型研究模型。而他看到的趋势是：所谓「品味」，也在快速被模型学会。
如果连「该做什么」都能被模型掌握，那人类还剩下什么？
在最近的一次访谈中，Boris 聊到了这个话题。
视频地址：https://www.youtube.com/watch?v=RkQQ7WEor7w&t=1s
同时，他也发表了对于其他一些关键问题的看法，比如：
Claude Code 如何从根本上改变公司的体系；
当模型可以写绝大部分代码之后，工程师还值不值得招聘？如果值得，那要看什么？
为什么 Anthropic 内部很多人都是 Member of Technical Staff，没有明确的职级和分工？
给所有创业者的一个反直觉建议为什么是「少招人，多给 token」？
……
这些问题表面上是关于一个产品的诞生与迭代，但每一层的答案，都在指向同一个更根本的变化：组织的运行方式，正在被模型本身重新定义。
而 Boris 给出的答案，非常值得冷静思考。
Claude Code 是如何诞生的？
当主持人问 Boris Claude Code 的起源时，他给出的答案有些出人意料。
在他的讲述里，Claude Code 并不是 Anthropic 一开始就规划好的核心产品，甚至某种程度上可以说是一个意外的产物。
2024 年底，Boris 加入了 Anthropic 的 Labs Team。这个团队的职责不是维护现有产品，而是探索未来产品形态。一方面，他们需要不断推动模型能力的边界；另一方面，他们也在寻找能够真正释放这些能力的新产品。
当时团队有一种非常强烈的感受：模型已经具备了远超现有产品的能力，但市场上还没有出现能够充分利用这些能力的产品。在编程领域尤其如此。
那时候市面上的 AI 编程工具大多还停留在两个方向。一个方向是自动补全，帮助开发者完成下一行代码；另一个方向是问答助手，开发者可以询问某段代码的含义或者某个报错的解决方案。但 Boris 认为，当时还没有真正意义上的 Coding Agent。
于是团队决定做一次更激进的尝试：不再把模型当作辅助工具，而是把它直接变成开发主体。他们想看看，如果从零开始构建一个完全围绕 Agent 展开的编程产品，会发生什么。
不过 Boris 也坦率地承认，最初的 Claude Code 并不好用。
在很长一段时间里，它只能完成他大约 10% 到 20% 的工作。大部分代码仍然需要他亲自编写。今天人们看到的 Claude Code 与那个时期的产品相比，已经完全不是同一个东西。
为什么 Anthropic 会如此重视 Coding？
很多人会认为 Anthropic 重视 Coding 的原因很简单 —— 编程市场足够大，商业价值足够高。但 Boris 给出的解释完全不同。
他说，如果你在 Anthropic 的办公室里随机拦下一名员工，问他为什么来到这里，大概率得到的答案都会是同一个：AI Safety。
在 Boris 看来，Anthropic 从成立开始最核心的使命一直都是 AI 安全。无论是可解释性研究、对齐研究还是其他各种安全方向，本质上都在试图理解模型的行为。但这些研究最终都面临同一个问题：仅仅在实验室里观察模型是不够的，研究者还必须观察模型进入真实世界之后会发生什么。
而 Coding 恰好是一个近乎理想的实验场。
与写作、绘画或者其他开放性任务不同，编程拥有极其清晰的反馈机制。代码能够运行还是不能运行，程序能够通过测试还是不能通过测试，编译能够成功还是失败，答案往往非常明确。与此同时，互联网又提供了海量代码作为训练数据。相比于诗歌创作这种可能存在无数优秀答案的任务，编程问题的正确解空间要收敛得多，因此也更容易验证模型能力。
正因为如此，Anthropic 从很早开始就高度关注 Coding、Tool Use 和 Computer Use。这些方向不仅具有商业价值，更重要的是，它们为研究模型如何与真实世界交互提供了一个天然的实验环境。
从这个角度来看，Claude Code 从来不只是一个面向程序员的生产力工具。在 Boris 的叙述里，它同时也是 Anthropic 用来理解未来 AI 系统的重要实验平台。
Claude Code 为什么突然变强了？
在介绍完 Claude Code 的起源之后，主持人提出了一个很多人都想知道的问题。既然 Claude Code 刚诞生的时候只能完成 Boris 大约 10% 到 20% 的工作，那么后来究竟发生了什么？毕竟今天 Boris 已经公开表示，自己已经有半年时间没有亲手写过代码了。从只能完成一小部分任务，到几乎完全接管开发工作，中间显然发生了巨大的变化。
对于这个问题，Boris 的回答反而异常简单。他说，外界往往会把注意力放在产品功能上，但如果让他回顾那些真正带来能力跃迁的时刻，最重要的原因其实只有一个：模型变强了。
在过去一年里，Anthropic 团队确实持续改进 Claude Code 本身。他们做了大量工程工作，增加了各种新的交互方式和产品形态。最初 Claude Code 只是一个命令行工具，后来逐渐扩展到桌面端、移动端、Slack、GitHub 等不同场景。团队也不断尝试新的功能，例如规划模式（Plan Mode）等各种帮助开发者与 Agent 协作的机制。但在 Boris 看来，这些都属于增量改进。
真正决定 Claude Code 上限的，是底层模型本身。
他提到了几个关键节点。从 Sonnet 4、Opus 4，到后来的 Opus 4.5，每一次模型能力提升，都会直接反映在 Claude Code 的表现上。
主持人随后问到，Claude Code 的使用经验是否会反过来影响模型研发。Boris 的回答是，Anthropic 内部几乎所有人每天都在使用 Claude Code，包括研发模型的人、开发产品的人…… 整个公司都在用。
因此并不存在一条专门的反馈通道。反馈本身就是公司日常工作的一部分。
研究人员在使用过程中发现问题，模型团队就会看到这些问题；模型能力提升之后，大家又会立刻在实际工作中感受到变化。产品和模型并不是两条平行的线，而是在同一个循环里共同演化。
Claude Code 给 Anthropic 带来了多大的生产力提升？
Boris 说，在 AI 实验室工作久了以后，大家会习惯用指数增长的方式思考问题。很多内部指标 —— 无论是收入、使用量还是模型能力 —— 看起来都更像指数曲线，因此他们甚至习惯使用对数坐标来观察变化。
而代码产出也呈现出了类似趋势。
根据 Anthropic 曾经公开披露的数据，自从 Claude Code 在公司内部广泛使用之后，每位工程师产出的代码量增长了大约三倍。但 Boris 特别强调，这已经是过时的数据了。实际增长远远超过这个数字。
更有意思的是，这种增长发生在公司规模快速扩张的过程中。
按照传统经验，一家公司工程师人数越多，平均生产力往往越低。新人需要学习系统，老员工需要回答问题，组织沟通成本会不断上升。
但 Boris 观察到的情况恰好相反。过去一个新工程师加入公司，可能需要数周时间才能真正熟悉内部系统。现在这个过程往往只需要两天。
原因并不是培训体系发生了革命性的变化，而是因为大家已经习惯直接询问 Claude。新人不需要知道数据库应该如何查询。他们甚至不需要知道应该向谁请教。在 Anthropic 内部，当有人问「数据库怎么查」的时候，经常得到的回答是：「打开 Claude，让 Claude 去查数据库。」很多原本需要资深工程师掌握的隐性知识，开始被转移到 Agent 身上。在 Boris 看来，这或许才是最重要的变化。
Claude Code 提升的并不仅仅是代码生成速度，而是在逐渐压缩组织内部知识传递的成本。过去企业依赖层层传帮带来完成知识流动。而现在，越来越多知识正在被直接封装进模型。
从穿孔纸带到 Vibe Coding，
人类只是再次提升了编程的抽象层级
既然 Claude Code 那么厉害，Anthropic 新招的工程师还写代码吗？当主持人抛出这一问题后，讨论的焦点随即转移到了：你怎么定义「写代码」？
在 Boris 看来，软件工程的发展历史，本质上就是一部不断提高抽象层级的历史。
他的祖父在苏联时代使用穿孔卡编程。那个时代，程序员需要在纸卡上打孔，再把纸卡送进计算机等待结果。后来出现了汇编语言。再后来出现了 Fortran、Cobol。然后是 Java、Python、JavaScript。每一次抽象层级的提升，都会有人认为：这已经不是真正的编程了。写汇编的人会看不起写高级语言的人，写 C 的人会觉得 Python 太简单。而 Boris 认为，今天发生的事情本质上没有区别。人类只是再次提升了编程的抽象层级。
他描述了自己过去一年工作的变化过程。最开始的时候，他和大多数开发者一样：打开 IDE、编写代码、偶尔使用自动补全，这是传统的软件开发方式。
后来 Claude Code 出现之后，他的工作方式变成了：向 Claude 描述需求、让 Claude 写代码、自己负责检查和修正。在这个阶段，人依然在直接指挥模型。只是代码由模型生成。但 Boris 认为，这其实只是一个过渡阶段。
真正有趣的变化发生在最近。他说：现在我甚至不再直接 Prompt Claude 了。他的工作已经变成了另一种形式。他会编写各种自动运行的流程和循环。这些循环负责向 Claude 提出问题，负责拆解任务，负责管理上下文，负责协调多个 Claude 实例之间的工作。
换句话说：过去是人向 Claude 下达指令。现在则是程序替他向 Claude 下达指令。而他的工作变成了设计这些自动运行的系统。他用一句非常简洁的话概括：我的工作已经变成写 Loops。
看来，Boris 不只是把代码外包给 Claude，而是在把「与 Claude 沟通」这件事本身也自动化。这已经不再是大家熟悉的 Copilot 模式。更接近于一个由多个 Agent 持续运行的系统。
Boris 提到，在去年十一月的时候，他甚至把自己的 IDE 卸载了。原因不是一种象征性的表态，而是因为他发现自己已经一个月没有打开过 IDE。既然完全不用，自然就卸载了。那段时间里，他通常同时运行五个到十个 Claude 实例，不同的 Claude 负责不同任务，而他主要负责监督整个过程。
工程师不写代码了
招聘看什么？
这时主持人提出了一个很有意思的问题：如果今天一个工程师想加入 Anthropic，Anthropic 会如何评估他？或者说：在一个越来越少亲手写代码的世界里，公司究竟在寻找什么样的人？
Boris 的回答几乎直接引出了后面关于组织形态的讨论。他说，Claude Code 团队最喜欢的一类人其实是：Generalist（通才）。
原因很简单：过去的软件组织有着非常明确的分工 —— 用户研究员负责理解用户，设计师负责设计产品，产品经理负责规划需求，工程师负责实现功能，每个人都在自己的环节里工作，像一个流水线。
但 Claude Code 团队在过去半年里发现，这种分工正在迅速瓦解。团队里的每一个工程师，几乎每天都在做各种各样原本不属于「工程师」职责范围的事情。有人直接和用户沟通，有人在设计交互，有人在拉数据、做数据分析、搭建 dashboard。没有人只做一个狭窄的环节。
Boris 甚至举了一个更极端的例子：Anthropic 的设计师也在写代码，财务同事也在写代码。Satya Nadella 管这种角色叫「Builder」。这个说法可能比「工程师」更准确，因为真正的边界已经不是「你会不会写代码」，而是「你能不能把一件事从想法变成现实」。
从 Boris 的视角来看，AI 并没有简单地替代程序员，它真正改变的是知识与执行之间的关系。过去一个人之所以不能同时承担多个角色，很大程度上是因为学习成本太高。而现在，模型正在不断降低这些能力之间的迁移成本。因此未来最有优势的人，未必是某一个领域最深的专家，而可能是那些能够快速跨越不同领域、不断整合资源的人。
这也是为什么 Boris 认为：我们正在进入一个属于 Generalist 的黄金时代。对于那些愿意做很多事情的人来说，现在可能是历史上最好的时代。
Member of Technical Staff 不是噱头，
是对未来的预演
主持人把话题从产品拉到了文化和组织设计上。他注意到，Boris 的头衔不是「产品总监」或「工程总监」，而是 Member of Technical Staff，而且 Anthropic 很多人都是这个头衔。他想知道：这有什么好处？有没有坏处？
Boris 非常坦诚。他说最糟糕的一点是：你在 Slack 上给人发消息，对方头衔是 MTS，你根本不知道这人是设计师、工程师还是经理，也不知道他到底在做什么项目。但他非常喜欢这个头衔。
他回忆起在 Meta 的经历。Meta 所有的软件工程师都只有一个头衔：Software Engineer，没有 senior、principal 这种层级。一开始他不太理解，后来发现这其实是一种文化上的设计。如果你给人一个「高级」的头衔，别人会因为 deference（礼貌性服从）而不好意思反驳他的坏主意。而把所有人放在一个看上去平等的场域里，反而会迫使大家用想法本身去竞争，而不是用资历。
当然，他承认，等级并不会因为头衔消失而真的消失。你知道某人是 L7，只是头衔没写出来。但有意思的是，很多时候你真的不知道。
他讲了一个自己在 Facebook 做 L4 工程师时的故事。他有了一个想法，直接去找了负责 connectivity 的 VP，说：这是我的想法，我们一起做吧。那个 VP 根本不知道他是什么级别。他又去找了另一个 VP，又失败了。第三次，成了。他们组了团队，开始做产品。
Boris 说，现在他在 Claude Code 团队里每天都在看到同样的事。那些有 20 年、30 年经验的资深工程师，反而要花好几个月「unlearn」—— 忘掉那些已经不再适用的旧习惯。而一个新毕业的大学生加入团队，反而能教他怎么更好地用 Claude Code，因为年轻人天然就用模型思维去思考。
每一次新模型出来，所有人都要 recalibrate（重新校准）。经验在这个时代不是线性累积的，有时甚至是负债。
所以 Member of Technical Staff 这个看上去模糊的头衔，在 Boris 看来，是对一个即将到来的现实的预演：工程师、PM、设计师、用户研究员之间的界限，到年底就会基本消失。与其被动接受这个变化，不如用头衔的方式主动把大家推到同一个角色上：Builder。
给所有创始人的建议：
少招人，多发 tokens
主持人请 Boris 从 Anthropic 的视角，给在场的创始人和公司一个更通用的建议：2026 年底之前，组织应该怎么调整心态？
Boris 的第一句话就带着笑点：「给所有人尽可能多的 tokens。」就像黄仁勋那句著名的话：「你买得越多，省得越多。」
这不是玩笑。他是认真的。他给出的具体建议是两件事：
第一，尽量多给 tokens，让大家疯狂实验。
第二，每个项目都故意「少给一点人」。如果你觉得一个项目需要四个工程师，就只放两个人上去，然后给他们大量 token，让他们自己想办法。你会发现，他们大概率真的能做到。他们会把能自动化的东西全部自动化，而且因为自动化了，下次再做会更快、更便宜。这是一个复利效应。
主持人对这个建议做了一个非常精炼的总结：用更少的人，把预算从人的工资转移到 tokens 上。这会抬高你的 upfront cost（前期成本），但会大幅降低 ongoing cost（持续成本）。就像 pre‑compiling 一样 —— 你一次性把脏活累活做完了，后面每一次重复执行都几乎免费。
Boris 表示完全同意。主持人接着问了一个更尖锐的问题：过去人们非常以自己的 discipline（专业领域）为傲。PM 以自己写的产品文章为傲，设计师以自己精美的作品集为傲。难道在 12 个月内，所有人都要放弃「我是某某某」这种身份认同，变成一个「灵活的、会消耗 tokens 的袋子」吗？
Boris 说：「我可能会用稍微不同的措辞，但…… 对的，差不多就是这样。」
品味也会被模型侵蚀？
最终剩下的只有「价值观」
主持人提到了之前和 Anthropic 另一位成员 Jared 聊过的一个话题，想听听 Boris 的看法：你们怎么理解「taste」（品味）？
Boris 的回答非常坦诚。他说，每一次他觉得自己在编程这件事上有什么「特殊的品味」时，最后都被证明是错的。
他曾经非常喜欢函数式编程，喜欢 Haskell、Scala 这类语言。在 Claude Code 早期代码库里，他定了一条规矩：不准用 class，只能用 function。周末工程师们偷偷提交带 class 的代码，周一被他 reject 掉。后来模型开始大规模写代码，模型直接写 class。他看了半天，最后说：好吧，也许模型是对的。我的这个执念可能本来就没什么意义，业务结果达到了，而且更快，代码也不差。
然后他做了一个更大胆的推演。现在大家总说「产品品味是最后的 alpha」。但他认为，这种 alpha 也在快速消失。
他现在已经有几百个 Claude 实例在同时运行。有些在刷 Twitter 反馈，有些在看 GitHub issues，有些在看 Slack，然后自己分析下一阶段应该做什么功能。目前大部分想法还是坏的，大概 20% 是好的。但等下一个模型，再等 3 到 6 个月 —— 大部分想法可能都会是好的。
主持人追问：那人类最终还有什么独特的东西？有没有什么东西是模型永远做不到的？
Boris 想了一下，说：价值观。
他说，最终我们要教模型的，和我们教孩子的是同一件事：如何成为一个好的存在。如何做对的事情，而不仅仅是把事情做对。
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：liyazhou@jiqizhixin.com
