Generate → Verify → Repair 如何做成可终止、可恢复且不会越修越坏的状态机？

题型：深入 · 明确状态、提交点、进步判断和人工出口。

建议回答

我会把每轮建模为 immutable candidate、verification report 和 repair patch，并记录 round、输入快照、Prompt、模型、Schema、评分与成本。状态可以是 generated、verifying、repairing、accepted、rejected 和 manual_review；只有 accepted 候选会发布给下游，其他版本保留用于比较和恢复。Worker 重启后从最后一个已提交状态继续，同一 round 和输入版本使用幂等键，避免重复发布。

Repair 默认只修改 Verifier 指出的字段或局部对象，生成新 candidate 后不仅复查旧问题，还要执行完整回归校验，防止修好人物动作却破坏场景或时间线。终止条件包括全部硬约束通过、达到最大轮数或预算、连续两轮无质量提升、同类问题反复出现、出现不可自动修复冲突，以及人工主动中止。达到上限后应保留最佳已知候选并转人工或明确失败，不能静默放行。

若修复对象已经触发图像或视频等昂贵副作用，应把文本候选接受与外部生成分成不同提交边界。结果未知时先查询产物和请求状态，不能因 Repair 重放而重复生成。

关键权衡

• 局部 Patch 可减少回归和 Token，但复杂关联错误可能需要整体再生成。
• 保留全部候选便于审计与回滚，却需要数据生命周期和存储成本控制。
• 更严格的终止标准提高质量，但可能增加人工介入和端到端延迟。

易错点

• 不要只设置最大轮数，还要检测无进展和问题振荡。
• 不要让 Verifier 直接修改正式结果，判断与变更职责应分离。