Appearance
内容型产品的编辑抽象：给业主语义模型，而不是代码
第一部 · 产品手记 · 第9章
撰写日期：2026-07-13
结论
需求是让一个非技术业主自己维护一个内容站（个人主页、展示页这类）。我第一版交付的是"白名单文件的在线代码编辑后台"——能在网页上直接改源文件。业主一句话把方向否了："我不想看任何代码，要像编 PPT 一样改。"
"零代码编辑"的正解不是给源码套一个网页编辑器，而是先为页面建一层语义模型——用户操作的是"标题 / 正文 / 卡片 / 图片 / 链接"这些业务对象，不是文件和语法。
给源码套壳，用户仍然要理解文件结构和语法，这跟"零代码"的目标从根上就不对齐。
1. 代码编辑器套壳为什么不算零代码
| 代码编辑器（套壳） | 语义编辑器 | |
|---|---|---|
| 用户看到的 | 源文件、标签、语法 | 页面上的可编辑对象 |
| 心智负担 | 要懂文件结构才能改对 | 只需理解"这是一张卡片" |
| 与源文件耦合 | 直接，格式一变用户就懵 | 被适配层隔离，用户无感 |
| 出错面 | 一个括号删错就白屏 | 改的是对象属性，破坏不了结构 |
2. 语义模型层：把页面拆成可编辑对象
做法是在源文件和用户之间插一层模型：
- 把页面抽象成一组业务对象（标题、正文段、卡片、图片、链接……），每个对象有可编辑的属性；
- 后台读写的是这层模型，再由适配层把改动落回真实的源文件；
- 源文件格式怎么变（换框架、改模板），对用户完全屏蔽——他始终只在编辑业务对象。
交互形态随之自然长出来：所见即所得的画布 + 选中对象后弹出的浮动属性面板。用户的动作是"点这张卡片、改这行字、换这张图"，而不是"打开哪个文件、改第几行"。
3. 编辑抽象的层级，取决于目标用户的技术水位
这件事可以推广成一条判断：给谁用，就把编辑抽象停在谁能理解的那一层。
| 目标用户 | 合适的编辑抽象 |
|---|---|
| 工程师 / 会写代码的人 | 结构化指令、规格文档（见用嘴编程会腐烂） |
| 非技术业主 | 业务对象 + 可视化画布 |
我踩的坑是用"我自己能接受的抽象层"去估"业主能接受的抽象层"。对我，改源文件已经足够方便；对业主，任何一行代码都是劝退。编辑器的成败，先取决于抽象层选没选对，再谈功能。