Claude Code 是怎么诞生的？
一个有意思的问题是：为什么这一轮 AI 编程里，最有代表性的产品之一，没有首先做成一个漂亮的 IDE 插件，而是以一个看起来有点朴素、甚至有点工程师自用味道的终端工具出现？
我最开始读 Platformer 对 Boris Cherny 的采访时，注意力其实不在“AI 会不会取代软件工程师”这个标题上。更有意思的是 Boris 对角色变化的描述：传统意义上边界清晰的 software engineer 会被重新拆开，越来越多人会成为能直接创造软件的 builder。也就是说，消失的未必是软件创造，而是那种“只有工程师能把想法变成软件”的组织分工。
Claude Code 就是这个变化的早期样本。
如果只看结果，它很容易被理解成 Anthropic 对开发者市场的一次有计划进攻。2025 年 2 月，Anthropic 在发布 Claude 3.7 Sonnet 时，把 Claude Code 作为研究预览版一起推出；官方说法是，开发者可以直接在终端里把一部分真实编码任务交给它：搜索和阅读代码、编辑文件、写测试、运行命令，甚至处理 Git 工作流。到了 2025 年 5 月 Claude 4 发布时，Claude Code 已经正式可用，并开始从终端扩展到 IDE、后台任务和更完整的工程环境。
但 Boris Cherny 在 Platformer 和 Pragmatic Engineer 的两次访谈里讲出的诞生过程，反而没有那么像一张产品路线图。它更像是一个典型的 AI 时代产品故事：模型能力已经在那里，只是还没有被放进正确的工作回路里。
我认为 Claude Code 的关键诞生时刻，不是“Anthropic 想做一个 Copilot 竞品”，而是 Boris 意识到一件事：如果模型不仅能回答问题，还能进入文件系统、运行命令、观察结果、再修改代码，那么它就不再只是一个写代码的聊天窗口，而开始变成一个在开发环境里行动的 agent。
起点不是代码，而是一段 AppleScript
Boris Cherny 加入 Anthropic 是在 2024 年 9 月。他之前在 Meta 做过 TypeScript、开发者工具和编程语言相关工作，也做过一些早期 agent 项目。按他的说法，他刚加入 Anthropic Labs 时，并不是被安排去做一个“AI 编程产品”。当时 Labs 里还有人在做 Model Context Protocol（MCP，模型上下文协议）和桌面应用这类实验性项目；Boris 的起点更简单，他只是想尽快熟悉 Anthropic 的 API。
于是他做了一个低成本原型。没有复杂 UI，没有完整产品设计，最容易搭起来的界面就是终端。这个选择后来显得很有战略意义，但一开始并不神秘：终端只是最快、最便宜、最接近开发环境的入口。他先让模型回答一个很小的问题：我现在在听什么音乐？
这听起来不像一个严肃的编程产品原点。但模型给出的解决方式很有意思：它没有像人类工程师一样先去想 Spotify API、权限、OAuth 或者集成流程，而是直接写了一段 AppleScript，让本机告诉它当前正在播放什么。
这个小实验最值得注意的地方，并不只是“模型会写 AppleScript”。它暴露了一个不同的解题方式。人类工程师会先寻找系统里正式、规范、可维护的入口；模型会在给定环境里寻找可用的行动路径。它不一定优雅，但有时候很快，而且足够有效。
这就是 Claude Code 的第一层底色：它不是从“代码补全”开始的，而是从“让模型在真实电脑环境里做事”开始的。
关键一步：给模型一个身体
后来 Boris 往这个原型里加了更多工具：读文件、写文件、搜索代码、运行 shell 命令。这个变化看起来只是工具列表变长了，但它改变了产品的性质。
在传统 AI 编程助手里，模型多数时候是在“文本层”工作。你把一段代码、一个报错、一段需求贴进去，它返回一段建议。它可以很聪明，但它和真实工程环境之间隔着人。人要复制、粘贴、运行、检查、再回来问下一轮。
Claude Code 的关键变化，是把这个中间层尽量缩短。它可以自己进入代码库，顺着 import 和调用链阅读上下文，改文件，跑测试，观察失败，再继续修。它不是只生成答案，而是进入一个循环：观察、判断、行动、验证。
我的理解是，Claude Code 的“Code”其实不是重点。重点是 “Claude + tools + feedback loop”。代码只是第一个最适合这个模式的场景，因为开发者的工作天然有文件、有命令、有测试、有版本控制，也天然允许机器快速得到反馈。
这也是为什么它一开始是终端产品，而不是一个更漂亮的应用。终端不是退而求其次的 UI，而是开发者工作流里最接近真实行动层的界面。文件系统、bash、测试命令、git、package manager、CI 脚本，都已经在那里。与其重新发明一个软件工程界面，不如让模型直接进入工程师已经在使用的环境。
Product overhang：能力先于产品出现
Boris 在 Platformer 视频里用了一个很有意思的概念：product overhang。意思是，底层模型已经具备某种能力，但市场上还没有一个产品把这种能力释放出来。
这个概念解释了 Claude Code 为什么诞生得像一个意外，又为什么诞生之后扩散得很快。问题不在于大家之前完全不知道 AI 能写代码，而在于大多数产品还在把它包装成“更好的补全”或“更聪明的聊天”。Claude Code 做的事情更激进一点：它默认模型可以负责一个连续任务，而不只负责一句回答。
这两者差别很大。
补全工具的边界在光标附近。聊天工具的边界在上下文窗口里。Claude Code 的边界在整个开发任务里。它未必每次都能完成，但它被设计成可以尝试完成。这个“尝试完成”的姿态，本身就会改变用户的使用方式。
在 Pragmatic Engineer 的访谈里，Claude Code 团队提到过一个反直觉的产品原则：他们尽量少写复杂控制逻辑，尽量让模型“原样”发挥。Boris 甚至说，随着模型变强，很多原来必须靠 prompt 和工具设计硬撑的东西，最后应该被删除。
这点很重要。很多 AI 产品的本能，是用越来越多规则、流程、UI 和 guardrail 去包住模型。但 Claude Code 的早期判断更像是：如果模型能力本身正在快速进步，那么产品层不应该过早把它锁死。因为过重的控制逻辑本质上是在把新模型塞进旧模型时代的假设里。更好的产品层，是提供真实工具、真实反馈和足够清晰的任务边界，让模型能力自己暴露出来。
这也是它和很多 IDE 插件不一样的地方。IDE 插件往往从“怎么嵌入现有编辑器体验”出发；Claude Code 更像是从“怎么让模型接管一个工程任务的闭环”出发。
内部狗粮，比发布更早发生
Claude Code 变成产品，先靠的不是外部市场验证，而是 Anthropic 内部的快速扩散。
按照 Boris 的回忆，他先把这个工具给周围同事用，后来开放给整个公司。Pragmatic Engineer 引述团队说法称，2024 年 11 月开始内部 dogfooding 后，第一天大约有 20 个人使用，到第五天已经到了 50 人左右。Platformer 视频里的说法更强调它在工程团队内部扩散得很快：几天之内，使用者就从一小圈人蔓延到 Anthropic 工程组织的相当一部分。
这类内部采用率，比“我们做了用户调研”更有解释力。因为 Claude Code 面对的第一批用户不是温和的早期试用者，而是 Anthropic 自己的工程师、研究员、产品和设计团队。对这些人来说，一个工具如果只是演示好看，很快就会被抛弃；如果它真的能减少某种工作摩擦，它会自然进入日常。
更有意思的是，Claude Code 后来不只是工程师在用。Boris 在 Platformer 里说，他已经几个月没有亲手写自己日常意义上的代码；他还提到，产品经理、设计师、经理也开始用它完成以前必须依赖工程师的小任务。
这句话不能被粗暴理解成“软件工程师不需要了”。更准确的理解是：软件生产里的某些门槛正在下降。过去不会写代码的人，需要通过工程师把想法翻译成软件动作；现在他们有机会直接操作一部分软件材料。工程师没有消失，但“谁能让软件动起来”的边界变宽了。
这可能才是 Claude Code 最重要的组织含义。它不只让原来的程序员快一点，也让公司里更多角色获得了接近代码库的能力。
为什么 Anthropic 没把它藏起来？
这里还有一个关键问题：如果 Claude Code 在 Anthropic 内部这么有用，为什么要发布出来？
Boris 在访谈里提到，公司内部确实讨论过类似问题。毕竟，如果一个工具能显著提高 Anthropic 自己的研发效率，把它留作内部优势似乎也说得通。但最后他们选择公开，原因和 Anthropic 的身份有关。Anthropic 的核心身份仍然是模型公司和 AI 安全研究公司，而不是单纯靠一个应用套利的公司。让真实用户在真实环境里使用 agent，可以帮助公司理解模型能力、安全边界和失败模式。
这点解释了 Claude Code 和模型发布之间的关系。2025 年 2 月，Claude Code 随 Claude 3.7 Sonnet 进入研究预览；2025 年 5 月，随着 Claude 4 发布，Claude Code 正式可用，并被官方放进更大的 agent 产品叙事里。它不是一个孤立工具，而是 Anthropic 用来观察、训练和暴露模型能力的一种工作界面。
换句话说，Claude Code 是产品，也是实验装置。
对用户来说，它是一个开发工具。对 Anthropic 来说，它还是一个高强度反馈通道：哪些任务模型能做，哪些任务会失败，什么时候需要权限控制，什么时候需要沙箱，什么时候用户会信任它，什么时候用户必须介入。这些东西光靠 benchmark 很难得到，只能在真实工作流里暴露。
它改变的不是敲代码，而是定义工作
所以，Claude Code 是怎么诞生的？
表面答案是：Boris Cherny 加入 Anthropic 后，为了学习 API 做了一个终端原型；一个查询音乐的小实验让他看到模型可以调用本机能力；随后加入文件系统和 shell 工具，内部 dogfooding 后扩散，最终作为 Claude 3.7 Sonnet 的研究预览发布，并在 Claude 4 时正式推出。
但更深一层的答案是：Claude Code 诞生于一个判断，模型已经不该只被当成回答机器，而应该被放进带工具、带反馈、带真实约束的工作环境里。
这让我想到一个更大的变化：编程正在从“写代码”变成“定义工作”。过去，稀缺能力是把想法翻译成准确代码；现在，越来越多代码可以由模型生成，新的稀缺能力变成了：你能不能提出正确的问题，切出合适的任务边界，给出足够上下文，识别错误，验证结果，并知道什么时候不能相信模型。
这不是一个轻松的变化。它不会让复杂软件突然变简单，也不会让工程判断失去价值。相反，它会把工程判断暴露得更直接。以前一个人不会写代码，很多判断错误会停留在想法层；现在模型可以帮他把想法快速变成软件动作，错误也会更快进入系统。
所以我不太喜欢把这件事讲成“软件工程师要消失了”。更准确的说法是，软件工程师原来那一整包工作会被重新拆开。语法生成会变便宜，单线程执行会变便宜，跨文件改动会变便宜；但拆任务、设权限、读 diff、判断测试是否足够、知道什么时候不能 merge，反而会变得更重要。
Claude Code 的诞生给我的启发是：AI 时代最好的产品，未必是把模型包装得最像传统软件的产品，而是把模型放进最高频、反馈最真实、用户最愿意授权的工作回路里。
终端看起来朴素，但它有一个漂亮界面没有的东西：真实。
它连接真实代码、真实命令、真实失败、真实测试，也连接真实组织里那些原本被软件门槛挡住的人。Claude Code 不是因为“AI 会写代码”而重要。它重要，是因为它让我们第一次清楚看到：当模型获得工具和反馈之后，软件生产的边界会怎样重新划分。
这才是它诞生故事里最值得记住的部分。
主要参考来源
- Platformer: Boris Cherny interview: AI and the future of jobs
- Platformer / YouTube: Claude Code creator Boris Cherny on the end of the software engineer
- The Pragmatic Engineer: How Anthropic teams use Claude Code
- Anthropic: Claude 3.7 Sonnet and Claude Code
- Anthropic: Claude 4 announcement
- Anthropic Docs: Claude Code overview