Agent工程化 · 第三篇：Skill也需要Git
整理版優先睇
將Git版本管理引入Skill開發，告別Prompt失憶症，並提供可行方案。
呢篇文章係作者專注AI Agent深度實踐嘅分享。佢發現好多工程師寫Prompt同Skill嗰陣，成日面對「Prompt失憶症」——改咗唔記得改咗咩，冇備份冇記錄。作者對比代碼工程一早用咗Git，但面對Skill同Prompt嘅時候，反而退化咗做手動備份派。
為瞭解決呢個問題，作者提出一個適用於大部分團隊嘅最小方案，包括三段版本號規則、每個版本必須記錄嘅資訊（版本號、日期、變更人、原因、內容、評測結果、已知問題、生產狀態），同埋兩種存儲方式：用Git + CodeBuddy管理（推薦技術團隊），或者用Langfuse等專門工具（非技術團隊）。作者仲講咗分支策略，類似Git Flow。
最後，作者指出版本管理嘅真正價值係積累工程智慧，令每次迭代都企喺之前經驗上面。佢建議今日就開始做三個簡單動作：打版本號、寫版本說明、建立文件記錄。整體結論係：Skill版本管理唔係可選項，而係專業AI工程必備。
- 結論：Skill同Prompt需要像代碼一樣做版本管理，否則改動不可追溯、回滾困難。
- 方法：使用主版本.次版本.修訂版三段號，每版記錄變更原因、內容及評測結果。
- 差異：Prompt diff唔直觀，必需關聯評測數據先有工程價值。
- 啟發：完整版本記錄形成迭代軌跡，可判斷改動方向有效性，加速成熟。
- 可行動點：即刻為現有Skill打v1.0.0，寫版本說明並建立記錄文件。
CodeBuddy
帶AI理解能力嘅代碼協作工具，可管理Skill文件版本，自動生成commit message同解讀diff。
Prompt管理工具推薦
Langfuse、PromptLayer、Helicone等，適合非技術團隊協作。
內容片段
版本號：v2.1.0變更日期：2024-03-15變更人：xxx變更原因：用戶反饋在多工具併發場景下會出現參數混淆變更內容：在工具調用部分增加了參數隔離的顯式約束，刪除了第三節中冗餘的格式說明（-200 Token）評測結果：準確性 87% → 91%，成本 1200 Token/次 → 980 Token/次已知問題：在極少數情況下（<2%）會過度約束，拒絕合理的併發請求生產狀態：灰度30%，2024-03-18全量Prompt失憶症：改咗唔記得改咗咩
呢篇文章開頭提到一個典型困境：有工程師精簡咗System Prompt，成本係低咗，但輸出變差咗，而且唔記得改咗邊度、冇備份。呢個狀況有個名，叫
Prompt失憶症
——你改咗，佢變咗，但講唔清楚改咗咩、點解變、點樣還原。
反而寫代碼嘅工程師一早用咗
Git
解決呢個問題：每次變更有記錄，每個版本可對比，出問題可以回滾。但怪就怪在，寫幾年代碼嘅人面對Skill同Prompt嗰陣，往往退化做「手動備份派」，改之前複製一份，改完叫system_prompt_最終版_v3_改完.txt。
點解Skill需要版本管理？
如果冇版本管理，你會面對以下四個問題：
- 改動不可追溯：三個月前嘅改動點解做？改咗咩？當時嘅測試結論係咩？冇記錄。
- 回滾無法執行：新版本上線出問題，你能喺十分鐘內回滾到上一個穩定版本嗎？多數團隊做唔到。
- A/B測試無法進行：想知道新System Prompt比舊嘅好定差，需要兩個版本同時運行對比指標，冇版本管理做唔到。
- 多人協作變災難：兩個人同時改同一個Skill，改完一合併——邊個版本算數？
呢四個問題，任何一個喺代碼工程都早有成熟解法，移植到Skill管理完全一樣。
Prompt版本管理同代碼版本管理嘅異同
先講相同嘅地方：
- 都需要變更記錄（改咗咩、點解改、邊個改）
- 都需要回滾能力（能快速切換到歷史版本）
- 都需要分支概念（實驗版本唔影響生產版本）
呢啲係版本管理嘅共通需求
再講唔同嘅地方：
- Prompt嘅diff唔直觀：代碼diff睇一眼大概明，但Prompt嘅diff經常係刪咗一句、加咗一個例子，但呢句同例子對行為嘅影響，淨睇diff睇唔出。
- Prompt嘅版本評估成本更高：代碼跑測試套件通過就得，Prompt評估往往要人工審核或LLM-as-judge，每次都要花時間同錢。
- Prompt嘅變更粒度更粗：代碼可以改一行，Prompt嘅最小有意義變更往往係一段——改咗一句話，成個Skill嘅行為基調都可能變。
Prompt版本管理更依賴評測數據
實用方案：今日就能落地
版本號規則：用三段版本號——
主版本.次版本.修訂版
主版本：核心行為根本性變化；次版本：添加新能力、修改工具調用邏輯；修訂版：修復邊界case、措辭優化。
每個版本必須記錄嘅信息：版本號、變更日期、變更人、變更原因、變更內容、
評測結果
、已知問題、生產狀態。呢啲唔係繁文縟節，三個月後你睇返呢條記錄，五秒就明。
存儲方式推薦用
Git + CodeBuddy
方案：將Skill嘅System Prompt存成純文字文件，納入代碼倉庫，每次改動寫清楚commit message，評測結果記喺PR描述裏。CodeBuddy可以自動生成commit message、提供diff解讀、關聯評測，將版本管理變成工程工作流一部分。非技術團隊可以考慮Langfuse等專門工具。
分支策略：
類似Git Flow嘅分支策略
——main行穩定版本，experiment做實驗，hotfix做緊急修復。同代碼Git Flow幾乎一樣。
版本管理嘅真正價值與即時行動
做好版本管理之後，你會得到Skill嘅進化記錄。每一個版本、每一次改動、每一次評測結果，形成一條完整迭代軌跡。呢條軌跡話你知呢個Skill喺咩方向改動有效，咩方向無效，邊類邊界case反覆出現，成熟度曲線係收斂定係震盪。
版本管理嘅真正價值係積累工程智慧
一個冇版本記錄嘅Skill，每次迭代都由零開始摸索；一個有完整記錄嘅Skill，每次迭代都企喺之前經驗嘅肩膀上。
- 1 揾到你而家用緊嘅一個Skill，畀佢打一個當前版本號，哪怕係v1.0.0。
- 2 寫一段版本說明，記錄佢而家嘅狀態、已知嘅問題、上次改動嘅原因。
- 3 建立一個文件或者文檔，將呢啲信息存落嚟，以後每次改動都更新。
一、你改過幾多次Prompt，仲記唔記得改咗啲乜嘢？
上一篇講完成本優化，我收到一個好典型嘅問題：
"我將System Prompt精簡咗，成本真係低咗，但係覺得有啲輸出差咗——但我唔記得改咗邊度，亦都冇備份。"
呢個係Prompt工程入面好常見嘅一種困境，有個唔係幾好聽嘅名：Prompt失憶症。
你改咗，佢變咗，但你講唔清楚改咗啲乜、點解變、點樣還原。
代碼工程一早解決咗呢個問題——Git。每次變更有記錄，每個版本可以對比，出咗問題可以回滾。
但奇怪嘅係，寫咗幾年code嘅工程師，面對Skill同Prompt嘅時候，往往退化咗做"手動備份派"——改之前複製一份，貼落備忘錄，檔案名叫system_prompt_最終版_v3_改完.txt。
呢篇文章想討論一個認真但好少被認真對待嘅問題：Skill嘅版本管理，應該點樣做？
二、點解Prompt需要版本管理
先講清楚問題嘅規模。
一個成熟嘅Agent系統，Skill數量通常喺10到50個之間。每個Skill嘅System Prompt平均每兩個禮拜會迭代一次。迭代嘅原因各式各樣：修復邊界case、優化成本、適配新工具、改善輸出格式……
如果冇版本管理，你會面對：
問題一：改動唔可以追溯三個月前嗰次改動點解要做？改咗啲乜？當時嘅測試結論係乜？冇記錄，冇答案。
問題二：回滾冇辦法執行新版本上線出咗問題，你可以喺十分鐘之內回滾到上一個穩定版本嗎？大多數團隊嘅答案係：唔得，因為上一個版本唔知存在邊度。
問題三：A/B測試冇辦法進行你想知道新嘅System Prompt比舊嘅好定差，需要兩個版本同時運行、對比指標。冇版本管理，呢件事做唔到。
問題四：多人協作變成災難兩個人同時喺改同一個Skill，改完一合併——邊個嘅版本算數？
呢四個問題，任何一個喺代碼工程入面都一早有成熟解法。移植到Skill管理入面，邏輯完全一樣。
三、Prompt版本管理同代碼版本管理嘅異同
喺傾具體方案之前，先諗清楚Prompt同代碼嘅差異——因為呢啲差異決定咗版本管理嘅方式唔可以完全照搬。
相同嘅地方：
都需要變更記錄（改咗啲乜、點解改、邊個改嘅） 都需要回滾能力（可以快速切換到歷史版本） 都需要分支概念（實驗版本唔影響生產版本）
唔同嘅地方：
Prompt嘅diff唔直觀。代碼diff睇一眼基本上可以理解變更意圖，Prompt嘅diff經常委係"刪咗一句話、加咗一個例子"，但呢句話同呢個例子對行為嘅影響，剩係睇diff睇唔出。你需要嘅唔單止係"改咗啲乜"，仲有"改咗之後表現點樣變咗"。
Prompt嘅版本評估成本更高。代碼跑測試套件，通過就係通過。Prompt嘅評估往往需要人工審核或者LLM-as-judge，每次都要花時間同錢。
Prompt嘅變更粒度更粗。代碼可以改一行，Prompt嘅最小有意義變更往往係一段——改咗一句話，成個Skill嘅行為基調都可能變。
呢啲差異意味住：Prompt嘅版本管理需要喺記錄變更嘅同時，強制關聯評測結果。一個冇配套評測數據嘅Prompt版本，幾乎冇工程價值。
四、一個實用嘅版本管理方案
唔談理想化嘅工具鏈，談一個大多數團隊今日就可以落地嘅最小方案。
4.1 版本號規則
用三段版本號：主版本.次版本.修訂版
主版本：Skill嘅核心行為發生根本性變化（例如從單步執行改成多步規劃） 次版本：添加新能力、修改工具調用邏輯、顯著改變輸出格式 修訂版：修復邊界case、措辭優化、唔影響核心行為嘅小改動
唔好用日期做版本號，日期冇辦法傳遞變更嘅重要程度。
4.2 每個版本必須記錄嘅信息
版本號：v2.1.0
變更日期：2024-03-15
變更人：xxx
變更原因：用戶反饋在多工具併發場景下會出現參數混淆
變更內容：在工具調用部分增加了參數隔離的顯式約束，刪除了第三節中冗餘的格式說明（-200 Token）
評測結果：準確性 87% → 91%，成本 1200 Token/次 → 980 Token/次
已知問題：在極少數情況下（<2%）會過度約束，拒絕合理的併發請求
生產狀態：灰度30%，2024-03-18全量
呢個唔係繁文縟節。三個月後你返嚟睇呢條記錄，五秒鐘就可以理解呢個版本嘅來龍去脈。
4.3 儲存方式
兩種選擇，各有適用場景：
用Git管理Prompt檔案（推薦技術團隊） 將Skill嘅System Prompt儲存成純文字檔案，納入程式碼倉庫管理。每次改動寫清楚commit message，評測結果記喺PR描述入面。呢個方案嘅好處係同程式碼工作流完全一致，工程師幾乎零學習成本。
呢度推薦一個具體嘅做法：用CodeBuddy嚟管理Skill檔案嘅版本迭代。
CodeBuddy本質上係一個帶AI理解能力嘅程式碼協作工具，但係佢管理嘅對象唔限於程式碼——Prompt檔案、Skill配置、YAML工具定義，全部都可以納入佢嘅版本追蹤體系。
具體操作流程係咁樣：
將Skill檔案放入倉庫：將你嘅System Prompt儲存成 .md或.txt檔案，例如skills/data_analyst.md，納入Git倉庫每次改動提交時，叫CodeBuddy生成commit message：佢可以理解Prompt改動嘅語義，自動生成"刪除冗餘嘅格式約束，新增多工具並發嘅參數隔離說明"呢啲有意義嘅描述，而唔係"update prompt" 利用CodeBuddy嘅diff視圖做改動審查：Prompt嘅diff唔似代碼咁直觀，CodeBuddy可以幫你解讀兩個版本之間嘅語義差異——唔止係"改咗邊行"，而係"呢次改動對Skill行為可能產生咩影響" 喺PR描述入面關聯評測結果：每次版本升級提PR時，將評測前後嘅指標變化附上，形成"改動-評測-結論"嘅完整閉環
呢個流程將版本管理真正變成了工程工作流嘅一部分，而唔係另一套需要單獨維護嘅體系。
用專門嘅Prompt管理工具（推薦非技術團隊協作場景） Langfuse、PromptLayer、Helicone等工具都有Prompt版本管理功能，仲可以直接關聯線上運行數據。適合需要產品、營運等非工程角色都參與Skill迭代嘅場景。
兩種方式唔矛盾，可以同時用：Git + CodeBuddy負責工程側嘅變更管理，工具平台負責線上表現數據嘅關聯。
4.4 分支策略
生產環境只係行穩定版本，實驗版本行獨立分支，灰度驗證通過先合併。
具體嚟講：
main分支 → 生產環境，永遠是經過驗證的穩定版本
experiment分支 → 實驗新版本，只給測試流量
hotfix分支 → 緊急修復，改完直接合main
呢個同代碼嘅Git Flow幾乎一樣，邏輯係通用嘅。
五、版本管理嘅真正價值：令迭代可以學習
做好版本管理之後，你會得到一個喺做之前冇諗到嘅嘢：Skill嘅進化記錄。
每一個版本、每一次改動、每一次評測結果，構成咗一條完整嘅迭代軌跡。
呢條軌跡可以話俾你知：
呢個Skill喺咩方向上改動係有效嘅，喺咩方向上係冇效甚至有害嘅 邊類邊界case係反覆出現嘅，說明有更深層嘅設計問題未解決 呢個Skill嘅成熟度曲線——佢係喺收斂，定係喺震盪？
一個冇版本記錄嘅Skill，每次迭代都係由零開始摸索。一個有完整版本記錄嘅Skill，每次迭代都企喺之前所有經驗嘅膊頭上。
呢個就係版本管理嘅真正價值：唔係管理檔案，係累積工程智慧。
六、今日就可以開始嘅最小動作
揾到你正在用嘅一個Skill，做呢三件事：
俾佢打一個當前版本號，就算只係v1.0.0 寫一段版本說明，記錄佢現在嘅狀態、已知嘅問題、上次改動嘅原因 建立一個檔案或文檔，將呢啲信息儲存落嚟，以後每次改動都更新
呢個唔需要任何工具，今日就可以做完。
三個月後，你會慶幸自己做咗呢件事。
一、你改過多少次Prompt，還記得改了什麼嗎
上一篇講完成本優化，我收到一個很典型的問題：
"我把System Prompt精簡了，成本確實下來了，但感覺有些輸出變差了——可我不記得改了哪裏，也沒有備份。"
這是Prompt工程裏極為普遍的一種困境，有個不太好聽的名字：Prompt失憶症。
你改了，它變了，但你說不清楚改了什麼、為什麼變、怎麼還原。
代碼工程早就解決了這個問題——Git。每次變更有記錄，每個版本可對比，出了問題能回滾。
但奇怪的是，寫了幾年代碼的工程師，在面對Skill和Prompt的時候，往往退化成了"手動備份派"——改之前複製一份，粘貼到備忘錄，文件名叫system_prompt_最終版_v3_改完.txt。
這篇文章想討論一個認真但很少被認真對待的問題：Skill的版本管理，應該怎麼做？
二、為什麼Prompt需要版本管理
先說清楚問題的規模。
一個成熟的Agent系統，Skill數量通常在10到50個之間。每個Skill的System Prompt平均每兩週會迭代一次。迭代的原因各種各樣：修復邊界case、優化成本、適配新工具、改善輸出格式……
如果沒有版本管理，你會面對：
問題一：改動不可追溯三個月前的那次改動為什麼做？改了什麼？當時的測試結論是什麼？沒有記錄，沒有答案。
問題二：回滾無法執行新版本上線出了問題，你能在十分鐘內回滾到上一個穩定版本嗎？大多數團隊的答案是：不能，因為上一個版本不知道存在哪裏。
問題三：A/B測試無法進行你想知道新的System Prompt比舊的好還是差，需要兩個版本同時運行、對比指標。沒有版本管理，這件事做不了。
問題四：多人協作變成災難兩個人同時在改同一個Skill，改完一合併——誰的版本算數？
這四個問題，任何一個在代碼工程裏都早有成熟解法。移植到Skill管理裏，邏輯完全一樣。
三、Prompt版本管理和代碼版本管理的異同
在談具體方案之前，先想清楚Prompt和代碼的差異——因為這些差異決定了版本管理的方式不能完全照搬。
相同的地方：
都需要變更記錄（改了什麼、為什麼改、誰改的） 都需要回滾能力（能快速切換到歷史版本） 都需要分支概念（實驗版本不影響生產版本）
不同的地方：
Prompt的diff不直觀。代碼diff看一眼基本能理解變更意圖，Prompt的diff經常是"刪了一句話、加了一個例子"，但這句話和這個例子對行為的影響，光看diff看不出來。你需要的不只是"改了什麼"，還有"改了之後表現怎麼變了"。
Prompt的版本評估成本更高。代碼跑測試套件，通過就是通過。Prompt的評估往往需要人工審核或者LLM-as-judge，每次都要花時間和錢。
Prompt的變更粒度更粗。代碼可以改一行，Prompt的最小有意義變更往往是一段——改了一句話，整個Skill的行為基調都可能變。
這些差異意味着：Prompt的版本管理需要在記錄變更的同時，強制關聯評測結果。一個沒有配套評測數據的Prompt版本，幾乎沒有工程價值。
四、一個實用的版本管理方案
不談理想化的工具鏈，談一個大多數團隊今天就能落地的最小方案。
4.1 版本號規則
用三段版本號：主版本.次版本.修訂版
主版本：Skill的核心行為發生根本性變化（比如從單步執行改成多步規劃） 次版本：添加新能力、修改工具調用邏輯、顯著改變輸出格式 修訂版：修復邊界case、措辭優化、不影響核心行為的小改動
不要用日期做版本號，日期無法傳遞變更的重要程度。
4.2 每個版本必須記錄的信息
版本號：v2.1.0
變更日期：2024-03-15
變更人：xxx
變更原因：用戶反饋在多工具併發場景下會出現參數混淆
變更內容：在工具調用部分增加了參數隔離的顯式約束，刪除了第三節中冗餘的格式說明（-200 Token）
評測結果：準確性 87% → 91%，成本 1200 Token/次 → 980 Token/次
已知問題：在極少數情況下（<2%）會過度約束，拒絕合理的併發請求
生產狀態：灰度30%，2024-03-18全量
這不是繁文縟節。三個月後你回來看這條記錄，五秒鐘就能理解這個版本的來龍去脈。
4.3 存儲方式
兩種選擇，各有適用場景：
用Git管理Prompt文件（推薦技術團隊） 把Skill的System Prompt存成純文本文件，納入代碼倉庫管理。每次改動寫清楚commit message，評測結果記在PR描述裏。這個方案的好處是和代碼工作流完全一致，工程師幾乎零學習成本。
這裏推薦一個具體的做法：用CodeBuddy來管理Skill文件的版本迭代。
CodeBuddy本質上是一個帶AI理解能力的代碼協作工具，但它管理的對象不限於代碼——Prompt文件、Skill配置、YAML工具定義，全都可以納入它的版本追蹤體系。
具體操作流程是這樣的：
把Skill文件放進倉庫：把你的System Prompt存成 .md或.txt文件，比如skills/data_analyst.md，納入Git倉庫每次改動提交時，讓CodeBuddy生成commit message：它能理解Prompt改動的語義，自動生成"刪除冗餘的格式約束，新增多工具併發的參數隔離說明"這樣有意義的描述，而不是"update prompt" 利用CodeBuddy的diff視圖做改動審查：Prompt的diff不像代碼那麼直觀，CodeBuddy可以幫你解讀兩個版本之間的語義差異——不只是"改了哪行"，而是"這次改動對Skill行為可能產生什麼影響" 在PR描述裏關聯評測結果：每次版本升級提PR時，把評測前後的指標變化附上，形成"改動-評測-結論"的完整閉環
這個流程把版本管理真正變成了工程工作流的一部分，而不是另一套需要單獨維護的體系。
用專門的Prompt管理工具（推薦非技術團隊協作場景） Langfuse、PromptLayer、Helicone等工具都有Prompt版本管理功能，還能直接關聯線上運行數據。適合需要產品、運營等非工程角色也參與Skill迭代的場景。
兩種方式不矛盾，可以同時用：Git + CodeBuddy負責工程側的變更管理，工具平台負責線上表現數據的關聯。
4.4 分支策略
生產環境只跑穩定版本，實驗版本走獨立分支，灰度驗證通過再合併。
具體來說：
main分支 → 生產環境，永遠是經過驗證的穩定版本
experiment分支 → 實驗新版本，只給測試流量
hotfix分支 → 緊急修復，改完直接合main
這和代碼的Git Flow幾乎一樣，邏輯是通用的。
五、版本管理的真正價值：讓迭代可學習
做好版本管理之後，你會得到一個在做之前沒想到的東西：Skill的進化記錄。
每一個版本、每一次改動、每一次評測結果，構成了一條完整的迭代軌跡。
這條軌跡能告訴你：
這個Skill在什麼方向上改動是有效的，在什麼方向上是無效甚至有害的 哪類邊界case是反覆出現的，說明有更深層的設計問題沒有解決 這個Skill的成熟度曲線——它是在收斂，還是在震盪？
一個沒有版本記錄的Skill，每次迭代都是從零開始摸索。一個有完整版本記錄的Skill，每次迭代都站在之前所有經驗的肩膀上。
這就是版本管理的真正價值：不是管理文件，是積累工程智慧。
六、今天就能開始的最小動作
找到你正在用的一個Skill，做這三件事：
給它打一個當前版本號，哪怕就是v1.0.0 寫一段版本說明，記錄它現在的狀態、已知的問題、上次改動的原因 建一個文件或文檔，把這些信息存下來，以後每次改動都更新
這不需要任何工具，今天就能做完。
三個月後，你會慶幸自己做了這件事。