道可道，非常道

定位：所有元技能的元技能，貫穿冷啓動、迭代、反思、質量控制、柳葉刀方法等所有工序的核心哲學。 

附：本篇實踐可參考案例為  一個開源的AI《史記》知識庫與26個可複用構造知識庫Skill，57萬字史記，10萬個實體、3185個事件、7652條關係全部結構化

全文可視化概覽（一頁紙）

核心公式

好東西 = 總結出來 ≠ 設計出來
OTF（邊做邊總結） + JIT（小步快跑） + Bootstrap（自舉）
知識自動增長，人工投入遞減

演進規律：從執行到自治

冷啓動：人工執行，0% 自動，產出數據。
模式湧現：邊做邊總結，20% 自動，產出模式。
知識固化：Agent 學習，60% 自動，產出 Skill。
系統自治：自主運行，90%+ 自動，產出 META。

知識資產：四層複用金字塔

腳本工具：Lint / Extract / Render / Transform，90%+ 主要是微調參數。
項目 Skill：實體標註 / 事件識別 / 消歧，60%-80% 需要適配。
META 技能：反思 / 迭代 / 冷啓動，100% 跨項目通用。
元元方法：演進式方法論，100% 跨領域通用。

五層抽象：知識壓縮過程

層1 案例：具體錯誤、修正記錄。
層2 模式：錯誤模式、工具模式。
層3 原則：OTF + JIT + Bootstrap。
層4 洞察：總結是唯一的知識來源。
層5 哲學：演進 > 設計。

三個反常識

不是先設計完美方案再執行，而是先執行最小版本，邊做邊總結優化。
不是等項目結束再總結，而是每輪迭代都總結，知識實時沉澱。
不是追求一次性完美，而是快速交付 60% 質量，再迭代收斂到 95%。

閲讀導航

零、核心命題：3 分鐘快速理解。
一、通用方法論框架：OTF + JIT + Bootstrap 詳解。
二、五層抽象金字塔：如何提煉知識。
三、為什麼總結：認知科學與信息論基礎。
四、實戰案例：史記項目全流程覆盤。
五、Agent 學習路徑：如何讓 AI 自主總結。

零、核心命題

一句話

好東西都是總結出來的，不是發明出來的。

核心方法論：OTF + JIT + Bootstrap

OTF = On-The-Fly，即時總結

不是做完再總結，而是邊做邊總結。
發現模式的那一刻，就立即記錄、歸納、應用。
總結不是項目結束時的附加動作，而是執行過程的一部分。

JIT = Just-In-Time，即時交付

不是一次性做完美，而是及時交付最小可用版本。
先跑起來，再拿反饋，再改進，再收斂。
重點不是“第一次就對”，而是“每一輪都更對”。

Bootstrap = 知識自舉

每一步迭代，都會產生下一步可複用的元知識。
知識會在迭代中自我增殖，自動化程度遞增，人工干預遞減。
一開始是人帶系統跑，後面是系統反過來加速人。

OTF + JIT + Bootstrap = 自舉式知識增殖系統

三個推論

1. 知識是壓縮
    — 從10,000個案例→100條模式→10條原則→1個洞察
2. 理解是歸納
    — 看到規律才算真正理解，沒有規律就沒有知識
3. 方法是沉澱
    — 做一次是經驗，做十次總結出來才是方法論

演進式方法論總綱

一、基本原則

演進 > 設計：多總結，少設計。
聚焦 > 全面：一次只做一件事。
實踐 > 理論：好東西都是總結出來的。

二、操作層次

觀察現象：先記錄案例。
識別關鍵：判斷什麼最影響結果。
提取模式：從重複現象裏發現規律。
固化方法：把規律寫成文檔、腳本、Skill。

三、迭代策略

小粒度：從小問題開始。
小工具：優先解決最痛的重複勞動。
小週期：快速反饋，快速迭代。

四、價值導向

防止重複犯錯：把隱性知識顯性化。
降低認知負荷：把方法標準化。
提高複用效率：讓模式可以遷移。

所有元技能清單

本項目最終形成14個元技能（13個方法論+1個元元技能）。

核心元技能（本文涉及）：

注：另有00-META-05（知識作為上下文壓縮）、00-META-06（SKILL優化與演化）、00-META-12（數據融合）、00-META-13（技能遷移）共14個元技能。

層級關係：

元元技能

本文檔討論的是“如何總結”本身，也就是關於總結的總結。

往下一層，是方法論元技能

迭代工作流、冷啓動、柳葉刀方法、標註體系設計、可讀性、質量控制。
它們回答的是：複雜知識工程任務，應該怎麼做。

再往下一層，是執行層元技能

實體標註、事件識別、消歧、渲染、發佈、數據融合、技能遷移。
它們回答的是：具體任務，實際怎麼落地。

核心關係

所有元技能都不是預先設計出來的，而是從大量任務裏總結出來的。
每個元技能都遵循同一套抽象路徑：案例 → 模式 → 原則 → 洞察 → 哲學。
本文檔不是替代其他元技能，而是解釋這些元技能為什麼會長成現在這樣。

核心關係： - 所有8個元技能都是通過總結提煉出來的（而非預先設計） - 每個元技能的形成都遵循五層抽象金字塔（案例→模式→原則→洞察→哲學） - 本文檔（元元技能）是對"如何總結"的遞歸總結

一、通用方法論框架

本章導航：本章分為兩部分 1. 通用原則（1.1-1.6節）：從多年實踐中抽象出的知識處理方法論 2. 實踐機制（1.7-1.8節）：OTF + JIT 作為方法論的具體落地機制

1.1 總結的雙重目標

目標1：決策優化 — 在實踐中檢驗邏輯，建立優先級的深刻共識

總結有兩個目標：一是理解更深，二是方法更穩。

目標1：決策優化

理解深度不是停在 Framework，而是繼續追到 Rationale，最後長出 Insight。
Framework 解決“怎麼做”，Rationale 解決“為什麼這樣做”，Insight 解決“下一次還會發生什麼”。

目標2：方法沉澱

沉澱路徑不是一句空話，而是清晰的五級演化：案例 → 方法 → 流程 → 制度 → 文化。
一次是經驗，三次可以總結為方法，十次才能穩定成流程。

實踐方法： - 每件事都追問：為什麼做？為什麼不做其他？ - 記錄決策過程，而非只記錄決策結果 - 週期性回顧：這個決策的rationale現在還成立嗎？

目標2：方法沉澱 — 將有效方法固化為可複用模式

實踐方法： - 一次是經驗，三次總結為方法，十次固化為流程 - 方法文檔化：寫成SKILL文檔、檢查清單、自動化腳本 - 定期審查：哪些方法已失效？哪些需要更新？

1.2 知識提煉的四個層次

基於"覆盤四步法"抽象出的通用框架：

1. 觀察層：記錄現象
   - 做了什麼？結果如何？
   - 數據是什麼？異常在哪裏？

2. 分析層：識別關鍵
   - 哪一步是關鍵步驟？
   - 哪個因素影響最大？

3. 歸納層：提取模式
   - 有哪些重複規律？
   - 其他案例是否支持這個規律？

4. 演繹層：形成方法
   - 如何應用到新場景？
   - 邊界條件是什麼？

核心價值： - 防止Agent在同一個地方犯錯 - 將隱性知識顯性化（人類執行經驗 → Agent可讀的SKILL） - 從單次執行提升為可複用的Agent知識資產

實踐案例（抽象版本）：

觀察：處理了130章數據，發現13,000個錯誤
  ↓
分析：60%是消歧問題，這是關鍵瓶頸
  ↓
歸納：消歧錯誤遵循25個模式（如"同名不同人"）
  ↓
演繹：開發自動檢查工具，規則覆蓋80%的情況

1.3 創新的邊界與節奏

聚焦原則：一次只解決一個核心問題

失敗模式："換四個引擎"
  同時改變數據模型 + 處理工具 + 工作流程 + 評價標準
  → 無法定位問題根源
  → 認知負荷過大
  → 反饋週期過長

成功模式："單點突破"
  只改變數據模型，工具/流程/標準保持不變
  → 快速驗證效果
  → 明確歸因
  → 容易回滾

實踐建議： - 每個迭代週期只改變一個變量 - 如果必須同時改變多個，至少要能清晰解耦 - 警惕"全面革新"的誘惑

認知負荷管理

