理柴德波浪技术过去这段时间，我一直在做一件挺零碎的事：把散落在各个目录里的文件集中提取成统一格式，该解压的解压，该抓取元数据的抓取元数据，最后整理成一份清单给人用。文件提取这种事看着不复杂，但一旦文件量上千，人工一个个打开看，就是一种精神折磨。后来我换了个思路，让 AI 辅助开发工具来干，前后做了好几个迭代版本，最终沉淀成一个比较稳定的小脚本族。今天把整个过程拆开讲讲，包括我怎么提需求、让 AI 选型、踩过哪些文件处理相关的坑，以及这套工具现在是怎么日常工作的。
先说清楚，这篇文章适合谁。如果你不是专业程序员，但对电脑文件处理比较头疼，想用 AI 辅助写点小工具节省重复劳动，这篇文章能给你一个能落地的参考。如果你本身就是开发，想了解 AI 辅助开发过程中哪些地方容易出问题，我踩过的一些坑应该也能帮到你。我讲的不是那种特别炫的算法，而是真正天天在用的文件提取工具，以及它背后承载的一套工程思路。
1. 做之前先想清楚：文件提取工具的边界在哪里
1.1 我的清理场景究竟是哪种
我手头遇到的典型场景，是你电脑里或工作盘里最常见的那类“内容垃圾场”。比如一个共享目录，里面堆着 PDF、Word、Excel、压缩包、图片，而且文件名乱七八糟，有的叫“最终版”，有的叫“新建文档(1)(1)(1)”，根本看不出内容。如果只是偶尔找一两个文件，问题不大，最怕的是需要一口气知道整个目录里有哪些文件、每个文件大致是什么内容、哪个文件夹占的存储最多、哪些文件明显重复或损坏。
我最初的提取需求，就是把一堆“不知道装着什么的文件”变成一张表格。表格里明确列出：文件的完整路径、扩展名、大小、最后修改时间，以及对于能解析正文的文件，尽量提取一段文本摘要或关键属性。如果是压缩包，提取内部文件清单并解压到指定目录。这个目标一旦清晰，后面让 AI 写代码就少了很多来回扯皮。
所以“文件提取工具”这个名字听起来宽泛，实际落到需求层，必须拆成两个能力：一个是从文档中提取“文本、元数据”，另一个是从容器类文件中提取“里面的文件”。前者用于了解内容，后者用于真正把文件拿出来。AI 能帮上大忙的前提，是你先知道自己到底需要哪一种，而不是让它替你做产品经理。
1.2 为什么要选 AI 辅助而不是直接买现成软件
市面上有很多企业级文件搜索、文档解析工具，尤其像 PDF 批量处理软件，功能动不动就几百块一年。但对我这种场景，问题不是“文件搜索能力不足”，而是“需要围绕自己的目录结构和命名规则定制一套处理流程”。现成软件不会理解你公司内部的归档习惯，也不会主动把结果输出成你 Excel 模板需要的格式。
自己从零写，对很多人来说又有门槛。这就是 AI 辅助开发的甜区：需求足够具体，不追求大而全，只求在特定目录结构上跑得快、结果可控。AI 可以在一两分钟内生成第一版脚本，然后我再根据自己的需求做增量修改。相比以前从网上翻博客拼代码，效率高很多。而且我还不用担心不懂某些库的用法，只要把任务描述清楚，AI 就能告诉我哪些库合适，并直接给出示例代码。
1.3 第一版工具的边界设定
为了避免项目无限扩张，我在动手前给“第一版”划定了几个硬边界：
- 只处理本机目录，不做网络磁盘的实时监控。
- 先支持常见办公文档：PDF、Word(docx)、Excel(xlsx)、纯文本。
- 压缩包先支持 zip，其他格式以后再说。
- 只提取文本摘要和基础属性，不调 OCR，不搞向量化。
- 所有输出统一为 UTF-8 编码的 CSV 文件，方便别人用 Excel 打开。
这几条看起来简单，实际特别重要。因为没有边界的话，AI 很容易往里面加 OCR、图片识别、数据库存储、 Web 界面这些功能，导致代码量膨胀，调试成本直线上升。我能用两三个小时就完成一个能用的版本，核心就是在需求描述里不断告诉 AI：这个阶段只做到什么程度，不许“顺手”加额外功能。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术底座选对了，AI 生成代码才不会跑偏
2.1 选 Python 的原因：不是跟风，而是文件处理库实在太全
第一版工具我用的是 Python 3.10。不是因为 Python 比别的语言更“智能”，而是文件处理生态太完善，AI 对 Python 标准库和第三方库的训练语料也足够多。用一个冷门语言让 AI 生成代码，出错概率明显高很多，尤其是一些编码细节，AI 很容易一本正经地胡诌。Python 里处理文件普遍用到的几个库，已经是社区沉淀十几年、被反复验证过的方案：
bash复制# 或者直接写进 requirements.txt
pypdf==4.2.0
python-docx==1.1.0
openpyxl==3.1.2
这几个库负责不同的文件类型，相互没有冲突。AI 在生成代码时会优先推荐它们，而不是某些冷门库，这本身就是一种“集体经验”的体现。为什么不用 PyPDF2？我的体会是 PyPDF2 维护节奏不稳定，很多老代码解析某些加密 PDF 时会遇到奇怪的报错，而 pypdf 是 PyPDF2 的持续维护分支，API 兼容性也做得比较平滑。反正有 AI 帮忙，切换起来并不费劲。
2.2 让 AI 在编码前先给技术选型方案
很多人在让 AI 写代码时，习惯直接说“帮我写个文件提取脚本”，这样得到的通常是通用模板，用的库可能是 AI 随机猜测的，无法匹配真实环境。我的做法是先不让它写代码，而是让它先给一张技术选型表。
我第一轮提问大概是这样的：
text复制我需要写一个 Python 命令行工具，用来递归读取