我用 AI 写项目这半年，踩过的坑和摸出来的套路

开头先说结论

AI 写代码这事，我一开始想得太简单了。

以为丢个需求过去，它就能给我吐出能用的代码。结果呢？越写越乱，逻辑断层，技术债堆成山。后来我才明白：问题不在 AI，在我自己没给它立规矩。

---

第一个坑：让 AI 直接生成整个项目

我最早做一个 Vue 项目，直接跟 AI 说："帮我生成一个 Vue3 + TypeScript 的项目。"

它确实给我生成了。但那个目录结构、那些配置文件，我根本不知道它为什么这么写。后来想改点东西，发现牵一发动全身，改不动。

后来我换了个做法：让 AI 告诉我该跑什么命令，我自己来执行。比如 npm create vite@latest，我自己敲，选项我自己选。这样项目底子是干净的，我知道每个配置是怎么来的。

这个教训让我意识到：地基必须自己打，AI 只能帮你搬砖。

---

第二个坑：需求没想清楚就开干

有一次我做一个后台管理系统，脑子里有个大概的想法，就直接让 AI 开始写。写到一半发现，用户权限这块我压根没想过。AI 写的代码里也没考虑这个，只能推倒重来。

现在我的做法是：先跟 AI 聊。不是让它写代码，是让它当产品经理，问我问题。

我会说："我想做一个 XX 系统，你来问我 10 个问题，帮我把需求想清楚。"

它问的问题有时候挺刁钻的，比如"用户删除数据后能不能恢复？""多人同时编辑怎么处理？"这些我自己没想到的点，被它一问就暴露出来了。

---

第三个发现：必须写清楚"我不要什么"

需求文档里光写"我要什么"不够。我后来加了一个章节叫"Non-Goals"，专门写我不要什么。

比如："这个版本不做多语言"、"不支持离线模式"、"不做移动端适配"。

为什么要写这个？因为 AI 太"热心"了。你不拦着它，它就会给你加各种它觉得"应该有"的功能。加完之后代码复杂度直接翻倍，维护起来想哭。

---

第四个套路：让 AI 站在未来维护者的角度审视

这是我觉得最有用的一招。

在正式开发前，我会让 AI 做一件事：

"请站在 3 个月后维护者的角度，找出这个需求和架构中可能让你后悔的地方。"

它会告诉我：

• 哪些功能看着简单，实现起来会很复杂
• 哪些设计以后扩展会很痛苦
• 哪些决定一旦做了就很难改

有一次它指出我的数据库设计里，订单和用户是强耦合的，以后想拆分会很麻烦。我当时没当回事，后来真的遇到这个问题，花了两天才改过来。

---

第五个坑：一次让 AI 干太多事

我试过让 AI 一口气写完一整个模块。结果代码质量参差不齐，有些地方写得还行，有些地方完全是乱来。

后来我学会了拆任务。一个模块拆成：

1. 先定义 TypeScript 类型
2. 再写 API 请求函数
3. 然后写静态组件
4. 最后把逻辑串起来

每次只让 AI 做一件事。这样它出错的概率小很多，我审查起来也轻松。

---

第六个发现：上下文会漂移

AI 没有记忆，或者说它的记忆很短。聊着聊着，它就忘了之前定的规矩。

我的解决办法是：每次对话都贴一个"项目上下文摘要"。

## 项目上下文
- 项目目标：XX 后台管理系统
- 当前阶段：用户管理模块开发
- 技术栈：Vue3, TypeScript, Pinia
- 禁止事项：禁止使用 any，禁止引入新依赖
- 本次任务：实现用户列表组件

这样它每次都能被拉回正轨。虽然麻烦，但比它跑偏了再改要省事得多。

---

第七个套路：给 AI 立规矩

我在项目里建了一个 AI_RULES.md，写清楚 AI 写代码必须遵守的规则：

• 禁止使用 any 类型
• 接口定义必须放在 @/types 目录
• 不允许擅自引入新的 npm 包
• 涉及技术选型必须先问我

这些规则每次对话都贴给它。效果很明显，它写出来的代码规范多了。

---

一个至今没解决的问题

AI 写的代码，我还是得一行行看。

它不会主动告诉你它写了什么"聪明"的东西。有时候它会偷偷加一些它觉得"应该有"的逻辑，不仔细看根本发现不了。

我试过让它"如果有更好的方案就挑战我"，但效果一般。它还是倾向于顺着我说的来，哪怕我说的不对。

所以现在我的原则是：AI 能帮我省掉一半体力活，但最后一步检查必须我自己来。

---

总结

用 AI 写项目这半年，我最大的体会是：它不是一个能独立干活的工程师，更像一个极其聪明但没有记忆、总想讨好你的实习生。

你得给它：

• 清晰的文档（它的"宪法"）
• 原子化的任务（它的"指令"）
• 严格的约束（它的"边界"）

做到这些，它确实能帮你提效。做不到，它就是一个高级的代码片段生成器，写出来的东西你还得花时间收拾。

这套方法我还在迭代。有些地方可能过一阵子我又会觉得不对，到时候再改。