降低學習成本的三個策略：
  1. 漸進式複雜化
     - 先用簡單方案建立直覺
     - 再逐步引入複雜特性

  2. 利用現有知識
     - 新工具儘量與舊工具接口兼容
     - 新方法儘量基於現有方法演化

  3. 分層隱藏細節
     - Agent初始階段只需瞭解最簡模型
     - Agent成熟後才需要了解全部細節

短週期迭代

對比：
  瀑布模式：規劃3個月 → 開發2個月 → 測試1個月 → 發現問題回到起點
  迭代模式：規劃3天 → 開發2天 → 測試1天 → 調整再來

優勢：
  - 快速反饋 > 完美規劃
  - 真實數據 > 理論推導
  - 早期暴露問題 > 後期集中爆發

1.4 知識工作的"小"策略

小粒度：從小問題開始，避免過早抽象

錯誤路徑：
  Day 1 → 設計通用本體框架
  Day 10 → 發現框架不適用於實際數據
  Day 20 → 推翻重來

正確路徑：
  Day 1 → 處理5個具體案例
  Day 2 → 歸納初步模式
  Day 3 → 處理30個案例驗證
  Day 5 → 提煉通用框架

原則： - 先有具體的"語義"，再有抽象的"語義網" - 先解決特定問題，再提煉通用方案 - 容忍局部不一致，在演化中逐步收斂

小工具：降低工具使用門檻

工具演進的三個階段：
  1. 人工操作（人類執行，Agent觀察學習）
  2. 半自動腳本（固化重複步驟，Agent輔助執行）
  3. 全自動工具（Agent自主執行，人類審查）

關鍵：
  - 工具演進 = Agent能力演進
  - 好工具來自真實執行過程的痛點
  - 充分利用現有工具生態（不要重新發明輪子）

小週期：精益迭代，減少浪費

懶處理策略：
  - 需要時再處理（不是提前處理所有可能情況）
  - 高頻問題優先（80%的價值來自20%的問題）
  - 自動化ROI分析（工具開發成本 vs 節省時間）

Build-Measure-Learn循環：
  1. Build：最小可用版本（1天）
  2. Measure：實際使用反饋（1周）
  3. Learn：總結問題和改進點（1天）
  → 重複

1.5 演進優於設計

核心原則："多總結，少設計"

設計思維：
  - 預先規劃完美方案
  - 追求一次性正確
  - 標準化、規範化

演進思維：
  - 從現狀出發小步改進
  - 容忍多樣性、試錯
  - 在競爭中自然選擇

為什麼演進更有效？

1. 未來需求不可預測
   - 設計時無法考慮所有場景
   - 演進可以根據實際需求調整

2. 認知能力有限
   - 很難一次性設計出完美方案
   - 通過迭代逐步逼近最優解

3. 環境持續變化
   - 今天的完美方案，明天可能過時
   - 演進保持系統的適應性

實踐策略：允許"重新發明輪子"

傳統觀點：
  - 避免重複造輪子
  - 統一標準、統一工具

演進觀點：
  - 百花齊放，在競爭中進化
  - 不同場景可能需要不同的"輪子"
  - 最終收斂到最優方案（自然選擇）

漸進式改進

三個原則：
  1. 在現有基礎上演化
     - 充分利用現有工具/方法
     - 不要從零開始

  2. 每個階段有自身核心任務
     - 不要試圖一步到位
     - 階段性目標要明確

  3. 總結優於規劃
     - 從實踐中提煉模式
     - 多觀察、多實驗、多總結

1.6 方法文檔化的價值

文檔化循環

文檔不是結項紀念冊，而是持續工作的反饋迴路。

實踐先發生。
在實踐中發現重複步驟和異常邊界。
發現模式之後，把它寫進文檔。
文檔再反過來指導新實踐。
新實踐又暴露出新邊界，再推動文檔更新。

這就是文檔化循環：實踐 → 發現模式 → 寫入文檔 → 指導新實踐 → 再更新。
所以文檔不應該項目結束後一次性寫完，而應該隨項目一起演進。

文檔的兩種形式

規範性文檔：
  - "應該怎麼做"
  - 示例：標註規範、質量標準

描述性文檔：
  - "為什麼這樣做"
  - 示例：決策歷史、演化過程

兩者都重要：
  - 規範性：指導執行
  - 描述性：傳遞理解

元認知：容忍多樣性

洞察："世界觀的attention"
  - 同一問題可能需要多個schema
  - 不同的人/場景可能有不同的理解
  - 不強求統一，在使用時選擇/對齊

實踐：
  - 允許多個標註體系並存
  - 在應用層做映射/轉換
  - 演化中逐步收斂（而非強制統一）

1.7 實踐機制：OTF（On-The-Fly）即時總結

定位：以下1.7-1.8節介紹OTF + JIT作為上述通用方法論的具體落地機制

核心理念：不等做完再總結，而是發現模式的那一刻立即總結

為什麼OTF有效？

認知科學依據： - 記憶衰減 — 做完130章再總結，前面的細節已遺忘 - 模式識別 — 人腦擅長識別模式（看到3次重複就能歸納） - 即時強化 — 總結後立即應用，形成正反饋循環

傳統方式（Post-Mortem）的問題：

Post-Mortem 的問題

Day 1-90 一直執行，不總結。
Day 91 才開始回頭整理。
結果通常是：細節忘了，總結質量低；錯誤已經重複了 90 次，返工成本高；總結也很難反哺項目本身，因為項目已經做完。

On-The-Fly 的做法

Day 1 做 5 個樣本，就開始總結。
Day 2 把總結出來的規則反過來用於新樣本。
Day 3-10 持續邊做邊改，錯誤率在執行中就開始下降。

OTF方式（On-The-Fly）： OTF 的基本工作方式是：執行中發現模式，立即長出規則，再把規則反向喂回執行。

OTF的三個時機

時機1：發現重複（3次規則）

OTF觸發器邏輯： - 維護錯誤模式的重複計數器 - 對每個任務，檢測執行結果是否為錯誤 - 如果是錯誤，識別其模式並累加計數 - 當某個模式重複≥3次時： - 立即總結該模式 - 將總結的規則寫入規則庫 - 記錄OTF總結日誌

時機2：發現異常（意外情況）

案例：標註時發現"周公"既是人名又是官職

傳統：繼續標註，等做完再處理
OTF：
  ├─ 立即停下（5分鐘）
  ├─ 分析：需要新分類"兼職"（如"周公"= 人名+官職）
  ├─ 更新標註體系
  └─ 繼續標註（後續不再遇到此類困惑）

時機3：批次邊界（每N個樣本）

每10個樣本 → 微總結（5分鐘）
  - 發現了什麼模式？
  - 需要調整什麼規則？

每50個樣本 → 中總結（30分鐘）
  - 哪些模式高頻（寫入自動化腳本）
  - 哪些模式低頻（記錄但不自動化）

每130個樣本 → 大總結（2小時）
  - 形成完整錯誤模式表
  - 提煉方法原則

本項目的OTF實踐

實體標註的OTF過程：

Day 1（5章）：
  OTF-1: 發現"武王"需消歧 → 規則："諡號必須加邦國"

Day 2（30章）：
  OTF-2: 發現"邦國"≠"地名" → 本體演化：4類→6類

Day 5（130章）：
  OTF-3: 發現"官職"≠"爵位" → 本體演化：6類→8類

Day 10（第一輪反思）：
  OTF-4: 發現系統性消歧遺漏 → 開發自動檢查工具

Day 15（第二輪反思）：
  OTF-5: 發現格式不一致 → 開發Lint工具

每次OTF的產出： - 規則更新（立即應用於後續樣本） - 本體演化（本體是"長"出來的） - 工具開發（自動化重複勞動）

1.8 JIT（Just-In-Time）：及時交付的威力

核心理念：不追求一次完美，而是及時交付最小可用版本，快速迭代

為什麼JIT有效？

工程經驗依據： - 需求不確定 — 前期對"好"的標準認知模糊 - 反饋驅動 — 只有交付了才能獲得反饋 - 風險可控 — 小批量迭代比大批量返工成本低

傳統方式（Big Bang）的問題：

Week 1-4: 設計完美方案（50屬性本體）
Week 5-8: 一次性執行（發現方案不適配）
Week 9: 大規模返工（本體重構，數據重錄）

→ 總耗時9周，質量未必高（前期決策錯誤）

JIT方式（Just-In-Time）：

Week 1:
  JIT-v0.1: 最小本體（4類）+ 標註5章
  ├─ 交付：初版數據（質量60%）
  └─ 反饋：需要"邦國"類

Week 2:
  JIT-v0.5: 本體演化（4類→8類）+ 標註30章
  ├─ 交付：擴展數據（質量75%）
  └─ 反饋：需要"器物"類

