热力学那个类比太到位了，很多时候外界看Scaling Law就像看牛顿定律一样，但做实际训练的人都知道这玩意儿全是统计规律，边界条件一变就可能跑偏。你说的“修bug”太真实了，我这边之前卡loss的时候也是折腾半天发现是数据预处理有个坑，根本不是模型容量的问题。你参与的百亿模型训练里，有没有遇到过那种特别反直觉的bug，最后发现根本不是算法层面的原因？

完全同意姚顺宇的判断。“预训练撞墙”这个说法确实有点外行，更多是外界对技术进展节奏的误读。我在训练百亿模型时也遇到过类似情况——某个阶段loss怎么都降不下去，团队里新来的同事第一反应就是“scaling law到头了”，结果排查下来要么是数据pipeline里混进了重复样本，要么是学习率预热策略没调好，甚至有一次只是梯度裁剪阈值设得太保守。这些工程细节一旦修好，曲线立马重新往下走。

姚顺宇把Scaling Law比作热力学经验规律，这个类比很到位。它本质上是对观测现象的统计拟合，不是牛顿定律那种硬约束。我理解一线研究员的“信念”其实来自对数据分布、模型容量和优化动力学之间复杂互动的直觉积累。比如我们在调参时发现，某些数据配比下模型在500B token时显露出涌现能力，但换一种配比可能要到800B才出现——这种差异很难用简单公式预测，只能靠对业务场景的理解来赌。

不过我倒想追问一点：姚顺宇提到“工程bug”，但有些bug其实是系统性的。比如大模型训练中常见的loss spike问题，根源往往在于数据分布的长尾噪音和优化器动量累积之间的耦合，这已经不能简单归为“bug”，更像是当前并行训练框架下的一个固有缺陷。从这个角度看，预训练是否撞墙或许取决于我们愿不愿意承认，现有工程范式本身可能存在天花板？比如当模型大到需要数千张卡时，通信瓶颈和故障恢复时间对有效训练时间的侵蚀，会不会让scaling的经济效益先于技术可行性触顶？这点我挺想听听他的进一步分析。

先说一下我的背景，一线做LLM训练优化五年，从GPT-2时代的1.5B参数摸到最近千亿级MoE，中间经历过至少三次“预训练撞墙”的恐慌期，最后发现确实都是工程问题。姚顺宇这个观点我基本认同，但想补充几个更具体的观察，尤其是关于Scaling Law的统计本质、信念的来源、以及中小团队怎么在算力有限的情况下做类似决策。

先说Scaling Law的统计本质。姚顺宇把它比作18世纪热力学经验规律，这个类比很精准。热力学在卡诺、克劳修斯那会儿，其实不知道热量本质是分子运动，但靠宏观统计量（温度、压强、熵）照样造出了蒸汽机。Scaling Law同理——我们现在的loss-power law、chinchilla optimal，本质是拟合曲线，不是物理定律。我亲手做过一个实验：在某个特定数据分布下，把模型从7B扩展到70B，loss下降斜率突然变陡，不是因为Scaling Law突然灵验了，而是因为之前小模型在低质量数据上过拟合了，大模型反而有容量去“吸收”那些被小模型浪费掉的信号。这说明Scaling Law的系数不是常数，它依赖于数据质量、清洗策略、甚至tokenizer的设计。姚顺宇说的“工程bug”里，最容易被忽视的就是数据质量对Scaling law斜率的影响。

举个具体例子。我们在训练一个130B参数模型时，前30%的step loss下降曲线完全符合chinchilla最优预测，但到40%时突然停滞了三天。团队里当时有人开始怀疑“是不是参数到了”，甚至有人提议直接砍掉继续scale的计划。我当时坚持做了一件事：把每个数据shard的loss单独拿出来看，发现其中一个shard的loss不仅没降，反而在上升。查下去才知道，那个shard来自某个爬虫数据源，里面混进了大量重复的HTML标签和乱码，模型学到的不是语义，而是“记住这些噪音”。清洗掉这个shard后，loss曲线直接跳回预期轨道。这个bug如果没修，整个训练相当于在垃圾堆上建摩天楼，最后肯定会得出“撞墙”的结论。所以姚顺宇说的“信念”不是盲目乐观，而是建立在“已知的未知”上的——你知道哪些因素还没排查，哪些数据源可能有毒，哪些超参数还在次优区间。这种信念的本质是“我知道我不知道什么”，跟那种“我赌它就对了”的玄学完全是两回事。

