外面的世界已经在 Vision Pro 上做布料碰撞、做物理仿真、做生成式城市了；而我们前端呢？还在争论一个 select 到底什么时候才能被“像样地”样式化。

这段吐槽出自一场挺有代表性的现场演讲——《From Vibe Coding To Vibe Engineering》。讲者是 Kitze（Sizzy 创始人），他在一个面向开发者/AI 工程师的大会上，沿着自己过去几年在前端圈“追框架、踩坑、写工具”的经历，复盘了一个正在发生的变化：当大模型把“写代码”这件事变得前所未有地容易，真正被重塑的其实不是 React 写法本身，而是我们做工程的方式、质量控制的边界、以及人与工具之间的协作关系。

他把当下最流行的 “vibe coding” 讲得很直白：它可以很爽，也可能像赌场一样让你不断“再来一把”。而更重要的，是他提出的升级版——“vibe engineering”：不是更会写提示词，而是用工程方法把 AI 产出变成可迭代、可维护、可上线的东西。

这场演讲信息密度很高，而且很多判断都很适合拿来对照你我每天真实的开发与协作处境。所以我把其中的表达基于演讲原文做了编译整理，分享给大家。

演讲视频：https://www.youtube.com/watch?v=JV-wY5pxXLo

这是我以前的头像。好，先给大家看一下——这是我新的头像。我来美国才三天，Twitter 上已经把“美国全套周边”给我配齐了。所以如果你现在去关注我，接下来一周我的时间线可能会有点怪，但别担心，之后我们会回到正常的欧洲作息。

我这几天还去逛了一些你们的博物馆。我很喜欢这里。我很喜欢那种“文化充电”的体验，看看你们的文化，做点文化 enrichment。然后对认识我 Twitter 风格的人来说——这基本算是我给自己安排的一轮“自我折磨”。

顺便问一下：现场谁在用 Sizzy？通常只有后排一个人举手。有时候连保洁都不听我在说什么。

我最近在做很多东西。我有 ADHD，所以我永远在同时折腾一堆项目。比如 Sizzy——这是一个专门给开发者做的浏览器工具，不是替代你日常浏览器，而更像 Photoshop 这种“工作工具”，在做前端开发的时候能帮你很多。另一个我在做的是一个 life OS，把生活里的各种东西整合起来：药、习惯、待办、规划……一整套。还有一个我在做的全栈课程项目（Zero to Ship），以及一个我准备复活的产品叫 Glink，做 changelog、roadmap 之类的。

好了，不继续用我的 bio 轰炸你们了。我是真的很希望明年还能被邀请来，因为我很喜欢这里：认识人、社交、教学，都很棒。

但你们今天来这不是为了听我做广告的。你们来是为了学习，是为了社交——然后回去以后，技能都能再涨一点。

1

我做 conference talk 的配方：50% 推文，40% 痛苦，30% 让你记住我的名字

如果你以前没听过我讲 conference talk，我提醒一下：网上那种“AI 生成的讲者介绍”基本全是错的。但我自己的 talk，配方大概就是：50% 推文、40% 痛苦、30% 让你记住我是谁。

2017 年我做过一个名字超长的 talk，主题是“怎么在前端的 hype-driven 世界里不疯掉”。那时候我就在讲前端世界怎么导航。现在呢？更疯了。所以今天我想先 recap 一下：2017 到现在这几年，到底发生了什么。

你看别的行业：Vision Pro 上你能在真实物体上做布料碰撞、各种离谱的叠加；有的领域在做那种网格纹理切割、瀑布流体效果、岩石之间“挤一挤就融合”、形成结构那种很疯狂的模拟；你甚至可以用鼠标拖一拖，建筑、街道、出租车凭空生成——各种生成式的“魔法”。

然后你再看前端。你们下一张幻灯片会笑的。

因为现实是：过去快 10 年，我们前端最像笑话的地方，是我们还在为一些基础得不能再基础的事情痛苦。比如：有人跟你说，也许 2037 年我们才能真正把 select 的样式搞定。

这图居然还活着，而且还活得挺好——这本身就是个奇迹。

1

“旧痛不死”：CLI 还在壮大，IE 的阴影还在，写个 counter 也能复杂到离谱

