AI Knowledge Archive

深度認知壓縮與架構解析精華

96
處理文章數
21
涵蓋分類數

🌟 今日領域總結 (Domain Summaries)

AI商業 領域

AI商業 總結報告

本期 AI 商業領域的 5 篇文章揭示了生成式 AI 進入深水區後的商業模式大洗牌。從「The Great Descent」到「Agents are the new SaaS」，我們看到單純販賣 Token 或底層模型能力的商業模式正在失效。企業客戶不再為「潛力」買單，而是為「工作完成度」付費。未來的商業核心不再是 SaaS（軟體即服務），而是 Service-as-a-Software（服務即軟體）——以 AI Agent 為載體，直接交付業務成果。這意味著 AI 新創必須從「提供工具」轉向「承包業務流程」，而傳統企業則面臨如何將 AI 勞動力融入現有營運架構的嚴峻挑戰。
核心主題 (Key Themes)
  • 商業模式演進：從賣 SaaS 到賣 Agentic Services：傳統 SaaS 是賣工具讓客戶自己動手，而新一代 AI 商業模式則是直接賣「數位勞動力」。
  • 營運架構重塑：AI Agents 作為一級業務實體：AI 不再只是輔助工具，而是實質參與營運的「虛擬員工」，這徹底改變了企業的組織設計。
Obsidian 開啟
AI工具 領域

AI工具 總結報告

本期 AI 工具領域的 3 篇文章聚焦於如何透過開源生態與平台功能升級，大幅釋放 AI 編程助手的生產力。我們觀察到一個明顯的趨勢：AI 工具正在從「單兵作戰的對話框」進化為「具備完整團隊能力的基礎設施」。Anthropic 開源的全套 Office Team 展現了官方對於 Agent 協作模式的推動；而各種圍繞 Claude Code 與 Codex 的周邊 Repo 則補齊了模型在本地端操作、程式碼解析與流程自動化上的短板。開發者不再需要從零打造輪子，而是將這些開源積木組裝成專屬的 AI 開發流水線。
核心主題 (Key Themes)
  • 開源生態填補了官方工具的最後一哩路：許多強大的 AI 能力往往受限於本地環境的隔離，開源社群正迅速填補這些空缺。
  • 官方推動的「Agent Team」標準化：單一強大模型的極限已現，多角色 Agent 協作成為了官方認可的最佳實踐。
Obsidian 開啟
AI工程 領域

AI工程 總結報告

本期 AI 工程領域共收錄高達 28 篇文章，呈現出極其強烈的「工程化與驗證焦慮」。文章高度集中於兩個核心議題：**LLM Evaluation（大型語言模型評估）**與 **RAG / 系統架構的最佳實踐**。產業正從「如何讓 LLM 產生酷炫的結果」轉變為「如何穩定、可預測且低成本地在生產環境運行 LLM」。作者群普遍認為，單一的準確率分數（Score）已失去意義，真正決定 AI 產品生死的是 Ground Truth 的品質、審查員的校準共識，以及詳細的評估日誌（Eval Log）能否直接轉化為工程修復行動。此外，Vibe Coding（憑直覺用語音或模糊文字寫程式）的熱潮正在退卻，規格驅動開發（SDD）強勢回歸。
核心主題 (Key Themes)
  • LLM Eval 的本質是產品契約，而非單純的測試：多篇文章共同顛覆了傳統對 LLM 評估的認知，強調評估體系本身就是一個產品資產。
  • 規格驅動開發（SDD）終結了 Vibe Coding 的浪漫：自然語言的模糊性在複雜的工程專案中成為了巨大的技術債來源。
  • RAG 與底層架構的解構與重建：開發者開始反思早期的粗放式架構，轉向更精細的語義處理與效能優化。
Obsidian 開啟
AI模型 領域

AI模型 總結報告

本期 AI 模型領域收錄 2 篇文章，聚焦於基礎模型（Foundation Models）在極致上下文長度與長程自主推理能力的最新突破。從支援超大上下文的 LongCat-2.0 到 Anthropic 的 Claude Fable 5，我們看到模型軍備競賽的焦點已從單純的「參數規模」轉移到「上下文利用率（Context Utilization）」與「Agentic 原生能力」。這些技術進展不僅打破了過去依賴複雜 RAG 架構來處理長文本的限制，更賦予了模型在沒有人類頻繁介入的情況下，自主規劃、除錯與執行複雜多步任務的能力。
核心主題 (Key Themes)
  • 超長上下文的暴力美學與實用落地：不再需要將檔案切碎，直接將整個 codebase 或大型知識庫塞進模型的時代已經來臨。
  • 模型原生的「Agentic」能力覺醒：新一代模型在訓練階段就已深度融合了工具調用與長時間反思的能力，使其不再只是一個問答引擎。
Obsidian 開啟
AI視野 領域

AI視野 總結報告

本期 AI 視野領域收錄 1 篇綜合早報，精煉地呈現了當前 AI 產業發展的三大關鍵維度：底層算力的國產化落地、開發者工具棧的本地化補齊，以及應用層面的方法論成型。這反映出 AI 技術正從「大廠秀肌肉的展示品」迅速下沉為「企業可實際部署的生產力基礎設施」。當萬億參數模型（如 LongCat）能夠在國產硬體上高效運行，且本地化 AI 工具鏈逐漸完備時，企業將不再受限於雲端 API 的隱私與成本枷鎖，從而引爆一波基於私有數據的深度 AI 應用浪潮。
核心主題 (Key Themes)
  • 算力與基礎設施的「在地化」與「去中心化」：依賴單一雲端巨頭的風險正在降低，本地部署成為企業級應用的新顯學。
  • 應用方法論的成熟：從「技術驅動」轉向「場景驅動」：業界不再盲目追逐新模型，而是開始沉澱可複製的商業應用模式。
Obsidian 開啟
Agent架構 領域

Agent架構 總結報告

本期 Agent 架構領域共收錄 25 篇文章，呈現出一個清晰的產業轉型脈絡：AI Agent 正從「單次對話式的 Chatbot」全面演進為「具備自主循環、跨時間編排與動態驗證能力的虛擬員工」。這波演進的核心驅動力是 **Loop Engineering（迴圈工程）** 的崛起——一套將 Agent 的執行從「人工逐步 Prompting」升級為「系統自動化的發現-計畫-執行-驗證閉環」的架構方法論。與此同時，Agent 的基礎設施層也在快速成熟，從 MCP (Model Context Protocol) 伺服器的五大架構模式、到 Specification 驅動開發 (SDD) 讓文件成為程式碼的事實來源、再到 Agentic RL（強化學習）為模型注入工具調用與多步推理的原生能力，整個技術堆疊正在從「玩具級 Demo」走向「企業級生產部署」。
核心主題 (Key Themes)
  • Loop Engineering 的架構分層：從 Harness 到 Control Plane：本期最密集的主題就是 Loop Engineering 的定義與實踐。多篇文章共同勾勒出一個清晰的架構分層：
  • Specification 驅動開發 (SDD)：文件成為 Agent 的執行協議：多篇文章揭示了一個深刻的典範轉移：在 AI Agent 時代，Spec 的身份發生了三重轉變——從靜態說明書變成**執行協議**、從一次性文檔變成**Living Document**（即時回饋的持久化狀態層）、從人類閱讀轉向**機器解析**（成為跨工具的 Agent 基礎設施層）。
  • MCP 伺服器架構模式化與 Agentic RL 的模型層突破：Agent 的基礎設施正在快速標準化。
  • 從「對話機器人」到「虛擬員工」的組織架構轉型：多篇文章從組織管理的角度切入 Agent 架構，強調真正的挑戰不在模型能力，而在於建構處理「90% 無聊日常工作」的系統架構。
Obsidian 開啟
Prompt工程 領域

Prompt工程 總結報告

本期 Prompt 工程領域的 6 篇文章，深刻反映了 Prompt Engineering 正在經歷一場從「咒語詠唱」到「系統性基礎設施」的典範轉移。隨著 Claude Fable 5 (Mythos) 等具備強大長程自主推理能力的新一代模型問世，過去那種依賴複雜、瑣碎指令的「微觀管理式 Prompt」反而成為了限制模型發揮的枷鎖。現在的最佳實踐是將 Prompt 提升為全局的上下文約束（如 `CLAUDE.md`）與專業角色定義。開發者的角色已從「逐步下達指令的操作員」，轉變為「提供業務背景、設定行為邊界、定義驗證標準的架構師與委託人」。
核心主題 (Key Themes)
  • CLAUDE.md：將 Prompt 固化為專案的「長期記憶與基礎設施」：多篇文章強烈呼籲停止依賴一次性的懶惰 Prompt，轉而建立系統級的環境設定。
  • 應對 Fable 5 的「少即是多」原則：面對能力更強、主動性更高的 Fable 5，舊有的 Prompting 技巧必須被淘汰。
  • 將人類頂級智慧編碼為 Prompt Skill：Prompt 成為了封裝人類專業知識的容器。
Obsidian 開啟
學習資源 領域

學習資源 總結報告

本期學習資源領域的文章反映了在 AI 資訊爆炸時代的「反向過濾」趨勢。面對每天數以百計的新模型、新框架與新工具，最優質的學習資源不再是大而全的百科全書，而是經過實戰檢驗的「高信噪比過濾器」。從《一些或許對你有益的信息》等文章可以看出，開發者更傾向於吸收帶有強烈個人觀點、經過實踐驗證的經驗總結，而非官方的公關稿件。這標誌著技術學習的典範正在轉移：從「囤積知識」轉向「建立個人認知框架」。
核心主題 (Key Themes)
  • 資訊降噪與策展型學習的崛起：在 Token 氾濫的時代，人工過濾與策展的價值不降反升。
  • 從「學語法」到「學工作流」：現代工程師的學習焦點已經轉移。
Obsidian 開啟
實戰教學 領域

實戰教學 總結報告

本期實戰教學領域聚焦於「如何從零到一建立實用的 AI Agent」。有別於過去那些充滿數學公式的底層原理解析，現在的教學文章展現了極強的「動手做（Hands-on）」屬性。如《How to Actually Build Your First AI Agent with Claude Code》這類文章，直接打破了 Agent 開發的高門檻迷思，透過具體的專案範例、現成的開源工具與逐步（Step-by-step）的引導，讓即便是初階開發者也能在幾個小時內將抽象的 AI 理論轉化為可實際運行的虛擬助理。這代表 AI 開發已經從「科學研究」階段，正式進入了「工程應用」的普及期。
核心主題 (Key Themes)
  • 「工具鍊整合」取代「底層演算法」成為教學核心：開發者不需要知道 Transformer 怎麼運作，但必須知道如何把元件串起來。
  • 實踐先於理解（Build first, understand later）：有別於傳統由下而上的學習法，AI 時代的實戰教學強烈推薦由上而下。
Obsidian 開啟
工作方法 領域

工作方法 總結報告

本期工作方法領域的探討，深刻反映了在強人工智慧輔助下，人類工作核心技能的轉移。文章如《认知科学角度的写作八原则》提醒我們，即便 AI 能夠在一秒內生成千言萬語，但直指人心的溝通與深刻的邏輯結構依然是稀缺的。工作方法的焦點已經從「如何更快地產出內容」轉向「如何更精準地表達意圖與引導 AI」。這意味著，未來的核心競爭力不再是執行層面的效率，而是認知層面的清晰度與指令架構能力。
核心主題 (Key Themes)
  • 認知科學引導下的降維溝通：無論是面對人類讀者還是 AI 模型，降低對方的認知負荷都是首要任務。
  • 意圖傳遞重於細節堆砌：AI 時代的工作流中，最昂貴的成本是「溝通誤差」。
Obsidian 開啟
工作流 領域

工作流 總結報告

本期工作流領域展現了自動化系統與人類協作的最新邊界。從《用 Codex + Remotion 实现无痛自媒体视频日更》的端到端內容生產線，到關於 `human in the loop`（人機協作）的深刻探討，我們看到現代工作流已經超越了單純的腳本串接，演化為「高度自動化引擎與人工關鍵決策節點」的有機結合。AI 負責處理耗時的繁瑣步驟（如剪輯、排版、資料清洗），而人類則退居幕後，專注於流程的監控、品管與審批。這種「把工作變成維護生產線」的思維，正在各個產業中創造出十倍速的個人生產力。
核心主題 (Key Themes)
  • 內容生產的工業化與管線化：自媒體與開發工作正在經歷類似福特汽車流水線的工業革命。
  • Human-in-the-Loop 的精準安放：全自動化往往伴隨著失控的風險，聰明的工作流懂得在關鍵處踩煞車。
Obsidian 開啟
工具實踐 領域

工具實踐 總結報告

本期工具實踐領域的文章強調了「降低 AI 工具導入門檻」的重要性。如《Codex 上手别卡在配置：Teamo 一键接入教程》所示，即使是再強大的 AI 開發工具（如 Codex），如果環境配置過於繁瑣、依賴過多，也會將絕大多數潛在用戶拒之門外。這反映出當前工具鏈生態的一個痛點：開發者渴望的是開箱即用（Out-of-the-box）的流暢體驗，而非花費整個下午與環境變數搏鬥。因此，能夠提供「一鍵部署」或「無縫整合」的輔助工具與教學，成為了推動 AI 技術普及的關鍵催化劑。
核心主題 (Key Themes)
  • 配置自動化成為工具推廣的生死線：工具的強大與否已經不是唯一賣點，上手體驗決定了留存率。
  • 生態系的去中心化與第三方補強：官方往往無法照顧到所有邊緣場景，第三方工具填補了這些空白。
Obsidian 開啟
後端開發 領域

後端開發 總結報告

本期後端開發領域的文章回歸到了企業級 API 設計的經典難題。在 AI 搶盡風頭的當下，《Adding Filtering, Sorting And Pagination To a REST API .NET 10》等文章提醒我們，穩健、高效的資料訪問層依然是任何強大應用的基石。探討如何在最新的 .NET 10 框架下優雅地實作過濾、排序與分頁功能，反映了後端工程師對於系統可擴展性（Scalability）與效能優化的永恆追求。即使在 Agent 滿天飛的架構中，如果底層的 REST API 無法支撐海量且複雜的資料檢索請求，再聰明的 AI 也會面臨巧婦難為無米之炊的窘境。
核心主題 (Key Themes)
  • 現代化框架對經典設計模式的原生支持：框架的演進致力於將重複性的「樣板代碼（Boilerplate）」降至最低。
  • 資料檢索效能是 API 設計的核心考量：當資料量呈指數級增長時，單純的 GET 請求已無法滿足需求。
Obsidian 開啟
思考隨筆 領域

思考隨筆 總結報告

本期思考隨筆領域探討了在強 AI 時代下，工作者「自我定位」與「創作價值」的深層焦慮與重新定義。無論是討論「Agentic Coding」本質的技術隨筆，還是探討作家如何在高產出的同時保持高品質的經驗分享，文章都指向一個共通的結論：AI 抹平了「執行層面」的落差，但放大了「品味」與「決策」的價值。當寫出一篇好文章或一段好程式碼的成本趨近於零時，真正能變現的不再是你的打字速度，而是你如何定義問題、如何編排邏輯，以及你對最終產出品味的堅持。
核心主題 (Key Themes)
  • Agentic Coding 的祛魅與本質：AI 編程並非魔法，而是另一種形式的工程管理。
  • 創作價值的轉移：從「產量」到「觀點」：在 AI 時代，高收入創作者的護城河不在於他們能寫多少，而在於他們能思考多深。
Obsidian 開啟
知識管理 領域

知識管理 總結報告

本期知識管理領域的文章揭示了傳統筆記軟體（如 Notion, Evernote）向「AI 知識層（AI Knowledge Layer）」的典範轉移。隨著 LLM 成為工作流的核心，知識管理的受眾不再只是「未來的自己」，而是「現在的 AI Agent」。《AI Knowledge Layer》等文章指出，沒有持久化知識庫的 Agent 就像每天都被重置記憶的實習生。未來的知識庫必須是以「機器可讀」的格式構建，成為 LLM Wiki Pattern 的具體實踐。這意味著個人與企業的知識管理系統，將成為驅動自動化代理人運作的燃料庫。
核心主題 (Key Themes)
  • 知識的受眾改變：從 Human-readable 到 Agent-readable：筆記不再只是為了給人看，更是為了給 AI 讀。
  • 靜態文檔的終結與動態協議的崛起：知識不再是存放於資料夾底層的死水，而是參與每次執行的動態協議。
Obsidian 開啟
系統架構 領域

系統架構 總結報告

