「物理内存 free 仅 171M，内存压力偏大。」

那天给七亿批量远程管理工具的 SSH 运维 AI 助手调诊断输出，报告里蹦出这么一行。我盯着看了半天——这台机器 8G 内存，刚起来没多久，怎么可能只剩 171M。

先说背景。RdpManager（就是那个七亿批量远程管理工具）那阵子在 SSH 终端里接了个 AI 助手，选一台 Linux 主机，让它通过 SSH 一步步帮着干活：装宝塔、挂磁盘、看日志、排障碍。核心是「逐步执行」——AI 每次给一条命令，客户端在服务器上真跑，把真实回显喂回去，它再看结果决定下一条。诊断是其中一环：用户问一句「机器卡不卡」「资源够不够」，AI 自己挑几条只读命令跑一遍，再把结论整理成一份报告。坑就出在这份报告上。

它跑的确实是 free -h。输出大概这样：

              total        used        free      shared  buff/cache   available
Mem:           7.8Gi       1.1Gi       171Mi       12Mi       6.5Gi       6.4Gi

它眼睛直接黏在 free 那一列——171Mi，然后写「物理内存 free 仅 171M，内存压力偏大」，还把这条塞进了「发现的问题」里。

这就是把列看串了。free 这个列名跟命令名一模一样，乍一看像是「空闲内存还剩多少」；可实际上 Linux 会把大量内存拿去做 buff/cache——文件系统缓存、块设备缓存——这块是随时能还给应用的。所以一台 8G 的机器，free 列很小完全正常，真正该看的是最后一列 available，它才是「应用还能拿到多少」。这台机器 available 有 6.4G，健康得很。

我第一反应是它算错了，转头先去翻它到底跑了哪条命令——干这行的毛病，先看证据，不先信结论。命令没问题，是它读错了列。

一开始想的是在代码里兜一层：解析 free 输出的时候，把 available 单独拎出来算。后来觉得这不是解析的事，是它「该怎么判断」的事——同一段 free 输出，换个说法问，它还是可能看串。真正要卡的是输出规范。于是在给它写的诊断提示词里，把内存这块钉死：

  • 看内存只认 total 和 available 两列，free 列不作为「可用内存」的依据；
  • 报内存必须写成「总 X / 已用 Y / 可用 Z」，把三个数摆出来，别只甩一个数；
  • 只有真不正常才算「问题」——free 列偏小这种正常现象，不许往「发现的问题」里写。

改完再让它跑，它这次老实报「总 7.8G / 已用 1.1G / 可用 6.4G」，问题列表也干净了。

回头看这件小事，挺有代表性。给七亿批量远程管理工具塞个 AI 助手，最难的不是把 free -h 接进来——那个半小时就接完了。难的是「判断」：free 和 available 差一个词，结论就天差地别；模型不知道这俩列在你这台机器上意味着什么，它只会照着字面猜。你不在提示词里把「该怎么看」钉死，它就会漂。它是我把 IPv6 一次开好 的那套「逐步执行」反过来用——执行它能一步步看着真实结果走，可轮到自己下判断，还是得有现成的规矩兜着。

那阵子这类坑踩了一串：它把内存看串、把「看看磁盘」当成安全评估一条命令都不跑、把只在服务器上 curl 127.0.0.1 通当成「服务没问题」。回头看，全是同一类——它不是不会，是缺「这一行到底该怎么理解」的规矩。这些规矩后来也顺手写进了七亿批量远程管理工具的用例里，谁再问一句「内存够不够」，先看 available，别被那个只有 171M 的 free 吓着。