写了一篇文章关于「Vibe Coding 是什么」

写了一篇文章关于「Vibe Coding 是什么」，发现写完我也没完全说清楚。也许这就是它该有的样子——边界模糊的实践。 写完之后我看了三遍，每次都问自己：「这真的是在解释一个东西，还是在解释我对这个东西的困惑？」最终答案是后者。 Vibe Coding 这个词从 Karpathy 2025 年 2 月提出到现在一年多，没有标准定义，每个人的用法都带自己项目的影子。我的用法是「AI 提速、AI 写样板、我专注做判断」；别人的用法可能是「完全不读 AI 写的代码、靠感觉接受或拒绝」、或者「用 AI 生成 prototype 但生产代码完全手写」。 当一个实践还没有沉淀成「标准定义」之前，写文章能做的就是诚实地记录「我自己的用法是什么」。所以那篇文章最终变成了我自己的 vibe coding 工作流，而非一份客观定义。 这可能是所有早期术语的共同命运：被命名、被传播、被每个人按自己的理解重新塑形，直到最终沉淀出某种共识。「云计算」「微服务」「区块链」都经历过这个过程。 写完之后还想到一个相关问题：vibe coding 和传统编程的边界到底在哪？我自己的判断是——如果 AI 写的代码出了 bug，作者能在合理时间内定位并修复，那就是 vibe coding；如果作者完全读不懂 AI 写的代码、bug 只能靠「让 AI 再试一次」解决，那就不是 vibe coding，是「AI 赌运气编程」。 后者的危险在于：技术债会指数级累积。每一次「让 AI 再试一次」都加一层抽象，每一层抽象都不在作者的理解范围内。一旦项目复杂度超过某个临界点，整个 codebase 就会变成「没人敢动」的黑盒。这是 vibe coding 最反直觉的副作用——它让人在短期内更快，长期内更慢。 2026 年这个边界更模糊了。Karpathy 自己 2026 年 4 月在 Sequoia AI Ascent 上说：「vibe coding 只是第一步，真正值得关注的是 Agentic coherent workflow，即智能体连续规划、执行、调试，并根据环境反馈自主修正。」换句话说，vibe coding 是「短循环的 vibe」，agentic engineering 是「长循环的 vibe」。两者本质是同一件事的不同时间尺度。所以我现在不纠结 vibe coding 的精确定义了——它在 2026 年已经自然演化成「AI 时代程序员该有的工作方式」的同义词。 我给自己立的那条规矩——vibe coding 只能用于「用完就丢」的场景、生产环境必须能完整 review——也跟着升级成：agentic engineering 可以用于生产环境，但人必须保持「读 AI diff、质疑 AI 方案」的习惯。AI 不再是「用完就丢」的工具，而是「永远有上级 review 的人」。