本期系統架構領域涵蓋了從微服務治理到高併發通知系統的深度案例。無論是 Netflix 構建即時服務拓撲圖以應對微服務的「孤島效應」，還是深入探討系統熵增與法典（規範）之間的對抗，這些文章共同指向一個核心挑戰：**複雜性管理（Complexity Management）**。在雲原生與分散式架構已成標配的今天，系統架構師的首要任務不再是如何畫出更炫的架構圖，而是如何建立即時的可觀測性（Observability），以及如何透過硬性規範與自動化工具，來延緩系統架構必然走向混亂的「熱力學第二定律」。
核心主題 (Key Themes)
  • 微服務治理的痛點：從黑盒到即時拓撲：當微服務數量達到數千個時，靜態架構圖將毫無意義，動態可觀測性成為剛需。
  • 系統演化的物理學：對抗熵增的架構法典：軟體系統天生有一種越變越亂的趨勢，這需要架構師刻意施加「外力」來維持秩序。
Obsidian 開啟
職場技能 領域

職場技能 總結報告

本期職場技能領域的文章，強烈反映了 AI 普及後對資深工程師（Senior SDE）能力模型的重新定義。從《The 6 Skills that get more valuable in the Agentic Era》到涵蓋各大科技巨頭的面試筆記，我們看到「寫程式的速度」與「默寫演算法」的價值正在快速貶值。取而代之的是，能夠定義模糊問題、進行高階架構設計、跨團隊溝通協調，以及具備「AI 系統邊界認知」的軟硬整合能力，成為了新時代職場的硬通貨。在 Agentic 時代，最值錢的技能不是成為一個更好的 Coder，而是成為一個能指揮 AI 大軍的 Commander。
核心主題 (Key Themes)
  • Agentic 時代的技能重估：從「解答者」到「提問者」：AI 擅長給出標準答案，但極度缺乏發現問題與定義問題的能力。
  • 頂級科技巨頭面試標準的演變：大廠的面試重點正在從 LeetCode 轉向 System Design 與 Behavioral Questions。
Obsidian 開啟
職場觀察 領域

職場觀察 總結報告

本期職場觀察領域的文章，以自由工作者與知識創作者的視角，探討了 AI 時代下的職涯選擇與收入模式轉變。《How I Make £10KMonth as a Writer》等文章揭示了一個殘酷卻也充滿機遇的現實：在這個「產量不再是壁壘」的時代，純粹販賣時間與勞力的底層打工人將面臨巨大壓力；然而，懂得利用 AI 作為槓桿，將個人獨特經驗、深度思考與個人品牌結合的「超級個體（Super Individual）」，其收入天花板正在被無限拔高。職場的兩極化趨勢正在加速，中間層的舒適圈正在消失。
核心主題 (Key Themes)
  • 超級個體的崛起：AI 作為槓桿放大器：AI 並沒有取代創作者，而是淘汰了那些「像機器一樣創作」的人。
  • 職場晉升階梯的斷裂與重建：傳統的「Junior -> Mid -> Senior」線性升級路徑正在受到挑戰。
Obsidian 開啟
認知思維 領域

認知思維 總結報告

本期認知思維領域的文章，以極其銳利的視角剖析了個人成長與社會流動的底層邏輯。《跨越阶级》一文打破了傳統「只要努力就能成功」的雞湯敘事，指出階級的跨越本質上是一場「認知帶寬（Cognitive Bandwidth）與信息梯度」的殘酷戰役。文章深刻地描繪了從舊階級跨入新階級時所必經的「身份懸空」陣痛期。這在技術快速迭代的 AI 時代具有強烈的隱喻意義：無論是社會階層的躍遷，還是工程師從傳統開發轉向 AI 驅動開發的認知升級，都需要主動釋放稀缺的認知資源，並承受舊經驗失效帶來的冒名頂替症候群（Imposter Syndrome）。
核心主題 (Key Themes)
  • 認知帶寬（Cognitive Bandwidth）的釋放是躍遷的前提：你無法在為生存焦慮耗盡心力的同時，去思考未來的戰略佈局。
  • 擁抱「身份懸空」帶來的撕裂感：任何實質的認知升級，都伴隨著舊有身份認同的崩塌。
Obsidian 開啟
量化交易 領域

量化交易 總結報告

本期量化交易領域的文章揭示了 AI 技術如何重塑金融市場的競爭格局。《How To Use Loop Engineering To Build A Self-Improving Quant Trading System》一文將近期火熱的 Loop Engineering（迴圈工程）概念直接導入了量化交易的實戰中。這代表著個人投資者或小型團隊，現在能夠利用具備「狀態記憶、獨立驗證與自我進化」能力的 AI Agent 系統，建立起 24/7 不間斷運作的自動化回測與交易引擎。過去這類高度自動化的研究與執行管線，是華爾街頂級避險基金（擁有數百名研究員與工程師）專屬的護城河，如今正被 AI 技術徹底平民化。
核心主題 (Key Themes)
  • 交易系統的 Agent 化：從「腳本自動化」到「自我進化」：傳統量化交易依賴人類寫死規則（Hardcoded Rules），而新一代系統具備自我修正能力。
  • 獨立驗證與「Kill Switch（緊急停止開關）」是生存底線：在涉及真金白銀的交易領域，AI 幻覺的代價是破產。
Obsidian 開啟
開發工具 領域

開發工具 總結報告

本期開發工具領域收錄的 4 篇文章，深刻展示了 AI 時代開發環境的底層基礎設施正在發生劇烈變革。從 Apple 顛覆性的輕量級虛擬機架構，到巧妙利用 Git Worktree 實現無痛多工，再到利用 Codebase Memory 與精準的上下文管理來解放 Claude Code 的潛力。這一切都圍繞著一個核心主題：「**環境隔離與上下文極致優化**」。開發者正在利用這些工具，試圖在龐大且複雜的專案中為 AI 代理人（AI Agents）打造出最乾淨、最高效的執行環境，從而突破 Token 限制並大幅提升程式碼生成的準確率。
核心主題 (Key Themes)
  • 上下文即資源：從「暴力檢索」走向「精準結構圖譜」：傳統的字串搜尋（grep）與粗放的上下文塞入，已經無法滿足高階 AI 開發的需求。
  • 環境隔離技術的極致輕量化與並行化：為了讓 AI Agent 能同時處理多個獨立任務，底層運行環境必須足夠輕量且互不干擾。
Obsidian 開啟

📚 文章摘要列表 (Articles)

AI商業
Cover

AI Agents Aren’t Just Changing Technology. They’re Changing How Businesses Will Operate.

"AI 代理不僅僅是提高生產力的工具，它正在重塑整個企業的營運模型，讓「人機協同」成為未來團隊的新常態。"
Top 5 Insights
  • **架構視角的轉變：從 API 調用到數位勞動力**
  • **必須建立 AI 治理與可觀測性架構 (Observability for Agents)**
  • **導入 Human-in-the-Loop (HITL) 批准機制**
  • **信任即架構 (Trust as Architecture)**
Obsidian 整理 原始文章
AI商業
Cover

Agents are the new SaaS. Here's the whole playbook.

"SaaS 賣軟體，Agent SaaS 賣工作成果；把一項人類討厭的、頻繁發生的工作封裝成自動化勞動力。"
Top 5 Insights
  • **商業模式升級**：從「提升效率的工具（SaaS）」進化為「直接替代重複勞動的執行者（Agent）」。
  • **漸進式架構**：摒棄完全 Autonomous 的幻想，採用 Workflow 導向架構，從 Human-in-the-loop（Draft/Triage）逐步演進到 Bounded Action。
  • **信任工程 (Trust Engineering)**：Agent 創業的核心壁壘不是底層 LLM 的能力，而是那層能提供可觀測性（Logs）、可干預性（Approvals）與可驗證性（Evals）的 SaaS Wrapper。這才是讓企業級客戶敢於買單的關鍵架構決策。
Obsidian 整理 原始文章
AI商業
Cover

The AI Economy: The Next Chapter

"AI 產業的經濟價值正從「發明智能的模型提供商」往「分配與編排智能的基礎設施（公有雲）平台」轉移。"
Top 5 Insights
  • **AI 架構設計必須導入「路由/編排層」**：架構師在設計企業內部 AI 系統時，應引入 Gateway 或 Orchestrator 模式（如 Semantic Kernel 或 LangChain 的路由機制），解除系統與單一模型提供商的強耦合，實現基於 ROI 的動態模型調度。
  • **開源模型將成為企業基石**：應積極評估並在內部私有環境或 VPC 中部署高效能的開源或蒸餾模型（Small Language Models, SLMs），以極低的推論成本處理高頻的常規自動化任務，將前沿模型保留給高價值業務。
  • **基礎設施的持續獲利能力**：從投資或產業觀點來看，隨著 AI 從技術概念驗證（PoC）進入大規模生產（Production），利潤將無可避免地流向能夠提供一站式合規、資安、以及模型編排的雲端基礎設施提供商。
Obsidian 整理 原始文章
AI商業

The Great Descent

"AI 正在重演智慧型手機的普及之路，當「專業判斷」變得極其廉價時，唯有將專有經驗系統化的人才能勝出。"
Top 5 Insights
  • **專業判斷的商品化**：AI 正在將稀缺的「人類專業經驗」商品化。單純的常規分析或代碼編寫能力將不再具備競爭溢價。
  • **系統化專屬優勢（Systematize your own alpha）**：系統設計的核心必須轉向如何擷取與數位化企業內部的「隱性知識」。將獨特的商業邏輯與決策經驗整合進專屬的 AI 應用架構中，是未來的關鍵戰場。
  • **決策與責任的分離設計**：隨著技術執行成本趨近於零，企業架構應更加著重於「決策審核」、「風險控管」與「最終責任歸屬」，確保人類在高階戰略與結果負責上的不可取代性。
Obsidian 整理 原始文章
AI商業
Cover

tokens ≠ value

"單純購買 AI 模型只會產生「AI 垃圾 (slop)」，唯有透過流程設計與反饋迴圈建立的「鷹架」，才能將模型轉化為會隨時間複利增長的資產。"
Top 5 Insights
  • **架構優先於模型**：AI 模型正快速商品化且可抽換（如 Apple Siri 的架構設計），企業真正的護城河與資產是圍繞模型建構的「鷹架 (Scaffolding)」與流程。
  • **價值乘法效應**：系統化地看待 AI 價值 (`AI Value = Human Capital x Scaffolding x Feedback Loops x Model`)，任何一環的缺失都會導致整體系統失效，其中「人類判斷與反饋」是不可或缺的乘數。
  • **基礎建設先行 (Step Zero)**：導入 Agent 或模型前，必須優先完成基礎層次（流程設計、治理、知識架構）的建構。若無法畫出清晰的流程地圖，就不應盲目引入 AI。
Obsidian 整理 原始文章
AI工具
Cover

10 Open-Source Repos That Quietly Make Claude Code 10x Better (Full Guide)

"十款讓 Claude Code 從單純的聊天助手進化為具備記憶、架構思維與安全意識的全能開發代理人的開源專案。"
Top 5 Insights
  • **多代理與職責分離架構（Multi-Agent Architecture）**：將 AI 視為單一執行個體是不夠的。利用如 GStack 或 DeerFlow 這樣的框架，可以建立起多層次的代理架構，透過職責分離（如將規劃、執行、測試與審查交由不同角色處理）來大幅提升系統的穩定度與產出品質。
  • **上下文最佳化機制（Context Optimization）**：中大型專案的上下文視窗管理是效能與成本的瓶頸。Graphify 所展示的「知識圖譜索引（Knowledge Graph Indexing）」技術，透過結構化檢索取代全文本掃描，是未來大型 AI 程式碼輔助工具的必要架構。
  • **防禦性安全整合（Defensive Security Integration）**：第三方技能的隨意載入對本機系統構成了極大威脅（如文中所提 26% 的技能漏洞率）。在建構 AI 輔助開發環境時，必須將類似 SkillSpector 的安全掃描整合進工作流的第一道防線，實行零信任（Zero Trust）的安全策略。
  • **工程紀律的強制化（Enforced Engineering Discipline）**：套用如 ECC 與 Matt Pocock skills，證明了 AI 生成代碼常出現的混亂與幻覺，可以透過外掛機制進行嚴格約束。強制執行 TDD（測試驅動開發）與架構審查，是讓 AI 代理真正適用於生產環境的關鍵。
Obsidian 整理 原始文章
AI工具
Cover

Anthropic Just Open-Sourced a Full Office Team for Claude and Almost Nobody Noticed

"Anthropic 悄悄開源了一組角色外掛，讓你可以用指令在 Claude Cowork 裡建立包含銷售、財務、行銷等角色的專屬 AI 團隊，徹底改變從零提示的對話模式。"
Top 5 Insights
  • **從單點問答到系統化工作流**: Claude Cowork 加上開源的知識工作外掛，成功將 LLM 從一個「患有健忘症的自由工作者」轉變為一個持續在線的跨職能虛擬團隊。
  • **微服務化的 AI 代理**: 透過 Skills, Commands 和 Connections 的分離設計，Anthropic 展現了一種高度模組化、易於客製的 AI Agent 架構，讓使用者能靈活組裝所需能力。
  • **極低門檻的企業級架構**: 過去需要龐大開發團隊才能完成的企業知識庫與系統 API 串接（如 CRM 或 Snowflake），現在透過幾個終端指令與 Markdown 配置即可免費獲得，這對中小企業的數位轉型將產生顛覆性影響。
Obsidian 整理 原始文章
AI工具
Cover

CodeX 新功能，又是一个独宠 MAC 的功能！！！

"Codex 的 Record & Replay 功能將 AI 工作流從「寫說明書」變成了「手把手演示」，讓不會寫代碼和 Prompt 的普通人也能輕鬆打造專屬的自動化技能。"
Top 5 Insights
  • **從聲明式走向示教式**：Record & Replay 將傳統自動化中「聲明式 (Declarative) 的腳本編寫」轉變為類似工業機器人領域的「示教編程 (Programming by Demonstration)」，極大降低了自動化落地的成本。
  • **UI 穩定性是 Computer Use 的阿基里斯腱**：依賴視覺與坐標的 GUI 自動化天生脆弱，未來的架構需考慮引入 VLM (Vision-Language Model) 的自癒機制來應對前端介面的微調。
  • **權限與沙盒隔離至關重要**：開放 Computer Use 意味著 AI 獲得了系統全局的操作權限，架構上必須嚴格劃分高/低風險操作區，並對密鑰、Token 等敏感數據實施硬體或系統級別的隔離防護。
Obsidian 整理 原始文章
AI工程
Cover

Building Rust-Powered Edge AI Runtimes for Real-Time Inference on IoT Devices

"AI 的未來不僅在於更大的雲端模型，更在於透過 Rust 等系統語言將智慧可靠地推廣至資料產生的邊緣端。"
Top 5 Insights
  • **推論邊緣化是必然趨勢**：低延遲、離線可用性與資料隱私要求，驅使推論過程必須從雲端下放至本地設備。
  • **資源受限環境中的語言選擇**：Rust 憑藉零 GC 開銷、記憶體預先分配能力與極高的並發安全性，是建構邊緣 AI Runtime 的理想系統程式語言。
  • **架構解耦與事件驅動**：應避免將雲端微服務架構套用於邊緣。透過 ONNX 實現訓練與部署分離；透過狀態/事件驅動取代持續輪詢推論，以最大化利用有限算力。
  • **可維護性的核心**：將 Runtime 本體、推論模型與系統組態徹底分離，是實現百萬台 IoT 設備長期 OTA 更新與維運的架構基礎。
Obsidian 整理 原始文章
AI工程

Every LLM Eval Fix Needs a Regression Check

"每個 LLM 的評估與修復，不僅要確認「失敗的案例修好了沒」，更要確認「原本好的有沒有被改壞」。"
Top 5 Insights
  • **建立三維度測試數據集**：LLM 評估必須從單維度的「Bug 修復測試」升級為包含 Failed, Clean-pass, Risk 三個維度的小型且高效的回歸測試集。
  • **將 Tradeoff 流程化**：透過 Keep / Revert / Adjust 的條件設定，將原本憑感覺的架構決策轉變為具備量化指標的工程規範。
  • **視 LLM Workflow 為微服務鏈條**：不應只把 LLM 視為一個黑盒子 API，而應將 Prompt、Parser、Routing 視為緊密耦合的微服務，任何單點改動都必須進行跨服務的副作用測試。
  • **拒絕盲目的 Benchmark**：相比於龐大且耗時的全局 Benchmark，建立針對特定 Pipeline 的小型但高覆蓋率的回歸測試集，才是敏捷 LLM 工程的正確解法。
Obsidian 整理 原始文章
AI工程
Cover

How to Actually Use Train, Validation, and Test Sets in ML

"測試集是你這學期的「期末考」，一旦你為了期末考去調整讀書方法，這份考卷就失去了客觀評估你實力的意義。"
Top 5 Insights
  • **警惕驗證集過擬合**：反覆透過驗證集調優模型會導致資訊洩漏，使驗證分數失去代表性。應適當採用 K-Fold 交叉驗證來提升評估的穩健度。
  • **隔離預處理管線**：諸如特徵縮放、缺失值填補等任何預處理步驟，必須**僅在訓練集上進行 `fit`**，隨後再 `transform` 到驗證/測試集上，嚴防資料統計特徵洩漏。
  • **針對特定資料結構選擇切分策略**：不能無腦依賴隨機切分 (`train_test_split`)。對於時間序列需使用滾動切分；對於不平衡資料需使用分層抽樣 (`Stratified`)；對於同源多筆紀錄需使用群組切分 (`GroupKFold`)。
  • **測試集的神聖不可侵犯性**：測試集僅能在最終上線前執行一次，絕對不能將其測試結果回饋到任何模型決策與超參數調整中，否則就失去了公正衡量真實世界效能的意義。