Week 3:
  JIT-v1.0: 本體穩定（18類）+ 標註130章
  ├─ 交付：全量數據（質量85%）
  └─ 反饋：系統性錯誤模式

Week 4:
  JIT-v1.5: 第一輪反思修正
  ├─ 交付：高質量數據（質量92%）
  └─ 反饋：收斂

→ 總耗時4周，質量92%（漸進收斂）

JIT的三個層次

層次1：功能JIT（最小可行產品）

不是：設計完整工具鏈（Lint + Validate + Transform + Export）
而是：
  Day 1: 需要格式校驗 → 開發 lint_format.py（30分鐘）
  Day 5: 需要統計分析 → 開發 stats.py（1小時）
  Day 10: 需要導出功能 → 開發 export.py（2小時）

→ 按需開發（JIT），無冗餘功能

層次2：質量JIT（梯度收緊）

不是：所有數據都要求95%準確率
而是：
  P0: 60%準確率（2天完成130章）
  P1: 80%準確率（1周）
  P2: 90%準確率（1周）
  P3: 97%準確率（1周）

→ 及時交付可用版本，逐輪提升質量

層次3：知識JIT（按需沉澱）

不是：項目結束後寫一份完整文檔（50頁）
而是：
  Week 1: 冷啓動文檔（3頁，夠用）
  Week 2: 本體設計文檔（5頁，基於實際演化）
  Week 4: 反思方法文檔（8頁，基於第一輪經驗）
  Week 8: 完整META技能文檔（20頁，基於全流程總結）

→ 文檔也是JIT，隨項目演化

本項目的JIT實踐

事件年代標註的JIT過程（真實時間線）：

P0（2小時）：
  交付：3,092事件初版年份（準確率60%）
  方法：LLM快速標註全部事件
  質量目標：能用即可，快速覆蓋

P1（半天）：
  交付：第一輪反思修正（1010處，準確率80%）
  方法：Agent自動反思 + 批量修正
  質量目標：系統性錯誤消除

P2（2小時）：
  交付：第二輪反思修正（431處，準確率88%）
  方法：基於P1模式庫的增量修正
  質量目標：模式驅動修正

P3（2小時）：
  交付：第三輪反思修正（465處，準確率92%）
  方法：跨章一致性檢查
  質量目標：跨章一致性

P4（1小時）：
  交付：第四輪反思修正（167處，準確率95%）
  質量目標：接近收斂

P5（1小時）：
  交付：第五輪反思修正（46處，準確率97%）
  質量目標：收斂完成

總耗時：約1.5天（vs 一次性完美需要1周+）

JIT的收益： - 2小時即可交付可用版本（P0，60%質量） - 避免一次性完美的返工風險 - 每輪都有可交付成果（持續價值） - 總時間反而更短（1.5天 vs 1周+）

1.9 OTF + JIT 的協同效應

單獨OTF的問題： - 總結太頻繁 → 執行效率低 - 總結質量受限於樣本量

單獨JIT的問題： - 迭代無方向 → 可能震盪不收斂 - 缺乏方法積累 → 每輪都是新探索

OTF + JIT 協同：

JIT 提供大循環，OTF 提供小循環。

JIT 的節奏是：P0 → P1 → P2 → P3 → 收斂。
OTF 的節奏是：每一輪內部持續發現模式、總結模式、應用模式。

所以真實協同關係是：

P0 階段先交付 60% 的版本。
在 P0 內部，通過 OTF 長出第一批規則、本體調整和工具。
P1 再把 P0 的總結結果吃進去，系統性修正。
後面每一輪，都建立在前一輪沉澱出的模式之上。

JIT 提供框架，OTF 提供燃料。
JIT 負責把版本往前推，OTF 負責把知識往上提。

具體協同：

P0階段（JIT框架）：
  Day 1: 標註5章
    ├─ OTF-1: 發現消歧模式 → 更新規則
  Day 2: 標註30章
    ├─ OTF-2: 發現分類模式 → 本體演化
  Day 3-4: 標註130章
    ├─ OTF-3: 發現格式模式 → 開發Lint
  Day 5: P0交付（60%質量，25條OTF總結的模式）

P1階段（JIT框架）：
  應用P0的25條模式（OTF產出）
  ├─ 系統性修正1010處
  ├─ OTF-4: 發現新模式1條
  └─ P1交付（80%質量，26條累計模式）

→ JIT提供框架，OTF提供燃料（模式）

複利效應： - OTF總結的模式 → JIT迭代的基礎 - JIT交付的版本 → OTF總結的樣本 - 兩者相互促進，形成正反饋

二、Bootstrap：知識自舉的五階演化

2.1 核心理念：知識增殖與自動化遞進

傳統觀念（錯誤）：

傳統觀念

人工勞動 → 完成任務 → 項目結束 → 下個項目從頭再來。

自舉觀念

人工勞動會產生中間知識，比如日誌、腳本、檢查規則。
中間知識會進一步總結成 Skill。
Skill 會再長出自動化工具。
工具使用過程又會產生更高階的模式。
最後，系統開始具備自動總結、自動演化的能力。

自舉理念（正確）： Bootstrap 不是重複跑流程，而是每一輪都長出更高階知識。

核心洞察： - 每一步迭代都是下一步的燃料（知識增殖） - 自動化程度指數增長（從0%→20%→60%→90%→99%） - 人的角色從執行者→監督者→設計者

2.2 第一階：人工勞動 + 記錄（Week 1）

狀態： - 自動化率：0% - 人工佔比：100% - 中間產物：聊天記錄、操作日誌、臨時筆記

典型場景：

Day 1-2: 手動標註5章
  ├─ Claude對話：30輪問答，探索標註規範
  ├─ 產出數據：5章標註文件
  └─ 副產品：
      - 30輪對話記錄（包含決策過程）
      - errors.txt（記錄了12個犯錯案例）
      - questions.md（3個未解決的模糊問題）

關鍵點： - 不要丟棄中間過程（對話、日誌、草稿） - 這些"廢料"是下一階段的"原料" - 人工階段已經在積累"隱性知識"

2.3 第二階：腳本化 + 局部自動化（Week 2）

狀態： - 自動化率：20% - 人工佔比：80% - 中間產物：檢查腳本、統計腳本、格式轉換腳本

典型場景：

Day 3-4: 標註30章，發現重複勞動
  ├─ 人工：標註（80%時間）
  └─ 發現模式：
      - 每章結束都要手動統計實體數 → 寫 count_entities.py（10分鐘）
      - 每次提交前都要檢查格式 → 寫 lint_format.py（30分鐘）
      - 每次都要生成markdown索引 → 寫 generate_index.py（1小時）

Day 5-7: 使用腳本標註30章
  ├─ 人工：標註（60%時間，↓20%）
  ├─ 腳本：自動檢查/統計/生成（20%時間，但只需運行命令）
  └─ 節省時間：20% → 用於標註更多章節

關鍵進展： - 從"純手工"到"腳本輔助" - 腳本是第一層知識固化（從隱性→顯性） - 但腳本還需人工觸發（半自動化）

2.4 第三階：SKILL 總結 + 工作流自動化（Week 3-4）

狀態： - 自動化率：60% - 人工佔比：40% - 中間產物：SKILL文檔、Agent反思工作流

典型場景：

Week 3: 完成130章初版，回顧30個腳本
  ├─ 發現：腳本之間有共同模式
  ├─ 總結：寫 SKILL_02_實體標註反思.md
  │   - 記錄：18類實體的識別規則
  │   - 記錄：12條常見錯誤模式
  │   - 記錄：腳本使用的最佳順序
  └─ 自動化升級：
      - 寫 workflow_entity_reflect.sh（串聯所有腳本）
      - Agent讀取SKILL → 自主執行反思流程
      - 人工只需：啓動workflow + 審查結果

Week 4: 第一輪反思，Agent自動修正1010處
  ├─ 人工：啓動Agent + 審查（10%時間）
  ├─ Agent：讀SKILL → 自動識別問題 → 自動修正（90%時間）
  └─ 新產出：
      - 反思報告（Agent自動生成）
      - 新發現的25條錯誤模式（Agent總結）

關鍵進展： - SKILL = 工作流的"DNA"（可被Agent讀取和執行） - 從"人寫腳本"到"Agent讀SKILL自動執行" - 人從"執行者"變為"審查者"（人工佔比從100%→40%）

2.5 第四階：自動總結 SKILL（Week 5-8）

