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