最近看了 Felix Rieseberg 的一篇文章：How to be more ambitious: A tutorial for humans with models。文章讲的是一个问题：AI 已经能做越来越多复杂的事了，那我们该如何更好地利用它呢？

作者将使用 AI 的野心分为四个维度：速度、高度、深度和广度。

但是看完这篇文章后，给我印象最深的不是这四个维度，而是背后的另一个问题：我们是不是一直用过去的能力边界来限制 AI 能帮我们做的事？

我们正在用更强大的工具，重复过去的工作

现在有了 AI 编程工具，人们用它来写代码、修 Bug、生成文档，一个原来一小时的工作现在十分钟就能完成。但这只是把原来的工作做得更快了，而并没有改变工作的本质。

更重要的是：AI 能否让我们去做一些以前因为成本太高、缺乏专业知识或者需要很多人配合才能完成的事情？AI 能否让我们重新思考一些我们一直以来认为理所当然的工作流程？

如果 AI 只是把原来的工作做得更快，那么它就只是一个提高效率的工具；但是如果 AI 让我们能够做到以前不敢想、做不到的事情，那它才真正能拓展我们能力的边界。这一点比起单纯地比较谁的模型编码水平更高要重要得多。

不要只让 AI 完成任务，要让它帮助我们实现目标

我觉得最有启发的一句话就是：“从安排任务到明确结果。”

以前我们总喜欢让 AI 去实现某个功能、修复某个 Bug、优化某段代码，以为自己已经知道该怎么做了。其实很多时候，我们并不知道最优解是什么。

比如开发一个 3D 游戏，与其只让 AI 去做天气系统，不如让 AI 去研究天气怎么影响探索、环境、怪物、资源和性能，然后给出一个可以落地、可以验证的解决方案。维护一个开源库也是这样，不只是生成 Hook 或 Plugin，还要考虑 API、依赖、Tree-shaking、测试、用户体验等等。

完成任务，是我们拆分和分配的；解决问题，是先想好目标，再让 AI 帮忙找路。

这并不是说“把项目做好”就行了。目标越大，就越需要清晰的约束、真实的背景和验证方式。最关键的是，别把自己第一个反应当成唯一的答案。

让 AI 像专家一样工作，而不只是说专家会说的话

让 AI 成为专家，和让 AI 使用专家的方法，是不同的。让 AI“像一个资深的架构师一样思考”，可能会给出听起来很专业的答案，但是不一定能解决实际的问题。

例如，当 Three.js 场景运行缓慢的时候，AI 可能会给出一些建议，比如减少 DrawCall、优化材质或者降低多边形的数量等等，但这些方法并不一定都适合。

更可靠的做法是先收集性能数据，找到 CPU 或者 GPU 的瓶颈，或者渲染、加载、内存等，然后再考虑如何优化。如果需要排查 Bug，也应该提供一些复现的步骤、日志、代码以及测试的结果，这样 AI 才能去验证自己的猜测。

专业不仅仅是会说些专业术语，还包括了收集证据、使用工具、检验结果。所以要想让 AI 做好复杂的工作，就需要给它提供这些数据、工具和反馈。

没有代码运行的能力、没有性能数据、没有测试的标准，它就无法确认答案是否真的有效。AI 能力虽然很重要，但是工作环境也会影响到它能发挥出多少能力。

跨领域协作，可能是个人开发者最值得利用的优势

以前复杂的项目需要工程师、设计师、分析师和测试人员一起合作，一个人不可能包办一切。

AI 可以让不同的工作流分别负责需求分析、设计、开发、测试和审查，也能够从不同的专业角度寻找方案。AI 协作的价值不在于有多少个智能体，而在于能够以低成本得到互相补充的专业意见。

比如分别研究用户的需要、技术的限制以及可能的风险，然后通过证据和测试来判断哪些方案是可行的。

但是增加智能体并不一定意味着更好的质量。如果它们基于相同的信息、共享相同的错误假设，又没有独立的验证，那么它们只会重复同样的错误。

所以协作的关键是要有明确的分工、不同的分析方法和检验标准，关键是每个人都能提供一些有价值的东西。

对于个人开发者而言，可以先使用 AI 来建立一个小型的协作系统，然后再根据项目的需要，逐渐完善，而不必一开始就建立一个完整的团队。

最大的限制，可能是我们不相信自己能做到

文章最后提到了自我效能感，提醒大家：AI 带来的一切变化，不仅仅是技术上的。

以前一个人要做一个 3D 游戏，还要考虑代码、架构、测试、文档、发布等等，难度很大。所以人们常常会选择熟悉的、可控的东西，而可能忽略了一件事：现在的尝试成本越来越低了。

AI 可以帮助我们做一些研究、学习一些新的领域、分析一些案例、做一个原型等等。一个人能做的，也可以是一个人完成。

当然，AI 并不是万能的，也不是专业的判断。AI 改变的，是我们考虑一件事是否值得去尝试的条件。

过去的经验固然重要，但是不应该是判断未来的唯一标准。当尝试的成本降低以后，也许有些想法可以再考虑一下。

真正的野心，是重新定义值得解决的问题

看完这篇文章，我觉得我对 AI 帮助开发有了一个更加清晰的认识。下一步值得追求的也许不是更强的模型、更长的上下文、更复杂的提示词，或者是更多的智能体。这些当然很重要，但是它们只是手段而已。更重要的是，我们是否能够重新思考一下我们正在解决的问题本身？

当我们要让 AI 来完成某件事情的时候，可以先问自己几个问题：我到底想要的是什么？当前的任务只是通向结果的一个手段吗？如果是这个领域最优秀的人来做这件事情的话，他会使用一些我没有考虑到的办法吗？为了真正解决这个问题，AI 需要哪些原始的数据、工具和执行环境？我可以独立测试、实际运行或者从外部得到反馈来验证最终的结果吗？还有哪些领域中的知识和方法能够帮助我找到更好的解决方案？

这些问题也许不会让每件事情都变得简单，但是也许会让我找到之前没有想到的路径。

我也并不认为所谓的野心就是要把所有的任务都交给 AI，或者不加判断地追求更大的项目、更复杂的项目。真正的野心应该是愿意挑战原来的假设，同时也愿意为最终的结果承担责任。

我们可以让 AI 去探索更多的可能性，但是仍然需要判断哪些目标是值得实现的，哪些方案是符合现实约束的，什么样的结果才是真正的成功。AI 可以生成越来越多的答案，但是选择正确的提问、制定合理的目标和标准、为结果负责，仍然是人的工作。

如果说过去开发者需要不断学习新的工具，才能提高自己的效率，那么在 AI 时代，开发者可能还需要另外一种能力：不断重新思考自己到底能够完成什么，什么事情是值得自己去完成的。

也许，下一次看到一个想法，觉得它太复杂了、太昂贵了、超出了自己的能力范围，而想放弃的时候，不需要急于放弃。不妨先问自己一个问题：如果今天已经拥有 AI 的帮助，我还会像以前一样认为这件事做不到吗？

也许真正值得尝试的事情就隐藏在这句话的答案之中。