Vibe Coding

最近几年，以 LLM 为主要技术路线的又一轮 AI 浪潮席卷了整个行业，并迅速外溢到与信息技术产业无关的普通民众的日常生活中。快到惊人——甚至可以说是有些吓人的发展迭代，正在迅速叩开传统企业和 C 端用户的大门；给个人和企业用户带来便捷、效率与趣味的同时，也在一些行业和岗位完成技术替代。

作为计算机行业的一个细分领域的从业者、一个前端工程师，虽然我们与真正参与 LLM 研发的算法工程师和数学家相比当然只能算离门口最近的门外汉，但是与行业外的公众相比算是站在岸边离潮头最近的弄潮儿。

要提起我们这些徘徊在 AI 领域门口的其他细分技术领域的信息技术从业者如何看待和使用 AI，有一点是不得不提到的：AI 辅助编程。无论是出于尝试新事物的兴趣和胆量，还是迫于提效和考核的无奈，AI 辅助编程，也就是 Vibe Coding，已经成为了计算机工程师在工作中必须掌握的技能之一。

Vibe Coding 与我

我接触 AI 辅助编程的时间很早——早在三年前 Chat GPT 刚刚火出圈的时候，就尝试将 AI 补全和代码生成引入我的工作流。不过在当时的时间点，AI 的编程能力仍然是不太够看的。LLM 对代码上下文的把控以及 prompt 的理解能力不够强，生成的代码并不能直接用于生产过程中；AI 代码补全也不够快、不够准确，对我完成代码不仅没有太大的提效作用，甚至有些时候还会产生干扰。因此，在本次 AI 浪潮刚刚掀起的时候，无论是出于为产出负责的原则，还是源自对 AI 提效的不信任，对于 Vibe Coding 我都是较为抗拒的。

计算机科学以及产业技术的发展一向是极为迅速的，而在 LLM 上这一点体现得淋漓尽致。短短两三年的时间，AIGC 的可用性得到了火箭般的提升。生成的照片和视频从最早的“鬼画符”变得以假乱真，创作的绘画从早期的低劣涂鸦到现在能够威胁专业插画师的饭碗——自然，代码生成的能力也发生了翻天覆地的变化。得益于更长的上下文窗口以及更精确的指令遵循特性，Vibe Coding 的能力已经完全能满足生产需求。

开发者对于技术的变化和提升是很敏锐的。察觉到 AI 辅助编程能力的快速增长，我再次尝试将 AI 作为我的编程助手。与此同时，作为一家科技巨头，公司的嗅觉也非常灵敏，为我们提供了丰富的 AI 资源并鼓励我们使用 AI 对开发工作进行提效。到现在，我已经在所涉及需求中都或多或少地引入了 Vibe Coding ——老项目保持了相对保守的步伐，通过渐进式引入 AI 代码生成和 AI 驱动测试，逐步完成 AI 转型；新项目的尝试则更为激进，几乎将全部的业务逻辑代码生成和测试工作都交给了 AI，打造出了几乎不含手写代码的“AI 原生应用”。

Vibe Coding 如何生成高质量的代码：十大核心技巧

在 Vibe Coding 过程中的一些思考和经验，或许对正在阅读本文的你有一定的参考价值。

【1】使用 AI IDE 而不是 AI 插件

在 Vibe Coding 过程中，更推荐使用 AI IDE，而不是使用传统 IDE 加上 AI 辅助插件——即使这个 AI IDE 的出品方也推出了插件版本。

AI 辅助插件完全可以使用和 AI IDE 相同的大模型，以此获得相同的编程水平和推理能力。但是这些专为 Vibe Coding 设计的 AI 原生 IDE，对文件和目录的操作权限通常都会高于 AI 编程插件；这就意味着，AI IDE 在阅读项目整体上下文和处理文件和代码的能力方面都会优于插件。

【2】选择合适的 LLM 模型

在当下（2025 年底）这个时间点，主流的 LLM 的编程能力都已经很不错了；但是，选好一个最合适的 LLM 模型仍是 Vibe Coding 过程中非常重要的一环。

