Vibe Slop：当 AI Coding 的速度开始反噬工程质量

Vibe Slop 这个词不好听，但它抓住了当前 AI Coding 里最尖锐的问题。

它不是在说“用 AI 写代码就是垃圾”。这个判断太懒，也不准确。真正的问题是：很多人把 AI 生成的可运行结果，当成了已经完成的软件工程。

这中间差了很远。

什么是 Vibe Slop

我理解的 Vibe Slop，是 Vibe Coding 失控后的产物。

Vibe Coding 的理想状态，是人用自然语言快速表达意图，让 AI 帮忙生成、修改、探索和验证代码。它降低了表达成本，让原型速度变快，也让非工程背景的人可以更接近软件创造。

Vibe Slop 则是另一回事：需求没有被澄清，边界没有被定义，生成代码没有被理解，测试没有被补齐，依赖没有被审查，安全没有被设计，最后却因为“它能跑”就被推进到生产或公开环境。

更直白一点说，Vibe Slop 是一种工程幻觉：看起来像产品，实际上只是模型、框架默认值、复制粘贴片段和人类侥幸心理堆出来的临时结构。

当前现状：速度是真的，债也是真的

这波变化不是空穴来风。

Palo Alto Networks 对 vibe coding 的解释很清楚：它让开发者用自然语言描述目标，再由 AI 生成代码，人的角色从“逐行构建”转向“引导和审查”。这个变化真实存在，而且确实提高了原型速度。但它也指出，模型会根据训练数据和 prompt 生成“看起来合理”的代码，而不是天然理解组织标准、安全边界和长期维护成本。

TechTarget 的风险分析也很务实：vibe coding 可以加速创新，但会引入数据泄露、prompt injection、不安全代码、依赖风险、技术债和责任模糊等问题。它的一个判断非常关键：AI 会放大一个组织现有的软件质量。如果原来的工程纪律很弱，AI 只会更快地产出更多弱质量代码。

更现实的案例已经出现。Axios 报道过，安全研究人员发现大量由 AI coding tools 构建的公开资产，其中有不少暴露了敏感企业数据、医疗记录、财务数据或内部文件。这里最吓人的不是“AI 写错了代码”，而是非专业用户在不了解权限、隐私和部署默认值的情况下，把内部工具直接推到了公开网络。

英国 NCSC 相关警告也说明，问题不只是个体开发者写得快不快，而是整个软件供应链的风险正在被放大。AI 生成代码如果缺少设计阶段的安全意识和后续审查，就可能把已有的软件质量问题推向更大规模。

学术研究也在补证据。2026 年 5 月的论文 From Prompting to Verification 调查了非开发者、新手和专业开发者三类 vibe coders，提出一个很重要的“perception-action gap”：大家大体知道 AI 代码有风险，但真正评估、调试和验证代码的能力高度依赖经验。另一篇 Is Vibe Coding Safe? 用真实开源任务构造安全 benchmark，结果显示一些 agent 生成的方案功能正确率远高于安全正确率。也就是说，“能完成需求”和“能安全上线”不是同一件事。

Vibe Slop 的五个症状

第一个症状是表面完整。页面有了，按钮能点，接口能通，demo 看起来很顺。但错误处理、权限边界、日志、监控、回滚、数据迁移、并发、时区、幂等性、异常路径都没有真正设计。

第二个症状是解释困难。代码是谁决定这样写的？为什么选这个依赖？为什么状态在这里存？为什么权限检查放在客户端？没人说得清。AI 生成了实现，人类只记得“当时让它改了几轮，终于跑起来了”。

第三个症状是补丁堆叠。一个 bug 出现，让 AI 修；修完引入另一个 bug，再让 AI 修。很快代码变成一层层局部补丁，架构意图消失，系统靠偶然性维持。

第四个症状是责任外包。出了问题以后，人说“这是 AI 生成的”。但用户数据泄露、账单算错、权限绕过、业务损失不会因为代码来自 AI 就变轻。责任永远落在人和组织身上。

第五个症状是能力退化。最危险的不是 AI 帮人写代码，而是人逐渐放弃理解代码。短期看效率提升，长期看判断力、调试能力、架构感和安全直觉都在萎缩。

但不要把问题简单归咎于 AI

我不赞成把所有 vibe coding 都打成 slop。

AI Coding 的价值非常真实。它可以加速探索、降低启动成本、帮助人理解陌生代码、生成测试草稿、重构样板代码、快速做内部工具。对独立开发者、设计师、产品经理、研究人员、学生和小团队来说，这是一种前所未有的创造力杠杆。

很多传统软件本来也很烂。手写代码同样会有安全漏洞、烂架构、无测试、无文档、无人负责。所谓“人写的就更好”是幻觉。

真正的分界线不是 AI 生成还是人类手写，而是有没有工程闭环。

有 spec、有边界、有 review、有测试、有安全扫描、有依赖治理、有可观测性、有回滚策略、有负责人，AI 代码就可以进入严肃工程流程。没有这些，手写代码也可能是 slop，只是生成速度慢一点。

犀利一点说：Vibe Slop 暴露的是管理层的幻想

当前最值得警惕的，不是新手用 AI 做玩具项目。

真正危险的是组织把 vibe coding 当成降低工程成本的捷径：既不补工程治理，也不增加安全预算，还希望业务团队、产品团队、外包团队和 junior 工程师用 AI 快速堆出内部系统。

这会制造一种非常诱人的错觉：软件终于变便宜了。

但便宜的是“写出第一版”的成本，不是“长期拥有这个系统”的成本。维护、审计、迁移、排障、安全、合规、数据治理、权限模型、组织协作，这些成本不会因为 AI 出现而消失。它们只是被推迟了，而且常常被推迟到最糟糕的时间点爆发。

Vibe Slop 的本质，是把软件工程中最贵的部分藏起来，然后只展示最便宜的部分。

我会怎么用 Vibe Coding

我不会拒绝 vibe coding，但我会给它划边界。

适合 vibe coding 的场景：

• 原型验证
• 一次性脚本
• 内部低风险工具
• UI 草稿
• 测试样例初稿
• 代码库探索
• 不熟悉技术栈的学习入口

不适合直接 vibe 到生产的场景：

• 认证、授权、支付、隐私、医疗、金融、风控
• 数据迁移和删除逻辑
• 权限边界复杂的后台系统
• 长期维护的核心业务系统
• 任何出了问题没人能解释的代码

如果一定要用，也必须加上硬门槛：需求文档、威胁建模、测试覆盖、依赖扫描、静态分析、人工 review、日志和回滚。

结论

Vibe Slop 不是 AI Coding 的反面，而是 AI Coding 缺少工程纪律后的自然结果。

它提醒我们，软件的瓶颈从来不只是“写代码”。真正难的是理解问题、约束系统、设计边界、验证行为、承担后果。

AI 让生成代码变便宜了，但它没有让正确性、安全性和责任变便宜。

未来优秀的工程师，不会是拒绝 AI 的人，也不会是盲目接受 AI 输出的人。真正有价值的人，是能把 AI 的速度接入严肃工程流程的人：让它快，但不让它乱；让它生成，但不让它逃避验证；让它帮忙，但不把判断力交出去。

这也是我对 Vibe Slop 最简短的判断：它不是技术问题的终点，而是工程文化的压力测试。