企业官网建设流程全解析

从 Kimi 2.5 上线那天开始，我就一直在琢磨一件事：公众号排版这种重复劳动，到底能不能彻底交给 AI？

先说结论：能，而且我已经用了大半个月。我不光把它当成一个“自动排版的提示词”，而是真的拆成了一个叫“Kimi 公众号排版编辑器”的完整工作流。它不是独立软件，不依赖某个模板网站，本质上是“一套严格约束的提示词 + 一份内联样式规范 + 一个粘贴中转页”。现在只要给我一篇 Markdown 或纯文本草稿，我能在十分钟内得到一份排版干净、有品牌识别度、可以直接甩进公众号后台的成稿。

这篇文章不是来吹新模型的，也不是来做教学的，就是一次完整的项目复盘。我会把提示词怎么设计、每个参数为什么这么定、粘贴的时候有哪些坑、后台过滤样式了怎么办，一条条给你捋清楚。适合所有被公众号排版折磨过的人，以及想拿大模型落地具体工作流的同学。

1. 整体设计：为什么我最终把排版交给了大模型

1.1 传统排版工具的问题

公众号排版这个事，市面上早就有 135 编辑器、秀米这类产品，功能也不算差。但我自己用了几年，越来越觉得哪里不对。

第一是“模板黏性”问题。用可视化模板排出来的稿子，好看是好看，但一眼就能看出你用的是谁家的模板。模板网站更新一版，你收藏的组件样式全变了，排版风格也随之漂移。你要想形成自己的视觉识别度，需要手动去改色值、改圆角、改阴影，改完还得小心翼翼地保存成自己的组件库。

第二是“复制粘贴断裂”。公众号后台本身不是个好的富文本编辑器。从 Word 里粘过来的内容，稍微复杂一点，段距、字体、列表符号全乱。从网页复制过来的，更可能带一堆 class 和 script，后台根本不认。我有一半的时间不是在写文章，是在跟格式打架。

第三是“结构化内容无法被复用”。传统编辑器里，你处理的是视觉结果，而不是内容结构。同一篇文章想换个配色、换个强调风格，基本等于从头排一遍。更别提多作者、多栏目、多专题的批量排版——完全靠手工，效率太低。

所以我的核心诉求从来不是“找到一个更好看的模板”，而是“找到一种能稳定复现排版效果的方式，同时保证内容结构的灵活”。顺着这个思路想下去，答案是现成的：把内容做成 Markdown，把样式写成一套固定的内联 HTML 规范，中间由大模型完成“从内容结构到视觉结构”的映射。

1.2 把排版当成“结构映射”而不是“美化工作”

排版这件事，看起来像是美化，本质上是“结构映射”。什么意思？

你脑子里的文章，是由标题、正文、引用、重点强调、列表、提示框这些“语义块”组成的。而呈现在读者眼前的，是字体、字号、颜色、间距、背景块这些“视觉属性”。所谓排版，其实就是把语义块翻译成视觉属性。

传统编辑器让你手动翻译，于是你要一次次选择字号、选颜色、调行距。而大模型恰好擅长“按规则做映射”——只要我给出足够明确的结构规则和视觉规则，它完全可以替代大部分手工作业。

这也意味着，我的工作重心从“拖动按钮”变成了“制定规则”。一套好规则要满足三点：结构语义不歧义、视觉属性全内联、组件边界足够稳定。前两点直接决定粘贴到公众号后台后还能不能活，第三点决定它能不能长期复用。

1.3 Kimi 2.5 在这个场景里赢在哪

说回 Kimi 2.5。新版本上线后，我最关心的是三件事：长上下文是不是真的稳、指令跟随是不是够准、输出格式是不是可控。

公众号排版这个任务，看起来简单，但实际很吃上下文。一份完整排版规范大概包括视觉变量、组件清单、样式约束、负面清单，字数在 800 到 1200 字左右。再加上一篇两三千字的正文草稿，模型需要在“不忘记规范”的前提下，把内容完整地转换出来。这要求模型把规范当“硬规则”记忆，而不是当“参考信息”带过。

