精读：ThinC——让语言模型以代码为核心推理

1 论文概览

一句话总结： ThinC 框架将代码从「被调用的工具」提升为「推理的主体」，4B 参数模型在竞赛级数学基准上全面超越 235B 的 Qwen3-235B-A22B-Thinking。

核心问题： 当前的工具集成推理（Tool-Integrated Reasoning, TIR）范式中，自然语言与代码的角色分工混乱——代码沦为事后验证器，中间自然语言计算不可靠，两者功能重叠而非互补。这种结构性缺陷导致推理效率低下且错误传播。

主要贡献：

1. 范式转换： 提出 ThinC（Thinking in Code）框架，代码作为主要推理通道，自然语言仅保留初始策略规划。轨迹结构从交替式 $`(q, t_1, c_1, o_1, t_2, c_2, o_2, \ldots)`$ 简化为 $`(q, t_1, c_1, o_1, c_2, o_2, \ldots)`$——$`t_1`$ 之后不再有思考块
2. 蒸馏-微调-强化三阶段训练： 从 Qwen3.5-27B 蒸馏 12.2K 代码中心轨迹→SFT 建立格式→GRPO 强化学习提升性能，RL 阶段贡献 +29.9 分
3. 跨尺度验证： ThinC-4B 在五项竞赛级数学基准上达到 78.1% 平均准确率，超越所有 TIR 基线及 235B 大模型
4. 深度分析： 99.2% 的最终答案由解释器输出产生（而非自然语言推导），代码失败恢复率是交错 TIR 的近 2 倍
5. 效率优势： 相比 ASTER-4B（同基座交错 TIR），工具调用次数少 45%（6.1 vs 11.1），响应短 12%（13.5K vs 15.4K tokens）

2 方法详解

架构/方法概述

ThinC 的核心创新在于重新定义推理轨迹的结构。传统 TIR 的轨迹由自然语言思考和代码执行交替组成，而 ThinC 仅在开头保留一个思考块 $`t_1`$ 用于策略规划，随后所有推理步骤通过代码块之间的执行输出串联完成。

ThinC 轨迹格式：

问题 q → 策略规划 t₁ → 代码 c₁ → 输出 o₁ → 代码 c₂ → 输出 o₂ → ... → 答案 a

每个代码块 $`c_i`$ 构建于前序所有执行输出 $`o_1, \ldots, o_{i-1}`$ 之上，且每个代码块在独立进程中执行——这意味着必须重新导入库、重新定义变量，将前序输出硬编码为常量。这一设计强迫模型将推理嵌入代码逻辑而非自然语言描述。

三阶段训练流程：

阶段	目标	关键细节
轨迹蒸馏	构建代码中心训练数据	Qwen3.5-27B 教师模型，3-shot 提示，4 项过滤标准（正确性、无报错、≥3 代码块、规划占比<50%）
SFT	建立代码中心行为格式	12.2K 轨迹，3 epoch，cosine LR 7e-6；性能低于基座模型（设计如此）
RL	提升推理性能	GRPO+DAPO 变体，二元验证奖励，三阶段课程学习（16K→16K 去简单题→32K 扩上下文）

关键创新点

1. 代码即推理者的结构设计

ThinC 通过三条结构约束解决 TIR 的三个根本缺陷：

• “代码作为推理者”而非”验证器”： $`i \geq 2`$ 时无思考块前置，代码必须自行完成推导
• 验证即构造： 所有中间值经解释器产出，不存在未经验证的 NL 中间计算
• 角色分离： NL 仅负责策略规划，代码执行所有后续推导

“Code often acts as a post-hoc verifier… Intermediate NL computations are error-prone… NL and code play overlapping rather than clearly distinct roles” ——论文对 TIR 三大缺陷的精准诊断

2. 三阶段课程式 RL 训练

RL 阶段的设计尤为精巧：

• Stage 1（280 步）： 全量 DAPO-Math-17k，16K 上下文，建立基础推理能力
• Stage 2（120 步）： 移除 Stage 1 中 100% 通过率的问题——这些题在组内优势计算中贡献零梯度
• Stage 3： 扩展到 32K 上下文+40 次工具调用，处理更复杂问题

3. DAPO 修改版 GRPO

• token 级归一化（而非轨迹级平均），避免长轨迹被欠采样
• 非对称裁剪 $`\epsilon_{low}=0.20, \epsilon_{high}=0.28`$，允许更大的正向策略更新
• 无 KL 惩罚，给予策略探索更大自由度

与基线方法的区别

维度	交错 TIR（ASTER/ToRA/MathCoder）	ThinC
推理主体	自然语言，代码辅助	代码，自然语言辅助
中间计算可靠性	NL 计算不可验证	解释器输出天然验证
角色分工	NL 和代码重叠	NL 规划、代码推导，严格分离
错误恢复	依赖 NL 反思	代码自纠错，RL 强化恢复能力
与 PAL/PoT 的区别	—	PAL/PoT 是单次代码生成，ThinC 支持迭代代码推理

