企业官网建设流程全解析

大约半年前，我遇到一个特别典型的场景：让 AI 写一篇技术方案，内容质量能打 80 分，但复制到文档里之后，标题层级错乱、列表缩进不统一、重点结论淹没在长段落里，整个排版像一杯没摇匀的果汁。后来我用 Agent 类工具的次数越来越多，发现同一类问题在代码输出里也存在：程序能跑，但目录结构、注释风格、导出格式，每次都靠临时对话去“抢救”。所以当我看到 Jason Liu 在社区里征求改进 AI 输出排版的 Skills 推荐时，我特别理解这个需求为什么会被提出来。它看起来只是“让排版更好看”的小问题，实际上却关系到 AI 协作能不能进入稳定、可维护、可团队复用的阶段。

这篇文章想从这个问题切入，聊一聊：为什么 AI 输出的排版这么难控制，Skills 到底能改变什么，以及怎么自己写一个真正可用的排版 Skill。重点不是给一份“最佳配置”，而是把设计方案、边界和排查思路讲清楚。

1. 先搞清楚：AI 排版差，不完全是模型的问题

1.1 排版问题往往有三层来源

很多人遇到 AI 排版不稳定时，第一反应是“这个模型不行”，或者“提示词写得不够细”。但从实际经验看，问题通常不是单点原因，而是至少三层因素叠加。

第一层是生成风格。不同模型对 Markdown、代码缩进、标题层级、列表用法的默认倾向不一样。同一个任务，换一个模型，可能输出风格完全不同。这种差异不是简单通过一句“请规范排版”就能抹平的，模型在 token 选择上会自带偏好。

第二层是提示词的“即兴性”。日常使用中，我们把排版要求写进对话上下文里，每次都在现场组织规则。问题是：上下文一旦变长、话题一旦切换、任务一旦跨多个会话，这些规则很快就会被稀释。最典型的情况是开头记得“要加空行”，写到最后一段却忘了；这未必是模型偷懒，而是提示词里的规则优先级在长上下文里已经变得非常模糊。

第三层是下游渲染环境的多样性。同一个 Markdown 文件，在 GitHub、博客园、Word、Pandoc、企业文档平台里渲染出来的效果完全不一样。AI 输出的往往是“通用格式”，并不一定适配你的最终落地场景。比如写论文，你可能需要的是双栏 Word 模板；写博客，你需要的是带目录和代码块标注的 Markdown；写测试用例，你可能需要的是结构化表格。没有约束的统一排版，很容易变成“在哪个平台都不太对”。

1.2 为什么“在提示词里多叮嘱几句”治标不治本

Jason Liu 的 Skills 征集之所以能引起讨论，核心原因就在这里：很多人已经发现，靠对话里的临时叮嘱来治理排版，已经走进了死胡同。

临时叮嘱有三个很现实的问题。第一，不可复用。昨天调的规则，今天开新会话就丢了；这个项目里积累的排版经验，换一个项目又要重新讲一遍。第二，不可回归。你为了修标题层级问题，加了一条规则，结果列表缩进又变了；为了修代码块语言标注，结果段落间距又乱了。每次调整都可能牵动未知的上下文，改一个问题，带出新问题。第三，不可校验。就算你在提示词里写了一大段排版要求，输出后也没有人真的去逐条检查；等到复制进文档才发现问题，再回头重写，效率反而更低。

这些问题的本质，是排版规则一直停留在“口头层面”。它被放在对话里、放在临时文件里、放在某位同事的经验里，却没有变成一个可以被稳定加载、执行和验证的工程产物。

1.3 从“排版差”到“规则漂移”，真正缺的是工程化机制

如果你长期使用 AI 写文档或写代码，大概率会观察到一种现象：同样一个任务，上个星期输出还不错，这个星期突然排版变乱了。这不是玄学，更像是一种“规则漂移”。

对话里有太多无关信息会占用注意力，排版的规则写得太靠后，模型可能已经“看不见”了。时间越长的会话，这种漂移越明显。更麻烦的是，你很难定位漂移发生在哪一步：是提示词被其他内容覆盖了，还是模型版本更新导致风格变化，还是这次输入里携带了不一样的格式示例？

所以，把排版要求写进一段完整、独立、可随时调用的 Skill 文件里，不是在追求“程序员式的洁癖”，而是在解决一个真实问题：让排版规则不再依赖对话记忆，而是成为 Agent 工作流里的一组固定资源。这也正是 Skills 这个机制最值得关注的地方。

