Kyoudesu — 技術學習與片刻紀錄

Murmur · 2026-07-20

Mon, 20 Jul 2026 00:00:00 GMT

睽違了 16 年的冠軍

2026-07-20 西班牙 1：0 阿根廷

把 Agent Session 沉澱成 Skill：我開始整理可重用工作流的方法

Mon, 01 Jun 2026 12:00:00 GMT

Agent session 最大的浪費，是做完後沒有留下方法

很多 Agent session 其實不只是單次任務。

例如一次完整的網站調整，可能包含：

先討論產品或 UX 的問題
實作元件
補測試或驗證 build
archive change
commit 到專案
最後整理出為什麼這樣做

如果這些只停在聊天紀錄裡，下次要做類似事情時，我還是得重新說一次背景、偏好、流程和驗證方式。真正有價值的不是「這次改了哪幾個檔案」，而是中間形成的判斷流程。

所以我開始把完成的 session 當成原料，整理成之後可以重用的知識。

我把產物分成 Skill、Draft 和 Project note

不是每一次 session 都應該變成同一種東西。

我目前會先判斷它比較適合沉澱成哪一類：

Skill：給 Agent 重用的操作流程。重點是觸發條件、步驟、命令、常見坑、驗證清單。
Draft：給人閱讀的文章草稿。重點是背景、問題意識、取捨、最後形成的方法。
Project note：只對某個專案有用的脈絡，例如某個 repo 的架構決策或維護規則。

這個分類很重要，因為 Skill 和文章的寫法完全不同。

Skill 不需要好看，它要可執行。文章不需要列出所有命令，它要讓讀者理解為什麼這套方法值得採用。

為什麼我採用「Skill first」

我現在傾向先寫 Skill，再寫文章。

原因是：如果先寫文章，很容易把 session 包裝成一個漂亮故事，但漏掉真正能重用的細節。例如：

什麼時候要觸發這個 workflow？
哪些情況不該用？
要先檢查什麼前置條件？
如果工具失敗，要怎麼換路徑？
最後要用什麼結果確認任務真的完成？

這些內容放在文章裡會太瑣碎，但對 Agent 下次執行任務非常重要。

所以我的順序是：

先從 session 裡抽出可重用 SOP。
把 SOP 寫成 Skill。
再從同一份材料裡提煉人類讀者會在意的故事和方法論。
最後寫成 Draft。

這樣文章不會只是操作紀錄，Skill 也不會變成散文。

什麼樣的 session 值得沉澱

不是所有聊天都值得保存。

我現在會看幾個訊號：

有 5 個以上的實際操作步驟
中間遇到非顯而易見的坑
有明確驗證方式
下次一到三個月內可能重複遇到
和我的核心工作流有關
最後形成了一個可以教給 Agent 的操作模式

如果只是一次查資料、單純問答，或只對當下有效，就不需要硬寫成 Skill。硬存太多只會讓知識庫變吵。

一次 session 裡，我會抽出哪些東西

沉澱時，我不是直接複製聊天紀錄，而是整理下面這些資訊：

這次原本要解決什麼問題
最後實際完成了什麼
中間做了哪些關鍵決策
哪些方法試過但不適合
哪些細節下次很容易忘記
需要保留的命令、檔案路徑或驗證方式
哪些內容不能放進公開文章，例如敏感憑證、私人 ID、內部端點或過細的機器資訊

這一步其實像是把「聊天」轉成「產品化後的工作流」。

聊天紀錄是時間序列；Skill 和文章則是經過編排的知識。

Skill 的內容要偏向可執行

一個好的 Skill 對 Agent 來說應該像是 SOP，而不是心得文。

我會希望 Skill 裡至少包含：

什麼情境要使用
什麼情境不要使用
前置條件
具體步驟
可能用到的命令或工具
常見錯誤，用「症狀 → 原因 → 修法」整理
最後的驗證清單

這樣下次我只要說「把這次沉澱一下」，Agent 就不需要重新猜我要的是什麼，可以直接進入整理流程。

Draft 的重點是讓讀者看懂取捨

Draft 不應該只是 Skill 的人類版。

文章要處理的是：為什麼我需要這個方法？它解決了什麼問題？我以前怎麼做？現在為什麼改成這樣？

所以文章裡會保留：

具體場景
做法的轉折
方法背後的取捨
可以被讀者借用的判斷標準

例如這次的核心不是「我建立了一個 Skill」，而是：

Agent workflow 如果只追求完成任務，很容易失去累積性；但如果每次都能把可重用部分沉澱下來，Agent 就會逐漸變成真正貼近個人工作流的助手。

這才是文章要傳達的東西。

這套流程之後會怎麼用

之後如果一個 session 完成了複雜任務，我可以直接用幾種說法觸發：

「把這次沉澱一下」
「這次可以寫成 skill」
「整理成 draft」
「把這次 session 變成 skill 和文章草稿」

Agent 接到之後，就先判斷輸出模式：

只需要 SOP：寫 Skill
有公共分享價值：Skill + Draft
主要是觀點整理：Draft
只跟專案內部有關：Project note

這讓工作流的尾聲不只是收尾，而是把這次工作變成下一次的起點。

我想保留的原則

最後，我會把這套方法壓成幾個原則：

不要讓 session 只留下結果，要留下方法。
Skill 是給 Agent 執行的，文章是給人理解的。
先保存操作細節，再寫敘事。
不是每次都值得沉澱，只有可重用的才保存。
公開前一定要做隱私檢查。

這樣 Agent 才不只是一次性工具，而是會隨著每次合作，逐步靠近我的實際工作方式。

Murmur · 2026-06-01

Mon, 01 Jun 2026 00:00:00 GMT

BEACH OPENS JUNE 1st GO GET ROBOT!!

https://www.youtube.com/watch?v=d2Mq6wxwCQA

把模糊想法變成可執行工作：我的 Supekku Workflow 設計

Thu, 28 May 2026 12:00:00 GMT

很多人開始用 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 做完之後，我們還知道它為什麼這樣做、做到哪裡、怎麼確認，以及下一步該怎麼接下去。

Murmur · 2026-05-27

Wed, 27 May 2026 00:00:00 GMT

DQ 40 週年快樂🥳

Murmur · 2026-05-20

Wed, 20 May 2026 00:00:00 GMT

拉亞這次聯名真的很讚！！！

把 Kobo 畫線同步到 Obsidian：我做了一個 Kobo Note Sync 插件

Sat, 16 May 2026 12:00:00 GMT

我想解決的不是「匯出」，而是閱讀流程的斷點

我用 Kobo 閱讀時，畫線本身不是終點。

真正重要的是：那些畫線之後能不能進入我的筆記系統，變成可以回顧、整理、引用、重新連結的材料。

但閱讀器和筆記系統之間常常有一個斷點：

Kobo 裡有畫線與註記
Obsidian 裡有我的長期筆記
中間缺少一個穩定、可重複、可客製的同步方式
如果每次都要手動複製、整理格式、補 metadata，最後很容易變成「有畫線，但沒有真正進入知識系統」。

所以我做了 Kobo Note Sync：一個把 Kobo highlights / annotations 匯入 Obsidian 的桌面插件。

Obsidian Community：https://community.obsidian.md/plugins/kobo-note-sync

https://github.com/KennKyou/obsidian-kobo-note-sync

這個插件做什麼

Kobo Note Sync 是一個 Obsidian community plugin，功能很單純：

從 Kobo 的本機 SQLite 資料庫讀取畫線與註記，然後在 Obsidian Vault 裡產生 Markdown 筆記。

目前支援兩種來源：

