前端开发的智能体训练法：把「改代码→看效果→再修」变成可强化的信号
一句话版本：WebCoder 用「工件接地」的强化学习训练前端智能体——不管智能体在写码、改版、修 bug，都只看一个标准：应用这个最终可执行的「工件」有没有更好满足任务要求。27B 模型训出的成绩超过 Claude-Opus-4.8 和 GPT-5.4。
前端开发的难点，恰恰是智能体训练的空白
真实的前端开发不是「一次生成一个页面」那么简单。用户的一句需求往往是这样：先照着设计稿复刻一个页面，再加一个商品模块，接上已有的购物车逻辑，还不能弄坏原有导航。复刻、生成、修改、修复——四种能力要在同一个不断演进的应用状态里协同。
这对训练意味着两件事：一，各种执行反馈（编译报错、渲染偏差、交互失效）要翻译成「和任务对齐」的奖励；二，几十步相互依赖的操作里，功劳怎么分配给每一步。
核心思想：一切以「工件」为准
WebCoder 的答案很干脆：只看最终那个可执行的应用工件。写码也好、调样式也好、修 bug 也好，评价标准只有一个——工件对任务要求的满足度变了没有。
围绕这个思想构建的 Webdev-World 训练环境里，智能体可以编辑代码、执行应用、用浏览器检查效果、按需调用技能，而且项目状态跨交互保留——不是每轮从零开始，而是像真实开发一样在一个持续演进的项目上干活。
奖励机制分两层：
- 终端奖励：一个独立的验证器在最后评估应用是否满足任务要求；
- 过程信号：中间工件进展的变化，用来把整条轨迹的优势（advantage）重新分配到各个开发片段——改对了关键一步，这一步就能拿到更多权重。
训练工程：上下文不够长怎么办
前端项目的轨迹远超一个上下文窗口。论文用两招解决：上下文压缩，以及消息树式的样本构造——共享的历史只算一次损失，不在每条样本里重复计算。这样长轨迹训练的成本才可控。
成绩：27B 超越大厂旗舰
在自建的 Webdev-Bench（单一项目内组合多种开发需求）上：
| 模型 | 需求满足度 |
|---|---|
| WebCoder-27B | 72.8 |
| Claude-Opus-4.8 | 65.1 |
| GPT-5.4 | 59.6 |
| 基座 Qwen3.8-27B | 64.8 |
在 Vision2Web 上，视觉与功能均分从 41.1 提到 62.4，与 Claude-Opus-4.8 相当。对开源 27B 模型来说，这是相当硬的成绩。
对我们的启发
一，「评价标准单一化」是智能体训练的杠杆。 写码、调试、修复这些动作表面上千差万别，但全部统一到「工件变好了没有」这一个标准上，奖励信号立刻变干净。做自动化工作流也一样——过程再复杂，验收标准要能归一到可执行的事实上。
二、过程信号要服务于终端奖励，不是另起炉灶。 WebCoder 的中间进展信号只做一件事：把终端奖励的功劳分配得更准。这比「过程给过程分、结果给结果分」的两张皮更收敛。
三、环境的状态保留决定智能体的上限。 Webdev-World 让项目状态跨轮次保留，智能体才能练出「在一个演进项目上连续干活」的能力——这正是真实工作场景，也是多数训练环境缺的东西。
在 BuddyMe 的办公 LOOP 里我们同样坚持：任务在同一个工作目录里持续推进、状态不丢，交付以「最终文件能不能用」为验收——和工件接地是同一个思路。
论文：WebCoder: Scaling General Frontend Development with Artifact-Grounded Agentic Reinforcement Learning（arXiv:2610.23104，清华 & 智谱）
BuddyMe 每日免费 4500 万 Token，把「写→看→改」的循环交给会干活的伙伴。