#开发者角色转变

avatar
宝玉
18小时前
研究 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 的风险吗？很少 。人才培养的速度，远远落后于技术发展的速度 。 论文地址：
AI编程工具激战：Claude Code、Gemini Cli崛起· 1087 条信息
#Vibe Coding #大语言模型 #AI编程 #开发者角色转变 #AI安全