别只对AI说“不对”：用三轮反馈把初稿改到可用
面对一份只有七十分的AI输出，简单回复“不对，重写”通常不会让结果稳定变好，反而可能修好一处又破坏另一处。问题往往不在模型是否听话，而在反馈缺少明确目标和修改边界。要让输出逐轮收敛，需要把不满意转化为可执行指令，并知道何时停止追问、重新整理提示词。
AI 越改越烂，锅多半不在模型——在你甩出那句"不对，重写"的瞬间。
你八成也干过：输出回来扫一眼，不满意的点明明有一堆，落到对话框里只剩两个字——"不对"。然后眼睁睁看着它在三个方向上随机乱撞。
这一篇就拆一套「三轮反馈闭环」：三个抓手、一个反馈模板、一条三振止损线，把七十分的第一版改到能用。
一、开场翻车：三次"不对"，三个灾难
阿K 最近学乖了。学完上一讲的提示词四要素，他给 prompt 也做了一次"代码规范"：
背景：Spring Boot + MyBatis-Plus 项目，接口给管理后台用。 任务：写一个订单分页查询接口，支持按状态和时间范围筛选。 约束：分页用 MyBatis-Plus 自带的 IPage；异常统一走全局异常处理器；参数校验用 @Validated。 格式：先 Controller，再 Service、Mapper，代码加注释。
输出回来了，代码能跑，分层也齐。阿K 扫一眼就皱眉：分页参数没用公司统一的 PageQuery 基类。他敲了一句：
不对，重写。
第二版回来了——PageQuery 有了，但查询条件写成了 JPA 风格的 Specification，把 MyBatis-Plus 的条件构造器扔了。阿K 更火：
还是不对，再来。
第三版——JPA 写法改回来了，但上一版里明明对的全局异常处理器没了。三版三个方向，每修一个错就崩一个对的。阿K 合上窗口，对旁边同事宣布：
"AI 写不了咱们的代码，别浪费时间了。"
把三轮对话摆在一起看，翻车路径一目了然：
| 轮次 | 阿K 说的 | 下一版发生的事 |
|---|---|---|
| v1 → v2 | "不对，重写" | PageQuery 补上了；查询条件却改成 JPA 风格，MyBatis-Plus 条件构造器没了 |
| v2 → v3 | "还是不对，再来" | JPA 写法改回来了；上一版明明对的全局异常处理器又没了 |
先别急着替阿K 委屈。复盘一下这场对话：第一版输出其实已经有七十分——结构对、能跑、注释全。翻车不是从第一版开始的，是从阿K 那句"不对"开始的。
三次"不对"，AI 实际收到的信息量是零。它不知道阿K 嫌哪里，只能每次换一个方向现猜——方向是随机的，所以错误也是随机的。这不是模型不行，这是反馈接口压根没实现。
（顺带埋个伏笔：阿K 的 prompt 里从头到尾没写过"分页参数要继承 PageQuery"——这条约束只存在于他脑子里。这是本场翻车的第二颗雷，讲到"三振回炉"时拆。）
二、核心方法：把反馈当接口设计
上一讲说，prompt 是接口契约。这一讲补上契约的后半句：第一版输出发出去之后，你的反馈就是这个接口的第二个入参。
带过实习生的人对这套流程太熟了。你不会对实习生只甩一句"不对，重做"——你会在他的 PR 里写：
"分页参数改成继承 PageQuery，其他不动；时间筛选你现在这么写可以。"
AI 和实习生在这一点上完全一样：它不知道你脑子里那个"对"长什么样。你不说，它就只能猜。
所以这一讲只讲一个方法：三轮反馈闭环。三个抓手，配一条纪律。先看全景：
抓手一：翻译——把"不满"翻译成"指令"
你对结果的所有模糊情绪，都要翻译成一条可执行的修改指令：
| 你嘴上说的 | 翻译后应该说 |
|---|---|
| "太啰嗦了" | "正文压到 300 字以内，只留操作步骤，删掉原理解释" |
| "不对" | "分页参数改成继承 PageQuery，字段从 page/size 改成 pageNum/pageSize" |
| "感觉差点意思" | "开头不要铺垫，第一段直接给结论" |
语言模板就一个：「把 X 改成 Y」。X 具体到字段、段落、行为；Y 具体到可以直接验收。
抓手二：给示例——一个好例子胜过十句描述
记住一句话：模型对"示例"的拟合能力，远强于对"描述"的理解能力。
你说"代码风格要跟公司规范一致"——什么是规范？每个公司的"规范"都是一百条没写下来的习惯。不如直接贴二十行公司现有代码：
照这个类的风格写：分层、命名、注释密度、返回值包装，都对齐它。
示例的三种给法：
- 正向样例："像这样写"——最常用，先给标杆再让它干；
- 对比样例："不要这样，要这样"——适合纠偏，模型对反差最敏感；
- 半成品样例："我起了个头，按这个骨架补全"——适合你对结构有明确预期的时候。
抓手三：给反馈——diff 式，必须标"保留项"
这是闭环里最阴的一个坑：**你让它改 A，它顺手把没让改的 B、C 也改了。**阿K 第三版丢掉全局异常处理器，就是这么来的。
原因第 1 讲讲过：模型每次都是全量重新生成，它没有"你只授权改这一处"的概念——除非你画边界。所以每轮反馈固定三段式：
保留：全局异常处理器、Controller 的接口签名——这两处别动。 修改：分页参数改成继承 PageQuery。 参考：（贴一段公司现有代码）
把模板填上真实场景，就是这张卡（建议存图，每次反馈照着填）：
"保留项"就是给这次改动画 scope，跟 code review 只评论 diff 行是同一条纪律。没有边界的重写，等于每次都让你的实习生把整个 PR 重开一遍。
一条纪律：三振回炉
三轮迭代还没有明显收敛，就停止追问，回炉重写 prompt（回第 2 讲的四要素）。
这不是玄学，是个止损阈值。底层逻辑：**追问是优化，救火靠回炉。**回到阿K 的案例——"分页参数继承 PageQuery"这条约束，他的 prompt 里压根没写。不回炉补上它，你追问一百轮，模型也是每轮现猜：关键信息从来没进过上下文，反馈再多也是隔靴搔痒。
判断标准就一句话：**这三轮是在收敛（每轮都更接近目标），还是在绕圈（每轮换个方向重来）？**绕圈，说明缺的不是修正，是背景。
三、常见错误：五种翻车姿势
五种最常见的翻车姿势——前四种是"迭代用力过猛"，第五种是"迭代懒得做"。对着自查：
| # | 姿势 | 现场表现 | 病根与解法 |
|---|---|---|---|
| 1 | 「不对」式打分 | 只有结论，没有方向；AI 瞎猜，猜错还要挨骂（阿K 主犯） | 反馈接口没实现 → 用第二节的三个抓手 |
| 2 | 动不动开新窗口 | 不满意就新开对话重来——上一轮的所有上下文被你自己清零了 | 第 1 讲说过：窗口之外等于没发生过。迭代的价值全在上下文累积，开新窗口等于每轮换个新实习生从头接手，还把他已经摸熟的背景全丢了 |
| 3 | 改 A 崩 B | 反馈不标保留项，全量重写没边界，每一版都是"按下葫芦浮起瓢" | 没画 scope → 三段式的「保留」行 |
| 4 | 无限追问不回炉 | 第五轮还在"再试一次"，把模型的随机性当自己的努力 | 没有止损阈值 → 三振回炉 |
| 5 | 第一版能用就将就 | 懒得迭代，七十分的代码直接合并上线 | 反向翻车：没经过一轮反馈就上线，跟自己的代码不跑测试就发布，是同一种堵薄 |
前四种的药方都在第二节里；第五种最隐蔽——它不疼，只是把七十分的东西送进了生产环境。
四、实操步骤：三轮反馈闭环操作手册
**第 0 步：先过 prompt 检查清单。**背景 / 任务 / 约束 / 格式，四项齐了再发（上一讲的活儿，这里只当 checklist 用）。
**第 1 步：输出回来，先做三栏分拣。**别急着回"不对"，先把结果分成三栏：
- ✅ 能用——这些就是下一轮的保留项；
- ? 要改——每条翻译成"把 X 改成 Y"；
- ➕ 缺失——注意，这一项大概率要回炉 prompt，而不是追问。
**第 2 步：套反馈模板。**模板卡见插图 3，每次反馈照着填：
保留：……（点名，别让它动） 修改：把 X 改成 Y 参考：……（示例 / 现有代码 / 反例） 理由：……（一句话说为什么——带理由的反馈，迁移到下一个任务时更准）
**第 3 步：每轮只提一个主问题。**最多两个。全提完等于没提——模型会平均用力，每处都改一点，每处都不到位。
**第 4 步：第三轮结束，做三振检查。**问自己一句话：在收敛，还是在绕圈？绕圈 → 回炉 prompt 补约束，不要开启第四轮追问。
**第 5 步：满意后立刻沉淀。**把「最终 prompt + 关键反馈」存进你的个人模板库。第 9 讲的毕业交付物——提示词资产库——地基就是从今天开始打的。
附栏：当前工具箱（2026-09）
时效隔离原则：正文只讲方法，本附栏讲工具形态。产品会换代，闭环不会。
| 任务形态 | 合适的工具形态 | 迭代方式 |
|---|---|---|
| 问答 / 写作 / 方案讨论 | 通用对话窗口（ChatGPT、Claude、Kimi、DeepSeek 等） | 在同一会话里追问、给示例、给反馈 |
| 改代码 | IDE 内嵌工具（Cursor、GitHub Copilot 类） | 迭代 = review diff：选中代码说改哪，看 diff 再给下一轮反馈 |
| 想多试几个方向 | "重新生成" / 分支对话功能 | 同一 prompt 重跑一次；或从某一轮岔出支线试别的方向，不打断主线 |
什么时候该换工具？三个信号：
- 回炉之后依然三轮无收敛——可能任务超出了当前模型的能力上限。换更强的模型；难题（复杂推理、架构设计）可以开推理模式，代价是更慢、更贵。
- 模型开始"忘事"——前面聊好的约束后面被违背，这是上下文窗口被塞满了（第 1 讲的失忆机制）。解法不是拼命追问：开新会话，手动带上沉淀后的结论当背景——带精炼版，不带全量历史。
- 任务要的不是"回答"，是"行动"——要它改十个文件、跑测试、看报错再修，对话窗口先天干不了这个，该换 Agent 类工具。这是第 14 讲的主题，先埋个钩子。
一句话：工具形态会过时，"追问—示例—反馈"的闭环不会。
五、课后练习：一次从失望到满意的完整迭代
拿一个你最近"问了一次就放弃"的任务（没有的话，就用阿K 的分页接口场景，代入你自己的技术栈），用三轮反馈闭环跑到底。
可验证产出——四个判据，缺一不可：
| 判据 | 标准 |
|---|---|
| 轮次 | 一条迭代了 ≥ 3 轮的完整对话记录 |
| 形式 | 每轮反馈用了「保留 / 修改 / 参考」三段式模板 |
| 质量 | 第 3 轮输出达到"可直接采用" |
| 沉淀 | 最终 prompt 已按「场景-版本」命名存档 |
达标自查（这一步才是练习的核心）：把最终版 prompt 和第一版 prompt 摆在一起，指出三处"第一版没写清、靠迭代才补上"的信息。这三处，就是你下一个同类任务的 prompt 里第一天就该写上的东西——这就是从"你的经验"到"你的模板"的过程。
六、收尾：一个动作、一个问题、一句话
现在就可以做的第一步：打开你最近一次"问一次就放弃"的对话，把那一轮输出做一次三栏分拣（能用 / 要改 / 缺失），再用三段式模板回一条反馈。十分钟的事，你就能看到它和"不对，重写"的差别。
评论区聊聊：你让 AI 迭代时翻过最离谱的车是什么——改 A 崩 B？第三版把对的也删了？还是追问了八轮越改越烂？蹲一个最惨的案例，说说你最后是靠追问救回来的，还是回炉重写的。
对 AI 说一百遍"不对"， 不如说一遍"把这里改成这样"。
第一版输出是草稿，你的反馈才是接口的一部分。
入门篇到这一讲完结。三讲连起来其实就一句话：**知道它是什么（第 1 讲），把话说清楚（第 2 讲），不满意就继续说（第 3 讲）。**从下一讲开始，我们把这三件事塞进程序员的日常——先从最熟悉的场景开始：写代码。
下一讲预告：第 4 讲《结对编程：AI 当副驾，你当机长》——生成、重构、写测试，副驾能干的事和你必须亲自干的事，界线在哪。