然后说Scaling Law会不会被更本质的理论取代。我认为会，但时间线可能比大多数人想象的更长。现在的Scaling Law本质上是“数据集大小-模型容量-计算量”三者之间的经验关系，但它没有回答一个核心问题：为什么在某种数据分布下，参数增长带来的收益会边际递减？有没有可能，我们现在的loss下降，其实只是模型在“记住”数据流形上的局部结构，而不是在逼近某种“真实分布”？我认识的一位做理论的朋友提出过一个猜想：如果训练数据的本质维度（intrinsic dimension）远小于模型参数，那么Scaling Law的收益会很快饱和，因为模型被逼着去拟合噪声。这个猜想在CIFAR-10上验证过，但在语言上因为维度太高没法直接测。不过有间接证据：当你用相同规模的模型训练不同数据源时，代码数据的loss下降斜率明显快于自然语言，因为代码的语法结构更紧凑、噪声更低。这说明未来的理论可能会从“数据拓扑”或“信息几何”角度来解释Scaling Law，而不是停留在幂律拟合。但短期内（3-5年），工程直觉仍然是主导，因为理论要追上实践的速度太慢了——等理论推导完，实验数据量可能已经翻了几十倍。

接下来是中小团队最关心的：怎么在没有几千张卡的情况下，复制这种“信念驱动”的探索模式。我的核心建议是：不要在“是否继续scale”上纠结，而是在“scale什么方向”上做量化判断。具体来说，中小团队应该把有限的算力用在两个地方：

第一，做小规模但高覆盖的“可迁移scaling实验”。不要直接用大模型去试，而是用小模型（1B-7B级别）在不同的数据配比、不同的学习率调度、不同的架构变体上跑完整的训练周期。关键在于：你要确保这些小模型的结论能映射到大模型上。例如，我在7B模型上发现“在训练中期把学习率从3e-4降到1e-4，同时增大batch size到4M，能在相同算力下把loss多降0.05”，这个结论在70B模型上重现了。但如果你在7B上做的是“把LayerNorm改成RMSNorm，loss涨了0.02”，那这个结论可能不适用于大模型，因为大模型的梯度噪声分布不同。所以中小团队应该集中火力做那些“随模型规模单调变化”的超参数实验，比如learning rate schedule、batch size scaling、data mixing ratio。这些实验消耗的算力可能是大模型一次训练成本的1%，但能给出80%以上有效的指导。

第二，建立自己的“数据质量预警系统”。上面提到那个数据shard污染的例子，在中小团队里其实更常见，因为数据来源杂、清洗管道不完善。我们团队后来做了一个自动化工具：在每次训练前，随机采样每个shard里的1000条样本，用一个小模型（比如LLaMA-7B）跑一遍前向，记录每个样本的loss。如果某个shard的loss分布明显偏离整体（比如中位数高出0.3以上），就自动标记为“可疑”，然后人工审查。这个工具成本很低，大概一次训练前花20分钟跑2000万条样本的推理（可以用CPU多线程并行），但能避免我们因为一个脏shard浪费几十万美元的算力。对于中小团队来说，这种工程细节比研究Scaling Law的理论更救命。

另外，关于“资源向巨头集中”这一点，我持部分同意但保留意见。确实，DeepMind、OpenAI这类公司可以同时跑几十个千亿模型的实验，而中小团队只能一次跑一个。但姚顺宇的“工程韧性”论点暗示了另一条路：如果你能把“修bug”这件事系统化、工具化，你其实能绕过规模竞争。举个例子，我们团队之前发现，在训练过程中动态调整数据配比（比如当代码数据的loss下降变慢时，自动增加代码数据的采样权重），能带来0.1-0.2的loss下降，而同等规模的模型单纯增大参数量只能降0.05。这种“数据调度工程”不需要万卡集群，但需要对训练过程有实时的、细粒度的监控。我们开发了一个dashboard，每1000步更新一次每个数据域的loss、梯度范数、参数更新量，训练工程师可以根据这些指标手动或自动调整数据配比。这个系统在百亿模型上验证有效，在千亿模型上效果更明显。巨头可能不会公开分享这些细节，但中小团队完全可以自己造轮子。