Obsidian 整理 原始文章
AI工程
Cover

LLM Evals Are Not Just Model Tests

"評估 LLM 不是在問「哪個模型最聰明」，而是在問「這個工作流在目前的資料與限制下，能否產出最可靠的結果」。"
Top 5 Insights
  • **評估標的轉移**：不要將 LLM Eval 侷限於「模型比較 (Model Tests)」，必須將其升級為「工作流測試 (Workflow Tests)」。Prompt、Schema、Validator、Fallback Chain 等周邊元件對系統成功與否的影響，往往大於模型本身的些微差距。
  • **防禦性設計與靜默失敗**：在 AI 萃取系統中，遺漏 (Missing) 與幻覺 (Hallucination) 是最致命的問題，因為它們經常會以合法的 JSON 結構出現（靜默失敗）。架構設計上，寧可讓欄位留白並標示不確定，也應拒絕模型過度自信的捏造，以保護下游業務邏輯。
  • **成本與延遲是架構驅動力**：不要把 LLM 的 API 成本與延遲只當作維運數據。它們會直接決定你的系統是否需要導入多模型路由 (Multi-model Routing)、快取層或是複雜的降級 (Fallback) 策略。
  • **建立基於 Root-Cause 的評估循環**：自動化評分只是第一步。真正能提升系統可靠性的，是深度檢查失敗的原因，釐清錯誤是來自 Prompt 歧義、字典映射缺失，還是模型本身的限制，並針對系統中最脆弱的環節進行迭代。
Obsidian 整理 原始文章
AI工程

LLM Evals Should Produce Routing Rules, Not Just Scores

"一個有用的 LLM 評估系統不只要告訴你哪個模型得分最高，更要告訴你的產品接下來該怎麼做。"
Top 5 Insights
  • **從排行榜到工作流**：揚棄追求單一模型的最高得分，將 Eval 系統的目標轉變為產出明確的「多模型協作與降級路由規則」。
  • **建立分工架構**：在雲端原生與微服務架構下，應將 LLM 視為具備不同特性的微服務。明確劃分「快且便宜的預設模型」、「強大但昂貴的降級模型」以及「領域專精模型」的職責邊界。
  • **以失敗模式驅動設計**：透過豐富的 Eval Logs（包含信心分數、Schema 驗證狀態、缺失欄位等），找出模型的特定失敗模式，並據此制定觸發 Fallback 或人工介入的條件。
  • **成本與風險的動態權衡**：每一次的路由降級都伴隨著延遲與 API 成本的增加。架構師必須與產品團隊對齊，決定哪些關鍵欄位值得花費額外成本重試，哪些邊際錯誤可以直接放行。
  • **測試你的路由層**：路由邏輯不應是靜態的，必須針對「路由層」本身建立監控指標（如不必要降級率、降級後接受率），確保系統整體的 ROI 與效能達到最佳化。
Obsidian 整理 原始文章
AI工程

LLM Evals Should Produce Routing Rules, Not Just Scores

"無一席話總結"
Top 5 Insights
  • **Evals 即系統設計 (Evals as System Design)**：模型評估不應僅止於計分板，其終極目的是幫助我們設計出能處理不確定性、不完整性、成本、延遲與風險的動態路由工作流。
  • **多模型協作的 API MoE 思維**：捨棄尋找單一全能冠軍模型的迷思。在工程實踐上，應該根據文件特性與失敗模式，明確指派「預設模型」、「備用模型」與「專家模型」的特定職責。
  • **建立細粒度的失敗日誌 (Failure-driven Routing)**：要實踐路由策略，必須揚棄單一總分，轉而記錄並分析豐富的評估日誌（包括 Schema 狀態、特定欄位缺失、幻覺風險等 18 項指標），讓路由規則建立在真實的失敗模式之上。
  • **將路由層納入測試與監控 (Testing the Routing Layer)**：路由規則（IF-THEN 邏輯）也是產品決策的一部分。系統必須針對路由層本身的效能（如 Fallback 觸發率、不必要的重試率、增加的總延遲與成本）進行獨立評估與監控，以確保系統架構整體的 ROI。
Obsidian 整理 原始文章
AI工程
Cover

Loop Engineering The AI skill every builder needs in 2026

"未來的核心技能不是優化提示詞，而是設計能讓 AI 代理人持續測試與修正直到成功的工作迴圈。"
Top 5 Insights
  • **思維範式轉移**：未來開發者的核心競爭力不再是「優化英文提示詞 (Prompt Engineering)」，而是「設計包含發現、計畫、執行、驗證的系統反饋循環 (Loop Engineering)」。
  • **隔離與校驗架構**：在設計多 Agent 系統時，必須嚴格遵守「創作者與審查者分離 (Maker and Checker separation)」原則，並搭配 Git Worktrees 來避免並行編輯的衝突。
  • **封閉迴圈優先於開放迴圈**：受限於當前的 Token 成本與模型漂移問題，企業應優先導入具備明確停止條件 (Stop condition) 與評估機制的封閉迴圈 (Closed Loops)，而非漫無目的的開放探索。
  • **系統級記憶與狀態管理**：單靠模型的 Context Window 是不夠的，長程迴圈必須依賴外部的持久化機制（如 Markdown 日誌、Issue Tracker）來維持狀態，確保每次迭代不是從零開始。
Obsidian 整理 原始文章
AI工程
Cover

Loop Engineering: A Loop That Tunes RAG to a Target Recall by Itself

"不要手動調整 RAG 參數，而是建立一個具有明確評估指標、防過擬合與預算控制的自動化迴圈來為你找到最佳配置。"
Top 5 Insights
  • **指標驅動架構**：將 RAG 調優轉化為一個具備封閉迴圈的軟體工程問題，利用明確的數值化指標 (`recall@k`) 來取代人為主觀測試。
  • **防禦性防護機制 (Defensive Safeguards)**：在自動化系統中，Train/Holdout 的隔離機制與預算預檢 (Pre-run budget check) 是確保系統不會產生意外結果（如過擬合或天價帳單）的核心架構設計。
  • **搜尋效率的折衷**：透過採用 Coordinate Descent 而非 Grid Search，我們在「找到全域最佳解」與「運算成本」之間取得了極佳的工業級平衡，讓自動化參數調優具備現實可行性。
Obsidian 整理 原始文章
AI工程

Solo LLM Evals Still Need Review Rules

"單人開發者在評估 LLM 輸出時，最大的敵人是「自己對模型的寬容」，唯有建立明確的書面審查規則，才能確保評估的穩定與客觀。"
Top 5 Insights
  • **建立「防寬容」機制 (Anti-Forgiveness Mechanism)**：在開發 LLM 萃取與解析系統時，最大的陷阱是開發者的「腦補」與「同情心」。必須將評估基準從「語意看似合理」轉移到「嚴格遵守資料契約 (Data Contract)」。
  • **隔離推論與萃取 (Decouple Inference from Extraction)**：LLM 擅長利用背景知識進行合理猜測（例如猜測航廈），但在精確萃取任務中，這種能力就是「幻覺」。系統設計時必須在 Prompt 與驗證邏輯中明確界定「依據文本萃取」與「模型自行推論」的界線。
  • **微型回歸測試約定 (Micro-Regression Contract)**：在單人開發或小團隊敏捷開發 LLM 應用時，修改 Prompt 牽一髮動全身。應建立嚴格紀律：任何針對單一 Case 的修復，都必須搭配一個涵蓋所有核心情境的迴歸測試集 (Regression Subset) 的執行，避免打地鼠式的開發。
  • **將主觀判斷轉化為成文規則 (Codify Subjective Judgments)**：實踐「如果明天判斷可能不同，今天就寫成規則」的哲學。在專案根目錄維護輕量級的 `review_rules_v1.md`，這不僅是評估的準則，更是未來若要導入 "LLM-as-a-Judge" 時最寶貴的 Prompt 來源庫。
Obsidian 整理 原始文章
AI工程

Solo LLM Evals Still Need Review Rules

"獨立開發者最難校準的審查員就是自己，因此你必須為 LLM 評估寫下一套「白紙黑字」的審查規則。"
Top 5 Insights
  • **消除評估的「人為寬容」**：獨立開發 LLM 系統時，開發者必須意識到自身是「最難被校準的審查員」。必須透過成文規則，強制將審查標準客觀化，拒絕因為「看起來很合理」而放行。
  • **明確化資料契約 (Data Contracts)**：將系統架構中的隱性假設轉化為顯性規則。例如嚴格區分 `Raw Value` 與 `Normalized Value`，以及 `Extracted` 與 `Inferred` 的界線。
  • **從「判例」提煉「規則」**：不需要一開始就完美。可以在評估過程中，遇到模稜兩可的案例時，透過記錄 Reviewer Notes 來動態擴充 `review_rules_v1.md`，以此作為個人開發工作流中的重要知識資產。
  • **確保迴歸測試的紀律**：對於 Prompt 或系統參數的任何微小修改，必須強制執行全集的迴歸測試，避免落入「局部修復導致全局退化」的常見陷阱。
Obsidian 整理 原始文章
AI工程
Cover

Vibe Coding 的尽头是规划先行

"把需求文件（Spec）當作給 AI Agent 閱讀的合約與基礎設施，是避免 Vibe Coding 災難的唯一解。"
Top 5 Insights
  • **自然語言不具備精確性**：Agent 無法讀取開發者的隱性假設與共享上下文，Vibe Coding 必然導致不符合業務邊界與安全標準的產出。
  • **Spec 是 Agent 的基礎設施**：在專案中建立 `CLAUDE.md` 或 `AGENTS.md` 這樣的文件，明確定義成功標準、約束底線與功能邊界，是讓 Agent 穩定產出的關鍵。
  • **投資報酬率極高**：事前花費少量時間撰寫結構化的規格文件，能避免後期因為架構偏離或細節錯誤而產生的巨大 Debug 與重構成本（15分鐘換 3 天）。
Obsidian 整理 原始文章
AI工程
Cover

Why LLM Evaluation Matters Building Reliable AI Systems Beyond Prompt Engineering

"LLM 系統的評估不該只是「感覺不錯」，而是一套能隔離錯誤層級、量化系統行為並指導工程迭代的紀律系統。"
Top 5 Insights
  • **分層與規則優先 (Layered & Rule-First Eval)**：在架構評估系統時，切勿濫用 LLM-as-judge。應優先實作成本低、速度快、可重現的確定性規則檢查 (如 JSON 解析、資料庫執行比對、數值追溯)，僅在需要語義解釋時才動用 LLM，以達成成本與效益的最佳平衡。
  • **評估指標需與架構解耦 (Decoupled Metrics)**：如同 Text-to-SQL 案例中將 SQL 檢索準確率與自然語言回應準確率分開計算，複雜的 Agent 系統應針對檢索 (Retrieval)、工具選擇 (Tool Call) 與最終回應 (Final Response) 分別建立追蹤指標，才能快速定位系統瓶頸。
  • **防範靜態數據漂移與過度擬合**：基準測試集 (Golden Set) 不應是死板的快照。預期答案應能隨資料庫或環境變動動態生成，並且必須不斷從生產環境的失敗案例中補充新樣本，以防止系統對特定測試集產生過度擬合 (Overfitting)。
  • **評估是開發的方向盤 (Eval is the Steering Wheel)**：評估系統不是軟體開發生命週期最後階段的報告卡，而是在每個 Commit 和 Prompt 變更當下，用以指導工程決策的核心驅動力。
Obsidian 整理 原始文章
AI工程
Cover

You're doing RAG wrong

"你做錯 RAG 的根本原因，在於把「沒有邊界的文本塊」當成了知識的最小單位；正確的做法是將知識轉化為帶有權限與元數據的「問答對 (IdeaBlocks)」。"
Top 5 Insights
  • **放棄無腦 Chunking**：將文本強制切塊是解析上的便利，卻是檢索上的災難。RAG 的未來在於結構化的原子數據單元 (Atomic Claims)。
  • **冗餘是 Vector DB 的毒藥**：向量空間中的相似重複數據不是「補充材料」，而是會干擾餘弦相似度計算的「競爭噪音」。必須在進入 Vector DB 前引入強制的語義去重與蒸餾機制。
  • **治理前移 (Shift-Left Governance)**：將權限控制 (RBAC) 和版本控制作為 Typed Fields 直接寫入知識的最小單元中，能徹底解耦 Orchestrator 層的複雜邏輯，實現 Data-Driven 的安全控管。
  • **建立「數據預處理層」**：如同 Web 架構長出了 CDN，現代 RAG 架構必須在文檔解析與向量化之間，建立一層專門負責聚類、摘要與 Schema 強制的 Data Optimization Layer。
Obsidian 整理 原始文章
AI工程

Your LLM Eval Is Only as Good as Your Ground Truth

"跑五個大模型很容易，但決定「它們到底該跟什麼標準比較」才是最難的；你的 LLM 評估品質，永遠不會超過你制定的標準答案品質。"
Top 5 Insights
  • **分離擷取與正規化 (Decouple Extraction and Normalization)**：在 Schema 設計上，將每一個實體拆分為 `raw_value` 與 `normalized_value`。這能大幅提升系統的可除錯性 (Debuggability) 與信任度。
  • **建立精細的 Null 語意 (Refine Null Semantics)**：禁止在 Ground Truth 中使用模糊的空字串。必須使用列舉型別 (Enum) 明確定義 `Not_Present`, `Unknown`, `Not_Applicable`，引導模型學會區分「資訊不存在」與「我不知道」。
  • **將 Ground Truth 視為代碼 (Treat GT as Code)**：Ground Truth 應該像系統程式碼一樣受到嚴格的 Review。它定義了產品的行為準則，任何對 Ground Truth 的修改都等同於修改產品契約。
  • **防禦性評估設計**：Eval 的目標不僅是找出最聰明的模型，更是要淘汰那些「過於自信但容易產生幻覺」的模型。高品質的 Ground Truth 是建立這種防禦機制的唯一基石。
  • **啟動實務循環**：從小批量、包含髒亂資料的真實文件開始，建立包含 Raw/Normalized/Status 的範本。在發現模型表現不佳時，不要急著改 Prompt，先回頭檢查是不是 Ground Truth 的定義自相矛盾了。
Obsidian 整理 原始文章
AI工程

Your LLM Eval Is Only as Good as Your Ground Truth

"無一席話總結"
Top 5 Insights
  • **拆分解構輸出 Schema 以確保可追溯性**：在進行資訊提取（Extraction）任務時，切忌將提取與理解混為一談。應在 Schema 中將單一目標拆解為 `raw_value`（保留原文證據）、`normalized_value`（系統理解與轉換結果）以及 `status`（提取狀態）。這為下游系統除錯與人工審核保留了完整的可追溯證據鏈。
  • **細緻化定義並枚舉「無（Null/Blank）」的語義狀態**：在 Prompt 設計和 Ground Truth 標註中，必須嚴格區分 Missing、Unknown、Not Applicable 與 Inferred。這不僅是資料結構的設計，更是量化和抑制模型幻覺（Hallucination）的關鍵系統機制。
  • **建立具備商業意識的錯誤分級評分機制（Weighted Scoring）**：在構建 Eval 流程時，絕對不應將所有欄位的錯誤一視同仁。對於「幻覺猜測」或「破壞 Schema」等可能導致系統崩潰或信任危機的致命錯誤，應給予嚴厲懲罰；而「可選資訊遺漏」等則視為輕微失誤。透過調整評分權重，將商業風險與產品價值觀直接嵌入評估體系中。
  • **認知轉換：評估即產品決策（Eval-Driven Product Behavior）**：Ground Truth 的制定過程不該外包給不了解產品目標的純標註團隊。你定義了什麼樣的 Ground Truth，設定了什麼樣的評分規則，就是在鼓勵模型產生什麼樣的行為（例如：誠實留白 vs 積極猜測）。這些底層的技術決策，將直接決定終端使用者的產品體驗與信任度。
Obsidian 整理 原始文章
AI工程

Your LLM Eval Log Is More Useful Than Your Final Score

