起因

久在职场，手里都会攒一堆文档。有些文档我叫它"鸡肋"文档：

1、它们可能是复制粘贴出来的，大部分相同、小部分修改，改动不多，但文档内容又不同，并且有大量相同的图片。

2：也可能写文档过程中有重大调整，费半天劲写出来的文档，结果有一部分用不到了，但之后可能还有用。所以这个中间版本也不方便删掉。

3：文档时间久了，不好判断哪个是最终版本，也没时间检查。可是直接删掉吧，害怕万一以后会用。

留之占地，弃之可惜，所以这些文档叫做"鸡肋"文档。

文档这种东西，pptx也好，docx也罢都是图片占体积大。既然Markdown可以引用图片，那一定能设计一款工具：文字、图片分别存放，重复图片只存一份。没有AI，这事也就想想，有了AI可以解决一下。

尽信AI不如无AI，不用AI迟早卖白菜。既然要用AI，就得让它真正帮上忙。

起步，让AI自己来策划

赶上周末有空，先用AI聊了聊我的需求：把文档转成Markdown，图片去重管理，保留文档关联关系，以后还能方便地搜索和引用。

方案出来后，我让AI自己找毛病。果然，AI一开始规划的方案有几个明显问题：数据库设计过于复杂，有些表冗余；错误处理写得不够健壮；界面交互逻辑也有矛盾。

我让AI重新审视方案，重点检查了几个关键问题：

• 图片去重的逻辑是否准确？SHA256 哈希能精确去重，但相似图片怎么识别？
• Markdown 转换怎么保证质量？pandoc 和 markitdown 各有什么优劣？
• 引用关系怎么维护？图片合并后，文档里的引用路径要不要自动更新？
• 数据库损坏了怎么办？有没有容错机制？

经过几轮讨论，方案终于定下来了。

开干，策划文档塞给TRAE WORK。

方案定好，把详细的策划文档塞给TRAE WORK。

太帅了，一次搭建完成，直接可运行

第一次生成时，代码结构清晰，目录组织合理：

DocHashSync/
├── src/
│   ├── core/
│   │   ├── database.py        ## SQLite 数据库管理
│   │   ├── hash_manager.py    ## SHA256 和 pHash 哈希计算
│   │   ├── converter_base.py  ## 转换引擎适配器
│   │   ├── pandoc_converter.py ## pandoc 转换引擎
│   │   ├── markitdown_converter.py ## markitdown 转换引擎
│   │   └── image_extractor.py ## 图片提取与引用替换
│   ├── services/
│   │   ├── config_service.py  ## 配置管理
│   │   ├── document_service.py ## 文档管理
│   │   ├── convert_service.py ## 转换调度（核心）
│   │   ├── asset_service.py   ## 资源管理
│   │   ├── sync_service.py    ## 一致性校验
│   │   └── merge_service.py   ## 相似图片合并
│   ├── gui/
│   │   ├── main_window.py     ## 主窗口
│   │   ├── document_page.py   ## 文档管理页面
│   │   ├── asset_page.py      ## 资源库页面
│   │   ├── sync_page.py       ## 一致性校验页面
│   │   └── merge_page.py      ## 相似图片页面
│   ├── common/
│   │   ├── logger.py          ## 日志系统
│   │   ├── config_manager.py  ## 配置文件管理
│   │   ├── common_utils.py    ## 通用工具函数
│   │   └── common_dataclass.py ## 数据类定义
│   └── main.py                ## 程序入口
└── config.ini                 ## 配置文件

编译运行，界面出来了，四个标签页：文档管理、公共资源库、一致性校验、相似图片。看起来已经像那么回事了。

修修补补，必不可少

 首次用markitdown确实挺丝滑的，一次成功，但转换效果比pandoc要差一点，引入pandoc问题就来了。

转换开始跑起来了，但没跑多久就停了。一个36MB的文档，里面有127张图片，跑到一半就没反应了。

查日志，发现是在 pandoc 转换 PPTX 文件时卡住了。AI最初没有区分文件类型，pandoc 对 PPTX 的支持本来就差，还硬要跑，结果就卡死了。

修正逻辑：PPTX 文件跳过 pandoc，直接走 markitdown；DOCX 文件双引擎对比，图片多的那个胜出；其他格式走单引擎。

if source_type == 'pptx':
    # PPTX 跳过 pandoc，直接走 markitdown
    mi_converter = MarkItDownConverter(self.logger)
    mi_result = mi_converter.convert(source_path)
elif source_type == 'docx':
    # DOCX: 双引擎对比择优
    ...

改完之后，转换速度明显快了。PPTX 不再拖后腿。

工具最终形态

一天下来，一个完整的文档收集器跑起来了。四个标签页，各司其职：

核心流程：

1. 输入文件夹 → 递归扫描所有文档（支持 DOCX/PPTX/PDF）
2. 计算源文件 SHA256，查重判断
3. 调用转换引擎（pandoc/markitdown）转为 Markdown
4. 提取 Markdown 中的 base64 图片，存入公共资源目录
5. 计算图片哈希，查重，已存在则复用
6. 替换 Markdown 中的引用为公共资源相对路径
7. 保存 Markdown 文件，写入数据库记录

图片去重效果：

假设一个文件夹里有 10 个文档，每个文档都引用了同一个公司 logo。转换前，这 10 个文档各自存了一份 logo，总共 10 份。转换后，公共资源目录只存一份 logo，10 个 Markdown 文件都引用同一张图片。如果这 10 个 logo 都是 50KB，那原本占用 500KB，现在只占 50KB，节省了 90% 的存储空间。

相似图片检测：

用感知哈希（pHash）识别内容相近的图片。比如同一张截图，经过轻微裁剪、压缩或调色后，SHA256 不同，但 pHash 距离很小。系统会把它们识别为一组，用户可以手动选择保留哪一张，其余的合并到保留的那张上。

写在最后

一天，没写一行代码（严格说是让AI写的），一个完整的“鸡肋”文档收集器就跑起来了。虽然还有些小问题需要修修补补，但核心功能都已经到位了。

图片去重后，存储空间节省巨大；转成 Markdown 后，AI 也能直接读取和推理，不再受限于 Office 格式。

超出预期的是相似图片合并，竟然也完成了。