研究 Vibe Coding 都能写论文了，来自中科院、杜克大学等的这篇《基于大语言模型的Vibe Coding综述》，还是花了点功夫把 Vibe Coding 相关的论文、信息梳理了一遍，有一些值得看的内容。

【一】
首先是对 Vibe Coding 的定义，这篇论文把 Vibe Coding 描述成一个“三方关系” （参考图1）：

1. 人类开发者：不再是代码的直接创作者，更像是需求的提出者、方向的把控者和最终质量的仲裁者 。你的主要工作是清晰地表达意图，并判断 AI 做出来的东西“对不对”。

2. 软件项目：不再仅仅是代码库，而是一个包含代码、数据、文档、领域知识等各种信息的“上下文空间” 。AI 需要从这里获取信息来理解任务。

3. 编程智能体 (AI)：负责具体的编码、修改、调试工作，它听从人类的指令，并受项目上下文的约束 。

论文也提到了 Vibe Coding 带来的问题：经验丰富的开发者在使用高级AI工具时，完成任务的时间反而增加了19% ！

【二】
为什么经验丰富的开发者 Vibe Coding 时间更长？不完全是模型能力不够，还有其他原因：

1. 系统性的上下文工程 (Context Engineering)：你得知道怎么把项目信息（代码库、文档、规范）有效地“喂”给 AI 。AI 不是凭空写代码，它需要知道你的项目是怎么回事 。光会写漂亮的提示词 (Prompt) 是不够的，管理上下文信息才是核心技术 。

2. 反馈循环 (Feedback Loops)：不能简单地把活儿全丢给 AI。怎么提要求？怎么给反馈？什么时候该介入？这些协作方式直接影响效率和质量 。

3. 基础设施 (Infrastructure)：你需要能安全执行 AI 代码的“沙盒” ，能跟 AI 流畅对话、共享项目信息的交互界面 ，甚至需要能自动化测试、部署 AI 代码的平台 。没有这些基础设施，AI 就是“带镣铐跳舞” 。

【三】
五种 Vibe Coding 开发模式 ：

1. 无约束自动化 (UAM)：完全放手让 AI 干，你只看最终结果 。速度快，风险高，适合做一次性原型或小工具 。有点像软件工程里的“快速应用开发”（RAD） 。

2. 迭代式对话协作 (ICCM)：你和 AI 像结对编程一样 ，AI 写，你审，反复沟通迭代 。质量有保障，但需要你深度参与 。

3. 规划驱动 (PDM)：你先做好设计、定好规范（比如写好技术文档、规则文件、实施计划） ，然后指导 AI 按计划执行 。有点像传统的“瀑布模型” ，但 AI 的快速迭代让它更灵活 。

4. 测试驱动 (TDM)：你先写好测试用例，定义清楚“怎样算对” ，然后让 AI 去写能通过测试的代码 。用机器验证代替人眼审查 。这是传统“测试驱动开发”（TDD）的应用 。

5. 上下文增强 (CEM)：这不是一个独立流程，而是一种“增强插件” 。通过检索增强生成（RAG）、代码库索引等技术，让 AI 能更好地理解项目现有情况，生成更贴合项目风格和规范的代码 。它可以与其他四种模式结合使用 。

【四】
Vibe Coding 的最佳实践——把 Agent 当员工而不是工具

很多一直把 AI 当成一个“超级自动补全”，一个更聪明的 Stack Overflow，我们把它当成一个“工具”，而实际上，它是一个智能体（Agent）。

“工具”和“Agent”的区别是什么？

- 工具（比如锤子、编译器）：它帮你完成你正在做的事。你100%掌控它。
- Agent（比如一个初级程序员）：它能自主完成任务。你需要给它分配任务、给它“记忆”（上下文）、给它权限，并对它进行“管理”和“审查”。

如果试图用“使用工具”的方式，去“管理一个员工”，结果就是会带来两个极端：

- 一个极端是盲目接受：AI 写的代码，语法漂亮，看着很对。你“Vibe”一下，直接提交。结果生产环境崩了。你大骂“模型产生了幻觉”，而真正的问题是，你跳过了必要的检查环节： 代码审查、自动化测试。

- 一个极端是过度怀疑：你根本不信它，它写的每一行你都要重写，这同样影响效率。

这特别像那些管理水平不怎么样的 Engineering Manager：要么对员工（AI）完全放任不管，要么事必躬亲地为管理。

最佳实践是在关键节点设置检查站，自动化验证流程，但在过程中放权。就像一个新员工入职，你不会直接让他们在生产环境上更新代码，而是会有配套的流程和环节保障。

【五】
开发者的角色正在发生根本性转变。你不再仅仅是代码的生产者，你的核心工作变成了：

1. 意图阐述与提示工程：把复杂需求翻译成 AI 能理解的清晰指令 。

2. 上下文管理：精心挑选和组织信息（API 文档、代码片段、设计规范），喂给 AI，限制它的“自由发挥”，确保方向正确 。

3. 系统级调试：当 AI 生成的系统出问题时，重点不再是逐行 GDB，而是从系统行为层面去推测、定位问题，然后引导 AI 去修复 。

4. 架构监督：AI 负责实现细节，你得把握整体架构，确保项目的概念完整性和长远健康 。

5. 质量验证与治理：设计测试用例，利用自动化工具验证 AI 的输出，管理 AI 的权限，追踪代码来源 。

简单说，你的价值从“写好代码”变成了“用好 AI 来写好代码”。这不仅仅是技能的增加，更是一种思维模式的彻底转变 。

【六】
Vibe Coding 带来的挑战：安全、可靠性、监管，以及……我们自己

1. 代码可靠性和安全性：AI 可能从训练数据里学到并复现各种 Bug 和安全漏洞 。只看“Vibe”不看代码，无异于“盲驾” 。我们需要新的自动化工具和流程来实时监控、验证 AI 生成的代码 。手动代码审查根本跟不上 AI 的产出速度 。

3. 大规模监管：当 AI 智能体能自主修改、部署代码时，如何有效监督它们？如何防止一个错误像病毒一样扩散？如何追踪责任？ 。现有的管理和审计方法都过时了 。我们需要能与 AI 能力同步扩展的监管架构 。

3. 人的因素：开发者需要转变思维模式 ，学习新技能 。团队协作方式需要调整 。更重要的是，如何建立对 AI 恰当的信任度——既不盲从也不过度怀疑 ？

4. 教育脱节：现在的计算机教育体系，有教你怎么“指挥”AI 写代码、怎么设计 AI 的工作流、怎么评估 AI 的风险吗？很少 。人才培养的速度，远远落后于技术发展的速度 。

论文地址：https://t.co/yq0Pr2gD6W

点击图片查看原图

点击图片查看原图

点击图片查看原图