狀態： - 自動化率：90% - 人工佔比：10% - 中間產物：自動生成的SKILL更新、模式庫自動擴展

典型場景：

Week 5: 第二輪反思，發現新模式
  ├─ Agent執行反思（自動）
  ├─ Agent發現新模式（自動）
  └─ **Agent自動更新SKILL**（新！）
      - 讀取 SKILL_02_實體標註反思.md
      - 檢測到新模式P26："確定性分層不清晰"
      - 自動追加到SKILL文檔：
        ```
        ### 模式P26: 確定性分層不清晰
        - 發現於：第二輪反思（2026-03-10）
        - 頻率：431處
        - 修正方法：明確"確定"/"推定"/"估算"三級
        ```
      - 人工只需審查是否合理

Week 6-8: 連續三輪反思
  ├─ Agent讀取不斷更新的SKILL
  ├─ 每輪自動總結新模式（如果有）
  ├─ 自動更新SKILL → 下輪自動應用
  └─ 人工：每輪只需10%時間審查

關鍵進展： - 總結本身自動化了！ - SKILL從"人寫"變為"Agent寫+人審" - 知識增殖進入自循環（SKILL → Agent → 新SKILL → Agent'）

2.6 第五階：元進化（進化的進化）（Week 9+）

狀態： - 自動化率：99% - 人工佔比：1%（只管理異常情況） - 中間產物：元SKILL（關於如何總結SKILL的SKILL）

典型場景：

Week 9-10: 跨章節事件關係提取
  ├─ Agent讀取 SKILL_05_事件關係提取.md
  ├─ 發現：這個SKILL和 SKILL_02_實體標註 有共同模式
  └─ **Agent自動提煉元SKILL**：
      - 創建 00-META_迭代工作流.md
      - 提煉通用原則：廣度優先、模式驅動、指數衰減...
      - 這些原則可應用於任何反思任務

Week 11+: 新任務（戰爭事件提取）
  ├─ Agent讀取 00-META_迭代工作流.md（元SKILL）
  ├─ Agent自動生成任務專用SKILL：SKILL_05e_戰爭事件識別.md
  │   - 基於元SKILL的模板
  │   - 自動適配具體任務
  └─ 執行任務（99%自動，1%人工審查異常）

進化的進化：
  ├─ 元SKILL本身也在進化
  ├─ Agent觀察到5個具體SKILL的共同演化模式
  └─ 自動更新元SKILL："SKILL演化三階段模型"

關鍵進展： - 進化機制本身在進化！ - SKILL → 元SKILL → 元元SKILL（遞歸抽象） - 系統接近"自治"（Self-Sustaining）

2.7 自舉的數學模型

知識增殖公式：

第N輪知識量 = 第N-1輪知識量 × (1 + 總結效率)

示例（史記項目）：

Week 1（人工階段）：
  知識量 = 5章數據 + 30輪對話
  總結效率 = 0（未總結）

Week 2（腳本階段）：
  知識量 = 30章數據 + 10個腳本
  總結效率 = 0.2（腳本複用20%勞動）

Week 3（SKILL階段）：
  知識量 = 130章數據 + 10個腳本 + 5個SKILL
  總結效率 = 0.6（Agent自動化60%）

Week 4-8（自動總結階段）：
  知識量 = 數據 + 腳本 + SKILL + 元SKILL
  總結效率 = 0.9（Agent自動化90%，包括總結本身）

累計增長：
  1.0 → 1.2 → 1.8 → 3.4 → 6.5
  （指數增長）

自動化率增長曲線：

人工佔比隨時間遞減：
Week 1:   100% ████████████████████
Week 2:    80% ████████████████
Week 3:    40% ████████
Week 4:    20% ████
Week 8:    10% ██
Week 12+:   1% ▌

2.8 自舉的關鍵條件

條件1：中間產物可讀

✓ 對話記錄（Markdown）
✓ 腳本（Python，有註釋）
✓ SKILL文檔（結構化Markdown）

✗ 二進制文件（Agent無法讀取）
✗ 隱性知識（只在人腦中）

條件2：知識可被Agent讀取和執行

✓ SKILL用結構化格式（## 模式P01: ...）
✓ 規則用可執行形式（if X then Y）

✗ 模糊描述（"儘量做好"）
✗ 隱喻表達（"像梳頭髮一樣"）

條件3：迭代週期足夠短

✓ 每輪1-2周（快速反饋）
✗ 每輪3個月（反饋太慢，知識衰減）

條件4：人類審查閉環

✓ Agent生成SKILL → 人審查 → 確認/修正
✗ Agent生成SKILL → 直接應用（可能積累錯誤）

2.9 自舉的湧現效應

湧現1：質量突變點

前三輪：修正量 1010 → 431 → 465（緩慢下降）
第四輪：修正量突降至 167（-64%）
  ↑
原因：積累的模式達到臨界點（25條）→ 系統性覆蓋

湧現2：跨領域遷移

史記項目（12周）：
  → 方法沉澱為14個META技能

漢書項目（預估6周）：
  → 直接複用14個META技能
  → 節省50%時間（從12周→6周）
  ↑
原因：知識從"項目專有"湧現為"領域通用"

注：6周預估基於方法複用，但仍需冷啓動驗證、邊界情況處理、反思修正

湧現3：認知躍遷

執行層：修正了2119處錯誤
  ↓ 壓縮
模式層：總結出35條錯誤模式
  ↓ 壓縮
原則層：提煉出5條迭代原則
  ↓ 壓縮
洞察層：頓悟"AI質量提升是模式驅動的"
  ↑
原因：遞歸壓縮到第4層，本質自動湧現

2.10 本項目的自舉軌跡

完整演化鏈：

[人工階段] Week 1
  - 產出：5章數據 + 30輪對話記錄
  - 自動化率：0%
    ↓
[腳本階段] Week 2
  - 產出：30章數據 + 10個腳本（lint/stats/export）
  - 自動化率：20%
    ↓
[SKILL階段] Week 3-4
  - 產出：130章數據 + 5個SKILL（標註/反思/質量）
  - 自動化率：60%
    ↓
[Agent自動反思] Week 5-8
  - 產出：5輪反思修正（2119處）+ 35條錯誤模式
  - 自動化率：90%（Agent讀SKILL自動執行）
    ↓
[自動總結SKILL] Week 9-10
  - 產出：Agent自動更新SKILL（新模式→自動追加）
  - 自動化率：95%（包括總結本身）
    ↓
[元SKILL提煉] Week 9-11
  - 產出：8個META技能文檔（迭代/柳葉刀/反思...）
  - 自動化率：98%（跨任務通用方法）
    ↓
[元元SKILL] Week 12+
  - 產出：本文檔（好東西都是總結出來的）
  - 自動化率：99%（關於總結本身的總結）
    ↓
[系統自治] Future
  - 目標：Agent自主完成新古籍項目（漢書/資治通鑑）
  - 自動化率：99.9%（人只管理1%的異常情況）

人工時間投入：

階段                  總工作量    人工投入    自動化率
Week 1（冷啓動）        40小時     40小時       0%
Week 2（模式湧現）      40小時     32小時      20%
Week 3-4（批量執行）    80小時     32小時      60%
Week 5-8（反思迭代）    40小時      4小時      90%
Week 9-12（元知識）     20小時      1小時      95%

總計：220小時總工作，109小時人工
節省：vs 傳統400小時全人工，節省73%人工成本

知識資產增長（真實數據）：

腳本工具：5個 → 25個 → 59個（最終）
項目SKILL：0個 → 15個 → 41個（史記專用）
META技能：0個 → 8個 → 14個（跨項目通用）
元元SKILL：0個 → 0個 → 1個（本文檔，跨領域）

資產價值（漢書項目複用預估）：
  - 腳本工具：90%可複用（只需微調參數）
  - 項目SKILL：60%可遷移（需適配古籍差異）
  - META技能：100%直接用（方法論通用）
  - 元元SKILL：100%直接用（演進式方法論）

三、本項目的總結實踐

3.1 實體標註：從混亂到18類本體

第零次總結（Day 1-2，冷啓動）

手動標註5章，發現需要的類型：
  - 人物（明確）
  - 地點（明確）
  - 官職（明確）
  - 時間（明確）
  - 其他（模糊，暫時全放這裏）

→ 最小本體v0.1：4+1類

第一次總結（Day 5，模式湧現）

全量標註30章，發現"其他"類中隱藏的模式：
  - 邦國（齊、楚、秦...）不是地名，需單獨分類
  - 氏族（姬、嬴、羋...）不是人名，需單獨分類
  - 器物（劍、鼎、鍾...）不是普通名詞，需標註
  - 典籍（《詩》、《書》...）高頻出現，需標註

