以模块积木打造创意工坊： 动态内容框架重构记

在一次系统性重构中，我们让原本只在 Shop 栏目试验的创意组件，变成所有文章都能自由装配的“乐高积木”。这篇文章是一次工程记事，也是面向搜索引擎的技术说明，旨在帮助团队和社区理解整个框架的来龙去脉。

为什么要动“大手术”？

旧架构就像只有一条轨道的火车：Shop 的帖子可以载着动态模块奔跑，其他栏目却只能停在原地。组件必须和 slug 同名，所有线路交织在一起，一旦某个模块脱轨，整篇文章都可能翻车。这种耦合既不利于维护，也限制了我们把创意功能带给更多读者。

为了解决这些痛点，我们提出了一个目标：让每篇文章都像一个拥有标准插槽的创意展台，既能展示纯 Markdown 图文，也能随时接入税务工具、工作流引擎等高级功能。

三步走的结构重构

第一步：把“隐形线路”变成显式元数据

我们在 Supabase 的 posts 与 post_translations 表里新增了 extensions JSONB 字段，相当于为每篇文章配备一份“舞台布置清单”。清单上会写明要挂载哪些组件、放在正文的哪个位置、需要哪些运行参数。即便是 AI，也能照着清单把功能插得稳稳当当。

第二步：重写 Markdown 渲染管线

新的 MarkdownWithDynamicComponents 会先在服务器把 Markdown 拆成结构化 AST，再按扩展清单生成多个动态插槽。想象一位舞台导演在排练前先摆好灯光、幕布和机关，演员（也就是组件）上场时才能流畅表演。这样无论文章来自 Shop、Blog 还是 Tech，都能在保持静态渲染性能的同时享受动态扩展。

第三步：升级组件注册表

我们把注册表从“slug 对应组件”的简易字典升级为 manifest 式的档案库。每个组件都有自己的版本、描述、权限要求以及默认属性，就像档案室里整齐摆放的工具卡片。任何栏目想借用它们，只需在扩展清单中引用对应的 componentId，系统就会帮你把组件和文章拼装在一起。

与图片、翻译的协作

重构期间，我们保留了原有的图片上传流程：创作者在编辑器里贴图，脚本自动上传到 Cloudinary 并回填 URL，不需要额外操作。翻译按钮目前仍是人工校对的“半自动”模式，但扩展清单已经预留好钩子，未来我们可以直接把 Gemini 翻译工作流接入，让多语言内容和创意组件同步上线。

这对未来意味着什么？

• 统一维护成本：组件开发、权限校验、错误兜底都走同一套协议，新增功能像换灯泡一样轻松。
• 跨栏目展示力：Tech、Blog、Education 文章也能嵌入创意工具，让这些栏目真正成为功能展示的橱窗。
• AI 友好度：AI 只要遵守 manifest 和扩展清单，就能把 Python 或 Cloud Run 的原型自然地嵌入文章，人与机器都能快速协作。

结语

这次重构更像是把散落各地的创意乐高收纳进一座模块化工作坊。舞台有了标准插槽，灯光与布景也由元数据提前排好，我们只需把灵感交给组件，便能让每一篇文章都有独一无二的互动体验。接下来，我们会在这个框架上继续打磨翻译工作流和更多服务连接层，让创意功能像空气一样自然地流动在网站的每个角落。