知識庫運營工作流（LLM Wiki 模式）
定位與適用
本 Skill 是平台無關的方法論：把外部知識轉化為智能體運行時可呼叫的行為規則（Memory/規範/Skill）。知識庫不是收藏夾，是智能體的能力增長引擎——每條入庫知識都必須經過蒸餾，判斷價值的唯一標準是：它能否直接改變智能體在具體場景下的行為決策。
- 若項目已有自己的知識庫規範文件（如
項目規範.md），以該文件為權威參照，衝突時以項目規範為準 - 在不同平台/項目應用時，按本 Skill 的三層架構與流程落地，目錄名可本地化；本倉
examples/提供可直接跑通的最小樣本
三層架構
| 層 | 推薦目錄 | 性質 |
|---|---|---|
| Raw Sources | 原始採集/（文章/討論/影片） | 唯讀，採集後不可變 |
| The Wiki | 知識庫/（目錄.md、採集經驗.md、操作日誌.md） | LLM 維護的派生內容 |
| The Schema | 項目規範.md + 程序檔案/配置/ | 人與 LLM 共同維護 |
關鍵原則：原始檔案始終留在 Raw Sources，不移動到 Wiki；校驗通過後在目錄.md 中建立引用即視為「入庫」。
角色分離（必須遵守）
| 角色 | 實體 | 職責 | 禁忌 |
|---|---|---|---|
| Planner | 人工 | 定採集目標、定價值契約、引導分析方向 | 不直接操作檔案 |
| Generator | LLM | 執行採集、補元數據、寫摘要、維護目錄與日誌 | 禁止自評產出品質 |
| Evaluator | 校驗治具（如 scripts/validate.py） | 獨立校驗格式、編碼、元數據、交叉引用 | 不參與生成 |
核心規則：模型不得給自己打分。 價值評估由 Generator 記錄在操作日誌，校驗通過與否由 Evaluator 裁定；人工有異議時以人工判斷為準。項目無治具時，按 Lint 六維逐項人工核查，但結論仍不得由生成者自證。
Ingest（攝入）
複製此清單跟蹤進度：
- [ ] 1. 採集前價值契約（三問）
- [ ] 2. 採集並補充元數據
- [ ] 3. 讀取內容、提取關鍵信息
- [ ] 4. 價值判定（不達標則中止）
- [ ] 5. 更新目錄.md（摘要 + 交叉引用）
- [ ] 6. 追加操作日誌
- [ ] 7. 蒸餾評估並標記落地狀態
- [ ] 8. Git 提交
第 1 步 · 採集前價值契約——動手前回答三問並記錄：
- 這篇文章要解決什麼問題？與已有知識的關係是什麼？（補充/對比/延伸）
- 什麼條件下算「有價值」？至少滿足一個：引入新概念、提供對比視角、有直接實作參考
- 預期歸入目錄.md 哪一層？（基礎理論/架構範式/工程實踐/工具資源/社區動態）
第 2 步 · 採集與元數據——用當前平台的採集引擎獲取原文（見「採集引擎抽象」），存入 Raw Sources 對應子目錄，檔案名稱遵循 {source}_{topic}_{date}.{ext}（如 github_karpathy_llm_wiki_20260630.md）。元數據必需字段：URL、採集時間、採集命令；建議字段：By、Site、Published、原始來源。採集引擎通常只能自動提取部分字段，其餘必須補齊。
第 4 步 · 價值判定（含中止）——對照第 1 步契約評估。明顯不滿足任何價值條件（內容空洞、嚴重重複、與知識庫定位無關）時，顯式記錄中止原因到操作日誌後退出，不強行完成入庫流程。
第 6 步 · 操作日誌格式：## [日期] ingest | 標題（append-only）。
第 7 步 · 蒸餾評估——該條目是否包含可直接指導智能體行為的原子規則？
| 標記 | 含義 | 動作 |
|---|---|---|
| 🟢 已落地 | 有可執行原子規則 | 提取寫入 Memory/規範/Skill，在目錄.md 條目註明 Memory 標題 |
| 🟡 部分落地 | 部分有 | 註明已落地與未落地的具體內容及原因 |
| 🔵 參考索引 | 無可執行規則 | 操作日誌中簡述原因 |
蒸餾標準：規則必須能改變智能體在具體場景下的行為決策，而非抽象理念或參考信息。
跨平台蒸餾適配：在 Qoder 中蒸餾產物寫入 Memory 系統（方法論→task_experience、踩坑→common_pitfalls_experience、架構決策→important_decision_experience 等分類）；在其他智能體平台，映射到該平台自身的持久記憶/行為規則機制，判定標準與三色標記保持不變。
第 8 步：git add -A && git commit -m "ingest: 標題"。
Query（查詢）
- 先讀
知識庫/目錄.md定位相關頁面 - 深入閱讀相關檔案，綜合答案
- 好答案回填為新頁面——讓探索本身也產生複利
- 追加操作日誌：
## [日期] query | 問題 - 產生新頁面後：
git add -A && git commit -m "query: 問題"
Lint（體檢）
優先運行項目校驗治具（本倉提供零依賴示例：python scripts/validate.py <知識庫根目錄>），治具裁定優先於人工判斷。無治具時按六維逐項核查：
- 元數據完整性 — 必需字段（URL、採集時間、採集命令）是否齊全
- 編碼正確性 — 雙重編碼亂碼、BOM、替換字元（U+FFFD）
- 格式規範性 — Markdown 須以 H1 開頭且元數據與正文以
---分隔；JSON 須有_metadata字段 - 命名規範 — 是否遵循
{source}_{topic}_{date}模式 - 交叉引用 — 目錄.md 連結是否指向實際檔案；孤兒頁面檢測
- 來源校驗 — URL 是否屬於來源白名單
追加操作日誌：## [日期] lint | 檢查範圍；有修復則 git commit -m "lint: 檢查範圍"。
Harness 遞減：治具與流程是補償模型弱點的輔助機制，應隨模型進步單調遞減。每次 Lint 時審視：哪些校驗規則已不再觸發？哪些步驟模型已內化？刪掉它。
採集引擎抽象（跨平台適配）
核心流程不綁定任何採集工具，採集引擎按平台可用性選擇：
| 平台環境 | 採集方式 |
|---|---|
| Windows + Edge 瀏覽器 | AutoCLI：autocli read "URL" -f markdown -o "輸出路徑"，自動提取 By/Site/URL；注意 PowerShell 下 stderr 進度信息會誤報 ExitCode=1，輸出含 "Saved to ..." 即成功 |
| 具備網頁讀取能力的智能體平台 | 網頁讀取工具（WebFetch 等）直接抓取並轉 Markdown |
| 公開 API 來源 | Hacker News、Lobsters 等無需瀏覽器，直接 API 請求 |
| 無網路工具 | 用戶粘貼原文，手動落盤並如實記錄 採集命令 為"手動粘貼" |
無論何種引擎，入庫後的元數據、校驗、蒸餾要求完全一致。採集命令 字段如實記錄實際使用的引擎與命令（含降級切換），保證可復現。
約定速查
- 檔案名稱：
{source}_{topic}_{date}.{ext}，source 小寫 - 操作日誌：append-only，格式
## [日期] {ingest|query|lint} | 簡述 - commit message：
{ingest|query|lint}: {簡述}；初始化：init: 知識庫基線 - 踩坑教訓結構化記入
採集經驗.md，不混入操作日誌