🎯 讨论背景

这里的 vibe coding 指的是让 Claude（Anthropic 推出的 AI 助手）这类 LLM 直接生成或修改代码，使用者往往不逐行审查。争论焦点不是 AI 能不能写代码，而是这种做法是否仍满足 software engineering 对架构、可维护性、责任边界和故障排查的要求。评论还提到 spec-driven development（先写规格再实现）、context window（上下文窗口）和 context compression（上下文压缩）这些概念，认为模型在长上下文下仍可能偏离约束。背景里也有桥梁工程、装配线开发、bootcamp 教学和 Stack Overflow 复制粘贴的类比，用来说明软件行业早就存在“只会拼接”的工作方式。

📌 讨论焦点

vibe coding 只能出 demo，不算工程

不少评论认为，vibe coding 主要产出的是能跑的代码片段或 demo，而不是可维护、可诊断的系统。真正的工程需要理解系统如何工作、在出错时能定位问题，并对停机、金钱损失和数据风险负责。有人把它类比为复制 Stack Overflow 答案、拼 framework 脚手架，或者在企业里把 demo 直接当最终产品。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]

先定架构和规格，LLM 也能参与工程

另一派把这种做法称为 vibe engineering，强调先做架构决策、定义接口、划定抽象边界，再让 LLM 填实现细节。对他们来说，工程并没有消失，只是把人放在上层设计位，把模型当作实现工具。还有人补充说，spec-driven development 本来就是被很多团队忽视的传统做法，只要配合 unit testing 和更严格的标准，AI 反而能把细节补齐。

[来源1] [来源2] [来源3] [来源4]

LLM 可靠性与规格遵循问题

质疑者追问的重点是：谁来确认模型真的遵守了规格。评论指出，模型拿到的上下文越多，越可能开始忽略指令；一旦发生 context compression，原本的约束就可能被压缩掉。有人提到 Anthropic 把上下文扩到 1M tokens，就是在缓解这类偏航，但这也说明生成结果不能被默认正确。

[来源1]

软件行业本身就充满拼接式工作

还有一类评论把争论上升到软件行业本身，认为很多所谓 software engineering 早就像装配线：套 framework、生成 model 和 controller、装几个 package，再补 glue code。有人认为开发者过去常因 PR 语法或门槛问题搞 gatekeeping，而真正该管的是 deadline 和需求清晰度。也有人提到 bootcamp 和部分 CS curriculum 训练出来的人本来就更像会搜索和拼接代码的“组装工”，AI 只是把这类工作方式进一步自动化。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]

📚 术语解释

vibe coding: 以“感觉”为主、借助 LLM 快速生成或修改代码，但通常不逐行理解和审查。

spec-driven development: 先写清规格、接口、边界和测试，再按规格实现代码的方法。

context compression: 模型在长上下文中压缩信息时丢失关键约束，导致偏离原始指令的现象。