Data Sharing List Review

数据共享清单审核 Skill

1. Skill 目标

对上传的文档进行自动识别与审核：

• 根据文档名称匹配对应的提取脚本；
• 先根据表名/数据资源名称判断该表是否与业务相关；
• 若判断为与业务无关，仅输出表级判断结果，不继续进行该表的字段级审核；
• 若判断为业务相关或需继续确认，则使用对应的审核要点继续进行字段级审核；
• 输出结构化审核结果（通过/不通过/需人工复核、表级业务相关性判断、问题明细、建议修改项）。

2. 目录约定

项目目录使用以下约定：

• refrences/：存放不同文档类型对应的审核要点（检查清单、规则说明等），以及表级业务相关性判断规则；
• scripts/：存放不同文档类型对应的信息提取脚本，以及表名/数据资源名称业务相关性判断脚本；
• SKILL.md：Skill 主说明文件（当前文件）。

说明：目录名按当前需求固定为 refrences（保持与需求描述一致）。

3. 文档名称与规则映射

当上传文档名称命中以下任一项时，先执行对应提取脚本，再执行通用业务相关性判断脚本，最后按逐表判断结果决定是否继续字段级审核：

1. 文档名称：附件1-1：数据需求清单（立项环节）
   提取脚本：1-data-demand-project-approval.py
   审核要点：1-data-demand-project-approval.md

2. 文档名称：附件1-2：数据需求清单（初设环节）
   提取脚本：2-data-demand-primary-design.py
   审核要点：2-data-demand-primary-design.md

3. 文档名称：附件1-3：数据共享清单（初设环节）
   提取脚本：3-data-share-primary-design.py
   审核要点：3-data-share-primary-design.md

4. 文档名称：附件1-4：数据共享清单（初验环节）
   提取脚本：4-data-share-primary-acceptance.py
   审核要点：4-data-share-primary-acceptance.md

5. 文档名称：附件1-5：数据共享清单（试运行环节）
   提取脚本：5-data-share-pilot-run.py
   审核要点：5-data-share-pilot-run.md

通用业务相关性判断脚本：

• 脚本名称：business_relevance_review.py
• 适用所有文档类型，在对应文档提取脚本执行完成后，读取其 JSON 提取结果并执行；
• 脚本作用：根据每条记录中的表名/数据资源名称判断该表/资源是否与业务无关；
• 判断结果（逐表输出）：
  • should_continue_field_review=false：该表与业务无关，仅输出表级判断结果（命中关键词、来源字段、行号），不继续进行该表的字段级审核；
  • should_continue_field_review=true：该表与业务相关，继续加载对应审核要点并执行字段级审核；
  • 表名/数据资源名称为空或无法判断时：不拦截字段级审核，继续按对应审核要点处理，并在报告中提示需人工复核。

4. 执行流程

4.1 单文件审核流程

一个文档可能包含多个表/数据资源，每个表独立完成以下流程：

1. 接收上传文档并读取文件名称；
2. 用"文档名称 -> 脚本/审核要点"映射表定位目标配置；
3. 执行 scripts/ 下对应脚本，提取所有表/数据资源的信息；
4. 执行业务相关性判断脚本 scripts/business_relevance_review.py：
   • 传入步骤 3 的提取结果 JSON；
   • 脚本逐表判断并返回每个表的 should_continue_field_review 标记；
5. 若某表判断为与业务无关：
   • 输出该表的判断结果（表名、命中关键词、来源字段、行号）；
   • 不读取该表的字段内容，不扫描该表的数据项，不加载审核要点；
   • 不继续进行该表的字段级审核；
   • 在报告中记录为"无需审核"；
6. 若某表判断为与业务相关（仅对 should_continue_field_review=true 的表）：
   • 加载 refrences/ 下对应审核要点，读取该表的字段内容，逐字段执行审核；
   • 记录该表的字段级审核结果（通过/不通过/需人工复核）；
7. 若某表判断为无法确认业务相关性：
   • 继续进行字段级审核；
   • 在报告中标记为"需人工复核"；
8. 文档整体审核结论：取所有表中审核结论最严重的作为文档级别结论：
   • 全文所有表均为"与业务无关" → 文档结论 无需审核
   • 存在任一表为"不通过" → 文档结论 不通过
   • 存在任一表为"需人工复核" → 文档结论 需人工复核
   • 其余情况 → 文档结论 通过