Kobo Desktop App 的 Kobo.sqlite（適合已經用 Kobo Desktop App 同步雲端閱讀資料的人。）
自行複製的 Kobo SQLite 檔案（例如從閱讀器裡複製出 .kobo/KoboReader.sqlite。）

大致流程像這樣：

Kobo 閱讀器 / App
→ Kobo 雲端
→ Kobo Desktop App
→ Kobo.sqlite
→ Kobo Note Sync
→ Obsidian Markdown 筆記

或是：

Kobo 閱讀器
→ 複製 KoboReader.sqlite
→ Kobo Note Sync
→ Obsidian Markdown 筆記

為什麼選擇讀本機 SQLite

我希望這個工具的資料流越單純越好。

閱讀資料其實很私密。你讀了什麼、在哪裡畫線、留下什麼註記，往往比一般瀏覽紀錄更能反映你的思考狀態。

所以這個插件的設計原則是：

只讀取你指定的本機 Kobo SQLite 資料庫
只寫入你的 Obsidian Vault
不需要外部帳號
不把閱讀資料送到任何外部伺服器

這也是為什麼它是 desktop-only plugin。它需要讀取本機檔案，而不是透過某個雲端 API 中轉。

匯入結果要是 Markdown，而不是另一個封閉資料庫

我不想把 Kobo 的畫線搬到另一個封閉系統裡。

對我來說，進入 Obsidian 的重點是：結果要是普通 Markdown。

Markdown 的好處是：

可以被 Obsidian 直接讀取
可以被 Git 備份
可以被其他工具處理
未來不依賴這個插件，也還能保留筆記內容

所以 Kobo Note Sync 匯入後，會在設定的輸出資料夾裡建立或更新 Markdown 檔案。預設資料夾是：Kobo Note Sync/

每本書可以是一份筆記，裡面包含該書的 metadata 與畫線內容。

模板是這個插件最重要的設計

每個人的筆記系統長得不一樣。

有些人想要 YAML frontmatter；有些人想要 Dataview-friendly fields；有些人只想要簡單的 quote list；也有人會把閱讀筆記接到自己的 MOC、書籍資料庫或 RAG workflow。

所以我不想把輸出格式寫死。

Kobo Note Sync 使用 Eta.js 作為模板系統，可以分開設定：

每本書的筆記模板
每條畫線的模板

例如筆記模板可以長這樣：

---
title: "<%= it.bookTitle %>"
author: "<%= it.bookAuthor %>"
publisher: "<%= it.publisher %>"
last_read: <%= it.lastRead %>
highlight_count: <%= it.highlightCount %>
source: Kobo
---

<%= it.highlights %>

畫線模板可以長這樣：

*<%= it.dateCreated %>*<% if (it.chapter) { %> | <%= it.chapter %><% } %>

> <%= it.highlightText %>
<% if (it.annotation) { %>
**Note:** <%= it.annotation %>
<% } %>
---

這樣我可以讓 Kobo 畫線融入自己的 Obsidian 結構，而不是被插件限制格式。

metadata 不是裝飾，是之後整理的入口

除了畫線文字本身，我也希望同步時保留足夠的 metadata。

Kobo Note Sync 目前提供：

23 個書籍變數
5 個畫線變數

書籍層級包含：

書名
作者
出版社
ISBN
系列名稱與編號
語言
書籍描述
閱讀進度
閱讀狀態
頁數、字數
加入日期、最後閱讀日期、完成日期
畫線數量

畫線層級包含：

畫線原文
註記內容
畫線日期
章節名稱
章節內進度

這些欄位讓閱讀筆記之後可以被整理、搜尋、篩選，也可以接到自己的 PKM workflow。

例如我可以把一本書的閱讀狀態、最後閱讀日期、畫線數量放進 frontmatter，再用 Obsidian 的查詢或其他工具整理。

採用 append-only sync 的原因

Kobo Note Sync 採用 append-only sync 的思路。

也就是說：

即使某條畫線之後在 Kobo 上被刪除，Obsidian 裡已經匯入的紀錄仍會保留。

這是刻意的。

對閱讀筆記來說，我比較在意的是「不要不小心失去已經沉澱過的內容」。

Kobo 裡的畫線可能會因為重新同步、裝置狀態、書籍版本或操作習慣而變動；但一旦進入 Obsidian，它就變成我的筆記材料，不應該被外部狀態輕易刪掉。

所以這個插件不是做雙向同步，也不是試圖讓 Kobo 和 Obsidian 永遠完全一致。

它更像是一條單向管線：

閱讀器裡的材料 → 筆記系統裡的材料

使用方式

目前使用方式大致是：

安裝插件
在設定中選擇同步來源
確認 Kobo SQLite database path
設定輸出資料夾與模板
從 Command Palette 執行 Kobo Note Sync
或點擊左側工具列的書本圖示同步

如果使用 Kobo Desktop App，macOS 預設資料庫路徑會是：

~/Library/Application Support/Kobo/Kobo Desktop Edition/Kobo.sqlite

Windows 則是：

%LOCALAPPDATA%\Kobo\Kobo Desktop Edition\Kobo.sqlite

如果使用自訂 SQLite 檔案，也可以指定自己複製出來的 KoboReader.sqlite。

在 macOS 或 Windows 的自訂 SQLite 模式下，插件也提供 Detect Kobo reader，可以嘗試自動偵測連接到電腦的 Kobo 閱讀器資料庫路徑。

目前支援的平台與語言

目前支援：

macOS
Windows

語言支援：

English
繁體中文

插件會跟隨 Obsidian 的語言設定。

這個工具適合誰

我覺得它適合幾種人：

用 Kobo 閱讀，也用 Obsidian 做長期筆記的人
想把閱讀畫線變成 Markdown 資料的人
不想把閱讀資料交給第三方同步服務的人
想用自己的模板整理閱讀筆記的人
想把書籍 metadata 接到 Dataview / PKM / RAG workflow 的人

如果你只是偶爾匯出幾條畫線，手動整理可能也夠。

但如果閱讀和筆記是長期流程，那同步工具的重點就不是省幾分鐘，而是讓資料能穩定進入系統。

我接下來可能會改善的地方

這個插件目前已經能完成基本同步，但我覺得還有一些可以繼續打磨的方向：

更完整的安裝與使用教學
更多模板範例
對不同 Kobo 資料庫版本的相容性說明
更清楚的同步結果提示
更方便的 release / community plugin 安裝流程
更多和 Obsidian 工作流整合的範例，例如 Dataview、書籍索引、閱讀回顧

尤其是模板範例，我覺得很值得補。因為真正讓這個工具變好用的，不只是「可以同步」，而是同步後的 Markdown 能不能自然融入自己的筆記系統。

結語

Kobo Note Sync 對我來說不是一個大型工具，而是一個把閱讀流程接起來的小插件。

它做的事情很明確：

Kobo 的畫線與註記 → 本機 SQLite → Obsidian Markdown

我希望閱讀時留下的片段，不只停在閱讀器裡，而是能進入我真正會整理、搜尋、回顧和重新使用的地方。

如果你也使用 Kobo + Obsidian，可以在 Obsidian Community 或 GitHub 查看：

https://community.obsidian.md/plugins/kobo-note-sync

https://github.com/KennKyou/obsidian-kobo-note-sync

AI 時代的個人知識庫：Obsidian、RAG 與 Agent 該怎麼分工？

Fri, 01 May 2026 12:00:00 GMT

以前談個人知識管理，很多人關心的是「怎麼把東西記下來」。

用什麼筆記軟體？要不要做雙向連結？資料夾怎麼分類？標籤怎麼設計？這些問題都很重要，但當筆記累積到一定數量之後，真正麻煩的通常不是記錄，而是重新取用。

