企业官网建设流程全解析

自动修复代码前先给它一条停止线

自动修复适合处理边界清晰的失败，例如缺少导入或明确的编译错误；它不适合在同一份失败代码上无限尝试。每次尝试都消耗时间、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 应只携带完成任务所需的约束和已验证错误，避免堆入无关历史。

每次终止都记录错误阶段、尝试数和脱敏诊断摘要。这样才能知道应优化提示词、修验证器，还是停止把该类任务交给自动修复。

上线前可以准备几类固定失败：缺少导入、测试断言失败、依赖不存在，以及验证器拒绝的高风险修改。分别确认哪些允许一次受控重试，哪些应立即交给人工。自动修复的价值在于缩短明确问题的反馈回路，不在于把所有失败都伪装成可以继续尝试的任务。