很多人以为，AI 变得不好用，是因为模型不够聪明。

但我后来越来越确定，很多时候不是它突然变笨了，而是你先没把规矩立住。

人处理信息时，其实会天然做很多筛选。

老师傅看一眼日志，知道哪里只是噪音，哪里才值得追；实习生常常不是这样，容易把看到的东西照单全收，轻重不分，主次不分。

模型，尤其当能力还不够强的时候，也很像这样。

你不给它规矩，不先替它把边界划出来，它就很容易把本来该待在后台的原始输出，整段整段带回主对话里。

日志、路径墙、扫描结果、调试噪音。

这些东西单看都不算错，堆在一起就很致命。

我踩过一个很典型的坑：任务本身一点都不复杂，做一次系统备份。目标也很明确：把真正有用的目录和配置保留下来，把 cache、临时文件、各种没价值的残留排除掉。真正决定去跑 find 的，是模型自己。问题也就是从这里开始的。

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

它为了完成”把 cache 类目录排除掉”这件事，自己选择直接跑了 find。

find 很忠诚，也很致命：它开始输出大量路径信息。

不是几十行，而是一路往下喷。

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

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

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

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

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

然后更糟的事就来了。因为这不是一次性的”输出太长”，而是叠加了系统记忆和会话延续机制。后面的表现非常典型：

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

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

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

工具当然可以调用。

目录当然也要扫。

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

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

所以这个坑的本质，不是 find。

而是原始输出回流到了本来应该只讨论结论和判断的地方。

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

那次之后，我没有去怪模型，也没有去换工具。

我改的是处理方案，而且改得比之前更”死板”一点。

因为我后来意识到，面对这类相对固定、又容易产生大量原始输出的任务，不能再指望模型临场发挥。

得先把路径收窄，把动作收敛，把可复用的东西沉下来。

• 📁第一步：先把首层目录整理出来，输出到文件
  
  不再让它在主对话里一边扫、一边吐结果，而是先把要备份的内容按首层目录整理出来，输出到文件。主对话里只留：这个记录文件是什么，它放在哪里，接下来要被拿来干什么。原始材料可以存在，但它先退出主对话。
• ⚙️第二步：根据文件内容生成代码脚本，用可控程序做固定动作
  
  有了整理好的目录文件之后，直接生成对应的代码 script 或工具脚本。程序的好处不是它更聪明，而是它更死板、更可检查、更适合做相对固定的事。
• ♻️第三步：能复用的，就别每次重新聊一遍
  
  如果这类动作已经稳定了，就直接调用可复用的 script 工具。一旦进入”每次都重新解释、每次都重新生成”的模式，系统又会回到高噪音、高不确定性的状态。
• 📋第四步：把方法沉淀成技能，而不是只记一次经验
  
  把这类处理方式继续往下沉——整理成可复用的技能和规则：什么场景容易产生大段原始输出、这类场景优先走什么解决方案、哪些做法应该避免、哪些更推荐。
• 🧠第五步：让经验真的被吸收，而不是停在一次复盘里
  
  把它沉成：场景 → 解决方案 → 应避免的做法 → 更推荐的做法。这样它才不是一次事故复盘，而是系统真的长出了一点新的免疫力。

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

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

原始输出不直接进主对话。

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

这条规矩看起来像个小技巧，实际改的是更底层的一件事：你不再把 AI 当成一个什么都能吞的黑箱，你开始承认，它也是一个需要控制信息密度、需要被保护上下文的系统。

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

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

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

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

最后收一下

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

先压缩，再判断；

先索引，再决策；

先收口，再继续。

有时候，救回一个 AI session，不需要更强的模型。

你只需要先把噪音挡在门外。

可后来我也发现，只挡噪音还不够。

如果交流、判断、执行还混在同一个角色身上，系统照样会继续乱。

真正让它开始稳定下来的，是我后来又下的一刀：把交流和执行，彻底分开。