一方面，虽然各家的大模型能力都不错，但是总也有个甲乙丙丁。有些模型在编程能力方面一骑绝尘，有些模型对 edge case 的考虑更为周全，还有些模型会有一些体验和交互上的思考。你需要根据你的需求，选择能力最强、最适合你的使用场景的大模型。

另一方面，当然是数据安全合规方面的要求。如果是个人项目或是你拥有团队的技术决策权，那么需要考虑到使用海外大模型存在的数据政策和法规要求；如果涉及到把用户数据作为输入，要警惕个人数据跨境传输风险。如果是企业项目，那么你的 AI 助手的选择还需要遵循企业或团队的数据安全要求，例如使用自研大模型或私有部署的大模型。

【3】明白程序的本质

看到这里的读者，应当是计算机行业从业者——或至少，有一定专业知识的学习者。或许你已经在计算机科学和信息技术的道路上走了很久、很远了；但我想，不管你走了多久、多远，你应该还没有忘记这个学科、这个行业最根源的问题：程序的本质是什么？

基于所处的细分领域的差异以及由此带来的知识体系的不同，每个人都可能给出不同的答案。但我想，这样的定义应该能得到大多数同行的认可——所谓“程序”，小到一个功能最简单、实现最基础的函数，大到功能复杂、代码体量动辄十万、百万行的工业软件，乃至我们这篇文章正在讨论的正不断创造奇迹的 LLM 本身，都可以抽象地定义为：一个输入，执行一系列预定义的行为，得到一个输出。

你可以回忆一下你所写过的每行代码、每个方法以及你所参与过的每个项目，想一想从微观到宏观是不是都符合这个定义。

那么，既然如此，我们使用 AI 辅助编程，其本质就是让一个输入自然语言、输出代码的强大的黑箱程序（LLM 大模型）为我们编写数不清的小程序（实现单一功能的语句和函数），然后组合成一个个的复杂程序（页面或功能模块），最终集成到大型程序（整个项目）中。所以我们要做的，就是对 LLM 说明我们需要编写的程序会有怎样的输入、需要经过怎样的处理、最终预期应该有怎样的输出。 通过定义输入、输出以及中间的行为，我们就能明确定义一个程序。把这作为 prompt 输入给大模型，便能得到符合预期的代码。

【4】给出尽可能详细的描述和指令

上一节中我已经给出了我在 Vibe Coding 实践中使用的最基本范式：用输入、输出与行为三个要素定义我需要生成的代码，并作为 prompt 提供给大模型。但如果你立刻将这一方法付诸实践，或许输出并不尽如人意——生成的代码大概能跑，但与你的预期并不完全一致；此时，使用更详细的描述和指令组成 prompt 往往可以大幅改善这一情况。

例如，如果你只在提示词中说 给我生成一个方法，输入一个数组，快速排序后输出，这当然能让 AI 写一些东西出来，但是写出来的东西大概率并不符合你的需求；如果你的提示词是 帮我生成一个方法，输入一个 number 类型的数组，不改变原数组的情况下按从小到大快速排序，输出一个新的数组，生成结果的可用性会高很多。

再比如，帮我生成一个图片轮播组件，会让你得到一个勉强交差、不太能用的图片轮播；帮我实现一个可以通过 css 控制尺寸、图片以 cover 的填充方式自适应尺寸的轮播组件，还需要有支持传入自定义 css 的 indicator 和 navigator，并可支持通过参数控制是否显示，这样一句看起来啰嗦但对需求描述巨细靡遗的 prompt，能为你快速生成一个可用性极高的轮播组件。

不管是参数类型还是用户行为，不管是函数逻辑还是模块整体功能，不管是输出数据结构还是 UI 布局，这些抽象意义上的“输入”、“行为”和“输出”都可以并且需要尽可能具体的定义以及细化。 通过对输入、输出和行为的详细描述，LLM 能更好地“理解”你的指令意图，并让生成的代码尽可能贴近你的预期。