实测下来，Kimi 2.5 在长上下文保持能力上确实有提升。我在提示词里塞了完整规范后，连续排五六段内容，它的色值、字号、边距基本不会漂移。早期用别的大模型，经常前面用墨绿，后面就突然变成深蓝，很让人头疼。

另外它的输出格式控制也更稳定。我要求“只输出 HTML，不输出解释文字”，它通常能直接给我干净的代码块，很少在前后夹带无关内容。别小看这个，这一点决定了你能不能把输出内容直接送进中转页，而不是还要人工清洗一遍。

2. 核心细节：提示词的每个模块都在约束什么

写提示词不是把需求扔给模型就完事。提示词本质上是一份“工程规格说明书”，每一个模块都是在约束模型的自由度。少了某一块，模型就会自作主张；多了某一块，又会让它束手束脚。

2.1 视觉变量：先定色，不要临时发挥

我踩过最大的坑，是让模型“自由配色”。它排完确实好看，但每排一篇换一套色，整个公众号的视觉语言就散架了。

解决思路很简单：不让模型选色，只让它用色。我在规范里固定一套视觉变量，模型每次生成时只能从这套变量里取值，不允许自己发明新色值。

我自己的号走的是“墨绿 + 米白”的安静系风格，具体定义如下：

为什么选这几个色互相搭？不是拍脑袋选的。公众号阅读场景以手机为主，背景以白色为主，正文用#333F3A这种软黑，比纯黑柔和，又不会显得太淡；主色用#1B7B44这种低饱和绿，长时间阅读不刺眼；强调色选偏红的深色，用来盯关键信息，跟主色形成强对比。整套色系压在一起，能形成稳定记忆点。这就是“视觉识别度”的来源。

注意，这里我必须强调一个硬约束：微信后台不认 CSS 变量。你在 HTML 里写color: var(--primary)，后台直接无视。所以所有颜色必须写进内联style属性的实际色值里。这也是为什么我会在提示词里反复强调“把#1B7B44当成一种常量，不要缩写，不要用 CSS 变量”。

2.2 组件库：我把排版拆成了这些“乐高积木”

排版上的重复劳动，本质上是同一批组件在反复排列。所以我定义了一套最小组件库，每个组件都有固定的 HTML 结构和内联样式，作用相当于“乐高积木”。

我的组件清单如下：

• 三级标题：H2 / H3，左侧带主色竖条或者色块底，用来区分章节层级。
• 正文段落：默认字号 15px，1.75 倍行距，段间距 18px，避免手机阅读时粘成一团。
• 引用块：浅色底 + 左侧主色粗边线，用来放编辑人语、文章摘要。
• 强调框：底色块或者描边样式，通常用来放活动提示、关键信息。
• 无序列表 / 有序列表：固定缩进和 marker 色，不跟随浏览器默认样式。
• 重点文字：正文里的加粗强调，统一用深色强调色。
• 分隔线：用浅色border-top的<p>模拟，替代容易丢的<hr>标签。
• 图片占位：不直接给图片链接，用一段文字占位标记，后面在后台手动替换。

组件化的好处在于，不管内容怎么变，组件的外壳不变。你只需要处理内容本身，颜色、边框、间距这些视觉参数全部由模型按规范生成。我连续排了十几篇稿子，成品之间的一致性很高，连读者都能感觉到“这个号有自己的味道了”。

2.3 输出格式与“样式快照”机制

还有一个细节非常重要：输出格式。很多人让大模型排版，模型输出一个<html>完整文档，或者输出一段带<style>标签的内容。这在普通网页里没问题，但在公众号后台几乎必丢样式。

我的方案是：只允许模型输出<section>、<p>、<h2>、<h3>、<blockquote>、<ul>、<li>、<img>这几类基础标签，并且所有样式以内联形式写在style属性里。不输出<style>标签，不输出 class，不输出 id。至于<table>、<iframe>、<script>、<form>这类标签，直接进负面清单。

