今天要解的問題

前三天都在做 mod，今天回到 vault 本身的內容流程。

起點是一個很短的問題：我目前哪個 skill 可以把 raw 直接升級成 wiki？答案是現成的，/wiki-build {raw 路徑} --promote。它把單篇 raw 搬進 wiki/，原文不改，只補 frontmatter、sources 和 vault 內的連結。

但我真正想問的是：有時候 note-enrich 跑完的內容，其實蠻適合直接變成 wiki 頁。 回頭對照兩個 skill 的規格，發現接不起來：

1. promote 的適用範圍寫的是「使用者自己寫、已經完整」的 raw。enrich 過的檔有一部分是網路素材，照字面不算在內
2. note-enrich 結束時只會提到一般的 wiki-build（多份 raw 合成），不會說「這篇已經夠完整，可以升格」，每次都要靠我自己想到
3. 再往下看 note-enrich 的輸出格式，有幾個地方會讓升格卡住，其中最麻煩的是：我寫的句子和查來的句子混在一起，分不出來

前兩件是小修，第三件是今天的主線。

想法與取捨

就近融入，還是原文一塊、補充一塊

Day17 公開 note-enrich 範本時，我把「查到的事實就近插進原段落、不改寫原句、不另開一節」寫成這個 skill 最核心的規則。這條規則保證我的原句不會被改寫，但它有一個副作用：查到的事實是一句一句插進我的段落之間的，插完之後檔案裡沒有任何標記。

這在 raw 階段沒問題，到了升格就有問題。promote 的規則是「使用者的文字是主體，不動；只對 LLM 新增的句子跑 edit-article」。可是哪幾句是 LLM 新增的？skill 自己認不出來，只能靠 git diff 一篇篇回推。

當時 claude 列了三條路：

• 把查到的句子標出來：Claude 的傾向是不要，因為正文會讀起來很碎。我同意，查到的句子不標
• 靠 git diff：這是當下唯一能用的辦法，但每次升格都要翻歷史
• 原文自成一塊：這是我自己提的，我扔給它的句子自成一個區塊，查到的東西另外寫在下面

我選了第三條。代價是它直接推翻了 Day17 寫的那條核心規則，「就近融入、不另立 section」不再成立。換來的是：

• 自己寫的和查到的一眼分得開，不需要任何標記
• promote 時原文那塊不能動，補充那塊可以跑 edit-article，也可以整段刪掉
• 重跑 enrich 只動補充那塊，不會越跑越分不清

這條規則原本要防的「原句被改寫」並沒有放鬆，反而更硬了：原文現在一字不改，連錯字都不修。

要不要從 raw 開始調整

結構改了之後，我第一個反應是：這樣感覺是否也要從 raw 開始調整？

Claude 的建議是不用，我接受了。

理由是 inbox-triage 產生的 raw 本來就全是我的原文，等於已經是「原文那一塊」。這個結構只有跑過 enrich 才會長出來，所以只改 note-enrich 就夠了。純文字 topic 模式沒有原文，就只有補充和來源兩塊。

已經 enrich 過的 20 幾篇拆不拆

用 grep 數了一下，vault 裡帶 source: enriched 的 raw 有 20 幾篇。這些檔的原文和補充已經混在一起，要拆只能翻 git 歷史逐篇比對，成本太高。所以不回頭拆，新規則只套用在之後 enrich 的檔。舊檔重跑時，新查到的照新結構另起一個 ## 補充；frontmatter 的舊欄位，等哪天升格時由 promote 順手清掉。

2026-10-16 更新：舊檔 frontmatter 沒有等到升格，已在全 vault 統一來源欄位時一次改掉：source: enriched-from-inbox／enriched-from-topic 改成 enriched: inbox／topic，之後 enrich 的檔才寫日期。source 這個欄位也整個併進 sources，見 Day32。原文的拆分照本篇，不回頭拆。

結束時提議升格，但只提議

note-enrich 落地之後新增一個 Phase 4：判斷這篇該往哪走。這裡沿用 vault 一直以來的管線規則，只提議，不執行。升格與否仍然是我決定。

logs 型的練習日記直接跳過，logs 不升格。其他檔依序看下面四種情況，落在哪一種就給哪一種提議：

1. 夠完整 → 提議 /wiki-build {路徑} --promote。這是今天真正要定的門檻，條件全部成立才提：
   • 有成形的段落架構，不是片段清單
   • ## 待追問 沒有還沒勾的題
   • 正文沒有「未查到」「僅搜尋摘要」這類標記
   • 目標域的 index.md 還沒有同主題的 wiki 頁；有的話不升格，改提議 /wiki-build {topic} 併入既有那頁
2. 同主題 raw 已經累積 5 篇以上、還沒有對應的 wiki 頁 → 提議 /wiki-build {topic}，走多源合成，而不是單篇升格
3. 還有缺口 → 列出剩下的缺口，提議再跑一次 /note-enrich 或 /topic-probe
4. 都不符合 → 不提，不為了收尾硬塞一個下一步

提議只寫一行，格式固定：下一步：{指令}（{理由一句}）。

實作

