企业官网建设流程全解析

领导一眼就看出你的公文是 AI 写的？这个狂更 114 版的开源 Skill，把"笔杆子"拆成了一条流水线

一、周五下午五点的那份通知

周五下午五点，你正准备关电脑。

群里弹出一条消息：“根据上午的会议记录，写个通知，明天下班前要，注意文种别搞错了。”

你熟练地打开对话框，把会议记录粘进去，敲下四个字：“帮我写个通知”。

十秒钟，AI 吐出来一篇东西。结构工整，小标题齐全，还有"综上所述"“下一步，我们将”。

你自己读着挺顺。发给处长。

半小时后，处长回了六个字：

“这是 AI 写的吧？”

……

怎么被看出来的？

其实很简单。真正写过公文的人，一眼就能抓到那几处不对劲的地方：

• 文种错了。该用"请示"的事，写成了"报告"；该"报告"的事，写成了"情况说明"。公文里文种用错，是硬伤中的硬伤，比错别字严重得多。
• 腔调不对。公文是"机关口吻"，AI 写出来的却是"教程腔"——“首先，我们需要明确的是……”“让我们来看看……”。你不是在讲课，你是在发文。
• 事实是编的。AI 最要命的地方，是它会非常自信地给你补上"根据《XX 办法》第三条"“据统计，同比增长 23.5%”。这些数字，一个都不存在。
• 味道太足。那种"既要……又要……"的二元包装句，那种把一句话拆成三个并列短语凑排比的节奏感，读起来像 PPT 转文字。

问题不在模型不够聪明。

问题在于：公文写作这件事，本来就不是"生成一段文字"，而是一条有文种、有要素、有视角、有复核的流水线。你只给了它最后一道工序，却指望它出成品。

最近在 ClawHub 的技能活跃榜上，有一个中文 Skill 连续出现在第一梯队——chinese-official-writing（中文公文写作），作者 gongyu0918-debug，GitHub 上已迭代到 1.6.x 系列，ClawHub 榜单显示其版本更新次数已超过 110 次，被多个技能聚合站点列入"最近更新最活跃"的技能之一。

它做的事，就是把上面那条流水线，一段一段写进了一个 Markdown 文件夹。

二、先说清楚：它不是"公文模板大全"

很多人第一次看到"公文写作 Skill"，会下意识以为它是那种塞了一堆通知模板、报告模板的文档包。

不是。

chinese-official-writing 的骨架非常朴素——一个 Markdown-first 的 Agent Skill。它没有后端服务，没有 API Key，没有复杂的运行时依赖。你下载下来，看到的就是这么几样东西：

作者自己的一句话总结是这么写的：

“这是一个 Markdown-first 的 Agent Skill。核心规则和 references 全部使用中文 Markdown 编写，不懂代码也能直接阅读、审查和修改。”

这句话看着平淡，其实是个很聪明的工程决策。

因为公文写作这件事，最怕的就是"黑箱"。办公室的笔杆子不信"AI 帮我写好了"，他们要的是"我能看见它按什么规则写的、按什么清单核的、哪一条我不认可，我直接改"。

全中文 Markdown，意味着这份规则可以被一个完全不懂代码的文秘人员审阅、修改、本地化。这才是公文场景能落地的前提。

三、渐进式路由：它没有一上来就把整本条例塞给模型

这是我读它的设计时最欣赏的一点。

写公文要遵守《党政机关公文处理工作条例》和 GB/T 9704-2012 的格式规范，内容非常多。普通做法是把这些全部写进系统提示词，然后每次调用都把一大坨规则塞进上下文。

后果是什么？**规则越多，模型越糊。**它读了一堆制度条文，最后写出来的还是一篇"AI 味的散文"。

chinese-official-writing 走的是另一条路：渐进式路由。

它的逻辑是——先看你要干什么，只加载你这次需要的那一页。

举个类比你立刻就能懂：

