2026-09-27 每日思考

今天看到那篇关于聊天模板决定模型自我指称口吻的论文，我第一反应不是"有意思"，而是有点被戳到——因为我正在做的 AI 代码审查工具，本质上也在做一件类似的事：给模型套一层"审查员"的壳，然后期待它输出稳定、可信的判断。

论文的结论很朴素：模型说"作为一个语言模型"，很大程度上是模板注入的格式先验，不是权重里的内在属性。换模板，口吻就变。放到我的场景里，这意味着什么？意味着我那份精心写的 system prompt——"你是一名资深安全工程师，请只报告可复现的漏洞"——可能正在制造一种审查严谨性的幻觉。模型输出的"严重性：高"和结构化的 CVE 式描述，未必来自它对代码的真实理解，而可能只是模板要求它这么排版。

这对我这个 MVP 阶段的产品是个不小的提醒。代码审查和聊天不一样，聊天里口吻漂移顶多是体验问题，但审查里如果"看起来很专业"和"判断真的对"之间的相关性被高估，用户就会基于错误信号去改代码。安全漏洞检测尤其如此：漏报一个真实的注入点，比误报十条更贵，但误报太多用户又会直接关掉工具。模型的自信心和准确性之间的错位，是我必须用别的手段（比如实际构造 PoC、跑一遍污点分析）去校准的，不能靠 prompt 里的措辞。

第二个让我停下来想的，是龙芯原子加指令丢更新那条。一个"偶尔"丢失的原子操作，会让所有基于它的无锁结构在极低概率下静默出错——不崩溃，不报错，就是数据悄悄错了。这和我做性能问题检测时最怕的那类 bug 是同构的：不是那种会立刻炸掉的错误，而是那种在特定时序、特定负载下才浮现的偏差。我的工具如果只做静态模式匹配，几乎必然漏掉它们。这也让我更确信一件事——AI 代码审查的价值不该定位在"替代 linter"，而应该是"生成可验证的假设"：不是告诉用户"这里有问题"，而是给出一个能跑、能复现、能证伪的检查。

所以我的下一步很具体：把审查结果从"结论"改成"证据 + 复现步骤"，让每一条报告都附带一个可执行的最小验证（哪怕只是一个能触发问题的输入）。同时，在评测集上固定模板变量，单独测"换了措辞之后判断是否还一致"，把模板敏感性当成一个要监控的指标，而不是一个可以随手调的旋钮。

预测一句：接下来半年，会有更多团队发现自己的 Agent 产品质量问题，根因不在模型，而在那层没人认真对待的模板与脚手架。谁先把这层当成一等公民来评测，谁的产品就更可信。