2. Skills 作用不在“让 AI 更听话”，而在“让 AI 有标准”

2.1 Skill 到底是什么：一个小型可复用工作流

如果你想在 Claude Code、Codex 或类似的 Agent 工具里使用 Skills，本质上是在做一个配置化的模块：把领域知识、操作步骤、输出约束、参考资源打包在一起，让 AI 在遇到对应任务时能够自动加载并遵循。

排版类 Skill 是一个特别适合入门的类别。它的目标很清晰，输入是一个待排版或待生成的文档/代码片段，输出是一份符合固定规范的内容。相比其他复杂的 Agent 技能，排版 Skill 的失败模式更容易观察：如果输出格式没达标，一眼就能看出来。

一个排版 Skill 的目录结构，常见的写法大致是这样的：

skills/ doc-formatter/ SKILL.md reference/ heading-rules.md list-rules.md examples/ bad-sample.md good-sample.md checklist.md

SKILL.md是主描述文件，负责告诉 Agent 这个技能什么时候用、规则是什么、输出格式是什么。reference目录放更详细的规范和参考样例，用来补充主文件里不适合写太长的内容。examples目录用来放正反样例，这是非常有效的约束手段。checklist.md则是一份输出前校验清单。这个结构不是唯一答案，但它是让排版规则可维护的基础。

2.2 排版类 Skill 的四个组成模块

如果你要写一个排版 Skill，我建议至少包含四个部分。

第一个是“触发说明”。明确告诉 Agent：当前任务属于什么类型时，应该使用这个 Skill。比如“当用户要求生成或重排技术文档、博客正文、方案说明时”。这个部分很重要，它决定了 Skill 会不会在错误场景被误用。

第二个是“核心规则”。不是放一堆形容词，而是放可直接执行的句式。比如“一级标题使用#，且标题与前后段落之间保留一个空行”“代码块必须标注语言”“列表最多嵌套三层”。这些规则必须是可执行动作，而不是模糊期望。

第三个是“参考样例”。包括好的输出和坏的输出。很多模型对规则的遵循能力并不差，但对抽象描述的解析效果不稳定。给一个“坏样例”和“好样例”对比，比写十句规则更有用。

第四个是“输出前校验清单”。这一步不能省。让 Agent 在输出完内容之后，逐项检查：标题是否跳级？代码块是否有语言标识？列表缩进是否统一？段落是否过长？检查结果最好直接写进输出末尾，这样你能快速判断规则到底有没有被遵循。

2.3 Skill 与提示词、模板、脚本的区别

这里需要稍微厘清概念，因为很多人把 Skill、提示词、模板、脚本混在一起。

提示词是一次性的口语指令，优点是灵活，缺点是漂移和不可复用。模板是静态骨架，适合固定结构内容，但不处理判断。脚本是可编程执行逻辑，适合确定性的转换，比如批量改文件名、批量替换格式。Skill 更像是介于它们之间的产物：它包含了提示词的描述能力，也包含了模板的固定约束，但增加了可调用、可版本化、可附带检查和参考资源的能力。

排版场景里，Skill 和脚本还可以配合使用。AI 负责解释规则、生成中间内容，脚本负责执行确定性的格式转换。例如 Pandoc 负责把 Markdown 转成 Word，VBA 宏负责在 Word 里把表格和样式调整到论文模板要求。这时候 Skill 的价值，就是让 AI 生成的内容从一开始就符合转换工具的要求，而不是生成了再反复“打补丁”。

不要一上来就写一个“万能排版 Skill”。Skill 最怕的不是不够聪明，而是规则太多、互相打架、无法验证。

3. 从 0 到 1 写一个排版 Skill：先跑通、再固化、最后校验

3.1 第一步：收集 3 个失败样例，而不是先列规则

很多人写 Skill 会犯一个方向性错误：一上来就在想“我要把排版规则列得丰富一些”，然后写出一大堆理想化规范，最后 Agent 根本记不住。

我更建议先做一次复盘：把你过去一两个月里觉得排版不达标的 AI 输出找出来，挑 3 个最典型的失败样例。然后问自己三个问题：这些输出到底哪里不对？如果要用一句话修正，该怎么表达？修正之后，会不会破坏其他已经正常的部分？

这 3 个失败样例就是你的需求来源。它们会告诉你，真正需要约束的是标题层级、代码块标注，还是列表缩进和段落长度。基于失败样例设计规则，比基于想象设计规则要可靠得多。

3.2 第二步：把排版规范从“形容词”改写成“动作”

