leaudit-platform-backend/docs/内部公文模块/内部公文规则补齐实施清单.md

内部公文规则补齐实施清单

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 补齐回来，再用样本文档验证执行效果。