【5】善用任务拆解和分步

如果你已经开始在你的兴趣项目或是工作实践中引入 Vibe Coding 完成一些简单的任务，并希望加重工作流中 AI 的占比、使之承担更复杂的工作，那么不妨想一想，在没有 AI 辅助编程的年代，作为开发者的你是如何完成大型需求的：

首先，你的产品经理会向你阐释需求，描述 TA 希望你实现的是个什么东西；在你理解了需求之后，你再将具体的、场景化的需求，拆解为抽象的、模块化的任务；最终再将这一个个任务，落实到细分的原子化步骤和一行行代码中。

我想你已经意识到了，任务拆解和分步在传统的编程范式中有非常重要的作用；在 Vibe Coding 中，这也是一种非常实用的技巧。帮我生成一个计算器 是一个简单的且有效的 prompt，但如果你想要精确把控生成的结果，帮我生成一个计算器：你需要实现一个字符串处理程序，将用户输入的用字符串表达的算式解析为可识别的 number 和算符；还需要有算式执行程序，对算式进行计算得到运算结果，或对不合法的输入抛出异常 这样拆解过的、以模块的行为和功能为导向的 prompt 会有更好的效果。如果你再加上 字符串处理程序的第一步是以 LIFO 方式处理字符串中的字符，并以数字为叶节点、算符为内部节点生成 AST；第二步是以深度优先方式对 AST 的叶节点进行自底向上归约的计算，直到最终只剩根节点，即为计算结果 这样详实的步骤，那么 AI 生成的代码将更贴合你的想法。

【6】用参考代码维持良好的编码风格

如果你用 Vibe Coding 用得足够多，想必你已经发现：AI 生成的代码，在单次对话、单个文件中的质量还是不错的，但是把观察维度扩展到多轮对话修改或生成的多个文件就会发现风格不一的问题。有不少人吐槽“AI 终归比不上人类工程师”，认为“AI 只是每天都在不断产生新的屎山”；其实，给予适当的参考，就可以很好地解决这一问题。

要给存量项目添砖加瓦，让 AI 开始开发新的功能或页面前，可以将你之前编写的类似功能的代码文件添加到 prompt 的引用中，并要求 LLM 模仿其代码风格和实现方式；要从零开始搭建新项目，希望 AI 保持稳定的代码风格和质量，可以将 Lint 标准加入你的 prompt。

LLM 是一个神秘的黑箱，LLM 生成的代码也具有不确定性；但是我们可以通过提供参考代码和标准，让结果的确定性高一点、再高一点，尽量维持良好的编码风格。

【7】用参考文档让 AI 跑得更快、更稳

上一节中我们聊了使用参考代码来优化 AI 编码风格的技巧，现在我们再来看看另一种参考——参考文档在 Vibe Coding 工作流中更重要的作用。这里说的参考文档，包含类型定义、技术方案说明和算法描述等一系列技术文档。

让 LLM 输出高质量代码，一种最佳范式是定义好“输入”、“行为”以及“输出”，这在前文中已经详细论述了。那么如何在 prompt 中尽可能做好这个定义呢？使用参考文档会是一种有效且讨巧的方法。相比于在 prompt 中大费周章描述上输入参数和输出返回值类型，一个简单的 ts 定义甚至 proto 协议会更精准；与其在 prompt 狭小的对话框中长篇大论输入你的设想和规划，不如直接附带一个技术方案说明行之有效；甚至因为 LLM 往往有一个知识库截止日期，如果你想要它帮你实现一个最新提出的算法，扔给它算法论文是个不错的主意。在 prompt 中加入参考文档，可以让你的 AI 编程体验变得更为简洁优雅，甚至把“不能”变为“能”。

当然，需要再次提醒的是，参考文档的使用同样要遵循安全合规的要求。对非自研、非私有化部署的 LLM，哪些文件能喂给它、哪些文件不能喂给它，应该经过审慎评估。

【8】巧妙使用多模态输入

