夜雨聆风
前两天在GitHub上翻到一个项目，看完仓库简介就决定要装。
不是有多复杂——恰恰相反，是因为太简单了。
作者刘飔齐发了一篇文章，讲他怎么用两小时把三千年中国公文写作史浓缩进一个开源Skill。我是公文岗位出身，看到"三千年"三个字就知道这人不是在吹。两小时做出来的东西能跑——这才是让我真正感兴趣的地方。
于是我花了周末一个下午，把这个Skill装进了自己的AI工作流，顺手把原来的旧版换掉了。
这篇文章不说他怎么做的，说说我做了什么、换了之后什么感受。
一、背景：公文Skill这件事，为啥难做
公文写作的Skill，我之前试过好几个。
GitHub上有，但一只手数得过来。质量嘛——说客气点叫"能用"，说不客气点就是格式挑不出毛病，但写出来的东西没有公文那股劲。
公文那股劲是什么？
是权力关系的文本映射。一份通知发出去，涉及二十个单位的执行动作，文字稍微有一点歧义，执行层面就会出现理解偏差。所以公文的语言不是文学创作，不是输出情绪，是精确到每个字都能被无歧义执行。
AI写不好公文，问题往往不在Prompt，而在于AI脑子里没有完整的中国公文体系。临时搜一点格式要求，喂进去的东西是碎片，拼出来自然也就四不像。
所以当我看到wenshu的仓库时，第一反应是看看它的底层知识够不够厚。
二、安装：十五分钟，从下载到出第一份文件
我的安装环境是Hermes Agent（OpenClaw也装了，但主力是这个）。wenshu支持四平台通用——Claude Code、Codex、OpenClaw、OpenCode，都用同一套SKILL.md标准。这个我在之前文章里提过，这次算是第一次亲测。
安装过程没有坑。克隆仓库，复制到skills目录，加载skill，发测试请求——四步，十五分钟。
git clone https://github.com/Aether-liusiqi/wenshu.git # 复制到 ~/.hermes/skills/government/wenshu/我原来装过一个旧版公文Skill，是从另一个开源项目里找的，19KB单文件，功能勉强够用。wenshu装完之后，我对照着看了一遍结构——
旧版：一个SKILL.md，19KB，混合了知识条目和操作流程
新版：SKILL.md（7KB）+ 8个references + 3个core模块 + 16份文书范例，结构清晰，层层递进
差别在哪里？旧版像一本缩印的教科书，什么都有，什么都挤在一起。新版像一套工具箱，需要什么拿什么，拿出来的都是完整的。
三、实测：让AI写一份会议通知
安装完了得测。我给了自己一个真实任务：写一份关于召开第三季度工作推进会的通知。
这是我们单位的常规动作，每年七月份要做上半年总结+三季度部署。我把需求发了出去，没有给额外格式说明，只说"请写一份通知"。
结果生成的文书结构：
发文机关：成都市发展和改革委员会
发文字号：成发改〔2026〕28号
生成的正文要素：会议时间精确到上午9时至12时（半天）；会议地点写了楼层和房间号；参会人员按职务层级逐级列明；五项议程有时间节点；要求部分有截止日期和提交方式；联系人信息完整。
格式方面，"时"而非"点"，成文日期用阿拉伯数字，参会人员写职务不写姓名——这些都是公文格式的基本要求，AI一次做对了。
之前旧版Skill经常出错的地方：把"分管规划的副局长"写成"负责规划相关工作的同志"，前者精确到岗位，后者模糊到无法执行。wenshu没有犯这个错误。
四、为什么我留下了wenshu，而不是继续用旧版
换掉旧版的原因有三个：
第一，知识深度不在一个量级。
旧版覆盖15种法定公文，但每种只给了格式要点。wenshu的references里，每种文种有"五对混淆辨析"——通知和通告有什么区别，请示和报告能不能合并，函的哪些用法是错的。这些内容不会出现在AI生成的最终文书里，但会直接影响AI对文种的选择判断。
第二，SKILL.md的体量控制合理。
wenshu的SKILL.md正文7KB，加上所有references总共不到200KB。初版作者写了13KB，被社区反馈"偏胖"，才拆成了现在的三层结构。这件事说明什么？Skill设计里的克制和专业，跟公文写作本身的要求是一样的——该放哪放哪，不该放的不放。
第三，英文名用拼音，省去了每次解释成本。
作者选了wenshu作为仓库名和安装命令，没用official-document-writer。我试着敲了一下：skill install wenshu，比skill install official-document-writer少敲十五个字符。两个月能省出两小时，攒起来做别的事不好吗。
五、一件事让我重新理解了Skill设计
安装wenshu的过程中，有一步让我停下来想了很久。
作者在设计SKILL.md时，提到了"渐进式披露"（Progressive Disclosure）机制：
Level 1只加载name和description（约50 tokens），用来判断什么时候触发这个Skill；Level 2加载SKILL.md正文（约3000-5000字），包含角色定义和核心工作流；Level 3按需加载references和examples，需要什么知识调什么知识。
这个设计不是wenshu独创的，是主流AI Agent平台的事实标准。但我在安装旧版Skill时从来没有注意过这一点——因为旧版根本没有分层的概念，所有东西都塞在一起，用的时候全量加载，上下文窗口被吃掉一截。
把三万字的研究报告拆成四十个文件，也是同一个思路的延伸。
初稿写完，作者对着三万字不知道怎么删——每一段看起来都有道理。最后是按"跟当前使用场景有没有关系"这条线来切的：有关联的保留，无关的直接删，哪怕内容本身再精彩。
这个判断标准听起来简单，但我在写技术文章的时候经常做不到。写了一段自认为很深刻的分析，回头看跟主题没什么关系，删了又觉得可惜，最后还是留下了。
wenshu的设计者没有这个包袱。他定了一条规则：跟使用场景无关的内容，再好也不要。
六、关于作者两小时做完这件事
文章发出去之后，有人问：真的只花了两小时？
我不懂编程，但从结果倒推，两小时做出来的东西能跑，说明他的准备工作做在了写代码之前。
他自己提到，在动手之前，先让AI跑了一轮公文写作溯源分析——纵向三千年，横向2012年至今的现行制度体系，产出三万字研究报告。这份报告是他的知识底座，Skill只是把知识底座结构化之后的输出。
换句话说：两小时是生产时间，准备工作另算。
这不是在说"其实做了更久所以不值得学"——恰恰相反，这说明了一件重要的事：AI时代做专业Skill，最大的门槛不是编程能力，而是领域知识的沉淀质量。知识体系完整，Skill才能完整。知识是碎片，出来的Skill再好也是碎片。
七、我的下一步
wenshu我已经用了两周，目前的心得是：AI生成草稿，我来做最后一道审核——主要审政策表述是否跟最新文件对齐，这部分AI暂时做不到实时。
下一步我想试一件事：能不能基于wenshu的结构，把自己日常积累的案例和心得写成一个专属的补充模块，按需调用。
这个需求不是刘飔齐文章里写的，是他文章之外我自己想出来的。
好的工具就是这样——它把标准立在那里，用着用着你就知道自己还有哪些差距，哪些地方可以继续加东西。
八、补充一个我观察到的细节
安装wenshu的时候，我顺手翻了它的GitHub Star曲线。
不是很多，但很稳。从发布第一天到现在，每天稳定涨几十个，没有大起大落。
我跟作者刘飔齐没有任何私人关系，但我猜这个增长曲线说明了一件事：用公文的人，不是在追AI热点，是真的在找一个能用的工具。
不像编程圈，一有新框架出来Star直接爆拉，然后两周后没人再提。公文Skill的用户留存率高，说明需求是真实的，不是蹭热点的。
这也是我愿意写这篇文章的原因之一。
九、和现有工作流的配合
我现在的公文写作流程是这样的：
第一步，AI出草稿（wenshu），耗时约三分钟；
第二步，我做政策对齐审核，耗时看文件新旧程度，一般五到十分钟；
第三步，领导修改，返回二稿。
以前第一步和第二步都是人来做的。现在第一步AI做，第二步人做，第三步不变。
省下来的时间不多，但每天能多处理两到三份文件。对于我们这种日常文件量大、格式套路又相对固定的岗位，这个效率提升是真实的。
不是AI取代人，是人用AI把时间花在真正需要判断力的地方。
十、两个已知局限，说在前面
说好的不说坏的，不是我的风格。
局限一：政策文件无法自动同步。
wenshu的知识底座是三万字溯源报告，但那之后如果有新的政策文件出台，Skill本身不会自动更新。AI生成的文书，在政策表述上需要人工审核。写这篇的时候，我刚做完季度总结，深知这一条的重要性。
局限二：复杂协调文书仍需人工起草。
比如多部门联合发文、涉及法律追责的协议、敏感节点的表态文件——这类文书需要判断文字背后的权力关系和利益博弈，AI暂时做不到。
把这个写出来，不是为了给wenshu差评，是为了说明白AI的边界在哪里。知道边界在哪，比知道能力在哪更重要。
十一、一个小测试题
看完文章，如果你也装了wenshu，给你一个测试题：
让它写一份"关于申请购置办公设备的函"，然后对比一份你手头真实存在过的同类文件。
看看AI在文种选择上有没有出错——很多人在需要用"函"的时候下意识用"请示"，这两个文种的边界在实践中其实经常被混淆。
如果你发现AI写对了，恭喜你，你的AI帮手至少在这一步是靠谱的。
附：wenshu安装信息
仓库：github.com/Aether-liusiqi/wenshu 安装：支持 Claude Code / Codex / OpenClaw / OpenCode 覆盖：15种法定公文 + 7种事务文书 费用：免费，开源
