最近看 Claude Code 的设计思路时，我发现它和很多 AI 产品有一个非常不同的地方：
它并不是在追求“功能越多越好”，而是在刻意克制。
你会发现，Claude Code 明明已经具备非常强的能力，却始终没有把所有工具、所有按钮、所有高级功能一次性摆在用户面前。甚至官方新增一个工具都非常谨慎。
一开始我也觉得奇怪：既然模型已经这么强了，为什么不干脆把所有能力都开放出来？
后来我才发现，这背后其实有一个非常重要的设计原则：
渐进式披露（Progressive Disclosure）
也就是：默认只展示当前最需要的能力，复杂能力只在真正需要的时候才出现。
为什么 AI 工具不是越多越好？
很多人做 AI Agent 的第一反应，往往是不断给模型“加工具”：
能搜索网页
能查数据库
能调 API
能读文件
能发消息
能操作浏览器
能调用几十种插件
看起来模型越来越强，但实际使用时，往往会出现几个问题：
模型开始犹豫，不知道该选哪个工具
Prompt 变得越来越长，占用大量 token
工具之间互相重叠，反而降低了准确率
用户界面越来越复杂，新人根本不知道从哪里开始
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。
一个更合理的顺序通常是：
系统规则
长期固定的上下文
工具定义
当前任务
用户最新输入
而很多人会反着写，把动态内容放在前面、规则放在后面。
结果就是每次请求都无法命中缓存，导致：
成本更高
响应更慢
Prompt 更容易混乱
所以真正高质量的 Agent，不只是 Prompt 写得长，而是 Prompt 的结构写得对。
最后：真正强大的系统，看起来往往都很简单
Claude Code 给我最大的启发，不是它有多少功能，而是它知道什么时候“不做”。
它没有把所有能力都塞给用户，也没有把所有工具都暴露给模型。
相反，它一直在坚持一件事：
先给最少、最清晰、最通用的能力；只有在真正需要的时候，再逐步打开更高级的能力。
这也是为什么 Claude Code 看起来不复杂，却能处理越来越复杂的问题。
真正优秀的系统，往往不是因为它“什么都有”。
而是因为它知道：
什么该出现，什么不该出现，以及什么时候出现。