代码生成沙箱开发短记：先把失败收敛住

代码生成沙箱开发短记：先把失败收敛住

刷题演示里，模型能生成一段能跑的代码，就容易被当成系统已经可用。真实链路还有格式错误、无限循环、异常输出和反复修复。关键不是让模型多试几次，而是让每次尝试都有明确边界。

先校验输出结构与允许的语言，再把代码交给受限执行器。执行器需要独立的超时、内存、进程数、网络和输出大小限制；请求层还要限制总尝试次数。容器断网并不代表已经安全，宿主机挂载、临时目录和子进程回收也需要单独处理。

for attempt := 0; attempt < maxAttempts; attempt++ {
if err := ctx.Err(); err != nil { return err }
result := sandbox.Run(ctx, code)
if result.Passed || !result.Repairable { return result.Err }
}
return ErrRetryExhausted

反例是把编译错误原样连同宿主路径、所有测试输入反馈给模型。这样既可能泄露信息，也会让模型围绕测试投机。反馈应是截断、脱敏的失败摘要，并且每一轮继续使用同一请求的时间与资源预算。

验证时至少提交正常代码、语法错误、持续运行的程序和主动取消请求。确认超时后子进程被清理、输出被截断、错误能按阶段返回。测试通过只说明覆盖的用例通过；界面应说明验证范围，而不是把候选代码说成正确答案。

一次可检查的上线前演练

把同一段候选代码分别设置为“编译失败”“运行超时”和“输出超限”，核对接口中的阶段码、对用户可见的提示以及审计记录是否一致。再在取消请求后查看容器 ID 是否仍存活；只有这三个检查都通过，才把修复循环接入灰度流量。