• 你只是要写一个 150 字的短通知 → 它只读一张"轻量卡"，不进入完整公文流程；
• 你要写一份正式请示 → 它按"文种路由"进入对应的文种叶子页，加载请示的骨架和办理要素；
• 你要写 AI 算力租赁的可研材料 → 它只加载技术类专项规则，按"需求来源 → 资源测算 → 成本边界 → SLA/安全/验收"这套结构走；
• 你只是要改两句话的措辞 → 它走二次局部修改路径，不重跑全文。

官方对这套机制的说法是：

“渐进式路由让短任务只读取轻量卡，完整公文再进入相应文种叶子，技术类材料只加载命中的专项规则。这样既保留必要边界，也减少无关规则对真实写稿的干扰。”

翻译成大白话：该精简的时候不啰嗦，该上规矩的时候不含糊。

四、四道关卡：它是怎么把"AI 味"摁下去的

拆到流程层面，这个 Skill 的主干其实只有四步。

第一步：定文种，再动笔

写公文之前，先回答清楚：这份东西发文单位是谁？受文对象是谁？行文关系是上行、下行还是平行？

这件事在真实办公里有多重要？——“该用请示却写了报告”，是公文审核里最常见的退稿理由之一。

它内置了文种路由规则，覆盖请示、报告、通知、通告、通报、函、复函、批复、意见、决定、公告、纪要等法定文种，也覆盖方案、可研、总结、调研报告、讲话稿、致辞等事务材料。用户明确要新闻稿、时评、整改方案、投诉反映这类文本时，它还会"直达"对应的专项 playbook，而不是被正文里偶然出现的"新闻""整改"字样带跑。

这一点，比"能写多少种文种"更值钱。

第二步：先出蓝图，再落笔

它的工作流里有一段明确要求：

写作前先建立稿件蓝图：大纲 → 段落地图 → 小段落要点。

这个顺序，跟老笔杆子写材料的习惯是一样的。

先想清楚这份材料要论证什么，分成几块，每块承担什么任务——然后才写句子。

而到了具体段落，它要求每个小段落只服务一个论点，并且通常按这个顺序展开：

结论先行 → 事实支撑 → 判断 → 项目/工作落点。

这四拍的节奏，就是机关文稿的呼吸方式。

第三步：分层复核，而不是"再读一遍"

写完就交，是 AI 最容易露怯的地方。

这个 Skill 的复核是分层的：先看小段落，再合并看小节，最后看全文。

每一层的检查项不一样——事实有没有编、视角有没有跑偏、结构有没有断、格式有没有错、表达有没有"成品残留"。

而且它还配了一个确定性工具scripts/prose_lint.py，可以对 .txt / .md / .docx 草稿做静态扫描，把"格式问题、重复表达、成品残留线索"报出来。

注意它的定位很重要：它只报风险，不负责改写。

这个边界划得很清醒——工具负责发现问题，人负责判断。公文这件事，不该让一个脚本替你做决定。

第四步：专门治"AI 味"

这是它最有识别度的一块。

它内置了references/anti-AI-patterns.md，专门列中文语境下的 AI 味模式和修复方法。据第三方技能站点的拆解，它使用了约 270 条合成反例做规则回归检查，针对的就是那几类标志性毛病：

• 旁白式写法（“让我们来看看”“接下来我将……”）
• 教学腔（“首先需要明确的是”“需要注意的是”）
• 二元包装句（"既要……又要……"的空泛表述）
• 过度完整的结构感（三段式排比、面面俱到的伪周全）
• 相邻段落换词重复、胶水段落、空泛套话

以及一条很硬的红线：

没有用户提供依据时，不编造真实单位、真实政策、真实金额、真实日期、电话、邮箱、文号、签发人、印章或审批结论。

这条规则，其实比"降 AI 味"更重要。

因为公文里出现一个不存在的文号，性质跟文章里写错一个错别字，完全不是一回事。

五、怎么装：三条命令，没有玄学