你知道自己以前寫過某個想法，但找不到。你記得某篇文章提過一個概念，但忘了放在哪裡。你想寫一篇文章，結果需要翻十幾篇舊筆記、剪貼、整理、重組，最後反而卡在準備工作。

AI 出現之後，這個問題變得更有趣。

我們開始可以讓模型幫忙摘要、整理、改寫，甚至產生草稿。但如果只是把一大堆筆記丟給聊天機器人，得到的常常不是更好的知識工作流，而是一段看起來很完整、實際上不知道根據哪裡來的回答。

所以問題不是「要不要用 AI 管理筆記」。

問題是： Obsidian、RAG 和 AI Agent 各自應該負責什麼？

如果分工不清楚，最後很容易變成三種混亂疊在一起：

Obsidian 裡的筆記沒有結構
RAG 找到的資料不夠準
Agent 很努力產出內容，但你不知道它根據什麼寫出來

我比較喜歡把它們想成一套工作系統，而不是單一工具。

Obsidian：保存知識
RAG：找出相關內容
Agent：整理、重組、產出
CLI / Local workflow：把流程固定下來

這樣看，事情會清楚很多。

Obsidian 負責保存，不該負責全部

Obsidian 很適合當個人知識庫的底層。

它使用 Markdown，檔案存在本機，不太綁平台。你可以用資料夾整理，也可以用雙向連結建立脈絡。更重要的是，這些筆記不是被鎖在某個服務裡，而是你可以直接打開、搬移、搜尋、備份的一堆文字檔。

這件事在 AI 工作流裡很重要，因為只要資料是一般檔案，就可以被其他工具讀取。CLI 可以處理它，搜尋工具可以索引它，Agent 也可以直接操作它。

但 Obsidian 本身不應該負責所有事情，它不是資料庫，也不是自動化系統。它可以讓人閱讀和編輯筆記，但不會自動幫你判斷哪些內容可以合併，哪些內容可以變成文章，哪些舊筆記其實已經過期。

更麻煩的是，如果 vault 本身很亂，AI 只會把混亂放大。

例如：note1.md、new.md、untitle.md、想法.md

這種命名方式，人類自己過幾個月都不一定看得懂，更不用說要讓 Agent 穩定處理。

所以在談 RAG 或 Agent 之前，Obsidian vault 本身至少要有基本結構。

不一定要很複雜，但要穩定。例如：

vault/
├─ inbox/
├─ notes/
├─ refs/
├─ drafts/
├─ projects/
├─ meetings/
└─ templates/

每個資料夾的用途要清楚：

inbox/ 放還沒整理的零散內容
notes/ 放長期保存的知識筆記
refs/ 放外部文章、書籍、資料來源
drafts/ 放文章草稿
projects/ 放專案相關筆記
meetings/ 放會議紀錄
templates/ 放固定格式

Frontmatter 也最好維持一致。

---
title: RAG 與個人知識庫
created: 2026-05-28
tags:
  - rag
  - obsidian
  - ai-agent
status: draft
---

這些東西看起來很瑣碎，但它們是後面工作流能不能穩定的基礎。

Obsidian 的價值不是自動化，而是讓知識保持可讀、可改、可長期保存。

RAG 負責查到正確資料

RAG 的全名是 Retrieval-Augmented Generation，中文通常翻成檢索增強生成。

名字聽起來很大，但放在個人知識庫裡，它做的事情其實很直覺：

先查資料，再讓 AI 回答。

這解決的是 LLM 很常見的一個問題：模型很會生成文字，但不一定知道你的資料。

如果你問模型「我之前寫過哪些關於 Obsidian 的想法？」它不可能憑空知道你的 vault 裡有什麼。除非你把相關內容提供給它，否則它只能猜。

RAG 的角色就是補上這一段。

大致流程會像這樣：

1. 將筆記切成 chunks
2. 用 embedding 模型把文字轉成向量
3. 儲存到向量資料庫或索引中
4. 查詢時，把問題也轉成向量
5. 找出語意上最接近的筆記片段
6. 把這些片段交給 LLM 生成回答

這裡最重要的不是「用了多厲害的模型」，而是檢索結果有沒有找對東西。

如果 RAG 找到的內容不相關，後面的 LLM 寫得再流暢也沒有用，它只是把錯的上下文包裝得比較像答案。

對個人知識庫來說，RAG 最大的價值不是讓 AI 變聰明，而是讓 AI 少一點亂猜。

例如你想寫一篇關於「AI 筆記工作流」的文章，RAG 可以先幫你找出：

你以前寫過的 Obsidian 筆記
關於 RAG 的技術整理
你保存過的外部文章摘錄
相關專案中的決策紀錄
曾經寫到一半的草稿

這些資料被找出來之後，Agent 才有東西可以操作。沒有 RAG 的 Agent 很容易變成單純的聊天機器人，有 RAG 的 Agent 才比較像是在你的資料上工作。

但 RAG 也不是魔法，它很吃幾個前置條件：

筆記切分方式是否合理
每個 chunk 是否保留足夠上下文
metadata 是否有標題、日期、標籤、來源
查詢語句是否清楚
檢索結果是否需要 rerank
過期筆記是否仍然被搜出來

所以 RAG 不是裝上去就好，它比較像是給知識庫加上一層語意搜尋能力。

搜尋變好了，但內容本身還是要整理。

Agent 負責把資料變成行動

如果說 RAG 是「找資料」，Agent 就是「用資料做事」。

這是兩者最重要的差別。

RAG 找出相關筆記，然後呢？如果最後還是要你自己一篇篇打開、複製、貼上、整理，那它只是比較聰明的搜尋。

Agent 的價值在於它可以執行多步驟任務。

例如：

1. 搜尋和某個主題相關的筆記
2. 讀取這些筆記
3. 整理出共同觀點
4. 找出重複或矛盾的地方
5. 產生文章大綱
6. 寫入 drafts/
7. 等人類最後編輯

這裡的關鍵不是「AI 幫我寫文章」，而是「AI 幫我處理寫作前最耗力的整理工作」。

以部落格寫作來說，Agent 很適合做這些事：

從舊筆記中整理主題
把零散想法變成大綱
根據既有文章風格產生初稿
補上可延伸閱讀的內部連結
檢查文章是否有重複段落
幫草稿補 frontmatter
把會議紀錄整理成可追蹤的 action items

但它不適合完全接管判斷。

我不會讓 Agent 自動決定哪些筆記應該刪除，也不會讓它直接把一批舊文章全部改寫後覆蓋。這些事情太容易出問題，而且錯了不一定馬上看得出來。

比較安全的方式是讓 Agent 產生新檔案，而不是直接覆蓋原始資料。

例如：

notes/obsidian-ai-workflow.md
refs/rag-embedding-notes.md
refs/local-first-ai.md

↓ Agent 整理

drafts/ai-personal-knowledge-base-outline.md

這樣原始筆記還在，AI 輸出也可以檢查。你可以接受、修改，或整份刪掉。

Agent 應該像一個能幫你整理書桌的人，而不是一個可以自己丟掉你所有文件的人。

CLI 讓流程變得可重複

只用聊天介面操作 AI，常常會有一個問題：流程很難重複。

今天你貼了三篇筆記，請 AI 整理成大綱。明天你又貼了五篇，請它照昨天的方式處理。過幾天你忘了 prompt 怎麼寫，輸出格式又變了。

如果只是偶爾使用，這沒什麼問題。但如果你想把它變成長期工作流，就需要更固定的流程。

這時候 CLI 或本機腳本就很有用。你可以把任務拆成幾個明確步驟：

read → retrieve → transform → write → review

