Hugging Face 开源“用代码画水彩”实验：TRL 与 OpenEnv 把审美偏好变成强化学习信号

Hugging Face 团队用 TRL 和 OpenEnv 将一套“用代码画水彩”的实验流程开源，展示如何把审美偏好转化为强化学习奖励并训练模型生成可执行的绘画代码。文章公开了参考池、评分器、训练脚本和运行数据，讨论了工程瓶颈、成本与评审偏差对模型审美取向的影响。

一篇发表于 2026 年 9 月 3 日的 Hugging Face 社区文章，展示了如何训练一个编码模型，让它不再只是生成可执行程序，而是通过 JavaScript 和 p5.brush 绘制水彩画。文章作者 Sergio Paniego 将参考图像、强化学习环境、训练脚本、模型适配器和训练结果全部公开，试图把此前由设计师 Surya Narreddi 提出的实验路线，变成一套可复现的开放工程流程。

这项工作的特别之处在于，模型面对的不是数学题、代码测试这类有明确答案的任务，而是“什么看起来更像一幅好的水彩画”。研究者必须先定义什么是“好”，再把这种判断转换为模型可以优化的奖励。

从生成图像转向生成绘画代码

Narreddi 在 个人项目说明 中描述了这套方法：模型收到“画一朵桃色木槿”之类的提示后，输出一段完整的 JavaScript 程序；程序在沙盒化的 Puppeteer 环境中运行，并由 p5.brush 渲染成 PNG。随后，图像会与参考水彩画进行比较，判断结果被转换为奖励，再用于 GRPO（Group Relative Policy Optimization）训练。

这种方式与直接调用文生图模型不同。模型输出的不是不可见的像素结果，而是一段可以阅读、修改和再次运行的代码。每一笔画如何形成，至少在程序层面留下了可追踪的痕迹。Narreddi 的项目说明称，这一设计也回应了传统图像生成中的一个限制：用户往往只能通过再次提示模型来修改图像，而代码作为中间产物提供了更细粒度的编辑入口。

Paniego 的工作并没有声称重新发明了这套艺术方法。他明确表示，原始创意来自 Narreddi，他的贡献主要是用 TRL 和 OpenEnv 将流程公开实现，并发布每个关键环节。

奖励函数的核心不是“像不像花”，而是“像不像喜欢的水彩”

在这项实验中，奖励由四部分组成：代码能够编译、确实产生绘画且没有作弊的 gate，占 0.05；对代码长度的软性鼓励，占 0.05；基于参考图像的成对比较，占 0.60；HPSv3 图像偏好模型评分，占 0.30。

HPSv3 是一个开放的 7B 图像偏好模型，用于估计人类对图像的平均偏好。成对比较则由 Qwen3-VL-30B-A3B-Instruct 完成：模型将候选水彩画与随机抽取的四幅参考图并列比较，重点关注颜料晕染、半透明色层和柔软边缘等特征，并在两种呈现顺序下重复判断。

这意味着系统实际上在优化两种不同的标准。HPSv3 更接近“多数人的平均审美”，成对评审器则更接近“参考池所编码的个人品味”。因此，训练数据并不只是帮助模型学习绘画技巧，它本身也定义了模型将要追求的审美方向。

作者建立了一个包含 178 幅图像的参考池，图像分为个人认为值得保留的 “love” 和一般可接受的 “okay” 两档。这些图像并非传统意义上的人工绘画，而是由 GLM-5.2、Kimi K3、Qwen3-Coder-Next 和 Qwen3.5-122B-A10B 等开放权重模型，根据开放许可的木槿照片生成，再经过视觉模型多轮改进和人工逐幅评级。

Paniego 将完整的 参考池及源代码 发布在 Hugging Face Hub 上。但这也带来一个重要限制：模型学到的是一组由模型生成、再由一个人筛选过的水彩审美，而不是更广泛的人类艺术传统。

三种奖励配方都能推动模型学习

作者使用 Qwen3.5-35B-A3B 作为基础模型，并比较了三种奖励组合：以成对评审为主的 judge-led，以 HPSv3 为主的 hps-led，以及完全关闭成对评审的 hps-only。前两项运行各训练到第 110 步，hps-only 运行到第 60 步。

结果显示，三种运行的平均群组奖励都有提升。hps-only 从前段的 0.58 上升到后段的 0.71；judge-led 从 0.45 上升到 0.72；hps-led 则从 0.57 上升到 0.82。作者强调，这些数字来自已公开的 rollout 数据集，读者可以重新计算，而不必依赖某个持续在线的 Space。

训练首先减少了近乎空白、只有无定形色块的失败作品。在 judge-led 运行中，奖励低于 0.3 的 rollout 数量从两个阶段对比中的 99 个降至 16 个；hps-led 则从 37 个降至 4 个。

