校验、重试与反馈回路

核心机制是 validate → retry 的反馈闭环——先用 schema 或业务规则校验输出，失败后不是原样重发同一个 prompt，而是把校验失败的具体信息（原始输入、失败的输出、明确的错误描述）一并喂回模型，让它带着“哪里错了”的信息重新生成。

这个考点同时覆盖两类失败：一类是结构性的（JSON 格式错误，比如多余逗号、缺括号），另一类是语义性的（字段值不满足业务规则，比如金额总和与 total_amount 对不上）。两类失败的诊断入口不同，但都共享同一个反馈回路的骨架：定位具体错误 → 把错误信息作为上下文回灌 → 让模型自我修正，而不是靠正则打补丁或代码强行覆盖数据来“让校验通过”。

考点还延伸到“何时该继续重试、何时该止损”的边界判断：如果目标信息在源文档中根本不存在（比如文档只是引用了外部附件），再多轮反馈重试也无法收敛，这时该做的是排查数据可得性，而不是无脑加重试次数或换更大的模型。

此外，这个考点也会对照一个容易混淆的相邻场景：当“错误反馈”面对的是恶意注入的用户输入而非模型自身的输出错误时，不能靠模型自我纠正或一句反提示词解决，必须依赖 prompt 之外的程序化边界。

考察角度通常是给一个“输出不合规”或“重试仍失败”的场景，让考生在几个选项里辨认哪个才是真正的反馈驱动重试（把具体错误信息喂回），哪个只是“原样重跑碰运气”“正则打补丁”“提前升级人工/换模型”或“静默覆盖数据掩盖问题”。

题目常把干扰项设计得“看似合理但治标不治本”——比如误判问题类型（把语义错误当结构错误、把有数据当无数据）、用工程蛮力（加重试次数、换大模型）替代诊断、或者用更严格的措辞代替程序化校验。另一条常见考法是把“防止 prompt injection”包装成校验问题，考生需要辨别：防注入靠的是输入/输出边界的程序化控制，而不是指望模型自己“识破”恶意指令。