常见 anti-pattern 与避坑清单

本节目标

• 识别 8 个 Vibe Coding 常见反模式
• 知道每个反模式的修正动作
• 把"踩过的坑"变成团队的"禁做清单"

8 个 anti-pattern：

1. 不验证就合并        → 修：AI 代码必须跑测试/手测后才合
2. 一次生成大杂烩      → 修：拆小步，一次一件事
3. 无 git 基线就上 Agent → 修：先提交，出事可回退
4. 把机密喂公有模型    → 修：敏感走本地/授权模型
5. 盲信 AI 的 API      → 修：查官方文档+TS 守卫
6. 不写测试            → 修：关键路径补单测，修 bug 补回归
7. 直接上生产不审      → 修：强制 PR + Code Review
8. 把 AI 当架构师      → 修：架构/选型由人定，AI 做实现

使用方式：把这张表贴进团队 wiki，作为"AI 协作禁做清单"，Review 时逐条对照。

名词解释

• Anti-pattern（反模式）：看似方便实则有害的做法。识别它们比记住"正确做法"更实用，因为错误往往重复出现。
• 禁做清单（Don't-do List）：把高频错误显式列成"不要做"，比正面规范更易在评审时快速对照。
• 架构决策权：系统结构、技术选型等"方向性"决定必须由人做；AI 适合"在既定方向上实现细节"。

课后练习

1. 为什么"把 AI 当架构师"是反模式？
   • 答案：架构关乎长期可演进性、成本与风险权衡，需要领域判断与担责；AI 缺乏全局上下文与问责，不宜主导方向性决策。
2. "一次生成大杂烩"的危害是什么？
   • 答案：大块代码出错难定位、难 Review，且 AI 容易在长生成里前后不一致；拆小步更可控、更易验证。

总结

anti-pattern 清单是这门课最"防身"的一页。正面教"该怎么做"往往记不牢，但"别踩这些坑"会因为痛过而刻骨铭心。我列的 8 条，每一条都对应一个真实翻车现场：没基线就上 Agent 结果改崩全栈、盲信 API 上线即 500、不写测试修东漏西……把它们贴在团队 wiki 当"禁做清单"，评审时逐条打勾，比任何口号都管用。特别想强调第 8 条"别把 AI 当架构师"——这是最隐蔽的陷阱：AI 很会"侃架构"，但架构是权衡与担责的艺术，需要你对业务和未来的判断。让 AI 在既定方向上实现细节，把方向性决策留给自己，这个边界守住了，Vibe Coding 才是助力而非负债。