别再问「这个函数有什么问题」

很长一段时间以来，我最常用的 prompt 都是「看看这个，告诉我哪里有问题」这类变体。

这是我用过的最差的 prompt，而且因为它的失败是缓慢的而不是明显的，所以我花了很长时间才注意到。

为什么开放式提问代价更高

「优化一下」可以意味着性能、可读性、内存，或者代码行数。这些方向相互拉扯。模型不知道你想要哪个，所以它会自行选择——或者更糟，把所有方面都处理一遍。

你得到一个重写版本，涉及十几个你根本不在意的改动，而你真正在意的那一点却纹丝不动，或者被淹没在大量改动里。

然后你纠正它。然后它再纠正。一来二去两三轮。

每一轮都会带着整个对话上下文一起膨胀。用量是按上下文长度计费的，所以第三轮比第一轮更贵。而且随着窗口填满，模型开始丢失原始意图——你花更多钱却得到更差的结果。

这个模糊的 prompt 打字的时候感觉很快很便宜，成本都累积到了下游。

这条记录超过 ~10k 条时就会变慢。我觉得是嵌套循环的问题。重写成单次遍历，行为不能改变，跑完测试。

打字时多花几秒，通常一次就能命中。

关键组成部分：

症状 — 超过 10k 变慢，而不是「很慢」

假设 — 嵌套循环（猜错了也没关系，这提供了一个起点）

约束 — 行为不能改变

验证 — 跑测试

最后那个承担了最重的工作。有了可运行的检查，agent 就自己形成了闭环，而不是交出一个看起来像是完成了的东西。

两种适合用模糊提问的情况

我不想矫枉过正，因为我也有那么一段时间走极端了。

深思熟虑的探索。 偶尔我会刻意问一个开放性问题，专门用来暴露盲区：

读一下这个文件，你觉得哪里可以改进？

上一次这样做，它标记出了一个在并发场景下会出问题的缓存失效路径——我没有考虑到并发，因为当前数据量还不需要。它还发现了两个在不同文件里逻辑几乎相同的函数，这种东西我几个月都没注意到，因为它们从来没有同时打开过。

这是真正有价值的一类产出，而精确的 prompt 从结构上就无法产生：你只能问那些你已经想象到的问题。

我定期这样做，预期信噪比大约是三比一。通过 subagent 处理，这样文件读取不会累积在主线程里。

真正的不确定。 当我不知道自己想要什么时，承认这一点比假装精确更好：

我不确定瓶颈在哪里。先分析，提出选项，暂时不要改任何东西。

假装知道会产生自信满满的解决方案，但解决的是错误的问题。

如果我能用一句话描述 diff 会是什么样子，我就精确地说明然后跳过分析。如果我不能，我就先问分析。

这个原则我坚持了好几个月。它还编码了一个真实的洞见：那些你无法描述 diff 的情况，恰恰就是你还不太理解问题的情况。

评审 prompt 的推论

同样的原则也适用于请求代码评审，但要多一条限定：

只报告影响正确性或所述需求的问题。跳过风格偏好。

让 agent 去发现问题，它就会发现问题——这就是请求本身。没有范围限定，你就会收到一大波「这里可以更优雅」，照着做就会导致过度工程：额外的抽象、防卫性代码、为不可能发生的场景写的测试。

底层经济学

返工是 AI 辅助工作中的主要成本驱动因素，而精确是控制返工的主要杠杆。

话虽如此，精确的 prompt 并不会让谨慎的工作变得便宜——它只是减少了浪费。可运行的检查仍然意味着迭代轮次。分析过程仍然需要读取代码库。评审 agent 仍然需要自己的上下文窗口。

在那些月份里，当这些开销累积超过我的基准线时，我通过 Asale 补充，而不是为峰值周配置更高的订阅档位——这是一个市场，未使用的订阅容量会被路由给需要的人，按每百万 token 计费。

标准免责条款：请求会通过另一个用户的客户端中转，所以在那一跳上 payload 是可见的。没有端到端加密，他们主页上写明了。个人项目和开源项目，没问题。涉及 NDA 的工作，不行。

有人也在做定期的开放式审计吗？很好奇其他人是否也觉得三比一的命中率值得这么做，还是只是我对自己的想法过于宽容了。