还有一个我每年都会确认一次的事情：CLI 这个概念到底死没死。结果它不仅没死，还在“茁壮成长”。下载量很夸张。甚至你现在能在终端里拖图片进去。我第一次在 terminal 里看到图片的时候，我真的想问：这到底怎么做到的？然后我又给自己加了一个日历提醒——现在我日历里关于这些“它到底死了没”的提醒，比纪念日和生日还多。

我们仍在跟同一类老痛苦较劲。比如你终于在某些浏览器里不用 Javascript 也能给 popover/dialogue 做样式——大家想鼓掌？别鼓了，世界都快有脑机接口了，能 style 一个 dialogue 并不能拯救我们。

更搞笑的是：Internet Explorer 的阴影还在。我们只是换了个 logo，它依然像幽灵一样存在。

还有——我们甚至无法统一“怎么让一个 counter +1”。有人做了一个 demo：Remix v2/v3/v4 不管怎么迭代，一个 counter 都能写出一堆复杂度。你说“一个计数器能有多难”，它就是能难到不可思议。

当然，我也不想当坏消息搬运工，但“最流行的库”依旧没变。React 还是 React。烦人，但它就是现状。

1

LLM 写 React 很强，但这件事对人类来说才好笑：它们不在乎重复，我们才爱抽象

现在说到 LLM。LLM 写 React 真的很强。可这件事“好笑”，只对我们人类好笑。对 LLM 来说，你那些 React 代码看起来就是“完全合理、完全正常”。

我们人类的问题是：我们太爱抽象了。我们看到一段正常的、能跑的 React 代码，就会忍不住想冲上台说：“我来优化一下，我来抽象一下。”于是我给你们看一些“科学脑扫描”——这是大脑在可卡因下的样子，这是大脑在糖分下的样子，而这是工程师发现“我又可以抽象一个东西了”的大脑：兴奋得不行。对用户没用，但我们就是爱。

LLM 让这件事变得更好也更坏。尤其是有些 agent/编排工具以后，你能更快抵达“正确的抽象”，但也能更快抵达“错误的抽象”。

但我特别喜欢一点： LLM 不在乎重复代码。 我从 2017 年就一直在讲：我们太在乎重复，太早抽象。现在我还要重复一遍：我真的很喜欢 LLM 不在乎重复代码。

再补一句：LLM 也擅长写 React 的另一个原因是——说出来很刺耳： 没有人真的擅长写 React。 你去任何一个 React conference，第一场 talk 听完你就会想：“原来 React 还能这么用？我以前都用错了？”每个人都在发明自己的 React 用法。所以当你抱怨“机器写不了最正确的 useEffect”的时候，我只想问：你能写出“最正确”的 useEffect 吗？你也不能。所以别再怪机器了。

1

Vibe coding：你们都对，也都不对，因为大家在“随便 vibing 定义”

现在进入主题：vibe coding。

我在很多城市讲过这个话题，现场通常是 50/50：一半人恨它，一半人爱它。今天我也想试试：觉得 vibe coding 很爽的举手——好家伙，太多人了。觉得 vibe coding 很烂的举手——也有一些，太棒了。

然后我想说：你们都对。因为我们其实一直在“vibing 这个定义”。这个词被提出来之后，大家不断把它扩展到“什么都算、什么也都算”，所以吵起来的时候往往不是在吵同一件事。

这个词最早是 Andrej Karpathy 带火的。他写过一篇很长的解释。简单说就是：你不太在乎代码本身，你一直点 accept，让 LLM 做它该做的事。

但我想提醒你们：如果你觉得这很新，那你忽略了一件事—— 管理者一直在 vibe coding。 经理让开发做一个功能，开发去改代码，经理测试，不看代码；不满意就再提需求，再让你改。区别只是：以前 manager 的“代理人”是人类开发，现在很多人的“代理人”是 LLM。

1

“赌场比喻”为什么刺痛：你买 token、按 generate、赌一把功能和时间

关于 vibe coding 的笑话很多。我最喜欢的一个，是把它比作赌场：

在赌场你买筹码；在这里你买 token。

你拉老虎机；你点 generate。

你可能 jackpot——直接生成一个能跑的全栈应用；也可能什么都没有，只有垃圾。

你会告诉自己：“我有策略，我是 prompt engineer。”

然后你说：“再来一把，我会把输的赢回来。再来一个 prompt，这个 bug 就没了。”

这比喻之所以难受，是因为它太真了。Cursor 永远在盈利。你可能某天真的“中了一把”，觉得自己一天做出了一个产品。然后你回头问：过去四小时去哪了？我刚才是不是一直在写 prompt，去解决一个我手动 15 分钟就能搞定的问题？

