# 内部公文规则补齐实施清单 ## 1. 文档目的 本文档只回答一个实施问题： - 在**不改变旧项目内部公文业务语义**的前提下，如何把旧项目 `31` 条规则按当前 `leaudit-platform` 的 `govdoc` 规范补齐回来 本文档不讨论“是否需要重新设计一套公文规则引擎”，因为当前结论已经明确： - 旧项目和当前平台使用的是同一套 `govdoc DSL` - 当前平台 `govdoc_engine` 已具备承接旧规则的大部分执行能力 - 当前缺的主要不是引擎能力，而是**规则内容尚未完整迁入** --- ## 2. 结论先行 当前内部公文规则补齐工作，应按下面这个判断推进： 1. **规则 DSL 不需要重做** 2. **现有执行器不需要先推翻重写** 3. **第一优先级是把旧项目规则语义按当前平台 YAML 补齐** 4. **只有在迁入后验证发现误报/漏报时，才对角色识别、提示词、个别 check 实现做小范围修正** 换句话说： - 当前不是“先开发引擎，再迁规则” - 而是“先补规则，再基于验证结果修实现细节” --- ## 3. 当前平台承接能力盘点 ## 3.1 DSL 结构已对齐 当前平台规则文件： - `rules/govdoc/govdoc_general/rules.yaml` 旧项目规则文件： - `/home/wren-dev/Porject/govdoc-audit/rules/govdoc_general/rules.yaml` 两边都是： - `metadata` - `extract` - `rules` 因此补齐规则时，不需要把规则改写成合同模块那套 DSL。 --- ## 3.2 当前平台已支持的 check 类型 旧项目规则实际用到的 check 类型如下： - `ai` - `attachment_marker_style` - `confused_pair` - `cross_role` - `font` - `forbid_chars` - `forbid_phrase` - `hierarchy` - `punctuation` - `regex_forbid` - `wenzhong_whitelist` 这些 check 类型当前平台都已经存在于 `govdoc_engine` 中。 因此从实施角度判断： - **绝大多数旧规则可以直接按 YAML 迁入** --- ## 3.3 当前平台已具备的 role 识别前提 当前 `role_tagger_rule.py` 已可识别： - `title` - `doc_number` - `date` - `recipient` - `signature` - `attachment_marker` - `attachment_title` - `heading_1` - `heading_2` - `heading_3` - `heading_4` - `body` 这意味着旧项目规则里依赖以下 role 的规则已有运行前提： - `heading_1` - `heading_2` - `heading_3` - `heading_4` - `body` - `attachment_marker` - `any` 结论是： - **旧项目规则在“选段目标”这一层，没有明显的结构性阻塞** --- ## 3.4 当前平台现状不是“没规则”，而是“规则过少” 当前平台内部公文规则现状： - `2` 个规则组 - `6` 条规则 当前保留的规则主要是： - 标题必填 - 发文字号必填 - 署名必填 - 日期必填 - 文种白名单 - 附件标记样式 这属于： - **最小可运行规则集** 不属于： - **旧项目完整规则语义** --- ## 4. 旧项目 31 条规则迁移分类 为避免后续实施发散，旧规则应先按“迁移方式”分组，而不是按代码文件分组。 ## 4.1 A 类：可直接迁入的确定性规则 这类规则特点是： - 不依赖 LLM 推理 - 主要依赖正则、字体、标点、层级、固定短语等确定性判断 - 迁移成本最低 - 最适合作为第一批补齐内容 包含如下规则： ### 标题类 - `GW-T-002` 标题不可有“请求+请示”重复 - `GW-T-003` 标题不可有“上报+报告”重复 - `GW-T-004` 标题介词连用 - `GW-T-005` 标题文种白名单 ### 发文字号类 - `GW-N-001` 发文字号必须用六角括号 - `GW-N-002` 发文字号不可加“第”字 - `GW-N-003` 发文字号顺序号不编虚位 ### 格式类 - `GW-F-001` 主标题用方正小标宋简体二号 - `GW-F-002` 一级标题用黑体三号 - `GW-F-003` 二级标题用楷体三号 - `GW-F-004` 正文用仿宋三号 - `GW-F-005` 附件后不加冒号 - `GW-F-006` 不使用“此页无正文” - `GW-F-007` 附件项末尾不加标点 - `GW-F-008` 三级标题用仿宋三号 - `GW-F-009` 四级标题用仿宋三号 - `GW-F-010` 附件标记用黑体三号不加粗 ### 层级类 - `GW-H-001` 层级序号格式 - `GW-H-002` 二级标题换行不带句号 ### 标点类 - `GW-P-001` 多书名号/引号并列不加顿号 - `GW-P-002` 句内括号末尾不加标点 - `GW-P-003` 引号嵌套不规范 ### 文字提法类 - `GW-W-001` 易混淆词使用 - `GW-W-003` 成文日期用阿拉伯数字 - `GW-W-004` 成文日期不编虚位 这批规则的实施结论： - **优先补** - **优先恢复旧 rule_id** - **优先保持旧 messages / severity / category 语义** --- ## 4.2 B 类：可迁入，但依赖 LLM 提示词稳定性的语义规则 这类规则当前平台格式和引擎都支持，但它们的稳定性更依赖： - 提示词是否原样保留 - 实体抽取结果是否稳定 - role 识别和上下文拼接是否足够 包含如下规则： ### 标题类 - `GW-T-001` 标题文种合规性 - `GW-T-006` 标题回行词意完整 - `GW-T-008` 标题字体（语义实体通道示例） ### 文字表述类 - `GW-W-002` 简称使用规范 ### 发文机关类 - `GW-S-001` 发文机关署名不能用简称 - `GW-S-002` 发文机关确定严谨性 这批规则的实施结论： - **可以按 YAML 直接迁入** - **不需要先开发新 check** - **但迁入后必须做专项样本验证** 这里的重点不是“能不能跑”，而是： - **误报率是否可接受** - **fail 条件是否与旧项目提示词语义一致** --- ## 4.3 C 类：当前已有最小替代规则，但语义仍未完全恢复 当前平台已有的 6 条规则中，有一部分与旧语义有关联，但并不等价。 例如： - `govdoc_wenzhong_whitelist` - `govdoc_attachment_marker_style` 问题不在于它们“错了”，而在于： - 它们使用的是新命名 - 它们只覆盖了旧规则中的一个点 - 它们没有连带恢复同组其它规则 因此这类规则后续要按一个明确原则处理： - **不是继续叠加 bootstrap 规则** - **而是回到旧项目规则语义集合，统一整理成正式规则集** 否则后面会出现： - bootstrap 规则一套命名 - 旧项目规则一套命名 - 语义重叠但口径不同 这会直接破坏规则可追溯性和前端规则展示一致性。 --- ## 5. 建议的实施顺序 ## 5.1 第一阶段：规则集语义回正 这一阶段只做一件事： - 把当前 `govdoc_general` 规则文件从“最小运行版”恢复到“旧项目正式规则版” 建议动作： 1. 以旧项目 `31` 条规则为基准 2. 保留当前平台 `govdoc DSL` 结构不变 3. 优先恢复旧 `rule_id / name / severity / category / messages` 4. 把当前 6 条 bootstrap 规则合并回正式规则语义，而不是长期并存 这一阶段的目标不是调优，而是： - **先把规则集语义补齐** --- ## 5.2 第二阶段：确定性规则验证 这一阶段重点验证 A 类规则： - 正则规则是否命中正确 - 字体规则是否受样式解析影响 - 标点/层级规则是否存在明显误报 建议验证方式： 1. 选取一批旧项目正例/反例文档 2. 对比迁移前后 `checked_rules / findings` 3. 重点看是否出现“旧项目 fail，当前 pass”或“旧项目 pass，当前 fail” 这一阶段的验收重点是： - **确定性规则尽量做到与旧项目结论一致** --- ## 5.3 第三阶段：语义规则验证 这一阶段只关注 B 类规则。 建议验证项： 1. 提示词是否与旧项目一致 2. 上下文变量是否完整可用 3. LLM 返回 `pass / warn / fail` 时，当前平台展示是否保持旧语义 4. 是否出现明显漂移，例如该 pass 的规则被大量误报为 fail 这一阶段允许的改动是： - 小范围调整 prompt - 小范围补上下文字段 - 小范围修正实体输入 这一阶段不应做的事情是： - 重新定义业务判定标准 - 为了追求“看起来更智能”而改变旧规则语义 --- ## 5.4 第四阶段：规则集治理接轨平台 当规则内容补齐并验证后，再处理平台治理问题： - `type_id` 命名是否回归 `govdoc.general` - 规则版本记录如何写入平台规则治理链路 - 规则列表、规则详情接口如何展示完整 metadata 这一步的重点是： - **把已经恢复的旧业务规则集，真正纳入当前平台的规则版本治理** 而不是继续长期依赖固定文件路径硬编码。 --- ## 6. 实施边界 ## 6.1 可以做的事情 - 按当前 `govdoc DSL` 补旧规则 YAML - 复用当前 `govdoc_engine` 已有 check - 复用当前 role tagger - 对少量提示词或 role 识别做兼容性修正 - 按当前平台规范接入规则列表、规则详情、版本记录 --- ## 6.2 不应做的事情 - 把内部公文规则改写成合同 DSL - 因为当前有 6 条 bootstrap 规则，就以它们为最终标准 - 在没有业务确认的情况下重命名旧规则语义 - 为了迁移方便删除 `skipped`、`warning`、`pass` 三分态 - 用“新平台习惯”替代旧项目正式审查语义 --- ## 7. 当前建议的优先级 ## P0：必须先补 - A 类确定性规则整体迁入 - 旧规则 metadata 语义恢复 - 旧 rule_id 体系恢复 - 规则列表 / 规则详情能看到正式规则集 ## P1：紧随其后 - B 类 LLM 语义规则迁入 - 样本文档专项验证 - 报告页中规则结果与旧项目口径对齐 ## P2：最后收口 - `type_id` 命名统一 - 规则版本治理正式接轨平台 - 后台规则管理入口与平台其它文档类型规则治理一致 --- ## 8. 最终结论 内部公文规则补齐这件事，现在不该再停留在“有没有 YAML”“格式支不支持”这个层面。 当前真实状态是： - 平台格式已具备 - 运行链路已具备 - 承接 check 已具备 - 缺的是**旧项目正式规则内容没有完整迁回** 因此下一步实施应按下面的最小原则推进： > **不改业务语义，不重造引擎，先把旧项目 31 条规则按当前平台 `govdoc DSL` 补齐回来，再用样本文档验证执行效果。**