用 AI 寫程式最大的問題是什麼？對我們來說，不是模型不夠聰明，而是 不放心 。 LLM token 越來越貴，但大部分都在重複看已經知道的程式碼結構。 Agent 改完程式編譯不過，要來回好幾輪才修好。 工作到一半 context 滿了，重開 session 什麼都不記得了。 有時候改壞了檔案還沒人知道。 這些問題大概不是只有我們遇到。我們的做法是寫兩個小工具來補，一個管 輸入成本 ，一個管 操作安全 。兩者透過 MCP 協定接進 OpenCode，各自只做一件事。 工具一：GraphifyRust — 讓 LLM 不用重看整包程式碼 GraphifyRust 是用 Rust 寫的靜態分析引擎。用 Tree-sitter 解析原始碼，把 function、struct、trait 這些節點抽出來，建成一個有向圖。 AI agent 要改程式時，傳統做法是把整支檔案丟給 LLM。幾百行的檔案可能只有幾段 function 相關，但 LLM 還是得看完所有 import、註解、不相干的邏輯。 Graphify 的 skeleton_extract 只回傳 AST 骨架 — function 名稱、行號、簽名。實際壓縮效果： 檔案 原始 token 骨架 token 節省比例 server.go (BloggerAgent MCP) 1,289 117 90.9% toon.rs (Graphify 核心) 2,132 147 93.1% 骨架不夠用時，用 range mode 精準讀取特定 function。不需要整包丟進去。 選 Rust 的理由很務實：Tree-sitter 的 Rust binding 最成熟。在 110 個檔案、422 條邊的測試專案上，建圖只要 16ms ，比之前 Python 版快 26 倍。節點用 petgraph arena 預分配，減少 heap 碎片。輸出用自訂的 .toon 格式，體積比 JSON 少 60%。 語意搜尋用本機 Qdrant，沒有雲端費用。目前支援 9 種語言：Rust、Python、Go、JavaScript、TypeScript、C、C++、Java、PHP、Swift。 工具二：StateMachineMcp — 永遠不讓壞掉的程...
(Pentax LX，FA 43 LE，Fujifilm X-tra 400) 每次有人問我相機要挑什麼，總會讓我想起： 相機購買指南 ，久久一次，一次久久。 基本上我認為 DRE 神寫的已經是流年批命一樣的東西了，就像星座書裡面不管寫什麼你總會找到一點蛛絲馬跡的那種，但底下要寫的跟祂的文章其實沾不上毛邊，只是純粹表達一種對 DRE 的景仰與愛戴，於是寫在開頭。 今天下班前收到一則訊息，題目是請推薦 15,000 元以內的相機，其實我很久沒看數位相機賣多少錢了，順手找了三台看起來順眼的相機，孤狗了一下，回給對方。 後來對方回了訊息，需求做了變更，題目改為 12,000 元以內的相機，於是再把前訊息所列的那三台相機的上一個型號報一次，想不到價格也差不多落在那裡。 經驗裡，面對這類型的來客問通常不用做第二品牌想，直接報我最不可能選的牌子就會一次命中，其他多列的產品一定都只是陪榜的而已，只是心腸有時候太軟，總想多提供一些給人家參考。 就好像有時候你提供很多規格彈性給客戶選擇，客戶反而更不會選，其實就告訴他金城武也是用這個，或者要針對年輕族群的話就說，和魯夫一同航向偉大的航道，最後再加一個啾咪，問題很容易就解決。於是我以為，一開始多蒐集的資訊是在下過度自詡博學專業與熱情過頭的迷思。 所以其實行政院那個什麼推升方案的影片也反映了這社會的標準行為模式，可能只是錯在沒找到大咖代言人，優質的代言人會比較容易讓群眾跟著拜，自然就看得懂，也就不致於搞出此番被停權的窘迫景況，不過我們英明的政府依舊表示欣喜，此次政策行銷肯定是中華民國有史以來效果最好並且最善用網路社群的一次。 最後，很熱心回答問題的時候，老婆辛苦下班回到家，在下因為正打字打得很順，少了該有的噓寒問暖，特此登報道歉。