先说一个残酷但重要的事实：
顶级独立开发者并不是写得最快的人，而是最早停止写代码的人。

vibe coding 在他们手里，首先不是“加速器”，而是刹车系统。

一、他们如何开始一个项目：不是写代码，而是“排斥未来”

普通人启动项目的第一反应是：
我能不能 3 天内跑起来？

顶级独立开发者的第一反应是：
半年后，什么会让我讨厌这个项目？

所以他们在第一轮与 AI 对话时，几乎一定会做三件事：

第一，他们会非常明确地告诉 AI：
这是一个“可能失败的项目”，不要假设它会成功。

这句话极其关键。
一旦你不说，AI 默认你在构建一个“值得长期维护的系统”，它会自动引入抽象、层级和“未来友好性”。而顶级独立开发者非常清楚：失败项目死于复杂度，而不是不够优雅。

第二，他们会反复强调“可删性”。
不是可扩展，不是可配置，而是：
哪一部分我明天删掉，系统还能继续跑？

第三，他们会让 AI 主动指出“如果这个项目失败，技术上最可能失败在哪里”。
这一步不是为了规避风险，而是为了心理预演。他们在项目一开始，就已经接受“这可能是一次练习”。

这三个动作，本质上是在提前清算沉没成本。

二、他们如何用 AI：不是生成代码，而是生成分歧

普通开发者用 AI，是为了“给我一个答案”。
顶级独立开发者用 AI，是为了“制造冲突”。

在真实项目中，他们几乎不会接受“单一方案”。
哪怕只是一个登录逻辑、一个数据模型、一个缓存策略，他们也会要求 AI 给出理念冲突的多种实现。

比如：
一个是“写死但清楚的版本”，
一个是“稍微抽象、但看起来很聪明的版本”。

然后，他们做的不是选“最好”，而是选：
哪个更不像未来的负担。

这里有一个非常微妙的点：
他们不是在评估技术指标，而是在评估心理摩擦。

顶级独立开发者对“我未来会不会不想碰这段代码”这件事，异常敏感。

三、他们如何判断“vibe 对不对”：不是靠标准，而是靠反感

这是 vibe coding 最容易被误解的一点。

外行以为 vibe 是“感觉好”。
实际上，顶级独立开发者更相信：
明确的反感，比模糊的喜欢更可靠。

在真实项目里，你会看到他们频繁做一件事：
把 AI 给出的实现快速扫一眼，然后说一句极不技术的话：

“这个看起来有点烦。”
“我不想每天看到这个。”
“这个东西一多，我肯定会拖延。”

这些判断在技术论坛里是站不住脚的，但在独立开发者的世界里，它们是黄金信号。

vibe coding 在这里的作用，是：
让这些原本无法进入工程流程的感受，合法化、结构化。

他们会直接把这种反感丢回给 AI，让 AI 解释：
“如果一个工程师对这段代码产生排斥，最可能的原因是什么？”

这一步，经常直接触发一次重写。

四、他们如何推进项目：极端偏好“局部完成感”

顶级独立开发者很少追求“系统完成度”。
他们追求的是：
局部闭环带来的确定感。

所以你会发现他们的项目节奏是这样的：
一小块功能 → 完整跑通 → 暂停 → 观察 → 再决定要不要继续。

vibe coding 在这里的作用，是快速把“想法”变成“可被感受的东西”。
而不是一次性铺开架构。

他们非常警惕一种状态：
项目看起来进展很快，但内心越来越空。

一旦出现这种感觉，他们宁愿停下来删代码，也不会“为了保持势头而写下去”。

五、他们如何重构：不是修，而是“否认过去的自己”

在真实项目中，顶级独立开发者重构得非常狠，而且非常冷静。

他们不会说：
“我当时没想清楚。”

他们会说：
“那是当时最合理的选择，但现在不成立了。”

这句话背后，是一个极其成熟的 vibe coding 心态：
代码不是身份，不需要被维护尊严。

他们会让 AI 帮他们做一件事：
把旧实现拆解成三类——
哪些是错的，
哪些是过期的，
哪些是无论如何都值得保留的。

重构在这里，不是技术优化，而是认知更新。

六、他们什么时候停止使用 vibe coding：当感觉开始稳定

一个反常识的事实是：
顶级独立开发者并不是全程“沉浸式 vibe coding”。

当项目的感觉、节奏、边界已经非常清晰后，他们反而会减少与 AI 的高频对话，转而进入一种更稳定、更确定的推进状态。

这说明一件事：
vibe coding 不是替代工程，而是帮助你抵达工程。

当你已经知道“什么是对的”，就不需要再反复搜索可能性空间。

七、总结一句他们的隐性原则

如果你把顶级独立开发者的 vibe coding 行为压缩成一句话，那就是：

他们用 AI 放大判断力，而不是替代判断力。

他们从不把“不确定性交给 AI”，
他们只是让 AI 帮自己更快地看清：
什么值得继续，什么该被放弃。

这也是为什么你会看到一个现象：
真正顶级的独立开发者，用 AI 用得非常克制，但每一次都击中要害。