不寫 code 的工程師，還算工程師嗎？

我想幫我的專案訂一個開發調性。

就像品牌有 brand guideline、設計有 design system — — 我想找一套方法論，告訴我怎麼「管理 AI 幫你開發」這件事。

找了一圈，沒有。

有的是怎麼管人的、怎麼帶團隊的、怎麼跑敏捷的。但我現在不是在管人，我是在管 AI。這兩件事，像但不一樣。

所以我只好自己摸。摸了大半年，摸出了一套自己的做法。現在我打算把這套流程定調下來，暫時就叫AI開發管理學？這篇文章，算是這個 program 的第一份筆記。

後面會提到的：自主開發測試網址：https://uno.trapic.ai/，歡迎隨時來看看他的進度！

這件事不是最近才開始的。

ChatGPT 剛出來的時候，我跟大部分人一樣 — — 問它問題、複製答案、貼到編輯器裡、自己整理、自己組合。說白了就是一個比較聰明的 Google。

後來用了 Cursor，事情開始不一樣了。可以「系統性」地開發，不再是一段一段貼。但體量一大，問題就來了 — — AI 會失憶、做了又做、同一個東西寫兩份、前面決定好的事後面又推翻。基本上就是一個沒有記憶的隊友。

再後來換成 Claude Code，效率跟條理確實上來了。但人會累死。我曾經為了趕進度，連續一個月每天早上四點起床，週末連續十個小時不停，一個月幹掉我一整年的進度。

很瘋狂對吧？

但這種事我應該不會再做第二次了。因為這個階段 AI 還是輔助的角色，你還是得從頭跟到尾，每一個環節都盯著。效率是上來了，但換來的是你自己的命。

所以我開始換一種方式 — — 先寫規範、先做規劃、先把設計定好，然後才讓 AI 去開發，什麼DDD、什麼spec-first，不管它什麼名字，無非就是PRD先出然後開發，很無聊。

一開始 OK。

但也只有一開始。

規模一大，問題又來了。於是我開始研究兩個東西：記憶和持續性開發。

這篇文章講的，是後者「持續性開發」

到目前為止，用這套方式，我做了三十幾個專案。從 web app、iOS app、MCP server、瀏覽器插件、到 design system、QA 工具、SEO 工具、資料分析平台，有的有上線有的沒有。

一行 code 都沒寫。

不是偷懶，不是外包 — — 是真的，從頭到尾，我的手沒有碰過編輯器。

我做的事情是：

控制

控制方向、控制規則、控制品質、控制節奏。

然後讓 AI 去執行。

先講結論

就好比你騎一匹馬，馬跑得比你快、耐力比你好、力氣比你大。但牠不知道要去哪裡。

你的工作，不是跑步。

你的工作，是拉韁繩。

我的方式

基本上，我的流程長這樣：

第一步：回顧。

每一輪開始之前，先回頭看。上一輪學到什麼？踩了什麼坑？哪些教訓已經記下來了？

這步很多人會跳過。但跳過這步，你就會一直重複犯同樣的錯。

第二步：PM 定任務。

這一輪要做什麼？根據上一輪的回饋和整體規劃，定出明確的 spec。不是「把首頁做好看一點」，是「首頁加上三欄佈局，sidebar 寬度 64，icon bar 寬度 12，內容區 flex-1」。

模糊的需求 = 隨機的結果。

第三步：Dev 執行 + 自檢。

AI 開始寫 code。但寫完不是交差 — — 要跑一份 14 項的自檢清單。本地跑過沒？手機寬度測過沒？console 有沒有 error？第三方套件版本對不對？

這份清單是踩坑踩出來的，不是憑空想的。

第四步：Security 審查。

另一個 AI agent 專門看資安。有沒有注入漏洞？Auth 有沒有 bypass？API 有沒有 rate limit？敏感資料有沒有外洩？

標記 CRITICAL 的就不能部署，標記 WARNING 的由 PM 決定。

第五步：QA 快速測試。

五分鐘 smoke test。能不能用？有沒有明顯壞掉的？有 bug 就退回去修。

第六步：部署。

Build、deploy、上線。

第七步：獨立驗收。

這裡我做了一個刻意的設計 — —

驗收的不是寫 code 的那個 AI，是另一個 AI。

我用 Gemini 來當獨立評審。功能完不完整？體驗好不好？跟業界標準比差多少？打分數，從 A 到 F。

為什麼不讓 Claude 自己評自己？因為球員兼裁判，你永遠拿不到真實的分數。

第八步：PM 回饋 + 記錄。

看完驗收報告，PM 決定哪些要改、哪些不改、哪些下一輪再說。每個決定都記錄下來。

然後，回到第一步。

這就是一輪完整的 sprint。

聽起來很簡單對吧？

是啊，聽起來確實像廢話。

但魔鬼在「持續」兩個字。

一輪、兩輪沒問題。十輪、二十輪之後呢？專案從一個變三個、十個、三十個呢？

這時候如果沒有一套方法讓每一輪都能「接住上一輪的成果」，你做的東西就會開始崩。

我給你看幾個真實的例子。

沒有規範的時候，會發生什麼事？

這些不是假設，是我真的踩過的坑。

同一個功能，寫了兩份。

有個處理團隊權限的功能，AI 寫了一份在 `team-access.ts`，後來另一輪開發的時候，它忘了，又寫了一份在 `core/team-access.ts`。兩份邏輯不一樣，一個回傳 `Set`，一個回傳 `Array`。你猜哪個會爆？都會。

改一個東西，把另一個東西毀了。

有個功能是在 marketplace 上編輯 pack 的 metadata。AI 寫了 `update({ config: { trace_count: count } })` — — 看起來沒問題對吧？但它是整個覆蓋，不是合併。所以每次更新 trace 數量，pack 的名稱、分類、作者名字，全部被洗掉。靜悄悄的，沒有報錯。

欄位名稱根本對不上，但編譯過了。

有個健康報告的頁面，AI 用了 `data.active`、`data.healthy` 這些欄位。問題是，實際的資料結構裡根本沒有這些欄位。它用了一個 `as Record<string, unknown>` 的強制轉型把 TypeScript 騙過去了。編譯過了，畫面上全部顯示 0。每個專案的健康分數都是 F。

這些問題的共通點是什麼？

AI 不記得上次做了什麼決定。

它不知道你三輪前說過「權限邏輯統一放在 core 裡面」。它不記得你說過「更新 JSON 要用 read-merge-write」。它也不知道那個 interface 的欄位名稱已經改過了。

所以你需要規範。不是可有可無的那種。是「沒有它，東西一定會壞」的那種。

真正的關鍵，不在流程

真正讓這整件事能跑起來的，不是「發想→分工→回饋」這個迴圈，是

規範

在開始之前，你需要一套最基礎的規則。什麼可以做、什麼不可以做、目標是什麼、邊界在哪裡。

就好比你開一間餐廳，在廚師開始炒菜之前，你得先決定：我們是中餐廳還是西餐廳？用什麼油？過敏原怎麼處理？出餐速度要求多少？

這些東西不是廚師該決定的。是老闆該決定的。

然後，在開發的過程中，你（沒錯，就是你，那個 boss）會不斷做決定。

這個 component 要不要拆？拆。

那個 API 的命名規則用什麼？用這個。

Design system 的色票要不要統一？要。

這段邏輯太複雜了，要不要重構？不要，先跑起來再說。

每一個決定，就是一條新的規範。

這些規範會慢慢累積。開發的時候會產生、設計的時候會產生、PM 做決策的時候也會產生。

然後，重點來了 — —

每次開始下一輪開發的時候，第一件事不是動手，是先回去讀規範。

確保你還記得之前做過什麼決定、為什麼這樣決定、哪些事情已經定案了不該再改。

然後，才繼續往下做。

這不就是在帶團隊嗎？

寫到這裡你可能會覺得：「等等，這跟帶團隊有什麼差別？」

事實上，沒有差別。

我做了十幾年的工程主管，帶人的方式就是這樣 — — 定方向、分工作、給回饋、建規範、下一輪。

其實在 AI 之前，我就已經把這套方式整理成一個方法論了，叫 FID（Future-Ready Interface Development）。還拿去寫了鐵人賽。

沒得名。

大概太偏門了，不知道該歸到哪一類。可能走太前面了，前面到沒有人跟你討論。

但沒關係，這套東西現在用在 AI 開發上，反而活過來了，他好像遲來的緣分，終於有「人」懂我了。

差別只在於，以前我帶的是人，現在我帶的是 AI。

而且在這個過程中，我遇到一個很實際的問題 — — 我需要不斷換裝置，我有2台電腦，2個手機，同時要記住三十幾個專案各自的規範和決策。人腦記不住的。

所以我做了一個工具專門解決這件事，關於長期記憶的問題，有了這個基礎，才能說「持續開發」

而帶 AI，某些方面甚至更嚴格。

人會自己判斷「老闆上次說不要這樣做，所以這次我換個方式」。AI 不會。你沒寫進規範的東西，它不知道。你寫得模糊的東西，它會亂猜。

所以你的規範必須精準。你的回饋必須具體。你的每一個決定，都必須被記錄下來。

這反而逼著我成為一個更好的管理者。

因為帶人的時候，你可以靠默契、靠氛圍、靠「你應該知道我在說什麼吧？」

帶 AI？不行。

你說不清楚，它就做不對。就這麼簡單。

在我的一天長這樣

早上出門前，看一下 AI 自動產的日報，知道昨天跑了什麼、哪些東西有進展。

等公車的時候，在 Telegram 上下幾個指令 — — 今天想研究什麼方向、哪個專案要推進、哪個想法可以先跑看看。

中午吃飯的時候，看一下結果。OK 的就進下一輪，不 OK 的給回饋、調整方向。

下班等捷運的時候，再看一下進度。

到家的時候，我已經拿到今天的研究結果和資料了，然後再花幾十分鐘看資料和報告（每日精華結論）

跟之前每天四點起床、週末十個小時的日子比，你說哪個比較健康？

好啦，其實就是懶了。所以才需要更懶的方法。

但懶歸懶，做決定這件事，不需要坐在電腦前面十個小時。

那你的價值是什麼？

你不再是那個寫 code 的人，你是那個控制「寫 code 的東西」的人。

你的價值不在於你能寫出多漂亮的 function，而在於你能不能：

1. 定義清楚的規則

2. 做出正確的決定

3. 給出精準的回饋

