技能版本控管指的是：在修改一個已經穩定運作的技能定義時，確保有能力回答「這一版何時改的、改了哪裡、如果需要能不能乾淨退回上一版」這三個問題的一套做法。這跟單純把技能定義複製一份存起來不是同一件事——單純備份只解決「有沒有存」，版本控管解決的是「退回去的時候，會不會留下這次改動的殘留」。它也跟前面提過的 golden-set 不是同一件事：golden-set 負責判斷這次改動好不好，版本控管負責判斷不好的話怎麼準確退回去，兩者是技能維護流程裡互補的兩半。
這件事會被需要，是因為技能不是靜態文件，業務規則本身會持續變動——財務加審核欄位、公司換系統、法規要求增加揭露，這些變動不會停止，技能定義因此必然要跟著改。但多數技能庫在設計時，注意力全部放在「怎麼建立技能」，很少人在建立當下就設想「這個技能之後會被改幾次、每次改動的風險是什麼」。等到某次改動意外影響到另一段原本正常運作的邏輯，才發現根本沒有任何機制能回答「上一個能用的版本長什麼樣」，只剩下「現在這一版」跟片段的記憶。version control 存在的理由，就是把這個原本被忽略的維護階段，變成建立技能時就該一併規劃的一部分。
實務上分三步。第一步，每次要修改技能定義前，先把目前這一版存成帶日期戳記的備份，存放位置固定，例如專門開一個資料夾，或用 Claude Projects 的知識庫存放，命名規則統一（例如技能名稱加修改日期）。第二步，修改完成後不要直接正式上線，先用少量代表性案例測試，觀察輸出是否符合預期，特別留意有沒有影響到這次改動範圍以外的其他邏輯。第三步，測試通過才正式取代舊版；如果測試發現問題，直接用第一步存的備份檔案復原，不要憑記憶手動改回去，因為手動改回去本身是一次新的修改，容易改得不夠乾淨、留下這次改動的殘留邏輯。這三步搭配 golden-set 一起用效果最好：golden-set 負責判斷改動好不好，版本備份負責在判斷不好時提供乾淨的退路。
對你來說，這套機制真正的價值不在「防止改壞」——改動有風險是常態，不可能完全避免——而在「改壞之後，退回去要花多久」。沒有版本控管時，退回去要花的時間是回想原本邏輯、重新測試、確認有沒有改對，通常是幾小時起跳；有版本控管時，是找到帶日期的備份、直接復原，通常幾分鐘就能完成。要留意的是判斷哪些技能值得投入這套機制：修改頻率高、輸出直接影響金流或法遵的技能值得做；一次性、改壞了重錄一次也無所謂的技能不需要，過度為每個技能都上版本控管，維護成本反而會超過技能本身帶來的效益。
技能庫裡那個報帳流程的技能，三個月前錄一次就存好了，這三個月來一直很穩定地用。上週財務多加了一個審核欄位，你順手改了技能定義，這次改動看起來很小——加一個欄位而已。改完之後跑了兩次，看起來沒問題。但這週有一筆報帳漏了原本該有的核銷分類，回頭查才發現，是上週那次小改動，意外影響到另一段原本運作正常的邏輯。現在的問題不是「這次改壞了」，是「改壞之前的版本存在哪裡，能不能retrieve回來」。
多數人對技能庫的想像停留在「錄一次、存起來、以後直接呼叫」，這個想像對第一次很準確，但漏了後續。業務規則會變（財務加審核欄位、公司換了報帳系統、法規要求多一個揭露項目），技能定義因此需要跟著修改，這是必然會發生的事，不是意外。問題是，多數技能庫的設計焦點放在「怎麼建立技能」，很少人在建立當下就想過「這個技能之後要怎麼修改、改壞了怎麼辦」。等到真的改壞了才發現，原來根本沒有版本紀錄，只有「現在這一版」跟「你依稀記得原本大概長怎樣」。
單純把技能定義複製一份存到別的地方，不等於有版本控管。真正有用的版本控管，要能回答三個問題：這一版是什麼時候改的、改了哪裡（不是整份重看，是具體差異）、如果要退回上一版，能不能乾淨地退回去而不留下這次改動的殘留。第三點最容易被忽略——如果技能定義裡有一部分是這次改動新增的邏輯，退回舊版時如果沒有乾淨地移除，會變成新舊邏輯混在一起，比完全沒退版更難排查。
實務上最基本的做法，是每次修改技能定義前，先把目前版本存一份帶日期戳記的備份，存放位置固定（例如專門的資料夾或 Claude Projects 知識庫），修改後先用少量案例測試，確認沒問題才正式取代舊版；如果測試發現問題，直接用備份檔案復原，而不是憑記憶手動改回去——手動改回去這個動作本身就是新的修改，可能改得不夠乾淨。這跟前面提過的 golden-set（黃金樣本集）概念直接相關：golden-set 是拿一組已核可的案例重跑比對，決定這次改動是不是真的比較好；版本控管解決的是另一半問題——決定「不好」之後，要怎麼準確退回去。兩者搭配，才是完整的技能維護流程。
不是每個技能都值得做到這個程度。判斷標準看兩件事：這個技能多久會被修改一次，以及改壞的代價有多大。像報帳流程這種每季隨政策微調、輸出會直接影響財務數字的技能，版本控管值得做；一個一次性、用完就丟、改壞了重新錄一次也不心疼的技能，不需要為它建立這套機制。過度為每個技能都上版本控管，本身也是一種成本，會讓維護這件事變得比技能本身還複雜。
沒有版本控管的代價，不是「改壞了」這件事本身，是「改壞了但不知道怎麼退回去」這段空白期——這段時間裡，錯誤的技能可能已經連續執行了好幾次，產生好幾筆有問題的輸出，而你渾然不覺，因為技能表面上「有在跑」。設定版本控管的成本很低，每次修改前存一份備份加日期戳記，通常不到 5 分鐘；換來的是遇到問題時，退回的時間從「花好幾小時回想原本邏輯、重新測試」壓縮到幾分鐘內找到備份、直接復原。真正該留意的是：備份要在每次修改前存，不是想到才存——依賴「這次應該記得存」的習慣，遲早會有一次忘記，而忘記的那一次，通常就是真正需要備份的那一次。