夜雨聆风【为了让小龙虾写出漂亮格式的Word文档，我自己写了一个Skill】
越来越多的人开始把 AI 真正带进工作流里。无论是在Claude Code、Codex、OpenClaw，还是 WorkBuddy 这类平台上，大家都已经不满足于“问答”本身了，而是希望 AI 能够真正接手一部分生产工作：帮忙写方案、整理报告、生成汇报材料、拼接项目文档，甚至直接产出可以交付的正式文件。
我们用 AI 换来了思考的自由，却在 Word 的格式漂移里重新戴上了镣铐
但只要你真的用过几次，就会很快发现一个很现实的问题：前面让 AI 写内容的时候感觉很顺，思路清楚，效率很高，甚至章节结构也搭得不错。可一旦准备把这些东西真正整理成一份正式 Word 文档，问题就接连出现了。表格在转换过程中开始变形，图片插进去之后前后位置不稳定，标题层级看起来像是统一了，实际却一会儿大一会儿小，正文段落的行距、缩进、段前段后都不太对。更麻烦的是，有时候你只是改了几段文字，整份文档的版式就跟着漂移，最后本来应该是“收尾”的工作，反而变成了一场漫长的格式补救。真正的业务交付，尤其是方案、报告、汇报材料、制度文件、说明文档这一类东西，最后不是停留在聊天窗口里，而是要变成一份能发出去、能打印、能归档、能让别人继续修改的 Word 文件。也正是到了这个时候，很多人会意识到：AI 最大的短板，不是不会写，而是输出不够稳定。
所以，我做这个skill，最直接的动机，其实就来自这里。我并不是想再做一个“帮你写文章”的 skill，因为这件事已经有很多工具在做了，而且它们做得也并不差。我更关心的是另一个一直被低估、但在真实工作里极其重要的问题：当一份文档已经不是草稿，而是要进入正式交付状态的时候，我们能不能给它一套更稳定、更原生、更可控的处理方式？换句话说，我想解决的不是“写一段话”，而是“把正式 Word 文档这件事做稳”。
formal-docx-workflow想做的，就是把这件事从“看运气”变成“有流程”。从业务使用的角度看，这个 skill 非常适合几类典型场景。第一类，是那些经常做正式汇报材料的人。无论是项目复盘、工作总结、年度报告，还是阶段性汇报，这类文档的共同特点都是内容结构相对清晰，但对正式感和排版稳定性要求很高。第二类，是经常写方案、建议书和说明文件的人。这类文档经常需要多人协作、反复修改，内容来源也比较杂，最后很容易在拼装环节出现格式失控的问题。第三类，则是那些已经有一份 Word，只想做精修、不想推倒重来的人。现实中这种需求非常多：封面已经做了，目录也差不多，正文也能用，只是表格不顺、标题不统一、图片位置不理想。这种时候，最忌讳的就是用一种激进方式把整份文档重做，而更合理的方式，是在尊重现有结构和样式的前提下做“有边界的修正”。
真正的生产力，不只是创作时的天马行空，更是交付时的四平八稳。
完整说明、使用示例和项目代码都已经放到 GitHub 上了，地址是：https://github.com/zhongtw1979/codex-formal-docx-workflow
