lieflat-gongwen 公文写作 DNA 是一个 Agent Skill：把 102 万字真实公文的写作风格拆成可测量、可验收的数值参数，让 AI 写公文不再是凭感觉判断「像不像」，而是用 12 项参数对照真实语料。
方法论只有一句：参数来自全量统计，不是经验归纳。仓库不存逐字原文，只存参数卡与中位数+四分位区间，代价是参数第三方无法独立复核——这一条作者作为已知局限直接写在文档里没回避。兼容 Codex、ClaudeCode、Moxt 等支持 agents.md 的 Agent，核心能力零依赖，附带两个 Python 脚本只用标准库。
场景痛点
让 AI 写一篇「像样的公文」过去几乎是一句空话：开头塞「根据……为……」，结尾塞「请遵照执行」，中间凑几个「一是二是」。凑出来的成品，经验判断一句「不像」，但「哪里不像、差几个字、改到什么样算像」说不清。
更麻烦的是按文体错位：工作方案要短业务标签、密集三级标题，调研报告要「判断+转折」长标题，党建材料反过来——不能加一级标题、靠段首动宾句推进。用一份「通用模板」应付所有文体，是工具链里最常掉的坑。
对 写作 类 AI工具 来说，可测量的标准比「会写」更重要——前者能让返工成本降下来，后者只能靠肉眼看。这也是为什么面向公文的 工具推荐 一直在迭代：少靠经验感觉，多靠数字判定。
界面预览
Hero 图取自
assets/gongwen-dna-hero-zh.jpg：以 103 万字 · 全量统计为基线，列出 306 估算统计、7 类文体参数、12 项可验收指标。
核心功能
102 万字语料、7 类文体、12 项可验收指标
这个 AI写作 skill 走的是把「像不像」变成可验收数值的路子：
语料分两个文体族、七个类别：公文族六类（调研报告、领导讲话、工作意见、经验材料、工作方案、经验总结），篇幅中位 2,500–3,700 字、2–5 个一级标题；党建族一类（党建材料），约 1,120 字、零一级标题。不做法定公文（通知 / 请示 / 批复 / 函），因为这类文体的正文是固定结构、风格已确定，不需要量化蒸馏。
102 万字是 91.4 万字公文语料 + 10.3 万字党建语料的合并计数。判族只看两件事：篇幅与一级标题数——千字材料一旦加上多个一级标题就变成压缩版公文，参数会跟着乱。
7 类文体各自带一张参数卡：平均句长、顿号密度、三级标题数、「一是二是」频次等 12 项参数都按中位数+四分位给出区间。Hero 图上标注的 12 项可验收指标就是这套参数卡的验收入口。
自检器只判一类硬冲突
配套的 scripts/check_params.py 把参数偏离分两类：硬冲突（判错）与软偏离（仅提示）。硬冲突只有一种：文种识别错误——比如给工作方案写出了调研报告的层级结构。其它偏离都按提示处理：自检器拒绝把均值当合格线，例如调研报告里「一是二是」从 0 到 20 次都有人用、四分之一的样本完全不用。
六步工作流与第 3 步不可跳过
入口 SKILL.md 把整个流程写成六步：判文体族 → 判文种 → 定参数行 → 读同文种的 DNA 文档 + 范文 → 出骨架等确认 → 按参数写正文 → 跑自检修正。设计上属于 Skill工具 一类：Agent 在执行写作任务前先把这一份当作上下文加载。
第 3 步是这个 skill 与模板类工具的分野。抽象的参数说不清并列成分怎么堆、过渡句放哪、看一篇真稿子比读十条规则有效——这是作者的明确判断，所以这一步在文档里被标成「不可跳过」。
文种指纹：标题字数与「一是二是」
不同文种在参数上有可作判据的差异：
- 工作方案：一级标题 4–8 字业务标签，三级标题密集（案例 11 个），是七类里唯一大量用
1.列表的文种 - 调研报告：一级标题 17–21 字「判断+转折」双分句，承载观点
- 党建材料：零一级标题，靠「拧紧责任链」这样的段首动宾提领句分层，长引语是这一族的正向指纹
作者把这些差异在 README 里写成「文种指纹」一节，作为参数卡的展开。
流行认知被实测推翻的 5 项
README 的「研究过程」一节直接列出统计推翻的常见假设。每一项都给出「流行说法 vs 全量数据」对照：
| 流行假设 | 全量数据 |
| 开头都「根据……为……」 | 依据式仅 6–8%，无单一主导 |
| 结尾必须程式化 | 75–87% 是自然收束，请遵照执行类不足 2% |
| 好公文要有数据支撑 | 60–72% 完全不用百分比，党建 100% / 工作方案 80% / 调研报告 51% 零百分比 |
| 一级标题应简短 | 分析类平均 17 字，承载观点；短标题只属于业务类 |
| 「必须 / 应当」体现文件力度 | 密度 0.56–0.58‰，3000 字公文只有 1–2 个 |
这五条的样本原文已被剥离（版权原因），作者把推翻的统计与修正过程留在文档里。
22 篇范文与 10 篇首批返工
仓库的 示例/ 目录放 22 篇合成范文与一份返工审计（示例/README.md），范文的边界是「只能借结构和节奏、不能借内容」。
首批 10 篇范文的返工过程被完整记录：当时是从原文中切前 700–1,200 字、正则抽一遍标题就动笔，骨架拿到了、场面与结尾没进过视野。审计后六篇重写、四篇保留——以同样的语料统计、复刻同样的写作风格这件工作，方法本身就是可被自身判据推翻的。
数字占位原则：遇到无法核实就标【待补：xx】
示例中的工作方案范本里出现 【待补：xx】 占位——这并非没写完，而是该填本地数字的地方刻意留坑。背后的逻辑：60–72% 真实公文完全不用百分比，没可靠数据时靠逻辑深度撑起文章是可行的；Skill 遇到无法核实的数字一律占位、绝不编造。
安装与使用
前置条件
- 兼容
agents.md的 Agent：Codex / ClaudeCode / Moxt 等任一 - 运行时：核心能力零依赖；
scripts/check_params.py与scripts/strip_meta.py仅用 Python 标准库
安装
仓库作者推荐两条路：
- 直接装到 Moxt：在 Moxt 里用这份 skill，长文的反复读取与逐句改写正需要工作空间的上下文能力
- 克隆到本地 skills 目录：
或把整个目录放进自己 Agent 的 skills/ 目录下。
六步调用流程
- 判文体族 → 判文种 → 定参数行：依据篇幅与一级标题数确定走「公文族」还是「党建族」，再选具体文种
- 读同文种的骨架公式：
参数卡.md七文体一页表，每次必读 - 读同文种的 DNA 文档 + 范文（不可跳过）：
公文语料/、党建语料/下的 DNA 文档与示例/下的合成范文 - 出骨架，停下等确认：把标题层级与段落大纲交给用户核对再下笔
- 按参数写正文：对照 12 项参数区间写
-
跑自检，按报告修正：
只判硬冲突；软偏离自己取舍。
注意事项
- 不做法定公文：通知 / 请示 / 批复 / 函 这类有固定模板的文体本 skill 不覆盖
- 不传逐字语料：语料因版权全部移除、不随包分发，频率数值第三方无法直接复核，这是已知缺陷
- 样本偏薄：工作方案（10 篇）、经验总结（8 篇）样本偏薄，对应参数仅供参考
- 合规边界：参数解决「像不像」，管不了「对不对」——涉密与对外口径须经本单位核稿人终审
我的使用感受
仓库最有说服力的一点是返工审计：作者把 10 篇首批的六篇重写过程直接公开，第一次看到的「已完成参数」其实是多轮修订后的稳定版本，这种自我审计在 GitHub精选 类项目里不算多见。
用之前先把 使用教程 里的六步和「第 3 步不可跳过」读到位——参数卡只能告诉你范围，真正的判断要从 DNA 文档与范文中读出。它只解决风格这一件事，政治表述、对外口径、涉密数据不在覆盖范围。作为 效率工具 与 Skill教程 类项目，它的定位介于 AI相关 与 实用软件 之间——skill 生态里肯把返工过程一并公开的不多。
官方网站
https://github.com/larashero3-dotcom/lieflat-gongwen
下载地址
https://pan.quark.cn/s/904c8608a791
