别让工具输出淹死你的 AI：一次备份事故之后，我给 AI 立下的几条规矩

这是「养 AI 记」的第 2 篇。上一篇先讲了 AI 为什么会越用越乱，这一篇把镜头拉近一点：不是所有失稳都来自大故障，很多时候，系统就是被一堆看起来“也没错”的原始输出，一点点灌坏的。

很多人以为，AI 变得不好用，是因为模型不够聪明。
但我后来越来越确定，很多时候不是它突然变笨了，而是你先没把规矩立住。

人处理信息时，其实会天然做很多筛选。
老师傅看一眼日志，知道哪里只是噪音，哪里才值得追；实习生常常不是这样，容易把看到的东西照单全收，轻重不分，主次不分。

模型，尤其当能力还不够强的时候，也很像这样。
你不给它规矩，不先替它把边界划出来，它就很容易把本来该待在后台的原始输出，整段整段带回主对话里。

日志、路径墙、扫描结果、调试噪音。
这些东西单看都不算错，堆在一起就很致命。

我踩过一个很典型的坑。

任务本身一点都不复杂：做一次系统备份。
目标也很明确：把真正有用的目录和配置保留下来，把 cache、临时文件、各种没价值的残留排除掉。

我当时给它的要求，是先把 cache 类目录排除掉。
真正决定去跑 find 的，是模型自己。问题也就是从这里开始的。

1. 这个 session 是怎么被打废的

它为了完成“把 cache 类目录排除掉”这件事，自己选择直接跑了 find。
结果 find 很忠诚，也很致命：它开始输出大量路径信息。

不是几十行，而是一路往下喷。
各种 cache 目录、临时文件、依赖残留、编译产物、历史中间件数据……
几百行，几千行，几乎全是“低信息密度但高占用”的内容。

真正重要的东西是什么？
其实只有几件：

• 这次备份的目标到底是什么
• 哪些目录属于“有价值资产”
• 哪些目录应该排除
• 排除规则是否足够安全
• 如果误删 / 误排，怎么回滚

但这些东西很快就被埋了。

一旦原始输出开始成片涌进对话，上下文的重心就会发生变化：
AI 不再围绕“目标”和“规则”思考，而是被迫围绕“刚刚刷出来的内容”继续反应。

然后更糟的事就来了。

因为这不是一次性的“输出太长”，而是叠加了系统记忆和会话延续机制。
那些本该只是过路信息的路径噪音，开始变成这个 session 的持续负担。
后面的表现非常典型：

• 已经确认过的约束开始忘
• 刚说完的排除规则开始漂
• 不断回到已经做过的步骤
• 任务看起来还在推进，实际上已经失去收口能力

很多人把这种体验叫“AI 越用越飘”。
我现在更愿意把它叫做：上下文被污染了。

而且这次不是只有体感在变差。
当时的对话界面后来已经直接开始报错，session 基本不可用；后台日志也给出了输入长度相关的报错。前一篇里我已经放过那两张截图，所以这里就不重复贴了，但它们其实很能说明问题：这不是“感觉变笨了”，而是这轮上下文真的已经被拖到坏掉。

2. 这个坑的本质，不是 find，而是“原始输出回流到对话”

这里最容易误判的地方是：
问题不在 find，也不在工具调用本身。

工具当然可以调用。
目录当然也要扫。
真正的问题是：模型没有能力像一个有经验的人那样，天然替你把噪音挡掉。

人处理这类信息时，其实会本能地做筛选。
一个有经验的人看目录、看日志，不会把所有原始内容都搬回会议桌上，而是会先过滤、先归类、先判断哪些值得继续追。

但模型不是天然会这样。尤其当能力还不够强的时候，它更像一个不够老练的实习生：
你让它去看，它就容易把看到的东西照单全收；你不先立规矩，它就会把本来该留在后台的内容，直接带回主对话。

所以这个坑的本质，不是 find。
而是原始输出回流到了本来应该只讨论结论和判断的地方。

AI 的上下文也是一样。
它擅长在有限空间里处理高密度信息，但并不适合长期吞咽大量原始日志、路径墙、全量扫描结果。
这些内容不是“没有价值”，而是不该以这种形式进入主对话。

3. 我后来怎么改：不是空讲原则，而是把流程重新做了一遍

