为了节省 Token 而被你剥离的思维链，其实隐藏着一项合规证据要求

一个平台团队发布了一次提示词重构，将平均响应成本降低了 32%。这个改动非常简单：剥离了 “解释你的推理过程” 前导语，要求模型仅返回 JSON 对象，并删除了从模型文本中解析推理逻辑的后处理步骤。仪表板变绿了。季度回顾中的单位经济效益页面从黄色变为了金色。平台团队中没有人想到要咨询风险团队，因为这个改动没有触及客户收到的任何答案。

两个季度后，一位受监管客户的审计员要求提供一份六个月前的贷款拒绝信的决策理由。团队调取了追踪记录。输入在那，输出也在那。推理过程消失了 —— 不是因为有人删除了它，而是因为它在重构发布的那天起就停止生成了。客户的合规计划一直运行在推理逻辑存储在追踪记录库中的假设之上；平台团队一直运行在推理逻辑不是任何人的问题，因为面向客户的答案没有变化的假设之上。孤立来看，这两个假设都是正确的。但结合在一起，它们让客户面临了一项监管违规审计发现，并让平台团队失去了一份合同续签。

这个教训听起来像是流程失效，事实也的确如此。但更深层次的教训是结构性的：推理 Token（Reasoning tokens）是一种双重用途产物。对于优化单次请求成本的工程团队来说，它们是以每百万美元计价的成本细目。对于辩护信贷决策的风险团队来说，它们是模型 “为什么” 存在的唯一场所。当同一字节流服务于两个保留周期和质量标准完全不重叠的受众时，你无法在不咨询另一方的情况下优化其中一方 —— 而大多数平台团队甚至不知道还有另一方的存在。

推理 Token 同时存在于两种成本模型中

在线上，推理 Token 的成本与输出 Token 相同 —— 有时甚至更高，当供应商对 “思考” Token 收取溢价时。一个为了证明 50 个 Token 的答案而生成 800 个推理 Token 的模型，其可见输出的成本翻了 18 倍。在单位经济效益仪表板上，这个比例看起来像是浪费。在合规仪表板上，这个比例则是整个产品的核心。

这两个仪表板存在于同一个字节流上，并为其分配了互不兼容的价值。工程团队希望比例是 1:1。合规团队则希望比例达到 “足以通过审计” 的任何程度。拥有提示词控制权的几乎总是工程团队。而依赖输出的团队在提示词发生变化时，几乎总是不在场。

这种不对称性就是 Bug 的根源。如果推理 Token 的账单由风险团队拥有的预算额度支付，那么没有哪个平台工程师会在不进行沟通的情况下动它们。但事实并非如此。它们被计入基础设施拥有的推理预算中，针对一个与可审计性毫无关系的目标进行优化。要求模型 “仅以 JSON 回答” 的提示词是一个完美的局部最优解，但它产生了一个在全局上无法辩解的产物。

看起来像优化的失效模式

有三种模式可以可靠地破坏证据链，且直到审计员到来之前都没有人会察觉。

输出清理重构。 提示词被重写以放弃 “解释你的推理过程，然后回答” 的前导语。模型现在直接输出 JSON。成本下降了。延迟下降了。推理追踪记录没有被删除 —— 它从一开始就没存在过。风险团队的证据流水线位于模型曾经生成、现在不再生成的字符串下游，流水线会在改动发布后，为每一项决策静默地返回空的推理逻辑。没有人注意到这一点，因为推理逻辑是在审计中抽样的，而不是在生产流量中。

追踪存储保留策略不匹配。 推理过程保留在响应中，但负责 “可观测性” 的团队将追踪库中的所有内容路由到同一个保留类别。运营追踪记录在 30 天后过期，因为那是调试成本效益最高的默认设置。合规证据也在 30 天后过期，因为没有人告诉可观测性团队它是别的东西。公平信贷审查的审计窗口是七年。第一次有人发现这种不匹配，是当监管机构要求提供第七个月的推理逻辑，而存储层返回了 404 时。

语法上存在的推理逻辑。 有人阅读了 CFPB（美国消费者金融保护局）的公告，并在提示词中添加了 “简要说明决策的主要原因”。模型生成了一个句子。这个句子在技术上是一个推理逻辑。它写着 “申请人信用状况” 或 “证明文件不足”，或者其他一些满足勾选框但无法告诉被拒绝申请人任何实质信息的短语。CFPB 明确表示，如果这些理由不能具体且准确地表明不利行动的主要原因，债权人不能依赖样本表中的理由清单。单行的 “信用状况” 推理逻辑正是该局所点名的那种含糊不清的占位符。模型正在生成 Token；但它们没有产生证据。

在每一种情况下，产物在工程团队衡量的维度上看起来表面正确。但在工程团队根本不知道正在被衡量的维度上，每一种都失败了。

监管机构并不在意你如何定价

