起因是一份说明书。
同事做完一版产品说明书，我拿过来审，一眼扫下去总有些不对：一个词不够地道，一张结构图的标注错位，某一页的排版跟前面不是一套风格。问题都不大，麻烦的是它们改起来牵一发而动全身。你动一处文案，后面对应的图注得跟着改；你调一处布局，多语言版本里那十几份 copy 出去的文件全要重来一遍。我们产品多，每次上新、每次迭代，物料都要成批同步更新，而大部分语言又不是我们的母语，顶多把英文打磨到勉强地道，再批量翻成各国语言。盯着设计师逐个像素改，是件又慢又磨人的事。
坐在那儿我冒出一个念头：这件事，能不能整段交给 agent？
人做的大多是搬运，不是创作
我要的不是它 one shot 出一份能直接付印的成品。说明书这种东西天生要反复打磨，不存在一次成型，返工是常态。真正想让它接手的，是中间那一大段。把人做的事拆开看，你会发现大部分根本不是创作：定个大致框架、根据 3D 模型渲染安装步骤的结构图、排版、编章节目录、统一样式，最后把一种语言 copy-paste 成所有其他语言。这里面能称得上判断的很少，多数动作只是把 context 从一个地方搬到另一个地方。搬运这件事，正是 agent 最该接手的。
人真正要守住的是两头：发起，和验收。发起是把要传达的东西先想清楚；验收是拿到成品之后，以真实用户的体感去审它到底好不好懂。审的时候我会把自己想象成几种完全不同的人：图省事的年轻用户，只想扫一眼就会装；工程师背景的用户，恨不得每个参数都写清楚；还有不太用 App 的老人家，说明书是他上手产品的唯一入口。用这几双眼睛轮着看一遍，总能挑出一堆要返工的地方。
但把说明书做出来，其实不是最难的部分。难的是人和 agent 在这件事上协作得顺不顺。
两个极端，中间是一片坟场
我拿这件事试过一圈现成方案，baoyu、guizang、taste、frontend-design，还有一个专做 PPT 的 Mck skill，都试过。它们各有各的好，但对我的场景太重了，场景绑得太死，没有一个能输出我要的东西。我甚至自己搓过一个 HTML 编辑器，想让生成出来的中间文件能被个性化地改。结果配置复杂、不符合设计习惯，用起来很费劲，想微调时几乎没有下手的空间，改着改着又回到了"手搓"的程度。
把这些方案摊平了看，其实卡在同一个地方。从"可控 / 可编辑"和"创意 / 灵性"两个维度切，市面上的做法分布在一条线的两端。
一端是直接出图，图像模型生成再合成 PDF。效果最惊艳、最有创意，风格能千奇百怪，这是它无法替代的地方。但可编辑程度极低。我试过对生成的图做局部修改，能改，可改着改着一些细节就丢了，或者你根本控制不住它，尤其在需要参考图来保证一致性的时候。它适合一次性的创意物料：生成一次，下一次完全不一样也没关系。可说明书要的正好相反，它要在一个固定框架里发挥有限的创作空间，还要保证品牌形象前后一致。
另一端是 HTML 转 PDF，用代码排版，输出精度非常高。但它靠 HTML 加 CSS 布局，灵活性仍然不够，更要命的是所有编辑都得过代码。你想挪一个元素，得回代码里找；你要对着预览判断改哪一行，这本身就是门槛。对一个普通设计师来说，这几乎不可能顺手。它精准，但缺了点设计上的灵性。
中间我也试过几种折中：MD 转 HTML 转 PDF、自建 HTML 编辑器、用 code gen 拼模板生成 PPTX。PPT 是这里面最接近的一种，生成完人还能再调。但作为设计工具，PPT 在布局的灵活性和专业性上都不行，很依赖后面再上一道 AI 视觉检查。这些折中方案的通病是：两头都想要，结果两头都不讨好。
| 方案 | 输出一致性 | 人能否顺手微调 | 创意灵性 | 设计师友好 |
|---|---|---|---|---|
| 直接出图合成 PDF | 弱 | 几乎不能 | 强 | 中 |
| HTML / 代码转 PDF | 强 | 要改代码 | 弱 | 差 |
| code gen 拼模板出 PPTX | 中 | 能，但工具不专业 | 弱 | 中 |
| 画布 + DSL（agent 可操作） | 强（靠设计系统） | 能，在原生工具里 | 中上 | 好 |
我把自己真正的需求列出来，其实就几条：输出要一致；出完之后人能用趁手的工具微调；最好有可复用的组件，能沉淀成一套设计系统和越用越厚的品牌资产；技术栈是开源的、不被锁死的。
换个方向：让 agent 来用人的工具
顺着这几条往下想，我发现自己一直在错的方向上使劲。我一直想造一个"对 agent 和人都友好"的新工具，那个 HTML 编辑器就是这么来的。可换个角度：设计师原本就有一套打磨了很多年、无比趁手的工具，为什么不让 agent 来用它？
GUI 这套东西，本来就是为人打磨的。agent 要产出同样的结果，不必去操纵屏幕，它可以从底层用代码生成的方式写进去。同一份设计，agent 从下层写，人从上层的 GUI 直接改，这是同一份产物的两条访问路径。人机不必在一个妥协的中间格式里碰头，而是在设计师的主场里碰头。
别去造一个对 agent 和人都友好的折中工具，那多半两头不讨好。把设计师本来就在用的工具变成 agent 可操作的，让 agent 从底层写、人从前台改，才是让两边都舒服的那条路。
落到具体工具，我用的是 Pencil，一个可以完全本地化的原型设计工具（类似开源版的 Figma，让它在 agent 圈子里出圈的，正是它能通过 MCP 让 agent 驱动画布这一点）。agent 通过 MCP 在画布上排布说明书的页面，画布上沉淀着一套设计系统，保证每次交付的东西不会跑太偏；同时人可以随时上去，对某个文案做针对性修改，对某处布局做微调。多语言尤其需要这个：每种语言的文字长短不一，经常把原本对齐好的布局撑破，这种活本来就得一处一处手动收。不管中间 agent 做到几成，最后总要有人去把控。
这套思路展开，是我现在从零做一个设计时实际在跑的流程：
- 先把要传达的内容本质定下来，也就是文案和框架。这一步最重要，东西没想清楚，后面做得再漂亮都是空的。
- 用 image gen 发散，碰一堆千奇百怪的方案，再收敛到自己想要的那种风格。
- 把风格用 HTML 沉淀成一套设计系统，再做细部调整。
- 设计系统不是终点。真正的文案和素材，最后落到 Pencil 画布上绘制。
- 画完 agent 先过一遍，保证不犯低级错误，人最后再微调。
这里有个分工值得单拎出来：插画、结构图这类素材，交给 image gen 或者 3D 渲染单独产出；排版、布局这类要一致性的活，落在画布上用 DSL 来摆。素材归素材，排版归画布。DSL 你可以简单理解成一串描述"像素该怎么摆在画布上"的配置，它落在 Pencil 上，就意味着 agent 摆的每一个元素，设计师都能像素级地再动手。
设计系统在这里不只是为了好看。它是可复用的组件，是把一次次判断沉淀成标准的过程，这跟我讲过的 Skill 的本质是压缩是一回事，每沉淀一层，下一次交付就少费一分力，时间长了它就成了越滚越厚的品牌资产。而人那一下微调也很关键：它不该被逼着用语音或打字去完成。我在 Agent 交互的三层架构里讲过，人在 agent 面前的角色正从"提问者"变成"审核者"，而审核者最自然的动作，是拿起自己惯用的工具直接上手，而不是把想法描述给另一个人听。
为什么这不是等模型变强的过渡拐杖
有人会说，直接出图那条路最惊艳，而且图像模型还在飞快变强，现在业界都能出可局部编辑的 AI 图了，你这套"把工具交给 agent"，会不会等模型再强一点就被淘汰？
我的判断是不会，至少不会全被淘汰。要看清这一点，得先分清 agent 在哪种活上能真放手。
我在 Loop Engineering 里说过，人能不能退出执行，取决于验证能不能被客观化。写代码是能客观化的那一端：能不能跑、测试过没过、功能能不能用，都是确定性的。只要目标定义清楚，agent 迟早能达成，人可以放心退出。设计不在这一端。一份设计，做，是能做完的；但做得好不好，几乎没有客观标准可依。那部分没法客观化的判断，只能人来把控。
这条线，决定了人机边界在设计上落在哪。写代码时我想让人尽量退出执行；做设计时，人退不出去，因为验证退不出去。既然退不出去，那至少要让人手里有一个又快又顺手的把控方式。这不只是控制欲的问题，更是一笔效率账：同样一处改动，你把意图讲清楚让 agent 去改，可能要一分钟；人自己上手，一秒钟的事。一个可编辑的中间层，省的正是这一分钟。
所以这套方案不是等模型变强的过渡拐杖。只要一类工作要的是一致性、是品牌把控、是那种没法写成 eval 的"好不好看"，人就会一直需要一个能亲手介入的中间层。直接出图那条路依然有它的地盘，那些一次性的、纯创意的、不需要一致性的活，它是最优解。两条路各有各的场景，不是谁取代谁。
我的思考
把这件事跑到现在，几个判断对我更清楚了。
第一，别再造那个"对谁都友好"的折中工具，把人本来就趁手的工具交给 agent。 我在 HTML 编辑器上栽过，想两头讨好，结果往往两头落空。让 agent 从底层写、人从前台的 GUI 改，人机在设计师的主场碰头，比逼着双方去迁就一个中间格式要顺得多。
第二，设计的人机边界，跟写代码不在同一个位置。 代码能客观化，人能放心退出执行；设计的好坏是价值判断，验证退不出去，人也就退不出去。既然退不出去，一个又快又顺手的可编辑中间层就是刚需。它省的不只是掌控感，是实打实的时间，人改一处是一秒钟的事，交代给 agent 可能要一分钟。这也是我在 元能力那篇里说的"校验质量"，落到设计上的样子。
第三，agent 能把设计做到中等往上，但到不了惊艳。 美学也许最终会收敛出某种客观标准，我觉得有这个可能。但真正好的设计，常常是因为它独特、突破了普遍的审美共识，才让人眼前一亮，而突破共识这件事，你写不出一个 eval 去判定它"突破得好不好"。没有验证机制，agent 就只能稳在中间地带。这也是设计 agent 现在还赶不上编码 agent 的原因：编码有干净的对错可以当训练目标，设计没有。谁来定义"好"，这个我在 用 AI 评估 AI里绕过，在设计上格外扎手。
第四，agent 拉高了基线，对人的要求反而更高了。 当 agent 能稳定交付中等往上的设计，人若还停在那个水平，就没有存在的必要了。人得反过来借 agent 的能力，把自己至少在 taste 上顶到 agent 之上。基线被抬高，分水岭就落在了 taste 上，这跟我一直讲的"人退出执行不是被淘汰，是岗位上移"是同一件事。
至于还有哪些活 agent 目前真顶不上，除了这层美学把关，还有 3D 建模和复杂素材导出。agent 能通过 MCP 去驱动 Fusion 这类 CAD，简单图形做得动，可一旦零件多、结构复杂，现在的模型对空间的理解还太弱，基本做不动。再往后我想加一道工序，让 agent 扮成前面那几种不同背景的用户，对说明书做多维度的 review，再循环着改，收敛到一个更好的版本，这条路我在 虚拟用户那篇里想过，但还没真跑起来，现在把关的仍然是人。
所以到最后，那道微调我还是自己动手做完。不是信不过 agent，是"好不好看"这道判断，暂时还只能长在人的手上。