> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Vibe编程 vs. Agentic工程 - URL: https://www.hubwiz.com/blog/vibe-coding-vs-agentic-engineering/ - Published: 2026-05-16T13:31:41.000Z - Updated: 2026-10-13T16:11:40.000Z - Description: 我以为我们有一个非常清晰的界限：vibe编程就是你根本不看代码的那种方式。你可能甚至不知道怎么编程。 - Author: admin - Tags: VIBE CODING, #Import 2026-10-14 14:41 我最近和Joseph Ruscio在Heavybit的High Leverage播客节目中聊了AI编程工具：[第9期，与Simon Willison一起探讨AI编程范式的转变](https://www.heavybit.com/library/podcasts/high-leverage/ep-9-the-ai-coding-paradigm-shift-with-simon-willison?ref=hubwiz.com)。以下是一些精彩片段，包括我意识到vibe编程和agentic工程在我自己的工作中已经开始融合的这个令人不安的发现。 播客真正让我享受的一点是，它们有时会推动我大声思考，从而暴露出我之前无法用语言表达的想法。 ## 1、Vibe编程和Agentic工程正在开始重叠 在vibe编程这个词被创造出来几周后，我发表了[并非所有AI辅助编程都是vibe编程（但vibe编程确实很棒）](https://simonwillison.net/2025/Mar/19/vibe-coding/?ref=hubwiz.com)，在文中我坚定地表明了我的观点："vibe编程"和负责任地使用AI编写代码是完全不同的两回事，后者我后来开始称之为[agentic工程](https://simonwillison.net/guides/agentic-engineering-patterns/what-is-agentic-engineering/?ref=hubwiz.com)。 当Joseph提到这两者之间的区别时，我突然意识到，对我来说它们已经没有以前那么泾渭分明了。 说来奇怪，这两件事对我来说已经开始变得模糊了，这让我相当不安。 我以为我们有一个非常清晰的界限：vibe编程就是你根本不看代码的那种方式。你可能甚至不知道怎么编程。你可能是一个非程序员，提出一个需求，然后得到一个东西，如果这个东西能运行，那就太好了！如果不能，你就告诉它不行，然后祈祷。 在这个过程中，你并不真正关心代码质量或其他任何额外的约束条件。我对vibe编程的看法是，它很棒，前提是你理解什么时候可以用它，什么时候不能。 如果是给你自己用的个人工具，出了bug只伤害你自己，那就放手去做吧！ 但如果你在为别人构建软件，vibe编程就是极其不负责任的，因为那关系到别人的信息。别人会因为你的愚蠢bug而受害。你需要有更高的标准。 而agentic工程恰恰相反，你是一名专业的软件工程师。你理解安全性、可维护性、运维和性能等等。你在以自己最高能力使用这些工具。我发现我能够承担的挑战范围有了显著提升，因为我有这些工具的支持。 但我仍然依赖我25年的软件工程师经验。 目标是构建高质量的生产系统：如果你只是在更快地构建低质量的东西，我认为那是坏事。我想以更快的速度构建更高质量的东西。我想让我构建的每一件东西在各方面都比以前更好。 问题是，随着编程代理变得越来越可靠，我已经不再审查它们写的每一行代码了，即使是我的生产级代码。 我非常清楚，如果你让Claude Code构建一个运行SQL查询并将结果以JSON格式输出的API端点，它就会正确地完成。它不会搞砸这个。你让它添加自动化测试，让它添加文档，你知道它会做得很好。 但我没有审查那段代码。现在我有一种负罪感：如果我都没有审查代码，把它用在生产环境中真的是负责任的吗？ 真正让我释怀的是回想我在大公司做工程经理的时候。其他团队在构建我的团队所依赖的软件。 如果另一个团队交付了一个东西并说："嘿，这是图片缩放服务，这是使用它来缩放图片的方法"……我不会去读他们写的每一行代码。 我会看他们的文档，然后使用它来缩放一些图片。然后我就开始发布我自己的功能了。如果我开始遇到问题，比如图片缩放器似乎有bug或者性能不好，那时我可能会去翻看他们的Git仓库，看看怎么回事。但在大多数情况下，我把它当作一个半黑盒，不需要的时候不会去看。 我开始以同样的方式对待代理了。但这仍然让我感到不舒服，因为人类对他们做的事情是有责任的。一个团队可以建立声誉。我可以说"我信任那边的那个团队。他们过去构建了很好的软件。他们不会构建垃圾，因为这会影响他们的职业声誉。" Claude Code没有职业声誉！它无法对自己做的事情负责。但它一直在证明自己——一次又一次地，它在产出那些直截了当的东西，而且以我喜欢的方式做得正确。 这里面有一种[偏差正常化](https://simonwillison.net/2025/Dec/10/normalization-of-deviance/?ref=hubwiz.com)的因素——每次模型在没有我密切监控的情况下写出了正确的代码，就存在一种风险：我可能在未来的某个错误时刻信任它，然后栽跟头。 ## 2、评估软件的新挑战 以前如果你在GitHub上找到一个有一百个提交、好的readme、自动化测试等东西的仓库，你可以相当确定写这个项目的人投入了大量的心血和关注。 而现在，我可以在半小时内敲出一个有一百个提交、漂亮的readme和覆盖每一行代码的全面测试的git仓库！它看起来和那些投入了大量心血的项目一模一样。也许它确实和它们一样好。我不知道。我从外观上看不出来。即使是我*自己的*项目，我也看不出来。 所以我意识到，比测试和文档的质量更让我看重的是，我希望有人真正*使用过*这个东西。如果你有一个vibe编程出来的东西，但你在过去两周每天都在使用它，那对我来说比你刚刚生成出来几乎没怎么用过的东西有价值得多。 ## 3、瓶颈已经转移 如果你能从每天写200行代码变成每天写2000行代码，还有什么会出问题？事实证明，整个软件开发生命周期都是围绕"写几百行代码需要一天"这个想法设计的。而现在不再是了。 不仅仅是下游的问题，上游也是。我看了[Anthropic设计负责人Jenny Wen的一个精彩演讲](https://simonwillison.net/2026/Jan/24/dont-trust-the-process/?ref=hubwiz.com)，她说我们所有的设计流程都是基于"你需要把设计做*对*"这个想法——因为如果你把设计交给工程师，他们花了三个月构建了错误的东西，那就是灾难性的。 所以你建立了这套非常广泛的设计流程，因为设计的结果会导致昂贵的开发工作。但如果不需要三个月来构建了，也许设计流程可以承担更多的风险，因为犯错的成本已经大大降低了。 ## 4、为什么我仍然不为我的职业生涯担忧 当我审视我与代理的对话时，我非常清楚，对绝大多数人类来说，这简直就是天书。 我有太多理由不害怕我的软件工程师生涯已经结束，即使计算机现在可以自己写代码了。部分原因是这些东西是现有经验的放大器。如果你知道自己在做什么，有了它们你可以跑得快得多。\[...\] 在使用这些工具的过程中，我不断被提醒我们所做的工作有多难。构建软件是一件*极其困难*的事情。你可以把世界上所有的AI工具都给我，我们在这里试图实现的目标仍然非常困难。\[...\] 政治评论家Matthew Yglesias昨天[发推说](https://twitter.com/mattyglesias/status/2049105745132585161?ref=hubwiz.com)："五个月过去了，我想我决定了，我不想vibe编程——我想要的是专业管理的软件公司使用AI编码辅助来制造更多/更好/更便宜的软件产品，然后卖给我。"我觉得这话说到点子上了。如果我看了足够多的水管工YouTube视频，我也能自己装修家里的水管。但我宁愿雇佣一个水管工。 关于公司自建解决方案对SaaS提供商的威胁： > 我刚意识到这就是我之前说的那件事——我只会在你用了你的副业项目几周之后才愿意使用它。企业版的说法是，除非至少有其他两家大型企业已经成功使用了那个CRM六个月，否则我不想要它。\[...\]你想要的是在你承担风险之前已经被证明有效的解决方案。 --- 原文链接: [Vibe coding and agentic engineering are getting closer than I'd like](https://simonwillison.net/2026/May/6/vibe-coding-and-agentic-engineering/?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处 > **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)