常见坑与避坑

Vibe Coding 最舒服的时刻，是你描述一个功能，AI 很快读文件、改代码、跑命令，看起来像多了一个经验丰富的搭档。

麻烦也在这里。它太顺了，你很容易放松警惕：没看 diff 就继续下一步，没跑项目就相信“已修复”，没确认上下文就让它改更大的范围。等项目开始报错，问题往往不是单个 bug，而是一串小失控叠在一起。

这一页不讲通用项目管理，只讲你在 AI 辅助编码里会反复遇到的坑。每个坑都可以提前识别，也都有比较实际的处理方式。

代码漂移：能跑，但越来越不像原项目

代码漂移指的是：AI 写出来的代码单看没问题，但风格、分层、命名和项目原来的方式逐渐偏离。

你可以从这些信号里识别它：

• 项目已有 services/，AI 又新建了一个 apiClient.ts。
• 同样的 loading 状态，旧代码用 isLoading，新代码开始用 loading、pending 混着来。
• 已有组件库或样式规范，AI 却写了一套新的按钮、弹窗和颜色。
• 一个简单功能被抽出好几个“看起来更通用”的 helper。

漂移最危险的地方是它短期不一定报错。Todo 页面能跑，登录也能跑，但每个功能都像不同人写的，后面维护会越来越费劲。

处理方式很直接：先让 AI 读已有模式，再让它改。

请先阅读 `src/features/todos` 里已有代码，说明当前项目的组件拆分、命名和状态管理方式。
然后再实现筛选功能，尽量沿用现有模式，不新增通用抽象。

如果已经漂移了，不要急着让 AI “整体优化”。先指出具体偏差：

这次改动中新建的 `request.ts` 和项目已有 `src/lib/http.ts` 重复。
请改为复用 `src/lib/http.ts`，不要保留第二套请求封装。

越具体，AI 越容易收回来。

上下文丢失：AI 开始给不符合项目现状的建议

上下文丢失不是模型突然变笨，而是它没有拿到当前任务需要的事实，或者对话太长后混进了过期信息。

常见表现包括：

• 它建议修改一个不存在的文件。
• 它引用了旧接口名，或者使用了项目里没有安装的库。
• 它把你的 Vite 项目当成 Next.js 项目处理。
• 它坚持一个你前面已经否定过的方案。

遇到这种情况，不要继续追问“你再想想”。更有效的是重建上下文。

当前项目不是 Next.js，而是 Vite + React。
请重新读取 `package.json`、`src/main.tsx` 和路由文件后，再给出修改方案。
不要基于上一轮回答继续推断。

如果对话已经很长，开新对话会更干净。带上当前事实、目标文件和本轮边界，比在旧对话里反复纠错更省力。

幻觉式修复：AI 说好了，但问题还在

幻觉式修复最常见的场景是你贴了报错，AI 很快改了几行，然后告诉你“现在应该可以正常运行”。你一跑，错误还在，或者换成另一个错误。

识别它可以看两个点。

第一，它有没有解释错误根因。如果它只是把某个类型断言、空值判断或 try/catch 加上去，但没有说明为什么这里会出错，就要小心。

第二，它有没有运行验证。如果它没有跑对应命令，只是根据代码推测，那就不能当作已修复。

更稳的提示方式是：

请先根据报错定位根因，不要直接改代码。
说明错误来自哪一行、为什么会触发、你准备怎么验证。
我确认后再修改。

如果已经改了但没修好，让它回到证据上：

刚才的修改没有解决问题。
请不要继续扩大改动范围，先对比报错前后的变化，说明当前错误和上一次错误是否相同。
只允许修改导致该错误的最小代码路径。

你要避免的是“AI 每次都动一点，问题范围却越来越大”。

范围蔓延：一个按钮改出了五个文件

范围蔓延通常发生在任务边界不清的时候。你让 AI “优化一下登录按钮”，它可能顺手改样式变量、重构表单组件、调整登录页布局，甚至补一个全局主题。

识别方式很简单：看 diff。如果本轮目标只涉及按钮文案和禁用态，却出现了路由、接口、配置、多个页面的变化，就已经蔓延了。

处理范围蔓延时，不要只说“改少一点”。要把允许修改的范围写清楚：

本轮只允许修改 `LoginForm.tsx`。
目标是让提交按钮在请求中显示 loading，并禁用重复点击。
不要改样式系统、路由、接口封装和其他页面。

AI 已经改多了怎么办？先让它解释 diff，再决定保留哪些。

请列出本轮改动的文件，并说明每个文件为什么必须修改。
与 loading 按钮无关的改动请撤回。