4.2 压缩包批量审核流程

当用户上传压缩包（.zip、.rar、.7z 等格式）时，执行以下流程：

1. 接收并识别压缩包

   • 检测文件扩展名，识别为压缩包格式
   • 创建临时目录用于解压

2. 解压处理

   • 解压压缩包到临时目录
   • 遍历解压后的目录结构
   • 识别所有符合审核条件的文档（按文件名匹配映射表）

3. 文档分类与排序

   • 按文档类型分类（附件1-1至附件1-5）
   • 按编号顺序排序（立项→初设→初验→试运行）
   • 记录未匹配的文档（作为异常项）

4. 逐个审核执行

   • 对每个符合条件的文档，执行4.1单文件审核流程
   • 对与业务无关的表，仅收集表级判断结果，不进行字段审核
   • 对业务相关的表，继续收集字段级审核结果
   • 维护审核状态映射表（文档名 -> 审核结果）

5. 批量结果汇总

   • 生成批量审核总览报告
   • 汇总各文档审核结论
   • 汇总与业务无关的表清单
   • 统计整体问题分布

6. 临时目录清理

   • 审核完成后清理临时文件

4.3 字段审核执行指南

重要：字段审核由 LLM 直接执行，不需要编写额外脚本。 提取脚本和业务相关性判断脚本已提供，字段级审核只需按照以下步骤逐表进行：

4.3.1 单表字段审核步骤

1. 加载该表的提取结果 — 从提取脚本输出的 JSON 中定位该表的数据
2. 加载对应审核要点 — 从 refrences/ 下读取对应文档类型的审核要点（.md 文件）
3. 逐规则检查 — 按审核要点中的每条规则，对照该表的字段值进行检查：
   • 必填字段规则：检查字段是否为空
   • 枚举规则：检查字段值是否在允许范围内
   • 格式规则：检查字段格式是否符合要求
   • 逻辑规则：检查跨字段的关联约束（如"数据量 > 10000 且非全量更新时，数据增量必填"）
4. 记录问题 — 每条违规生成一条 issue，包含：规则编号、字段名、行号/位置、问题描述、修改建议、优先级
5. 判定该表结论 — 存在 high 问题 → 不通过；仅 medium/low → 需人工复核；无问题 → 通过

4.3.2 逐表审核后汇总报告

每审核完一个表立即输出到报告中（按 Section 6 格式），审核完所有表后按 4.1 步骤 8 汇总文档级结论。

4.3.3 批量审核时的执行次序

1. 读取 SKILL.md（本文）——了解整体流程
2. 读取 refrences/ 下 5 个审核要点 ——了解各文档的审核规则
3. 读取 scripts/ 下 5 个提取脚本 ——了解各文档的提取逻辑
4. 读取 scripts/business_relevance_review.py ——了解关键词列表和判断逻辑
5. 读取 scripts/md_to_docx.py ——了解转换工具用法
6. 对每个文档：执行提取脚本 → 执行业务相关性判断脚本
7. 逐表执行字段审核（见 4.3.1）→ 被判定为与业务无关的表完全跳过
8. 按 Section 6 格式生成 Markdown 报告
9. 运行 md_to_docx.py 转换为 Word 文档

禁止：不要在审核过程中创建新的 Python 脚本。所有必要的脚本（提取、业务相关性判断、格式转换）已就位，字段审核和报告生成由 LLM 直接完成。

5. 输出结果建议格式

每个文档的输出以表/数据资源为基本单元，再汇总为文档级结论：

• document_name：文档名称
• mapping_key：命中的映射键（如 1-data-demand-project-approval）
• tables：该文档中每个表/数据资源的审核结果数组，每项包含：
  • table_name：表名/数据资源名称
  • business_relevance：该表的业务相关性判断结果（见 5.2）
  • field_review：字段级审核结果（仅业务相关/无法判断时有值；业务无关时为 null）
• review_result：文档级总体结论（通过 / 不通过 / 需人工复核 / 无需审核），取所有表中最严重的
• summary：审核摘要

5.1 业务相关性判断结论分类

