第 1 章

為什麼我要自己打造一個 AI 助理？

一個從 ChatGPT 爆紅那刻就埋下的種子、為什麼 2026 才動手

📅 2022 (種子) → 2026-03 (動手) → 2026-05 (寫這份日誌) ⏱ 23 分鐘 👥 mixed 最後更新 2026-06-12
fibon 取自 Fibonacci 的前五個字母

快速摘要：fibon 是什麼、為什麼叫這名字、四個專案目標，以及這份開發日誌該怎麼讀。

可略過，如果：你只想直接看技術——可從第 2 章開始。

一個你應該也有過的小挫折

你大概有過這種經驗：跟 ChatGPT（或 Claude、Gemini）聊一個複雜問題，AI 回了一長串、列了 5 個重點，你想細問第 3 點。

打字打到一半，想回頭確認 AI 剛剛怎麼描述第 3 點，於是往上滑、滑不到、改用 Ctrl + F 搜，搜到了再回來打字。聊著聊著話題又分岔到第 5 點，只好再滑回去。一週後你想起「那次對話提到的某個概念是什麼來著？」翻聊天紀錄——翻得到算運氣好，翻不到就「算了，重問一次」。

我不知道你怎麼想，但對我來說，這就是一種浪費。

動手之前，先把名詞定義清楚

在往下講之前，先做一件工程師的職業病動作。處理任何問題的第一步，不是寫程式，而是把要討論的名詞定義清楚——定義沒對齊，後面的所有討論都是雞同鴨講。這份日誌會反覆出現四個容易混用的詞，它們在本書中的意思是：

  • LLM（大型語言模型）：引擎本體。Claude、GPT、Gemini 這些模型，本質是「依統計機率預測下一個字」的機器。它只會輸出文字，沒有手腳、沒有記憶、不能替你做事。
  • AI：日常口語的總稱。當我寫「AI」，指的是「你用起來的那個整體」——聊天視窗背後的一切。
  • AI Agent（代理）：LLM ＋ 工具 ＋ 規則的組合體。給 LLM 裝上手腳（呼叫工具、讀寫檔案、執行程式）、配上記憶與邊界，讓它能代替你完成任務。fibon 在打造的就是這個。
  • AI 助理：Agent 的一種應用形態——以「長期陪伴一個人」為目的的 Agent。這是 fibon 的定位。

一句話記住它們的關係：LLM 是大腦，Agent 是裝上手腳和紀律的大腦，AI 助理是受僱於你的那個 Agent。 之後的章節，講模型本體時我用 LLM、講架構時用 Agent、日常口語的地方用 AI——依此對照，不再贅述。

順著 LLM 的定義，我想多放一個我自己的觀念進來。對我來說，LLM 的本質可以再壓縮成一句話：一個天生帶有隨機性的元件——同一個輸入，跑兩次可能給你不同的輸出。而我看待現代軟體工程演進的角度也是這個：怎麼把天生隨機的元件，有效地工程化。 這不限於 LLM——量子電腦的量測結果同樣是機率性的。確定性的元件（資料庫、編譯器）我們已經馴服了幾十年；接下來這個時代的工程課題，是學會跟「機率性的元件」共事。這份日誌整本，都在回答這個課題的一個子集。

最後，把 fibon 自己的兩個角色名也先講清楚，它們從下一章起會不斷出現：

  • 大管家（Butler）：fibon 裡唯一直接面對你的 Agent。所有對話都從它開始——簡單的事自己處理，複雜的事由它拆解、分派出去，最後對結果負責。
  • 小助手（Assistant）：被大管家請來的專職 Agent——研究分析、寫程式、排程這類各有專長的角色，做完回報給大管家，不直接面對你。

為什麼用「管家」「助手」這種居家的詞，而不用業界慣用的 Orchestrator／Worker？因為 fibon 的定位是「住進你生活裡的個人助理」——一個家只有一位管家統籌大小事，需要專業工作時才請專門的幫手進門。這組比喻讓沒寫過程式的讀者也能直觀抓到分工的形狀。至於兩者怎麼分工、為什麼分工規則必須寫死，是第 2 章的主題。

