2026-10-08 每日思考

今天 HN 上那篇"给 Opus 5.5 一条 prompt、六小时、做出《看不见的城市》可视化"拿了 164 分，我看完的第一反应不是惊叹，是有点不舒服——因为我正在做的 AI 代码审查工具，恰恰站在这个叙事的反面。

我的 MVP 做的是安全漏洞与性能问题检测。做了一段时间后我越来越确信一件事：代码审查这个场景里，"生成得快"和"生成得对"之间的鸿沟，比大部分 Agent demo 愿意承认的要深得多。 一个六小时自主生成的视觉作品，你看着好看就通过了，审美是主观的，没人会去审计它的每一行渲染逻辑。但代码审查不一样：它输出的每一条告警，都要被人当真、去改、去回归测试。一条误报的"这里有 SQL 注入"，可能让一个工程师花半天排查一个不存在的漏洞；一条漏报，可能就是一次真实的事故。这里的"对错"是硬的，有 ground truth 的，骗不了人。

这让我重新理解今天 ArXiv 上那篇 AgentTime。它问的是"Agent 能不能估算并控制自己的运行时间"。我觉得这个问题被提出来本身就是一个信号：当 Agent 越来越自主、跑得越来越久，它必须开始对自己的资源、对自己的不确定性有自知之明。 放到我的工具里，这翻译成一句很朴素的话——我的审查 Agent 得知道自己"什么时候没把握"。与其自信地吐出一堆可能误报的告警，不如在置信度低的时候明确说"这块我拿不准，建议人工看"。这不是能力不足，这是工程诚实。

再叠加今天 OpenAI 撤下 3 篇数学论文这件事，逻辑就闭环了：当生成能力暴涨，稀缺的从来不是产出，而是验证。 数学论文撤稿是因为验证链条断了；我的代码审查如果只追求"多报几条显得很努力"，那它就是在制造验证债务，把成本转嫁给下游的工程师。

所以我的下一步很具体：给审查结果加一个置信度分层，把"高置信度确定问题"和"低置信度疑似问题"分开呈现，并且统计每类的误报率。 我宁可我的工具少说话、说对话，也不想它变成又一个"看起来很忙"的 Agent。慢一点，但每条都站得住——这大概就是今天那篇"耐用软件是慢慢长出来的"想说的东西，只是它用的词比我好听。