评审一个 Agent 系统，最后总会得到一份发现清单。清单本身没问题，问题是它去了哪里。
大多数时候的默认动作是：读一遍，点头，记住，下次注意。
**「下次注意」不是一个修复。**它是一种情绪，不是一条约束。换个人、换段上下文、换个模型版本，它就不存在了。下一轮同样的问题会原样回来，而你会以为自己已经解决过它。
熵增定律适用于 Agent
Agent 会复制现有模式，好的坏的一起复制。它读到的上下文里有什么，它就倾向于产出什么。
所以「这次改好了」几乎从不意味着「以后都好」。不把标准固化下来，下一轮就会漂回去——而且是无声地漂回去，因为没有任何东西在盯着这条标准。
这是 Agent 系统和普通软件最不一样的地方：普通软件你改完就是改完了，Agent 改完之后，重力还在。
每条发现只有三个合法去处
我给自己定的规矩是：一次评审产出的每一条，必须落进下面三类之一。
- 直接修掉。 能当场改的，当场改。
- 编码成检查器。 改不掉、或者会反复发生的，变成一条机器每次都跑的检查。
- 写明「为什么暂时不能自动化」。 连同它现在靠什么兜着——谁在看、多久看一次。
三样都没做的发现，等于没发现。清单上剩下的那些「注意一下」「优化下措辞」「保持警惕」，下一轮评审会一字不差地再生成一遍——这本身就是证据。
判据可以更狠一点：**一条规则如果无法被机器验证，它就还没有真正进入流程。**它现在还是一段文字。
我们做短视频生产线时，先写了十条铁律，每条都是被打回来过的教训。但铁律写在文档里的那几周，该犯的错照犯。直到把它们逐条翻译成质检脚本里的断言——画面主体是否贴题、关键信息是否在安全区内、同系列相邻两集是否共用了镜头——返工率才真的掉下来。顺序不能反：**先写进检查器，再写进规范。**反过来做，规则就会退化成文字。
生成者不能评估自己
一个很容易踩的坑：用同一个 Agent、同一段上下文去检查自己刚生成的东西。
它会系统性偏宽。它知道自己为什么这么写，那个理由在上下文里还热着，于是每一处可疑的地方都会被解释过去。
评估要独立：独立的提示词、独立的样例，最好是独立的模型。这不是为了更聪明，是为了不共享借口。
完整评审是找新约束的工具，不是日常
人工做一次彻底评审很贵，所以它的定位应该是勘探：找出还没被检查器覆盖的那类问题。找到了就编进检查器，之后靠检查器维持。
如果每次人工评审发现的都是同一类问题，那说明这类问题早就该被机械化了——真正该被评审的不是系统，是你为什么还在手工做这件事。
检查器本身也要维护
加检查很爽，但检查器不是越多越好。阈值太严会变成噪音，人开始习惯性忽略；太松则形同虚设，只是让人心安。
所以要定期回看：哪些告警最后被证明是真问题，哪些从来没有。没有命中过的检查要么删掉，要么调紧——留着一条没人信的告警，比没有这条告警更糟。
还没想清楚的
一条约束什么时候该从提示词层升级到代码层？
提示词层便宜、好改，但会被模型「理解」掉；代码层刚硬、可靠，但每一条都是维护成本。我现在的经验法则是：同一条建议连着几轮都没生效，就该升级。
但「几轮」我还没有好答案。两轮可能只是巧合，五轮可能已经烧掉了一个月。