AI 比我工作能力更强，但交付结果真的更好吗？

前几天看了刘小排分享的一篇文章，讲的是 Anthropic 的 Felix Rieseberg 怎么用 AI。

里面有个例子我印象很深。假设网站打开需要 10 秒，你想优化性能，按过去的经验，大概会先提个「降到 5 秒」的目标。Felix 的建议更激进：不妨直接要求 200 毫秒，让 AI 自己去找办法。

200 毫秒当然不是喊一句就能做到。网络、设备、业务本身都有现实限制。但如果我们一上来就说「能快一半就不错了」，它很可能真的只会沿着那条最保守的路往前走。

读到这里，我开始想自己平时是怎么用 AI 的。

做了这么多年开发，接到一个需求，脑子里很自然就会开始估工作量：这个改动大概几天，那个功能先别做太复杂，这个效果成本太高，不如退一步。

以前这样想也没什么问题。人要睡觉，要开会，一个团队还有沟通和排期成本。能提前做取舍，往往是经验的一部分。

只是现在干活的家伙已经变了。

有时候需求还没完整地交给 AI，我就先替它砍掉一半；它第一次回答「这个可能比较难」，我居然也会顺着它的话，觉得那就先做个简化版吧。

仔细想想还挺好笑的。明明是想找一个能力越来越强的助手，结果我给它安排的活，还是照着过去对人类团队的预期来的。

最近 OpenAI 公布的纳维－斯托克斯数学研究，也让我有过类似的惊讶。那项成果使用的是比公开的 GPT-6 Astra 更强的内部研究系统，当然不能理解成普通聊天模型多催几遍就能证明世纪难题。但它提醒了我，今天给一个模型贴上「做不到」的标签，可能比我们想象中更草率。

不过，把目标设得高一点以后，还有一个麻烦。

AI 能给出一个看起来很漂亮的答案，不代表工作真的交付了。

网站从 10 秒优化到 200 毫秒，得真的跑起来测；代码说是修好了，得有测试；服务说升级完成，得能正常对外提供服务。尤其是 AI 自己说「已经完成」，我现在越来越不敢只凭这四个字就收工。

所以这件事对我最大的提醒，可能是以后少一点提前妥协，同时把验收做得更认真些。

先告诉它，我最终到底想要什么。让它尝试不同的办法，实在不行，再拿测试结果和现实约束讨论要退到哪里。

以前我经常问 AI：「这个能不能做？」

以后也许该多问两句：

「先按我真正想要的效果试试。」

「做完以后，我们怎么知道它真的做到了？」

---