前言¶
在智能體開發或團隊協作中，交付物版本管理常陷入混亂：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
