企业官网建设流程全解析

说实话，公众号排版这件事我烦了快三年。不是不会排，而是每次写完整篇内容，还得花二三十分钟去对付官方编辑器里那个弱到让人无语的富文本区：调完字号，颜色又不对；拖完段间距，列表又缩没了；更别提代码块样式，丑得我一度放弃在公众号里放代码。第三方工具用过一阵，好看是好看，但会员不便宜，模板看多了全是同一股味儿。

直到 Kimi 2.5 上线，我顺手试了试“能不能帮我把草稿变成能直接粘进公众号的图文”，结果竟然真的行。于是我用它搭了一个属于我自己的公众号排版编辑器——算不上大工程，连后端都没有，但它是那种我每天早上打开后台前会先走一遍的工具，是真“愿意天天用”的那种。这篇文章把整个搭建过程、踩坑经历、以及真正影响使用体验的那些细节完整记录下来。

1. 为什么我放着现成编辑器不用，偏要自己做一个

1.1 官方编辑器真正让人抓狂的地方

先聊痛点，不然你可能不理解我为什么要折腾。公众号后台的编辑器属于典型的“能用，但不顺手”。它支持最基本的加粗、斜体、字号、颜色，但你要是想让一段重点内容有个像样的视觉层级，就得手动把所有属性点一遍。更难受的是样式不稳定——你在电脑上排好的段间距，手机预览一打开就变小；你辛辛苦苦做的列表缩进，粘贴到别处再回来全乱。

代码块是重灾区。官方编辑器默认的代码样式几乎没有任何修饰，背景、边框、内边距都没有。我见过有朋友直接在正文里贴代码，结果在手机上糊成一团。遇到稍长一点的代码，根本没法阅读，只能靠截图应付过去。

我还有一个非常具体的需求：引用块。写作中经常要放一句受访者的话，或者一段资料原文。官方编辑器给的“引用”样式只有一条灰色竖线和一个缩进，视觉上非常弱，完全没有层级感。我希望引用能有一点背景色、一条有存在感的左边框，甚至可以是某种卡片效果——但这些官方一个都不给你。

这些问题叠加起来，就是每次发文前最痛苦的那段时间：内容明明写完了，却想不出该怎么把它“做得好看点”。排版应该成为内容的放大器，结果在这套工具里变成了体力活。

1.2 第三方工具不是不好，是给我的负担太重了

第三方公众号排版编辑器确实解决了很多问题：模板丰富、样式漂亮、代码块也能做得像样。但用久了，我的体验反而是负担越来越重。

首先是要注册账号，很多功能要开会员。我理解工具需要收入，但我一个月可能只发四到六篇内容，算下来每篇的排版成本并不低。更麻烦的是，第三方工具的模板通常会绑定自己的 CSS 结构，如果我哪天不想用某个样式了，想把整篇内容整体换一种风格，比重新排一遍还累。

其次是复制粘贴的稳定性问题。我遇到过不止一次，明明在第三方工具里看到的效果很完美，复制进公众号编辑器之后，样式却出现了偏移：可能是一行间距被吞了，可能是某个卡片的圆角失效，也可能是标题下面的强调条位置偏移了。这时候我反而要开始排查“到底是我的操作问题还是工具的问题”，排版时间瞬间翻倍。

还有就是审美疲劳。模板再丰富，用久了都会有“模板感”。读者其实很敏感，同一个号连续几次一模一样的排版，他们会觉得“这期是套模板发的”。我不希望自己的内容一眼被识别成“某个模板的购买用户”，但第三方工具的体系决定了你只能在它提供的框架里选，想要个性化的微调成本很高。

所以我越来越意识到：我要的不是一套固定的排版模板，而是一个能“理解我写的内容、并给我生成对应版式”的工具。排版不应该靠模板套，应该靠内容驱动。

1.3 我想要的东西，根本不是“编辑器”，而是“排版生成器”

想清楚之后，我给这个工具画了一条界线：它不是编辑器，而是生成器。

编辑器的逻辑是手动调整每一个元素——你选中一段文字，给字号、给颜色、给缩进。生成器的逻辑是，输入一篇草稿，点击一下，得到一段已经排好版的 HTML，粘进去就能用。中间不需要我参与任何“排”的动作。

这带来的好处很直接：第一，省时间，内容写完直接进排版环节，一个按钮的事；第二，风格统一，每次生成出来的样式都遵循同一套设计规则；第三，不依赖固定模板，生成出来的版式是根据每篇文章的具体内容动态变化的，不会给人“套模板”的感觉。

当然，生成器也有它的前提：它必须能理解排版这件事。如果它只是把固定样式套上去，那本质上还是模板，只不过换了皮。真正的难点在于，它需要判断文章里哪句适合做引用、哪段适合做列表、标题该用什么层级、语气词放在这儿合适不合适。这些判断建立在语义理解之上，不是简单字符串替换能搞定的。这也是我为什么选 Kimi 2.5 来当引擎，而不是自己写一套规则的正则表达式。