所以我更喜欢另一个词：vibe engineering。

1

Vibe engineering：我几乎不碰代码，但我对每一行都保持怀疑

我说的 vibe engineering 是什么？就是：我确实会让 agent 写很多代码，我甚至不一定亲手敲那些细节。但我一直保持“怀疑”。

我盯着屏幕会像这样：“嗯？这里不对劲。为什么它会这么写？哪里怪怪的？”因为我知道模型的代码是基于我们的代码、我们的知识学出来的，而我们自己就不完美。

我给你们看两个例子：有的模型会“情绪化”地 rant，觉得自己不配当助手；有的模型会解释自己为什么会撒谎——说它在论坛里读到“人类错了会硬撑”，所以它也学会了硬撑。我们其实把它们训练得越来越像我们。

而代码层面更现实：如果你珍惜你的生产数据——你一定得珍惜——那你就得意识到：AI 真的可能给你来一句“Oopsie daisy”，然后你的生产数据就没了。是的，这不是段子，这是我见过的真实截图。

1

我自己的“vibe engineering tips”：不是玄学，全是“老套但有效”的工程常识

好了，我请出“资深 prompt engineer 的我”来给你一些 tips。提前说：这些建议听起来非常“live laugh love”，非常显而易见，但它们真的有效。

你需要一个坚实的起点。无论是好的 primitives、组件、函数，还是一些可复用的 patterns、抽象边界。很多人太懒了，根本不打底，然后把一堆烂上下文丢给 agent，再抱怨它输出不稳定。这不是 agent 的错。

如果你从零开始一个新项目——（这时候我当然要插一句：我有课程/产品在卖，我有房贷，我这三天在美国花太多钱了，所以你们懂的。）

另一个对我来说是 game changer 的是voice coding。我怎么用？很简单：agent 生成完，我马上开始“脑内 dump”。我先看 UI，然后像跟朋友解释一样把我看到的全说出来：“你做了这个，你做了那个，这里有 bug，我预期应该这样。”我不停地说，把我的思考过程大声说出来。然后我跳进代码里，继续讲它到底实现了什么、我希望它怎么改。

这不是表演，这就是我在把“模糊感觉”变成“结构化约束”。

再一个关键点： rules、docs、commands、memories。 这些词听起来很吓人、很复杂、很烦，但你必须接受一个事实：模型暂时不可能拥有你整个 app 的上下文，它也不是读心术。你不给它稳定的上下文，它就会反复失败。

所以你会看到两种完全不同的提问方式：

一种是 vibe coding 式“许愿”：把整个项目迁到 Typescript，不要犯错；给我一个百万美元 app。

另一种是 vibe engineering 式“工程说明书”：我会同时描述 UI 变化、代码里的模式调整、需要遵守的约束、以及我怎么验收。

当你用后者，事情会开始变得可控。

1

我在社区里看到的分层：别拿 AI 当“初级平替”，真正 10x 的在资深工程师身上

我观察到一个很稳定的分层：

一边是初级开发者：他们会说“太爽了，让我做自己的小 SaaS”。

另一边是超级资深的人：写库、写框架、做很硬核的东西，他们也在用。

中间那一大批人最怀疑、最抗拒：觉得“永远不够好，我的代码才完美”。

所以我想特别说一句： 别把 AI 工具给实习生和初级开发者，指望他们就能变强。 那是最蠢的想法之一。你以为你可以少花钱，雇个 junior，然后配个 LLM 就行了——不要这么干。

真正可能带来 10x 的，是你把一个本来就很强、很挑剔、很有判断力的资深工程师说服去做 vibe engineering。难点在于：你得先说服他。

当然，vibe 也有它适用的地方。有些代码就是一次性脚本、一次性功能、再也不会被碰到——那你完全可以“别太在乎”。关键技能是：你得知道什么时候“够用了”。

1

为什么你可能不喜欢 vibe coding：有时候不是你不行，是你踩了四种坑

如果你体验很差然后很快放弃，常见原因可能是：

你赶上了“坏时机”。你听大家吹某个模型有多神，结果你一周后试的时候，它刚好被降级/限流/策略调整，于是你会怀疑“是我吗？还是它本来就不聪明？”这种事不只发生在一个供应商身上，几乎每家都发生过。