Skill 文件里最常见的低质量写法是“标题要清晰”“段落要简洁”“结构要合理”。这些不是规则，是评价标准。模型面对这种描述时，只能凭感觉执行，结果还是不稳定。

可执行的规则应该像操作手册。比如：

• 错误写法：标题层级要清晰。
• 可执行写法：文档中的标题必须从#开始逐级递增，不允许出现##后面直接接####的跳级情况。
• 错误写法：代码块要规范。
• 可执行写法：代码块必须使用带语言标识的围栏格式，例如```python，不能使用缩进式代码块。

这看起来只是表述差异，实际执行效果差别很大。模型对“动作”类指令的遵循能力，远高于对“态度”类指令的遵循能力。

一个简化版的SKILL.md可以长这样：

--- name: doc-formatter description: 用于规范 Markdown 技术文档的排版输出，适合博客、方案、README 类内容。 --- ## 适用输入 需要生成或重排的技术文档、博客正文、方案说明。 ## 输出要求 1. 标题层级必须连续，一级标题使用 `#`，标题与前后段落之间保留一个空行。 2. 正文段落不超过 5 行，超过时拆分为多个短段。 3. 强调内容使用 **加粗**，不使用下划线。 4. 代码块必须标注语言，文件名单独使用代码格式。 5. 列表不超过 3 层，第三层使用带缩进的有序列表。 ## 输出前校验 - [ ] 是否存在跳级标题？ - [ ] 是否每个代码块都有语言标识？ - [ ] 是否所有列表具有统一缩进？ - [ ] 是否将可执行动作与解释性文字分开？

这个示例的目的不是让你照抄，而是展示“动作化规则”和“输出前校验”的组合方式。实际规则要结合你自己的场景来定。

3.3 第三步：加入输出前校验清单

我之前写过很多次提示词，有一个体会：如果你不要求 AI 在输出的最后“自检”，它往往会在完成主体内容后直接收尾，哪怕中间已经出现格式问题。而当你明确要求它在输出末尾附上校验结果时，规则的遵循率会明显提升。

所以在排版 Skill 里，务必加上checklist.md这一层。它不复杂，就是几条待办检查：

• 标题层级是否连续。
• 每个代码块是否有语言标识。
• 列表缩进是否统一。
• 段落长度是否超标。
• 重点结论是否被加粗或专门标识。

关键不是检查项多，而是每一条都要能被当场验证。如果某一条检查项连你自己都说不清怎么算通过，那就别放进去，否则 Agent 也会糊弄过去。

3.4 第四步：加一个“不建议继续”的兜底策略

排版 Skill 不可能每次都成功。有时候输出内容太复杂，规则会互相冲突；有时候是上游输入本身有问题，Skill 无论如何也救不回来。

这种情况下，设计一个“兜底策略”很有必要。例如在规则里写明：如果核心规则存在冲突，优先保证标题层级正确；如果输入文档携带了额外的表格或图片对象，停止通用排版规则，提示用户使用专门的表格式 Skill 或脚本工具处理。这样可以避免 AI 在不确定的场景里硬凑输出，反而把格式改得更乱。

另一个常见兜底是重试策略。例如要求“如果输出前校验有超过两项未通过，请重新生成一版”。但要注意设置上限，比如最多重试一次或两次，避免无限循环。排版是锦上添花，不是把内容返工成另一套东西。

3.5 给一个可复用的开发流程框架

把上面四步收拢一下，可以沉淀成一套小型方法论。它不只适用于排版类 Skill，也适用于大多数规则型 Skill：

1. 收集 3 个真实失败样例，定位高频问题。
2. 把问题解释成 3 到 5 条可执行规则。
3. 为每一条规则设计对应的输出前校验项。
4. 在固定样例集上测试，观察成功率和副作用。
5. 每出现一个新问题，优先把它补充成新规则或新检查项，而不是重新设计整套 Skill。

这套流程的核心是“先跑通，再固化，最后校验”。一开始不追求覆盖所有场景，而是先保证一类场景的输出稳定。之后每遇到一个翻车案例，再把它沉淀进 Skill。时间长了，这个 Skill 会越来越像一个真正的“排版负责人”。

4. 不同场景下的排版 Skill 设计差异

4.1 写代码与前端输出：重点是结构与注释

如果你使用 AI 编程工具比较多，一定会遇到这类问题：让 AI 生成一个组件，代码能跑，但文件命名随意、目录结构混乱、注释风格不统一。尤其在前端项目里，组件组织、样式 token 命名、API 调用位置，都需要与团队现有约定保持一致。