"別再只盯著模型排行榜上的準確率了，一個能追蹤「為何觸發降級」與「人工如何介入」的詳細 Eval 日誌，才是讓 AI 產品進步的真正引擎。"
Top 5 Insights
  • **超越單一模型的評估 (Beyond Model-centric Evals)**：停止只對 LLM 的輸入輸出做簡單比對。必須建立 **Workflow-level Evals**，將 Parser, Schema Validator, Fallback Logic 與 Human Review 全數納入評估追蹤的範圍。
  • **分散式追蹤思維 (Distributed Tracing for AI)**：借鑑微服務的追蹤理念，為每一筆 Extraction 請求建立完整的 Request ID，串聯從文件解析到最終人工審核的所有狀態轉移與決策點。
  • **定義 "Next Fix" 欄位**：在錯誤日誌中強制要求標註 `next_fix`（如改 Prompt, 改 Schema, 改字典）。這能逼迫工程團隊進行 Root Cause Analysis，避免無腦怪罪 LLM。
  • **保護系統免受隱性退化 (Prevent Silent Regressions)**：詳細的 Log 能讓架構師在 A/B 測試時看清全貌。例如發現新 Prompt 雖然提高了總分，卻增加了 Fallback 系統的負載與人工審查的成本，從而做出更明智的權衡。
  • **日誌即產品價值觀 (Log is Product Philosophy)**：架構師設計的 Log Schema，就是產品演進的指南針。確保你的 Log 欄位精準反映了產品最在乎的維度（如：成本、延遲、可追溯性、誠實度）。
Obsidian 整理 原始文章
AI工程

Your LLM Eval Log Is More Useful Than Your Final Score

"無一席話總結"
Top 5 Insights
  • **工作流追蹤 (Workflow Tracing) 是 AI 工程的核心**：現代 LLM 應用已經超越了單一的 Prompt In / Text Out。將分散式追蹤與可觀察性 (Observability) 的概念導入 AI 工作流，記錄從解析、模型路由、降級到人工審查的完整決策路徑，是打造高穩定系統的基礎。
  • **定義「可行動」(Actionable) 的 Eval 指標**：一個優秀的評估系統，其產出不應該只是一個準確率數字，而應該能直接推導出具體的工程行動清單（Next Fix），例如修改 Schema 結構、更新特定字典，或增加邊界路由規則。
  • **日誌驅動的產品迭代 (Log-Driven Iteration)**：開發者決定在 Eval 日誌中追蹤哪些欄位，就決定了產品演進的方向。將抽象的業務需求轉化為日誌中的具體欄位（如 `raw_value_preserved`），能使隱性的問題變得可被衡量與優化。
Obsidian 整理 原始文章
AI工程

Your LLM Eval Needs Confidence Calibration

"LLM 評估不能只看「答案對不對」或「格式漂不漂亮」，必須建立基於證據的「欄位級別信心度（Confidence）」，才能讓工作流安全地決定後續的路由。"
Top 5 Insights
  • **解耦正確性與可靠度**：系統架構設計上，必須將「資料格式正確 (Schema Valid)」與「資料來源可信 (Evidence Backed)」視為兩個獨立的檢查點。
  • **導入防禦性抽取 (Defensive Extraction)**：嚴防模型的「無證據推論 (Unsupported Inference)」。對於核心業務欄位，必須強制要求附帶溯源依據，否則視同無效。
  • **實踐欄位級動態路由 (Field-Level Dynamic Routing)**：揚棄整份文件單一信心度的做法，改用欄位級別的信心度標籤，並將其與系統的降級機制 (Fallback) 和人工審查 (Human-in-the-loop) 工作流直接對接。
  • **建構可觀測性日誌**：針對 LLM 的抽取任務，日誌不只要記錄 Input/Output，必須結構化地記錄 `confidence_label` 與決定此標籤的 `confidence_reason`，以利後續的閉環校準。
Obsidian 整理 原始文章
AI工程

Your LLM Eval Needs Review Calibration

"如果兩個審查員對同一個模型輸出的對錯有不同意見，那不是模型的錯，是你們的「評估契約」寫得不清楚。"
Top 5 Insights
  • **防禦性評估架構**：在設計 LLM Eval 時，必須假設「人類標註是不可靠的」。引入 Calibration Guide，將系統的隱性期望（如「寧可漏抓不准瞎猜」）轉化為顯性、有範例支持的操作手冊。
  • **精細化 Null 處理**：在資料庫 Schema 設計層面，揚棄單一的 `Null` 或空字串來代表「沒有資料」。引入狀態列舉（Enum，如 `Not_Present`, `Unknown`, `Not_Applicable`），以精確捕捉 AI 在面對不確定性時的行為。
  • **擁抱並量化分歧**：在 QA 或標註平台中，設計機制捕捉「Inter-Rater Reliability (評分者一致性)」。將審查員經常產生分歧的欄位，視為 Prompt 最佳化或 Schema 重構的最高優先級目標。
  • **從規則走向自動化**：這份人工的 Calibration Guide 最終的歸宿，是成為「LLM-as-a-Judge」的系統提示詞（System Prompt）與 Few-shot examples，從而在保證校準品質的前提下，實現評估的自動化與規模化。
  • **以案例為中心的知識管理**：校準指南不應是乾巴巴的定義，而應是「邊界案例的圖書館」。一條「不要腦補」的定義毫無意義，附帶「把 INF 變成 infant 算腦補嗎？」的具體判例才具備工程價值。
Obsidian 整理 原始文章
AI工程

Your LLM Eval Needs Review Calibration

"你的 LLM 評估分數之所以不穩定，往往不是因為模型變了，而是因為人類評審的標準沒有對齊。"
Top 5 Insights
  • **建立客觀的錯誤分類體系 (Error Taxonomy)**：在系統架構中處理 LLM 提取結果時，應區分 `not_present_in_document`、`unknown_due_to_low_quality`、`not_applicable` 與 `missing_field` 等狀態，避免模糊的 null/空白值導致業務邏輯誤判。
  • **Schema 設計必須兼顧原始與標準化資料**：針對高精度的資料提取，架構上應同時設計 `[Field]_raw` 與 `[Field]_normalized` 欄位。這不僅能防止資訊遺失，還能確保 LLM 產生的標準化資料有跡可循。
  • **零容忍「無根據推論 (Unsupported Inference)」**：在要求「來源證據」的企業級應用中，必須嚴格防範 LLM 的幻覺或過度推論。系統層面應定義何種資料是允許推論的，何種是嚴格必須直接提取的。
  • **將人工審查契約轉化為 LLM-as-a-Judge 規則**：雖然本文探討的是人工審查校準，但這套「具備實際 Edge Cases 的校準指南」正是撰寫高品質 Prompt 用於自動化 LLM 評估（LLM-as-a-Judge）的最佳藍圖。
Obsidian 整理 原始文章
AI工程
Cover

Your LLM Eval Passes. Your Users Are Churning. Both Are True.

"無一席話總結"
Top 5 Insights
  • **防線分層設計**：採用「零成本的確定性檢測 -> 帶統計信心區間的基準檢測 -> 偏誤校正後的 LLM 評委」的三層架構，可以兼顧評估成本與精確度。
  • **正視統計雜訊**：在測試資料集不夠大時（例如少於 3000 筆），小幅度的指標升降（如 1~2%）沒有統計學意義。工具與架構必須將「最小可偵測效應 (MDE)」視覺化，避免工程團隊在雜訊中打轉。
  • **校正 LLM 作為評委的固有偏誤**：LLM 本身並非真理，不應直接採用其勝率結果。系統設計中應引入 Rogan-Gladen 估計等統計方法，透過少量標註資料動態校準 LLM 評委的特異性與敏感度。
  • **追蹤與評估 Agent 的過程而非僅是結果**：對於多步驟的 Agent 操作，必須建立基於 schema 驗證的幻覺檢測機制，並透過 OTel 等標準化協議對每個推理步驟獨立評分，以確保除錯的粒度。
Obsidian 整理 原始文章
AI工程

Your LLM Eval Set Is a Product Asset

"無一席話總結"
Top 5 Insights
  • **將測試左移至產品行為定義**：LLM 評估不該只是量化分數 (metrics)，而應具象化為各種分類資料夾（如 `do_not_infer`, `routing_decisions`），直接映射到產品必須保護的核心行為上。
  • **負面測試（Negative Testing）是關鍵**：為了防止 LLM 過度熱心造成的幻覺，必須刻意建構缺乏必要資訊的文件，確保系統有能力拒絕回答或上報給人工審查。
  • **架構化與模組化評估**：針對多步驟或多 Agent 的 LLM Pipeline，不應只測試最終輸出，還應將工作流中的「路由路徑選擇」、「原始值保留」等細節獨立設組進行驗證，這有助於精確除錯並提升開發迭代速度。
Obsidian 整理 原始文章
AI工程

Your LLM Eval Set Needs a Manifest

"你的 Eval 測試案例不只要能回答「預期輸出是什麼」，更要能回答「這個案例為什麼在這裡（保護了什麼規則）」。"
Top 5 Insights
  • **將測試集視為資料庫**：停止將測試案例當作靜態檔案存放。引入 Manifest 機制，將 Eval Set 升級為具備 Schema、可查詢的「測試案例資料庫」。
  • **明確測試意圖 (Test Intent)**：每一個進入 Eval Set 的案例，都必須在 Manifest 中明確宣告其「保護了什麼行為」，如：保護特定排版的解析、測試降級觸發條件，或確保模型不產生特定幻覺。
  • **實作智能路由測試 (Smart Rerun)**：在持續整合 (CI) 流程中整合 Manifest 解析，根據修改的模組（Prompt, 程式碼, 字典檔）動態篩選並執行最小單位的迴歸測試，大幅降低 API 成本與等待時間。
  • **防範系統性遺忘**：Manifest 解決了 AI 團隊常見的「人員流動導致測試集作廢」問題，將針對邊界案例的工程知識（Know-how）永久固化在程式碼庫中。
  • **漸進式架構 (Progressive Architecture)**：採用 YAML 或 JSON 格式儲存 Manifest 以利版本控制。初期不必強求欄位完美，重點是建立「每個測試檔都必須有對應詮釋資料」的工程紀律。
Obsidian 整理 原始文章
AI工程

Your LLM Eval Set Needs a Manifest

"無一席話總結"
Top 5 Insights
  • **將 Eval Set 視為具備 Schema 的資料庫**：測試檔案只是 Payload（負載），Manifest 才是 Index（索引）。必須為每一個 Eval 案例建立包含上下文與預期系統行為的元資料，以建立長期的「產品記憶」。
  • **導入 Targeted Reruns（精準重測）策略**：根據變更的維度（如 Prompt, Schema, Routing, Dictionary）透過 Manifest 篩選出特定的測試子集，大幅降低測試時間成本與運算資源浪費。
  • **明確定義邊界與負面行為 (Negative Behavior)**：不僅測試模型「應該萃取什麼」，更重要的是利用欄位如 `do_not_infer_cases` 或 `fallback_expected` 來防範 LLM 的幻覺與過度推論。
  • **敏捷與漸進式的元資料管理**：初期設計應避免欄位過度膨脹，先以 CSV/YAML 記錄最核心的 `eval_group`, `expected_route`, `regression_risk` 等基本欄位，避免阻礙開發者與測試人員新增測試案例的意願。
Obsidian 整理 原始文章
AI工程

Your LLM Eval Set Will Go Stale

"無一席話總結"
Top 5 Insights
  • **Eval Set 不是靜態的基準指標，而是活的系統文物（Living Artifact）。**
  • **建立閉環反饋**：必須將人工審查、Fallback 觸發與生產失敗等實際訊號，結構化地轉化為 Eval 的回歸測試案例。
  • **重視元資料（Metadata）**：在建構 Eval Set 時就應設計標籤機制，確保能隨時對比生產環境的真實分佈與測試集分佈的落差（Distribution Gap）。
  • **貴精不貴多**：勇敢地修剪（Prune）過時的 Eval 案例，並維持一個能反映當前真實風險與邊界條件的精簡測試集。
Obsidian 整理 原始文章
AI工程

Your LLM Eval Should Be a Release Gate

"無一席話總結"
Top 5 Insights
  • **分數陷阱**：在 LLM 應用開發中，絕不能單看 Eval 的平均分數或基準測試（Benchmark）表現來決定上線與否。分數的提升極易掩蓋關鍵欄位的致命退化（Regression）。
  • **多維度的底線防禦**：必須根據產品的「不可妥協行為」（如：零幻覺推論、必須保留溯源 Token、成本上限）建立多維度的阻擋機制（Blocking Failures）。任何變更只要觸碰紅線，即刻拒絕發佈。
  • **全域版本控制**：強烈建議將 LLM 系統的各個組成部分（Prompt, Model, Schema, Routing）與 Eval Gate 本身都進行嚴格的版本控制，確保每個決策在未來都有跡可循。
  • **價值導向的架構迭代**：不需要等到有完美的自動化 MLOps 平台才實施 Eval Gate。從一份簡單的 Markdown 檢查清單開始，讓「是否安全到可以上線？」成為團隊每次變更前必須回答的唯一問題。
Obsidian 整理 原始文章
AI工程

Your LLM Eval Should Create Work Items, Not Just Scores

"無一席話總結"
Top 5 Insights
  • **擺脫分數迷思**：LLM 評測工具不該只產出準確率排行榜，而應產出具體指明系統缺陷的 Issue / Ticket。
  • **精細化層級歸因**：LLM 應用的除錯需要全端思維，錯誤可能來自文件解析（Parser）、提示詞（Prompt）、資料結構（Schema）、資料後處理（Dictionary）或路由機制（Routing），不要一味歸咎於模型本身。
  • **閉環驗證設計**：任何修改都必須帶有「局部重跑條件（Rerun condition）」與「量化的決策規則（Decision rule）」，確保修復 A 問題時不會造成 B 指標的嚴重 Regression。
  • **投資報酬率（ROI）導向的修復**：維護 Schema 欄位和新增 Fallback / Review 路由都有成本。系統架構師應依據業務價值（下游使用情況）與錯誤嚴重性，主動忽略邊緣或無影響的失敗。
Obsidian 整理 原始文章
AI工程

Your LLM Eval Should Measure Correction Effort

"LLM 評估不應只看「對或錯」，更要看「人類修正這個錯誤有多難」。"
Top 5 Insights
  • **評估框架的典範轉移**：在 Human-in-the-loop 的 AI 系統中，`Accuracy` 只是及格線，`Mean Time To Correct (MTTC)` 或 `Correction Effort` 才是決定產品營運成本的核心指標。
  • **Fail Loudly 的系統設計**：在撰寫 Prompt 或微調模型時，應強烈懲罰「在低信心度下進行無根據推論 (Unsupported inference)」，並鼓勵模型在不確定時直接留白或拋出明確的低信心度標記。
  • **溯源能力 (Traceability) 是標配**：LLM 的 JSON 輸出必須強制包含溯源 Metadata（如頁碼、段落或原始字串）。缺乏證據連結的純預測值會造成極高的審查成本，應視為架構上的 Anti-pattern。
  • **建立成本感知的回饋迴圈 (Cost-aware Feedback Loop)**：將使用者的「修正耗時」與「修正動作」記錄下來，不僅用於評估，更應成為後續優化 Prompt、調整 Schema 規則或訓練 Reward Model 的關鍵訓練資料。
Obsidian 整理 原始文章
AI工程

Your LLM Eval Should Measure Correction Effort

"你的 LLM 評估不該只問「模型對了嗎？」，還必須問「人類修復這個錯誤有多難？」。"
Top 5 Insights
  • **重新定義 ROI**：將「LLM Eval」從單純的模型能力測試，升級為系統整體的 TCO (Total Cost of Ownership) 評估。必須將 Human-in-the-loop 的時間成本量化並納入考量。
  • **設計「大聲失敗」的架構**：在 Prompt 設計與系統架構上，應鼓勵模型「寧可留白並發出警告，也不要為了交差而捏造看似合理的資料」。隱蔽的幻覺是營運的毒藥。
  • **強迫輸出證據連結 (Traceability)**：將「可追溯性」作為輸出 Schema 的必備欄位。任何關鍵資料的提取，都必須附帶引用的原始段落，以此作為降低審查成本的基礎設施。
  • **建立難度回饋迴圈**：在人工審查介面中，收集錯誤修復的耗時或主觀難度標籤（Low/Medium/High）。將這筆資料回饋給 Eval 系統，藉此發現那些「發生頻率不高，但一發生就癱瘓審查流程」的致命邊界案例。
  • **改變優先級權重**：修復成本改變了 Bug 修復的優先級。一個頻繁發生但 1 秒能改好的可選欄位錯誤，其修復優先級應低於一個罕見但需耗費 5 分鐘查證的關鍵欄位幻覺。
Obsidian 整理 原始文章
AI工程
Cover

一个人，管理开发5款产品，而且80% 时间不在写代码，靠这一步...

