大约半年前我遇到一个特别典型的场景让 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.mdSKILL.md是主描述文件负责告诉 Agent 这个技能什么时候用、规则是什么、输出格式是什么。reference目录放更详细的规范和参考样例用来补充主文件里不适合写太长的内容。examples目录用来放正反样例这是非常有效的约束手段。checklist.md则是一份输出前校验清单。这个结构不是唯一答案但它是让排版规则可维护的基础。2.2 排版类 Skill 的四个组成模块如果你要写一个排版 Skill我建议至少包含四个部分。第一个是“触发说明”。明确告诉 Agent当前任务属于什么类型时应该使用这个 Skill。比如“当用户要求生成或重排技术文档、博客正文、方案说明时”。这个部分很重要它决定了 Skill 会不会在错误场景被误用。第二个是“核心规则”。不是放一堆形容词而是放可直接执行的句式。比如“一级标题使用#且标题与前后段落之间保留一个空行”“代码块必须标注语言”“列表最多嵌套三层”。这些规则必须是可执行动作而不是模糊期望。第三个是“参考样例”。包括好的输出和坏的输出。很多模型对规则的遵循能力并不差但对抽象描述的解析效果不稳定。给一个“坏样例”和“好样例”对比比写十句规则更有用。第四个是“输出前校验清单”。这一步不能省。让 Agent 在输出完内容之后逐项检查标题是否跳级代码块是否有语言标识列表缩进是否统一段落是否过长检查结果最好直接写进输出末尾这样你能快速判断规则到底有没有被遵循。2.3 Skill 与提示词、模板、脚本的区别这里需要稍微厘清概念因为很多人把 Skill、提示词、模板、脚本混在一起。提示词是一次性的口语指令优点是灵活缺点是漂移和不可复用。模板是静态骨架适合固定结构内容但不处理判断。脚本是可编程执行逻辑适合确定性的转换比如批量改文件名、批量替换格式。Skill 更像是介于它们之间的产物它包含了提示词的描述能力也包含了模板的固定约束但增加了可调用、可版本化、可附带检查和参考资源的能力。排版场景里Skill 和脚本还可以配合使用。AI 负责解释规则、生成中间内容脚本负责执行确定性的格式转换。例如 Pandoc 负责把 Markdown 转成 WordVBA 宏负责在 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收集 3 个真实失败样例定位高频问题。把问题解释成 3 到 5 条可执行规则。为每一条规则设计对应的输出前校验项。在固定样例集上测试观察成功率和副作用。每出现一个新问题优先把它补充成新规则或新检查项而不是重新设计整套 Skill。这套流程的核心是“先跑通再固化最后校验”。一开始不追求覆盖所有场景而是先保证一类场景的输出稳定。之后每遇到一个翻车案例再把它沉淀进 Skill。时间长了这个 Skill 会越来越像一个真正的“排版负责人”。4. 不同场景下的排版 Skill 设计差异4.1 写代码与前端输出重点是结构与注释如果你使用 AI 编程工具比较多一定会遇到这类问题让 AI 生成一个组件代码能跑但文件命名随意、目录结构混乱、注释风格不统一。尤其在前端项目里组件组织、样式 token 命名、API 调用位置都需要与团队现有约定保持一致。这时候的排版 Skill 关注点不是“代码缩进几个空格”这么简单而是要覆盖文件与目录的组织方式。导入语句的排序规则。组件命名和变量命名规则。注释应该在什么位置出现以什么格式出现。样式写法是 Tailwind 还是 CSS Modules甚至是组件库的主题 token。这些规则如果能固化成 SkillAI 编程输出会稳定非常多。否则每次让 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 输出的测试用例字段足够规范平台就能直接解析、导入、执行。排版在这里不是“好看”而是“能不能被机器读取”。不同场景的差异可以简单对照输出场景核心难点Skill 的典型输入Skill 的典型输出代码与前端结构与注释统一需求描述、既有目录结构带固定注释风格的代码骨架博客与技术文档层级与可扫读性原始草稿、主题要点已排版 Markdown 文档Word/论文/双栏中间格式兼容源文档、论文模板要求Pandoc 可识别文件、样式清单测试用例/结构化数据字段完整、格式一致功能需求、已有字段结构化表格、JSON/CSV 样例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 是否被正确加载查看日志检查目录名、文件名、frontmatter 格式输入层输入样例是否干净清理全角空格、旧格式占位符、多余空行规则层规则之间是否冲突逐条检查规则为冲突场景写明优先级环境层工具版本与路径确认版本支持能力升级或降级重启会话渲染层目标平台显示效果在 GitHub、博客平台、Word 中分别确认如果 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 效率的本质。