2. 用 Kimi 2.5 当排版引擎，我提前做了三轮验证

2.1 第一轮验证：它到底懂不懂“排版”

工具选型之前，我先在 Kimi 2.5 的对话里做了一些很基础的测试。我直接丢了一段写了一半的文章进去，要求它：

请帮我判断这段内容里，哪些句子适合作为独立引用块，哪些内容应该用列表来呈现，同时把二级标题标出来。

它给我的结果让我意外——它不是简单地挑句子，而是会解释为什么某句话适合做引用，说“这句话是全文转折点，信息密度高，适合用强调卡片承载”。而列表的筛选也符合行文逻辑，比如把三个并列的方法点并列成列表，而不是随便拆段落。

这说明它理解排版不只是“样子好看”，更关注内容的结构关系。排版本质上是视觉信息层级的呈现，一个工具能不能判断出哪句话重要、哪句话次要，直接决定了它排出来的东西是否“可用”。当时我特意试了一篇比较碎的草稿，里面既有正式表述也有口语化吐槽。它分得很清楚，正式表述被规整成段落，口语吐槽被处理成了带引号的幽默标注，没有出现“把吐槽当正文加粗”这种低级错误。

第一轮结论：语义理解能力足够支撑排版判断。

2.2 第二轮验证：输出稳定性能不能达到“天天用”标准

语义理解过关只解决了一半问题。对高频使用的工具来说，稳定比惊喜重要得多。

我做了另一组测试：拿十篇风格完全不同的历史文章，分别要求 Kimi 2.5 输出统一的排版 HTML。观察这十次输出的差异和错误率。这轮测试我主要盯三件事：

第一，标签是否闭合。有些模型在生成复杂 HTML 时会出现嵌套错误，段落里有未闭合的<strong>，这种输出贴进编辑器就是灾难。实际测下来开头几版确实出现过一次<section>标签没闭合的情况，但后面我加了输出格式约束之后，基本就稳定住了。

第二，内联样式是否一致。公众号后台对class样式支持很差，所以我要求所有样式都写进style属性里。但有些模型会“偷懒”，给出形如class="highlight"的代码。我必须让 Kimi 2.5 始终输出内联样式才行。前期测试偶尔会出现类名残留，后来我在提示词里做了强制约束，这条才逐步稳定。

第三，风格参数能否按指令变化。我给了几个可调节的维度，比如是否需要衬线标题、正文用什么灰度、引用块的边框颜色。它基本能按要求区分出不同的视觉风格，不会所有文章都生成一模一样的版式。

十次测试里，有七次是一次通过，剩下三次只要我指出具体问题，重新生成也很快。对一个个人效率工具来说，这个稳定性已经足够支撑“天天用”了。

2.3 第三轮验证：API 接入的延时与成本控制

既然要天天用，走网页对话就显得很别扭。我得手动复制粘贴、手动点生成、手动复制结果，这跟直接用第三方编辑器没什么本质区别。所以我决定通过 API 来调用，做一个轻量本地工具。

API 调用我最关心的是两个数字：延时和成本。延时方面，一段一千五百字左右的文章，从提交到拿到完整结果，实测大概在几秒到十几秒这个范围。这个速度对“每天排一篇文章”的场景完全能接受，甚至可以说比我手动排版还快得多。我试过更极端的情况，比如一次性贴入三千字长文，耗时会更长一些，但也没到让人失去耐心的程度。

成本就更可以忽略了。虽然 API 会按 token 计费，但排版任务本质上不复杂——输入是一篇文章，输出也只是一段 HTML。字数规模决定费用非常低，何况个人号一天最多排一两篇。相比之下，那些一个月几十块钱的会员费反而比我实际产生的 API 调用费用贵得多。

这轮验证通过之后，我就确定了项目形态：本地跑一个极简的网页工具，核心逻辑是拼 Prompt、调 API、把返回结果展示成一个可复制的代码块，仅此而已。你不需要什么后端服务器，也不需要数据库，更不需要复杂的权限系统——真正难的编排都在提示词里。

3. 这个排版编辑器是怎么搭起来的：本地网页 + 强提示词

3.1 整体结构只有三层，不要把它想复杂

工具的逻辑很直白，三条链路：

1. 用户把草稿粘贴进输入框。
2. 用户选择想要的文章基调（正式、轻松、干货型等等），点击生成。
3. 工具把草稿、基调选项和一段预设的系统提示词汇编成请求，发给 Kimi 2.5 的接口，然后把返回的 HTML 显示在预览区，复制后贴进公众号后台。

我在设计时特意让它没有数据库、没有用户系统、没有历史记录。因为是自用的工具，只要打开 HTML 文件就能用，数据提交完即走，不留任何隐私负担。这也是我“愿意天天用”的原因之一：没有学习成本，没有账号登录，也没有营销弹窗。

