從 Prompt 到 Skill：將 Release Note 寫作流“工程化”
整理版優先睇
將Release Note寫作流程工程化：從Prompt到Skill
呢篇文章係作者分享佢點樣將寫Release Note嘅流程，由每次都要手動教AI嘅「學徒模式」，升級成一個可以重複用嘅Skill。佢發現如果唔將AI放入標準化工作流程，AI只係一個玩具，唔會變成真正生產力工具。所以佢決定將自己腦入面嗰套經驗——包括點樣判斷功能大小、點樣排版——全部封裝成一個可調用嘅Skill。
過程中，佢解決咗兩個核心痛點。第一係AI嘅「平均主義」：以前AI會將大型功能同小修改當成一樣重要，輸出嘅內容冇輕重。佢喺Skill入面加入權重分級邏輯，要求AI先判斷功能Size，再匹配對應模版。第二係格式化問題：AI輸出嘅Markdown複製到文書軟件時格式亂曬，要花十幾分鐘手動整理。佢叫AI分析佢以往Release Note嘅樣式規則，生成可以直接用嘅Doc-Ready輸出，連顏色都對埋。
最後，佢將呢個Skill分享俾團隊，其他同事只要調用，就可以產出一致嘅高質量Release Note。呢件事嘅價值超越咗「省時間」，而係將個人經驗變成團隊資產。佢認為未來嘅競爭力可能唔在於寫得好唔好，而在於有冇能力將寫作邏輯提取封裝成Skill，令團隊以零邊際成本產出80分水平嘅交付物。
- 作者將Release Note寫作流程工程化，從每次手動調教AI轉變為建立可重用Skill，大幅提升效率同確定性。
- 核心方法：喺Skill入面加入權重分級邏輯，按功能大小（Major/Medium/Small）匹配唔同模版，告別AI嘅平均主義。
- 解決格式化痛點：要求AI唔淨止輸出文本，仲要生成符合以往樣式嘅Doc-Ready格式，慳返手動排版時間。
- 差異：Prompt係概率性嘅，每次要Human-in-the-loop；Skill似封裝好嘅程序，包含判斷、寫作、排版、輸出，確定性更高。
- 啟發同可行動點：未來核心競爭力在於將個人經驗提取封裝成Skill，令團隊以零邊際成本產出標準化高質量成果；建議讀者審視自己嘅重複性工作，嘗試封裝成Skill。
從學徒模式到工程化思維
作者喺準備產品Release Note時，產生一個強烈體感：如果唔將AI納入標準化工作流，佢只係一個
玩具
，無法成為
生產力工具
。以往用Prompt嘅流程係「Human-in-the-loop」，每次都要幾輪Copy-Paste-Modify，AI只係一個需要手把手教嘅
學徒
。佢發現自己費力糾正嘅邏輯權重同格式規範，就係想將腦海經驗固化成程序，於是直接將隱性知識編寫成可重複調用嘅Skill。
按功能Size分級，告別AI端水
呢個
權重分級邏輯
具體分三層：
- 1 Major Feature：需要包含Support Use Case、Feature Highlight或Benefit。
- 2 Medium Feature：適中篇幅，重點講清楚解決咗咩痛點。
- 3 Small Fix/Enhancement：一句話帶過，唔好喧賓奪主。
由文本升級為Doc-Ready輸出
通用LLM輸出Markdown，複製到Google Doc或郵件時格式災難級。作者之前每次生成完要花15-20分鐘做
搬運工
：手動上色、調整縮進同加粗。於是佢向Claude提出工程化需求：唔淨止要文本，仲要一個同以往Release Note樣式一樣嘅
Doc-Ready輸出
。Claude分析樣式規則後，用Python生成咗符合格式嘅文檔。
從個人經驗到團隊資產
作者將Skill分享俾團隊，其他PM或開發同學調用後，產出內容喺邏輯權重同視覺格式上嚴格遵循同一範式。呢種將
個人經驗變成團隊資產
嘅做法，令團隊以
零邊際成本
產出
80分水平
嘅交付物。佢認為
未來核心競爭力可能唔在於寫得好唔好，而在於有冇能力將寫作邏輯提取封裝成Skill
。
昨日喺準備產品嘅 Release Note 嘅時候，我產生咗一個強烈嘅體感：如果唔將 AI 納入標準化嘅工作流，佢只能夠係一個玩具，而冇辦法成為生產力工具。
起因好簡單。以往我寫 Release Note 嘅流程係標準嘅“Human-in-the-loop”：我將歷史 Release Note 作為 Sample 餵俾 AI，再將今次 Feature 描述貼入去，讓佢照住寫。
然後，我會進入漫長嘅「改作業」模式：叫佢補充 Benefit，調整 Tone of Voice，微調措辭。雖然比完全手寫快，但每次都要經歷幾輪「Copy-Paste-Modify」嘅折騰，本質上 AI 仲係一個需要我手把手教嘅「學徒」。
昨日，我喺用緊 Claude 嘅時候，依然習慣性咁開咗呢個流程。但喺幾輪調試、糾正邏輯、規範格式嘅過程入面，我突然意識到：我正在費力糾正嘅呢啲點（邏輯權重、格式規範），唔正係將我腦海裏面嘅經驗，嘗試固化做一段程序咩？
既然係咁，點解唔直接將佢封裝好？於是，我停止咗單純嘅 Prompt 調優，轉而叫 Claude 將呢啲隱性知識編寫成一個可重複調用嘅 Skill。
痛點一：告別「平庸嘅平均主義」
喺將經驗轉化做 Skill 嘅過程入面，我解決嘅第一個問題係 AI 嘅「平均主義」。喺得簡單 Prompt 嘅情況下，AI 往往係個「端水大師」。喺佢眼裏，一個耗時兩週開發嘅 Major Feature 同一個改咗幾行代碼嘅小優化，權重係一樣嘅。佢套用咗一模一樣嘅模板：標題、功能、價值。但我好清楚知道我做寫 release note 嘅時候心裏面其實有一套 SOP：
Major Feature：需要包含 Support Use Case、Feature Highlight 或者 Benefit。 Medium Feature：適中篇幅，重點講清楚解決咗乜嘢痛點。 Small Fix/Enhancement：一句話帶過，唔好喧賓奪主。
我開始喺 Skill 嘅定義入面，強制寫入呢套「權重分級邏輯」。我唔再要求佢「寫得好」，而係要求佢「先判斷 Size，再匹配模版」。
痛點二：跨越「格式化」嘅最後一公里
解決咗內容邏輯，緊接落嚟係更現實嘅交付問題。通用 LLM 輸出嘅都係 Markdown。呢個喺代碼編輯器裏面睇起嚟好極客，但當你將佢複製到 Google Doc 或者郵件裏面時，格式往往係災難級嘅。喺建立 Skill 之前，我每次生成完內容，都要花 15-20 分鐘做「搬運工」：手動將 "New Feature" 嘅標題刷成綠色；將 "Enhancement" 刷成黃色；調整縮進同加粗…… 呢 20 分鐘嘅損耗，笨拙而無奈。
於是我向 Claude 提出咗一個更工程化嘅需求：「唔好淨係俾我文本，我要一個同我以往 release note 樣式一樣嘅 Doc-Ready 嘅輸出。之後我就見到 Claude 開始分析我過往 release note 使用嘅樣式規則，之後調用 Python 七里嗙啷咁寫代碼生成咗 Doc。」
最後我叫 Claude 將我腦裏面呢啲要求都生成到 skill 裏面，我再咗用 skill test 一次 release note 生成。基本生成嘅內容完全符合我嘅要求，我冇再追加任何過多嘅改動喇。
俾大家睇下我 skill 嘅描述。
從「個人經驗」到「團隊資產」
當呢個 Skill 最終跑通之後，我睇佢生成嘅內容——重點突出、格式完美、甚至連顏色都啱嘅時候，我意識到呢件事嘅價值超越咗「省時間」。我將呢個 Skill 分享俾咗團隊。咁樣，其他嘅 PM 或者開發同學，只要調用呢個 Skill，產出嘅內容喺邏輯權重同視覺格式上，都嚴格遵循咗同一個範式。
思考：AI 時代嘅「知識工程」
對比之前使用 GPT Prompt Template 嘅體驗，Skill 帶來嘅唔單止係效率嘅提升，更加係確定性嘅增加。 Prompt 往往係概率性嘅，我哋需要不斷 Human-in-the-loop 去微調。而 Skill 更加似一個封裝好嘅程序，佢包含咗「點樣寫」、「點樣排版」、「點樣判斷」同「點樣輸出」。
我亦喺度思考，也許未來嘅核心競爭力，或許唔在於你能唔能夠寫出一篇靚嘅 Release Note，而在於你能唔能夠將呢套寫作邏輯提取出嚟，封裝成一個 Skill，令到整個團隊都可以以零邊際成本，產出 80 分水平嘅交付物。
我接下來亦會更多試試呢個 skill，感覺進入咗一個神奇嘅新世界，哈哈～
昨天在準備產品的 Release Note 時，我產生了一個強烈的體感：如果不把 AI 納入標準化的工作流，它只能是一個玩具，而無法成為生產力工具。
起因很簡單。以往我寫 Release Note 的流程是標準的“Human-in-the-loop”：我把歷史 Release Note 作為 Sample投餵給 AI，再把本次 Feature 描述貼進去，讓它仿照着寫。
然後，我會進入漫長的“改作業”模式：讓它補充 Benefit，調整 Tone of Voice，微調措辭。雖然比完全手寫快，但每次都要經歷幾輪“Copy-Paste-Modify”的折騰，本質上 AI 還是一個需要我手把手教的“學徒”。
昨天，我在使用 Claude 時，依然習慣性地開啓了這個流程。但在幾輪調試、糾正邏輯、規範格式的過程中，我突然意識到：我正在費力糾正的這些點（邏輯權重、格式規範），不就是在把我腦海裏的經驗，試圖固化成一段程序嗎？
既然如此，為什麼不直接把它封裝好？於是，我停止了單純的 Prompt 調優，轉而讓 Claude 將這些隱性知識編寫成了一個可重複調用的 Skill。
痛點一：告別“平庸的平均主義”
在把經驗轉化為 Skill 的過程中，我解決的第一個問題是 AI 的“平均主義”。 在只有簡單 Prompt 的情況下，AI 往往是個“端水大師”。在它眼裏，一個耗時兩週開發的 Major Feature 和一個改了改動了幾行代碼的小優化，權重是一樣的。它套用了一模一樣的模版：標題、功能、價值。但我很清晰的知道我在做寫release note 時候心裏其實有一套SOP：
Major Feature：需要包含 Support Use Case、Feature Highlight或者 Benefit。 Medium Feature：適中篇幅，重點講清楚解決了什麼痛點。 Small Fix/Enhancement：一句話帶過，不要喧賓奪主。
我開始在 Skill 的定義中，強制寫入這套“權重分級邏輯”。我不再要求它“寫得好”，而是要求它“先判斷 Size，再匹配模版”。
痛點二：跨越“格式化”的最後一公里
解決了內容邏輯，緊接着是更現實的交付問題。 通用 LLM 輸出的都是 Markdown。這在代碼編輯器裏看着很極客，但當你把它複製到 Google Doc 或者郵件裏時，格式往往是災難級的。 在建立 Skill 之前，我每次生成完內容，都要花 15-20 分鐘做“搬運工”：手動把 "New Feature" 的標題刷成綠色；把 "Enhancement" 刷成黃色；調整縮進和加粗…… 這 20 分鐘的損耗，笨拙而無奈。
於是我向 Claude 提了一個更工程化的需求：“不要只給我文本，我要一個和我以往release note樣式一樣的 Doc-Ready 的輸出。之後我就看到Claude 開始分析我過往release note使用的樣式規則，之後調用Python七里哐啷的寫代碼生成了Doc。
最後我讓Claude把我腦子裏這些要求都生成到skil裏面，我再用了skill test 了一遍release note 生成。基本生成的內容完全符合我的要求，我沒有再追加任何過多的改動了。
給大家看看我skill的描述。
從“個人經驗”到“團隊資產”
當這個 Skill 最終跑通後，我看它生成的內容——重點突出、格式完美、甚至連顏色都對的時候，我意識到這件事的價值超越了“省時間”。 我把這個 Skill 分享給了團隊。這樣，其他的PM或者開發同學，只要調用這個 Skill，產出的內容在邏輯權重和視覺格式上，都嚴格遵循了同一個範式。
思考：AI 時代的“知識工程”
對比之前使用 GPT Prompt Template 的體驗，Skill 帶來的不僅是效率的提升，更是確定性的增加。 Prompt 往往是概率性的，我們需要不斷 Human-in-the-loop 去微調。而 Skill 更像是一個封裝好的程序，它包含了“怎麼寫”，“怎麼排版”、“怎麼判斷” 和“怎麼輸出”。
我也在思考，也許未來的核心競爭力，或許不在於你能不能寫出一篇漂亮的 Release Note，而在於你能不能把這套寫作邏輯提取出來，封裝成一個 Skill，讓整個團隊都能以零邊際成本，產出 80 分水平的交付物。
我接下來也會更多試試這個skill, 感覺進入到了一個神奇的新世界，哈哈～