→ 本體v0.5：4+4=8類

第二次總結（Day 10，分類細化）

全量標註130章，發現8類仍不夠：
  - 官職需拆分為"官職"和"爵位"（語義不同）
  - 地名需拆分為"地名"和"山川"（用法不同）
  - 時間需拆分為"朝代"、"年號"、"節氣"
  - 新增"制度"類（如"井田制"、"分封制"）
  - 新增"事件名"類（如"長平之戰"、"鴻門宴"）

→ 本體v1.0：18類（穩定）

第三次總結（P1反思後，屬性補全）

18類本體穩定，但發現需要屬性：
  - 人物：需要"生卒年"、"籍貫"、"官職"
  - 地名：需要"今地對照"（如"咸陽 → 今陝西咸陽"）
  - 官職：需要"設立年代"、"職責"
  - 邦國：需要"建國/滅國年份"、"都城"

→ 本體v1.5：18類 + 平均6屬性/類

第四次總結（跨項目，方法論提煉）

史記經驗應用到《漢書》，發現：
  - 80%類型可複用（人/地/官/時/邦/族...）
  - 20%需調整（新增"年號"類，漢代年號複雜）
  - 屬性繼承90%

→ 通用古籍本體框架v2.0（可遷移）

第五次總結（本文檔，方法論）

從史記+漢書的實踐中總結出：
  - 本體不是設計的，是"長"出來的
  - 最小可行本體 + 數據驅動演化
  - 屬性按需增加，不預設

→ Lean Semantic Web方法論（可傳播）

壓縮比分析：

原始數據：32,022個實體標註
  ↓ [第一次總結]
18類實體類型
  ↓ [第二次總結]
平均6屬性/類 = 108個屬性定義
  ↓ [第三次總結]
3條核心原則（最小本體、數據驅動、按需演化）
  ↓ [第四次總結]
1個洞察（本體是長出來的）

3.2 事件年代：從1010處錯誤到5條原則

第一輪總結（1010處修正 → 25條模式）

原始錯誤（部分）：
  - 001章："武王伐紂"標註為-1050，實際-1046
  - 003章："齊桓公即位"標註為-705，實際-685
  - 005章："晉文公稱霸"標註為-632，實際-636
  ... （1010處）

總結出25條錯誤模式：
  P01: 單錨點塌縮（多個事件共享同一個錨點年份，未展開）
  P02: 確定性不足（能從編年表驗證的未標註為"確定"）
  P03: 世系年代估算（父子/兄弟之間的年代推算錯誤）
  P04: 跨章不一致（同一事件在不同章節年份矛盾）
  ...
  P25: 諸侯在位年錯誤（某些諸侯在位年數據庫有誤）

第二輪總結（431處修正 → 新模式1條）

原始錯誤（部分）：
  - 006章："秦穆公卒"年份需升級為確定（-621）
  - 015章："趙武靈王即位"需修正為-325
  ... （431處）

新模式：
  P26: 確定性分層不清晰（需明確"確定"/"推定"/"估算"三級）

第三輪總結（465處修正 → 錨點污染問題）

發現：第二輪修正量未減少 → 說明有新問題

新問題：
  - 第二輪的"確定性升級"引入了錨點污染
  - 部分"確定"年份本身有誤，污染了其他事件

→ 新原則：在修正前先驗證錨點質量

第四輪總結（167處修正 → 跨章驗證原則）

發現：跨章同事件年份不一致

新原則：
  - 建立"事件標準年份表"（canonical year）
  - 所有章節引用同一事件時，年份必須一致

第五輪總結（46處修正 → 收斂）

修正量<5%，新模式=0

→ 方法收斂

最終總結（五輪 → 5條迭代原則）

原則1: 廣度優先
  - 來源：P0階段如果深度優先，會因系統性錯誤大量返工
  - 表述：先130章全覆蓋（60%質量），再迭代提升

原則2: 模式驅動
  - 來源：1010處錯誤→25條模式，壓縮比40:1
  - 表述：每輪核心產出是錯誤模式表，而非修正數據

原則3: 指數衰減
  - 來源：修正量1010→431→465→167→46（平均衰減率43%）
  - 表述：修正量應指數衰減，否則說明有系統性遺漏

原則4: 新模式歸零
  - 來源：P2後仍發現新模式 → 說明P0/P1質量太低
  - 表述：收斂的標誌是新模式=0（連續兩輪）

原則5: 交叉驗證
  - 來源：跨章不一致問題在第四輪才暴露
  - 表述：單章質量高不等於全局質量高，需跨章交叉驗證

再次總結（5條原則 → 1個洞察）

洞察: AI生成內容的質量提升不是線性的，是模式驅動的
  - AI的錯誤是系統性的（不是隨機的）
  - 發現模式比修正數據更重要
  - 迭代收斂比一次完美更現實

3.3 柳葉刀方法：從大量實驗到混合方案矩陣

實驗階段（Week 1-2）

任務：提取7652條事件關係

嘗試方案A（純LLM）：
  - 成本：507萬對 × $0.01 = $41,000
  - 時間：11小時
  - 精度：87%
  - 召回：92%
  → 成本太高，不可接受

嘗試方案B（純規則）：
  - 成本：$50（開發時間）
  - 時間：5分鐘
  - 精度：95%
  - 召回：68%
  → 召回太低，遺漏大量關係

嘗試方案C（簡單混合：規則+LLM順序執行）：
  - 成本：$2,100
  - 時間：3小時
  - 精度：89%
  - 召回：85%
  → 改進，但仍有優化空間

第一次總結（Week 3，分類策略）

總結：不同關係類型適合不同方法

跨章關係（co_person, co_location, concurrent）：
  - 特點：結構化匹配（實體共現、時間對齊）
  - 方案：代碼自動化（精度98%，成本$0）

章內關係（sequel, causal, part_of）：
  - 特點：語義理解（時序、因果、層次）
  - 方案：LLM推理（精度87%，成本$380）

→ 混合方案v1.0：按關係類型分工

第二次總結（Week 4，進一步優化）

發現：跨章也有因果關係，但候選太多

優化：規則前置篩選 + LLM二次推理
  1. 規則篩選：共享實體+時間接近 → 2.5萬候選對
  2. LLM推理：語義判斷因果關係 → 352條

→ 混合方案v2.0：規則篩選 + LLM精煉

第三次總結（跨項目，方法論提煉）

從事件關係、人名消歧、戰爭提取的實踐中總結：

決策樹：
  ├─ 有明確規則？→ 規則+代碼
  ├─ 結構化匹配？→ 代碼算法
  ├─ 需語義理解？→ LLM
  └─ 可安全自動？→ 規則+LLM+人工

→ 任務分工決策樹（通用框架）

第四次總結（方法論文檔）

從決策樹中再次總結：

核心原則：
  1. 精細分解（複雜任務→可優化模塊）
  2. 混合驅動（LLM/規則/代碼各取所長）
  3. 成本意識（不盲目用LLM）

→ 柳葉刀方法（00-META_柳葉刀方法.md）

第五次總結（本文檔）

從柳葉刀方法的形成過程中提煉：

洞察: 最優方案不是設計出來的，是從對比實驗中總結出來的
  - 預設"LLM最好"或"規則最好" = 教條
  - 實驗A/B/C → 總結混合策略 = 科學
  - 混合方案矩陣 = 歸納的產物

四、為什麼好東西都是總結出來的？

4.1 認知科學基礎

人類理解的本質是模式識別

原始數據（低熵，無結構）
    ↓ [歸納/總結]
模式/規律（高熵，有結構）
    ↓ [壓縮/抽象]
原理/洞察（極高熵，本質）

示例：從案例到洞察

案例層（130章×平均100次標註錯誤 = 13,000個錯誤）
  ↓ [第一次總結]
模式層（25條錯誤模式："單錨點塌縮"、"確定性不足"...）
  ↓ [第二次總結]
原則層（5條迭代原則："廣度優先"、"模式驅動"...）
  ↓ [第三次總結]
哲學層（1個核心洞察："AI質量提升不是線性的，是模式驅動的"）

為什麼不能跳過： - 直接從13,000個錯誤→1個哲學 = 沒有中間抽象層 = 無法執行 - 模式層是可操作的知識（"下次遇到X，就做Y"） - 原則層是可遷移的方法（適用於漢書、資治通鑑） - 哲學層是可傳播的洞察（適用於所有AI知識工程）

