Vibe Coding 不是随意编程，而是更严格地表达意图

从“怎么做”转向“要什么”#

传统开发里，开发者会先把需求翻译成接口、数据结构和函数调用。AI 编程把这层翻译交给模型，于是人的工作重心变成：说清楚结果、边界与验收方式。

一个模糊请求是：

做一个好看的博客。

一个可执行请求是：

用 Astro 搭建可部署到 GitHub Pages 的中文博客；文章来自 Markdown；深色、单栏、内容优先；保留项目页；构建和移动端都要验证。

差别不是措辞漂亮，而是后者包含了技术选择、范围、视觉方向和验收条件。

小步推进，比一次性许愿可靠#

AI 编程可以拆成四个小循环：

1. 观察：读取现有结构和真实约束；
2. 设计：明确本次要改变的最小范围；
3. 实现：只改与目标相关的文件；
4. 验证：运行构建、测试或实际页面。

每一轮只推进一个可验证的切片。这样即便模型理解偏了，也能很快止损，而不是在数千行改动后才发现方向错误。

需要提前说出的边界#

AI 最容易在未被约束时“自作主张”。因此下面几类信息应该前置：

• 哪些文件或功能不能动；
• 是否允许增加依赖；
• 是否涉及删除、覆盖、发布；
• 哪些视觉元素必须保留；
• 什么才算完成。

这也是为什么 Vibe Coding 的关键能力不是提示词花样，而是产品判断力：你得知道什么值得做，什么不该做，以及如何判断它做对了。

最后仍要回到工程基本功#

AI 可以写出实现，但不能替你承担上线后的维护成本。依赖是否必要、边界是否清晰、错误是否可恢复、变更是否可回滚，这些问题仍然需要工程判断。

好的 Vibe Coding，不是放弃结构；恰恰相反，是用更少的代码操作，换取对结构更高的要求。