重要：一个文档有多个表时，每个表独立判断。表 A 与业务无关不代表表 B 也跳过——只跳过命中关键词的表。

5.2 business_relevance_review 输出结构

{
  "conclusion": "业务无关",
  "matched_keywords": ["临时表", "temp"],
  "location": {
    "field": "数据资源名称（中文表名）",
    "row_index": 1,
    "value": "租户表_互联网APP同步数据临时表"
  },
  "note": "该表名包含\"临时表\"关键词，通常为系统内部临时存储，建议从共享清单中移除。如确需共享请确认。"
}

6. 审核报告输出要求

当审核完成后，生成 Markdown 格式 的审核报告文档发送给用户。

6.1 报告内容结构

审核报告按表/数据资源逐项呈现：

1. 文档基本信息

   • 审核文档名称
   • 文档类型（根据映射键）
   • 审核时间

2. 业务相关性判断（第一个独立区块，逐表列出）

   • 汇总统计：与业务无关 X 项，与业务相关 X 项，无法判断 X 项
   • 每个表/数据资源的判断明细：
     • 表名/数据资源名称
     • 来源字段与行号
     • 命中的内置关键词（逐条列出）
     • 判断结论：与业务无关 / 与业务相关 / 无法判断
   • 明确说明：该判断仅基于表名/数据资源名称，不针对表内字段

3. 审核结论（逐表输出）

   • 每个表/数据资源独立给出审核结论：
     • 与业务无关 → 无需审核（未执行字段级审核）
     • 与业务相关且字段审核通过 → 通过
     • 与业务相关但存在问题 → 不通过 或 需人工复核
   • 文档级总体结论（取最严重的）

4. 问题明细（仅针对与业务相关 + 无法判断的表）

   • 按表分组，按规则编号列出问题
   • 每条问题包含：规则编号、问题字段、定位、问题描述、修改建议、优先级

5. 数据提取摘要

   • 各表的数据记录数量
   • 关键字段摘要（不涉及敏感数据）

6. 后续操作建议

   • 与业务无关项：建议从清单中移除，如确需保留请确认
   • 不通过项：逐项整改指引
   • 无法判断项：人工确认说明

6.2 报告格式示例

以下示例展示一个包含 2 个数据资源 的文档，其中一个与业务无关、一个与业务相关：

# 数据共享清单审核报告

## 1. 文档信息
- **文档名称**：附件1-4：数据共享清单（初验环节）
- **审核类型**：4-data-share-primary-acceptance
- **审核时间**：2026-07-29

## 2. 业务相关性判断

| 表名 | 来源字段 | 行号 | 命中关键词 | 结论 |
|------|----------|------|-----------|------|
| 新生儿信息备份 | data_resource_name | 第1行 | `备份` | ⚠️ 与业务无关 |
| 老年人信息 | data_resource_name | 第2行 | — | ✅ 与业务相关 |

> 判断仅基于表名，不针对表内字段。1 项与业务无关，1 项与业务相关。

## 3. 审核结论

### 新生儿信息备份 — ⚠️ 与业务无关
- **审核结论**：无需审核
- **说明**：命中关键词 `备份`，跳过字段级审核。建议从共享清单中移除。

---

### 老年人信息 — ✅ 与业务相关
- **审核结论**：不通过
- **问题统计**：高优先级 2 项，中优先级 3 项，低优先级 0 项

#### 问题明细

| 规则编号 | 字段 | 定位 | 问题描述 | 修改建议 | 优先级 |
|----------|------|------|----------|----------|--------|
| 4-1-1 | 共享条件 | 第3行 | 内容不完整 | 补充具体共享条件 | 高 |
| 4-1-2 | 数据资源分类 | 第5行 | 缺少"类"后缀 | 改为"主题数据类" | 中 |
| 4-1-3 | 开放条件 | 第6行 | 长度不足 | 补充完整法律依据 | 中 |
| ... | ... | ... | ... | ... | ... |

---

### 文档总体结论：不通过

## 4. 数据摘要
- 数据资源总数：2 个
- 与业务无关：1 个（新生儿信息备份，未审核）
- 与业务相关：1 个（老年人信息，已审核）

