第 4 章：工具与 Context 选择——为什么 AI IDE 卖的是“上下文选择能力”

“AI IDE 或 AI Agent 卖的是两个：一个是 Context 选择的能力，一个是最佳实践通用化的能力。”

延伸阅读：Context window 的物理边界及其对工程实践的影响，参见AI 的无状态性与 Context Window。

本章聚焦于：不同 AI Coding 工具的特性、商业模式带来的隐性约束，以及为什么 RAG、任务管理器、多 Agent 这些“看上去很聪明”的东西，在 AI-native 工程实践里，往往是反模式。

从商业角度看，Cursor 的生意模式是“批发转零售”：

一旦上下文被压缩：

结果就是：你以为它读了整个文件，其实它只看了中间的几段。

延伸阅读：Token 规模如何影响工具选择决策，参见Token 作为项目规模的量化指标。

因此，最好的工具其实是大模型厂商自己出的工具：

代价是：
— 不是所有普通人都付得起账单。随随便便聊几十刀、几百刀就下去了，20–200 美元反而成了“均价”。

另一个思路是：直接用模型厂商的 Web 端界面。

比如 Gemini：

但这里最大的问题不在工具，而在于：

当你在 Web 端处理超大上下文时，内部仍然需要用Test–Code 循环：为什么测试代码比功能代码更重要中所强调的测试体系来兜底。

Cursor 找东西用的是 RAG。
RAG 这个技术从工程角度看，一个最大的缺点就是：准确率特别低。

“cursor 经常会找出来一些似是而非的东西。唯一可靠的，是对符号建立索引，也就是所谓的 AST。”

后来我们知道，像 codex 或者 cloud code，本质上都是 AST/symbol 索引的思路：

而对比之下：

正确的做法应该是：

“让大模型自己来建索引，然后让大模型调自己的索引。”

市面上有很多基于 AI 的“任务管理器”产品：

这条路径的出发点是好的，我自己也在这条路上走了大半年，甚至手搓过类似的 pipeline。

但最后我把这类流程全部淘汰了，原因在于：

AI IDE 或 AI Agent 卖的是两个：一个是 Context 选择的能力，一个是最佳实践通用化的能力。