Lolly 面向运营方
一套面向未来、纵深防御的数据防泄漏与溯源策略——只不过它恰好是一个创意生产平台
这是一套包裹在你现有工作方式之外的零信任组织免疫系统——让团队每天都需要的日常创意工作发生在你的边界之内，而不是从边界泄漏出去。
这对你有什么好处。 你将成为那个对既安全又受欢迎的方案说“是”的人。你一举堵住了一个数据外泄漏洞、获得了新能力，还清空了一条需求队列——这是少有的、让你更受欢迎而非更招人厌的安全举措。不会再有法务部门凌晨三点打来的电话——起因是机密文件或客户数据流入了某个来路不明的网页工具；你要应付的 SaaS 供应商、合同和审计也变少了；而且有一套完全可复现的审计记录，可以在有人问起时随时拿出来。你可以睡个安稳觉，也顺带让周围的人跟着轻松几天。
Lolly 绝非低人一等的创意工具：它把可直接投产的成果交到每个人手中，其品牌导向的创作体验更是首屈一指。它之所以能够如此大范围地安全分发，原因在于架构本身：没有任何你没有主动放进去的内容会被上传，每一份结果都可复现，每一次导出都可以携带多层业界领先的加密记录。无论一份文件是经过怎样的辗转到达你的桌面，你都能看清它完整的来源、判断它是否遭到篡改，以及能否将它像素级地重新生成。
目前的进展。 Lolly 的安全特性在设计上就很过硬，其加密与文件解析引擎正在接受 SUSE 企业级的基础设施加固。下文提到的签名封印、设备端签名与加密现在都是真实且站得住脚的，并正朝着独立认证不断成熟——因此在合同要求认证保证的场合，请在该流程完成期间将它们作为纵深防御的一层来部署。
战略优势
日常创意工作通常的完成方式，本身就是一个风险暴露面：文件通过邮件发给外部设计承包商，品牌素材被上传到十几个 SaaS 编辑器，客户数据被粘贴进陌生人的网页工具里，只为“快速做张图”。这些做法无一例外，都是数据在脱离你的掌控。
Lolly 把这个局面反转了过来。那些引发外泄的工作——语录卡片、本地化横幅、活动徽章、打码截图——现在都在员工自己的设备上完成，套用你的品牌，全程没有服务器介入。你不是在高风险的流程上叠加一层管控，而是用一个从一开始就不存在外泄路径的流程，取代了那个高风险的流程。
- 配置权在你手中。 引擎与各个 shell 均为开源（MPL-2.0）。你可以叠加自己的身份认证、遥测或 CA；可以自行托管，也可以不托管；功能与成本完全由你掌控，一切都有 git 记录可查，不会被锁死在某个 SaaS 数据库里。
- 治理可以是数据，而不是仪表盘。 当你需要这种管控时，可以把工具目录（catalog）作为 Git 仓库来管理——pull request 审核就成了品牌审批，员工能接触到的每一个模板，你都拥有完整的审计记录并可即时回滚。这是一种可选项，而非义务：只想做东西的团队完全可以在 Layout Studio 中编写自己的工具、把自己的文件导入目录（catalogue），全程在应用内完成，从不接触 git。参见采用与治理。
- 护栏是结构性的。 品牌约束被硬编码进模板本身，而不是作为可以被人忽视的指导方针发布出来。错误的产出不是被“不鼓励”，而是根本无法产生。
在扩大内容产出的同时清空需求队列
Lolly 的目标之一是设计需求分流：让常规请求永远不需要送到设计师手上，因为需要素材的人自己就能在几分钟内正确地做出来。每一张被分流掉的工单，既是效率上的胜利，也意味着少一份文件在人与人之间流转。
Lolly 的设计初衷是贴合你的组织实际运作方式——部署它并没有唯一正确的方式：
- 分发部署，而非集中托管。 通过你现有的 MDM（Intune、Jamf、Munki 等）把 Lolly 推送到各设备。它以桌面/移动应用或离线 PWA 的形式在本地运行——可在任何防火墙之后、任何隔离网络环境中使用，无需维护服务器，更新节奏完全由 IT 掌控。
- 仅集中托管。 在你的网络内部（或 VPN 之后）运行一个实例；用户通过浏览器访问，无需安装任何东西。发布一次工具，所有人立即可用；搭配你的身份提供方（IdP）实现访问控制。
- 混合模式。 离线外勤用本地应用，借用设备用始终最新的浏览器版本——两者指向同一个工具库。
防外泄工具
Text Helper 提供的是同一笔交易，只是针对文本而不是文件。它就是员工原本会跑到陌生网站上去找的那种分页式工作台，而且它完全没有声明任何输入项，因为它处理的一切都不会离开这个页面。
Compress PDF 补齐了这一组：过大的附件会按照你选择的质量档位被压小，而且就在那台本来就存着它的机器上完成。
有一类 Lolly 工具——即隐私工具——专门用来把文件留在边界之内。
- 清除隐藏数据
从文档和媒体文件中移除位置信息及所有隐藏的身份识别信息。
- 文本助手
对结构化与非结构化文本进行匿名化、编码、格式化及各种处理。
- 压缩 PDF
在设备端为体积过大的 PDF 瘦身，这样在文件大到无法通过邮件发送时，就没有人需要求助于第三方“帮我压缩 PDF”的网站——而这恰恰正是数据溜走的地方。
以上这些都是设备端本地转换：你的文件或数据进去，干净的字节出来，而且没有任何服务器可以上传。它们是刻意反其道而行之的产物——与那种善意员工原本会去使用的、典型的“把文件上传到陌生网站清洗一下”的工具截然相反。
确定性与可复现性
Prompt to Image 是确定性最朴素的样子：文字就是全部的输入，排好版的图片就是全部的输出，而同一段文字永远会排成同样的结果。
每一个工具的输入都可以表示为 URL 参数，相同的输入总是产生相同的文件。这对运营方来说有两个直接影响：
- URL 本身就是产物。 提交这个链接，按需重新生成素材即可——不必把二进制文件提交进 Git，也不必在聊天记录里追查“最新版本”是哪一个。素材与工具的 ID 是永久性的约定，因此今天生成的链接，日后依然能够正确解析。
- CLI 与 GUI 走的是同一条渲染路径，因此构建流水线与应用程序永远不会产生偏差。可以在构建阶段以可复现的方式生成 OG 图片、社交卡片和数据可视化图表。
溯源与 Content Credentials
导出的文件可以携带 Content Credentials——一份签过名的 C2PA 清单，与文件字节的哈希值绑定。之后对文件的任何改动都会破坏这枚封印，因此支持 C2PA 的验证工具能够在离线状态下、以密码学手段检出篡改。这份凭证是可察觉篡改的：它标示出篡改，而不是阻止篡改——而这恰恰正是完全离线验证得以实现的原因。
- 默认开启，设备端完成。 签名密钥在设备上生成，不可导出（连 Lolly 自己都读不到），签名过程在本地完成——只有可选的身份注册环节才会涉及网络。
- 信任分级。 未经注册身份的导出文件在结构上是有效的，但只是匿名签名（
untrusted）。注册一个已验证身份（由 Lolly CA 签发、与邮箱绑定的短期证书）之后，锁定 Lolly 根证书的验证工具会报告trusted以及签名者的邮箱。可信时间戳机构与第三方验证工具的绿色认证（C2PA 合规）都已列入路线图。每一级信任都是明确标注的，一份文件只会声称它能够证明的信任程度。 - 凭证有效期由运营方/用户在签名时自行决定：7 / 30 / 90 / 365 天，默认 30 天。
- Lolly Imprint。 这是一枚默认开启的第二重互补信号：一种烘焙进光栅导出文件（以及 PDF/PPTX 内由 Lolly 渲染出的位图，但绝不包括用户自行嵌入的图片）中的隐形像素水印。凭证一旦容器发生任何改动就会失效，而 Imprint 却能在重新保存或截图后依然存活——它是一枚持久的“这些像素曾经过 Lolly”的提示，只标示存在与否，不携带任何个人数据。它属于“隐蔽式安全”，而非加固级防护，用来补充凭证，而不是取代凭证。使用
imprint=0可以选择关闭。 - Durable Content Credentials（可选开启）。 光栅导出文件还可以额外携带一枚隐形的持久标记，编码一个软绑定标识符，使得即便社交媒体上传或重新保存清除了文件的元数据（普通凭证在这种情况下会彻底丢失），C2PA 凭证依然可以被找回。该功能仅限光栅格式，且需要经过一次神经网络编码处理，因此默认关闭（使用
durable=1开启）。目前 Lolly 已能在/verify上离线识别自己生成的持久标记；待业界的软绑定解析方案落地后，第三方工具（例如 Adobe）也将能够据此找回凭证。 - 验证在设备端完成。 把任意文件拖放到
/verify（或运行lolly validate <file>），即可离线获得一份报告，说明它是否确实由 Lolly 制作、且此后未被修改。Web 端的 Verify 视图还会标记 AI 生成的内容、检测 Lolly Imprint、验证 SEAL 签名（一种以 DNS 为密钥的字节级签名——唯一涉及网络的环节是一次 DNS 密钥查询，从不涉及文件本身）、可选地深度扫描第三方像素水印（需要一次性下载设备端模型），并揭示隐藏数据——所有这一切都无需上传文件。参见 Content Credentials 身份。
互操作性说明。 Lolly 如今已能在离线状态下验证自己的凭证以及许多第三方凭证，包括读取其他生产方生成的 C2PA v2 声明清单。还有一项互操作性工作仍在进行中：WebM——目前尚无标准化的 C2PA 映射方案，因此 Lolly 将清单以 Matroska 组成部分的形式附加（第三方工具可以开箱验证 Lolly 的 MP4；WebM 将在标准确定后跟进）。
加密与密码保护
对于必须加锁传输的文件，一切都在设备端完成：
- PDF 打开密码——标准级别是 40 位 RC4，起威慑作用（可在任何地方打开，可随链接传播）；强级别是 AES-256（PDF 2.0），在导出时输入，且绝不会出现在链接中。
- 锁定下载——一个 ZIP、一个 Projects 文件夹，或一次批量运行的结果，都可以整体加锁：标准为 ZipCrypto（较弱但通用性强），强为 AES-256（WinZip AE-2）。纵深防御体现在：强级别压缩包内的任何 PDF，也会同时被单独加上 AES-256 锁，解压后依然保持锁定。
- 密码保护的分享链接——整个链接状态都在一个由 PBKDF2 派生出的密钥下进行 AES-256 加密；传播的只有密文，密码从不出现在链接中，解密在接收方的浏览器中完成。
隔离网络就绪
隔离网络是一种一等部署方式，而非某种特殊模式——Lolly 开箱即可在渲染时完全不依赖网络运行。Web shell 是离线优先的 PWA（service worker）；字体和 WASM 都存储在设备本地；工具状态通过 host bridge 在本地持久化，绝不使用 localStorage。任何需要联网的工具，都必须通过其清单中声明的、经过白名单限制的 host.net 能力才能访问网络——无法（或不愿）满足该能力的 shell 会以空实现代替。通过你的 MDM 把各 shell 推送到设备，或在你的网络内部运行一个实例，一套完全隔离网络的安装即可完成渲染、导出、加密与凭证验证，全程无需向任何外部“回传”数据。
值得了解的事项
在推广部署之前，有几件事值得先弄清楚：
- 加固进行中。 加密与解析器正在接受 SUSE 企业级规模的加固（见上文）——如今在设计上已经过硬；在合同要求认证保证的场合，请作为纵深防御部署。
- *工具钩子不是安全沙箱。 工具可选的
hooks.js运行时会注入 host bridge，但在浏览器 shell 中，它是在页面的作用域内执行的，可以*访问window/document/fetch。请像对待任何你要运行的代码一样对待工具代码——审查它。正因如此，运行共享目录的组织可以通过 Git 审核为其把关；无论采用哪种方式，在 Worker 隔离机制上线之前，都只运行你已审查过的工具。 - Content Credentials 是可察觉篡改的。 它们检出篡改，而不是阻止篡改——参见上文的互操作性说明。
- 两种加密等级。 标准级别的锁是快速、通用的威慑手段；强级别（AES-256）才是完整的保护——任何敏感内容都应选用强级别，但要注意它需要较新的阅读器。