代码生成服务开发短记看延迟、成本和有效性模型路由不能只按题目里有没有“动态规划”这类关键词。模型规模、上下文长度、题目约束和校验器都会影响结果。真正要比较的是在同一批任务和预算下哪种策略给出了更多通过验证的答案以及它为此消耗了多少时间和资源。路由前可使用规则、用户选择或已验证的特征分层但结果必须经过同一套沙箱或测试校验。缓存键要包含题目版本、语言、提示词或模型配置等隔离字段语义相近不表示可以跨用户或跨约束复用。if cached and cached.matches(question_version, language, prompt_version): return cached.result return generate_and_verify(request)反例是把小模型失败的请求自动转给大模型再把多次调用累加的成本忽略掉。此时“首次模型成本低”没有意义。每个请求应记录排队、生成、验证、重试和缓存命中失败和取消也要计入预算。验证使用固定题集并按题型分组比较校验通过率、尾部延迟、每个有效结果的实际成本和回退率。若一种路由只在少数题型上更好就把适用范围写清楚。系统的目标不是让单项数字好看而是在已声明的约束内提供可验证的结果。防止评估漂移题集要冻结题面、校验器版本和统计脚本并把新题与历史题分开报告。上线后随机抽取一小批真实但已脱敏的请求进行离线复核若通过率变化先确认题目分布与校验器没有变化再讨论模型或路由是否真的退化。每次评估生成不可编辑的结果快照至少保存任务 ID、策略版本、校验结论和聚合脚本的提交号。这样看板上的一次波动才能被还原而不是靠回忆解释。