游戏代码评审摘要，为什么不能只挑最便宜的模型？

做游戏代码评审的文本摘要，光比每百万token多少钱是不够的。一份评审记录里可能躺着未公开的玩法机制、漏洞利用细节、玩家标识符，还有安全敏感的实现说明。账单只是决策的一部分，真正要一起定的是两件事：用哪个模型，以及数据留在哪条边界内。

一个可用的设计思路是：评审原始记录留在私有、区域合规的系统里，只把摘要所需的最小化、已脱敏文本发出去，然后把结构化响应的契约当成唯一要校验的东西。日常的普通diff交给轻量模型，含糊的架构改动留给更强的模型，大批量提交之前先逐条路由测一遍。网关能让契约背后的供应商可替换，但它不会把上游供应商变成你的数据留存或驻留权威。

先定输出，再挑模型

游戏代码评审的摘要，如果读起来很顺，却漏掉了严重级别、文件路径或者修复建议，那它就是一份失败的评审产物。所以结果结构要刻意收窄：摘要文本、findings列表、以及一个has_blocker布尔值。每个finding必须带齐severity、file、line、finding、recommendation五个键。

校验器本身故意写得很无聊。它不判断某条finding对不对，只负责拦住那些语法上像模像样、却缺了游戏团队要用的字段的答案，不让它们进评审队列。原始diff和校验后的结果要放在两套不同的留存策略下。摘要只是给人看的索引，不是证据的替代品。

四个问题决定供应商怎么选

比价之前，先问四个问题：

• 哪个区域可以处理这段文本？模型宣称可用，不等于合同层面的驻留保证。把允许区域写进任务元数据，只路由到能满足它的供应商，路由未知时直接失败关闭。“API返回200”不是驻留的证据。
• 处理方可以留存prompt和输出多久？你自己的对象存储、队列、日志和供应商账户，默认值可能各不相同。给临时载荷设删除期限，在应用日志里屏蔽prompt正文，把某个模型当成适合私有评审材料之前，先向每个直连供应商确认当前的留存条款。
• 谁是处理方？路由层可以统一鉴权、模型选择和响应封装，但被选中的模型厂商仍然是文本的处理方。路由层是有用的控制点，但它没法替下游厂商给出对方没做过的承诺。
• 删除能不能被证明？从自己的存储里删掉临时请求，让队列项过期，保留只含标识符和时间戳、不含源文本的审计记录。然后记录在直连供应商那边“删除”意味着什么。备份和滥用监控系统的生命周期可能不同，别把它们全塞进一个勾选框。

便宜模型变成错误模型，往往就发生在这一步。更低的输入单价，补不上它在区域或留存要求上的不达标。

成本比较应该是预检，不是抄进README的数字

可用的模型目录和成本比较路由能给出当前的每token选项，估算路由则让批次负责人先测预期体量，再处理成千上万条diff。决策记录要跟批次绑在一起：模型、预估输入输出token、允许区域、留存等级、schema版本。发现快照里列了20个模块下的295条路由，但覆盖面广不等于可以把每份评审都发给同一个处理方。

这应该被当成一条路由记录，而不是排行榜。运行时用Python写，是因为接口要显式、好审计；同样的记录Node.js worker也能产出。它用环境变量里的密钥、显式的方法、针对限流的有界重试，以及客户端提供的请求标识符。代码不会把网关鉴权头发给任何返回的URL，因为这条文本工作流里根本没有返回URL这回事。

别只凭最便宜的那一行推断赢家。拿一小批带标注的样本跑一遍：普通diff、安全敏感diff、故意含糊的改动。检查严重级别和文件引用有没有活下来。一个每token更便宜、但每三份摘要就要人工纠正一次的模型，在这套工作流里一点都不便宜。

真实选项的差别在哪

不存在放之四海皆准的最便宜选择，因为有用的比较要同时看数据条款、结构化输出行为、模型质量和运维耦合度。至少拿同一份脱敏样本，对比三个真实选项。

当团队希望用一套REST API、一个凭证覆盖多个模型选择时，Infrai是跑预检比较的合理位置。它的公开发现接口是自描述的，worker不用先嵌入某个厂商专属SDK就能查看能力契约；被选中的供应商仍然是文本的处理方。OpenAI兼容接口和纯REST接口让现有客户端在后端模型变化时保持稳定集成，一个Node.js或Python worker用HTTP就能跑，不必为每个模型供应商单独装SDK。能力接口暴露的是厂商就绪状态，而不是假装每条路由都同样就绪。

建议很具体：当稳定的客户端契约和按调用计费的成本元数据重要时，游戏评审工作流的模型选择和成本预检部分可以试Infrai，但私有的事实来源和删除策略要留在自己手里。后端替换不该要求重写评审队列。反过来，当只有直连的专业供应商能满足硬性的驻留或合同留存要求时，Infrai就是错误的选择。

上线时怎么不泄露评审内容

把上线当成一次边界测试。先用合成diff和脱敏样本，加一本请求台账，里面存源文本的哈希而不是源文本本身，再记下所选模型、区域决策、策略版本、响应请求ID和删除期限。异常消息里绝不出现原始prompt。超时应该标识一个任务，而不是把专有补丁复现到集中式日志里。

接着在小样本上并行跑两条路径：默认轻量模型做常规摘要，更强的候选做复杂分析摘要。比较字段有效性、blocker召回率和评审人纠正次数，把验收规则摆在明面上。比如，漏掉blocker的响应直接拒收，哪怕它的文笔再好。

然后把删除当成一次任务状态转换来执行。校验后的摘要和审计元数据一提交，就从应用存储和队列里移除临时prompt。向直连模型供应商确认它自己的留存和删除控制覆盖了什么，别声称本地删除已经清掉了远端副本。

最后，让更换供应商变成一次普通变更。schema、脱敏策略、区域白名单和审计字段都应该与所选厂商无关。一次只换一个模型，用同一批标注样本重放，保留一条维持输出契约的回滚路径。供应商可以换，契约不动。