TL;DR
更稳的工程默认：generalist 预训练把 code 设在 15–25%（常用 20%），把 >30% 当实验区并配套 NL-retention gate（至少 MMLU + 长上下文理解回归）[3][18]。公开 continual 反例已经足够强：Code Llama 在 Llama 2 基座上追加约 500B code token，代码能力大幅上升而 MMLU 下降 <1 pp [2][15]，因此“continual 必然 catastrophic”不成立。specialist 走 50–90% code 是另一条路线：DeepSeek-Coder 87% code/13% NL 从头训，换来强代码能力，但通用基准存在约 6–9 pp 缺口，需要把缺口当成本项并在 post-training 回补 [1]。机制上，code 的低 entropy 往往对应更低 downstream variance（论文报告约 30% 量级差异）[5]，解释了训练更稳但也更容易挤走 token 预算；因此先做 repo-level packing 与 FIM/infilling 这类“提高每个 code token 价值”的工程杠杆，通常比把占比推到极端更划算 [6][7][8]。
核心断言
§1 把 code 占比当预算旋钮：15–25% 默认，>30% 进实验区
更稳的读法不是“code 越多越好”，而是把 code 占比当成预算分配：固定 FLOPs 下，每增加 1 个 code token 就挤掉 1 个 NL token；这个机会成本来自 compute-optimal 训练视角 [17]。mixture 相图解释了曲线形状：某类数据占比很低（<10–15%）时，更常落在 synergy 区，边际收益高；占比推到 ~40% 附近时，更容易进入 interference 区，开始挤压其它能力 [3]。把 code 视作一种“数据模态”，就能把经验阈值改写成可检验假设：15–25% 是稳态默认，>30% 必须通过 NL-retention gate，>~40% 若没有 matched-compute sweep，不应作为通用默认。Llama 3 的 mixture annealing 提供工程侧一致性：后段提高 code share 说明两位数 code 占比在大规模训练中可接受，但并不支持“高占比全程单调最优” [16]。因此，在讨论“要不要 40%/60%”之前，先把 gate 设为硬约束：至少包含 MMLU 这类通用能力回归，并加入长上下文理解/跨文档一致性回归，避免只用代码基准定义成功 [18][6]。
“占比”不是调味料，是 token 预算：每提高 10% code share，就等价于减少 10% NL 覆盖，必须用 matched-compute 曲线和 retention gate 兜底。
§2 Continual 不必然 catastrophic：公开反例与“何时会漂移”
“continual 加大量 code 会遗忘 NL”常被当作一般规律，但公开可复现的反例已经足够强：Code Llama 在 Llama 2 基座上继续训练约 500B code token，代码能力显著提升，MMLU 下降 <1 pp [2][15][18]。这说明 catastrophic forgetting 并不会因“新分布=code”自动发生，而更受训练配方与 replay/混入策略支配。更务实的解释是：continual 风险来自未受约束的分布漂移，不是 continual 动作本身；因此第一优先级是 gate 与 replay，而不是预设必须 from-scratch。
同时要承认 continual 的上限问题：如果只在训练后段 anneal 提高 code，前段几乎不见 code，模型可能只学到表层模式，迁移弱于全程混入。这个“何时混入”问题在工程上经常被忽略；Llama 3 的 annealing 只能说明“后段提高可行”，不能替代全程配比的受控对照曲线 [16]。更稳的做法是把 continual 做成可控实验：固定 compute，明确 code share 的 schedule（全程混入 vs 后段抬升），并把通用回归（MMLU、长上下文理解）设为硬门槛；只要门槛守住，continual 往往是购买代码能力的更便宜路径 [2][17]。
§3 Specialist 的高 code 配方：把通用缺口当成本项
specialist 路线的关键不是“占比越高越强”，而是把目标函数改成“代码优先”，并把通用能力受挤压视为显式代价。DeepSeek-Coder 选择 87% code/13% NL 从头训，将 repo-level packing 与 FIM 纳入配方，获得强代码能力；同时量化了通用代价：相对通用 base，MMLU 存在约 6–9 pp 缺口 [1]。这条证据把争论从“会不会退化”推进到“退化多少、是否可接受、如何回补”。
对比之下，CodeGen/BigCode 系列更像是“逐步把工程做对”的演进：从 CodeGen 的 code-first 规模化 [13]，到 SantaCoder 的数据管线与可复现性 [14]，再到 StarCoder 将 The Stack + infilling 目标做成标准件 [8][11]。这些工作共同指向一个工程结论：若目标是 specialist，与其在 generalist 上硬推占比，不如从一开始就围绕代码任务设计评测与数据组织，并把通用缺口写进计划（例如预留 NL-heavy 的 SFT/RLHF 或蒸馏预算）。否则最常见的问题不是“代码不够”，而是“目标函数与数据结构不匹配真实使用”。
§4 机制拆分与工程优先级：语义迁移 vs 低 entropy 优化效应
关于“code 为什么能带来 reasoning/ICL 改善”，更可操作的拆分是两条并行机制：
(1) 语义迁移：code 的强语法约束与依赖结构，使模型更频繁接触可验证的多步结构（变量绑定、作用域、调用图），这些结构与某些 reasoning/ICL 形式重叠；因此 <15% 时“under-fed”的直觉成立，但不推出 commonsense 全域提升。
(2) 优化效应：code 的 token 分布更可压缩、entropy 更低，可能降低梯度噪声；Gadre et al. [5] 报告，在相近训练 loss 下，code 域 downstream variance 低于 web（约 30% 量级差异），足以解释“训练更稳、方差更小”的部分收益，无需把全部增益归因于语义迁移。
工程优先级由机制拆分直接给出：若主要收益来自“更值钱的 token 组织”，先做 repo-level packing 与跨文档 in-context 组织 [6]，再做 FIM/infilling 等目标函数增强 [7][8]；若主要收益来自“低噪声稳定训练”，对照组必须干净：用 matched-entropy 或 matched-variance 的替代数据源检验“code 可替代性”，否则容易把优化收益误读为语义迁移。最后，任何占比讨论都必须回到预算：Code-only scaling 的 compute-optimal 前沿接近 token:param ~20 [4]，与 Chinchilla 的预算逻辑一致 [17]，因此“继续加到 60%”不是结论，而是需要曲线与门槛的实验计划。
| 路线 | 典型 code 占比/策略 | 关键工程杠杆 | 通用能力门槛/代价（公开） |
|---|---|---|---|
| Generalist（全程混合） | 15–25% 默认；>30% 需 gate；>~40% 视为高风险区 [3] | 数据选择/过滤优先于盲推占比 [20] | |
| Generalist→Coder（continual） | 在强 base 上追加 ~500B code token 的量级可行 [2] | ||
| Coder specialist（from-scratch） | 50–90%（例：87% code/13% NL）[1] | 公开代价：相对通用 base，MMLU 缺口 ~6–9 pp [1] |
时间线
研究立场对比
阵营 A：generalist 应该把 code 推到 40–60%，收益单调
立场 — 把 code 当作通用推理与工具使用的“主燃料”：既然 code-only scaling 没看到 saturation，就应尽早把占比推到 40% 甚至 60%；NL 退化要么不会发生，要么可在 post-training 轻松补回（对应 c-b6fd752a5d / c-d2e94cac6f / c-d19a8d06fd）。
证据：[4]
反方 — CodeScalingLaws2023 [4] 讨论的是 code-only 前沿，不等价于“混合训练里占比越高越好”。mixture 相图直接给出反例机制：占比升高会从 synergy 进入 interference，~40% 附近更容易压制其它能力 [3]。更关键的是公开代价并不“可忽略”：DeepSeek-Coder 87% code 的通用缺口是 ~6–9 pp [1]，说明高占比会把通用覆盖挤出预算；而 Code Llama 的成功路径是 continual + gate，把通用损失压到 <1 pp，而不是把 generalist 全程推到 60% [2][18]。这组证据更像“存在甜区 + 需要门槛”，而不是单调上升。
判词 — 更务实的建议：把 40–60% 当作需要 matched-compute sweep 才能讨论的实验区，而不是 generalist 默认；默认仍落在 15–25%，并用 retention gate 把“能不能补回”变成可测量约束（修正 c-b6fd752a5d / c-d2e94cac6f / c-d19a8d06fd）。
阵营 B：code 主要是低 entropy 的优化/正则化，语义迁移是次要
立场 — Gadre et al. [5] 看到 code downstream variance 更低，说明 code 的价值在于更稳的梯度信号、等效更低 effective LR；因此任何低 entropy 数据（结构化文本、合成数据）都可替代，没必要纠结 code 占比（对应 c-c0fec56a8d / c-43756fc3d6 / c-522572e2cb）。
反方 — 优化解释能覆盖一部分现象，但“可替代性”需要更强的对照：如果只用 loss/variance 解释，就很难解释为什么 repo-level packing 与跨文档 in-context 组织会对跨文件补全产生结构性收益 [6]，以及为什么 infilling 目标能在不增加 code 占比的情况下提升编辑/修复能力 [7][10]。这些更像是“语义结构 + 目标函数匹配真实使用”的收益，而不是单纯的低噪声训练。更稳的机制读法是：低 entropy 带来优化稳定性（可替代的部分），而 code 的可验证结构与编辑分布带来任务对齐（不易替代的部分）。
判词 — 结论层面的建议：把“低 entropy 稳定性”当作收益来源之一，但不要据此否定 code 的结构迁移；工程上先把 packing/FIM 做满，再用 matched-entropy 对照去验证“哪些收益可替代”（修正 c-c0fec56a8d / c-43756fc3d6 / c-522572e2cb）。
阵营 C：generalist 应把 code 压到 5–10% 以保护 NL
立场 — 把 code 视为强分布偏置：占比上来会挤占世界知识与自然语言覆盖，导致对话、写作、常识等能力退化；因此宁可把 code 留到 post-training/工具调用阶段，预训练只保留极少量（对应 c-9cc57ad007 / c-b65d1cd159）。
反方 — “挤占预算”是事实，但 5–10% 作为硬上限缺少公开曲线支撑。相反，mixture 相图给出的可迁移阈值是：<10–15% 更常处于 synergy 区，边际收益高 [3]，这与“<15% reasoning/ICL under-fed”的工程观察一致。更直接的公开反例是 continual：在强 generalist base 上追加 ~500B code token，MMLU 下降 <1 pp [2][18]，说明只要有 retention gate 与合适配方，两位数 code 并不必然伤 NL。把 code 全部推迟到 post-training 还会错过“预训练阶段的结构化信号”，并把压力转移到更昂贵、更不稳定的对齐阶段。
判词 — 更稳的定位：generalist 不需要把 code 压到 5–10%，默认 15–25% 更符合相图与公开 continual 证据；真正需要保护的是“通用回归门槛”，而不是某个迷信占比（修正 c-9cc57ad007 / c-b65d1cd159）。
阵营 D：code 能力必须 from-scratch；continual 终将失控或遗忘
立场 — 认为 continual 在强分布迁移（加入大量 code）上不可控：要么遗忘 NL，要么出现不可预测的行为漂移；因此要么从零做混合预训练，要么训练专门 coder 再协作（对应 c-e98b6bb551 / c-68f2a1c75c / c-a27feb0824）。
反方 — 目前公开证据更支持“continual 可控但需要门槛”，而不是“终将失控”。Code Llama 的 500B code continual 仍能把 MMLU 损失压到 <1 pp [2][18]，这已经否定了“必然 catastrophic”作为一般规律。from-scratch 的确能把目标做得更纯（DeepSeek-Coder 的 87% 配方）[1]，但它同时展示了通用缺口的确定性成本（~6–9 pp），因此 from-scratch 不是“更干净”，而是“更明确地选择了分布”。更稳的工程策略是：如果已有强 base，先用 continual 买代码能力，并用严格回归门槛与 replay/混入策略约束漂移；只有当目标明确是 specialist，才把 from-scratch 当主路线。
判词 — 结论层面的建议：把“continual 终将失控”降级为需要证据的假设；默认优先 continual + gate（以 <1 pp 通用回归为第一红线），from-scratch 留给明确的 specialist 目标（修正 c-e98b6bb551 / c-68f2a1c75c / c-a27feb0824）。
实践要点
可执行清单（带红线与优先级）：
1) Do（generalist 默认配比）：code 先设 15–25%（默认 20%）；把 <15% 当作“reasoning/ICL 可能 under-fed”的风险区，把 >30% 当作实验区 [3][16]。
2) Do（>30% 必配 gate）：至少做 MMLU 回归 + 长上下文/跨文档理解回归；把“能不能补回”从口头承诺变成硬门槛 [18][6]。
3) Don’t（无曲线别极端化）：没有 matched-compute 的 code-fraction sweep 时，不要把 >40% 当通用默认；相图机制更偏向 interference 风险而非单调收益 [3][17]。
4) Do（已有强 base 优先 continual）：先用 continual 买代码能力，并以“通用指标下降 <1 pp（MMLU）”作为第一道红线；Code Llama 的 ~500B 量级是可参考的公开尺度 [2][18]。
5) Do（先提高每个 code token 的价值）：优先上 repo-level packing / 跨文档 in-context 组织，再上 FIM/infilling；这通常比把占比从 20% 推到 40% 更便宜、更可控 [6][7][8]。
6) Don’t（把 specialist 伪装成 generalist）：如果目标是 coder specialist，直接走 50–90% 并把通用缺口写进计划；DeepSeek-Coder 的 87% 配方对应 ~6–9 pp MMLU 成本，别指望“不会退” [1]。
7) Do（机制对照要做干净）：若要证明“code 只是低 entropy 稳定训练”，需要 matched-entropy / matched-variance 的替代数据对照；否则容易把优化收益误读成语义迁移 [5]。
8) Do（数据选择替代盲推占比）：在 token 预算紧时，优先用数据选择/过滤提高有效 token，而不是简单提高 code share；把“占比”与“质量”拆开讨论 [20][21]。
悬而未决的问题
- Q1.需要公开、matched-compute 的 generalist ratio sweep：对比 <10%、15–25%、>30%、>40% code，在 reasoning（含 ICL）与通用基准（MMLU/长上下文理解）上的完整曲线；目前更多是相图推断与零散工件 [3][18]。
- Q2.需要“>30% code 导致 NL 退化”的预训练期明确反例（非 RLHF 阶段）：最好带数据配方、训练曲线与可复现评测，才能把 gate 的必要性从推断变成证据。
- Q3.需要 head-to-head：continual code pretrain vs from-scratch 高 code，在相近 compute 下同时评估代码基准与通用基准；目前公开证据更多是各自路线的单点工件 [2][1]。
- Q4.需要能支撑“continual 会失控/漂移”的公开证据来填充反方：目前更多是工程担忧而非可复现实验（对应 c-e98b6bb551 / c-68f2a1c75c / c-a27feb0824）。
- Q5.需要因果拆分实验：在 matched-entropy / matched-variance 对照下，分离“语义迁移”与“低噪声优化效应”的贡献；Gadre et al. [5] 提供了现象，但还缺少替代数据的严格对照。
- [1]Daya Guo, Qihao Zhu, Dejian Yang, et al.. DeepSeek-Coder: When the Large Language Model Meets Programming. arXiv, 2024论文
- [2]Baptiste Rozière, Jonas Gehring, Fabian Gloeckle, et al.. Code Llama: Open Foundation Models for Code. arXiv, 2023论文
- [3]Armen Aghajanyan, Lili Yu, Alexis Conneau, et al.. Scaling Laws for Generative Mixed-Modal Language Models. arXiv, 2023论文
- [4]
- [5]Samir Yitzhak Gadre, Georgios Smyrnis, Vaishaal Shankar, et al.. Language Models Scale Reliably With Over-Training and On Downstream Tasks. arXiv, 2023论文
- [6]Weijia Shi, Sewon Min, Maria Lomeli, et al.. In-Context Pretraining: Language Modeling Beyond Document Boundaries. arXiv, 2023论文
- [7]Mohammad Bavarian, Heewoo Jun, Nikolas Tezak, et al.. Efficient Training of Language Models to Fill in the Middle. arXiv, 2022论文
- [8]Raymond Li, Loubna Ben Allal, Yangtian Zi, et al.. StarCoder: may the source be with you!. arXiv, 2023论文
- [9]Anton Lozhkov, Raymond Li, Loubna Ben Allal, et al.. StarCoder 2 and The Stack v2: The Next Generation. arXiv, 2024论文
- [10]Daniel Fried, Armen Aghajanyan, Jessy Lin, et al.. InCoder: A Generative Model for Code Infilling and Synthesis. arXiv, 2022论文
- [11]Denis Kocetkov, Raymond Li, Loubna Ben Allal, et al.. The Stack: 3 TB of permissively licensed source code. arXiv, 2022论文
- [12]Erik Nijkamp, Hiroaki Hayashi, Caiming Xiong, et al.. CodeGen2: Lessons for Training LLMs on Programming and Natural Languages. arXiv, 2023论文
- [13]Erik Nijkamp, Bo Pang, Hiroaki Hayashi, et al.. CodeGen: An Open Large Language Model for Code with Multi-Turn Program Synthesis. arXiv, 2022论文
- [14]Loubna Ben Allal, Raymond Li, Denis Kocetkov, et al.. SantaCoder: don't reach for the stars!. arXiv, 2023论文
- [15]Hugo Touvron, Louis Martin, Kevin Stone, et al.. Llama 2: Open Foundation and Fine-Tuned Chat Models. arXiv, 2023论文
- [16]
- [17]Jordan Hoffmann, Sebastian Borgeaud, Arthur Mensch, et al.. Training Compute-Optimal Large Language Models. arXiv, 2022论文
- [18]Dan Hendrycks, Collin Burns, Steven Basart, et al.. Measuring Massive Multitask Language Understanding. arXiv, 2020论文
- [19]Leo Gao, Stella Biderman, Sid Black, et al.. The Pile: An 800GB Dataset of Diverse Text for Language Modeling. arXiv, 2020论文
- [20]Alon Albalak, Yanai Elazar, Sang Michael Xie, et al.. A Survey on Data Selection for Language Models. arXiv, 2024论文
- [21]