跳转至

VibeCoding的陷阱与应对

Vibe Coding 让你飞起来，但也容易让你摔得很惨。本篇系统整理 Vibe Coding 的常见陷阱、出现原因、应对策略。不踩这些坑的人，才能真正享受 Vibe 的红利。

1. 陷阱图谱

┌─────────────────────────────────────┐
│ 1. 看不懂自己的代码                    │
│ 2. 技术债积累                         │
│ 3. 测试覆盖率为零                      │
│ 4. 安全问题                           │
│ 5. 过度依赖                           │
│ 6. AI 幻觉                           │
│ 7. 上下文衰减                         │
│ 8. 无尽的"再迭代一次"                 │
│ 9. Token 烧钱                        │
│ 10. 失控的复杂度                      │
└─────────────────────────────────────┘

下面逐个拆解。

2. 陷阱 1：看不懂自己的代码

表现

AI 引入了陌生的库、用了你不熟悉的设计模式。功能能跑，但出问题时你完全无从下手。

出现原因

  • AI 倾向于用"它知道"的东西，可能不是你熟悉的
  • 你 Vibe 时只看效果，没看代码

后果

  • bug 修不动
  • 性能问题查不出
  • 安全风险看不出

应对

强制让 AI 解释每次改动：

每次改完代码，请用 3 句话告诉我：
1. 你做了什么改动？
2. 为什么这么改？
3. 引入了哪些新依赖、新模式？

如果引入了我可能不熟悉的东西，多解释几句。

定期 review session：每周/每个里程碑，让 AI 把整个项目的核心逻辑用 5 段话讲清楚。

3. 陷阱 2：技术债积累

表现

代码越改越乱： - 同样的功能写了 3 个变体 - 死代码堆积 - 文件越来越长（AI 不愿意删） - 命名不一致

出现原因

AI 的默认倾向：加代码，不删代码。每次"修复"是加 if-else 而不是改设计。

应对

定期重构 session，明确指示"只清理不加功能"：

今天的任务：清理代码债。

请：
1. 找出所有重复代码
2. 找出未使用的导入、变量、函数
3. 找出过长的函数（> 50 行）
4. 找出过长的文件（> 300 行）

输出：清理计划，不要立即改。

约束：不能改任何已有功能的行为。

频率建议：每完成 5-10 个新功能，做一次清理。

4. 陷阱 3：测试覆盖率为零

表现

项目跑得好好的，直到某次改动引入了 5 个 bug，没有测试发现。

出现原因

  • Vibe 模式下，没人会主动写测试
  • AI 默认不会写（除非你要求）
  • "看着对就行"的心态

应对

从一开始就让 AI 写测试。提示词模板里加：

每个功能完成后：
1. 写对应的单元测试
2. 至少覆盖：正常路径、边界、异常
3. 用 vitest / jest（按项目栈）
4. 测试和实现在同一个 PR 里

每次 PR 包含测试变成默认。

进阶：让 AI 自动跑测试

Cursor / Claude Code 都能跑命令。每次改完：

改完后跑 npm test，把失败的测试给我。

5. 陷阱 4：安全问题

表现

  • API key 写进前端代码
  • SQL 拼接字符串
  • CORS 全开（*）
  • 密码明文存储
  • 敏感信息写进 console.log

出现原因

AI 优先实现"能跑"，不优先"安全"。

应对

项目宪法里加安全约束：

.cursorrules 或 CLAUDE.md：

【安全约束（红线）】
- 任何密钥、token 都不能写进前端代码
- 任何用户输入都视为不可信，必须校验
- SQL 用参数化查询，绝不拼接字符串
- CORS 必须明确域名，不能用 *
- 密码用 bcrypt / argon2 哈希
- 永远不要 console.log 密码、token、PII
- 涉及钱、权限、用户数据的代码必须人审

如果代码涉及安全敏感操作，必须显式提醒我。

生产代码必过人审：哪怕你信任 AI，敏感代码必须自己看一遍。

强烈推荐：跑 SAST 工具

# 静态安全分析
npm audit
semgrep --config=auto
gitleaks detect

可以用 git pre-commit hook 自动跑。

6. 陷阱 5：过度依赖

表现

  • 离了 AI 就不会编程了
  • 简单语法都要问
  • 遇到 AI 解决不了的问题彻底卡住
  • 写文档、想方案也依赖 AI

出现原因

短期效率高 → 不刻意练 → 能力萎缩。

应对

主动留出"无 AI 时间"：

  • 每周 1 天不用 AI 编程
  • 学新技术的前 1 小时不用 AI
  • 重要决策不用 AI 替你想

判断什么时候必须自己想：

  • 架构 / 设计决策
  • 商业 / 产品决策
  • 性能瓶颈分析
  • 复杂 bug 的根因
  • 团队协作中的取舍

核心原则：让 AI 当工具，不当大脑。

7. 陷阱 6：AI 幻觉

表现

  • 引用不存在的库、API
  • 调用过时的接口（已被弃用）
  • "权威地"给出错误信息
  • 写出语法对但语义错的代码

出现原因

LLM 本质是"概率生成"，不是"知识检索"。它会"编"听起来对的内容。

应对

永远要跑一遍。看起来对不算对。

不熟悉的库先查文档：

你要使用 X 库。

不要凭记忆写。
请先：
1. 用 web search 查最新文档
2. 确认 API 签名
3. 再写代码

Cursor 和 Claude Code 都支持网页搜索。强制 AI 查比让它"记忆"靠谱。

给 AI 真实文件名 / API 名：

我用的是 react-query v5，不是 v4。
查询 hook 是 useQuery，参数对象包含 queryKey 和 queryFn。