"將每一次除錯與新功能的經驗，寫入系統的 AI 操作手冊（CLAUDE.md 與方案庫），讓 AI 成為越用越聰明的自動化開發團隊。"
Top 5 Insights
  • **AI 驅動的知識管理 (AI-Driven Knowledge Management)**：架構師應推動團隊建立機器可讀的知識庫（如 `CLAUDE.md`），讓 AI 開發助手能夠學習團隊的特定領域知識與架構決策，而非僅依賴通用模型能力。
  • **職責轉移：從實作到設計與審查**：隨著 AI 代碼生成能力的提升，工程師的核心價值正式轉向「架構設計 (Plan)」與「代碼審查/驗證 (Review)」。團隊應重新分配時間比例，追求 80/20 法則的落地。
  • **多維度併發審查 (Multi-dimensional Concurrent Review)**：建構或引入類似 14 個專項 Agent 的機制，在 CI/CD 流程或本地開發階段，針對資安、效能 (如 N+1 查詢)、資料完整性與架構邊界進行並行掃描，大幅降低人工 Review 的負擔與盲點。
Obsidian 整理 原始文章
AI模型
Cover

Claude Fable 5: Hidden Features Most People Have No Idea About.

"Anthropic 釋出的首個 Mythos 級別公開模型 Claude Fable 5，不僅擁有多數人不知道的 10 項驚人隱藏能力，更展現了從「解決問題」到「自主建構工具來解決問題」的質變。"
Top 5 Insights
  • **Insight 1**: Claude Fable 5 已經超越了傳統的對話型 LLM，展現出多步推理、系統建構與自主執行任務的 Agent (代理) 能力（如自主遊玩 Factorio 或進行 50M 行代碼遷移）。
  • **Insight 2**: 掌握高階提示詞（Prompt Engineering）的核心在於「要求模型展現思考過程與建立系統」，而非單純給出答案。例如在給予建議前要求其先建立「變數與回饋迴路模型」。
  • **Insight 3**: 在享受模型強大能力的同時，企業與開發者必須將 30 天的資料保留期納入資安與隱私合規的考量之中，能力越大，伴隨的監管妥協也越深。
Obsidian 整理 原始文章
AI模型
Cover

LongCat-2.0 深度技术解读

"在國產晶片顯存與頻寬受限的環境下，LongCat-2.0 透過 LSA 解決長文本瓶頸、N-gram Embedding 聰明擴充參數，並以極限的 6D 並行與容錯工程，成功訓練 1.6 萬億參數的 MoE 大模型。"
Top 5 Insights
  • **極限硬體約束驅動創新**：LongCat-2.0 的成功證明，在顯存、頻寬皆受限的硬體上，透過 6D 並行、超節點與底層算子優化，依然能訓練出世界級萬億參數模型。
  • **軟體架構層面的靈巧解法**：LSA（解決長度瓶頸）與 N-gram Embedding（不增加稀疏度的參數擴展）展示了如何以算法優化補足硬體算力短板。
  • **「確定性」與自動化容錯是基石**：在數萬張卡的叢集中，算子層級的「比特翻轉檢測」與端到端的自動容錯切流，是達成「全程無回滾」與穩定收斂的核心工程保障，值得所有超大規模分散式系統借鑒。
Obsidian 整理 原始文章
AI視野
Cover

BestBlogs 早报 · 07-02｜本地 AI 补齐工程栈，LongCat 万亿模型落地国产算力，美图讲 AI 应用方法论

"AI 的競爭已經從「誰的模型大」轉變為全鏈路的工程比拼：在本地端缺的是 Agent 基礎設施，在雲端缺的是萬億參數的算力訓練穩定性，在應用端拼的是 1 個月上線試錯的組織中台能力。"
Top 5 Insights
  • **模型不再是唯一壁壘**：隨著開源模型的逼近，系統架構師應將精力從「微調模型」轉向構建穩健的 Agent 外圍工程棧（如檢索、工具路由、容錯處理）。
  • **軟硬協同的極致榨取**：美團的案例證明，在國產算力環境下，透過自研算子與通信優化提升 MFU，是實現萬億參數模型工程落地的必經之路。
  • **中台化是 AI 敏捷落地的基石**：美圖能實現「1個月上線、不導流試錯」的底氣，在於底層堅實的影像與增長中台。AI 時代的應用開發必須依賴 Platform Engineering 來降低單次試錯的沈沒成本。
  • **確定性與非確定性的融合**：如 Google ADK 2.0 所示，生產級的系統架構必須明確界定哪裡交給 LLM 發揮（非確定性），哪裡必須由傳統代碼兜底（確定性），兩者的混合運行時是未來的標配。
Obsidian 整理 原始文章
Agent架構
Cover

20 Loop Design Patterns Every AI Engineer Should Know

"無一席話總結"
Top 5 Insights
  • **從 Prompt 工程轉向 Loop 工程**：最強大的 AI 系統不依賴完美的初始提示詞，而是依賴「生成→評估→學習→改進」的反覆運算。
  • **解耦生成與評估角色**：讓系統兼具「產生想法 (Generator)」與「嚴格審查 (Critic/Evaluator)」的雙重角色，是提升品質的最快途徑。
  • **系統的記憶管理至關重要**：不僅要儲存失敗經驗（Error Library），也要儲存成功經驗（Success Pattern），並定期壓縮記憶（Memory Compression），使系統越用越聰明。
  • **設計具備自我適應能力的工作流**：不要寫死管線（Fixed Pipelines），應該引入動態分支與自我效能評估，讓管線在運行時能依據成本、延遲與品質自我重構（Workflow Optimization）。
Obsidian 整理 原始文章
Agent架構
Cover

9 out of 10 people who use Claude have never built a loop

"無一席話總結"
Top 5 Insights
  • **架構典範轉移**：高槓桿的系統設計已從優化單一 Prompt，轉移到設計由 Trigger、Memory、Skill、Checker 與 Gate 組成的自動化 Agent 迴圈。
  • **Maker-Checker 職責分離模式**：AI 對自我產出存在盲點。高可靠度系統必須將「生成內容」與「驗證內容」的 Agent 進行分離，配置不同的嚴格度與指令。
  • **客觀的守門機制 (Gate) 是系統底線**：沒有客觀的通過/失敗測試（如 Linter、編譯器或數值指標），系統就只是在盲目附和，無法保證品質，也無法成為真正的自動化流程。
  • **狀態外部化 (State Externalization)**：迴圈的持續進化與斷點續傳仰賴外部狀態文件 (`STATE.md`) 記錄進度與經驗教訓，解決了 LLM 跨會話失憶的問題。
  • **嚴格的邊界控制與監控**：建構迴圈必須設立硬性的停止條件（防呆機制），並以「接受率 (Accept Rate)」與「單位變更成本」作為衡量該迴圈架構是否具有商業價值的核心指標。
Obsidian 整理 原始文章
Agent架構
Cover

AI Agents Need Alignment, Not Prompts. I Built AI Runtime Governance Layer.

"AI 代理需要的是確定性的執行期治理閘門，而不是容易被繞過的 Prompt 提示詞建議。"
Top 5 Insights
  • **安全邊界的物理隔離**：在架構設計上，AI 模型本身不該直接持有執行高風險操作的最終權限。必須在 Intent (意圖) 與 Action (執行) 之間建立由非 AI 邏輯 (Rule Engine 或形式化驗證) 控制的 Middleware 攔截點。
  • **Prompt Engineering 無法解決 Security 問題**：將安全規則寫入 System Prompt 在資安防護上形同虛設，必須透過程式碼層級的 Policy Guard 才能抵禦 Prompt Injection 等攻擊。
  • **零延遲的決策攔截**：`chimera-compliance` 將政策引擎部署於本地端 (Local Evaluation)，避免了分散式架構中 Policy Engine 導致的額外網路延遲 (Network Hop)，這是打造高併發 Agent 系統的重要架構決策。
  • **審計軌跡 (Audit Trail) 的不可變性**：為了迎合 EU AI Act 等法規，未來所有的 Agent 架構都必須內建 Append-only 的 Log 系統，並詳細記錄每次決策的上下文 (Context) 與觸發的規則 (Rule)。
Obsidian 整理 原始文章
Agent架構
Cover

Agentic Engineering 概念（上）：Agent 的底层逻辑

"Agent 工程化的核心不在於追求最新框架，而在於掌控迴圈、定義狀態邊界與設計協作模式。"
Top 5 Insights
  • **控制狀態邊界**：清楚區分「Context Window」與「外部持久化存儲」。Agent 無法處理未顯式載入上下文的資料，確保只注入任務必需的最少資訊。
  • **實施關注點分離**：對於複雜任務，避免使用單一的全能型 Agent，應採用 Router/Specialist 或 Planner/Executor 模式，降低單點失效風險並優化成本。
  • **配置即代碼 (Config as Code)**：將 `AGENTS.md` 視為系統核心代碼，實行嚴格的行數限制與優化；避免輸入冗餘的通用開發守則，轉而提供具體的指令與約束。
  • **優化 Token 經濟學**：利用 Prompt Caching 技術處理穩定的全局上下文，並主動防範「上下文漂移」，以確保模型在長時任務中的推理精準度不衰減。
Obsidian 整理 原始文章
Agent架構
Cover

BestBlogs 早报 · 07-01｜Sonnet 5 发布，谷歌补齐媒体模型，吴恩达画出智能体开发三循环

"隨着模型成本下探與能力補齊，Agent 開發的核心已從「模型夠不夠強」轉向「如何透過工程與反饋迴圈讓 Agent 產品可持續發展」。"
Top 5 Insights
  • **大腦降級與普惠化**: Sonnet 5 證明了具備強大 Agent 規劃與工具調用能力的模型成本正在劇降，架構師應評估將生產環境中的預設鏈路遷移至平價高效模型，保留昂貴模型 (如 Opus) 處理極端高精度任務。
  • **多媒體管線端到端落地**: 透過結合 Nano Banana 2 Lite 的極低成本圖像生成與 Omni Flash 的會話式影片編輯，企業可建構穩定且經濟的多媒體 AI 生產管線，將迭代成本控制在對話上下文中。
  • **Harness 駕馭工程與專才架構**: 在設計系統架構時，應遵循「Agent = Model + Harness」原則。摒棄全能型 Agent 的幻想，轉而設計上下文精簡、狀態落盤且約束明確的專才型 Agent，以提升系統的準確率與可調性。
  • **工程師角色轉型**: 開發團隊應落實吳恩達的「三層循環」框架，認知到在編碼自動化的趨勢下，工程師的核心價值已從「程式碼產出」轉移至「領域上下文判斷」與「系統邊界決策」。
Obsidian 整理 原始文章
Agent架構
Cover

BestBlogs 早报 · 07-03｜用协议对象拆 Agent Runtime，四层嵌套讲清企业 Agent 落地，再加自我改进外环

"無一席話總結"
Top 5 Insights
  • **基於協議對象的架構抽象**：不要追逐框架名詞，請以 Thread, Run, Step, Event, Artifact, Checkpoint 這 6 個穩定對象為核心，來設計或評估任何 Agent Runtime 系統。
  • **狀態持久化是生產級系統的基石**：沒有可靠的 Checkpoint 機制，就沒有所謂的超時控制、任務取消或可觀測性，系統永遠只能停留在玩具階段。
  • **遵循四層嵌套工程範式，切勿跳級**：Prompt (L1) $\subset$ Context (L2) $\subset$ Harness (L3) $\subset$ Loop (L4)。在沒有穩固的 L3 Harness 之前，強行上馬 L4 Loop 只會自動化並放大系統錯誤。
  • **Error-as-Data 取代 Error-as-Exception**：在 Agent 的執行鏈路中，將錯誤視為資料流的一部分，這對於保證狀態乾淨以及實現可靠的中斷恢復 (Resume) 至關重要。
  • **內外環分離與基於 Signals 的自我進化**：將用戶互動的 Inner Loop 與負責系統優化的 Outer Loop (Autoresearch) 區隔開來；構建自我進化能力的關鍵不在於模型的智商，而是在於是否定義了能正確捕捉系統表現的 Signals 與 Eval Recipe。
Obsidian 整理 原始文章
Agent架構
Cover

Building AgyQueue — An Asynchronous Execution Layer for AI Agents (Part 1)

"AI Agent 不應該像個埋頭苦幹的工人一樣被耗時任務卡死，而是要像個專案經理，發派任務後立刻回報進度，讓非同步佇列 AgyQueue 去完成繁重工作。"
Top 5 Insights
  • **同步設計是生產環境 Agent 的毒藥**：要求 LLM 同時負責決策與等待長耗時操作完成，將導致系統脆弱、連線超時，無法應用於真實世界的企業級任務（如 CI/CD 與基礎架構部署）。
  • **關注點分離 (Separation of Concerns) 必須延伸至 AI 領域**：架構師必須將「推理 (Reasoning)」與「實體執行 (Execution)」明確拆分。AI Agent 應扮演發號施令的專案經理，透過發放 `task_id` 來非同步追蹤背景 Worker 的執行狀況。
  • **AI 專屬佇列的必要性**：傳統如 Celery 的 Task Queue 無法完全涵蓋 AI Agent 的需求。生產級的系統需要原生支援 MCP (Model Context Protocol)、工作區環境隔離、以及能暫停等待人類審批 (Human-in-the-loop) 的特殊設計。
  • **雲端原生架構的高度適配性**：這種非同步拆分架構能完美地映射到現代 Serverless 與容器化架構（如 Cloud Run, Pub/Sub, Cloud SQL），確保系統可以從單機無縫擴展至企業級雲端環境。
Obsidian 整理 原始文章
Agent架構
Cover

Building an Agentic RAG with BM25 + an LLM Eval Harness (No Vector DB)

"拋棄昂貴的向量庫與盲目的 RAG，用老派的 BM25 搭配細緻的分桶評分，建立一個真正可以被量化與信任的 Agent。"
Top 5 Insights
  • **Evaluation 才是工程的核心**：建構 RAG 的困難不在於腳本或資料庫的串接，而在於建立一個能穩定度量系統好壞的 Eval Harness。作者花在評估框架上的時間是 Agent 本身的兩倍。
  • **專業領域 RAG 不必執著於 Vector DB**：在使用者術語與文件詞彙高度重疊的場景下，BM25 是極佳的選擇。它不僅便宜（無雲端成本）、輕量，且具備完全的可解釋性。
  • **分離「檢索」與「生成」的評分訊號**：LLM-as-a-Judge 必須精心調校，並設計出能容納邊界情況（如 `0.9` 桶的「答對但找錯」）的標準，否則評估將淪為無效的「感覺測試 (Vibe check)」。
  • **Chunking 策略具備領域依賴性**：沒有一體適用的文件切分策略。技術文件的結構與散文/哲學書籍截然不同，必須依賴可靠的 Eval 數據來決定哪種 Chunking 對特定語料庫最有效。
Obsidian 整理 原始文章
Agent架構
Cover

Building an Autonomous UI Agent Critic with the New Google Antigravity SDK 2.0

"無一席話總結"
Top 5 Insights
  • **工程師角色轉化**：AI Agent 處理了「無聊的中間層」(如專案建置與環境設定)，工程師必須從依賴打字速度，演化為具備「架構動能」的**導演、審閱者與產品思考者**。
  • **治理與安全擴展 (Governed Extensibility)**：Antigravity SDK 透過策略引擎 (Policies) 與生命週期鉤子 (Hooks)，使得企業級的自主 AI 工作者不僅能自動化，還能保持在嚴格的架構護欄與安全規範內。
  • **多模態與 MCP 的無限可能**：視覺能力結合第三方工具協議 (Playwright MCP)，打破了文字模型對外互動的限制，實作出能真正「看」並「操作」UI 的自動化檢驗系統。
Obsidian 整理 原始文章
Agent架構
Cover

Claude Code 的 goal 和 loop，很多人没用过的最强功能

"無一席話總結"
Top 5 Insights
  • **核心操作單元升級**：AI 編程範式正從「逐條 Prompt 驅動」向「Loop 循環驅動」演進，開發者的角色應轉移至更上游的「循環結構設計」與「成功標準定義」。
  • **驗證機制的編碼化**：任何高級 Loop（如 Goal-based 或 Proactive）的成功前提，是具備強健的、自動化的本地驗證機制（如 `SKILL.md` 中的檢查清單、腳本）。
  • **退出條件的量化**：將目標從模糊的自然語言轉化為精確的、可測量的工程指標（如 Lighthouse 分數），是 Agent 能夠自主完成迭代的關鍵。
  • **防禦性架構設計**：在引入主動式和並行工作流時，必須具備成本意識，採用「先小規模驗證、後放大」的策略以控制 Token 消耗風險。
Obsidian 整理 原始文章
Agent架構
Cover

How To Master Fable (Fundamentals Guide)

"Fable 5 是專為長時間、目標導向的自動化工作流而設計的 AI 模型，透過 Loop Engineering 與自建的記憶系統，能將繁瑣任務委託給自主代理執行。"
Top 5 Insights
  • **從單一提示走向分散式代理架構**：不再依賴單次的高手動 Prompting，而是透過 Fable 5 作為主控制器（Master Controller），配置 Sonnet/Haiku 子代理處理繁瑣任務的 `Barbell Strategy`，實現成本與效率的系統級平衡。
  • **無狀態到有狀態的進化**：透過本地建立 `claude-memory.md` 並配置自更新指令（Self-updating instruction），成功將 Agent 轉換為具備持久化狀態（Persistent State）的系統，大幅提高長期任務的準確性。
  • **事件驅動與排程執行**：靈活運用 `/goal`（達標即止）與 `/loop`（定期觸發）構建微型自動化 Pipeline，將人類介入降至最後的決策簽核層，實現真正的 10x 生產力突破。
