OpenDesign 可以较快地把需求转化为可运行的页面，但当工作进入高频、精确、连续的微调阶段后，编辑成本会明显上升。本文结合一次实际使用和改造过程，分析问题为什么会集中出现在“最后 10%”，以及最终放弃继续投入的原因。

一、为什么尝试 OpenDesign

在产品原型阶段，AI 生成页面的价值很直观：输入需求、补充上下文，短时间内就能得到一个可运行的 HTML 原型。相比从空白文件开始搭建，OpenDesign 能快速完成页面结构、基础样式和主要交互，特别适合验证信息架构和业务流程。

最初的预期也很明确：让 AI 负责从 0 到 1，让人工负责从 1 到 1.1。

理想流程应该是：

1. 使用 Prompt 生成页面或完成结构级修改；
2. 进入可视化编辑模式，选中具体元素；
3. 直接修改文案、字号、颜色、宽高、间距和位置；
4. Canvas 实时更新；
5. 修改结果可靠地写回源码，并且可以撤销和恢复。

这个分工看起来很合理。新增页面、重构流程、增加弹窗等语义级工作继续交给 AI；修改 8px 间距、按钮高度或一段文案，则不应该再次调用模型。

二、从 Prompt 编辑转向可视化微调

为了降低生成后的修改成本，实际尝试是在 OpenDesign 已有架构上补充 Manual Edit，而不是另外制作一个独立编辑器。

这条编辑链路主要包含四个环节：

• 在预览 iframe 中选中元素，并读取它的 DOM、样式和位置；
• 通过属性面板编辑文本、尺寸、排版和外观；
• 将拖拽、输入等操作转换成结构化的修改指令；
• 将修改应用到 HTML 源码，保存文件并接入历史记录。

P0 阶段覆盖了文案、字体、颜色、背景、边框、圆角、透明度、宽高、间距以及拖拽位置等常用能力。宽高需要同时接受 px、% 和 auto，文本需要处理直接输入，拖拽还要考虑缩放比例、iframe 坐标与父级布局。

从功能清单看，这已经接近一个轻量设计工具。但真正使用后会发现：属性面板只是最外层的界面，难点都藏在它后面的语义转换里。

三、微调为什么成为主要瓶颈

1. 视觉结果不能只由一个属性决定

设计工具里的宽度通常表现为一个明确数值，但网页元素的最终宽度可能同时受到以下条件影响：

• width、min-width 和 max-width；
• 父级容器的可用空间；
• Flex 或 Grid 布局规则；
• padding、border 与 box-sizing；
• 内容长度和换行行为；
• 响应式样式与媒体查询。

因此，把面板中的宽度从 160 改成 168，并不一定只产生 8 像素的视觉变化。对高度、间距和位置的修改也存在同样的问题。

微调最需要的是确定性：改一个值，只影响一个预期目标。但 CSS 本身是一个相互约束的系统，编辑器如果不了解原页面的布局意图，就只能修改表面属性，无法保证最终效果。

2. 拖拽位置很容易改变原布局语义

拖拽操作看起来简单，实际上最难稳定处理。

一个元素可能原本处于正常文档流、Flex 排列或 Grid 单元格中。用户把它向右移动 8 像素时，编辑器必须判断这是在修改外边距、父级对齐、网格位置、位移变换，还是要把元素改成绝对定位。

这些实现方式在当前画面上可能得到相似结果，但后续影响完全不同：

• 修改 margin 可能推动相邻元素；
• 修改 transform 只改变视觉位置，不改变布局占位；
• 使用绝对定位会脱离原有文档流；
• 修改父级对齐可能影响整个组件组。

如果编辑器只追求“拖完以后看起来到了目标位置”，源码很容易逐渐积累补丁式样式。当前画面可能正确，但下一次改文案、切换尺寸或调整父级后，偏移就可能重新出现。

3. 预览结果和源码结果之间存在转换成本

Manual Edit 并不是直接在源码编辑器里改一行 CSS。它需要在预览 iframe、宿主页面和源文件之间传递消息：预览层负责选择与即时反馈，宿主层负责接收修改，源码补丁层负责定位节点并持久化。

这意味着一次看似简单的修改，要同时保证：

1. 选中的确实是用户看到的那个元素；
2. iframe 内的即时样式正确；
3. 消息携带的选择器和属性没有丢失；
4. 源码中能稳定找到对应节点；
5. 保存后重新加载仍得到相同结果；
6. 撤销、重做和外部文件变化不会覆盖新内容。

任何一层出现偏差，用户都会感受到“刚才明明改好了，刷新以后却不一样”。对编辑器来说，这不是单个输入框的问题，而是一条跨运行时的状态一致性问题。