这里我想多说一句架构选择。有人会问，直接打开网页端对话，把提示词复制进去，再加一段草稿，不也能达到同样效果吗？为什么要费劲做一层前端。确实能，但体验差很远。网页端对话需要每次手动复制粘贴一长段提示词；提示词一旦超过视觉长度就很难维护，而且会话一旦被刷新，提示词就丢了。而封装成一键生成后，我的操作只有“粘贴文本、选风格、点按钮”三步。工具一旦达不到这个流畅度，我就不会想天天用它。

3.2 内置风格标签：我给自己定义了 8 套基础版式

样式是这个编辑器最重要的视觉产出。我不希望每次生成都一样，所以我在提示词里定义了几个风格标签，让 Kimi 2.5 按标签来调整具体样式。

别小看这些标签，其实它们就是写死在提示词里的示例表。Kimi 2.5 拿到文章后，会根据文章内容自动判断应该使用哪一种，并把对应标签的样式应用到 HTML 里。我不需要每次手动指定，只有当它判断明显不对时，我才会强制覆盖成某一个标签。

有人可能会觉得这样还是“模板化”。但从实际使用效果看，同一标签下不同文章处理时，AI 会调整引用内容、句子层级和卡片位置，所以视觉上并非同质化。模板是死的，而语义判断是活的。

3.3 前端输入框设计：简单到不可能用错

既然是自己每天都要开的工具，我坚决不做复杂界面。主界面只有一个大文本框、一个风格下拉框、一个生成按钮、一个预览区。这个设计遵循一条原则：工具的流畅程度，决定了我是否会持续使用。

不过我也加了几个防呆措施，都是磨出来的教训。

第一个是文本长度限制。我在提交前会做一次字数估算，超过一定阈值就会提示先拆分成两段处理。因为太长的一次性提交，既容易超出模型上下文限制，也容易在生成过程中出现中断或漏段。手动拆一下虽然多一步操作，但比生成一个残缺结果再修补省心得多。

第二个是空内容保护。这个看起来很蠢，但其实很有必要。我遇到过几次点击生成后才发现，输入框里的内容不小心被清空了，于是模型开始顺着提示词“自由发挥”，生成一份样本文章。所以我现在在提交前会做一次校验，没内容就直接弹窗打断，不继续。

第三个是复制便利性。返回结果不要放在一个看起来像代码展示的页面上，而应该直接有一个“一键复制”按钮。因为最终用户是要把这段 HTML 粘进公众号后台的，中间只要多一次手动全选复制，就可能把标签搞漏。

这些设计听起来没有任何技术含量，但它们是“天天用”和“偶尔用”的分界线。排版工具最忌讳复杂，一复杂我就想逃避。

4. 提示词工程才是真正的核心，我在这里翻过几个大车

4.1 第一版提示词的翻车现场

我最开始把提示词写得特别简单，只有一句话：

请把这段文字排版成适合公众号的 HTML。

结果很灾难。它确实给了 HTML，但至少有四个问题：

第一，它没有使用内联样式，而是给了普通 CSS 和 class 选择器。这样的代码贴进公众号后台，样式会全部丢失，只剩纯文本。第二，它把原文的标题层级重新打乱，甚至自己加了一些内容，比如在标题前面增加“以下是排版后的内容”这种废话。第三，它生成了一个完整的 HTML 文档，包括<html>、<head>、<body>，这些对公众号后台完全没有用，粘贴进去反而会变成乱码区域。第四，它没有理解重点内容，经常把正常的行文也标成了加粗，整个页面看起来像全部被高亮。

这版教训让我明白，直接对模型说“帮我排版”是不够的。排版这个任务在人类语境里可能有共识，但在模型语境里，它既不理解公众号的限制，也不了解“排版应该突出什么”。必须在提示词里把所有规则讲清楚，一个细节都不能省。

4.2 我最终使用的“四段式”提示词结构

经历了几次翻车，我把提示词重构为四层结构：角色设定、任务定义、输出规范、禁止事项。每一层各管一块，互相不干扰。

第一层，角色设定：

你是一位深谙微信公众号排版规律的前端工程师，熟悉富文本编辑器对 HTML 的兼容性要求，能用最小的代码量实现最稳的视觉效果。

给角色定位不是为了让模型“演戏”，而是为了触发它在这一领域的知识。经过对比，有角色设定的输出比没有角色设定时，在标签选择和样式写法上明显更收敛、更专业。

第二层，任务定义：

请把用户输入的草稿转换成一个公众号可用的 HTML 片段。要求保留原文所有文字信息，不得增删内容，不得自己续写，不得修改原文语义。

“保留原文所有文字信息”这一条看起来多余，实际上非常关键。模型天然有“改写倾向”，你越不约束它，它越容易把原文“润色”一遍。对于直接把草稿转成版式的场景，我根本不需要它帮我改句子，只要帮我穿衣服。所以我必须明确“不得增删”。

第三层，输出规范：

输出必须是一个以

开头的 HTML 片段。所有样式必须写在 style 属性中，禁止使用