从「AI 帮我写」到「我带 AI 干」——工具形态、上下文预算与人的位置

想象你给一个技术很好、但今天第一天来的外包同事派活。

第一种给法：把近三年所有文档打印出来堆满他的工位，说「都在这儿了，自己找」。他技术再好，也得先花半天分辨哪份是现行版本、哪份是废弃草稿——而且他判断错了你不会知道，因为他会很自信地按错的那份干。

第二种给法：桌上三份文件加一张便签：「这个模块上周刚出过事，注意第 47 行的重试逻辑；旧版在 legacy/ 下，不跑了，别动。」信息量小得多，但信噪比高得多。模型和这位新同事一样，没法从「文件存在」推断出「文件重要」——你不说哪个在跑，它就只能猜。

• 上下文预算（context budget）——一次请求里，你实际能让模型「用上」的信息是有限的，而且远小于窗口标称的容量。装进去的东西之间会互相竞争注意力：多塞一份废弃代码，不是「多了一份参考」，而是「给正确答案多加了一个竞争者」。
• 上下文腐化（context rot）——上下文越长模型表现非均匀地下降。注意「非均匀」：不是线性变笨，而是在某些位置、某些任务上断崖式失效。一份测了 18 个模型的研究还发现：把干扰材料打乱顺序，模型反而比材料逻辑连贯时更准——连贯的错误材料更像正确答案。
• 代理式检索（agentic search）——不预先建索引，让模型自己 grep、读文件、顺引用爬，边找边判断。相对的是索引式检索：预先把仓库切块做 embedding，查询时向量召回。

2025 年流行的分法是「终端类 / IDE 类 / 云端类」。截至 2026-08 这个分法已经不成立——头部产品全部三态齐备，且官方明说共用同一套 agent harness：同一个引擎，套 CLI、套 IDE 插件、套云端会话，会话还能在本地与云之间来回推拉。

真正还有工程后果的，是下面三根轴：

这三根轴各自逼出一个必须由人回答的问题：合规边界、验收标准、预算。工具形态怎么变，这三个问题都在。

第 3 层是主战场。故障案例里的十二万 token 全在第 3 层；正确做法是把最关键的那句「V2 才是在跑的那个」上提到第 2 层写进规则文件，让它每次都在，而不是指望模型每次从代码里重新推断。

这里有一条容易被忽略的推论：规则文件是用来放「推不出来的事实」的，不是用来放「读一眼代码就知道的事实」的。官方给的检验方法很朴素：逐行问自己「删掉这行，模型会不会犯错？不会就删」。三家大厂给的长度上限数字不同（见下节表格），但都附了同一句警告：臃肿的规则文件会让模型忽略你真正的指令。

索引式：预先 embedding 全仓 → 查询时向量召回 → 塞进上下文。 代理式：不建索引 → 模型自己 grep、读文件、顺引用爬。

两边的官方理由，2026 年都摆到台面上了，但它们根本没在同一个指标上争论：

没有第三方在同一 benchmark 上做过「纯 grep vs 纯 embedding」的公开对照实验，任何一方声称「被证明更好」都不成立。产品层面两条路线已在合流：代理式那边在做更快的 grep 原语，索引式那边配了只回摘要的探索子 agent。

编程 agent 每一轮都在重发同一个巨大前缀（系统提示 + 工具定义 + 规则文件 + 之前所有轮次），服务端把这段公共前缀缓存住就不用重算。所以命中率不是省钱技巧，是成本结构本身。原则一句话：

打穿缓存的三个经典写法都长得人畜无害：静态系统提示里放精确到秒的时间戳（命中率恒为 0）、工具定义顺序不确定（比如从字典遍历生成）、中途改工具参数或接断外部工具服务。反过来，有几条「不失效」是反直觉的，也是最好的分水岭：改仓库里的文件不会失效（文件内容不在前缀里，是模型现读的）；中途修改规则文件不会失效——但也不会生效，得等清空上下文或重启；回滚到之前的检查点不会失效（回到的是已缓存的前缀）。

还有一条几乎没人提：缓存作用域绑定机器和工作目录。系统提示里嵌了当前路径、平台、shell。这意味着用 git worktree 并行开三个会话，三个 worktree 之间互不命中缓存——并行省的是你的时间，花的是钱。

1. 别把「全部」当成「重点」。先给三个文件加两百字现状说明，比先给三十个文件再让模型自己筛更快也更准。
2. 把「推不出来的事实」写进规则文件：哪个实现在跑、哪个目录已废弃、哪个测试是不可信的。这类信息模型永远推不出来，而它一旦搞错，后面全错。
3. 规则文件要定期删，不是定期加——只增不减是最常见的慢性病，臃肿到一定程度模型会忽略里面的真指令；而且它中途改不当场生效，要重开会话（很多人改完觉得没用，其实是没生效）。
4. 别在静态前缀里放会变的东西：时间戳、当前分支名、动态生成的文件清单。
5. worktree 并行不共享缓存，开并行会话前先算一下值不值。
6. 探索类任务一定要限定范围。没有边界的「调研一下这块」会让 agent 读掉几百个文件撑爆上下文，正确做法是丢给独立上下文的子 agent 只回摘要。但子 agent 不是万金油——官方给的「不该用」边界是：需频繁往返迭代、需多阶段共享上下文、改动很小、在意延迟。

这一章在 2026 年几乎是一面开场必问，形式一般是「你平时怎么用 AI 写代码」。看起来是闲聊，实际上信息密度最高——你答的过程会自动暴露：用的是哪一代工作流、被它坑过没有、有没有形成纪律。后续往两个方向压：往下压细节（「精简到什么程度？依据呢？」），往上压判断（「那你的价值是什么？」）。

「一个成功例子 + 一个翻车例子 + 一条你因此立下的规矩」——三段，两分钟。

翻车例子是这道题真正的分水岭。只讲成功例子的人，听起来像在念产品宣传页；能讲清楚一次翻车、并且归因到机制（而不是「模型不行」）的人，才是真在用。翻车例子要满足两个条件：它得是你会二次犯的错（说明有普遍性），你得说出你后来怎么改的流程（说明你把它变成了纪律）。

关于「你的价值是什么」，不要答成表忠心（「AI 只是工具，人才是主导」——这是空话）。可落地的回答方式是：指出 AI 交不出来的三样东西。

1. 判断哪个上下文是对的。故障案例里模型不是不会写幂等，是不知道哪个 handler 在跑——这类「系统当前的真实状态」只存在于人的脑子和线上，不在代码里。
2. 定义「做完了」的标准。异步派活的前提是有可判定的验收标准，写出它是人的活。
3. 为后果签字。这条最硬：出了事，被复盘的是人。