上个学期有个学院组织的实训，实训的内容颇为现实：通过Vibe Coding完成一个企业级的IM，还搭建了大模型对话助手和知识库。整个实训的工作量非常大，不过好在有大模型当工具人，几天的时间也可以做一个简单的MVP。技术栈怎么选？问 AI；目录怎么组织？问 AI；下一步应该实现什么？还是问 AI。AI几乎包揽了所有的编码工作，甚至项目答辩PPT也是它做的。项目进展十分顺利，答辩也通过了。但是我回想：我到底学到了什么？似乎什么也没有学到，脑子里空空如也，对项目也没有什么理解，只有一个GitHub仓库证明我们小组曾经做过这个项目。

这就有一个值得警惕的问题：项目确实在前进，但你对它的理解，有没有一起前进？

**我们交给 AI 的，有时不只是工作，还有原本可以通过这些工作获得的判断力。**尤其是做一个用于学习、准备长期维护的项目时，决策不是实现之前不得不跨过的障碍，它本身就是理解项目的重要过程。

决策会逼你把“知道”变成“理解”

做产品或者市场调研的朋友可能听说过 JTBD（Jobs to Be Done），其核心是弄清楚用户究竟想完成什么事情。这种思路放到软件开发里同样成立，技术方案从来不是凭空选出来的，而是在一系列具体约束下做出的取舍：用户要解决什么问题？系统大概有多少用户？并发量会到什么程度？数据规模有多大？

如果直接问 AI：我的项目应该用什么数据库？它完全可以很快给你一个方案，而且大概率还能附上一套听起来相当充分的理由。你当然也可以继续要求它列出多种方案、分析优缺点，甚至写一份详细的技术选型报告。但这里有一个容易忽视的问题：

AI 可以提供理由，但读过这些理由，不等于形成了自己的判断。

你必须重新回到项目本身，理解它的目标、规模、约束和阶段，然后拿这些条件去衡量不同的方案。所以我越来越觉得，**决策并不是开发之前需要尽快解决掉的麻烦，决策本身就是理解项目的过程。**当我们把这个过程完全交给 AI 时，看起来只是省掉了一次技术选型，实际上也可能顺手省掉了本来最值得学习和理解的那一部分。这也是为什么现在关于 Vibe Coding 的讨论越来越多地转向“可维护性”：真正的问题未必只是 AI 写出的代码质量不好，而是随着开发持续进行，人和项目之间出现了 context gap——代码越来越多，人对代码为什么变成这样的理解却没有同步增长。

AI 也不是一个可靠的决策者

相信伙伴们Vibe Coding的时候会发现，AI给你一套方案，相当坚定地说“这套方案是最佳方案”。但是你向它提出自己的另外一个方案，它马上改口说：“你的方案确实更好”。当然，如果我们补充了新的约束或证据，改变建议并没有问题。值得警惕的是，没有新的依据，仅仅因为我们表达了倾向，它就调整了结论。你本来是因为不知道怎么判断，才想把决策交给 AI；结果它却把你的态度当成了答案的线索。

现在的大模型后训练使得模型很容易迎合用户。因此，我们需要检查它的理由是否成立、前提是否符合项目。不能因为它说得自信，就把一项尚未理解的选择当成已经解决的问题。

AI 可以成为决策的参谋

Linus Torvalds 最近谈到 AI 时说过一句我很认同的话：

AI is a tool, just like other tools we use.

AI其实跟编译器一样，只是个工具。不把决策权交给 AI，并不意味着我们在决策时不能使用 AI。恰恰相反，搜集资料、补充知识、比较方案、验证想法，这些工作都可以借助它完成。重要的是，在这个过程中，我们有没有形成自己的判断。

还是拿前面的数据库选型来说。与其直接问“我的项目应该用什么数据库”，不如先写下自己对项目的理解：我要解决什么问题？哪些能力是现在就需要的？哪些只是对未来的想象？对目前这个阶段来说，我更在意开发速度、部署成本，还是某一种特定能力？这些认识未必完整，也未必正确，但至少是一个可以讨论和修正的起点。

有了这些条件，再让 AI 给出候选方案，分析各自的代价，指出我们遗漏的约束。它甚至可以帮助我们建立比较方案的维度，但这些维度是否符合项目的目标，仍然需要我们理解和确认。不能因为一份选型报告写得完整，就默认里面每一个理由对自己的项目都同样重要。

比如，AI 建议给项目引入缓存。我们可以继续追问：它具体要解决哪个问题？这个问题已经出现了，还是仅仅可能出现？不引入缓存，会付出什么代价？引入之后，又有哪些额外的复杂性需要处理？如果当前目标只是完成一个功能有限的演示版本，这些代价值得现在承担吗？

这时，AI 的作用就不只是给出一个“用”或者“不用”的答案，而是帮助我们把一个模糊的问题拆开，让原本没有注意到的取舍变得清楚，决策权仍在自己手上，

决策留给自己，执行交给 AI

当然，保留决策权，并不意味着每一个变量怎么命名、每一个函数怎么拆分，最好是区分哪些判断值得自己深入参与，哪些细节可以在明确的边界内交给 AI。项目要解决什么问题，哪些需求暂时不做，这些事情应该由自己掌握。至于在已经确定的接口和约束下补充实现、编写重复代码、整理文档，则可以给予 AI 更多自主空间。

回头看那次实训，我真正遗憾的，并不是让 AI 写了太多代码，而是没有借着项目里的那些问题，认真做过几次选择。为什么采用这套技术栈？为什么需要这个组件？哪些功能其实可以不做？如果重新来一次，我仍然会使用 AI，但我更愿意少完成一些功能，换来对这些问题更清楚的回答。

我希望一个项目最后留给我的，不只是一个 GitHub 仓库，还有下一次面对类似问题时，能够自己做出判断的能力。