3 实验结果

主要指标

五项竞赛级数学基准（avg@16）：

模型	参数量	AIME24	AIME25	AIME26	HMMT25	BeyondAIME	平均
Qwen3-4B-Thinking	4B	79.2	73.1	76.7	50.2	45.8	65.0
Qwen3-235B-A22B-Thinking	235B/22B	90.6	80.6	82.1	68.8	54.1	75.2
ASTER-4B	4B	78.8	84.6	78.8	73.1	54.0	73.8
ThinC-4B	4B	88.3	85.8	86.0	74.0	56.1	78.1

与 SOTA 的对比

• 超越 235B 大模型： ThinC-4B 平均 78.1% vs Qwen3-235B-A22B-Thinking 75.2%（+2.9 分），在 AIME25、AIME26、HMMT25、BeyondAIME 四项上领先
• 超越同基座交错 TIR： vs ASTER-4B +4.1 分，且工具调用少 45%、响应短 12%
• 超越教师模型： vs Qwen3.5-27B（蒸馏教师）+13.4 分——学生超越教师，验证了 RL 阶段的价值
• 超越所有更大 TIR 系统： rStar2-Agent-14B（+16.6 分）、ReTool-32B（+27.4 分）
• 超越闭源大模型基线： gpt-oss-20B-medium（+13.4 分）

消融实验关键发现

1. 代码中心推理的真实性验证

模型	平均代码行数	答案代码验证率
ThinC-4B	349 行	99.2%
ReTool-32B	261 行	88.4%
ASTER-4B	102 行	—
CoRT-1.5B	40 行	—

99.2% 的最终答案来源于解释器输出，而非自然语言推导。这证明模型确实在”用代码思考”，而非仅仅在代码中包装自然语言推理。

2. 代码失败恢复能力

失败次数（k）	ASTER 恢复率	ThinC-4B-SFT	ThinC-4B（RL 后）
k=1	52.1%	42.9%	~64-69%
k=5	18.5%	19.1%	33.3%

关键发现：交错 TIR 系统的恢复率随失败累积单调下降，ThinC 在 k=1,2,3 时恢复率稳定在 64-69% 的平台期。RL 阶段为恢复能力贡献了 20+ 个百分点。

3. 域外泛化（GPQA-Diamond）

模型	avg@16	best@16
Qwen3-4B-Thinking	66.32	83.84
ASTER-4B	63.42	90.40
ThinC-4B	66.48	91.41

仅数学训练数据下，ThinC 在研究生级科学推理上仍优于交错 TIR，表明代码中心推理范式具有域外泛化优势。

4. RL 训练动态

• AIME 2024 准确率从 63.5%（SFT 检查点）爬升至 88.3%（RL 结束），RL 贡献 +29.9 分
• 训练过程平滑单调，无崩塌或平台期
• ThinC-4B 响应长度全程稳定在 7K-11K，即使 Stage 3 扩展上下文至 32K 也未膨胀——模型学会了适度推理

4 个人分析

亮点

1. 结构性创新优于参数堆叠

ThinC 最深刻的启示是：推理效率的提升不一定来自更大的模型，而可以来自更合理的推理结构。4B 模型超越 235B，本质上是因为代码中心轨迹格式消除了自然语言推理的系统性弱点（算术错误、不可验证性、角色混乱）。这呼应了”推理范式比参数规模更重要”的洞见。

2. “验证即构造”的设计哲学

“All intermediate values are produced through the interpreter, ensuring verification by construction”

传统 TIR 的验证是事后补充，ThinC 的验证是构造内蕴的——不存在”未验证的中间值”这个概念。这种设计哲学的转变，从”推理→验证”变为”推理即验证”，从根本上改变了错误传播的可能性。

3. RL 作为行为深化器而非行为塑造者

SFT 阶段性能低于基座模型（设计如此），RL 阶段贡献 +29.9 分。这揭示了一个重要的训练范式：SFT 建立”行为格式”，RL 提升”行为质量”。这与本专栏此前分析的 SFT-then-RL 论文（arXiv:2604.23747）形成有趣的对话——当 SFT 的目标是格式而非性能时，SFT→RL 的顺序优势更加明显。

4. 代码失败恢复的 RL 强化效应

SFT 数据经过严格过滤（所有轨迹必须无报错），但 SFT 模型已经展现出一定的恢复能力。RL 在从未见过恢复样本的情况下，将恢复能力提升了 20+ 个百分点。这暗示 RL 学到了某种”元恢复策略”——一种比显式训练恢复更强大的泛化能力。