4.2 工程實踐基礎

預設 vs 總結的對比

本項目的核心選擇：總結驅動

傳統方案（預設）:
  Week 1-4: 設計18類實體的完整本體（50屬性/類）
  Week 5: 開始標註，發現：
    - "族"類需要"分支"屬性（本體沒有）
    - "官"類不需要"籍貫"屬性（本體有，但無數據）
    - "邦"類需要拆分為"邦國"和"地名"（本體未區分）
  Week 6: 本體重構，數據返工
  → 總耗時6周，士氣低落

本項目方案（總結）:
  Day 1-2: 最小本體（4類：人/地/官/事件）
  Day 3-4: 標註30章（發現需要"族"、"邦"、"物"...）
  Day 5: 總結出18類實體（基於實際數據）
  Day 6-10: 全量標註130章
  → 總耗時2周，本體自然湧現

為什麼總結更優： - 現實優先 — 數據告訴我們需要什麼，而非我們猜測 - 增量演化 — 本體從簡到繁，每次增加都有數據支撐 - 風險可控 — 即使初期本體不完美，後期可迭代修正

4.3 知識複用基礎

總結的複利效應

項目1（史記，12周）
  ├─ 產出數據：32,022實體、3,092事件、7,652關係
  └─ 產出方法：9階段管線、5個META技能、20+工具

項目2（漢書，預估6周）
  ├─ 數據從零開始
  └─ 方法繼承80%（只需微調）
      → 節省6周（50% ↓）

項目3（資治通鑑，預估20周）
  ├─ 數據從零開始
  └─ 方法繼承90%
      → 節省20周（50% ↓）

累計收益：
  - 項目1：12周
  - 項目2：6周（節省6周）
  - 項目3：20周（節省20周）
  - 總耗時：38周 vs 預估76周（傳統方案）

總結是資產，數據是消耗品

啓示：投入時間總結方法 = 長期ROI最高的活動

五、如何總結？五層抽象金字塔

5.1 第一層：原始案例（具體事實）

特徵： - 具體、獨立、不可複用 - 數量巨大（13,000+ 錯誤案例） - 信息密度低（大量冗餘）

示例：

案例1: 001章第37段，"周武王"誤標為"武王"（缺消歧符）
案例2: 003章第52段，"齊桓公"誤標為"桓公"（缺消歧符）
案例3: 005章第89段，"晉文公"誤標為"文公"（缺消歧符）
...
案例423: 089章第12段，"漢武帝"誤標為"武帝"（缺消歧符）

問題：423個案例，每個都單獨處理 = 不可擴展

5.2 第二層：錯誤模式（歸納規律）

特徵： - 抽象、通用、可批量修正 - 數量適中（20-30條/輪） - 信息密度高（一條模式覆蓋數百案例）

示例（從上述案例總結）：

模式P01: 短名缺消歧符
  ├─ 定義：諡號/爵位（如"武王"、"桓公"）未標註所屬邦國
  ├─ 頻率：423處（覆蓋37章）
  ├─ 修正方法：掃描上下文，提取前置邦國標記（如&周&@武王@ → &周武王&）
  └─ 自動化：可編寫腳本批量修正（準確率95%+）

價值： - 1條模式 = 423個案例的壓縮 - 壓縮比：423:1 - 下次遇到類似問題，直接應用模式（不再逐個處理）

5.3 第三層：方法原則（通用策略）

特徵： - 跨任務通用（不限於具體錯誤類型） - 數量少（5-10條） - 可指導整個工序

示例（從25條錯誤模式中再次總結）：

原則1: 廣度優先
  ├─ 來源：模式P01-P25顯示，系統性錯誤只有全量處理後才能發現
  ├─ 適用：所有需要質量迭代的工序
  └─ 表述："先快速覆蓋全部數據（60%質量），再迭代提升（→97%）"

原則2: 模式驅動
  ├─ 來源：修正量從1010→431→465呈指數衰減（基於模式積累）
  ├─ 適用：所有Agent反思任務
  └─ 表述："每輪迭代的核心產出是錯誤模式表，而非修正數據"

原則3: 梯度收緊
  ├─ 來源：P0階段追求完美 → 進度慢；P3階段標準松 → 質量差
  ├─ 適用：所有質量標準設計
  └─ 表述："質量基線隨輪次動態調整（P0-60% → P1-80% → P2-90% → P3-97%）"

價值： - 3條原則 = 25條模式的壓縮 - 可遷移到其他任務（事件提取、關係構建...） - 形成可執行的工作流程

5.4 第四層：核心洞察（本質認知）

特徵： - 跨領域通用（不限於古籍知識工程） - 數量極少（1-3條） - 改變認知框架

示例（從5條原則中再次總結）：

洞察1: AI生成內容的質量提升不是線性的，是模式驅動的
  ├─ 來源：5輪迭代，修正量指數衰減（1010→431→465→167→46）
  ├─ 本質：AI的錯誤不是隨機的，而是系統性的
  ├─ 推論：
  │   - 發現模式 > 修正數據
  │   - 迭代收斂 > 一次完美
  │   - 廣度優先 > 深度優先
  └─ 適用：所有LLM驅動的知識工程項目

洞察2: 好的本體不是設計出來的，是從數據中"長"出來的
  ├─ 來源：本體從4類→18類的演化過程
  ├─ 本質：預設本體 vs 數據現實 總有鴻溝
  ├─ 推論：
  │   - 最小本體起步
  │   - 按需增加屬性
  │   - 數據驅動演化
  └─ 適用：所有語義建模任務（Lean Semantic Web）

洞察3: 總結是壓縮，壓縮是理解，理解是價值
  ├─ 來源：13,000案例→25模式→5原則→2洞察 的遞歸壓縮
  ├─ 本質：信息熵的遞增 = 知識密度的提升
  ├─ 推論：
  │   - 沒有總結就沒有方法論
  │   - 沒有壓縮就沒有複用
  │   - 沒有抽象就沒有遷移
  └─ 適用：所有知識工作

價值： - 改變思維方式（從"做事"到"總結做事的方法"） - 跨領域複用（不限於古籍，適用於RegTech、醫療知識抽取...） - 可傳播、可教學

5.5 第五層：元哲學（認識論）

特徵： - 超越具體領域 - 關於"知識如何產生"的知識 - 本文檔本身

示例：

元命題: 好東西都是總結出來的
  ├─ 不是："好東西都是設計出來的"（傳統工程觀）
  ├─ 不是："好東西都是學習出來的"（端到端深度學習）
  ├─ 而是："好東西是從大量實踐中歸納/壓縮/抽象出來的"
  └─ 適用：所有創造性知識工作

推論1: 總結先於設計
  - 設計是基於總結的（先有經驗，再有理論）
  - 沒有總結的設計 = 空中樓閣

推論2: 歸納優於演繹（在模糊問題域）
  - 演繹需要完備公理（古籍知識工程沒有）
  - 歸納從數據出發（更魯棒）

推論3: 迭代優於一次性
  - 總結需要樣本（第一次總結質量有限）
  - 迭代 = 多次總結 + 遞歸壓縮

六、如何培養"總結思維"？

6.1 三個核心習慣

習慣1: 每次做完就問"規律是什麼"

反例（只做不總結）：

Week 1-12: 標註130章（逐章處理錯誤）
  - 每章獨立處理，不總結模式
  - 每次遇到同類錯誤都重新思考
  - 累計處理2600+個錯誤，全部人工判斷

→ 耗時12周，無方法積累
→ 下次做《漢書》還得從頭來，又是12周

正例（邊做邊總結）：

Week 1: 標註5章（冷啓動）
  → 總結：錯誤類型分佈（消歧60%、格式25%、分類15%）

Week 2: 標註30章（發現模式）
  → 總結：重複模式→開發自動檢查工具（Lint規則）
  → 產出：消歧規則庫、格式檢查腳本

Week 3-4: 批量執行130章
  → 工具自動檢查→Agent修正→人類審核異常
  → 產出：5個SKILL文檔（可複用）

Week 5-12: 反思迭代 + 提煉META技能
  → Agent自主修正2119處
  → 產出：14個META技能文檔

→ 耗時12周，產出115個可複用組件
→ 下次做《漢書》預估6周（50%時間節省）
   理由：冷啓動仍需1-2周驗證本體適配性
        批量執行雖自動化但數據量在
        新的邊界情況仍需人工處理

啓示： - 不是"做完130個→總結1次"，而是"做5個→總結→做30個→總結→做130個" - 總結越早，後續效率越高 - 總結不是額外成本，是降低未來成本的投資

