新手在使用 AI 编码时，有一些重复出现的错误模式。提前了解它们，可以帮助你避免大部分问题。
你会发现，这十个陷阱表面上看起来各不相同，但本质上都源于同一个问题：没有理解 AI 编码的底层逻辑。当你知道 AI 的上下文窗口有限、当你知道 AI 有自洽陷阱、当你知道 AI 的代码"看起来对"不等于"真的对"——你自然就不会踩这些坑。
这是新手最常犯的错误，也是后果最严重的。它包含三个具体的陷阱。
陷阱一：需求模糊就开工。 告诉 AI"帮我做一个博客系统"就等着它完工。结果 AI 做出了一个你不想要的博客系统——用了你不熟悉的技术栈，功能不符合你的预期。原因是 AI 没有读心术，它只能从训练数据中猜一个最可能的实现。你心里想的是"一个极简的、用 Markdown 写文章的个人博客"，AI 猜的是"一个功能完整的、带评论区和管理后台的企业博客"。蓝图五分钟，返工五小时。
陷阱七：不维护蓝图。 项目刚开始时写了一份蓝图，之后就再也没更新过。开发到一半，实际实现已经和蓝图不一样了。AI 后续生成的代码基于过期的蓝图，与现有代码不一致。原因是蓝图是"活文档"——开发过程中你会发现更好的方案、新的需求、架构调整，这些都应该及时更新到蓝图中。蓝图常更新，代码不迷路。
陷阱二：一次让 AI 做太多。 让 AI"实现整个用户管理模块，包括注册、登录、密码重置、个人资料编辑、头像上传"。AI 生成了大量代码，但很多地方不符合你的预期。原因是 AI 的任务越复杂，出错的概率越高——多个功能耦合在一起，一个错了可能影响其他。小步快跑，步步验收。
这是最容易被忽视的陷阱，因为它看起来"省时间"。
陷阱三：跳过验收。 AI 写的代码看起来不错，直接提交了。第二天发现功能有 bug，但已经提交到代码库。原因是 AI 生成的代码从语法上看往往是正确的——因为它是一个概率模型，生成的每一个 Token 都是"在当前上下文中概率最高的那个"。这意味着它的代码看起来"对"，但逻辑错误、边界情况、安全隐患不是一眼能看出来的。先验收，后提交。
陷阱四：在混乱代码上修修补补。 AI 生成了一段代码，你发现有很多小问题。你让它修了一个问题，结果引入了新的问题。再修，又出问题。如此循环，代码越来越乱。原因是当代码的基础架构有问题时，修修补补解决不了根本问题——在混乱的地基上，每一层都会歪。回滚不可耻，在错误基础上修补才可耻。
陷阱八：害怕回滚。 AI 代码出了问题，但你觉得"好不容易写了这么多，回滚了不就白做了"，于是继续在原基础上修修补补。结果越修越乱，最后花了更多时间。这是典型的"沉没成本谬误"——已经投入的时间让你不愿意放弃，即使继续投入只会损失更多。回滚成本约十分钟，修理成本可能两小时。舍不得回滚，就会花更多时间。
AI 编码的底层机制决定了"上下文"是核心资源。不理解这一点，就会踩坑。
陷阱五：忘记上下文会丢失。 和 AI 对话了两小时，做了很多功能。突然 AI 的表现变差了——它开始忘记之前做过的功能，或者之前已经解决的问题又出现了。原因是 AI 的对话上下文是有限的——随着对话变长，AI 会"忘记"之前的约定。写在蓝图里，别只靠 AI 记住。
陷阱六：过度依赖 AI 做决策。 遇到任何技术选择都问 AI。AI 推荐了一个方案，你直接采纳了，没有自己做判断。结果这个方案不适合你的场景。原因是 AI 的建议基于通用知识，不一定了解你的具体情况——它的推荐可能是"平均而言最好的"，而不是"对你的场景最好的"。AI 给建议，你做决定。
陷阱九：不学 git 基础。 没有用 git 管理代码，AI 改坏了文件后无法恢复。或者用了 git 但只会 git add 和 git commit，不会 git reset --hard 来回滚。git 是 AI 编码的安全网——没有 git，你就没有"后悔药"。不会 git，不敢重构。
陷阱十：追求完美主义。 AI 生成的代码已经很好了，但你觉得还不够完美——代码风格可以更好、性能可以再优化、可以支持更多功能。于是让 AI 反复修改，迟迟不进入下一个里程碑。AI 编码的效率容易让人产生"再改一下就更好了"的冲动——但很多时候，80 分的代码交付比 100 分的代码无限修改更有价值。先交付，再完美。
这就是所有十个陷阱。它们不是孤立的——当你理解了第一个（需求模糊就开工），你自然就会重视蓝图的维护（陷阱七）和里程碑的拆解（陷阱二）。当你理解了 AI 代码"看起来对"不等于"真的对"（陷阱三），你自然就不会跳过验收（陷阱四）和害怕回滚（陷阱八）。所以，不需要死记硬背这十个陷阱——理解背后的逻辑，自然就能避开它们。
十个陷阱表面上各不相同，但根因只有一个：没有理解 AI 编码的底层逻辑。 当你知道 AI 的上下文窗口有限，你就不会把重要信息只放在对话里；当你知道 AI 有自洽陷阱，你就不会跳过验收；当你知道 AI 的代码"看起来对"不等于"真的对"，你就不会害怕回滚。理解这些逻辑，比死记硬背十个陷阱更重要。附录中提供了术语表和常用命令供参考。
完整术语表见
common/glossary.md，此处仅列出本章涉及的核心术语。
| 术语 | 说明 |
|---|---|
| 蓝图（Blueprint） | 项目架构设计文档，即 CONTEXT.md |
| 里程碑（Milestone） | 一个可独立验收的功能单元 |
| 验收（Inspection） | 检查 AI 代码是否符合预期 |
| 回滚（Rollback） | 用 git 恢复到之前的干净状态 |
| 上下文（Context） | AI 能记住的对话信息量 |
| 架构偏移（Architecture Drift） | 代码偏离了原始设计 |
# 启动项目
npm run dev
# 提交代码
git add .
git commit -m "feat: 实现笔记列表功能"
# 回滚代码（谨慎使用，会丢失未提交的更改）
git reset --hard
# 查看修改历史
git log --oneline
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。