Obsidian 整理 原始文章
Agent架構
Cover

How to Build a Claude Code Agent Team That Runs in Loops (Exact Setup Inside)

"把「球員（Builder）」和「裁判（Checker）」分開，並讓他們在有限的迴圈中互相拉扯，直到程式碼真正能跑為止。"
Top 5 Insights
  • **分離生成與判別機制 (Generator-Discriminator Pattern)**：在 AI Agent 系統設計中，將「修改程式碼」的工具權限與「運行測試」的工具權限分給不同的 Agent，能有效打破 LLM 給自己打高分的護航盲點。
  • **建立系統邊界 (System Boundaries)**：LLM 缺乏「放棄」的判斷力。實作硬性的防護網（如：最多 5 次、同個錯誤兩次就停、禁止削弱測試），是讓 Agent 系統從玩具走向工程實用的關鍵。
  • **標準化錯誤傳遞介面 (Standardized Error Interface)**：Checker 被嚴格要求不能統整或重寫錯誤訊息，必須直接複製 `file:line` 與實際 Error，這能最大化 Builder 的 Debug 命中率。
  • **信任自動化工具而非 LLM 判斷**：Checker Agent 的核心不依賴 LLM 的「閱讀理解」來抓蟲，而是純粹依賴既有的 `tsc`, `lint`, `test` CLI 工具的退出碼與輸出。將驗證工作交還給確定性系統（Deterministic Systems），是提升系統可靠度的最佳實踐。
Obsidian 整理 原始文章
Agent架構
Cover

How to Build an OS for Your AI Workforce?

"管理多個 AI Agent 在生產環境中運行是一個維運問題，我們需要一個「Agent OS」作為指揮中心，而非只是更好的建構框架。"
Top 5 Insights
  • **基礎設施的成熟度已成為瓶頸**：阻礙 AI Agent 企業級落地的核心已不再是 LLM 的模型能力，而是缺乏能夠在生產環境中規模化部署、管理與治理的「維運管理層（Operations Layer）」。
  • **區分 Builder 與 OS 的邊界**：架構設計時必須明確劃分「建構 Agent 的工具（如 LangChain/Dify）」與「統籌多 Agent 協作的 OS」。Agent OS 的核心價值在於資源仲裁、權限隔離與全局審計。
  • **Platform Engineering 視角介入**：在導入 AI Agent 平台時，必須跳脫單一開發者視角，納入維運主管（Ops Lead）、合規專員（Compliance Officer）與產品經理的使用需求，將 Governance 與 Audit Trail 視為 Day-1 的必備架構要素。
  • **組合性與共享狀態是關鍵**：未來的 AI 勞動力必須具備高度可組合性（Composability）。架構師應致力於打造 Workspace-level 的共享記憶體、憑證管理與工具庫，確保不同的 Agent 任務之間能夠平滑地轉交與繼承上下文。
Obsidian 整理 原始文章
Agent架構
Cover

How to make AI agents behave like actual employees

"無一席話總結"
Top 5 Insights
  • **從同步等待轉向異步狀態機 (Asynchronous State Machine)**：
  • **實作強制的安全簽核閘道 (Mandatory Approval Hooks)**：
  • **分層的協調架構 (Hierarchical Coordination)**：
  • **狀態持久化與長事務管理 (State Persistence for Long-running Tasks)**：
Obsidian 整理 原始文章
Agent架構
Cover

I Made My Hermes Agent 10x Faster Without Changing the Model

"透過為每個主要資料夾建立 INDEX.md 導航地圖與編號結構，可將 AI Agent 尋找上下文的時間縮短 10 倍以上。"
Top 5 Insights
  • **系統級別的優化優於模型升級**：在追求更強的 LLM 之前，先優化系統周邊的「鷹架 (Scaffolding)」，因為不良的檔案結構會嚴重消耗 AI 的能力。
  • **以機器為本的目錄架構 (Machine-centric Hierarchy)**：人類思維依賴自動化的交叉連結，但 Agent 需要明確的指標。利用數字排序與專責的 INDEX.md 檔案，為 Agent 提供強制的「軟審批關卡」，能將檢索效率提升數量級。
  • **層級扁平化 (Flattening Hierarchy)**：深度是快速查詢的敵人。減少資料夾巢狀層次，並避免過度工程化（如在微型資料夾內佈建索引），是維持系統低延遲的關鍵實踐。
  • **資料冷熱分離**：明確隔離出歸檔資料 (Archived)，並在地圖中標示其位置，能防止 Agent 受噪音干擾，同時又保留追溯歷史脈絡的能力。
Obsidian 整理 原始文章
Agent架構
Cover

Introducing OpenWiki, an open source agent for repo documentation

"OpenWiki 是一個開源 CLI 與 Agent 工具，透過自動生成專案 Wiki 並動態更新 `AGENTS.md`，為 AI Coding Agent 提供即時、結構化的程式碼庫上下文，解決了大型專案中文件難以與程式碼同步的問題。"
Top 5 Insights
  • **反轉 RAG 模式**：OpenWiki 本質上是一個具象化的 RAG 前置處理器。與其在 Runtime 才做程式碼的 Chunking 與 Embedding，不如提前由 AI 解析程式碼，生成結構化、人類與 Agent 都能閱讀的 Wiki，有效降低 Runtime 檢索的雜訊。
  • **Context Routing 設計**：架構師在設計 AI 輔助開發流程時，應捨棄「巨型 Prompt」的思維，轉而擁抱「Prompt Routing / Context Routing」。利用 `AGENTS.md` 作為路由表，將實體文件存放在次級目錄。
  • **自動化的最後一哩路**：將文件更新從「開發者的手動任務」轉變為「CI/CD Pipeline 的自動構建產物」。這種基於 Git Diff 的增量更新機制，是未來維護大型軟體資產的重要基礎建設。
Obsidian 整理 原始文章
Agent架構
Cover

Loop Engineering: Build an AI That Codes While You Sleep

"不要在手動 Prompt AI 寫代碼了，你應該設計一個自動 Prompt AI 的迴圈 (Loop)，並為它裝好煞車系統。"
Top 5 Insights
  • **擁抱 Loop Engineering**：將 Agent 視為可編排的微服務，透過 State, Automations, Worktrees, Skills, Connectors, Sub-agents 構建自動化的後台工作流。
  • **狀態持久化與合約化目標**：使用 `STATUS.md` 保存跨運行的上下文；利用可量化的指標（如 CI green、Lint clean）作為終止條件（`/goal`），避免 Agent 陷入無意義且昂貴的隨機遊走。
  • **隔離與職責分離**：使用 Git Worktree 隔離並發任務，並強制分離「實作 (Maker)」與「審核 (Checker)」的 Agent，透過對抗式審查（Adversarial reviewer）提升代碼質量。
  • **煞車系統優先**：在部署任何無人看管的迴圈前，必須設定強制步數上限 (`--max-turns`)、階段預算上限 (`--max-budget-usd`) 以及爆炸半徑限制，嚴防遞迴失控與天價 API 帳單。
  • **警惕認知債務 (Comprehension Debt)**：保持對代碼庫的掌控力。系統必須保留「人類審查 (Human-read gate)」的環節，確保迴圈的高效運作不會剝奪工程師對系統架構的理解與判斷力。
Obsidian 整理 原始文章
Agent架構
Cover

Loop Engineering: Four Loops That Actually Works

"打造真正有用的 AI Agent 迴圈，關鍵不在於讓它無所不能，而在於為它設定無法造假的客觀驗證標準與嚴格的煞車邊界。"
Top 5 Insights
  • **無驗證與煞車，則無自動化**：將自動化迴圈視為一項工程系統，必須建立在客觀的退出條件 (Exit Code) 與嚴格的資源邊界 (預算/次數上限) 之上。
  • **狀態分離優於 Context 堆疊**：在迴圈設計中，讓狀態保存在檔案系統或 Git 歷史中，讓每一次 Agent 的迭代都從一個乾淨的 Context 開始，能有效避免模型降級與 Context Window 的浪費。
  • **引入 Maker-Checker 對抗模式**：對於高風險的程式碼修改，單一 Agent 無法客觀評估自身產出。使用雙 Agent 架構（執行者修改，更強的模型負責嚴格審查），能大幅提升自動化修改的可靠性。
  • **依照驗證的客觀程度調整人類介入時機**：驗證越客觀（如測試紅綠燈），自動化程度可以越高；驗證越主觀（如文件修改、摘要品質），就必須將「提出 PR」或「提供報告供審閱」作為煞車機制，讓人為決策留在迴圈中。建議從具備絕對客觀驗證標準的小任務開始建立信任。
Obsidian 整理 原始文章
Agent架構
Cover

MCP Server Architecture Patterns for LLM-Integrated Applications (MCP 伺服器架構模式)

"這是一本將 MCP (Model Context Protocol) 伺服器設計標準化為五大架構模式與四大反模式的實戰指南，幫助開發者解決 LLM 工具列舉、狀態管理與系統聚合的難題。"
Top 5 Insights
  • **MCP 設計本質上是 API 設計的反轉**：傳統 API 假設工程師會看文件，但 MCP API 的客戶端是 LLM，LLM 只能透過工具名稱和自然語言描述來「猜測」功能。因此，精確、資訊密集的描述是系統運作的核心基石，而非事後補充的註解。
  • **嚴守工具數量預算 (Tool-Count Budget)**：不要在單一 Context 中塞入超過 10~15 個工具。如果系統過於龐大，必須實作 Retrieval-over-tools（Scoped Proxy Aggregator）動態載入工具集。
  • **降低 LLM 認知負擔為首要任務**：不要讓 LLM 處理複雜的中間狀態或瑣碎的 API 調用。善用 **Tool Orchestrator** 封裝工作流，並使用 **Domain-Specific Adapter** 翻譯機讀代碼與模糊錯誤，這能顯著提升系統的穩定度與執行成功率。
  • **重視基礎建設 (Cross-Cutting Concerns)**：所有對外的 MCP 工具都必須在 Gateway 層實作輸入輸出的 Sanitization；任何需要跨輪操作的流程都應引入 Session 狀態管理；日誌（Log）中必須包含 tool_name, input_hash, latency 等，這是除錯 LLM 行為異常的唯一途徑。
Obsidian 整理 原始文章
Agent架構
Cover

Specification 即协议——当文档成为代码的「事实来源」

"無一席話總結"
Top 5 Insights
  • **確立 Spec-First 架構思維**：在 AI 時代，必須將 Specification 視為唯一的 Source of Truth，程式碼只是其執行結果。架構師應專注於撰寫精確的結構化自然語言規範。
  • **建立跨 Agent 配置文件標準**：盡早在專案根目錄引入 `AGENTS.md` 或 `CLAUDE.md` 等機器可讀的 manifest 文件，作為專案的運行時上下文與外部記憶系統，為多重 AI 工具鏈預埋基礎設施。
  • **將 Spec 視為 API Contract**：把需求文件當作與 Agent 之間的 API 契約來設計。內容必須清晰到沒有誤解空間，明確回答 Agent 執行的三大問題：「做什麼」、「怎麼做」、「做對的標準是什麼」。
Obsidian 整理 原始文章
Agent架構
Cover

The Only Loop Engineering Roadmap You Need to Build Production-Ready AI Agents!

"建立可靠的 AI Agent 迴圈不是 AI 模型能力的問題，而是傳統系統設計與工程邊界的問題。"
Top 5 Insights
  • **建立客觀驗證防線**：Agent 的能力天花板取決於驗證器 (Verifier) 的可靠度。優先選擇那些能透過 CI、Linters 或自動化測試給出決定性 (Deterministic) 結論的任務來進行自動化。
  • **落實狀態持久化與資源限制**：Agent 迴圈必須具備中斷恢復能力 (Checkpoints)，並且必須在系統層級設立 Token 預算、最大重試次數與權限邊界，防止無限樂觀的盲目重試與資源耗盡。
  • **強制執行職責分離 (Separation of Concerns)**：絕不能讓生成程式碼的模型同時扮演最終決策者。必須拆分為 Worker (提出解法)、Checker (邏輯審查) 以及 Deterministic Verifier (執行驗證)，由系統而非模型決定迴圈是否終止。
  • **警惕「理解債」的累積**：在追求吞吐量的同時，必須衡量團隊的認知頻寬。對於高風險領域 (如核心架構與金流)，必須強制定義人工介入 (Human-in-the-loop) 節點，防止團隊失去對系統底層運作的掌控能力。
Obsidian 整理 原始文章
Agent架構
Cover

What is Loop Engineering? How it is different than Harness Engineering?

"Loop Engineering 是建立在 Agent Harness 之上，透過動態評估與 Maker/Checker 分離機制，讓系統能自主決定執行步驟與停止條件的高階編排模式。"
Top 5 Insights
  • **系統架構的職責分離**：Harness Engineering 提供單一 Agent 穩定、具備狀態記憶的執行容器；而 Loop Engineering 則是更高階的控制平面，負責協調任務排程、跨 Agent 溝通與動態決策。
  • **動態驗證 (Maker/Checker) 模式**：Loop 的核心價值在於透過 `/goal` 原語，引入了獨立的 Checker 模型來評估任務的完成度，實現了執行與驗證的分離，讓系統具備自主驗證與停止的能力。
  • **狀態持久化外置**：由於 LLM 對話存在上下文長度限制與遺忘特性，長期任務的狀態 (State) 必須被抽取出來，持久化到外部媒介（如 Git Repo 的 Markdown 或是 Issue Tracker），以此作為 Loop 運作的 Single Source of Truth。
  • **避免過度工程 (Cost-Aware Design)**：Loop Engineering 的 Token 成本極高。架構師應嚴格把關，不應將能用決定性 (Deterministic) 腳本毫秒級完成的任務，包裝成需要模型反覆思考的 Loop，Loop 應專屬於需要 Runtime 動態判斷的複雜情境。
Obsidian 整理 原始文章
Agent架構
Cover

What is Loop Engineering? How it is different than Harness Engineering?

"無一席話總結"
Top 5 Insights
  • **釐清層級架構**：Harness 是單一 Agent 的執行環境與防呆機制；Loop 則是跨 Agent、跨時間的控制平面與編排器。兩者不可混為一談，且缺一不可。
  • **引入獨立驗證機制 (Maker/Checker)**：Loop Engineering 最大的架構創新在於 `/goal` 原語，將執行任務的模型與驗證任務是否完成的模型分離，建立可靠的停止條件。
  • **避免過度工程 (Over-engineering)**：如同不是所有函式經重構成微服務，只有在「運行時需要高度動態判斷」的場景才應該使用 Loop，否則簡單的確定性腳本（Bash/Python）才是最具成本效益的選擇。
  • **務實的實踐路徑**：不要一開始就盲目建構 Loop 系統。應先透過手動 Prompt Agent 處理日常任務，仔細觀察其失敗點、消耗的 Token 成本以及需要人工介入判斷的地方，基於這些真實痛點來設計你的 Loop。
Obsidian 整理 原始文章
Agent架構
Cover

Your AI Agent Doesn’t Need LangChain — It Needs These 3 Decisions

"褪去框架的包裝，AI Agent 只是個在應用程式管理的迴圈中，不斷接收對話紀錄、執行工具並將錯誤與結果回傳給模型的過程。"
Top 5 Insights
  • **無狀態本質與狀態管理**：LLM 本身不記得任何事情。Agent 架構的核心設計之一，是應用程式（而非模型）必須承擔起完整對話歷史（包含工具輸入與輸出）的狀態管理責任。
  • **控制反轉：以 Exception 作為 Sensor**：不要讓工具執行的失敗終止系統。將 Exception 攔截並轉化為結構化的 Feedback 餵給 LLM，是賦予 Agent 自主錯誤排除與自我修復能力的關鍵架構模式。
  • **保護邊界：強制介入機制**：Agent 不能無限運作，必須在架構層面設計斷路器 (Circuit Breaker) 或最大迭代上限 (Max Steps)，以控制成本並避免系統陷入死循環。
  • **看透框架的抽象**：市面上複雜的框架（Agents, Executors, Memory 等）底層都在實作相同的 `Send context -> Execute tools -> Append results -> Repeat` 模式。理解這個基礎，能讓架構師在評估或自己實作 Agent 框架時更游刃直餘。
Obsidian 整理 原始文章
Agent架構

从 GLMQwen 看：Agentic RL 最新进展

