综合小项目:用 Python 构建可预览的 AI 文件归档建议器
文件越来越多时,按主题整理文件名和目录是一件重复但容易误操作的工作。让模型直接重命名或移动本地文件,虽然方便,却把理解错误、路径问题和实际写操作混在了一起。本篇做一个综合小项目:模型只提出归档建议,Python 负责校验,程序最后生成一个可预览的计划文件,不直接修改任何原文件。
项目目标与安全边界
示例输入是几条文档元数据,每条包含编号、原文件名和内容摘要。程序要为每条文档建议分类、目标文件名、理由和置信度。分类只允许 work、study、personal、other 四个值;目标文件名只能是单层文件名,不能带 /、\\ 或 ..。
这个项目适合放在“批量整理”和“直接执行”之间:先把模型结果当作待审核数据,再由确定性代码决定哪些建议能够进入下一步。这样即使模型偶尔把文档分错类别,错误也会停在计划文件中,不会立刻改变磁盘状态。后续还可以为计划增加审核人、审核时间和执行状态,但这些字段应由程序或人工填写,不要让模型自行伪造。
这个边界体现了一个重要的工程原则:模型负责理解自然语言并提出候选,代码负责检查编号、枚举值、文件名和范围,人工或后续脚本再决定是否执行。即使模型返回了格式正确的结果,也不能因此直接相信它的语义判断。
先定义结果契约
先把模型输出定义成 Python 类型,再写调用逻辑。下面的契约要求每个输入文档恰好出现一次:
1 | { |
confidence 只是模型的主观判断,不等于事实正确率,也不能直接当作自动执行阈值。真正影响文件安全的约束,例如是否引用了不存在的编号、是否生成了重复文件名,必须在模型外部再次检查。
最小可运行实现
先安装当前 OpenAI Python SDK 和 Pydantic,并通过环境变量提供密钥和模型名:
1 | python -m pip install -U openai pydantic |
把下面代码保存为 archive_planner.py。它既包含真实模型调用,也提供不需要网络的 --self-test,可以先验证确定性校验逻辑。当前 SDK 的 client.responses.parse(..., text_format=...) 可以把结构化输出解析成 Pydantic 对象;如果模型拒答或没有得到可解析结果,程序会明确失败,而不是继续生成计划。
1 | import json |
先运行离线检查:
1 | python archive_planner.py --self-test |
确认校验逻辑后,再设置环境变量运行真实调用:
1 | python archive_planner.py |
程序只写出 archive-plan.json。查看计划并人工确认后,才可以另写一个独立的执行脚本;执行脚本仍应再次检查源文件存在、目标路径在允许目录内,以及目标文件没有被占用。
为什么不让模型直接操作文件
文件移动、删除和覆盖都有不可逆风险。即使模型能够正确理解摘要,也无法替代程序对路径、权限、同名文件和备份策略的检查。把“建议”和“执行”拆成两个阶段,至少能获得三层保护:模型输出可以被审阅,计划文件可以被保存和回放,真正的文件操作可以由确定性代码控制。
如果输入来自真实目录,还要注意隐私边界。发送给模型前只提供完成分类所需的摘要,路径、账号、令牌和个人信息应先脱敏;日志记录请求编号、状态和错误类型即可,不要打印完整原文或密钥。
常见问题
结构化输出通过了,为什么还要校验? 结构化输出主要保证字段和类型符合契约,不能证明分类正确,也不能自动理解你的文件系统规则。编号覆盖、文件名冲突和业务阈值仍应由代码检查。
能不能让程序自动执行高置信度建议? 不建议直接用单一置信度决定。可以把高置信度作为候选排序依据,但仍要检查路径、冲突和敏感目录;涉及删除或覆盖时必须人工确认并保留备份。
为什么示例没有直接读取整个目录? 先用固定样本验证核心流程更容易测试,也避免把本地私人文件误发给模型。接入目录扫描时,应明确允许的根目录和发送字段,再增加离线测试。
小结
这个综合项目把模型调用、结构化输出、结果校验和人工确认串成了一条安全边界:模型提出归档建议,Pydantic 解析结构,Python 检查编号和文件名,程序只生成预览计划。AI 应用不应把“模型给出了答案”当成“系统可以执行”,把副作用留在最后一个、可审计的步骤,才更容易测试、回滚和维护。