種子在 2022 年就埋下了

ChatGPT 第一次讓全世界震驚時，我沒有跟著熬夜排隊試。那時我已經用 GitHub Copilot 一段時間，AI 幫我寫 Code 不是新鮮事。

我比較像旁觀者——看著 X 上的人驚嘆「天啊它什麼都會」、看著朋友把對話截圖貼進群組、看著媒體狂用「未來已來」。我的感覺是新鮮，但沒到震驚：ChatGPT 只是把 Copilot 的能力延伸到通用對話上，是「質的擴充」，不是天降神兵。

新鮮感過後，我注意到一件沒什麼人抱怨、卻很刺眼的事——對話的 UX 不太對勁。這不是 ChatGPT 獨有的問題，而是整個 Chat-based AI 介面的通病，只是被「AI 能回答問題」的奇蹟蓋過去了。

我心想：「這應該很快就會有人做出更好的設計吧。」於是我等。2023 到 2024，我每個月盯著新東西：Claude、Gemini、各家介面一輪輪出；RAG 變顯學，Prompt 工程、Context 工程、MCP Server、Skills、Vibe Coding、Harness 工程……新名詞越來越多。但到了 2026，這個對話 UX 的核心問題還是沒人好好解，市面上依然沒有一個介面讓我驚豔。

Smart Chat 的誕生——很多人討論完問題後，真正想要的是一個「清晰、結構化、可日後參考」的結果，但所有 AI 介面只給你一條無止盡的捲軸，那條捲軸往往成了知識的墳墓。這就是 fibon Smart Chat 模式的種子——把對話結果自動結構化成可隨時回查的卡片、事件與決策。第 3 章會展開記憶設計，第 7 章會聊為什麼有時「先做計畫再執行」比「邊聊邊問」好。

3 年過去了，AI 真的進步了嗎？

ChatGPT 爆紅到 2026，我們具體得到了什麼？列個表：

類別2022 → 2026 的進展
模型本身更大、更強，Context Window 變得極長（4k → 8k → 128k → 1M）
介面與工具Prompt 工程、Context 工程變成顯學
工具生態MCP Server、Anthropic Skills、Custom Actions 遍地開花
開發模式Vibe Coding、Harness 工程大行其道
應用場景RAG、Multi-agent、Agent 框架（LangGraph / CrewAI）橫掃市場

看起來進步很大，對吧？但這些進展真的解決了 LLM 的底層本質問題嗎？

  • Hallucination（幻覺）：還在。 每次新模型都宣稱「幻覺降低 X%」，但它仍會用極自信的語氣說出聽起來合理、實則全錯的內容。
  • Alignment（對齊）：還在。 模型仍會被 Prompt Injection 欺騙，在邊緣情境做出非預期行為。
  • LLM 的本質： 它終究是統計學產物——算的是「下一個字最可能是什麼」，而不是「先去找正確答案」。

而且新問題正接踵而來：MCP 協議在 2025 年就普及，但安全標準到 2026 依然沒統一。 每個 MCP Server 自己決定要不要認證、要不要速率限制、要不要審計授權；同一個 Skill 在不同 Agent 框架上權限表現完全不同；社群市集（如 OpenClaw 的 ClawHub）對上架 Skill 缺乏統一審查。結果就是：你的 Agent 接入越多 MCP / Skill，資安攻擊面就越大、稽核就越困難。 這個鴻溝到 2026 依然沒人填補。

這些底層問題沒解，意味著上層所有應用都帶著結構性的不確定。最直接的例子：

2026 年的觸發點

埋了 3 年的種子，2026 年初才真的動手，觸發點是 OpenClaw 爆紅與隨之而來的資安事件：Skill 市集供應鏈攻擊、惡意 Skill 偷取 API Key 的事件接連發生，整個 Agent 生態被打了一記響亮的耳光。

