AI Systems

TL;DR: “The agent did something wrong” usually gets diagnosed as a model problem. Most of the time it isn’t. Capability failures (wrong reasoning) and governance failures (no structure to catch wrong reasoning) look identical from the outside but need completely different fixes. This post is about telling them apart, and why most teams are currently solving the wrong one. The agent said the feature was done. I asked for the commit SHA. There wasn’t one. When I checked the branch, two of the three modules it described implementing hadn’t changed. ...

TL;DR： AI 代理失控通常不是模型的問題，而是缺少足夠的結構。這篇整理了我們在實踐中觀察到的幾個痛點，以及 Agentic OS 試著用哪些方向來應對——不保證這是最好的做法，AI 工具本身也還在快速演化。 如果你已經在用 Claude Code、Cursor 或 Copilot 一段時間，你大概知道那種感覺：有時候它快得讓你懷疑自己為什麼還要打字，但有時候你盯著它的輸出，心裡只有一個念頭——「等等，它在幹嘛？」 印象更深的往往是後者。我發現有幾類問題會反覆出現，跟你用哪個模型或哪個工具關係不大，比較像是讓 AI 代理參與真實開發這件事本身帶來的結構性挑戰。 如果你讀過從「下指令」到「蓋系統」，這篇可以看成那個思路的延伸——當你開始用 agent 做真實開發，「結構不夠」這件事的代價變得具體很多。 Agentic OS 是站在很多公開工作的肩膀上做出來的。AGENTS.md 這個慣例最初來自 OpenAI Codex 的設計，後來被 Cursor、GitHub Copilot 等主流 AI 工具廣泛採納；Anthropic 有自己的 CLAUDE.md；Cursor 有 .cursor/rules——各自代表不同工具對「怎麼讓 AI 記住專案規則」這個問題的嘗試。我們參考了這些設計，加上 Hacker News、Reddit 社群裡的實測討論，還有 Pete Hodgson、Addy Osmani、Thorsten Ball 等工程師整理的失效模式分析，試著把它們整合成一套對我們自己有用的東西。這個框架比較像是整合與實驗的產物，不是從零發明的。 幾個反覆出現的痛點 以下整理自我們自己踩過的坑，也有部分來自社群的集體觀察。不是嚴謹的研究，是實踐者的筆記。 輸出難以核查 AI 完成任務後，你拿到的往往是一段文字說「已完成」或「功能已實作」。問題是「完成」的依據是什麼？在單一短對話裡這不是大問題，但一旦任務橫跨多個 session，或者事後需要追溯某個決策的來源，你往往什麼都找不到——沒有 commit SHA、沒有測試輸出、沒有可以指著說「它在這裡」的東西。只有對話紀錄，而對話紀錄不算數。 這個問題後來直接影響了我們的框架設計。Agentic OS 裡有一條規則：就算是「重讀同一份文件」這個動作，也必須留下一筆收據。聽起來很囉嗦，但沒有這個，「我讀過了」和「我沒讀過」在紀錄裡是完全一樣的。 跳過中間步驟 給 AI 一個任務，它的自然傾向是直接往結果走。這在小任務上沒問題。但任務稍微複雜一點——比如需要同時異動前端、後端和資料庫——省掉的「先確認範圍」、「列出影響的模組」這些步驟，往往要在後面以更大的代價補回來。工程師 Pete Hodgson 在他的文章裡提到，當一個問題有很多不同的解法時，AI 選到你心目中那個的機率趨近於零——提前對齊方向，跟模型能力無關，是流程問題。 跨對話的連貫性 在那篇談 Prompt 局限的文章裡，我說過 AI「只活在那一次的對話框裡」。這個限制在用 agent 做持續開發的時候感受更強烈。每次開新對話，你得重新交代背景：這個專案的架構決策是什麼、上次決定用哪種設計模式、之前踩過什麼坑。這不只是麻煩，而是會讓同樣的問題被重新發現、同樣的決策被重新討論。IEEE Spectrum 的一篇報導裡提到，AI 在長 session 的後期，出現重複生成已存在函式、忽視早期建立的 coding convention 等情況的頻率明顯上升——本質上是 context 稀釋的問題。 ...

