Files
mdpolish/README.md
T
Bepr4 8ac4f1dd12 更名 mdpolish 并补充清洗流水线设计与调研记录
- 仓库由 govdoc-md-cleaner 更名为 mdpolish,更新 README、AGENTS、CLAUDE
  及 reference 中的仓库名;冻结的 design 与带日期 scratch 保留旧名
- 冻结 0002:可组合清洗组件与流水线(check/transform、单轮修改加最终复查)
- 新增 0003 草稿:第一版可执行核心架构,待评审
- 新增 HTML 表格清洗专题调研(2026-08-21)
2026-08-21 22:49:03 +08:00

121 lines
6.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# mdpolish
实验室共用的 Markdown 清洗研究与基础工具库。项目不属于 GovDoc 专用组件,也不只服务政务文档。
本仓库面向实验室内不同项目复用,用于清洗 PDF、DOCX、OCR、网页等上游管线生成的 Markdown,统一解决
格式噪声、结构损坏、内容异常、修改追踪和多用途派生问题。各项目共享通用清洗能力,再通过独立配置或
profile 表达论文、政务文档、RAG、文档对比等不同需求。
仓库当前仍处于研究和方案设计阶段:用于澄清问题、记录设计选择、积累可复核证据,并在方案获得确认后
再建立实现。它目前不是可安装的 Python 包,也不提供命令行工具或生产接口。
## 当前阶段
2026-08-20 已完成仓库重置与最小文档治理骨架:
- 原有 Python 实现、YAML 规则、测试和打包配置已经移除;
- `AGENTS.md``CLAUDE.md` 提供同步的协作规则;
- `research-wiki/` 按文档生命周期区分设计、说明、参考、指南和草稿;
- `research-wiki/design/0001-repository-foundation.md` 记录本次基础架构选择。
- `research-wiki/reference/GOVDOC_SAAS_CLEANING_SCOPE.md` 保存 45 份外部测试 Markdown 的只读问题审计;
- `research-wiki/scratch/markdown-cleaning-ecosystem-research-2026-08-20.md` 完成首轮生态与架构调研。
- 2026-08-21 完成师姐项目(ClinDB-ReviewBench5 份论文 Markdown 的问题审计
`research-wiki/scratch/data-5papers-cleaning-audit-2026-08-21.md`),并确定其第一版清洗范围
`research-wiki/reference/CLINDB_REVIEWBENCH_CLEANING_SCOPE.md`9 类确定性规则)。
- 2026-08-21 明确本项目定位为实验室共用库;GovDoc 和论文清洗都是使用场景,不是核心边界。
- 2026-08-21 批准并冻结 `research-wiki/design/0002-composable-cleaning-pipeline.md`,确定只接收 Markdown、
项目显式组装组件、单轮修改加最终只读复查的总体组织方式。
- 2026-08-21 建立 `research-wiki/design/0003-first-executable-core-architecture.md` 草稿,等待评审第一版
Python 内存核心、精确修改协议、错误语义和测试边界。
- 2026-08-21 完成 HTML 表格清洗专题调研
`research-wiki/scratch/html-table-cleaning-ecosystem-research-2026-08-21.md`):核实 Pandoc 表格
方言能力边界、Turndown 不处理合并单元格、Docling Markdown 导出重复合并单元格内容、MinerU 全
HTML 输出,印证审计 T001 的分流方向。
- 2026-08-21 仓库由 `govdoc-md-cleaner` 更名为 `mdpolish`,GitHub 远程仓库与本地目录同步改名;
冻结的 design 记录和带日期的 scratch 笔记保留当时的旧名。
当前没有清洗算法、可执行命令、运行依赖、测试套件或函数级输入输出契约。`0002` 只批准了总体组织方式;
调研报告中的解析器、内部 IR、具体 profile 和实施路线仍是候选方案,尚未批准。
目录存在只代表文档落点已经建立,不代表相应能力已经完成。
## 服务对象与复用目标
当前已经明确的使用场景包括:
- **论文清洗**`data/` 中现有内容来自师姐的项目,包含论文 PDF 的 Markdown、JSON、图片等转换产物;
- **GovDoc**:政务、招投标、采购、合同等文档的清洗、比对和 RAG 前处理;
- **未来实验室项目**:后续可以继续接入其他需要 Markdown 质量检查、规范化或用途派生的项目数据。
当前用例只用于发现真实问题和验证通用能力,不能反过来限定库的设计。核心代码不得依赖论文 DOI、
GovDoc 目录、具体客户名称或某一转换器的固定输出路径。
## 面向复用的设计原则
- **通用核心**:只接收 Markdown,提供结构检查、异常检测和可审计变换,不读取 PDF、图片或转换器 JSON;
- **输入边界**PDF/OCR/DOCX/HTML 转换和外部材料核验由使用项目或上游流程负责,不写入共用组件契约;
- **项目 profile**:论文、GovDoc、对比、RAG、公开脱敏等规则独立组合,不互相污染默认行为;
- **保真优先**:不确定内容默认保留或进入人工确认,不能为了格式整齐改写业务或学术内容;
- **可复现**:规则、配置、输入哈希、输出和每次变更都可以追踪;
- **可扩展**:新增项目在自身边界处理上游适配,并主要组合或补充组件和 profile,而不是复制一套清洗器。
## `data/` 的职责
`data/` 是实验室项目的本地数据工作区。当前存放师姐论文清洗项目的输入和转换产物,未来可能继续加入
其他项目的数据。新增数据时应逐步按项目命名空间组织,例如 `data/<project_id>/...`,避免不同项目的
输入、产物和评测结果混在一起。
数据目录与通用库保持以下边界:
- `data/` 已被 Git 忽略,不作为库源码、公开 fixture 或发布包的一部分;
- 默认把项目数据视为只读输入,清洗结果写到独立输出位置,不覆盖原文件;
- 数据可以推动通用规则设计,但项目专属规则必须进入对应 profile;
- 测试需要的公开样例应单独制作脱敏、最小化 fixture,不能直接复制真实项目文档;
- `/home/lihaoze/gov_test_data` 等仓库外真实材料同样保持只读,不复制、不修改、不提交。
任何清洗语义、规则格式、评估指标、代码目录或运行依赖,都应先形成设计记录并获得确认。研究结果进入
具体项目或生产系统前,还需要在使用方范围内独立验证。
## 目录结构
```text
mdpolish/
├── AGENTS.md
├── CLAUDE.md
├── README.md
├── data/ # 本地项目数据;Git 忽略,未来按项目分区
└── research-wiki/
├── README.md
├── design/ # 方案选择与冻结决策
├── explanation/ # 当前有效机制及原因
├── reference/ # 需要准确查询的稳定事实
├── guides/ # 已实际验证的操作步骤
└── scratch/ # 调研笔记和未收敛草稿
```
## 开始工作
进入仓库后依次阅读:
1. 本文件,确认当前阶段;
2. `AGENTS.md``CLAUDE.md`,确认协作与安全边界;
3. `research-wiki/README.md`,确认文档应放在哪里;
4. 与任务直接相关的 `research-wiki/design/` 记录。
下一项实质工作开始前,应评审并批准 `research-wiki/design/0003-first-executable-core-architecture.md`
草稿尚不授权创建源码、测试、依赖或公共接口。
## 当前可用检查
```bash
# 两份 Agent 入口除标题外必须一致;无输出且退出码为 0 表示通过
diff -u <(tail -n +2 AGENTS.md) <(tail -n +2 CLAUDE.md)
# 查看当前 Wiki 中实际存在的文档
find research-wiki -maxdepth 2 -type f | sort
# 检查本地变更
git status --short
```
当前没有测试命令;在真实实现和测试体系获批并落地前,不应声明测试通过。