改動集中在三個檔：note-enrich 的 SKILL.md、wiki-build 的 SKILL.md、CLAUDE.md 的 skill 表與資料流描述。

新的檔案結構

note-enrich 的 Phase 3 從「融入方式」改寫成「檔案結構」：

---frontmatter---
（使用者原文，一字不改）

## 待追問        ← 有才出現（/topic-probe 留下的）
## 補充          ← enrich 查到的，寫成連貫段落
## 來源          ← 外部連結彙整清單

## 補充 依主題寫成連貫段落，可以用 ### 分小節，對應原文提到的子題，不是逐題的 Q&A 清單。句尾照舊帶可點的外部連結。## 來源 把本檔所有外部連結各列一行、去重，重跑時往下追加。

## 待追問 的回填也跟著改。以前答案直接寫在題目下方，現在答案寫在 ## 補充，題目下只留一行指向對應小節，答案集中在一個地方。

frontmatter 直接照 wiki 規格寫

 ---
+title: {頁面標題，規則同 CLAUDE.md wiki 頁 title：中文概念通常＝檔名，結尾不可是日期}
 summary: {LLM 綜合內容 + 網路結果寫的一句摘要}
-tags: [{推測 tags, kebab-case, 3–6 個}]
+tags: [{中文主題 tag 為主，技術專名可英文 kebab，3–6 個}]
 date: YYYY-MM-DD
-source: enriched   # 純文字模式可用 enriched-from-topic
+enriched: YYYY-MM-DD   # 最近一次 enrich 的日期
 ---

raw 一出生就帶齊 wiki 的四個必填欄位，日後升格幾乎不用補。既有的 raw 或 logs 檔，原有欄位不動，只新增或更新 enriched 日期。

wiki-build promote 的兩處補丁

promote 的適用範圍改成「一份已經完整的單篇 raw，使用者自己寫的，或 note-enrich 補完後結構已成形的都算」。另外補兩條規則，處理 enrich 產出的檔：

- 來自 note-enrich 的檔：`enriched` 欄位保留；舊檔殘留的 `source: enriched`／`enriched-from-topic` 移除（wiki 的 `source` 只放外部 url），kebab-case tags 換成中文主題 tag。正文殘留的「未查到」「僅搜尋摘要」標記在步驟 1 列給使用者，決定留著、刪掉或先回 `/note-enrich` 補查

2026-10-16 更新：「wiki 的 source 只放外部 url」已不成立，來源欄位統一成 sources，舊檔的 source: enriched 也已全部改成 enriched，這條補丁上半段現在改成「enriched 欄位保留」，見 Day32。

- note-enrich 產出的檔：原文（`## 補充` 之前）是使用者文字不動；`## 補充` 是 LLM 寫的，可跑 `edit-article`，也可依使用者意思併進正文或刪掉；`## 來源` 保留當 Reference 區

第二條就是今天主線的收穫：## 補充 這個標題，同時是 promote 判斷「哪些是 LLM 寫的」的邊界。

踩到的坑

兩份規格各寫各的 frontmatter

這次沒有錯誤訊息，是對照規格時才發現的分歧。CLAUDE.md 規定 wiki 頁的 tags「中文主題 tag 為主」，note-enrich 卻一直產出 kebab-case 的英文 tag；wiki 頁的 source 欄位是放外部網址的，note-enrich 拿它來標「這篇被 enrich 過」。

兩邊各自都說得通，問題出在交接的地方：raw 只要一直待在 raw，沒有人會發現；一升格，每篇都要換 tag、刪欄位。用 grep 數的時候，已經有 20 幾篇帶著 source: enriched，而且沒有任何腳本讀這個值，它只是一個沒人在用的標記。

之後的做法：兩個 skill 會交接同一個檔時，上游的輸出格式直接照下游的規格寫，不要讓下游每次補。

第一個回答只講對一半

我第一次問「哪個 skill 可以把 raw 直接升級成 wiki」時，Claude 直接回答 --promote，沒有回頭看 note-enrich。等我補一句「我是指 note-enrich 完的內容」，它去讀兩份 SKILL.md，才發現 promote 的適用範圍把 enrich 過的檔排除在外，note-enrich 結束時也不會提議升格。

指令本身是對的，實際也能用。但「能用」和「規則有寫到」是兩回事：規則沒寫到的路，下一次另一台機器上的 session 不一定會走。

小結

• note-enrich 改成原文一塊、## 補充 一塊、## 來源 清單，原文一字不改
• frontmatter 直接照 wiki 規格寫，source: enriched 改成 enriched: 日期
• note-enrich 新增 Phase 4，夠完整時提議 /wiki-build --promote
• promote 的適用範圍擴及 enrich 過的 raw，並知道 ## 補充 可以整理、原文不能動
• 已經 enrich 過的 20 幾篇不回頭拆，升格時再清 frontmatter

改動共 3 個檔、+53／−21 行，已經上線，下一次跑 /note-enrich，兩台機器都會用新結構。

本文同步發表於 kiwi-walk.com：https://kiwi-walk.com/blogs/engineer/ironman-2026-day29-enrich-block-promote/