給 AI 讀的知識庫差在哪：動手前先寫測試題
人看得懂的 wiki，AI 還是可能答錯：它看到的是被切出來的幾段文字，看不到導覽、標題層級和前後文。所以動手建 RAG 之前，先寫一份測試題：每題附上答案和出處段落，並刻意放幾題文件答不了的。Azure 的 RAG 指南把這一步跟內容分析平行做；一項研究發現，只用 AI 生成的題目評估，會高估檢索表現 29 到 37 個百分點，所以要混入真實使用者的問題。知識庫小於約 500 頁時，也可以先不做 RAG，整份放進提示裡。
全部文章
第 7 頁，共 128 頁
知識庫怎麼建：個人筆記、團隊 wiki、AI 知識庫的四個共同問題
個人筆記、團隊 wiki、給 AI 用的知識庫，差在讀者是誰：未來的自己、同事、模型。三種都要回答收什麼、怎麼整理、怎麼找到、誰來維護。個人收藏的研究發現，「找」多半是找回自己看過的東西；企業 wiki 的研究則看到，負責整理或代寫的人一離開，內容就開始變亂、過時。
選筆記工具：Obsidian、Notion，與換工具時資料帶不帶得走
選筆記工具前先問五件事：檔案能不能用別的程式打開、連結改名會不會斷、搜尋、多裝置同步、離線能不能用。Obsidian 的筆記就是本機一個資料夾裡的 Markdown 檔，但區塊連結這類語法離開 Obsidian 就點不開，iPhone 上官方建議的同步方式也只有兩種。Notion 的資料庫好用，但匯出時只能帶走一個檢視、callout 會變成 HTML，匯出的東西也不能直接上傳回去還原。換工具之前，先匯出一次、用別的程式打開看看。
放哪裡：PARA、Johnny.Decimal，與到底要不要分資料夾
自己建的檔案，研究一再發現人主要靠點資料夾找回，搜尋工具變好也沒改變；標籤用的人很少，用了也多半只貼一個。所以筆記值得分類，但每則有一個主要的家就好，結構別太深、資料夾別太滿。PARA 依「離手上的事多近」分四類，Johnny.Decimal 每層最多十個、用編號固定位置；兩者的數字都是作者的經驗，不是實驗結果。
寫給同事看：how-to 模板、決策紀錄，與寫少一點
團隊文件要長得差不多、看得懂，靠的是兩份模板和一條原則。原則是寧可少而新鮮：Google 的文件指南說，少量但新鮮正確的文件，勝過大量年久失修的文件，別處有的就連過去。how-to 模板照「先決條件、步驟、怎麼確認成功、出問題找誰」排；一項研究裡，照模板改寫的安裝說明在讀者評分的十個面向中有八個較好。決策紀錄（ADR）記下當時為什麼這樣決定，推翻時不刪、標成「已被取代」並連到新決定。研究也看到 ADR 常常試了沒繼續、「考慮過的選項」那段問題最多，常常沒寫或寫錯地方，所以模板要短，那一段要留著。
資訊架構：團隊 wiki 要按部門分還是按任務分，以及怎麼驗證
團隊 wiki 常見的爭論是按部門分還是按任務分。研究的答案比想像中保守：熟悉組織圖的員工用按部門分的內網反而比較快，標籤取得好不好的影響也比分類方式大得多。比較穩的做法是：主結構選一個每頁都找得到負責人的分法，再加幾頁按任務整理的入口頁、只放連結；頁面標題寫讀者會搜的字。動手分之前用卡片分類找出讀者怎麼想，分完用樹狀測試驗證找不找得到。
維護責任：誰負責、多久確認一次、什麼時候刪
文件過時是常態，而且不會報錯。GitHub 最熱門的專案裡，八成曾在文件裡留下指向已刪除程式碼的引用。維護有四種做法：每頁掛一個負責的角色、設驗證到期、改流程時同一個變更裡改文件、在被用到的時候順手改。每一種都有失靈的方式：負責人離職、到期通知被當垃圾信、規定在但沒人照做、沒人用的文章永遠沒人檢查。刪除的原則是先刪確定錯的，正確但少用的封存。讀完你能替團隊訂一張維護規則表：文件類型、負責角色、確認週期、刪除條件。
找得到：用搜尋紀錄找出缺口，以及開始讀團隊文件的 AI
同事搜不到，多半不是沒寫：一間大學圖書館的 50 筆零結果查詢只有一成是真的沒有。用三到六個月的搜尋紀錄把缺口分成找不到、不存在、用詞不同，先改標題、設同義詞；給 AI 看的 AGENTS.md 也一樣要精簡、要維護、要先評估，一項評估發現它們整體沒提高成功率，成本卻增加約兩成。
團隊知識庫為什麼會爛掉，以及要寫哪幾種文件
團隊 wiki 會爛掉，研究看到的主要是三件事：缺漏和過時比寫錯更常被抱怨、寫的人沒時間或離職了、主管和實際寫的人要的東西不一樣。不是所有 wiki 都會爛：寫的人自己也是讀的人，或文件解決的是一個明確的問題時，比較撐得住。文件可以照 Diátaxis 分成四種：教學、操作指南、參考資料、說明，用兩個問題判斷一份文件該是哪一種，就能看出團隊缺哪一類。
維護：筆記怎麼不在三個月後荒廢，以及哪些事交給 LLM
排一個 30 分鐘的每週回顧：清收件匣、處理結束的專案、從一張 MOC 挑一個問題往下想。摘要不必排時間，碰到才加一層。LLM 可以幫你找重複、建議可能相關的筆記、把你先寫好的重點擴寫成句子；那一句自己的話、判斷什麼重要、刪不刪，留給自己。一項 30 人的研究比較三種 AI 協助，AI 直接給完整筆記的那組學得最少，也最少修改。
收什麼：收集不等於知識庫
決定一則資訊收不收，按順序問三句：說得出具體用途嗎、之後搜得回來嗎、寫得出一句自己的話嗎。說不出用途就不留；搜得回來的原文只留連結，搜不回來的存副本；寫得出那句話才進知識庫，寫不出就放進待讀清單。收件匣每週清空。背後的原因是：收不收有兩種錯，多收會把重要的東西淹沒，漏收之後要重找，只把門檻調鬆或調緊，只是把一種錯換成另一種。
怎麼連：Zettelkasten、Evergreen notes 與 MOC
讀完這篇，你能把一篇讀書摘要改寫成兩三則可以互相連結的筆記，並在筆記多起來時建一張地圖筆記（MOC）。做法歸成四個原則：一則筆記只講一個概念、依概念不依書寫、用自己的話寫、每條連結寫出為什麼連。這套做法源自 Luhmann 的卡片盒；研究支持「自己產生比只讀記得牢」，但我找不到可信的對照實驗測過 Zettelkasten 本身。
Cloudflare 模型家族：Clef 決策模型與 Clairic 抽取模型怎麼選
Cloudflare 自研模型分兩條線：Clef 家族輸出選項機率（clef 27B、clef-flash 9B、clef-omni 30B-A3B），Clairic 輸出型別化值與區間。四者只計 input token（$0.038–$0.24/1M）、不計 output；Clef 三個以 Apache-2.0 開源可自架，Clairic 仍是託管預覽。決策類基準贏 Jev，深推理類輸 Jev。
決策模型怎麼選：Jev、Decider、d1-ultra、mammoth-1 與其他十幾家
決策模型把一般 LLM 的「生成一段文字、你再自己解析」換成「你先把選項列好，模型直接回每個選項的機率」。TypeSafe 在 2026-09-15 提出 System One 之後，一個多月裡這類模型從一家變成十幾家：Jev 1.14、OpenAI Decisions API、Perplexity Decider v1.2、Microsoft-Decision-1、Liquid d1-ultra、Base Labs mammoth-1、vLLM d3、StartLux、Fastino GLiDE、Celeris-1 Decision、Inception Mercury Decide、Cloudflare Clef。兩張榜單給的答案幾乎相反——社群 Jev Decision Index 0.4.1 冠軍是 GLiDE V1.2（71.5），獨立 Artificial Analysis Decision Index 冠軍是 d1-ultra（65.2）、Jev 1.14 只有 57.1。決策模型贏在分類與工具選擇，輸在知識與推理，而且普遍過度自信。
Claude Code 團隊怎麼做 code review：七層檢查、風險分級與人力配置
Anthropic 說 Claude Code 約 90% 的程式碼由 Claude 撰寫。這篇導讀他們的審查流程：PR 先過七層檢查，人力依風險分 0／1／2 人，目標是每個變更最多一位真人，而且 revert 不增加。
看見 agent 在做什麼：用 stream-json 畫出執行軌跡｜Harvard CS2680 作業 1
CS2680 作業 1 要你做一個網頁來驅動 Claude Code：送出任務，即時看到 agent 讀了什麼、跑了什麼、結果如何，最後顯示花了多少錢、幾秒、幾輪。關鍵是讀懂 `claude -p --output-format stream-json --verbose` 的事件串流：tool_use 和 tool_result 靠同一個 id 配對，subagent 的事件靠 parent_tool_use_id 掛回呼叫它的那一步。這篇拆解七項要求、示範用 40 行 Python 把事件串成一棵樹並分辨成功與失敗，最後整理交件、評分與開發時最容易卡住的地方。
親手寫一個 coding agent harness：四個工具加一個 loop｜Harvard CS2680 作業 2
CS2680 作業 2（Mads-Loop）要你自己寫一個 coding agent harness：用指定的小模型 qwen3.6-35b-a3b，在 Docker 容器裡修 SWE-bench Pro 的真實 issue，並照規定格式記下每一步。作業頁明說它給的設計不要照單全收，10 題裡也有解不了的題。這篇整理規格、作業頁值得懷疑的幾處、harness 最常壞的五個地方與各自的處理方式（附一段實跑過的片段），以及怎麼自建四題評估集、怎麼判斷一題是不是真的解不了。不含官方解答。
在不掉分的前提下省錢省時間：成本優化競賽｜Harvard CS2680 作業 3
CS2680 作業 3（Mads-Opt）是一場 harness 競賽：同一批 SWE-bench Pro 題目，比誰解得多、每解一題花得少、每解一題等得短。三個指標不加權，改用 skyline（Pareto）分層排名：沒有人在三項都不比你差、還至少一項比你好，你就是第 1 名。這篇整理作業的容器架構與硬限制、排名與計分怎麼算（附手算例子），用作業頁公布的模型價格先算一題大概花多少，再把第 8 堂的成本與速度槓桿對到這份作業。不含官方解答，也不談具體解法。
現代 AI 系統：從用 agent 到優化 agent 的學習路線｜Harvard CS2680 課程總覽
Harvard CS2680 拿同一個 coding agent 當主角，從上往下拆：先用 Claude Code 看 agent 怎麼跑，再自己寫 loop、選工具、管 context，接著擴成多 agent、加上記憶、學會評估，最後把成本和延遲壓下來；下半學期再往下自己 serve 模型。這篇整理 Part I 八堂與三份作業各在學什麼，用一個手算例子說明為什麼 agent 每多走一步就更貴，最後給先備檢查與閱讀順序。
Agent 是系統問題：從單次推論到一串工具呼叫｜Harvard CS2680 第 1 堂
CS2680 第 1 堂（2026-09-02）先說明 AI 系統和傳統系統的差別：運算分散在 CPU 與 GPU、浮點運算不保證每次一樣、狀態大到要跨 GPU 搬。接著把 agent 比作新型電腦（LLM 是 CPU、context window 是記憶體、harness 是作業系統），指出 agent 的一個請求會變成「推論 → 工具 → 推論」的長鏈，所以每秒 token 數是錯的目標，要看任務成功率、端到端延遲與每次成功的花費。本文用兩個 agent 的帳算一次這些指標怎麼用。