在大模型领域，“多模态”早已不是一个新鲜的概念。特别是 to C 的应用中，各种图片生成、视频生成，大家玩多模态输出早已玩得不亦乐乎。但你或许没有注意到，这些针对编程场景优化的 LLM，本身也是具备多模态输入能力，并且可以用多模态输入进一步拓宽能力边界的。

在上一节内容中我们已经提到，参考文档可以成为 prompt 中很重要的一部分；那么，如果你的参考文档并不是纯文本，而是流程图呢？很简单，利用多模态输入能力，直接把流程图也扔给 LLM 即可。很多 LLM 模型是具备理解流程图或算法设计图等以图片表示的过程的能力的，因此你完全可以以非文本形式输入参考文档。

多模态输入在 Vibe Coding 中的另一个重要作用是 UI 的实现与还原。曾经有一段时间，图生代码是前 LLM 时代前端智能非常热点的方向；而在 LLM 已经高度发达的今天，你可以直接把设计稿交给 AI 让它生成样式和布局代码。 这样生成的代码当然仍需经过手动的修改和调整，但至少在我的实践中，其还原的准确度、兼容性及合理性是不弱于传统图生代码方案的。

【9】尽量保持延续的上下文

如果你已经在用 Vibe Coding 了，那么应该会知道上下文窗口是什么、有什么作用，这里就不再赘述了。有一个非常显然、大家应该也日常会遵循的技巧，但我认为它太重要了因此有必要再提一句：如果条件允许，尽量保持延续的上下文。

在 Vibe Coding 中，LLM 如果被要求生成功能复杂的、多文件共享的或是可能产生全局影响的代码，那么它会对整个项目进行梳理和分析，并将所需的知识都储存在上下文窗口中；LLM 帮你生成的代码、遵循的思路或 prompt，也被存在上下文窗口中以备后续使用。可以说，上下文窗口构成了你在 Vibe Coding 过程中与 LLM 的这场“对话”的“记忆”。

如果随意创建新对话、清空上下文，可以理解为对“清除”了 LLM 关于这个项目以及阅读过或编写过的代码的“记忆”。虽然这不是什么绝对意义上的实质性破坏，但你在后续工作中必须让大模型重新熟悉你的项目，甚至重新认识它自己编写的代码，还是会对整体效率和进度有一些负面影响的。

【10】发现方向不对时不吝推倒重来

这一点技巧与上一节的描述背道而驰。是的，在一些必要的场景下，新开一段对话、重启上下文窗口是有积极意义的。

在某些时候，LLM 没有很好地理解你的意图，写出来的代码与你的预期南辕北辙。你已经试过了纠正它，结果收效甚微；你也回滚了若干语句让它重新思考，但是仍不尽如人意。此时，重启一段新会话成为了一种可以考虑的选项。因为，在之前的会话中，你并不知道 LLM 的概率链和思考方向在哪一步出了问题，一步步地倒推回去是低效且不确定。在倒退回滚的过程中，你还需要担心这些步骤已经生成的代码应该如何处理。这种时候，不如开启一段新会话，让 LLM“清空记忆”，重新思考。

当然，具体操作上还是需要有策略的。比如，你在对整个项目进行 Vibe Coding 的过程中，初始会话为 A 会话；在某个时间点，你希望 LLM 帮你实现 X 需求，但是发现 LLM 输出的代码不符合预期且怎么改都改不好，此时你开启了 B 会话，顺利解决了 X 需求；那么：

如果 X 需求是一个影响有限、与其他部分耦合不高的小功能或模块，那么你应该回到 A 会话继续你的工作。此时，A 会话仍保留有之前的完整上下文，只需要阅读 B 会话中生成的一小段代码即可完善它的“临时知识库”。

如果 X 需求是一个颠覆性重构或非常大的修改，那么你可以舍弃 A 会话，在 B 会话继续工作。因为经过颠覆性重构后，A 会话的上下文中保有的知识很多都已过时，需要重新构建“临时知识库”，与 B 会话重新熟悉整个项目的代价相当。