例如一個「產生文章草稿」的流程可能是：

1. 從 notes/ 和 refs/ 搜尋主題
2. 找出最相關的 10 個片段
3. 將片段整理成文章大綱
4. 根據大綱產生初稿
5. 寫入 drafts/
6. 保留來源引用，方便人工檢查

這樣做的好處是，每一步都可以被檢查。

如果結果不好，你可以知道問題在哪裡：

是資料找錯？
是 chunk 太小？
是 prompt 寫得不清楚？
是 Agent 寫作風格太平？
是原始筆記本來就不夠完整？

工作流一旦拆開，就比較容易修。

這也是我覺得 local-first workflow 很有吸引力的地方。它不是把所有東西都交給某個雲端服務，而是讓資料、流程和輸出都盡量留在自己可控的環境中。

一個最小可行的個人知識工作流

如果要從零開始，不需要一開始就做完整 RAG 系統，也不需要馬上接很多 Agent 工具。

可以先從一個很小的流程開始。

例如：把零散筆記整理成文章大綱。

1. 先整理資料夾

vault/
├─ inbox/
├─ notes/
├─ refs/
└─ drafts/

先不用太多分類。能穩定使用比較重要。

2. 統一筆記格式

每篇筆記至少有標題、日期、標籤、狀態。

---
title: AI agent 與筆記整理
created: 2026-05-28
tags:
  - ai-agent
  - obsidian
status: note
---

3. 把原始想法放進 inbox

不要急著整理。先收集。

inbox/2026-05-28-ai-writing-ideas.md
inbox/2026-05-28-rag-notes.md

4. 定期整理成 notes 或 refs

自己判斷哪些是長期有用的想法，哪些只是暫時資料。

notes/personal-knowledge-base.md
refs/rag-retrieval-notes.md

5. 讓 Agent 產生草稿

任務可以寫得很具體：

請讀取 notes/ 和 refs/ 中與 "AI 個人知識庫" 相關的筆記，整理出一篇部落格文章大綱，輸出到 drafts/ai-personal-knowledge-base.md。

請保留引用到的來源筆記檔名，不要修改原始筆記。

這裡有幾個重點：

指定讀取範圍
指定輸出位置
要求保留來源
明確禁止修改原始筆記

這樣 Agent 比較不會亂跑。

6. 人類最後編輯

最後一步還是要回到人。

AI 可以整理資料，但文章裡真正重要的通常是你的判斷：

哪個觀點你認同？
哪個工具你用起來其實不順？
哪些流程看起來很美，但實際上很難維持？
哪些限制你踩過坑？

這些東西 AI 可以模仿，但最好不要讓它憑空發明。

不要把所有事情都交給 AI

AI 很適合處理文字工作，但不是所有文字工作都該交給它。

尤其是個人知識庫，裡面的東西通常很雜。有些是公開資料，有些是私人想法，有些可能包含工作內容、客戶資訊、會議紀錄或尚未整理的判斷。

幾件事我會特別避免：

不要讓 AI 自動刪筆記

刪除是不可逆的知識管理動作。

AI 可以建議哪些筆記可能重複，或哪些內容可能已經過期，但最後要不要刪，最好還是自己決定。

比較安全的做法是：

archive/

先歸檔，不要直接刪。

不要讓 AI 決定最終觀點

AI 很會把資料整理成看似平衡的說法，但文章真正有價值的地方常常不是平衡，而是取捨。

你可以讓 AI 幫忙列出不同觀點，但最後應該由你決定文章要站在哪裡。

不要讓 AI 把未確認內容寫成事實

這在草稿裡很常見。

例如 AI 可能會把「我猜這可能跟效能有關」改成「這會導致效能問題」。語氣變得更肯定，但事實基礎沒有變多。

所以最好在 prompt 裡要求它區分：

已確認事實
推測
待查證
個人觀點

不要讓 AI 大規模覆蓋 vault

批次修改很誘人，但也很危險。

尤其是 frontmatter、標籤、連結這些東西，一次改錯可能會讓整個 vault 的結構變得很難追。

我比較建議 Agent 先輸出修改建議，或產生 patch，再由人確認。

不要忽略資料隱私

如果筆記裡有敏感資料，就要想清楚模型在哪裡執行。

本機模型、雲端模型、公司內部模型，風險不一樣。不是所有內容都適合送出去。

知識庫會從收藏系統變成產出系統

過去建立個人知識庫，常常像是在建立一個收藏系統。

看到好文章，存起來。想到好句子，記下來。讀到有用的概念，放進筆記。

這些都沒錯，但收藏本身不會自動變成產出。

AI Agent 出現之後，個人知識庫開始有另一種可能：它不只是保存資訊，而是可以被查詢、整理、重組，最後變成文章、簡報、決策紀錄或專案文件。

但前提是分工要清楚。

Obsidian 負責保存。
RAG 負責檢索。
Agent 負責操作。
CLI 或固定流程負責讓這件事可以重複。

如果這幾層混在一起，很容易變成一套看起來很先進、實際上很難維護的系統。

我現在比較相信的方向是：先不要追求全自動。

先讓 AI 幫你完成一個小任務就好。

例如：

把三篇舊筆記整理成一篇文章大綱。

如果這件事穩定，再往下做：

把一週的 inbox 整理成 notes。

再更進一步：

從 notes 和 refs 產生草稿。

個人知識庫不需要一開始就變成完整的 AI 系統。它可以從一個資料夾、一種筆記、一個流程開始。

重點不是讓 AI 替你思考，而是讓你過去累積的知識更容易被重新使用。

這可能才是 AI 對個人知識管理最實際的幫助。

Murmur · 2026-05-01

Fri, 01 May 2026 00:00:00 GMT

Komeda 跟寶可夢聯名好可愛😍

用 LQIP 讓圖片載入不再跳來跳去

Mon, 06 Apr 2026 12:00:00 GMT

瀏覽有大量圖片的網頁時，應該都遇過這種情況：圖片還沒載入完成，畫面就一直跳動，文字被推來推去，或是圖片從上到下一條一條慢慢出現。這些體驗都不太好，尤其在網速較慢的環境下會更明顯。

LQIP（Low Quality Image Placeholder）是一種常見的圖片載入優化技術，核心概念很簡單：在原始圖片還沒下載完成之前，先用一張極小的低畫質圖片當作佔位，等實際要顯示的圖載入完成後再替換上去。

為什麼需要 LQIP？

如果只是把 <img> 丟上去什麼都不處理，會遇到兩個問題：

版面跳動（Layout Shift）：圖片載入前沒有預留空間，載入後把其他內容擠開，造成 CLS（Cumulative Layout Shift）分數變差
載入體驗差：圖片從空白到完整顯示的過程中，要嘛是一片空白，要嘛是一條一條慢慢出現，使用者會覺得頁面還在「壞掉」的狀態

LQIP 同時解決了這兩個問題：透過預先知道圖片的寬高比來預留空間，再用一張模糊的縮圖做視覺過渡，整個載入過程會流暢很多。

我的做法

我在自己的照片牆專案被光保存的瞬間中實作了這個技術。這個專案會一次顯示大量照片，每張照片又有高解析度的原圖，很適合拿來做這種優化。

整體流程分成三個階段：上傳時預處理、照片牆渲染、Lightbox 原圖載入。

上傳時預處理

在圖片上傳到後端時，我會做三件事：

記錄原圖的寬高：用來計算 aspect ratio，讓前台在任何圖片載入前就能預留正確的空間
產生 blurDataUrl：把圖片壓縮成極小尺寸（寬度大概 20~32px），轉成 base64 字串直接存進資料庫
產生 thumbnail：壓縮成適合在照片牆上瀏覽的中等尺寸縮圖，上傳到儲存空間

