#大语言模型

宝玉
2周前
研究 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 的风险吗?很少 。人才培养的速度,远远落后于技术发展的速度 。 论文地址:
Y11
1个月前
宝玉
2个月前
转译:为什么大语言模型无法真正构建软件 作者:Conrad Irwin 我花了大量时间做的一件事就是面试软件工程师。这显然是项艰巨的任务,我不敢说自己有什么绝招;但这段经历确实让我有时间去反思,一个高效的软件工程师究竟在做什么。 软件工程的核心循环 当你观察一个真正的行家时,你会发现他们总在循环执行以下几个步骤: * 构建一个关于需求的心理模型。 * 编写(希望如此?!)能够实现需求的代码。 * 构建一个关于代码实际行为的心理模型。 * 找出两者之间的差异,然后更新代码(或需求)。 完成这些步骤的方式有很多种,但高效工程师的过人之处,就在于他们能够构建并维持清晰的心理模型。 大语言模型表现如何? 平心而论,大语言模型在编写代码方面相当出色。当你指出问题所在时,它们在更新代码方面也做得不错。它们还能做所有真人工程师会做的事:阅读代码、编写并运行测试、添加日志,以及(大概)使用调试器。 但它们无法做到的是,维持清晰的心理模型。 大语言模型会陷入无尽的困惑:它们会假设自己写的代码真的能用;当测试失败时,它们只能猜测是该修复代码还是修复测试;当感到挫败时,它们干脆把所有东西删掉重来。 这与我所期望的工程师特质恰恰相反。 软件工程师会边工作边测试。当测试失败时,他们可以对照自己的心理模型,来决定是修复代码还是修复测试,或者在做决定前先收集更多信息。当他们感到挫败时,可以通过与人交流来寻求帮助。尽管他们有时也会删掉一切重来,但那是在对问题有了更清晰理解之后才会做出的选择。 但很快就行了,对吧? 随着模型能力越来越强,这种情况会改变吗?也许吧??但我认为这需要模型在构建和优化方式上发生根本性的变化。软件工程需要的模型,不仅仅是能生成代码那么简单。 当一个人遇到问题时,他们能够暂时搁置全部的上下文,专注于解决眼前的问题,然后再恢复之前的思绪,回到手头的大问题上。他们也能够在宏观大局和微观细节之间自如切换,暂时忽略细节以关注整体,又能在必要时深入研究局部。我们不会仅仅因为往自己的“上下文窗口”里塞进更多词语,就变得更高效,那只会让我们发疯。 即便我们能处理海量的上下文,我们也知道当前这些生成式模型存在几个严重的问题,这些问题直接影响了它们维持清晰心理模型的能力: * 上下文遗漏:模型不擅长发现被忽略的上下文信息。 * 新近度偏见:它们在处理上下文窗口时,会受到严重的新近度偏见影响。 * 幻觉:它们常常会“幻想”出一些本不该存在的细节。 这些问题或许并非无法克服,研究人员也正在努力为模型增加记忆,让它们能像我们一样施展类似的思维技巧。但不幸的是,就目前而言,它们(在超出一定复杂度后)实际上无法理解到底发生了什么。 它们无法构建软件,因为它们无法同时维持两个相似的“心理模型”,找出其中的差异,并决定是该更新代码还是更新需求。 那么,现在该怎么办? 显然,大语言模型对软件工程师来说很有用。它们能快速生成代码,并且在整合需求和文档方面表现出色。对于某些任务来说,这已经足够了:需求足够清晰,问题足够简单,它们可以一蹴而就。 话虽如此,对于任何有点复杂度的任务,它们都无法足够精确地维持足够的上下文,来通过迭代最终产出一个可行的解决方案。你,作为软件工程师,依然需要负责确保需求清晰,并保证代码真正实现了其宣称的功能。 在 Zed,我们相信未来人类和 AI 智能体可以协同构建软件。但是,我们坚信(至少在目前)你才是掌控方向盘的驾驶员,而大语言模型只是你触手可及的又一个工具而已。