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 模型创始人的表态能够引起这么多共鸣：从业者早就感到哪里不对，只是很少有人能一句话把问题定性。
最后再少说几句实际操作层面的思路。如果你也想往这个方向走，我建议从能自动检查结果的场景切入，比如代码生成或者逻辑推理，别一上来就做开放式写作或情感陪伴这类任务，因为你无法自动判断产出好坏，优化过程会重新依赖人工打分。规则先行，偏好兜底，这个顺序在可预见的很长一段时间里都会是构建更可靠智能的关键路径。而判断一个产品是过渡品还是下一个时代的入口，就看它是在帮人把活干完，还是在帮人把活干得漂亮，这两者的差别决定了它的天花板。