4. 持續累積有效的規範

這四件事，恰好就是一個好主管該做的事。

下一步：讓它自己進化

持續性開發搞定之後，我開始想一件更刺激的事 — —

如果我完全不介入，讓 AI 自己跑下去，會發生什麼？

所以我開了一個實驗專案。規則很簡單：我不動手，讓它自己開發、自己測試、自己改進。

我幫它建了一整套角色 — — PM 負責定需求、Dev 負責寫 code、QA 負責測試、Security 負責抓漏洞。

但光有分工還不夠。

AI 有一個很根本的問題：它太聽話了。

你讓 Claude 寫 code，再讓 Claude 評自己寫的 code，它會跟你說「做得不錯喔」。就像你叫一個員工自己寫績效考核，他不會給自己打 C。

所以我刻意設計了兩個角色來打破這件事：

一個對抗角色： 驗收評審不是 Claude，是 Gemini。一個完全不同的 AI，沒有參與開發過程，不會護短，不會客氣。它只看結果，給分就是給分。而且以我自己的經驗，Gemini 在商業洞察和市場觀察方面略勝一籌 — — 當然這純粹是我的主觀感受，毫無數據支撐，你聽聽就好。

一個隨機角色：PM 在一定範圍內會產生不可預測的需求變化。不是每一輪都按照計畫走，偶爾會丟出意料之外的任務。就像真實世界裡，老闆突然說

「這個功能下週要上」。

這兩個機制加在一起，做的是同一件事 — — 模擬真實世界的壓力。

對抗，讓品質不會自我膨脹。隨機，讓系統不會只會走直線。

每跑完一輪，它會自己做 retro、記下學到的教訓、帶進下一輪。

結果呢？

一天之內跑了 25 個 sprint。品質評分從 D 一路爬到 B+。中間會退步、會震盪，但趨勢是往上的（我發布這個文章的時候已經72個sprint，早上的筆記是25）

我不知道一個月後會變成什麼樣子。搞不好爬到 A，搞不好卡在某個地方上不去。

但這件事本身就很有意思 — — 我建了一套系統，然後這套系統開始自己長出東西來。

我只是偶爾過去看一眼，確認方向沒偏太遠。

基本上，我從 CEO 變成董事長了（董事長會給意見嗎？我也不知道，有沒有人認識董事長可以介紹給我認識）

自主開發測試網址：https://uno.trapic.ai/，歡迎隨時來看看他的進度！

所以呢？

我不是要說「工程師以後不用寫 code 了」這種話。

我要說的是 — —

如果你一直在帶團隊、做決策、定規範，那你其實已經具備這個能力了。

你只是還不知道，這件事在 AI 時代，會變成一種非常值錢的能力。

不是會下 prompt 就夠了。

是你能不能建立一套系統，讓你的「馬」知道該往哪裡跑、跑多快、什麼時候停下來。

而這套系統的核心，從頭到尾，都是那個拉韁繩的人。

寫 code 的能力，AI 會越來越強。但決定「寫什麼 code」的能力，永遠是人的事。

至少目前是。

我們的 MCP server 有 12 個 tool。

每次 session 開始，AI 還沒說一句話，光是讀完這 12 個 tool 的 schema，就吃掉 6,000 個 token。

我盯著 debug log 看了很久，心想：「等等，使用者還什麼都沒問，我就花掉快一萬 token 了？」

然後我回頭去看那 12 個 tool 的設計，突然有一種很熟悉的羞恥感 — — 就是那種你 debug 了三個小時，最後發現是自己拼錯變數名稱的感覺。

我犯了一個所有後端工程師第一天就知道不該犯的錯。

但我花了一個月才發現。

這個問題不只是我

先說數據，因為數據比我的自我反省有說服力。

有一份研究（SEP-1576）測試了真實世界的 MCP 使用情境：11 個 server、137 個 tool，光是 tool schema 就吃掉 27,462 個 token

還沒開始對話。還沒問第一個問題。兩萬七千個 token，沒了。

這不是理論數字，是實測。

更可怕的是 tool 數量對 AI 表現的影響。研究顯示：

- 10 個 tool：表現完美。

- 107 個 tool：斷崖式失敗。

不是漸進退化。不是「慢慢變差」。是直接從「能用」掉到「不能用」。AI 開始選錯 tool、傳錯參數、甚至幻覺出根本不存在的 tool。

另一份調查發現，97.1% 的 MCP tool 描述存在品質問題。不是格式問題，是 AI 根本看不懂你在寫什麼。

這就是為什麼 Perplexity 的 CTO 公開說他們放棄了 MCP。YC 的 CEO 也發文表達類似的立場。不是因為 MCP 協議本身有問題，而是因為生態系裡的 server 設計得太糟了。

大公司也在踩坑。Block 的團隊把他們的 MCP server 重做了三次，從 30 多個 tool 砍到最後剩 2 個。GitHub Copilot 從 40 個 tool 合併到 13 個。

他們花了多少工程師時間才得出「tool 要少」這個結論？

我不知道。但我知道我自己花了一個月。

我做了什麼

說出來很簡單，做的時候覺得自己是天才，事後回想覺得自己是白痴。

我把 12 個 tool 合成了 1 個。

用一個 `action` 參數分流。

就這樣。

從將近 6,000 token 降到不到 700。

每一次 session 開始，省下 5,200 個 token。如果一天跑 100 個 session，一天省 52 萬 token。一個月省一千五百萬 token。

而我做的事情就是把 12 個 function 包進 1 個 entry point，用一個字串參數決定要做什麼。

這在技術上有個名字，叫 Fat Tool模式 — — 把邏輯分流從模型的「工具選擇」層級，下放到「參數處理」層級。對模型來說，選 1 個 tool 再看 action 參數，比從 12 個 tool 裡選對 1 個，推理負擔小得多。

等等，這不就是 WebSocket 的 Message Dispatcher！

寫完的那一刻，我愣住了。

MCP 是長連線的 JSON-RPC 協議。它不是 REST — — 不是每次請求獨立的 stateless 通訊。它更像 WebSocket：連線建立時交換能力，然後在同一條連線上持續通訊。

你寫 WebSocket 的時候，不會為每一種訊息開一條新連線。你用一條連線，靠 event type 分流：

// 你不會這樣做：
ws.connect("chat-message")
ws.connect("user-typing")
ws.connect("read-receipt")
ws.connect("file-upload")

// 你會這樣做：
ws.connect("chat")
ws.send({ type: "message", data: {…} })
ws.send({ type: "typing", data: {…} })
ws.send({ type: "read", data: {…} })

MCP tool 也一樣。我原本的設計是每個功能一個 tool（等於每種訊息開一條新連線）。合併之後是一個 tool + action 參數（等於一條連線 + event type）。

這是任何一個寫過 Socket 通訊的工程師都知道的事。你不會在 handshake 階段就把所有可能的 message type 全部註冊，讓對方花大量資源去記住每一種訊息格式。你只註冊幾個 channel，用參數分流。

我花了一個月，才想到一個所有後端工程師都知道的事，也可能我對JSON-RPC不熟悉的緣故🤔

為什麼我們會忘記

這件事困擾了我很久，為什麼會犯這種錯？想了很久，我覺得原因有幾個。

第一，MCP 是新東西，我們被「協議」這個詞嚇到了。

當你聽到「Model Context Protocol」，你的大腦會自動切換到「這是一個全新的範式，我需要用全新的思維來理解它」的模式。你會忘記你已經知道的所有東西，從零開始思考。

但 MCP 的本質就是 JSON-RPC。就是 client 發 request，server 回 response。Tool 就是 channel。Schema 就是 message format。

沒有魔法。

第二，官方範例就是 one tool per function。

你去看 MCP 的官方文件、範例程式，幾乎都是一個功能一個 tool。`read_file` 一個 tool，`write_file` 一個 tool，`list_directory` 一個 tool。

這在範例裡沒問題，因為範例只有 3–5 個 tool。但當你照著這個 pattern 去建一個真正的 production server，你就會長到 20、30、50 個 tool。然後你就掉進那個斷崖了。

第三，沒有人寫過「不要這樣做」的文章。

至少在我踩坑的時候沒有。所有的 MCP 教學都在教你怎麼「加」tool，沒有人教你怎麼「不加」tool。這就像早期的 microservice 風潮 — — 每篇文章都在教你怎麼拆，沒人告訴你拆太細會死。

五條具體建議

踩完坑之後，我整理了幾條原則。不是什麼高深的理論，就是常識。但有時候常識是最容易忘記的東西。

1. 一個 MCP server 最多 5–15 個 tool

不是 50 個。不是 30 個。

如果你超過 15 個，停下來想一想你是不是在重複我的錯誤。

2. 想 outcome，不要想 operation

不要設計 `get_customer`、`list_orders`、`get_order_status` 三個 tool。

設計一個 `track_order` tool，讓它內部去串這三個步驟。

這是從 API-Centric（以介面為中心）轉向 Intent-Centric（以意圖為中心）的設計。MCP tool 不是 database query。它是使用者意圖的入口（這個很有趣改天細說）。

3. Tool description 是給 AI 看的 UI

你的 tool description 不是寫給人看的文件。它是寫給 AI 看的使用者介面。AI 靠這段文字來決定要不要呼叫你的 tool。

如果你的 description 寫得含糊，AI 就會用錯。這不是 AI 笨，是你的 UI 爛。

4. 量你的 token

大部分人根本不知道自己的 tool schema 吃多少 token。

去量。用 tokenizer 把你的 tool list 丟進去，看看數字。你可能會跟我一樣嚇一跳。

5. 如果你不確定要不要加一個 tool — — 不要加

每多一個 tool，就是每一次 session 都要多付的 token 稅。

先不要加。等真的有人需要，再加。

最後

MCP 是一個好的協議，解決了一個真實的問題。

我檢討的是我們 — — 包括我自己 — — 在設計 MCP server 時，莫名其妙地忘記了所有後端工程的基本功。

我們試圖用人的工程整潔感去餵養模型的注意力機制。我們把功能切得整整齊齊，覺得「每個 tool 各司其職」很優雅。但模型不在乎你的優雅。模型需要的是高內聚、有上下文關聯的大型 entry point，而不是碎成一地的功能片段。

MCP 不是問題，你的 server 設計才是。

回去看看你的 WebSocket 是怎麼設計的。

照做就好。

直接寫一個 skill？