"隨著模型能力增強，靜態驗證器必然失效；Agentic RL 的核心在於驗證系統必須與生成器「和諧進化」，並透過生成式 Critic 與動態路由技能來解決長任務中的信用分配與穩定性問題。"
Top 5 Insights
  • **驗證系統的動態化與對抗性**：靜態驗證與最終目標獎勵（Final Reward）已無法約束能力愈發強大的 Agent。必須建立包含軌跡攔截、動態交互與大語言模型裁判的立體驗證網，防堵模型從「解題」偏向「尋找系統漏洞」。
  • **生成式評估取代判別式評估**：無論是價值函數 (Critic) 還是驗證器 (Judge)，「先思考再打分」的生成式架構在擴展性與穩定性上已全面輾壓傳統的瞬間前向預測模型，突破了 TC0 的複雜度理論限制。
  • **錯誤數據的剩餘價值挖掘**：透過 Span-Level KTO，證明了失敗的代碼與執行的軌跡依然具有極高的語言建模價值，架構設計上不應將其一刀切剔除。
  • **上下文狀態感知的精準路由**：在 Critic 評估（注入參數與勝率）與技能提煉（OPID 全域與步驟級路由）中，證明了上下文資訊的精準匹配與路由，是提升樣本效率與模型效能的關鍵。
Obsidian 整理 原始文章
Prompt工程
Cover

20 CLAUDE.md Rules for Getting Ahead of Your Competitors by 5 Years

"只要設定一個 CLAUDE.md 檔案，就能讓 Claude 記住你的偏好、工作脈絡與開發習慣，從此告別每次對話都需要重新解釋的噩夢。"
Top 5 Insights
  • **System Prompt 即 Infrastructure**：將 `CLAUDE.md` 視為專案基礎設施的一環。它能有效設定 AI 的行為邊界，將原本難以預測的 LLM 輸出收斂成高度可控、符合專案規範的結果。
  • **以文件驅動持久化記憶**：LLM 本身是無狀態的，但透過強制其維護 `MEMORY.md` 與 `ERRORS.md` 等外部文件，可以巧妙地建立起跨 Session 的「長期記憶」，這是 Agentic Workflow 中非常實用的架構設計。
  • **防禦性 AI 開發 (Defensive AI Usage)**：給予 AI 越高權限（如終端機執行權限），就必須配置越嚴格的防護網。將「破壞性操作攔截」、「嚴格作用域控制」納入 Prompt，是防止 AI 造成災難性後果的必要手段。
  • **抑制 AI 的「過度優化」衝動**：AI 傾向於提供超出預期的複雜解法。透過明確指令如「Simplest solution first」及「Do not touch unrelated code」，能確保系統架構保持簡潔，避免不必要的技術複雜度入侵專案。
Obsidian 整理 原始文章
Prompt工程
Cover

Fable 5 (Mythos) Prompting Masterclass by Anthropic

"無一席話總結"
Top 5 Insights
  • **思維典範轉移：** 提示工程從「編寫繁瑣的規則集」轉向「定義清晰的 Context (為什麼) 與 Constraints (邊界)」，將 Fable 5 視為一位高階顧問而非低階打工仔。
  • **擁抱自主與代理：** 善用 `/loop` 指令與 Fable 5 內建的多重 Agent 管理能力，將任務從「單次對話」升級為「長程自主運作工作流」。
  • **化繁為簡的指令設計：** 停止使用過度設計 (Over-engineered) 的舊提示詞，轉而使用精簡的四大組件 (Context, Request, Format, Constraints) 結構，並加入外部記憶系統以實現自我修正。
Obsidian 整理 原始文章
Prompt工程
Cover

How One File Called CLAUDE.md Turns Claude from a Search Engine into a Second Employee

"把 Prompt 當成一次性對話是新手的作法；把 Prompt 寫進 `CLAUDE.md` 當成基礎設施，才能讓 Claude 變成擁有記憶與系統規範的數位員工。"
Top 5 Insights
  • **Context as Code (脈絡即程式碼)**：
  • **Defensive Prompting (防禦性提示) 系統化**：
  • **Workflow Automation 宣告**：
  • **關注點分離 (Separation of Concerns)**：
Obsidian 整理 原始文章
Prompt工程
Cover

How to optimize your Claude setup to get the most out of Fable

"將 Fable 視為資深工程師，只負責架構、規劃、困難除錯與最終審查，其餘繁雜工作交由較便宜的模型代勞以節省 Token 與成本。"
Top 5 Insights
  • **職責分離是降低成本的關鍵**：將 AI 模型依照能力與成本分級（Fable > Opus > Sonnet），如同團隊中的資深工程師與基層工程師，合理分配任務能大幅降低 API 費用。
  • **上下文整潔度決定了效能與花費**：避免全域掛載不必要的外掛，並謹慎使用 1M 超大上下文模型，透過子代理回傳「精確證據」而非「全文轉儲」來保護主線程的上下文空間。
  • **動態調整思考深度**：不要將 Effort（思考努力度）全域拉滿，應該在需要高階判斷時針對特定任務或子代理做局部升級，好鋼要用在刀刃上。
Obsidian 整理 原始文章
Prompt工程
Cover

I Turned David Ogilvy's Writing Rules Into An AI Writing Coach (Free Claude Skill Inside)

"將 David Ogilvy 的 10 條不朽寫作法則提煉為 Claude Skill，讓 AI 成為你專屬的商業寫作教練。"
Top 5 Insights
  • **Prompt Engineering 即知識封裝**：將過往依賴人工審核或 Checklists 的專家經驗（如 Ogilvy 備忘錄），轉化為結構化的 Prompt，是目前 AI 應用落地最有效的模式之一。
  • **分類與分級反饋機制 (Linter Pattern)**：在設計處理文本的 AI 工具時，採用類似程式碼 Linter 的模式（標示錯誤級別、給出具體引文與修復建議），遠比單純要求 LLM「重寫這段文字」來得更有價值且可控。
  • **保持"Human-in-the-loop"的架構設計**：該 Claude Skill 刻意設計為「只給建議、不代勞重寫」，這是一種優良的產品設計思維。工具應增強人類能力，而非完全取代學習過程。
  • **非同步與同步溝通的邊界**：從系統架構的角度來看，法則 10 提醒我們，不是所有的訊息傳遞都適合透過非同步佇列（Writing）處理，高優先級、需要立即觸發動作的指令，應使用同步呼叫（直接對話）。
Obsidian 整理 原始文章
Prompt工程

一文掌握 Claude Fable 5 實戰：Prompt · 上下文管理 · Loop

"使用 Claude Fable 5 時，應從「微觀管理者」轉變為「委託人」，減少過度約束，設定好目標、邊界與記憶系統，讓模型自主完成長週期的迴圈任務。"
Top 5 Insights
  • **策略做減法，目標做加法**：針對 Claude Fable 5，最佳的提示詞策略是放棄「操作清單」式微操，專注於提供任務背景、設定嚴格邊界（Constraints）並提供清晰的驗證條件（Goal）。
  • **基礎設施建構**：對於無人值守的長循環代理系統，強制要求它依據「工具回傳結果」來彙報進度，並將除錯經驗寫入本地 `notes/` 目錄，是防止幻覺與提升穩定性的最佳做法。
  • **重新思考代理驗證機制**：要發揮出多代理編排的真正威力，應全面摒棄讓 LLM「自我批評」的做法，轉而擁抱派發具備全新上下文的子代理來進行客觀的對抗驗證。
Obsidian 整理 原始文章
學習資源
Cover

一些或許對你有益的信息

"這是一份從專業到業餘的完整投資學習導航圖，涵蓋了宏觀數據、技術分析、風險對衝、ETF 定投以及投資心理學。"
Top 5 Insights
  • **建立系統化監控**：不論是專業還是業餘，都需要一份「全市場觀察表」與固定的宏觀數據監控，讓交易決策基於客觀數據而非主觀臆測。
  • **接受不完美並管理風險**：沒有任何技術指標是完美的（模糊正確），因此必須了解衍生性金融商品（期權/期貨）的對衝機制，確保極端狀況下的生存能力。
  • **從打工者到資產所有者**：技術分析與宏觀研究只是工具，真正的投資護城河在於「心理建設」與「認知思維」的轉換，尤其是利用系統（ETF 與複利）為自己工作。
Obsidian 整理 原始文章
實戰教學
Cover