局限性

1. 仅在数学领域验证

论文仅评估竞赛级数学推理，未涉及逻辑推理、常识推理、代码生成、多步规划等其他推理场景。代码中心推理在非数值计算任务上的适用性是开放问题——例如，当推理需要概念类比而非精确计算时，代码能承担推理者角色吗？

2. 规模限制

实验仅覆盖 1.7B 和 4B，未验证在更大规模（如 32B、72B）上的效果。代码中心推理是否随规模继续增益？是否存在规模饱和点？

3. 每代码块独立进程的设计成本

每个代码块在独立进程中执行，必须重新导入库和硬编码前序结果。这一设计虽然保证了隔离性和确定性，但带来了：

• token 效率损失（重复导入和定义）
• 变量状态无法跨代码块复用
• 长推理链的累积开销

4. 蒸馏依赖教师模型的代码推理能力

训练数据从 Qwen3.5-27B 蒸馏而来，而教师模型本身采用交错 TIR 格式。教师能否产出高质量的纯代码推理轨迹？蒸馏过程是否丢失了教师模型的某些推理能力？

对大模型领域的影响

1. 推理范式选择的结构性影响

ThinC 提供了一个清晰的证据：在可形式化验证的推理任务上，代码中心推理显著优于自然语言推理。这对当前”思考越多越好”的推理缩放趋势提出了结构性的替代方案——不是更多的思考 token，而是更合理的思考结构。

2. 对 AI Coding 的直接启示

ThinC 的”代码即推理”范式与 AI Coding 领域存在深层共鸣。编程本质上就是将推理编码为可执行代码——ThinC 在数学推理上验证的范式，可能自然延伸到代码生成、调试、重构等 Coding 场景。未来 Coding Agent 或许不应”用自然语言解释代码”，而应”让代码成为推理本身”。

3. 小模型的推理效率路线

4B 超越 235B 的结果，为小模型在资源受限场景下的推理部署提供了可行路径。结合此前分析的 T² 缩放定律（arXiv:2604.01411），过度训练+代码中心推理可能是小模型推理效率的双引擎。

4. 与 RL 推理系列论文的呼应

ThinC 的 RL 训练动态（平滑单调、无崩塌、响应长度稳定）与本专栏此前分析的多篇论文形成对照：

• vs Overthinking（arXiv:2604.10739）：ThinC 的响应长度不随上下文扩展而膨胀
• vs Sparse Policy Selection（arXiv:2605.06241）：代码中心格式可能天然降低了 RL 的策略搜索空间
• vs Illusion of Thinking（arXiv:2506.06941）：代码推理在高复杂度下是否仍有”精确计算崩塌”？

5 实践启示

可以借鉴的技术

1. 代码中心轨迹格式作为推理结构

将推理任务的结构从”交替式 NL+Code”改为”规划→代码链”可以立即应用于：

• 数学推理 Agent 的轨迹设计
• 代码调试 Agent 的推理流程
• 数据分析 Agent 的执行链路

2. SFT 格式+RL 性能的两阶段范式

SFT 不追求性能，只建立行为格式；RL 在正确格式基础上提升性能。这一范式可推广到：

• 工具使用格式的训练（搜索、API 调用等）
• 多步 Agent 行为格式的建立
• 任何需要先”学会格式”再”提升质量”的推理任务

3. 三阶段课程式 RL 训练

“全量→去简单题→扩上下文”的课程设计，尤其适合推理任务的 RL 训练：

• Stage 1 建立基础推理能力
• Stage 2 通过移除零梯度问题提升训练效率
• Stage 3 扩展推理深度处理复杂任务

4. 轨迹蒸馏的过滤标准

四项过滤标准（正确性、无报错、≥3 代码块、规划占比<50%）是高质量代码推理数据构建的实用指南。

潜在应用场景

1. 竞赛级数学推理

ThinC 的直接应用场景。4B 模型在 AIME/HMMT 级别题目上的表现已达到竞赛选手水平。

2. 科学计算与数据分析

代码中心推理天然适合需要数值计算、统计分析、符号推导的场景。GPQA-Diamond 上的域外泛化结果支持这一方向。

3. Coding Agent 的推理层

将”代码即推理”范式引入 Coding Agent：让 Agent 在调试时用代码推理而非自然语言推理，可能显著降低逻辑错误的传播。

4. 可验证推理的安全关键场景

99.2% 的代码验证率意味着推理过程几乎完全可审计、可复现。在对推理可验证性有严格要求的场景（金融风控、医疗诊断辅助、法律推理），代码中心推理提供了天然的安全保障。

5. 小模型推理部署

4B 模型超越 235B 的结果，为边缘设备上的高质量推理部署开辟了可能——通过结构优化而非参数堆叠实现推理质量。