來我還想到一件事 — — 我為什麼一定要用 MCP tool？直接寫一個 skill，裡面 curl 我的 API 就好了。tool schema 的 token 成本是零。AI 需要的時候呼叫
skill，skill 去打 API，結果回來。整個過程不佔 context window 一個 token。

其實我有XD。

如果你的 MCP server 只是提供資料（不需要 AI 在對話中途動態決定要不要呼叫），那你根本不需要註冊 tool。寫一個 hook script，用 curl 打你的
API，把結果注入 context。Token 成本：零

差別是

Skill/Hook: 你預先決定「session 開始就跑 recall」
→ 固定時機，固定動作

MCP Tool: AI 在對話中判斷「現在需要搜一下」→ 自己呼叫 search
→ 動態時機，AI 自主決定

半年前我把整個向量搜尋層砍掉了。Embedding、pgvector、cosine similarity，全部。換成 PostgreSQL 全文搜尋加一堆 tag。

結果？搜尋變準了。

我自己也不信，所以跑了一個正式的 benchmark — — 120 筆測試資料、35 組查詢、跟 OpenAI 的 embedding 正面對決，樣本雖然不大，但足以證明猜想。

差距只有 5%。

而且我們快了 6.5 倍，token 省了 57%，API 費用是零。

讓我講講怎麼走到這一步的，因為過程比結果有趣多了。

起點：懶惰和貧窮

有人說，創意來自懶惰和貧窮。這兩個剛好是我的優勢。

帳單越來越貴。

每一筆知識要 embed，每一次搜尋要再 embed 一次，向量 DB 的託管費按月扣。用量一大，帳單就開始不好看了。我看著那些數字，覺得這個成本結構不太能當日常。

當然，第一個念頭是：是不是我用錯了？Chunk 切太大？Embedding model 選錯？Prompt 沒調好？我認真想過這件事。但越想越覺得，問題不在調參數 — — 而是在這整條路的假設。向量搜尋的核心假設是：把語義壓成一組數字，然後靠數學距離找「最近」的東西。對通用文本這很好用。但我的資料不是通用文本 — — 它是有明確結構的：每筆知識都有類型、有 tag、有時間、有狀態。這些結構資訊在 embedding 的過程中全部被壓平了。

所以這不是「我用錯了 RAG」的問題，而是 RAG 本身的假設跟我的場景不合。

想通這件事之後，我才開始往另一個方向想。

我真正需要的其實是兩件事：精準搜尋和模糊搜尋。精準搜尋 — — 按類型、按 tag、按時間範圍，直接撈出符合條件的東西。模糊搜尋 — — 當你不確定關鍵字的時候，用文字比對找到「大概相關」的內容。這兩個加在一起，就能覆蓋九成的查詢場景。

有人會說：那你用 Elasticsearch 啊。對，ES 當然能做。但我們沒有用 ES，也不打算為了一個功能多加一個模組。每多一個依賴就多一份維護成本、多一個掛掉的可能。我想要的是用現有的東西就能解決 — — Postgres 已經在那了，ILIKE、tsvector、WHERE 加 GIN index，這些就夠了。

然後我想到另一件事。

我們社群裡的人都在用 AI 協同開發 — — Claude Code、Cursor、Copilot。基本上人手一個比我雲端 embedding 模型強得多的 AI。

那我為什麼要花錢在雲端算向量？

這些 client 端的 AI 已經理解上下文了。它們知道你在問什麼、知道專案的慣例、知道領域詞彙。如果讓 AI 在搜尋之前先分析問題，根據我們的使用習慣推斷出可能的關鍵屬性 — — type、topic tag、keyword — — 然後按照這些屬性去結構化查詢，找出相關內容。Client AI 拿到內容後，再結合自己的 context 進行分析解讀。

整條路走下來：AI 分析問題 → 推斷屬性 → 精準搜尋 + 模糊搜尋 → AI 解讀結果。

中間那層搜尋根本不需要向量，也不需要額外的搜尋引擎。Postgres 的 SQL 就夠了。

我就是從這個想法開始的。把方向做出來、跑了 benchmark，結果比預期好不少。後來回頭查資料，發現 AWS 2025 底的一篇論文得出了類似的結論；VectifyAI 的 PageIndex 用完全不同的方法也走到了同一個方向。

算是殊途同歸。後來找到這些論文，反而驗證了這條路走得通。

先走錯的那一步

一開始我當然是做向量搜尋。大家不都這樣嗎？Embedding、cosine similarity、top-K 最近鄰 — — RAG 教科書第一章。

我搜了「我們對 error handling 做了什麼決定？」

回來的結果：一段 CSS 的 error state、一段 database timeout 的描述、一個 404 頁面的設計。

全部都跟 “error” 這個字「語意相近」。沒有一個是我要的。

我又花了一個週末調參數。換模型、換 chunking 策略、換距離算法。有進步，但也就從「完全不能用」變成「偶爾能用」。

就好比你去餐廳點「牛肉麵」，老闆端上來牛肉乾、牛奶、還有一碗白飯。他說：「這些都跟牛有關啊。」

技術上沒錯。但你就是想吃麵。

沒有人告訴我的事

Embedding 搜尋找的是「聽起來像你的問題的文字」，不是「回答你問題的文字」。

這兩件事差很遠。

如果你有一堆雜亂的文件，「聽起來像」通常夠用了。但如果你找的是「我們團隊同意的 convention」「上週為什麼選了這個架構」 — — 你要的是精確答案，不是語意相近。

Sensible 做了一個完整測試 — — 試了所有能想到的 embedding 優化策略。結果？「沒有顯著改善。」

我看到這個的時候，終於不覺得是自己的問題了。

某天晚上，我把整個向量層刪了。Embedding 欄位、pgvector extension、index。全部。

然後我問了一個不一樣的問題：如果知識在存的時候就已經整理好了，搜尋的時候還需要猜嗎？

圖書館的比喻

想像你要找一本關於 JWT authentication 的書。

傳統 RAG 把圖書館變聰明。我們把管理員變聰明。

管理員本來就在了 — — 你用 Claude Code / Cursor / Copilot，AI 就是你的管理員。為什麼要在圖書館裡再建一個 AI？

現在怎麼做的

每一筆知識，建立的時候就結構化：

type:       decision
content:    "選了 CSS custom properties，不用 Tailwind theme config"
context:    "Tailwind 不支援 runtime theme switching"
tags:       [topic:theming, topic:css, project:my-app, branch:main]
confidence: high

搜尋就是 SQL 查詢：

• project: 和 branch: → AND（必須全部匹配）
• topic: → OR（任一個匹配就回傳）
• 關鍵字 → 全文搜尋加分
• 綜合排序：tag 匹配數 + 文字相關度 + 時間新舊

沒有向量。沒有近似。你標了 topic:theming，搜 topic:theming 就一定找得到。不存在「差一點但沒中」的情況。

正式 Benchmark

120 筆 traces — — 四個模擬專案（電商、行動 App、API Gateway、Design System）。35 組查詢 — — 5 種類型。兩個引擎 — — 同一份資料，正面對決。

品質差距在 5–9% 之間。但速度快 6.5 倍，token 省 57%。

這不是「差不多好」，這是「用零成本換來 5% 的差距」。

差點搞砸的地方

第一版 benchmark 很糟。我直接把自然語言丟給 keyword search。

「我們怎麼讓 app 在沒網路的時候也能用？」→ 搜尋 “work without internet” → 0 筆結果。

廢話。Trace 裡寫的是 “offline”、”WatermelonDB sync”，不是 “work without internet”。

那時候的 MRR 只有 0.47。我差點下結論說向量是必要的。

然後我想到：這根本不是搜尋實際被使用的方式。

呼叫搜尋的是 AI — — Claude Code、Cursor、Copilot。AI 不會把自然語言直接丟進去。它會先推斷正確的關鍵字，就好比 Claude Code 搜你的 codebase 不會 grep “login code”，而是 grep signIn|authenticate|login。

它知道要搜什麼。

當我把 benchmark 改成模擬 AI 的真實行為 — — 先推斷 tag 再搜尋 — — MRR 從 0.47 跳到 0.93。

第一筆結果就是對的，93% 的時間。

三個關鍵改動

1. Tag 和 keyword 是 OR，不是 AND

本來：同時有 tag 和 keyword 時，兩個都要匹配才回傳。改成：匹配任一個就回傳，兩個都中的排更前面。

這一個改動，recall 從 0.60 跳到 0.77。

2. Tag 匹配越多，分數越高

本來：中 1 個 tag 和中 3 個 tag 分數一樣。改成：中越多排越前。就好比考試答對越多題分數越高，不是只看有沒有及格。

3. AI 就是 query rewriter

不是程式碼的改動，是設計原則。我們在文件裡告訴 AI：「搜尋的時候像 grep 一樣 — — 先推斷正確的 tag 和 keyword，不要直接傳自然語言。」

AI 本來就是你能找到的最好的 query rewriter。它理解上下文、意圖、領域詞彙。

這不是搜尋引擎，是 Query Planner

我花了一段時間才看清楚。

我做的東西不是搜尋引擎，更像是一個「有 LLM 前端的 database query planner」。

智慧不在搜尋層。它分佈在兩個地方：寫入時（AI 結構化知識）和查詢時（AI 推斷搜尋參數）。中間的資料庫刻意保持笨。

後來我找到 AWS 的論文，發現他們得出類似的結論：agentic keyword search 達到向量 RAG 的 90% 以上。我們測出來是 92–96% — — 樣本不大，但方向一致。

成本導向：這才是真正的重點

很多人比較 RAG 方案只看準確度。但成本才是真正殺死你的東西。

這個方法從頭到尾都是成本導向的。 不是「向量不好」，而是「向量在這個場景的 ROI 不合理」。

向量搜尋的費用不是一次性的，是每一步都在燒錢：

拿一個 5 人團隊、每天 50 筆 trace、每天 50 次搜尋來算：

看起來向量方案一個月也就幾十塊？問題是這東西會長大。

人變多、trace 變多、搜尋變頻繁 — — 向量的成本是線性增長的。每一筆新 trace 都要 embed，每一次搜尋都要算 cosine，每一次 OpenAI 更新模型你都要重跑全部。

結構化方案？SQL 查詢不管你有 1000 筆還是 100 萬筆，成本都是零。有 index 就快。

5% 的品質差距，換來的是零成本、零維護、零 vendor lock-in。

