这一阶段最值得说的，不是又加了几个功能，是平台的形态变了。
过去它是一套装在客户服务器上的系统。现在它是两套：一套仍然装在客户服务器上，负责内容、页面与接口；另一套在我们这边，负责授权签发、客户与实例台账、发布包与更新、官方托管存储、官方 AI。两套系统通过签名接口协作，各自独立，不共享数据库。
这不是架构上的洁癖。分不分家，取决于三件事有没有着落：授权能不能收回，版本能不能下发，出了问题能不能诊断。装完就失联的系统做不到这三件事，所以我们先把这三件事做出来了。
一、为什么要分成两半
装到客户服务器上的系统，最大的问题是交付之后看不见。域名换了、证书过期了、磁盘满了、版本停在半年前——客户不说，我们不知道。等知道的时候，通常已经影响到生意。
中控台解决的正是这一段。客户机激活时用激活码换取授权文件，中控台按客户档案推导出存储前缀；此后定期上报实例信息——域名、IP、版本、健康度，形成一份台账。不是监视，是让交付之后还有人负责。
几条具体的做法，能说明这套东西的分寸：
授权仍然是离线的。客户机断网也能运行，不依赖我们的服务在跑。在线部分只负责激活、续期与更新验证，不做实时管控。这是刻意的：把客户的关键业务绑在我们的可用性上，是一种不负责任的交付方式。
托管存储用临时凭证。客户机以签名换取 STS 临时安全凭证，权限按客户自己的前缀收窄，直传官方存储桶。凭证是临时的，桶是隔离的，我们看不到客户的其他文件。
官方 AI 走四道门。授权签名校验、请求签名头、功能位、积分余额，加一层 IP 限流。任何一道不过，请求就停在门外。
更新走信箱，不走推送。中控台管理发布包，客户机从更新信箱领取升级请求，由宿主机上的脚本执行。什么时候升、升不升，决定权在客户那边。
二、产品这一侧，补的四件事
会员体系。会员运行时以注入脚本的方式挂到前端站点，登录入口是一个可拖拽吸附的悬浮球，登录面板做成右侧抽屉。为什么不嵌在页面结构里？因为客户的前端是各自定制的，会员入口不能要求他们改版式——能力要能挂上去，而不是要求页面为它让路。
模板版本库。在线模板、模板编辑器、预览、拷贝，加上开发槽、线上槽与历史版本三档并存。改版可以先在开发槽里做，看完预览再切；切错了能退回上一个版本。这条链路是我们自己改官网时天天在用的，也是上一篇文章里说的「对话即改版」的底座。
数字资产统计。作品统计、文件组合、网站访问、接口与 MCP 调用、爬虫统计、日志归档，前后八个阶段做完，后台配了数据大屏。做这件事的原因很朴素：客户问「这个站到底有没有用」，我们不能永远只回答「看起来还行」。
支付验签换了一套方案。0.9.42 把微信支付验签从「平台证书」换成「微信支付公钥」，两侧同步改造，旧方案彻底移除，不留兜底。留兜底听起来稳妥，实际上是两条路径都得维护，迟早有一条没人测——真出问题时，坏的一定是没人测的那条。代价也说清楚：已经配置过平台证书的存量站点，必须到后台「支付设置」里改填公钥与公钥 ID，否则微信回调仍会验签失败、订单仍挂在未支付。这条我们已经逐个通知。
顺带修了一个小问题，但取舍值得记一句。回收站缩略图原来要走鉴权中转接口，线上一直转圈。现在改成直连：对象存储的删除是把文件复制到同桶的 trash/ 前缀再删原件，副本仍然可以直连访问。代价是回收站地址可以由原地址推导出来——已删文件理论上能被猜到。我们接受这个代价，因为回收站本身就是「可恢复」的语义，用一点可知性换掉一直转圈，是值的。
三、产品成熟度，藏在部署链里
这一段不产生任何功能，但它决定了「上线」是一次冒险还是一次流程。
部署脚本现在的顺序是：环境检查，缺失的配置自动生成随机密钥；依赖校验，先探测软件源可用再决定要不要清理重装，避免「删了依赖却装不上」的中间态；部署前预检，主版本、磁盘空间、内存与交换分区；构建；迁移前自动备份，破坏性语句预检拦截建表类的删除操作，迁移失败自动标记回滚并重试一次；nginx 配置幂等注入，按本站端口生成副本，避免同机多站串站；最后重启、轮询接口核对迁移是否全部应用、清空页面缓存。
两个细节值得单独说：前端构建先出 dist.new，校验 index.html 存在后才整体替换 dist——历史上构建被中断留下半个产物，直接导致后台 403；运行时目录属主在部署时修正——用 root 建的目录会让应用写盘失败，报出来的却是 500。
这些都是被事故教出来的。产品成熟度不体现在功能列表上，体现在这些地方。
四、这一阶段的账目
数字平台 0.9.42，59 次数据库迁移，54 个服务文件，27 个系统子模块，后台 52 个页面；中控台 39 次迁移，16 个模块，20 个页面，23 个服务。
测试是 775 个用例、775 通过；中控台 105 个用例全部通过。数字看着平常，但对一个一直在改的系统来说，全量回归能跑干净，才敢往外发版本。
五、下一步
平台这一侧还会继续往三个方向走：平台级的 AI 能力中心、经接口与内容系统互通的外挂画布工具、CRM 的在线模板服务。三件事都还在路上，等成型了再单独写。
写在后面
回头看这一阶段，做的事大多不在表面上：授权、台账、发布包、凭证、部署脚本、迁移备份。它们不产生好看的截图，但决定了这个平台能不能被长期使用。
我们对「产品化」的理解只有三条：改动能退，操作能查，版本能更新。这三条立住了，才谈得上让客户自己动手——毕竟把系统交给别人用，前提是出了问题收得回来。
这条路还在走，进度会继续写在这里。