从文档内容出发,交付完整的文件命名包
本文目录
一项有用的按内容命名任务,最终应交付身份可核对的文件、完整的原名到新名映射,以及每个获准名称中所有字段的来源证据。先读文档,保留不确定字段,批准一份明确的映射,再将它应用到可丢弃副本上,并检查实际文件。
本教程提供八份完整、原创的 UTF-8 纯文本工作坊记录。其中四份可以根据内容命名;另外四份需要审阅,保留原名。完成改名的副本包 包含全部八份文件,原始内容字节均保持不变。可读预览 将每个来源 ID 与建议名称、批准决定和实际结果连接起来。
这些样例不含个人、客户、财务记录或真实业务文档。字段由作者逐项核读。本项目没有单独进行模型提取试验;下文的错误建议是作者编写的例子,不是捕获到的 AI 错误。文件操作和检查则曾在本地实际运行。本次中文翻译引用既有结果,没有重新执行。
取得输入,把文件身份与名称分开
下载共享的源文件包、输入清单、字段证据,并阅读命名规则。完整材料清单与运行说明 链接了所需的每份文件,包括两个小型 Python 程序。将程序和原始数据文件下载到同一个新建本地文件夹。
每份记录都有稳定的 Source-ID。输入清单将该 ID 与原始文件基本名、字节数及 SHA-256 绑定。表格行号或目录列出文件的顺序都不是文件身份。主题文字相同,也不能证明两个文件重复。
例如,Scan001.txt 的完整内容如下,保留英文源文本:
Document-Type: workshop-note
Source-ID: F01
Document-Date: 2026-04-03
Project: amber
Subject: airflow
Revision: a
Fictional teaching material. No people, customers or financial records.
Check the paper vane at the practice vent.
ID 为 F05 的 IMG005.txt 具有相同的日期、项目、主题和修订标记,但最后一行描述的是更宽的纸质风向片。它的内容字节和哈希都不同。两份记录都应保留在输出中;本任务是命名,不是去重。
全部待处理文件如下:
| ID | 原始文件 | 文档日期 | Project / Subject 原值 | 决定 |
|---|---|---|---|---|
| F01 | Scan001.txt |
2026-04-03 |
amber / airflow | 批准 |
| F02 | IMG002.txt |
2026-04-04 |
cobalt / latch-fit | 批准 |
| F03 | Scan003.txt |
缺失 | birch / spacing | 阻止执行 |
| F04 | Scan004.txt |
2026-04-05 与 2026-04-06 |
cedar / balance | 阻止执行 |
| F05 | IMG005.txt |
2026-04-03 |
amber / airflow | 批准 |
| F06 | Scan006.txt |
2026-04-07 |
dune / 主题不可读 | 阻止执行 |
| F07 | IMG007.txt |
2026-04-08 |
elm / hinge | 批准 |
| F08 | Scan008.txt |
04/05/2026,顺序未说明 |
fir / alignment | 阻止执行 |
八份文件属于同一种文档类型,均保留 .txt。这些日期是虚构文档中的字段,不是执行时刻或文件系统时间戳。
提出名称之前,先记录字段证据
48 行字段证据表 为每份文件记录六项字段:文档类型、来源 ID、文档日期、项目、主题和修订标记。每行包含原始值、源文件行号、准确字段原文、状态、采用值及作者决定。
F01 的日期在第 3 行明确标注。F03 没有 Document-Date 行,因此不会为这个缺失字段编造行号。F04 在第 3、4 行各有一个日期,两者都未采用。F08 提供了一个斜杠日期,却没有说明年月日的排列方式。选择 4 月 5 日或 5 月 4 日,都会添加文档本身未能确认的事实。
F06 的主题字段为空,记录说明该字段在这份虚构转录中不可读。写入“notes”,只会掩盖主题缺失,并没有找回主题。它的获准名称单元格保持为空。
对于另一组文档,人可以从权威来源补充缺失值。但这需要单独记录出处,并重新审阅计划。本包不会用今天的日期、原始文件名或文件创建时间,填补未知的文档事实。
如果请 AI 助手建议字段,应要求它先返回来源 ID、字段值、位置和不确定性,再提出文件名。然后将其说法与实际文档对照。本例直接由作者提供这份字段基准,没有测量提取准确率或节省时间。
使用完整命名规则,并另设批准列
获准使用的规则为:
<document-date>__<project>__<subject>__rev-<revision>__<source-id-lowercase>.txt
日期必须是单个、无歧义、格式为 YYYY-MM-DD 的有效日历日期。项目、主题和修订标记必须是核实过的小写 ASCII 词项,仅使用字母、数字和位于词项内部的单个连字符。名称只能是文件基本名,最多 160 个 ASCII 字节,保留 .txt。不自动转写字符,不自动分配后缀,也不截断名称。
F01 因此得到 2026-04-03__amber__airflow__rev-a__f01.txt。F05 使用相同的内容字段,末尾加上 f05,既能区分两份记录,也不必猜测新主题或丢弃文档。
完整改名计划 将 proposed_name、approved_name、status 和 reason 分开保存。表中包含全部八个 ID、原路径和哈希,以及指向字段证据的引用。只有已批准、且获准名称与规范名称完全一致的行才能执行。批准列中的空单元格表示有意保留待核,不是在邀请程序自行补名。
读懂错误建议及其修复
完整错误计划 故意从名称中省略 ID,导致 F01 和 F05 指向同一个目标。它还为 F03 缺失的日期填入无依据的 2026-10-22,选择 F04 两个冲突日期中的第一个,用“notes”编造 F06 的主题,并沿用 F08 有歧义的斜杠日期。
这些错误由作者编写,用于展示审阅过程,不是模型或用户犯错频率的证据。预览 将每个错误名称与修复后的决定并列展示。
修复分为两部分:为其余有效名称加入核实过的稳定 ID;让四份不确定的文档保持原样。结果是四个获准名称和四个被阻止的行,而不是八个表面完整的猜测。
可以先查看两份计划,不改动任何文件:
python3 rename_packet.py preview --plan wrong-plan.csv
python3 rename_packet.py preview --plan rename-plan.csv
既有记录还在可丢弃源副本中实际评估过错误计划。每行都被拒绝,每份源文件均保持不变。重复目标检查覆盖完整待处理集合,因此改变行顺序也不能任意选出一个“胜者”。
只在新建教学目录中执行
辅助程序要求 macOS。最终留存的执行使用 Python 3.9.6、macOS 26.5.2 arm64 和 APFS 卷;本地探测观察到文件查找不区分大小写。这只是一组经过测试的运行时和文件系统,不是跨平台适用结论。代码仅使用 Python 标准库和一个 Darwin 系统调用,不下载软件包。
使用一个全新、尚不存在的 /private/tmp/fw1-... 目录名。初始化命令会拒绝任何已有目录,即使目录为空。它仅将压缩包中已知的八个条目解压到私有 files 目录,并记录目录身份。后续操作要求该标记和身份匹配,不会通过扫描桌面或主目录来发现文件夹。
python3 rename_packet.py init /private/tmp/fw1-reader-one
python3 rename_packet.py apply /private/tmp/fw1-reader-one
python3 rename_packet.py apply /private/tmp/fw1-reader-one
第一次 apply 应将 F01、F02、F05 和 F07 报告为 applied,其余四行保持被阻止状态。重复命令应先检查日志和当前字节,再将四个已完成行报告为 already_applied;这不是又执行了一轮改名。已确认完成的操作会另行按源包、来源 ID、原名、源字节数/哈希、精确的原名到目标名操作,以及当前文件检查来匹配。因此,语义相同、仅在末尾多一个空行的 CSV,仍可识别同一个已完成操作;不同目标不能当作该操作。
要检查每个返回行。命令退出 0,只表示评估正常返回,不表示每行都获准或发生了修改。无效调用退出 2。不能仅凭命令退出码判断成功。
改名前,程序检查源文件是否具有预期字节;改名后,检查原名已不存在,且新名文件具有预期字节。程序在操作前刷新写入一条日志 intent,之后再记录结果。结果缺失时保持 unknown,阻止自动重放。这个阻断依据与源包绑定的自有目录内的稳定来源 ID,跨越所有计划哈希,并在评估替代建议之前执行。重新保存同一 CSV,或另提一个目标,都不能清除不确定性。原始计划哈希仍留在审计记录中,但不再用来隔离未知历史。
实际文件系统操作使用 renameatx_np,传入 RENAME_EXCL 和 RENAME_NOFOLLOW_ANY,路径相对于已打开的教学目录。Apple 的 rename 手册源码 说明,在支持的文件系统上,已有目标与排他标志冲突时会拒绝操作。Apple 的头文件 定义了这些标志。不支持该操作时,程序不会退回会覆盖目标的替代方式。
只检查目标是否存在,再调用普通 Unix rename,并不足够。Python 的 OS 文档 说明,已有的目标文件可能被替换。本例直接对一个已被占用的目标测试了排他操作本身,得到 EEXIST,两份文件均保留。该测试支持的是本机观察,不是跨文件系统保证。
保持这个练习目录私有,不允许外部程序并发写入。操作前的内容检查,不是阻止另一程序编辑源文件的原子锁。日志不是批次事务或崩溃恢复服务。需要共享目录协调、任意文件格式或生产恢复时,这个范围有限的辅助程序不提供那些实现。
检查完整输出,再单独审阅反向操作
实际的 renamed-copy.zip 来自最终记录中的副本 A,获取时点在正向操作完成后、反向操作之前。它恰好包含以下文件:
2026-04-03__amber__airflow__rev-a__f01.txt
2026-04-04__cobalt__latch-fit__rev-b__f02.txt
Scan003.txt
Scan004.txt
2026-04-03__amber__airflow__rev-a__f05.txt
Scan006.txt
2026-04-08__elm__hinge__rev-c__f07.txt
Scan008.txt
实际执行结果 记录最终两份副本中的每个 ID、原名、实际名称、结果、字节数和哈希。每份文件都与其源字节一致。副本 B 从冻结的源压缩包重新解压,没有接收 A 生成的文件。这是作者的两次执行,不是独立审阅。
反向计划 仅包含四个已确认的正向操作。它是一份可以审阅的映射,不是无条件 Undo 承诺。要在教学目录内请求反向操作,应使用该目录的日志:
python3 rename_packet.py reverse /private/tmp/fw1-reader-one
程序重新检查当前已改名文件,并拒绝被占用的原名。在通常的 A、B 练习中,四个名称都已恢复,内容字节匹配。在另一项单独练习中,一个后来创建的教学文件占用了 Scan001.txt。F01 的反向操作被阻止,后来文件保留,仅恢复 F02、F05 和 F07。F01 的已改名文件与占用原名的后来文件都留在目录中。不能把该分支称为“全部撤销”。
一般性的设计问题另见明确 Undo 应恢复什么及重复执行前说明部分成功批次。本包新增的是具体文档输入、从字段证据到名称的映射,以及实际文件输出。
复现既有练习,并理解它的范围
将完整材料放在同一个文件夹后,运行:
python3 reproduce.py
程序会创建新的私有教学根目录,记录实际命令、退出码和输出,检查两份全新副本及边界情形,保存已改名 ZIP 和结果表,再仅移除本次自行创建的根目录。它把生成的证据文件写在脚本旁边;若要保留随包提供的既有执行证据,请在材料包的另一份自有副本中运行。
最终留存的练习包含 38 条辅助程序命令和十组情形。原执行记录保留命令及逐行返回;conflicts.csv 汇集观察到的 blocked 或 unknown 行。情形包括已有目标、重复目标、源文件变化或缺失、无效扩展名、目录外路径、完整错误计划、后来发生的反向冲突,以及直接针对已占用目标的系统调用检查。日期缺失、冲突、歧义和字段不可读,则由主要输入集合覆盖。
最后一组插入作者明确编写的未完成日志 intent,检查程序是否以 unknown 拒绝重放。加入作者编写的 unknown 结果记录后,调用也继续保持 unknown。对于未完成 intent 和 unknown 结果,既有练习分别检查原计划、字节不同但解析行完全相同的 CSV,以及改变了 F01 目标名的计划。每项均保持 F01 unknown、八份文件不变,后七个 ID 未处理。各变体被拒绝时,已有日志字节也保持不变。更改计划后的反向请求同样被判为 unknown。该练习没有模拟掉电,也没有证明崩溃持久性。Unknown 会停止后续行,剩余 ID 被报告为未处理。普通 blocked 行则可以与其他成功行并存,因此批次有意不采用原子性语义。
完整请求 记录这份成品包的任务范围。作者核对了最终执行的逐文件结果及源包哈希;最终记录中的十二个可丢弃根目录均已移除。公开发布和独立编辑接受属于另外的步骤。
根据文档实际需要,选择自动化程度
少量关于多文件按内容命名的公开问题和办公文档流程为本任务提供了线索。既有研究记录的是个人自述,不是有代表性的客户样本,也不是当前产品缺陷的证据。一则相反观点讨论更偏好可预测的规则和预览。它们均未建立 AI 在准确率或吞吐量方面的优势。本包的冲突与反向检查是编辑选择的验收设计。
对于少量文件,人工核字段并命名可能已经足够。对于已知的前后缀或计数规则,普通批量工具可能更合适。只有当任务确实依赖理解文档含义时,助手才成为一个候选,而它的建议仍需证据和审阅。请求可以打字或口述;使用转写时,核对 ID、日期、路径和否定是否保留。输入方式本身不能证明文件结果更好。
应判断的是完整成品包:每份源文档、每个字段决定、每条获准或被阻止的映射,以及每份实际结果文件。一张整齐的建议名称清单,只是中间一步。