該花的花，不該花的不花。

什麼時候不行 — — 講清楚

我具體講，因為含糊的「trade-off」段落沒有用。

成本導向，所以它天生不適合探索性搜尋。 這是設計選擇，不是缺陷。你用結構化搜尋換來的是零成本和確定性。你放棄的是模糊匹配的能力。這筆帳還是挺明顯的。

沒有結構就廢了。 這個方法能用是因為知識有 type、tags、content。PDF 沒有這些。Slack 訊息也沒有。你的資料沒結構，這個方法就不適用。

AI 猜錯就漏掉。 整個系統靠 AI 推斷正確的 tag。推錯了 — — 你說「onboarding slow」但 trace 寫的是「activation funnel」 — — 就什麼都找不到。向量搜尋會撈到。我們的 recall 是 0.843，向量是 0.917。差 8% 是真的。

開放式探索很弱。 「我們有哪些重複的 pattern？」「有什麼該擔心的？」沒有明確的 tag、沒有關鍵字。這種問題向量搜尋比較行。如果你的主要需求是探索性搜尋 — — 「我不知道我在找什麼，但我知道大概跟什麼有關」 — — 向量是更好的選擇。

這是給 AI 產生的結構化知識用的，不是給文件庫用的。 你有一萬份 PDF 要做 QA，請用向量。那才是正確的工具。

那 LightRAG 呢？

有人會問：LightRAG 這類 graph-based RAG 不是也能降低成本嗎？

能，但不是零成本。你還是需要建圖、維護節點關係、跑 embedding。比純向量輕，但那個「輕」是相對的。

我們做的事不太一樣。我們是把內容在寫入的時候就結構化 — — type、tags、context 都是 AI 在對話當下產生的。搜尋的時候，query planner 拆解意圖，組合 tag 條件去撈。

效果好到什麼程度？其實很好想像。

就好比你去圖書館找書。一邊是按主題、年份、作者有序排列的書架；另一邊是把所有書丟在地上，靠「這本書的味道跟你要找的很像」來推薦。前者找起來當然快。如果找到之後還能快速翻摘要、補上下文，效率又再拉高一截。

但還是那一句 — — 它不適合目的不明確的探索性問答。「我不知道我在找什麼」這種需求，有序的書架幫不了你，你需要的是那個能聞味道的人。

我處理的是 AI 對話中產生的知識 — — 決策、慣例、發現。天生就有結構。被一個理解上下文的 AI 搜尋。

在這個場景裡，向量是多餘的。在別的場景裡，它可能是必要的。不要拿錘子找釘子。

結語

回頭看，這整件事的核心很簡單：

當你的資料有結構、你的搜尋者有智慧，中間那層不需要也有智慧。

傳統 RAG 把智慧放在搜尋層 — — 用向量、用 embedding、用近似算法。這在非結構化資料上是對的。

但當資料本身就被 AI 結構化過，搜尋又是由 AI 發起的 — — 你等於在兩個聰明人中間放了一個昂貴的翻譯機，而他們本來就說同一種語言。

拿掉翻譯機。直接對話。

5% 的品質差距。6.5 倍的速度。57% 的 token 節省。零 API 費用。零 vendor lock-in。

值不值得，看你的場景。

參考資料：

• Keyword Search is All You Need — Subramanian et al., Amazon Science, arXiv:2602.23368, Dec 2025
• PageIndex: Vectorless RAG — VectifyAI, 98.7% on FinanceBench
• Beyond Embeddings: Completions-Only RAG — Sensible, embedding 優化實測

Every new session, my AI starts from zero. I got tired of re-explaining the same decisions. So I built something about it.

Three weeks ago, I started a conversation with Claude in my terminal. First message:

“We decided last week to use CSS custom properties instead of Tailwind’s theme config for theming. Can you refactor the dark mode toggle?”

Claude’s response: “I don’t have context about previous decisions. Could you share more about the current setup?”

I stared at the screen for a good ten seconds.

We had this exact conversation four days ago. Same repo. Same file. Same decision. I explained it then. I explained the reasoning. I explained why Tailwind’s theme config didn’t work for our use case. Claude understood perfectly, wrote great code, and we moved on.

And now it’s gone. All of it.

This Isn’t a Bug. It’s the Architecture.

Let me be clear — I’m not blaming the AI. This is how LLMs work. Every session is a blank slate. The model doesn’t remember you. It doesn’t remember your codebase. It doesn’t remember the three-hour debugging session you had together last Tuesday.

It’s like hiring a brilliant contractor who gets amnesia every time they leave your office. They show up the next morning, same skills, zero memory. And you have to re-onboard them. Every. Single. Day.

Sounds ridiculous when you put it that way, right?

But that’s exactly what we’re all doing with AI coding assistants right now.

The Real Cost Isn’t the Repetition. It’s the Drift.

At first, I thought the problem was just annoying. Repeating context, re-explaining decisions — inconvenient, sure, but manageable.

Then I noticed something worse.

In one session, I told the AI: “We always use named exports in this project — no default exports.” The AI followed that perfectly. Consistent, clean code.

Next session, different feature, I forgot to mention it. The AI wrote `export default function SettingsPage()` — the exact pattern we’d agreed to avoid.

The code worked fine. Tests passed. I almost merged it.

A week later, another session, I told the AI we handle all errors with a shared `Result` type — no throwing. Forgot to mention it the next day. The AI wrote try-catch blocks everywhere.

That’s when it hit me: the real cost of AI amnesia isn’t the five minutes you waste repeating yourself. It’s the decisions that silently get lost between sessions. The conventions nobody re-states because they assume the AI “knows.” The architectural drift that creeps in, one forgotten context at a time.

You don’t notice it until something breaks in production.

But What About CLAUDE.md / Specs / SpecStory / …?

Before you ask — yes, I’ve tried the obvious solutions. CLAUDE.md, system prompts, rules files, spec-driven workflows like SpecStory, Repomix, document-first AI development. I use some of them to this day.

They work. For a while. For small projects. For solo developers.

But they share one trait: they’re static and manual. You write the rules, you maintain the rules, you hope the AI reads the rules. When your project has forty conventions and fifteen architectural decisions, the instruction file gets long enough that the AI starts ignoring parts of it. When the implementation diverges from the spec — and it always does — nobody updates the document in real time.

The thing is, these approaches aren’t wrong. They’re just solving a different problem. A spec tells the AI what to build. Memory tells the AI what you’ve already decided along the way. One is planning. The other is institutional knowledge. You need both.

So I wasn’t looking to replace any of that. I was looking for something that captures the stuff that happens between the specs — the runtime decisions, the gotchas, the “we tried X but it didn’t work so we switched to Y” moments that no planning document ever contains.

What I Built

I’m an engineer. When something annoys me more than three times, I build a tool.

So I built Trapic — a long-term memory layer for AI coding assistants. It works through MCP (Model Context Protocol), which means the AI can read and write to it directly. No copy-pasting. No manual context files. No “please read this README before we start.”

Here’s the basic idea:

The AI records important decisions, conventions, and discoveries as it works. Things like “we use named exports, no default exports” or “error handling uses Result type, no try-catch” or “all color values go through CSS variables, not hardcoded.”

Next session, the AI automatically recalls what matters. Not everything — just the relevant stuff, filtered by project, branch, and domain.

That’s it. The AI remembers. Across sessions. Across days. Across weeks.

One more thing: it works across tools. The conventions I set up in Cursor are available when I switch to Claude Code. One memory layer, every AI assistant.

Before and After:

Some context first: this is a solo side project. React + TypeScript + Vite, about 15K lines. I’m the only developer, running 3–5 AI sessions per day. These numbers are from one person on one codebase — not a team of twenty. Take them for what they are.

Before Trapic:

- Average context setup per session: 3–5 minutes of manual explanation

- Convention violations caught in self-review: 4–6 per week

- Sessions where I had to re-explain a past decision: roughly 70%

- Time spent on “wait, we decided not to do it that way”: ~2 hours/week

After Trapic:

- Context setup per session: 0 minutes (auto-recalled)

- Convention violations: 0–1 per week (AI checks conventions before committing)

- Sessions requiring re-explanation: under 10%

- Time spent on re-explaining past decisions: ~10 minutes/week

The numbers aren’t dramatic in isolation. Two hours a week doesn’t sound like much for a solo dev.

But compound it. Over three weeks, that’s six hours of pure waste — not building features, not fixing bugs, just repeating things I’ve already said to a machine that already understood them once.

And the convention violations — that’s the one that matters. Every violation that slips through is a bug you’ll find later, a refactor you’ll do later, a “why is this code different from everything else” moment that someone on your team will hit later.

How It Actually Works Day-to-Day

I’m not going to walk you through every feature. But here’s what a typical morning looks like now.

I open my terminal. Start a new session with Claude. The AI automatically calls `trapic_recall` and gets a structured briefing:

- Project foundations: 12 conventions and key decisions for this codebase

- Team updates: what happened since my last session (in a team setup)

- My progress: where I left off yesterday

- Open plans: what’s still in flight

The AI reads all of this silently. No output. No “here’s what I found.” It just… knows.

Then I say: “Let’s add dark mode support to the settings page.”

And the AI already knows we use CSS custom properties for theming. Already knows the color tokens. Already knows we don’t inline style overrides. It writes the code correctly on the first try.

When it’s time to commit, the AI pulls up the project’s conventions and checks the staged diff against them. Convention violation? It fixes it before I even see it.

At the end of the session, the AI records anything new it learned — a new convention, a discovery, a decision — so the next session starts with that knowledge already in place.

No friction. No ceremony. I just code.

What Surprised Me

I expected the time savings. That was the whole point.

What I didn’t expect was how much it changed the way I work with AI.

Before, I treated every session as disposable. Quick questions, short tasks, move on. I didn’t invest in giving the AI deep context because I knew it would be gone tomorrow.

After, I started trusting the AI with bigger, multi-day tasks. Refactoring an entire module. Designing a new feature across multiple files. Things I wouldn’t have delegated before because the ramp-up cost per session was too high.

The AI went from “smart autocomplete that occasionally writes functions” to something closer to a junior developer who actually remembers what the team decided last week.

That’s a fundamentally different tool.

Where It Gets Interesting: Teams

Everything I’ve described so far is solo. One developer, one AI, one memory.

But the moment you add a second person, the problem gets worse by an order of magnitude.