8. 陷阱 7：上下文衰减

表现

聊到第 30 轮，AI 开始"忘"早期的约束： - 重命名了你说不要改的变量 - 引入了你禁止的依赖 - 改回了你修复的 bug

出现原因

LLM 的注意力对长上下文逐渐衰减。

应对

项目规则文件（.cursorrules / CLAUDE.md）—— 每次都自动加载，比对话里的约束稳定。

定期开新对话：

  • 完成一个里程碑就开新对话
  • 总结当前状态：3-5 句话告诉 AI"我们到哪了"
  • 继续

重要约束在每次提示开头重申（特别是临时约束）：

（再说一遍约束：不要改 router.ts，不要引入 lodash）

任务：……

9. 陷阱 8：无尽的"再迭代一次"

表现

一个简单功能改了 20 轮，每一版都"差一点点"，永远到不了"完美"。

出现原因

  • 没有"完成"的明确标准
  • 你自己也不知道想要什么
  • 改一处坏一处

应对

改动前定 DoD（Definition of Done）：

这个功能完成的标准：
- [ ] 能添加 / 删除 / 编辑
- [ ] 数据持久化
- [ ] 通过 5 个测试用例
- [ ] UI 在 768px 以上显示正常
- [ ] 通过浏览器手动验证（用户路径 1、2、3）

满足全部 = 完成，停止迭代。

明确清单，满足就停，不要无限优化。

承认"够用就好"：90% 的功能不需要完美，只需要"能用且不坑"。

10. 陷阱 9：Token 烧钱

表现

  • 月底账单震惊：$200+
  • 长上下文无限增长
  • 每次都重读整个项目

出现原因

  • AI 每次调用都消耗 token
  • 长对话累积成本指数增长
  • 没限制范围（"读所有文件"）

应对

控制上下文：

  • @ 引用具体文件，不要整个项目
  • 长任务拆 session
  • 不需要的旧对话清掉

用更便宜的模型做简单任务：

任务 模型
复杂规划、架构决策 Opus
日常编辑 Sonnet
样板代码、补全 Haiku

监控：定期看账单，超预算就调模型。

11. 陷阱 10：失控的复杂度

表现

项目越长越大，越来越难维护。每次改动都担心破坏什么。

出现原因

  • AI 倾向于"加抽象"
  • 每个新需求一个新文件
  • 没有人审视全局

应对

定期"瘦身"：

任务：审视项目结构，给我一份"瘦身建议"。

找出：
1. 不必要的抽象
2. 可以合并的文件
3. 过度工程化的部分
4. 用了但不必要的依赖

输出建议清单，不要立即改。

保持可视化：让 AI 画项目架构图（mermaid），你看不懂的地方说明太复杂了。

12. 综合应对：Vibe Coding 的"安全清单"

每个项目开始时建立这个清单：

[项目宪法]
□ 创建 .cursorrules / CLAUDE.md
□ 列出技术栈、风格、禁止项

[安全]
□ 安全约束写进项目宪法
□ 配置 git secrets / gitleaks
□ npm audit 自动检查

[质量]
□ 测试要求写进项目宪法
□ 配置 pre-commit hook（lint、format）
□ 关键模块必须人审

[版本管理]
□ 每个稳定版本就 commit
□ 写清楚的 commit message
□ 大改动建分支

[流程]
□ 改前定 DoD
□ 改后跑测试
□ 改后人审关键模块

[长期]
□ 每 5-10 个功能做一次清理 session
□ 每月看一次成本
□ 留 1 天 / 周不用 AI

每个项目过一遍，受益巨大。

13. 一个真实事故

某独立开发者用 Cursor + GPT 做了一个 SaaS：

Day 1-30：飞速开发，Vibe 上线 MVP，付费用户 100 人

Day 31：发现 API key 写进了前端

Day 32：紧急轮换 key，但已经被人薅了，亏了 $3000 OpenAI 余额

Day 33-40：发现还有 SQL 注入和未授权访问

Day 41：花一周补救，期间用户流失

复盘原因：

  • 没有 .cursorrules 写安全约束
  • 没有人审过敏感代码
  • 没有 SAST 工具
  • 没有 git secrets

总结教训：Vibe Coding 不等于不用工程纪律。

14. 哲学：Vibe 的边界

Vibe Coding 适合： - 创造性的探索 - 不可逆但不致命的尝试 - 学习新东西 - 重复样板代码

Vibe Coding 不适合： - 涉及钱、权限、用户隐私的代码（认证、支付、PII） - 高并发、高性能场景 - 嵌入式、底层、安全关键 - 需要长期维护的开源核心

关键判断：你能不能审出 AI 写错？能 → Vibe；不能 → 自己写。

总结

  • Vibe Coding 的 10 大陷阱：看不懂代码、技术债、零测试、安全、过度依赖、幻觉、上下文衰减、无尽迭代、烧钱、失控复杂度
  • 看不懂代码 → 强制 AI 解释，定期 review session
  • 技术债 → 每 5-10 个功能做清理 session
  • 零测试 → 提示词模板里把测试列为默认要求
  • 安全 → 项目宪法里写安全红线，敏感代码必过人审
  • 过度依赖 → 每周留 1 天不用 AI，关键决策自己想
  • 幻觉 → 永远跑一遍，不熟悉的库强制 AI 查文档
  • 上下文衰减 → 项目规则文件 + 定期开新对话
  • 无尽迭代 → 改动前定 DoD，满足就停
  • 烧钱 → 简单任务用便宜模型，控制上下文
  • 复杂度失控 → 定期瘦身，画架构图自检
  • 终极原则：Vibe Coding 不是不用工程纪律，反而需要更严的纪律

评论