为什么这么苛刻？因为公众号后台是个强过滤环境。它梯队式地保留一部分标签，过滤掉一部分标签。你把希望寄托在后台“聪明地保留样式”上，不如从一开始就用最基础、最稳定的标签。

为了让模型的行为更稳定，我还在提示词里加了“样式快照”机制。所谓快照，就是让模型在正式排正文之前，先输出一段“视觉规范声明”，把本篇文章里会用到的色值、字号、间距重新列一遍。这样做有两个作用：一是强制模型“进入角色”，二是让生成结果用一个统一基准，避免排到一半突然变风格。

3. 实操过程：从一篇草稿到公众号成稿

这一部分直接上真东西。我把自己现在用的系统提示词，以及一次真实的排版过程拆给你看。你可以直接抄作业，改掉色值就能用。

3.1 完整的系统提示词

下面这段是我当前在用的核心提示词，略微去掉了我文内的品牌占位内容：

你是公众号排版助手。你的任务是把用户给定的内容草稿，转换成一篇文章正文的 HTML。 排版要求： 1. 输出内容必须是干净的 HTML 片段，不能包含 <style>、class、id、script、form、iframe。 2. 所有视觉样式必须以内联 style 属性形式写在标签上，颜色必须写实际色值。 3. 允许使用的标签：<section>、<p>、<h2>、<h3>、<blockquote>、<ul>、<ol>、<li>、<img>。 4. 本公众号视觉规范： - 主色：#1B7B44，深色强调：#C0392B - 正文主色：#333F3A，正文浅色：#5B6B63 - 背景色块：#F0F5F2，分割线：#DCE8E2 - 正文字号 15px，行高 1.75，段间距 18px，全篇左右边距 8px 5. 组件要求： - 大标题：用 <h2>，背景为主色，白色字，圆角 6px，内边距 10px 14px，下边距 22px； - 小标题：用 <h3>，左侧加 4px 主色竖条（border-left），深色字，加粗； - 引用块：用 <blockquote>，背景 #F0F5F2，左边框 4px 主色，圆角 6px，内边距 12px 14px； - 重点提示：用 <section>，边框 1px solid #1B7B44，圆角 8px，内边距 12px 14px，底部留白 16px； - 无序列表：用 <ul>，列表项左侧 marker 用主色，行距 1.6，下边距 14px； - 分割线：用 <p>，顶部边框 1px solid #DCE8E2，左右居中，宽度 90%，下方留白 24px； - 图片不直接输出 <img>，用文字占位【图片占位：这里放描述】替代； - 正文里的强重点，用 <strong> 包裹，颜色为 #C0392B。 6. 操作流程： - 第一步，先输出“样式快照”，简要列出本篇文章使用的色值、组件、间距规则； - 第二步，正式输出 HTML，要求完整、标签闭合，不要省略任何段落内容； - 如果正文较长，可以分几次输出，但每次输出前先提示“第几段”。 7. 只在最终回复中输出样式快照和 HTML，不要解释你在做什么，不要输出额外的建议。

这段提示词看着长，但每个条目都是有意义的。第 1、2 条是硬性底线，对应微信过滤机制；第 4 条是视觉身份；第 5 条把每个组件的“配方”写死，模型不需要思考“标题应该长什么样”，只需要机械地套用。

3.2 给模型的输入草稿

这是我在测试时丢给 Kimi 2.5 的一段原始文字（部分摘录）：

新一批功能清单如下： 第一，文章详情页支持了暗色模式，用户可在设置中关闭。 第二，评论区支持楼中楼回复，但需要用户升级到最新版本。 第三，新增了“稍后阅读”列表，最多保存50篇文章。 需要提醒用户的是，本次更新不涉及收费功能，之前承诺过的免费策略不会改变。

这段文字不是标准 Markdown，比较接近真实写作状态。你把草稿丢进去，剩下的事情完全交给模型处理。

3.3 模型输出的关键片段

模型先输出了“样式快照”，内容大致是这样：