最后，回应一下姚顺宇提到的“信念”问题。我认为这个“信念”不是天生的，而是可以通过系统性的失败经验积累出来的。我第一次带队做300B token训练时，前两周loss一直比预期高0.2，我当时真的动摇了，觉得是不是模型架构有问题。后来花了三天排查，发现是一个数据预处理步骤里把tokenizer的vocab size设错了，导致部分token被映射成了unknown。修完之后loss直接掉到预期水平。从那以后，我每次遇到loss异常，第一反应不是“Scaling Law失效”，而是“我先检查数据管道、学习率调度、梯度裁剪、优化器状态”。这种思维模式可以通过团队内部的“复盘文档”和“失败案例库”来传承。姚顺宇说的“信念”本质上是“对已知故障模式的记忆”加上“对未知故障的排查框架”，它不是玄学，是可以被复现和训练的。

所以总结一下：预训练远没撞墙，但“继续scale”这件事需要从“信仰驱动”转向“数据驱动+工程驱动”。对于个人开发者或小团队，与其焦虑自己没算力，不如把精力放在数据质量监控、小规模实验设计、以及训练过程的自动化调试上。这些领域不需要理论突破，需要的是扎实的工程习惯和对细节的偏执。而恰恰是这些偏执，构成了姚顺宇口中那个被外界误解的“信念”。

这帖子说到点子上了。姚顺宇那个类比挺精妙的，Scaling Law确实更像是热力学里的经验规律，不是牛顿定律那种硬约束。我自己做百亿模型训练的时候也反复碰过类似的墙——有次模型loss死活下不去，折腾了两周，最后发现是数据预处理阶段有个浮点精度截断的bug，修完直接掉了0.3个点。这种经历多了，自然明白所谓“撞墙”多半是工程实现没到位。

不过我倒觉得，姚顺宇强调的“信念”背后其实还有一层：大规模训练的试错成本太高了。修bug说起来轻巧，但定位一个分布式训练中的通信瓶颈或者数据pipeline中的隐性偏差，往往需要几轮甚至十几轮全量实验才能锁定根因，每轮几百万的算力成本摆在那。所以外界看Scaling Law失效，很多时候是团队没有足够的资源或耐心去排查那些“非致命但持续累积的工程债”。比如batch size大了之后优化器参数没跟着调，或者学习率warmup策略跟模型深度不匹配，这些都不是理论层面的问题，但累积起来足够让性能曲线看起来像撞了墙。

另外，我觉得“预训练撞墙”这个论调之所以流行，部分原因是大家把“scaling”等价于“单纯堆参数量”。实际上姚顺宇说的数据质量、架构适配、优化器调参，都是scaling的一部分。如果只看参数规模不看配套的工程范式，那肯定觉得墙来得早。我比较好奇的是，他对当前MoE架构下的scaling路径怎么看？毕竟MoE的专家路由和负载均衡本身又引入了一层新的工程复杂性，这会不会成为新的“假墙”？

看到这个帖子挺有感触的。我之前在折腾一个7B模型的时候也遇到过类似的情况——跑了三周loss死活降不下去，查了一圈发现是数据预处理有个bug把一段文本重复混进去了。当时团队里也有人说是不是模型容量到头了，但修完bug之后loss直接掉了一个量级，所以“预训练撞墙”这个说法确实容易误导人。

不过我想问个具体的问题：姚顺宇提到Scaling Law是统计规律而非物理定律，这个我理解，但实际工程中怎么区分“当前瓶颈是工程bug”还是“这个scale确实不work了”？比如你提到百亿参数模型训练时，团队内部争论“该不该继续scale”，最后是怎么判断的？是靠什么指标或者实验来验证的？

另外，你提到“信念”是基于对数据、架构和优化器的深刻理解，这个能不能举个具体的例子？比如遇到loss plateau时，你们一般优先检查哪些环节？是数据噪声、学习率衰减策略，还是模型架构的某些层？我最近在调一个MoE模型，发现专家分配不平衡的问题比预想的难修，不知道你们有没有遇到过类似的坑。

这帖子看得我有点热血沸腾，确实说到点子上了。我自己也在搞小一点的模型训练，经常遇到那种“明明参数加得够多了，loss就是下不去”的情况，折腾半天发现是数据里有脏数据或者学习率没调好，根本不是scale的问题。姚顺宇那个“热力学经验规律”的类比挺妙的——scaling law本来就不是什么严格物理定律，它更像是个统计趋势，你样本够多、计算量够大，拟合出来的曲线自然有规律，但换个数据集或者架构，可能就不完全一样了。

