Files

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

6.9 KiB

Raw Blame History

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-ReviewBench）5 份论文 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 等仓库外真实材料同样保持只读，不复制、不修改、不提交。

任何清洗语义、规则格式、评估指标、代码目录或运行依赖，都应先形成设计记录并获得确认。研究结果进入具体项目或生产系统前，还需要在使用方范围内独立验证。

目录结构

mdpolish/
├── AGENTS.md
├── CLAUDE.md
├── README.md
├── data/                   # 本地项目数据；Git 忽略，未来按项目分区
└── research-wiki/
    ├── README.md
    ├── design/       # 方案选择与冻结决策
    ├── explanation/  # 当前有效机制及原因
    ├── reference/    # 需要准确查询的稳定事实
    ├── guides/       # 已实际验证的操作步骤
    └── scratch/      # 调研笔记和未收敛草稿

开始工作

进入仓库后依次阅读：

本文件，确认当前阶段；
AGENTS.md 或 CLAUDE.md，确认协作与安全边界；
research-wiki/README.md，确认文档应放在哪里；
与任务直接相关的 research-wiki/design/ 记录。

下一项实质工作开始前，应评审并批准 research-wiki/design/0003-first-executable-core-architecture.md；草稿尚不授权创建源码、测试、依赖或公共接口。

当前可用检查

# 两份 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

当前没有测试命令；在真实实现和测试体系获批并落地前，不应声明测试通过。

6.9 KiB Raw Blame History Unescape Escape