那次之后，我没有去怪模型，也没有去换工具。
我改的是处理方案，而且改得比之前更“死板”一点。

因为我后来意识到，面对这类相对固定、又容易产生大量原始输出的任务，不能再指望模型临场发挥。
得先把路径收窄，把动作收敛，把可复用的东西沉下来。

第一步：先把首层目录整理出来，输出到文件

我后来不再让它直接在主对话里一边扫、一边吐结果。
而是先把要备份的内容按首层目录整理出来，输出到文件。

这样主对话里保留的，不再是成片的路径噪音，
而只是：这个记录文件是什么，它放在哪里，它接下来要被拿来干什么。

也就是说，原始材料可以存在，但它先退出主对话。

第二步：根据文件内容直接生成代码脚本，用可控程序去做固定动作

有了整理好的目录文件之后，下一步就不是继续在对话里临场判断。
而是根据文件内容，直接生成对应的代码 script 或工具脚本。

因为像“按规则排除 cache 类目录”“基于目录清单执行备份”这种动作，本质上都更适合交给可控程序完成。
程序的好处不是它更聪明，而是它更死板、更可检查、更适合做相对固定的事。

第三步：能复用的，就别每次重新聊一遍

再往后，如果这类动作已经稳定了，就不应该每次都从对话里临时拼。
直接调用可复用的 script 工具，反而更稳。

因为一旦进入“每次都重新解释、每次都重新生成、每次都重新判断”的模式，
系统又会慢慢回到之前那种高噪音、高不确定性的状态。

第四步：把方法沉淀成技能，而不是只记一次经验

我后来还多做了一步：把这类处理方式继续往下沉。
不是只留一段感想，而是把它整理成可复用的技能和规则。

比如：

• 什么场景容易产生大段原始输出
• 这类场景优先走什么解决方案
• 哪些做法应该避免
• 哪些做法更推荐

这样下次再遇到相似问题，就不是“重新踩一遍”，而是直接调用已经沉淀下来的方案。

第五步：让经验真的被吸收，而不是停在一次复盘里

我后来越来越在意的一点是：经验不能只停在“这次长记性了”。
更有用的做法，是把它整理成一种更容易复用的积累方式。

也就是把它沉成：

• 场景
• 解决方案
• 应避免的做法
• 更推荐的做法

这样它才不是一次事故复盘，
而是系统真的长出了一点新的免疫力。

4. 我最后留给自己的，不是技巧，是一条硬规矩

那次之后，我对“养 AI”这件事，定下了一条很硬的规矩：

工具可以跑很多，但主对话里只能留下“结论 + 证据索引 + 下一步动作”。

原始输出不直接进主对话。
日志不是不能看，但它应该进日志；路径不是不能存，但它应该进文件；扫描结果不是不能分析，但分析之后回来的，必须是压缩过的高密度信息。

这条规矩看起来像个小技巧，实际改的是更底层的一件事：

你不再把 AI 当成一个什么都能吞的黑箱，
你开始承认，它也是一个需要控制信息密度、需要被保护上下文的系统。

5. 这事不只是命令行场景才会遇到

看到这里，可能会觉得这是不是太技术了。
其实也不完全是。

哪怕你不用命令行，你也会遇到同类问题：

• 一口气把太多聊天记录、网页内容、截图 OCR 全塞进去
• 让 AI 同时做“理解、筛选、执行、总结”四件事
• 没有中间压缩层，导致后面对话越来越散

本质是一样的：
不是信息越多越好，而是信息要按对的形式进入。

AI 不是垃圾桶。
它吃错了，也会消化不良。

最后收一下

如果一个任务会产生大量原始输出——日志、路径、代码扫描结果、网页抓取结果——
不要让这些内容直接回流到主对话。

先压缩，再判断；
先索引，再决策；
先收口，再继续。

有时候，救回一个 AI session，不需要更强的模型。
你只需要先把噪音挡在门外。

可后来我也发现，只挡噪音还不够。
如果交流、判断、执行还混在同一个角色身上，系统照样会继续乱。
真正让它开始稳定下来的，是我后来又下的一刀：把交流和执行，彻底分开。

回头看，这次踩坑不算多高级，甚至有点笨。

但这种坑也最值得记，因为它不是某个大故障，而是那种你一开始根本不会当回事的小噪音，最后一点点把整个上下文拖坏。