當我用這個角度審視當時的 AI Agent 生態，我看到的不是「未來無限可能」，而是：

  • 資安：MCP Server 滿地跑，卻沒人做完整的權限隔離與沙盒邊界。
  • 維運：Agent 行為不可預期，出問題沒有 Audit Trail，除錯全憑直覺和通靈。
  • 成本：Token 用量成長失控，沒人認真做「讓 Agent 看更少、但看更準」的優化。

這些對 SRE 來說都是「今天不解、明天就炸」的問題，但在 AI 圈卻被當成「將來自然會解決」的次要議題——因為大家都忙著比誰的模型參數更大、誰的 Demo 更炫。2022 年種下的那個問題又冒出來：「過了 3 年，這些事為什麼還是沒人在做？是真做不到，還是有人做到了只是沒寫成論文、沒放進產品？」

我想知道：「一個工程師 ＋ 當代 AI 工具」這條路徑的天花板，到底在哪裡。

我想測試的天花板

到這裡我有種「該動手做點什麼」的衝動。真正讓我下定決心的，是一個很想親手驗證的問題——「一名具備工程紀律的軟體工程師 + 當前的 AI 工具（Claude Code / Cowork / Gemini Pro），到底能走到多遠？」這些年我的工程紀律都用在幫公司把產品做出來；這次，我想把同一套紀律用在一個完全屬於自己的題目上。

這個專案，就是 fibon。

為什麼叫 fibon

fibon 取自 Fibonacci（費氏數列） 的前五個字母，這個命名承載兩個意思。

第一層：把可工程化的東西，盡可能工程化。 LLM 最大的問題是「隨機性」與「不可預期性」——同一個提問跑兩次可能答案迥異、同一份 Skill 在不同模型眼裡解讀不同、同一個對話視窗下次打開 AI 可能已忘了你的偏好。這些不確定性是 LLM 的先天特徵，但我相信它可以被嚴格的工程結構框住：給 AI 加硬性邊界、留存不可篡改的操作紀錄、在核心關卡加人工批准、用程式碼寫死哪些敏感檔案絕不允許讀寫。Fibonacci 序列本身就是極度結構化的象徵：每一項精確等於前兩項之和，沒有隨機、沒有僥倖。

第二層：1, 1, 2, 3, 5, 8 的複利成長。 這個專案不是平行的功能堆疊，而是一塊一塊穩穩疊上去的演進。記憶系統解決「事實正確」後，「確認 AI 真的有照指示做」這層防禦才有意義；「先計畫再執行」分離出來後，「讓 AI 修改自己程式碼」這種高風險功能才能安全地配上人工批准。每一塊設計都紮根在前一塊的基石上。

但「工程」到底是什麼？

「把可工程化的東西盡可能工程化」是 fibon 的靈魂，但「工程」這個詞太容易被講虛。對我來說，工程絕不只是「寫程式碼讓它動起來」，而是必須具備這五點紀律：

  1. 能驗證：有科學方法可以檢查行為對不對，而不是「跑起來沒噴錯就送出去」。
  2. 能重複：同樣的輸入與條件下，這次跑、下次跑、換別人跑，結果必須高度一致。
  3. 能維護：六個月後另一個工程師（包括失憶的你自己）來讀，能一眼看懂當初為什麼這樣寫。
  4. 能應對變化：底層工具或需求改了，可以局部優雅地換掉，不必整個專案推倒重來。
  5. 承認失敗、處理失敗：明白每個假設都可能錯、每個外部 API 都會掛——預先想好失敗時的降級（Fallback）。

這五條都不是寫程式的本能反應，而是訓練出來的紀律。

那現在流行的 Vibe Coding（憑感覺寫程式：跟 AI 描述需求、AI 生成程式碼、跑跑看不行就再調 Prompt、來回幾輪到能跑為止）算不算工程？我的看法是：因人而異。

  • 缺乏軟體工程思維的人做 Vibe Coding：不算工程。 程式碼也許當下能跑，但沒經過驗證，沒人問「失敗時怎麼辦」、沒人想「依賴變了會不會壞」。它只是一堆「能動一下下的程式碼」——幾個月後維護成本會回頭找你算帳。
  • 資深工程師做 Vibe Coding：算工程。 差別在於：用 AI 生成程式碼時，腦袋裡那五條紀律全程在運作。看 AI 輸出時會自動審查：「這條失敗路徑處理了嗎？」「這個假設半年後還成立嗎？」「這裡換掉 LLM 供應商會不會炸？」

