内容、工具与文件各归其位：主站与 VI 的架构取舍

一篇文章要加入动态图表，一个视觉工具要增加资料包，素材开始放到对象存储：这些事情看起来都叫“给网站加内容”，实际改变的责任却不同。我的主站与 VI 正在遇到这些边界，整理它们比先决定换 CMS 更有价值。

目前主站依然通过文件维护内容，CMS 和主站 R2 都不在本次实现范围。VI 则已有公开展示、私人资料 Worker/R2 和本机制作工具。把两者连成一套系统时，需要既能共享身份与规则，又能清楚说明每部分真正做到了什么。

先分清内容、功能、资源和来源先确定内容、工具与文件各自负责什么。

文章类型用来组织阅读，目录或 slug 不应该成为永久身份。同一图表模块可以被两篇文章调用，同一个文件可以被多篇正文引用；它们不需要复制成不同实体。新增“架构”“声音”“转场”分类也不意味着重建一套路由或存储。

发布状态、资源操作与可用位置要分别判断。中文文章发布了，不会自动产生英文正文；文章公开了，不会自动允许额外源文件下载；工具声明 use/export，也不代表它已在线执行。一个看起来可点击的按钮无法代替真实交付和服务端授权。

正文如何引用图表和下载，可以直接看下面的代码。第一段是当前资源块的真实形状；第二段展示图表块的装配方式，graph 取自本条目的 data/diagrams.json。正文保存数据与引用，React 实现留在模块目录。

{
  "type": "resource",
  "kind": "downloads",
  "id": "content-system-skill"
}

const figure = {
  type: "interactive",
  module: "architecture-map",
  version: 1,
  params: { graph },          // 有界的节点与关系数据
  fallback: {
    mediaId: "content-pipeline",
    text: "文件来源通过校验与读取边界，进入公开阅读。",
  },
};

文件只是当前来源，契约决定可持续维护

查看大图 ↗

作者维护 entry、资源与交互代码。生成器验证身份、语言、来源与引用；读取层分别服务摘要、正文和轻量网址。文章引用模块版本与资源 ID，文件交付另行映射。未来 CMS 改内容来源，R2 改文件来源，不重建身份；主站当前未接这两项。

主站每条内容有不可变 ID 的独立目录。record.json 管共享身份、显式 access、媒体和展示配置；zh-cn.json/en.json 各自管理标题、正文、引用、slug、历史 slug 和 publication。assets.json 记录媒体来源，README 告诉下一个维护者从哪里复现、如何验证。辅助 JSON 放 data，避免被扫描器误认成语言版本。

生成器把作者文件转成完整内容、轻量网址登记、资源登记和按需模块加载器。公开列表只拿摘要，详情才拿正文；proxy 与 sitemap 不必拖入整篇文章。轻量路由只投影公开 discover，不携带其他操作或私人 policy ID。生成结果由工具更新，不手工改登记文件。

公开路径由集中 routes API 生成。locale 在请求入口确定，服务器与客户端消费同一上下文；组件不再从浏览器或路径猜一次语言。中文与英文正文独立发布，旧无前缀中文地址和历史 slug 保留别名。对日后 CMS 来说，这些身份与语言契约比选哪一家内容服务更重要。

图表代码共享，文章语义留在文章

这两篇文章需要结构图和责任对照表，不需要假造吞吐量或性能柱状图。创作软件的调用关系与源码依赖必须分开；主站和 VI 的生成、授权、交付也不是一张万能层级图。每张图都注明箭头含义，把有限实现与后续设计分开。

图表可组件化的是呈现能力：分组节点、关系筛选、键盘选择、手机布局、错误处理。不能把某个项目的业务术语和“主站已接入 CMS”这样的判断写死在共享组件里。文章保存自己的 graph 参数与节点说明，组件只解释版本 1 的结构。

