不用写一行代码，AI 帮我复刻任意公众号的排版 + 配色

我不会写代码。但这 24 小时里，我和 Claude 一起做了一个叫 mofang 的skill——丢一个排版好看的公众号链接给它，它会先学那篇文章的版式节奏，再换成我自己的配色，最后把我的 Markdown 稿子排成一份能直接贴进公众号的 HTML。

如果你也不会写代码，但试过用 AI 做点什么——做完发现效果不太对，又不知道哪里该停哪里该继续——这篇文章是写给你的。

我不打算教你怎么做一个 mofang。我想给你看的是：一个不会写代码的人，是怎么一边和 AI 协作、一边判断"这个值不值得继续"的。中间推翻过三次设计，踩了两个坑，跑废过一版。每一次喊停或者放行，都是一个普通人也能学会做的判断。

1

先说清楚我为什么要做这个

上周我发了一篇《Clawdy 诞生》，评论区有人说排版好看。

其实排版不是我做的。我的办法很笨，但对不会代码的人很实用：找一篇排版好看的参考文章，把它的源代码扔给 AI，把我喜欢的复古绿配色也扔给它，再把我的 Markdown 扔过去，AI 拼一份 HTML 给我。每次都灵，每次都要手动重走一遍。

我就想，能不能把这个流程打包成一个固定的 skill？下次我只要丢一句"这个链接 + 我的稿子"，它就能自己跑完。

4 月 21 日上午 11 点，我开了一个新窗口，跟 Claude 说了第一句话。

2

兜了一圈，才想明白自己要什么

一开始我没直接说要做 skill。我先问了一个拐弯的问题：

我平常用 135 编辑器填公众号链接，它能显示源代码，这个是怎么实现的？

Claude 给我拆了一下。简单说，这事不能靠浏览器前端直接做，得让服务端去拿文章源码，再清洗成能用的内容。

我听懂了，然后亮底牌：

我想把这套流程做成一个 skill。但我最担心一件事——给一个公众号 URL 能自动抓到正文吗？技术要求高不高？有风险吗？如果不能自动抓，我就先不做了。

Claude 说能抓，不难。公众号单篇文章页并没有难到离谱，服务端正常请求就能拿到 HTML，正文也有明确的容器能定位。

那一刻我才从"要不要做"切换成"怎么做"。

然后我让它去偷师——我记得之前装过一个 wechat-mick 是总结公众号文章的，让它翻了一下人家源码。果然，就是我想的那个套路。

Claude 给了我两条路：

a. 月鹿专属骨架模仿器——把我那套复古绿固化，骨架从 URL 抽

b. 通用排版 skill——不绑定任何主题，配色完全看用户

我说：先 a。

先问拐弯的问题，再亮底牌

3

一句话推翻了自己最初的设计

Claude 已经开始搭目录、写 YAML、建脚本了。搭到一半，我突然觉得哪里不对。

不对。我想要的不是"永远输出复古绿"。

我觉得我想要的不是输出复古绿，而是根据源代码进行模仿，然后再自定义颜色。复古绿只是其中一个配色方案。这可行吗？

这句话是整个 mofang 的设计拐点。

Claude 接得很稳：完全可行，而且更合理——这才是真正的骨架 + 皮肤两层解耦。

骨架可变，皮肤可换

原来我脑子里的模型是"月鹿专属骨架模仿器"——骨架可变，配色永远复古绿。Claude 帮我把它重构成了"骨架模仿器 + 可插拔主题系统"：复古绿只是内置的第一个主题，以后可以无限加。

顺着这个思路，我把配色入口也想清楚了。因为不会设计的人和专业用户，要的根本不是一回事：

· 我自己这种不懂设计的人，希望发一张喜欢的封面图，让 AI 帮我配色

· 如果是专业设计师或公司用户，他们会有固定品牌色

· 如果想继承那篇参考文章的气质，就直接从源码里抽色

后来 mofang 里那个"配色 5 选项"，就是从这段对话里长出来的：内置主题 / 从参考文章抽色 / 从图片抽色 / 品牌色自定义 / 描述风格。

Claude 给方案起了个名字叫 remix-structure，我立刻回：

这名字能不能起简单点，复杂的我不会用。

给我 4 个候选：mofang / fangpaiban / chao / paiban。

就叫 mofang。两个字，拼音，不用解释。

4

