所见即所得内容编辑 —— 现状盘点与选型建议

作者：波波 · 2026-10-11

目标：让运营在 A 端改配置时能看见 C 端长什么样，而不是靠猜。

一、先更正我自己的一个错误结论

⚠️ 我做盘点时 grep 了 drag|canvas|preview|所见即所得，得出「零命中，没有任何所见即所得实现」。

🔴 错的。 admin-console/src/pages/BrandConfig.tsx 里已经有手机预览：

/** C 端消费形态实时预览（对齐 miniprogram/utils/brand.ts 的降级规则） */
function BrandPreview({ draft }: { draft: BrandDraft })

⚠️ 它的注释还写明了两件事：

「右侧手机预览实时映射 C 端消费形态」
「对齐 C 端降级规则」（logo 缺省退文字名、无 hero 退默认底、主题色驱动强调色）

✅ 结论：不是从零做，是把 BrandPreview 这套思路推广到别的配置页。

二、现状盘点（实测）

2.1 A 端三种编辑形态

组件	用途	出现次数
`DataTablePage`	列表页（带增删改）	108
`WritePanel`	写入/编辑弹窗（`FieldSchema` 描述字段）	121
`ObjectPage`	单例配置页（非列表端点）	17

⚠️ WritePanel 是当前所有编辑的入口（121 处）⇒ 提升所见即所得的最短路径是增强 WritePanel，而不是每页各写一个。

2.2 C 端能渲染什么（详情页）

detail-render/normalize.ts 的 BODY_TYPES 已登记 23 种：

intro includes leader redeem gallery video notice provenance visit
itinerary cost_exclude altitude gear kora season etiquette departure
faq cancellation related merchant reviews textBlock

⚠️ 这是「A 端能配什么」的硬上限 —— 新增模块类型必须先在 C 端登记，否则会被静默跳过

（normalize.ts:69 有一句现成的警告：跳过未登记模块类型：xxx）。

2.3 唯一已有预览：品牌配置页

已做到：手机壳 + 实时映射 C 端降级规则。

没做到：其他 20+ 个配置页都没有预览。

三、真正的问题是什么

⚠️ 不是「没有预览」，是「预览只覆盖了 1 / 21 个配置页」。

运营改「路况」「通知设置」「目的地」时，看不到 C 端长什么样 ⇒ 只能改完让客人先看到效果 ⇒

这就是线上问题的温床（今晚的「风物内容全没了」若配置页有预览，运营当场就能发现）。

四、三个方案（按性价比排序）

方案 A ·「模块清单 + 实时预览」页（推荐）

给 content_items 做一张可视化配置页：左边模块列表（含启用开关/排序），右边手机预览。

项	说明
改动面	新增 1 个 A 端页 + 复用 `BrandPreview` 的手机壳
收益	直接消除"配了什么"与"显示什么"的断层；新增模块类型不用改前端
成本	中（1–2 天）
风险	低（只读渲染，不写库）

⚠️ 它还能顺带解决今晚那类事故：配置页直接显示「本页已配 2 个模块 / C 端将渲染 2 个」，

运营不用等客人反馈才发现漏配。

方案 B · 增强 `WritePanel`（覆盖面最广）

在 WritePanel 右侧加一个通用预览槽，各配置页传自己的渲染函数。

项	说明
改动面	`WritePanel`（121 处调用）
收益	所有弹窗都能预览
成本	高（要定义预览契约，且 121 处要逐个适配）
风险	中（改的是最核心组件，回归面极大）

⚠️ 不推荐先做这个 —— 动 121 处调用的核心组件，性价比不如方案 A。

方案 C · 真·拖拽画布（所见即所得的"所见"）

⚠️ 不推荐现在做，理由：

C 端是 WXML，不是 HTML ⇒ 拖拽画布天然无法 1:1 还原
要在 A 端重写一套渲染器 ⇒ 两份渲染逻辑必然漂移（今晚 textBlock 就是两处清单不一致导致的）
23 种模块每种都要画一遍预览

⇒ 代价远大于收益。

五、建议路径

第1 步（低成本高收益）：方案 A —— content_items 专属配置页 + 手机预览
第2 步：把「已配模块数 / C 端将渲染模块数」做成 A 端常驻提示
第3 步（看情况）：决定是否推广到其他配置页（相当于方案 B 的轻量版）

⚠️ 第 2 步尤其值得做：它把「配置与渲染不一致」这类静默失败变成显式提示。

六、给决策者的一句话

⚠️ 「所见即所得」在微信小程序上有一个硬约束：

C 端是 WXML，A 端不可能做出 1:1 的所见即所得。

⇒ 现实可行的目标不是「所见即所得」，而是「所见即所得的预览 + 配置与渲染一致的显式提示」。

⚠️ 我们已经有一个可复用的预览实现（BrandPreview），不需要从零做画布。