创意

一份文档，而不是一个模板

你写的是一个具有已发布模式的块树。发出去的是该文档针对某个目标渲染后的结果——电子邮件、页面、表单、短信、推送或印刷。两者刻意分开，因为编辑器可以替换而渲染不能，假装不是这样，营销工具最终就会有六个互不一致的同一消息版本。

六个目标，一个来源

每个目标都有一些并非品味问题的约束，渲染器了解它们，你就不必了解。

电子邮件意味着表格和内联 CSS，不用 flex 也不用 grid，因为 Outlook 仍然用 Word 来排版邮件；会为你生成纯文本替代版本；颜色要能在深色模式客户端反色后依然可读；还有约 102 KB 的大小警戒线，超过它 Gmail 就开始截断。

页面意味着普通的现代响应式 HTML，以 slug 发布，需要的话可以放在你自己的域名上。表单是页面加上字段绑定、验证、蜜罐和速率限制——而且它是唯一能合法产生 consent 依据的联系人入口。

短信在你输入时统计条数。推送包含标题、正文、图标、操作和深链接。信函是用印刷 CSS 渲染成 PDF，填写地址并寄出。

文档本身以具有已发布模式的设置形式存储，存放在生态系统的文档服务中，而不是藏在私有表里。这意味着当更好的编辑器出现的那一天，它编辑的是同样的文档，上游什么都不用改。

一份创意渲染目标

渲染结果按目标缓存

合并变量

所有模板语言对缺失键的默认行为都是渲染成空。在邮件里，这意味着“你好，”发给四万人，而且直到回信开始涌进来才有人发现。所以文档在发布之前必须先对照变量词汇表做校验。

联系人的电子邮箱、姓名、电话和语言区域；attrs.*，它是开放的，因为这些属性属于你；你所在组织的名称和邮政地址；退订和偏好设置链接；以及消息本身的主题和预览文本。

刻意做成一个清单，而不是“记录里的任何字段”。联系人行还带有内部标识符，而那些都不该出现在消息里。

{{first_name | default:there}} 是一个已知变量，只是这位联系人恰好没有——比如导入的名单里有一半行没有姓名。这会渲染出回退值，完全没问题。

被拒绝的是 {{frist_name}}：一个对任何人都不存在的变量。发送时两者看起来一模一样；发布时它们截然不同，所以检查就放在发布时进行。

同一套词汇表适用于所有目标，因此为邮件写好的一句话，无需重写就能在短信和落地页上渲染。而且 first_name 是在渲染时从完整姓名推导出来的，而不是存储的——因为存储的拆分迟早会碰上一个不符合假设的名字。

发出之前

超过大约 102 KB，Gmail 就会截断消息，把其余内容藏在一个几乎没人会点的链接后面——包括最底部的退订链接。渲染器会在发布时测量并发出警告。

一张四兆的主视觉照片会撑爆体积预算，在手机上也渲染得很差。图片在上传时就会被缩放和转码，这关乎送达率，而不只是锦上添花。

消息会在桌面和移动宽度下渲染并截图，让列表视图展示它实际的样子，而不是它的名字。不涉及任何付费预览服务。

把它发给你自己，走的是真实收件人会经历的同一渲染器和同一发送身份。走不同代码路径的预览，证明不了任何关于实际发出消息的事情。

从别处粘贴进来的内容在存储前会经过净化器处理，因为营销邮件不是发现别人剪贴板里有什么的地方。

用 Markdown 写，然后渲染出来。比让模型生成邮件 HTML 可靠得多，也正是它让“由智能体撰写消息”成为一个可行的想法，而不是一个演示。

首次运行时粘贴一个 URL。ClickSomo 会读取页面上的标志、图标、清单以及它实测到的颜色——不是谁猜出来的颜色——并生成一封第一眼就像你自己的邮件。它还会检测平台，这通常足以建议一个值得拥有的漏斗：商店会得到弃购挽回，出版方会得到新闻通讯欢迎。

你提供的每个 URL 的抓取都经过一个受保护的抓取器：仅限 HTTP 和 HTTPS，字面地址直接检查，每个 DNS 应答都必须是公网地址，每一跳重定向都重新校验。替客户抓取任意 URL 是在自己网络里挖洞最简单的方式之一，这种代码不该写两遍。

老实说：从你的网站生成的第一个模板是个不错的起点，而不是成品设计。它把标志、颜色和字体大致弄对，让你第一次发送不至于看起来像演示——然后你再去编辑它，这可比盯着空白画布好干多了。