「物理内存 free 仅 171M，建议尽快扩容或排查内存泄漏。」

这条诊断报告，是七亿批量远程管理工具里的 AI 助手自己写的。那阵子我正给它加"只读排查"这一块：用户说一句"看看这台机器内存怎么样"，它就通过 SSH 跑几条命令，再把回显整理成结论。报告发出去不到一分钟，对面回过来一句：「我这机器 8G 的。」

我第一反应是它连错机器了。让他把 free -h 的原样输出发我，total 7.8Gi，available 5.6Gi，free 171Mi。数字一个都没错，是列看错了。

free -h 那一屏有六列：total、used、free、shared、buff/cache、available。它把 free 那一列当成了"总内存"，于是 8G 的机器在它眼里只剩 171M。其实 free 小恰恰是正常的——Linux 会把空闲内存拿去做页缓存，buff/cache 那一列涨上去，free 就掉下来，真要用的时候内核会回收。判断一台机器还剩多少内存，看的是 available，不是 free。

更麻烦的是，它把这条正常现象写进了「发现的问题」，还给了建议。这份报告是要给用户看的，用户要是信了，轻则去加内存，重则挑个业务高峰重启机器，那就不是一句"算错了"能收场的。

我去翻它的输出整理规则，发现模板里只写了「检查内存使用情况，报告空闲内存」，没说看哪一列。模型看到 free 那一列数字最小、名字又叫 free，就顺着字面理解了。这不是模型不懂 Linux，是我没把"这份输出里每个字段是什么意思"交代清楚。

改法不复杂，提示词里写死三条：

  • 内存只看 total 和 available，不看 free；
  • 报内存固定成「总 X / 已用 Y / 可用 Z」，已用按 total 减 available 算；
  • 「发现的问题」只写真问题，阈值内的正常波动不许往里塞。

另外让它把原始回显附在报告末尾。不是给用户看的，是给它自己下一轮判断留证据——后面用户追问"你凭什么说内存够"，它能翻回原文，而不是重新编一段。

改完拿几台机器试。一台 1G 的小机器，available 只剩 90M 出头，这次它写进了问题里，是对的；8G 那台 available 5.6G，它只写在基本情况里，没再报警。同一套规则，两个结果都对，说明不是把阈值调松了，是判断依据换了。

回头看，这类坑在那几天里反复出现。模型不缺 Linux 常识，缺的是约束：六个数字摆在面前，人一眼知道 free 和 available 不是一回事，模型只看到六个数字。后来我在提示词里加了一句自己都觉得啰嗦的话——任何命令的输出，先说明每一列是什么，再做判断。这句话之后，"看错列"的毛病少了，但也没绝迹，前几天还见它把 df 的 Use% 和 Inodes 的 IUse% 混着说。

AI 助手是调出来的，不是配出来的。这话我在上下文那篇里说过一次，这次又验证了一遍。顺带说一句，给助手加能力的时候，先想清楚它能看到什么、看不到什么，比让它多跑几条命令重要得多——安全边界那篇里的教训，也是同一个道理。工具本身的说明在七亿批量远程管理工具说明书，里面那些命令示例，最好也按"每列是什么"标一遍。

如果你也在用七亿批量远程管理工具管机器，碰到助手给出的结论，建议先看一眼它引用的原始回显，别急着照做。

七亿网络这边主要做云主机和服务器，韩国、香港节点都有，机器上的内存怎么分、swap 留多少，装机时其实就能定下来：https://www.7ehl.com/