编辑 | 听雨
出品 | 51CTO技术栈（微信号：blog51cto）
自从 5 月份正式开放以来，Claude Code 已经在开发者圈掀起了风暴。
据统计，这款工具目前的年度化收入超过 5 亿美元，仅仅在发布后三个月内，使用量就激增了 10 倍以上。
那它到底怎么构建的？
小编最近看了一篇深度专访，作者 Gergely Orosz，采访了 Claude Code 的几位联合创始工程师和产品经理，信息密度颇为巨大。三位可以说都是CC元老级员工。
Boris Cherny，该项目的首位工程师，也是最初原型的设计者；Sid Bidasaria， Claude Code 的第二位工程师，也是 “Claude Code 子代理（subagents）” 的创建者；
Cat Wu，首位产品经理。
讨论中，他们分享了 Claude Code 的构建方式，也洞察了一个成功的“AI 优先工程团队”是如何运作的。
作者甚至形容自己提前窥见了未来，窥见了一个高速运转的初创公司可能的工作方式。
“值得庆幸的是，在这个未来里，软件工程师仍然非常吃香。”
可以说内容非常稀有，为此小编特地为大家整理了这篇采访文章。
我们这篇文章会聊以下这些，enjoy：
- Claude Code 的起源
- 它的技术栈 & 架构
- 怎么做到几天交一个功能
- 交互体验：终端 UX 的“进化”
- “AI 优先”工程团队是什么样子
- 子代理（subagents）功能是怎么炼成的
- 对未来 AI 辅助工程团队的一些展望
好，话不多说，咱们开整！
1.起源：怎么从“听歌小工具”演变成开发神器
最早，Boris 在 Anthropic 工作，想着用 Claude 模型写个命令行工具：让它读出开发者在工作时在听什么歌，还能控制音乐。
最初版本很简陋：不能读文件，也不能执行 shell 命令，只能做极基础的“问答＋控制音乐”的操作。
但后来，Boris 想：要是让这个工具有读写文件、执行批处理命令、浏览代码能力呢？于是他给它“下了工具包”：
- 它能读、写文件
- 它能执行 shell / batch 命令
它能浏览项目里的文件结构、读 import 的模块、进入子文件夹查找依赖的代码……
于是，这工具就从“小打小闹”进化成“能自己探索代码库、自己找答案”的智能助手。Boris 觉得，这就是“产品滞后”——模型其实有能力了，但市场上还没一个产品把这个能力展现出来。
内部开始了 dogfooding（内部使用）。在 2024 年 11 月，Claude Code 的第一个内部版本问世：第一天就有 20% 的工程师用了，五天后涨到 50%。
当时团队内部还在争论要不要公开它，因为这可能成 Anthropic 的“秘密武器”。最后他们决定发布：既能让更多人用，也能在实际使用中学习模型的安全与能力。
团队从最初只有 Boris，一直到 Sid 加入，后来扩展到设计、产品、数据科学等角色，慢慢变成一个完整产品组。
有意思的是：虽然 “Code” 二字暗示这是给开发者用的，但现在很多数据科学家、分析师也开始用了，他们让 Claude Code 写查询、生成可视化……简单讲，就是“原本只是给码农用的工具，竟然被别人截胡了”。
有个很酷的指标：Anthropic 在工程人数翻倍时，通常 PR（pull request）数/人 会下降，因为老员工要带新人等。但引入 Claude Code 后，他们反而 PR 数/人 +67%，也就是每个人产能反而上去了。
作者自己也用了这个工具，觉得写东西快、进度好，也能跑测试、做验证。
2.技术栈 & 架构：最小 “外壳＋模型” 设计
技术栈选型：让 Claude 自己写自己
Claude Code 用了这些技术组合：
- TypeScript
- React + Ink（Ink 是一个用来在命令行里写 UI 的 React 库）
- Yoga（一个布局系统，支持不同终端尺寸）
- Bun（打包、构建方案）
为什么选这些？一句话：on-distribution。也就是说，这些技术模型本身就很擅长（模型本来就懂 JS / TypeScript / React 这些东西），不是它要重新“学”的。
团队的目标是：让 Claude Code 尽量由 Claude 自己写。Boris 提到：“90% 的Claude Code 是由 Claude Code 自己写的。”
架构之道：最轻、最透明的外壳
虽然 Claude Code 外表看起来做很多事，但实际上内部业务逻辑／客户端复杂度被压得非常低。为什么？因为模型做大部分工作。
外壳主要负责三件事：
- 定义 UI，让模型有接口可以操控界面
- 暴露一些工具（读文件、执行命令等）给模型调用
- 然后“退后”，不要干涉模型太多
团队相信：很多产品会给模型添“脚镣”——用很多中间层、限制、UI 交互，使模型被束缚住。但 Claude Code 想尽量少加这些包袱，让模型“自由地”发挥。
一句经典话：每当模型能力升级，他们就会删掉一些之前写的代码。比如模型更强了，以前要通过系统 prompt 写的东西，有时候可以直接去掉。至于运行方式，Claude Code 在本地运行，不走虚拟机也不跑云端。为什么？因为最简单的方案往往是最可靠的。
本地执行批命令、读写文件、交互都发生在用户机器上，没有特殊容器或沙箱。这样设计虽然有风险（误操作可能伤害系统），但便利性、安全性的权衡团队觉得最合理。
权限系统：用“问你”机制
在本地直接操作，有风险。比如模型可能想「删文件」。Claude Code 的解决方案：在执行敏感操作前必须问用户：
- 本次允许
- 今后允许（记住这个项目／全局）
- 拒绝
他们还做静态分析：如果命令在用户的 settings.json 里已被授权，就不再询问。settings.json 可以按项目 / 用户 / 组织层面共享配置。
3.功能开发：几天就出一个功能
在 Claude Code 团队里，速度就是生命力。
- 内部：每天约 60–100 个内部版本（改一点就发包，让整个团队都试）
- 外部：几乎每天会有一个新版本上线给用户看
- 每位工程师一天能提交约5个PR（pull request）
更神奇的是：原型设计极其快速。他们在两天里能产出 10+ 个原型版本——比如 “todo list” 功能就是这样一步步迭代的。
原型演化过程很有意思：
- 原型 #1：把 todos 列表放在命令行下面
- #2：尝试把 todos 信息插入当前行中
- #3 / #4：尝试把 todos 做成可展开的“pill”卡片
- …
- 到 #20 左右，他们才定下来最终效果：spinner （转圈加载器）里显示 todos + Ctrl+T 切换显示/隐藏
整个过程中，用 prompt（向模型下指令）＋人工调试＋同事反馈，循环迭代非常快。
以前一个功能可能要几天／几周才能够有雏形，现在 AI 助手加速下来，这类原型几小时就能搞很多版本出来。
4.终端 UX 重塑：让交互升级
Claude Code 最酷的一点在于：它把「终端（Terminal）」从静态工具，变成一个「可以互动、有反馈」的界面。以下是几个有意思的交互设计方向：
- Todo / 任务跟踪：当模型执行多个子步骤时，用户可以看到进度、折叠／展开细节
- Hooks：用户可以自定义 shell 命令，让 Claude Code 调用这些命令
- 多种输出格式：比如 “解释型”（解释模型为什么这么写）、“学习型”（让用户亲自参与一些小步骤以便理解）等风格
- GitHub / GitLab 集成、CI/CD、配置系统、MCP（模型上下文协议）连接等功能
总之，它不只是一个 “在终端里跑模型” 的工具，而是把「交互」这个维度拉进来，让用户感觉像和一个聪明搭档在对话。
5.“AI 优先”工程团队：未来工程师的工作方式？
Claude Code 本身就是一个“AI 优先”的产品，而背后的团队运作也体现这种思路：
- 用 AI 做代码审查、做测试
- 强调 TDD（测试驱动开发）+ 自动化
- 自动化应急响应、监控
- 小心使用 feature flags（功能开关）来控制风险
团队愿意让模型直接进入代码流程，而不是只作为辅助工具。这个模式是否会成为未来大部分工程团队的标准？目前还不好说，但 Claude Code 给了一个强烈暗示。
不过，有一点要注意：这种方式在 Anthropic 能行，在别的公司能不能复制，还取决于模型能力、团队文化、基础设施安全等因素。
6.子代理（subagents）：3 天做出来的“代理代理”
“子代理”是 Claude Code 的一个扩展机制：基本逻辑是让模型为某个子任务分配一个“子代理”去跑。
有趣的是，他们花了三天搞出来这个功能，其中两天做的东西直接砍掉重来。团队并没有一步到位，而是用快速原型 + 模型反馈 + 拆解方式，最终把这个功能打磨出来。
这个过程体现了整个团队在 AI 助力下，做“尝试—失败—重做—验证”循环的能力。
7.对未来的展望：AI 辅助开发还会走到哪里？
从 Claude Code 可以看出一些趋势：
- 工程师并不会被取代，但角色可能演变得更像“监督 + 指挥者”，把细节交给模型
- 快速原型、快速迭代将成为常态
- 交互设计、权限、安全体系会比以前更重要
- 不同公司复制这种 AI-first 模式的难度可能很高 ——模型能力、团队文化、资源等都是门槛
总的来说，Claude Code 是一个非常勇敢、前瞻的尝试。它展示了 AI 在工程生产力提升上的可能性，也给我们一个窗口看看“工程师＋AI 协作”的未来可能长什么样子。
