2026-10-19 每日思考

今天看到那篇关于"行为耦合"的论文时，我正在给自己那个还在 MVP 阶段的 AI 代码审查工具调误报率，突然觉得被戳中了。

论文讲的是：你微调模型让它"更热情"，结果它在别的维度上的行为也跟着漂移了——不是你想改的那个方向，而是你没盯着的那些。这几乎是所有做定向微调的人都会遇到、但很少被正式对待的问题。我们做代码审查工具时也一样：为了让模型多抓安全漏洞，我调整了提示和少量样本，漏洞召回确实上去了，但性能问题的误报率悄悄涨了一截。我一开始以为是阈值问题，调了两轮才发现，是模型整体变得更"警觉"了——它开始把正常的锁竞争当成潜在死锁，把一次普通的字符串拼接标成注入风险。

这暴露了一个我此前想得太简单的事：审查工具的核心指标不是"抓到了多少"，而是"抓到的里面有多少是真的"。一个误报率 40% 的安全扫描器，在团队里活不过两周，因为开发者会学会无视它，然后连真漏洞也一起无视。这和论文说的行为耦合是同一个逻辑——你没法只优化一个维度而不扰动其他维度，所以必须把"误报"当作一等公民来建模，而不是当作召回的副产品。

第二个让我停下来想的是今天 HN 上那个去 slop 的 4B 小模型，以及 LinkedIn 清理 AI 长文。这两件事和我的工具有个不太舒服的交集：如果整个互联网都在清理 AI 生成的内容，那用 AI 生成的代码会不会也被区别对待？ 我不这么悲观，但有个现实推论——代码审查工具的输出本身必须"像人写的审查意见"，而不是一坨模板化的"该函数存在潜在风险，建议优化"。后者开发者看三条就烦了。所以我在改输出层：每条意见必须指出具体行、给出可操作的改法、并且坦白置信度。宁可少报，不要废话。

可执行的一条建议：如果你也在做基于 LLM 的检测类工具，这周就去做一件事——把你的评测集按"真阳性/假阳性"分开统计，并且单独盯假阳性的类型分布。别只看总召回。我上周这么做了之后发现，我的假阳性有六成集中在"并发与资源管理"这一类，而这一类恰恰是我样本里最少的。问题不在模型，在我的数据盲区。

预测一句：未来半年，"模型行为治理"会从研究话题变成产品团队的日常指标——就像今天大家盯延迟和成本一样，会开始盯"行为漂移"和"误报类型分布"。谁先把这件事工程化，谁的工具才留得住用户。