前言¶
在智能体开发或团队协作中，交付物版本管理常陷入混乱：report_FINAL.xlsx、report_FINAL_v2.xlsx、report_FINAL_really.xlsx 躺在同一个文件夹里，没人知道该信任哪一个。这种混乱的根源在于文件被原地修改和命名含糊。下面介绍一个名为 deliverable-versioning 的插件，通过机械化的规则来重建交付纪律。
插件简介¶
deliverable-versioning 是一个解决交付版本混乱的纪律工具，由 ChenneyZhuang 维护，采用 MIT 许可证。它不依赖外部包，核心逻辑通过一个 SKILL.md 文件实现。
核心功能¶
该插件强制执行一套机械化的规则，以消除对版本的模糊认知：
-
已发出 = 不可变
文件一旦发出，绝不原地修改。新内容必须生成新文件，旧文件保持发送时的状态。 -
日期命名，拒绝 “final”
使用日期和内容命名，避免使用 “final” 这样的模糊词汇。例如proposal_2026-09-14.xlsx比proposal_final_v3.xlsx更可靠。 -
单权威交付目录
每个项目只保留一个交付目录，作为 “实际发送内容” 的唯一真相源。 -
台账记录文件流向
维护一份台账，记录日期、文件名、行数和接收人。通过台账可以回答 “我们发过什么”，而不需要翻阅聊天记录。 -
新版本前先查存在性
在重建交付物前，先检查交付目录中是否已存在该版本。重建是第二个真相源，先查存在性可以避免产生冗余。 -
替代要留痕
当旧版本被新版本替代时，旧文件保留在目录中，但需在台账中标记；文档中的引用需更新。
安装与启用¶
- 打开终端，执行官方安装命令：
git clone https://github.com/ChenneyZhuang/deliverable-versioning ~/.claude/skills/deliverable-versioning
- 插件安装后版本为 v0.1.0，无需额外依赖。
典型用法¶
在处理交付文件时，遵循以下步骤：
* 避免原地修改：不要修改已发送的文件，而是创建新文件。
* 使用日期命名：按照 文件名_YYYY-MM-DD.扩展名 的格式命名。
* 查询历史：只看交付目录和台账，就能回答发送历史、接收人和具体内容。
局限与注意¶
该插件的有效性高度依赖于执行纪律：
* 台账纪律：台账记录取决于执行。一旦漏记一次发送，对账逻辑就会失效。
* 存量清理：对于已经混乱的存量文件夹，必须先做一次性清点，规则才能见效。
总结¶
deliverable-versioning 通过不可变文件和日期命名，解决了交付版本混乱的问题。要使用它，需遵守上述规则，并注意台账的完整记录。
- 插件目录：https://www.skillhub.cn/plugins/ChenneyZhuang/deliverable-versioning
- GitHub 仓库：https://github.com/ChenneyZhuang/deliverable-versioning
