1. 开篇从零到一我用AI打磨了一把“文件捉虫手”做运维和开发这些年我电脑里最不缺的就是各种散落的文件——下载目录里堆满几个月没动的压缩包临时目录里躺着命名成“新建文档(3)(最终版).docx”的文档甚至有些从论坛扒下来的资料是根本没有后缀名的裸文件。每次想清理光是手动改后缀名、解压嵌套压缩包、批量重命名这几件事就够我喝一壶。所以当我把“AI辅助开发小工具”这个系列提上日程时第一个想解决的就是文件提取这个高频痛点。这篇文章想分享的就是我如何用AI辅助从零开始做出一款能批量提取文件内容、智能识别文件类型、自动解压嵌套压缩包、甚至能读二维码和条形码的“文件提取工具”。它不是那种大而全的商业软件而是一个正好够用、却能帮我省掉大量重复操作的个人效率工具。如果你也想试试用AI当编程外挂但不知道从哪下手或者正在为“AI写的代码我不敢用”这件事发愁那这篇内容应该能给你不少实际参考。简单说说我能从AI辅助开发这件事里得到什么写代码只是其中一小部分更重要的是让AI帮我把需求拆清楚、把边界列明白、把异常情况补全甚至帮我把打包发布的流程都理顺。这套思路完全可以复用到任何一个小工具的开发上文件提取只是一个非常好的切入点因为它的逻辑足够直观——把一个文件变成你能用的内容。2. 为什么选“文件提取”当AI辅助开发的试水项目2.1 需求来源我到底想从文件里提取什么动手之前我先把自己日常最烦的几类“文件处理”场景列了个清单。第一类是压缩包里的内容要高频取出可能是周报附件、项目交付包或者客户发来的素材包它们往往还是多层嵌套的zip套rar、rar套7z每次解压都像剥洋葱。第二类是文件类型识别和内容抽取比如从一堆无后缀名的文件里识别出哪个是PDF、哪个是Word或者把一张图片上的文字快速提取出来。第三类是更“土”的诉求比如想批量把一批txt文档里的邮箱、电话、URL提取出来或者从几百张截图里批量读出二维码里的信息。这些需求听起来不大但真做起来每一样都有不少细节。比如压缩包解压要考虑中文文件名乱码、内存占用过大、压缩炸弹zip bomb保护PDF提取要分文本型PDF和扫描件PDF扫描件就得走OCR二维码识别要考虑光线不好时怎么处理。如果是以前我可能需要分别搜集几个工具、写一堆脚本才能搞定但现在我把它统一成一个“能跑起来的工具”就是AI辅助开发最好的练手项目。2.2 为什么AI适合做这个小工具我是这么做判断的文件提取工具的核心逻辑相对独立不依赖复杂业务系统不需要对接数据库没有太多状态同步问题非常适合用Python这种胶水语言快速实现。而AI大模型特别擅长把自然语言拆成函数和模块它见过海量的开源代码对“解压”“正则匹配”“OCR”这些常见操作的实现套路非常熟悉。我只要把需求描述得足够清楚它就能给出一个能用的骨架我再根据实际场景去调整。另外很重要的一点是这种小工具的错误处理需要大量经验兜底。你可能不知道AI写出来的“正常路径”代码往往比人还顺滑但只要一进真实环境就会翻车——中文文件名编码错误、临时文件没清理、路径里有空格、系统没有安装中文字体导致OCR结果乱码……这些东西我在开发过程中全都踩过。AI的作用是帮我减少“常规代码”的编写时间让我把精力集中在那些“只有实际跑过才知道”的坑位上。2.3 项目的大致范围和技术选型既然是系列文章之一我先把“文件提取工具”定义清楚。它至少包含几个核心模块支持常见压缩包格式zip、rar、7z、tar.gz的批量解压与递归处理支持文本类文件内容的批量抽取txt、md、log、csv等支持PDF、DOCX、XLSX等办公文档的文字抽取支持图片的OCR文字识别支持二维码/条形码内容识别顺便再做一个按规则批量提取信息手机号、邮箱、URL等的小功能。技术选型上我最终选用了Python原因很简单生态全面像PyInstaller能把脚本打成单文件exe方便在我那台没装Python的旧电脑上直接用像pytesseract做OCR、pyzbar做二维码识别都有成熟的轮子。这里有个经验是AI辅助开发时不要盲目追求最新或者最强功能而要选那些AI见过最多样例的常规组合因为模型见过的代码越多生成的质量越稳。3. 需求拆解和AI对话前我先把边界划好3.1 不要把“能做什么”交给AI替你做决定很多人在让AI写代码时习惯直接扔一句“帮我写一个文件提取工具”然后AI就给你喷出一大坨代码——功能倒是不少但多半不是你想要的那个。我的习惯是在和AI对话之前先自己把“哪些必须做、哪些坚决不做、哪些是同义词但别搞混”都列清楚。比如压缩包解压时我明确告诉AI不递归解压超过两层提取文本时明确要求每类文件走独立处理器而不是用通用方案而二维码识别时明确限制图片最长边超过4096像素要先缩放防止内存炸掉。这种“先定边界再写代码”的做法其实在AI辅助开发里极其重要。AI本质上是一个“概率续写器”你给它越明确的边界它越不容易自由发挥成一锅粥。边界清单不用特别长但每条都要是“验收标准”比如“必须是递归解压但遇到同名文件要自动重命名而不是覆盖”“OCR识别失败时要保存原图路径到失败日志里”。这些要求写清楚后面能省掉大量调bug的时间。3.2 用三个“伪场景”来确认核心流程接下来我会用三个虚构但足够真实的使用场景来约束整个工具的功能走向。第一个场景是“下班前收到一个项目交付包”这个操作的目标是快速把压缩包里的文件全部解压并按原目录结构放好同时能识别出里面有没有插图、表格、PDF文档输出一个简略的文件清单报告。第二个场景是“从一个混乱的文件夹中提取所有联系方式”比如一堆txt、doc、图片混在一起但要快速把所有手机号、邮箱汇总到一张表里。第三个场景是“从一堆截图里批量收集二维码跳转地址”这个更偏采集类需要把每个二维码对应的文本内容按图片名存入结果文件。这三个场景覆盖了“结构处理、内容抽取、图像识别”三条主线定义的足够清楚之后我直接把这三个场景的描述发给AI让它先给我画一个模块划分方案。它给的方案通常比我预先想的结构还要细一点比如建议把“文件类型识别”单独拆成一层把“提取器”注册成插件模式。我不用全盘照收但它的提议能帮我补盲区。3.3 让AI先生成“验收清单”再写代码这里有个非常实用的小技巧先不要急着让AI写实现代码而是先让它生成一份“这个工具应该满足的验收清单”。我会给它描述具体的场景和限制让它列出至少20项验收标准包括“支持zip/rar/7z/tar.gz格式”“能处理超过4GB的tar.gz文件”“中文文件名不乱码”“遇到无法解析的文件不中断整个流程”“最终产出一个报告文件”。这份清单出来之后我再从头到尾读一遍把不合理的删掉、缺的补上最终这份被我们双方确认过的清单就是整个开发的“合同”。实际上这步操作花不了多少时间却能显著提高产出的质量。因为AI在生成清单时其实是在做“需求建模”它的思维链条会让后续的代码生成更聚焦。而如果你一开始就让AI直接生成代码它往往会基于猜测去设计后面你就要一版一版地改提示词反而更累。4. 核心功能的技术设计与实现细节4.1 我用了什么样的Python技术栈和依赖库我去掉了那些“听起来很酷但实际用不上”的库最终选定的依赖并不多。压缩包处理方面用的是zipfile、rarfile和py7zrzipfile是Python自带的处理zip最稳rarfile需要后台有unrar支持macOS和Linux装起来方便Windows下得装WinRARpy7zr纯Python实现对7z的兼容性不错。文本抽取上pdf用pdfplumberdocx用python-docxxlsx用openpyxl这几个库在AI训练语料里出现频率高、API稳定生成的代码基本不会跑偏。图像识别和条码这块OCR用的是pytesseract它的本质是包装了Google的Tesseract OCR engine识别中文需要额外安装chi_sim语言包二维码和条形码用的pyzbar它对QR、Code 128、EAN-13这类常见格式都支持。最后一个重要依赖是PyQt5。打包成带界面的工具时我选了PyQt5虽然它比较老牌但AI对它的认知非常深生成界面代码的速度和质量都比用一些新框架要好。做桌面工具界面不用多花哨能选目录、看进度条、输出日志就够了。4.2 提取框架的核心思路注册器模式整个工具的骨架我设计成“注册器模式”。简单说有一个ExtractorRegistry每种文件类型对应一个提取器类注册进去之后主流程只需要查表调用。这样扩展起来极其方便以后想加一个新格式只需新写一个类并注册不用改动主流程。具体来说我定义了这样一个基类方法class BaseExtractor: def __init__(self, config): self.config config def extract(self, file_path, output_dir): raise NotImplementedError然后每种文件类型写一个子类。比如PdfExtractor负责从PDF里抽文本和图片DocxExtractor负责Word文档ImageExtractor负责图片文字和条码识别。注册器里维护一个ext_map字典键是文件后缀名值是相应的提取器实例。这里有个坑AI一开始生成的注册器用的是“后缀名直接匹配”但如果某个文件没有后缀名怎么办后来我给注册器加了一个sniff_type(file_path)函数通过读取文件头部的魔数magic number来判断真实类型。比如PDF文件头部通常是%PDFPNG图片头部是\x89PNG\r\n\x1a\nZIP文件头部是PK\x03\x04。这层指纹识别面对“无后缀名文件”时非常能打。4.3 递归解压与防嵌套陷阱的实现文件提取工具最容易被人忽略的是“无限嵌套解压”。假如有个压缩包里放了一个压缩包再放一个压缩包如果你的代码是简单递归那它可能会一直解压到磁盘满了为止。我一开始就让AI实现了一个深度上限参数max_depth默认是3层。每层解压前先检查当前深度超过就直接跳过并在日志里记录。另一个致命问题是“压缩炸弹”。zIP里有一种恶意玩法一个很小的压缩包解压出来能有几百GB。我通过在解压前先读取压缩包里的文件信息、预估解压后总大小来防御如果估算值超过设定阈值默认5GB则直接拒绝解压并给出提示。这个逻辑对人手写的脚本来说很容易漏但对AI来说只要你在提示词里明确提到“要防zip bomb”它一般都会给你写出预检查的代码片段。def safe_extract(zip_ref, dest_path, max_size5 * 1024 * 1024 * 1024): total_uncompressed sum(info.file_size for info in zip_ref.infolist()) if total_uncompressed max_size: raise RuntimeError(f解压后预估大小 {total_uncompressed / (1024**3):.2f} GB 超过限制) zip_ref.extractall(dest_path)这里得提醒一句extractall本身在对付中文文件名时可能有编码问题。zipfile模块默认用cp437处理非UTF-8文件名遇到中文很容易乱码。我查了不少资料最终采用了一个修复方案读取时用zip_ref.infolist()遍历如果flag_bits 0x800为真说明是UTF-8编码否则先用cp437解码再用gbk重新编码。这段代码看着不复杂但如果你不提前告诉AI去处理你会在真实解压时被乱码文件整到崩溃。4.4 OCR图像文字提取的几处关键细节OCR这一块很多教程只会告诉你“pip install pytesseract”但实际用起来要处理三件事。第一是设置语言参数识别中文要用langchi_simeng这里有个小细节两个语言包用“”号连接识别时会同时启用两种语言模型。第二是图片预处理Tesseract对清晰度非常敏感我用了OpenCV做灰度化、二值化和降噪尤其是把彩色图片转成灰度再二值化识别率能提升好几个档次。第三是设置环境变量和tesseract_cmd路径Windows下如果你没把Tesseract安装目录加入PATH或者没在代码里显式指定路径它直接报错。还有一个小技巧是分块识别。如果一张图片是A4纸扫描出来的长文直接整张丢给Tesseract不仅慢而且错误率高。我的做法是先检测图片尺寸如果宽度超过2000像素就按水平方向切分成多个重叠的子图然后分别识别再拼接文本。这个“重叠”很重要避免文字正好被切断导致漏字。AI对这块的编码思路其实就是“贪心分割”你要做的就是在提示词里加一句“避免在文本行中间切割”。4.5 编码识别文本提取的隐形杀手读取txt或者日志文件时最恼火的问题是编码。Windows下常见的gbk、macOS和Linux常见的utf-8还有一些老文件可能是gb18030。如果你用固定的utf-8去读大概率会得到一堆乱码。这里我引入了chardet库来自动检测编码但纯靠它也有翻车的时候。更稳的思路是“尝试多个编码逐一解码”先尝试utf-8如果抛异常再尝试gbk再尝试gb18030最后用latin1兜底latin1解码永远不会报错因为它映射了256个字节的全部取值。这一步看着简单但它直接影响后续所有内容抽取的质量。我在真实使用中有一个体会用AI辅助开发时如果你没想到编码问题AI是大概率也不会主动处理的因为它在训练语料里最常见的代码模式就是open(file, r, encodingutf-8)。所以在提示词里一定要专门加一条“处理文本文件时必须自动检测编码并兼容中文常见编码”。4.6 二维码识别与批量采集的边界问题二维码识别在工具里的作用是“从截图里批量提取链接或文本”。这个功能的实现依赖pyzbar它能检测出图像中的二维码并解码。但在真实场景中截图可能是手机拍的、有透视畸变的直接识别成功率不高。我后来给这个模块加了一个预处理函数先做灰度化再用cv2.adaptiveThreshold做自适应阈值二值化然后把图像临时resize到几档不同分辨率都去试一遍能显著提升识别率。不过这里有个边界如果图片上二维码太小再怎么预处理也难救。所以在界面上我加了一个选项“图片过大时自动分割为九宫格分别识别”这样如果用户截图里包含多个二维码至少不会漏掉边角的那个。另外一个有意思的点是pyzbar对二维码和条形码的识别结果格式不太一样二维码的data通常是字符串条形码的data可能还有bytes所以我在封装时统一做了decode和strip处理。4.7 目录遍历和文件类型识别的“快与慢”整个工具的入口是对用户选择的一个根目录做递归遍历。这里我最开始用的是Python自带的os.walk代码很简洁但应对几十万文件时速度一般。后来优化成了os.scandir少一次stat调用速度提升明显。还有一个细节如果目录里有符号链接很容易产生循环引用我在遍历时加了一个参数followlinksFalse默认不跟随链接目录。文件类型识别是另一个性能瓶颈。如果用python-magic库去调用libmagic识别结果最准但每次打开文件都要读头耗时会增加不少。而如果只靠后缀名匹配又会被“无后缀名”文件打脸。我的折中方案是先看后缀名如果后缀名在常见类型集合里就直接用如果未知或者缺失再用magic.from_file去探测真实类型。这两级策略在绝大多数场景下既快又稳。5. 实操过程从AI对话框到能跑的桌面工具5.1 我的AI对话模板如何把需求“喂”给模型在实际写代码之前我会在AI对话框中输入一个结构化的“开发任务书”。这里分享一个我自己写提示词的模板不一定最好但非常稳定先是一句总目标然后分“输入场景”“功能要求”“技术约束”“负面清单”四段来细化。比如我当时的第一个提示词大概是这样请你作为资深Python工程师帮我开发一个文件提取工具。输入是一个文件夹路径输出是提取结果目录和一份报告。 功能要求 1. 支持递归遍历文件夹识别所有文件类型。 2. 支持zip、rar、7z、tar.gz等常见压缩格式的解压解压时要处理中文文件名乱码且设置解压深度上限为3层。 3. 支持PDF、Word、Excel、TXT、Markdown等文档中文字的提取统一输出为纯文本。 4. 支持图片中的中文文字OCR识别要求先预处理再识别。 5. 支持二维码和条形码的识别。 6. 所有结果写入一个汇总的TXT或CSV报告。 技术约束 1. 使用Python 3.10。 2. 使用pdfplumber、python-docx、pytesseract、pyzbar、py7zr等库。 3. 程序入口是命令行main.py --input 路径 --output 路径。 4. 重要必须处理中文文件名、编码问题、以及解压炸弹。 负面清单 1. 不要使用在线API做识别所有功能需要本地完成。 2. 不要使用Docker打包程序需要单机直接运行。这样一个提示词扔进去AI第一次就能生成一个可运行的骨架。而且因为它见多了这种结构生成的代码基本一眼能看懂、能跑通。5.2 从命令行工具升级成带界面的桌面程序命令行工具其实已经能用了但对非程序员朋友或者日常快速操作来说图形界面会更合适。我选择用PyQt5做GUI。这里最省力的做法是再开一个AI对话给它描述界面布局上面是输入目录选择框和输出目录选择框中间是一个“开始提取”的按钮和进度条下方是一个日志输出区。AI会生成一个main_window.py我再把它和之前的处理器模块对接。对接过程中有个比较麻烦的事压缩包解压和OCR识别都是耗时操作如果在GUI主线程里直接跑界面会卡死。所以我把核心功能封装成QThread子线程通过信号量发送进度和日志消息。这部分如果你不跟AI特别说明它默认写的还是同步代码界面一跑就无响应。在提示词里加一条“耗时操作必须在QThread中执行并通过pyqtSignal更新UI”出来的代码就会专业不少。对话过程中的一个经验是让AI生成完GUI代码后先不要急着接后端而是先跑一个最简单的“点击按钮打印hello world”来验证UI框架能启动。等确认界面没问题了再逐步把提取逻辑接进来这样定位问题时可以清晰地判断是界面问题还是后端问题。5.3 打包发布用PyInstaller把工具变成exe打包这块要是没经验会踩到不少坑。我最终选择的方案是PyInstaller命令大概长这样pyinstaller -F -w --name FileExtractor main.py-F表示打成一个单文件-w表示不显示控制台窗口。但PyInstaller有个老问题它默认做的静态分析经常会漏掉一些动态导入的库特别是pytesseract这种通过命令行调用外部程序的库、以及有数据文件的pdfplumber和pyzbar。我开始打包后生成的exe一运行就报“找不到Tesseract”排查半天发现tesseract.exe根本没被塞进去。解决办法是给PyInstaller加一个--add-data参数或者写一个.spec文件手动把Tesseract的路径和语言包路径加进打包目录。另一个坑是pyzbar在Windows上依赖libzbar-0.dllPyInstaller也不一定自动帮你带。最后我是从系统PATH里找到这个dll拷贝到项目目录然后在spec文件里指定binaries。那次打包折腾了我将近一个下午。但现在回头看这些“和AI对话很难问出来的坑”恰恰就是小工具开发最值钱的经验自己踩过了以后就不会再犯。5.4 给工具加一个“好用的壳”日志、缓存和中断恢复随着功能越来越多我逐渐给工具加了一些“非核心但极影响体验”的壳。比如日志系统每个文件处理成功或失败都要写一条结构化日志包括时间戳、文件路径、耗时、错误信息。这样处理几万份文件时你可以通过日志快速定位是哪个文件出了问题。又比如提取结果缓存在提取图片文字时如果图片没变化但程序重复跑了可以用文件的mtime和size做一个简单的摘要值作为缓存键避免重复OCR。还有一个我尤其满意的功能“中断恢复”。因为批量OCR几十张图片可能会跑很久如果跑到一半断电或者手动停了重新开始就得从头再来。我给工具加了一个“已处理文件清单”机制程序启动时先加载历史记录处理文件之前先检查它是否在历史记录里如果在就直接跳过。这个机制用Redis或者数据库当然也能做但小工具用本地的JSON文件就足够了几万条记录完全没压力。6. 常见问题排查与避坑经验6.1 AI生成代码最常见的五类“水土不服”AI生成的代码思路一般是好的但“水土不服”的问题非常多。第一类问题是版本兼容性比如AI默认生成的Python语法用了pathlib.Path.unlink(missing_okTrue)但你本机Python版本如果是3.7就会直接报TypeError。解决办法很简单提示词里明确写“代码必须兼容Python 3.8及以上”或者干脆用语法检查器扫一遍。第二类问题是依赖库版本不一致AI可能用了A库新版的API但你装了老版本。这种问题可以通过requirements.txt里把关键库的版本范围写死来规避。第三类问题是路径处理不严谨比如AI生成拼接路径时用本地字符串拼接而不是os.path.join在Windows下就会出乱子。我在提示词里明确要求“所有路径操作必须用pathlib或os.path.join”。第四类问题是外部程序路径依赖比如Tesseract和unrar没有装到系统PATH里程序就崩了。所以我的代码里专门留了一个函数setup_external_tools()在程序启动时检测这些外部依赖并给出人性化的提示。第五类问题是内存占用失控AI的循环里可能在高频读文件时没有及时释放资源批量处理几万个小文件时内存飙升我后来给文件对象统一用了上下文管理器with open(...) as f:来确保及时释放。6.2 压缩包处理三大坑乱码、覆盖、超大文件中文文件名乱码的问题前面提过这里再补充一个细节rarfile库读取中文文件名时也经常乱码。它的根本原因是压缩包的注释头里的编码不是统一的7z格式反而好一点因为py7zr默认按UTF-8处理。解决的通用办法是解压后跑一个“重命名修复”函数遍历解压出来的文件如果发现文件名里包含â、æ’这类莫名字符就尝试用gbk重新解码匹配成功就重命名。覆盖问题则是这么解决的解压时如果同一层目录里有重名文件AI默认会直接覆盖导致数据丢失。我在解压函数里加了一个规则目标路径若已存在则在文件名后加_1、_2这样的序号而不是覆盖。这个逻辑对用户体验的提升非常明显尤其当压缩包里有多个版本的文件时。超大文件压缩包超过4GB也是一个坎。Python的zipfile在解压超过2GB的文件时有时会因为内部使用的offset字段导致问题最好是在处理前用seek方式分块读取并写入磁盘。此外py7zr在处理大文件时也有内存占用问题解决方法是设置extract_into_dir而不是把所有内容load进内存。6.3 OCR识别的准确率优化实践分享OCR准确率不是一锤子买卖它和图片本身的清晰度、背景复杂度、语言文字类型息息相关。我跑了上百张真实截图后总结出几条实用经验一是文字颜色和背景对比度太低时先做直方图均衡化或者对比度拉伸二是图片里有水印或阴影时用cv2.createCLAHE做局部自适应增强效果很显著三是如果图片有倾斜角度用cv2.minAreaRect检测文本行的倾斜角再做仿射变换识别率能提升一大截。不过也得说句实话无论怎么优化Tesseract对拍照模糊、复杂背景、艺术字这些场景的能力是有上限的。如果遇到那种识别率还不足七成的图片我通常会退一步先把能识别的部分提取出来把低置信度的部分单独存成一张“待人工核对”的图片夹。实用主义一点小工具不一定非得做到100%准确能把80%的重复劳动干掉就已经值得了。6.4 二维码批量识别的误报与漏报二维码识别经常出现的问题是“误报”——把图片里的某些纹理结构误认为二维码。zbar库给的返回结果里面除了data还有type和rect但无法直接告诉你置信度。我的处理办法是对识别结果里的data做一次合法性校验如果是URL必须符合基本的URL格式如果是纯数字可能是一个条形码如果是字符串且包含明显乱码很可能是误报直接跳过并记录下来。校验逻辑不复杂但能显著降低“识别出一堆垃圾信息”的挫败感。漏报的问题更多来自图片过小或二维码被遮挡。除了前面说的“多尺度识别”外另一个容易被忽视的点是二维码的颜色翻转——有些二维码印在白底黑纹有些是黑底白纹Tesseract和zbar默认期望都是前者。我突然想到一个曲线救国的办法把一个图同时用原图、反色图各跑一遍识别两个的识别结果做一个合并去重漏报率能下降不少。6.5 一个很好用但常常被忽略的辅助目录结构预览给工具加“目录结构预览”这个功能的灵感来自我用AI对话时的一次“灵感碰撞”。当时我只是想让程序在开始提取之前先输出一个待处理文件清单这样用户可以确认是不是选错了目录。结果AI主动提议加一个简单的树状预览面板用QTreeWidget展示扫描出来的文件层级并且每个文件旁边标注类型图标。我试了下发现非常好用因为它让你在处理前就能看到整体规模避免在几万个文件的目录上误操作。6.6 性能瓶颈排查记录一次上万文件提取的实测复盘有一次我拿一个含接近一万个文件的项目交付包做实测整个流程跑下来花了大概20分钟。耗时分布让我很意外OCR识别只占了三成反而是“文件遍历类型探测读取文本”占了近一半。后来我通过cProfile定位到两个主要瓶颈第一个是每个文件都用magic.from_file去探测类型代价太高我把策略改成“先用后缀名白名单匹配再用magic去探测”速度立刻提升几倍第二个是大量小文件时反复开关文件句柄我在遍历时用了批量缓冲每处理100个文件才flush一次日志也减少了很多IO开销。这里也给将来想优化这类工具的人一个建议不要迷信刷算法先用profiler测一测看时间到底花在哪百分之八十的优化空间都在“减少了不必要的操作”上。7. 心得总结与扩展方向7.1 用AI辅助开发的三个层次我自己的体会是用AI辅助开发小工具大致有三个层次。第一层是把AI当成“搜索引擎”遇到不会的函数或语法直接问它适合完全没基础的入门者。第二层是让AI生成完整模块你负责把模块组装和调bug这要求你懂一点程序设计但不用到专家水平。第三层是让AI参与到需求拆解和方案评审里来你把边界、负面清单、验收标准抛给它它给你输出一套完整的模块划分和实现计划然后你再结合自己的经验做增减、写核心部分。我这份文件提取工具做到后来其实已经到了第二层和第三层之间的状态——很多“边缘情况”我根本没想到是AI提醒我要考虑的。7.2 踩过最值得说的一次坑提示词里漏掉“加密压缩包”开发过程中让我印象最深的坑是用户反馈说“解压带密码的压缩包时提示错误”。后来一查我确实完全没考虑过加密压缩包这种场景。zipfile模块支持读取加密文件但必须提供密码否则无法提取。我就给程序加了一个选项“是否尝试常见密码字典”如果选中就会尝试一组很常见的密码比如123456、password、virus解压失败就跳到下一个。这个功能不复杂但恰恰说明“需求边界”永远不可能一开始就完美真实使用场景会不断教你做人。7.3 小工具后续能往哪些方向扩展目前这个工具大概能覆盖我80%的文件提取需求但后续还能做的方向其实很多。比如加上“格式转换”能力把Word批量转PDF、把PDF批量转图片也可以加上“自动归档”能力根据提取出来的内容自动按日期、类型、关键词把文件归入不同目录更进阶一点可以接入大模型做摘要提取比如把一堆PDF文档的标题和简介自动汇总成一份可以导入Notion的表格。这几年AI能力发展很快工具类软件的想象空间比过去大很多唯一限制你的可能就是愿不愿意花时间把一个个小需求磨成能跑的代码。最后分享一个我做小而实用工具的心得别总想着做一个“全功能大平台”抓准一两个高频痛点把它们打磨得足够顺手这比堆功能重要得多。文件提取工具就是一个很好的例子它的核心场景就那几个但每个场景都被我亲自跑过、踩过坑、优化过用起来的顺手感是任何“大而全”软件都给不了的。