直接把"帮我写一个包含用户认证、订单管理和支付回调的电商后台"丢给 AI，往往会导致接口对不上、逻辑遗漏、甚至变量未定义。处理复杂需求时，核心原则是把大任务切成 AI 能一次性做对的小单元，而不是指望它一次生成完美代码。
1. 先定契约，再填实现：分层描述
不要上来就要完整代码。第一轮先让 AI 输出核心数据结构、类型定义和模块接口（例如 TypeScript 的 interface 或 Python 的 dataclass），人工快速确认字段和类型无误后，再进入第二轮逐个实现函数体。在 Cursor 中，第一轮适合用 Ctrl/Cmd + L 侧边栏对话做架构设计；确定接口后，再针对单个函数用 Ctrl/Cmd + K 行内编辑完成实现。
2. 一步一确认，避免滚雪球
每轮提示词只聚焦一个可验证的子任务。例如：
- 第 1 轮：生成
OrderService的类结构和三个方法签名； - 第 2 轮：实现
createOrder的库存校验逻辑； - 第 3 轮：补充事务回滚和异常处理。
这样即使某一步跑偏，也只需要回滚最近一轮的修改。如果使用 Agent 模式（见 3.5 节），务必在任务描述里划定边界："仅修改 src/services/ 目录下的文件，不要动路由层和前端组件"。
3. 用 @ 指令锁定上下文
复杂需求必然跨文件，拆解时要配合 @ 引用（见 3.4 节）把 AI 的注意力约束在相关上下文中。例如：
- "参考
@schema.sql中的表结构，生成对应的 Prisma 模型"； - "对照
@types.ts里的PaymentResponse接口，补全payment.ts中的解析逻辑"。
这能防止 AI 在全局代码库中自由发挥，生成与现有风格不一致的冗余代码。
4. 给约束条件，不给开放题
把模糊需求转化为带边界的技术指令。对比：
- ❌ "优化这段代码"（AI 不知道你要什么）
- ✅ "将这段回调地狱重构为 async/await，保持原有错误处理逻辑，不引入 lodash 等新依赖"（目标明确）
在每一步拆解后的提示词中，建议包含三个要素：输入输出格式、技术约束、禁止修改的范围。
5. 草稿文件兜底
当拆解出的模块需要最终组装时，可以让 AI 先把中间产物写到临时文件（如 _draft.tsx 或 temp_utils.py），人工核对接口对齐后，再发一轮指令："把 _draft.tsx 中的逻辑合并到正式组件，并删除临时文件"。这比让 AI 直接在原文件上反复大面积修改更安全，也方便你用 Git 做阶段性回退。