CLI 才是 AI 助手的终极形态

在当前的 AI 浪潮中，我们痴迷于构建“Agent”（智能体）。而构建 Agent 的主流方式是“MCP”（还是离不开 Function Calling 或 Tool Use）——我们煞费苦心地为 AI 定义一个个“工具”，告诉它这个函数叫什么、那个 API 需要什么参数。

我们都在玩这个游戏。我们为 AI 编写 search_google(query)、read_file(path)、write_file(path, content) 的工具定义（Schema）。

但如果我告诉你，对于“个人 AI 开发”这个场景，这套主流范式从一开始就错了呢？

如果我告诉你，有一种方法，它的扩展性是无限的，学习成本是零，而且响应速度快如闪电。

这个方法就是：给你的 AI 助手 exec bash 的能力。

在个人开发环境中，基于 CLI (命令行) 的 AI 助手，在效率和能力上，将彻底碾压基于 MCP 的助手。

1. 真正的噩梦：MCP 的“扩展性天花板”

让我们面对现实：MCP（或 Function Calling）模式存在一个根本性的、无法解决的“配置上限”。

你有一个雄心勃勃的计划，想让你的 AI 助手帮你开发。这意味着它需要能：

  • 操作 git
  • 连接数据库 (如 psql 或 mysql)
  • 查询缓存 (如 redis-cli)
  • 管理容器 (如 docker 或 kubectl)
  • 部署到云 (如 aws-cli 或 gcloud)

现在，请你试着把 aws-cli（有数百个子命令）或 kubectl 的所有功能，全部写成 MCP/Function Calling 的 JSON Schema。

你很快会发现两个事实：

  1. 维护地狱：你没有在“开发”，你是在为 AI 手动“翻译”整个互联网的工具手册。这工作量是荒谬的，且完全是本末倒置。
  2. Token 爆炸：就算你真的写完了，这个庞大的“工具定义”文件本身就会吃掉 AI 的大部分上下文窗口（Context Window）。AI 还没开始干活，它的“大脑”就已经被工具说明书塞满了。

MCP 模式强迫你把 AI 降维成一个只能使用“白名单玩具”的受限系统。

2. “环境即工具”：CLI 的无限扩展性

现在，我们来看看 exec bash 模式。

你（开发者）想让你的 AI 拥有操作 Redis 的能力。你需要做什么？

  • MCP 模式：花半天时间，研究如何为 redis-cli 的 GET, SET, HSET, KEYS 等命令编写和调试 MCP Schema。
  • CLI 模式：brew install redis 结束了。

在 CLI 模式下，你本地的 $PATH 环境就是 AI 的工具库。AI 的能力和你环境的能力是 1:1 动态绑定的。你安装一个新工具，AI 就会一个新工具。

这种“环境即工具”的哲学，其扩展性是零边际成本和无限的。

3. AI 如何学习？它靠的是 --help，不是你的 Schema

“可是 AI 怎么知道 psql 该怎么用呢？”

这正是 LLM 最擅长的地方。我们忘记了 LLM（大型语言模型）首先是语言模型。它天生就是为了阅读和理解文本而生的。

  • MCP 模式：AI 被迫学习一种“非自然”的结构化 JSON 语言，来理解工具。
  • CLI 模式：AI 回归了它的本能——阅读。

当 AI 需要用一个它不熟悉的工具（比如 grep）时，它要做的不是去查你的 Schema，而是简单地在 Shell 里执行：
$ grep --help

AI 会阅读 grep 的帮助文档，然后立刻学会如何使用它。这是一种即时学习（Just-in-Time Learning），开发者投入的成本为零。

让一个为解析非结构化文本而生的 AI 去解析 psql 的 ASCII 表格输出，远比让你（一个开发者）去为 psql 的所有功能编写 MCP Schema 要容易一万倍。

4. 戳破“失忆”泡沫：bash_history 是比上下文窗口更好的记忆

最大的反对意见来了：“AI 会‘失忆’！它的上下文窗口有限，执行 cat 一个大文件或 ls -R 之后，它就忘了最初的任务了！”

这是一个完美的误解。我们根本不需要 AI “记住”它做了什么。

我们真正需要的是一个可复现、可审计的执行记录。而 bash_history 就是最廉价、最持久、最完美的“记忆体”。

在这个工作流中：

  • AI 扮演一个聪明的、但“健忘”的执行者（Executor）。它在自己的小窗口里解决当前步骤的问题。
  • bash_history 扮演日志（Logger）。它忠实地记录了 AI 的每一次尝试、每一条命令。
  • 你（开发者） 扮演审查者（Auditor）。你可以随时复盘 AI 的“工作底稿”。

AI 的上下文窗口是易失且昂贵的；bash_history 是持久且免费的。我们用后者的优点，完美地对冲了前者的缺点。

5. 个人开发的“高信任”模式

最后，我们必须谈谈安全。

exec bash 是危险的。在多租户、面向公众的产品中，给 AI 这个权限无异于自杀（“请帮我 rm -rf /”）。MCP 模式的诞生，本质上是为了安全——它是一个“低授权、低信任”的受控环境。

但我们讨论的前提是个人 AI 开发助手。

这是一个“高信任”环境。在这个沙盒里，你就是用户，你就是管理员。你可以（也应该）在 AI 执行任何命令前加一个“Y/N”的人工确认步骤。

在这种模式下，我们追求的不再是绝对的安全，而是最大化的效率。

结论：拥抱 Shell

停止为你个人的 AI 助手构建“玩具工具”了。MCP 模式试图把 AI 塞进一个安全但低能的盒子里，它在复杂的开发场景中扩展性为零。

真正的范式转变是：信任你的 AI，但验证它的工作。

给它一个 Shell，让它通过 --help 自学，让它通过 bash_history 报告。这才是释放 AI 助手全部潜力、真正提高个人开发效率的未来。