它的安装相当朴素，因为它本来就是纯规则包。

方式一：从 ClawHub 安装

npx clawhub@latest install chinese-official-writing

方式二：国内镜像加速

npx clawhub@latest install chinese-official-writing --registry https://cn.longxiaskill.com

方式三：通用 Agent Skills 安装器（GitHub 源）

npx skills add https://github.com/gongyu0918-debug/chinese-official-writing-skill --skill chinese-official-writing

装完之后，通常放在~/.openclaw/skills/chinese-official-writing/，重启网关即可被识别。

不需要 API Key，不需要额外账号，MIT 许可，免费开源。整个包体量只有 0.22 MiB 左右——规则密度极高，体积极小，这也是"规则型 Skill"相对"服务型 Skill"的一个天然优势。

六、三个真实场景，你可以直接抄

场景 1：一份单位通知

请按公文格式写一份通知：本周五下午 2 点在 3 楼会议室召开全员培训会，请各部门提前安排好工作，准时参加，培训时长约两小时。

它会先定文种（下行通知）、明确受文对象（各部门）、梳理办理要素（时间、地点、事项、要求），再按"依据/背景 → 事项 → 要求 → 时限"的结构成文，而不是上来就抒情。

场景 2：把会议纪要变成报告

根据下面这份会议记录，写一份向集团报送的专项工作报告。

它会走"情况 → 做法 → 成效 → 问题 → 下一步"的报告骨架，并且严格守住"报告里不夹带请示事项"这条规则——这一条，是很多人被退稿都不明白为什么的地方。

场景 3：限字压缩

这篇 2400 字，帮我压到 1200 字以内，保留措施、责任、时限和结尾落点。

它的做法是先做篇幅预算，再逐段取舍，而不是粗暴删句子。压缩这件事，删错一句，整段的逻辑就断了。

七、该泼的冷水还是要泼

任何 Skill 都有边界，这个也不例外。综合第三方站点和官方说明，几个已知短板值得提前知道：

还有一条最重要的提醒：它降低的是"AI 味"，不是"责任"。

AI 可以帮你把结构搭好、把腔调调正、把明显的机器痕迹擦掉。但这份材料最终是挂在谁名下、由谁签发，判断权永远在人手里。公文这件事，从来不是"生成"出来的，是"写"出来的。

八、同类对比：这个赛道已经打起来了

"中文公文写作"已经不是蓝海。我在调研中至少看到四类路线：

一句话选型建议：

• 要写正式材料、怕被看出是 AI 写的→ 选规则型；
• 只想知道"这个标题该用几号字"→ 选格式模板型；
• 想批量处理上百份 Word 公文→ 选 CLI 型。

九、最后

回到开头那个问题：为什么领导一眼就看出来是 AI 写的？

因为公文写作的核心从来不是"文采"，而是规矩。

文种是规矩，行文关系是规矩，办理要素是规矩，称谓是规矩，落款是规矩。"AI 味"之所以刺眼，是因为它破坏了这些规矩——它在用写公众号的方式，写一份要盖章的材料。

chinese-official-writing 最有价值的地方，不是它"写得像公文"，而是它把公文写作的规矩，一条一条写成了可以被审阅、被修改、被本地化的中文规则文件。

一百多次版本迭代，迭代的其实就是一件事：把规矩校准得更准一点。

如果你身边有在办公室、综合岗、文秘岗、宣传岗的朋友，把这篇文章转给他。他大概率会回你一句：

“你早说啊。”

关键词：chinese-official-writing、中文公文写作、Agent Skills、ClawHub、GB/T 9704、降 AI 味、AI 办公自动化

数据来源：ClawHub 技能页、GitHub（gongyu0918-debug/chinese-official-writing-skill）、skills.sh、longxiaskill 镜像站、openclaw-easy、CocoLoop 技能商店等公开页面，检索时间 2026-09-11。文中版本号、下载量等数据来自第三方聚合站点，可能随时间变动，请以官方页面为准。