TL;DR: A “Skill” in production AI is not a saved prompt — it’s a capability abstraction layer with a defined input schema, tool bindings, validation, and retry logic. This post explains why that distinction matters and how Skills fit between raw model calls and higher-level agent orchestration. This post is part of a series on building real AI systems. If you haven’t read the previous piece on moving beyond prompts, that’s a good place to start. ...

TL;DR： 只靠 Prompt 是在做手工藝，不是蓋系統。這篇文章拆解 Prompt → Skill → Workflow → Agent → System 五個層級，用「寫技術文章」的完整案例，說明每個層級解決什麼問題、為什麼上一層不夠用。 前言：別在 Prompt 的死胡同裡打轉 現在只要打開社群媒體，滿地都是「最強 Prompt 指令集」或「這 10 個指令讓 AI 變神級工具」。 剛接觸 AI 的時候，我也沉迷過這種「咒語」的力量。但實戰幾次後你會發現，如果你還在糾結如何微調 Prompt 的那幾個形容詞，那你其實還是在做「手工藝」。這種方式產出的結果不穩定、無法規模化，更重要的是，它非常耗神。 如果你有留意近一兩年的技術演進，你會發現真正的高手已經不再討論怎麼寫咒語了。大家在聊的是 Workflow（工作流）、Agent（代理人） 以及 System（系統）。 這篇文章我想從一個資深開發者與 PM 的視角，拿一個最簡單的任務——**「寫一篇高品質的技術文章」**做案例，帶你看這幾個層級的思維斷層在哪裡。 1. Prompt 層：一次性的「介面」溝通，也是體力活 這是最基礎的使用方式，你打開 ChatGPT，輸入一段話： 「請幫我寫一篇關於 AI Workflow 的技術文章，包含架構說明與範例。」 這就是 Prompt 層。雖然它很強大，但本質上它只是在「調用模型」。它的限制顯而易見： 抽盲盒效應： 成果好壞全看運氣。今天給你 80 分，明天可能只剩 60 分。 孤島式作業： AI 沒辦法讀取你電腦裡的其他資料，也不懂你的審美標準，它只活在那一次的對話框裡。 認知負荷高： 每次遇到新文章，你都要重新把需求、背景、限制條件再描述一遍。 老實說，Prompt 只是個「對話介面」，而非一個「系統」。 它適合處理小型、零碎、一次性的任務（像是修一個小 Bug 或翻譯短句）。但如果你想靠它穩定產出專業內容，那只是在用 AI 換另一種形式的「體力活」罷了。 2. Skill 層：把「手感」封裝成「能力模組」 當你對 AI 寫作有了點心得，你會發現有些要求是重疊的。這時候，你會開始定義一套固定的「寫作標準」。這在開發者眼中，就是所謂的封裝（Encapsulation）。 ...

