模块四：迭代引导能力
出错时精准反馈，而不是推倒重来
AI 第一次输出完美的概率极低，但第二次修正后完美的概率极高。本讲讲怎么用精准反馈引导 AI 修正——方向性反馈、伪代码引导、模板化与节奏感。
为什么迭代引导比一次到位更重要
一个残酷的现实：AI 第一次输出完美的概率极低，但第二次修正后完美的概率极高。
这意味着真正的效率不在于"怎么让 AI 一次做对"，而在于"AI 做错后，怎么用最少的话让它改对"。
推倒重来 = 浪费前面所有的上下文积累。精准反馈 = 在 80% 的基础上只修 20%。
反馈的三个层次
┌────────────────────────────────────────────┐
│ Level 3：方向性反馈（最高效） │
│ "这个方向对，但边界条件没处理" │
│ → AI 保留主体逻辑，只补充边界处理 │
├────────────────────────────────────────────┤
│ Level 2：局部修正反馈 │
│ "第15行的判断条件反了，应该是 ===" │
│ → AI 只改指定位置 │
├────────────────────────────────────────────┤
│ Level 1：推倒重来（最低效） │
│ "不对，重新来" │
│ → AI 从零开始，可能犯完全不同的错 │
└────────────────────────────────────────────┘
永远尝试给 Level 3 或 Level 2 的反馈，只有在方向完全错误时才用 Level 1。
核心技巧
技巧一：指出"错在哪"而不是"重新做"
差：这段代码不对，重新写一个
好：这段代码的主逻辑是对的，但有两个问题：
1. updateDriveModeFromBack 调用时没有传 papStatus，应该传 data.papStatus
2. 缺少对 data 为 null 的保护
第一种方式丢弃了所有正确的部分；第二种方式保留了 90% 的成果，只修 10%。
技巧二：给出"期望行为"而不是"不要做什么"
差：不要用 any 类型
好：这里的 data 参数应该用 IUpdateDriveModeFromBackData 类型，
定义在 src/js/store/layoutStore/types.ts 中
"不要做 X"是负面约束，AI 需要自己猜该做什么。"应该做 Y"是正面指令，AI 直接执行。
技巧三：区分"逻辑错误"和"风格偏好"
这两类反馈的优先级完全不同：
| 类型 | 示例 | 处理方式 |
|---|---|---|
| 逻辑错误 | 条件判断反了、遗漏边界情况 | 立刻修正，这是 bug |
| 风格偏好 | 变量名不喜欢、想用不同的写法 | 一次性说完所有偏好，一次修正 |
常见错误：每次只说一个风格问题，来回 5 轮改变量名。正确做法：把所有风格问题攒一起说：
风格调整：
1. 变量 isParking 改名为 isParkingMode
2. 用 early return 代替嵌套 if
3. 日志信息用英文
技巧四：提供修正后的伪代码
如果你知道正确的逻辑但懒得写完整代码，给 AI 一段伪代码：
第15-20行的逻辑应该改成这样：
if (data.papStatus === EDriveMode.Parking) {
// 切到泊车布局
} else if (data.papStatus === EDriveMode.Driving) {
// 切回行车布局
} else {
// 忽略其他值
}
帮我按这个逻辑补完整代码。
AI 拿着伪代码来补全，比它自己重新理解需求再写要准确得多。
技巧五：用"接受 + 追加"代替"否定 + 重做"
差：这个实现不够好，重做
好：这个实现可以用，在这个基础上再加两点：
1. 加一个 loading 状态
2. 错误时展示 toast 提示
"在这个基础上"这六个字告诉 AI：保留现有代码，只做增量。
技巧六：分批反馈，不一次说完
如果 AI 输出了 100 行代码，你发现了 5 个问题，不要一次说完。分两批：
第1批：前3个问题（逻辑错误）
AI 修正...
第2批：后2个问题（风格偏好）
AI 修正...
原因：反馈太多，AI 可能在修问题 A 时引入新的问题，或者忘了修问题 D。分批可以控制每次的修改范围。
技巧七：当 AI 反复犯同一个错误
有时 AI 会在同一个坑里反复跌倒。这时候需要换一种沟通策略：
你已经第3次忘了在 makeObservable 里注册新的 action 了。
这是这个项目的一个硬性规则：
每次新增 action/observable/computed 方法，
都必须同步更新 constructor 中的 makeObservable 调用。
请先修正，然后检查你这次改动中是否还有其他遗漏。
关键词："硬性规则" —— 让 AI 提升这条约束的优先级。如果反复发生，把它写进 .trae/rules/project_rules.md。
迭代的节奏感
一次高效的迭代应该是这样的节奏：
你：提出任务
↓
AI：输出 v1（~80% 正确）
↓
你：精准反馈 2-3 个问题（30秒）
↓
AI：输出 v2（~95% 正确）
↓
你：微调 1 个细节（10秒）
↓
AI：输出 v3（✅ 完成）
↓
你：跑 lint + tsc，确认无误
整个过程 3 轮，每轮你的输入不超过 3 行。如果超过 5 轮还没搞定，说明问题应该被拆得更细（回到模块一）。
反馈模板
以下是不同场景下的反馈模板，直接套用：
逻辑修正
第{X}行的{函数/条件}逻辑有误：
- 当前行为：{描述当前代码做了什么}
- 期望行为：{描述正确的行为}
- 修改方式：{简要说明怎么改}
补充遗漏
功能基本完成，还需要补充：
1. {遗漏的边界条件}
2. {遗漏的错误处理}
3. {遗漏的资源释放}
风格调整
代码逻辑没问题，风格上调整几处：
1. {命名修改}
2. {写法偏好}
3. {格式调整}
方向纠偏
思路有偏差。你用的是{AI的方案}，但这个项目中应该用{正确的方案}。
原因：{简要说明为什么}
请按{正确的方案}重新实现，其他逻辑保持不变。
反模式 vs 正确做法
反模式一：模糊否定
差：这不太对
差：再想想
差：不够好
好：updateDriveModeFromBack 的参数类型错了，
应该是 IUpdateDriveModeFromBackData 而不是 any
反模式二：情绪化反馈
差：怎么又用 any 了？我说了多少次了不要用 any！
差：这代码写得太烂了
好：这里应该用具体类型，参考 types.ts 中的 IUpdateDriveModeFromBackData
AI 不会因为你骂它就写得更好，但精确的指令一定会让它写得更好。
反模式三：一次改太多东西
差：把类型改对，变量名也改一下，顺便把那个 if-else 改成 switch，
还有那个 console.log 换成 Logger
好：
第1轮：先把类型从 any 改成 IUpdateDriveModeFromBackData
第2轮：变量名和写法风格统一调整
实战练习
练习 1：反馈精确度训练
让 AI 写一个有一定复杂度的函数（比如"解析 URL query string 为对象"）。故意在拿到输出后，不管对不对，都找出 3 个可以改进的地方，用 Level 2 或 Level 3 的反馈方式告诉 AI。练习"快速定位问题 + 精确描述"的能力。
练习 2：反馈轮次优化
在你的下一次 AI 协作中，记录：
- 一共迭代了几轮
- 每轮你的反馈是几行字
- 哪些轮次的反馈导致了"退步"（AI 修了 A 问题但引入了 B 问题）
分析退步的原因，下次如何避免。
练习 3：模板化反馈
把上面的"反馈模板"应用到你的下 5 次 AI 交互中。记录模板化反馈 vs 自由发挥反馈的效果差异。
练习 4：极端情况处理
故意让 AI 做一个它不擅长的任务（比如根据一段模糊的需求描述写业务代码）。观察：
- AI 的第一版偏差有多大？
- 你需要几轮才能引导到正确方向？
- 过程中有没有"越改越歪"的情况？怎么拉回来？
思考题
反馈粒度的边界：Level 2 反馈要求你能精确定位问题。但如果你自己也不确定哪里有问题（比如代码能跑但结果不对），怎么给反馈？
负面反馈的效果：有些人发现对 AI 说"你之前写的代码有 bug"后，AI 会变得过度保守（加太多不必要的检查）。你遇到过这种情况吗？怎么平衡"让 AI 认识到错误"和"不让 AI 过度矫正"？
推倒重来的时机：Level 1 反馈（推倒重来）虽然低效，但有时是必要的。什么信号告诉你"这个方向不值得继续修补，应该重来"？
迭代引导 vs 自己动手：如果你花了 3 轮引导 AI 修正一段 20 行的代码，但你自己 5 分钟就能写完。这种情况下该引导 AI 还是自己写？判断标准是什么？
引导能力的可迁移性：这种"精准给反馈"的能力，在人与人的协作中（比如 Code Review、带新人）是不是同样重要？AI 时代的 Code Review 能力和传统的 Code Review 能力有什么异同？