图表显示的是这篇文章自己的关系数据，布局由公共组件处理。读者直接点击图上的节点，说明与相邻关系就在图内出现；无需先切换一种阅读模式。手机会改成较大的节点，静态图仍作为无脚本和加载失败时的回退。

图表属于正文能力，所以文章仍是 article；Skill ZIP 是下载文件，独立登记为 downloads resource。模块版本、Skill 版本和内容 ID 各自表达不同身份。制作源需要时放 design/content，当前 SVG 从结构化图数据直接生成，没有另建空的设计工程。

VI 的制作与交付边界是另一种实践

查看大图 ↗

VI 从品牌源生成展示和 AI 资料。公开 site 只发布白名单成品；既有私人字体/资料经 Worker 授权后读取私有 R2。本机 Type Weave 和声音学习保持本机可用。真实用户权益及远程处理是后续设计；主站的 CMS/R2 迁移与既有 VI R2 是不同事项。

VI 的品牌 tokens 是规则来源。生成器把它投影为公开展示、结构化 AI 摘要、简短 Skill 和按需参考资料；主站只接必要且可追溯的品牌适配与真实截图。制作母版、渲染工具、声音原件、路径配置和听评不因参与品牌系统而变成公开素材。

公开展示由独立 publish/site 白名单包提供。本机制作目录和这个发布仓库有不同版本管理边界，server.mjs 也不是线上运行的完整制作后端。展示、工具和资料交付可以共享规则，各自发布与维护的责任仍要单独记录。

既有私人资料链路通过 Worker 解析凭据和资源操作，再从私有 R2 读字节。资源 registry、会话、访问策略和交付适配各做自己的事；拒绝时应在读取文件之前停止。旧 password/Bearer/Cookie 只是原资料的能力范围，不等同多用户账号、购买权益或对新资源的自动授权。

Cloudflare 的官方资料说明 R2 bucket 默认不公开，公开访问需显式开启。这是存储设置；应用仍需为受限文件定义自己的服务端授权。能阅读的字节可以另存，read/download 的区分管理不同交付范围，不能把它写成防复制承诺。 [来源]

Type Weave 和声音学习仍是本机可用的工具。相对索引与可配置挂载解决搬盘问题，真实路径校验保证引用不会越出素材根；将来上 R2 改的是 locator 和交付，不应该同时重建素材身份、来源、语言或许可。已有私人字体资料上云，也不能推出整套声音库或远程处理已经上线。

为未来留接口，不先造未来系统

迁 CMS 不是把 import 换成 fetch 就结束：生成登记依赖的稳定地址、草稿状态和语言公开范围仍要来自可校验来源。迁 R2 也不该在每篇正文换一遍 URL；正文继续引用资源 ID，在唯一交付登记处改变位置。短期签名地址只在需要时生成，不能成为长期内容数据。

模块、存储和独立应用是三种决定。很多文件可能只需要换文件交付，少量订单却已经需要业务权威。需要持续业务写入、后台转码、GPU、不同部署或独立回滚时，才考虑单独服务。主站保留公开说明与入口，不把交易和处理任务塞进文章字段。

两种架构，共同保住身份与权威

共同原则是把身份和规则留在持久边界，让入口与具体设施可以替换。差别来自真正的状态：创作软件持续修改工程并执行任务，内容主站主要读取经过发布的版本。后者无需复制前者的 command log、完整撤销或实时求值器；形式相似不足以证明所有机制都值得引入。

让 AI 按边界维护，而不是凭文件名猜测

第二份 Skill 把这套判断整理为操作入口：先读项目作者与 URL 约定，辨认 entry/module/resource/adapter，登记来源与真实 availability，再按任务验证。具体路径作为主站案例按需读取，VI 作为制作与交付案例读取，不强迫别的网站照搬文件结构。

文章、Skill 与图表共享同一组经过核对的事实，但承担不同职责：文章解释为什么，Skill 指导下一次怎么判断，图表帮助读者看见关系，来源记录让维护者能回查。现在继续用文件即可，未来换来源时也有明确的地方动手。