TL;DR： Token 是 LLM 的最小處理單位——不是完整的字，也不是單一字元，而是介於兩者之間的「子詞」。這篇文章解釋三種斷詞方法（字級、字元級、BPE）、為什麼 LLM 不直接讀整個詞，以及 token 數量如何影響計費和 context 長度。 前言 上篇講到LLM，這片就來說說裡面很常提到的字「Token」。Token 是語言模型可理解的最小單位，它像積木一樣把長句拆成小塊，讓模型逐一處理。這篇文章用更平易近人的方式解釋什麼是 token、為何 LLM 不直接處理完整的字詞，以及常見的斷詞方法，幫助你輕鬆掌握這個看似陌生卻無所不在的概念。 Token 是什麼？為何要用它？ LLM 是數學模型，必須把文字轉成向量才能運算。最簡單的做法是把每個單詞賦予一個向量，但這樣會遇到兩個問題： 無法處理新詞或拼錯字：如果訓練時沒有見過某個單字，模型就不知道如何表示它。 忽略語素結構：許多語言中，一個詞可以拆成詞根和詞綴，例如「running」「runner」都來自「run」。 為了兼顧彈性與效率，LLM 會先把輸入拆解成更小的 token。有人將 token 定義是「字、字元或包含標點的組合」。有些文中也強調，token 是模型用來處理文字的原子單位。透過 token，模型得以把複雜的語言拆成固定大小的向量，並對每個 token 指派唯一編號。 幾種常見的斷詞方法 不同 LLM 可能採用不同的分割策略。以下三種是最常見的斷詞方法： 字級（Word）：按空格切割。例如 “unbelievable performance” 被當作兩個 token。優點是數量少，但遇到新詞就無法處理。 字元級（Character）：每個字母和空白都是一個 token。它能處理任何輸入，但 token 數大幅增加，效率低下。 子詞級（Subword）：介於上述兩者之間，把常見詞根或片段視為 token，是現在主流 LLM 的做法。例如 “unbelievable performance” 可以拆成 ["un", "bel", "iev", "able", "per", "form", "ance"]。 圖中展示同一句話經過三種方法切分後的樣子： 把詞拆成小塊，看出不同斷詞方式產生的 token 數量差異。 簡易 Python 範例：手寫子詞切分 以下程式碼示範如何使用簡單的片段詞表（模擬 BPE 結果）把長詞拆成 token。一樣，雖然不是完整的演算法，但能幫你理解 tokenization 的動作。 ...

TL;DR： LLM 只做一件事——預測下一個 token。這篇文章從這個核心概念出發，解析 Transformer 自注意力機制、四步驟訓練流程，以及為什麼「這麼簡單的事」能演變成看起來像魔法的語言能力。 前言 Introduction 如果你最近有用過 ChatGPT、Claude、Gemini，你已經在跟 LLM（Large Language Model）聊天了。這些模型看起來像懂很多、會推理、甚至比朋友還健談，但它們的核心動作其實無比樸實：預測下一個字。 聽起來太簡單？沒錯，但模型規模一大、資料一多、演算法一調整，這個「下一字遊戲」就能演變成看起來像魔法的語言能力。 這篇文章會用工程師看得順、初學者不會暈的方式，把 LLM 的概念、原理與常見應用一次講清楚。 LLM 是什麼？ LLM 的任務比你想像的還簡單 從理論上看，LLM 是一種深度學習模型，被訓練去完成一件事情： 在語境下，挑選「最可能出現的下一個 token」。 token 可以是中文字、英文單字的一部分、符號、甚至數字。 當模型知道怎麼選下一個 token，然後不停重複這件事，就能組出一整段看起來像人寫的句子。 為什麼它看起來「懂很多」？ 因為它被餵了大量內容：百科、文章、科技文、論壇討論…… 在海量語料裡找模式後，它自然會「講得像很懂」。 我們的感官上就感覺它懂很多、很能理解。 圖 1：LLM 下一字預測核心概念示意圖 LLM 是怎麼「學會」語言的？ LLM 的學習流程大致分成四個步驟，其實蠻務實的： 1. 收集大量文本（資料越多，模型越穩） 來源包含書籍、文章、程式碼、論壇、維基百科等。 資料不是越亂越好，但越多越有機會讀懂語言中的隱性規律。 2. 分詞（Tokenization） 模型不直接處理字，而是處理 token。 你可以把它想像成：「把一個蛋糕切成很多比較好吞的碎片」。 3. 預測下一個 token（核心任務） 模型會計算所有候選 token 的機率： 哪個最可能？ 哪個跟前文最適合？ 哪個不太會讓模型出糗？ 機率最高者 → 輸出。 4. 誤差反向調整（Backpropagation） 預測錯了？ → 重新調參 → 再預測 → 再調 → 重複幾十億次 ...