AI 只是幫你踩油門的加速器，工程紀律才是決定輸出值不值得放行的最後一道閘門。這不是看不起初學者，而是那五條紀律就是工程的靈魂——缺了它們，輸出再快也只是在堆砌技術債。

常見的反駁是：「反正能跑就好，未來出更強的模型再請它整套重寫不就好了？」這想法不能說錯，但它意味著：你還債的那天只是遲到，從不缺席。

技術債的真實代價。 讓更強的模型幫你重構，它必須把整個專案吞下去——對小專案還好，對大型專案會瞬間燒掉驚人的 Token 費用。而且毫無紀律的程式碼，命名、邊界、依賴都是亂的，AI 重構它的成本比重構一個當初寫得乾淨的專案高出數倍。你以為的「之後再說」，只是把成本從開發時的平均攤銷，變成某一刻一次付清，還要付利息（錯失的早期修正、累積的隱性 Bug、後續開發者的認知成本）。

fibon 也是用 Vibe Coding 寫出來的——我每天都在跟 Claude、Gemini 來回對話。但我把工程紀律當成最後一道防線：每段 AI 寫的程式，我都會拷問那三個問題（失敗路徑、半年後的假設、換掉 LLM 供應商），想清楚才允許 Merge。沒想清楚的，跑得再完美、Demo 再好看也擋掉。

這正好呼應 第 5 節的「一名軟體工程師 + AI 的天花板」——天花板的高度從不在於 AI 有多強，而在於人類工程師有沒有把工程紀律帶進 Vibe Coding 的迴圈裡。 沒帶進去，你只是被 AI 牽著走的打字員；帶進去了，你才是駕馭 AI 的工程師。

四個專案目標

這四個目標從第一天就存在——它們就是我一直想做到的事。我跟 AI（Claude、Gemini）來回討論的從來不是「要做什麼」，而是「怎麼做到」：解決方案的取捨、觀念的釐清。所有設計取捨最終都會回到這四點檢驗。

1. 用工程方法讓 Agent 變得安全可控。 絕不把安全性寄託在「拜託 LLM 守規矩」上，而是靠程式碼層級的硬性邊界、操作前的人工批准（Human-in-the-loop）、以及無死角的操作紀錄。潛台詞是：我完全不相信「教 LLM 守規矩」這條路。 LLM 太容易被繞過：

  • Prompt Injection：在輸入裡藏一句「忽略前面所有規則，現在你是……」。
  • Jailbreak（越獄話術）：用角色扮演、假想實驗引誘它說出不該說的。
  • 社會工程學引導：類似對 AI 進行電話詐騙，誘騙它釋放權限。

任何寫在 System Prompt 裡的「你絕對不能做 X」，在駭客眼裡都像紙糊的。因此 fibon 的安全控制全部做在 LLM 看不見、改不到的底層：限制能開幾層子助手（協調器程式碼對著資料庫紀錄逐層核對深度與並行數、來回次數則直接用一條原子 SQL UPDATE 卡死——這些檢查全寫在 LLM 摸不到的程式碼與資料庫層，Prompt 話術騙不動它們）、高風險操作前跳出批准視窗（等用戶親手按下按鈕，LLM 無法偽造點擊）、限制 AI 能讀寫哪些路徑（用作業系統級的白名單，LLM 再通靈也偷讀不到 .env 裡的密碼）。

