打磨：打磨 Vibe 代码的艺术

我最近读了 Mitchell Hashimoto 关于优化非平凡 Ghostty 功能的氛围编程的文章，他描述了自己的“反粗制滥造（anti-slop）会议”：

在这些[提示词会话]中，我通常也会顺手进行一些细微的手动修改。

清理步骤非常重要。要有效地进行清理，你必须对代码有相当深入的理解，这迫使我不能盲目地接受 AI 编写的代码。随之而来的是，组织良好且文档完备的代码能帮助未来的智能体（agentic）会话表现得更好。

我有时会戏称这为“反粗制滥造会议”。

在关于“氛围编程”（vibe coding）的辩论中，清理步骤似乎被排除在讨论之外。每个人都认同“使其能运行、使其正确、使其高效”的原则，对于像 Mitchell 这样经验丰富的开发者来说，很明显 LLM 可以迅速加速“使其能运行”这一阶段。

但出于某种原因，每个人都认为氛围编程到此为止了。而在 Continue，我们倾向于将氛围编程的过程比作雕塑创作。

冲击钻

CLI（命令行接口）是你的冲击钻，它能打破巨大的可能性障碍，让你在不陷入细节的情况下验证想法并探索架构模式。正如 Karpathy 在最初的氛围编程文章中所述，在这个阶段，你“甚至可以忘记代码的存在”。对许多工程师来说，这令人感到不适，但这是实现“使其能运行”的最快路径。

但可运行的代码并不等于成品代码。你真正想要的核心被埋在了一堆 AI 生成的“垃圾”（slop）之下：重复的功能、1000 行的方法、毫无意义的单元测试。就像面对一块粗糙大理石的雕塑家，你需要剔除多余的部分，露出其下干净、符合逻辑的核心。

凿子

这时你需要进行精炼和打磨，使用任何最适合你工作流的工具。你将臃肿的函数重构为三个专注的函数。你剥离掉那些为了一个用例而设计的过度抽象。你将 processDataAndTransformResultsIntoFinalFormat() 重命名为简单的 parse()。

雕琢不仅是清理，更是理解。你优化的每一行代码都迫使你去理解它的实际运作方式，而不仅仅是知道它能运行。这就是“氛围编程”转化为“氛围工程”的地方。你不再只是指挥 AI，你是在为每一个决策、每一个抽象、每一行最终交付的代码负责。

诱惑在于停留在“能运行”阶段——毕竟测试都通过了。但如果不进行雕琢，你构建的就不是软件，而是在以每小时数千 token 的惊人速度累积技术债务。氛围编程给了你速度，但雕琢给了你质量。正是这种关键的人类判断，才将原型与生产级代码区分开来。

规模化雕琢

挑战在于：随着团队采用 AI 辅助开发，雕琢变成了瓶颈。你不能指望每个开发者每次都能完美地进行雕琢。当团队以 AI 加速后的速度交付时，那些存在于文档中或资深工程师脑海里的标准就无法规模化了。

这就是组织需要引入第三个阶段的地方：审查（inspection）——即通过自动化检查，确保交付的内容在到达生产环境之前符合你的标准。在 CI/CD 中运行的云端智能体可以强制执行你关心的雕琢标准：命名规范、抽象模式、测试要求、安全模式以及文档质量。

可以将其视为将你最佳的雕琢实践编码进审查每一个 PR 的智能体中。你原本在代码审查中捕捉到的标准，现在可以被系统性地捕获。组织可以一次性定义什么是“雕琢精良”——清晰的命名、恰当的抽象、有意义的测试——并让这些标准在 PR 层面自动执行。

这并非要取代人类的判断，而是为了实现其规模化。你的资深工程师专注于架构和设计决策，而自动化检查则处理代码在合并前是否经过了妥善雕琢的系统性验证。

CLI 让它能运行。你的雕琢让它变得正确。任务控制（Mission Control）让它保持一致。