先给结论：把研发全部交给机器之后，就算芯片暂时冻住，软件这一侧仍可能越跑越快。今天一半来自更大的机器，一半来自更好的算法、数据、结构和外壳。后一半不受工厂工期约束。若软件效率的翻倍，快过「再翻一倍要多付出多少研究」的变难速度，正反馈会压过收益递减。训练要几个月、实验要排队，会拖，但拖不等于熄火。历史上效率提升经常把训练和实验也一起变短。

为什么「芯片跟不上所以不会爆炸」会把软件环看丢

痛点是把进步理解成只能堆硅。堆硅当然有效：同样算法，算力上去会冒出新能力。但软件进步同样在走：结构、训练法、数据质量、超参、提示和外壳。图像识别、翻译、对弈、语言模型，训练效率的翻倍周期多在数月量级。纯效率之外，还有质变：新的微调、逐步推理、把多个系统串成代理，这些不是把旧活做便宜，是把以前做不到的活做出来。

更关键的是劳动力替换。训练一次前沿系统的算力，事后可以用来同时跑数量巨大的副本。全自动之后，等于把顶尖研究员的规模一下子抬到远超今天人类团队。即便最初每份活要「想很久」才配得上专家一分钟，效率提升也会把这份税打下来。环一旦闭合，人不再是节拍器。

五步判断软件环会加速还是会熄火

1. 先分开两条账。硬件账看芯片和电。软件账看：同样硬件上，认知产出翻倍要多久。爆炸讨论的是软件账能不能自己转起来。
2. 看回报系数。软件能力每翻一倍，累计研究投入是不是也必须翻一倍以上。必须翻一倍以上，环会减速；翻不到一倍，环会加速。经验上，软件效率的翻倍往往快过研究队伍的增长，这是加速侧的证据，不是证明。
3. 把训练墙单独记账。下一代要从零训几个月，墙会把节拍钉死。但算法改进历史上会缩短训练。墙在变矮，不能按今天的墙外推十年。
4. 把实验墙单独记账。固定算力下，并行实验有上限。同样，效率提升会让单次实验变便宜，上限会松。松多少不确定，但「排队所以不可能加速」过强。
5. 在全自动之前装监测。只盯训练算力阈值的治理，会在软件狂奔时失效。要看内部最强系统的能力、研发节奏、以及软件效率是否在加快翻倍。

玩具模型能把分界说清。效率每翻一倍，若下一倍需要的「论文」超过两倍，劳动力翻倍也赶不上，节拍变慢，这是熄火。若下一倍需要的论文不到两倍，劳动力翻倍会把节拍打快，这是加速。真实世界没有论文计数那么干净，能力进步更难量化，但分界的形状还在：变难的速度对上劳动力扩张的速度。

现场有三条。其一，熄火也不是缓慢。即便回报小于临界，头一年仍可能给出和今天全年相当的相对涨幅，而那时系统已经极强。慢下来之前的那一截，足够把原来够用的护栏甩在后面。其二，人可能把速度按在指数刀刃上：太快就设障，太慢就拆障，像疫情时的封与放。那不是自然规律，是集体反应，反应本身要被设计，不能靠运气。其三，全自动之前会先自动「大部分」。瓶颈任务仍要人，但人会把时间全部砸在瓶颈上，软件进步在到达全自动前就会加快。等到全自动，你已经在更快的轨道上。

治理含义很硬。多数方案围着芯片转：登记存量、卡训练阈值、过线就评测。这些是地基，在软件爆炸里会过时。领先团队的能力将主要由内部软件进度决定，而不是由新买了多少卡决定。要持续看研发流水和内部最强系统，而不是只看公开的训练规模。

能做的事先做。监测早期信号：软件效率翻倍是否在缩短、内部系统相对公开系统的能力差是否在拉大、研发任务被自动完成的比例。技术护栏要在把研发交给机器之前装上，而不是爆炸开始后再补。补的窗口可能以周计，不以年计。

不要把「可能爆炸」理解成命运。默认路径是各家追求本地短期利益、社会因素不减速。协调可以改路径。写清机制，是为了让人有机会在环闭合前把监测和护栏装上。环闭合后再谈，讨论速度会跟不上系统速度。

结论：软件环可能在固定算力上加速，芯片治理必须补上能力监测

硬件可以冻住，软件正反馈仍可能压过收益递减。训练墙和实验墙会拖，但效率提升常把墙凿矮。仍只拿训练算力当门槛，内部系统会在你看不见的地方换代。

你下周只做一件：给内部最强系统建一条能力日志，按周记软件效率是否在加快翻倍。没有日志，爆炸来了你只能事后解释。有日志，至少知道该不该把研发自动化再往前推一格。

本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源