## 5. 后续建议
1. **新生儿信息备份**：确认是否为备份表，如确认则从清单中移除
2. **老年人信息**：按问题明细逐项整改高优先级问题
3. 整改完成后重新提交审核

6.3 输出要求

• 报告标题明确为「XXX审核报告」
• 使用 Markdown 标准格式（标题层级、列表、表格等）
• 问题按优先级从高到低排序
• 提供清晰的修改建议和定位信息
• 不包含原始敏感数据，仅展示审核结论和问题

6.4 批量审核报告格式

当审核压缩包内多个文档时，生成批量审核总览报告 + 各文档独立审核报告。

批量审核总览报告结构

# 数据共享清单批量审核报告

## 1. 审核概览
- **压缩包名称**：xxx.zip
- **审核时间**：2026-07-29
- **文档总数**：5 个
- **数据资源总数**：9 个（与业务无关 3 个，与业务相关 6 个）
- **通过**：3 个 | **不通过**：1 个 | **无需审核**：1 个

## 2. 业务相关性判断汇总（逐表列出，跨文档）

| 序号 | 所属文档 | 表名/资源名 | 命中关键词 | 结论 |
|------|----------|------------|-----------|------|
| 1 | 附件1-1 | 人口信息字典表 | `字典`、`字典表` | ⚠️ 与业务无关 |
| 2 | 附件1-4 | 新生儿信息备份 | `备份` | ⚠️ 与业务无关 |
| 3 | 附件1-5 | 租户表_互联网APP同步数据临时表 | `临时表`、`临时` | ⚠️ 与业务无关 |

> 以上 3 项已跳过字段级审核，建议从共享清单中移除或确认后保留。

## 3. 文档审核结果汇总表

| 序号 | 文档名称 | 总表数 | 业务无关表数 | 审核结论 | 高 | 中 | 低 |
|------|----------|--------|-------------|----------|----|----|----|
| 1 | 附件1-1：数据需求清单（立项环节） | 2 | 1 | 通过 | 0 | 0 | 0 |
| 2 | 附件1-2：数据需求清单（初设环节） | 2 | 0 | 通过 | 0 | 0 | 0 |
| 3 | 附件1-3：数据共享清单（初设环节） | 2 | 0 | 通过 | 0 | 0 | 0 |
| 4 | 附件1-4：数据共享清单（初验环节） | 2 | 1 | 不通过 | 2 | 7 | 0 |
| 5 | 附件1-5：数据共享清单（试运行环节） | 1 | 1 | 无需审核 | 无 | 无 | 无 |

> **说明**：
> - 业务无关表已在 Section 2 逐表列出，此处仅统计数量
> - 审核结论取该文档所有表中**最严重**的（无需审核 < 通过 < 需人工复核 < 不通过）
> - "业务无关表数 > 0"且"总表数 = 业务无关表数" → 审核结论为 `无需审核`（全文跳过）
> - 高/中/低列仅统计业务相关表的问题数；文档全文为无需审核时填"无"

## 4. 各文档主要问题

1. **附件1-1**：含 2 个数据资源——"人口信息字典表"与业务无关已跳过；"房屋租赁信息"字段级审核全部通过
2. **附件1-2**：共享需求清单 2 条记录全部通过；采集需求清单无数据记录（低优先级提示）
3. **附件1-3**：2 条记录全部通过，无问题
4. **附件1-4**：含 2 个数据资源——"新生儿信息备份"与业务无关已跳过；"老年人信息"发现 9 个中优先级问题（数据资源分类缺后缀、共享条件不完整等）
5. **附件1-5**：仅 1 个数据资源"租户表_互联网APP同步数据临时表"，命中"临时表"判定为与业务无关，跳过字段级审核（该表含 78 个数据项，数据量 104,448）

## 5. 后续建议
1. 与业务无关项（3 项）：统一确认是否从共享清单中移除
2. 不通过文档（附件1-4）：整改后重新提交审核
3. 通过文档（附件1-1、附件1-2、附件1-3）：无需操作

批量审核特定要求

• 总览报告提供整体视角，便于快速了解所有文档的审核状态
• 独立报告保持单文件审核报告的完整格式
• 跨文档关联问题（如同一系统在不同环节的描述不一致）在总览报告中体现
• 各文档独立报告的命名格式：{原文件名}-审核报告.md