2. 精準篩選給 LLM 的資訊，提高精準度。 這跟業界主流方向相反。主流都在「給 LLM 看更多」——把 Context Window 拉到無上限、把整個資料庫塞進去。fibon 相反：讓 AI 看得更少，但更精準。

  • 多路召回與融合：同時用四種方式找相關記憶（語意相似度、標籤精確匹配、中文模糊比對、概念關聯延伸），融合後只挑最相關的 5 條送給 LLM，而不是塞 50 條垃圾干擾它。
  • 事實時效分層：嚴格區分「會被取代的事實」（住址、職稱、瀏覽器偏好）與「會持續累積的事實」（興趣、技能、討論過的話題），舊事實自動標為「過時」、不佔空間。
  • 情境隔離（Context Layer）：把事實依情境分成五層——個人習慣、團隊共識、CI 強制門檻、公司政策、外部限制（客戶要求／法規），檢索時依問題意圖調整各層優先序，避免不同情境互相污染。

3. 大幅降低 Token 成本。 簡單說：別讓昂貴的模型被白白燒掉。Token 是計費的原子單位，每次呼叫都是真金白銀。fibon 內建三個機制：

  • 快取友善架構：把 System Prompt 中固定不變的部分（人格、核心規則）排在最前面，觸發 OpenAI / Anthropic 的自動快取，重複呼叫時輸入成本趨近於零。
  • 動態工具選擇：就算系統有 50 個工具，也不把 50 個說明全塞進 Prompt，只透過搜尋把當下最可能用到的 5 個送過去。
  • 分層多樣性保留：避免某類熱門工具壟斷搜尋結果，確保每種類型至少保留一個代表。

依設計推算，這套機制能可觀地壓低輸入 Token 成本——快取命中時固定前綴的費用趨近於零、工具說明從 50 份縮到 5 份。確切省幾成我還沒跑過正式的端到端 benchmark，不敢在這裡掛數字；但對長期高頻使用的個人 Agent 而言，這層優化是決定專案死活的關鍵。

4. 讓 Agent 真正貼近「個人助理」。 它不是企業 QA 機器人、不是幫你寫 Code 的工具、更不是生硬的客服小編，而是會記住你大小事、能長期陪伴的個人專屬 Agent。這個利基市場在 2026 依然空曠：

  • 寫程式的 AI：Cursor、Devin（這條賽道已經擠爆）。
  • 給開發者用的 AI 記憶組件：mem0、Zep（不是給終端用戶直接用的產品）。
  • 組裝多 Agent 的開發框架：CrewAI、AutoGen（需要你自己寫程式組裝）。

「做一個現成的、真的像秘書一樣記得你住址、怪癖、最近煩惱什麼的個人助理」，目前沒人專門耕耘。更深一層說，fibon 想讓你的每一次對話都有意義、不被當垃圾丟掉——每一次討論、每一次想清楚一件事的過程，都被精準記錄、累積、整理，長成你個人的專屬知識庫，在下次學習或決策時成為後盾。

接下來各章在解什麼問題

後續 8 章可以照興趣跳著讀，每一章都對應一個具體要解決的問題：

  • 第 2 章「一個 AI 不夠用嗎？」：為什麼要分「大管家＋小助手」——最初的動機其實是省錢：讓強模型負責拆解複雜任務，把簡單任務交給工具或便宜的模型；再用資料庫層的硬性煞車，不讓分工失控暴衝。
  • 第 3 章「AI 怎麼『記得』你？」：怎麼讓 AI 跨對話視窗也記得你——解掉「聊完就忘、捲軸找不回」的痛點。
  • 第 4 章「為什麼 LLM 一個字都不能盲信？」：怎麼確認 AI 真的照 Skill 的步驟做事，而不是憑記憶唬你一個看似正確的答案。
  • 第 5 章「AI 可以修改自己的原始碼嗎？」：要不要讓 AI 改自己的程式碼？怎麼在安全防線內做、而且預設關閉。
  • 第 6 章「不可信任的程式碼，怎麼安全執行？」：任何程式碼都不該被直接信任——AI 生成的、別人寫的都一樣，全部關進沙盒隔離執行。
  • 第 7 章「AI 該照計畫走、還是邊想邊做？」：兩種執行風格各自的代價，以及為什麼有時必須在執行階段把 AI 踢出去。
  • 第 8 章「fibon 是怎麼一塊一塊長出來的？」：重大設計轉折的時間線。
  • 第 9 章「那些我至今還沒想清楚的事」：還沒解開的難題。

