【AI论文科普】专业开发者不vibe 而是Control
作者：微信文章2025年12月，arXiv上出现了一篇很有意思的论文。
标题很直接：《Professional Software Developers Don't Vibe, They Control》专业开发者不是"感觉对了就行"，而是要控制。
这篇论文研究了一个很现实的问题：当AI代理真正进入专业开发者的日常工作，他们到底怎么用？
这个研究怎么做的？
2025年8月到10月，研究团队做了一件很有意思的事。
他们找了13个程序员，最短的有3年经验，最长的干了25年。然后通过Zoom，看着这些人的屏幕，听他们边写代码边说话。
不是让他们做个demo，而是真刀真枪的工作。有人在写公司生产环境的代码，有人在调Bug，有人在做自己的副业项目。就像你平时写代码一样，只是旁边多了两个研究员，全程盯着你的屏幕，听你嘀咕。
45分钟观察，30分钟访谈。每个人75分钟。
研究员想知道：这些老程序员用AI的时候，到底在想什么？他们怎么下prompt？什么时候接受AI的代码？什么时候直接重写？
这是第一件事，深度观察。
第二件事，他们做了个更大规模的调查。
但不是随便在网上发个问卷链接。他们从GitHub上，精准定位了4000多个开发者——这些人过去一年里，提交过Cursor、Claude Code这些代理工具的代码，或者给相关项目提过issue，或者star过"agentic"标签的仓库。
换句话说，都是真正用过AI代理写代码的人。
研究团队给这4000多人发了邮件，每个人一个独立的调查链接。最后249人响应，经过筛选（至少3年经验，至少18岁，用过代理工具），剩下99个有效回答。
这99个人，被问了一个问题："回想一下你上次用AI写代码，当时在做什么？"
然后，问卷让他们回答：平时写代码最在乎什么？用AI时最在乎什么？哪些任务会用AI？哪些绝对不用？
这个设计很聪明。不是问"你觉得AI有用吗？打分1-5"，而是让你回忆具体场景，说出真实感受。
13个人的深度观察，加上99个人的广度验证。这不是实验室测试，是跟着专业开发者看他们在真实项目里怎么用AI。
论文里设计的问题：
调查的开发人员分布：
开发者喜欢使用的AI工具：
AI代码需要修改概率 / 对任务的适用性 / 使用 Agent 的愉悦度
核心发现：控制，而不是依赖
论文的核心发现可以用一句话概括：
专业开发者把AI当工具，但绝不交出主导权。
experienced developers value agents as a productivity boost, they retain their agency in software design and implementation .
具体来说：
1. AI是生产力工具，不是决策者
开发者用AI来提高效率，但软件设计和实现的决策权牢牢握在自己手里。AI可以帮你写重复代码，可以帮你查文档，可以帮你生成测试用例。但架构怎么设计、接口怎么定义、性能怎么优化——这些核心决策，开发者不会让AI做主。
2. 质量标准不能降
论文发现，开发者坚持基本的软件质量属性（ insistence on fundamental software quality attributes ）
代码可读性、可维护性、性能、安全性——这些标准不会因为"AI生成的"就降低。AI生成的代码，开发者会仔细审查。不符合标准的，直接重写。
3. 有策略地控制AI
开发者不是被动接受AI的输出，而是主动采用各种策略来控制AI的行为。
employing strategies for controlling agent behavior leveraging their expertise
比如：
精心设计prompt，引导AI生成符合项目规范的代码
分步骤让AI完成任务，而不是一次性交给它
用自己的专业知识验证AI的输出，发现问题立即纠正
4. 积极但谨慎
开发者对AI持积极态度，但这种积极是建立在有信心弥补AI不足的基础上的。
experienced developers feel overall positive about incorporating agents into software development given their confidence in complementing the agents' limitations
他们知道AI会犯错，知道AI有局限，但他们相信自己能识别这些问题并修正。
沃顿商学院教授 Ethan Mollick 说的那句
"我可以告诉你，没人知道任何事。"（I can tell you, no one knows anything.）
连顶级AI实验室都不知道AI真正有用的场景。这篇论文恰好证实了这一点：即使是2025年，专业开发者也在摸索如何正确使用AI。
没有标准答案，没有最佳实践，每个人都在试错。
但专业开发者的优势在于：他们有足够的专业知识来控制试错的风险。因为"有用"不只是技术能力，还需要人的控制和判断。
AI可以生成代码，但代码是否符合项目需求、是否可维护、是否安全——这些判断需要人来做。
他们具体怎么控制AI？
说"控制AI"很容易,但具体怎么控制？论文通过观察13个开发者的真实工作,记录了他们的每一个prompt、每一次代码审查、每一个决策。
这些细节,才是最有价值的部分。
策略1: 小步快跑,绝不放手
论文发现了一个数据：开发者平均每次只让AI处理2.1个步骤。
即使有人制定了70步的大计划,他们也只会让AI一次执行5-6步,然后停下来验证,再继续。为什么？因为AI容易"跑偏"。
一个开发者在prompt里专门写了一句：
"Please do just step 1 now"（请只做第1步）
他担心AI会"热心过度",把后面的步骤也一起做了,结果可能偏离预期。这就像带小孩过马路,你不会说"自己走到对面去",而是"先看左边,再看右边,然后跟着我走"。控制的本质,就是把大任务拆成小任务,每一步都在你的掌控之中。
策略2: Prompt要"清晰、具体、详细"
论文分析了所有观察对象的prompt,发现专业开发者的prompt包含10种上下文信息：
UI元素（按钮、输入框、布局）
技术术语（API名称、数据类型）
领域对象（业务实体、数据模型）
参考文件（要修改的文件路径）
特定库（要使用的npm包、框架）
预期行为（点击后应该发生什么）
新功能需求（要实现的功能描述）
现有计划中的步骤（引用之前的计划）
要修改的文件（具体文件名）
请求的目的（为什么要这样做）
论文展示了一个真实案例:
"我需要修改UserProfile.tsx文件。当用户点击'编辑'按钮时,应该弹出一个模态框,包含name和email两个输入字段。数据类型是User接口。请只做第1步:创建模态框组件。"
这个prompt包含了:
文件名(UserProfile.tsx)
UI元素(按钮、模态框、输入字段)
数据类型(User接口)
预期行为(点击后弹出)
明确范围(只做第1步)
这不是随便说一句"帮我做个编辑功能",而是像写技术文档一样精确。
43个调查对象也强调了同样的策略:
"我的prompt总是非常具体,包含尽可能多的信息——文件名、函数名、变量名、错误信息等。我专注于确保prompt有清晰的陈述,告诉LLM我要它看什么、做什么。小而具体的修改。"
策略3: 代码审查,一行都不放过
论文发现,9个观察对象(69%)会仔细审查AI生成的每一行代码。
不是"看起来没问题就行",而是逐行检查:
这段代码符合项目规范吗？
有没有性能问题？
有没有安全隐患？
可维护性如何？
有5个人会把审查结果反馈给AI,让AI保持上下文一致:
"我喜欢一直和AI对话,因为这样能保持所有内容在聊天上下文里...如果我在编辑器里改了什么,我需要告诉它我改了,因为它没看到。"
另外4个人会直接手动修改代码,而不是让AI重新生成:
"我觉得这样长远来看更省时间,也避免了重新解释一遍。"
这种审查不是"不信任AI",而是"对代码质量负责"。
策略4: 用专业知识纠正AI
论文发现,11个观察对象和65个调查对象都强调:软件工程专业知识是控制AI的关键。
AI会犯错,会产生幻觉,会生成不符合最佳实践的代码。
但专业开发者能识别这些问题:
"你仍然需要自己思考...评估LLM告诉你的是不是好方法。"
"首先要理解编程,然后再使用AI。"
"我的观察是,花时间理解已经生成的代码,会极大地帮助后续工作。"
有些开发者甚至会"教育"AI:
有些开发者会手动修改代码,展示"正确的写法",让AI学习
有些开发者把自己的编码规范写成"用户规则",让AI遵守
有些开发者会拒绝AI想安装的依赖包,因为他知道不需要
这就像师傅带徒弟,不是徒弟说什么就是什么,而是师傅用经验纠正徒弟的错误。
策略5: 传统工程实践依然重要
论文发现,开发者用传统软件工程实践来控制AI:
测试驱动开发:
5个人在用AI后,反而更愿意写测试
有开发者说:"现在测试覆盖率比以前高,因为它成了工作流的一部分。"
AI可以帮你生成测试用例,但你要确保测试真的有效
版本控制:
多个人用git记录AI的每次修改
出问题了,直接回滚
用多个Agent时,用git merge合并不同Agent的工作
代码审查工具:
用linter检查代码规范
用测试套件验证功能
用debugger追踪问题
这些"老派"的工程实践,在AI时代不仅没有过时,反而更重要了。
策略6: 监控AI的"思考过程"
有些开发者会在AI工作时,盯着它的"思考过程"(thinking process)。
AI在生成代码前,会先"思考"要做什么。
开发者会看这个思考过程,判断AI是否理解了任务:
如果AI的思路对了,就让它继续
如果AI的思路偏了,立即打断,重新引导
这就像你在教学生解题,不是等他写完答案再批改,而是看他的解题思路,发现错误立即纠正。
一个真实案例: React迁移
论文里有个很精彩的案例。
一位开发者用AI完成了一个大型React迁移项目,3天完成了原本需要2周的工作。他的做法很有代表性：
自己制定详细计划- 把迁移任务分解成几十个小步骤
每次只让AI做一步- 比如"迁移UserProfile组件"
每步都测试- 确保功能正常再继续
仔细审查代码- 确保符合项目规范
用git记录每次修改- 出问题立即回滚
最终的结果令人惊讶：
"三天结束时,我们没发现一个bug,没发现一个设计错误。"
这不是"vibe coding",这是"工程化的AI使用"。
哪些任务适合用AI？哪些不适合？
这可能是论文最有实用价值的部分。研究团队分析了99个调查对象提到的189个具体任务,归纳成89个任务类型。
然后,根据开发者的反馈,把这些任务分成三类:
适合用AI(支持:反对 ≥ 2.5:1)
有争议(支持:反对在2.5:1到1:2.5之间)
不适合用AI(支持:反对 ≤ 1:2.5)
这是一份来自真实战场的"AI使用指南"。
适合用AI的任务
1. 样板代码和脚手架 (26:0)
这是AI的强项。
"AI帮我写那些我们本来就不想写的样板代码。"
"AI很擅长搭建脚手架。"
比如: 创建新的React组件模板、生成数据库模型的CRUD代码、初始化项目的文件夹结构
2. 编写测试 (19:2)
很多开发者发现,AI写测试特别好用。
"让AI起草测试,我再完善,节省了很多时间。"
"AI写已有代码的通用测试,效果出奇地好。"
3. 编写文档 (20:0)
这个任务几乎没有反对声音。
AI可以 : 根据代码生成API文档、写README、生成代码注释
4. 简单重构 (14:0) 和一般重构 (18:3)
"我经常说'重构这个函数'。"
比如: 提取重复代码、重命名变量、简化复杂函数
5. 简单调试 (12:3)
如果问题明确,AI很有用。
"当我能指向一个具体的失败测试时,AI修复bug非常有效。"
"AI很擅长分解令人困惑的堆栈跟踪,建议可能的原因。"
6. 小而直接的任务 (33:1)
"AI移除了那些单调乏味的工作。"
7. 原型开发 (12:0)
"用LLM构建框架/原型(比如2000行代码),很直接,甚至可以vibe coding。"
"我用AI做一次性的demo和实验。"
8. 项目初始化 (10:4)
"AI在从零开始构建东西时表现很好,直到变成一个小应用。"
特别是用主流框架时:
"像Tailwind CSS / Radix UI这样的主流框架,AI表现更好。"
9. 遵循明确定义的计划 (28:2)
这是AI的核心能力。
"一旦计划存在,AI就能工作得非常好,我只是惊讶于它做出的伟大成果！"
但前提是:
"如果给出清晰的指令,它们会完成我的工作。"
"如果你不够具体,AI会跑偏,你花在纠正上的时间比节省的时间还多。"
有争议的任务
1. 架构设计和高层规划 (13:23)
这是最有争议的任务。
反对派:
"系统设计！我从不信任LLM处理系统性问题。"
"架构方面,我很少用AI,除了用来做研究。"
"如果天真地委托给Agent,很多架构决策会反噬你。这归根结底是领域专业知识,以及在构建初始基础设施前给Agent提供严格要求。"
支持派:
但也有人用AI做架构设计,只是不会完全委托:
"我不喜欢用AI做高层规划,但我确实用。它帮我避免盲点。但需要大量来回讨论,所以我不会让Agent在没有我输入的情况下工作。"
"我和Gemini 2.5 Pro讨论设计/架构,然后用Claude Code实现...我发现先做设计/架构,然后让LLM输出Markdown源代码(.md文件)...包含设计细节,非常有效。"
有开发者说,当他需要设计系统架构时,AI是"救星",因为可以让AI画出系统上下文图,帮他可视化系统结构。
结论: AI可以辅助架构设计,但不能替代人类决策。
2. 一般调试 (12:8)
简单调试适合AI,但一般调试就有争议了。
"简单bug修复可以,但bug修复不行。"
"LLM经常制造的问题比它发现的还多。"
"我用AI调试,但它们会陷入调试循环。"
"有清晰复现步骤的bug修复,AI很好用。"
结论: 取决于bug的复杂度和你的prompt质量。
不适合用AI的任务
1. 业务逻辑和需要领域知识的任务 (2:15)
这是最明确的"不适合"。
"我避免让AI处理重逻辑或业务规则部分。"
"非常特定的业务逻辑,需要大量上下文,不适合AI。"
为什么？因为业务逻辑需要深入理解业务需求、用户场景、边界条件。AI没有这些领域知识。
2. 复杂任务 (3:16)
"我的用例很复杂,AI在大部分时候表现很差,最终没完成任务。"
"如果函数复杂(需要多个依赖),Agent倾向于产生幻觉。"
"如果任务复杂,比如把工作目录的大量修改拆分成一堆小提交,AI会卡住并做坏事。"
3. 复杂重构 (1:4)
简单重构可以,但复杂重构不行。
"任何对项目结构的核心修改,我不用AI。"
"复杂的、多步骤的、跨代码库边界的协调修改,我避免用AI。"
4. 无法一次性生成完美代码 (5:23)
"AI几乎在所有事情上表现都很好。只是不能一次性搞定。"
"有时Agent生成的代码很乱。"
"过度工程化,不够细节意识,不断重复自己。"
5. 集成现有代码/遗留代码 (3:17)
"AI经常为核心库里已有的函数写自定义代码。"
"AI很难确保功能在整个架构中端到端集成。"
"如果我想探索或理解其他遗留代码库,我的体验不太好。"
"处理遗留或高风险代码时,我宁愿去StackOverflow。"
6. 性能关键代码 (3:9)
"高性能结构设计,我不用AI。"
"高负载场景的性能优化,AI表现很差。"
"AI倾向于写性能较差的代码。"
7. 安全关键代码 (2:5)
"高风险决策、没有保障的敏感数据处理等任务,我避免用AI。"
"实现需要高性能或安全的关键组件时,我不用AI。"
8. 人类决策不可替代 (0:12)
没有一个人说AI可以替代人类决策。
"尽量成为领域专家,如果你是软件架构师,你知道能改进模型结果的东西,你是飞行员,模型是副驾驶,你需要和它们分享你的专业知识。"
"对实施Agent生成的计划/选项/修改的决策权在我手里——我会花时间思考其影响,然后才点赞。"
"你需要掌握某些技能和判断力,来验证生成的代码是否正确。"
"我用AI辅助做所有事情,但从不让Agent完全自主——我总是阅读输出并引导方向。"
成功案例: React迁移
一位开发者用AI在3天内完成了React迁移,原本需要2周。
成功的原因很明确：
React是主流框架,AI训练数据充足，迁移是"脚手架"性质的工作,有明确模式，开发者制定了详细计划, 分步执行，每步都测试验证。
失败案例: 动画设计
另一位开发者想用AI实现一个动画网页横幅的视觉效果。但结果并不理想：
"我试了,不知道,30次...无论我怎么prompt,就是达不到我想要的效果。"
视觉设计是主观的,难以用语言精确描述， AI不理解"美感"，需要大量来回调整,效率反而低。
所以，AI适合有明确标准的任务,不适合需要主观判断的任务。
对我们意味着什么？
1. AI不会取代专业开发者，但会改变工作方式
论文的发现很清楚：专业开发者的价值在于控制和判断，而不是敲代码。AI可以帮你敲代码，但不能替你做决策。未来的开发者，需要的是更强的架构设计能力、更好的代码审查能力、更深的领域知识。
2. "会用AI"是一种专业技能
论文发现，开发者采用各种策略来控制AI。这意味着，"会用AI"本身就是一种需要学习的专业技能。不是简单地把任务扔给AI，而是知道什么时候用、怎么用、如何验证。
3. 质量标准不能因为AI而降低
这可能是最重要的一点。AI生成的代码，不是"能跑就行"，而是要符合专业标准。AI是工具，不是借口。
4. 保持主导权
论文标题说得很清楚：Don't Vibe, Control。不要"感觉对了就行"，要主动控制。这不只是对AI的态度，也是对自己职业生涯的态度。
写在最后
2025年，AI代理已经进入了专业开发者的日常工作。但这篇论文告诉我们：AI没有改变软件开发的本质。好的软件，依然需要好的设计、好的架构、好的代码质量。AI只是让我们有更多时间专注于这些真正重要的事情。
专业开发者的价值，不在于敲代码的速度，而在于：
知道什么样的代码是好代码
知道如何设计可维护的系统
知道如何控制AI，而不是被AI控制
正如论文标题所说：Don't Vibe, Control。不要"感觉对了就行"，要主动控制。这是专业开发者和业余爱好者的区别。
所以 ，你在用AI写代码时，是"感觉对了就行"，还是主动控制？
参考资料
Ruanqianqian Huang, Avery Reyna, Sorin Lerner, Haijun Xia, Brian Hempel. "Professional Software Developers Don't Vibe, They Control: AI Agent Use for Coding in 2025" arXiv:2512.14012 (2025年12月16日)https://arxiv.org/abs/2512.14012
Ethan Mollick在CNBC峰会发言https://www.cnbc.com/2025/10/07/generative-ai-knowledge-learning-jobs-education-skills-wharton-ethan-mollick.html
Dwarkesh Patel博客 - Thoughts on AI progress (2025年12月)https://www.dwarkesh.com/p/thoughts-on-ai-progress-dec-2025
Ilya Sutskever访谈 - The Dwarkesh Podcast (2025年11月25日)https://www.dwarkesh.com/p/ilya-sutskever-2
点击原文 可以直接下载 原版论文去看！
页:
[1]