// 概念上的處理流程
const metadata = await sharp(imageBuffer).metadata()
const { width, height } = metadata

// 產生 base64 模糊圖
const blurBuffer = await sharp(imageBuffer)
  .resize(32)
  .blur(1)
  .toBuffer()
const blurDataUrl = `data:image/jpeg;base64,${blurBuffer.toString('base64')}`

// 產生 thumbnail
const thumbnailBuffer = await sharp(imageBuffer)
  .resize(480)
  .toBuffer()

// 儲存：原圖 URL、thumbnail URL、blurDataUrl、寬高

blurDataUrl 是 base64，可以直接跟著 API 回應一起回來，不需要額外的 HTTP 請求。一張 32px 寬的模糊圖通常只有幾百 bytes，對回應大小幾乎沒有影響。

照片牆渲染：blurDataUrl → thumbnail

頁面載入後，每張照片的載入會經過兩個階段：

立即顯示 blurDataUrl：因為是 base64，不需要任何網路請求，頁面一渲染就能看到模糊的佔位圖，同時 aspect ratio 也已經是正確的
thumbnail 載入完成後替換：瀏覽器在背景下載 thumbnail，下載完成後替換掉模糊圖

<template>
  <div
    class="image-wrapper"
    :style="{ aspectRatio: `${image.width} / ${image.height}` }"
    @click="openLightbox(image)"
  >
    <!-- 底層：blurDataUrl 作為佔位 -->
    <img :src="image.blurDataUrl" class="blur-placeholder" />

    <!-- 上層：thumbnail 載入完成後顯示 -->
    <img
      :src="image.thumbnailUrl"
      :class="{ loaded: thumbnailLoaded }"
      class="thumbnail"
      @load="thumbnailLoaded = true"
    />
  </div>
</template>

.image-wrapper {
  position: relative;
  overflow: hidden;
  cursor: pointer;
}

.blur-placeholder,
.thumbnail {
  position: absolute;
  inset: 0;
  width: 100%;
  height: 100%;
  object-fit: cover;
}

.thumbnail {
  opacity: 0;
  transition: opacity 0.3s ease;
}

.thumbnail.loaded {
  opacity: 1;
}

使用者看到的效果是：頁面一打開，所有照片的位置就已經排好，每張都是模糊但有輪廓的樣子。接著 thumbnail 陸續載入完成，一張一張從模糊變清晰，整個過程很順暢，沒有版面跳動。

Lightbox 原圖載入：thumbnail → 原圖

使用者在照片牆上點擊某張照片後，會打開 Lightbox 來查看原始解析度的大圖。這時候又是一次從小圖到大圖的載入過程，一樣可以套用同樣的策略：

先顯示 thumbnail：因為 thumbnail 已經在照片牆階段載入過了，瀏覽器有快取，可以瞬間顯示
原圖載入完成後替換：高解析度原圖下載完成後，替換掉 thumbnail

<!-- Lightbox -->
<div class="lightbox" v-if="currentImage">
  <img :src="currentImage.thumbnailUrl" class="lightbox-placeholder" />
  <img
    :src="currentImage.originalUrl"
    :class="{ loaded: originalLoaded }"
    class="lightbox-original"
    @load="originalLoaded = true"
  />
</div>

因為 Lightbox 中的 thumbnail 已經被快取過，使用者點開後會先看到一張稍微模糊但完整的圖，而不是一片空白等原圖慢慢載入。原圖載入完成後再無縫切換成高解析度版本。

三層載入的完整流程

整理一下使用者實際看到的體驗：

階段	顯示內容	來源	等待時間
頁面載入	模糊佔位圖	blurDataUrl（base64）	無，瞬間顯示
thumbnail 載入完成	清晰縮圖	thumbnail URL	視網速而定
點擊照片，原圖載入完成	高解析度原圖	原圖 URL	視網速與圖片大小而定

每一層都不會出現空白或版面跳動，使用者在任何時刻都能看到「有東西」的畫面。

總結

LQIP 的實作不複雜，核心就是讓每個階段都有東西可以顯示：

上傳時：記錄寬高、產生 base64 模糊圖（blurDataUrl）、產生 thumbnail
照片牆：先顯示 blurDataUrl，thumbnail 載入後替換
Lightbox：先顯示已快取的 thumbnail，原圖載入後替換

在圖片量大或原圖解析度高的場景下，這種分層載入的效果會特別明顯。與其讓使用者盯著空白方塊等圖片慢慢冒出來，不如在每個階段都給他一個「夠用」的畫面。

用 Slidev 把 Markdown 變成簡報網站

Wed, 01 Apr 2026 12:00:00 GMT

最近需要在會議上做簡報，與其用 PowerPoint 或 Google Slides，不如直接做成一個網站，隨時打開瀏覽器就能展示。最後選擇了 Slidev 這個框架，用 Markdown 寫投影片，搭配一些簡單的動效，最終部署成純靜態網站。

這篇文章會分享從技術選型到部署上線的過程，以及一些使用上的心得。

https://github.com/slidevjs/slidev

為什麼選 Slidev

一開始有考慮過幾個方案：

方案	優點	缺點
Slidev	Markdown 撰寫、Vue 組件擴展、內建動效和樣式系統	依賴 Vue 生態
reveal.js	老牌、外掛多	需要寫比較多 HTML，客製化不太方便
自己刻	完全自由	要自己造翻頁、鍵盤控制、transition 等輪子

Slidev 最吸引我的地方是用 Markdown 就能寫投影片，而且如果需要更複雜的排版，隨時可以在 Markdown 裡面穿插 HTML 和 Vue 組件。內建的 UnoCSS 讓樣式也不用額外設定，寫法跟 Tailwind CSS 幾乎一樣。

建立專案

npm init -y
npm install @slidev/cli @slidev/theme-default

在 package.json 加入 scripts：

{
  "scripts": {
    "dev": "slidev",
    "build": "slidev build"
  }
}

接著建立 slides.md，這就是你的整份簡報：

---
theme: default
transition: slide-left
title: My Presentation
---

# Hello

This is the first slide.

---

# Second Slide

This is the second slide.

每一頁用 --- 分隔，最上面的 --- 區塊是全域設定。跑 npm run dev 就能在瀏覽器看到結果了。

投影片結構

因為這是個人簡介，內容不是技術導向，我把它設計成一個比較有節奏感的流程：文字頁和圖片頁交替出現。

封面 → 個人照＋簡介 → 主題文字 → 搭配照片 → 主題文字 → 搭配照片 → ... → 結尾

每個主題都拆成獨立的頁面，不會把太多東西塞在同一頁。這樣在操作的時候節奏會比較好，聽眾也比較容易跟上。

自訂樣式

Slidev 預設的樣式比較中性，如果想要有自己的風格，可以在 styles/ 資料夾裡覆寫。建立 styles/index.ts 作為進入點：

import './custom.css'

然後在 custom.css 裡面寫你的樣式：

.slidev-layout {
  background: #f5f0eb !important;
  color: #3a3a3a !important;
  font-family: 'Noto Sans TC', sans-serif !important;
}

這裡的 .slidev-layout 是每一頁投影片的最外層容器，用 !important 覆蓋預設 theme 的樣式。

如果要讓所有頁面都使用同一張背景圖，也可以直接寫在這裡：

.slidev-layout {
  background: url('/images/bg.jpg') center / cover no-repeat !important;
}

圖片放在 public/images/ 下，Slidev 會把 public/ 作為靜態資源的根目錄。

使用 Vue 組件

