很多人转发引用了一年前我的那条推文（见下文），庆祝 Vibe Coding 诞生一周年。下面是我个人对其一周年的回顾。
我玩 Twitter（现 X）已经 17 年了（天呐），但我还是完全无法预测推文的互动量。当时这只是我洗澡时灵光一现、随手发的一条“废推”，没怎么过脑子。但不知怎么的，它就在恰当的时机创造了一个贴切的名字，捕捉到了当时很多人共同的感受。于是就有了现状：Vibe Coding 现在作为我重大的“模因（梗）贡献”被写进了维基百科，甚至它的词条比我的个人介绍还要长。哈哈。
我想补充的一点是，在那时，大语言模型（LLM）的能力还比较有限，你大多只是把 Vibe Coding 用于一些好玩的、随手即弃的小项目、Demo 或探索。那很有趣，而且效果勉强过得去。今天（一年后），通过 LLM 智能体（Agents） 编程正日益成为专业人士的默认工作流，只不过增加了更多的监督和审查。
我们的目标是利用智能体带来的杠杆效应，同时不牺牲软件质量。很多人尝试起一个更好的名字来将其与 Vibe Coding 区分开，我个人目前最喜欢的是 “智能体工程”（Agentic Engineering）：
- “智能体”（Agentic）：是因为现在的默认状态是，你 99% 的时间都不再直接编写代码，而是在编排并监督执行任务的智能体。
- “工程”（Engineering）：是为了强调这其中包含艺术、科学和专业知识。这是一门你可以学习并不断精进的技能，有着另一种维度的深度。
2026 年，我们很可能会看到模型层和新的智能体层持续改进。我对这两者结合的产物以及又一年的进步感到兴奋。
下面就是 Andrej Karpathy 在一年前（2025年）首次提出“Vibe Coding”概念时的那篇标志性推文翻译：
有一种我称之为 “Vibe Coding（氛围编程”） 的新式编程法：你完全随性而为，拥抱指数级的技术爆发，甚至忘记了代码的存在。
这之所以成为可能，是因为大语言模型（比如 Cursor Composer 搭配 Sonnet）变得太强大了。而且我还会配合 SuperWhisper 直接对 Composer 喊话，所以几乎不怎么碰键盘。我会提一些极其“小白”的要求，比如“把侧边栏的边距（padding）缩减一半”，纯粹是因为我懒得去翻代码找位置。
我总是习惯性地点击“全部接受（Accept All）”，再也不去读代码差异（diffs）了。遇到报错信息，我直接原封不动地复制粘贴回去，一句话都不解释，通常这样就能修好。代码量增长得超出了我平时的理解能力，如果真要看懂，我得盯着读好半天。有时候 LLM 修不掉某个 Bug，我就干脆绕开它，或者提一些随机的修改要求，直到 Bug 消失为止。
这种方式搞点周末的“随手即弃”小项目还挺不错的，甚至很有趣。我确实是在开发一个项目或 Web 应用，但这真的不算是在写代码——我只是看一看、说一说、跑一跑、贴一贴，然后它居然就这么跑通了。
💡 深度解析：从“氛围”到“工程”
对比上面那篇一周年回顾，你会发现 Karpathy 的心态发生了微妙的变化：
- 从“玩票”到“专业”：一年前他觉得这只适合“周末随手即弃的小项目（throwaway weekend projects）”，但一年后，他认为这已成为“专业人士的默认工作流”。
- 从“盲目”到“监督”：一年前他“不看代码差异（don‘t read diffs）”，但现在他强调“智能体工程”需要“监督与审查（oversight and scrutiny）”，不能牺牲软件质量。
- 角色的转变：一年前他觉得自己像个“指挥家”，现在他明确了这种新角色——不是不写代码了，而是成为了智能体的编排者。
💡 核心词汇理解
- Vibe Coding：指开发者不再深究每一行代码的逻辑，而是通过描述意图，靠 AI 生成代码，只要“感觉（Vibe）”对了、程序能跑起来就行。
- Agentic Engineering：卡帕斯提出的新阶段，强调从“随意尝试”转向“专业编排”，开发者角色从“码农”转变为“智能体调度员”。
原文：https://x.com/karpathy/status/2019137879310836075
你对这种编程范式的演变有什么看法？是更倾向于早期的“氛围”式探索，还是拥抱有监督的“智能体工程”？欢迎在云栈社区分享你的实践与见解。 | 
发表于 6 小时前
|
查看: 1|
回复: 0