这时候的排版 Skill 关注点，不是“代码缩进几个空格”这么简单，而是要覆盖：

• 文件与目录的组织方式。
• 导入语句的排序规则。
• 组件命名和变量命名规则。
• 注释应该在什么位置出现，以什么格式出现。
• 样式写法是 Tailwind 还是 CSS Modules，甚至是组件库的主题 token。

这些规则如果能固化成 Skill，AI 编程输出会稳定非常多。否则，每次让 AI 改功能，它都可能重新生成一套风格不完全一致的文件，代码评审时很容易被“这不像老代码风格”卡住。

4.2 写博客与技术文档：重点是层级与可扫读性

博客和技术文档是另一个高频场景。很多工具都能生成文章，但生成结果很像“连续的长方块文字”：标题能看出层级，但段落过长、列表很少、重点不突出，读者只能硬着头皮线性阅读。

面向这类场景的排版 Skill，核心目标是“可扫读性”。也就是说，读者扫一眼标题和列表，就能抓到文章结构。可以设计的规则包括：

• 每个一级标题下，至少有一个二级标题来支撑，避免单点孤悬。
• 段落最多 6 行，超过就拆分。
• 涉及 3 个以上并列对象时，转成列表。
• 重点名词第一次出现时可以加粗，但全文加粗总量不宜过多。
• 代码块必须标注语言。

这里最需要注意的是“规则密度”。一篇博客如果同时叠十几条排版规则，AI 很容易顾此失彼。建议先只保留对可读性影响最大的 5 到 6 条，其余留给后续迭代。

4.3 Word、论文与双栏排版：重点是中国用户最常见的“最后一公里”

从热词里“论文双栏排版”“微信图片下载与 word 排版工具”“文转表 vba 宏排版工具”能看出，很多人真正需要的不是一份漂亮的 Markdown，而是能交到 Word 里的实际文稿。这算是国内用户非常常见的“最后一公里”问题。

这里要澄清一个边界：AI 不能直接稳定操作 Word。排版 Skill 能做到的，是生成一个适合转换工具使用的中间文件，再配合 Pandoc、VBA 宏、样式模板等完成最终 Word 输出。

所以面向 Word/论文场景的排版 Skill，重点其实是“给转换工具喂干净的数据”：

• 标题样式必须使用文档层级，而不是简单加粗。
• 图表要有编号，并对应正文引用。
• 参考文献要使用统一字段格式。
• 双栏场景下，表格宽度和图片位置要有专门约定。
• 表格内容建议先输出为 Markdown 表格或 CSV，再由脚本转成 Word 表格。

这类 Skill 的复杂度会明显高于博客排版，因为它既要考虑内容结构，又要考虑下游工具的兼容性。更稳妥的落地方式是把 AI 生成和脚本转换拆开：AI 负责把内容整理成规则清晰的中间文件，脚本负责执行最终转换。

4.4 测试用例与结构化数据输出：重点是字段完整性和一致性

另一个常被忽略的场景是测试用例和结构化数据输出。让 AI 写测试用例，难点不是“用例数量够不够”，而是字段是否完整、边界条件是否覆盖、步骤描述是否一致，以及表格或 JSON 格式是否规范。

针对这类输出，排版 Skill 的关注点完全不一样：

• 用例编号是否递增且唯一。
• 前置条件、操作步骤、预期结果三个字段是否齐全。
• 每条用例是否覆盖了一个确定的输入。
• 边界条件是否以独立用例出现。
• 输出格式是否保持在表格或结构化数据内，而不是变成大段叙述。

这类 Skill 如果设计得好，后续可以进一步对接自动化测试平台。因为当 AI 输出的测试用例字段足够规范，平台就能直接解析、导入、执行。排版在这里不是“好看”，而是“能不能被机器读取”。

不同场景的差异可以简单对照：

5. 排查链路：Skill 不生效时，先别急着怪模型

5.1 先判断是“没被调用”还是“被覆盖”

很多人写完 Skill 后遇到的第一个问题是：为什么我写了一大堆规则，AI 输出还是原来的样子？

这里先别急着怀疑“模型能力不行”。最常见的解释是：这个 Skill 根本没有被当前会话加载。可能是目录名和配置文件里的 name 不一致，可能是 Skill 文件路径没被识别，也可能是工具版本还不支持这类字段。先确认 Skill 有没有被正确注册，再谈输出效果。