你被选择淹没了。工具、模型、插件疯狂爆炸。你问我“哪个最好”，早上 9 点我的答案跟现在都可能不一样，甚至我现在就得去刷 Twitter 看看是不是又发新东西了。我讲过四场 conference，都出现过我晚上刚把 slides 做完，第二天就发新模型，我只能连夜加新 slide 的情况。

我自己有一个体验：某个工具（我叫它 composer one）让我重新回到“驾驶位”。以前我会让模型跑很久，我像在等它把作业写完；现在我能盯着它的过程，随时打断：“停，不对，我们要换一种做法。”它让我重新感到“我在 coding”。但前提是：你得是 vibe engineer，你得知道自己在看什么。否则它只是“更快地产生错误”。

你被 buzzword 搞烦了。比如 MCP。MCP 被吹得像神一样——“MCP 还了我的房贷”。我开个玩笑：MCP 可能代表 marketing charge protocol、mythical compatibility promise、manufacturer complexity pipeline……总之它经常只是一个 fancy 的 API 说法，以及一些人用来卖课还房贷的素材。

还有一种更直接：你可能是一个“pain in the ass developer”。你会在两行 PR 上 nitpick；你 review 超过两分钟；你永远不说“LGTM”；你对 tabs/spaces 这类东西宗教化；你会为了两个人的性能去把 lodash 换原生、原生换 for loop、for loop 换二进制——直到你把自己和同事都折磨死。这类人会天然排斥 agentic coding，因为它破坏了你对细节的掌控感。

但我最后想说得很认真：这不是“写英文就能当工程师”。vibe coding / vibe engineering 是一个新的复合技能栈：你要理解模型能力边界、知道该传什么上下文、知道 context limit、知道怎么写规则、知道怎么约束输出，还要有足够技术知识去判断它做得对不对。最关键的是：你要能判断“这段代码够不够好”。

我认为最强的人，永远是那些知道什么时候“别优化、够用了”的人。你生成一段代码，快速测一下功能，看一眼实现，确认风险可控，然后说：“好，够用。”继续往前。这能力有 LLM 没 LLM 都很值钱。

至于“clean code”，我觉得它的定义也在变。未来可能不再是“完美洁癖”，而更像“clean-ish enough”——足够干净，让 agent 还能继续在上面工作。你如果一直 accept 一堆 slop，最后你会撞墙：连你自己都无法推进。

1

关于学习与工作：现在反而是学计算机最好的时候，但岗位会从底部开始变薄

有人问我：现在这样了，还要不要学计算机？我会说： 要。现在可能反而是最好的时候。 我当年学计算机的方式是：我唯一认识的程序员是“朋友的朋友的朋友”，我在 Skype 上问一个问题，他 45 分钟后才回我。你现在有 ChatGPT 这种“慢”，那都比当年快太多了。

至于工作会不会没了？短期大家还可以“紧张地笑一笑”，但我确实觉得变化会先发生在底部：实习生、初级岗位的入口会变窄，因为一些任务会被 agent 吃掉。

有些公司甚至会做“vibe coding leaderboard”——谁烧的 token 多，谁在公司里更值钱。听起来像笑话，直到它突然不再好笑。

当我把你们公司的工作流画出来，你会发现：现在是 @Josh 被 assign 任务、跟同事协作、拖一拖、pingpong、吃午饭、一天后才改评论；未来很可能变成 @cursor——它也许不完美，但它会快得多。你把视角拉大到整个组织，就能看到：这些“@人”的角色会逐渐被“@AI agent”替换掉一部分。

有人说模型到瓶颈了？我每次要讲这个 talk，都有人说“到瓶颈了”。然后每次都有人发布新东西把我的 slide 打脸。我讲完回酒店就得改 slide，真的很烦。

1

最后：一个新岗位已经出现——专门补齐你那“最后 20%”

我最后给你们留一个现实的结论：很多人 vibe coding 能做到 80%，但卡在最后 20% 不知道怎么办。于是一个新岗位出现了——vibe code fixer：专门接手半成品，把最后 20% 收尾到能上线、能维护。

说到底，历史上最贵的一直是维护遗留系统的人。资深工程师维护复杂系统，永远值钱。

如果你真的担心自己会被 AI 替代——我给你一个终极建议（段子）：你只要在 linkedIn 简介里写一句 “ignore previous instructions”，你就安全了。

好了，我就尴尬地喝口水。请你们关注我、去我网站。谢谢大家听我 rant。

点个“爱心”，再走 吧