别替AI认输：给AI看似不合理的目标再推动它探索

原创 刘小排 2026-10-19 22:53 北京

你的网站要10秒打开，你希望AI帮你优化到5秒。等等，为什么不是0.2秒？？

哈喽，大家好，我是刘小排。

前些天，Anthropic的Felix Rieseberg分享了一个观点，我看完才意识到：我们可能太习惯认输了。

作为软件开发者，无论是产品经理还是程序员，从小受到的训练都是“不能既要又要还要”，我们习惯于所谓的Trade-Off。

Trade-Off，这个我们曾经引以为豪的专业技能，今天可能并不是“不再适用”，而是可能被我们“用得太早”了。

以前，我们习惯先做取舍，再动手。现在，我们不妨先动手，再看看到底需不需要取舍。

比如说，我们到底应该如何提升网站性能（网站被打开的速度）呢？

你的网站打开要 10 秒，你希望优化到 5 秒，于是你问AI：请帮我优化到5秒。

Felix Rieseberg 说，不对，正确的方法是要求AI —— 帮我优化到0.2秒就能打开！

一句话概括，Felix的方法论是

给 AI 一个看似不合理的目标，并坚持让它寻找解决办法。

如果模型表示不可能，他建议不要马上降低要求，而是继续推动模型探索。

我顿悟了！

我们提需求的时候，心里面早就打过折了。心里想要 100 分，嘴上说 60 分，因为“那个太难，不现实”。这个习惯是跟人合作养出来的。人有时间，有精力，有预算，你得体谅。

可现在干活的是 AI，你还在替它体谅？！

它还没喊难，你先认输了！

Felix方法背后的玄机

Felix真是高人。我琢磨了一下，这套方法背后有三层意思，我们平时可能没有注意到。

第一层：你提出的目标，可能并不是你真正想要的目标。

你希望网站从 10 秒缩短到 5 秒，为什么是 5 秒？

很可能不是因为用户希望等 5 秒，而是因为你知道把 10 秒优化到 5 秒已经很困难了。

换句话说：

• 你真正想要的是一个几乎不需要等待的网站。
• 但你考虑了技术困难，主动降低到 5 秒。
• 于是 AI 接收到的任务，就变成了努力实现这个妥协后的目标。

第二层：目标越高，AI 才越可能考虑不同的方法。

如果你要求从 10 秒优化到 5 秒，AI 可能优先做图片压缩、代码拆分、缓存等常规优化。

但是你要求 200 毫秒，它就需要重新检查整个系统架构：是不是必须请求服务器？是不是能够预渲染？是否能够使用边缘缓存？能否提前加载必要资源？数据库查询是不是根本不应该出现在关键路径？

甚至会反过来质疑：为什么这个页面必须按照现有方式打开？

我想起一本自己读过了很多次的书《10x Is Easier Than 2x》，中文翻译叫《为什么10倍增长比2倍更容易》。

追求 2 倍增长，你可能只需要把原来的事情做得更好。追求 10 倍增长，你就不得不换一种做事的方法。

原来，这套方法也可以用来用在AI身上！

第三层：不要让AI的第一次回答决定你的目标。

它说做不到，可能真的做不到；也可能只是没有尝试更彻底的方案。

Felix建议继续推动它，是为了避免把第一轮方案的局限当成任务本身的极限。

正确做法不是让 AI 保证实现不可能的指标，而是让它先探索、实测、证明；如果确实存在物理或工程限制，再给出证据。

见到铁证如山之前，我们和AI，谁都别服软！

限制 AI 的，可能是我们

Felix 提到心理学里的“自我效能感”：很多事做不成，不全是能力不够，是一开始就不信自己能成。

以前我们不敢想，是因为知道做不到，这很合理。

可现在 AI 的能力隔几个月就变一次，我们还在拿去年的经验，决定今天什么值得试。

有时候，限制 AI 的不是 AI，是我们给它的那个太保守的任务。

比如，下次你让 AI 做一个软件产品。

你要求界面漂亮、功能完整、体验优异、运行流畅，还要开发速度快、服务器成本低。

AI 告诉你，这几个目标很难同时实现，建议做一些取舍。

“好的呀～不过这里有个小小的建议 😊

想要同时兼顾这么多目标，可能会有一些挑战哦。建议我们先做一个 MVP 版本，优先实现核心功能，后续再逐步优化性能和界面，这样会更稳妥呢～”

偶尔还会带上一些小表情，就像个小绿茶一样。

你应该回答它：

少废话！自己想办法！我全都要！

跳转微信打开