如果某些排版用純 Markdown 不好實現，可以建立 Vue 組件。把 .vue 檔放在 components/ 資料夾下，Slidev 會自動註冊，直接在 Markdown 裡面用就好：

<script setup lang="ts">
defineProps<{
  name: string
  level: number
}>()
</script>

<template>
  <div class="mb-4">
    <div class="flex justify-between mb-1">
      <span class="text-sm">{{ name }}</span>
      <span class="text-xs">{{ level }}%</span>
    </div>
    <div class="w-full rounded-full h-1.5" style="background: #d4cac0;">
      <div
        class="h-1.5 rounded-full"
        style="background: #8c7b6b;"
        :style="{ width: `${level}%` }"
      />
    </div>
  </div>
</template>

在 slides.md 裡直接使用：

<SkillBar name="Vue.js" :level="90" />
<SkillBar name="TypeScript" :level="85" />

動效

頁間切換

在全域 frontmatter 設定預設的 transition：

---
transition: slide-left
---

也可以在個別頁面的 frontmatter 覆寫：

---
transition: fade
---

逐步顯示

用 <v-click> 包住想要按下一步才出現的內容：

# Title

<v-click>

This text appears after clicking.

</v-click>

這在會議上很實用，可以控制資訊出現的時機，不會一次全部秀出來。

元素進場動畫

如果想要更細緻的動畫效果，可以安裝 @vueuse/motion：

npm install @vueuse/motion

然後在 HTML 標籤上加 v-motion directive：

<div v-motion
  :initial="{ opacity: 0, y: 15 }"
  :enter="{ opacity: 1, y: 0, transition: { duration: 1000 } }">
  Content here
</div>

踩到的坑

Markdown 裡的 HTML 縮排會變成 code block

這大概是最容易踩到的問題。在 slides.md 裡面寫 HTML 時，如果縮排超過 4 個空格，Markdown parser 會把它當成程式碼區塊，整段 HTML 就會被原封不動地顯示出來。

解決方法就是把巢狀 HTML 的縮排壓平，不要超過 3 個空格。雖然可讀性會差一點，但至少能正常渲染。

`` 巢狀問題

如果在  標籤裡面放了 Markdown 文字，Slidev 會把文字解析成 ，導致  裡面又有 ，瀏覽器會報 hydration warning。解決方法是外層改用 <div>。

第一頁空白

全域 frontmatter 區塊本身也會被渲染成一頁投影片。如果你的第一頁是封面，可以直接把封面內容跟全域設定放在同一個 frontmatter 區塊裡，加上 layout: none 然後自己排版。

部署

npm run build 會在 dist/ 產出純靜態的 HTML/CSS/JS，可以部署到任何靜態網站託管服務。

我是部署到 Zeabur ，連接 GitHub repo 後設定好 build command（npm run build）和 output directory（dist）就完成了。

如果是部署到 GitHub Pages 之類有 sub-path 的服務，記得在 build 時加上 --base 參數：

slidev build --base /your-repo-name/

操作快捷鍵

在會議上用筆電操作時，這些快捷鍵很實用：

快捷鍵	功能
→ / Space	下一頁
←	上一頁
o	總覽模式（快速跳頁）
f	全螢幕

這些都是 Slidev 內建的，不需要額外設定。

心得

用 Slidev 做簡報最大的好處是，它就是一個前端專案。想要什麼樣式就寫 CSS，想要什麼互動就寫 Vue 組件，不會被簡報軟體的功能限制住。而且因為是 Markdown，內容的維護和版本控制都很方便。

比較需要注意的是，Slidev 畢竟是把 Markdown 轉成 Vue 組件再渲染，有些 Markdown 和 HTML 混用的邊界情況會比較奇怪（像上面提到的縮排和巢狀問題），需要花一點時間摸索。

整體來說，如果你本身有前端開發的經驗，用 Slidev 做簡報會很順手，也能做出比傳統簡報軟體更有個人風格的東西。

讓 AI 學會查資料：RAG 與 Embedding 技術解析

Sun, 29 Mar 2026 12:00:00 GMT

什麼是 RAG？

Retrieval-Augmented Generation（檢索增強生成）是一種結合「資料檢索」與「AI 生成」的技術架構。它讓 AI 不再只依賴訓練時學到的知識，而是在回答問題的當下，即時從你的資料庫中找到最相關的內容，再據此生成回答。

簡單說：RAG 讓 AI 擁有「查資料再回答」的能力。

為什麼需要 RAG？

純粹的大型語言模型（LLM）有幾個根本性的限制：

知識截止日期： 模型只知道訓練資料中的內容，無法回答訓練後發生的事。
幻覺問題 (Hallucination)： 當模型不確定答案時，它會「自信地編造」看似合理的內容。
無法存取私有資料： 你的產品文件、內部知識庫、部落格文章，模型一概不知。

RAG 的出現就是為了解決這些問題——讓 AI 的回答有據可查，而不是憑空捏造。

RAG 的運作流程

一個完整的 RAG 系統通常包含三個階段：

索引 (Indexing)： 將你的文件內容切割成小段落（Chunks），並透過 Embedding 模型轉換為向量，存入資料庫。
檢索 (Retrieval)： 當使用者提出問題時，將問題同樣轉換為向量，然後透過相似度比對，從資料庫中找出最相關的段落。
生成 (Generation)： 將找到的相關段落作為上下文（Context），連同使用者的問題一起送給 LLM，讓它基於這些真實資料生成回答。

關鍵點：RAG 的品質取決於「檢索」的精準度。如果第 2 步找到的段落不相關，第 3 步的回答再流暢也沒有意義。

什麼是 Embedding？

Embedding（嵌入向量）是 RAG 的核心基礎設施。它的作用是將文字轉換成一組數字（向量），讓電腦能夠理解文字之間的「語意距離」。

舉例來說：

文字	向量（簡化示意）
「JavaScript 的非同步處理」	[0.82, -0.15, 0.43, ...]
「JS async/await 錯誤處理」	[0.79, -0.12, 0.41, ...]
「今天晚餐吃什麼」	[-0.31, 0.67, -0.22, ...]

前兩句話語意相近，因此向量數值也接近；第三句話完全不相關，向量方向截然不同。這就是 Embedding 的威力——它捕捉的是語意，而非關鍵字。

Embedding 的技術細節

模型選擇

常見的 Embedding 模型各有特色：

模型	維度	多語言	適用場景
text-embedding-3-small (OpenAI)	1536	是	通用場景、商業應用
intfloat/multilingual-e5-small	384	是	輕量部署、中文支援佳
BAAI/bge-m3	1024	是	高精度多語言檢索
all-MiniLM-L6-v2	384	否	英文為主的輕量場景

維度越高，理論上能表達越細緻的語意差異，但也意味著更大的儲存空間與更高的運算成本。對大多數應用來說，384 維已經足夠。

Chunking 策略

在生成 Embedding 之前，必須先將長文切割成適當大小的 Chunks。這一步驟直接影響檢索品質：

太大的 Chunk： 包含過多不相關資訊，稀釋了語意焦點。
太小的 Chunk： 失去上下文，導致語意不完整。
最佳實踐： 以段落為自然切割點，每個 Chunk 控制在 200–500 tokens，確保語意完整且聚焦。

相似度計算

有了向量之後，如何判斷兩段文字有多「相似」？最常用的方法是 Cosine Similarity（餘弦相似度）：

similarity = (A · B) / (|A| × |B|)

結果範圍為 -1 到 1，越接近 1 表示越相似。
它衡量的是向量的「方向」而非「長度」，因此不受文字長短影響。

RAG vs. Fine-tuning：什麼時候該用哪個？

