一个小项目，把项目说明 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 的东西，我感觉「架构要早行」这个印象比较深刻。但总的来说，仍然没有得到一个最佳实践。
最佳实践到底是什么啊？！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。