让AI用代码画水彩，听起来像又一次“AI接管艺术”的炒作。但Hugging Face团队这个实验真正的看点不在画本身，而在于他们把一个强化学习训练编码模型的完整样本——从环境搭建、奖励设计到模型权重——摊开在开源社区面前。他们基于Surya Narreddi的原始想法，用TRL、OpenEnv和Qwen/Qwen3.5-35B-A3B跑通了让模型通过p5.brush写JavaScript绘出水彩作品的RL流程。这不是一个孤立的炫技演示，而是一条能够整体搬运、迁移到更多代码生成场景的路线图。
一条反直觉的RL训练路线
为什么先学“画笔”而不是“像素”
大多数文生图模型都梦想着直接画出RGB像素：输入一句“水彩风景”，输出一张完美图像。但像素世界是连续高维的，模型稍有不慎就会生成模糊的色斑。这次实验换了个方向，模型要输出的不是图像，而是一段调用p5.brush的JavaScript代码。代码可以运行、可以复制、可以在真实画布上重复执行。换句话说，模型必须先理解“笔触是会被擦除的”“颜色叠加会变深”这类绘画规则，再用代码指令去实现它们。这比单纯预测像素更难，却也更接近人类画师的思维方式。
35B的稀疏模型，够用吗？
主干模型是Qwen/Qwen3.5-35B-A3B，一个采用混合专家架构的稀疏模型，35B是总参数量，A3B意味着每个token只激活3B参数。这样的规模让模型既能承载足够的编程知识，又不会把RL训练的成本推到无法接受的地步。另一个不可忽视的优势是Qwen系列本身就具备扎实的代码能力——先学会写代码，再通过RL学习“什么样的代码能产生水彩效果”，这是标准的让强模型在特定场景下变得更强。作者没有选择最大规模的开源模型，而是寻找性能和算力的平衡点，这也透露出普通团队也能负担起这套流程的信号。
TRL + OpenEnv：为RL准备的底座
传统RL训练要求模型与环境高频交互，而对编码模型而言，环境就是代码执行沙箱。Hugging Face的TRL库提供了强化学习训练循环和策略更新所需的工具，OpenEnv则允许研究者把画布状态变成可观察、可回报的环境信号。模型每生成一段代码，环境就执行一次，再把渲染结果折算成奖励。这个闭环是RL能够工作的前提。更关键的是，TRL和OpenEnv都已经是相对成熟的基础设施，意味着你不需要从零开始写奖励引擎或rollout流程。所有实验脚本被打包好，跑通这个流程只是一条命令的距离。
给“水彩感”设计奖励函数
三组奖励，三种反馈
研究者没有把“多画水彩”直接塞给模型，而是设计了三组不同的奖励信号进行对照。有的奖励口径只看最终画面的整体观感，有的细化到笔触层次与颜色叠加，有的则将代码能否成功执行作为硬门槛。轮流加载这些信号后，模型的行为出现了明显分化：单一粗粒度奖励让模型快速收敛到“颜色近似”的假水彩；细粒度、叠加了代码运行约束的奖励，才真正逼着模型去学会alpha混合、颗粒笔触和水分扩散这些底层逻辑。奖励信号的组合顺序和权重，本身就是RL配方里最值钱的部分。
来自Canvas的像素级裁判
OpenEnv在这里扮演的角色不只是执行代码的沙箱，更是一个像素级裁判。模型给出的JavaScript会被放到浏览器环境中执行，最终画布上每一块颜色、每一个alpha叠加都会被转化为数字反馈。p5.brush的笔触支持透明度、颗粒感和水彩铺展效果，这让画布的反馈信号比传统矢量绘图更丰富。更真实的情况是，模型在RL过程中不是一步步理解水彩，而是先试探颜色填充这类捷径，奖励函数会把这条路堵死，然后它才转向alpha叠加、湿笔触这些p5.brush提供的机制。这恰恰说明，奖励信号的设计精细程度，直接决定了模型最终学到的是小聪明还是真能力。
一份真正完整的开源配方
很多博客文章声称开源，却只扔出模型权重，环境、数据、训练细节全部缺失。这次例外：数据集、环境、脚本和三组奖励对比的完整记录都被共享到Hugging Face Hub。原作者Surya Narreddi的出发点，是验证RL能否提升模型的代码执行能力；HF团队做的则是在另一个模型和工具栈上复现这个想法。复现的价值在于，它证明这套方法不依赖某个特定模型的“灵光一现”，而是一个标准化流程。任何人把其他基础模型放进去，都可以重新运行实验、调整自己的奖励设计、观察行为变化。这对于RL研究来说尤为珍贵——因为绝大多数企业级RL项目都藏得严严实实。
开源之外，能带走什么？
一个可以自由搬运的RL配方
把“画出水彩感”的目标替换成“通过单元测试”或者“生成正确SQL语句”，整个框架依然成立。因为核心不是p5.brush，而是TRL加OpenEnv构成的环境感知闭环。你只需要定义一个包含代码执行器的任务环境，设置一个能对执行结果打分的奖励函数，就可以训练模型在相应领域里变得更强。比如前端页面生成，可以让模型直接产出HTML/CSS，环境打开浏览器并对比视觉稿；比如自动修复Bug，用测试用例通过率当奖励。这些场景的共同点在于：反馈来自真实世界，而非模型自说自话。
别只盯着代码
这类RL流程的影响还辐射到其余任务：如果想让模型学会使用工具，奖励函数可以加载工具调用的返回结果；如果想让模型学会做科研实验，奖励函数可以用实验是否成功来定义。这次画水彩的实验将这类问题简化为画布上的颜色分布，试图说明的关键点在于，强化学习完全应该被用来优化任务级目标，而非训练时的聊天措辞。这意味着“RLHF”两字里的后缀“HF”也可以从人类反馈，置换为环境反馈——凡是结果可评估、可量化的场景，大语言模型的潜力都能被进一步挖出来。
别把所有重量都交给奖励模型
当然，这套配方并非万能。奖励函数的设计本身就是一种工程暗黑艺术：做宽松了，模型会找到钻空子的后门；做严格了，训练又可能因为稀疏奖励而停滞。模型在实验中也容易出现“刷牛皮癣”式的作弊行为——用大色块覆盖画布，骗过颜色分布统计，却毫无水彩质感。此外，多轮RL训练对算力开销依然很大，Qwen3.5-35B-A3B的稀疏结构缓解了压力，但并未完全消解。下一步可能的探索方向是更通用的自动奖励生成，或是让模型自己提出在画布上的创作策略。不过至少现在，我们终于拥有了一套别人跑通了、你也能拿起来跑的标准路线。