Alice decides in her session that API errors follow RFC 7807. She doesn’t announce it — she just tells her AI, gets the code written, merges the PR. Bob starts his session the next morning. His AI has no idea. He writes error responses in a completely different format. Both pass tests. Both get merged.

Two weeks later, the frontend team discovers they’re parsing two different error shapes. Nobody did anything wrong. The knowledge just didn’t flow.

This is what happens when every developer has their own isolated AI context. Five developers, five AI sessions, five different versions of “what we decided.”

Trapic fixes this because the knowledge isn’t personal — it’s shared. When Alice’s AI records a decision, Bob’s AI sees it the next morning in its recall briefing. Not everything — filtered by project, relevance, and recency. But the important decisions, the foundational conventions, the gotchas? Those cross the boundary between sessions and between people.

It’s like an automatic standup meeting, except more accurate — because it’s pulled from the actual knowledge base, not from someone’s memory of what they did yesterday.

What It Doesn’t Do

I want to be honest about the limitations, because overselling is the fastest way to lose trust.

”Will it slow down my AI?” No. The recall step adds about half a second at the start of a session. After that, zero overhead. The AI reads, stores what it knows, and moves on. You won’t notice it.

”How long does it take to set up?” One command. I’m serious — I spent three hours fighting Claude Code’s plugin marketplace before I gave up and wrote a shell script that does everything in thirty seconds. Run `curl … | bash` from your project root, paste your token when prompted, restart your editor. It sets up the MCP server, hooks, skills, and even injects instructions into your CLAUDE.md. No YAML, no config files to manually edit, no “Duplicate hooks file detected” error messages at 2 AM.

”Will it make my AI smarter?” No. Trapic doesn’t touch the model. It doesn’t improve reasoning or code quality by itself. It doesn’t replace documentation or code reviews or good engineering practices.

What it does is remove the single dumbest failure mode of AI-assisted development: starting from zero every single time.

One problem. Solved properly.

The Bigger Picture

Here’s what I think most people miss about AI coding tools right now.

Everyone’s focused on making the AI smarter. Better models. Bigger context windows. More training data.

But the bottleneck isn’t intelligence. The bottleneck is continuity.

You can have the smartest AI in the world, and if it forgets everything between sessions, you’re still going to waste hours every week repeating yourself. You’re still going to have convention drift. You’re still going to find code that contradicts decisions you made three days ago.

A slightly less smart AI with perfect memory will outperform a genius AI with amnesia. Every time.

Try It or Don’t

Trapic is an MCP server. If your AI coding assistant supports MCP (Claude Code, Cursor, Windsurf, etc.), you can plug it in.

It’s free while we’re in beta. If it saves you time, great. If it doesn’t, uninstall it and move on. I’m not going to pretend this is for everyone.

But if you’ve ever had that moment — staring at your terminal, realizing you’re about to explain the same architectural decision for the fourth time this week — you know exactly the problem I’m talking about.

And now you know there’s a fix.

The AI that remembers beats the smarter AI that forgets. Every time.

Plugin (open source): Trapic-plugin

Get your API token: trapic.ai → Sign up → Tokens page

I’m Malaysian. I’ve been managing software teams in Taiwan for over ten years.

When I first moved here, the biggest culture shock wasn’t the food or the language. It was the silence in meetings.

Growing up in Malaysia — a multiracial society of Malays, Chinese, and Indians — you learn early that nobody is going to guess what you’re thinking. Everyone communicates differently. Everyone has a different style. If you don’t speak up, you simply don’t get heard. That environment trained me to say what I think and correct course later.

So when I ran my first team meeting in Taiwan and asked, “What does everyone think?” — I was not prepared for what happened next.

Silence.

One person eventually said, “Looks good to me.” Everyone else nodded. Meeting over.

I thought maybe my proposal was just that solid. No objections because there was nothing to object to.

Of course not.

After the meeting — in the hallway, in the break room, in Slack DMs — everyone was talking. And what they were saying was: “That proposal has a few problems.”

I was stunned. You were all sitting right there. Why didn’t you say something?

So I started asking people one by one, privately: why don’t you speak up in meetings?

The most common answer wasn’t some dramatic story about being punished for dissent. Nothing that theatrical.

Most people said the same thing: “I didn’t feel comfortable saying it.”

Not comfortable contradicting the manager. Not comfortable disagreeing with a colleague. Not comfortable voicing an idea that might be wrong. Not comfortable making things awkward.

That’s it. Nobody was threatening them. Nobody was shutting them down. They just felt that speaking up was — uncomfortable.

Silence Isn’t the Absence of Ideas. It’s the Price of Speaking Up.

This stuck with me for a long time.

Think about it — from the moment someone enters the workforce, how many times have they regretted speaking up?

Been shut down. Been ignored. Been labeled “difficult.” Been quietly passed over because they challenged the wrong person at the wrong time. It doesn’t take many instances. Two or three is enough.

The brain is efficient. It remembers which behaviors lead to pain. Once “expressing a different opinion” gets linked to “unpleasant outcome” a few times, silence becomes instinct.

It’s not that they don’t want to speak. Their body is protecting them.

So when you stand at the front of the room and ask, “Any thoughts?” and wonder why nobody says a word —

What you see is silence.

What you don’t see is every uncomfortable experience behind it.

You Think You’re Open. Your Behavior Says Otherwise.

A lot of managers — myself included, once upon a time — genuinely believe they’re open to feedback.

“I always ask for different opinions.”

“I never get upset when someone disagrees.”

“My door is always open.”

Sure. You asked. But what did you do after?

Someone offered a different take. You immediately responded with “Yeah, but I think…” and spent five minutes explaining why your approach was better. You weren’t angry. Your tone was perfectly pleasant. But the result was the same — their idea was overridden, and you went with yours.

Will they speak up next time?

Probably not.

Because they learned something: when the manager asks for opinions, it’s a formality. The decision was already made. Asking was just politeness.

The worst part? You have no idea you’re doing this. You genuinely think you listened.

But your behavior told the team something else entirely: speaking up doesn’t change anything.

The Silicon Valley Playbook Doesn’t Work Here

I’ll admit it — I made this mistake.

Early on, I imported all the popular practices: open brainstorming sessions, encouraging dissent, “disagree and commit,” contrarian opinions go first. I even opened meetings by saying, “I want to hear different perspectives today. Don’t just agree with me.”

Guess what happened?

Nobody spoke. It was actually worse than before — because now, on top of not feeling safe to speak, there was additional pressure: “The boss is asking me to talk, but I don’t know what’s safe to say.”

It took me a while to understand: it wasn’t a method problem. It was a sequence problem.

I was demanding honesty before I’d established safety. The order was wrong.

These days, everyone talks about psychological safety. Google’s Project Aristotle found it’s the number one factor in high-performing teams. So managers everywhere announce: “We’re building psychological safety! Everyone should feel free to speak their minds!”

Congratulations. You just did the most useless thing possible.

Psychological safety isn’t declared. It’s demonstrated. You can’t tell someone who’s afraid of water, “The water is safe, just jump in,” and expect them to dive.

They need to see someone else jump in and not drown.

They need to see it many times.

Then, slowly, they’ll start dipping their toes in.

What Actually Works

I won’t pretend I’ve figured it all out. But a few things have worked for me over the years.

First, be the first to make mistakes — publicly.

Not on purpose. But when you genuinely get something wrong, own it in front of the team. Say it in a meeting: “That decision last sprint was mine. It didn’t work out. I misjudged it.”

Do this once, and the team will be surprised. Do it three times, and they’ll start to believe that mistakes aren’t punished. Do it ten times, and someone might finally feel safe enough to make a mistake in front of you.

Yes, ten times.

You demonstrate it ten times before someone follows once. The ratio sounds terrible, but there’s no shortcut.

Second, when someone does speak up — shut up.

This was the hardest lesson for me.

Someone shares an idea. You think it’s off. Your instinct is to respond, to add context, to “refine” their point.

Hold it.

Just say: “Can you tell me more?” Or simply nod.

You don’t have to agree. But let them finish. Then thank them before you respond.

What the rest of the team sees in that moment matters more than what you actually say. They see that speaking up didn’t result in an immediate rebuttal. That’s more powerful than any motivational speech.

Third, start in one-on-ones, not group settings.

Some people are never going to be comfortable speaking in front of ten colleagues. That’s not a courage problem — it’s personality.

In a one-on-one, ask them what they really think. They’ll often surprise you with how articulate and thoughtful they are. Then you can ask: “That’s a great point. Would you be open to sharing it with the team next time?”

Give them the choice. Invite them to speak, don’t put them on the spot. There’s a big difference.

Fourth, reward the act of speaking up — not just the right answers.

Someone raises a concern in a meeting. Turns out it wasn’t actually an issue. Most managers say, “Oh, that’s not a problem, don’t worry about it.” And move on.

Instead, try: “Thanks for raising that. That’s exactly the kind of thing we should be flagging.”

The team needs to know that speaking up has value regardless of whether the content is right or wrong. You’re not rewarding their answer. You’re rewarding their willingness.

When speaking up is consistently rewarded, silence starts to fade.

One Last Thing

After ten-plus years of managing teams here, the most important thing I’ve learned is: don’t rush it.

When I first arrived, I saw “nobody talks in meetings” as a problem to solve. Now I see it as something to understand.

Behind every person’s silence, there’s a reason. Maybe it’s past experience. Maybe it’s a deep-rooted sense that speaking up is simply not done. Maybe they’re still figuring out whether you — their manager — are someone worth trusting.

You don’t need them to become different people overnight. That’s not realistic, and it’s not necessary.

You just need to do one thing: bring the cost of speaking up down to zero.

How? Not with slogans. Not with announcements. With every interaction, every reaction, every day — proving, little by little, that in this team, honesty won’t get you hurt.

It’s slow. But it’s the only thing that works.

And honestly, if you can’t get this right, then everything else you do as a manager — the OKRs, the performance reviews, the team-building offsites — is built on sand.

Because a team that’s afraid to speak will only ever give you the answers they think you want to hear.

Not the real ones.

你不是不想管人，你是不想管爛事。

我每次聽到這句話，都會笑一下。

不是嘲笑，是無奈。

因為我很早就知道自己是當主管的人。不是因為我不愛寫 code，是因為我看到的問題從來不只是 code 本身。需求為什麼不清楚、流程為什麼卡住、團隊為什麼沒有方向 — — 這些事在我腦子裡的優先級，一直比「這段程式怎麼寫更漂亮」來得高。

