那天我拿到一份对技能文件的长篇审查。它列出了很多问题，分了优先级，还把不少内容标成“必须修复”。第一眼看上去很完整，像是已经替我做完了检查。我的第一反应也很普通：既然对方列了这么多条，那就按清单逐项改掉，改完再说。
但真正动手前，我停了下来。审查报告写得完整，不等于里面的事实已经被核对；建议数量很多，也不等于它们对当前文件都重要。这次我没有先统计“有多少条建议值得接受”，而是把每条意见拆开，回到路径、源文件和简单的运行结果里重新确认。最后发现，报告里确实有真实问题，也有不存在的路径和错误的数量统计。更重要的是，它把一些结构偏好写成了必须修复项。
这件事让我重新意识到，AI代码审查最危险的地方，不是它偶尔说错一句，而是它可以用很完整的形式，把没有核实的判断包起来。面对AI审查意见，第一步不是表态接受或反对，而是把它改写成可以被验证的事实断言。
一份完整报告为什么仍然不可靠
这份报告表面上是在审查文件质量，实际上混合了几种完全不同的内容。有些句子是在陈述事实，比如“某个路径不存在”“某个数量是47条”“描述中的数量和实际列举不一致”；有些是在提出设计建议，比如“应该增加目录”“最好补一份变更记录”；还有一些只是审查者对文档形态的偏好，比如希望它更像一份给人阅读的手册。
这些内容不能整体接受，也不能因为其中有一处错误，就把整份报告全部否定。对事实主张，应该问“它能不能被源文件证明”；对设计建议，应该问“它会不会改善实际行为”；对偏好，则要问“这个文件究竟服务谁”。如果三类内容混在一起，审查报告看起来会很有分量，执行时却容易把不同强度的判断当成同一条命令。
当时最容易走的错误捷径，就是因为报告写得长、问题列得多，就按清单全部修改。这样做的后果是，真正的缺陷会和无关的装饰一起进入文件，最后既增加维护成本，也让下一次审查更难分辨重点。如果不先做分类，修改本身就会把未经核实的判断固化下来。
先把意见改写成可核验的问题
我先处理报告里最容易确认的内容。它声称存在一个安装路径冲突，于是我没有凭印象判断，而是直接检查报告引用的路径、文件的真实位置，以及元数据里记录的来源。结果发现，报告写出的那个路径根本不存在，真实文件位置和元数据是一致的。所谓“路径不一致”，不是需要修复的缺陷，而是审查过程中生成的幻觉。
接着我核对它对触发词数量的统计。报告说有47条，我回到源文件逐项计数，实际是35条。这个错误看起来很小，却改变了报告的可信度。一个可以用简单计数验证的数字都没有对上，后面的“过多”“比例不合理”就不能直接当成事实，只能重新检查它依赖的依据。
这里有一个很实用的改写方法。不要把“第3条建议不对”直接写进结论，而要改成“文件中是否存在这个路径”“源文件里到底有多少个触发词”“描述中的数量是否等于实际列出的项目”。前一种写法是在争论观点，后一种写法是在安排检查。事实核查的价值，不是证明AI不可靠，而是把可靠性从语气里拿出来，放回证据里。
这一步还要控制范围。当前任务只需要核对报告中的具体主张，不需要顺便重审整个技能系统。检查得太宽，容易把新的猜测带进来；检查得太窄，又可能漏掉决定性证据。我选择路径、数量、源文件内容这几个最小核验面，是因为它们能直接判定报告里的关键结论，而且成本很低。
把真实问题和结构偏好分开
核对之后，报告并不是一无是处。它指出描述中的数量和后面实际列出的项目不一致，这个问题可以直接从文件内容确认。它还指出一个过宽的裸触发词，几乎只要谈到人工智能就可能误触发，这会让不相关的对话也进入技能流程。另一个句子存在粘连，两个意思挤在一起，确实影响阅读和执行。
这些意见我愿意接受，不是因为它们排在报告前面，而是因为它们分别对应了可观察的后果：描述会误导读者，触发词会增加误启动，句子粘连会让执行者理解错误。一条建议是否值得采纳，最终要看它能否改善文件的实际行为，而不是看它在报告中被标成什么等级。
报告的另一大部分建议增加目录、变更记录、常见问题、退出码表和快速上手说明。这些内容放在给人读的手册里可能有用，但当前文件主要是提供给Agent读取的工作规则。它不是让人从头翻到尾的产品说明书，也不需要为了“看起来完整”增加一套目录结构。版本变化已经有现成的记录方式，边界流程也已经写在原文件里。
我因此没有机械采纳这些建议。我的判断是，文件类型决定了评价标准：给人读的文档强调导航和解释，给Agent读的文件更需要边界清楚、触发准确、动作可执行。把前一种模板完整套过来，可能让版面更像手册，却同时增加无关文字，让真正重要的规则变得不突出。
新增复杂度也要算成本
审查时还有一个容易被忽略的维度：一条看似合理的修改，是否会引入新的维护负担。报告建议删掉同音字触发词，理由是它们看起来不够整洁。单看文字，删除似乎可以让列表更短；但这些词是为了应对语音输入中的误听，属于静态匹配，几乎没有额外维护成本。删掉它们，换来的只是表面整齐，却可能降低流程被正确触发的概率。
我没有接受这个建议，是因为它拿一个可见的形式问题，交换了一个不容易被立刻发现的健壮性损失。相反，删除过宽的裸触发词，我愿意接受，是因为它会产生真实的误启动，而且可以用更具体的表达替代。两者都涉及“触发词要不要改”，但风险方向完全不同。
这也是为什么我不按建议数量投票。一个报告里有34条意见，并不意味着至少要完成其中的一半；一条事实错误，也不意味着其余内容全部无效。真正要算的是每个改动带来的收益、风险和后续成本。如果新增一段文字不能让Agent更准确地行动，不能让人更容易验证，也不能减少误触发，那么它很可能只是把文件变长。
如果不把这部分成本算进去，审查会变成一种“越改越像合格答案”的竞赛。文件越来越完整，规则越来越多，执行时却要读更多无关内容。表面上质量分提高了，实际行为可能没有改善，甚至因为边界变模糊而变差。
我最后采用的是最小修改集
完成分类后，我没有从报告末尾开始逐项勾选，而是形成了一个最小修改集：接受能够从源文件直接证明、且会改善行为的真实问题；驳回被事实核查推翻的路径和计数；保留那些虽然不够整齐、但承担防误触发作用的机械规则；不因为审查者偏好而新增完整手册结构。
这个决策有一个重要理由：每一次改动都应该能回答“改完以后，哪种错误会更少”。数量描述修正后，读者不再被错误信息误导；过宽触发词删除后，不相关对话更不容易误启动；句子拆开后，执行边界更清楚。至于目录、变更记录和快速上手，它们没有对应到当前任务中的明确行为收益，所以暂时不加。
我也保留了一个诚实的缺口：某个探活表没有覆盖一个暂时无法探测的对象。这个问题不适合假装已经解决，但可以把原因说明白，避免后续读者误以为它被遗漏。事实、限制和改动范围都留下来，下一次审查才能继续从证据出发，而不是重新猜一遍背景。
好的审查结论不是“全部接受”或“全部驳回”，而是一张能追溯到证据、又控制住新增复杂度的取舍表。
下次我会怎么做
下次再收到AI对代码或技能文件的长篇审查，我会先把意见拆成3层。第一层是事实：路径、文件、数量、调用关系和运行结果，逐条回到源头核对。第二层是判断：它指出的行为风险是否真实，是否有具体后果，是否值得在当前范围内处理。第三层是偏好：它只是希望结构更漂亮，还是确实能让执行更稳定。
然后我会为每条意见写出一个最小验证问题。能直接查文件的，不靠解释；能简单计数的，不靠模型估算；需要运行结果的，就安排一次有边界的验证。核对结果为真，再判断是否修改；核对结果为假，就明确标记为噪声，不让它继续影响后续决策。
最后，我会检查每个拟议改动的行为收益和维护成本。如果改动只是增加格式、层级或说明，却没有减少误触发、误解和执行失败，我会先不采纳。如果它能让一个真实错误消失，就算它不够华丽，也应该优先处理。
表面上我是在审查一份审查报告，其实是在建立人与AI共同工作的边界。AI可以帮助我发现候选问题，但不能替我决定哪些事实已经成立。真正难的不是让它提出更多意见，而是保留一条从意见回到证据、从证据回到行动的链路。这个链路一旦形成，下一次面对再长的报告，也不会因为它看起来专业，就把判断权一起交出去。