Claude Code 5亿美元背后的AI工程革命（下集）

（上集）http://t.cn/AX48XJtv

【4】重新设计集成 AI 后的命令行终端

命令行终端已经存在了几十年，为什么现在需要重新设计？

因为在 LLM 出现之前，终端并不会太注重交互体验。

传统的命令行是一问一答：你输入命令，它返回结果，完事。没有对话，没有上下文，没有等待时的反馈。你盯着光标闪烁，不知道后台在干嘛。

Claude Code 是第一批真正需要思考“终端 UX”的产品。他们加了几个小细节，看起来不起眼，但用起来感受完全不同。

第一个：上下文加载提示。

当模型在思考时，屏幕上能根据当前任务显示生成相关的提示：比如“正在阅读你的代码结构”或者“正在思考解决方案”。

这是个很小的触感，但它让工具有了“人格”。你会觉得它在认真干活，而不是卡住了。Boris 说，上一次他看到这种让人愉快的小交互，还是 Slack 的新手引导流程。

第二个：等待时的教学提示。

当 Claude 在执行一个长任务时，屏幕底部会轮流显示使用技巧，比如“你可以按 Esc 中断当前任务”或者“试试 /help 看看所有命令”。

命令行用来教命令行，简单又聪明。

第三个故事更精彩：Markdown 渲染器。

发布前一天，有工程师抱怨嵌套列表显示得很丑，段落间距也不对。问题出在 Markdown 渲染器上。Boris 试了市面上所有现成的渲染器，没一个在终端里好看的。

于是他用 Claude Code 花了一天时间，从头写了一个 Markdown 解析器和渲染器。

对，发布前一天。对，从头写。对，用的是 Claude Code 自己。

结果这个“赶工”出来的渲染器，比所有现成方案都好看。他们直接发布了。Boris 认为现在没有任何其他终端有同样质量的 Markdown 渲染。

这个故事说明了一件事：当你有一个足够好的 AI 编程工具时，“自己造轮子”的成本会大幅下降。以前“能用就行”的妥协，现在可以变成“那就做一个更好的”。

命令行终端这个古老的界面形态，正在因为 LLM 的加入而焕发新生。终端还是那个终端，只是因为有了 AI 的加入，让我们需要认真思考：怎么让人和终端里的 AI 更好地对话。

---

【5】AI 渗透到每个环节——一个工程团队的“全面 AI 化”实验

Anthropic 的工程团队，可能是目前把 AI 工具用得最极致的团队之一。

不只是体现在写代码上，而是是项目中的各个环节。

代码审查：所有 PR 的第一遍审查由 Claude Code 完成，工程师做第二遍。Boris 说，Claude Code 在第一遍就能发现很多问题。这个功能原本只在内部用，后来他们把它公开了，所有人都能用 Claude Code 做安全审查。

写测试：Claude Code 的测试套件几乎全是 Claude Code 写的。Boris 说：“以前如果有人提 PR 不写测试，我会犹豫要不要说什么——感觉像在挑刺。但现在有了 Claude，写测试就是一句提示词的事，没有借口不写。”

事故响应：oncall 的工程师会让 Claude Code 帮忙分析 Root Cause（导致问题最根本的原因）。它能从 Slack 拉相关讨论，从 Sentry 拉错误日志，从各种监控系统拉数据，然后综合分析。Boris 说 Claude Code 在某些场景下找 Root Cause 比人还快。

GitHub issue 分流：每当有新 issue 进来，Claude Code 会先做一遍分析，然后工程师问它“能不能实现一下”。Boris 说，大概 20%-40% 的情况下，它第一次就能搞定。

图表和查询：产品数据存在 BigQuery 里，几乎所有查询和可视化都是用 Claude Code 生成的。工程师甚至会让它直接输出 ASCII 图表。

最让我意外的是 TDD（测试驱动开发）的复兴。

TDD 是个老概念了：先写测试，再写让测试通过的代码。理论上很美好——强迫你先想清楚要什么。但实际操作中，大多数人觉得它太慢、太麻烦，所以这个方法在过去十几年慢慢边缘化了。

但 Boris 说，用 Claude Code 之后，他做了大量 TDD：

“我会先让模型写一个测试，同时告诉它这个测试现在会失败，不要试图让它通过。然后我再让它写代码实现功能，并且让测试通过，但不能改测试本身。”

“当模型有一个明确的目标去迭代——比如一个单元测试或者一个 mock——它表现得非常好。”

他特别提到，Claude 4.0 是第一个能让模型写大部分测试的模型系列。之前的版本可以写一部分，但需要大量人工干预。

还有一个新概念：multi-clauding。

意思是同时运行多个 Claude Code 实例，让它们并行处理不同的任务。Sid 说他经常这么干——开会的时候启动几个 agent，会后回来看结果。

Anthropic 发现，25% 的 Max 订阅用户（月费 100-200 美元的高级用户）每天都在 multi-clauding。

这是一个很有趣的变化。编程一直是“单线程”活动：你一次只能干一件事，只有等代码审查或者部署的时候才会切换任务。但现在，“并行编程”成为可能——你可以同时推进好几件事。

当然，这里面有很多未知数：并行工作是真的更高效，还是只是感觉更高效？什么类型的任务适合并行？每个 agent 分到的注意力变少，会不会出问题？

这些问题还没有答案。但我们有了一个新工具可以实验。

最后讲一个案例。有家公司要做框架迁移，原本估计需要两个工程年——一个工程师干两年，或者十个工程师干两个半月。他们用 Claude Code，一个工程师两周搞定了。

Boris 说他以前会对这种说法持怀疑态度，但类似的故事他们听到太多次了。

---

【6】三天黑客松——Subagents 功能是怎么诞生的