所以當我聽到資深工程師說「我只想寫 code」的時候，我不覺得他在說真話。

我覺得他在躲。

你討厭的不是管理，是你看過的那些管理

我們先誠實面對一件事：大部分工程師說「不想當主管」的時候，腦海裡浮現的畫面是什麼？

是無止盡的會議。是寫不完的週報月報季報。是處理兩個工程師之間的恩怨情仇。是被老闆追問「這個功能什麼時候好」，然後轉頭去追問自己的人「這個功能什麼時候好」。

是一個不寫 code、不碰技術、整天在開會和寫信的人。

你看著那個人，心裡想：「我才不要變成那樣。」

這不是你在拒絕管理。

這是你在拒絕一個爛的管理範本。

「寫 code」和「當主管」從來不是二選一

業界製造了一個很漂亮的假選擇題：IC track 和 Management track。

好像你走了管理，就要跟程式碼說再見。好像你繼續寫 code，就代表你不用管人。

事實上，這條線根本不存在。

你以為你在選「要不要管人」，其實你在選「要不要對更大範圍的事情負責」。

寫 code 是解決一個問題。帶團隊是解決一類問題。本質上都是工程思維 — — 拆解、設計、執行、迭代。

而且我可以很負責任地告訴你，最強的技術主管，從來不是那個寫 code 最厲害的人。

技術主管不是寫 code 最強的那個人

這點很多人搞不清楚。

他們以為升上去就是因為技術最強，當了主管就要證明自己技術最強，所有技術決策都要自己拍板，所有架構都要自己定。

然後就變成了一言堂。

我見過太多這樣的主管了。會議上，他問大家的意見，但所有人都知道最後會用他的方案。慢慢的，沒有人再提意見了。慢慢的，整個團隊只剩一個人在思考。

這不叫管理，這叫一個人在 solo，只是底下多了幾個打字的（我在曾經的團隊裡做了個side project就叫Solo，有人問我為何，我都沒說真話，我就是在諷刺這裡怎麼變成我一個人在思考）

技術主管真正要做的事，是決策 — — 不是什麼都自己決定，而是知道什麼時候該聽、什麼時候該選、什麼時候該放手讓別人決定。

決策和一言堂的差別是什麼？

決策是：我聽完所有人的觀點，我評估了風險、成本和時間，我做了一個判斷，我為這個判斷負責。

一言堂是：我不需要聽你的，我說了算。

看起來結果可能一樣 — — 最後都是主管拍板。但過程完全不同。團隊感受到的東西完全不同。

一個讓人成長，一個讓人離職。

不過，怎麼做好這件事，怎麼從「管人」變成「管理得好」，那又是另一個很大的題目了。下次再說。

你在怕什麼？

我不是要說每個工程師都應該當主管。不是的。

有些人確實在 IC 的路上走得又深又遠，成為領域專家、架構師、技術顧問。那是很好的路。

但你得先搞清楚，你是「選擇」留在 IC，還是「逃避」去當主管。

這兩個長得很像，但本質完全不同。

怎麼分辨？

問自己一個問題：你是對「程式碼」不滿，還是對「系統」不滿？

如果你每天抱怨的是：這段 code 好爛、這個 API 設計得很差、這個架構撐不住 — — 你在意的是程式碼本身，IC 的路適合你。

但如果你抱怨的是：為什麼需求永遠不清楚、為什麼團隊溝通這麼差、為什麼明明有更好的做法沒有人推動、為什麼每次都在重複一樣的錯 — —

你在意的已經不是 code 了。你在意的是系統。是流程。是人。

這時候你嘴上說的「我只想寫 code」，其實是一句謊話。

你心裡想改變的，遠比一段程式碼大得多。

最後

「我只想寫 code」是一個很安全的句子。

說出來的時候，沒有人會質疑你。大家會覺得你很專注、很有工匠精神、很 pure。

但安全的選擇，不一定是對的選擇。

你可以選擇不當主管。真的可以。世界上有太多優秀的 Staff Engineer、Principal Engineer，他們選擇了那條路，過得很好。

但如果你選擇的理由是「我不想變成我主管那樣」 — —

那不是選擇。

那是逃避。

而逃避最大的代價，不是你沒當上主管。

是你明明看到了問題，卻選擇不去碰。明明有能力改變，卻說服自己那不是你的事。然後繼續跟自己說：「我只想寫 code。」

這才是資深工程師最大的謊言。

When the guy who invented Story Points says “if I did invent them, I’m sorry now,” you know something has gone terribly wrong.

A few days ago, I was having dinner with a friend. He’s a backend engineer at a startup, been there about three years.

Halfway through the meal, he let out a sigh and said: “We adopted Scrum six months ago. The most productive part of my day is now the forty minutes between the end of Daily Standup and the start of the next meeting.”

I laughed.

Not because it was funny. Because it was painfully real.

Let Me Start with the Conclusion

The spirit of Agile itself isn’t wrong. What’s wrong is that the entire industry turned it into a business, a ritual, a religion.

In other words, what you’re experiencing at your company right now — the daily standup reports, the biweekly sprints, the endless estimation meetings, a Scrum Master whose job description nobody can quite explain — most of it has absolutely nothing to do with what the Agile Manifesto was trying to say.

How an Adjective Became an Industry

In 2001, seventeen software developers gathered at a ski resort in Utah and wrote the Agile Manifesto. Four statements. Simple:

- Individuals and interactions over processes and tools

- Working software over comprehensive documentation

- Customer collaboration over contract negotiation

- Responding to change over following a plan

That’s it. No frameworks. No certifications. No Scrum Masters. No SAFe.

Dave Thomas, one of the original signatories, later said something in a talk that I think nails it perfectly:

“Agile was originally an adjective. But you can’t sell adjectives. You can only sell nouns.”

So agile became Agile.

And then Agile became an industry.

A two-day course, a CSM certification, a thousand dollars. Plus $750 a year to maintain it. Tell me — is that spreading the spirit of agility, or is that selling certificates?

The Agile You Think You’re Doing vs. The Agile You’re Actually Doing

Imagine you join a gym. The coach tells you: “The core philosophy of fitness is continuous progress, listening to your body, and taking it one step at a time.”

Then you show up and find out that every day starts with a one-hour meeting to discuss what you’ll train today, what you trained yesterday, and what problems you ran into during training. After your workout, you fill out a form estimating how much you can lift this week. Every two weeks, there’s a Review to examine why you didn’t hit your estimated numbers.

Are you still working out? Or are you just in meetings?

That’s what “Agile development” looks like at most companies.

Daily Standup becomes a daily status report. Your manager stands there listening to what you’re going to do today, and if you don’t look “busy enough,” you’re assumed to be slacking off.

Sprints become “waterfalls with deadlines.” Agile was supposed to be about embracing change, but every Sprint comes with a delivery commitment that can’t be touched. Change? What change? Next Sprint, maybe.

Story Points become performance metrics. You only did 13 points this Sprint but 21 last Sprint — are you getting lazy?

Mate, Ron Jeffries, the guy who invented Story Points, said it himself: “I may have invented story points, and if I did, I’m sorry now.”

The inventor is apologizing. And you’re still tracking Velocity.

The Most Ironic Part

The first line of the Agile Manifesto: “Individuals and interactions over processes and tools.”

And what did the entire Agile industry do?

Sell processes. Sell tools. Sell Jira. Sell certifications. Sell frameworks. Sell consultants.

Ron Jeffries, co-creator of XP, wrote an article in 2018 called *Developers Should Abandon Agile*. He introduced a concept called Dark Scrum:

“When ‘Agile’ ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to ‘go faster’.”

Yeah. He’s describing your company’s Scrum.

The Framework Itself Is the Problem

Someone will say: “Agile isn’t wrong. You just didn’t implement it correctly.”

I’ve been hearing this for ten years.

Every time a Scrum project fails, the excuse is “Scrum wasn’t properly implemented.” Every time estimates are off, the excuse is “you haven’t developed the habit of estimating yet.” Every time a Sprint blows up, the excuse is “scope wasn’t controlled well enough.”

So let me ask you — if most intelligent software engineers can’t get it right, is that a people problem or a framework problem?

A framework that only works when everyone on the team is a genius is, by definition, fragile.

It’s like designing a car that only a racing driver can operate, and then blaming everyone else for not knowing how to drive. What’s the point of that car?

So What Do We Do?

I’m not saying the spirit of Agile is wrong. Embracing change, iterating fast, continuous improvement — these ideas are genuinely good.

But ideas are ideas. Frameworks are frameworks.

The folks at Basecamp came up with Shape Up: six-week cycles, no backlog, no estimates, no Velocity tracking. After every six weeks, two weeks of cool-down. They’ve been running this way for over twenty years.

Others advocate for #NoEstimates — skip the guessing, use actual delivery data to project progress.

And some say the best approach is to go back to XP’s technical practices — TDD, continuous integration, pair programming, refactoring. These are the things that actually improve software quality. Not standing in a circle every morning.

The answer has always been simple: find what works for your team, and keep adjusting.

Dave Thomas said it best: “The ideal consultant should tell you — I don’t know what works best for you. You don’t either. But we have to start somewhere. Six months from now, what you’re doing won’t have any brand name, because you invented it yourselves.”

Right?

The question was never whether to be agile or not.

The question is whether you’re actually thinking about what problem you’re trying to solve.

One Last Thing

If your team is currently “doing Agile” but you feel more exhausted, more anxious, and less productive than before — that’s not your fault.

It’s the framework’s fault. It’s the implementation’s fault. It’s the stuff the people who sold you that certification will never tell you.

The spirit of the Agile Manifesto isn’t wrong.

But the words “Agile Development,” twenty-five years later, have become a hollow shell.

Inside it, you’ll find meetings, story points, status reports, certification fees, and a bunch of Scrum Masters who aren’t quite sure what they’re supposed to be doing.

This isn’t Agile.

This is just agile in name only.

TLDR: Try it now: Install the Product Lock MCP server to let your AI agent generate, review, and score product boundaries automatically

claude mcp add product-lock — npx product-lock-mcp

I’ve managed engineering teams for years. Most of the job isn’t about building — it’s about drawing lines. Defining scope. Running reviews. Saying “no” more often than “yes.” You don’t build great products by saying yes to everything.

Then AI started writing code.

