Vibe Coding 再次被证明“被吹得有点过了”！
过去一年，自前 OpenAI 创始成员 Karpathy 引燃“Vibe Coding”概念后，整个 AI 编程赛道以十倍速热闹起来。LLM 厂商们以“肉眼都快分不清”的速度在编程能力上进行疯狂代际提升，智能编程也从最初的“超级自动补全”进化到了 Agentic 的自主编程时代。
如今，关于 Vibe Coding 的流行叙事变成了：只要“跟着感觉走”，把需求丢给 AI，剩下的交给模型自动完成。
然而回到真实环境中，AI 编程到底有多强？真正的软件开发人员，真的是这么干的吗？
最近，一项针对职业软件工程师的研究，给出了一个非常不“网感”的答案：
几乎没有。工程师在意的，从来不只是快！
一项不太“酷炫”，但很硬核的研究
这项研究的论文标题直接点明主题：
《Professional Software Developers Don’t Vibe, They Control》。
专业软件开发者们从不 Vibe，他们控制！
这项研究来自加州大学圣地亚哥分校与康奈尔大学的软件工程与人机交互研究团队。作者中包括软件工程与程序分析领域的资深教授 Sorin Lerner，以及长期研究“工程师如何真实工作”的开发者工具学者。
这些软件工程正统学派的研究者，打算从工程实践出发，让 AI 编程工具做了两件更难、也更有价值的事：
- 观察 13 位资深工程师 在真实项目中如何使用 AI 编程工具。
- 调研 99 位职业开发者 的实际使用习惯与决策逻辑。
这些工程师都是拥有 3 至 25 年经验的在职专业人士，他们使用的不是实验题或演示项目，而是正在维护、随时可能出问题的真实代码库。
调查方面，每次研究会话包括两部分：45 分钟的观察和 30 分钟的半结构化访谈。研究者通过 Zoom 进行研究，记录参与者的屏幕和音频以供分析。会话时间从 2025 年 8 月 1 日持续到 10 月 3 日。
调研覆盖了主流的 AI 编程工具，如 Claude Code、Codex、Cursor、Windsurf、GitHub Copilot、Kilo Code、Terragon 等。值得注意的是，Sonnet 和 GPT-5 是当时最主流的选择。（由于研究时间在 8 月至 10 月，当时尚未推出最新一代的前沿模型。）
研究真正想回答的核心问题只有一个：
当“写代码”这件事真的交给 AI，职业工程师是如何保持控制的？
第一个结论：他们几乎不“放手”
如果你期待看到“工程师已完全将工作交给 AI”的画面，这篇论文可能会让你失望。
论文在 Results 部分关于“控制软件设计与实现”的分析中 指出，工程师极少让 AI 智能体长时间自主执行任务。即便智能体给出了完整的多步计划，开发者通常也只允许其逐步执行，并在每一步之后检查代码变更、运行测试，再决定是否继续，从而始终将节奏与决策权掌握在人类手中。
研究中观察到的真实情况是：
- 工程师 很少 让 AI 自行连续执行任务。
- 即便面对一个 50 或 70 步的完整计划，他们通常也只让 AI 一次执行 1-2 步。
- 每一步执行完后，都会停下来：查看代码、对比差异、运行测试、判断是否继续。
也就是说，AI 在干活，但节奏掌握在人手里。
在与智能体协作时，资深开发者通过在提示与规划中提供清晰的上下文和明确的指令，来掌控软件的设计与实现，并且一次只让智能体处理少量任务。
除了提示工程之外，资深开发者还会借助既有的软件开发最佳实践（例如验证与版本控制），并结合自身的工程经验，在监督之下将智能体生成的改动纳入代码库。
研究者直接点破了“vibe coding”的误区：那种完全不看实现、只等结果的用法，在职业开发中几乎不存在。
工程师在意的，从来不只是“快”
这项研究中一个非常反直觉的数据是：在问卷中，提到“软件质量”的工程师，比提到“效率提升”的还多。
论文在 Results 的 RQ1（使用动机）部分 指出，在问卷调查中，有 67 位工程师 在使用 AI agent 时首先关注软件质量属性，而只有 37 位 提到效率提升等非质量因素，这与“agent 主要用于提效”的直觉认知形成反差。
他们反复提到的关键词包括：
- correctness（正确性）
- maintainability（可维护性）
- readability（可读性）
- architectural clarity（架构清晰度）
换句话说，AI 能不能写得快，并不是第一位的。
能不能写得“对”，才是关键。
这也解释了为什么工程师会频繁打断 AI 的自动执行——因为一旦代码偏离预期，后续的修正成本会指数级上升。在职业工程领域，“之后再改”从来不是一个轻松的选项。
Prompt 不是聊天，是“规格说明”
此外，论文还揭露了一个关于开发者控制 agent 行为中被很多人低估的事实：
资深工程师写的 prompt，看起来一点也不“自然”。
prompt 样本示例
他们的 prompt 往往很长，包含大量上下文：
- 文件路径
- 接口定义
- 现有模块结构
- 明确的输入输出约束
- 清晰的边界说明
他们这样做的目的，并不是教 AI 怎么写代码，而是只有一个：把不确定性压到最低。
研究者给了一个很到位的总结：
Prompt engineering，本质上就是一种软件工程沟通能力。
这也意味着，AI 并没有消灭工程经验，而是把工程经验转移到了“如何描述问题”这一步。
AI 最擅长的，并不是“思考”
在对近 200 个真实开发任务的分析中，研究给出了一个非常清晰的任务适配分界线。
适合交给 AI 的任务：
- 样板代码生成
- 明确规则下的实现
- 测试代码
- 小范围重构
- 已有方案的翻译与扩展
不适合交给 AI 的任务：
- 系统架构设计
- 复杂业务建模
- 跨模块决策
- 高风险变更
一句话总结就是：AI 擅长执行清楚的事情，不擅长判断复杂的事情。而后者，恰恰是职业工程师最核心的价值所在。
所谓“全自动写软件”，并不符合工程现实
这项研究可以说从实践工程的角度戳破了“AI 全自动开发”的幻想。
在流行叙事中，AI Agent 往往被描述为“自主工程师”：能规划、能执行、能自我修正。
但在真实工程场景中，工程师更希望的是：可控的、可暂停的、可验证的、可随时推翻的 Agent。
换句话说，他们要的是“工具”，不是“替代者”。
其二，这篇论文还隐含了一个非常值得注意的判断：
AI 没有让工程师变得多余，而是迫使工程师回到更“负责”的位置。
未来更有价值的工程师，可能不再是写代码最快的，或 API 最熟的。
而是：能拆解问题的、能定义清晰规格的、能判断代码是否“值得合并”的。
最重要的是，能对系统结果负责的。
可以确定的是——AI 写得再多，责任也不会自动消失。
真正的职业工程师，并没有把方向盘交给 AI，他们只是换了一种方式来控制代码的输出。“凭感觉”编程中的“感觉”，实际上更多是实际积累的“开发经验”。
这，或许才是 AI 编程真正进入工程世界的标志。
参考文献：
– https://arxiv.org/pdf/2512.14012
关注“鲸栖”小程序，掌握最新AI资讯
本文来自网络搜集，不代表鲸林向海立场，如有侵权，联系删除。转载请注明出处：http://www.itsolotime.com/archives/16442