vibe coding 的最佳实践到底是什么？

最近烦恼

一个小项目，把项目说明 PROJECT . md、用户故事 PLAN . md、原型图 prototype ，都给到了 AI （ opus 4.5 ），希望 AI 能一次性长时间编码。

AI 倒是吭哧吭哧编码了 20 分钟，我满怀期待，结果一看，4 个前端 tab 页对应的 4 个功能，基本不能用。感觉就像一个不负责任的人，连自测都没有测过！

编程的最佳实践是什么

AI 编程出现的问题，并不是不能理解需求。第一次给它原型图，它从中抽取的功能点非常准。但实现时，有几个问题：

1 是有些要求它直接忽略了。比如我希望渲染一个节点网络，用户可以点击某节点，展开和收起它的相邻节点。这个功能描述，在原型中和 PLAN 中都是有的，但 AI 做的时候似乎直接忽略了。也许它做了，但功能没有用，看过程，它也是有自测的。

2 是prompt 不能描述所有的信息，没描述的 AI 可能就考虑不到。比如给每个节点添加了一个+号按钮，用来表示收起和展开，但拖拽节点时，这个+号按钮并不会跟随移动。

总结一下就是，长程编码任务，AI 不能很好的完成，总有挂一漏万的感觉，虽然都说要小步快跑，但是毕竟麻烦啊；而隐含的常识，AI 有欠缺，感觉必须非常详细的说明。

第一性原理的思考

我现在对 AI 的感觉是，AI 修 bug ，编码单个功能，感觉是不在话下的。但涉及到长程的、意图推测的，就不太行。

回归到第一性原理，我尝试把 AI 编码过程，看作是一个在巨大的空间中，寻找解的过程。一个编程任务，就是要在这个巨大的多维空间中，寻找到一个解。

一旦从这个视角看，很多问题就容易理解了：

约束

解的空间是巨大的，要想办法快速找到解。

约束是在给定的空间内求解，剪枝，缩小搜索范围。

如果约束越多，解空间越小，理论上应该更容易找到解。但实践中：

约束太少 --> 解空间太大，AI 乱跑，找到的解不符合要求；

约束太多 --> 可能根本没有解（约束互相矛盾）；

架构

因为一个任务，可能有非常多的解。

不同的架构其实对应了不同的区域的解。架构其实是将解的求解范围，约束在了一个范围区域。

所以架构很重要，要早确定。一旦确定了架构，后续的求解过程，就都在这个范围区域内进行了，除非用户手动要求调整架构，求解才会「经由用户指定的路径」跳转到另一块区域。

验证

验证和反馈，是一种修正的信息，让现有的解结合修正的信息，往正确的解集上靠。让不符合的解，走向正确的解。

全局和局部

代码的各个部分之间存在耦合，一些修改，可能会影响到很多地方。问了 AI ，说在修改一个"全局相关"的东西（效率、架构）时，实际上是在高维度上移动，这会同时影响很多低维度的投影。

而局部的 bug 修复，或单个功能的实现，是在低维度上移动，也就是在局部范围内寻找解，它的影响范围有限。

vibe coding 实践的对应物

Rules = 显式的全局约束，定义解空间的边界；

Skills = 预定义的子空间/模式，是已知的"好解区域"；

Examples = 锚点，直接在解空间中标记"这里有解"；

隐性知识

人类的隐性知识，其实也是对解的一种筛选或者约束。AI 没有这些隐性知识，或者没有实际用到它们，那就意味着求得的解不符合这些隐性约束。

启发

不过，抽象的思考总是很容易，实践起来困难重重。

从上面的分析，得到的都是些 trivial 的东西，我感觉「架构要早行」这个印象比较深刻。但总的来说，仍然没有得到一个最佳实践。

最佳实践到底是什么啊？！