In 2025, I started using AI to write code. Not snippets — real, full features. And it was incredible. Claude, GPT, Copilot — they could scaffold an entire backend in an afternoon. What used to take a team a sprint now took a single session.

But something felt off.

The “helpful intern” problem

AI is like the most eager, most capable, most tireless intern you’ve ever hired. You say “build me a chat app.” It builds a chat app. And then it adds emoji reactions. And voice calls. And file sharing. And message editing. And read receipts with typing indicators. And a notification system. And a settings page with theme customization.

You didn’t ask for any of that.

But AI doesn’t know that, because you never said no. And unlike a human engineer who has limited hours in the day, AI has no natural stopping point. It will keep building until you tell it to stop.

In management, we have a word for this: scope creep. And every experienced manager knows — the hardest part of building a product isn’t deciding what to build. It’s deciding what NOT to build.

The moment it clicked

I was reviewing AI-generated code one evening. The AI had built everything I asked for. But it also added a payment module. I never mentioned payments. The AI just… thought it would be helpful.

And I thought: I’ve seen this before.

This is exactly what happens with a new team member who’s talented but doesn’t understand the product boundary. They’re not wrong — payments probably will be needed someday. But adding it now, without discussion, without approval, without understanding the product strategy? That’s a problem.

With a human, you fix this through management. You define the scope. You set up review processes. You track decisions. You have a “not now” list.

With AI, there was nothing like that. Every session started fresh. No scope document. No review protocol. No institutional memory.

So I built one.

What if we managed AI the way we manage teams?

That’s the core idea behind Product Lock. It’s not a framework. It’s not a tool. It’s a protocol — a way to encode the management practices that every good manager already knows, into a format that AI can follow.

Here’s the parallel:

Every field in product.lock.json maps to something I already did as a manager — just on a whiteboard, in a Notion doc, or in my head. Product Lock makes it machine-readable.

The file that matters most

If you take one thing from this, let it be this: the denied field is the most important thing in the entire specification.

"denied": {
  "executeTrade": "Market intelligence only — no brokerage liability",
  "voiceCall": "Text-based communication only"
}

In traditional development, you don’t need a “denied” list because humans are slow. The boundary is natural. You simply don’t have time to build everything.

AI is different. AI is fast, eager, and has no sense of product strategy. If you don’t explicitly say “don’t build this,” it might. And when it does, you might not even notice — buried in a pull request with 50 other files.

denied is the "no" that every good manager says. It's the scope line that keeps products focused. It's the thing that separates "we haven't built it yet" from "we will never build it, and here's why."

The test I use: “If AI added this on its own, would it be a product violation?” If yes, it goes in denied. If no, it's just backlog.

Three roles, zero trust

Here’s where my management experience really kicked in.

In any healthy organization, you don’t let the person who builds the thing also verify the thing. That’s basic governance. The developer doesn’t approve their own PR. The accountant doesn’t audit their own books.

Product Lock enforces the same separation:

Human (Boss)    → approves the lock
AI Worker       → writes code + generates lock
AI Reviewer     → independently verifies code against lock

Two AIs. They don’t trust each other. One builds, one audits. The human reads a summary — not code, just a rendered Markdown view of what the product is — and makes the call.

This is exactly how I ran teams. I didn’t read every line of code my engineers wrote. I read the PRD, I read the design doc, I reviewed the demo. Product Lock is the same workflow, adapted for AI.

The full management loop

Over time, I realized scope definition alone wasn’t enough. A good manager doesn’t just define scope and walk away. They track progress, measure complexity, and maintain institutional memory.

So Product Lock grew into four files:

File.               Management equivalent
product.lock.json - The scope document — what we're building and what we're not
product.plan.md.  - The implementation blueprint — how we're building it
Scoring (PLS),    - "The complexity measure — how big is this product, really?"
Worklog           - "The decision log — what changed, when, and why"

The scoring system was born from a real need. As a manager, I always wanted to answer: “Is this product getting more complex over time? Are we creeping?” Product Lock Score (PLS) gives a single number derived entirely from the lock. Same lock, same score. Language and framework don’t matter. If the score keeps going up and no one approved it — you’ve got scope creep.

The worklog was born from the AI memory problem. AI sessions are ephemeral. Context windows expire. Conversations get compressed. But product decisions persist. The worklog captures what happened so the next session — or the next agent — can pick up where the last one left off.

What this is NOT

Let me be clear about what Product Lock isn’t.

It’s not a replacement for requirements documents. It’s not an architecture diagram. It’s not a project management tool. It’s not about controlling AI or restricting what it can do.

It’s about giving AI the same context a good team member would have. When you onboard a new engineer, you tell them: here’s what we’re building, here’s who our users are, here’s what’s out of scope. Product Lock is that onboarding doc — but for AI.

It’s also not something humans write by hand. The whole point is that AI generates the lock by analyzing the codebase. Humans review it. AI verifies against it. The human’s job is to read, think, and approve — the same job a manager has always had.

Why I think this matters now

We’re at a strange moment in software. AI can write most of the code. The capability is there. But the trust isn’t.

I’ve seen studies showing 45% vulnerability rates in AI-generated code. I’ve seen surveys showing only 29% of developers trust AI output. The problem isn’t that AI can’t code. The problem is that we don’t have the management layer to make AI-generated software trustworthy.

We solved this problem for human teams decades ago. We have code reviews, architecture reviews, scope documents, sprint planning, retrospectives. We have managers whose entire job is drawing boundaries and making decisions.

For AI? We had nothing. Just a prompt and a prayer.

Product Lock is my attempt to bring that management layer to AI development. Not because AI is bad. But because even the best engineer needs a scope, a review, and someone who says “no” when it matters.

Try it

The spec is open. MIT licensed. One JSON file.

Give the Generator Guide to an AI and point it at your codebase:

“Read this guide, then analyze this codebase and generate a product.lock.json.”

Then give the Reviewer Guide to a different AI:

“Read this guide, then verify this codebase against this product.lock.json.”

Two AIs. Independent. One builds, one checks. You read the lock, approve or deny, and move on.

You already know how to do this. You’ve been doing it with humans your whole career.

Now do it with AI.

Product Lock is open source. GitHub · Spec

我一直不太信任 AI 寫的程式。

不是那種「AI 會取代工程師」的恐懼，那個我之前寫過一篇了，結論是不會，至少不是現在這種取代法。我說的是一種更深層的不安 — — AI 寫出來的東西，你怎麼知道它是對的？

這個問題困擾了我好幾個月，於是我決定做點什麼。

起點：一碗看起來很好吃但你不敢吃的麵

事情是這樣的。

2026 年，AI 寫 code 已經不是什麼新鮮事。你跟它說「幫我做一個聊天系統」，它嘩啦嘩啦幾分鐘就給你幾千行程式碼，結構清楚，命名漂亮，還會幫你加註解。

但你敢直接用嗎？

就好像路邊有一攤免費的牛肉麵，香味撲鼻，看起來用料實在，可是你不知道老闆是誰，廚房長什麼樣，食材從哪來。十個人裡面有四個吃完拉肚子。

數據也是這樣說的 — — 45% 的 AI 生成程式碼含安全漏洞。四成五。你手上的 code 快一半可能有問題。

所以我想，如果 AI 的能力已經到了，但信任跟不上，那我就做一個東西來解決信任問題。

第一個版本：我來當翻譯官

我的第一個想法很直覺。

AI 直接寫 code 不可信，對吧？那如果 AI 不直接寫 code 呢？

我設計了一套中間格式 — — 你可以把它想成一份「施工藍圖」。AI 負責畫藍圖，藍圖可以被人看懂、被機器驗證。然後由一組我寫好的「翻譯器」，把藍圖轉成真正的程式碼。

信任被拆成兩段：

> 你信任 AI 畫的藍圖 → 因為藍圖可以被檢查

> 你信任翻譯出的 code → 因為翻譯器是我寫的，是確定性的，測過的

概念很漂亮，對吧。我還真的做出來了，寫了十幾個翻譯器，涵蓋資料庫、後端、前端、驗證層、狀態管理。一千多個測試，全部通過。

做完那天我還蠻有成就感的。

然後我開始問自己一個問題。

第一次拆：AI 自己就會寫啊

翻譯器做的事情是什麼？把「這個 entity 有 name、email 兩個欄位」翻譯成 Prisma schema、翻譯成 API route、翻譯成前端 hook。

但 AI 自己也會做這件事啊。你跟 Claude 說「幫我寫一個 User entity 的 CRUD」，它直接就給你 Prisma + Hono + React 了。格式還比我的翻譯器靈活。

而且 AI 只會越來越強。今天它可能寫得不太一致，明年它可能寫得跟資深工程師一樣穩。

我花了幾個月寫的翻譯器，本質上是在跟 AI 的能力賽跑。而且我跑不贏。

好吧，那方向不對。翻譯器砍掉，重新想。

第二個版本：不生成，改審計

既然 AI 自己會寫 code，那我不幫它寫，我幫人類「看」。

一個資深架構師面對 AI 生成的三萬行 code，根本看不完。但如果我把架構意圖抽出來 — — 這個系統有哪些模組、資料怎麼流動、誰依賴誰 — — 壓縮成兩百行結構化描述，架構師五分鐘就能判斷「這個架構合不合理」。

我覺得這個方向好多了。不是生成 code，是幫人類做架構層面的審計。

然後我又問了自己一個問題：這個「結構化描述」，跟一份寫得好的 CLAUDE.md 有什麼差別？

答案是：沒什麼差別。

你在 AI 的指令檔裡寫好架構規範 — — 「Payment 要獨立模組」「所有寫入操作要有驗證」「不准循環依賴」 — — AI 就照做了。不需要什麼架構審計框架。

這不就是一份 skill 嗎？

第三個版本：那做 QA 吧

好，skill 是 input 端的建議，AI 不一定照做。那我做 output 端的驗證 — — 跑完 AI 的產出，自動檢查符不符合架構規範。

就是一個架構層級的 linter。

想法不錯，但問題是：這東西已經存在了。ESLint 有 boundaries plugin，Java 有 ArchUnit，JavaScript 有 dependency-cruiser。人家做了好幾年，生態成熟，我一個人怎麼跟成熟的開源工具比？

差異化在哪？

我想了半天，誠實的答案是：差異化不夠。

第四個版本：專家知識打包

拆了三次之後，我開始從不同的角度想。