但两种评审方式带来的变化并不相同。单独使用 HPSv3 时，模型更主要是学会稳定地画出“像花”的结果；加入成对评审后，较好的作品也继续改善，颜料覆盖率在两个包含评审器的运行中明显上升。按照作者的解释，参考图像给了模型一个“还可以更接近什么”的方向，而不仅仅是避免生成失败。

实验同时暴露出 GRPO 在主观任务上的另一面：模型会逐渐趋向同一种风格。由于参考池集中在木槿和相近的色彩范围，训练后同一运行中的作品看起来越来越相似。要获得更丰富的视觉变化，研究者需要先构建更丰富的参考池。

工程瓶颈往往比算法更现实

这条训练链路包括 Hugging Face Jobs、两个 Spaces、推理服务以及持续运行的 WebSocket。环境负责调用绘画库、限制系统提示词、在无头 Chromium 中渲染 JavaScript，并拒绝直接调用底层 p5 绘图接口、只画空白画布或向画布写文字等作弊行为。

作者说，约 1.5% 的 rollout 曾因为渲染超时或评分服务无响应而失败；在最差的一次运行中，这一比例达到 5.2%。如果这些失败被当成真正的低质量绘画，模型就会在噪声奖励上训练。为此，他让基础设施错误返回 None，将其从群组比较中排除。

OpenEnv 也出现过一个实际故障：远端关闭 WebSocket 后，客户端仍缓存着已经失效的连接，后续请求会持续失败。Paniego 表示，他已经向上游提交修复。OpenEnv 的 官方仓库 则将自己定位为用于智能体强化学习的隔离执行环境框架，提供类似 Gymnasium 的 reset()、step() 和 state() 接口，并支持将环境部署到容器化服务中。不过，仓库同时提醒，OpenEnv 仍处于实验阶段，API 可能变化。

计算成本也不低。已完成的运行使用一张 H200：60 步约需 18 小时，110 步约需 34 小时；每一步包含八次 rollout，耗时约 15 至 18 分钟，其中 70% 至 80% 的时间花在渲染。由于环境没有 GPU，Chromium 通过软件方式渲染 WebGL 画布，p5.brush 的晕染和纹理效果进一步增加了负担。

“可复现”仍然不等于“低门槛”

文章将环境、HPSv3 评分器、参考池、三组适配器、rollout 数据、训练曲线和可浏览的画廊集中在 Paint with Code 集合 中。训练流程还可以通过一条命令启动，例如使用 H200、LoRA、bf16 和 Qwen3.5-35B-A3B，在 Hugging Face Jobs 上运行最多 48 小时。

在框架层面，TRL 的 OpenEnv 文档 说明，GRPOTrainer 可以通过 environment_factory 管理多轮环境交互：模型生成工具调用，环境返回观察结果，训练器再将结果放回对话，最后由环境状态计算奖励。对游戏、浏览器操作和代码执行等需要保持状态的任务来说，这比单次、无状态的工具调用更适合。

不过，把完整流程公开并没有消除实验门槛。训练需要高端 GPU、持续运行的评分器和渲染环境，成对评审还会消耗推理配额。作者的下一步设想包括使用更小的模型、先做监督微调、让模型在多轮训练中看到自己画出的图像，以及检查评审器对同一图像的判断是否稳定。

他还指出，自己的侧实验显示，4B 模型已经能够写出通过环境 gate 的有效草图。如果这一规模的模型也能通过强化学习学会稳定绘画，实验成本可能下降一个数量级。

关键问题是：谁在决定什么算“好”

这项实验的意义不在于证明语言模型已经取代了图像生成模型。相反，它展示了一个更窄、但更值得讨论的方向：强化学习是否可以应用于没有标准答案的创意工作。

在数学和代码任务中，奖励通常来自答案是否正确、测试是否通过；在水彩画任务中，奖励来自参考池、评分模型和人工筛选。换言之，算法能够优化什么，取决于研究者先把哪些作品放进池子、让谁来比较，以及哪些视觉特征被写进评审提示。

Paniego 的结论因此带有明显的保留：178 幅由模型生成的画作，最终定义了训练模型眼中的“美”。参考池既是奖励函数，也是整个系统最难以原则化的瓶颈。

这也解释了为什么该项目值得与 Hugging Face 发布 WebGPU 内核、推动浏览器端本地推理 的工作放在同一条开源工具链脉络中观察：前者优化的是模型运行的底层计算，后者则在探索如何把主观判断变成可运行、可审计的训练基础设施。两者都表明，开放模型生态的竞争不只发生在参数规模和榜单上，也发生在数据、环境、评估以及复现成本这些更具体的环节。

来源： Hugging Face 官方社区文章《Training a coding model to paint watercolours with TRL and OpenEnv》；Surya Narreddi 的原始项目说明。