CFPB 对 ECOA 和 Regulation B 的立场在监管机构中显得异常直接：债权人不能以“决策技术过于复杂或不透明，无法识别导致不利行动的具体原因”为由，来为违规行为辩解。如果模型过于复杂，无法产生可辩护的合规理由，那么该模型就不能被使用。这里没有“为了节省成本我们删除了推理过程”的例外，也没有“推理理由在追踪日志中，但因过期被清理了”的例外。可解释性是部署的前提条件，而不是你可以针对推理预算进行摊销的功能。

欧洲的立场在不同的语境下也是一样的。《欧盟 AI 法案》第 12 条要求高风险系统自动记录足以确保在系统整个生命周期内实现可追溯性的事件，并妥善保留日志以防篡改。第 18 条规定提供者有义务针对审计周期保留这些日志，对于高风险系统，该周期通常会超出任何工程团队基于成本考虑而选择的运行窗口数年之久。2026 年 8 月，核心高风险要求的合规截止日期对某些类别而言已经生效，而英国金融行为监管局（FCA）2026 年的审查立场明确强调了“有证据支撑的原则”——监管机构想看到的是追踪记录，而不是对追踪记录的描述。

这意味着在实践中：一个影响消费者、患者、借款人或租户的模型决策必须产生一个记录文件，以便在多年后让监管机构能够重建其决策原因。如果记录文件因为 Prompt 不再要求它而消失，监管机构不会接受“我们当时正在优化”的理由。如果记录文件因为保留期被限制在运营需求内而消失，监管机构也不会接受“那是可观测性技术栈的默认设置”。平台团队想要建立的防御——即他们正在最大限度地提高一个获权系统的效率——恰恰是这些规则旨在拒绝的辩解。

基于每个决策类别的策略胜过基于每个 Prompt 的直觉

弥补这一差距的纪律不是“始终包含推理”，而是一种基于每个决策类别（per-decision-class）的策略。在编写任何 Prompt 之前，先确定推理追踪是属于产品界面、审计界面、两者皆是，还是两者皆非。这四个答案对应着四个不同的后果。

当推理是产品界面时——例如编码助手解释其差异（diff）、搜索引擎展示其引文——追踪记录是用户体验（UX）的一部分，其保留策略可以遵循产品日志。当推理仅作为审计界面时——例如信用决策理由、医疗分诊证明——追踪记录是监管机构唯一接受的物证，其保留时间必须匹配审计窗口，通常是几年而不是几天。当推理两者皆是时，系统需要两条路径：一个经过脱敏处理、对用户友好的产品版本，以及一个用于审计流水线的完整版本，且后者绝不能因周期性重塑前者的成本压力而受限。当推理确实两者皆非时——例如没有消费者影响且不受监管的内部分类——则可以随意删除。

该策略应与标明模型、Prompt 和成本目标的文档放在一起。如果它存在于其他任何地方，下一次重构都会绕过它。

三个操作层面的环节能让策略在生产环境中得以延续。首先，推理追踪流水线与运营追踪流水线是分离的。它们拥有不同的保留类别、不同的访问控制和不同的所有权。风险团队拥有推理流水线；未经正式审查，任何人都不能更改其保留策略。其次，针对模型实际输出的理由运行证据质量评估（evidence-quality eval），评分标准不是答案的正确性，而是人类审计员是否会接受该理由，认为其具体且准确地描述了主要原因。这种评估可以捕捉到那种“语法上存在但实质上无用”的失败模式，而这是任何工程指标都无法捕捉的。第三，推理预算的成本模型根据推理 Token 产生的审计价值定价，而不是根据可见的答案定价。如果一个推理追踪能防止一笔 500 万美元的监管罚款，那么每条请求支付几美分来保留它就是一个显而易见的交易。

架构层面的认知

推理 Token 是模型的“为什么”存在的唯一载体。在大多数系统中，它们也是最容易被削减的细目，因为它们在成本仪表盘上清晰可见，但在面向用户的输出中却是隐形的。这两个事实共同描述了一个近乎完美的失败模式：其价值由一个看不到成本的团队掌握，却由一个看不到价值的团队进行优化。

为了节省 30% 的推理成本而删除推理过程的团队，同时也删掉了审计人员、客户或事故复盘将要问到的每个问题的答案。这 30% 的节省体现在本季度的财务报表中。而这种删除行为将体现在下一次不利行动投诉、下一次合规审查，以及下一次有人需要知道模型在想什么而答案却已消失的事件中。财务上的节省是立竿见影的，而代价是延后的，这正是所有在当下看起来英明、在复盘时看起来毁灭性的决策所共有的结构。

正确的框架不是“推理 Token 太贵了”，而是“推理 Token 是证据”。在任何高风险领域，证据都是受监管的产物，而优化 Prompt 的团队无权单方面决定公司必须提供哪些证据。在这一框架进入 Prompt 审查清单之前，受监管产品中的每一次成本节约重构，都是一枚引信长度为一个审计周期的合规定时炸弹。