第一次跑通——它开始像个真能用的东西了

骨架和主题系统搭完，我拿了一篇蓝调风格的参考文章 + Clawdy 那篇 Markdown，让它跑一遍。

第一版蓝调 HTML 出来的那一刻，我其实有点不敢相信。参考文章的版式节奏还在，配色换成了我选的蓝调，文字也已经是我自己的。三样东西真的拼上了。

然后我开始疯狂换配色。发一张封面图让 AI 读图取色，再生成一版；换一张图，再生成一版。几轮下来，同一篇《Clawdy 诞生》的 Markdown，跑出了好几套完全不同气质的 HTML——复古绿、蓝调、暖金，每一版都是同一篇文章，气质却各不相同。

同一篇文章三种配色对比

同一套骨架 + 同一篇文章 + 不同配色 = 完全不同的视觉气质。

这一刻 mofang 不再是一个想法，它是一个能跑起来的工具。

5

关窗重来——两个坑都是这一步暴露的

我做了一个对自己很狠的动作——关掉当前窗口，开一个新窗口重新跑一遍。

因为同一个窗口里的 Claude 已经记得我所有偏好了，skill 怎么跑都不会出错。只有冷启动状态下，才能看出 skill 的说明书是不是真的写得够清楚。

结果两个坑连着爆。

关窗重来，两个坑连着爆

第一个坑：数字选项两层菜单冲突。

新窗口里我先让它写了一篇《AI 装傻：一场静悄悄的对齐危机》，然后用 mofang 排版。配色选项它给我 1-5 这样的菜单。我回 2，它抽了一套亮蓝 + 警示橙的色板给我看，然后又弹了一层菜单：

是否开始生成？ 1. 就用这套色　　2. 调整　　3. 换一种方式

我回 1——本来是想说"就用这套色"。

Claude 把这个 1 理解成了"回到上一步选第 1 项（复古绿）"，生成了一份复古绿的 HTML。我人都麻了。

两层菜单都用 1-5 做选项标号，用户回一个"1"，AI 在两种上下文之间会猜错。这是工程细节，但一错整篇文章就跑废。修：色板确认那一步改用「确认 / 调色 / 重选」关键词，明确避开数字。

第二个坑：抽骨架的脚本只能认粗类型，抽色也会抽错。

修完菜单之后我重排，对着参考文章截图一看，又不对——框架还是我那个模板复古绿的框架，框架和颜色都错了。

这次参考的是一篇 Lovart 的文章。Claude 一开始从源码里抽出一套亮蓝 + 警示橙的颜色，我当时也没多想。后来它把真实 HTML 源码重新完整看了一遍才发现，真正决定整篇气质的其实是翡翠绿 + 芥末黄。问题就在这里：如果只是机械统计出现次数，AI 很容易把"装饰色"误判成"主色"。

然后更离谱的是，抽骨架的脚本只能识别"这里有一个 section"，但识别不出"这到底是竖排大数字章节头，还是黄色荧光笔小节标题"。所以 Claude 拿到一份粗骨架之后，其实还是在用我原来的模板往里面填。表面上颜色换了，骨架没真的换。

Claude 看了截图上几个局部，就开始给我讲参考文章的骨架是什么样。我拦住它：

你不要按我发你的截图，而是要看源代码。

它回我的那句话让我印象很深——"你说得对，我确实不够严谨。刚才我截取到的只是正文前 4000 字加几段局部片段，然后就下结论骨架就是这样。但整篇正文有 42274 字，我只看了约 10%。"

能拉到不等于看清楚，看到几段不等于看完整。AI 太想给我一个"完整答案"，但很多时候它是拿 10% 的信息补齐剩下 90% 的想象。

两条路摆在我面前：A 让脚本抽视觉指纹（CSS 特征），实现复杂还容易抽错；B 让 Claude 自己去看真实 HTML 源码逐组件复刻，token 贵但能做。我选了一个更根本的方向：

不是复杂链接，是复杂模板。有些纯 SVG 生成的文章，我感觉这种就不太行。

复杂模板本来就不应该硬复刻。识别不了就不要硬上，老老实实告诉用户"这篇我搞不定，你换一篇"——比跑废一整篇更好。

6

最重要的一课：让 AI 先学会说"做不到"

我们换了一篇更规整的参考文章重跑——黄叔的《Skill 和 CLI：经验指导能力》。

