创意

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

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

六个目标，一个来源

每个目标都有一些不容个人口味的约束，渲染器了解它们，你就不用操心。

电子邮件意味着表格和内联 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 会读取页面上的 logo、图标、manifest 以及实测的颜色——不是谁凭感觉猜的颜色——并生成一封第一眼就像你自己的邮件。它还会检测平台，这通常足以建议一个值得拥有的漏斗：商店会得到弃购挽回，出版方会得到新闻通讯欢迎。

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

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