010. 本週雷達｜五個專案，其實在補同一套 Agent stack
這支七分半的「GitHub 一週熱點 117 期」一次介紹五個看似分散的專案：Open Design、Headroom、Taste Skill、English-level-up-tips，以及 AI Engineering from Scratch。若只把它看成熱門 repository 清單，很容易讀完、按星，然後再也沒有打開；更值得注意的是，這五個專案剛好落在 Agent 工作流的不同層次。
Open Design 想處理的是「Agent 要如何穩定產出可交付的視覺成品」；Headroom 處理「大量工具輸出進入模型前，怎麼減少 Context 浪費」；Taste Skill 處理「生成介面為什麼總有模板感，以及視覺規則能否被打包重用」；最後兩個學習型 repository 則把焦點拉回人：當工具快速演進，人要如何建立語言能力與 AI 工程的長期學習路徑。
這四層可以粗略寫成：
- Learning：人如何建立能判斷、能實作的基礎能力。
- Context：Agent 在有限的上下文與成本裡，讀到什麼、捨棄什麼。
- Taste：輸出要服從哪些風格、版面、互動與品質約束。
- Design：最後如何組成可預覽、可匯出、可交接的成品。
這也反映出 2026 年 Agent 工具的競爭方向正在改變。模型能力仍重要，但開發者日常遇到的摩擦，往往已經不是「模型會不會寫」，而是 Context 太肥、結果不一致、視覺太普通、產物無法交接，或團隊不知道該怎麼系統性學會。於是，模型外圍開始出現一層又一層的能力基礎設施。
不過，熱門不等於適用。以下所有 GitHub star 數、節省比例與課程規模，都是截至 2026 年 6 月 6 日的頁面資訊或專案方自述。它們適合拿來判斷「值得花時間研究嗎」，不適合直接當成 production 採用證明。
021. Open Design｜設計從畫布操作變成 Agent 可呼叫的能力
Open Design 把自己定位為 local-first、open-source 的 Claude Design 替代方案，也稱自己是「Agent 時代的 Figma alternative」。它最關鍵的主張，不是再做一套拖拉元件的畫布，而是把設計流程拆成 Agent 已經能讀取的檔案與協定。
在這套架構裡，SKILL.md 描述工作方式與設計任務，DESIGN.md 承載品牌與視覺系統，plugins 封裝可執行流程，MCP 則讓 Claude Code、Codex、Cursor、OpenClaw 等工具接進來。使用者提供 brief，Agent 讀取所選 skill 與 design system，生成真實 HTML/CSS、簡報、圖片或動態內容，再放進 sandbox preview 檢查。
截至文章整理時，它的 README 列出 100+ skills、150 個 design systems 與 261 個 plugins，支援 21 種本機 CLI，並可輸出 HTML、PDF、PPTX、MP4 等格式。0.9.0 版也加入內建 Model Router，讓使用者可以登入後直接開始，或選擇 BYOK 連接 OpenAI、Anthropic、Gemini、Ollama 及其他相容端點。專案採 Apache-2.0 授權。
真正值得看的不是數量，而是它對「設計工具」的重新切割。傳統設計工具的核心資產是畫布裡的節點；Open Design 的核心資產是可以被版本控制、組合與發佈的 skills、design systems 和 plugins。當品牌規範變成 DESIGN.md，設計流程變成 SKILL.md，它們就能進 Git、做 code review、被 Agent 呼叫，也能在不同工具之間搬移。
這對小團隊尤其有吸引力。製作 landing page、活動頁、內部 dashboard、簡報或社群素材時，最耗時間的常常不是第一版，而是維持品牌一致、反覆修正和把視覺稿交給工程。若輸出本身就是 HTML/CSS，設計與實作之間的距離確實可能縮短。
但「Agent 原生」不等於「自動得到好設計」。Open Design 綁定的是一套生成與交付機制，最後品質仍取決於 brief、design system、skill、模型能力及人工 critique。對既有設計系統成熟的團隊，導入前還要驗證 token、元件、字型、responsive 行為是否真的能被保留；對涉及客戶素材的工作，也應先檢查 local-first 的實際資料流、外部模型端點與權限邊界。
最合理的試法不是立刻把整個設計流程搬過去，而是選一個低風險成品，例如單頁活動頁或內部週報簡報。保留原本製作時間與品質 baseline，再比較「從 brief 到可交付檔案」究竟省了多少輪溝通。
032. Headroom｜當 Context 成為成本，壓縮層就會出現
Agent 會讀檔、跑測試、查 log、呼叫 MCP、搜尋 repository，也會把每次結果持續塞進 Context。工具越多，Agent 看似知道得越多，但其中可能充滿重複 JSON、過長 stack trace、無關欄位、重複檔案內容與早已過時的歷史訊息。模型最後消耗的 token，並不等於真正有用的資訊量。
Headroom 就是在這個位置插入一個壓縮層。它會在內容送進 LLM 前，先辨識輸入類型，再依 JSON、程式碼或一般文字採用不同壓縮方式。專案提供 Python、TypeScript library、HTTP proxy、Agent wrapper 與 MCP server，也設計了可逆取回機制：精簡內容先進模型，原始內容保留在本地 store，模型需要細節時再透過 retrieval 工具取回。
README 的醒目主張是「減少 60–95% tokens，維持相同答案」。這個數字需要帶著正確的閱讀方式：它是專案方對特定內容與評測的描述，不代表每一種任務都能得到相同比例。若輸入原本就是短小、高密度的程式碼，壓縮空間有限；若任務依賴精確行號、完整錯誤上下文或極小的語意差異，過度壓縮反而可能讓模型失去關鍵線索。
Headroom 值得關注的地方，在於它把 Context engineering 從 prompt 技巧變成一個可以觀測與替換的系統層。過去大家常用「請只回傳摘要」「不要輸出多餘內容」減少 token，但這種約束散落在 prompt 與工具裡，很難統一評估。當壓縮被放到 proxy、middleware 或 MCP，團隊就能集中看壓縮率、品質變化、失敗案例和成本。
對長時間運作的 coding Agent、RAG 系統或多 Agent workflow，這個方向尤其合理。Context 不只是帳單問題，也會影響注意力分配：無關內容越多，模型越容易被舊資訊或表面相似的片段干擾。好的壓縮不只是刪字，而是保留任務需要的結構與可追溯性。
導入時，最重要的不是先看節省比例，而是建立自己的 benchmark。可以挑 20 個真實任務，分成 log 除錯、程式碼理解、RAG 問答與工具呼叫四類，同時跑原始 Context 與壓縮 Context，比較答案正確率、完成時間、token、retrieval 次數及失敗模式。若只看 token 降低，卻沒追蹤答案品質，省下的成本可能最後變成更多重試與人工修正。
此外，任何位於 prompt 與模型之間的 middleware 都是新的信任邊界。團隊需要理解它讀取什麼、保存什麼、資料放在哪裡，以及更新後壓縮策略是否改變。Headroom 強調 local-first 與可逆，但 production 採用仍應鎖版本、保留原始紀錄，並讓高風險任務可以繞過壓縮。
043. Taste Skill｜品味能否被寫進 SKILL.md？
使用 AI 生成前端，常會遇到一種很難只靠 bug report 說明的失敗：功能都有，畫面也沒有壞，但就是像套版。版面總是置中 hero、三張卡片、藍紫色光暈、圓角按鈕；字級、留白、資訊密度和動效都沒有明確意圖。它不是「不能用」，而是缺乏區辨度。
Taste Skill 嘗試把這種模糊問題改寫成 Agent 可執行的設計約束。它是一組可攜的 Agent Skills，涵蓋一般 frontend taste、image-to-code、既有介面 redesign、minimalist、industrial brutalist、高階柔和視覺，以及 image-generation reference board。使用者可以透過 npx skills add 安裝，也能直接把某個 SKILL.md 放進專案。
其中最具代表性的設計，是三個 0–10 的旋鈕：DESIGN_VARIANCE、MOTION_INTENSITY、VISUAL_DENSITY。它們沒有假裝把美感變成客觀分數，而是提供共同語言，讓人可以說「這一版需要更高的版面變化，但降低動效、維持中等資訊密度」，而不是只說「再有設計感一點」。
這說明品味至少有一部分可以被操作化。排版比例、字級層級、留白、重複模式、動畫使用時機、元件密度、對齊方式，都能寫成規則與 pre-flight checklist。這些規則不會讓模型變成真正的設計師，但能降低最常見的平庸輸出，也能讓同一團隊的多個 Agent 比較一致。
問題在於，設計規則很容易從「避免預設答案」變成「新的預設答案」。如果所有專案都套同一套 taste skill，最後可能只是從藍紫漸層換成另一種流行風格。介面是否有效，仍要回到產品情境、內容、品牌、無障礙、效能與使用者行為。高 variance 不是天然較好，重動畫也不一定較高級。
因此 Taste Skill 適合被當成 critique 與約束工具，而不是審美真理。最好的試驗方式，是拿團隊已經完成、且有明確設計意圖的一頁，讓 Agent 先做 redesign audit，再比較它指出的問題是否真的成立。若規則與現有 design system 衝突，應修改 skill，而不是讓產品去迎合 skill。
054. 兩種學習型 Repository｜一個練語言，一個練 AI 工程
本期後兩個專案都不是狹義的工具，而是「把學習路徑做成 repository」。它們的共同價值，是把分散的知識整理成可導航、可持續更新、能留下產出的結構。
English-level-up-tips 從 2017 年開始維護，內容涵蓋理解、詞彙、聽力、閱讀、口說與寫作。2026 年更新的 AI 章節，不只提供零散 prompt，而是討論如何把 Gemini 的 Gem、Live、Guided Learning、Canvas、quiz、flashcards 串成學習流程，也說明 ChatGPT、Claude、Perplexity 與 DeepL Write 可以如何分工。
這份指南真正耐用的地方，是它沒有把英語學習簡化成單一工具。語言能力仍然來自輸入、輸出、回饋與長期累積；AI 的角色是提供高頻陪練、逐句修正、材料生成和個人化節奏。工具會換，但「建立訓練迴路」這個原則比較不容易過期。
AI Engineering from Scratch 則把範圍拉到 AI 工程。專案方規劃 20 phases、503 lessons、約 320 小時，橫跨 Python、TypeScript、Rust、Julia，從數學、ML、Deep Learning、Vision、NLP、Transformer、LLM，一路延伸到 tools、protocols、Agent、multi-agent、infrastructure、production 與 alignment。
它最有辨識度的設計，是每一課都遵循「理解問題、建立概念、自己實作、使用 production library、最後交付產物」的節奏。產物可能是 prompt、skill、Agent 或 MCP server。學習因此不只停在看懂，而是留下可測試、可重用、可放進 portfolio 的東西。
但 503 課與 320 小時也可能形成另一種焦慮。完整路線圖看起來很可靠，卻不代表每個人都應該從 Phase 0 線性走到 Phase 19。對已經在做產品的人，更合理的方法是先用它的 placement skill 找起點，或從眼前專案所缺的一層反向學習。需要除錯 Agent loop，就先讀 Agent Engineering；需要理解 embedding 與 retrieval，再補 NLP 與 Transformer，而不是為了「完整」停工半年。
兩套 repository 也都提醒一件事：AI 時代的學習資源不只可以被閱讀，也可以被 Agent 直接操作。課程能帶 placement skill、quiz skill、範例程式與 outputs；學習者可以要求 Agent 出題、檢查理解、安排複習或陪練。這讓教材從靜態文件變成互動環境，但也提高了另一項要求：學習者需要能辨認 Agent 給的回饋是否可信。
065. 怎麼選、怎麼試｜把熱門專案變成可回退的小實驗
這五個專案沒有誰是「最好」，因為它們解的不是同一個問題。選擇之前，可以先問目前最昂貴的摩擦在哪裡：
- 如果團隊從 brief 到視覺成品反覆來回，先看 Open Design。
- 如果 Agent 任務長、工具輸出多、token 與 Context 污染明顯，先測 Headroom。
- 如果前端能生成但總有模板感，先用 Taste Skill 做 audit 與單頁比較。
- 如果想建立長期英語訓練迴路，從 English-level-up-tips 選一個弱項章節。
- 如果會呼叫 API，卻對模型、Agent loop 或 production 基礎缺乏把握，從 AI Engineering from Scratch 選一個 phase 做小專案。
評估熱門開源專案時，一個簡單但有效的流程是：
- 選一個真實任務：不要只跑 README demo，要用團隊真的會遇到的資料與限制。
- 保留 baseline：記錄原本的品質、時間、token、人工步驟與失敗率。
- 限制試驗範圍：先單頁、單工作流、單類任務，不一次改造整條 production pipeline。
- 記錄失敗案例：成功 demo 很容易看，真正決定可用性的常是錯誤能否理解、回退與重現。
- 檢查維護邊界：授權、版本、外部服務、資料流、社群活性與升級策略都要納入。
GitHub star 是注意力訊號，不是架構審查、資安稽核或長期維護承諾。README 裡的數字也應被當成待驗證假設。Open Design 的模板數、Headroom 的 token reduction、Taste Skill 的「anti-slop」定位、學習課程的規模，都只能告訴我們專案想解什麼問題；能否進入自己的工作流，仍取決於實測。
把這期五個專案放在一起，最值得帶走的不是安裝指令，而是一張 Agent 工具鏈地圖：能力正在從模型內部往外拆，變成可版本控制的設計規範、可觀測的 Context 層、可攜的 taste rules，以及能由 Agent 參與的學習系統。未來真正有價值的工具，不一定是再做一個更大的聊天介面，而是讓某一種能力更容易被呼叫、檢查、重用和替換。
影片來源： IT咖啡館｜GitHub 一週熱點 117 期
專案連結：