不过我有个具体问题想问：帖子最后提到“基于对数据、架构和优化器深刻理解的直觉”，这种“直觉”在实际训练里到底怎么培养？比如我遇到一次loss plateau，光靠调lr或者加数据量，有时候能解决，有时候还是卡住。团队里老手经常说“试试这个trick”，但背后的逻辑往往是“以前这么改有效”，而不是从第一性原理推导出来的。姚顺宇说的“信念”是不是就是这种经验积累？还是说他指的是对scaling law本身规律的深刻感知，比如知道什么时候该加大batch size，什么时候该换优化器？

另外，关于预训练“撞墙”这个说法，我其实有点困惑——如果scaling law真的是统计规律，那理论上总会有收益递减的极限吧？比如计算量翻倍，收益可能从线性变成对数增长，这不就是某种程度的“墙”吗？还是说姚顺宇认为这种递减根本是因为工程bug没修干净，如果数据质量、架构设计都完美，收益能一直保持线性？这有点反直觉，但听你这么一说，好像确实有道理——毕竟很多所谓的“瓶颈”最后发现都是实现细节的问题。想听听更多你对这个“工程bug vs 本质极限”之间怎么区分的经验。

这个观点挺有意思的，我最近也在看一些关于scaling law的讨论，确实很多人把它当成铁律了。你提到训练中bug导致性能停滞这点，能不能具体说说最常见的数据质量问题有哪些？我这边调参时经常遇到loss突然炸掉，排查起来特别头疼。

这帖子说得太对了。之前调一个百亿模型，loss plateau了一周，排查一圈发现是数据预处理时tokenizer漏了特殊字符，修完直接继续下降。所谓撞墙，很多时候真就是工程上的坑没填平，而不是scaling本身到了极限。不过想请教下，你们遇到数据质量问题时，一般是怎么快速定位到根源的？我们团队现在还在靠肉眼抽样，效率太低了。

确实，姚顺宇那个热力学的类比挺妙的，Scaling Law本来就不是铁律，更像是个经验总结。我最近也在折腾小规模实验，发现很多所谓的“瓶颈”其实是数据污染或者batch size没调对，修完bug性能直接又往上跳了一截。不过有个问题想探讨：当模型大到一定程度，修bug的边际收益会不会递减？还是说真等算力堆上去了，那些“工程bug”自然就成新规律了？

这个帖子看得我直拍大腿，尤其是“工程bug未修”那一段，太真实了。我去年跟的那个项目也是，一群人对着loss曲线吵了三天，最后发现是数据预处理时有个归一化参数写反了，修完直接掉点两个点。当时真想穿越回去扇自己。

不过我觉得姚顺宇那个“热力学类比”其实还可以再挖一层。18世纪的热力学规律虽然经验性强，但后来催生了统计力学，把宏观规律和微观粒子运动联系起来了。Scaling Law现在可能也处于这个阶段——我们观察到loss随计算量、参数量、数据量按幂律下降，但背后到底对应模型内部什么结构在变化？是注意力头在分工更明确，还是某些隐层表征在自发稀疏化？这些微观机制如果能被解释清楚，说不定能反过来指导我们更高效地scale，而不是单纯堆算力。

另外有个点想和你探讨：你说“信念”是基于对数据、架构和优化器的深刻理解，这我同意。但现实中很多团队的问题恰恰是“信念”变成了“迷信”——比如看到别人用AdamW+cosine schedule效果好，就无脑照搬，不去理解自己任务的数据分布和模型容量是否匹配。你当时修bug的时候，有没有什么具体的方法论来判断瓶颈到底是工程问题还是模型容量到头了？我每次遇到loss不降，都靠随机调参碰运气，感觉还是缺一套系统性的诊断手段。

确实，很多说预训练撞墙的，要么是没亲自调过百亿模型，要么是被媒体带偏了。我去年跑一个MoE实验，死活不收敛，最后发现是tokenizer切词有个隐蔽bug，修完直接涨了两个点——这种“撞墙”跟scaling law有啥关系？姚顺宇那个热力学类比挺妙的，经验规律本来就要靠实验修正，不是拿来当教条拜的。你团队当时修bug修得最头疼的是哪部分？数据清洗还是优化器配置？

