加载失败
“vibe coding”指用 LLM（Large Language Model，大语言模型）或 AI agent 通过自然语言快速生成代码，争议点在于它是否会让团队绕开正常的 review、spec 和 security 流程。这里讨论的是一篇把它描述成会“break your company”的观点文，核心论点是速度如果没有 judgment 和治理就会放大风险。评论区把问题拆成了工程实践、企业管理和市场竞争三层：有人强调 code review、规范和责任边界，有人认为商业成败更取决于产品、价格、信任和执行，而不只是写代码快慢。与此同时，大家还在吐槽 AI 时代的内容环境，认为网上充斥着 AI 生成的文章和 slop。
不少人直接把这篇文章当成 clickbait 或 doomsaying，认为它把最坏情况包装成必然结果。还有人嘲讽这是又一篇 AI 生成的“AI is bad”故事，甚至连论证都显得混乱，把不同的 AI 风险混在一起。评论里也有人顺手吐槽 Forbes 之类媒体的信誉太低，整篇更像情绪输出而不是分析。
另一条主线认为，AI 的关键不是单纯加速写代码，而是放大判断力：好工程师更快，坏工程师更容易用 AI 把自己包装得很专业。有人强调企业需要 specs、coding styles 和 security 规则，否则 pure vibe coding 根本不适合 enterprise。还有人把问题上升到 leadership，认为真正的风险是管理层只会为产出鼓掌，却不追问为什么要这么做。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
也有评论认为，vibe coding 不是万能，但在受控场景里很有价值。最常被提到的是 internal tool、早期 bootstrapping、输出型系统，以及有 competent engineer review 的场景；甚至有人说它对 code removal、refactoring 这类维护工作更有帮助。这个观点的核心不是放弃审查，而是把 AI 当成提速工具，同时保留人类兜底。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
反对者则认为，速度一旦压得太狠，团队会迅速失去对 codebase 的直觉和记忆，后续 debugging 会变得非常痛苦。AI 往往只会给出“more of the same”的修补方案，容易把设计问题越补越烂，最后变成 spaghetti code。还有人指出，一旦让 AI 去做会影响用户或系统状态的事，出错后到底谁负责就不再是抽象问题。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
不少人不同意“AI 不用就会落后”的说法，认为商业成败更看产品、定价、质量、信任和长期保障。客户往往在意的是 business proposition，而不是你今天把 feature ship 得多快；就算软件很慢，也未必妨碍公司成功。有人举例说 Jira、Microsoft Teams 这类慢工具会招骂但照样能活，而真正会带来 reputational damage 的更可能是泄露数据或给用户错误信息。也有人补充，真有 100M ARR 以后，企业大概率还是会高薪招少量顶级人才来指挥 AI，而不是永远维持一个神话般的 4 人团队。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
评论区还不断把话题拉到更大的 AI 内容生态，认为现在网络上充满了 AI 生成的文章、帖子和互相复制的观点。有人开玩笑说完全可以再用 AI 生成一批“AI is good”的反击稿，甚至让 agents 自己互相对打。更悲观的看法是，LLM 不只是生成错误内容，而是在把语料和文风一起拖向 slop，让人对整个信息环境越来越疲惫。
vibe coding: 用自然语言和 AI 快速生成代码的开发方式，通常伴随较少人工审查。
code review: 对代码进行人工审查，检查正确性、安全性和可维护性。
LLM: Large Language Model，大语言模型；这里指驱动代码生成和文本生成的 AI 模型。