用 Obsidian 搭配 Claude Code 直接讀取本地端的專案筆記，可以把過去做完的專案經驗提煉成可重用的 Task Template 和 SOP！ 因為 AI 沒有「這太理所當然」的盲點，所以能看見我工作流裡那些從來沒寫進筆記的隱性步驟。 舉例來說： 今天上午我在 Obsidian 進行週復盤時，腦中冒出一個念頭。 這禮拜我剛結束一場在政大圖書館的線上演講，從邀約到收尾走了快五個月。整個過程我都用 Obsidian 的專案筆記在追蹤像是：
- 窗口是誰
- 什麼時候提供大綱
- 簡報改了幾版
- 單據幾號寄出去
- 款項什麼時候入帳
我的專案筆記寫得很細，但寫完之後就封存在「已結案」的資料夾裡。
我突然想到：
如果我每接一場類似的演講都要重新從零開始想流程，那這份筆記的價值就只發揮了 30%。
剩下 70% 應該被提煉成 SOP 或 checklist，成為下次的 Template。
這件事我過去曾用人工做過。
但每次手動把專案經驗整理成 checklist 都覺得很費力，也常常漏掉細節。今天我想試試：讓 Claude 來幫我做這件事，會不會更精準？
實際做下來成果超好！！！
但更有意思的是過程中體會到的 5 件事，這些事跟我原本想像的「AI 幫我做事」完全不一樣。
▋反思 1. 「AI 幫我做事」雖然會腦補，但也能帶來意外的驚喜
我把政大演講的專案筆記丟給 Claudian (Obsidian 的一個插件，能在 Obsidian 中使用 Claude Code 和 Obsidian 的筆記互動)，請它提煉成 Template。
它很快丟回一份 draft，分了 6 個階段。
讀完第一遍我有 shock 到…它補上一些我沒列在筆記裡、但我實際上真的做過的步驟！例如：
- 課後 AAR
- 正式上場前練習一次完整流程
- 課後補充經歷到個人網站上
這些步驟一直存在我的工作流裡，只是因為太理所當然我從來沒想過要把它們寫進筆記。
AI 沒這個盲點。
它讀到我的專案筆記，會用一個外部視角問：「這之間是不是還缺一步？」
當然 AI 也會腦補一些不該抽象化的東西，例如： 把「政大」「窗口名字」這些具體的細節保留下來，或把具體的演講金額直接寫成通用步驟。
這時候我就要介入，告訴 Claude 哪些該抽掉、哪些該保留。
我慢慢發現：AI 負責補充空白，我負責校正方向。
▋反思 2. AI 能看見「我沒寫進筆記的隱性步驟」
延續上一點再講細一點。
AI 補上「課後 AAR」這件事讓我意識到一個問題：
我的專案筆記其實漏掉了「隱性步驟」。
漏掉這些其實是因為它們對我來說太自然了，自然到我不覺得需要寫下來！
但「對自己自然」跟「對未來的自己有用」是兩件事。
如果我半年後再開一個新專案，那時的我已經忘了當初
- 怎麼思考的
- 怎麼執行的
- 怎麼收尾的
Template 的價值，就是把這些隱性的東西外顯化。
AI 沒有「這太理所當然」的盲點，它只看我寫了什麼 (沒寫的它會問)。
某種程度上，AI 比我自己更適合做這個「萃取」的工作。
我的 Lesson Learned 是：
每次讓 AI 提煉 Template 的第一輪 draft 出來時，重點要放在「它補了什麼是我筆記裡沒有的」。
▋反思 3. Show before edit！別讓 AI 直接動手
第一輪互動我吃了個小虧。
Claude 提煉完內容後，沒問我直接就建了一份新的 Markdown 檔案並放到我的 Template 資料夾裡。
當下我有點 Shock，因為我的 Template 資料夾裡已經有一份「學校 (公部門) 講座邀約模版」。我等於多了一份重複的 Template，還要再花時間刪掉。
我馬上告訴 Claude：
以後每次要新增或修改 Template 之前，先掃資料夾找有沒有類似的 (找到就直接優化既有檔案)。 任何寫入動作都先在對話裡提案，等我確認過再動手。
這個習慣建立後，後續來回幾輪都很順。
Claude 提案→我看內容→確認→再編輯筆記，這樣我就不太需要手動修正。
我把這個原則記成「show before edit」，意思是：
AI 動筆前先讓我看。
這個原則對高度依賴 AI 處理檔案系統的工作流特別好用，因為 AI 一旦寫錯…
刪檔、重整、改連結，每一步都是隱性成本。
▋反思 4. 避免過度設計，簡單方案先試不好用再改
最後一個反思跟 Template 維護有關。
聊到一半我問 Claude：
未來這份 Template 會被優化第二版、第三版，舊版要怎麼保存？ 是不是要拆檔放到 Archive 子資料夾，用 Obsidian 內部連結串起來？
Claude 的建議是：拆檔保存舊版，這樣每次優化都要建檔、命名、改連結，固定成本很高！
但實際上回頭看舊版的次數可能一年不到一次。
為了一個低頻率需求付出高額成本，這就是過度設計。
Claude 建議我先用最簡單的方案：
單一檔案管理即可。
新版本的 Template 內容置頂，舊版內容放到下方並標記「上一版本」區塊。
如果哪天這則 Template 真的長到不好用，再來討論搬遷策略。
我自己常常會掉進「先把未來都想清楚再開始」的陷阱。
但模版這種東西結構可以隨時重構，它不像資料庫 schema 改起來會死人。
簡單方案先用，不好用再改就好。
▋反思 5. 把工作流封裝成 Skill
這四個反思走完，我跟 Claude 確認了一份打磨完的 Task Template。
我做的最後一件事是：把整個流程封裝成一個 Claude Code Skill，叫做 task-template-distill。未來只要我說「幫我把這則專案提煉成 Task Template」，這個 Skill 就會自動執行。
依序
- 先掃既有 Template，找最相關的那份
- 如果有找到就提案優化內容，沒找到就新建 Template
- 等我確認提案的 Template 內容後，實際編輯 Template 並加版本紀錄。
我的啟發是： 和 AI 來回討論的過程，都值得封裝成 Skill。
我們只需要說：「幫我將剛才討論的過程寫成 1 個 Skill，讓我可以重複使用。」
下面把這個 Skill 的完整內容附上，可以直接拿去改成自己的版本。
▋【Asset】Task Template 提煉 SOP
把這份 SOP 存成你 Claude Code 的 Skill，之後就能用自然語言觸發整個提煉流程。
name: task-template-distill
description: 從一則完成的專案筆記提煉出可重用的 Task Template。當使用者說「幫我把這則專案提煉成 Task Template」、「幫我做成 Task Template」、「優化 Task Template」、「把這個專案變成 Task 模版」，或選取一則 Project 筆記要求 Task 模版化時，立即啟動此 Skill。專門處理 Obsidian Vault 中 Template 資料夾下檔名以 `Task - ` 開頭的模版（Project / Note / Writing 等其他系列模版不適用）。
Task Template 提煉流程
適用情境
使用者的 Obsidian Vault 中：
- 專案筆記：放在
{專案筆記資料夾}，檔名常以{專案前綴-YYYYMMDD}開頭 - Task 模版：放在
{Template 資料夾}，檔名以Task -開頭 - 用 Obsidian Templater 外掛快速插入新任務時使用
只處理 Task 系列模版。如果使用者要求提煉的內容明顯不是任務型 SOP（例如要做寫作模版、卡片模版），不要套用本 Skill 的格式。
核心原則
-
不主動建新檔，先掃既有模版
- 收到指令第一步：用 Glob 掃描
{Template 資料夾}/Task - *.md - 比對主題，找最接近的既有模版
- 找到 → 優化既有檔案
- 真的找不到才建新檔
- 收到指令第一步：用 Glob 掃描
-
show before write
- 任何寫入前，先把優化後內容貼在對話中給使用者 review
- 列出「新增了哪些步驟、為什麼新增、來源是哪則專案筆記」（建議用表格）
- 經使用者確認才動手寫檔
-
版本疊加，不拆檔
- 新版直接覆寫主檔最頂端，舊版推到下方「上一版本（保留備查）」
- 不要為了「保存舊版」拆出多個檔案或建 Archive 資料夾
- 第三版以後若主檔太長，再跟使用者討論搬遷策略
-
無 emoji
- Template 不使用 emoji，保持文字簡潔
標準檔案結構
（略 — 詳見原文）
提煉的判斷邏輯
從專案筆記抽取 Task Template 時：
- 保留：任何主題的此類專案都會走過的流程步驟
- 抽掉：專案特有細節（具體日期、人名、金額、主題名）→ 用
{佔位符}取代 - 補上：專案筆記沒明確列、但實際上做過的隱性步驟
- 例如：「課後 AAR」、「練習一次完整流程」、「評估時間與意願」
- 分階段：把平面 task list 重構成 3–6 個階段
- 線上 / 實體分支：若任務有此差異，用
### 5-A 線上/### 5-B 實體切分