第二种常见情况是“被覆盖”。比如你的主提示词里已经写了一些排版要求，Skill 里又写了另一套，当两套规则冲突时，模型只会选它认为更优先的那条。这种时候不是 Rule 不够好，而是规则之间有冲突。建议保持主提示词简洁，把复杂的排版规则全部交给 Skill 文件去表达。

5.2 再检查输入样例和规则冲突

如果 Skill 已经加载，但效果不稳，下一步要检查输入样例。

有时候问题不在规则，而在于输入文本本身携带了“坏格式”。比如用户粘贴来的文档里有全角空格、空行数量异常、旧版 Word 自动编号占位符，这些都会污染 AI 对结构的判断。排版 Skill 的设计初衷是“按规范重排”，但如果输入已经严重混乱，Skill 可能需要在规则里增加一条“先清洗输入再排版”的步骤。

另外要注意规则内部冲突。最典型的是“段落要简洁”和“内容要详细”同时出现；或者“列表层级不超过三层”和“所有要点都要用列表”同时出现。每加一条规则，都要问一句：它会不会和已有规则矛盾？如果会，就必须写清优先级。

5.3 最后检查工具版本、路径和渲染环境

还有一个容易被忽略的因素是工具版本。Skills 这类机制在不少 Agent 工具里还在快速迭代，不同版本对配置文件字段的支持程度不一样。你用了新的字段，但是工具版本太老，字段被静默忽略，整个 Skill 看起来就像没写一样。排查时可以先确认自己使用的工具版本是否支持 Skills 或 skills 目录，必要时升级或降级到兼容版本。

最后还要检查“最终渲染环境”。一个 Skill 在本地 Markdown 编辑器里看起来没问题，不代表复制到博客平台、Word 或企业文档系统里没问题。每个渲染环境对空行、列表缩进、代码块语言标识的处理方式都有差异。所以不要只看 AI 输出时的观感，一定要把它放进真实使用环境里做最终确认。

5.4 一张排查顺序表

如果 Skill 没有生效，最常见的解释不是“模型没学会”，而是“这个 Skill 根本没被当前会话加载”。

6. 写排版的最终目的：把输出变成可校验的工程产物

6.1 排版 Skill 不只是格式美化

从表面看，改进 AI 输出排版是在解决格式问题；但往深一层看，这是在解决 AI 输出的“可接受标准”问题。

当一段输出有了明确格式规范和校验清单，它就不再是一个“一次性生成的结果”，而是一个可复制、可解析、可进一步处理的中间产物。后续无论是转成 Word、导入测试平台、发布到博客，还是发给团队成员继续修改，都会顺畅很多。

这也是为什么在 AI 编程工作流里，会有人专门研究“前端开发 skills”“测试用例 skills”“结构图 skills”。这些技能的本质都不是“让 AI 更好看”，而是“让 AI 的输出能直接进入现有的工程链路”。排版能力在这里是一个关键的接口层。

6.2 下一步建议

如果你也想把自己的 AI 输出排版打磨得更稳定，可以先从最小闭环开始。

第一步，找出最近一次让你不满意的排版输出，把它保存为失败样例。第二步，只针对这一个问题写一条可执行规则。第三步，让 AI 基于新规则重新输出，并把结果和前版对比。第四步，如果有效，就继续增补；如果无效，就检查规则是否太模糊。第五步，积累到 5 到 8 条规则后，再考虑加入检查清单和参考样例。

不要追求一个 Skill 覆盖所有场景。写代码的 Skill 和写论文的 Skill 应该分开，写博客的 Skill 和写测试用例的 Skill 也应该分开。先让一类场景变得稳定，再逐步扩展。排版 Skill 的价值，从来不是一次写全，而是持续迭代、可沉淀、可复用。

6.3 一个更长远的主判断

这次 Jason Liu 征求改进 AI 输出排版的 Skills 推荐，引发了一大批“排版类 Skills”相关关注，这背后其实藏着一个更值得关注的信号：AI 使用的重心，正在从“如何让模型生成高质量内容”转向“如何让模型输出能够被稳定接入真实工作流”。

排版是其中最显眼、最容易被感知的一环。因为无论内容多好，只要格式不稳定，后续的人工修正成本就会抵消掉 AI 带来的效率提升。反过来，一旦排版规则被 Skill 固化下来，AI 的输出质量就从“灵感型”变成了“工程型”。

所以，如果你真的想提升 AI 的实际产出价值，不妨从写一个小小的排版 Skill 开始。它不宏大，却能让你第一次体会到：原来 AI 的输出也可以被规范、被校验、被长期复用。这个体验，比任何复杂的 Agent 架构都更接近 AI 效率的本质。