29e3636bd2
不想被編入 wiki 的內容(密碼/金鑰/個資)三層防線: - L1 .wikiignore:整個機敏檔不編入(glob,像 .gitignore) - L2 行內標記 <!-- wiki:ignore -->:檔案內某段不編入 - L3 wiki-secret-scan.sh hook:機敏值真寫進 .claude/wiki/ → exit 2 擋 L3 偵測密碼賦值/PEM 私鑰/AWS·GitHub·Slack·Google·Stripe 金鑰/JWT/ 連線字串帳密/台灣身分證/信用卡號;wiki-secret-ok 行尾標記可豁免誤判。 wiki-init/wiki-capture/SKILL 寫入 L1+L2 協議。 誠實限制:L1/L2 靠 CC 自律、L3 靠 regex(有偽陽/偽陰),減少意外外洩 非保險箱——真正的密鑰本就不該進版控。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
5.3 KiB
5.3 KiB
name, description
| name | description |
|---|---|
| llm-wiki | 為任何開發專案建立或維護 LLM Wiki 記憶系統——一套讓 CC(Claude Code)不再重複犯錯、 不忘決策脈絡的雙空間文件結構。觸發時機: (1)新專案 init——「幫我建立 wiki 系統」「新專案要設置文件結構」; (2)老專案 migrate——「幫我整理文件」「文件太亂了」「散落的 md 幫我收一收」; (3)對話結論 capture——「把剛才的討論記下來」「這個決定要存起來」「我不想再解釋一次」; (4)wiki 更新——「更新 status」「記錄這個 mistake」「加一條決策」。 只要涉及「讓 CC 記住某件事」或「整理專案文件讓 CC 好找」,都用這個 skill。 |
LLM Wiki Skill
讓 CC 不再是失憶的協作者。這個 skill 幫你在任何專案裡建立一套 人寫文件 + CC 整理 wiki 的雙空間系統,讓每次 session 都能無縫接上。
靈感來源:Andrej Karpathy 的 LLM Wiki 概念——不用 embedding, 只靠 pre-compile 把知識整理成 LLM 友善的格式。
四種使用情境
| 情境 | 觸發訊號 | 跳到 |
|---|---|---|
| A. 新專案 init | 空專案、剛開始 | → 流程 A |
| B. 老專案 migrate | 已有文件但很亂 | → 流程 B |
| C. 對話結論 capture | 剛討論完某個決策 | → 流程 C |
| D. Wiki 日常更新 | session 結束、踩到坑 | → 流程 D |
雙空間架構
專案根目錄/
├── CLAUDE.md ← 導航牌,≤100 行,永遠不增長
├── docs/ ← 原始文件空間(人寫,CC 讀)
│ ├── README.md
│ ├── 1-vision/
│ ├── 2-architecture/decisions/
│ ├── 3-specs/
│ ├── 4-guides/
│ ├── 5-records/{incidents,test-reports}/
│ └── 6-user/
└── .claude/wiki/ ← CC 整理的知識(CC 寫)
├── INDEX.md
├── mistakes.md
├── status.md
└── decisions-summary.md
三條原則:docs/ 人寫 CC 不改 | wiki/ CC 維護 | CLAUDE.md ≤100 行
詳細格式見 references/templates.md。
機敏內容防護(三層)
有些內容不該被編入 wiki——密碼、API 金鑰、私鑰、個資。三層防線:
| 層 | 機制 | 擋什麼 | 性質 |
|---|---|---|---|
| L1 | .claude/wiki/.wikiignore(glob,像 .gitignore) |
整個機敏檔不編入 | 協議(CC 遵守) |
| L2 | 行內標記 <!-- wiki:ignore --> … <!-- wiki:end --> |
檔案內某段不編入 | 協議(CC 遵守) |
| L3 | wiki-secret-scan.sh hook(PreToolUse) |
機敏值真的寫進 wiki → exit 2 擋 | 硬攔截(機械偵測) |
CC 的守則:
- init/migrate 掃描時,先套
.wikiignore再分類;命中的檔案不讀不編入。 - 編入任何內容前,自檢有無密碼/金鑰/個資——有就記「位置」不記「值」。
- L3 是兜底底線,不是藉口:別把機敏值帶到寫入那一刻才靠 hook 攔。
誠實限制:L1/L2 靠 CC 自律,L3 靠 regex 特徵(有偽陽/偽陰)。 這是「減少意外外洩」的機制,不是保險箱。真正的密鑰本就不該進版控。
流程 A:新專案 Init
- 建立目錄結構
- 依
references/templates.md建立六個核心檔案 - 訪談(每次一個問題):做什麼 / 技術限制 / 技術棧 / 現有規範
- 填入 CLAUDE.md,完成確認
流程 B:老專案 Migrate
⚠️ 三個階段,每階段等確認再繼續。
階段一:掃描 + 分類計畫 遞迴找所有 .md,標注建議位置和信心度,列清單等確認。
分類規則:
子系統設計文件 → docs/3-specs/[子系統]/
為什麼做某決定 → docs/2-architecture/decisions/
怎麼操作 → docs/4-guides/
歷史記錄 → docs/5-records/
給使用者看的 → docs/6-user/
不確定 → 列為「待確認」,問使用者
階段二:讀文件,建 wiki 每個文件讀完後提取到對應 wiki 檔案,全部讀完後展示結果等確認。
階段三:歸檔 按確認好的分類移動,根目錄只留必要項目,更新 CLAUDE.md 路徑。
流程 C:對話結論 Capture
這是最容易被忘記、也最重要的情境。
| 內容類型 | 存到哪 |
|---|---|
| 架構決策 | decisions-summary.md + docs/2-architecture/decisions/[日期]-[主題].md |
| CC 誤解被糾正 | mistakes.md |
| 狀態更新 | status.md |
操作:辨識 → 列清單給使用者確認 → 寫入 → 告知存到哪裡
Mistakes 格式:
⚠️ MISTAKE: [錯誤描述]
症狀: [CC 的表現]
正確做法: [應該怎麼做]
原因: [背景]
日期: [YYYY-MM-DD]
流程 D:Wiki 日常更新
Session 結束時固定更新 status.md:
- 這次做了什麼
- 遇到什麼問題
- 下次從哪裡開始
- 有新誤解 → 同時 append mistakes.md
- 有新決策 → 同時 append decisions-summary.md
維護規則
docs/只讀不改.claude/wiki/只增不刪CLAUDE.md不增長,超過 100 行就是放錯地方- 分類不確定就問
- 對話結論當場 capture