模型可以把“给孩子买两本书哪种组合划算”理解得更顺却不应该直接决定收银台扣多少钱。金额一旦进入支付链路规则版本、商品范围和取整方式都必须可核对。我会把这条边界放在接口上模型提交候选购物车代码重新核算展示确认后才进入结算。模型说得再有道理也不能跳过一次确定性计算。候选、校验与执行分开假设一家演示商店只有“满 300 元减 50 元”这一条规则。这里的金额都是分数量有明确上限。模型可能提出两种商品组合但价格必须来自服务端商品表不能信模型传回来的单价。package main import ( errors fmt ) type Item struct { SKU string; Qty int64 } func payable(cart []Item, prices map[string]int64) (int64, error) { if len(cart) 0 || len(cart) 20 { return 0, errors.New(invalid cart size) } var gross int64 seen : map[string]bool{} for _, item : range cart { price, ok : prices[item.SKU] if !ok || seen[item.SKU] || item.Qty 1 || item.Qty 10 || price 0 || price 1000000 { return 0, errors.New(invalid item) } seen[item.SKU] true gross price * item.Qty } if gross 30000 { return gross - 5000, nil } return gross, nil } func main() { prices : map[string]int64{A:15000, B:14999} for _, c : range [][]Item{ {{A,1},{B,1}}, {{A,2}}, {{A,1},{A,1}}, } { n, err : payable(c, prices) fmt.Printf(pay%d accepted%t\n, n, err nil) } }保存为 main.go 后运行 go run main.go。三个构造输入分别检查门槛以下、刚好达到门槛和重复 SKU。价格、条目数与数量上限也使本例的整数求和范围有界。真实商城还要加入库存、税费、互斥券、运费和价格快照这里没有假装覆盖这些规则。服务端重新计算还有一个好处模型提了一个不存在的优惠计算器会直接拒绝或忽略不存在的规则而不是继续为它编理由。推理成本要和任务质量放在一起看OpenAI 推理模型文档区分推理 token 与可见输出。请求即使没有返回可用答案也可能消耗推理预算。对用户来说等待时间也包括网络、工具、排队和重试不能只看首字出现得快不快。下面两件事值得做但本文没有模型接口实测用同一批带标准答案的购物车测试不同推理设置分别统计合法候选率、规则核验通过率、总耗时和完整任务费用。将“生成建议”与“找全局最优解”分开验收。前者可能足够改善搜索体验后者需要明确约束、穷举基线或可靠求解器不能靠一段解释证明。DeepSeek 当前模型与计价文档还区分模型版本、缓存与峰谷价格。一次测试的费用不能仅写“某模型每次多少钱”至少要带日期、版本、输入/输出量和计费时段。模型出错后系统能不能停在正确的位置候选无效时产品可以继续问一个澄清问题或者展示已核验的商品组合。最不该做的是拿上一次优惠结果凑一个“看起来顺畅”的答案。我更看重一个朴素的验收条件无论模型如何改写商品名、数量和优惠解释进入付款的金额都由同一套业务规则重新算出。它并不保证规则本身没有 bug所以仍需边界测试和订单对账但它让模型的错误停在建议层而不是直接变成资损。本地验证采用 Go 1.26.5只运行上述构造案例。没有调用真实模型没有评估转化率也没有得出任何生产降本比例。