Ch 1：歡迎 – 什麼是 Vibe Coding？

本章目標：讓從未接觸過 CLI 或程式碼的 BD（Business Development; 商務開發）人員，在 20 分鐘內理解三件事：(1) 什麼是 vibe coding，(2) Claude Code 是什麼，(3) AIKT 這套工具箱能幫你做什麼。讀完本章，你會知道為什麼你不需要學寫程式，也能讓 AI 幫你完成過去需要整個團隊才能做到的事。

1.1 開場比喻：你已經有一個超強助理了

想像一下這個場景。

你剛到一家新創生技公司上班，老闆跟你說：「這是你的私人助理。他會 Google 搜尋、會讀 PDF、會做 PowerPoint、會查學術論文、會幫你做盡職調查報告、會幫你排版出版品質的文件，而且他 24 小時在線，從不請假、從不抱怨，速度是一般人的 50 倍。」

你會怎麼做？

你會跟他說：「幫我查一下這家公司。」「幫我把這篇論文整理成重點。」「幫我做一份一頁式的公司介紹。」

你不會去學他是怎麼操作電腦的。你不會去研究他用哪個搜尋引擎、哪個排版軟體。你只要把需求講清楚，他就會幫你搞定。

這就是 vibe coding (氛圍寫程式) 的核心概念。

1.2 什麼是 Vibe Coding（氛圍寫程式）？

1.2.1 一句話定義

Vibe coding = 用自然語言描述你要什麼，讓 AI 幫你把事情做出來。

你不需要學 Python（Python; 一種程式語言）。你不需要學 JavaScript（JavaScript; 一種網頁程式語言）。你不需要知道什麼是 API（Application Programming Interface; 應用程式介面）。你只需要會講人話。

1.2.2 用日常比喻理解

你去餐廳吃飯，你不需要知道廚師怎麼切菜、怎麼控火候。你只要看菜單，跟服務生說：「我要一份紅燒牛肉麵，不要香菜，加辣。」

Vibe coding 就是這樣。你就是那個點餐的人。AI 就是那個廚師。你講需求，他做事。

差別在於：這個廚師不只會做菜。他還會幫你：

• 查全世界的食譜（查學術論文）
• 寫餐廳的菜單（做排版精美的文件）
• 分析對手餐廳的菜色（做公司盡職調查）
• 把今天學到的新菜色記下來，明天還記得（知識管理）

1.2.3 Vibe Coding 這個詞的由來

“Vibe coding” 這個詞是 Andrej Karpathy（Tesla 前 AI 總監、OpenAI 共同創辦人）在 2025 年提出的。他的原意是：寫程式的時候，不用逐行手敲程式碼，而是「跟著感覺走（vibe）」，用自然語言把想法告訴 AI，讓 AI 幫你寫程式。

Karpathy 在一則推文中寫到：

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

翻成白話文就是：「有一種新的寫程式方式叫 vibe coding，你完全放手，擁抱指數級的成長，甚至忘記程式碼本身的存在。」

對 BD 人員來說，我們不是在「寫程式」，而是在「指揮 AI 幫我們完成工作」。但精神完全一樣：你專注在「要什麼」，AI 專注在「怎麼做」。

1.2.3.1 Vibe Coding 不是「隨便做」

有些人聽到「vibe」可能會覺得這聽起來很隨性、不嚴謹。但事實正好相反。

Vibe coding 不是「隨便講一句話就好了」。它是「用精確的自然語言描述你的需求」。就像你跟助理說「幫我訂下週三台北飛東京的機票」——這句話雖然是自然語言，但包含了所有關鍵資訊：時間（下週三）、出發地（台北）、目的地（東京）、任務（訂機票）。

在 AIKT 裡也是一樣。你不會只說「幫我查東西」，你會說：

1paper: ADC linker payload year=2024-2026 n=15

這句「指令」告訴 Claude Code：

• 我要查論文（paper:）
• 關鍵字是 ADC linker payload
• 年份範圍是 2024 到 2026 年
• 給我前 15 篇

夠精確，也夠自然。這就是 vibe coding 的精髓。

1.2.4 傳統工作方式 vs Vibe Coding 工作方式

讓我們用 BioGenesis Corp.（一家虛構的 ADC（Antibody-Drug Conjugate; 抗體藥物複合體）平台公司）的場景來對比。

假設你是 BioGenesis Corp. 的 BD，明天要參加 AACR（American Association for Cancer Research; 美國癌症研究協會）會議，你需要在會前準備好三件事：

傳統方式：

1. 查公司資料：開 Google，搜尋對方公司名字，點進官網、ClinicalTrials.gov（美國臨床試驗登錄網站）、SEC filings（美國證券交易委員會公開文件），一個一個看，手動整理到 Word 文件裡。每個來源的資訊格式不同，你需要自己統一格式。花費：2-3 小時。
2. 查學術論文：開 PubMed（美國國家醫學圖書館的學術論文搜尋引擎），輸入關鍵字，跑出 300 多篇結果。你需要一篇一篇看標題和摘要，篩選出有用的，下載 PDF，讀完之後把重點手動抄到筆記裡。有些論文要付費才能看全文，你還得找有沒有 open access（開放取用）版本。花費：3-4 小時。
3. 做簡報 / 一頁式：開 PowerPoint 或 Canva，從零開始排版。選字型、調顏色、對齊文字方塊、找 icon、調整 logo 大小。做完之後老闆說「字太小了」，改。「顏色不對」，改。「換個版型」，重做。花費：2-3 小時。

總計：7-10 小時。整整一個工作天。而且你還累得半死。

Vibe Coding 方式（用 AIKT）：

1. 查公司資料：在 Claude Code 裡打一句 dd: Genmab，10 分鐘後拿到完整的盡職調查報告（due diligence report），包含 pipeline（研發管線）分析、合作歷史、財務摘要、SWOT（Strengths/Weaknesses/Opportunities/Threats; 優劣勢分析）分析，還附一份排版精美的 HTML 報告。
2. 查學術論文：打一句 paper: ADC linker payload year=2024-2026 n=15，5 分鐘後拿到 15 篇相關論文的結構化摘要，每篇附 PubMed ID（PMID; 論文唯一編號）、期刊名、impact factor（影響因子）。想深入問？再打 pq: "這些論文中哪些 payload 的 therapeutic index 最高？"，3 分鐘拿到答案附引文編號。
3. 做一頁式：打一句 kami: one-pager BioGenesis-Genmab-AACR，3 分鐘拿到出版品質的 PDF。字型、顏色、logo、排版全部自動搞定。

總計：20-30 分鐘。你還有時間喝杯咖啡。

以下是這兩種工作流的對比圖：

傳統 BD 工作流與 AIKT 工作流的效率對比：

