从一个周末项目到 Anthropic 最受关注的开发者工具
2024 年 9 月，Anthropic 的工程师 Boris Cherny 为了测试 API，随手写了一个终端工具。这个工具没有花哨的界面，没有精心的产品规划，甚至连"做成终端形态"都不是有意为之。然而就是这个"随手一写"的东西，在不到一年时间里成了全球开发者圈子里讨论热度最高的 AI 编程工具之一。
在 Every 播客上，Claude Code 的产品经理 Cat 坦言："我们没打算把终端做成最终形态。"但现实比计划更有说服力——CLI 形态不是退步，而是一次被偶然发现的进化。
为什么开发者不愿意离开终端？答案藏在注意力流里。一个开发者写代码时，终端、编辑器、浏览器文档构成一个紧凑的工作三角。每一次切换到新的窗口，都在打断深度思考的状态。Copilot 和 Cursor 把 AI 嵌入编辑器是对的，但它们把开发者框在了 AI 定义的世界 里——你得在 AI 的聊天窗口里提问，在 AI 的面板里审查代码，按照 AI 设定的交互模式工作。
Claude Code 做了一件截然不同的事：它让 AI 进入开发者的世界。你不需要去任何新的界面，AI 就在你每天敲命令的地方，用你熟悉的工具，操作你熟悉的文件系统。这个方向性的差异，决定了两个截然不同的能力上限。
给 AI 一个 Bash Shell，等于给它整个世界
Claude Code 团队经历过一个被内部称为"第一个 AGI 时刻"的故事。当他们把 bash 工具交给 Sonnet 3.5 时，模型做了一件没人预料到的事：它写了 AppleScript，去查询 Boris 正在听的 Spotify 音乐。
没有人教过它写 AppleScript。没有人给它配置过 Spotify API。它只是拥有了一个 shell，然后自己找到了答案。这个瞬间揭示了一个深刻的架构哲学：通用工具 > 专用工具。
当你给 AI 一个 bash shell，你不是给了它一个工具——你给了它一个可以自己制造工具的工具。
这种哲学直接体现在 Claude Code 的工具设计上。你可能以为，这么强大的工具一定集成了几十种专用能力。事实恰恰相反——Claude Code 只有大约十几个核心工具，而且团队每周都在评估，该添加哪些、该移除哪些，以保持工具集的简洁。
同样的"少即是多"原则也体现在 MCP（Model Context Protocol）生态中。社区经过大量实践后形成了一个共识：日常使用 4 个 MCP 服务器就够了，装 15 个反而会让模型选择困难，效率直线下降。这和人类面对太多选择时的决策疲劳完全一样。
五层配置：从混乱到秩序
一个严肃的 CLI 工具如果不解决配置问题，很快就会在企业环境中碰壁。Claude Code 设计了一套五层配置架构，每一层都有明确的优先级和适用场景：
- 托管设置（Organization Managed）——组织级强制策略，所有下级无法覆盖。企业的安全团队在这里锁定红线。
- CLI 参数——单次调用的临时覆盖，适合实验和调试。
- 本地项目配置（.claude/settings.local.json）——个人开发偏好，不提交到 Git。
- 共享项目配置（.claude/settings.json）——团队统一规范，提交到 Git 仓库，所有人共享。
- 用户全局配置（~/.claude/settings.json）——跨项目的个人默认设置。
这个设计的精妙之处在于：它同时满足了 企业管控、团队协作和个人自由 三个往往互相矛盾的需求。安全团队可以在托管层禁止一切网络访问，团队负责人可以在共享层规定允许的文件目录，而个人开发者仍然可以在本地层加入自己喜欢的别名和快捷方式。
权限系统同样遵循清晰的优先逻辑：deny > ask > allow。如果任何一层设置了 deny，无论其他层怎么配置，这个行为都会被拒绝。这和防火墙的"默认拒绝"理念一致——安全永远是第一优先级。
沙箱模式进一步加固了安全边界：文件系统读写隔离、网络域名白名单和黑名单、进程执行的精细控制。Claude Code 可以在严格受限的环境中运行，这对于企业场景至关重要。
还有一个容易被忽略但非常实用的设计：模型的 effort level 可以跨会话持久化。你设置了 high effort，关掉终端再打开，它还记得。这个细节说明 Claude Code 不把每次交互当成孤立的请求，而是当成一个持续的工作会话。
为未来六个月构建
Boris Cherny 有一个被团队反复引用的产品理念："不要针对今天的模型能力设计产品。为未来 6 个月的模型构建。"
这句话听起来像是冒险——如果 6 个月后的模型没有如预期进步怎么办？但如果你仔细想想，这恰恰是 AI 产品成功的核心逻辑。AI 模型的能力在以季度为单位飞速迭代，如果你按照今天的限制来设计产品架构，6 个月后你的产品就会被模型的能力甩在后面，成为"旧范式"。
大多数软件产品的设计假设是：底层能力是稳定的。但 AI 产品必须假设底层能力是快速进化的。架构的职责不是适配今天的模型，而是为模型的成长预留空间。
这个理念直接影响了 Claude Code 的功能取舍。很多"今天的模型做不到"的功能，团队依然保留了接口和架构支持。他们赌的不是今天的 Sonnet 能完成，而是 6 个月后的新模型能完成。而历史证明，这个赌注到目前为止是赢的。
Command → Agent → Skill：三层分离架构
Claude Code 的内部架构遵循一个清晰的三层模型：
- Command 层——用户交互入口。它负责理解用户意图、编排任务流程、决定调用哪个 Agent。
- Agent 层——执行引擎。Agent 使用预加载的技能获取数据、调用工具、执行具体操作。
- Skill 层——能力单元。每个 Skill 独立生成输出，专注于单一任务。
这种分离的好处是显而易见的：每一层都可以独立迭代。你可以新增一个 Skill 而不影响 Command 层的编排逻辑；你可以优化 Agent 的工具选择策略而不改变 Skill 的输出格式。
更有意思的是模型选择策略："入口轻、执行重。"Command 层只需要理解意图和分发任务，可以用更快、更便宜的模型；Agent 和 Skill 层需要深度推理和代码生成，值得投入更强的模型。这种分层资源配置的思路，和微服务架构中"网关用轻量实例、核心服务用高配实例"如出一辙。
与 Copilot 和 Cursor 的本质区别
最后回到那个最根本的问题：Claude Code 和 GitHub Copilot、Cursor 到底有什么不同？
表面上看，差异是界面形态——一个在终端，一个在 IDE。但真正的差异是权力方向：
- Copilot / ChatGPT / Cursor：用户在 AI 的世界里工作。AI 提供了一个聊天框、一个面板、一个侧边栏，你进入它的领地，按照它的规则交互。
- Claude Code：AI 在用户的世界里工作。AI 进入你的终端，读取你的文件，运行你的命令，融入你已有的工作流。
这不是一个微小的产品偏好差异，而是一个根本性的架构分叉。前者的上限是"AI 能构建多好的交互环境"；后者的上限是"用户已有的环境有多强大"——而答案显然是，用户的真实环境（终端 + 文件系统 + 所有已安装的工具 + 互联网）比任何 AI 能构建的沙箱都要强大得多。
Claude Code 的架构哲学可以用一句话概括：不要把用户带到 AI 的世界，把 AI 带到用户的世界。从这个起点出发，CLI 不是退步，不是技术选型的妥协，而是通往更高能力上限的必经之路。
一个 bash shell，胜过一百个专用 API。少即是多，开放优于封闭。为未来构建，而非为现在妥协。这些不是口号，而是 Claude Code 用代码验证过的架构真理。
Views: 1