我做聊天系統的時候，最痛的不是 AI 寫得不好，是我不知道 AI 的建議對不對。AI 說用 WebSocket 加 message queue，聽起來合理，但我怎麼知道這是最佳實踐還是它在瞎掰？

如果有一個做過五年聊天系統的資深架構師，把他踩過的坑、做過的決策、為什麼選 A 不選 B，全部結構化地打包起來，然後我把這份「專家知識」餵給 AI — — AI 就不是從零在猜了。

就像你用 npm 的 react-datepicker，你不需要知道裡面怎麼處理時區和閏年，你信任的是：有人比你更懂這件事，他已經幫你處理好了。

我要做的就是這件事 — — 但不是打包 code，是打包知識。

這次我覺得方向終於對了。

我甚至想到了商業模式：做成 MCP Server，AI 工具可以自動拉取專家知識，開發者裝一下就好，背後的事全自動。freelancer 和資深工程師可以把自己的專業上架，被動收入，知識變現。

完美。

然後又來了那個該死的問題。

最後一次拆：AI 已經讀完了

AI 的訓練資料包含什麼？

所有的技術文章。所有的 Stack Overflow。所有 GitHub 上的開源專案。所有的架構書籍。Netflix 的技術 blog、Uber 的系統設計文件、Martin Fowler 寫的每一篇 pattern。

我想打包進去的「專家知識」 — — 聊天系統要用 WebSocket 加 message queue、已讀回條要 batch update、大群組用 fan-out-on-read — — AI 早就知道了。

它讀過的聊天系統文章，比任何一個單一專家都多。一萬倍都不止。

那我到底在賣什麼？賣 AI 已經知道的東西嗎？

五次，全部拆掉

回頭看這幾個月的路：

- 翻譯器 → AI 自己就會寫

- 架構審計 → 一份 skill 就好了

- 架構 QA → 現成工具已經有

- 專家知識模組 → 放個 GitHub markdown 就行

- 知識即服務 → AI 已經讀完全人類的知識了

每走一步，都覺得自己找到了方向。每多想一層，方向又沒了。

像什麼呢？就像你蓋房子，地基打了，牆砌了，屋頂架了，最後退後兩步看 — — 發現這塊地根本不是你的。

我到底在害怕什麼

拆到最後，我才看清楚一件事。

我做的所有嘗試，背後有一個共同的假設：「AI 不可信，人類比較可信。」

翻譯器是因為我不信 AI 直接寫的 code。架構審計是因為我覺得人類架構師的判斷比 AI 準。專家知識模組是因為我覺得人類專家知道的東西比 AI 多。

但等一下。

人類做的就一定是對的嗎？

我當了十幾年工程師，看過多少資深工程師做的爛架構？看過多少「最佳實踐」其實是某個人的個人偏好？看過多少信誓旦旦的技術選型，半年後被推翻？

我在之前的文章寫過，客戶會點一碗牛肉麵加豬排和西瓜，然後堅持要全部混在一起。但那不只是客戶的問題 — — 工程師自己也會做出一樣荒謬的決定，只是我們把它包裝在「架構設計」和「技術選型」的術語裡。

AI 讀過的架構文章比我多一萬倍。它見過的系統設計比任何單一人類都多。它不會因為上一份工作用 Spring Boot 就覺得全世界都該用 Spring Boot。它沒有情緒，沒有偏見，沒有「我之前做過所以一定對」的慣性。

而我花了好幾個月，做了一個又一個方案，本質上都是在試圖證明「人類比 AI 更值得信任」。

然後我一層一層把自己拆掉了。

所以呢

我不是說 AI 就是對的。它當然也會錯。

但我原本以為的信任公式：

人類專家 > AI

也許真正的公式是：

好的問題 > 好的答案

AI 不缺知識。它缺的是好的問題 — — 精準的需求、清楚的限制條件、具體的情境描述。而這些，恰好是人類最擅長的。

也許我該做的不是幫 AI「補知識」，也不是幫人類「驗 AI」。也許方向完全不在這兩者之間。

但我還沒想到是什麼。

我能確定的只有一件事 — — 這幾個月最大的收穫，不是做出了什麼東西，而是認清了自己的偏見。

我不信任 AI，所以我一直在造工具來約束它。

可當我認真審視之後發現，我約束的不是 AI。

是我自己。

給我答案

在一次分享中，得到蠻多人的正面回饋，但其中一個讓我印象深刻的回饋是，內容類似是「給我做法，告訴我，我能得到什麼？」

就好比我在寫工作心得，為了照顧這群人，我已經寫了一篇「認真篇」，而最後我再寫這篇，純粹這篇才是我真正的心聲～

我自己觀念，是這樣認為，很多人以為，讀了一堆管理學的書，你就懂管理；看了一堆財金指南，就能變成理財專家。我覺得這個想法，是比較不實際的。

有一些閱歷的人應該都大概清醒了，不管你看多少成功人士的分享，背誦多少個做人做事的攻略和方法，真的記得住，做的到，得到不錯的結果的，你人生中又有多少次這樣的經驗呢？

記得有一次不小心看到C羅的採訪片段，內容大概該是這樣：

「我不怕告訴你我的訓練菜單和方法，因為即便我告訴你，你也未必做得到，沒有人願意每天都到健身房訓練。」

所以最後我自己得到的結論是，做吧，別再想了，別再聽了。

事情，根本就沒有標準答案。

也不要試圖從別人嘴巴得到答案，因為即便我告訴你方法和步驟，你也未必能得到我相同的產出。

雖然如此，但從別人口中依然可以得到一些規律，後來我也盡最大的努力，整理出這些規律，但這些規律都是發生在我經歷一切之後，而非執行之前，所以很可能每個人遇到的困難和反應，做法和策略都不同，只能參考用而已。

我這幾年做的最頻繁的三件事，判斷、決策和決定。

決策和決定的差別

決策和決定的差別是什麼？我隨口問了一下身邊的人，大多數時候，我都得到安靜和空白。

工作的越久，越要懂得下決策

我前幾天看了一部電影，男主和恐怖份子的鬥智鬥勇的故事。

看完預告之後，或正片之後，你可以看到大量的判斷、決策、決定互相交替的運作。

好幾次看到有些標題寫「資深工程師」的朋友，我都會認定這些人是一個能夠下判斷和決策的人。

決策就是一個局

一個leader、或者一個coach、或是一個主導者，最重要的技能，我覺得決策是必備之一。

決策沒有好和壞，決策就是一個長遠的目標，過程中不斷的糾正和調整，決策就是在模糊不清的情況下，做一個方向和定位，然後想辦法往前走。

舉個例子，教練寫了一個菜單，每週訓練五次，每次一小時，比賽的時候，就會發揮作用。

這樣的假設，是一個決策，是不是真的有作用，不知道，但，教練的作用就是讓他的假設發揮作用。

所以一個主管或者資深的工作者，腦袋裡面不能只有做，還需要想和觀察。

判斷就是一個快

判斷（Judgment）就是講求一個「快 ->執行-> 結果 -> 糾正 -> 確認 」的過程，因為只要拖的越久，事情的變化就會越多，你又要重新掌握一次資訊，再做一次判斷，當並非全部事情都要有「執行」有時候，「不執行任何事情」也是一個action。

決定就是一個「下一步」

決定最大功能，就是讓事情move on，很多時候遲遲不下決定，事情就會停在哪裡，沒有進展。

整理了一些小筆記，可以參考看看

1. 大事，用決策。
2. 小事，用決定。
3. 不知道是什麼事，用判斷。

而順序是這樣的。

我們做「判斷」，會得到很多小事需要做「決定」，而這些決定，都是擁有一個共同的「決策」。

不管怎麼變，都不要偏離「決策」太遠。

就用以上的電影來舉例的話：

決策就是要「讓炸彈做到阻嚇國會的效果，從而讓國防預算…」，這個決策之下，決定要用誰當作關鍵人物，不重要，只要效果和目的達成就好，所以故事的開始，恐怖份子做了個判斷，他認為…

所以故事中，事情變來變去的，突發狀況一大堆，但決策從始至終都沒變，變的只是一個又一個的決定，一個又一個突發狀況，要判斷一次又一次的…

假設，我訂了團隊目標就是增加效率和減少開發成本，這是一個決策。

突然團隊有人花很多時間，去想「react 和 vue」哪一個比較好，這是一個決定，不管用什麼都好，他不影響決策的核心，所以這個決定不怎麼重要。

又或者，我們突然接到三個不同專案的需求，分別由三個工程師執行，他們三個其實可以各做各的，但這個和決策違背，所以這裡需要做一個判斷，怎麼做這三個需求，我決定整理出這三個需求的共性和開發細節，或者他們可以坐在一起。

掌握的資訊越多，越能夠判斷和決定出更細節的事情，從而更加邁進決策。

推動力

把以上的三個動作連環起來，我簡稱為推動力。

怎麼講事情進行下去，有千千萬萬種方法，但萬變不離其中，move on 是一門藝術。

這篇文章沒什麼脈絡，基本上就是想到什麼就寫什麼，都是我在高鐵上一點點完成。

回歸到我2024年的的心得，應該就是更能準決的描述出，我心目中對於「資深」和「專業」的想像，我自己也試圖在反覆驗證這些觀點。

為2024年做一個決策，例如說，做一個全公司用的系統。

然後在書房研究了一兩個月，搞出了個prototype，然後找人要資源把事情推動，在過程中，不斷來回的判斷和決定，將最適合的工作找到最適合的人選，然後事情自然水到渠成，雖然現在還不是最好的，但至少我們開始了，且它只會越來越好。

這個計畫從來都不是一個作業，也不是一個命令，而是一個願景，我身在組織中，也體會到那種不容易和困難。

這個計畫沒有人告訴我怎麼做，也沒有人承諾過做了會得到什麼，甚至很多人不知道背後的研發心酸事，但這都不重要，如同我上面說的，做這些的決策不是為了得到什麼，如果真的得到了一些肯定（如下圖），我心存感激，萬一沒有，也無所謂，我也得到了一個驗證我思考方法的機會。

當事情開始之後，找到支持你的主管、PM、設計、跨部門的同事，讓事情一步一步推進，我很幸運的這一步運氣不錯，都有很多好同事和好主管們的鼎力支持。

所以這樣算起來，我的心想事成2024又達標了，2025年繼續許願，今年除了再來繼續閉關做個決策之外，還想要利用有限的能力和時間，做一點和工作無關的事情。