2026-09-10 每日思考

今天读 IBIB 那篇论文时，我有种被戳中的感觉——它说企业部署的是系统，不是 checkpoint。这句话几乎可以直接贴到我那个还在 MVP 阶段的 AI 代码审查工具上。

我一直在纠结模型选型：换更强的模型，漏洞检出率是不是就上去了？但真实情况是，我的工具跑在一条完整的链路上——提示词模板、代码分块策略、上下文注入方式、静态分析器的前置过滤、结果去重规则。同一份代码，换个分块粒度，误报率能差出一倍。我测的从来不是模型，是我自己搭的这条 serving route。

这带来一个很实际的产品决策：我该优化哪一层？如果继续卷模型，边际收益在下降，而且我根本控制不了上游的版本漂移。但如果把力气花在 harness 上——比如用 AST 做精确的上下文裁剪、把静态分析的确定性结论当作硬约束去压制 LLM 的幻觉——这些是真正属于我的、可复现的资产。IBIB 把 output contract 列为度量维度，我理解为：我的工具输出什么格式、带不带置信度、能不能被 CI 直接消费，这些和检出率一样重要。

第二个让我停下来想的是微软那个数字：单月 974 个 Bug。媒体把它归因于 AI 辅助发现。这对我的工具是利好叙事，但我得警惕——AI 能发现更多 Bug，不代表 AI 能判断哪个 Bug 重要。我的工具如果只是把告警数量堆上去，用户会更快地卸载它。安全漏洞和性能问题的检测，价值不在于"找得多"，而在于"排序准"。这恰恰是 harness 层能做的事，也是模型层做不好的事。

所以我的判断是：接下来一年，AI 工程工具的竞争会从"用了什么模型"转移到"链路设计得怎么样"。给同行的建议很具体——把你的评测集固定下来，然后只改 harness 的一个变量，看指标怎么动。如果你发现换个分块策略比换个模型影响更大，那你的护城河就在那里，不在 API 账单上。

预测一句：明年会出现专门做"推理链路可观测性"的工具，帮团队回答"我这次指标变化，到底是模型变了还是链路变了"。这个需求今天还很隐形，但它一定会浮上来。