生成代码后验证链路比自动修复更重要LLM 可以加快题解草稿的生成但它输出的代码仍是不可信输入。验证链路应把失败区分为格式、编译、测试、资源限制和基础设施错误不同错误的下一步不同不能把所有日志直接回填给模型重试。一条简单的流程是提取预期语言的代码块解析输出结构编译再在隔离环境中运行样例和边界用例。验证失败时保存任务 ID、语言、编译器版本、测试版本和经过截断、脱敏的诊断信息。这样才能复现问题并改进提示词或测试集。func extractCode(output, lang string) (string, error) { pattern : regexp.MustCompile((?s)(?: regexp.QuoteMeta(lang) )?\\s*\\n(.*?)\\n) matches : pattern.FindStringSubmatch(output) if len(matches) ! 2 { return , errors.New(未找到唯一的代码块) } return matches[1], nil }实际实现还应拒绝多个候选代码块并为不同语言使用明确的解析规则。不要把模型输出的 shell 命令交给宿主机执行。Docker 容器本身不是完整的安全边界。沙盒应限制 CPU、内存、进程数、运行时间、文件系统写入与网络访问使用非特权用户并避免挂载宿主机目录或 Docker socket。编译日志也可能含有用户代码片段回传前需要截断与脱敏。“自动修复”最多做有限次数的受控尝试只提供必要的错误摘要保持 token 与时间预算并让每一次候选代码重新经过同一套验证。最终是否采用题解仍应基于测试覆盖、复杂度审查和必要的人工复核。