> ## Content Index
> Fetch the complete content index at: https://lucent.blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Claude Code 的设计哲学：为什么“少一点能力”反而更强？
- URL: https://lucent.blog/5y84hv2x/
- Published: 2026-04-07T07:38:35.000Z
- Updated: 2026-08-21T00:49:58.000Z
- Author: Lucent
- Tags: AI, 大模型

最近看 Claude Code 的设计思路时，我发现它和很多 AI 产品有一个非常不同的地方：

它并不是在追求“功能越多越好”，而是在刻意克制。

你会发现，Claude Code 明明已经具备非常强的能力，却始终没有把所有工具、所有按钮、所有高级功能一次性摆在用户面前。甚至官方新增一个工具都非常谨慎。

一开始我也觉得奇怪：既然模型已经这么强了，为什么不干脆把所有能力都开放出来？

后来我才发现，这背后其实有一个非常重要的设计原则：

渐进式披露（Progressive Disclosure）

也就是：默认只展示当前最需要的能力，复杂能力只在真正需要的时候才出现。

---

## 为什么 AI 工具不是越多越好？

很多人做 AI Agent 的第一反应，往往是不断给模型“加工具”：

- 能搜索网页
- 能查数据库
- 能调 API
- 能读文件
- 能发消息
- 能操作浏览器
- 能调用几十种插件

看起来模型越来越强，但实际使用时，往往会出现几个问题：

1. 模型开始犹豫，不知道该选哪个工具
2. Prompt 变得越来越长，占用大量 token
3. 工具之间互相重叠，反而降低了准确率
4. 用户界面越来越复杂，新人根本不知道从哪里开始

Claude Code 恰恰是在反着做。

它内部虽然支持大量能力，但真正暴露给模型的工具其实并不多，大约只有二十个左右，而且新增工具的门槛非常高。

因为 Claude Code 团队认为：

每增加一个工具，都会增加模型的认知负担。

模型不只是“会不会用”，还需要在每次思考时判断：

- 这个工具适不适合？
- 有没有更好的工具？
- 我应该先用哪个，再用哪个？
- 这些工具之间有没有冲突？

工具越多，模型越容易分心。

## “少而精”的能力，比“多而杂”更重要

Claude Code 更倾向于提供少量但非常通用的能力。

例如很多场景下，它不会专门增加一个新工具，而是优先使用已有能力组合解决问题。

比如：

- 用 Bash 执行脚本
- 用代码执行处理数据
- 用已有的搜索能力读取信息
- 用 Skill 或 Prompt 模板组合出复杂流程

这样做有两个好处：

### 1\. 模型更容易理解

一个通用工具，模型会反复使用、越来越熟悉。

而如果你给模型十个相似的小工具，它反而会经常选错。

### 2\. 系统更容易扩展

今天来了一个新需求，如果每次都新增一个工具，很快系统就会变成“工具垃圾场”。

但如果你有一个足够强的通用能力，只需要稍微组合一下，就能覆盖更多场景。

这和软件设计里的一个经典原则很像：

不要为了一个小问题，创造一个新的复杂系统。

## 什么叫“渐进式披露”？

渐进式披露，并不是隐藏能力，而是让能力在合适的时候出现。

Claude Code 的默认体验其实非常简单：

- 编辑代码
- 搜索内容
- 执行命令
- 修改文件

对于大多数用户来说，这已经足够了。

但当任务开始变复杂时，更高级的能力才会逐渐出现，比如：

- Todo 管理
- 多 Agent 协作
- Task 拆分
- MCP 接入
- PR Forking
- 更复杂的上下文控制

这样做的好处是：

- 新用户不会被吓到
- 简单任务可以快速完成
- 复杂任务又不会被限制

也就是说：

系统表面保持简单，但内部依然足够强大。

## Todo 和 Task：两个很容易混淆，但本质不同的东西

Claude Code 里有两个看起来很像的能力：Todo 和 Task。

但它们其实服务于不同层级的问题。

### Todo：模型自己的“待办事项”

Todo 更像是模型在思考过程中，给自己列一个小清单。

例如：

- 先看代码
- 再找到 bug
- 然后修改文件
- 最后运行测试

它解决的是：

我接下来应该做什么？

Todo 的作用，是帮助模型不要跑偏，不要忘记步骤。

### Task：把事情交给另一个 Agent

Task 则更像是在多 Agent 系统里，把一个子问题分发出去。

例如：

- 一个 Agent 负责前端
- 一个 Agent 负责后端
- 一个 Agent 负责写测试
- 最后再统一汇总

它解决的是：

哪些事情应该交给别人做？

所以可以简单理解为：

- Todo = 我自己的计划
- Task = 团队之间的协作

Claude Code 并不会一开始就把 Task 这种复杂机制展示给用户，而是先让模型学会用 Todo 管理自己。只有在任务复杂到需要多 Agent 时，Task 才会出现。

这就是典型的渐进式披露。

## 为什么 MCP 不应该默认加载？

很多人喜欢把所有外部能力一次性接进模型，比如：

- 数据库
- 飞书
- Notion
- GitHub
- 浏览器
- 企业内部系统

看起来很强，但实际上，模型每次回答问题时，都必须“看到”这些能力。

问题在于：

这些内容会占据上下文、消耗 token、稀释模型注意力。

Claude Code 对 MCP 的做法非常克制：

默认不加载，只有在明确需要时再接入。

例如：

- 需要查 GitHub 时，再连接 GitHub
- 需要读数据库时，再加载数据库能力
- 需要调用外部系统时，再把相关上下文放进 Prompt

这样模型始终只关注当前真正相关的信息。

## Prompt 和缓存顺序，往往比你想象中更重要

Prompt 的顺序，会直接影响缓存效果。

Claude 会把前面一部分内容缓存起来。如果你把最稳定、最不变的信息放在最前面，那么后续请求就能复用这些内容，节省大量 token。

一个更合理的顺序通常是：

1. 系统规则
2. 长期固定的上下文
3. 工具定义
4. 当前任务
5. 用户最新输入

而很多人会反着写，把动态内容放在前面、规则放在后面。

结果就是每次请求都无法命中缓存，导致：

- 成本更高
- 响应更慢
- Prompt 更容易混乱

**所以真正高质量的 Agent，不只是 Prompt 写得长，而是 Prompt 的结构写得对。**

# 最后：真正强大的系统，看起来往往都很简单

Claude Code 给我最大的启发，不是它有多少功能，而是它知道什么时候“不做”。

它没有把所有能力都塞给用户，也没有把所有工具都暴露给模型。

相反，它一直在坚持一件事：

先给最少、最清晰、最通用的能力；只有在真正需要的时候，再逐步打开更高级的能力。

这也是为什么 Claude Code 看起来不复杂，却能处理越来越复杂的问题。

真正优秀的系统，往往不是因为它“什么都有”。

而是因为它知道：

**什么该出现，什么不该出现，以及什么时候出现。**