Claude 扫了一遍源码，告诉我：正文只有 31KB（上一篇 42KB），section 数 41（上一篇 100+），主色系只有 3 种，5 个 PART 章节头全部是同一套竖排布局，组件种类少 + 样式统一。结论：能做，能到 85%。

这次 Claude 老老实实把正文里的组件都扫完，列出真实会用到的几类版式元素，然后再按真实 HTML 一段段复刻出我的《AI 装傻》那篇。深色主标题卡、浅橘大数字 PART 序号、奶黄荧光笔高亮、深色引言块加橘红左边框，全部对得上。

我看了一眼说：对很棒，就是这个效果。

按黄叔公众号骨架复刻的对比图

那一刻我决定把"能不能做"这件事也写进 skill 本身。

我对 Claude 说：加一个可行性自评环节——抽完骨架之后你自己先打分，按 4 个维度评估（组件种类数 / 样式统一度 / SVG 复杂度 / 主色数），平均分乘以 20 作为相似度预估。

我最开始说："用 70-85% 作为预期吧。"Claude 纠正我：

这个预期值应该是我来评估的，可以 50% 也可以 10% 或者 90%。太低的话建议用户换链接。毕竟 token 太贵了，尤其是 Opus 模型，跑废一篇花不少钱和时间。

对。这个判断不该我定，该 AI 自己做。最后 mofang 的可行性自评长这样：

· 相似度 ≥70%：值得做，直接继续

· 相似度 40-70%：降预期 or 改用内置主题

· 相似度 <40%：强烈建议换一篇参考文章

低于 40% 会主动劝退。还把"复杂模板"的两类红灯文章直接写进 SKILL.md：SVG 密集型（整篇 SVG 画图标和标题文字），深度定制型（每章节换一套设计、横向滑动目录、flex 多层布局）。

AI 最值得信赖的一面，不是它什么都能做，是它能告诉我"这个我做不好，换一个吧"。

7

要开源，就不能只属于我

尾声我跟 Claude 说了一件事：把这个 skill 里所有"月鹿专属"的痕迹改掉，别人也要能用。

这是最难的一件事。因为从头到尾，它就是"月鹿用的"——默认主题叫 retro-green.yaml，文档里到处是"月鹿默认 / 月鹿常用"。

改完之后：默认主题重命名为 yuelu-zaowu.yaml 并标注"内置示例主题"，额外补一份 _template.yaml 让用户照着建自己的主题，所有"月鹿默认"的字眼换成"内置主题"。

保留作者签名，但明确它只是一个示例。工具的终点，是让它不再只属于创造者。

8

如果你也有一件总在手动重做的事

如果你是 Claude Code 用户，mofang 最后长这样——它的工作流是 6 步：抽骨架 → 可行性自评（Claude 自己打分 + 三档建议，<40% 劝退）→ 确认骨架清单 → 配色引导（5 选项 + 关键词确认，避开数字歧义）→ 按骨架生成 HTML → 输出到 Markdown 同目录下的 -wechat.html。

mofang 目录结构

mofang 6 步工作流程图

触发方式：/mofang <URL> <md路径> 或 "模仿这篇排版 <URL>"。

完整代码我开源在 GitHub：github.com/lunaark/mofang-skill，clone 下来按 README 装就能用。

但我觉得，这篇文章真正重要的不是目录结构，而是下面这三件事。哪怕你不用 Claude Code，只要你手上也有一件"每次都能做成、但每次都要手动重走"的事，它们也一样有用。

第一，冷启动测试是检验 skill 的唯一方式。同一个窗口里永远不会出错，因为 AI 记得你的偏好。只有关窗重来，才能看到说明书写得够不够清楚。

第二，分叉点用关键词，不用数字。只要你的 skill 有多层菜单，数字选项一定会打架。用「确认 / 调整 / 重选」这种词，不会歧义。

第三，让 AI 学会说"做不到"。与其硬做跑废一整篇，不如让它先诚实打分、主动劝退。时间和 token 都很贵，早点承认做不好，往往比硬撑更接近真正的效率。

这 24 小时之后我的代码量还是 0。多出来的只是一个能跑的 skill，和几次"该停 / 该继续 / 别硬做"的判断。

如果你手上也有一件每次都能做成、但每次都要手动重走的事，那件事就是你的起点。先把它拆清楚，再决定要不要做。