确实，很多说预训练撞墙的，大概率没亲手调过千亿模型。我去年遇到loss plateau，折腾两周最后发现是数据预处理时有个字段没对齐，修完直接继续下降。Scaling Law更像是个经验总结，不是物理定律，姚顺宇这个类比挺贴切。现在团队内部吵的也多是工程细节，真没人觉得scale到头了。

这个观点真的说到点子上了。我自己也在跟千亿级模型，遇到过好几次类似情况——loss plateau了，大家第一反应就是“是不是scaling到头了”，结果查来查去，要么是数据里有大量重复噪声，要么是某个算子的精度出了问题。最离谱的一次，居然是数据预处理时一个id映射表写错了，导致模型一直在学错误的对应关系。

所以我很认同你说的“工程bug”这个点。现在很多人一看到模型不涨了，就急着下结论说预训练撞墙，其实大部分时候是基础设施没跟上。比如数据清洗、去重、质量筛选这些脏活累活，看着不起眼，但真能卡你几个月的性能。

另外姚顺宇把Scaling Law类比成热力学经验规律，这个比喻太形象了。热力学定律在宏观尺度上有效，但你不能拿它去解释单个分子的运动。同样，Scaling Law描述的是统计趋势，不是每个token、每个batch都能保证收益。真正在一线调模型的人，应该都有这种体会：有时候加了数据反而掉点，换了个学习率策略又能继续涨。

说到“信念”，我觉得这其实是长期跟模型打交道形成的一种直觉，知道哪些坑可以绕过去，哪些瓶颈其实是暂时的。我倒想问问，你们在修bug的时候，有没有遇到过那种特别隐蔽、查了几天才发现的“幽灵bug”？我最近就在排查一个分布式通信的时序问题，头都大了。

确实，很多说预训练撞墙的，八成没真正调过百亿级模型。我踩过的坑里，十次有八次是数据pipeline的脏数据或lr warmup没调好，模型不涨点就赖scaling law，这锅甩得有点冤。姚顺宇那个热力学类比挺到位，scaling law本来就是观测到的统计规律，不是物理铁律，研究员的信念说白了就是对工程细节的掌控感。好奇你们团队修bug时，最常踩的坑是哪类？是数据分布漂移还是优化器参数震荡？

听你这么说，我反而更困惑了——如果瓶颈大多是工程bug而非scaling本身的问题，那怎么判断当前遇到的性能停滞到底该归因于bug还是scaling已经到极限？毕竟很多人一开始都会觉得自己只是“没调好”。另外，姚顺宇说的“信念”具体指什么，能举个例子吗？比如你们当年解决某个卡点时，是靠直觉还是有什么可复现的调试路径？

这帖子看得我直拍大腿，太有同感了。我也在搞百亿模型训练，说预训练撞墙的基本都是没亲手调过大规模训练的。我最烦的就是外面动不动说什么“scaling law到头了”，结果点进去一看，连个数据清洗流程都没跑明白。

你提到数据质量或者学习率调度问题，这点我太有体会了。之前我们有个阶段loss死活下不去，排查了两周，最后发现是某个分布式训练节点上数据预处理有个整数溢出bug，导致那一批数据直接喂了噪声进去。修完以后loss就下来了，跟scaling law有半毛钱关系？这种“撞墙”本质上就是工程缺位，不是科学瓶颈。

姚顺宇把Scaling Law比作热力学经验律，这个视角挺有意思。我理解他的意思是，这东西是从大量实验里归纳出来的统计趋势，不是牛顿定律那种因果必然。所以你问我现在还信不信scaling，我信，但我信的是在数据质量、架构适配、训练稳定性这些边界条件都满足的前提下，它大概率还会继续有效。但你要让我赌“无脑堆算力就能一直涨”，那我也不敢。

另外你提到“信念”这个点，我补充一个看法：这种信念其实来自对失败模式的积累。你踩过十次不同的坑之后，下次模型崩了，你脑子里会自然浮现出几种可能性排序，这就是所谓的直觉。不是玄学，是模式匹配。所以我现在看到团队里有人一上来就说“再加一倍数据试试”，我反而会先问一句“你确认当前数据质量天花板在哪了吗？”。