保持谨慎、尽量延续上下文窗口是必要的；但在合适的时机不吝推倒重来，能帮你解决不少问题。

Vibe Coding 时代人类工程师的价值在哪里

LLM 的编码能力越来越强，在我们日常工作中的参与度越来越高。我们在享受工具带来的效率飞速提升同时，也难免感受到来自工具替代的威胁。那么在这个 Vibe Coding 逐渐成为主流的时代，前端工程师——或者可以外延一些，传统的业务开发工程师，价值在什么地方？

人工审查代码仍是必要的

理论层面上，在现阶段，以及可预见的相当长一段时间的近未来内，不管人工智能的能力和表现形式发展到什么程度，它的根基仍然是概率模型——换句话说，LLM 的输出结果不是基于理性思考的推理，而是基于概率链的猜测。或许 LLM 可以在实际测试结果层面做到比人类工程师更高的编码效率和更低的错误率，或许它可以在输出结果时加上合理且详细的“reasoning”，但其本质仍是个概率黑盒，与人相比仍然是 unreasonable 的。

在 Vibe Coding 实践中，即使使用最先进的模型、给出最详尽优化纠偏还是整体需求维度的纠偏，人类工程师的参与仍然不可或缺。

不管是理论意义上对确定性的追求，还是现实需求中作为质量的保证，人工代码审查和人类工程师的工作仍然是必不可少的一环。

往前走：产品思维的重要性在提升

Vibe Coding 的出现让代码的具体实现不再那么重要。最关键的步骤，变成了把具体需求抽象化，然后转换成详细精确的、可实现的 prompt 喂给 AI。

曾经的开发者，承担了把产品需求转换成代码的全流程工作；而在 AI 接手了具体的编码工作之后，开发者就需要往前走一步：用更深刻的产品洞见和在之前职业生涯中积累的专业技术知识，承担产品需求和 LLM 之间的桥梁。在 AI 还不够懂产品的时候，具备产品思维的开发者将成为 Vibe Coding 中需求落地的关键角色。

往深挖：架构能力越来越关键

大型需求的模块拆解、复杂方法的步骤划分，这些对提示词的要求，也是对开发者架构能力的考量。一个很残忍的事实是，只会写代码而不具备架构能力的初级码农，确实将被 AI 淘汰——如果还没有淘汰，那可能只是因为 AI 还不够便宜。但与此同时，具备架构能力的工程师仍然保持着职业生命力。

放在更广的维度上，如何用代码实现一个复杂但经典的算法的能力，已经不那么重要了——或许可以作为考察一名工程师知识储备的参考，但是不具有实际业务价值；但是针对不同需求场景，该用什么基础架构、能用怎样的数据组织形式，要综合使用哪些方法抗住高并发、可以多管齐下什么手段维持高鲁棒，这些依托知识、经验构建起来的对项目设计和宏观架构的把控能力，会成为新的核心竞争力。

保持学习，保持技术敏锐

我们不能忽略了，除了 AI 以外的细分技术领域，也在不断向前发展；逐渐适应 Vibe Coding 的我们，不能因为手写代码越来越少就疏于对新知识的学习或是让技术敏锐度变得钝感。

如果你是前端工程师，那么每年新的 ECMA Script 标准你是否熟悉？CSS 标准委员会的新草案有没有新的 trick 可以做出好看效果的？对于后端工程师而言，k8s 的最新动态你是否有关注？更海量数据和流量冲击下分布式架构有没有新的解决方案？对于客户端工程师来说，最新版本的 Android 有哪些安全性方面的加强和 API 限制？iOS 的新特性是否都已了解？

始终保持学习、保持对自己细分领域最新专业知识的了解和掌握，永远是只有好处没有坏处的。

毕竟，LLM 都有知识库截止日期，而我们人类工程师却是可以不断学习新知识的；如果连我们的“知识库”都要落后于 LLM 的知识库，那怕是要被彻底淘汰了。