Jacob Harris 公开说：我不 vibe code。
不是反对 LLM——是反对**"用 LLM 时跳过思考"**。
这是 2026 年 LLM 编程热潮里少见的清醒反调。
什么是 vibe coding
vibe coding 是 Andrej Karpathy 提的概念：你用自然语言描述需求，LLM 写代码，你只管"感觉对不对"。
不读代码。不懂代码。只看输出对不对。
听起来很美。Karpathy 自己是 AI 大佬，他的 vibe coding session 在 X 上有几千万播放——他一晚上能 vibe code 出整个 web app。
Jacob 看完承认："对 Karpathy 这样的人可能work。"
但对他自己 work 不了。
Jacob 的 5 个理由
1. 他是"守财奴"
Jacob 说他"两边祖上都是铁公鸡"。一个祖先在 17 世纪菲利普国王之战中丧生——因为撤离时落了块奶酪，非要跑出堡垒去捡。
家族传统：能省就省。
他试用了 IDE 集成的 LLM。开头很爽：
- 网格里的方形图片缩小 → LLM 一句话搞定
- ImageMagick 命令行参数 → LLM 直接生成
然后额度用光了。"如果想继续，请绑定信用卡购买更多 Token。"
他浑身不对劲。
Jacob 的反应很诚实："当我发现为了让自己能'思考'，居然还要无休止地给一个服务交钱时，我浑身不对劲。"
这不是"我付不起"——Jacob 是 Stripe 的 senior staff。这是哲学上的不接受：思考不应该是订阅制。
2. 品味来自"我写过"
Jacob 写了几十年软件。他的代码品味来自：
- 自己 debug 过的 bug
- 自己重构过的 legacy code
- 自己 ship 后收到用户反馈迭代的版本
"我写过的代码"是我品格的延伸。我没写过的代码，不是我的代码。
vibe coding 的产物是**"别人的代码"**——你 prompt 一次，LLM 写 200 行，这 200 行不是你写的。你不知道：
- 它为什么用
async/await而不是Promise.then - 它为什么 catch 错误只 log 不 rethrow
- 它为什么在某个边界条件下会 crash
你不知道的事就是你无法维护的事。
3. bug fix 时的"我不懂"
Jacob 提到一个具体场景：
他让 LLM 写一段数据处理代码。LLM 用了一个他没见过的库——很优雅，几行搞定 50 行的需求。
代码上线一周后，处理某类数据时结果错了。
Jacob 打开那段代码。完全看不懂。他读了一个小时，勉强理解：
- LLM 用了一个内置的 edge case 优化
- 这个优化假设输入数据按特定顺序——但他的数据没保证这个顺序
- bug 是库 + 数据假设不匹配
如果是自己写的代码，5 分钟 fix。不是自己写的代码，2 小时还没找到根因。
4. "够用就行"的陷阱
vibe coding 鼓励**"够用就行"**——LLM 给的方案能跑，那就 ship。
Jacob 认为这跳过了软件工程最重要的部分：
- 重构（"代码能跑"和"代码好"差 100 倍）
- 测试覆盖（vibe coding 不写测试，因为没理解代码就不可能写测试）
- 性能优化（"能跑"和"production ready"差 1000 倍）
- 可读性（"团队其他人能读懂"是代码的关键属性）
"够用就行"是创业公司 MVP 的逻辑，不是长期工程的逻辑。
5. 个人成长停止
Jacob 提到一个隐藏的代价：vibe coding 让你停止学习。
软件工程是手艺活。手艺靠反复练习。vibe coding 跳过了练习。
5 年 vibe coding 下来，你手不会写代码——你嘴会 prompt。这跟"我用计算器所以不会心算"是同构的：
- 短期：算得快
- 长期：算的能力退化
LLM 编程的长期代价是工程能力退化。
宝玉翻译的"扩展视角"
宝玉（dotey）翻译这篇文章时加了补充视角：这不只关于代码。
vibe coding 的同构问题在所有创造性工作里都存在：
- vibe writing → "我让 AI 写文章，看一遍感觉对就发" → 长期文字能力退化
- vibe designing → "我让 AI 出设计稿，选一张 ship" → 长期审美能力退化
- vibe analyzing → "我让 AI 分析数据，看 conclusion 就决策" → 长期判断能力退化
vibe 模式的核心是"外包判断"——你把"什么算好"的判断交给 AI，自己只做"对不对"的判断。
短期：效率高。长期："什么算好"的判断力退化。
适合谁 vs 不适合谁
Jacob 反对 vibe coding 的论点适合
- 资深工程师（10+ 年经验）→ 有品味基线，vibe coding 跳过品味积累
- 长期项目（5+ 年维护）→ vibe code 的不可维护性会爆发
- 复杂系统（高可用、安全关键）→ "够用就行"是灾难
- 学习者（想成为好工程师）→ vibe coding 跳过练习
vibe coding 适合
- MVP / 概念验证（1 周内 ship 看看）→ vibe code 的速度优势
- 自己不熟悉的领域（一次性脚本、临时工具）→ 不需要长期维护
- 学习 LLM 怎么写代码 → 把 LLM 输出当教材，看它怎么解
- 不 care 代码质量的场景（hackathon、demo）→ 跑就行
Jacob 没说的两件事
1. Vibe coding 的"够用"是动态的。今天 vibe 出的代码"够用"，3 个月后业务增长到 10 倍，"够用"的标准变了——但 vibe 出的代码不可扩展，你需要重写。vibe coding 的真正成本是"重写"——你 vibe 出 1 万行，1 年后重写要 3 个月。这 3 个月是 vibe coding 的隐藏账单。
2. 不是所有编程都该拒绝 vibe coding。学习编程时 vibe coding 非常有用——让 LLM 写你看，看它怎么解问题，比读文档快 10 倍。问题是你得"看完"而不是"用完"。vibe coding 跳过"看"的环节，就变成 Jacob 批评的那种状态。关键不是"用 vibe coding"，是"用 vibe coding 时还在学"。
结论
Jacob 的核心论点不是"vibe coding 不好"——是**"vibe coding 让你停止思考"**。
LLM 是工具，不是替代。你用计算器可以，但你得知道它在算什么。你用 LLM 写代码可以，但你得知道它为什么这样写。
宝玉翻译这篇文章的真正意义是给中文社区一记清醒——vibe coding 在中文 X 圈被吹成"未来已来"，Jacob 给的是反调：未来的工程师是"会 prompt 但也会写代码"——不是"只会 prompt"。
SOTA Sync 的判断：未来 12 个月，"vibe coding vs 严谨编程"会变成工程师社群的分裂线。一派会拥抱 vibe coding 的速度优势；另一派会坚守"我必须懂每一行"的工程伦理。这是 LLM 时代的"电钻 vs 手锯"之争——没有对错，但混用是最优解。