比較面向	RAG	Fine-tuning
適用情境	資料經常更新、需要引用來源	需要改變模型的語氣或行為模式
資料更新	即時，只需更新向量資料庫	需要重新訓練模型
成本	低，主要是儲存與檢索	高，需要 GPU 運算時間
幻覺控制	強，回答基於實際資料	弱，仍可能編造
可解釋性	高，可追溯引用來源	低，無法得知答案依據

如果你的需求是「讓 AI 知道你的資料」，選 RAG；如果需求是「讓 AI 變成你的語氣」，選 Fine-tuning。

實際應用場景

RAG + Embedding 的組合已經被廣泛應用：

知識庫問答： 企業內部文件搜尋，員工直接用自然語言提問。
智慧客服： 基於產品文件與 FAQ 自動生成精準回答。
相關內容推薦： 部落格、新聞網站透過語意相似度推薦相關文章。
程式碼搜尋： 在大型 codebase 中用自然語言找到相關的函式或模組。
個人化學習： 將教材向量化，根據學生提問推薦最相關的章節。

建構 RAG 系統的注意事項

Chunking 品質比模型選擇更重要。 再好的 Embedding 模型也救不了切割混亂的文件。
Query 與 Document 的格式要一致。 某些模型（如 E5 系列）要求查詢加 "query: " 前綴、文件加 "passage: " 前綴，忽略這點會嚴重影響檢索品質。
向量資料庫的選擇取決於規模。 幾千筆資料用 MongoDB 或 PostgreSQL + pgvector 就夠；百萬級以上才需要考慮 Pinecone、Milvus 等專用方案。
定期重建索引。 當內容更新後，舊的向量不會自動失效，需要機制確保向量與原文同步。

總結

RAG 與 Embedding 的結合，解決了 AI 應用中最關鍵的問題：如何讓模型的回答基於事實而非猜測。Embedding 負責讓機器「理解」文字的語意，RAG 負責在對的時機把對的資料送到 AI 手中。

Embedding 讓文字有了座標，RAG 讓 AI 學會查資料。兩者結合，AI 才從「很會說話」進化成「說得有根據」。

Murmur · 2026-03-15

Sun, 15 Mar 2026 00:00:00 GMT

精神時光屋

Murmur · 2026-03-09

Mon, 09 Mar 2026 00:00:00 GMT

這次 WBC 沒機會看到陳冠宇登板投球了😭

Murmur · 2026-03-05

Thu, 05 Mar 2026 00:00:00 GMT

《おかえりジョニー》

傳遞著做自己的溫暖訊息

https://www.youtube.com/watch?v=2VelYboi-ZM

Murmur · 2026-02-27

Fri, 27 Feb 2026 00:00:00 GMT

看完《Pokémon Presents 2026.2.27》後，覺得今年有好多時間可以慢慢回去玩究極之日跟終極紅寶石了😴

Murmur · 2026-02-18

Wed, 18 Feb 2026 00:00:00 GMT

電子書閲讀器真的是會無性繁殖的東西

搜尋引擎的下一次進化：GEO (生成式引擎優化)

Sat, 14 Feb 2026 12:00:00 GMT

什麼是 GEO？

Generative Engine Optimization (生成式引擎優化) 是一套針對 AI 搜尋與生成式系統設計的內容優化策略。其目標不再只是爭奪搜尋結果頁 (SERP) 的第一名，而是確保你的內容被 AI 引用、摘要並呈現給使用者。

為什麼現在需要 GEO？

使用者行為正在轉變：

直接獲取資訊：使用者傾向閱讀 AI 整合後的回答，而非逐一挑選連結。
對話式搜尋：關鍵字（Keywords）逐漸被問題（Prompts）取代。
零點擊流量 (Zero-Click)： AI 直接給出答案，導致進入網站的點擊率下降，但品牌曝光的質量提升。

比較面向	傳統 SEO	生成式 GEO
目標系統	Google / Bing 傳統演算法	LLM (大型語言模型) / RAG 系統
核心指標	關鍵字排名、點擊率 (CTR)	引用頻率、回答可見度 (Answer Visibility)
使用者行為	點擊連結、進入網站瀏覽	直接從 AI 生成的內容獲取解答
內容重點	關鍵字密度、反向連結權威性	可引用性、結構清晰度、數據支持
核心目標	如何排到第一頁？	如何被 AI 選為最佳答案來源？

GEO 的運作原理：AI 如何挑選你？

AI 搜尋引擎（如 Perplexity 或 Google AI Overviews）在生成回答時，通常遵循以下 RAG (Retrieval-Augmented Generation) 流程：

檢索 (Retrieval)：從網路中抓取與問題最相關的來源。
評估 (Ranking)：評估來源的可信度、相關性與資訊完整度。
生成 (Generation)：整合多個來源，生成連貫的回答並標註引用來源。

關鍵點：你的內容必須在「步驟 1」被抓到，並在「步驟 2」被判定為高品質，才可能出現在「步驟 3」的最終回答中。

GEO 的七大核心策略

1. 提升內容的引用適切性 (Citability)

AI 偏好結構化、易於摘錄的片段。

使用明確的標題層級 (H2, H3)。
每個段落聚焦單一概念，並提供清晰的定義句（如：「X 是指...」）。
善用表格與條列式清單，這類格式極易被 AI 抓取。

2. 深化 E-E-A-T (經驗、專業、權威、可信)

Experience：分享第一手實測經驗或獨特案例。
Expertise：引用專業數據、研究報告，展現深度。
Authoritativeness：強化品牌與作者在特定領域的專業關聯。
Trustworthiness：標註清楚的資料來源、日期與專家審核資訊。

3. 問題導向的內容設計

預測使用者會如何「問」AI，而不只是搜尋什麼關鍵字。

使用 FAQ 結構 撰寫內容。
針對長尾問句（How, Why, What is...）提供直接且精準的回答。

4. 強化結構化資料 (Schema Markup)

使用 Schema.org 標記（如 FAQPage, HowTo, Article），協助 AI 爬蟲精確理解內容的語意角色與邏輯關係。

5. 語意完整性 (Semantic Completeness)

AI 傾向引用能「一站式」解決問題的頁面。

避免過於破碎的內容，應建立主題群 (Topic Cluster)。
確保頁面涵蓋了該主題的背景、原因、操作方法與實際案例。

6. 引用統計數據與原創研究

AI 非常喜歡引用具體數字。

自行發布原創調查或測試報告（Benchmark）。
引用可信的第三方權威數據，並附上來源。

7. 維持內容新鮮度 (Freshness)

定期更新舊文並標註「最後更新日期」。AI 在處理時事或技術性話題時，具有「時效性優先」的傾向。

如何衡量 GEO 的成效？

由於 GEO 是一個新興領域，目前的衡量指標與傳統不同：

品牌提及頻率 (Brand Mention Frequency)：你的品牌在 AI 回答中出現的次數。
引用率 (Citation Rate)： AI 在生成回答時引用你網站連結的比例。
回答引擎可見度：手動測試各平台，觀察品牌是否出現在 AI Overviews 或 Perplexity 的來源卡片中。

對既有 SEO 的影響

GEO 並非取代 SEO，而是延伸與進化。

良好的 SEO 是 GEO 的基礎 —— 技術健全、內容優質、反向連結強的網站，在 AI 搜尋中同樣具有優勢。

但 GEO 進一步要求內容不只是「可被找到」，更要「可被理解與摘錄」。這對內容策略、資訊架構、以及 UX 寫作都提出了新的要求。

總結

GEO 代表搜尋行為演進的下一個階段。隨著使用者越來越習慣透過 AI 直接獲取答案，能夠讓 AI「選擇你的內容作為答案」，將成為未來數位行銷與內容策略的核心競爭力。簡單說：

