你有没有遇到过这种情况：让AI帮你写一个网页小工具，它信誓旦旦地给了你一份代码，运行起来却是这也不对那也不对。按钮点了没反应，输入框改了数字页面上却没更新，或者干脆页面加载就报错。你把问题反馈给它，它道个歉，改了改，结果修好了这个功能，另一个又坏了。
这背后其实藏着一个挺有意思的技术问题：AI模型是怎么"学会"写出能用的交互式网页应用的？这篇来自蚂蚁集团Inclusion AI团队的论文，就是在琢磨怎么让AI更聪明地从错误中学习，而不是像现在这样，改东墙塌西墙。
先说说这事儿难在哪。
写一个能交互的网页应用，跟解一道数学题或者写一个排序算法完全不是一回事。数学题只有对错，排序算法跑一遍测试用例就知道行不行。但一个网页应用好不好用，得看它是不是真的实现了用户想要的那一堆功能：点击按钮能不能弹出面板，输入框改了内容页面能不能同步更新，操作之后状态切换对不对。这些要求往往分散在代码的不同角落，有的藏在事件处理函数里，有的藏在状态更新逻辑里，有的藏在DOM元素或者CSS样式里。
现在训练AI写代码，主流方法是强化学习里的一种叫GRPO的技术。
GRPO*：全称Group Relative Policy Optimization，一种强化学习训练方法，通过让模型对同一个任务生成多份答案，比较这些答案的好坏，从中学习该往哪个方向调整。这个方法不需要额外训练一个"打分模型"，相对省事,是DeepSeek-R1等模型训练中用到的核心技术之一。
这套方法本身没毛病，问题出在它处理"网页应用"这种复杂产出时的一个致命缺陷上。
GRPO的工作原理简单说就是，让模型针对同一个问题生成好几份答案，然后打分，分数高的答案就整体被"表扬"，分数低的整体被"批评"。这个表扬或批评的力度，术语叫"优势值"，会被均匀地摊到答案里的每一个字（在这里就是每一段代码）上。问题来了：如果一个网页应用里十个功能实现对了九个，只有一个功能坏了，那这份代码到底该被表扬还是批评？如果按整体打一个分数，那对的部分和错的部分会被同等对待，模型根本不知道具体是哪一小段代码需要修正。
这就好比你带着一份期末考卷去找老师，老师不告诉你每道题对错，只说"你这次考了72分，比上次的68分好一点，继续保持"。你听完是懵的：到底是哪道题进步了？哪道题还得加强？如果不告诉你具体哪道题错在哪，你下次复习的时候根本无从下手，很可能是把已经学会的知识又重新复习了一遍，真正的薄弱点却被忽略掉了。放在AI写代码这件事上，如果不做更精细的反馈拆解，模型的每一次"进步"都带着很大的运气成分,可能这次纠正对了错误的地方，也可能强化了本来就没问题的代码。
论文管这个问题叫"粒度不匹配"：用户看到的反馈是一个个具体功能对不对，但模型接收到的训练信号却是一整份代码打一个笼统的分。
为了解决这个问题，研究团队提出了一套叫RCCA的方法。
RCCA*：全称Rubric-to-Code Credit Assignment，字面意思是"从评分细则到代码的功劳分配"，核心思路是把用户能感知到的功能对错，转化成对代码里具体片段的针对性训练信号。
这套方法围绕一个叫"rubric"的东西展开。
rubric*：评分细则，在这篇论文里指的是每个网页应用任务对应的一组具体、可检验的功能要求，比如"点击按钮后面板应该打开""输入框内容变化后显示区域应该同步更新"。每条rubric都能独立判断满足与否。
这些评分细则被分成两类。一类叫"初始状态型"，说的是页面刚加载出来的时候应该长什么样，比如该有的按钮元素在不在，默认显示的内容对不对。另一类叫"动态型"，说的是用户操作之后应该发生什么变化，比如点了某个按钮之后面板打不打得开。前者一加载页面就能检查，后者得真的模拟一次点击、一次输入才能验证。
有了这套细致的评分标准，接下来的关键是怎么把它转化成能训练模型的有效信号。研究团队从两个层面下手：一个是给整份代码打分的层面，一个是给代码里每一小段打权重的层面。
先说打分这一层，研究团队设计了一套"分层奖励"机制。
分层奖励*：把生成的应用分成四个阶段依次检查，分别是输出格式对不对、源代码有没有语法错误、运行起来会不会崩溃、以及最后的功能要求满足了多少。前面三关有一关不过，后面的分数就直接归零或封顶，只有全部通过才能进入最细致的功能打分环节。
这么设计的道理其实很直白。想象你去应聘一份工作,面试官第一步先看你的简历格式对不对（有没有乱码、字段全不全），第二步看你写的项目经历经得起推敲吗（有没有明显造假的地方），第三步让你现场试讲一下能不能讲清楚（会不会当场卡壳说不出话），只有前三关都过了，才会进入最后一轮：具体考核你的专业能力到底怎样。如果不这样一层层过滤,直接把"简历有错别字"和"专业能力差一点"混在一起打一个总分，那两个完全不同性质的问题会被算成差不多的结果,面试官（也就是训练算法）就很难判断到底该往哪个方向指导你改进。
分层奖励解决的正是这个问题:格式都不对的烂代码，和格式正确但只是某个小功能没做好的代码，不该被同等对待，前者应该被压得更低，这样模型才能学到"至少得先写出能跑的代码"这个底线要求。
在最后这层功能打分里，研究团队还做了进一步的细化处理：不是简单数一数错了几条rubric，而是给每条rubric标上重要性等级,分成核心功能、行为正确性、渲染质量三档,再根据违反的严重程度扣分。重要功能出了大问题，扣分会设一个上限，防止靠满足一堆无关紧要的小要求把大问题的分数"洗"回来。这就像考试里，如果一道大题的核心步骤全错了，哪怕字迹工整、格式规范，也不能靠这些加分项把大题的分数拉回及格线。
分层打分解决的是"整体给多少分"的问题，但真正解决"粒度不匹配"的核心创新，在于接下来的这一步：把评分细则的反馈，落实到代码的具体片段上。
这一步叫"rubric到代码的定位"。
研究团队让负责打分的评估器（本质上也是一个AI模型）不只是判断每条rubric满足没满足，还要求它像写代码审查意见一样，具体指出问题出在哪个函数、哪个事件处理逻辑、哪个状态变量、哪块DOM区域。这些意见会先圈出"直接相关"的代码片段，再顺着代码的调用关系往外扩一圈，找出"间接相关"的片段,比如一个按钮的点击事件处理函数里调用了另一个更新状态的函数，那这个被调用的函数也算相关联的代码。
这一步做完之后，就到了整套方法里最关键的操作：把这些被标注出来的代码片段，对应到模型生成时候用到的具体字词token上，然后给不同的token分配不同的训练权重。
token*：语言模型处理文本时的最小单位，可以理解成模型"写字"时一次落笔写下的最小片段，可能是一个单词、一个符号，也可能是半个词。
具体的权重分配是这样的：如果这份代码整体表现不好（也就是"优势值"是负的），那么被标记为"直接相关"的代码片段对应的token，会被赋予3倍的权重，"间接相关"的赋予1.5倍，其他不相关的部分保持1倍。反过来，如果这份代码整体表现好（优势值是正的），出问题的那些片段就不再额外加强，让它们保持原样,反而是那些没被标记出问题的代码会得到一个1.2倍的小幅度加强。
这个设计的用意值得琢磨一下。为什么表现差的代码要重点打压问题片段，而表现好的代码却不去额外表扬问题片段？
打个比方，假设你带了一个学生练琴，这次演奏总体是失败的，其中有一个小节明显弹错了音,你当然要重点纠正这个小节，别的地方稍微提醒一下就行,这是负优势值的情况。但如果这次演奏总体是成功的，只是同一个小节其实也存在瑕疵只是被其他部分的精彩表现盖过去了，你会怎么处理？如果这时候还使劲表扬这个有瑕疵的小节，学生反而会误以为这里弹得没问题，下次继续这么弹。所以更合理的做法是，不去特别强化这个有瑕疵的部分，转而多鼓励那些真正弹得好的地方，让学生把注意力自然地引向正确的方向。这正是RCCA里"正优势值时不再额外强化问题片段"的设计初衷:避免把偶然蒙对的错误片段也当成榜样固化下来。
如果不做这层区分会怎样？答案很直接,系统会持续把"能跑起来但有内伤"的代码模式当成正例强化，久而久之，模型学到的可能只是一种表面上过关、实际上暗藏毛病的写代码习惯。
把这套完整的RCCA训练流程用在一个叫Ling-3.0-Flash的模型上（这是一个拥有1240亿参数、每次实际激活51亿参数的混合线性架构MoE模型），
MoE*：全称Mixture of Experts，混合专家模型，一种让超大模型在处理每个具体任务时只激活其中一部分"专家"网络参与运算的架构设计，能在保持大模型能力的同时降低实际计算成本。
研究团队先用监督微调（SFT）的方式让模型具备基础的应用生成能力，再在这个基础上用RCCA做强化学习训练，最终得到的模型叫Ling-RCCA-Flash。
结果怎么样呢？在专门评测交互式网页应用生成能力的MiniAppBench测评上，Ling-3.0-Flash原始版本只能拿到9.05分，做完监督微调之后提升到26.85分，再经过RCCA强化学习训练，最终冲到了41.25分。这个41.25分是什么水平？它略微超过了Claude Opus 4.5的41.14分，同时甩开GPT-5.1的32.00分将近10个百分点。要知道，这中间的跃升，绝大部分是靠RCCA这一步带来的，从26.85到41.25，整整拉高了14.4个百分点，这个提升幅度比之前监督微调阶段带来的提升还要大。
更让人意外的是，这套方法训练出来的模型，拿到另一个完全不同的测评ArtifactsBench上（一个覆盖更广泛的视觉与交互类应用生成任务的评测集）也表现出色，拿到76.19分，比训练前的SFT模型高出4.48分，并且超过了官方排行榜上原本排名第一的GPT-5的72.55分，反超3.64分。
这个跨基准的提升说明了什么？它意味着RCCA学到的不是"如何在MiniAppBench这道特定考题上刷分"的应试技巧,而是某种更通用的、可迁移的写代码能力,把优化信号精确对应到具体实现区域这件事，本身就在培养一种更扎实的编程习惯，这种习惯换到别的考场依然管用。
这里其实藏着一个更深的问题值得多想一层。传统意义上，我们训练AI模型解决问题，常常满足于让它在某个具体的评测榜单上刷出更高的分数,但一个方法如果只对一个榜单有效，换个场景就失灵，那说明它可能只是学会了"应付这道题"的表面套路，而不是真正学到了底层能力。RCCA这次能同时在两个完全不同的评测集上都拿到亮眼成绩，某种程度上说明它抓住了一个更本质的东西:把反馈精确到位这件事，本身就是一种能穿越具体任务的通用能力。
当然，这套方法也不是万能的。论文自己也承认，它现在评测的还只是相对单页的HTML/CSS/JavaScript应用，像是需要后端服务、需要持久化存储、需要用户登录认证的大型多页面应用，还没有被验证过。另外，整套RCCA高度依赖那个负责打分和定位问题的评估器,如果这个评估器自己判断错了，把责任归咎到了错误的代码片段上，尤其是当一个bug其实是由两块相距很远的代码共同导致的时候，模型学到的可能反而是错误的关联，这是一个还没被完全解决的隐患。
写在后面
读完这篇论文，最触动我的一点是,它其实在回答一个比"怎么写好网页代码"更大的问题：当我们用强化学习训练AI时，反馈的"分辨率"有多重要。
现在很多强化学习训练依然停留在"一份答案打一个分"的粗颗粒度上，这套逻辑放在数学题这种非黑即白的场景里问题不大，但一旦任务变得复杂、由多个可拆解的子目标构成，这种粗颗粒度反馈就会显著拖慢学习效率,甚至学出偏差。RCCA这篇论文提供的思路，本质上是把"复杂任务"拆解成"一组可独立检验的小要求"，再把每个小要求的结果精确映射回产生它的那部分代码。这个思路其实不难迁移到别的领域,任何一个可以被拆分成多个独立可检验子目标的复杂任务，理论上都可以借鉴这套"整体打分+局部定位+差异化权重"的组合拳。
另一个让我留意的细节是，论文里提到评估器不仅要判断rubric满足没满足，还要生成一段自然语言描述，指出问题出在哪个函数、哪个变量。这意味着这套系统里，AI在用文字给AI挑错,评估模型写的诊断意见，最终变成了训练信号里的权重系数。这种"用语言反馈驱动训练信号"的做法，某种程度上打破了我原来对强化学习训练信号必须是数值化的默认印象,原来自然语言本身，只要能被恰当地转化成代码位置信息，也可以精确地参与到梯度更新里去。
这套方法目前测的还只是相对简单的网页小应用，如果哪天真要用在一个包含几十个文件、几万行代码的真实项目上，那个"定位到底是哪一小段代码出了问题"的评估器,能不能撑得住这么大的复杂度，会不会自己先犯迷糊，这是我读完之后一直在琢磨的问题。
Q&A
Q1：RCCA是什么？
A：RCCA全称Rubric-to-Code Credit Assignment，是一种强化学习训练框架，能把用户能感知到的功能对错反馈，转化成对代码具体片段的针对性训练信号，解决了传统方法把整份代码笼统打分导致的训练效率低问题。
Q2：Ling-RCCA-Flash在测评中表现如何？
A：在MiniAppBench测评中拿到41.25分，超过Claude Opus 4.5，比原始模型提升32.2分；在ArtifactsBench测评中拿到76.19分，超过GPT-5的官方成绩，显示出跨场景的迁移能力。
Q3：RCCA和标准GRPO训练方法有什么区别？
A：标准GRPO把一份代码的所有优缺点合并成一个整体分数，均匀分配给每个字词；RCCA则通过分层奖励和代码定位技术，把训练信号精确对应到导致成功或失败的具体代码片段上，实现更精细的功劳分配。