Subagents 这个功能的灵感，来自 Reddit 上的一条帖子。

有人说他同时开了五个 Claude Code 实例，给每个实例设定不同的角色，然后用文件系统让它们互相通信。

Sid Bidasaria 看到这条帖子的时候，第一反应是：这个玩法很酷，但用户不应该需要这么折腾。我们应该把它做成产品内置的功能。

正好公司有个三天的内部黑客松，Sid 决定用这三天来做这件事。

第一天，团队兴奋地画出了各种复杂的 Agent 拓扑结构：Agent 之间用消息总线通信、异步模式、多对多交互……图画得很漂亮，概念很先进。

第二天，他们意识到这样做似乎不可行。

问题不是技术实现——那些复杂模式都能做出来。问题是用户没法理解。Claude Code 的 UI 就是一个简单的终端，你怎么在这么简单的界面里让用户明白那些复杂的 Agent 通信模式？

他们决定推倒重来，回到一个根本问题：普通开发者能用的最简单形式是什么？

他们给自己定了两条约束：

第一，不发明任何新东西。只用 Claude Code 已有的能力——“/”命令和 .md 文件。

第二，不做 Agent 间通信。改成一个简单的编排模式：有一个主 Agent，它可以调用子 Agent，子 Agent 完成任务后返回结果，仅此而已。

他们还和 Anthropic 的研究团队聊了聊。研究人员正在研究多 Agent 模式，但结论是：复杂的 Agent 拓扑是否真的有效，目前还没有定论。

这给了他们更多信心：既然连研究团队都说复杂不一定好，那就更应该做简单的版本。

第三天结束时，他们做出了一个能用的版本。用户可以在 .md 文件里定义子 Agent 的角色和能力（比如“前端子 Agent：使用 React 19 和 Next.js”），Claude Code 会在合适的时候调用它们，或者用户可以手动触发。

黑客松结束后，稍微打磨了一下，功能就上线了。

现在你可以定义各种专属子 Agent：有安全审计专长的后端 Agent、熟悉特定框架的前端 Agent、专门写测试的 QA Agent……它们可以在后台并行工作，各司其职。

很多团队在黑客松里会舍不得推翻自己的复杂方案，毕竟花了一整天画图讨论，有感情了。能够承认“这条路走不通”并推翻从头开始，需要勇气，也需要对“简单”的信念。

简单不是偷懒。简单是在无数可能性里找到那个用户真正能用的形态。

---

【7】未来的工程团队会是什么样？一些可以借鉴的，和一些不能复制的

Boris 说：“编程现在太有意思了。上一次有这种感觉，还是中学时第一次在图形计算器上写代码。那种魔法般的感觉，我很久没体验过了，但现在又回来了。”

Sid 的感受类似：“让我兴奋的有两件事。一是我们发布的速度——有时候甚至感觉太快了。二是这么多的实验空间——以前的工作虽然也快，但做的东西比较套路，知道答案是什么，就是执行而已。现在不一样，模型每三个月就变一次，我们得不断重新思考怎么做事。”

这些感受很真实，也很有感染力。

但在讨论“未来工程团队会是什么样”之前，也不要忘记 Anthropic 的特殊性。

第一，Anthropic 是研究实验室，不是产品公司。它的核心使命是研究 AI 安全和能力，产品是手段不是目的。这意味着他们对“快速实验”的容忍度比一般公司高得多。

第二，他们的主要产品是 Claude 模型本身。Claude Code 只是模型的一个“套壳”。所以“删代码让模型做更多事”对他们来说是自然选择，但对其他公司可能意味着把核心业务逻辑交给一个黑盒。

第三，所有员工都有无限的 Claude 访问权限，包括最贵的 Opus 模型。在大多数公司，AI 订阅费是需要争取的预算项目，不可能人人敞开用。

第四，团队只有十几个人，流程极简。他们几乎不用 feature flag（功能开关），因为“太慢了”。这在用户基数大、出错成本高的产品里是不可想象的。

所以，直接复制 Claude Code 团队的做法，对大多数团队来说不一定现实。

但有些东西是可以借鉴的。

快速原型的思维方式：就算你做不到一天 10 个原型，能不能从“两周一个”变成“一周三个”？工具已经变了，对“原型应该多快”的预期也该更新了。

AI 辅助代码审查：让 AI 做第一遍审查，人做第二遍。这个流程不依赖无限 API 访问，大多数团队都能尝试。

TDD 的复兴：如果写测试变得足够容易，那“没时间写测试”就不再是借口。这可能是改善代码质量的一个低成本切入点。

Product-minded engineer (有产品感的工程师) 的价值放大：Claude Code 团队没有设计师、没有 PM，就靠几个有产品感的工程师。AI 工具让这种“全栈型人才”能做的事情大幅扩展了。

当然，也有些东西是工具替代不了的。

Boris 能在 20 个原型里挑出最好的那个，是因为他有判断力——他知道什么“感觉对”，什么只是“看起来能用”。这种品味是 17 年软件开发经验的积累，不是 AI 能给的。

团队第一天做了复杂方案，第二天能狠心推倒重来，这种决断力也是人的判断。

知道什么时候该删代码、什么时候该留着，这种架构直觉同样如此。

AI 让执行变快了，但它没有让“知道该做什么”这件事变简单。相反，因为执行成本下降，“做什么”的决策变得更重要了——你可以很快做出 20 个版本，但你得知道哪个是对的。

几年后的软件工程会是什么样子？没人能准确预测。但 Claude Code 团队的今天，可能是很多团队明天的某种预演——更快的迭代、更少的“搬砖”、更多的判断和决策。

工具在变。不变的是，最终做决定的还是人。