flowchart LR
    subgraph Traditional["傳統 BD 工作流 -- 7-10 小時"]
        T1["Google 搜尋
手動整理"] --> T2["PubMed 逐篇下載
手動摘要"]
        T2 --> T3["PowerPoint
從零排版"]
        T3 --> T4["Word 彙整
人工校對"]
        T4 --> T5["完成"]
    end
    subgraph AIKT["AIKT 工作流 -- 20-30 分鐘"]
        A1["dd: 公司名
一句話啟動"] --> A2["paper: 關鍵字
自動跨庫搜尋"]
        A2 --> A3["kami: one-pager
自動排版"]
        A3 --> A4["完成
含 HTML 報告"]
    end
    Traditional ~~~ AIKT

1.2.5 你需要會的「程式語言」只有一種：人話

讓我再強調一次。在 AIKT 的世界裡，你要打的「程式碼」長這樣：

1dd: Genmab

或是：

1paper: ADC linker payload year=2024-2026

或是：

1kami: one-pager BioGenesis-Genmab-AACR

這不是程式碼。這是指令。就像你對 Siri 說「幫我設定明天早上 7 點的鬧鐘」一樣自然。唯一的差別是，你是用打字的而不是用說的。

你甚至不一定要用這些特定的前綴格式。你完全可以用自然語言來下指令：

1幫我查一下 Genmab 這家公司的背景，包括他們的 pipeline 和最近的合作案

Claude Code 同樣能理解你的意圖，自動幫你走到正確的 Layer。只不過，用前綴格式（dd: Genmab）比較快、比較精確。就像你去星巴克可以說「我要一杯中杯美式」，也可以說「我想要咖啡，不要太大杯，不用加奶」——兩者最後都能拿到咖啡，但前者更有效率。

1.2.6 「但我不懂技術怎麼辦？」

這是 BD 人員最常問的問題。讓我用一個表格來打消你的顧慮：

你需要的只有兩件事：

1. 知道你要什麼：例如「我想查這家公司的背景」
2. 會打字：把需求打出來

就這樣。真的就這樣。

1.3 什麼是 Claude Code（Claude 程式碼工具）？

1.3.1 用日常比喻理解

你知道 Siri 嗎？或是 Google 助理？

Claude Code 就像是「Siri 的超進化版」。差別在哪裡？

1.3.2 Claude Code 的工作模式

Claude Code 的運作很簡單。你在終端機（terminal; 一個黑底白字的文字介面，別怕，你只需要在裡面打字就好）裡跟它對話。你打一句話，它就開始工作。

什麼是終端機？ 你知道電影裡駭客在黑色螢幕上打很多綠色的字嗎？終端機長得有點像那個，但沒那麼可怕。它就是一個可以打字的視窗。你打字，電腦回應。就跟 LINE 聊天差不多，只是對話對象是電腦而不是朋友。

例如你打：

1幫我把這個 PDF 存起來，要保留表格

Claude Code 會自動判斷：「使用者提到了 PDF，要保留表格 → 這應該用 Layer 8 docling 來處理。」然後它就自動呼叫正確的工具幫你做。

你會看到它回應類似這樣的訊息：

1偵測到 PDF 檔案 + 保留表格需求 → 使用 docling 深度解析
2[載入 PDF]... 32 頁
3[OCR 文字辨識]... ✓
4[表格解析]... 8 個表格已保留
5[轉換為 Markdown]... ✓
6
7完成！存至 inbox/260628-docling-investor-deck/investor-deck.md

你不需要知道 Layer 8 是什麼。你不需要知道 docling 是什麼。你不需要知道 OCR 是什麼。你只需要說出你的需求。

1.3.2.1 你只需要看懂一種東西：「完成」

當 Claude Code 在工作的時候，螢幕上會滾動一些技術性的文字。不用擔心看不懂。你只需要看兩樣東西：

1. 進度指示：[Phase 1/7]... ✓ 表示第一步完成了
2. 最終結果：完成！存至 XXX 表示做完了，結果在 XXX 位置

中間那些你看不懂的技術細節？完全可以忽略。就像你叫計程車，你不需要看懂 GPS 導航軟體的每一個圖標，你只需要知道「到了」就好。

1.3.3 Claude Code 是如何「想」的

為了幫助你理解，這裡畫一張 Claude Code 的工作概念圖：

Claude Code 接收使用者指令後如何調度工具的概念圖：

flowchart TB
    User["你（BD 人員）"] -->|"用自然語言下指令"| Claude["Claude Code
（AI 大腦）"]
    Claude -->|"判斷該用哪個工具"| Toolbox["AIKT 工具箱
（24 個 Layer）"]
    Toolbox -->|"執行並回傳結果"| Claude
    Claude -->|"整理後回覆你"| User

就這麼簡單。三個角色：

1. 你：提出需求（用自然語言或前綴指令）
2. Claude Code：理解需求、選擇正確的工具、執行任務、回報結果
3. AIKT 工具箱：24 個專業工具，各司其職

你只需要跟 Claude Code 說話。它會自己去工具箱裡拿正確的工具。

1.3.4 Claude Code vs ChatGPT：有什麼不同？

你可能用過 ChatGPT。Claude Code 跟 ChatGPT 有一個根本性的差異：

簡單來說：ChatGPT 是「聊天機器人」，Claude Code 是「能操作電腦的 AI 助理」。ChatGPT 只能跟你聊天，Claude Code 可以幫你做事。

1.3.5 安全嗎？

一個合理的擔心：「讓 AI 操作我的電腦，安全嗎？」

答案是：AIKT 有嚴格的安全設計。

1. Claude Code 只在你的工作區裡操作。它不會跑到你的桌面去刪檔案，不會去讀你的私人照片。
2. 網路預設關閉。做 PDF 排版時，系統預設不連網路，你的文件內容不會被外洩。
3. 每一步都可追蹤。所有操作都有 log，你可以回頭查 Claude 做了什麼。

更詳細的安全設計會在 Ch 2 提到。目前你只需要知道：AIKT 是為了處理機密商業資訊而設計的，安全是第一優先。

1.4 什麼是 AIKT（AI Knowledge Template; AI 知識模板）？

1.4.1 工具箱比喻

想像你家裡有一個超大的工具箱。這個工具箱有 24 個抽屜。每個抽屜裡放著一種專用工具：

• 第 1 個抽屜放的是「萬能剪刀」 → 什麼網頁都能剪下來存起來
• 第 9 個抽屜放的是「學術探照燈」 → 照到哪篇論文就能抓到哪篇
• 第 11 個抽屜放的是「排版印表機」 → 放進去的東西出來就是出版品質的 PDF
• 第 22 個抽屜放的是「偵探套裝」 → 查公司背景、做盡職調查一氣呵成

你不需要知道每個抽屜裡的工具怎麼運作。你只要說：「我需要查一家公司的背景。」Claude Code 就會自動打開第 22 個抽屜，拿出偵探套裝，幫你完成任務。

以下是 AIKT 工具箱的概念圖：

AIKT 24 個 Layer 分為 5 大群組的工具箱概念圖：

flowchart TB
    subgraph Toolbox["AIKT 工具箱（24 Layers）"]
        subgraph Input["擷取群（把資料拉進來）"]
            L1["L1 ai-save
存網頁"]
            L2["L2 gh-save
存 GitHub"]
            L3["L3 autofetch
每日自動抓"]
            L8["L8 docling
讀 PDF/Word"]
            L9["L9 paper-search
找論文"]
        end
        subgraph Index["索引群（讓資料可被搜尋）"]
            L4["L4 graphify
知識圖"]
            L5["L5 notebooklm
AI 問答"]
            L6["L6 gitnexus
程式碼地圖"]
            L10["L10 paper-qa
論文問答"]
        end
        subgraph Output["輸出群（做成漂亮文件）"]
            L7["L7 quarkdown
Markdown 排版"]
            L11["L11 kami
出版品質 PDF"]
            L12["L12 gh-tutorial-qd
教學全套"]
            L15["L15 paper-tutorial
論文教學"]
            L17["L17 video-to-tutorial
影片教學"]
        end
        subgraph Pro["專業群（封閉任務）"]
            L18["L18 research-pipeline
多管線研究"]
            L19["L19 tu-plan-generator
藥物評估"]
            L22["L22 company-intel
盡職調查"]
        end
        subgraph Ops["維運群（系統維護）"]
            L16["L16 rtk
省 token"]
            L20["L20 sync
同步 repo"]
            L23["L23 agent-browser
瀏覽器自動化"]
            L24["L24 codex-image
圖表生成"]
        end
    end

1.4.2 AIKT 的核心價值：統一管線

過去你的工作是這樣分散的：

• 查資料 → Google
• 存檔案 → 自己的電腦桌面（或「新增資料夾(2)(最終版)(最終最終版)」）
• 讀 PDF → Adobe Acrobat
• 查論文 → PubMed 網站
• 做簡報 → PowerPoint
• 寫報告 → Word
• 查公司 → ClinicalTrials.gov + SEC + Crunchbase，各開一個瀏覽器分頁

每個步驟用不同的工具，資料散落在不同的地方。三個月後你要找當時查過的一家公司？「那個 Excel 放在哪個資料夾來著…」

AIKT 把這些全部統一成一條管線：

擷取 → 轉換 → 加工 → 檢索 → 發佈

所有資料都存在同一個地方（inbox/ 和 projects/），用同一種格式（Markdown），由同一個助理（Claude Code）操作。三個月後要找？直接問 Claude：「上次查 Genmab 的那份報告在哪？」它就能幫你找到。

1.4.3 為什麼叫「模板」（Template）？

因為 AIKT 不是一個固定的軟體。它是一個框架。就像你買了一個空的工具箱，你可以自己決定要裝哪些工具。

你可以只裝 Layer 1（存網頁）+ Layer 22（盡職調查）+ Layer 11（排版 PDF），就能覆蓋 BD 日常 80% 的工作。等你慢慢熟悉了，再把其他抽屜打開。

每個 Layer 都是獨立安裝的。你不需要一次裝 24 個。只裝你需要的就好。

1.4.4 BD 最常用的 Layer：六把瑞士刀

在 24 個 Layer 裡，BD 人員最常用的是以下 6 個：

1.5 BD 人員的「啊哈時刻」

1.5.1 一封郵件觸發的 10 分鐘奇蹟

讓我帶你走過一個真實場景。

背景：你是 BioGenesis Corp.（ADC platform; 抗體藥物複合體平台公司）的 BD。今天是 AACR 會議前兩天。你收到一封郵件：

Subject: Coffee Chat at AACR — Re: ADC Collaboration

Hi,

I’m Dr. Sarah Chen from PharmaX Therapeutics. We’re interested in exploring ADC collaboration opportunities. Would you be available for a 30-min coffee chat at AACR on Friday at 2pm?

Best regards, Dr. Sarah Chen VP, Business Development PharmaX Therapeutics

你對 PharmaX Therapeutics 一無所知。會議後天就開始了。傳統做法：花一個下午 Google、看 SEC filing、查 ClinicalTrials.gov、做簡報。

Vibe Coding 做法：

你打開 Claude Code，打了三行字：

1dd: PharmaX Therapeutics

你會看到 Claude Code 開始自動工作。螢幕上會滾動一些文字，像這樣：

 1[Phase 1/7] 基礎資訊搜集... ✓
 2[Phase 2/7] Pipeline 分析... ✓
 3[Phase 3/7] 財務與市場分析... ✓
 4[Phase 4/7] 合作歷史... ✓
 5[Phase 5/7] 專利與 IP 態勢... ✓
 6[Phase 6/7] SWOT 分析... ✓
 7[Phase 7/7] 報告彙整 + 排版... ✓
 8
 9完成！報告已存至 projects/company-intel-pharmax/
10HTML 報告：projects/company-intel-pharmax/quarkdown-out/report.html

然後你再打：

1paper: PharmaX ADC payload year=2024-2026 n=10

1[搜尋 PubMed]... 找到 23 篇
2[搜尋 bioRxiv]... 找到 7 篇
3[搜尋 Semantic Scholar]... 找到 31 篇
4[去重 + 排序]... 取前 10 篇
5[產出摘要報告]... ✓
6
7完成！結果存至 inbox/Paper/260628/pharmax-adc-payload/

最後你打：

1kami: one-pager BioGenesis-PharmaX-AACR

1[讀取 BioGenesis 品牌設定]... ✓
2[從 company-intel 報告提取關鍵數據]... ✓
3[生成 HTML 模板]... ✓
4[WeasyPrint 渲染 PDF]... ✓
5
6完成！PDF 存至 projects/BioGenesis-PharmaX-AACR/kami-out/one-pager.pdf

10 分鐘。三行指令。你拿到了：

1. 一份完整的 PharmaX 盡職調查報告（HTML + Markdown）
2. 10 篇最新的 ADC 相關論文摘要
3. 一份出版品質的一頁式 PDF，可以直接帶去會議

1.5.2 第二個場景：追蹤競品的最新論文

除了會前準備，BD 另一個常見任務是「追蹤競品的最新學術發表」。

假設你的老闆問你：「最近有沒有什麼新的 ADC linker 技術論文？我下週要跟研發團隊開會，想知道最新趨勢。」

傳統方式：開 PubMed，花 2 小時搜尋、篩選、下載、閱讀、整理重點。寫進 PowerPoint。

Vibe Coding 方式：

1paper: ADC site-specific conjugation linker year=2025-2026 n=10

5 分鐘後你拿到 10 篇最新論文的結構化摘要。然後你接著打：

1pq: "這 10 篇論文中，哪些 linker 技術能實現 DAR=4 的均一性？各自的優缺點是什麼？"

你會看到 Claude Code 對這 10 篇論文做 RAG 問答（Retrieval-Augmented Generation; 檢索增強生成——簡單說就是「先找到相關段落，再生成答案」），3 分鐘後給你一份結構化的回答，每個論點都附有引文編號：

 1根據 10 篇論文的分析：
 2
 31. Engineered cysteine conjugation (pqac-003, pqac-007)
 4   - 優點：DAR=4 均一性 >95%，生產可放大
 5   - 缺點：需 antibody 工程化，開發週期長
 6
 72. Enzymatic conjugation using sortase (pqac-002, pqac-009)
 8   - 優點：site-specific，溫和反應條件
 9   - 缺點：sortase 本身有交叉反應風險
10
113. Non-natural amino acid incorporation (pqac-005)
12   - 優點：DAR 精確控制，linker 設計自由度高
13   - 缺點：表達系統成本高
14
15(pqac-XXX) 引文對應 search-results.md 中的論文編號

然後你可以把這個結果直接轉成簡報素材：

1qd from: inbox/Paper/260628/adc-linker/search-results.md as slides

5 分鐘後你有了一份可以直接拿去開會用的 HTML 簡報。從收到老闆的要求到交付，不到 15 分鐘。

1.5.3 這不是科幻小說

你可能覺得：「這也太誇張了吧？真的能做到嗎？」

答案是：真的。而且你在讀完本教學之後，就能自己做到。

AIKT 不是一個 demo（展示品）。它是一個已經在生技公司日常使用的生產力工具。從學術論文檢索、到公司盡職調查、到專利草稿生成、到會前情資準備，都是經過實戰驗證的工作流。

它不完美。有時候搜尋結果需要人工篩選，有時候排版需要微調。但即使加上人工校對的時間，整體效率仍然是傳統方式的 10-20 倍。

本教學會一步一步教你，從零開始，到能獨立使用 AIKT 的 6 個 BD 核心 Layer。你不需要一次學會所有東西，先學最常用的 4 個就能覆蓋 80% 的日常工作。

1.6 本教學的學習路徑

1.6.1 八章旅程

本教學共 8 章，設計為漸進式學習。每一章都建立在前一章的基礎上：

1.6.2 學習路徑圖

以下是你的學習旅程。就像爬山一樣，一步一步往上：

本教學 8 章的學習路徑，從基礎概念到實戰應用：

flowchart TD
    Ch1["Ch 1：歡迎
了解 Vibe Coding"] --> Ch2["Ch 2：全景架構
認識 24 Layers"]
    Ch2 --> Ch3["Ch 3：第一次擷取
ai-save + gh-save"]
    Ch2 --> Ch4["Ch 4：查文獻
paper-search + paper-qa"]
    Ch3 --> Ch5["Ch 5：做報告
quarkdown + kami"]
    Ch4 --> Ch5
    Ch5 --> Ch6["Ch 6：BD 核心任務
company-intel 盡調"]
    Ch6 --> Ch7["Ch 7：組合技
串聯多個 Layer"]
    Ch7 --> Ch8["Ch 8：日常實戰
AACR 場景演練"]

1.6.3 你需要準備什麼

在開始之前，你需要準備以下東西：

1. 一台電腦：Mac 或 Linux。Windows 的話需要安裝 WSL（Windows Subsystem for Linux; Windows 的 Linux 子系統，你的 IT 同事會幫你裝好）。
2. Claude Code：你的公司應該已經幫你設定好了。如果沒有，請找你的 IT 同事。安裝過程大約 5 分鐘，你只需要坐在旁邊喝咖啡。
3. AIKT 工作區：同上，IT 同事會幫你 clone（複製）好。這就像是幫你在電腦上建立一個專用的工作資料夾。
4. 好奇心：這是最重要的。
5. 不需要：任何程式設計經驗。真的。零。一行程式碼都不用會寫。你人生中唯一要打的「程式碼」就是 dd: Genmab 這種前綴指令。

IT 同事快速上手指南：如果你是幫 BD 同事設定 AIKT 的 IT 人員，請參考 docs/SETUP.md 裡的安裝指南。最基本的設定只需要安裝 L1（ai-save）、L9（paper-search）、L11（kami）、L22（company-intel）四個 Layer，總共不到 30 分鐘。

1.6.4 學習建議

• 先讀 Ch 1-2（概念篇），大概 40 分鐘。不用動手。
• 然後做 Ch 3（第一次擷取），跟著教學一步一步做，大概 30 分鐘。
• 接著做 Ch 4-5（查文獻 + 做報告），這兩章是相連的，大概 1-2 小時。
• Ch 6（盡職調查）是 BD 的殺手應用，務必認真做。
• Ch 7-8 是進階的組合應用和實戰演練。

整個教學大約需要 4-6 小時。你可以分成幾天來完成。每一章都是獨立的，中間可以休息。

1.6.5 如果你只有 30 分鐘

如果你真的很忙（BD 通常都很忙），以下是「30 分鐘速成路線」：

1. 讀完本章（Ch 1）：理解 vibe coding 是什麼（10 分鐘）
2. 掃一眼 Ch 2：知道 24 Layer 分 9 組、先學哪 4 個（5 分鐘）
3. 做 Ch 6 的第一個練習：打 dd: Genmab 做一次盡調（15 分鐘）

做完這三步，你就已經能在日常工作中開始使用 AIKT 了。其他的慢慢學。

1.6.6 常見問題 FAQ

Q：我打錯指令會怎樣？ A：不會怎樣。Claude Code 看不懂的話會問你「你是想做 X 嗎？」不會造成任何損害。

Q：我可以用中文下指令嗎？ A：可以。前綴部分（dd: / paper: / kami:）用英文，但後面的內容可以用中文。例如 paper: ADC 連接子技術 year=2024-2026。

Q：如果系統跑錯 Layer 怎麼辦？ A：用前綴。前綴是最高優先級的判斷規則，不會跑錯。例如你明確打 paper: ADC linker，系統保證走 L9 paper-search。

Q：一次可以叫 Claude 做多件事嗎？ A：可以，但建議一次做一件事。做完一件再做下一件。Claude 完成後會提示你「下一步可以做什麼」，你可以根據提示繼續。

Q：做出來的報告可以自己改嗎？ A：當然可以。所有產出都是標準格式的檔案（Markdown、HTML、PDF），你可以用任何編輯器打開修改。

1.7 BD 日常任務與 Layer 的對應關係

在結束本章之前，讓我們做一個總整理。以下這張圖告訴你：BD 每天在做的事情，分別對應到 AIKT 的哪個 Layer。

BD 日常任務對應到 AIKT Layer 的關係圖：

flowchart LR
    subgraph BD_Tasks["BD 日常任務"]
        BT1["收到一篇文章連結"]
        BT2["要查一家公司"]
        BT3["要找相關論文"]
        BT4["對方寄來 PDF"]
        BT5["要做一頁式"]
        BT6["要做會前準備"]
        BT7["要做 equity report"]
        BT8["要追蹤競品動態"]
    end
    subgraph Layers["對應的 AIKT Layer"]
        LL1["L1 ai-save"]
        LL22["L22 company-intel"]
        LL9["L9 paper-search"]
        LL8["L8 docling"]
        LL11a["L11 kami
（one-pager）"]
        LL22b["L22 company-intel
（meeting 模式）"]
        LL11b["L11 kami
（equity-report）"]
        LL3["L3 autofetch"]
    end
    BT1 --> LL1
    BT2 --> LL22
    BT3 --> LL9
    BT4 --> LL8
    BT5 --> LL11a
    BT6 --> LL22b
    BT7 --> LL11b
    BT8 --> LL3

看到了嗎？BD 的每一項日常任務，都有對應的 Layer。而且大部分只需要一行指令。

1.7.1 傳統工具 vs AIKT Layer 對照

為了幫助你理解 AIKT 取代了哪些傳統工具，這裡做一個詳細的對照表：

重要觀念：AIKT 不是要「取代」這些工具。你仍然可以用 Google、PubMed、PowerPoint。AIKT 是幫你把這些重複性的工作自動化，讓你把時間花在更有價值的事情上——例如判斷要不要跟這家公司合作、怎麼設計 deal structure、如何向老闆呈現你的分析。

1.7.2 AIKT 不做什麼

為了設定正確的期望，以下是 AIKT 不做的事情：

• 不做決策：AIKT 幫你收集和整理資訊，但最終的商業判斷還是你做。
• 不寫 email：AIKT 不是 email 寫作工具（雖然你可以用 L11 kami 的 letter 模板生成正式信函的 PDF）。
• 不做財務模型：複雜的 DCF 或 NPV 計算不在範圍內。
• 不保證資料 100% 正確：所有 AI 生成的內容都應該經過人工驗證。

1.8 本章小結

讓我們回顧本章的重點：

1. Vibe Coding 不是寫程式。它是用自然語言告訴 AI 你要什麼，讓 AI 幫你做事。你不需要學任何程式語言。

2. Claude Code 是你的超級助理。你只要打字告訴它需求，它會自動判斷該用哪個工具、怎麼做，然後把結果交給你。

3. AIKT 是一個有 24 個抽屜的工具箱。每個抽屜（Layer）負責一件專門的事。你不需要一次學會所有 Layer，先學最常用的 6 個就夠了。

4. BD 的日常工作都有對應的 Layer。查公司 → L22、查論文 → L9、做一頁式 → L11、存網頁 → L1、讀 PDF → L8、做報告 → L7。

5. 從 7-10 小時到 20-30 分鐘。這不是誇大。這是 AIKT 的實際效率提升。

準備好了嗎？翻到下一章，我們來看看這 24 個 Layer 的全貌。

下一章預告：Ch 2 全景架構 – 你會看到 24 個 Layer 的完整地圖，了解它們分成哪 9 個群組，以及 BD 應該先學哪些、後學哪些。

Ch 2：全景架構 – 24 Layers 一覽

本章目標：讓你在 30 分鐘內建立 AIKT 24 Layer 系統的全景認知。你不需要背下每個 Layer 的細節，但你需要知道：(1) 24 個 Layer 分成哪幾組，(2) 它們之間怎麼協作，(3) 作為 BD，你應該先學哪些、後學哪些。本章是整份教學的「地圖」，後面每一章都是在這張地圖上走特定路線。

2.1 為什麼是 24 個 Layer？

2.1.1 不是一次設計出來的

AIKT 的 24 個 Layer 不是某個工程師在白板上畫出來的「完美架構」。它是從實際工作中長出來的。

就像你家的工具箱一樣。一開始你可能只買了一把螺絲起子（Layer 1 ai-save，存網頁）。後來你發現需要剪東西，就買了剪刀（Layer 8 docling，讀 PDF）。後來又要鑽洞，又買了電鑽（Layer 22 company-intel，盡職調查）。工具箱裡的東西越來越多，但每一件都是因為真的需要才加進去的。

AIKT 也是這樣。從 2026 年 4 月開始，每當發現一個重複出現的工作流（例如「每次收到一個網頁連結，都要手動存起來」），就把它固化成一個 Layer，配上專屬的指令前綴、專屬的腳本入口、專屬的輸出位置。

24 之所以是 24，不是因為 24 是個好數字，而是因為到目前為止，剛好識別出了 24 種不同的工作流。

備註：24 個 Layer 中，L14（meeting-intel）已被 L22（company-intel）吸收，標記為 deprecated（已棄用）。L21 在目前版本中保留但不啟用。所以實際活躍的 Layer 是 22 個。但為了編號的連續性，我們仍然稱整個系統為「24 Layers」。

2.1.2 Layer 之間不是孤島

一個很重要的概念：這 24 個 Layer 雖然各自獨立，但它們不是互相隔離的孤島。很多 Layer 設計時就考慮了「下一步交給誰」。

舉個例子：

• 你用 paper: ADC linker payload 找到了 10 篇論文（Layer 9）
• 系統會提示你：「找到 10 篇。需要我用 paper-qa-lite 幫你問問題嗎？」（Layer 10）
• 你問了問題拿到答案，又可以說：「把這些整理成教學文件」（Layer 15）
• 最後你可以說：「排版成 HTML 報告」（Layer 7）

Layer 之間的邊界明確，但允許清楚、可追蹤的跨 Layer 協作。就像接力賽一樣，每一棒跑的人不同，但棒子（資料）是連續傳遞的。

2.2 九大群組：BD 視角的分類

從 BD 的角度來看，24 個 Layer 可以分成 9 個群組。這個分法不是系統本身的技術分類（系統內部分成 5 個群組），而是從「BD 人員關心什麼」的角度重新整理的。

以下是完整的 24 Layer 架構圖，按 9 大群組排列：

AIKT 24 Layer 按照 BD 視角的 9 大群組分類架構圖：

flowchart TB
    subgraph G1["知識擷取群：把東西存進來"]
        L1["L1 ai-save
存網頁 / 文字片段"]
        L2["L2 ai-gh-save
存 GitHub repo 資訊"]
        L3["L3 ai-autofetch
每日自動抓 AI 新知"]
    end
    subgraph G2["深度解析群：看懂複雜的東西"]
        L4["L4 graphify
知識圖譜"]
        L5["L5 ai-notebooklm
NotebookLM AI 問答"]
        L6["L6 gitnexus
程式碼符號圖"]
    end
    subgraph G3["排版發佈群：讓東西變漂亮"]
        L7["L7 quarkdown
Markdown 排版"]
        L11["L11 kami
出版品質 PDF"]
        L24["L24 codex-image
圖表生成"]
    end
    subgraph G4["文件轉換群：讀別人的檔案"]
        L8["L8 docling
PDF / Word / PPT / Excel"]
    end
    subgraph G5["學術研究群：找論文、問論文"]
        L9["L9 paper-search
跨 10+ 資料庫搜尋"]
        L10["L10 paper-qa-lite
本地 RAG 問答"]
        L15["L15 paper-tutorial
論文轉教學"]
    end
    subgraph G6["專利群：專利草稿"]
    end
    subgraph G7["BD 核心群：盡調 + 會前會"]
        L22["L22 company-intel
盡職調查 + 會前會"]
        L14["L14 meeting-intel
（已棄用 → L22）"]
    end
    subgraph G8["研究管線群：深度研究"]
        L17["L17 video-to-tutorial
影片轉教學"]
        L18["L18 research-pipeline
多管線研究"]
        L19["L19 tu-plan-generator
藥物資產評估"]
    end
    subgraph G9["基礎設施群：系統維運"]
        L12["L12 gh-tutorial-qd
GitHub 全套交付"]
        L16["L16 rtk
省 token"]
        L20["L20 sync
repo 同步"]
        L23["L23 agent-browser
瀏覽器自動化"]
    end
    style L14 fill:#eee,stroke-dasharray:5 5

2.2.1 第 1 群：知識擷取群（L1-L3）– 把東西存進來

日常比喻：這三個 Layer 就像你辦公桌上的「收件匣」。不管東西從哪裡來（網頁、GitHub、自動推播），都先放到收件匣裡。

BD 使用頻率：L1 每天用，L3 被動使用（自動跑），L2 偶爾用。

L1 ai-save 的降級鏈設計：

L1 ai-save 有一個聰明的設計叫「降級鏈」（fallback chain）。當它嘗試抓取一個網頁時，會依序嘗試三種方法：

1. 先用 markitdown（最快、最輕量的方法）
2. 如果 markitdown 抓不到（例如網站有反爬蟲機制），自動切換到 opencli
3. 如果 opencli 也失敗（例如需要 JavaScript 渲染的網頁），最後用 playwright（模擬真實瀏覽器）

你不需要知道這三個工具的差別。你只需要貼連結，系統會自動選擇最佳方案。

你會打的指令：

1https://www.fiercebiotech.com/some-article

你會看到 Claude Code 自動識別這是一個 URL，走 L1 ai-save 路徑，開始抓取網頁內容。完成後會顯示類似這樣的訊息：

1[嘗試 markitdown]... ✓
2[儲存 Markdown]... ✓
3
4已存至 inbox/260628-fierce-biotech-some-article.md

就這樣。一個連結，一行回應，文章就永遠存在你的知識庫裡了。

L3 ai-autofetch 的每日自動推播：

L3 是被動型 Layer。你不需要主動觸發它。IT 同事會設定一個 cron job（排程任務），讓它每天自動從以下來源抓取最新資訊：

• HackerNews（科技新聞）
• HuggingFace（AI 模型社群）
• arXiv（學術預印本）
• Dev.to（開發者社群）

你每天早上打開工作區，就能看到 inbox/ 裡多了昨天的新知摘要。就像訂閱報紙一樣，只不過這份「報紙」是 AI 幫你篩選過的。

2.2.2 第 2 群：深度解析群（L4-L6）– 看懂複雜的東西

日常比喻：如果知識擷取群是「收件匣」，深度解析群就是「分析室」。它們不只是把東西存起來，還會幫你看懂這些東西之間的關係。

BD 使用頻率：L5 中等頻率，L4 偶爾用，L6 幾乎不用（除非你想了解自家公司的技術架構）。

L4 graphify 的特殊地位：graphify 在系統中有一個特殊的地位——它不只是一個工具，更是一個「meta-tool（元工具）」。當你把大量文件丟給 graphify 分析時，它會自動找出文件之間的關聯，把它們畫成一張關係圖（knowledge graph; 知識圖譜）。你可以看到哪些主題出現最頻繁（叫做「god nodes」），哪些主題之間有緊密的關聯。

對 BD 來說，這在做「市場格局分析」時特別有用。例如你把過去半年存的 50 篇 ADC 相關文章丟給 graphify，它可能會告訴你：「最近半年的 ADC 論文高度聚焦在兩個主題：site-specific conjugation 和 bispecific ADC。兩者的交集正在快速增長。」這種跨文件的趨勢分析，人工做要花好幾天，graphify 幾分鐘就搞定了。

L5 ai-notebooklm 使用須知：L5 利用 Google 的 NotebookLM 服務做大規模 AI 問答。因為它會把你的文件上傳到 Google 的雲端服務，所以有一個重要限制：不要把機密文件（例如未公開的合作條款、專利草稿）丟進去。對於公開的學術論文和產業報告，使用上完全沒問題。

2.2.3 第 3 群：排版發佈群（L7, L11, L24）– 讓東西變漂亮

日常比喻：這就是你的「印刷廠」。把草稿放進去，出來的就是可以交給客戶、老闆、合作夥伴看的精美文件。

BD 使用頻率：L11 高頻（做文件）、L7 高頻（做報告）、L24 偶爾用。

L7 和 L11 的差別：

• L7 quarkdown 的強項是把 Markdown 排版成 HTML，適合做可以用瀏覽器開的報告。
• L11 kami 的強項是做出版品質的 PDF，適合做需要列印或正式寄送的文件。
• 簡單規則：要 HTML → L7，要 PDF → L11。

你會打的指令：

1kami: one-pager BioGenesis-overview lang=en

你會看到類似這樣的輸出：

1[讀取品牌設定]... ✓
2[生成 one-pager HTML 模板]... ✓
3[填入 BioGenesis 相關內容]... ✓
4[WeasyPrint 渲染 PDF]... ✓
5
6完成！
7HTML 原始檔：projects/BioGenesis-overview/kami/one-pager-en.html
8PDF 輸出：projects/BioGenesis-overview/kami-out/one-pager-en.pdf

2.2.4 第 4 群：文件轉換群（L8）– 讀別人的檔案

日常比喻：這是你的「翻譯官」。不管對方寄來什麼格式的檔案（PDF、Word、PowerPoint、Excel），都能翻譯成你的知識庫能理解的格式（Markdown）。

BD 使用頻率：中高頻。BD 收到的外部文件大部分是 PDF 和 Word。

docling vs markitdown 的差別：

AIKT 有兩種讀 PDF 的方式：

簡單規則：如果 PDF 很複雜（有很多表格、圖表、是掃描版），用 docling:。如果只是簡單的文字 PDF，直接貼連結用 L1 ai-save 就夠了。

你會打的指令：

1docling: ~/Downloads/PharmaX-investor-deck.pdf

你會看到：

1[偵測文件類型]... PDF（32 頁）
2[啟動 OCR 引擎]... ✓
3[解析表格]... 發現 8 個表格
4[解析圖片]... 發現 15 張圖片
5[轉換為 Markdown]... ✓
6
7完成！結果存至 inbox/260628-docling-pharmax-investor-deck/
8  - pharmax-investor-deck.md（全文 Markdown）
9  - images/（15 張圖片）

轉出來的 Markdown 可以被其他 Layer 直接使用。例如你可以接著用 L10 paper-qa-lite 對這份 investor deck 做問答，或用 L7 quarkdown 把它重新排版成你公司的格式。

2.2.5 第 5 群：學術研究群（L9-L10, L15）– 找論文、問論文

日常比喻：這是你的「學術研究助理」。幫你從全世界的學術資料庫裡找論文，讀論文，甚至把多篇論文整理成教學文件。

BD 使用頻率：L9 高頻（查論文）、L10 中頻（問論文問題）、L15 低頻（整理教學文件時才用）。

你會打的指令：

1paper: ADC linker payload year=2024-2026 n=15

你會看到系統先跳出一個分類選單：

1請選擇搜尋類別（可複選，以逗號分隔）：
2A) 生物醫學（PubMed, bioRxiv, medRxiv）
3B) 通用學術（Semantic Scholar, OpenAlex, Crossref）
4C) 預印本（arXiv, bioRxiv）
5D) 全文開放取用（CORE, Unpaywall）
6E) 以上全部
7F) 自訂組合
8
9> 你的選擇：

你輸入 E（全部），然後系統開始跨資料庫搜尋。完成後：

 1[PubMed] 找到 31 篇
 2[bioRxiv] 找到 12 篇
 3[Semantic Scholar] 找到 47 篇
 4[OpenAlex] 找到 52 篇
 5[去重]... 獨立論文 58 篇
 6[依相關性 + 引用數排序]... 取前 15 篇
 7[產出結構化摘要]... ✓
 8
 9完成！結果存至 inbox/Paper/260628/adc-linker-payload/
10  - search-results.md（15 篇論文摘要）
11  - metadata.json（原始 metadata）

2.2.6 第 6 群：專利群（L13）– 專利草稿

BD 使用頻率：低頻但高價值。一年可能只用幾次，但每次都能省下數萬美元的律師費（前期準備）。

2.2.7 第 7 群：BD 核心群（L22, 含 L14 deprecated）– 盡調 + 會前會

日常比喻：這是 BD 人員的「瑞士刀中的瑞士刀」。公司盡職調查、會前準備、競品分析，全部在這一個 Layer 裡搞定。

BD 使用頻率：高頻。這是 BD 的殺手應用。

L22 company-intel 有兩種模式：

L14 meeting-intel 原本是獨立的 Layer，後來發現會前會準備和盡職調查有大量重疊的工作（都要查公司背景、都要查 pipeline），所以把它合併進了 L22。這就像原本你有一把小刀和一把大刀，後來發現小刀能做的事大刀都能做，就只帶大刀出門了。

你會打的指令：

1dd: Genmab

你會看到系統啟動 7 階段 pipeline：

 1[Phase 1/7] 基礎資訊搜集...
 2  - 公司全名、成立年份、總部位置、員工人數... ✓
 3[Phase 2/7] Pipeline 分析...
 4  - 搜尋 ClinicalTrials.gov... 
 5  - 分析開發階段分佈... ✓
 6[Phase 3/7] 財務與市場分析...
 7  - 近期營收、市值、主要投資者... ✓
 8[Phase 4/7] 合作歷史與交易...
 9  - 歷年合作案、授權交易、收購... ✓
10[Phase 5/7] 專利與 IP 態勢...
11  - 近期專利申請、技術平台 IP 佈局... ✓
12[Phase 6/7] SWOT 分析...
13  - Strengths / Weaknesses / Opportunities / Threats... ✓
14[Phase 7/7] 報告彙整 + 排版... ✓
15
16完成！
17Markdown 報告：projects/company-intel-genmab/report.md
18HTML 報告：projects/company-intel-genmab/quarkdown-out/report.html

2.2.8 第 8 群：研究管線群（L17-L19）– 深度研究

日常比喻：如果前面的 Layer 是「查資料」，研究管線群就是「做研究」。它適用於需要花好幾天、整合好幾種資料來源的深度研究任務。

BD 使用頻率：L17 中頻（會議後整理）、L18 低頻但高價值（大型研究案）、L19 中頻（藥物評估）。

2.2.9 第 9 群：基礎設施群（L12, L16, L20, L23）– 系統維運

日常比喻：這些是「水電瓦斯」。你平時不會注意到它們，但沒有它們，整個系統就跑不動。

BD 使用頻率：大部分在背景自動運作，BD 不需要直接操作。知道它們存在就好。

L23 agent-browser 為什麼重要：

雖然你不會直接操作 L23，但它在幕後非常重要。當 L22 company-intel 在做盡職調查時，它需要從各種網站抓取資料。傳統方式（WebFetch）每抓一個網頁要消耗 2,000-10,000 個 token（你可以把 token 想像成 Claude Code 的「思考燃料」）。L23 agent-browser 用一種叫做 snapshot（快照）的技術，把同樣的工作壓縮到只需要 200-400 個 token。

這意味著什麼？同樣的「思考燃料」可以做更多事情。原本一次對話只能抓 5 個網頁的資料，現在可以抓 50 個。盡調報告的資料來源更豐富，品質更好。

你不需要操心這些技術細節。只要知道「系統在幕後幫你省了很多資源」就好。

L16 rtk 的工作原理（簡單版）：

rtk（Rust Token Killer）是另一個「省燃料」的工具。Claude Code 在執行指令時，會產生大量的技術性輸出（例如 git status 的結果可能有幾百行）。rtk 會自動過濾掉不重要的部分，只保留 Claude Code 真正需要的關鍵資訊，省下 60-90% 的 token 消耗。

簡單說：它讓 Claude Code 跑得更快、更遠、更省錢。你不需要操作它，它在背景自動運作。

2.3 九大群組全覽圖

讓我們用一張圖把 9 個群組的關係看清楚：

9 大群組的概覽，從資料輸入到最終輸出的邏輯關係：

flowchart LR
    subgraph Input["輸入端"]
        G1["知識擷取群
L1, L2, L3
把東西存進來"]
        G4["文件轉換群
L8
讀別人的檔案"]
    end
    subgraph Process["處理端"]
        G2["深度解析群
L4, L5, L6
看懂複雜的東西"]
        G5["學術研究群
L9, L10, L15
找論文、問論文"]
        G7["BD 核心群
L22
盡調 + 會前會"]
        G8["研究管線群
L17, L18, L19
深度研究"]
        G6["專利群
L13
專利草稿"]
    end
    subgraph Output["輸出端"]
        G3["排版發佈群
L7, L11, L24
讓東西變漂亮"]
    end
    subgraph Infra["基礎設施"]
        G9["基礎設施群
L12, L16, L20, L23
系統維運"]
    end
    G1 --> G2
    G4 --> G2
    G1 --> G5
    G4 --> G5
    G2 --> G7
    G5 --> G7
    G5 --> G8
    G7 --> G3
    G8 --> G3
    G6 --> G3
    G9 -.->|"支援所有群組"| Process

看這張圖的方式：

• 左邊是輸入端：把資料從外部世界拉進你的知識庫
• 中間是處理端：分析、搜尋、研究、調查
• 右邊是輸出端：把結果排版成漂亮的文件
• 底下是基礎設施：默默支撐所有其他群組

2.4 BD 人員最常用的 Layer：使用頻率分級

不是所有 24 個 Layer 都需要學。以下是 BD 人員的使用頻率分級：

BD 人員對各 Layer 的使用頻率分級圖：

flowchart TD
    subgraph Must["必學 -- 每天都會用到"]
        M1["L1 ai-save
存網頁"]
        M2["L9 paper-search
找論文"]
        M3["L11 kami
做 PDF 文件"]
        M4["L22 company-intel
盡職調查"]
    end
    subgraph Should["建議學 -- 每週會用到"]
        S1["L7 quarkdown
HTML 報告"]
        S2["L8 docling
讀 PDF"]
        S3["L10 paper-qa-lite
問論文問題"]
        S4["L2 ai-gh-save
存 GitHub"]
    end
    subgraph Nice["知道就好 -- 偶爾用到"]
        N1["L5 ai-notebooklm
NotebookLM 問答"]
        N3["L15 paper-tutorial
論文教學"]
        N4["L17 video-to-tutorial
影片教學"]
        N5["L19 tu-plan-generator
藥物評估"]
    end
    subgraph Background["不用學 -- 自動運作"]
        B1["L3 autofetch"]
        B2["L16 rtk"]
        B3["L23 agent-browser"]
        B4["其他維運 Layer"]
    end
    Must --> Should --> Nice --> Background

2.4.1 先學這 4 個

如果你只有一個下午的時間，就學這 4 個：

1. L1 ai-save：學會存網頁。這是所有知識管理的起點。
2. L22 company-intel：學會做盡職調查。這是 BD 的殺手應用。
3. L9 paper-search：學會查論文。技術對比和市場調研都靠它。
4. L11 kami：學會做文件。一頁式、equity report、正式信函。

2.4.2 然後學這 4 個

有了基礎之後，再加上這 4 個你就能覆蓋 BD 日常 95% 的工作：

5. L7 quarkdown：把任何筆記變成漂亮的 HTML 報告。
6. L8 docling：讀對方寄來的 PDF。
7. L10 paper-qa-lite：對論文集合做深度問答。
8. L2 ai-gh-save：存 GitHub repo 資訊。

2.4.3 知道就好的 Layer

剩下的 Layer 不需要刻意學。知道它們存在，等有需求的時候再翻本教學查怎麼用：

• L5 ai-notebooklm：當你有大量文件需要問答時（例如 20+ 篇論文）
• L15 paper-tutorial：要把多篇論文整理成教學文件給團隊看時
• L17 video-to-tutorial：把會議演講影片變成文字教學時
• L19 tu-plan-generator：做藥物資產評估時（可能更偏向 pharmacology 團隊）

2.5 Layer 之間如何協作：接力賽比喻

2.5.1 核心概念：檔案系統就是接力棒

AIKT 的 24 個 Layer 之間不需要複雜的通訊機制。它們用最簡單的方式傳遞資料：檔案。

就像接力賽一樣：

• 第一棒跑完，把棒子放在指定位置
• 第二棒到那個位置拿棒子，繼續跑
• 第三棒再到下一個位置拿棒子

「棒子」就是 inbox/ 和 projects/ 裡的 Markdown 檔案。

讓我們用一個實際的 BD 場景來看接力賽是怎麼跑的：

BD 場景下 Layer 之間的接力賽協作流程（從存網頁到產出 PDF 報告）：

flowchart LR
    Step1["L1 ai-save
同事傳來一個
產業報告連結"] -->|"存入 inbox/"| Step2["L22 company-intel
對報告提到的
公司做盡調"]
    Step2 -->|"存入 projects/"| Step3["L9 paper-search
查該公司相關
學術論文"]
    Step3 -->|"存入 inbox/Paper/"| Step4["L11 kami
把盡調結果
排版成 PDF"]
    Step4 -->|"輸出到 kami-out/"| Result["出版品質
盡調報告 PDF"]

每一棒的工作：

1. L1 ai-save：把同事傳來的產業報告連結存成 Markdown → 放入 inbox/
2. L22 company-intel：讀取 inbox 裡的報告，對報告提到的公司做盡調 → 放入 projects/
3. L9 paper-search：查該公司相關的學術論文 → 放入 inbox/Paper/
4. L11 kami：把盡調結果 + 論文摘要整理成一頁式 PDF → 輸出到 kami-out/

注意：你不需要手動搬移檔案。Claude Code 會自動知道上一步的結果在哪裡，自動傳給下一步。你只需要下指令。

2.5.2 自動提示「下一手」

AIKT 的每個 Layer 完成任務後，Claude Code 都會主動提示你下一步可以做什麼。例如：

當你完成 paper: ADC linker payload 後，Claude 會說：

1找到 15 篇論文，已存至 inbox/Paper/260628/adc-linker-payload/
2
3你可以：
41. pq: "哪種 linker 的穩定性最好？" → 對這 15 篇做 RAG 問答（L10）
52. paper-tutorial: inbox/Paper/260628/adc-linker-payload/ → 整理成教學文件（L15）
63. nlm: inbox/Paper/260628/adc-linker-payload/ → 丟進 NotebookLM 做問答（L5）

你不需要記住哪個 Layer 能接在哪個後面。系統會告訴你。

2.6 Cross-Layer 分流規則：餐廳點餐比喻

2.6.1 為什麼需要分流規則？

24 個 Layer，你怎麼知道打了一句話之後，系統會送去哪個 Layer 處理？

這就像去餐廳一樣。你走進一家什麼都賣的大餐廳（火鍋、壽司、義大利麵、牛排都有）。你跟櫃檯說：「我要吃壽司。」櫃檯就把你帶到壽司區。你說：「我要義大利麵。」就帶你到義大利麵區。

Claude Code 就是那個櫃檯。它根據你說的話，判斷你要去哪個「區」（Layer）。

2.6.2 五層判斷邏輯

Claude Code 的判斷邏輯分成 5 層，就像一個漏斗，從上到下：

AIKT Cross-Layer 分流的五層判斷邏輯：

flowchart TD
    Input["使用者輸入"] --> L1_check{"第 1 層
有顯式 prefix？"}
    L1_check -->|"有（如 paper: / dd: / kami:）"| L1_result["直接送對應 Layer
不可推翻"]
    L1_check -->|"沒有"| L2_check{"第 2 層
有副檔名？"}
    L2_check -->|"有（.pdf / .docx 等）"| L2_result["自動送 docling
或 video-to-tutorial"]
    L2_check -->|"沒有"| L3_check{"第 3 層
是引號路徑 + 問句？"}
    L3_check -->|"是"| L3_result["送 paper-qa-lite"]
    L3_check -->|"不是"| L4_check{"第 4 層
是 URL？"}
    L4_check -->|"GitHub URL"| L4_gh["送 ai-gh-save
或 gh-tutorial-qd"]
    L4_check -->|"其他 URL"| L4_other["送 ai-save"]
    L4_check -->|"不是 URL"| L5_check{"第 5 層
自然語言關鍵字"}
    L5_check -->|"含學術場景詞"| L5_paper["送 paper-search"]
    L5_check -->|"含盡調意圖詞"| L5_dd["送 company-intel"]
    L5_check -->|"其他"| L5_default["送 ai-save
（預設）"]

2.6.3 五層邏輯詳解

第 1 層：顯式 prefix（最高優先，不可推翻）

如果你的訊息以特定前綴開頭，Claude Code 就不用猜了，直接送去對應的 Layer。這就像你在餐廳直接說「我要 A3 號套餐」，服務生不用問你任何問題。

以下是 BD 最常用的 prefix 對照表：

BD 最常用的指令前綴與對應 Layer 的對照圖：

graph LR
    P1["paper:"] --> L9["L9 paper-search
找論文"]
    P2["pq:"] --> L10["L10 paper-qa-lite
問論文問題"]
    P3["dd: / ci:"] --> L22a["L22 company-intel
盡調模式"]
    P4["meeting: / intel: / prep:"] --> L22b["L22 company-intel
會前會模式"]
    P5["kami:"] --> L11["L11 kami
做 PDF"]
    P6["qd: / qd from:"] --> L7["L7 quarkdown
排版 HTML"]
    P7["docling:"] --> L8["L8 docling
讀 PDF/Word"]
    P8["gh: / gh full:"] --> L2["L2 ai-gh-save
存 GitHub"]
    P10["v2t:"] --> L17["L17 video-to-tutorial
影片教學"]

第 2 層：副檔名自動判斷

如果你的訊息裡包含檔案路徑，Claude Code 會看副檔名：

• .pdf / .docx / .pptx / .xlsx → 自動送 L8 docling
• .mp4 / .mkv / .webm / .mov（加上教學意圖詞）→ 自動送 L17 video-to-tutorial

第 3 層：路徑形態

如果你的訊息包含引號路徑 + 問答意圖（例如 "inbox/Paper/260628/" 哪篇論文的方法最新穎？），自動送 L10 paper-qa-lite。

第 4 層：URL 型態

• GitHub URL → L2 ai-gh-save（或 L12 gh-tutorial-qd，取決於是否包含「教學/全套/打包」等關鍵字）
• 其他 URL → L1 ai-save

第 5 層：自然語言關鍵字（最低優先）

如果以上都不符合，Claude Code 就靠關鍵字判斷：

• 包含「研究 / 論文 / literature」等學術場景詞 → L9 paper-search
• 包含「盡調 / due diligence / 查這家公司 / 會前準備」→ L22 company-intel
• 都不符合 → L1 ai-save（預設）

2.6.4 為什麼 prefix 最好用？

看到了嗎？prefix 是第 1 層，優先級最高，不可推翻。這就是為什麼在本教學中，我們鼓勵你養成打 prefix 的習慣。

不用 prefix 的時候，Claude Code 要靠猜測（第 2-5 層）來判斷你要什麼。它大部分時候猜得很準，但不是每次都對。

用 prefix 的時候，就是明確告訴它：「我要的就是這個 Layer。不用猜。」

就像在餐廳裡：

• 說「我想吃點有肉的熱食」→ 服務生可能帶你去火鍋區，也可能帶你去牛排區（猜測）
• 說「A3 號套餐」→ 服務生直接下單（prefix）

2.6.5 BD 必備 prefix 備忘單

以下是你最常用的 10 個 prefix，建議列印出來貼在螢幕旁邊（認真的）：

小訣竅：prefix 後面有一個冒號和一個空格，不要漏掉。例如 dd: Genmab（正確），不是 dd:Genmab（可能會出問題）或 dd Genmab（沒有冒號，系統會當成自然語言處理）。

2.7 資料流全景：從 URL 到最終交付物

2.7.1 整體資料流

不管你用哪個 Layer，資料的流動路徑都遵循一個簡單的模式：

資料在 AIKT 中的流動路徑，從外部輸入到最終輸出：

flowchart LR
    subgraph External["外部世界"]
        URL["URL / 連結"]
        PDF["PDF / Word"]
        GH["GitHub Repo"]
        Paper["學術論文"]
        Video["會議影片"]
    end
    subgraph Inbox["inbox/ -- 原始素材"]
        MD1["Markdown 檔案"]
        MD2["論文摘要"]
        MD3["GitHub metadata"]
    end
    subgraph Projects["projects/ -- 加工區"]
        QD["quarkdown 排版"]
        KAMI["kami 模板"]
        CI["company-intel 報告"]
        RT["research 研究"]
    end
    subgraph Output["最終交付物"]
        HTML["HTML 報告"]
        PDFO["出版品質 PDF"]
        ZIP["打包 ZIP"]
    end
    URL --> MD1
    PDF --> MD1
    GH --> MD3
    Paper --> MD2
    Video --> MD1
    MD1 --> QD
    MD2 --> KAMI
    MD3 --> CI
    MD1 --> RT
    QD --> HTML
    KAMI --> PDFO
    CI --> HTML
    RT --> ZIP

三個關鍵位置：

1. inbox/：所有從外部世界拉進來的原始素材都放這裡。就像你辦公室的收件匣。
2. projects/：加工中的半成品放這裡。就像你的工作桌面。
3. projects/<topic>/*-out/：最終成品放這裡。就像你的成品架。

2.7.2 你不需要記住這些路徑

別擔心。你不需要記住 inbox/ 和 projects/ 的完整路徑結構。Claude Code 每次完成任務都會告訴你結果存在哪裡。如果你三個月後忘了，直接問 Claude：「上次做的 Genmab 盡調報告在哪裡？」它會幫你找到。

2.8 BD 一天的 Layer 使用流程

讓我們用一個虛構的場景，走過 BD 一天可能用到的 Layer。

2.8.1 場景：BioGenesis Corp. BD 的一天

你是 BioGenesis Corp. 的 BD，今天是 AACR 會議前一天。

BD 工作日各時段使用 AIKT Layer 的互動序列圖：

sequenceDiagram
    participant BD as BD 人員
    participant Claude as Claude Code
    participant L1 as L1 ai-save
    participant L8 as L8 docling
    participant L22 as L22 company-intel
    participant L9 as L9 paper-search
    participant L11 as L11 kami
    participant L7 as L7 quarkdown

    Note over BD,L7: 上午 9:00 — 收信 + 存資料
    BD->>Claude: 貼一篇 FierceBiotech 連結
    Claude->>L1: 自動存為 Markdown
    L1-->>Claude: 存至 inbox/

    BD->>Claude: 對方寄來的 investor deck PDF
    Claude->>L8: 深度解析 PDF
    L8-->>Claude: 轉成 Markdown + 表格

    Note over BD,L7: 上午 10:00 — 會前準備
    BD->>Claude: dd: PharmaX Therapeutics
    Claude->>L22: 啟動 7 階段盡調
    L22-->>Claude: 完成盡調報告

    Note over BD,L7: 下午 1:00 — 深入研究
    BD->>Claude: paper: PharmaX ADC payload year=2024-2026
    Claude->>L9: 跨資料庫搜尋
    L9-->>Claude: 15 篇論文摘要

    Note over BD,L7: 下午 3:00 — 做文件
    BD->>Claude: kami: one-pager BioGenesis-PharmaX-AACR
    Claude->>L11: 生成 PDF
    L11-->>Claude: 一頁式 PDF

    BD->>Claude: qd from: 盡調報告路徑 as report
    Claude->>L7: 排版 HTML
    L7-->>Claude: 精美 HTML 報告

    Note over BD,L7: 下午 4:30 — 準備完成

2.8.2 一天下來用了哪些 Layer？

總計：24 分鐘的主動操作（其餘時間 Claude Code 在背景自動處理）。

2.9 系統安全設計：你需要知道的最低限度

2.9.1 三個安全原則

AIKT 有嚴格的安全設計。作為 BD 使用者，你只需要知道三件事：

2. 網路預設拒絕：kami 和 quarkdown 做 PDF / HTML 時，預設不會連上網路。你的文件內容不會被外洩。

3. 公司盡調資料保密：company-intel 的原始資料不會自動上傳到 Discord 或其他平台。你可以手動選擇分享。

2.10 本章小結

讓我們回顧本章的重點：

2.10.1 24 Layer 的 9 大群組

2.10.2 BD 學習優先序

1. 先學（每天用）：L1 ai-save、L9 paper-search、L11 kami、L22 company-intel
2. 再學（每週用）：L7 quarkdown、L8 docling、L10 paper-qa-lite、L2 ai-gh-save
3. 知道就好（偶爾用）：L5, L13, L15, L17, L19
4. 不用學（自動運作）：L3, L16, L20, L23, L4, L6, L12, L18, L24

2.10.3 三個核心概念

1. Prefix 最好用：養成打 prefix 的習慣（dd: / paper: / kami:），讓 Claude Code 不用猜。
2. 接力賽協作：Layer 之間透過檔案系統（inbox/ → projects/ → *-out/）傳遞資料。
3. Claude 會提示下一步：每個 Layer 完成後，Claude Code 會告訴你下一步可以做什麼。

準備好了嗎？下一章我們開始動手。你會親手執行你的第一個 Layer – L1 ai-save，把一篇文章存進你的知識庫。

下一章預告：Ch 3 第一次擷取 – 你會實際操作 L1 ai-save 和 L2 ai-gh-save，親手建立你的知識庫。從貼一個連結開始，到存一個 GitHub repo，全程手把手帶你走過。

Ch 3：安裝與設置 — 讓工具箱就位

前一章我們認識了 AIKT 的 24 層架構。現在要把工具箱從貨架上搬下來、組裝好、確認能用。這一章會帶你完成三件事：確認電腦環境、安裝核心系統、依優先順序啟用你需要的 Layer。

3.1 硬體與軟體需求 — 你的電腦能跑嗎？

在開始安裝之前，先確認你的電腦符合基本條件。這就像要開一間實驗室，你得先確認水電瓦斯都通了，才能擺儀器。

3.1.1 硬體最低需求

BD 人特別注意：你不需要 GPU（顯示卡）。GPU 只有在處理影片轉錄（Layer 17）時才需要，而那不是 BD 日常會用到的功能。你的 MacBook Air 或公司配的 ThinkPad 完全夠用。

3.1.2 軟體前置條件

AIKT 需要幾個基礎軟體。把它們想成「插座」——你的電器（Layer）要插上去才能用。

「這些我都不會裝怎麼辦？」 別擔心。接下來的安裝流程中，每個 Layer 的 setup 指令會自動檢查這些前置條件，缺什麼會告訴你。你不需要事先全部裝好。

3.1.3 特別說明：Windows 使用者

如果你用 Windows，需要先啟用 WSL2（Windows Subsystem for Linux; Windows 的 Linux 子系統）。這就像在 Windows 裡面開了一個小 Linux 房間。操作方式：

1wsl --install

你會看到系統開始下載 Ubuntu，完成後重開機就好。之後所有操作都在這個 Linux 環境裡進行。

你會看到： 終端機會顯示下載進度條，下載完成後會要求你設定一個使用者名稱和密碼。這個密碼是 Linux 環境用的，跟你的 Windows 密碼不同，設一個簡單好記的就好。

3.2 安裝三步驟 — Clone、Claude Code、Setup

整個安裝過程可以用三個步驟概括。把它想成買家具：第一步把箱子搬回家（clone），第二步確認你有螺絲起子（Claude Code），第三步組裝你需要的那一件（setup）。

下面這張流程圖展示了完整的安裝步驟：

flowchart TD
    A["Step 1
Clone 專案到本地"] --> B["Step 2
確認 Claude Code 可用"]
    B --> C["Step 3
執行 Layer setup"]
    C --> D{"自動檢查
前置條件"}
    D -->|通過| E["安裝完成
開始使用"]
    D -->|缺少依賴| F["顯示缺少什麼
提示安裝指令"]
    F --> G["手動安裝依賴"]
    G --> C

Step 1：Clone — 把專案下載到你的電腦

打開終端機（Terminal），輸入以下指令：

1git clone https://github.com/your-org/AI-knowledge_template.git
2cd AI-knowledge_template

你會看到： 終端機會顯示 Cloning into 'AI-knowledge_template'...，然後出現下載進度。整個過程大約 30 秒到 2 分鐘，取決於你的網路速度。完成後會回到 $ 提示符，表示下載成功。

「終端機在哪裡？」 macOS 使用者：按 Cmd + 空白鍵，輸入「Terminal」，按 Enter。Windows WSL 使用者：在開始選單搜尋「Ubuntu」。

Step 2：確認 Claude Code 可用

AIKT 的核心引擎是 Claude Code（Claude 的命令列介面工具）。確認它已經安裝：

1claude --version

你會看到： 類似 claude-code v1.x.x 的版本號。如果看到 command not found，表示還沒安裝，請找你的 IT 同事或工程團隊協助。

Claude Code 安裝完成後，你還需要設定 Discord 頻道作為你和 AI 助手的溝通介面。這部分通常由團隊管理員幫你設定好，你只需要確認你能在 Discord 頻道裡看到 Claude 的回覆就行。

Step 3：執行 Layer Setup — 安裝你需要的工具

這是最關鍵的一步。每個 Layer 都有自己的 setup 指令，格式統一：

1bash scripts/<layer-name>.sh setup

例如，要安裝 Layer 1（ai-save; 網頁儲存）：

1bash scripts/ai-save.sh setup

你會看到： 腳本會自動執行以下動作：

1. 檢查前置條件（Python、Node.js 等是否安裝）
2. 建立獨立的虛擬環境（不會影響你電腦上的其他程式）
3. 下載必要的模型或資料
4. 執行自我測試（確認安裝成功）
5. 顯示「下一步可以做什麼」的提示

如果某個前置條件沒裝好，腳本會明確告訴你缺什麼、怎麼裝。你不需要自己猜。

3.3 Layer 安裝優先順序 — 先裝哪些？

24 個 Layer 不需要一次全裝。就像廚房裡的刀具，你不需要一次買齊 20 把刀——先買一把主廚刀（萬用）、一把麵包刀（常用），其他的等需要時再添購。

我們把 Layer 分成三個優先等級：

下面這張金字塔圖展示了三個安裝等級的優先順序：

flowchart TB
    subgraph T1["Tier 1 — 必裝（BD 生存包）"]
        L1["L1 ai-save
網頁儲存"]
        L7["L7 quarkdown
Markdown 排版"]
        L22["L22 company-intel
公司盡調"]
    end

    subgraph T2["Tier 2 — 建議安裝（效率提升）"]
        L2["L2 gh-save
GitHub 儲存"]
        L8["L8 docling
PDF 深度解析"]
        L11["L11 kami
精美 PDF"]
        L23["L23 agent-browser
AI 瀏覽器"]
    end

    subgraph T3["Tier 3 — 按需安裝（進階用途）"]
        L9["L9 paper-search
論文檢索"]
        L18["L18 research-pipeline
多管線研究"]
    end

    T3 --> T2
    T2 --> T1

Tier 1：必裝 — BD 生存工具包

這三個 Layer 覆蓋了 BD 日常 80% 的需求。先把這三個裝好，你就能開始工作了。

Tier 1 安裝範例：一次裝完三個

1# 依序安裝三個必裝 Layer
2bash scripts/ai-save.sh setup
3bash scripts/quarkdown.sh setup
4bash scripts/company-intel.sh status

你會看到： 每個指令執行完會顯示 PASS 或 OK 之類的成功訊息。如果某個步驟失敗，會用紅字告訴你哪裡出問題。三個全部完成大約需要 10 分鐘。

Tier 2：建議安裝 — 效率倍增器

Tier 1 裝好之後，這四個 Layer 能讓你的工作效率再上一個台階。

小提醒：L8 docling 的安裝空間需求較大（~928 MB），因為它要下載 OCR（光學字元辨識）模型。如果你暫時不需要解析掃描版 PDF，可以先跳過，等需要時再裝。

Tier 3：按需安裝 — 進階武器庫

這些 Layer 用於特定場景，不需要提前安裝。等你真正需要時再裝即可。

BD 實務建議：如果你是剛開始用 AIKT 的 BD 新手，先專心用好 Tier 1 的三個 Layer。等你熟悉操作流程後（大約一到兩週），再考慮安裝 Tier 2。Tier 3 的東西，等專案需要時再說。

3.4 Setup 子命令詳解 — 每個 Layer 怎麼裝

所有 Layer 的安裝都遵循同一個模式：bash scripts/<name>.sh setup。這個 setup 指令背後做了四件事情：

下面這張流程圖展示了 setup 指令的內部執行邏輯與依賴關係：

flowchart LR
    A["setup 指令啟動"] --> B["檢查前置條件"]
    B --> C{"全部通過？"}
    C -->|是| D["建立虛擬環境"]
    C -->|否| E["列出缺少的項目
顯示安裝指引"]
    D --> F["下載必要資源"]
    F --> G["執行 smoke test"]
    G --> H{"測試通過？"}
    H -->|是| I["顯示使用說明"]
    H -->|否| J["顯示錯誤訊息
建議排除方式"]

每個 setup 做了什麼

各 Layer 的 setup 特別事項

以下列出 BD 常用 Layer 的安裝注意事項：

Layer 1 — ai-save（網頁儲存）

1bash scripts/ai-save.sh setup

前置條件：markitdown（基本），opencli（JS 頁面），Node.js >= 18。

你會看到： 腳本會檢查三個下載工具（markitdown / opencli / playwright）是否存在，缺的會自動安裝。全部完成後會顯示 ai-save setup complete。

Layer 2 — gh-save（GitHub 儲存）

1bash scripts/gh-save.sh setup

前置條件：gh CLI 已認證。如果你從沒用過 GitHub CLI，需要先登入：

1gh auth login

你會看到： 會跳出一個選單問你要用瀏覽器登入還是 token 登入。選「Login with a web browser」最簡單——它會給你一個 code，讓你到瀏覽器裡輸入確認。

Layer 7 — quarkdown（Markdown 排版）

1bash scripts/quarkdown.sh setup

前置條件：Java 17。這是最常見的卡關點。

如果你看到 Java 17 not found 錯誤：

1# macOS 使用者
2brew install openjdk@17
3
4# Ubuntu / WSL 使用者
5sudo apt install -y openjdk-17-jdk

驗證安裝：

1java --version

你會看到： 類似 openjdk 17.0.x 的版本號。只要開頭是 17，就沒問題。

Layer 8 — docling（PDF 深度解析）

1bash scripts/docling-convert.sh setup

前置條件：Python >= 3.11、uv。

特別注意： 首次執行會下載 OCR 模型（~928 MB），如果網路慢可能需要 15 分鐘以上。如果你暫時不需要 OCR（光學字元辨識，用來處理掃描版 PDF），可以設定環境變數跳過：

1DOCLING_NO_OCR=1 bash scripts/docling-convert.sh setup

這樣安裝會快很多，之後需要 OCR 時再完整安裝。

Layer 11 — kami（精美 PDF 文件）

1bash scripts/kami.sh setup

前置條件：Python >= 3.11、uv、WeasyPrint 系統依賴（libcairo、libpango、字型）。

如果你看到 libatk-1.0.so.0: cannot open shared object file 錯誤（Ubuntu/WSL 常見）：

1sudo apt update
2sudo apt install -y libatk1.0-0 libcairo2 libpango-1.0-0 libpangoft2-1.0-0 \
3                    libgdk-pixbuf2.0-0 libffi-dev shared-mime-info fonts-noto-cjk

你會看到： 系統會下載並安裝一堆系統套件。完成後再次執行 bash scripts/kami.sh setup，應該就能通過。

安裝完 kami 後，建議設定品牌檔案：

1bash scripts/kami.sh brand

你會看到： 系統會在 ~/.config/kami/brand.md 建立一個品牌設定檔。你可以在裡面填入公司名稱、Logo 路徑、品牌色等資訊。填完之後，所有 kami 產出的文件都會自動套用你的品牌風格。

Layer 22 — company-intel（公司盡調）

1bash scripts/company-intel.sh status

Layer 22 沒有獨立的安裝腳本，它複用其他 Layer 的工具。執行 status 指令會告訴你目前哪些下游工具已就緒：

你會看到： 一個檢查清單，列出 ToolUniverse、quarkdown、agent-browser 的狀態。綠色勾表示已安裝，紅色叉表示需要安裝。

Layer 23 — agent-browser（AI 瀏覽器自動化）

1npm install -g @anthropic-ai/agent-browser
2agent-browser --version

前置條件：Node.js >= 18、Chrome 或 Chromium 瀏覽器。

你會看到： 安裝成功後 agent-browser --version 會顯示版本號。可以用以下指令測試：

1agent-browser open https://example.com

它會開啟瀏覽器載入頁面，然後你可以用 agent-browser snapshot -i 取得頁面的精簡文字內容。

scripts/ 目錄結構一覽

所有 Layer 的執行入口都在 scripts/ 目錄下。每個腳本都遵循相同的介面模式：

 1scripts/
 2├── ai-save.sh              ← L1：網頁儲存
 3├── gh-save.sh              ← L2：GitHub 儲存
 4├── ai-autofetch.sh         ← L3：自動抓取
 5├── graphify.sh             ← L4：知識圖
 6├── notebooklm-save.sh      ← L5：NotebookLM
 7├── gitnexus.sh             ← L6：程式碼圖
 8├── quarkdown.sh            ← L7：Markdown 排版
 9├── docling-convert.sh      ← L8：PDF 解析
10├── paper-search.sh         ← L9：論文檢索
11├── paperqa-lite.sh         ← L10：RAG 問答
12├── kami.sh                 ← L11：精美 PDF
13├── company-intel.sh        ← L22：公司盡調
14├── codex-image.sh          ← L24：圖表生成
15└── ...

每個腳本都支援以下子命令：

統一介面的好處：你不需要記住 24 種不同的安裝方式。bash scripts/<name>.sh setup 永遠有效。這就像每台家電的電源線都是同一種插頭——你不需要為每台電器準備不同的轉接頭。

3.5 安裝完成後的驗證 — 確認一切正常

每個 Layer 安裝完之後，可以用 smoke test（冒煙測試）快速驗證。格式統一：

1bash tests/<layer>/test_<layer>_smoke.sh

例如：

1# 驗證 ai-save
2bash tests/ai-save/test_smoke.sh
3
4# 驗證 quarkdown
5bash tests/quarkdown/test_smoke.sh
6
7# 驗證 kami
8bash tests/kami/test_smoke.sh

你會看到： 每個 smoke test 都會跑一個極小的測試案例（一個很短的 URL、一個很小的 markdown 檔案），然後檢查輸出是否正確。通過的話會顯示 PASS 或類似的成功訊息。整個過程不到 30 秒。

如果 smoke test 失敗怎麼辦？ 不要慌。執行以下指令重新安裝：

1bash scripts/<layer>.sh setup --force

--force 旗標會強制重新安裝，跳過「已安裝」的檢查。如果還是不行，查看 logs/<layer>-setup.log 裡的錯誤訊息。

3.6 常見安裝問題 Q&A

Q1：「Java 版本不對，我裝了 Java 11 / Java 21，可以嗎？」

不行。 quarkdown 明確要求 Java 17。多個 Java 版本可以共存，你只需要確保 java --version 顯示的是 17 即可。

macOS 使用者如果有多個版本，可以用以下指令切換：

1export JAVA_HOME=$(/usr/libexec/java_home -v 17)
2java --version  # 確認是 17

Q2：「Node.js 版本太舊怎麼辦？」

建議使用 nvm（Node Version Manager; Node 版本管理器）來管理：

1# 安裝 nvm
2curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
3
4# 安裝 Node.js 18
5nvm install 18
6nvm use 18
7
8# 確認版本
9node --version  # 應該顯示 v18.x.x

Q3：「Python 版本怎麼確認？」

1python3 --version

你會看到： 類似 Python 3.11.x 或 Python 3.12.x 的版本號。只要是 3.11 以上就沒問題。

如果版本太舊，建議用 uv 來安裝：

1# 安裝 uv（Python 套件管理器）
2curl -LsSf https://astral.sh/uv/install.sh | sh
3
4# uv 會自動管理 Python 版本
5uv --version

Q4：「我在公司網路環境，下載速度很慢怎麼辦？」

有些公司有 proxy（代理伺服器）設定。如果下載卡住，試試設定 proxy：

1export HTTP_PROXY=http://your-company-proxy:port
2export HTTPS_PROXY=http://your-company-proxy:port

具體的 proxy 位址請問你的 IT 部門。

Q5：「安裝失敗，錯誤訊息看不懂怎麼辦？」

三個步驟：

1. 截圖：把終端機裡的錯誤訊息截圖
2. 查 log：看 logs/ 目錄下有沒有對應的 log 檔
3. 問人：把截圖和 log 傳給工程團隊或在 Discord 頻道裡問

BD 人的心態建議：安裝過程遇到問題是正常的，工程師每天也在跟環境問題搏鬥。不需要自己硬解，問人是最快的方法。你的價值在於「用工具做出洞見」，不在於「自己修工具」。

Q6：「我可以把所有 Layer 一次全裝嗎？」

強烈不建議。 原因有三：

2. 安裝時間：全裝可能需要 1-2 小時
3. 認知負擔：一次學 24 個工具會讓你不知道從哪裡開始

正確做法：先裝 Tier 1 三個 Layer，用一兩週熟悉後，再依需求往 Tier 2 擴展。這是官方建議的漸進式上手路徑。

Q7：「uv 是什麼？為什麼不用 pip？」

uv 是新一代的 Python 套件管理器，速度是 pip 的 10-100 倍，而且會自動建立虛擬環境，不會污染你電腦上的系統 Python。AIKT 統一使用 uv 來管理 Python 依賴。

安裝 uv：

1curl -LsSf https://astral.sh/uv/install.sh | sh

你會看到： 下載並安裝 uv 的過程，完成後可以用 uv --version 確認。版本需要 >= 0.4.0。

Q8：「gh CLI 是什麼？跟 Git 有什麼不同？」

git 是版本控制工具（管理程式碼的歷史紀錄），gh 是 GitHub 官方的命令列工具（跟 GitHub 網站互動）。Layer 2 需要 gh 來查詢 GitHub 上的 repo 資訊。

安裝：

1# macOS
2brew install gh
3
4# Ubuntu / WSL
5sudo apt install gh

安裝完要登入：

1gh auth login

你會看到： 一個互動式選單，選「GitHub.com」→「Login with a web browser」→ 照指示在瀏覽器裡確認。完成後 gh auth status 會顯示你已登入。

Q9：「我的 Mac 沒有 brew 怎麼辦？」

Homebrew 是 macOS 上最常用的套件管理器。安裝方法：

1/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

你會看到： 終端機會要求你輸入 Mac 的登入密碼（輸入時畫面不會顯示任何字，這是正常的安全設計）。安裝過程大約 2-5 分鐘。安裝完後執行 brew --version 確認。

Q10：「各個 Layer 之間有安裝順序的依賴嗎？」

有，但大多數 Layer 是獨立的。以下是幾個有依賴關係的例子：

Tier 1 的三個 Layer（L1、L7、L22）之間沒有互相依賴，可以任意順序安裝。Tier 2 的 Layer 也都是獨立的。只有 Tier 3 和更進階的組合 Layer 才有依賴問題——到那個階段你已經很熟悉系統了。

Q11：「安裝過程會不會影響我電腦上其他的程式？」

不會。 AIKT 的核心設計原則之一就是「隔離安裝」：

• Python 工具都裝在 uv 建立的虛擬環境裡，不會碰到你系統的 Python
• Java（quarkdown 用的）是獨立的 JAR 檔案，不需要系統層面的 Java 設定
• Node.js 工具用 npx 執行或裝在專案級別

你的 Excel、PowerPoint、瀏覽器、其他工作軟體完全不受影響。

3.7 安裝地圖 — 你目前在哪裡

完成本章的安裝後，你的 AIKT 系統狀態應該是這樣：

 1AI-knowledge_template/
 2├── inbox/          ← 所有存檔的文章、筆記會出現在這裡
 3├── projects/       ← 專案工作目錄（盡調報告、教學等）
 4├── docs/           ← 學習記錄與設計文件
 5├── scripts/        ← 每個 Layer 的執行入口
 6│   ├── ai-save.sh          ✅ 已安裝（Tier 1）
 7│   ├── quarkdown.sh        ✅ 已安裝（Tier 1）
 8│   ├── company-intel.sh    ✅ 已安裝（Tier 1）
 9│   ├── gh-save.sh          ⬜ 等需要時安裝（Tier 2）
10│   ├── docling-convert.sh  ⬜ 等需要時安裝（Tier 2）
11│   ├── kami.sh             ⬜ 等需要時安裝（Tier 2）
12│   └── ...
13├── tests/          ← smoke test 腳本
14└── .claude/        ← Claude Code 整合設定

下一章預告：工具已經就位了。Ch 4 會帶你親手操作第一個 Layer——從儲存一篇文章開始，一步步體驗整個系統的運作方式。準備好你的 Discord 頻道，我們馬上開始實作！

3.8 安裝後的第一件事 — 建立你的品牌設定

如果你安裝了 Layer 11 kami，強烈建議在開始使用前先設定品牌檔案。這就像買了一台新的印表機，先把公司的信紙模板設定好，之後每次列印都會自動套用。

1bash scripts/kami.sh brand

這會在 ~/.config/kami/brand.md 建立一個品牌設定檔。你需要填入以下資訊：

你會看到： 設定完成後，每次用 kami 產出的文件都會自動帶上你的公司 Logo 和品牌色系。不需要每次手動插入 Logo。

沒有設定 brand.md 也能用 kami。只是產出的文件會用 kami 的預設設計（暖色羊皮紙 + 墨水藍），不會有你的公司 Logo。

Claude Code 基礎設定 — 讓 AI 助理聽懂你的規矩

前面幾節我們把 AIKT 的各個 Layer 都安裝好了。但你可能會想：「這些工具是怎麼聽懂我的指令的？為什麼 Claude 知道要幫我存檔、做盡調、排版？」

答案是：AIKT 背後有一套精心設計的「行為架構」。這套架構決定了 Claude Code 在每次對話中會遵守什麼規矩、知道什麼技能、不能做什麼事。

你可能會問：「我又不是工程師，為什麼要知道這些？」

因為理解這套架構——即使只是表面地理解——能帶來三個實際好處：

1. 信任感提升：當你知道 Claude 不是隨便亂回答、而是有一套完整的行為規範在控制，你會更放心把重要任務交給它
2. 問題排查能力：如果 Claude 突然「不聽話」（例如拒絕上傳某個檔案），你能判斷是 Hooks 在保護你、還是系統出了 bug
3. 跟工程團隊溝通：當你想客製化某個行為時，能用正確的術語跟工程師說「我想在 CLAUDE.md 裡加一條規矩」或「能不能用 Hook 來強制這個行為」

你不需要自己設定這些——AIKT 已經全部幫你做好了。但理解這套架構，會讓你在使用時更有信心，遇到問題時也知道去哪裡找原因。

把這套架構想成公司的管理制度：

• CLAUDE.md = 員工手冊（基本規矩，每天上班都要遵守）
• Skills = 工作 SOP 卡片（不同情境拿不同的卡片出來看）
• Hooks = 自動安檢機制（機場安檢門——不管你願不願意都會被掃描）
• Memory = 工作日誌（記住上次學到的經驗，下次主動提醒）

接下來我們一一介紹。

閱讀提示： 接下來六個小節（3.9 到 3.14）是概念介紹，沒有需要你動手操作的部分。你可以在通勤時、喝咖啡時輕鬆閱讀。真正的動手操作在 Ch 4。

如果你是「先做再說」型的人，完全可以先跳到 Ch 4 開始實作，之後再回來補讀這些背景知識。但我們建議至少快速瀏覽一遍——理解「為什麼系統會這樣反應」，能讓你在遇到問題時更快找到解決方向。

3.9 什麼是 CLAUDE.md？— AI 助理的員工手冊

基本概念

CLAUDE.md 是 Claude Code 的「行為憲法」——一份文字檔案，告訴 Claude 在這個工作環境裡應該遵守什麼規矩、知道什麼背景知識、用什麼語言回覆。

把它想成你新進公司時收到的「員工手冊」。手冊裡會寫：

• 「我們用繁體中文溝通」
• 「報告必須用這個格式」
• 「機密資料不能外傳」
• 「我們是做 ADC（antibody-drug conjugate; 抗體藥物複合體）平台的」

每次你跟 Claude 開啟一個新對話，CLAUDE.md 的內容就會自動被載入。Claude 會像翻閱員工手冊一樣，先把這些規矩讀一遍，然後才開始回答你的問題。

這裡有一個重要的技術概念需要理解：Agent（代理）和 ChatBot（聊天機器人）的差別。

你平常用的 ChatGPT、Claude.ai 網頁版是 ChatBot——你問它問題，它回答你，就這樣。但 Claude Code 是 Agent——它不只回答問題，還能主動讀取環境資訊、執行工具、呼叫外部 API。

差別在哪裡？在於「誰來組裝上下文（context; 脈絡）」：

這就是為什麼用 Claude Code 做盡調，比你在 ChatGPT 裡打一大段提示詞（prompt; 提示）要有效得多——因為 AIKT 已經把所有背景資訊、工作流程、安全機制都「注入」到 Claude 的上下文裡了。你不需要每次都從頭解釋「我是 BD、我在做盡調、請用繁體中文、不要洩露機密」——這些全部由 CLAUDE.md 自動處理。

三層優先順序 — 公司、部門、個人

CLAUDE.md 不是只有一份。它分成三個層級，就像公司的規範也分成集團層級、部門層級、個人偏好：

下面這張流程圖展示了 CLAUDE.md 三層設定的優先順序與覆蓋關係：

flowchart TB
    G["Global 全域設定
~/.claude/CLAUDE.md
所有專案共用的基本規矩"]
    P["Project 專案設定
專案根目錄/CLAUDE.md
這個專案的特定規矩"]
    L["Local 本地設定
CLAUDE.local.md
你個人的偏好（不進版本控制）"]

    G -->|"被覆蓋"| P
    P -->|"被覆蓋"| L

    G -.- G1["例：一律用繁體中文
禁止洩露 API Key
Python 用 uv 管理"]
    P -.- P1["例：Discord 頻道 ID
24 個 Layer 的分流規則
機密邊界設定"]
    L -.- L1["例：我個人的 email
我偏好的輸出格式
不需要進 git 的設定"]

用辦公室來比喻：

優先順序規則：越靠近你的設定越優先。 如果集團規定「報告用 A 格式」，但部門規定「報告用 B 格式」，那在這個部門裡就用 B 格式。Local 又比 Project 更優先。

另外還有一個進階功能：Rules（路徑範圍規則）。你可以在 .claude/rules/ 目錄下放針對特定路徑的規則檔案。例如：

1.claude/rules/
2├── testing.md      ← 寫測試時的規範
3├── security.md     ← 處理安全相關程式碼時的規範
4└── git-workflow.md ← Git 操作時的規範

Rules 的作用跟 CLAUDE.md 類似，但它們會根據你目前操作的檔案路徑來決定載入哪些規則。例如，當 Claude 在編輯一個 Python 測試檔案時，testing.md 裡的規則會自動生效。

BD 人不需要管 Rules。 這是給工程師用來精細控制 Claude 行為的進階功能。我們提到它只是讓你知道完整的架構全貌。

上下文壓縮 — 為什麼 CLAUDE.md 的位置很重要

Claude Code 有一個你需要理解的技術限制：上下文視窗（context window）是有限的。 就像你的辦公桌面空間有限，不可能同時攤開 100 份文件。

當對話變得很長（例如一個複雜的盡調跑了 30 分鐘），Claude 會自動「壓縮」對話——把早期的內容摘要化，只保留重點。這就像你整理辦公桌，把不太重要的文件收進抽屜，只在桌面留關鍵資料。

重點來了：根目錄的 CLAUDE.md 永遠不會被壓縮掉。 不管對話跑多久、多複雜，根目錄的 CLAUDE.md（也就是 Project 層級的設定）永遠會被保留在 Claude 的「桌面」上。

這就是為什麼 AIKT 把最重要的資訊（24 Layer 分流表、機密邊界、溝通規則）放在根目錄的 CLAUDE.md——確保 Claude 在任何時候都不會忘記這些核心規矩。

該放什麼、不該放什麼

CLAUDE.md 適合放「事實」和「規矩」，不適合放「工作流程」。

為什麼不把工作流程放進 CLAUDE.md？ 因為 CLAUDE.md 每次對話都會被載入，它佔用的是你寶貴的「上下文空間」（context window; 上下文視窗）。如果你把 24 個 Layer 的完整 SOP 全塞進去，Claude 還沒開始回答你的問題，空間就被佔滿了。

原則：事實放 CLAUDE.md，工作流程放 Skills，自動化放 Hooks，學習放 Memory。

BD 團隊的最小 CLAUDE.md 範例

如果 BioGenesis Corp. 的 BD 團隊要從零開始建立 CLAUDE.md，最小可行版本大概長這樣：

 1## 團隊基本資訊
 2- 公司：BioGenesis Corp.（ADC 抗體藥物複合體平台）
 3- 團隊：Business Development
 4- 工作語言：繁體中文（台灣用語）
 5
 6## 溝通規則
 7- 所有回覆同步發送到 Discord 頻道
 8- 關鍵字格式：English term (abbreviation; 中文)
 9
10## 安全規範
11- 禁止在對話中直接貼出 API Key 或密碼
12- 專利相關資料不可上傳 Discord
13- 盡調原始檔案不可對外分享

好消息：你不需要自己寫這些。 AIKT 的 CLAUDE.md 已經包含了完整的 24 Layer 分流規則、機密邊界設定、Token 省用守則等。上面的範例只是讓你理解概念。

常見誤解澄清

「CLAUDE.md 就是 prompt engineering（提示工程）嗎？」

某種意義上是的，但更精確地說，CLAUDE.md 是「結構化的、持久的、自動注入的系統提示」。跟你在 ChatGPT 裡手動打一段提示詞不同，CLAUDE.md：

• 不需要你每次都手動輸入（自動載入）
• 有版本控制（可以追蹤修改歷史）
• 有優先順序系統（Global → Project → Local）
• 可以被團隊共享（放在 Git repo 裡，大家都用同一份）

「如果我想讓 Claude 改變行為，直接在對話裡說不行嗎？」

可以，但效果是暫時的。你在對話裡說「從現在開始用英文回答」，Claude 會照做——但只限這次對話。下次開新對話，它又會回到 CLAUDE.md 裡設定的繁體中文。如果你想永久改變行為，就要去修改 CLAUDE.md。

「CLAUDE.md 的大小有限制嗎？」

技術上沒有硬性限制，但實務上建議控制在 2000-3000 行以內。太長的 CLAUDE.md 會佔用過多上下文空間，讓 Claude 能用來思考你的問題的空間變少。AIKT 的 CLAUDE.md 大約 300 行——包含了所有 24 Layer 的分流規則和完整的機密邊界設定，是經過精心設計的合理長度。

3.10 什麼是 Skills？— 抽屜裡的食譜卡片

基本概念

Skills（技能）是 Claude Code 的「工作 SOP 手冊」。如果 CLAUDE.md 是員工手冊（基本規矩），那 Skills 就是抽屜裡的食譜卡片——你有一整抽屜的食譜，但每次做菜只會拿出你需要的那一張。

每個 Skill 是一個獨立的資料夾，裡面包含：

• SKILL.md：這個技能的完整說明（什麼時候用、怎麼用、注意事項）
• scripts/：執行用的腳本
• references/：參考文件（選用）

AIKT 有 24 個 Skills，對應 24 個 Layers。 每個 Layer 就是一張食譜卡片。

Skill 的資料夾結構 — 打開抽屜看看裡面

每個 Skill 的資料夾長這樣（以 company-intel 為例）：

1.claude/skills/company-intel/
2├── SKILL.md          ← 主文件：什麼時候觸發、7 個執行階段、輸入輸出格式
3├── scripts/          ← 執行用的腳本（如果有的話）
4│   └── check-downstream.sh
5└── references/       ← 參考文件（選用）
6    └── dd-template.md

SKILL.md 的核心內容包括：

你不需要記住這些，但了解 Skill 的結構可以幫助你理解：為什麼輸入 dd: BioNTech 之後，Claude 能自動跑出一份完整的盡調報告——因為 SKILL.md 裡已經把每一步都寫好了。

隨選載入 — 省空間的聰明設計

Skills 最聰明的設計是「隨選載入」（on-demand loading; 按需載入）。啟動 Claude Code 時，它不會把 24 張食譜全部讀進腦袋裡——那太浪費空間了。它只會記住每張食譜的「名字和一句話描述」。

下面這張流程圖展示了 Skills 的隨選載入機制：

flowchart LR
    A["Claude Code 啟動"] --> B["載入 24 個 Skill
的名字 + 一句話描述"]
    B --> C["使用者輸入指令
例如 dd: BioNTech"]
    C --> D{"比對 Skill 名稱
和描述"}
    D --> E["找到匹配：
company-intel Skill"]
    E --> F["載入完整
SKILL.md 內容"]
    F --> G["按照 SOP
執行盡調工作"]

用廚房來比喻：

• 啟動時：你走進廚房，冰箱門上貼了 24 張標籤：「番茄炒蛋」「紅燒牛肉」「清蒸魚」……（只有名字）
• 你說「做番茄炒蛋」：你打開抽屜，拿出「番茄炒蛋」的完整食譜卡片
• 做完之後：食譜卡片放回抽屜，不佔桌面空間

這就是為什麼 AIKT 能有 24 個 Layer 卻不會把 Claude 的腦袋塞爆——因為同一時間只有 1-2 個 Skill 被完整載入。

AIKT 的 24 個 Skills 一覽

你在 Ch 2 已經看過完整的 Layer 列表。這裡從 Skills 的角度重新整理，讓你看看每個 Skill 的「觸發前綴」：

完整的 24 Layer 列表和觸發前綴請參考 Ch 2 的架構總覽。 上面只列出 BD 最常用的 10 個。

作為 BD 使用者，你不需要設定任何 Skill。 你只需要記住觸發前綴就好——就像你只需要知道菜名，不需要自己寫食譜。一開始記不住也沒關係——你可以自然語言描述你想做的事（例如「幫我查一下這家公司的背景」），Claude 會自動判斷該觸發哪個 Skill。前綴只是一個「快捷鍵」，讓你可以更精確地指定你要的功能。

BD 人怎麼使用 Skills？

答案很簡單：打前綴就好。

1你（在 Discord 輸入）：dd: BioNTech
2Claude：「好的，啟動 company-intel 盡調工作流……」

Claude 會自動做以下事情：

1. 看到 dd: 前綴
2. 查分流表，發現對應 company-intel Skill
3. 載入 company-intel 的完整 SKILL.md
4. 按照 SKILL.md 裡面寫的 7 階段 SOP 執行
5. 產出報告到 projects/company-intel-<date>/

你完全不需要知道 SKILL.md 裡面寫了什麼。 就像你叫外送，你只要說「我要一份番茄炒蛋」，廚師會按照自己的食譜做好端給你。

進階知識（可跳過）： 如果你好奇某個 Skill 的完整 SOP，可以去 .claude/skills/<skill-name>/SKILL.md 看。例如 .claude/skills/company-intel/SKILL.md 有幾百行的盡調流程說明。但這是給「想改食譜的人」看的——身為「點餐的人」，你不需要看。

Skills 的 Token 預算 — 不是無限量吃到飽

前面提到 Skills 是「隨選載入」的，這意味著 Claude 的上下文空間有限，Skills 的載入也有預算。

想像你的辦公桌面可以同時攤開 5 份 A4 文件。你可以隨時把一份收起來、拿另一份出來，但同時最多就是 5 份。Skills 的載入也是這樣——Claude 會根據需要載入必要的 Skills，但如果一次載入太多（例如你同時要做盡調、查論文、排版、還要存 GitHub），Claude 會自動管理優先順序，先處理最緊急的。

這對 BD 使用者有什麼影響？ 幾乎沒有。在日常使用中，你很少會在同一個對話中同時觸發 5 個以上的 Skill。但如果你注意到 Claude 在一個特別長的對話末尾開始「忘記」某些規矩，那可能是上下文空間快用完了。這時候最好的做法是：開一個新對話。 新對話 = 全新的空間 = Claude 重新讀一遍 CLAUDE.md 和所有必要的 Skill。

Skills 和你之前用的「GPTs」有什麼不同？

如果你用過 ChatGPT 的 GPTs（自訂 GPT），可能會覺得 Skills 跟那個很像。確實有相似之處，但 Skills 更強大：

3.11 什麼是 Hooks？— 機場安檢門

基本概念

Hooks（鉤子）是 Claude Code 裡的「自動強制機制」。如果 CLAUDE.md 是員工手冊（你「應該」遵守的規矩），那 Hooks 就是機場安檢門——不管你有沒有讀過安全手冊，你的行李都會被 X 光機掃描，你的水瓶都會被攔下來。

為什麼需要 Hooks？因為 CLAUDE.md 裡的規矩是「建議」，Claude 有可能忘記。 Claude 是一個語言模型 (LLM; Large Language Model; 大型語言模型)，它處理指令的方式是「機率性」的——大多數時候會遵守規矩，但偶爾可能會忘記或誤判。

Hooks 則是「確定性」的——它是硬寫在程式裡的自動化腳本，百分之百會執行。

用數學的方式說：CLAUDE.md 裡的規矩遵守率大約是 95-99%（很高，但不是 100%）。Hooks 的執行率是 100.0%——因為它根本不經過語言模型的判斷，而是由底層程式碼直接執行。

對 BD 來說，這個差別在處理「機密資訊」時尤其重要——你不會想讓「不小心洩密」成為那 1-5% 的例外情況。

三種 Hook 類型

下面這張流程圖展示了三種 Hook 各自在什麼時機觸發：

flowchart TD
    U["使用者下指令"] --> Pre{"PreToolUse
執行前檢查"}
    Pre -->|"安全"| T["執行工具
（寫檔案、跑指令…）"]
    Pre -->|"危險！"| Block["阻擋執行
顯示警告"]
    T --> Post{"PostToolUse
執行後處理"}
    Post --> R["結果回傳"]
    R --> Stop{"Stop
結束前檢查"}
    Stop -->|"品質 OK"| Done["任務完成"]
    Stop -->|"還沒測試！"| Force["強制要求
先跑測試"]

為什麼 CLAUDE.md 的規矩可能被忽略，但 Hooks 不會？

讓我用一個生活化的例子說明：

CLAUDE.md 的規矩（像貼在牆上的標語）：

1「請勿在辦公室吸菸」
2→ 大多數人會遵守，但偶爾有人會忘記或偷偷違規

Hooks 的強制機制（像煙霧偵測器）：

1偵測到煙霧 → 自動啟動灑水器 + 通知消防隊
2→ 不管你有沒有看到標語，系統都會自動反應

在 AIKT 裡，這個差別體現在「機密邊界」的保護上：

• CLAUDE.md 裡寫：「專利相關資料不可上傳 Discord」（Claude 通常會遵守，但可能偶爾忘記）

AIKT 中 Hooks 的實際應用

AIKT 已經預設了幾個重要的 Hook 設定。你不需要自己配置，但了解它們的存在有助於理解系統為什麼這麼可靠：

BD 人須知： 你永遠不需要配置 Hooks。但如果你注意到 Claude 拒絕做某件事（例如不肯把某份報告上傳 Discord），那可能是 Hook 在保護你。這是系統在幫你守規矩，不是 Claude 在鬧脾氣。

Hook 的一個重要特性：零上下文消耗

這裡要提到一個技術細節，但對理解系統效率很重要。

Hooks 不佔用任何上下文空間。還記得前面說過 CLAUDE.md 每次對話都要載入，Skills 觸發時要載入，它們都會佔用 Claude 的「腦容量」嗎？Hooks 完全不會。

為什麼？因為 Hooks 是在 Claude 的「思考」之外運作的。它們是獨立的程式腳本，由 Claude Code 的底層框架（harness; 框架）直接執行，不經過 Claude 的語言模型。

用機場的比喻來說：X 光安檢機不需要「思考」你的行李裡有什麼——它用物理方式掃描，跟人類安檢員的判斷力無關。同樣地，Hooks 用程式碼邏輯判斷，跟 Claude 的語言理解能力無關。

這帶來一個重要的設計原則：

• 需要 Claude「理解」才能判斷的事 → 放 CLAUDE.md（例如「關鍵字要用 English (abbreviation; 中文) 格式」）
• 可以用機械規則判斷的事 → 放 Hooks（例如「禁止 git add -A 指令」）

BD 情境：Hook 救了你一命的場景

想像這個場景：你在準備下週的 board meeting（董事會），正在用 AIKT 做一份競品分析報告。你做完之後，隨口跟 Claude 說：「幫我把報告傳到 Discord。」

但你忘了，這份報告裡包含了你們公司正在評估的 acquisition target（併購標的）的敏感資訊。

如果沒有 Hooks： Claude 照做，把報告傳上 Discord。如果 Discord 頻道有其他人能看到……你就有麻煩了。

有了 Hooks： PreToolUse Hook 偵測到這份報告位於 projects/company-intel-*/ 目錄下，自動阻擋上傳，並顯示警告：「此報告位於受保護的盡調目錄，禁止上傳至 Discord。如需分享，請手動複製到安全位置。」

這就是為什麼 Hooks 是「確定性」的——它不管你怎麼跟 Claude 說，也不管 Claude 怎麼理解你的意圖，只要規則觸發了，就一定會執行。

3.12 什麼是 Subagents？— 把任務交給實習生

基本概念

Subagents（子代理）是 Claude Code 的「分身術」。想像你是一個主管，手上有三件互不相關的調查任務。你可以一件一件自己做（很慢），也可以把三件任務分別交給三個實習生，讓他們同時去做，做完再把結果彙報給你。

Subagent 就是 Claude 派出去的「實習生」——每個 Subagent 有自己獨立的「腦袋」（context window; 上下文視窗），不會互相干擾，做完之後把結果交回「主管」Claude。

下面這張流程圖展示了主代理如何把任務分派給 Subagents 並收集結果：

flowchart TD
    Main["主代理（你的 Claude）
接收任務：盡調 BioNTech"]

    Main --> S1["Subagent 1
查財務資料
SEC / 年報"]
    Main --> S2["Subagent 2
查管線進度
ClinicalTrials.gov"]
    Main --> S3["Subagent 3
查專利佈局
USPTO"]

    S1 --> R["主代理彙整
產出完整盡調報告"]
    S2 --> R
    S3 --> R

為什麼不讓一個 Claude 全部做完？ 因為 Claude 的「腦容量」（context window）是有限的。如果一次塞進十個資料庫的原始數據，Claude 的思考品質會下降——就像你同時在三個電話上跟不同的人講話，一定會搞混。

分派 Subagents 的好處：

AIKT 哪裡用了 Subagents？

在 AIKT 的 24 個 Layer 中，有幾個「大型 Layer」會自動使用 Subagents：

BD 人須知： 你完全不需要手動「派出 Subagent」。當你輸入 dd: BioNTech 啟動盡調時，Claude 會自動判斷是否需要派 Subagent。你只會看到最終結果——一份完整的盡調報告，而不是四個實習生的個別筆記。

唯一你可能會注意到的跡象：如果一個盡調任務跑了 10-15 分鐘，中途 Claude 沒有回覆你任何訊息，那多半是因為它派出了 Subagents 在背景工作。耐心等一下，它們會帶著結果回來。

BD 情境模擬：盡調 BioNTech 時 Subagents 在幕後做了什麼

讓我們用一個具體場景走一遍。假設你輸入了 dd: BioNTech：

你看到的（Discord 畫面）：

1你：dd: BioNTech
2Claude：好的，啟動 BioNTech 盡職調查。正在蒐集資料，預計需要 10-15 分鐘……
3（等待 12 分鐘）
4Claude：BioNTech 盡調報告已完成。報告已存至 projects/company-intel-260630-biontech/
5        包含：財務摘要、管線進度、專利分析、團隊背景。
6        HTML 版本可以雙擊開啟：report.html

幕後實際發生的事：

如果不用 Subagents，主代理必須一個一個查：先查 SEC（3 分鐘）、再查 ClinicalTrials（3 分鐘）、再查 USPTO（3 分鐘）、再查 LinkedIn（3 分鐘）、最後彙整（2 分鐘）= 14 分鐘。用 Subagents 並行處理，4 個資料來源同時查，總共只要 12 分鐘。

而且更重要的是：每個 Subagent 有完整的上下文空間來處理自己負責的部分，不會因為「同時在看四個資料來源」而品質下降。

Subagent 和「開新的 ChatGPT 對話」有什麼不同？

你可能會想：「我也可以自己開四個 ChatGPT 分頁，分別查四個資料來源啊？」

可以，但有三個關鍵差別：

3.13 四層架構總覽 — 規矩、技能、強制、記憶

現在把前面介紹的四個概念放在一起看。Claude Code 的行為由這四層架構共同決定：

下面這張流程圖展示了四層架構如何協作形成完整的 AI 行為控制系統：

flowchart TB
    subgraph C["CLAUDE.md — 規矩層"]
        C1["事實：公司是做 ADC 的"]
        C2["規矩：用繁體中文"]
        C3["禁令：機密不上 Discord"]
    end

    subgraph S["Skills — 技能層"]
        S1["L22 company-intel
7 階段盡調 SOP"]
        S2["L11 kami
10 種文件類型"]
        S3["L9 paper-search
跨 10 個資料庫"]
    end

    subgraph H["Hooks — 強制層"]
        H1["PreToolUse
阻擋危險操作"]
        H2["PostToolUse
自動格式化"]
        H3["Stop
結束前檢查"]
    end

    subgraph M["Memory — 記憶層"]
        M1["CLAUDE.md 手動記錄"]
        M2["Auto Memory 自動學習"]
        M3["Session Memory 對話記憶"]
    end

    C --> S
    S --> H
    H --> M

四層對照表

記住這句話就夠了

事實 → CLAUDE.md，工作流程 → Skills，強制機制 → Hooks，學習經驗 → Memory。

用 BioGenesis Corp. 的 BD 團隊來舉例：

Memory 的三種記憶系統（補充說明）

Claude Code 有三種記憶方式，就像人的記憶也分短期和長期：

Auto Memory 的實際運作方式： 當你對 Claude 的某個行為表達滿意或不滿意時，Claude 會在幕後寫一條小筆記。例如：

• 你說「下次報告不要用條列式，用表格」→ Claude 記住：user prefers tables over bullet lists for reports
• 你說「很好，這個格式我很喜歡」→ Claude 記住：user satisfied with current output format
• 你說「以後盡調都幫我多查 ClinicalTrials.gov」→ Claude 記住：user wants ClinicalTrials.gov as priority source for DD

這些小筆記會存在 Claude 的記憶系統裡（具體位置是 memory/ 目錄下的 .md 檔案），下次開新對話時自動載入。久而久之，Claude 會越來越「懂你」——就像一個跟你合作很久的助理，知道你喜歡什麼格式、偏好哪些資料來源、不喜歡什麼風格。

BD 人的一個真實體驗： 當你第一次跟 Claude 說「我比較喜歡表格格式的報告」，Claude 可能會用 Auto Memory 記下這個偏好。下次你做盡調時，它會自動用表格格式呈現結果——你不需要每次都重複說。這就是 Memory 層的價值——你不需要每次都「訓練」你的 AI 助理，它會自己記住並改進。

BD 場景模擬：四層架構如何協作

讓我們用一個完整的 BD 場景，看四層架構如何在幕後協作。

場景： 你在 AACR 會議上遇到 NovaBio 公司的 VP，對方提到他們有一個 ADC 管線跟 BioGenesis 的技術平台可能互補。你回到飯店後，想在明天早餐會前做一份快速盡調。

你做的事： 在 Discord 輸入 dd: NovaBio Inc.

四層架構在幕後做的事：

1. CLAUDE.md（規矩層）先讀：

   • 「這個使用者是 BD 團隊，用繁體中文」→ Claude 知道報告要用中文寫
   • 「公司做 ADC 平台」→ Claude 知道要特別關注 NovaBio 的 ADC 相關管線
   • 「盡調原始檔禁止上 Discord」→ Claude 記住這條規矩

2. Skills（技能層）被觸發：

   • dd: 前綴 → 比對分流表 → 載入 company-intel SKILL.md
   • SKILL.md 裡的 7 階段 SOP 開始執行
   • Claude 派出 Subagents 同時查財務、管線、專利、團隊

3. Hooks（強制層）持續監控：

   • 每次 Claude 要執行寫檔、API 呼叫、Discord 上傳時，Hook 自動檢查
   • 如果有任何操作觸及機密邊界，自動阻擋
   • 你完全不會注意到 Hook 在工作——除非它攔住了某個危險操作

4. Memory（記憶層）輔助：

   • Claude 查 Auto Memory：「上次有查過 NovaBio 嗎？」→ 如果有，先讀上次的結果
   • 做完盡調後，Claude 可能自動記住：「NovaBio 的 CEO 是 Dr. Lee，2024 年從 Pfizer 跳槽來的」→ 下次你再查 NovaBio 時，這條資訊會自動出現

你拿到的結果： 一份完整的 NovaBio 盡調報告，存在 projects/company-intel-260630-novabio/ 目錄下，HTML 版本雙擊就能打開。從你輸入 dd: NovaBio Inc. 到拿到報告，大約 10-15 分鐘。

如果沒有四層架構呢？ 你可能要花 2-3 小時手動查 ClinicalTrials.gov、SEC、USPTO、LinkedIn，然後再花 1 小時把資訊整理成報告。有了 AIKT，你省下的這 3-4 小時可以拿來準備明天早餐會的話術——這才是 BD 人的核心價值所在。

動態工作流 — Claude 自己寫劇本

除了靜態的四層架構之外，Claude Code 還有一個進階能力：Dynamic Workflows（動態工作流）。這是指 Claude 在執行複雜任務時，會自己臨時寫出「協調腳本」來指揮多個 Subagent。

用電影拍攝來比喻：四層架構是「劇本」「演員」「安全規範」和「拍攝日誌」。而動態工作流就像導演根據現場狀況臨時改戲——劇本寫的是「主角走到門前」，但導演看到下雨了，臨時改成「主角撐傘走到門前」。

在 AIKT 裡，這體現在 L18 research-pipeline 和 L19 tu-plan-generator 等大型 Layer：Claude 不是機械地按照 SKILL.md 的步驟一步一步走，而是根據中間結果動態調整策略。例如，如果 Subagent 1 在查管線時發現某個候選藥物已經被競品公司開發了，主代理可能會臨時改變後續 Subagent 的查詢方向——去查那個競品公司的進度，而不是繼續查原本的標的。

BD 人不需要理解動態工作流的技術細節。 我們提到它只是讓你知道：AIKT 不是一個「呆呆的腳本機器人」，它有相當程度的靈活性和判斷力。你只需要給它一個起點（dd: BioNTech），它會自己決定最佳路徑。

3.14 AIKT 已經幫你設好了 — 你只管用

讀完前面五節，你可能會想：「CLAUDE.md、Skills、Hooks、Memory……這些我都要自己設定嗎？」

好消息：完全不需要。AIKT 已經全部幫你做好了。

就像你不需要理解汽車的引擎運作原理才能開車一樣，你不需要理解 Claude Code 的四層架構才能用 AIKT 做盡調。前面幾節介紹這些概念，是為了讓你在「車子發出怪聲」的時候知道大概是哪裡的問題——是引擎（CLAUDE.md 設定問題）、是煞車（Hooks 攔截了某個操作）、還是輪胎（某個 Skill 的下游工具沒裝好）。

你現在手上的 AIKT 系統包含：

你要做的事情，從頭到尾只有三步：

1. Clone（下載 AIKT 到你的電腦）
2. Setup（安裝你需要的 Layer）
3. 開始用前綴指令工作

就是這麼簡單。

類比：你買了一台預裝好的電腦

把 AIKT 想成一台蘋果電腦——你買回家、開機、登入，就可以開始用了。macOS、Safari、iCloud、App Store 全部預裝好。你不需要自己灌作業系統、設定網路驅動程式、安裝瀏覽器。

AIKT 也是這樣：

• CLAUDE.md = macOS 的系統設定（已經調好了）
• Skills = 預裝的 App（已經裝好了，你只要打開用）
• Hooks = 內建的安全機制（FileVault 加密、Gatekeeper 驗證，你不需要知道它們在，但它們一直在保護你）
• Memory = iCloud 同步（你的偏好和記錄會自動保存、跨裝置同步）

數字一覽：AIKT 幫你省了多少工

為了讓你感受 AIKT 預設配置的價值，這裡列一些數字：

保守估計，AIKT 的預設配置幫你省了 4-8 週的設定時間。 而且這還不包括「踩坑 → 除錯 → 修正」的時間——光是讓 24 個 Layer 能正確分流、互不干擾，就是一個非常大的工程挑戰。

進階使用者：如果你想客製化

如果你用了一陣子之後，想客製化某些行為，以下是建議的方向：

建議：先用預設值跑幾週。 等你熟悉系統行為之後，再考慮客製化。過早改設定就像買了新車第一天就去改裝——你還不知道原廠設定好不好用，先開幾圈再說。

一個你可能會好奇的問題：「這套系統是誰維護的？」

AIKT 的四層架構由系統維護者（通常是你公司裡懂 Claude Code 的工程師或資料科學家）負責更新和調整。他們的工作包括：

• 新增 Layer（例如發現一個新的有用工具，把它整合進 AIKT）
• 更新 SKILL.md（例如某個資料庫的 API 改版了，需要修改查詢流程）
• 調整 CLAUDE.md 的分流規則（例如加入新的前綴、修改機密邊界）
• 配置新的 Hooks（例如公司新增了一條合規要求）

身為 BD 使用者，你跟維護者的分工很清楚：他們負責維護工具，你負責用工具產出洞見。 就像你不需要自己修理影印機，但你需要知道影印機在哪裡、怎麼按「影印」鍵。

如果你遇到 AIKT 無法處理的新需求（例如「我需要一個能查日本 PMDA 審查紀錄的工具」），把需求告訴維護者，他們會評估是否值得新增一個 Layer。

銜接下一章

現在你已經知道：

• AIKT 的 24 個 Layer 都安裝在哪裡（Ch 3 前半段）
• 這些 Layer 背後的四層行為架構是什麼（Ch 3 後半段）
• 你不需要自己設定任何東西

下一章（Ch 4）會帶你親手操作——從儲存一篇 AACR 會議報導開始，一步步走過盡調、論文搜索、報告排版的完整流程。把你在 Ch 2 和 Ch 3 學到的概念，變成真正可以交出去的工作成果。

準備好你的 Discord 頻道和終端機，我們馬上開始。

3.15 Claude Code 基礎設定 Q&A

前面幾節介紹了不少概念。這裡用 Q&A 的方式，回答 BD 同事最常問的問題。

Q1：「CLAUDE.md、Skills、Hooks 這些東西，我需要會修改嗎？」

90% 的情況不需要。 AIKT 的預設配置足以覆蓋 BD 日常工作。你需要修改的唯一情境是：

• 你想把公司 Logo 放進 kami 產出的文件 → 修改 ~/.config/kami/brand.md（這其實不是 CLAUDE.md 的一部分）
• 你想加入一個 AIKT 沒有的自訂工作流 → 需要工程師協助

其他的，用就好。

Q2：「如果 Claude 忘了某個規矩怎麼辦？」

兩個層面的回答：

如果是 CLAUDE.md 裡的規矩（機率性）： 在對話裡直接提醒它。例如：「請用繁體中文回答」或「請按照分流表處理」。Claude 通常馬上就會糾正自己。如果問題反覆出現，考慮把這條規矩從 CLAUDE.md 升級為 Hook（確定性）——但這需要工程師協助。

如果是 Hook 的規矩（確定性）： 不可能忘記。Hook 是程式碼，不是文字建議。如果 Hook 沒有觸發，那表示 Hook 的設定本身需要修改——同樣需要工程師協助。

Q3：「我可以在對話裡臨時改規矩嗎？例如『這次用英文回答就好』？」

可以。對話裡的直接指令會臨時覆蓋 CLAUDE.md 的設定。但這個覆蓋只在這次對話中有效。下次開新對話，Claude 又會回到 CLAUDE.md 的預設行為。

如果你想永久改變某個行為，最好的做法是修改 CLAUDE.local.md（你個人的設定檔，不影響團隊）。

Q4：「Subagent 跑的時候，我可以繼續做別的事嗎？」

可以，但不建議在同一個對話裡。 當 Claude 派出 Subagents 執行任務時，這個對話會進入「等待」狀態。你可以去做別的事（喝咖啡、看 email、開另一個 AIKT 對話），等它完成後會在 Discord 通知你。

但不要在同一個對話裡插入新指令——這可能會打斷 Subagent 的工作流。

Q5：「四層架構聽起來很複雜。有沒有一句話總結？」

有。

AIKT = 一個預裝好所有規矩（CLAUDE.md）、所有技能（Skills）、所有安全機制（Hooks）、並會自動學習你偏好（Memory）的 AI BD 助理。你只管用前綴指令下單，它會按照 SOP 交付結果。

就這樣。

Q6：「如果 AIKT 更新了，我的設定會被覆蓋嗎？」

不會。AIKT 的設計把「系統設定」和「你的個人設定」分開：

底線：你個人的東西不會被覆蓋，系統的東西會隨更新變好。 這是版本控制系統的優勢——團隊共用的設定由維護者統一更新，你個人的設定由你自己掌控。

Q7：「聽說 Claude Code 很貴。四層架構中，哪些會消耗 token（算力費用）？」

好問題。簡單整理：

AIKT 已經內建了 Token 省用機制（包括 L16 rtk Token 壓縮器），整個系統的設計從一開始就在考慮成本效率。身為使用者，你不需要擔心這些——知道「系統在幫你省錢」就好。

本章重點回顧

Ch 4：基本操作 — 你的第一個 Layer

工具已經裝好了。現在讓我們真正動手——從最簡單的操作開始，一步步感受 AIKT 的威力。本章有四個 hands-on tutorial（實作教學），分別對應四個最常用的 Layer。每個 tutorial 都從「你在 Discord 打一句話」開始，到「你拿到一份完整的文件」結束。

4.0 開始之前 — 你的工作介面長什麼樣

在進入 tutorial 之前，先理解一下你的工作流程。當你使用 AIKT 時，操作方式是：

1. 你在 Discord 頻道裡打一句指令（或貼一個 URL）
2. Claude（AI 助手）收到你的訊息，自動判斷該走哪個 Layer
3. Claude執行對應的腳本，處理你的輸入
4. Claude把結果存檔，並在 Discord 回覆你

你不需要打開終端機、不需要記指令、不需要寫程式碼。你只要在 Discord 裡「說話」就好。

還記得嗎？ Ch 2 提到 AIKT 像郵局——你只需要知道「寄到哪裡」（用什麼 prefix），系統會自動「分揀到正確的窗口」（路由到正確的 Layer）。

好，讓我們開始。

4.1 Tutorial 1：ai-save（L1）— 儲存一篇網頁文章

場景

你是 BioGenesis Corp. 的 BD 經理。今天早上你在 STAT News 上看到一篇關於 ADC (Antibody-Drug Conjugate; 抗體藥物複合體) 市場趨勢的深度報導，想存起來之後參考。以前你會複製連結貼到 Notion 或 Bookmark 裡，但幾個月後你就找不到那篇文章了。

用 AIKT，你可以把整篇文章的完整內容存成結構化的 Markdown 檔案，標題、日期、標籤一應俱全，永遠不會弄丟。

操作步驟

你在 Discord 打：

1https://statnews.com/2026/06/adc-market-overview

就這樣。一個 URL，沒有任何 prefix，沒有任何指令。

發生了什麼事？

Claude 收到你的訊息後，會依照以下流程自動處理：

下面這張流程圖展示了 ai-save 從 URL 到存檔的完整資料流：

flowchart LR
    A["你貼 URL
到 Discord"] --> B["Claude 偵測到
非 GitHub URL"]
    B --> C["執行 ai-save.sh"]
    C --> D{"markitdown
下載成功？"}
    D -->|是| E["轉成 Markdown"]
    D -->|否| F{"opencli
下載成功？"}
    F -->|是| E
    F -->|否| G{"playwright
下載成功？"}
    G -->|是| E
    G -->|否| H["記錄失敗
存基本資訊"]
    E --> I["加上 frontmatter"]
    I --> J["存入 inbox/"]

讓我們拆解這個流程：

1. 偵測 URL 類型：Claude 看到你的訊息是一個 URL（不是 GitHub 的），自動判定要走 Layer 1 ai-save
2. 呼叫下載腳本：Claude 執行 bash scripts/ai-save.sh "https://statnews.com/2026/06/adc-market-overview"
3. 三段降級鏈：
   • 第一步試 markitdown（最快、最省資源，適合靜態網頁）
   • 如果失敗（例如網頁是 JavaScript 動態載入的），試 opencli（用 Chrome 渲染）
   • 如果還是失敗，試 playwright（headless 瀏覽器，最後手段）
4. 轉成 Markdown：把網頁的標題、正文、圖片說明等轉成結構化的 Markdown 格式
5. 加上 frontmatter：在檔案開頭加上 metadata（標題、來源 URL、擷取時間、標籤等）
6. 存入 inbox/：檔案存到 inbox/ 目錄，檔名格式為 YYYY-MM-DD-article-<slug>.md

你會看到…

Claude 在 Discord 回覆你一則訊息，大約長這樣：

1已儲存：inbox/2026-06-29-article-adc-market-overview.md
2
3標題：ADC Market Overview: Trends Shaping the Next Wave
4來源：https://statnews.com/2026/06/adc-market-overview
5類型：article
6標籤：[]

存檔的檔案長什麼樣？

打開 inbox/2026-06-29-article-adc-market-overview.md，你會看到類似這樣的結構：

 1---
 2title: "ADC Market Overview: Trends Shaping the Next Wave"
 3source_url: "https://statnews.com/2026/06/adc-market-overview"
 4source_type: article
 5captured_at: "2026-06-29T09:15:32+08:00"
 6tags: []
 7---
 8
 9# ADC Market Overview: Trends Shaping the Next Wave
10
11The antibody-drug conjugate market is projected to reach $30 billion
12by 2030, driven by...
13
14## Key Players
15
16- Daiichi Sankyo / AstraZeneca: Enhertu franchise...
17- Pfizer / Seagen: Adcetris and next-gen payloads...
18- Gilead Sciences: Trodelvy...
19
20## Market Drivers
21
221. Improved linker technology enabling higher DAR...
232. Expansion into earlier lines of therapy...
243. Novel payload classes beyond MMAE/DXd...
25
26(完整文章內容)

注意幾個關鍵點：

• --- 之間的是 frontmatter（結構化 metadata），機器和人都能讀
• source_url 記錄了原始來源，永遠可以回溯
• captured_at 記錄了你存檔的時間
• tags: [] 目前是空的，你可以之後手動加標籤，也可以讓 Claude 幫你加
• 正文是完整的文章內容，不是只有摘要

進階用法：儲存文字片段

如果你不是要存一個 URL，而是要存一段文字（例如同事在 LINE 群組裡分享的產業消息），直接在 Discord 裡打那段文字就行：

1今天跟 Daiichi Sankyo 的 BD 聊到，他們 Q3 要開放 ADC 平台授權，
2payload 不限 DXd，也可以談 MAAA-1181。
3窗口是東京 BD 部門的 Tanaka-san。

你會看到： Claude 把這段文字包成一個 markdown 檔案，存入 inbox/2026-06-29-text-091732.md，frontmatter 的 source_type 標為 text。六個月後你搜尋「Daiichi」或「MAAA-1181」就能找到這條筆記。

為什麼這比 Notion / Evernote 好？

ai-save 支援的 URL 類型

ai-save 不只能存新聞文章，它幾乎能處理任何 URL：

特別有用的場景：YouTube 影片的 URL。ai-save 會用 markitdown 自動抓取影片的字幕逐字稿，存成可搜尋的 Markdown。這意味著你在 AACR 會議上錯過的演講，只要有 YouTube 回放，就能把完整內容存下來。

小技巧：用標籤分類

存檔後，你可以請 Claude 幫你加標籤：

1幫我把 inbox/2026-06-29-article-adc-market-overview.md 加上標籤：ADC, market-analysis, 2026

你會看到： Claude 會修改檔案 frontmatter 裡的 tags: []，變成 tags: [ADC, market-analysis, 2026]。之後搜尋特定標籤就能快速找到相關文章。

4.2 Tutorial 2：gh-save（L2）— 儲存一個 GitHub 專案

場景

你正在為 BioGenesis Corp. 評估一個 PDF 解析工具，工程團隊推薦了 GitHub 上的開源專案 MinerU。你需要快速了解這個專案的基本資訊：它有多少人用？最近還有在維護嗎？功能有哪些？有沒有已知問題？

以前你會打開 GitHub 網頁，一個一個 tab 去看 README、看 Issues、看 Releases。現在你只需要一句話。

操作步驟

你在 Discord 打：

1gh full: https://github.com/opendatalab/MinerU

讓我們拆解這個指令：

• gh full: 是 prefix（前綴），告訴 Claude 要走 Layer 2 gh-save
• full 表示要「完整報告」（含 README 全文 + 熱門 Issues）
• 後面跟著 GitHub 的 URL

gh-save 的三種深度

你可以根據需要選擇不同的報告深度：

下面這張流程圖展示了 gh-save 三種深度的選擇與包含內容：

flowchart TD
    A["你給一個 GitHub URL"] --> B{"使用什麼 prefix？"}
    B -->|"gh:"| C["標準報告"]
    B -->|"gh deep:"| D["深度報告"]
    B -->|"gh full:"| E["完整報告"]
    B -->|無 prefix| F["Claude 問你
要哪種深度"]

    C --> C1["metadata
stars / forks / license"]
    C --> C2["近期 5 個 commits"]
    C --> C3["近期 3 個 releases"]

    D --> D1["標準報告的全部內容"]
    D --> D2["README 全文"]

    E --> E1["深度報告的全部內容"]
    E --> E2["熱門 Issues Top 5"]

BD 建議：大多數情況用 gh full: 就對了。完整報告包含最多資訊，讓你一次看完所有需要知道的事。

發生了什麼事？

Claude 收到你的 gh full: 指令後：

1. 呼叫 GitHub API：透過 gh repo view 取得 repo metadata（名稱、描述、星數、語言、授權等）
2. 抓取近期 commits：最近 5 個 commit 的訊息和日期
3. 抓取 releases：最近 3 個版本的版本號和發布日期
4. 下載 README：完整的 README 文件內容
5. 查詢 Issues：按留言數排序，取最熱門的 5 個 Issue
6. 組裝報告：把所有資訊組裝成結構化的 Markdown
7. 存檔：透過 scripts/gh-save.sh 存入 inbox/

你會看到…

Claude 在 Discord 回覆你一份精簡的摘要：

 1已儲存：inbox/2026-06-29-github-opendatalab-MinerU.md
 2
 3專案：opendatalab/MinerU
 4描述：A high-quality tool for convert PDF to Markdown and JSON
 5語言：Python
 6Stars：29,847 ⭐
 7Forks：2,156
 8License：AGPL-3.0
 9最近更新：2026-06-28
10
11近期動態：
12- v0.10.2 (2026-06-25): Performance improvements for CJK texts
13- v0.10.1 (2026-06-18): Bug fixes for table extraction
14
15熱門 Issues：
16- #892 Support for scanned PDFs with handwriting (45 留言)
17- #856 Memory leak on large PDFs > 500 pages (32 留言)
18- #801 Docker image size optimization (28 留言)

存檔的檔案長什麼樣？

打開 inbox/2026-06-29-github-opendatalab-MinerU.md，你會看到：

 1---
 2title: "opendatalab/MinerU — A high-quality tool for convert PDF to Markdown"
 3source_url: "https://github.com/opendatalab/MinerU"
 4source_type: "github"
 5captured_at: "2026-06-29T10:30:00+08:00"
 6stars: 29847
 7language: "Python"
 8topics: ["pdf", "markdown", "ocr", "document-parsing"]
 9license: "AGPL-3.0"
10tags: []
11---
12
13## 專案概述
14（repo description + 1-2 句補充）
15
16## 技術亮點
17- 使用語言：Python
18- 主要 topics：pdf, markdown, ocr, document-parsing
19- 核心用途：高品質 PDF → Markdown / JSON 轉換
20
21## 近期動態（最後 5 個 commits）
22- 2026-06-28 a3f7c2d Fix CJK character spacing in table cells
23- 2026-06-27 b8e1d4f Update OCR model to v3.2
24- ...
25
26## 為什麼值得關注
27（stars 趨勢、獨特之處、與其他方案差異）
28
29## README 全文
30（完整 README 內容）
31
32## 熱門 Issues
33- #892 Support for scanned PDFs with handwriting (45 留言, 2026-05-12)
34- ...

注意看 frontmatter 裡的結構化資訊：stars、language、topics、license 全部都是可以被機器讀取的欄位。之後如果你用 Layer 12 gh-tutorial-qd 來做完整教學文件，這些 frontmatter 資訊會被自動利用。

進階用法

搜尋 GitHub 專案：如果你不知道確切的 repo URL，可以用關鍵字搜尋：

1gh search: ADC payload linker bioinformatics

你會看到： Claude 列出搜尋結果前 10 名，按星數排序。你回覆編號（如 1 3 5），Claude 就會把你選的 repo 存入 inbox/。

瀏覽整個組織：想看某個組織（如 opendatalab）最近在做什麼：

1gh org: opendatalab

你會看到： 該組織最近更新的 10 個 repo 清單，含描述和星數。

BD 實際應用範例

假設你在 AACR (American Association for Cancer Research; 美國癌症研究協會) 會議上聽到一家公司提到他們用了某個開源的 ADC linker 設計工具。你可以：

1. gh search: ADC linker design → 找到候選 repo
2. gh full: <URL> → 做完整評估
3. 把報告寄給工程團隊評估技術可行性

整個過程不到 5 分鐘。以前你可能需要自己在 GitHub 上翻半小時，然後寫一封郵件摘要。

4.3 Tutorial 3：quarkdown（L7）— 把 Markdown 變成漂亮的 HTML

場景

你用 ai-save 存了 5 篇 ADC 市場文章，用 gh-save 存了 3 個相關的 GitHub 專案。現在你要寫一份「ADC 技術趨勢簡報」給主管看。你已經在 Markdown 裡寫好了內容，但純文字的 .md 檔案不太適合直接交出去——主管期待的是一份有格式、有目錄、看起來專業的文件。

quarkdown 就是把你的 Markdown 內容「排版」成漂亮的 HTML（或 PDF）的工具。想像你寫了一封手寫信，quarkdown 就像一台印刷機，把你的手寫稿變成精裝書。

操作步驟

你在 Discord 打：

1qd from: inbox/2026-06-29-article-adc-market-overview.md

讓我們拆解：

• qd from: 是 prefix，告訴 Claude 要走 Layer 7 quarkdown
• 後面跟著你要轉換的 Markdown 檔案路徑

發生了什麼事？

下面這張流程圖展示了 quarkdown 從 Markdown 到 HTML 的完整轉換流程：

flowchart LR
    A["你的 .md 檔案"] --> B["scripts/quarkdown.sh
convert"]
    B --> C["轉換為 .qd 格式"]
    C --> D["套用 preset
（預設 report）"]
    D --> E["scripts/quarkdown.sh
compile"]
    E --> F["生成 index.html"]
    F --> G["雙擊開啟
就能看"]

具體步驟：

1. md → qd 轉換：Claude 執行 bash scripts/quarkdown.sh convert inbox/2026-06-29-article-adc-market-overview.md --preset report

   • 把 Markdown 語法轉成 quarkdown 格式（大部分相同，但 mermaid 圖表需要特殊處理）
   • 從 frontmatter 或第一個 H1 標題自動設定文件名稱
   • 套用 report preset（報告風格的排版）

2. qd → HTML 編譯：Claude 執行 bash scripts/quarkdown.sh compile <file>.qd --mode plain

   • quarkdown 引擎（Java 程式）讀取 .qd 檔案
   • 套用主題色彩、字型、排版
   • 生成完整的 index.html

3. 輸出完成：HTML 檔案出現在輸出目錄

重要細節：--mode plain 是必要的。如果不加這個旗標，生成的 HTML 用「雙擊開啟」（file:// 協定）時會白屏。plain 模式確保你在本機直接打開就能看。

你會看到…

Claude 在 Discord 回覆：

1Markdown → quarkdown 轉換完成
2已編譯 HTML：projects/adc-market-overview/quarkdown-out/plain/index.html
3
4你可以雙擊 index.html 在瀏覽器中查看。

打開 HTML 後的效果

當你在 Finder（macOS）或檔案總管（Windows）裡找到 index.html，雙擊打開，你會在瀏覽器裡看到：

• 專業的排版：標題、副標題、段落都有適當的字型和間距
• 自動目錄：如果文章有多個章節（H2、H3），會自動生成可點擊的目錄
• Mermaid 圖表：如果你的 Markdown 裡有 mermaid 語法的圖表，會被渲染成漂亮的向量圖
• 程式碼高亮：如果有程式碼區塊，會有語法上色
• 統一配色：根據 preset 使用一致的顏色方案

quarkdown 的 5 種 preset

BD 建議：日常用 report 就好。要做簡報時用 slides-light（淺色背景比較商務）。

進階：從零開始寫一份報告

如果你還沒有現成的 Markdown 檔案，也可以讓 Claude 幫你從主題直接生成：

1qd: ADC 市場趨勢 2026 as report

你會看到： Claude 會先幫你生成一份 .qd 草稿（包含大綱和初步內容），然後編譯成 HTML。你可以在 Discord 裡跟 Claude 討論修改內容，Claude 會即時更新。

進階：生成 PDF

如果你需要 PDF 而不是 HTML（例如要郵件附檔給外部合作夥伴），可以加上 --pdf 旗標：

1bash scripts/quarkdown.sh compile note.qd --pdf --mode paged

你會看到： 除了 index.html，同一目錄下還會出現一個 PDF 檔案。PDF 會有 A4 分頁、頁碼，跟你在辦公室印出來的報告一樣。

注意：PDF 生成需要 Node.js（用來跑 Puppeteer 渲染引擎）。第一次執行會自動下載 Chromium 瀏覽器（~200-300 MB），之後就不需要了。

為什麼不直接用 Google Docs / Word？

核心優勢：你在 Layer 1 存的文章、Layer 2 存的 GitHub 報告，都是 Markdown 格式。Layer 7 quarkdown 可以直接把它們變成漂亮的 HTML/PDF，不需要「複製貼上 → 手動排版」這個步驟。整個知識管道是連通的。

4.4 Tutorial 4：kami（L11）— 產出專業 PDF 文件

場景

AACR 會議下週就要開始了。BioGenesis Corp. 的 CEO 要你準備一份「公司一頁摘要」（one-pager），在會議上交給潛在合作方。這份文件需要有公司 Logo、聯絡方式、核心技術說明、管線進度——而且必須看起來夠專業，因為對面坐的可能是 Pfizer 或 Roche 的 BD VP。

以前你會開 PowerPoint 或 InDesign 折騰半天。現在你用 kami（紙），10 分鐘搞定。

kami 與 quarkdown 的差別

在開始之前，先釐清一個常見問題：Layer 7 quarkdown 和 Layer 11 kami 有什麼不同？

簡單規則：對內文件用 quarkdown，對外文件用 kami。

kami 的 8 種文件類型

kami 支援 8 種精心設計的文件類型。每一種都有繁中、英文、韓文三語版本的模板：

BD 最常用前三名：one-pager（會議用一頁紙）、equity-report（投資分析）、slides-weasy（簡報）。

操作步驟

你在 Discord 打：

1kami: one-pager BioGenesis

讓我們拆解：

• kami: 是 prefix，告訴 Claude 走 Layer 11
• one-pager 指定文件類型
• BioGenesis 是主題名稱

發生了什麼事？

下面這張流程圖展示了 kami 從類型選擇到 PDF 產出的完整流程：

flowchart TD
    A["你說 kami: one-pager BioGenesis"] --> B["Claude 選擇模板
one-pager.html"]
    B --> C["Claude 填充內容"]
    C --> D["讀取 brand.md
套用品牌設定"]
    D --> E["生成完整 HTML"]
    E --> F["kami build
WeasyPrint 渲染"]
    F --> G["輸出 PDF 檔案"]
    G --> H["存入
projects/BioGenesis/kami/"]

具體步驟：

1. 選擇模板：Claude 根據你指定的類型（one-pager）和語言（偵測到你用中文，選中文版模板 one-pager.html）
2. 填充內容：Claude 根據你提供的主題「BioGenesis」，填入公司名稱、基本資訊。如果你之前有相關的 inbox/ 文件（例如之前存的 BioGenesis 相關文章），Claude 可能會從中提取資訊
3. 讀取品牌設定：如果你設定過 ~/.config/kami/brand.md，會自動套用公司 Logo、品牌色等
4. 生成 HTML：完整的 HTML 檔案，包含所有排版和內容
5. WeasyPrint 渲染：Claude 執行 bash scripts/kami.sh build <html-path>，用 WeasyPrint 引擎把 HTML 轉成 PDF
6. 存檔：PDF 和 HTML 都存入 projects/BioGenesis/kami/

你會看到…

Claude 在 Discord 回覆：

 1kami: one-pager 已完成
 2
 3HTML：projects/BioGenesis/kami/one-pager.html
 4PDF：projects/BioGenesis/kami/one-pager.pdf
 5
 6設計風格：warm parchment / ink-blue accent / serif
 7語言：繁體中文
 8
 9你可以雙擊 HTML 預覽，或直接使用 PDF。
10需要修改內容請告訴我。

打開 PDF 後的效果

你會看到一份非常精美的一頁文件：

• 暖色羊皮紙背景：不是死白色的紙，而是帶一點溫暖米色調的底色
• 墨水藍強調色：標題和重點用深藍色標示
• 襯線字型：中文用蒼耳今楷、英文用 Charter——正式而不死板
• 結構清晰：公司名稱、核心技術、管線、聯絡方式分區塊排列
• 品牌一致：如果你設定了 brand.md，Logo 和公司色系會自動套用

互動修改

如果你對內容不滿意，直接在 Discord 裡跟 Claude 說：

1把管線表格裡的 Phase 2 改成 Phase 3，
2然後在「核心技術」段落加上 DAR 8 的說明。

你會看到： Claude 修改 HTML 內容，重新執行 kami build，產出新的 PDF。整個過程不到 1 分鐘。

進階用法：其他文件類型

equity-report（個股研報）——適合做投資備忘錄：

1kami: equity-report BioGenesis Corp ADC平台估值分析

你會看到： 一份類似券商研報的 PDF，有目標價、管線分析、估值模型的排版框架。你只需要填入數字和分析。

letter（正式信函）——適合寫合作意向書 (LOI; Letter of Intent)：

1kami: letter BioGenesis-Roche合作意向書 lang=en

你會看到： 一封格式正確的商業信函 PDF，有日期、收件人、正文、署名區，語言為英文（因為你指定了 lang=en）。

slides-weasy（簡報）——適合做會議簡報：

1kami: slides-weasy BioGenesis Q3 Board Update

你會看到： 一組投影片風格的 PDF，每一頁是一張 slide。用的是 kami 的暖色設計語言，比 PowerPoint 的預設模板高級很多。

kami 的三步流程（詳解）

讓我們更仔細地看 kami 的完整工作流程，理解每個步驟發生了什麼：

Step 1：模板選擇與語言判斷

當你說 kami: one-pager BioGenesis 時，Claude 會：

• 判斷語言：你用中文打字 → 選中文模板 one-pager.html
• 如果你說 kami: one-pager BioGenesis lang=en → 選英文模板 one-pager-en.html
• 如果你用日文 → 盡力選 CJK 路徑，但建議視覺檢查

Step 2：內容填充（意圖萃取）

Claude 不會直接給你一個空殼模板。它會先在背後做一個「意圖萃取」：

• Purpose（目的）：one-pager 的目的通常是「讓對方在 30 秒內了解你的公司」
• Audience（讀者）：AACR 會議的潛在合作方，通常是同業的 BD 或 CSO
• Constraint（限制）：一頁 A4，內容要精煉
• Success（成功指標）：對方看完願意交換名片、安排 follow-up 會議

如果 Claude 覺得你給的資訊不夠（例如你只說了「BioGenesis」但沒說要放什麼內容），它會在 Discord 裡問你一個精簡的問題，而不是丟出一長串問卷。

Step 3：WeasyPrint 渲染

kami 用 WeasyPrint 把 HTML 轉成 PDF。這個引擎的特色是：

• 完全離線：不需要連網，渲染在你的電腦上完成
• 精確控制：CSS 的分頁、邊距、字型都能精確控制
• 印刷品質：300 DPI 輸出，直接送印都沒問題

kami 與 quarkdown 的分工規則

這個規則很重要，記住就好：

1含 mermaid 圖表的內容 → 一律走 quarkdown（L7）
2需要品牌設計感的對外文件 → 走 kami（L11）
3沒有 prefix 的 Markdown → 預設走 quarkdown
4kami 必須顯式呼叫（用 kami: prefix）

為什麼 mermaid 要走 quarkdown？ 因為 WeasyPrint（kami 的渲染引擎）不直接支援 mermaid 語法。quarkdown 有內建的 mermaid 渲染器，能把圖表語法轉成向量圖。如果你的 kami 文件裡需要圖表，有兩種做法：

1. 先用 quarkdown 渲染 mermaid → 匯出 PNG → 嵌入 kami HTML
2. 直接用 quarkdown 排版整份文件（如果設計要求沒那麼高）

kami 的設計哲學

kami 的名字來自日文「紙（かみ）」。它的設計理念是：好的內容值得好的載體。

就像你不會把一瓶 1982 年的拉菲裝在塑膠杯裡端上桌，你也不應該把精心準備的 BD 提案用 Times New Roman 12pt 的 Word 檔交出去。kami 確保你的內容呈現方式與內容品質匹配。

kami 的設計語言有三個核心元素：

這三個元素組合在一起，產出的文件比任何 PowerPoint 模板都更有「精心準備」的感覺。在 AACR 這樣的大型會議上，當別人遞出來的是制式 Word 轉 PDF，而你遞出來的是 kami 排版的 one-pager，第一印象就已經贏了。

但也不要過度依賴排版。一份內容空洞但排版精美的 one-pager，只會讓對方覺得「這家公司很會做文件但沒有真材實料」。先確保你的內容紮實（這是 L1 ai-save、L2 gh-save、L9 paper-search、L22 company-intel 的工作），再用 kami 做最後的包裝。

4.5 四個 Tutorial 的連貫性 — 知識管道的威力

到這裡，你已經學會了四個 Layer 的基本操作。讓我們回顧一下它們是怎麼串在一起的：

 1你的日常工作流可能是這樣的：
 2
 3早上 9:00 — 看到一篇好文章
 4  → L1 ai-save：貼 URL，存入 inbox/
 5
 6早上 10:00 — 工程師推薦一個 GitHub 專案
 7  → L2 gh-save：gh full: URL，存入 inbox/
 8
 9下午 2:00 — 要寫一份內部趨勢報告
10  → L7 quarkdown：qd from: inbox/xxx.md，生成 HTML
11
12下午 4:00 — 主管要一份 one-pager 給合作方
13  → L11 kami：kami: one-pager 主題，生成 PDF

關鍵洞察：每個 Layer 的輸出，都可以成為下一個 Layer 的輸入。inbox/ 是你的知識倉庫，所有 Layer 都可以從中取用材料。這就是為什麼 AIKT 叫「知識模板（knowledge template）」——它不是一個單獨的工具，而是一個讓知識流動的管道系統。

4.6 常見問題 — 新手常踩的坑

Q1：「我打了指令但 Claude 沒反應怎麼辦？」

檢查三件事：

1. 頻道對嗎？ 確認你在正確的 Discord 頻道裡（每個 AIKT 實例對應一個特定頻道）
2. prefix 對嗎？ gh: 後面有冒號和空格，不是 gh :（多了空格）也不是 gh（少了冒號）
3. Claude 在線嗎？ 看看 Claude 的狀態是否為綠色在線

Q2：「inbox/ 裡的檔案越來越多，怎麼整理？」

目前 AIKT 的 inbox/ 是扁平結構（所有檔案在同一個目錄），但檔名有日期前綴（YYYY-MM-DD-*），方便按時間排序。你也可以：

• 用 ls inbox/ | grep "adc" 搜尋特定關鍵字
• 用 grep -l "ADC" inbox/*.md 全文搜尋
• 讓 Claude 幫你分類：「幫我把 inbox/ 裡跟 ADC 相關的文章列出來」

Q3：「quarkdown 編譯出來的 HTML 打開是白色的，什麼都沒有？」

這是最常見的新手問題。原因是你的 .qd 檔案用了 paged 模式編譯（預設），但雙擊開啟 HTML 走的是 file:// 協定，paged.js 在 file:// 下無法運作。

解法：確保編譯時加上 --mode plain：

1qd compile: <file>.qd --mode plain

你會看到： 重新編譯後的 index.html，雙擊開啟就能正常顯示內容了。

Q4：「kami build 失敗，顯示 WeasyPrint 錯誤怎麼辦？」

最常見的原因是系統缺少字型或圖形庫。回到 Ch 3 的安裝指引，執行那段 apt install 指令安裝依賴。

如果是字型問題（PDF 裡的中文顯示成方框），安裝中文字型：

1sudo apt install fonts-noto-cjk

Q5：「我可以修改 kami 的設計風格嗎？」

可以，但有兩種方式：

1. 品牌設定（推薦）：編輯 ~/.config/kami/brand.md，修改 Logo、公司名稱、品牌色等。這是正規的客製化方式。
2. 直接改 HTML（進階）：你可以直接編輯 kami 生成的 HTML 檔案，然後重新 kami build。但這需要懂 HTML/CSS，不建議 BD 新手嘗試。

Q6：「我存了一篇文章但內容不完整，只有標題和前兩段？」

這通常表示網頁有付費牆（paywall）或需要登入才能看全文。ai-save 的 markitdown 工具只能抓取公開可見的內容。

解法：

• 如果你有訂閱，在瀏覽器裡打開文章、全選複製、在 Discord 裡直接貼全文，ai-save 會把它存為 text 類型
• 或者用 Layer 23 agent-browser，如果它已經登入了你的帳號

Q7：「gh-save 顯示 ‘gh CLI 未認證’？」

你需要先登入 GitHub CLI：

1gh auth login

選「GitHub.com」→「HTTPS」→「Login with a web browser」，照指示完成。

完成後驗證：

1gh auth status

你會看到： Logged in to github.com as <your-username>

Q8：「可以一次對多個 URL 執行 ai-save 嗎？」

可以，在 Discord 裡一次貼多個 URL（每個 URL 一行）：

1https://example.com/article-1
2https://example.com/article-2
3https://example.com/article-3

Claude 會依序處理每個 URL，每個都存成獨立的 markdown 檔案。

4.7 下一步建議 — 練習計畫

學完了基本操作，建議你用以下計畫練習一週：

進入 Ch 5 之前：你已經會用四個 Layer 了。Ch 5 會教你 AIKT 最強大的能力之一——Layer 22 company-intel（公司盡職調查）。BD 的核心戰場，就在那裡。

Q9：「kami 產出的 PDF 可以編輯嗎？」

PDF 本身不太方便編輯。如果你需要做微調：

1. 改 HTML 再重新渲染：修改 kami 產出的 HTML 檔案（用任何文字編輯器），然後再執行一次 kami build
2. 請 Claude 改：在 Discord 裡告訴 Claude 要改什麼，它會幫你修改 HTML 並重新渲染
3. 如果需要可編輯格式：考慮用 quarkdown 輸出 HTML（HTML 在瀏覽器裡可以複製內容），或請 Claude 把內容同時輸出為 Word 格式

BD 實務建議：大多數對外文件（one-pager、equity report）不需要讓對方編輯。PDF 格式其實是優勢——確保對方看到的跟你設計的一模一樣，不會因為字型缺失或排版跑掉而出現意外。

Q10：「四個 Layer 學完了，接下來該學什麼？」

取決於你最迫切的需求：

本章重點回顧

Ch 4.5：Superpowers 開發工作流 — 像蓋房子一樣規劃 AI 任務

本章重點：了解 AIKT 的 Superpowers 工作流 — 一套確保每個 AI 任務都「做對、做好、可追蹤」的標準化五步驟流程。無論你是要做一份盡調報告、同步兩個系統、還是撰寫一份萬行教學，Superpowers 都是背後的品質引擎。

4.5.1 為什麼需要 Superpowers？

一個 BD 人的週一早上

在介紹 Superpowers 之前，讓我們先想像一個場景。

BioGenesis Corp. 的 BD 主管 Alice 週一早上到辦公室，打開 email，看到三件事：

1. VP 要她在週五前準備 AACR 研討會的 3 家目標公司盡調報告
2. 同事轉來了 5 篇新的 ADC 論文，問她能不能做成團隊內部教學
3. 公司網站上的技術白皮書需要更新

如果 Alice 用傳統方式處理，每件事可能需要 2-3 天。但有了 AIKT，每件事可能只需要 2-3 小時。

但是 — 這裡有個但是 — AI 快不代表 AI 對。

如果 Alice 急著把任務丟給 Claude，沒有先對齊方向，可能會得到：

• 盡調報告用了錯誤的公司名稱（因為有同名公司）
• 論文教學寫成了學術風格（因為 Claude 預設面向研究人員）
• 白皮書更新改了本來不該改的段落（因為範圍沒界定好）

每一個「做錯 → 重來」的循環都要 1-2 小時。三件事加起來，可能浪費一整天。

Superpowers 就是為了解決這個問題而設計的。 它讓你在開始之前花 15 分鐘對齊方向，確保 AI 的第一次輸出就是你要的。

蓋房子的故事

讓我們用一個更具體的比喻來說明。想像一下這個場景：

你決定蓋一棟房子。你走到一塊空地，叫了一群工人過來，然後說：「幫我蓋一棟漂亮的房子。」

工人們開始動手了。泥水匠開始砌牆，電工開始拉線，水管工開始裝管。問題是：

• 沒有人知道房子長什麼樣
• 沒有人知道房間要幾間
• 沒有人知道廁所在哪裡
• 電工拉的線被泥水匠砌進牆裡了
• 水管工裝好的管子，被木工鋸斷了

三個月後，你得到了一棟「東西」。它確實有牆、有屋頂、有門。但是：

• 廁所在廚房旁邊
• 臥室沒有窗戶
• 客廳的電線外露
• 二樓的地板會漏水

這就是「沒有流程」的結果。

你可能會說：「可是我告訴他們要蓋漂亮的房子了啊！」問題就在這裡 — 「漂亮」對每個人的意義都不同。對泥水匠來說，漂亮就是牆面光滑；對電工來說，漂亮就是線路整齊；對你來說，漂亮是「三房兩廳、採光好、有陽台」。

如果你不把你心中的「漂亮」用藍圖寫清楚，每個人就會按自己的理解去做。

AI 任務也是一樣。當你說「幫我做一份盡調報告」，Claude 可能理解為一份 3 頁的簡要摘要。但你心裡想的是一份 30 頁的完整分析報告，含 pipeline 比較表、競爭優勢分析、甚至包含專利佈局。如果不在開始前對齊期望，結果必然令人失望。

現在，換一個場景：

你找了一位建築師 (architect; 建築師)。建築師先跟你坐下來聊：「你家有幾個人？需要幾間臥室？喜歡什麼風格？預算多少？」然後他畫出設計藍圖 (blueprint; 藍圖)，請結構工程師檢查，確認沒問題後才開始施工。施工過程中，每天都有施工日誌 (construction log; 施工日誌) 記錄進度、問題、解決方案。

三個月後，你得到了一棟完全符合需求的房子。

Superpowers 就是那個「建築師 + 藍圖 + 施工日誌」的流程。

你可能會想：「可是蓋房子要幾個月，我的 AI 任務最多幾個小時啊。有必要這麼大費周章嗎？」

答案取決於任務的 複雜度 和 重做成本。如果你只是請 Claude 幫你存一個網址（10 秒鐘的事），當然不需要 Superpowers。但如果你請 Claude 幫你做一份 30 頁的盡調報告（可能要 2 小時），而且做錯了要從頭來過，那 15 分鐘的規劃絕對值得。

規劃時間和任務時間的黃金比例大約是 1:4 到 1:6。 如果任務需要 2 小時，花 20-30 分鐘做規劃是合理的。如果任務需要 10 分鐘，那就不需要規劃了。

沒有流程的 AI 任務會怎樣？

在 AIKT 的世界裡，「沒有流程」的 AI 任務就像沒有藍圖蓋房子：

讓我們用一個真實案例來說明。假設 BioGenesis Corp. 的 BD 主管 Alice 說：

「幫我把這 5 篇 ADC 論文做成一個教學文件。」

沒有 Superpowers 的做法：Claude 直接開始寫。寫了 3000 行，Alice 看完說：「我要的不是學術風格，我要 BD 看得懂的版本。」全部重寫。

有 Superpowers 的做法：Claude 先問 5 個問題（語言？風格？重點？格式？誰看？），確認後畫藍圖，藍圖經過審核確認沒問題，才開始寫。一次到位。

差別在哪？前者浪費了 3 小時和數萬個 token。後者多花了 15 分鐘做規劃，但省下了 3 小時的重工。

讓我們把這兩種做法放在一起比較：

最後一行特別值得注意 — 「團隊協作」。如果一個任務只有你和 Claude 知道怎麼做，那等你離開團隊，這個知識就消失了。但如果有 Spec + Plan + execution.md，任何人（包括三個月後的你自己）都能重現整個過程。

flowchart LR
    subgraph NO["沒有 Superpowers"]
        direction TB
        N1["接到任務"] --> N2["直接開始做"]
        N2 --> N3["做完交付"]
        N3 --> N4["不符合需求"]
        N4 --> N5["重新來過"]
        N5 --> N2
    end

    subgraph YES["使用 Superpowers"]
        direction TB
        Y1["接到任務"] --> Y2["問清楚需求"]
        Y2 --> Y3["畫設計藍圖"]
        Y3 --> Y4["請人檢查藍圖"]
        Y4 --> Y5["按計畫執行"]
        Y5 --> Y6["一次到位"]
    end

    NO ~~~ YES

    style NO fill:#fff5f5,stroke:#e53e3e
    style YES fill:#f0fff4,stroke:#38a169

Superpowers 的五個步驟

Superpowers 是一套標準化的五步驟工作流 (5-step workflow; 五步驟工作流)，確保每個非簡單任務都經過妥善規劃和執行：

flowchart TD
    START["使用者提出任務"] --> B["Step 1: Brainstorming\n腦力激盪\n（問清楚需求）"]
    B --> S["Step 2: Spec\n設計規格\n（畫藍圖）"]
    S --> R["Step 3: Review\n審核\n（檢查藍圖）"]
    R -->|"有問題"| FIX["修正 Spec"]
    FIX --> R
    R -->|"通過"| P["Step 4: Plan\n實作計畫\n（排施工排程）"]
    P --> PR["Plan Review\n計畫審核"]
    PR -->|"有問題"| FIXP["修正 Plan"]
    FIXP --> PR
    PR -->|"通過"| E["Step 5: Execute\n執行 + execution.md\n（施工 + 施工日誌）"]
    E --> DONE["交付成果"]

什麼時候要用 Superpowers？

不是每個任務都需要走 Superpowers 完整流程。以下是判斷標準：

簡單的判斷規則：如果一個任務需要超過 30 分鐘、涉及多個 Layer、或者做錯會浪費很多時間，就應該走 Superpowers。

另一個簡單的判斷方式 — 問自己三個問題：

1. 「如果做錯了，重做的成本高嗎？」 — 如果高（例如寫了 3 小時全部白費），就走 Superpowers。
2. 「這個任務有多少不確定性？」 — 如果你不太確定要什麼結果，就先做 Brainstorming。
3. 「其他人需要看這個成果嗎？」 — 如果是要給主管或客戶看的，品質標準更高，應該走完整流程。

怎麼觸發 Superpowers？

你不需要記任何特殊指令。Superpowers 會自動觸發。

當 Claude 判斷你的任務足夠複雜時（根據上面的判斷標準），它會自動進入 Brainstorming 模式開始問你問題。你也可以主動觸發，只需在 Discord 訊息中包含表達計畫意圖的詞語：

如果 Claude 沒有自動觸發 Brainstorming，但你覺得這個任務應該先規劃，你可以直接說：

「等一下，這個任務比較複雜，我們先做一輪 Brainstorming 好嗎？」

Claude 就會切入 Brainstorming 模式。

反過來，如果 Claude 自動觸發了 Brainstorming，但你覺得不需要（例如你已經很清楚要什麼），你也可以說：

「不用 Brainstorming 了，我很清楚需求。直接做就好。」

Superpowers 是工具，不是枷鎖。 它的存在是為了幫你做得更好，而不是為了限制你。

BioGenesis 案例：BioGenesis 的 BD 主管 Alice 要準備 AACR 2026 (American Association for Cancer Research; 美國癌症研究學會) 的整套參會素材 — 包含 3 家目標公司的盡調報告、談判要點、一頁式摘要、slides。這個任務涉及 Layer 22 (company-intel)、Layer 11 (kami)、Layer 7 (quarkdown)，而且做錯會浪費大量時間。這就是典型的 Superpowers 使用場景。

讓我們用三個問題來驗證：

1. 做錯重做成本高嗎？ — 非常高，盡調報告如果方向錯了，3 家公司可能要全部重做。
2. 不確定性高嗎？ — 中等，Alice 大致知道她要什麼，但細節需要討論（例如盡調要看哪些面向？需要中文還是英文？要 slides 還是 PDF？）
3. 其他人會看嗎？ — 會，這些素材要帶到 AACR 研討會上使用，品質必須達到專業水準。

三個問題都指向同一個答案：應該走 Superpowers。

4.5.2 Step 1: Brainstorming (腦力激盪) — 先搞清楚要做什麼

這一步的目的：確保你和 Claude 對任務有完全一致的理解。不是「大概知道」，而是「白紙黑字確認」。

為什麼 Brainstorming 是最重要的一步？

在 Superpowers 的五個步驟中，Brainstorming 看起來最「不起眼」— 它不產出任何文件、不執行任何操作、不修改任何檔案。但它可能是最重要的一步。

為什麼？因為 方向性錯誤的修正成本隨著階段推進而指數成長。如果你在 Brainstorming 階段就搞清楚了「我要的是中文報告，不是英文報告」，成本是零。但如果等到 3000 行英文教學都寫完了才發現，成本是整體重寫。

一個有趣的統計：在 AIKT 的實際使用中，超過 60% 的「做錯重來」都是因為跳過了 Brainstorming，或者 Brainstorming 不夠深入。最常見的失誤類型：

Brainstorming 就是在把這些「以為不用問」但「其實超重要」的事情問清楚。

跟建築師的第一次面談

還記得蓋房子的比喻嗎？Brainstorming 就是你跟建築師的第一次面談。

建築師不會一坐下來就開始畫圖。他會先問你一連串問題：

1. 「你家有幾個人？」
2. 「需要幾間臥室？」
3. 「喜歡什麼風格？現代簡約還是古典歐式？」
4. 「預算大概多少？」
5. 「有沒有特殊需求？比如家裡有長輩需要無障礙設施？」

注意，建築師是一次問一個問題，等你回答後才問下一個。為什麼？因為你的第一個回答會影響後面的問題。如果你說「家裡有長輩」，建築師接下來可能會問「長輩的臥室需要在一樓嗎？」而不是問「要不要頂樓露台？」

Superpowers 的 Brainstorming 完全一樣。 Claude 會透過 Discord 逐題問你問題，每題給你選項（通常 A/B/C），其中一個選項會標上推薦符號。你只需要選一個，或者告訴 Claude 你有不同的想法。

Brainstorming 的運作方式

當你觸發一個需要 Superpowers 的任務時，Claude 會自動進入 Brainstorming 模式。以下是它的運作流程：

sequenceDiagram
    participant U as 使用者 (Discord)
    participant C as Claude (AIKT)

    U->>C: 提出任務需求
    Note over C: 分析任務複雜度
    C->>U: Q1: 語言選擇？
A) 全英文
B) 繁中+關鍵字 ⭐
C) 全繁中
    U->>C: B
    Note over C: 根據 Q1 答案
調整後續問題
    C->>U: Q2: 結構策略？
A) 全架構
B) 全實戰
C) 混合 ⭐
    U->>C: C
    Note over C: 根據 Q1+Q2
調整後續問題
    C->>U: Q3: 案例設定？
A) 生技公司 ⭐
B) 科技公司
C) 製藥公司
    U->>C: A
    C->>U: Q4-Q5...
    Note over C: 所有問題回答完畢
    C->>U: 設計決策摘要表

一個真實的 Brainstorming 案例

讓我們看一個 真實的 Brainstorming 過程 — 這正是你正在閱讀的這份教學的 Brainstorming 紀錄。沒錯，這份教學本身就是用 Superpowers 流程產生的。

以下是實際的 Q&A 過程（摘自 docs/superpowers/specs/2026-06-30-bd-tutorial-design.md）：

Q1：教學語言

Claude 問：「這份教學要用什麼語言？」

使用者選擇：B — 因為 BD 人員看繁中比較舒服，但技術關鍵字需要英文以便對照。

Q2：結構策略

Claude 問：「教學的結構要怎麼安排？」

使用者選擇：C — 因為 BD 人員需要先理解全貌，再學怎麼用。

Q3：虛擬公司設定

Claude 問：「案例要用什麼虛擬公司？」

使用者選擇：A — 因為 BD 人員最常在 ADC 領域工作，AACR 是最相關的研討會。

Q4：Mermaid 圖風格

Claude 問：「架構圖要用什麼風格？」

使用者選擇：A — 保持簡潔，讓 quarkdown 的 theme 統一處理視覺風格。

Q5：執行方式 + 規模

Claude 問：「要怎麼執行？規模多大？」

使用者選擇：A — 規模太大，需要多個 AI 分工並行。

Brainstorming 的設計決策摘要

所有問題回答完畢後，Claude 會生成一張 設計決策摘要表 (design decision summary; 設計決策摘要)，把所有決定整理成一張表：

這張表會被寫進 Spec（下一步），成為整個任務的「設計合約」。

flowchart TD
    Q1["Q1: 語言選擇\nA/B/C"] --> D1["決定: B 繁中+關鍵字"]
    Q2["Q2: 結構策略\nA/B/C"] --> D2["決定: C 混合"]
    Q3["Q3: 案例設定\nA/B/C"] --> D3["決定: A 生技/ADC/AACR"]
    Q4["Q4: 圖表風格\nA/B"] --> D4["決定: A 簡潔標準"]
    Q5["Q5: 執行方式\nA/B"] --> D5["決定: A 多 agent 並行"]

    D1 --> SUMMARY["設計決策摘要表"]
    D2 --> SUMMARY
    D3 --> SUMMARY
    D4 --> SUMMARY
    D5 --> SUMMARY

    SUMMARY --> SPEC["寫入 Spec 設計規格"]

為什麼要一次問一個？

你可能會想：「為什麼不一次把所有問題列出來，讓我一次回答完？」

原因跟建築師面談一樣：後面的問題取決於前面的答案。

舉個例子：

• 如果 Q1 你選了「全英文」，Q4 可能會問「要用 APA 格式還是 Nature 格式？」
• 但如果 Q1 你選了「繁中」，Q4 就不會問這個問題，因為中文文件不用 APA 格式。

又例如：

• 如果 Q2 你選了「全實戰」，Q5 可能會給你較小的規模選項（因為純實戰不需要太多架構說明）。
• 但如果 Q2 你選了「混合」，Q5 就會建議較大的規模。

每個答案都會「塑造」後續的問題選項。 這就是為什麼 Superpowers 的 Brainstorming 採用逐題對話 (one-at-a-time; 逐題對話) 的方式，而不是一次性問卷。

Brainstorming 的補充說明

在實務中，Brainstorming 還有幾個重要的細節：

1. 你可以自由回答

雖然 Claude 會給你 A/B/C 選項，但你完全可以不選任何一個，直接告訴 Claude 你的想法。例如：

1Claude: Q3: 虛擬案例要用什麼公司？
2A) 生技公司 ⭐
3B) 科技公司
4C) 製藥公司
5
6你: 我想用真實的案例，但是要匿名處理。不要虛擬公司。

Claude 會接受你的回答，並在後續問題中調整。選項只是參考，不是限制。

2. 你可以追加補充

有時候所有問題問完後，你想到了遺漏的需求。沒關係，你可以直接補充。在本教學的 Brainstorming 中，使用者就追加了 Q6（執行規範），要求 Spec 必須含前情提要、必須經過 Review、Plan 必須含 execution.md。

3. 你可以說「我不確定」

如果某個問題你不確定怎麼選，可以直接說「我不確定，你建議呢？」Claude 會解釋每個選項的利弊，幫你做決定。

4. Brainstorming 本身不產生任何「實際作業」

Brainstorming 只是「討論」，不會修改任何檔案、不會產生任何輸出。它的唯一目的就是把你和 Claude 的共識形成文字紀錄，為下一步的 Spec 做準備。所以你不用擔心「問錯了」— 在這個階段，什麼都可以改、什麼都可以推翻。

BioGenesis 案例：Alice 想做 AACR 參會素材。Brainstorming 的第一題可能是：「你需要幾家公司的盡調？」如果 Alice 說「3 家」，下一題就會問「這 3 家都是 ADC 公司嗎？」而不是問「你需要幾頁 slides？」。因為知道了公司數量，才能決定整體規模和 workflow 的分工方式。

但如果 Alice 在第三題才說：「等等，我其實還需要一份整體市場概覽」，這也完全沒問題。Claude 會把這個新需求加進設計決策中，調整後續的問題。

Brainstorming 是一個安全的討論空間 — 在這裡改主意的成本是零。 但如果等到 Execution 階段才改主意，成本可能是數小時的重工。

4.5.3 Step 2: Spec (設計規格) — 畫設計藍圖

這一步的目的：把 Brainstorming 的所有決定，加上技術細節和風險評估，寫成一份正式的設計文件。這是整個任務的「合約」。

建築師的藍圖

Brainstorming 結束後，建築師不會馬上叫工人來施工。他會先畫一份 設計藍圖 (blueprint; 設計藍圖)。

這份藍圖上會清楚標示：

• 建什麼：房子的平面圖、立面圖、3D 效果圖
• 不建什麼：不含游泳池（因為預算不夠）、不含地下室（因為地質不適合）
• 用什麼材料：混凝土結構、木質地板、玻璃帷幕
• 風險在哪：地基可能需要加固、雨季施工可能延期
• 怎樣算成功：三房兩廳、使用面積 120 坪、預算不超過 2000 萬

Spec 就是 AI 任務的設計藍圖。 它把 Brainstorming 的所有決定，加上技術細節，寫成一份正式的設計文件。

Spec 包含什麼？

一份標準的 Spec 包含以下段落，就像建築藍圖有固定的圖紙編排：

flowchart TB
    SPEC["Spec 設計規格文件"] --> S0["0. 前情提要\n（Brainstorming 紀錄）"]
    SPEC --> S1["1. 目標\n（蓋什麼房子）"]
    SPEC --> S2["2. 範圍界定\n（做什麼 / 不做什麼）"]
    SPEC --> S3["3. 技術設計\n（怎麼蓋）"]
    SPEC --> S4["4. Workflow 架構\n（幾組工人）"]
    SPEC --> S5["5. Rollback 計畫\n（出錯怎麼辦）"]
    SPEC --> S6["6. 限制條件\n（不能碰的東西）"]
    SPEC --> S7["7. 成功標準\n（怎樣算完成）"]
    SPEC --> S8["8. 開放問題\n（待解決的疑問）"]
    SPEC --> S9["9. 風險評估\n（可能出什麼問題）"]

讓我們用這份教學的 Spec（docs/superpowers/specs/2026-06-30-bd-tutorial-design.md）作為真實案例，逐一說明每個段落：

段落 0：前情提要 — 把 Brainstorming 寫進去

這個段落記錄了整個 Brainstorming 的過程，包括：

• 使用者原始需求：使用者說了什麼（原文引用）
• Brainstorming 討論紀錄：每一題的選項和決定

為什麼要記這些？因為三個月後你回頭看這份 Spec，你會忘記當初為什麼做了這些決定。有了前情提要，你（或其他人）可以理解整個思考脈絡。

真實案例：這份教學的 Spec 開頭就記錄了使用者（tpow001）在 Discord 上的原始訊息，以及 5 題 Q&A 的完整紀錄。

段落 1：目標 — 用一句話說清楚

目標要簡潔明確，像門牌號碼一樣清楚：

為完全不懂 Claude Code / vibe coding 的 BD 人員撰寫一份 10000+ 行的完整教學文件，使其能夠：

• 理解 AIKT 的 24 Layer 架構設計
• 使用各 Layer 產生 BD 工作素材
• 掌握核心案例：研討會連結 → company-intel → BD 素材

段落 2：範圍界定 — 做什麼，更重要的是「不做什麼」

範圍界定 (scope; 範圍界定) 分成兩張表：

IN SCOPE（做什麼）：

OUT OF SCOPE（不做什麼）：

「不做什麼」往往比「做什麼」更重要。 就像建築師的藍圖上會明確標示「不含游泳池」，Spec 也會明確標示不在範圍內的東西。這可以防止後續執行時的 scope creep (範圍蔓延; 範圍蔓延) — 也就是任務越做越大、永遠做不完。

段落 3-4：技術設計 + Workflow 架構

這些段落詳細描述「怎麼做」：

• 章節結構：8 章的標題、預估行數、mermaid 圖數量
• Workflow 架構：哪些任務並行、哪些順序、幾個 agent

段落 5-9：風險、限制、成功標準

讓我們逐一解釋這些段落，用蓋房子的比喻來理解：

段落 5：Rollback 計畫（出錯了怎麼恢復）

就像你在裝修前會先拍照記錄原始狀態，Rollback 計畫定義了「如果一切搞砸了，怎麼回到安全狀態」。例如：

Rollback：從 v1_clean_backup_20260630/ 完整還原

這意味著在開始任何修改之前，系統會先做一份完整備份。如果同步過程中出了嚴重問題（例如不小心覆蓋了重要檔案），可以用備份直接恢復。

蓋房子的比喻：在拆牆之前先拍好照片、做好記錄，萬一拆錯了可以還原。

段落 6：限制條件（不能碰的東西）

有些東西是「絕對不能碰」的，就像蓋房子時不能挖到鄰居的地基、不能破壞承重牆。Spec 會明確列出：

1- 不搬：blog-publish / sync-v1-to-clean / .env / .mcp.json
2- 信任 v1 SKILL.md 直接搬，不另做 sanitize
3- 每個 task 完成後必須更新 execution.md

這些限制條件是整個任務的「紅線」— 任何 agent 在執行時都不能越過。

段落 7：成功標準（怎樣算完成）

成功標準是最具體的「驗收條件」。如果蓋房子的成功標準是「三房兩廳、使用面積 120 坪」，那 Spec 的成功標準也同樣具體：

• 教學行數 >= 10000 行
• mermaid 圖 >= 60 張
• 8 章全部完成
• 可產出 HTML + PDF

段落 8：開放問題（還沒決定的事）

有些事情在 Spec 階段還無法確定 — 就像蓋房子時，你可能還沒決定要什麼顏色的磁磚。開放問題段落會列出這些待決事項，留到後續解決。

段落 9：風險評估（可能出什麼問題）

風險評估列出了可能出錯的地方，以及對應的因應措施。例如：

蓋房子的比喻：颱風可能延誤工期（風險），所以我們預留了兩週的緩衝時間（因應措施）。

Spec 的命名慣例和存放位置

所有 Spec 文件都存放在固定位置，命名也有嚴格的規範。這就像公司的合約檔案 — 每份合約都有固定的編號和存放位置，方便日後查找。

檔案命名格式：

1docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md

其中：

• YYYY-MM-DD — 日期，確保按時間排序
• <topic> — 主題描述，用連字號分隔
• -design.md — 固定後綴，表示這是設計規格

真實案例：

注意到規律了嗎？每個重要任務都有對應的 Spec 文件。三個月後，你想知道「Layer 24 是怎麼設計的？」只要去 docs/superpowers/specs/ 目錄裡找 codex-image 相關的 Spec 即可。

這些 Spec 加起來就構成了系統的「設計歷史」(design history; 設計歷史)。就像一棟大樓的所有設計圖紙都歸檔在建築事務所裡，每次修改都有紀錄。

Spec 和 Plan 的關係：

flowchart LR
    BRAIN["Brainstorming\n完成"] --> WRITE["撰寫 Spec"]
    WRITE --> SAVE["存檔至\ndocs/superpowers/specs/\nYYYY-MM-DD-topic-design.md"]
    SAVE --> REVIEW["送交 Review\n（下一步）"]

Spec 和 Plan 永遠是成對出現的：

1docs/superpowers/
2├── specs/
3│   ├── 2026-06-30-bd-tutorial-design.md          ← Spec（設計藍圖）
4│   └── 2026-06-30-sync-v1-to-clean-design.md
5└── plans/
6    ├── 2026-06-30-bd-tutorial-plan.md             ← Plan（施工排程）
7    ├── 2026-06-30-bd-tutorial-execution.md        ← 施工日誌
8    ├── 2026-06-30-sync-v1-to-clean-plan.md
9    └── 2026-06-30-sync-v1-to-clean-execution.md

Spec 回答「做什麼」和「為什麼」，Plan 回答「怎麼做」和「誰來做」。 它們之間用 Spec 路徑互相引用：Plan 的開頭會寫 **Spec:** docs/superpowers/specs/2026-06-30-bd-tutorial-design.md，這樣任何人讀 Plan 時都能回溯到原始設計。

Spec 作為「單一事實來源」

在企業環境中，一個常見的問題是：不同的人對同一件事有不同的理解。BD 主管以為要做 3 頁的摘要，Claude 以為要做 30 頁的完整報告，結果兩邊都不滿意。

Spec 解決這個問題的方式就是成為「單一事實來源」(single source of truth; 單一事實來源)。 所有的決定都白紙黑字寫在 Spec 裡。如果有任何爭議，打開 Spec 看一眼就知道當初決定了什麼。

這就像商業合約 — 合約簽了之後，雙方都按合約行事。如果一方說「我以為我們說好的是 X」，另一方可以打開合約說「合約第 3 條寫的是 Y」。

在 AIKT 的世界裡：

• Brainstorming 是「口頭討論」
• Spec 是「正式合約」
• Plan 是「施工排程」（合約的附件）
• execution.md 是「履約紀錄」

如果 Brainstorming 討論的內容沒有被寫進 Spec，那它就「不存在」。 這聽起來很嚴格，但實際上是在保護你 — 確保所有重要決定都有文字紀錄，不依賴任何人的記憶。

如何閱讀一份 Spec？（BD 人員速讀指南）

作為 BD 人員，你不需要讀懂 Spec 的每一行。以下是你應該重點關注的部分：

BioGenesis 案例：Alice 收到 AACR 參會素材的 Spec 後，重點檢查了三個地方：(1) 範圍確認包含 3 家公司的盡調、(2) 成功標準確認包含 PDF 輸出、(3) 風險評估確認有「公司資料過時」的應對方案。其他技術細節她交給 Claude 處理。這就是 BD 人員讀 Spec 的正確方式。

4.5.4 Step 3: Review (審核) — 請另一個 AI 來檢查

這一步的目的：用「新鮮的眼睛」檢查 Spec 的正確性、完整性和一致性。就像學術論文的 peer review (同行審查; 同行審查)，寫論文的人不能自己審查自己的論文。

建築檢查員的重要性

想像一下：建築師畫好了藍圖，就直接開始蓋了。結果蓋到一半發現，藍圖上寫的樑柱間距太大，承重不夠。整棟樓要重新設計、部分拆除重建。

這就是為什麼每個國家都有 建築檢查員 (building inspector; 建築檢查員) 制度：在施工之前，必須有另一個專業人士檢查藍圖，確認結構安全、符合法規。

Superpowers 的 Review 就是 AI 世界的建築檢查。 而且它有一個特別聰明的設計：檢查你藍圖的不是畫藍圖的那個人，而是一個全新的 AI agent。

為什麼要用不同的 agent？原因跟人一樣 — 自己檢查自己的作品，很容易看不到自己的盲點。 寫了 3 小時的 Spec，你會覺得每一行都很合理。但一個「新鮮的眼睛」可能一眼就看到問題。

Review 的運作方式

Review 的流程如下：

flowchart TD
    SPEC["Spec 完成"] --> DISPATCH["派出 Review Agent\n（全新 AI）"]
    DISPATCH --> READ["Review Agent 閱讀\n整份 Spec"]
    READ --> CHECK["逐段檢查\n一致性/完整性/正確性"]
    CHECK --> REPORT["產出 Review 報告"]
    REPORT --> SEVERITY["標記嚴重度"]
    SEVERITY --> C["CRITICAL\n必須修正"]
    SEVERITY --> I["IMPORTANT\n應該修正"]
    SEVERITY --> M["MINOR\n可以之後修"]
    C --> FIX["修正 Spec"]
    I --> FIX
    FIX --> R2["第二輪 Review\n（驗證修正）"]
    R2 --> APPROVE["通過 → 進入 Plan"]
    M --> APPROVE

三個嚴重度等級

Review 報告會把發現的問題分成三個等級，就像醫院的檢傷分類 (triage; 檢傷分類)：

flowchart LR
    ISSUE["發現問題"] --> CRITICAL["CRITICAL 關鍵\n必須立即修正\n例：Layer 數量寫錯"]
    ISSUE --> IMPORTANT["IMPORTANT 重要\n應該盡快修正\n例：遺漏某個功能"]
    ISSUE --> MINOR["MINOR 次要\n可以延後修正\n例：措辭可改善"]

    CRITICAL --> ACTION1["修正 → 重新 Review"]
    IMPORTANT --> ACTION2["修正 → 繼續流程"]
    MINOR --> ACTION3["記錄 → 之後再處理"]

真實 Review 案例：這份教學的 Spec 被抓到了什麼？

讓我們看看這份教學的 Spec 在 Review 過程中被抓到了哪些問題。這是 真實發生的事，不是虛構案例：

第一輪 Review 發現 13 個問題：

你注意到了嗎？第一個 CRITICAL 問題就足以讓整份教學出錯 — 如果教學裡寫「系統有 23 層」，但實際上有 24 層，讀者安裝後會發現對不上。這種錯誤如果到了執行階段才發現，意味著所有已寫好的章節都要修改。

Review 在執行之前就抓到了這個問題，節省了大量的返工時間。

讓我們更詳細地看看 Review 報告長什麼樣子。一份典型的 Review 報告包含：

1. 執行摘要 — 一句話總結：「Spec 整體結構完整，但有 1 個 CRITICAL 和 4 個 IMPORTANT 問題需要修正」
2. 問題清單 — 每個問題的嚴重度、位置、描述、建議修正方式
3. 正面回饋 — Review 不只抓問題，也會肯定做得好的地方

一個 Review 問題的典型格式：

1[CRITICAL] §3.1 章節結構
2問題：Spec 提到「23 Layers」，但 v1 最新版已有 24 Layers（含 codex-image）。
3影響：教學內容會與實際系統不一致，讀者安裝後發現多一層。
4建議：將所有「23 Layers」更正為「24 Layers」，並補充 Layer 24 的描述。

注意這個格式有多清晰：問題是什麼 → 為什麼這是問題 → 應該怎麼修。Review Agent 不只是說「你寫錯了」，而是告訴你錯在哪、會造成什麼後果、以及怎麼修正。

多輪 Review

有時候第一輪 Review 發現了嚴重問題，修正後需要 第二輪 Review 來確認修正是否正確。這就像建築檢查員在你修改了結構圖之後，會再來看一次。

這份教學的 Spec 就經歷了兩輪 Review：

• R1（第一輪）：發現 13 個問題，其中 1 個 CRITICAL
• 修正：把 Layer 數量從 23 更正為 24，更新 kami 類型數量等
• R2（第二輪）：確認所有修正正確，通過審核

Review 的智慧 — 不只抓錯，更防禦未來的錯

好的 Review 不只是「找出錯誤」，而是「防止錯誤發生在更昂貴的階段」。

讓我們用數字來說明：

Review 的價值在於：它在「修正成本很低」的階段，攔截了「在後面會很昂貴」的問題。

想像一下：如果 Layer 數量的錯誤（23→24）不是在 Spec Review 階段被抓到，而是在整份教學寫完之後才發現，那意味著 8 個章節、10000 行文字裡所有提到 Layer 數量的地方都要修改。更糟的是，可能有些地方漏改了，造成教學內容前後矛盾。

Review 花了 5 分鐘，但省下了可能 2 小時的修改工作和潛在的品質問題。

BioGenesis 案例：Alice 的 AACR 參會素材 Spec 在 Review 時被發現：「目標公司 C 的 pipeline 資料來源已經過期（2024 年），需要更新為最新版本。」如果沒有 Review，盡調報告裡的 pipeline 數據就會是錯的 — 在 BD 會議上拿出過時數據，會嚴重影響專業形象。Review 就是防止這種尷尬的安全網。

4.5.5 Step 4: Plan (實作計畫) — 拆成一步一步的施工計畫

這一步的目的：把 Spec 的設計轉化為具體的、可執行的、可追蹤的步驟清單。每個步驟都要清楚到「任何 AI agent 拿到就能直接做」的程度。

從藍圖到排程 — 設計和施工的區別

在繼續之前，讓我們先澄清一個概念：Spec 和 Plan 是不同的東西。

很多人第一次看到 Superpowers 流程時會問：「Spec 不就是 Plan 嗎？」不是。它們的關係就像建築設計圖和施工排程表的關係：

如果你只有 Spec 沒有 Plan，就像有了藍圖但沒人知道從哪開始蓋。

如果你只有 Plan 沒有 Spec，就像有了施工排程但不知道要蓋什麼。工人可能很有效率地蓋了一棟你不想要的房子。

兩者缺一不可。

施工排程表

設計藍圖通過了建築檢查員的審核。接下來呢？

建築師會把藍圖交給 工地主任 (construction manager; 工地主任)。工地主任不負責設計，他負責的是：把設計藍圖變成一步一步的施工排程。

施工排程表會回答以下問題：

1. 誰做什麼？ — 泥水匠砌牆、電工拉線、水管工裝管
2. 什麼順序？ — 先打地基，才能砌牆；先砌牆，才能拉線
3. 哪些可以同時做？ — 電工和水管工可以同時工作（在不同區域）
4. 每一步需要什麼材料？ — 砌牆需要磚頭和水泥，拉線需要電線和開關
5. 每一步怎樣算完成？ — 牆砌到 3 米高、線拉到每個房間的插座位置

Superpowers 的 Plan 就是這份施工排程表。 它把 Spec 的設計變成一步一步可執行的任務。

Plan 包含什麼？

一份標準的 Plan 包含以下內容：

開頭：

• 目標（一句話）
• 架構（幾個 phase、幾個 agent）
• 技術棧 (tech stack; 技術棧)（用什麼工具）
• Spec 路徑（指向設計藍圖）
• 全域限制 (global constraints; 全域限制)（所有 agent 都要遵守的規則）

主體：

• 每個 Task 的詳細步驟

讓我們看看真實 Plan 的結構 — 以同步兩個系統版本（v1_clean 同步）的 Plan 為例：

1Phase 1: 基礎設施同步（4 agents 並行）
2├── Agent A: CLAUDE.md + .gitignore
3├── Agent B: Skills 同步（3 新增 + 2 重大更新 + 6 微量更新）
4├── Agent C: Scripts 同步（5 新增 + 1 更新 + 版本依賴）
5└── Agent D: Tests 同步（2 目錄補入）
6
7Phase 2: 文件更新（2 agents 並行，Phase 1 完成後）
8├── Agent E: SETUP.md + Tutorials（3 新增 + 21 既有更新）
9└── Agent F: README x 2 + whitepaper + scenarios

flowchart TB
    subgraph P0["Phase 0: 準備"]
        T0["Task 0\n建立 Execution Journal"]
    end

    subgraph P1["Phase 1: 基礎設施（4 agents 並行）"]
        T1["Task 1\nAgent A\nCLAUDE.md"]
        T2["Task 2\nAgent B\nSkills 同步"]
        T3["Task 3\nAgent C\nScripts 同步"]
        T4["Task 4\nAgent D\nTests 同步"]
    end

    subgraph P2["Phase 2: 文件更新（2 agents 並行）"]
        T5["Task 5\nAgent E\nSETUP + Tutorials"]
        T6["Task 6\nAgent F\nREADME + Whitepaper"]
    end

    subgraph P3["Phase 3: 驗證"]
        T7["Task 7\n全局驗證"]
    end

    T0 --> P1
    P1 --> P2
    P2 --> P3

Phase 架構 — 同時出動多組工人

Plan 的一個關鍵設計是 Phase (階段; 階段) 架構。就像蓋房子時，泥水匠和電工可以在不同樓層同時工作，Plan 也會把不相依的任務安排在同一個 Phase 裡並行執行。

為什麼要並行？因為時間就是金錢。 如果 4 個 Task 各需要 15 分鐘，一個一個做需要 1 小時。但如果 4 個 agent 同時做，只需要 15 分鐘。

但並行有一個前提：任務之間不能有依賴關係。 例如：

• Agent B（Skills 同步）需要 CLAUDE.md 定義嗎？如果只是複製 SKILL.md 檔案，不需要 — 所以可以和 Agent A 並行。
• Agent E（Tutorials 更新）需要 Skills 同步完成嗎？需要 — 因為 tutorial 要引用 skill 的內容 — 所以 Agent E 必須等 Phase 1 完成後才能開始。

Plan 的 Phase 設計就是在回答這個問題：「哪些可以同時做？哪些必須按順序做？」

讓我們用一個表格來說明並行 (parallel; 並行) 和順序 (sequential; 順序) 的區別：

理解並行的關鍵就是一個問題：「這兩件事需要共享資訊嗎？」 如果不需要，就可以並行；如果需要，就必須安排先後順序。

在蓋房子的世界裡：

• 一樓的泥水匠和二樓的木工 → 可以同時做（不同區域）
• 砌牆和裝電線 → 必須先砌牆（電線要嵌進牆裡）
• 室內裝潢和外牆油漆 → 可以同時做（不同區域）
• 驗收和任何施工 → 必須等全部完工才能驗收

單一 Task 的內部結構

每個 Task 都有標準化的結構，就像每個施工隊的工作清單：

flowchart TD
    TASK["Task N: 任務名稱\nAgent X"] --> FILES["Files:\n要修改或建立的檔案清單"]
    FILES --> CONSUMES["Consumes:\n需要讀取的輸入"]
    CONSUMES --> PRODUCES["Produces:\n產出的結果"]
    PRODUCES --> STEP1["Step 1: 具體操作\n含指令範例"]
    STEP1 --> STEP2["Step 2: 具體操作"]
    STEP2 --> STEP3["Step 3: 具體操作"]
    STEP3 --> VERIFY["驗證步驟\n確認結果正確"]
    VERIFY --> UPDATE["更新 execution.md\n記錄問題/解決/狀況/下一步"]

讓我們看一個真實的 Task 範例（簡化版）：

 1### Task 1: CLAUDE.md + .gitignore（Agent A）
 2
 3Files:
 4- Modify: $CLEAN/CLAUDE.md
 5- Modify: $CLEAN/.gitignore
 6
 7Consumes: v1 CLAUDE.md 中 Layer 14/22/23/24 段落
 8Produces: 更新後的 clean CLAUDE.md（24 Layers）+ .gitignore
 9
10- [ ] Step 1: 讀取 v1 CLAUDE.md 中需同步的段落
11    grep -n "^### Layer 14" "$V1/CLAUDE.md"
12
13- [ ] Step 2: 更新 clean CLAUDE.md — Layer 14 deprecation
14    將 Layer 14 段落替換為 DEPRECATED 版本
15
16- [ ] Step 3: 新增 Layer 22/23/24 段落
17    從 v1 複製對應段落到 clean
18
19- [ ] Step 4: 更新 Cross-Layer 分流規則
20    加入新的 routing 規則
21
22- [ ] Step 5: 驗證
23    grep 確認所有 Layer 存在、數量正確

注意幾個重點：

1. 每個 Step 都有具體的操作指令 — 不是「更新 CLAUDE.md」這種模糊說法，而是「從 v1 複製 Layer 22 段落到 clean 的 Layer 20 之後」
2. 每個 Step 都有驗證步驟 — 不是「做完就好」，而是「做完後用 grep 確認結果正確」
3. Checkbox 語法 — - [ ] 表示待辦，- [x] 表示完成，方便追蹤進度

Global Constraints — 所有人都要遵守的規則

Plan 的開頭會列出一組 Global Constraints (全域限制; 全域限制)。這些是所有 Agent 在執行任務時都必須遵守的規則，就像工地的安全守則 — 每個工人進工地都要戴安全帽，不管你是泥水匠還是電工。

來看一個真實案例的 Global Constraints（來自 v1_clean 同步的 Plan）：

 1## Global Constraints
 2
 3- V1 路徑：$V1
 4- CLEAN 路徑：$CLEAN
 5- Layer 21 跳過不搬、不重新編號
 6- Layer 14 meeting-intel deprecate → Layer 22 company-intel
 7- 不搬：blog-publish / sync-v1-to-clean / .env / .mcp.json / inbox / projects
 8- 信任 v1 SKILL.md 直接搬，不另做 sanitize
 9- Rollback：從 v1_clean_backup_20260630/ 完整還原
10- 每個 task 完成後必須更新 execution.md

注意這些限制有多具體：

• 「Layer 21 跳過不搬」 — 使用者在 Brainstorming 時明確說不要 blog-publish，這裡確保每個 Agent 都知道這件事
• 「不搬：.env / .mcp.json」 — 防止 Agent 不小心把含有密碼的環境變數檔案複製過去
• 「每個 task 完成後必須更新 execution.md」 — 確保施工日誌不會被遺忘

Global Constraints 就像蓋房子時的「不可動搖的規則」：安全帽必須戴、工地門禁必須刷卡、承重牆絕對不能打洞。每個 Agent 在開始工作前都會先讀這些限制，確保不會踩到紅線。

Plan 也要 Review！

沒錯，Plan 本身也需要經過 Review。就像施工排程表也需要工程監督確認：

• 排程是否合理？（會不會有任務遺漏）
• 依賴關係是否正確？（會不會某個 Phase 缺了前置條件）
• 資源分配是否適當？（會不會某個 agent 分到太多任務）

Plan Review 的流程跟 Spec Review 一樣：dispatch 一個新的 AI agent 來檢查，產出 Review 報告，修正後確認通過。

你在 Plan 階段需要做什麼？

作為 BD 人員，你在 Plan 階段的角色跟 Spec 階段類似 — 你不需要理解每個技術細節，但你需要確認大方向正確。

你需要關注的重點：

當 Claude 把 Plan 拿給你看時，你可以：

1. 同意：「OK，按這個執行。」
2. 修改：「T3 和 T4 可以合併，不需要兩個 Agent。」
3. 追加需求：「Plan 裡沒有提到要打包成 zip，請加上。」
4. 拒絕：「這個 Plan 太複雜了，我想要簡單版。」

重點是：Plan 必須得到你的同意才能開始執行。 這是 Superpowers 流程中的一個重要安全閘門 — Claude 不會自作主張開始施工。

Plan 的檔案位置

所有 Plan 文件都存放在：

1docs/superpowers/plans/YYYY-MM-DD-<topic>-plan.md

例如：

• 2026-06-30-bd-tutorial-plan.md — 這份教學的 Plan
• 2026-06-30-sync-v1-to-clean-24layers-plan.md — 系統同步的 Plan

BioGenesis 案例：Alice 的 AACR 參會素材 Plan 可能長這樣：

 1Phase 1: 資料收集（3 agents 並行）
 2├── Agent A: dd: TargetCo-1 → 盡調報告
 3├── Agent B: dd: TargetCo-2 → 盡調報告
 4└── Agent C: dd: TargetCo-3 → 盡調報告
 5
 6Phase 2: 素材製作（3 agents 並行，Phase 1 完成後）
 7├── Agent D: kami 一頁式摘要 x 3
 8├── Agent E: kami slides x 1（含 3 家比較）
 9└── Agent F: quarkdown 談判重點 HTML
10
11Phase 3: 整合驗證
12└── Agent G: 全局驗證 + 打包

注意 Phase 1 的三個盡調可以同時做（因為互不相依），但 Phase 2 必須等 Phase 1 完成（因為 slides 需要引用盡調結果）。

4.5.6 Step 5: Execution + execution.md — 施工 + 施工日誌

這一步的目的：按 Plan 的步驟執行任務，同時用 execution.md 記錄全程，確保過程可追蹤、問題可回溯、進度可掌握。

execution.md — 被低估的英雄

如果要問 Superpowers 五個步驟中哪一個最容易被忽略，答案一定是 execution.md。

很多人覺得：「計畫做好了，執行就好了，幹嘛還要寫日誌？」

這就像很多建設工地不認真寫施工日誌，結果：

• 水管在哪個牆壁裡面？不知道。
• 為什麼用了 A 牌水泥而不是 B 牌？不記得了。
• 上週四地基有沒有做防水？沒人寫。

然後三年後房子漏水了，要修理的時候沒人知道管線在哪。

execution.md 就是為了防止這種「我以為記得但其實記不得」的情況。

每天都要寫的施工日誌

施工開始了。工地主任每天早上到工地，第一件事是打開 施工日誌 (construction log; 施工日誌)。

施工日誌不是什麼華麗的文件。它就是一本很樸素的筆記本，每天記錄四件事：

1. 問題 — 今天碰到了什麼問題？（例：水泥送錯型號）
2. 解決 — 怎麼解決的？（例：退貨換正確型號，延遲半天）
3. 狀況 — 目前進度到哪？（例：一樓牆面完成 80%）
4. 下一步 — 明天要做什麼？（例：完成一樓牆面，開始二樓地基）

execution.md 就是 AI 任務的施工日誌。 它在任務開始「之前」就建立好，每個 Task 完成後都會更新，記錄過程中的問題、解決方案和進度。

execution.md 的結構

讓我們看一份真實的 execution.md — 這是 v1_clean 同步任務的施工日誌（摘自 docs/superpowers/plans/2026-06-30-sync-v1-to-clean-24layers-execution.md）：

狀態總覽（所有任務一目了然）：

狀態圖示的意思：

• ⬜ = 尚未開始
• 🔄 = 進行中
• ✅ = 已完成
• ❌ = 失敗（需要處理）

每個 Task 的詳細紀錄：

 1## T3 — Scripts 同步 (Agent C)
 2### 問題
 3- codex-image.sh 沒有 setup subcommand
 4- kami_to_pptx.py line 26 含 hardcoded 路徑
 5
 6### 解決
 7- codex-image.sh：無需修改，script 自帶 error handling
 8- kami_to_pptx.py hardcoded path：記錄但不修改（使用者執行時以 CLI 參數覆蓋）
 9
10### 狀況
11- 5 new scripts copied
12- confidentiality/ directory created with 4 files
13- All 10 files size-verified: v1 vs clean MATCH
14
15### 下一步
16- T3 完成，等待 T7 全局驗證

flowchart TD
    CREATE["任務開始前\n建立 execution.md\n（空白模板）"] --> START["Task 開始\n狀態更新為 🔄"]
    START --> WORK["Agent 執行 Task\n按 Plan 的步驟"]
    WORK --> PROBLEMS{"過程中\n有問題嗎？"}
    PROBLEMS -->|"有"| RECORD["記錄問題\n+ 解決方案"]
    PROBLEMS -->|"沒有"| NOPROB["記錄\n問題: 無"]
    RECORD --> STATUS["更新狀況\n（做了什麼、驗證結果）"]
    NOPROB --> STATUS
    STATUS --> NEXT["填寫下一步\n（接下來做什麼）"]
    NEXT --> DONE["狀態更新為 ✅"]
    DONE --> NEXTTASK["下一個 Task\n或全局驗證"]

為什麼 execution.md 這麼重要？

你可能會想：「只是做個記錄而已，有必要這麼認真嗎？」

讓我們用三個理由說明為什麼 execution.md 是 Superpowers 的核心文件之一：

理由 1：防止資訊遺失（記憶傳承）

AI 任務可能需要多個 session (工作階段; 工作階段) 才能完成。每次開新 session，AI 對之前做了什麼是「一片空白」的。execution.md 就是 AI 的「記憶外掛」— 新 session 開始時讀一下 execution.md，就知道之前做到哪、遇到了什麼問題。

這就像醫院的病歷 (medical record; 病歷)。每次換班的護理師不需要重新問病人「你哪裡不舒服？」，只要翻開病歷就知道前一班做了什麼治療、用了什麼藥、病人對什麼過敏。

在 AIKT 的實戰中，research-pipeline-v2（Layer 18）的一次完整研究可能需要 6 個 session、跨越 30 小時。沒有 execution.md，每個新 session 都要從頭理解狀況。有了 execution.md，新 session 開頭花 2 分鐘讀完紀錄，就能無縫接續。

理由 2：可追溯的決策紀錄（為什麼這樣做）

三個月後，有人問：「為什麼 codex-image.sh 沒有 setup subcommand？」你翻開 execution.md，上面清楚寫著：「因為 script 自帶 error handling，無需額外 setup。」不用猜測、不用回憶。

這在企業環境中特別重要。當團隊成員離職或調動時，接手的人可以透過 execution.md 理解每個決策的脈絡。為什麼選了 A 方案而不是 B 方案？因為 execution.md 記錄了：「B 方案在 Step 3 失敗，因為 X 原因，改用 A 方案。」

理由 3：品質監控（即時掌握狀況）

通過 execution.md 的狀態總覽，你可以一眼看到：

• 哪些任務完成了（✅）
• 哪些還在進行中（🔄）
• 哪些失敗了（❌）

如果看到某個 Task 的「問題」欄寫了一堆、「解決」欄寫了一堆奇怪的 workaround，那就是一個 品質警訊 — 可能需要回頭檢查那個部分。

理由 4：團隊溝通的共同語言

當你需要向主管匯報進度時，不需要自己彙整。直接把 execution.md 的狀態總覽拿出來：

「目前 7 個 Task 中，4 個已完成、2 個進行中、1 個尚未開始。預計今天下午全部完成。T3 過程中發現一個問題（hardcoded path），已決定暫不修改，記錄在案。」

這比「差不多快好了」清楚一百倍。

Workflow 並行執行

讓我們看看在 execution 階段，多個 agent 是怎麼並行工作的：

flowchart TB
    ORCH["Orchestrator\n（指揮中心）"] --> |"Phase 1\n同時派出"| A1["Agent A\nCLAUDE.md"]
    ORCH --> |"Phase 1\n同時派出"| A2["Agent B\nSkills"]
    ORCH --> |"Phase 1\n同時派出"| A3["Agent C\nScripts"]
    ORCH --> |"Phase 1\n同時派出"| A4["Agent D\nTests"]

    A1 --> BARRIER1["Phase 1 完成\n全部 ✅ 才繼續"]
    A2 --> BARRIER1
    A3 --> BARRIER1
    A4 --> BARRIER1

    BARRIER1 --> |"Phase 2\n同時派出"| A5["Agent E\nTutorials"]
    BARRIER1 --> |"Phase 2\n同時派出"| A6["Agent F\nREADME"]

    A5 --> BARRIER2["Phase 2 完成"]
    A6 --> BARRIER2

    BARRIER2 --> A7["全局驗證\n最終檢查"]
    A7 --> SHIP["交付成果"]

這個流程有幾個關鍵設計：

1. Orchestrator (指揮中心; 指揮中心)

Orchestrator 就像工地的總指揮。他不自己砌牆、不自己拉線 — 他負責的是「派人」和「監工」。在 AIKT 中，Orchestrator 是 Claude 的主 session，負責：

• 讀取 Plan，了解有多少個 Task 和 Phase
• 建立 execution.md
• 依序啟動每個 Phase 的 Agent
• 監控每個 Agent 的完成狀態
• 在 Phase 之間做 Barrier 檢查

2. Barrier (屏障; 屏障)

Barrier 是一個「等待點」。就像建築工地規定「地基完成前，不准開始砌牆」，Barrier 確保前一個 Phase 的所有 Task 都完成後，才啟動下一個 Phase。

為什麼需要 Barrier？因為有些 Task 需要前置 Task 的輸出。例如，Tutorial 更新（Phase 2）需要引用 Skill 更新的結果（Phase 1）。如果 Skill 還沒更新完就開始寫 Tutorial，Tutorial 裡的引用可能是錯的。

3. Agent 獨立性

每個 Agent 是一個獨立的 AI session，只負責自己的 Task，不干擾其他 Agent。就像每組工人有自己的工作區域、自己的工具、自己的材料清單。Agent A 在更新 CLAUDE.md 的時候，不會去碰 Agent B 正在處理的 Skills 檔案。

4. execution.md 作為共享狀態

雖然 Agent 之間不直接溝通，但他們透過 execution.md 分享進度資訊。每個 Agent 完成後更新自己的段落，Orchestrator 就能透過讀取 execution.md 知道整體狀態。

這就像工地的白板 — 每個施工隊完成工作後在白板上打勾，工地主任看白板就知道進度。

當事情出錯的時候

不是所有任務都會順利完成。當某個 Task 失敗時，系統會怎麼處理？

flowchart TD
    FAIL["Task 失敗"] --> ASSESS["評估嚴重度"]
    ASSESS -->|"輕微\n例：格式問題"| RETRY["自動重試\n修正後繼續"]
    ASSESS -->|"中等\n例：資料不完整"| ROLLBACK["回滾到上一步\n重新執行"]
    ASSESS -->|"嚴重\n例：整個方向錯誤"| HUMAN["暫停\n通知使用者決定"]

    RETRY --> CONTINUE["繼續執行"]
    ROLLBACK --> CONTINUE
    HUMAN --> DECISION{"使用者決定"}
    DECISION -->|"修改 Plan"| REPLAN["修改後重新執行"]
    DECISION -->|"放棄此 Task"| SKIP["跳過，記錄原因"]
    DECISION -->|"全部取消"| CANCEL["從 backup 還原"]

    CONTINUE --> UPDATE["更新 execution.md\n記錄問題和解決"]
    REPLAN --> UPDATE
    SKIP --> UPDATE
    CANCEL --> UPDATE

關鍵設計：Rollback 計畫 (rollback plan; 回滾計畫)

還記得 Spec 裡有一個段落叫「Rollback 計畫」嗎？它就是為了這種情況設計的。

在真實案例中，v1_clean 同步任務的 Spec 寫明：

Rollback：從 v1_clean_backup_20260630/ 完整還原

這意味著，如果同步過程中出了嚴重問題，可以用備份直接恢復到原始狀態，不會造成永久性損害。就像蓋房子時，如果地基打歪了，可以推倒重來 — 但前提是你事先做好了備份。

Rollback 計畫通常有三個層級：

在實務中，大多數問題在 Task 層級就能解決。真正需要全局 Rollback 的情況非常罕見 — 因為 Brainstorming + Spec + Review 已經在執行前排除了方向性錯誤。

Rollback 就是你的安全網。你可能永遠用不到它，但知道它在那裡，你就能放心地讓 Agent 們大膽執行。

execution.md 的實際長相

為了讓你更具體地理解 execution.md，讓我們看看一個完整 Task 的紀錄長什麼樣子（來自 v1_clean 同步的真實 execution.md）：

 1## T1 — CLAUDE.md + .gitignore (Agent A)
 2
 3### 問題
 4- clean CLAUDE.md 停留在 20 Layers，缺 Layer 14 deprecation + Layer 21-24
 5- clean 機密邊界缺 company-intel 規則
 6- clean Token 守則缺 agent-browser / codex-image 規則
 7- clean Cross-Layer 分流規則仍指向 meeting-intel 而非 company-intel
 8- clean .gitignore 缺 company-intel 與 codex_generated 排除
 9
10### 解決
11- Header 更新 20 → 24 Layers
12- 機密邊界追加 company-intel + apotek-pipeline-internal.md 規則
13- Layer 14 替換為 DEPRECATED → Layer 22 redirect
14- Layer 20 後追加 Layer 21-24 完整段落
15- Cross-Layer 分流規則整體替換為 v1 版本
16- Token 守則追加 4 行
17- .gitignore 追加 company-intel-*/ 和 codex_generated/
18
19### 狀況
20- CLAUDE.md: grep 驗證 Layer 21/22/23/24 全部存在
21- DEPRECATED 標記正確，24 個 Layer header 正確
22- .gitignore: grep 驗證 company-intel 和 codex_generated 條目存在
23
24### 下一步
25- T1 完成，等待 Phase 2（T5-T6）啟動