别只对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 具体到可以直接验收。

抓手二：给示例——一个好例子胜过十句描述

记住一句话：模型对"示例"的拟合能力，远强于对"描述"的理解能力。

你说"代码风格要跟公司规范一致"——什么是规范？每个公司的"规范"都是一百条没写下来的习惯。不如直接贴二十行公司现有代码：

照这个类的风格写：分层、命名、注释密度、返回值包装，都对齐它。

示例的三种给法：

1. 正向样例："像这样写"——最常用，先给标杆再让它干；
2. 对比样例："不要这样，要这样"——适合纠偏，模型对反差最敏感；
3. 半成品样例："我起了个头，按这个骨架补全"——适合你对结构有明确预期的时候。

抓手三：给反馈——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. 回炉之后依然三轮无收敛——可能任务超出了当前模型的能力上限。换更强的模型；难题（复杂推理、架构设计）可以开推理模式，代价是更慢、更贵。
2. 模型开始"忘事"——前面聊好的约束后面被违背，这是上下文窗口被塞满了（第 1 讲的失忆机制）。解法不是拼命追问：开新会话，手动带上沉淀后的结论当背景——带精炼版，不带全量历史。
3. 任务要的不是"回答"，是"行动"——要它改十个文件、跑测试、看报错再修，对话窗口先天干不了这个，该换 Agent 类工具。这是第 14 讲的主题，先埋个钩子。

一句话：工具形态会过时，"追问—示例—反馈"的闭环不会。

五、课后练习：一次从失望到满意的完整迭代

拿一个你最近"问了一次就放弃"的任务（没有的话，就用阿K 的分页接口场景，代入你自己的技术栈），用三轮反馈闭环跑到底。

可验证产出——四个判据，缺一不可：

判据	标准
轮次	一条迭代了 ≥ 3 轮的完整对话记录
形式	每轮反馈用了「保留 / 修改 / 参考」三段式模板
质量	第 3 轮输出达到"可直接采用"
沉淀	最终 prompt 已按「场景-版本」命名存档

达标自查（这一步才是练习的核心）：把最终版 prompt 和第一版 prompt 摆在一起，指出三处"第一版没写清、靠迭代才补上"的信息。这三处，就是你下一个同类任务的 prompt 里第一天就该写上的东西——这就是从"你的经验"到"你的模板"的过程。

六、收尾：一个动作、一个问题、一句话

现在就可以做的第一步：打开你最近一次"问一次就放弃"的对话，把那一轮输出做一次三栏分拣（能用 / 要改 / 缺失），再用三段式模板回一条反馈。十分钟的事，你就能看到它和"不对，重写"的差别。

评论区聊聊：你让 AI 迭代时翻过最离谱的车是什么——改 A 崩 B？第三版把对的也删了？还是追问了八轮越改越烂？蹲一个最惨的案例，说说你最后是靠追问救回来的，还是回炉重写的。

对 AI 说一百遍"不对"， 不如说一遍"把这里改成这样"。

第一版输出是草稿，你的反馈才是接口的一部分。

入门篇到这一讲完结。三讲连起来其实就一句话：**知道它是什么（第 1 讲），把话说清楚（第 2 讲），不满意就继续说（第 3 讲）。**从下一讲开始，我们把这三件事塞进程序员的日常——先从最熟悉的场景开始：写代码。

下一讲预告：第 4 讲《结对编程：AI 当副驾，你当机长》——生成、重构、写测试，副驾能干的事和你必须亲自干的事，界线在哪。