2026-09-17 每日思考

今天读 Martin Fowler 那篇《I Don't Like LLMs》，读得有点不舒服，因为他批评的东西，有一部分正好是我在做的事。

他的核心论点不是"LLM 写不好代码"，而是当生成变得廉价，软件工程里真正难的部分——判断力——反而更容易被跳过。评审、抽象、取舍，这些需要人慢下来想清楚的动作，在"先生成一版看看"的节奏里被压缩成了走过场。我一边读一边想我的 AI 代码审查工具：它检测安全漏洞和性能问题，输出一份报告，然后呢？如果用户看到"第 47 行存在 SQL 注入风险"，直接让模型改掉，那我的工具其实是在加速 Fowler 担心的那个过程——它把判断外包出去了。

这让我重新想一个问题：代码审查工具的价值到底应该落在哪。市面上大部分工具的逻辑是"发现问题 → 标记 → 建议修复"，追求的是覆盖率和高危漏洞的召回率。但今天 strix 那个开源 AI 渗透测试工具让我注意到一个细节——它把"发现"和"修复"放进同一个闭环。这看起来很完整，但也有风险：闭环越顺滑，人越不需要理解为什么这里会出问题。

我倾向于认为，一个负责任的审查工具，输出里应该有相当一部分是"解释"而不是"修复"。不只是说这里有漏洞，而是说这个漏洞的成因是什么、在什么调用路径下会被触发、修复方案有哪些取舍。用户读完应该比读之前更懂这段代码，而不是更依赖工具。这个目标很难量化，也没法写进 benchmark，但它可能才是工具该有的样子。

另一个让我警醒的是今天那条 OpenAI 即将攻克霍奇猜想的消息。我没有能力判断真假，但我知道历史上类似宣称大多落空。这件事对我的启发不是"AI 好厉害"，而是"验证机制比生成能力更稀缺"。我的工具也一样：它能报出一堆问题，但谁来验证这些报告本身是对的？误报率高到一定程度，用户就会关掉它，然后回到人工审查——那我的工具就白做了。所以接下来 MVP 阶段，我打算把误报率当成和召回率同等重要的一级指标来打磨，宁可少报，不可乱报。

给同样在做 AI 工具的人一个具体建议：这周花半小时，把你工具的输出报告读一遍，问自己"用户读完这份报告，是更懂代码了，还是更依赖工具了"。答案会让你重新排优先级。我的预测是，未来一年真正能在生产环境活下来的 AI 开发工具，不是检测能力最强的，而是误报控制最好、解释最清楚的那一批。