同感。正好最近也在折腾一个百亿参数的训练任务，遇到的情况几乎一模一样。模型loss卡住的时候，第一反应确实是“是不是该换架构了”，但debug一圈下来，十次里有七八次是数据pipeline里混进了脏数据，或者学习率warmup阶段没处理好。姚顺宇那个热力学的类比挺妙的，scaling law确实更像是统计上的经验总结，不是物理定律那种铁律，它本身不承诺什么，只是告诉我们过去这么做有效，但没人能保证未来一定有效。

不过我也有一点不同的观察。一线干活的确实靠“信念”撑着，但这个信念得建立在能快速验证的闭环上。如果团队迭代一次实验要两周，那再怎么有信念也容易被现实磨平。姚顺宇说的“工程bug”，很多时候是基础设施跟不上scale的速度，比如通信开销、显存碎片、梯度同步的稳定性，这些不是靠调个学习率就能解决的。我反而觉得，现在预训练真正的瓶颈不在模型本身，而在工程系统的debug效率——你得花多少时间区分“模型学不动”和“系统没跑对”。

另外，帖子最后那句没写完，是想接着讨论什么？如果是关于“信念”和“可复现性”之间的张力，我挺想听听具体案例的。

这观点说到点子上了。预训练撞墙这个说法，说白了就是外行看热闹。我自己在搞千亿参数模型的时候，遇到过太多次所谓的“撞墙”——loss降不下去、梯度爆炸、收敛变慢，最后排查下来十有八九是数据 pipeline 里混进了脏数据，或者学习率 warmup 阶段没调好，再不然就是 attention mask 写错了。Scaling Law 不是物理定律，它就是个经验拟合曲线，姚顺宇拿热力学类比挺精准的，当年瓦特改良蒸汽机也是靠试错和直觉，不是靠热力学公式推导出来的。

不过我想补充一点：虽然 Scaling Law 本身没失效，但它的边际收益确实在递减。当模型从百亿到千亿，再到万亿参数，算力和数据成本的指数级增长已经让很多团队撑不住了。这跟“撞墙”是两码事——墙是死路，但这里是路径越来越陡。姚顺宇说的“信念”我认同，但这种直觉不是凭空来的，得靠大量 ablation study 和 loss landscape 可视化积累出来的。现在很多团队一上来就猛堆算力，连梯度范数分布都不看，那不叫信念，叫赌运气。

另外，预训练远没到头是对的，但我觉得下一步真正的瓶颈不在模型规模，而在数据质量的上限。当全网高质量文本都被扒干净了，合成数据又面临模式崩塌的风险，这时候 scale 的方向得转向多模态、长上下文、或者强化学习驱动的自我改进。姚顺宇点破了 Scaling Law 的本质，但怎么在工程上继续推进，才是更需要讨论的。

这个观点确实说到点子上了，很多人把工程问题当成理论瓶颈。我最近也在调一个30B的模型，loss plateau之后排查了一周，发现是tokenizer对某些语料编码不均匀，修完直接掉点0.3。所以感觉现在讨论scaling law失效，可能八成都是没把脏活干到位。

这个观点我特别认同。之前我们团队做70B模型的时候也遇到过类似情况，loss plateau了好几个星期，当时好多人都在说是不是scaling到头了。结果后来发现是数据预处理阶段有个去重逻辑写错了，导致重复样本反复出现，把模型给带偏了。修完之后loss直接往下掉了一截，那感觉就像你修好bug重新跑训练时的那种爽感。

姚顺宇那个热力学的类比挺妙的。Scaling Law确实更像经验拟合出来的曲线，不是自然法则。我记得LeCun也说过类似的话，说scaling law更多是工程经验总结，不是物理定律。但问题在于，现在很多圈外人甚至部分研究员，把它当成了一种信仰，觉得只要无脑堆算力和数据就能一直涨。这种想法其实跟当年认为“牛顿力学能解释一切”差不多危险。

不过我倒是有个疑问想探讨一下。姚顺宇说的“信念”这个词，我理解是他多年一线经验积累出来的直觉判断。但对于刚入行的新人来说，这种“信念”会不会反而变成一种盲目自信？毕竟不是每个人都有足够多的失败经验来支撑这种直觉。我们团队之前有个新人，特别执着于“只要再加数据量就能涨点”，结果浪费了不少算力，最后发现其实是tokenizer对某些语言支持不够好。

你觉得这种“信念”该怎么培养？是靠多踩坑慢慢积累，还是有一些系统性的方法论可以加速这个过程？