4. 小问题具有累积效应

微调阶段遇到的 Bug 往往并不大：某个输入值没有立即生效、选区在刷新后丢失、一次拖拽产生了不理想的定位方式、修改宽度后文本意外换行，或者撤销结果与当前预览不完全一致。

单独看，每个问题都可以继续修。但微调本身是高频操作，一个页面可能需要连续调整几十次。只要其中一部分操作需要重新选择、刷新确认或回到源码检查，原本节省下来的时间就会被快速抵消。

这里真正影响效率的不是 Bug 数量，而是信任成本。用户无法确定一次修改是否已经完整写回，就必须反复验证预览、源码和重新加载后的结果。工具越接近最终交付阶段，这种不确定性越难接受。

5. 为了修微调工具，开始偏离原始目标

最初的目标是更快地完成产品原型，而不是开发一套通用网页设计器。

但要让微调足够可靠，就必须继续处理元素身份、选择器稳定性、布局语义、样式优先级、响应式规则、iframe 通信、历史记录、外部文件冲突和异常恢复。这些工作并非附属功能，而是可视化编辑器的核心基础设施。

当大量时间从“制作原型”转移到“修复制作原型的工具”时，投入方向已经发生变化。

四、为什么“能修改”不等于“适合持续修改”

从技术上说，大部分属性都可以通过 DOM 和 CSS 修改。因此，判断一款工具是否具备编辑能力并不困难。

但持续微调需要更高的标准：

• 每次操作的结果必须可预测；
• 修改后不能破坏其他区域；
• 保存、刷新与重新打开后必须一致；
• 源码仍然可读、可维护；
• 出现问题时可以准确撤销，而不是重新生成页面；
• 操作成本必须低于直接改代码。

OpenDesign 在“生成出一个能看的页面”这件事上能提供明显效率，但在“把页面稳定地调整到接近交付标准”这件事上，仍需要承担大量验证和修复成本。

两者并不矛盾。快速生成和高精度编辑本来就是两种不同的技术问题：前者更依赖模型对结构和语义的理解，后者更依赖确定性的编辑模型与成熟的状态管理。

五、最终为什么选择放弃

最终停止继续投入，并不是因为 OpenDesign 完全不可用，也不是某一个严重 Bug 导致项目无法运行，而是综合成本超过了收益。

决策依据主要有三点：

1. 微调频率很高。 原型进入细节阶段后，大量工作都属于几个像素、一个属性或一段短文案的调整。
2. 细节问题分散。 问题横跨选中、预览、布局、源码写回和历史状态，修复一个点不一定能覆盖其他页面结构。
3. 直接修改源码更确定。 对熟悉 HTML 和 CSS 的使用者来说，定位到具体规则直接调整，往往比在可视化编辑器中修改后再检查结果更快。

继续完善当然可以让工具逐步变好，但这已经接近独立产品研发，而不是当前原型项目所需要的辅助能力。因此，停止投入是一个范围和成本判断，而不是对技术路线的彻底否定。

六、OpenDesign 仍然适合什么场景

即使最终没有把它作为长期微调工具，OpenDesign 在以下阶段仍然有价值：

• 根据 PRD 快速生成第一版页面；
• 验证页面数量、信息层级和主要业务流程；
• 创建多个方向供讨论和比较；
• 完成结构级修改，例如增加页面、区块或弹窗；
• 为后续人工开发提供可运行的参考原型。

它更适合作为“加速起点”的工具，而不是现阶段唯一的高精度设计与交付环境。比较务实的使用方式是：用 AI 快速完成 60% 至 80% 的结构和视觉方向，确认方案后切换到源码或成熟设计工具完成剩余细节。

这个比例不是固定指标，而是一条工作原则：当修改开始频繁涉及布局语义、跨区域联动和重复验证时，就应该重新评估继续留在 AI 编辑流程中的成本。

七、结论

OpenDesign 的尝试说明了一件很现实的事：生成页面和编辑页面并不是同一个问题。

AI 可以快速给出一个看起来完整的结果，但原型越接近最终状态，工作越依赖确定性、可预测性和细节控制。最后 10% 的微调可能比前面 90% 的生成更耗时，因为每一次小改动都必须保证不会产生新的偏差。

因此，这次评测的结论不是“OpenDesign 没有价值”，而是它当前更适合快速生成、结构探索和早期验证。对于需要大量精细调整、持续迭代并保持源码稳定的项目，把它作为唯一编辑入口，成本仍然偏高。

最终选择放弃继续改造，是因为继续解决这些细节问题的投入，已经超过直接完成原型本身。对工具的合理评价，不只看它能不能完成一次操作，更要看它能否在几十次连续修改后，仍然保持结果可信。