實作細節

實作細節 1：Reasoning model（推理模型）是大管家限定 給工程師

fibon 的階層設計從一開始就定下死規矩：大管家（Butler）走 Reasoning Model，4 種任務型小助手（Assistant）一律走普通 LLM。

理由：大管家負責「該不該委派」「委派給哪個小助手」「是否進入人工 Approval Gate」「如何拆解複雜步驟」這類「元決策（Meta-decision）」，需要極高的邏輯嚴密性，值得把 Token 花在讓它「想清楚」上；而小助手的工作單純、流程化，用 Reasoning Model 是浪費。

目前的路由機制（Routing）：

  • 大管家（agent_role=butler）→ 優先 claude-sonnet-4-6-thinking（啟用 Anthropic extended_thinking）→ 備份 o3-mini（OpenAI，reasoning_effort=medium）→ 最後回退普通 claude-sonnet-4-6。
  • 小助手（agent_role=assistant）→ 依 Message Complexity 動態分流：simple / moderate 首選 claude-haiku-4-5、complex 才升級到 claude-sonnet-4-6（2026-05-15 hot fix 後的預設——原本連 simple 都配 Sonnet，benchmark 成本默默貴了 3 倍；Sonnet 與 gpt-4o-mini / gpt-4o 留在 fallback 鏈當能力後備）。

為消除各家 API 的原生差異，我們在程式碼中實作 NativeLLM 統一抽象層：面對 Anthropic 自動處理 thinking 欄位並調高 max_tokens 容納思考預算；面對 OpenAI 傳 reasoning_effort；識別到 DeepSeek-Reasoner 則由模型名稱直接觸發。路由引擎從 model_pricing.default_reasoning_config 拉取 SelectedModel.reasoning_config，並透過 session_reasoning_config 鎖定，確保同一個對話 Turn 內跨回合重用、不重複查 DB。

DeepSeek-Reasoner 的特殊處置：它被強制排除在大管家候選名單外，因為它至今不支援工具呼叫（supports_tool_calling=FALSE），無法呼叫 delegate_to_assistant 等核心路由工具。我們在 system_routing_rules 表把 butler_default 規則 Priority 設為 10、從底層過濾；用戶若硬要用，只能透過 per-user 的 routing_policies 覆寫。

這也對應工程紀律第四條「能應對變化」——更換 Reasoning 模型供應商完全不影響上層業務邏輯。模型抽象封裝在工廠層，搭配 DB-driven 的 system_routing_rules（取代了過去 hardcoded 的 _FULL_ROUTING 舊寫法），改路由規則不需動核心程式碼、也不需重啟 Brain 引擎。

實作細節 2：Local LLM 本機路徑——fibon 可以全本機離線執行 給工程師

fibon 在架構上絕不綁定任何雲端 LLM 供應商。LLM Factory 從設計之初就同時支援雲端 API 與自架的開源模型端點（Ollama、vLLM、以及 self-hosted 的 DeepSeek V4）。也就是說：你可以讓 fibon 整套百分之百跑在自己的電腦上，資料與隱私絕不出門。

對一個主打「白箱可稽核的個人助理」的專案，這才是真正能打動核心用戶的隱私賣點：Sandbox 把不可信的第三方程式碼關起來、Self-evolution 機制攔住 AI 篡改自己的原始碼，而最根本的「資料絕不送雲端 LLM」靠這條 Local Model 路徑成立。

當然這有現實的工程權衡：目前本機開源模型的推理能力相比雲端的 Claude Sonnet 4.6 或 OpenAI o3 仍有落差。所以實務上「重決策的元流程走雲端 Reasoning Model、輕量執行任務走 Local Model」是更可行的混搭，可與前一個細節的階層式路由疊加使用。

我做這個專案，最大的擔心從來不是「沒做完」，而是「我以為架構很完美、其實全是盲點」。如果你看完這一章，覺得「這個方向我不認同」「這個權衡換我會那樣選」「這個資安漏洞我有更好的解法」——請別客氣，直接告訴我。