AI 已经能生成像样的前端页面，原来的低代码可视化产品还应该投入在哪里？这个问题不能只拿一次漂亮的生成结果回答。页面要接业务数据、改参数、发布并交给别人维护，后面的工作同样决定产品能不能用。

我目前比较三条路线：生成平台配置，直接生成代码，以及平台组件与自由代码混合。还没有足够统一的收益数据，下面是基于现有能力的判断与验证办法。

配置与源码由谁作为依据

生成配置可以复用渲染器、组件、数据绑定与编辑器，但表达范围仍由 schema 和组件决定。用户要求全新交互，模型不能让渲染器凭空拥有它。复杂配置一次生成，错误也不好定位，所以局部创建与修改更适合作为最初范围。

代码生成自由度更大，原型不必等待平台内置能力。代价是依赖、运行环境、身份传递、版本和后续修改都需要处理。数据访问不能由生成代码自己决定权限，业务凭证也不能随意拼接到页面里。

这两条路线的事实来源不同：配置路线以文档为准，代码路线以源码为准。若两边都可改，却没有明确的主版本，双向转换就容易丢失语义。

混合方式需要明确不能做什么

任意代码包含条件、循环、闭包与动态组件，不一定能无损变成可视化组件树。不能承诺生成什么代码，都能在属性面板逐项编辑。

我倾向于让平台组件继续由受限 schema 管理，自由代码放在扩展组件内部，只暴露输入、事件和尺寸。扩展不依赖编辑器私有状态，界面也明确说明它不支持完整可视化编辑。

这样的限制会少一些自由，但用户知道一块内容以后该在哪里改，不必在两套表示之间来回修补。

连续修改比首次截图更能区分方案

用同一张带筛选、趋势图、受权限控制数据源和导出的页面测试。创建完成后，换指标、增筛选、改联动、发布、回退，再交给没参与创建的人维护。

每一步固定初始输入与产物，记录人工补充、结构错误、语义错误和运行失败。数据范围用明确身份检查，恢复后核对版本和结果。任务简单程度、输入详细程度、人工是否已经修过，都不能混进生成速度里。

可维护性还包括第二个人能否找到修改位置，能否保留已有布局和交互。一个结果只有原来的操作者能继续提示模型修复，交付成本并没有消失。

当前选择与改变选择的条件

如果目标仍是标准化业务看板，我会优先验证配置生成，把自由代码用于平台无法表达的局部扩展。数据语义、版本和发布检查可以继续使用现有机制，不必全部重做。

如果大量需求长期绕开 schema，说明平台表达能力或用户目标已经变化，届时应重看路线，而不是不断增加特殊字段。判断依据来自连续任务中的失败与人工成本，不来自“低代码一定会被替代”或“平台能力不可替代”这样的结论。

这轮要得到的是同条件的可修改产物和完整记录。能创建、能变更、能恢复、别人能维护，几种路线的收益与代价才有可比的内容。