習慣2: 記錄"為什麼這樣做"

反例（只記錄結果）：

## 實體分類規則

1. 人名用@標註
2. 地名用&標註
3. 官職用%標註
...
18. 朝代用~標註

正例（記錄決策過程）：

## 實體分類規則演化史

### v0.1（Day 1）
- 人名：@
- 地名：&
- 官職：%
- 其他：無標註

### v0.5（Day 5，基於30章數據總結）
- 發現：邦國（齊、楚）與地名（咸陽、邯鄲）語義不同
  → 決策：邦國單獨分類，用^標註
- 發現：氏族（姬、嬴）高頻出現
  → 決策：氏族單獨分類，用#標註

### v1.0（Day 10，基於130章數據總結）
- 發現："長平之戰"、"鴻門宴"既是事件又是名稱
  → 決策：新增"事件名"類，用$標註
- 發現：朝代（夏、商、周）與年號（元年、二年）需區分
  → 決策：朝代用~、年號用*

### 為什麼最終是18類？
  - 不是預設的（Day 1只有4類）
  - 是從數據中湧現的（每次總結都基於實際需求）
  - 穩定性驗證：130章後無新類型 → 18類已收斂

啓示： - "為什麼"比"是什麼"更重要 - 決策歷史 = 可複用的經驗 - 下次遇到類似問題，回顧決策歷史可避免重複探索

習慣3: 定期"遞歸壓縮"

什麼是遞歸壓縮：

第一次壓縮（案例→模式）
  13,000個錯誤 → 25條錯誤模式
  壓縮比：520:1

第二次壓縮（模式→原則）
  25條錯誤模式 → 5條迭代原則
  壓縮比：5:1

第三次壓縮（原則→洞察）
  5條迭代原則 → 1個核心洞察
  壓縮比：5:1

總壓縮比：13,000:1

操作方法：

每週五下午：遞歸壓縮時間（2小時）

Week 1:
  - 回顧：本週標註了30章，發現78個錯誤
  - 總結：錯誤模式表（6條新模式）
  - 壓縮：6條 → 2條原則（"消歧規則庫優先"、"格式Lint自動化"）

Week 2:
  - 回顧：本週完成全量130章
  - 總結：錯誤模式表（25條累計）
  - 壓縮：25條 → 5條原則

Week 3:
  - 回顧：第一輪反思，1010處修正
  - 總結：反思方法文檔
  - 壓縮：5條原則 → 1個洞察

Week 4:
  - 回顧：五輪反思全部完成
  - 總結：迭代工作流方法論
  - 壓縮：洞察 → META技能文檔

為什麼每週： - 太頻繁（每天）：案例不夠，總結質量低 - 太稀疏（每月）：細節遺忘，總結困難 - 每週：平衡點（案例足夠 + 記憶清晰）

6.2 三個思維工具

工具1: 對比表（發現差異才能總結規律）

示例：傳統 vs Lean Semantic Web

從對比中總結： - 規律1: 延遲決策（先數據後本體） - 規律2: 簡單起步（最小本體） - 規律3: 漸進嚴格（容錯→收緊） - 規律4: 低耦合設計（本體演化不影響數據）

工具2: 演化鏈（看到變化才能理解本質）

示例：本體演化鏈

v0.1 (Day 1)
  ├─ 4類：人/地/官/事件
  └─ 為什麼？→ 最小可行，快速啓動

v0.5 (Day 5)
  ├─ 8類：人/地/官/事件/邦/族/物/典
  └─ 為什麼？→ 數據顯示需要（30章總結）

v1.0 (Day 10)
  ├─ 18類（細分）
  └─ 為什麼？→ 分類不夠細（官≠爵，地≠山）

v1.5 (Week 3)
  ├─ 18類 + 屬性
  └─ 為什麼？→ 分類穩定，需補充屬性

v2.0 (跨項目)
  ├─ 通用框架
  └─ 為什麼？→ 漢書複用，提煉通用部分

從演化鏈中總結： - 規律1: 從簡到繁（4→8→18） - 規律2: 數據驅動（每次變化都有數據依據） - 規律3: 收斂特徵（v1.0後無新類型） - 規律4: 抽象提升（v2.0跨項目通用）

工具3: 決策樹（結構化決策過程）

示例：混合方案決策樹

任務分析
  ├─ 有明確規則？
  │   ├─ 是 → 規則+代碼
  │   │   └─ 示例：類型過濾、格式校驗
  │   └─ 否 ↓
  ├─ 結構化匹配？
  │   ├─ 是 → 代碼算法
  │   │   └─ 示例：實體共現、時間對齊
  │   └─ 否 ↓
  ├─ 需語義理解？
  │   ├─ 是 → LLM
  │   │   └─ 示例：因果推理、情感分析
  │   └─ 否 ↓
  └─ 可安全自動？
      ├─ 是 → 規則+LLM
      │   └─ 示例：規則篩選候選 + LLM確認
      └─ 否 → 人工審查

從決策樹中總結： - 規律1: 優先級（規則>代碼>LLM>人類審查） - 規律2: 成本梯度（規則最低，LLM中等，人類審查最高） - 規律3: 精度梯度（規則確定性，LLM可能錯，人類審查最準） - 規律4: 混合最優（不同任務用不同方案，Agent自動選擇）

6.3 養成總結習慣

每日（10分鐘）：
  - 今天做了什麼？（案例記錄）
  - 遇到了什麼問題？（異常記錄）
  - 有什麼重複模式？（初步歸納）

每週（2小時）：
  - 本週案例彙總（X個案例）
  - 提取錯誤模式（Y條模式）
  - 更新規則庫/工具（Z個改進）

每月（半天）：
  - 本月方法演化（v0.X → v1.X）
  - 跨任務規律總結（通用原則）
  - 文檔化沉澱（META技能更新）

七、總結的邊界與反模式

7.1 什麼時候不應該總結？

場景1: 樣本量不足

反例：

Day 1: 標註3章，發現5個錯誤
  → 立即總結："所有人名都缺消歧符"
  → 錯誤：樣本太少，規律可能是偶然

Day 2: 標註30章，發現78個錯誤
  → 重新總結：60%是消歧問題，40%是其他
  → 正確：樣本足夠，規律可靠

判斷標準： - 定量任務：樣本量>30（統計顯著性） - 定性任務：樣本量>10（模式可靠性） - 複雜任務：樣本量>100（覆蓋邊界情況）

場景2: 規律尚未穩定

反例：

第一輪：發現25條錯誤模式
  → 立即寫入正式文檔："這就是全部模式"
  → 錯誤：第二輪又發現10條新模式 → 文檔過時

第三輪：新模式歸零（連續兩輪）
  → 此時總結："25+10=35條是穩定模式集"
  → 正確：規律已收斂

判斷標準： - 新模式歸零（連續2輪） - 修正量<5%（相對總量） - 跨樣本一致性>95%

場景3: 過度泛化

反例：

從史記項目總結：
  "所有古籍都應該用18類實體分類"
  → 錯誤：漢書需要"年號"類（史記沒有），資治通鑑需要"官署"類

正確總結：
  "古籍實體分類應從4-5類最小本體開始，基於數據演化到15-20類"
  → 抽象了方法（最小本體+演化），而非具體分類

判斷標準： - 總結的是方法（可遷移），而非具體方案（項目專有） - 保留一定抽象層次，不過度具體化

7.2 總結的反模式

反模式1: 總結代替思考

表現：

遇到問題 → 立即查文檔 → 套用模式
  → 從不思考"為什麼這個模式有效"
  → 模式失效時無法應對

正確做法：

遇到問題 → 回顧模式的來源 → 理解本質 → 判斷是否適用
  → 適用：直接套用
  → 不適用：理解差異，創造新方案 → 新一輪總結

反模式2: 追求完美總結

表現：

花3天時間寫一份"完美"的總結文檔
  → 文檔太長（50頁），無人閲讀
  → 細節太多，核心洞察被淹沒

正確做法：

第一版：用1小時寫核心要點（1頁）
  → 夠用即可，不追求完美

第二版：使用過程中發現不足，補充（3頁）
  → 基於實際需求演化

第三版：跨項目複用，提煉通用部分（5頁）
  → 穩定版本

原則： - 總結也要迭代（不要追求一次性完美） - 夠用就好（過度總結 = 浪費計算資源） - 讓Agent執行反饋（總結是否有用，實際效果說了算）

反模式3: 只總結成功經驗

表現：

