AI 生成的代码并非总是可直接运行，尤其是在复杂业务或特定框架版本下。以下方法能显著降低返工率，让生成结果更接近你的真实需求。
1. 上下文给足，避免“盲猜”
不要假设 AI 了解你的项目结构。涉及跨文件逻辑时，主动使用 @文件 或 @代码库（详见 3.4 节）把相关源码抛给 AI；如果使用了特殊工具库或内部封装，简单说明一句“我们项目使用自研的 utils/request.ts 做 HTTP 请求”，能避免 AI 给你生成一套标准 axios 代码却与你现有拦截器冲突。
2. 需求描述具体化
模糊的指令带来模糊的结果。
- ❌ “优化这段代码”
- ✅ “将这段双重循环优化为单次遍历，使用 Map 缓存中间结果，要求兼容 Node.js 18”
边界条件、异常处理、返回值格式最好一次性交代清楚，减少后续“再改一下”的轮次。
3. 复杂任务分步拆解
不要在一次对话里要求 AI “写一个带权限校验的完整的后台管理系统”。先让它输出接口定义和数据结构，确认无误后再生成核心逻辑，最后补充错误处理和日志。每轮对话聚焦一个明确目标，准确率远高于一次性生成大量代码。
4. 明确技术约束
如果你有限制，必须前置声明：
- 不允许引入新依赖（“只用原生 JavaScript，不使用 lodash”）；
- 框架版本锁定（“使用 Vue 3 Composition API，不要 Options 写法”）；
- 编码规范（“遵循项目已有的 ESLint 规则，使用单引号”）。
5. 生成即验证，不要直接合入生产
AI 尤其容易在 API 名称、参数顺序或版本差异上“幻觉”。拿到代码后：
- 先用 TypeScript 编译或 IDE 语法检查扫一遍基础错误；
- 对关键函数，用 Cursor 的 自动生成单元测试 功能（3.7.1）快速跑一遍边界场景；
- 涉及数据库或网络请求时，务必人工核对官方文档，确认方法真实存在。
6. 善用多轮修正，保留上下文
如果第一版结果有问题，直接在原对话中指出具体错误点（“第 15 行的 sort 会改变原数组，需要改为不改变原数组的实现”），AI 会在已有上下文基础上修正。比重新开一个新对话更高效，也更不容易丢失业务背景。
核心原则
把 AI 当作一个经验丰富的外包工程师：你描述得越精确、约束越清晰，交付物越符合预期；最终代码审查和测试的责任，始终在你。