1.好的模型，事半功倍

“工欲善其事必先利其器。”

显而易见，模型的智商直接决定了代码的质量。对比GPT-5 mini以及Claude Sonnet 4.5，其思考时间、输出长度以及给出的代码肯定是不同质量的。在核心业务的开发上，使用SOTA的模型，是一定能减少后期维护、Debug的成本的。

2.Vibe Coding有风险，all in 需谨慎

盲目Vibe Coding最大的陷阱在于，它非常擅长写出看起来能跑但经不起推敲的代码。

结合我在使用Vibe Coding的经验来看，AI往往倾向于使用最简单的实现方式，而忽略了工程上的鲁棒性。

例如，在我开发的实际情况中，在核心的业务逻辑以及系统的架构上，盲目使用Vibe Coding就堆了很多致命隐患。首先，AI会出现系统架构上的盲区：比如AI给出的docker-compose配置文件里，并没有把用户上传的文件挂载到容器外部，导致我们迭代更新的时候，down掉容器然后用户上传的文件就丢失了（难绷，，，简直是自讨苦吃 /悲）。

另外， AI可能会少考虑一些边界条件：比如，AI在设计系统的时候，很难考虑全面所有的情况。在我通过Vibe Coding开发的村民的信息统计展示平台中，我们需要通过序号（通过村民房屋号编码）+户号来确定居民的家庭归属，但是AI就没有考虑到序号或者户号字段缺失的情况，导致任一字段缺失的村民都无法被搜索到。

所以，从我的经验来看，一定要先和AI讨论思路与实现方案，不急于让AI上来就写代码。在让 AI 写代码前，最好先让它复述业务逻辑和异常处理方案。举个例子，如果不告诉它某个字段可能为空，它就倾向于假设数据是完美的。（甚至这个假设并不会告诉用户，而是悄悄隐藏在思维链中。）

3.与其堆💩山，不如推倒重来

使用Vibe Coding时，维护旧代码的成本往往高于重写。

在开发这个信息展示平台的过程中，有些需求AI也很难给出好的解决方案。比如用户当时要求把街道用数字编号，同时新增“序号”字段来代替原来的“东西区-南北向-房号”索引方式时，如果让AI打补丁，可能会陷入拆东墙补西墙的窘境（毕竟这部分的补丁，想想就比较复杂）。所以我就直接考虑重构数据库和后端的接口部分——直接告诉 AI 新的数据库结构，让它重写整个模块。而且毕竟Vibe Coding，这部分改动AI很快就能很好的实现。

4.阶段性总结任务，开启新的上下文

我觉得使用Vibe Coding最短的那一块木板，就是AI的上下文问题。

冗余的上下文不仅会让模型的性能下降，而且会导致其遗忘一些重要的设计（比如python虚拟环境的位置、数据库的密码、我们使用的数据库是mysql而不是sqlite等等），这时候AI就需要消耗大量的上下文来试错，使得冗余的上下文恶性积累。所以我们可以考虑阶段性把目前的方案设计总结到一个markdown文件中（同时记得git commit一下），然后重开一个对话，继续迭代下一个任务。

总结一下

总结来说，我觉得Vibe Coding最重要的技能有两点：精确表达需求+快速验证代码

首先，我们必须精确、全面、系统地表达需求，我说的全面和系统，并不一定要深入到代码层面（当然，我们在AI写完之后审核其代码是最好的～），而是在让AI编写/改动代码之前，就商定好具体的逻辑是如何实现的、具体的方案是如何设计的。

另外，我们还需要快速验证AI的代码是否能够在满足需求的同时保证其安全可靠。尽管我没有亲自阅读AI的代码（额，其实是因为我看不懂... orz），但是我一定要知道AI的实现方案与思路，看看其核心逻辑的设计是否合理。我认为这是非常必要的——也是非常考验工程经验的。因为AI能够参与到开发项目的每一个环节——需求分析、接口设计、代码实现、生成文档等等，自动化程度非常高，所以我们更需要人为地去思考系统等扩展性与维护性的问题——这往往是AI没有考虑却为未来埋下巨大隐患的点。