自动修复代码前先给它一条停止线自动修复适合处理边界清晰的失败例如缺少导入或明确的编译错误它不适合在同一份失败代码上无限尝试。每次尝试都消耗时间、token 和验证资源必须由外层调度器限制。停止条件至少包括任务截止时间、最大尝试次数、累计预算和错误类别。相同输出摘要连续出现可作为复核信号但不能单独判定为死循环某些确定性任务本来就会返回相同结果。func canRetry(ctx context.Context, attempt, used, maxAttempt, maxBudget int, retryable bool) bool { return ctx.Err() nil retryable attempt maxAttempt used maxBudget }复杂度分析也不能只依赖模型或循环层数。AST 可以发现结构特征基准测试可以观察增长趋势但摊还分析与输入相关的复杂度仍需要明确推导。Prompt 应只携带完成任务所需的约束和已验证错误避免堆入无关历史。每次终止都记录错误阶段、尝试数和脱敏诊断摘要。这样才能知道应优化提示词、修验证器还是停止把该类任务交给自动修复。上线前可以准备几类固定失败缺少导入、测试断言失败、依赖不存在以及验证器拒绝的高风险修改。分别确认哪些允许一次受控重试哪些应立即交给人工。自动修复的价值在于缩短明确问题的反馈回路不在于把所有失败都伪装成可以继续尝试的任务。