本页目录5
这个考点是什么
迭代精炼（Iterative refinement）说的是这样一件事：面对一个模糊、或者容易一次改错的目标，不要指望靠一次 prompt 或一次大改就拿到理想结果，而是把过程拆成「给出→检查→反馈→再改」的小循环，让结果逐步收敛到你要的样子。
在 Claude Code 的语境下，这条考点主要落在三类场景里：
- 当散文式指令（比如「永远用 ISO 8601 格式」）已经重复强调过、但输出依然不一致时，该收紧的不是措辞的强度，而是指令的具体性——用几组覆盖边界情况的输入/输出示例（
multishot prompting）把目标行为钉死。 - 在正式动手实现之前，用「提问模式」（
interview pattern）让 Claude 反过来问需求方问题，把没说出口的假设、约束和风险逼出来，而不是拿着一份看似完整的规格直接开工。 - 当要同时修的几个问题之间存在交互（是否共享同一个中间结果/状态）时，批处理消息的方式要跟着交互性走：有耦合的放进同一条消息一起改，互相独立的问题拆开、逐条发送并验证。
这条考点本质上考的是「如何设计与 Claude 的来回节奏」，而不是某个具体命令的用法（命令层面的操作步骤站内指南已经覆盖，这里不重复）。
为什么考
出题的核心角度是：给一个「看起来该继续加大力度」的失败场景，考你能不能识别出真正该换的是技巧而不是强度。
典型套路包括：
-
散文指令重复两次仍不奏效，正确解法是转向具体示例而非加粗/重复措辞，也不是转去
plan mode或让 Claude 自己写个函数； -
高风险模块（如认证）实现前想挖出未预料的风险，正确解法是先用
interview pattern反问，而不是先给规格直接实现，也不是靠代码审查或预定义测试事后补救； -
几个改动同时存在时，批处理顺序按「是否存在数据/状态交互」分组，而不是按数量、复杂度或书写顺序分组。
这几个角度合起来覆盖的是「识别对症技巧」这一能力面。
核心辨析
- 1
示例（
multishot prompting）vs 加大强调当散文式规则重复强调仍不能纠正不一致的输出时，应该换成 2-3 组具体的输入/输出示例、并显式覆盖边界情况，而不是靠加粗、大写或重复同一句话来「更用力地」强调规则——强调只能提示重要性，不能消除规则本身的歧义。
- 2
interview pattern的适用边界目标是「实现前挖出未预料到的假设/风险」时，用
interview pattern让 Claude 先反问再设计；如果目标已经是「照着确定的规格实现」，直接给规格更合适；如果已经写完代码想补救，只能靠事后审查，已经错过了「提前发现」的时机；预定义测试套件只能验证想到过的场景，发现不了没想到的问题。 - 3
批处理按交互性分组，不按数量或顺序
多个改动同时存在时，判断依据是它们之间有没有共享的中间结果或状态——有交互的必须放进同一条消息让 Claude 一起处理，无关的独立问题应该拆开、逐条发送，并在验证前一条改动之后再进行下一条。
- 4
迭代精炼 vs
orchestrator-workers迭代精炼说的是「针对同一个产出物反复给反馈收敛」的节奏，前提是任务范围本身可控、可预判；如果子任务的范围和数量本身无法提前确定、需要动态拆解并分派给多个 worker，考的是
orchestrator-workers这个正交模式，不要混用迭代精炼的思路去作答。 - 5
迭代精炼 vs
prompt chainingprompt chaining处理的是有数据依赖的固定步骤流水线（上一步输出是下一步输入）；迭代精炼处理的是同一个目标上「人给反馈、Claude 改进」的循环。两者可能出现在同一个场景里，但判分点不同——固定步骤+数据依赖时优先考虑 chaining，反复试、反复纠偏时才是迭代精炼。
反模式对照
散文指令试了两次没用，继续加大措辞力度（加粗/全大写/多说几遍「一定要 ISO 8601」）
换成 2-3 组具体的输入→输出示例，并把两位数年份、歧义格式等边界情况也写进示例里
反复失败说明问题不是「没被重视」，而是规则本身有歧义；示例能把目标行为钉死到没有解释空间。
需求还没捋清楚就把一份「看似确定」的规格丢给 Claude 直接实现高风险模块
先用 interview pattern，让 Claude 反过来提问，把没说出口的约束、假设和风险问出来，再进入设计
直接实现只会把团队已有的盲点原封不动地固化进方案，不会额外浮现任何未预料到的问题。
两个会相互影响同一中间结果的逻辑 bug，拆到两条不同消息里分别让 Claude 修
有交互的改动放进同一条消息一起修；互相独立的问题（比如变量命名）之后再逐条发送、每条改完先验证
拆开修有耦合的问题，容易在改好一个的同时不知情地破坏另一个所依赖的前提，导致修复不完整。
遇到「输出格式不一致」这类小范围问题，尝试用 plan mode 来解决
格式类问题优先用具体示例澄清目标；plan mode 留给代码库探索和架构级设计决策
plan mode 解决的是探索和方案权衡的问题，不能消除具体输出格式上的歧义。