诊断报告弹出来，我扫到中间一行：「物理内存 free 仅 171M，建议尽快排查内存占用。」底下还跟了一句，内存可能不足。

那台机器，8G 内存。

用户先看到的，他回过来一句：「我这台是 8G 的，它是不是算错了。」我当时也有点懵，登上服务器 free -h 敲了一遍：

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

一行行看下来就明白了。free 那一列确实只有 171M，它没读错表；total 是 7.8G，available 还剩 6.3G，机器好好的。

问题出在它拿了哪一列。

这个长在七亿批量远程管理工具里的助手，做诊断时会把命令回显塞回给模型，让它写一段「体检报告」。模型看到 free -h 的表头，挑了 free 那一列——名字还就叫 free——当成了「剩下的内存」，再拿它去比总内存，一比就得出「只剩 171M」。可 8G 的机器上 free 列小得可怜本来就是常态：内存没闲着，被内核拿去做了磁盘缓存（buff/cache），需要的时候随时能还回来。真正代表「还能用多少」的是 available，不是 free。

坏还不在读错列，坏在它把这个数，当成一个「问题」写进了报告里。

用户其实没被吓到，他知道自己机器多大。换成不太懂的客户，报告上白纸黑字写着「内存可能不足」，大概率要来找我，问是不是该加内存。一条本来不存在的告警，就这么造出来了。

修的时候我把提示词那段钉死：内存只看 total 和 available，不看 free；报内存统一写成「总 X / 已用 Y / 可用 Z」这种三条数一起给的格式；最后一条是——只把真正的问题写进「问题」那一栏。
free -h.png

那阵子给七亿批量远程管理工具做这个助手，这一类坑我记了好几个，归到一起就是「分不清正常和问题」。AI 写报告的时候，只要看到某个数「看着不对劲」，就容易当成故障往上写——它没有那点经验判断：这个数小，是这台机器正常该有的样子。它只知道「小」。

这类毛病比读错一列更麻烦。读错列是硬伤，一看就看得出来，改一行提示词的事；把正常现象列成问题，是软的，报告读起来还挺像回事，不盯着看根本发现不了。攒多了就成了「狼来了」——真出问题那条，混在一堆虚报里，谁还当真。

后来再翻这些记录，我发现自己改这种问题的路子一直在变。一开始是遇到一个补一个，报告里冒出哪句话不对，就回去加一句提示词。补到后面才慢慢转到另外一头：不去教它「这个数是什么意思」，而是先把「什么样才算问题」给它定下来——定不了的，宁可不写进问题栏，也不虚报。像它自作主张把我监控库删了那次，根子也是它自己下了个「这些文件没用」的判断，判断一歪，动作就跟着歪。

说到底，让模型读命令、写结论都不难，难的是让它知道哪条结论「不该说出口」。这一点，市面上不少七亿批量远程管理工具这类软件的 AI 功能都还在摸索，我也一样。

那天报告改完我又让它在同一台机器上跑了一遍，这回「问题」栏是空的。用户回了个「行」。挺好，空着才正常。