坑一：架构腐化（“意大利面条式”代码）

现象：AI写单文件、单函数很强，但你让它直接生成一个包含登录、权限、增删改查的完整模块时，它往往会把所有逻辑塞在一个文件里，或者采用最简单粗暴的设计模式。随着项目变大，代码变得难以维护。
原因：AI没有“全局视野”，它只根据你当前的Prompt给出最直接的答案，缺乏长期架构规划能力。
解决方案：

1. “先设计，后生成”：不要一上来就让AI写代码。先用AI辅助生成README.md、技术选型文档、数据库ER图和API契约（如Swagger/OpenAPI规范）。
2. 强制目录规范：在项目根目录创建一个 CLAUDE.md 或 .cursorrules 文件，严格规定项目的分层结构（如Controller、Service、Dao分离，前端的状态管理目录结构等），让AI每次生成代码时都参考这个规范。
3. 使用Design Patterns Prompt：在提示词中明确指定设计模式，例如：“使用Repository模式封装数据库操作，使用DTO进行前后端数据传输”。

坑二：前后端接口对不上（“各说各话”）

现象：后端AI生成的接口返回 { code: 200, data: { user_id: 1 } }，前端AI请求时期望的是 { status: "success, userId: 1 }。联调时疯狂报错。
原因：AI在处理后端任务和前端任务时，处于两个独立的上下文中，没有“对齐”数据结构。
解决方案：

1. 契约驱动开发：先用AI生成标准的TypeScript类型定义（types/api.d.ts），或者OpenAPI JSON文件。
2. 共享上下文：在写前端请求代码时，把后端的接口文档或DTO代码直接贴给前端AI：“请根据以下后端返回的数据结构，编写前端的数据获取和类型断言代码：[贴入结构]”。
3. 全栈类型安全：使用 tRPC 或 monorepo 共享 types 的方式，让前后端共用一套类型定义，从根本上消除AI产生的类型不一致。

坑三：AI幻觉与“伪造API”

现象：AI调用了一个根本不存在的库方法（比如前端用了 react-dom/client 里没有的函数，或者后端用了某个ORM不存在的链式调用），导致编译失败或运行时报错 xxx is not a function。
原因：大模型的训练数据包含了大量过期或虚构的开源代码。
解决方案：

1. 指定版本号：Prompt中必须带上精确版本，例如：“使用 Vue 3.4+ 和 Element Plus 2.5 的语法”。
2. 善用RAG工具：尽量使用 Cursor 等带有 Codebase Indexing 功能的工具，让它基于你本地已安装的 node_modules 里的真实类型声明来生成代码，而不是靠“背诵”。
3. 查证机制：对AI给出的不熟悉的API，快速去官方文档扫一眼，不要直接无脑回车接受。

坑四：安全漏洞（“给黑客开大门”）

现象：AI为了快速实现功能，可能会写出存在SQL注入的原始拼接SQL、把密钥硬编码在代码里、或者前端直接暴露敏感后端逻辑。
原因：AI的优化目标是“完成任务”，而非“满足安全合规”。
解决方案：

1. 绝对不要把 .env 文件传给AI：在 .gitignore 和 AI 工具的忽略配置中屏蔽掉环境变量文件。
2. 强制使用ORM和参数化查询：在Prompt中死磕这一点：“禁止使用字符串拼接SQL，必须使用 Prisma/TypeORM/MyBatis 的参数绑定方式”。
3. 引入AI安全扫描：代码写完后，不要让AI自己审查，使用专业的工具（如 SonarQube、Snyk）进行扫描，或者专门开一个Chat窗口，只输入代码让它做安全审计。

坑五：UI/UX灾难（“Tailwind默认风”与缺乏交互）

现象：AI写出的前端页面能跑，但长得像十年前的后台管理系统，或者满屏都是Tailwind的默认蓝色，缺乏Hover效果、Loading状态、空状态处理。
原因：AI是逻辑机器，缺乏“审美”和“用户体验同理心”。
解决方案：

1. 基于UI组件库开发：绝对不要让AI从零写CSS。明确要求：“仅使用 Shadcn UI / Ant Design 的现有组件进行组合，不要自定义底层样式”。
2. 分步细化Prompt：
   • 第一步：“画出基础布局”
   • 第二步：“为这个表格添加骨架屏Loading状态”
   • 第三步：“当数据为空时，显示一个友好的Empty提示，并带有重试按钮”
3. 参考图生成：如果你用支持视觉的AI（如Claude 3.5 Sonnet或v0.dev），截一张你喜欢的竞品UI图让它模仿，比用文字描述效果好10倍。

坑六：上下文污染与“越改越乱”

现象：项目改到第10天，你让AI修改一个Bug，AI不仅没改好，还把之前运行正常的代码逻辑破坏了。
原因：AI的上下文窗口被塞满了无效的报错信息、废弃的代码片段，导致它“精神分裂”。
解决方案：

1. 勤开新Chat：一个Chat只解决一个特定的问题（比如“解决登录Token过期问题”），不要在一个Chat里聊整个项目的演进。
2. 精准引用：使用Cursor的 @ 符号精准引用相关文件，不要让AI去“猜”问题在哪。
3. 提供最小复现路径：报错信息不要全贴，提取核心的 Error Stack，并附带你认为最可疑的20行代码。

坑七：开发者的“认知退化”

现象：离开AI完全写不出代码，遇到AI给出的烂代码也看不懂，导致项目最终无法收尾（因为AI无法对整个复杂系统负责）。
原因：把AI当成了“代写”而不是“副驾驶”。
解决方案：

1. 转变角色定位：你要把自己当成 Tech Lead（技术负责人）+ 代码审查者，AI是你的初级程序员。
2. 拒绝盲盒代码：接受AI代码前，必须能口述出这段代码的逻辑。如果看不懂，问AI：“请逐行解释这段代码的执行顺序”，直到你完全理解为止。
3. 手动Debug：遇到Bug时，先自己看日志分析5分钟，得出初步结论，然后再把你的结论和代码发给AI验证，而不是直接把报错扔给AI。

💡 总结：全栈AI开发的“黄金法则”

“AI负责微观实现，人类负责宏观连接。”

永远不要对AI说：“帮我写一个电商系统”。
正确的做法是：

1. “帮我设计电商系统的数据库表结构。” -> 人工审查。
2. “基于这个表结构，用Prisma生成Schema。” -> 人工验证。
3. “基于这个Schema，写后端的创建订单接口，要求用事务处理库存扣减。” -> 人工Review。
4. “基于后端的API响应格式，写前端的提交订单按钮和Loading状态。” -> 人工联调。

把全栈的复杂性拆解，让AI每次只处理一个清晰的切片，才是全栈开发用AI的终极解法。

视频课程完整地址：https://edu.csdn.net/course/detail/41103