把模糊想法變成可執行工作：我的 Supekku Workflow 設計
Supekku Workflow 是我用來和 AI Agent 協作的一套工作脈絡保存方式。它不是單純的 todo list，也不是一開始就把所有事情文件化，而是先透過對話釐清意圖、範圍、成功標準與取捨；等到工作需要跨 session、交接或驗證時，再整理成 proposal、criteria、reasoning、actions 與 verification。重點不是讓 AI 自動做完所有事，而是讓人和 Agent 都能知道：這件事為什麼要做、做到哪裡算完成、怎麼檢查，以及下一步該怎麼接下去。
很多人開始用 AI Agent 之後，第一個會研究的東西通常是 prompt。
怎麼問比較準？怎麼讓模型照格式回答？怎麼避免它亂改檔案？怎麼讓它一次做完更多事情？
這些問題都重要。但用久了之後，我慢慢覺得，AI 協作真正麻煩的地方不只在 prompt。
更大的問題是：脈絡很容易消失。
一件事情為什麼要做？做到什麼程度算完成？有哪些東西明確不做？中間做過哪些取捨？最後怎麼驗證？如果下一次換另一個 Agent 接手，它要從哪裡知道前面發生過什麼？
如果這些都只存在對話裡，每次重開 session 都像重新開始。模型可能很強，但它拿到的是一團模糊的需求，自然也只能產出一團看起來很完整、實際上很難驗證的結果。
這是我設計 Supekku Workflow 時想解決的問題。
Supekku 不是單純的 todo list，也不是為了把每件小事都變成厚厚一疊文件。它比較像是一套工作脈絡的保存方式：先讓模糊想法在對話裡變清楚，真的需要留下來時，再把它整理成未來的人和 AI 都能接手的工作單位。
AI 協作最大的問題不是 prompt，而是脈絡
Prompt 很像是入口。
它決定你這一次怎麼跟模型說話，但它不一定能保存一件事的來龍去脈。
例如你可能會這樣要求 AI：
幫我寫一篇關於 Obsidian 和 AI Agent 的文章。模型可以寫，而且通常會寫得很快。但它不一定知道：
- 這篇文章要接在哪一篇之後
- 讀者是誰
- 你想避開哪些角度
- 你自己的觀點是什麼
- 文章要偏教學、方法論，還是個人經驗
- 寫完後要怎麼判斷它能不能發布
如果這些脈絡沒有被說清楚，AI 只好自己補。它補得越順，反而越危險，因為你很容易被一篇流暢的草稿騙過去。
軟體開發也是一樣。
「修掉這個 bug」聽起來很簡單，但實際上至少包含幾個問題：
- bug 的重現條件是什麼？
- 這次修復的範圍到哪裡？
- 哪些相鄰問題先不處理？
- 要補測試嗎？
- 怎麼確認沒有改壞其他地方？
- 如果修法有取捨，理由是什麼？
這些東西如果沒有留下來，AI Agent 可能真的會「做完」，但你不一定知道它完成的是不是你要的東西。
所以我後來越來越少把 AI 協作理解成「寫一個更好的 prompt」。我更在意的是：
這件事能不能被描述成一個可接手、可驗證、可追蹤的工作單位？
Supekku Workflow 就是往這個方向設計的。
我想要的不是任務管理，而是可接手的工作單位
一般 todo list 很適合記提醒。
- 寫文章- 修 bug- 整理筆記- 做 proposal這種清單對人有用，因為人腦會自動補上上下文。你看到「寫文章」，可能立刻想起昨天在想的題目、目標讀者、想引用的舊文、還有那個一直沒寫完的段落。
但 AI Agent 不會知道這些。下一個接手的人也不一定知道。
所以 Supekku 想保存的不是「有一個任務」，而是任務背後的脈絡。
一個可接手的工作單位，至少要回答幾件事：
- Why：為什麼要做？
- Scope：這次做什麼，不做什麼？
- Criteria：怎樣算完成？
- Reasoning：為什麼選這個方向？
- Actions：下一步怎麼做？
- Verification：怎麼檢查結果？
- Evidence：完成後留下什麼證據？
這些問題看起來有點像專案管理，但我不想把它變成很重的流程。
很多事情其實不用正式建檔。只是想一想、聊一聊、試一試，就結束了。硬把每個念頭都寫成 proposal，只會讓工作流變成負擔。
所以 Supekku 有一個很重要的原則：先對話，再保存。
在想法還不成熟的時候，先保持自然討論。等到這件事真的需要跨時間、跨 session、跨 Agent 被接手，再把它整理成 artifact。
這樣文件不是為了流程而存在，而是因為未來真的會有人需要它。
Supekku Workflow 的基本形狀
Supekku 的格式可以很簡單。
我通常會把一件工作拆成幾個區塊：
## Proposal
- Why:- What changes / what we are deciding:- Non-goals:- Impact / stakeholders:
## Criteria
- Outcome:- Acceptance criteria:- Constraints:
## Reasoning
- Approach:- Alternatives considered:- Risks and unknowns:- Verification strategy:
## Actions / next steps
- [ ] 1.1 ...
## Self-verification
- Coverage:- Consistency:- Ambiguity:- Risks:- Evidence:這些欄位不是為了看起來正式，而是各自解決一種很常見的混亂。
Proposal：說清楚為什麼要做
Proposal 處理的是意圖。
很多工作失敗不是因為執行差，而是從一開始就沒有說清楚要解決什麼問題。
例如「改版首頁」這件事，如果沒有補上 why，可能有很多種解讀：
- 視覺太舊，需要更新品牌感
- Above the Fold 轉換率不好，需要優化 CTA
- 資訊架構混亂，需要重新組織內容
- 效能太差，需要改善載入速度
這幾種方向都叫改版首頁，但做法完全不一樣。
所以 Proposal 至少要說清楚：為什麼做、這次要改什麼、哪些事情不在範圍內。
Non-goals 尤其重要。
它可以阻止工作一路膨脹。當 Agent 很積極地想把相關問題一起處理掉時，Non-goals 會提醒它：這次不是要解決所有問題。
Criteria：定義怎樣算完成
Criteria 處理的是成功標準。
如果沒有 criteria，AI Agent 很容易把「有產出」誤解成「已完成」。
例如寫文章不是產出一篇 3000 字草稿就好。你可能真正想要的是：
- 能接續既有文章脈絡
- 有清楚的主張
- 不是工具介紹文
- 語氣符合部落格風格
- 可以直接發布，或至少接近可發布
這些標準如果沒有寫下來，最後就只能憑感覺驗收。
Criteria 不一定要很多，但要具體。越具體，Agent 越知道怎麼收斂。
Reasoning：留下取捨，而不是只留下結論
Reasoning 是我覺得很容易被忽略，但最有價值的部分。
很多工作做完之後，我們只留下結果，沒有留下為什麼。
幾週後回頭看，就會忘記當時為什麼選 A、不選 B。下一個接手的人也只能從結果反推。AI 更不用說，它可能會把已經被排除的方案重新提出來。
Reasoning 不需要寫成長篇論文，只要留下幾個關鍵判斷：
- 這次採用的方向是什麼？
- 有哪些替代方案？
- 為什麼先不選那些方案？
- 風險在哪裡？
- 哪些東西還不確定？
這些文字會讓未來的工作更容易接續。
Actions：把方向拆成可以做的下一步
Actions 處理的是執行。
我不喜歡把 action 寫得太大，像這樣：
- 完成文章這太粗了。對人來說可能還可以，對 Agent 來說不夠好。
比較好的拆法是：
- [ ] 1.1 檢查既有文章，確認可內連的內容- [ ] 1.2 產出文章大綱- [ ] 1.3 根據大綱寫初稿- [ ] 1.4 檢查語氣是否符合既有部落格風格- [ ] 1.5 補上 frontmatter、slug 與摘要每個 action 都應該小到能被執行，也能被檢查。
Self-verification：不要只相信「完成了」
AI Agent 很常回報「完成了」。
但完成了什麼？怎麼檢查？有沒有證據？有沒有遺漏？
Self-verification 是為了處理這件事。
它要求最後至少回頭看幾個面向：
- Coverage：有沒有覆蓋原本需求？
- Consistency：內容是否前後一致？
- Ambiguity：有沒有仍然模糊的地方？
- Risks：有沒有留下風險或未處理問題？
- Evidence：有哪些檔案、測試、連結、輸出可以證明完成？
這不是為了不信任 AI，而是因為人類自己做事也需要驗證。
只是 AI 做得太快，反而更需要把驗證寫清楚。
先 conversation，再 artifacts
Supekku Workflow 裡我最在意的一點，是不要一開始就寫文件。
很多流程設計最後會變重，就是因為它把所有事情都制度化。只要有一個想法，就要開文件；只要有一個任務，就要填欄位；只要有一個討論，就要進入流程。
這樣很快就會累。
我比較喜歡的方式是：先讓想法停留在對話裡。
對話適合探索。你可以快速改方向，可以說不確定，可以提出很粗糙的念頭，也可以中途發現其實這件事不值得做。
等到討論逐漸收斂，再決定要不要保存。
我會在幾種情況下把內容轉成 Supekku artifact：
- 這件事需要分多次 session 完成
- 之後可能要交給另一個 Agent 或另一個人接手
- 中間有重要取捨，需要留下理由
- 結果需要驗證，不只是產出文字
- 未來可能要回頭查這件事為什麼這樣做
反過來說，如果只是一次性問答，就不需要 Supekku。
不是每個念頭都值得被保存。保存本身也有成本。
人類讀得懂，Agent 也讀得懂
我希望 Supekku artifact 同時服務兩種讀者。
第一個讀者是人。
人需要快速知道這件事的背景、範圍、狀態與下一步。不應該讀完一堆對話紀錄，才知道現在要做什麼。
第二個讀者是 AI Agent。
Agent 需要穩定的結構，才能搜尋、摘要、接續與驗證。自然語言當然可以讀，但如果每次格式都不一樣，接手成本就會變高。
所以 Supekku 會偏向使用固定欄位、清楚命名、明確狀態與可追蹤證據。
這其實跟個人知識庫很像。
如果 Obsidian 是保存知識的地方，那 Supekku 就是保存工作脈絡的方式。
Obsidian 裡可能有你的筆記、文章、研究材料、讀書紀錄。Supekku 則保存另一種東西：
- 為什麼要做這件事
- 當時怎麼判斷
- 接下來要做什麼
- 做完後怎麼驗證
- 哪些證據可以證明它真的完成
這些內容對人有用，對 AI 也有用。
尤其當你開始讓 Agent 做比較長的任務時，這種結構會變得很重要。
一個實際例子：把部落格選題變成工作流
假設一開始只有一個很模糊的想法：
我好像一段時間沒有寫部落格了，想恢復產出。一般 todo list 可能會寫成：
- 寫一篇部落格文章這沒有錯，但它沒有保存任何脈絡。
如果用 Supekku 的方式整理，可能會變成這樣：
## Proposal
### Why
最近部落格停了一段時間，需要用一篇能串起既有主題的文章恢復產出。既有內容已經包含 Obsidian、RAG、GEO、LQIP 與 Slidev，接下來適合寫一篇能連接 AI 知識管理與 Agent 工作流的文章。
### What changes / what we are deciding
產出一篇關於 Obsidian、RAG 與 AI Agent 如何分工的文章，定位為 AI knowledge workflow 系列的入口文。
### Non-goals
- 不做完整工具比較- 不寫成 RAG 程式實作教學- 不介紹太多特定產品- 不把文章寫成 AI 趨勢評論
### Impact
這篇文章可以連接既有的 Obsidian、RAG 與 GEO 文章，也能作為後續 Supekku Workflow 文章的前置脈絡。接著是 criteria：
## Criteria
### Outcome
完成一篇可以發布到部落格的 Markdown 草稿。
### Acceptance criteria
- 文章有清楚主張：Obsidian、RAG、Agent 應該分工，而不是混在一起- 能自然連回既有 Obsidian、RAG、GEO 文章- 包含一個最小可行 workflow 範例- 語氣符合既有部落格風格，偏清楚、實用、不要太行銷- 產出 frontmatter、slug 建議與摘要
### Constraints
- 不誇大 AI 能力- 不宣稱 RAG 可以解決所有幻覺- 不讓文章變成工具清單再來才是 actions：
## Actions / next steps
- [ ] 1.1 檢查部落格既有文章脈絡- [ ] 1.2 決定文章主標與定位- [ ] 1.3 產出大綱- [ ] 1.4 寫完整 Markdown 草稿- [ ] 1.5 補上摘要、slug 與延伸閱讀- [ ] 1.6 檢查語氣與可發布性這樣一來，AI Agent 不只是收到「幫我寫文章」這種模糊指令，而是拿到一個有方向、有邊界、有驗收標準的工作單位。
做完後，也比較容易檢查它到底有沒有達成要求。
Supekku 不是讓 AI 自動做完所有事
我不把 Supekku 想成全自動 Agent 系統。
它比較像 guardrail。
它讓 AI 不要亂跑，讓人知道為什麼做，讓結果可以被檢查，也讓下一次 session 可以接續。
這件事很重要，因為 AI 很容易製造一種「事情已經完成」的感覺。
它可以很快寫出草稿，很快改完檔案，很快列出總結。但如果沒有 criteria 和 verification，你很難知道這個完成是真的完成，還是只是產出了一個看起來像完成的東西。
所以 Supekku 不是為了讓 AI 取代判斷。
剛好相反。
Supekku 是為了讓判斷被留下來。
當你留下 why、non-goals、reasoning、verification，未來的你或下一個 Agent 才知道：這不是隨便做的，這些取捨是有理由的。
我目前會怎麼使用它
我會把 Supekku 用在幾種情境。
需要跨 session 的工作
如果一件事今天做不完，之後還要接著做，就適合保存。
例如：
- 部落格系列規劃
- 個人知識庫整理
- 專案功能設計
- 技術債清理
- 長期研究主題
只要中斷後需要接回來，就值得留下脈絡。
有明確取捨的決策
如果一件事只是照著做，不一定需要 Supekku。
但如果中間有取捨，就很值得記錄。
例如：
- 為什麼這次不做完整自動化？
- 為什麼先用 Markdown，而不是資料庫？
- 為什麼先寫文章，不先做工具？
- 為什麼這個 bug 只修最小範圍？
這些問題過一段時間很容易忘。
忘記之後，人和 AI 都可能重複討論同一件事。
需要驗證的產出
只要一件事不是「寫出來就好」，而是需要確認品質，就適合加 verification。
例如：
- 程式有沒有測試通過
- 文件有沒有涵蓋必要情境
- 文章有沒有接上既有內連
- 設計有沒有符合可及性要求
- 工作流有沒有真的能重複執行
AI Agent 做完後，最重要的不是它說完成，而是它能留下什麼證據。
從收藏知識，到保存工作脈絡
我之前很長一段時間都在想個人知識庫。
怎麼記筆記，怎麼整理資料，怎麼讓 Obsidian 裡的 Markdown 能被 AI 使用，怎麼透過 RAG 找回相關內容。
但當知識可以被找到之後，下一個問題就會出現：找到之後要做什麼？
這時候就不只是 knowledge management，而是 workflow management。
不過我不太想把它做成傳統專案管理工具。太重了，也太像在管理別人。
我想要的是一種比較輕的方式：
- 想法可以先自由討論
- 需要保存時再轉成 artifact
- artifact 要能讓人讀懂
- 也要能讓 AI Agent 接手
- 做完後要有驗證和證據
這就是 Supekku Workflow 目前對我的意義。
它不是一套完美方法，也不是每件事都需要用。
但當工作開始變得模糊、跨時間、需要交接，或需要 AI Agent 參與時，我會希望有一個地方能保存這些脈絡。
因為真正難的不是讓 AI 做事。
真正難的是，當 AI 做完之後，我們還知道它為什麼這樣做、做到哪裡、怎麼確認，以及下一步該怎麼接下去。
相關文章
AI 時代的個人知識庫：Obsidian、RAG 與 Agent 該怎麼分工？
Obsidian、RAG 與 AI Agent 常被放在一起討論，但它們其實負責不同任務。本文從個人知識管理的角度，拆解 Obsidian 如何保存筆記、RAG 如何檢索資料、Agent 如何把內容轉成可執行的工作流。
搜尋引擎的下一次進化：GEO (生成式引擎優化)
在 AI 驅動的時代，傳統 SEO 的「藍色連結」正在失去光環。隨著 ChatGPT、Google AI Overviews、Perplexity 與 Bing Copilot 的崛起，使用者不再點擊網站，而是直接向 AI 要答案。
讓 AI 學會查資料：RAG 與 Embedding 技術解析
當 AI 不再只靠訓練記憶回答問題，而是能即時從你的資料中檢索再生成，這就是 RAG（檢索增強生成）的核心概念。本文從 Embedding 向量化到 Cosine Similarity 相似度計算，完整拆解 RAG 的運作原理與實務要點。
用 Slidev 把 Markdown 變成簡報網站
用 Slidev 把 Markdown 變成簡報網站，從建立專案、自訂樣式到部署上線的完整流程與踩坑紀錄。
用 LQIP 讓圖片載入不再跳來跳去
用 LQIP 技術搭配三層圖片載入策略，讓照片牆從進場到開啟大圖的每個階段都不會出現空白或版面跳動。