Simon Willison 辨析：vibe coding ≠ 用 AI 写代码
原文 · Simon Willison（Django 联合创始人、独立开发者）同样用大模型写代码，看不看得懂那一行，是两件事
读原文导读
这是 vibe coding「定义之争」里最关键的一篇辨析。Karpathy 造词之后，这个词被迅速用废，几乎成了「用 AI 写代码」的同义词。Simon Willison 这篇长文把边界重新划清楚：vibe coding 特指「不看模型写的代码」，而认真负责的 AI 辅助编程恰恰相反。
下面按原文结构做完整精译导读，关键论点配原句直引，建议结合上方链接读英文全文。
开篇：一个正在被用废的词
vibe coding 这个词是 Andrej Karpathy 在 2025 年 2 月 6 日提出的，之后被《纽约时报》《Ars Technica》《卫报》等大媒体反复引用，迅速出圈。
Willison 担心的是：这个词的含义正在被稀释。现在很多人把任何「用 AI 写代码」都叫成 vibe coding，他认为这既用废了这个词，也歪曲了「认真负责地用 AI 辅助编程」到底是怎么回事。
“Vibe coding is not the same thing as writing code with the help of LLMs!”
一、vibe coding 到底指什么
Willison 先回到 Karpathy 的原始定义。Karpathy 描述的是一种彻底放手的状态：完全交给感觉、拥抱指数级，甚至「忘了代码的存在」。
具体表现是：永远「Accept All」、不再读 diff；报错直接复制粘贴、不去理解；项目长到超出自己的理解范围；遇到 bug 不修，而是绕过去，或者让模型随便改改直到它消失。
Karpathy 自己也加了限定：这套玩法「对周末扔了就忘的小项目还行，但仍然挺好笑的」，他说这其实不太像在写代码，更像是「看东西、说东西、跑东西、复制粘贴东西」。
Willison 把它精炼成一句定义：vibe coding 就是「在不审查模型所写代码的前提下，用 LLM 造软件」。他强调 Karpathy 的动机是图快和图乐子，作为极有经验的程序员（比最熟练的人类还快一个数量级），不是因为不会写；低风险项目，干嘛不放手一搏。
“building software with an LLM without reviewing the code it writes”
二、负责任地用 LLM，不叫 vibe coding
Willison 把专业开发和 vibe coding 划开。专业开发要操心的远不止「代码能跑」：代码要能被别人和机器看懂、要能支撑后续迭代，还要在性能、可访问性、安全、可维护性、成本之间权衡。
他给自己立了条黄金法则：如果一段代码我没法向别人清楚解释它在干嘛，我就不会把它提交进仓库。
关键区分在于：如果模型写完代码、你审查了、认真测了、还能讲清楚，那这就是正常的软件开发，不是 vibe coding。用没用 LLM 不重要，重要的是过程和责任。他也说明这只是他《我如何用 LLM 帮我写代码》一文里的一小部分做法。
“I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.”
三、别忘了 vibe coding 真正的价值
Willison 不希望这个词彻底变成贬义。他觉得 vibe coding 有实打实的好处。
他相信「每个人都应该有能力用计算机把生活里那些繁琐的事自动化掉」，而做这些自动化，不该非得先受过正规编程教育。
对新手：vibe coding 能把编程极其陡峭的入门曲线拉平，让人更容易上手，甚至「被编程这个 bug 咬到」、最后成长为熟练开发者。
对老手：用好 LLM 本身很难，需要长期积累的直觉，而 vibe coding 正是培养这种「模型能做什么、不能做什么」直觉的好工具。他自己就发布了 80 多个 vibe coding 实验，并鼓励所有人不论水平都去试。
“everyone deserves the ability to automate tedious tasks in their lives with computers”
四、什么时候可以放心 vibe code？
Willison 给了几条判断标准。
低风险：先想清楚出 bug 或安全漏洞最坏会怎样，会不会有人因此名誉受损、财务损失甚至更糟，尤其当软件要给别人用时。
安全：别把密码、API key 这类秘密暴露出去，而这恰恰需要你真的懂代码在干嘛；碰私有数据的工具也要小心数据泄露路径。
做网络上的好公民：会向外部服务发请求的项目，可能给别人加负载、加成本。他点名 Claude Artifacts 的沙箱机制是个好解法。
金钱风险：别拿没有计费上限的按量付费 API 去 vibe code，他提到有人因此莫名背上几千美元账单的「恐怖故事」。
最后一句建议：凡是可能被别人用到的东西，公开发布前先找有经验的开发者把把关。
五、怎么让 vibe coding 变得更好？
Willison 认为「沙箱」是让新手安全 vibe coding 的关键。Claude Artifacts 就是范例：代码跑在锁死的 iframe 里、只能加载经过批准的库、不能向外部站点发网络请求。
代价是功能受限：这种沙箱里的项目没法访问外部 API、也没法自己跑 LLM 提示。
对比之下，Cursor 这类原本面向专业开发者的工具，安全约束就少得多。
他对未来很乐观，预期工具会迎来一场「寒武纪大爆发」，让人们能尽可能高效、又尽可能安全地造出自己想要的工具。
结语：放手去 vibe code
Willison 明确反对劝退新手去尝试 vibe coding，他强调：学任何东西最好的方式，就是动手做一个项目。
对老手，价值是建立对模型能力与边界的直觉；对新手，价值是亲手试出来「代码到底能干什么」。
全文落点回到那句核心：要把 vibe coding 和其他「LLM 辅助编程」区分开。不是所有 AI 辅助编程都叫 vibe coding，反过来也一样。
“The best way to learn anything is to build a project!”
出处与版权
作者 · Simon Willison（Django 联合创始人、独立开发者）
原文 · simonwillison.net
本页为 GoodVibe 对原文的中文整理，著作权归原作者所有；建议点击上方链接阅读原文全文。