样式快照： - 主色 #1B7B44，深色强调 #C0392B - 正文 #333F3A，浅色 #5B6B63 - 引用底色 #F0F5F2，分割线 #DCE8E2 - 正文字号 15px，行高 1.75，段距 18px - 组件：h2 主色底白字、h3 左竖条、blockquote 浅底左边框、section 描边提示框、ul 主色 marker

紧跟着的 HTML 片段就长这样：

<h2 style="background-color:#1B7B44;color:#FFFFFF;font-size:18px;font-weight:600;line-height:1.5;border-radius:6px;padding:10px 14px;margin:22px 0;">新一批功能更新</h2> <p style="font-size:15px;color:#333F3A;line-height:1.75;margin:18px 0;">本次新功能一共三项，请在升级前留意自己的版本号。</p> <p style="font-size:15px;color:#333F3A;line-height:1.75;margin:18px 0;"><span style="color:#C0392B;font-weight:700;">第一，</span>文章详情页支持暗色模式，可在设置中手动关闭。</p> <p style="font-size:15px;color:#333F3A;line-height:1.75;margin:18px 0;"><span style="color:#C0392B;font-weight:700;">第二，</span>评论区支持楼中楼回复，需要用户升级到最新版本。</p> <p style="font-size:15px;color:#333F3A;line-height:1.75;margin:18px 0;"><span style="color:#C0392B;font-weight:700;">第三，</span>新增“稍后阅读”列表，最多保存 50 篇文章。</p> <section style="border:1px solid #1B7B44;border-radius:8px;background-color:#F0F5F2;padding:12px 14px;margin:24px 0;font-size:15px;color:#333F3A;line-height:1.75;"> <strong style="color:#C0392B;">重要提醒：</strong>本次更新不涉及收费功能，此前承诺过的免费策略不会改变。 </section>

这里注意几个细节：列表项用的不是<ul>，而是把每个条目标成了独立段落。原因是我做过测试，微信后台对<ul>的list-style支持不稳定，有时候 marker 颜色和位置会丢。与其赌它保留，不如直接用文字特征明确的前缀（“第一”“第二”），再加重点色块来区分。这也是“为公众号环境妥协”的一部分。

3.4 粘贴到微信公众号编辑器的正确姿势

模型给的是 HTML 代码，你不能直接把代码粘到公众号后台，后台不会解析代码字符串。正确流程是：

1. 把模型生成的 HTML 保存为一个.html文件（比如preview.html），用 Chrome 或 Edge 打开。
2. 在浏览器里看到渲染好的正文效果，确认排版没有异常。
3. 在浏览器中全选（Ctrl+A），复制（Ctrl+C）。
4. 切到微信后台编辑器，直接 Ctrl+V 粘贴。

这里的关键点在于，当你从浏览器复制内容时，复制的是“渲染后的 DOM 结构”，里面每一层的style都会跟着一起走。公众号后台会按自己的规则过滤一部分属性，但基础的背景色、边框、内边距、字体颜色基本都能保留。

我为什么强调必须经过“中转页”，而不是直接复制代码？因为如果你从代码编辑器里复制的是纯文字字符串，粘到后台就真的是字符串了。只有通过浏览器这个“翻译器”，HTML 才会变成真正可以被粘贴的富文本。这个中转页同时也是你对模型输出的最终检查关卡——渲染不对，就不要进后台。

如果你不想每次新建.html文件，也可以做一个固定的中转页模板，把模型输出的 HTML 粘贴到页面里的文本框，点击渲染，再从预览区复制。本质上是一样的，只是少了一次保存文件的动作。

4. 常见问题与排查技巧实录

这套流程用久了，总会遇到各种状况。我把自己踩过的几个典型问题整理一下，遇到同款情况能少走弯路。

4.1 粘贴后样式丢失或只剩纯文本

这是最常见的翻车场景。排查顺序很重要：

• 先确认你复制的是“浏览器渲染后的部分”，不是代码里的文本。
• 再确认中转页是正常显示样式，如果中转页里就没样式，问题一定出在模型输出那边，去看是不是有<style>标签或者 class。
• 最后确认复制范围。我在微信后台踩过一个小坑：如果光标停在正文之外，粘贴时可能触发后台的“纯文本粘贴”模式，样式全丢。解决方法是先把光标放进正文里，再执行粘贴。