How to Actually Build Your First AI Agent with Claude Code (Complete Beginner's Course)

"透過設定專屬資料夾與 `CLAUDE.md` 指令檔，即使零程式經驗也能讓 Claude Code 自動讀取檔案、檢查錯誤並產出報告。"
Top 5 Insights
  • **基礎設施即 Prompt (Infrastructure as Prompt)**：透過 `CLAUDE.md`，我們實作了一種類似配置驅動（Configuration-driven）的 Agent 架構，系統行為由靜態文本決定，而非寫死在程式碼中。
  • **沙盒隔離機制 (Sandbox Isolation)**：將 Agent 的作用域嚴格限制在單一資料夾內，並在 `CLAUDE.md` 中明確宣告唯讀與寫入目標，是確保自動化安全性的最佳實踐。
  • **可擴展的微型架構**：這套模式具備極高的可擴充性。未來可以輕易將輸出格式轉換為 CSV，或結合 Routine 排程功能，發展成持續整合/持續檢查 (CI/CD) 的輕量級工具。
Obsidian 整理 原始文章
工作方法

认知科学角度的写作八原则

"寫作應從讀者認知出發，用具體、生動、互動的語言取代抽象、陳舊與過度包裝的詞彙。"
Top 5 Insights
  • **優化資訊傳遞的「頻寬」**：寫作的本質是編碼與解碼，去除元話語、模糊限定詞與不必要的抽象名詞（性、度、力），能有效降低讀者的解碼成本（認知負荷）。
  • **動詞驅動架構**：如同在程式設計中我們偏好動態的行為（方法）而非靜態的資料庫欄位，文字表達也應避免「名詞化」，盡量使用具體的動詞與主動語態來驅動句子的行進。
  • **具象化與互動設計**：將讀者視為對話對象，使用第一/第二人稱，並用具體的場景取代抽象的概念描述，這與系統設計中強調 User Experience (UX) 的思維不謀而合。
Obsidian 整理 原始文章
工作流
Cover

human in the loop

"不要逐項審批 AI 的動作，而是要設計「人在迴圈中」的參與節點：專注於輸入、引導與最終審查。"
Top 5 Insights
  • **放棄微觀管理 (Stop Micromanagement)**：AI 工具的逐步授權（Per-action approval）會導致同意疲勞。應轉向「計畫模式（Plan Mode）」，在 AI 執行前審查並修正其總體執行計畫。
  • **前置領域知識投資 (Front-load Context)**：AI 執行的品質與效率高度取決於 Input 階段。定義清晰的目標、絕對的約束條件（Constraints）與最佳實踐範例，是避免大量後期重構的關鍵。
  • **基礎設施化引導 (Infrastructure-as-Steering)**：善用專案層級的約定檔案（如 `CLAUDE.md`）來固化架構風格與編碼標準，讓 AI 在啟帶前就內化團隊的「隱形假設」。
  • **職能升級至架構師思維**：開發者的角色應從「初稿撰寫者 (First-draft writer)」轉變為「審查與評估者 (Reviewer & Evaluator)」，專注於定義成功標準與軌跡監控。
Obsidian 整理 原始文章
工作流
Cover

用 Codex + Remotion 实现无痛自媒体视频日更，涨粉过万：把剪视频变成维护一条生产线

"不要把視頻當作一次性剪輯專案，而是當成一個由 AI 維護、可吃 JSON 吐影片的程式碼專案。"
Top 5 Insights
  • **Video as Code 的典範轉移**：將視頻製作從依賴個人體力與意志力的「手工藝」，轉變為依賴系統與代碼的「工業化生產線」。
  • **AI 的正確使用姿勢**：不要把 AI 當作一次性的對話框工具，而是將其視為可以讀取專案規則（`AGENTS.md`）、維護代碼並優化流程的工程師夥伴。
  • **創作者價值的重新聚焦**：當排版、渲染等繁瑣工作被自動化系統接管後，創作者可以將寶貴的注意力全部集中於「選題判斷」、「觀點表達」與「情緒分寸」等核心價值上。日更不再是比拼熬夜，而是比拼系統的完善度。
Obsidian 整理 原始文章
工具實踐
Cover

Codex 上手别卡在配置：Teamo 一键接入教程

"無一席話總結"
Top 5 Insights
  • **API Gateway 模式的優勢**：透過像 TeamoRouter 這樣的代理網關（API Gateway），可以將配置複雜度、多供應商路由與快取機制封裝起來，讓終端 Codex 客戶端配置極大簡化。
  • **配置管理的最佳實踐**：對於 CLI 工具，提供 GUI 輔助一鍵安裝 (避免環境差異導致的錯誤)，以及清楚的 Shell Script 寫入配置 (`cat <
  • **成本與穩定的取捨**：在高度依賴上下文的 AI 輔助開發場景中，快取機制的效率直接決定了使用成本。初次導入時應優先保證可用性 (精品路由)，待收集到足夠的用量指標 (Metrics) 後，再優化成本 (低價路由)。
Obsidian 整理 原始文章
後端開發
Cover

Adding Filtering, Sorting And Pagination To a REST API | .NET 10

"無一席話總結"
Top 5 Insights
  • **無條件實作分頁**：API 不應依賴「資料量不會很大」的假設，必須強制加上分頁與 `PageSize` 的硬性上限 (例如 100)，防止惡意請求拖垮系統。
  • **善用 IQueryable 組裝**：利用延遲執行 (deferred execution)，在應用層疊加過濾與排序邏輯，最後再將組裝好的查詢交由 EF Core 翻譯成高效的 SQL 語法。
  • **索引是靈魂**：所有的過濾與排序欄位 (`Status`, `Price`, `CreatedAt` 等) 都必須建立資料庫索引，否則再好的分頁邏輯最終都會變成全表掃描。
  • **根據場景選擇分頁模式**：無限滾動的 Feed 流 (如社群貼文) 應使用 Cursor Pagination；而後台管理系統需要指定頁碼跳轉時，則使用 Offset Pagination。
  • **儘早投影 (Project Early)**：透過 `.Select()` 盡早在資料庫層級將 Entity 轉為 DTO，避免將用不到的欄位載入記憶體。
Obsidian 整理 原始文章
思考隨筆
Cover

Agentic Coding Is Just Vibe Coding In A Suit

"無一席話總結"
Top 5 Insights
  • **AI 開發的本質不變**：無論工具如何進化，核心依然是「自然語言意圖轉換」與「將驗證與實作外包給 AI」。
  • **Agent 架構的四大支柱**：評估或建立 Agentic 開發系統時，應關注其四大要素：規劃能力 (Planning)、跨模組分析 (Whole repo context)、外部工具整合 (Tool use)、以及自我修正迴圈 (Self-correcting loop)。
  • **心理學影響技術名詞**：不要被社群中新穎的技術名詞所迷惑。工程師有時候只是需要一個「聽起來像工程」的名詞來降低對於交出控制權（不逐行 Review Code）的焦慮與羞恥感。
  • **享受原型的樂趣**：不要急著在概念驗證階段追求過度的嚴謹，Vibe Coding（直覺式開發）是驗證想法最快樂也最高效的方式，不必急著為其穿上西裝。
Obsidian 整理 原始文章
思考隨筆

How I Make £10K/Month as a Writer

"無一席話總結"
Top 5 Insights
  • **「意義」驅動優於「營收」驅動**：將愛好強行商業化往往會導致熱情消退。建立穩定的變現管道（如 B2B 行銷文案）來支撐生活，同時保留一塊不受金錢干擾的創作淨土（如 Mind Cafe），是維持職涯長青的最佳架構。
  • **尋找並建立「Golden Ticket (黃金門票)」**：在注意力稀缺的時代，光有技術是不夠的。必須建立一個能證明你權威性的平台或專案（例如主理一個擁有百萬讀者的專欄），這能使你的市場定價呈指數級躍升。
  • **防禦 AI 的最佳護城河是「真實的人性」**：AI 已經拉高了行業的及格線。不要依賴 AI 來生成最終內容，而是把 AI 當作基礎研究工具；唯有注入真實經歷與獨特人格特質的「精英文本 (Elite writing)」，才能在機器生成的內容海中被讀者感知與珍視。
  • **職涯的韌性來自「靈活轉型 (Pivot)」**：市場需求會不斷改變，從 SEO 內容到企業行銷再到個人品牌代操，創作者必須具備極強的適應力，不固守單一的變現模式。
Obsidian 整理 原始文章
知識管理
Cover

AI Knowledge Layer (and why your agents are useless without it)

"如果沒有專屬的知識層，你的 AI 代理只是在盲目猜測；給予它會自動成長的知識庫與清晰的品牌基礎，它才能真正成為你的分身。"
Top 5 Insights
  • **預先編譯架構 (Ahead-of-Time Compilation) 勝過傳統 RAG**：將非結構化資料預先由 AI 代理編譯、摘要並建立 Markdown 交叉連結，不僅在回答準確度上更高，更能大幅降低檢索時的 Token 成本消耗。
  • **動靜分離的狀態管理**：將經常變動的來源知識 (KBL) 與不可妥協的品牌原則 (BF) 分離處理。這確保了 AI 在獲得龐大外部知識的同時，行為模式仍受到嚴格的領域驅動規則 (Domain Rules) 約束。
  • **GitOps 與 Human-in-the-Loop 的知識治理**：底層架構依賴 Markdown 與 Git 進行版本控制，且強制引入 `explored: false` 的審查標籤。這在架構上避免了 AI 幻覺（Hallucination）在知識網路中產生不可逆的複利污染。
  • **閉環的查詢累積機制**：代理不僅將 Raw 資料編譯為 Wiki，更將使用者的每次 Query 結果（`/wiki-query`）直接作為新節點寫回系統。這將單向的檢索系統，轉化為具備自我增強能力（Self-reinforcing）的狀態機。
Obsidian 整理 原始文章
知識管理
Cover

What is LLM Wiki Pattern? Persistent Knowledge with LLM Wikis

"無一席話總結"
Top 5 Insights
  • **從檢索 (RAG) 轉向編譯 (Compilation)**：知識的價值在於狀態的持久化。不要讓 LLM 每次都從頭檢索，而是讓它把新資訊「編譯」進現有的知識圖譜中。
  • **擁抱不可變的數據與演化的狀態**：原始來源（Raw Sources）必須是 Immutable 的，而衍生出來的 Wiki 則是可持續覆寫的狀態。這與軟體工程中的事件溯源（Event Sourcing）與具體化視圖（Materialized View）架構思想不謀而合。
  • **解決知識庫的「維護稅 (Maintenance Tax)」問題**：企業或個人的內部 Wiki 總是失敗，是因為維護交叉引用與一致性的成本過高。LLM 正好填補了這個「免費且不知疲倦的簿記員」的角色。
  • **建立清晰的 Schema 邊界**：要讓這套系統有效運作，必須透過明確的 Schema 告訴 LLM 檔案的結構與更新規範，確保 LLM 的行為是可預期且結構化的。
  • **實現 Memex 願景**：Vannevar Bush 在 1945 年提出的具備關聯軌跡的個人知識庫（Memex），在 LLM 的自動維護能力加持下，終於找到了最後一塊拼圖。
Obsidian 整理 原始文章
知識管理
Cover

What is LLM Wiki Pattern? Persistent Knowledge with LLM Wikis

"放棄讓 LLM 每次從頭找答案的 RAG，給它一個 Markdown 知識庫，讓它成為不知疲倦、自動維護交叉連結的私人圖書館長。"
Top 5 Insights
  • **知識架構的典範轉移**：將 LLM 的應用從「Stateless RAG (無狀態檢索)」推進到「Stateful Compilation (有狀態編譯)」，這大幅改變了知識沉澱的效率與深度。
  • **CQRS 架構的思想體現**：系統將 Immutable 的 Raw Sources (Event Store) 與可變的 Wiki (Materialized View) 分離，這是經典的分散式系統設計，確保了系統的可追溯性與可重建性。
  • **維護成本的自動化**：此模式證明了 LLM 最強大的企業級應用場景之一，不是從零生成靈感，而是執行枯燥但需要語義理解的「記帳工作 (Bookkeeping)」，如更新連結與發現資料矛盾。
  • **Agentic IDE 的最佳實踐**：人類只負責提供指令 (Schema) 和資料源 (Sources)，並透過版本控制 (Git) 進行審閱，這是人類與 AI Agent 協作最穩定的工作流範本。
Obsidian 整理 原始文章
系統架構
Cover

From Silos to Service Topology: Why Netflix Built a Real-Time Service Map

"無一席話總結"
Top 5 Insights
  • **擁抱異質資料源的互補性**：網路層 (eBPF) 提供無遺漏的全貌，應用層 (IPC) 提供 API 粒度的上下文，請求層 (Tracing) 揭示真實的運行路徑，結合三者才能建構完美的拓樸圖。
  • **中介點解析 (Intermediary Resolution) 是關鍵**：單純收集網路連線會被 Load Balancer、NAT 等網路設備切斷邏輯依賴，必須在串流處理層將其摺疊 (Collapse) 成真實的點對點應用依賴。
  • **邏輯分離但視圖統一的架構**：三個資料源在底層分別存在獨立的 Partition，這允許各層資料獨立演進與平行查詢，只在使用者需要時才於 API 層合併為統一視圖 (Unified View)，大幅提升查詢效能。
Obsidian 整理 原始文章
系統架構
Cover

Thinking Fast & Slow for a Personalized Notification System

"無一席話總結"
Top 5 Insights
  • **將「量 (配額)」與「質 (排序)」解耦**：分離頻率規劃與訊息選取，不僅解決了長期疲勞與短期點擊間的矛盾，還賦予了工程團隊兩條獨立的迭代與優化路線。
  • **稀疏負反饋的處理技巧**：在設計 ML 效用函數時，面對稀疏的退訂回饋，人為地引入「通用訊息成本」是防止模型過度發送的實用且必要的防護網。
  • **異步溝通提升即時效能**：利用低延遲 Feature Store 儲存複雜且耗時的長期規劃結果，讓即時推播決策層 (Fast Policy) 只需執行輕量級的查詢與過濾，完美兼顧了系統效能與策略深度。
  • **對邊緣/輕度用戶效益最大**：這套系統對於偶爾觀看的「Casual Viewer」產生了最顯著的提升，證明了對於這些用戶，保護他們的注意力餘裕並在對的時間傳遞高相關性內容是至關重要的。
Obsidian 整理 原始文章
系統架構
Cover

构架师教程：熵与法典

"程式碼的腐壞是熱力學第二定律的必然，只有透過判定下沉的九層階梯與人類持續投入不可外包的判斷力，才能延緩系統的死亡。"
Top 5 Insights
  • **系統防腐的本質是持續的負熵輸入**：程式碼的腐壞是必然的物理現象，必須透過自動化的判定網（九層階梯）與人類的高價值決策，才能有效維持系統結構。
  • **防禦機制必須從「結果驗證」轉向「軌跡驗證」**：在 Agent 時代，只看最終狀態極易被 AI 的偽造行為蒙蔽，必須實施基於行為步驟的軌跡評估（Trajectory Evaluation）。
  • **判斷力是一種會耗竭的實體資源**：應當像珍惜能量一樣珍惜人類的 Review 精力，將所有能自動化的檢查（類型、契約、屬性測試）盡可能往下沉，讓人腦只負責最高層級的品味與信任判斷。
  • **判定覆蓋率是系統健康度的核心指標**：每一個依賴人類記憶的隱式規則都是潛在的系統炸彈，架構師必須主動將其顯式化為自動化規則。
  • **本地算力崛起改變了工程邊界**：隨著本地硬體（AI PC/一體機）的普及，高頻率、低成本的判定驗證將成為可能，"本地優先、雲端兜底"的架構將成為未來應用的標準配置。
Obsidian 整理 原始文章
職場技能

2026 Senior SDE 面試筆記 Google, Microsoft, Amazon, Mercari, PayPay, Appier, Woven and More

"面試不僅是公司考驗你的 Coding 溝通力，更是你透過內推與精準 Q&A 篩選出具備優良工程文化團隊的雙向選擇過程。"
Top 5 Insights
  • **人脈即架構的延伸**：在求職中，內推網路 (Networking) 就如同分散式系統中的服務發現 (Service Discovery)，能有效繞過擁擠的公開路由，直接獲取高價值的團隊內部狀態資訊。
  • **將 Q&A 視為系統探針 (Health Probe)**：透過標準化、具穿透力的提問 ("favorite part about working here")，在不同層級的節點 (IC, Manager, HR) 進行探測，若返回的 Response 高度一致指向「工程文化」，則代表該組織具備良好的健康度與一致性。
  • **Communication > Computation**：在現代 Coding 面試中，演算法的最佳化 (Time/Space Complexity) 已經被視為預設配置 (Default Baseline)。真正的決勝點在於「系統狀態的可觀測性 (Observability)」，即面試者能否在 Dry Run 時，流暢且清晰地輸出資料結構變化的即時狀態 (Log & Trace)。
  • **防禦性 AI 開發思維**：AI 提升了代碼產量，卻可能降低代碼的長期可維護性。扎實的軟體工程基本功與 OOP 概念，是防止系統被「看似正確實則無法維護的 AI 代碼」腐蝕的最後防線。
Obsidian 整理 原始文章
職場技能
Cover

The 6 Skills that get more valuable in the Agentic Era

"在 AI 能完成多數常規工作的時代，最值錢的技能是組裝 AI 代理、硬體機器人，以及創造真實的注意力與人際連結。"
Top 5 Insights
  • **價值轉移至邊界**：在 AI 代理時代，純軟體開發的壁壘下降。技術人員的價值從「寫出功能」轉移到「串接 AI 與真實世界」，無論是透過硬體機器人、實體社群，還是精準的注意力分發。
  • **微型系統架構思維**：Agent 的建構本質上是一種微型分散式系統的設計。開發者需將原本寫死 (Hard-coded) 的邏輯，轉換為具有 Context, Evals 與 Tools 協作的動態工作流。
  • **快速驗證取代長週期開發**：利用 AI 的生產力優勢，開發者必須學會執行 48 小時的「建構-分發」循環。這要求我們在架構設計初期就考慮到市場測試 (Go-to-market) 的需求。
  • **軟硬整合的文藝復興**：軟體工程師應開始涉足硬體。利用開源生態（如 Hugging Face, SO-100 臂），將軟體的迭代速度帶入硬體與機器人領域，將成為下一個十年的巨大護城河。
Obsidian 整理 原始文章
職場觀察

How I Make £10K/Month as a Writer

"一位寫作者歷經十年的跌宕起伏，最終領悟到在 AI 時代保持競爭力的關鍵是成為「頂尖」，且盲目追逐金錢會消磨對創作的熱情與人生的意義。"
Top 5 Insights
  • **「頂尖」是 AI 時代唯一的護城河**：當生成式 AI 能輕易產出及格線以上的內容時，中庸的技能將被淘汰。唯有建立獨特的人類聲音與深度的情感連結，達到領域內的「Elite」水平，才能免於被取代。
  • **保持超精簡架構 (Ultra-Lean Architecture)**：作者的經歷證明，盲目擴充團隊與實體開銷（如實體雜誌）會極大增加系統的脆弱性。在充滿變數的數位時代，低開銷、高靈活度的一人商業模式更具韌性。
  • **區分「生存機制」與「意義機制」**：將熱情完全商業化往往會消磨初衷。架構個人職涯時，應同時配置「帶來穩定現金流的業務（如代寫 LinkedIn）」與「提供生命意義的專案（如 Mind Cafe）」，避免因過度商業化而迷失方向。
Obsidian 整理 原始文章
認知思維

跨越阶级

"努力和運氣只是門票，真正決定你能否跨越階級的，是你的認知帶寬、信息梯度以及承受「身份懸空」撕裂痛苦的能力。"
Top 5 Insights
  • **認知帶寬管理是重中之重**：系統需要預留充足的資源（認知帶寬）來處理未來的演進，而非將所有算力耗費在短期的存活 (Survival) 上。
  • **跨域節點帶來高價值**：如同微服務架構中，系統的創新與突破往往來自不同模塊（弱關係）之間的異步通信與數據交換，而非封閉的強耦合模塊內。
  • **架構演進的陣痛期管理**：系統架構升級（階級跨越）必然伴隨著新舊兼容的痛苦（身份懸空）。設計平滑的遷移策略（身份預演與過渡共同體）是架構師必須考慮的成本。
  • **長期價值驅動**：應投資於能產生覆利效應的基礎設施（長週期帳戶），而非僅為滿足短期的業務需求（短週期帳戶）打補丁。
Obsidian 整理 原始文章
量化交易
Cover

How To Use Loop Engineering To Build A Self-Improving Quant Trading System

"停止單次 Prompting，改為設計具備狀態記憶、獨立驗證與自動執行的「循環 (Loop)」，讓系統能 24/7 自動回測、交易並從虧損中自我學習。"
Top 5 Insights
  • **從 Prompting 到 System Architecture**：不要再手動輸入提示詞，而是建立基於 `SKILL.md` 與 `STATE.md` 的閉環系統，讓知識自動累積與複利。
  • **嚴格的 Maker-Checker 架構**：系統設計的關鍵在於隔離「生成」與「驗證」，確保決策的客觀性與高勝率，這與大型機構的管理架構一致。
  • **無人值守的安全性**：透過平行的 Risk Monitoring Loop 作為強制開關（Kill Switch），與明確客觀的停止條件（避免 Agent 自己宣稱完成），才能在完全放手的情況下控制下行風險。
Obsidian 整理 原始文章
開發工具
Cover

Apple’s Anti-Docker Gives Every Container Its Own VM: Boots in Under a Second

"無一席話總結"
Top 5 Insights
  • **「減法」才是終極的最佳化**：Apple 的 Micro-VM 能在 1 秒內啟動，證明了只要精準捨棄不必要的 OS 元件（libc, coreutils），VM 也能達到接近容器的輕量級特性。
  • **強隔離與資源效率的雙贏**：一容器一虛擬機的架構，不僅在安全上縮小了爆炸半徑，更實現了真正的「零閒置成本」，這是傳統共享 VM 架構無法做到的。
  • **Swift 跨足系統底層**：透過靜態編譯並運行在沒有 C 標準函式庫的 Linux 環境中作為 PID 1，Apple 展示了 Swift 具備作為現代化系統級程式語言的強大潛力與野心。
Obsidian 整理 原始文章
開發工具
Cover

How Codebase Memory cuts 50% token for my Claude Code

"Codebase Memory MCP 透過 C 與 tree-sitter 在幾秒內將程式碼庫建構為關係圖譜，並透過 Hook 攔截 grep 請求，讓 AI 代理在不改變習慣的情況下減少 50% 的 Token 消耗。"
Top 5 Insights
  • **摒棄 Embeddings，擁抱 AST**：在程式碼檢索領域，基於語義的向量檢索精準度不足，利用 tree-sitter 等工具建立精確的抽象語法樹與依賴圖譜是更可靠的架構選擇。
  • **無感增強（Invisible Enhancement）的設計哲學**：透過 pre-tool-use hook 攔截並增強常用的 `grep` 操作，成功繞過了 LLM Agent 容易忘記呼叫新工具的問題，大幅提升了工具的實用性。
  • **效率與成本雙贏**：將關聯結構直接交給 Agent，不僅避免了開啟大量不相干檔案的 Token 浪費（節省約 50%），更提升了 AI 處理大規模重構或跨檔案追蹤任務的準確度與自信心。
Obsidian 整理 原始文章
開發工具
Cover

这几个功能你不知道，就不要去浪费fable5了

"把 Claude Code 當成一位需要清晰上下文與適當規劃的並行工程團隊，而不只是一個被動接受指令的輸入框。"
Top 5 Insights
  • **將 Context 視為一級資源 (First-Class Resource)**：AI 的輸出品質直接取決於上下文的純淨度。建立定期執行 `/compact` 與 `/clear` 的機制，以及透過動態的 `CLAUDE.md` 提供精確約束，是減少模型幻覺的架構級解法。
  • **運用工作區隔離實現並行開發**：透過子代理 (Sub-agents) 與 Git Worktrees 的物理隔離，能有效避免不同任務間的狀態耦合與污染，這與微服務架構中避免共享資料庫的理念如出一轍。
  • **任務路由與模型分級 (Model Routing)**：依據任務複雜度動態選擇模型（如 Haiku 處理 Routine，Fable 5 處理架構），並適時使用 API 直連取代厚重的 MCP，能在控制成本的同時極大化吞吐量與效能。
  • **擁抱 Agentic Workflow**：隨著 Agent Teams 與 `/loop` 等功能的成熟，軟體開發的範式正從「命令式編程」轉向「聲明式驗收」，工程師應提升自身的架構規劃與系統驗收能力。
Obsidian 整理 原始文章
開發工具
Cover

高效使用 Worktree，成为十倍程序员

"將任務實體化為獨立目錄，並用腳本打通環境初始化的最後一哩路，實現真正的多工並行。"
Top 5 Insights
  • **狀態隔離的本地容器化**：Worktree 提供了一種輕量級的狀態隔離機制，讓每個分支擁有獨立的 File System 視圖與依賴狀態，是解決「多工污染」的最佳實踐。
  • **關注點分離 (Separation of Concerns)**：Git 本身專注於版本控制（檢出代碼），而 `cc-launch` 負責環境配置（Environment Provisioning），兩者結合補足了開發者體驗（Developer Experience）的最後一塊拼圖。
  • **AI 驅動的工作流變革**：在 AI 輔助下，開發瓶頸已從「撰寫程式碼」轉移到「上下文切換與環境準備」。透過全自動化的工作區配置，開發者能真正發揮多 Agent 並行開發的潛能。
Obsidian 整理 原始文章