# Data Sharing List Review

> Use when user wants to review 数据共享清单材料中的数据需求/数据共享清单填写质量。根据上传文件名自动匹配对应提取脚本与审核要点，先对所有文档类型中的表名/数据资源名称进行业务相关性判断，再保持原有字段审核机制输出结构化问题清单与审核结论。

- Skill: `kinjo886/data-sharing-list-review` (Agent Skill, multi-file: 14 files)
- Install (CLI): `npx skillmds@latest add kinjo886/data-sharing-list-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kinjo886/data-sharing-list-review/raw
- Safety review: pending (external: skill-scanner PASS, skillspector CAUTION)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kinjo886 (https://skillmd.com/u/kinjo886)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/kinjo886/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` 输出结构

```json
{
  "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 个数据资源** 的文档，其中一个与业务无关、一个与业务相关：

```markdown
# 数据共享清单审核报告

## 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 批量审核报告格式

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

#### 批量审核总览报告结构

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

## 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` 库执行转换
   - 命令示例：
     ```bash
     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` 脚本，功能要求：

```python
# 核心转换逻辑
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`