这里的重点不是“文件越少越好”，而是每个文件都要和本轮目标有明确关系。

过度依赖 AI 调试：错误修完了，但你没学到原因

把报错交给 AI 分析很正常。问题是，如果你每次都只是复制错误、等待修复、继续复制下一个错误，你会失去对项目的基本判断。下次同类问题出现，你还是不知道该看哪里。

这个坑在前端项目里很明显。比如页面白屏，控制台显示某个 hook 调用顺序异常。AI 可能能修，但如果你不知道 React hook 只能在组件顶层调用，后面写新功能时还会再犯。

更好的用法是让 AI 同时修代码和解释最小原因：

请修复这个报错。
修复后用两三句话解释根因，指出是哪条框架规则被违反。
不要写长教程，只说明我下次遇到同类错误先看哪里。

你不需要把每个底层原理都学到很深，但至少要知道错误属于哪一类：类型问题、异步状态问题、路由问题、构建配置问题，还是接口数据形状不匹配。

不验证就推进：错误被带进下一轮

AI Coding 里最贵的错误，经常不是某一行代码写错，而是你没有在那一轮发现它。

比如你让 AI 做 localStorage 持久化，没有刷新页面验证，就继续让它加筛选。筛选功能写完后发现数据丢失，你已经不知道是持久化没做好，还是筛选逻辑破坏了状态结构。

识别这个坑的方法也很直白：你是否能说清上一轮的验证结果。如果你只能说“AI 说完成了”，那就是没有验证。

每轮结束前可以固定问一句：

请告诉我本轮应该如何验证。
如果需要运行命令，请给出命令。
如果需要手动操作，请按步骤列出最短路径。

然后真的去跑。对于小功能，验证可能只需要一分钟。相比后面在混乱状态里排查，这一分钟很便宜。

过早抽象：AI 把小功能写成框架

AI 喜欢把代码写得“可扩展”。这在某些任务里是优点，但在项目早期容易变成负担。

你只是要一个 Todo 筛选，它可能生成一个通用 filter registry；你只是要一个确认弹窗，它可能做出一套 modal manager；你只是要保存本地设置，它可能引入复杂的状态同步层。

识别它的方式是问自己：当前需求真的需要这套抽象吗？如果未来两周内都用不到第二个场景，就先别抽。

可以在任务里提前写：

请优先实现直接、局部、容易理解的版本。
除非现有代码已经有相同抽象，否则不要新增通用框架或 registry。

如果 AI 已经抽过头，让它退回简单实现：

当前只需要 Todo 页面使用，不需要通用化。
请移除新增的 registry，把逻辑收回到当前组件或已有 hook 中。

抽象不是坏事，但时机很重要。AI 不知道你的项目后面会不会真的变大，你要替它判断。

安全边界被忽略：AI 开始动危险区域

当 AI 具备读写文件、运行命令、调用工具的能力时，你要特别留意高风险操作。比如删除数据、改权限、改支付逻辑、批量迁移文件、修改部署配置。

识别危险信号：

• 它准备运行会删除文件或重写历史的命令。
• 它修改了鉴权、支付、数据删除、生产环境配置。
• 它建议“先关闭校验”来绕过问题。
• 它在没有备份或测试的情况下做大范围迁移。

处理方式不是完全不用 AI，而是把权限收紧：

这个任务涉及鉴权逻辑。
请先只阅读相关文件并给出修改方案，不要直接编辑。
方案里需要说明影响范围、回归风险和验证步骤。

对危险命令，要让 AI 解释目的和影响。你不确定时，停下来查文档或自己判断，不要因为 AI 语气很确定就执行。

一个实际场景：页面白屏之后怎么办

假设你让 AI 给 Todo 页面加筛选，改完后页面白屏。

不稳的处理方式是：

页面白屏了，帮我修一下。

AI 可能开始到处补空值判断。

更稳的方式是把问题收窄：

刚才只改了 Todo 筛选功能，现在页面白屏。
请先查看浏览器控制台错误和本轮 git diff。
目标是恢复页面可运行，不要新增功能。
如果错误来自本轮改动，请优先回到最小修改。

这段话同时处理了几个坑：它让 AI 看证据，限制范围，避免顺手加功能，也把目标从“继续实现筛选”改成“先恢复可运行”。项目出问题时，先恢复稳定，再谈下一步。

Vibe Coding 不是把判断力交给 AI。更准确地说，它会放大你的判断：任务边界清楚，AI 会跑得很快；边界混乱，它也会很快把混乱扩散到代码里。