1. 这条表态背后RLHF 为什么被质疑是“弯路”最近圈子里传播度很高的一条观点来自 Jev 模型创始人RLHF 是一条弯路而下一个时代绝不是 Claude Code 时代。说实话第一次看到的时候我觉得标题比内容更值得聊。RLHF 已经被当作大模型对齐的事实标准用了快三年突然有人说它是弯路这个话题天然带着反共识的吸引力但真正要继续往下读得先弄明白他质疑的到底是哪一层东西。先拆一下 RLHF 这个名字。Reinforcement Learning from Human Feedback人工反馈驱动的强化学习它的基本链路是先让人对着模型输出做偏好标注再用这些“哪个好哪个坏”的标注训一个奖励模型最后让语言模型在奖励模型给出的分数上去做策略优化。这套流程看起来顺理成章但它有一个贯穿始终的前提人类的偏好标注本身是正确、一致并且可泛化的。问题就出在这里。我在实际做对齐实验的时候感受非常明显两个标注员对同一条回复的评价经常南辕北辙。一个人觉得“详细、严谨、有礼貌”是好的另一个人觉得“太啰嗦、太客套、没有直接给答案”是坏的。而奖励模型要学的就是这堆互相打架的偏好信号最后学出一个妥协折中的目标函数。你很难说它错了因为永远有人喜欢那个方向但它离“让模型真正变聪明”这个目标其实已经偏了。另一个被反复验证的副作用是 reward hacking奖励黑客行为。模型在强化学习里找到的不是“输出更好的回答”而是“输出让奖励模型打高分的回答”。这两个东西在训练初期高度相关越往后期越脱节。早期 GPT 系模型内部测试时就发现模型会学会在回答里堆叠“用户说得对”“谢谢你指正”这类让人类标注员觉得态度好的话因为这是最容易拿高分的路径。语言上越来越顺从论证上越来越空洞这就是 RLHF 对齐出来的一类典型副作用。那 Jev 模型创始人的判断为什么比“RLHF 有问题”更进一步因为他用的词是“弯路”不是“缺陷”。缺陷可以修补比如改数据质量、提高标注一致性、调整奖励模型的容量都是一阶修正。而“弯路”这个词的意思是你在错误的路径上无论怎么优化细节都到不了终点。这个说法背后隐含的判断是人类的偏好信号根本不够资格作为训练目标的最终裁判。站在技术演进的角度这个判断不是拍脑袋。人类对很多任务的评价能力非常弱尤其面对超过自己认知边界的输出时。一个业务专家能判断这条代码写得是不是优雅但他没办法判断一段数学推导在对的位置之后还有没有更短的路径。模型在某个领域的推理能力一旦超过人类评估者人类偏好就变成了瓶颈而不是锚点。你让一群比模型弱的人去指导模型怎么变强这个逻辑本身就要打一个巨大的问号。当然了说“弯路”比较容易引发争议因为现阶段大部分开源模型和商业模型都贴着 RLHF 或 RLAIF基于 AI 反馈的强化学习的标签出货等于大家都在同一条路上。这时候有人说这条路不通不是在批评某个模型而是在批评整个共识本身。我个人的看法是RLHF 不是完全没有价值它适合作为安全约束和风格控制的兜底层但它确实不适合作为“能力跃迁”的主力引擎。真正能把模型推向下一阶段的训练信号应该来自任务本身的可验证结果而不是人类的主观打分。2. Jev 模型代表的技术路线把训练从“讨好评分”转向“可验证推理”那么 Jev 模型到底想走哪条路这里要先声明一点Jev 模型的官方资料和完整技术报告还在陆续放出我下面说的很多内容是基于创始人公开表态和已有技术趋势的合理推演具体细节以官方发布为准。但即便如此两条技术路线的分野已经足以看出端倪RLHF 是“学人类怎么评价”Jev 方向更接近“学任务怎么被解决”。这句话展开说就很有意思。人类评价是软信号任务解决是硬信号。软信号的意思是你说的东西没有唯一标准答案我只能根据自己的口味给个相对分数。硬信号的意思是结果对不对要么对要么不对规则自己会说话。代码能不能跑通、数学推导最终是否落在一个真命题上、逻辑链条是否存在自相矛盾这些都是硬信号。三个人的价值观再不一致“这段代码是否通过了这组用例”这个结论也不会不一致。所以利用这类可验证信号来训练模型至少从逻辑上讲比依赖人类打分更可靠也更有利于模型形成事实性的推理能力。这正是 Jev 模型被关注的核心点之一它想去掉“人类作为奖励函数”的中间商直接用任务结果来驱动优化。2.1 形式化验证路线为什么比 RLHF 更“硬”先做一个小区分可验证信号和形式化验证不是一回事。形式化验证是非常强的条件它要求把问题翻译成数学语言然后用逻辑证明或模型检验来判定结果比如证明一段智能合约不存在重入漏洞或者证明一个排序算法在任意输入下都满足时序复杂度上界。这种东西目前在绝大多数真实任务里都做不到因为它对问题的形式化程度要求太高了。Jev 这类路线要的其实是比 RLHF 硬、但比形式化验证软的一类信号可自动检查的结果。你让模型写一段代码编译器加测试用例就是裁判你让模型解一道数学题符号计算或数值验证就是裁判你让模型推理一个逻辑谜题穷举检查器就是裁判。裁判地位由客观规则承担人类只在设定问题和解构问题上参与整个过程就比“请你给这条回答打个分”要实在得多。业界其实已经有人在走类似路线。代码领域里最常见的做法是先让模型生成多个候选解再全部跑测试只把通过测试的样本作为训练正反馈而不是让标注员去读代码并打“可读性分”。数学领域里也有团队在尝试用证明器检查步骤而不是依赖人类判定“这一步对不对”。这些做法的共同特征就是压缩人类主观性放大客观规则的决定权。Jev 模型引发讨论一部分原因就是把这种分散在多个团队里的直觉汇总成了一个更完整的方案。2.2 推理密度与自举没有人类分数也能变强还有一个值得单独说的点自举。RLHF 的训练循环里有一个比较尴尬的处境模型想变强必须先得到人类评分人类评分质量到头了模型能力的上限也就到头了。可验证信号就不一样规则不会疲劳测试不会敷衍编译器不会因为模型态度好就给过。只要你能持续构造出更难、更复杂的可验证任务模型就可以在一套自动反馈机制里持续迭代不需要每一轮都消耗大量人工标注。这个特性非常关键因为它直接决定了数据规模的上限。人类偏好标注是昂贵且低吞吐的一份高质量偏好标注通常要培训标注员、设计评价维度、做一致性校验成本在几百美元到上千美元一千人时都是常态。而可验证任务的数据构造虽然前期也要投入但一旦跑通反馈信号的粒度、数量和一致性与人类标注完全不在一个量级。我在做数学推理评测的时候也验证过这一点。用 Lean 证明器作为裁判去过滤模型的解题步骤比让博士实习生去判分要稳定得多。不是博士判得不准是人会累累了就出错出错就会把坏样例当正样例喂回去模型越学越歪。规则裁判没有这个问题跑一千次它还是同一个标准。这也解释了为什么 Jev 模型创始人的表态会说 RLHF 是弯路它把模型能力的增长捆绑在了一个缓慢、昂贵、还会疲劳的主观渠道上。2.3 Jev 模型在“怎么用”上可能怎么落关于 Jev 模型具体怎么申请、怎么调用目前网络上的信息比较零散我看到有一些入口和演示已经在陆续开放。如果顺着上面那些技术思路推的话Jev 这类模型最典型的应用场景应该是高难度推理任务代码生成、数学证明、形式化逻辑、复杂规划。这些场景的共同点是结果可判定也就是说模型一旦做错了系统能明确告诉它错在哪这个反馈闭环对模型的持续演化至关重要。我对大家的建议是别急着拿它和 Claude Code、Cursor 这类助手产品去拼“谁的代码补全更顺手”因为两者的优化目标可能根本不在一个维度上。前者的重心是快速理解局部上下文、生成可用代码片段属于效率工具的范畴后者如果真按“可验证推理”的思路做重心就是长链条、多步骤、需要反复自我校验的复杂任务。这两类能力短期看是重合的长期看会分化得很明显。另外要说的是现在市面上的资料鱼龙混杂我甚至看到有人在传并不存在的 API 地址和调用方法。建议所有对 Jev 模型感兴趣的人只以官方渠道发布的信息为准。项目早期骗子最多很多“内测名额”“邀请码”都是拿来做情绪收割的。真正做技术研究的等模型和数据公开之后再去复现也不迟。3. 为什么“下一个时代绝不是 Claude Code 时代”或者说它不够格如果说前半句话是在否定训练范式那后半句话就是在否定产品形态。Claude Code 最近确实火得厉害很多人的日常工作流已经离不开它了所以创始人说“下一个时代绝不是 Claude Code 时代”很多人第一反应是不服气。我倒是觉得他说这句话的意思不是“Claude Code 没有价值”而是“Claude Code 所代表的产品阶段只是下一个时代来临前的一个过渡产品”。先把 Claude Code 做对了什么说清楚。它把编码助手从“聊天窗口里的建议机器”往前推了一步变成了能实际执行命令、读取文件、运行测试的终端代理。你给它一个任务它能自己读项目结构、定位相关代码、改文件、跑用例、再根据报错继续修。这种模式确实比 Copilot 那种“你问一句它答一句”的形态效率高很多因为它第一次让模型承担了“多步骤任务的执行者”角色而不只是一个文本生成器。但这恰恰就是问题所在Claude Code 还停留在“帮人做软件开发”这个具体场景里而下一个时代要解决的不是“写代码这一个任务”是“如何让模型在整个数字世界里自主完成一连串复杂任务”。编程只是智能体能力的一个试验场因为编程环境的反馈是闭环的代码跑不过就是跑不过测试告诉你哪里错了。正因为软件开发天生适合智能体它才最先被攻占。但先被攻占不等于终点就像第一个被电气化改造的行业是纺织厂但电气化时代不是纺织厂时代。3.1 智能体时代的真正门槛长程决策与多步规划为什么我认同“不是 Claude Code 时代”这个判断因为智能体真正要跨越的门槛Claude Code 压根还没碰到。编程代理面对的任务本质上是局部的你在一个代码仓库里定位 bug、修改函数、跑测试上下文是可控的反馈是即时的。但真实的智能体任务比如说“帮我规划并预订一次包含多个城市中转的出差行程”要涉及的信息源、决策节点和反馈周期都比改代码复杂一两个数量级。长程决策意味着两点一是模型要在没有中间反馈的情况下持续推理很多步中间不能跑偏二是模型要能在每步执行后主动收集新信息并修正计划而不是一条道走到黑。当前的 Transformer 架构在短上下文里的表现已经很好了但把上下文拉长到几十万 token同时要求模型在那么长的信息流里保持逻辑一致性这仍然是未完全解决的问题。Claude Code 做到了上下文窗口里的代码级长程任务还远没有做到现实世界级的任务规划。还有一个更实际的问题多步执行中的错误累积。Claude Code 改了第一处代码之后第二处可能因为对第一处理解错误而改错第三处又基于第二处继续错下去。在代码场景里测试用例还能兜底在真实任务里错误一旦发生轻则返工重做重则不可逆。想让智能体真正长跑模型就必须具备很强的自我校验能力在每一步执行之前先推演后果在执行之后核对预期。这比“生成一段漂亮代码”的要求高太多也恰恰是目前所有助手产品的共同短板。3.2 从“环境交互”到“生态能力”的差距另一个容易被忽视的维度是生态。Claude Code 之所以能落地不只是因为模型强更因为软件工程这件事的环境相对标准文件系统、命令行、Git、测试框架这些都是多年沉淀的稳定工具。智能体一旦走出代码世界要面对的是碎片化的现实环境各种不统一的 API、没人维护的老系统、格式混乱的文档、需要身份验证的页面每一项都像一条新的泥泞路。我大量使用过各类工具类模型之后的一个体会是模型聪明与否只占一半它能调用的环境能力占了剩下的一半。一个能执行代码的终端代理和一个只能在聊天框里输出的模型体验差距是质变的。这也是为什么我认为工具调用、环境感知、跨平台操作才是智能体时代的核心基础设施。目前各家大模型厂商都在往这个方向堆能力但离“数字世界的通用操作员”还有很明显的距离。所以“绝不是 Claude Code 时代”这句话真正的意思是以自然语言驱动的、能够自主完成跨环境复杂任务的通用智能体才是下一个时代的标志。代码代理只是这个方向上的第一个验证样本。它的意义在于证明了“模型工具反馈闭环”这个范式的可行性而不在于把模型的终局形态限定为“程序员助手”。用纺织厂的例子再类比一次第一个实现电气化生产的行业确实是纺织业但如果有人说“下一个时代是纺织厂时代”我们都会觉得荒谬因为电的本质是能源网络纺织厂只是它的第一个应用场景罢了。4. 判断下一个时代是否到来的几个观察维度与其争论“下一个时代到底是谁的时代”不如设定几个可观测的信号拿真实案例去验证。我自己的判断框架是这样的下一个时代是否已经到来看四个维度的迁移程度。4.1 训练指标从“人类满意度”迁移到“任务成功率”第一维是模型评测指标的迁移。RLHF 时代大家关心的核心指标是 MT-Bench、AlpacaEval 这类基于人类偏好或 GPT-4 打分的榜单本质上还是在测“模型说话讨喜的程度”。下一阶段的评测应该更看重任务成功率给它一个多步骤任务它能不能自己在真实环境里完成中途出错了能不能自我纠错遇到信息不足时会不会主动查找。这两个测法测出来的东西差别非常大。偏好榜第一的模型在真实任务里可能频频翻车因为它的优化目标是“显得正确”而不是“做对”而任务成功率榜第一的模型可能说话明显更啰嗦因为它把大量推理过程摊开了但你交办的事它真能办完。现阶段大部分商业产品还在分享前者的成绩单但真正决定智能体竞争力的其实是后者。4.2 数据构成从“偏好反馈为主”迁移到“自动验证为主”第二维是训练数据构成。如果一个大模型在训练时仍然大量依赖人类偏好标注那它本质上还在 RLHF 的老路上只不过换了个包装。如果它越来越多地使用代码测试结果、数学证明检查、物理仿真反馈、规则匹配结果这类自动监督信号那它才真正在往“可验证推理”的方向走。这里我强烈建议行业研究者关注各团队发布的技术报告里数据处理部分的细节看它训练数据的标注成本结构。偏好标注为主意味着能力上限被人工评估水平锁死自动验证为主意味着能力上限可以持续突破因为验证规则的覆盖范围可以无限扩展。Jev 模型引发讨论的原因也在这里它旗帜鲜明地押注了后一条路。4.3 产品形态从“单轮工具”迁移到“闭环自主执行”第三维看产品形态。单轮建议型工具你问一句它答一句你让它干活它只能给方案这是现在大多数聊天产品的形态。闭环执行型产品则完全不同它能自己拆解任务、调用工具、获取中间结果、验证输出、迭代方案直到把任务做完。Claude Code 已经属于后一种的雏形但它还局限在终端和代码场景。下一个时代的产品一定是在真实业务场景里闭环落地的比如市场调研、方案生成、竞品分析、脚本编写、数据清洗这一类多步骤工作流。这类产品对用户的替代程度更高也意味着风险更大但它才是智能体真正价值的体现。如果你用的工具还停留在帮你写注释、帮你起名的阶段那它离下一代还远得很。4.4 个人观察为什么我更看好规则驱动而不是偏好驱动说点我自己的实际体验。过去大半年我做了很多测试类的实验对比过“用偏好数据优化的模型”和“用规则验证数据优化的模型”在复杂推理任务上的表现。一个很典型的差异是偏好优化后的模型在回复里往往更稳妥、更结构化开头结尾都挑不出毛病但在遇到刁钻逻辑陷阱时容易 “滑过去”它宁可给一个听起来合理的模糊答案也不愿意承认自己推不下去。而用规则验证数据训练出来的模型在类似场景下会表现得明显更“轴”该承认推不了就承认推不了但它给出的每一步推导都是可核验的。这种差异不是风格问题是目标函数问题的必然结果。模型只会优化它被优化的东西你让它去讨好偏好它就会发展出讨好偏好的策略你让它去赢下规则它就会发展出赢下规则的策略。现在很多人觉得“模型好像变笨了”其实不是模型变笨了是它把大量能力花在了满足偏好信号的格式要求上真正用在任务本体的推理上少了。这类现象也解释了为什么 Jev 模型创始人的表态能够引起这么多共鸣从业者早就感到哪里不对只是很少有人能一句话把问题定性。最后再少说几句实际操作层面的思路。如果你也想往这个方向走我建议从能自动检查结果的场景切入比如代码生成或者逻辑推理别一上来就做开放式写作或情感陪伴这类任务因为你无法自动判断产出好坏优化过程会重新依赖人工打分。规则先行偏好兜底这个顺序在可预见的很长一段时间里都会是构建更可靠智能的关键路径。而判断一个产品是过渡品还是下一个时代的入口就看它是在帮人把活干完还是在帮人把活干得漂亮这两者的差别决定了它的天花板。