4.2 模型风格漂移，同一篇稿子越改越乱

刚开始用的时候，我让模型先输出一部分，我再追加“改一下第三段措辞”，结果它把整篇风格都改了。

后来我加了两重保险。第一重是“样式快照”，不管我改多少次，快照都在对话里，模型能返回去对齐。第二重是“分块不重新生成”，如果只需要微调局部，我明确告诉它“不要改动其他地方，只重发需要修改的段落”。这样能大幅减少漂移。

4.3 图片无法显示

模型生成的<img>标签，除非你用的是公众号白名单域名里的图片链接，否则都会裂图。

我的策略是：不要直接生成图片链接。让模型在图片位置输出【图片占位：文章封面图，城市夜景】这样的文字标记。排版完成后，在微信后台把占位文字选中，用后台的图片按钮直接插入本地图片。这样既不会被过滤，也能保持视觉位置稳定。

4.4 输出过长导致截断或格式不闭合

文章太长时，模型输出可能被截断，导致<section>或<ul>没闭合。这会造成排版区域错乱甚至全篇崩坏。

实操建议：超过 1500 字的长文，让模型分段输出。第一段排完，检查标签闭合没问题后，再让它接第二段。你可以在提示词里预先写清楚“如果内容超过 1500 字，分段输出，每段开头标记【第一段】【第二段】”。最后把所有段落的 HTML 拼到同一个中转页里检查。

4.5 公众号后台自动过滤部分样式

微信后台有自己的样式白名单。比如position: absolute、margin-left、line-height: normal这些，粘贴后可能被静默删除。别急着怀疑模型，先看看是不是用了后台不支持的属性。

我现在只肥稳定主题用这些属性：

• color、background-color
• font-size、font-weight、line-height
• margin、padding
• border、border-left、border-radius
• text-align、letter-spacing

凡是涉及定位、浮动、变换的属性，尽量不用。样式设计阶段就先遵守这个约束，能省掉大量在后台和代码之间来回切换的时间。

还有一个容易被忽略的细节：同一套样式，从 Chrome 复制和从 Edge 复制，粘贴结果可能有细微差别。我现在固定用 Chrome 做中转页，不用 Safari，因为 Safari 会往粘贴内容里塞一些额外元信息，偶尔会干扰后台解析。

5. 扩展方向与个人经验

5.1 模板复制与批量多栏目

这套“编辑器”的好处是，它本质上是一套可编程的规范。我不需要为每一篇文章重新想配色，只需要在提示词里替换“视觉变量”，就能快速切换不同栏目风格。

比如我的号分三个固定栏目：

换栏目时，我只需要把提示词里的几个色值替换一下，剩下的组件逻辑完全不用动。这种批量化的稳定能力，是传统可视化编辑器很难给你的。

5.2 未来可以再做些什么

我接下来打算把“样式快照”做成一个可渲染的预览页模板。也就是说，把快照里的视觉参数自动变成 CSS 变量，在本地预览时用变量控制，一键切换多套主题。在公众号后台继续用展开后的实际色值，本地预览用变量减少维护成本。两端各取所需。

另外，我还想沉淀一套自己的“排版异常检测”清单。比如用脚本检查 HTML 是否有未闭合标签、是否出现了负面清单里的标签、是否所有色值都在允许列表中。这些检查可以交给 Kimi 2.5 在输出时顺手完成，也可以本地写一个小工具。检查机制越靠前，出错概率越低。

说实话，做公众号排版这件事本身不复杂，但要做好、做稳、做成可持续的工作流，还是要花不少心思。这套方法目前最让我满意的地方，不是“生成得快”，而是“稳定”。稳定到我可以放心地把它变成日常工具，而不是偶尔尝鲜的玩具。如果你每天也要跟公众号后台死磕，我建议你直接复制提示词跑一遍，把颜色和组件换成自己的，半小时内就能感受到这套方式的差别。