總結文檔：
  ✓ 成功案例：混合方案節省$40,000
  ✓ 成功案例：迭代收斂準確率97%
  ✗ 失敗案例：無

→ 問題：後來者不知道哪些坑已經踩過

正確做法：

總結文檔：
  ✓ 成功案例：混合方案節省$40,000
  ✓ 成功案例：迭代收斂準確率97%
  ✗ 失敗案例1：純LLM方案成本爆炸（$41,000）
  ✗ 失敗案例2：深度優先導致大量返工（浪費2周）
  ✗ 失敗案例3：預設50屬性本體，50%缺失值（Week 6本體重構）

→ 價值：失敗經驗 > 成功經驗（避免重複踩坑）

啓示： - 失敗案例是反向的成功經驗 - "不要做X" 比 "應該做Y" 更容易記住 - 失敗的代價 > 成功的收益 → 避免失敗更重要

八、總結的總結：元元技能清單

8.1 三個核心認知

1. 知識是壓縮
    — 從10,000案例→1個洞察 = 信息熵的遞增
2. 理解是歸納
    — 看到規律才算真正理解，沒有規律就沒有知識
3. 方法是沉澱
    — 做一次是經驗，做十次總結出來才是方法論

8.2 五層抽象金字塔

第五層：元哲學（認識論）
  ↑
第四層：核心洞察（本質認知）
  ↑
第三層：方法原則（通用策略）
  ↑
第二層：錯誤模式（歸納規律）
  ↑
第一層：原始案例（具體事實）

8.3 三個核心習慣

1. 每次做完就問"規律是什麼"
    — 不是做130個再總結，而是做5個就總結
2. 記錄"為什麼這樣做"
    — 決策歷史比結果更重要
3. 定期"遞歸壓縮"
    — 每週2小時，從案例→模式→原則→洞察

8.4 三個思維工具

1. 對比表
    — 發現差異才能總結規律
2. 演化鏈
    — 看到變化才能理解本質
3. 決策樹
    — 結構化決策過程

8.5 兩個邊界判斷

何時總結： - ✓ 樣本量足夠（定量>30，定性>10） - ✓ 規律已穩定（新模式=0，連續2輪） - ✓ 有實際用途（下次遇到可直接套用）

何時不總結： - ✗ 樣本量不足（偶然規律） - ✗ 規律未收斂（仍在快速變化） - ✗ 過度泛化（方法 vs 具體方案）

8.6 一個元洞察

好東西都是總結出來的 = 所有其他元技能的基礎

迭代工作流 ← 基於總結（錯誤模式表）
Lean Semantic Web ← 基於總結（本體從數據中"長"出來）
柳葉刀方法 ← 基於總結（混合方案矩陣）
反思工作流 ← 基於總結（Agent審查的核心是模式發現）
質量控制 ← 基於總結（Lint規則來自錯誤案例）
冷啓動 ← 基於總結（先5個樣本建立直覺）
數據體感 ← 基於總結（觀察數據的異常模式）

遞歸性： - 本文檔本身就是總結的產物（元元技能） - 總結如何總結 = 元認知 - 好東西都是總結出來的 = 終極元技能

九、實踐檢查清單（Agent自主執行版）

重要說明：本檢查清單及所有SKILL文檔都是由Agent執行、給Agent看的。 人類的角色是：引導方向、審核異常、驗收成果，而非逐步執行。

Agent執行任務時（自動觸發）

Agent在執行標註/分析/提取等任務時，自動檢查：

• [ ] 每處理5-10個樣本，自動分析："當前批次有什麼重複模式？"
• [ ] 遇到決策點時，在日誌記錄："為什麼選擇方案A而非方案B？"
• [ ] 自動分配時間：90%執行任務 + 10%模式總結與SKILL更新

人類引導：設定任務目標、檢查清單閾值（如"樣本量>10才總結"）

Agent每輪迭代後（自動總結）

Agent完成一輪標註/修正後，自動執行：

• [ ] 生成本輪統計：處理X個案例，發現Y個問題，分佈如何
• [ ] 提取錯誤模式：自動歸類為Z條模式，更新模式庫
• [ ] 更新SKILL文檔：將新模式寫入對應SKILL的"常見錯誤"章節
• [ ] 遞歸壓縮：從案例→模式→原則（自動升維）

人類引導：審核Agent總結的模式是否合理，指出過度泛化或遺漏

Agent階段性覆盤（按設定週期）

Agent按設定週期（如每完成30章、或每5輪迭代）自動覆盤：

• [ ] 生成方法演化史：從v0.1→v1.0，記錄每次調整及原因
• [ ] 提取跨任務規律：標註/反思/消歧中的共性原則
• [ ] 構建失敗案例庫：自動記錄錯誤案例，防止重複犯錯

人類引導：設定覆盤觸發條件，審核跨任務規律的通用性

Agent項目結束時（自動生成文檔）

Agent完成全部章標註後，自動生成：

• [ ] 完整方法論文檔（META技能文檔，如"迭代工作流"、"反思機制"）
• [ ] 核心洞察提煉（1-3條，如"本體是長出來的"）
• [ ] 複用價值評估（統計：自動化率、人工時間節省、可遷移組件數）

人類引導：審核文檔質量，提煉更高層次的元洞察（如本文檔）

人類的三種介入模式

1. 事前引導
   ：設定目標、閾值、檢查清單內容
2. 事中監督
   ：審核Agent總結的模式、抽查異常案例
3. 事後提煉
   ：從多個META技能中提煉元元技能（如本文檔）

核心理念：Agent執行重複性的總結工作，人類負責方向性的洞察提煉。

十、與其他元技能的關係

本文檔的位置

它不是替代別的元技能，而是解釋這些元技能是怎麼長出來的。

真實路徑是：

項目實踐 → 41 個項目 Skill → 14 個 META 技能 → 本文檔。
執行經驗先沉澱成項目 Skill。
多個項目 Skill 再被壓縮成 META 技能。
多個 META 技能 再繼續壓縮成元方法論。

所以本文檔的價值，不在於多發明了一個新概念，而在於解釋了已有方法論的共同生長機制。

核心關係： - 所有元技能都是"總結出來的"（而非預設的） - 每個元技能的形成過程都遵循五層抽象金字塔 - 元元技能是方法論的方法論

十一、後記：本文檔本身的形成過程

元技能也是從技能中總結出來的

這份元元技能文檔是如何"總結出來"的？

它遵循了完整的五層抽象過程，從具體的項目SKILL文檔中逐層提煉：

層1：原始數據（執行層）

史記項目 12 周實踐，包含 32,022 個實體、3,092 個事件、7,652 條關係。
背後還有數千個錯誤案例、數十次工具開發、數百次具體決策。

層2：項目 Skill（任務級總結）

從執行過程中，長出 41 個項目 Skill 文檔。
每個 Skill 記錄：這項任務怎麼做、遇到什麼問題、如何解決。
這是第一次壓縮：執行經驗 → 可複用 Skill。

層3：META 技能（方法論級總結）

再從 41 個 Skill 裏，提煉出 14 個 META 技能。
比如迭代工作流、柳葉刀方法、反思機制。
這是第二次壓縮：項目 Skill → 跨項目方法論。

層4：元元技能（哲學級總結）

再從 14 個 META 技能裏，發現共同結構：它們其實都是總結出來的。
OTF、JIT、Bootstrap 也因此被進一步提煉出來。
這是第三次壓縮：META 技能 → 元方法論。

層5：元哲學（本質認知）

最後收斂成一句話：好東西都是總結出來的。
這句話本身，也是總結出來的。
本文檔本身，就是這套方法論的自證。

關鍵洞察：

• 元技能不是預先設計出來的，而是從大量具體SKILL中歸納出來的
• 每個META技能都有10-30個SKILL案例支撐
• 本文檔（元元技能）有14個META技能支撐
• 這驗證了核心命題：好東西都是總結出來的，包括"總結"這個方法本身

用時： - 實踐：4個月（2025年11月-2026年3月） - 第一次總結：各工序完成後（每週2小時，累計32小時） - 第二次總結：各META技能文檔（每月半天，累計16小時） - 第三次總結：本文檔（2小時）

壓縮比： - 960小時實踐 + 48小時總結 → 本文檔（2小時閲讀） - 壓縮比：500:1

複用價值： - 本文檔可指導所有知識工程項目（不限古籍） - 預估節省：每個新項目至少20%時間（基於方法論複用）

最後一句話：

如果你記住本文檔的唯一一句話，那就是標題：好東西都是總結出來的。

然後，去總結你的工作。