智能题解验证，不能拿演示结果当能力结论
让模型解出一两道题，只能说明那几次输入、提示和运行环境下的流程走通了。它不能证明系统对同类题目稳定，也不能说明生成的代码在复杂输入、资源限制和错误环境下都安全可用。若验证只围着演示样例转，版本变化后出现退化时，团队甚至不知道是模型、提示、验证器还是运行环境出了问题。
更可靠的做法是把题解生成与判定分开，准备可重复的基准集，并把每次失败落到具体阶段。这样报告里的“通过率”才有范围和含义，而不是一张好看的截图。
基准集先覆盖真实的任务边界
每道题应有明确版本、输入约束、预期判定和可重复的测试数据。除了典型题，还要包括边界输入、已知反例、空值和异常格式，以及模型容易误解的条件。随机对拍或生成数据可以扩展覆盖，但必须保存随机种子和失败样本；否则下一次无法复现一次失败。
题目分布也需要有意识地选择。短函数题、状态机题、复杂图题和需要解释思路的题，难度和失败方式都不同。把它们混成一个总分，容易掩盖某一类别明显退化。报告至少应按任务类型和语言区分，必要时再按输入规模与是否调用工具分层。
基准不是越大越好。更重要的是每个样本为什么在里面、是否仍代表当前产品范围。题目版本变化后，旧答案和判定器也要同步审阅；否则测试通过的只是一个过期世界。
生成、解析和执行是三段不同的风险
模型返回的内容首先是外部输入。它可能不是预期结构、缺少代码块、混入说明文字，或给出不受支持的语言。解析阶段要把这些情况单独记录，并在失败时给出可解释的结果，而不是把异常文本直接送进编译器。
代码候选进入编译和执行环境后，仍需受到资源与权限限制。模型生成不等于可信代码：它可能死循环、占用大量内存、读取不该读取的路径，或触发不允许的系统调用。沙箱应保持既有的隔离、时限、内存和输出限制，不能为了提高演示成功率放宽规则。
编译失败、测试失败、超时、内存限制、沙箱启动失败和用户取消，应各自成为可观察阶段。把所有结果都归为“模型答错”，会掩盖验证器、镜像和基础设施的问题，也让后续优化没有方向。
通过覆盖的用例，不等于理解了题意
测试通过仅说明候选代码满足了当前覆盖到的输入。它不能保证复杂度符合要求，也不能证明算法在未覆盖的边界上正确。对于需要解释的题目，文字说明还应与最终代码对应；模型可能给出看似合理的思路，却附上一段做了别的事情的实现。
可以对关键题目增加复杂度约束、属性测试或人工复核，但这些方法各自也有边界。人工检查适合抽样发现误导性解释，不适合替代所有自动判定；属性测试能发现部分规律性错误，却依赖正确的属性设计。报告应如实说明覆盖范围，而不是把多个检查堆在一起就宣布完全可靠。
回归依靠相同条件下的比较
改模型、提示、解析器、镜像或资源参数时，都在同一套基准与同一口径下比较。记录每类失败数量、运行时间、资源超限和取消情况，并保留可追溯的版本信息。若某类题通过率上涨却超时更多，或解释更长却与代码不一致，这些取舍都应被看见。
故意注入非法输出、超时、沙箱失败和中断，确认系统会停止、清理并给用户正确反馈。正常样例走通只是最浅的一层验证；失败路径才决定服务在真实使用中是否可控。
智能题解系统值得追求的不是一次漂亮的展示，而是可复查的能力边界。基准集可重跑、阶段失败可区分、执行环境不因模型来源而放松，版本改动才有证据可依，也才能知道哪些任务目前还不该承诺。