6.5 Markdown 报告转 Word 文档

审核完成后，将生成的 Markdown 格式审核报告转换为 Word 文档（.docx）并发送给用户。

转换流程

1. 生成 Markdown 报告

   • 按 6.1-6.4 节要求生成标准 Markdown 审核报告

2. 转换为 Word 文档

   • 使用 python-docx 库执行转换
   • 命令示例：

     python scripts/md_to_docx.py --input "审核报告.md" --output "审核报告.docx"
     

3. 格式保留要求

   • 标题层级 → Word 标题样式（Heading 1/2/3）
   • 表格 → Word 表格（保留边框和对齐方式）
   • 列表 → Word 项目符号/编号列表
   • 加粗/斜体 → Word 字符格式
   • 代码块 → 等宽字体段落

4. 发送给用户

   • 单文件审核：直接发送 {原文件名}-审核报告.docx
   • 批量审核：发送总览报告 Word + 各文档独立报告 Word（打包为 zip）

转换脚本规范

创建 scripts/md_to_docx.py 脚本，功能要求：

# 核心转换逻辑
from docx import Document
from docx.shared import Pt, RGBColor
from docx.enum.text import WD_ALIGN_PARAGRAPH
import markdown
from bs4 import BeautifulSoup

def markdown_to_docx(md_path: str, docx_path: str):
    """将 Markdown 文件转换为 Word 文档"""
    # 1. 读取 Markdown 内容
    # 2. 解析为 HTML（使用 markdown 库）
    # 3. 使用 BeautifulSoup 遍历 HTML 节点
    # 4. 根据节点类型创建对应 Word 元素：
    #    - h1/h2/h3 → add_heading()
    #    - p → add_paragraph()
    #    - table → add_table()
    #    - ul/li → 添加项目符号列表
    #    - strong/b → 应用加粗格式
    #    - em/i → 应用斜体格式
    # 5. 保存文档

文档命名规范

• 单文件审核：{原文件名}-审核报告.docx
• 批量总览报告：批量审核总览报告.docx
• 批量独立报告：{原文件名}-审核报告.docx

输出要求

• Word 文档使用标准宋体/黑体字体
• 标题使用黑体，正文使用宋体
• 表格边框清晰，表头加粗并设置背景色
• 页边距：上下 2.54cm，左右 3.17cm（标准 A4）
• 页眉：可添加"数据共享清单审核报告"字样

7. 异常处理规则

• 若文档名称未命中映射表：返回“暂不支持的文档类型”，并提示可支持文档列表；
• 若脚本执行失败：返回错误信息与失败步骤，不直接给出通过结论；
• 若审核要点缺失：返回“审核规则未配置完成”，进入待补充状态；
• 若提取信息不完整：标记为“需人工复核”；
• 若表名/数据资源名称为空：不执行表级业务相关性拦截，继续按对应审核要点中的必填字段规则处理；
• 若表名/数据资源名称无法判断业务相关性：继续进行字段级审核，并在报告中标记为“需人工复核”；
• 若表名/数据资源名称判断为与业务无关：仅输出表级/资源级判断结果（命中关键词、来源字段、行号），不继续进行该表/数据资源的字段级审核。

8. 待补充项（下一步逐步完善）

后续将按你的步骤补充以下内容：

1. 每个映射项在 refrences/ 中的具体审核要点内容； ✓ 已完成
2. 每个映射项在 scripts/ 中的具体字段提取逻辑； ✓ 已完成
3. 统一的规则编号体系与问题描述模板； ✓ 已完成
4. 最终可执行的审核示例与测试用例。

9. 审核要点与脚本索引

9.1 已落地审核要点

• refrences/1-data-demand-project-approval.md
• refrences/2-data-demand-primary-design.md
• refrences/3-data-share-primary-design.md
• refrences/4-data-share-primary-acceptance.md
• refrences/5-data-share-pilot-run.md

9.2 已落地提取脚本

• scripts/1-data-demand-project-approval.py
• scripts/2-data-demand-primary-design.py
• scripts/3-data-share-primary-design.py
• scripts/4-data-share-primary-acceptance.py
• scripts/5-data-share-pilot-run.py
• scripts/business_relevance_review.py