SEO 讓你被找到，GEO 讓你成為答案。

Murmur · 2026-01-27

Tue, 27 Jan 2026 00:00:00 GMT

新的翻頁器 Ꮚ･ꈊ･Ꮚ

Murmur · 2026-01-12

Mon, 12 Jan 2026 00:00:00 GMT

肯尼要繼續跟股菇好好相處哦

Murmur · 2025-12-31

Wed, 31 Dec 2025 00:00:00 GMT

サカナクション最高だ

Murmur · 2025-11-09

Sun, 09 Nov 2025 00:00:00 GMT

度過一個愉快的週末

Murmur · 2025-07-25

Fri, 25 Jul 2025 00:00:00 GMT

在看 Fuji Rock 的時候，被 Vaundy 的《しわあわせ》驚艷到一直起雞皮疙瘩

https://www.youtube.com/watch?v=3SR57oeegws

Murmur · 2025-03-30

Sun, 30 Mar 2025 00:00:00 GMT

看完大港的 Chilli Beans. 直接被圈粉

https://open.spotify.com/artist/48apiuEaHdddhdRvfFjPB7

Murmur · 2025-03-03

Mon, 03 Mar 2025 00:00:00 GMT

謝謝我的成長過程中有方大同的音樂

Murmur · 2025-01-04

Sat, 04 Jan 2025 00:00:00 GMT

在電影院看燈海、衝撞、circle pit 初體驗，還有感人的大合唱，謝謝造次的特別場

Murmur · 2024-06-23

Sun, 23 Jun 2024 00:00:00 GMT

Aimer 在《花の唄》第一次副歌結束 Pose 發現沒站到 Spotlight 中間，所以默默往後退了幾個小碎步超可愛😍

Murmur · 2023-11-25

Sat, 25 Nov 2023 00:00:00 GMT

開始認識 Ellegarden 後沒多久他們就宣布無限期暫停活動，當時沒想過有生之年可以看到他們的 Live。

直到 2018 年恢復活動加上 2019 年的火球祭讓我圓了 Ellegarden 的夢，2023 年在台灣專場更讓內心悸動🥹

這15年真的好漫長！謝謝 Ellegarden

https://open.spotify.com/playlist/6hUDofDGl3qdsodXdVFoqN

如何在 Kobo 電子書閱讀器安裝自訂字型

Mon, 20 Feb 2023 12:00:00 GMT

Kobo 閱讀器內建的中文字型選擇有限，如果你想要換一個更順眼、更適合閱讀的字型，其實只要簡單幾步就能把喜歡的字型裝進去。

下載字型

這邊以芫荽（iansui）這款開源字型來示範。芫荽是基於 Fontworks 的 Klee One 所衍生的繁體中文字型，字形經過調整以符合台灣教育部標準，筆觸帶有手寫感，很適合拿來在電子書閱讀器上閱讀。

前往芫荽的 GitHub Releases 頁面
下載最新版本的 iansui.zip
解壓縮後會得到 .ttf 字型檔

https://github.com/ButTaiwan/iansui

芫荽採用 SIL Open Font License 1.1 授權，任何人都可以免費使用，包含商業用途。

把字型匯入閱讀器

連接閱讀器：使用 USB 線將閱讀器連接到電腦
建立資料夾：在閱讀器的根目錄下新增一個名稱為 fonts 的資料夾（該資料夾有可能已經存在）
放入字型檔：把解壓縮得到的 .ttf 字型檔放到 fonts 資料夾內
退出連接：安全地退出閱讀器與電腦的連接

在閱讀器上套用字型

在閱讀器上打開任意一本書
點擊畫面中央叫出選單，點選字型相關的設定（通常是 Aa 的圖示）
在字型列表中就能看到剛剛放入的字型名稱，選擇後即可套用

套用後字型會即時生效，可以直接預覽閱讀效果。

常見問題

支援哪些字型格式？

Kobo 閱讀器支援 .ttf 和 .otf 格式的字型檔。

可以同時安裝多種字型嗎？

可以，把多個字型檔都放到 fonts 資料夾內，閱讀時就能在字型列表中自由切換。

安裝字型後會影響閱讀器的效能嗎？

一般不會有明顯影響，但如果安裝過多字型，開啟字型選單時可能會稍微慢一些。建議只保留常用的幾款字型即可。

安裝的字型會在韌體更新後消失嗎？

通常不會，fonts 資料夾在韌體更新後會保留。但建議更新前先備份字型檔，以防萬一。

所有書籍格式都能使用自訂字型嗎？

EPUB 格式的書籍可以正常套用自訂字型。但如果書籍本身有嵌入指定字型且設定為強制使用，可能會覆蓋你的選擇。PDF 格式則不支援更換字型。

如何自訂 Kobo 電子書閱讀器的待機畫面

Sun, 19 Feb 2023 12:00:00 GMT

許多閱讀器在待機時會預設顯示正在閱讀的那本書封面，雖然說 Kobo 在設定上可以取消顯示書封，但如果想讓閱讀器更有自己的特色，可以試試自訂待機畫面。

準備好圖檔

以下會用我的 Kobo Sage 來示範。

準備好想當作待機畫面的圖檔，格式建議使用 jpg 或 png。圖片尺寸需要對應你的閱讀器解析度，可以在產品官網查到，從產品的官網可以看到顯示器的解析度：

像我的 Kobo Sage 解析度是 1440x1920，所以在製作圖片時可以先設定好這個尺寸。我自己是使用 Canva 來製作，在建立設計時自訂好尺寸就可以開始設計了。

把圖檔匯入閱讀器

連接閱讀器：使用 USB 線將閱讀器連接到電腦
建立資料夾：在 .kobo 資料夾內新增一個名稱為 screensaver 的資料夾（該資料夾有可能已經存在）。如果沒有看到 .kobo 的話，在 Mac 可以按下 ⌘ Command + ⇧ Shift + . 來顯示隱藏資料夾；在 Windows 則到檔案總管的「檢視」中勾選「隱藏的項目」
放入圖片：把想作為待機畫面的圖檔放到 screensaver 資料夾內。放多張會在每次待機時隨機選擇一張顯示；放一張則固定使用該圖片
開啟設定：在閱讀器的 設定 > 省電和隱私權設定 中，把 顯示目前正在閱讀、顯示全螢幕書封 都打勾即可（不同機型的選項可能略有差異，如果打勾後沒有顯示，可以交叉測試這兩個選項的啟用狀態）

最終成果

常見問題

支援哪些圖片格式？

支援 jpg 和 png 格式。

可以放多張圖片嗎？

可以，放多張圖片到 screensaver 資料夾內，閱讀器會在每次進入待機時隨機選擇一張顯示。

圖片的建議尺寸是多少？

依照你的機型解析度來製作：

機型	解析度
Kobo Sage	1440x1920
Kobo Libra Colour	1264x1680
Kobo Libra 2	1264x1680
Kobo Elipsa 2E	1404x1872
Kobo Clara Colour	1072x1448
Kobo Clara BW	1072x1448
Kobo Clara 2E	1072x1448

設定後待機畫面沒有顯示怎麼辦？

請確認 設定 > 省電和隱私權設定 中的 顯示目前正在閱讀 和 顯示全螢幕書封 選項，交叉測試這兩個選項的開關組合，不同韌體版本的行為可能不同。

哪些 Kobo 機型支援自訂待機畫面？

大部分 Kobo 閱讀器都支援，包括 Kobo Sage、Kobo Libra、Kobo Clara、Kobo Elipsa 等。只要閱讀器內有 .kobo 資料夾就可以使用此方法。