把一套设计系统 fork 成另一个站

做 Kikoman 这个个人站时，我没有从空白页开始。我把朗福官网那套设计内核整个搬了过来， 只换了品牌色和内容——这篇记录这次 fork 具体做了什么、哪里顺利、哪里不顺利。

fork 不是复制粘贴

复制一份代码库然后到处替换字符串，那是「复制」，不是「fork」。真正的 fork 是把内核当成 一个已经验证过的系统去搬运：架构决策不动，只换外壳。这也是为什么 fork 之前那套内核必须先 立在「单一数据源」上——颜色全在 CSS token 里、文案全在 i18n 表里、组件不写死任何字符串—— 不然「只换外壳」就是一句空话，实际上要满仓库找哪里还藏着一个没被发现的硬编码。

三个文件，加一个例外

朗福内核的绝大部分换皮工作确实只落在三处：色彩 token、i18n 文案表、site 配置。原站是橙色的 「热」信号系统，Kikoman 换成霓虹紫：

--color-signal: #a855f7; /* 一处定义 */

改完这一行，全站的链接、激活态、CTA、Hero 效果全部跟着变，因为它们都读同一个 token， 没有第二处硬编码需要手动追。

但 fork 过程也确实揪出了一个漏网之鱼：生成 OG 分享图的脚本 (scripts/make-og.mjs) 是一段 跑在 Node 里、直接拼 SVG 字符串再用 sharp 转成 JPEG 的独立脚本，它不 import 任何 token 文件，颜色是在字符串模板里手抄的十六进制。这一处没法靠改一个 token 联动，得手动把十六进制 值换成新色板。这恰恰是 fork 最有用的地方：它不会说谎——真的做一次搬迁，才知道「单一数据源」 哪里是真的、哪里只是看起来是。

收获

最大的体会：纪律不是负担，是杠杆，但杠杆有多长要靠 fork 一次才能量出来。前期把单一数据源、 视觉自检做扎实，后期复用时一个完整的站几小时就能立起来；没做到位的那一小撮硬编码，也只有 真的 fork 一次才会浮出水面——留着继续记账，下次 fork 时先补上。

这次 fork 的源项目在本站有完整的 case study：朗福官网—— 这套内核的真身外链也挂在那里。