十一月初刷 arXiv 存了一篇，编号 2611.01383，Toward Executable Multi-framework Front-end Code Generation with Self-Correction，NeurIPS 2026，30 页，六个作者。存的时候只是想看看多框架生成又出了什么，真正让我把页面往下翻的是 Project Agent 那段——它要在运行时沙箱的反馈下反复改项目。这篇笔记不聊视觉指标刷到多少，只拆一件事：为什么这条路绕不开「把项目真的跑起来」。
先把我的偏见摆前面。这类论文的 abstract 里，「提升可执行性」和「缩小视觉保真度差距」通常并排写，我不太买账这种并列。样式不对，改一张表就能补；结构跑不起来，后面所有调整都是在流沙上盖楼。所以看到它把可执行性单独拎出来当优化目标，我是认的，虽然它自己没把话说得这么绝。
现在这类方法大多还是冲着 HTML 去的。很多人把这件事当成「少调几个框架 API 罢了」，其实不是。HTML 不需要编译，扔进浏览器就是最终结果，错了就是白屏；React、Vue、Angular 各有各的语法，失败模式也各不相同——同一个错误在 Vue 里可能是模板编译期就报，在 React 里拖到运行时才炸。更麻烦的是跨文件：一个页面拆在五六个文件里，父子组件之间的 props、类型、装配关系得全局一致，而这类一致性问题在单文件视角下根本看不见。论文把这一点单独提出来，我认为是它最诚实的部分——它没说「我们的模型更强所以能生成」，而是承认这个问题的形状和 HTML 那边不是一回事。
MESCoder 的做法是从截图里先抽一个结构脚手架，再逐步构建子树和装配关系：
screenshot.png
└── scaffold ← 从截图抽出来的结构骨架
├── App.tsx ← 根节点，先定下来
├── components/
│ ├── Header.tsx ← 一棵子树，独立生成
│ └── ProductList.tsx
└── styles/
拆开看看，这么拆的实质是把「生成一个项目」降级成「连续做一批局部决策」。思路本身不新，难的是后面——局部决策做错了怎么办。而且我读的时候一直在想一件事：脚手架抽歪了会怎样。如果根节点的边界划错了，比如把本该属于同一个组件的东西劈成两半，后面每一棵子树都是在错误的位置上生长，局部修复怎么修都修不回来，只能回到顶层重抽。论文里没花太多篇幅谈这个失败模式，但我觉得它才是这套树状结构最脆的地方。
Project Agent 在沙箱反馈下持续修改部分项目，并且要在局部修复和簇级修复之间动态选：
on sandbox_feedback(err):
if err.scope == "single_file":
patch_local() # 改一个文件就够，便宜
else:
patch_cluster() # 装配关系错了，得连着父子一起改
这个 if/else 看着平淡，但它是全文我最在意的一处。局部修复便宜、快、容易验证，所以模型天然倾向它；可跨文件的一致性问题局部修就是打地鼠，你改完子组件的 props，父组件那边传参的地方又对不上。能在两者之间动态切，前提是有个东西能告诉你「这个错到底属于哪一层」——那个东西就是沙箱。换句话说，它不是在脑子里反思出来的，是让编译器或运行时把错误甩回来，再照着错误改。
这里我要改口一次。之前我一直把「生成完自己跑一遍」当成习惯问题，写笔记也这么写——好像只要人够自律，多跑一遍就行了。看完这篇我觉得这说法只对了一半：跑一遍要有意义，前提是有一个足够便宜的反馈通道。我在本地手动起 dev server、看控制台、翻回代码里找问题，一轮下来十分钟起步；它有沙箱，一轮几秒，还能反复试几十轮。同样是「跑一遍」，成本差两个数量级的时候，这就不是习惯问题，是能力问题。这条记下来了，下次再跟人聊 AI 生成的代码要不要自己跑，我大概会先反问一句：你一轮反馈要多久？
训练那块是两阶段：先离线初始化一个策略，学多框架生成和修复的基础先验；再用在线强化学习优化长程可执行性和最终页面质量。RL 这一段的细节我读了两遍还是没完全吃透，30 页里这块密度最高，不想装懂——但目标很明确，它优化的不是「这一步写得像不像」，是「一路走到底项目还能不能跑」。论文把这件事描述成带条件的项目状态转移，我理解成每一步生成都得保证状态还能编译，而不是最后再统一救火。
实验结论是提升了可执行性，并缩小了和基于 HTML 方法在视觉保真度上的差距。注意「缩小差距」这四个字，意思是视觉上还是没追上。我觉得这个对比本身也不必太当真——视觉是能后调的，结构不能。真正值得看的是它把评价重心从「截图像不像」挪到了「跑不跑得起来」，这个挪动比它刷了多少分重要得多。
顺手记两个读的时候卡住的点。一个是它说代码已公开，但摘要里只写了这一句，具体仓库我没点进去，这个坑先留着，等我真把某张截图跑通一遍再回来补。另一个是「自我修正」这个词容易被读成「让模型自己 review 一遍」，这两件事差得很远：review 出来的是猜测，沙箱甩回来的是事实，前者会一本正经地说「这里可能有类型问题」，后者直接把报错栈贴你脸上。💡 小技巧：如果你想在本地模仿这套流程，最省事的做法不是接什么 agent 框架，是先把 build 和 lint 挂成 watch 模式，让错误自己往外冒，比事后一次性检查有效得多。
再多说一句我自己的偏见。其实很少有项目真的同时要 React 和 Vue，多框架这个设定作为卖点有点虚；但它的副作用是把方法逼到了不能过拟合某一个框架语法糖的位置上，这个价值比「支持多框架」本身大。我甚至觉得，就算你只写 React，这种必须同时照顾三种失败模式的压力测试，也比单框架训练出来的东西结实。
划重点：第一，多框架生成难在跨文件的一致性和各自的失败模式上，不在「少调几个框架 API」；第二，可执行性该排在视觉保真度前面，前者是结构性的，后者是可以后调的；第三，自我修正要有意义，得先有一个便宜的反馈通道，沙箱不是锦上添花，是这套方法成立的前提。你可以拿手上正在做的那个截图转代码的活试一遍，先把 build watch 挂起来再说，如果踩到别的坑，回来留言，我补一条笔记。