結束的時候，有聽眾問了一個問題，他說：「我聽說你今年也會去 jcconf 當講者，到底投稿要選什麼題目啊？我都想不到合適的題目。」

我發現我大致上採用了兩個方法論來尋找題目。

從應用出發

在實際的工作中，總是會遇到很多挑戰。

1. 維護系統的經驗：

比方說幫客戶維護一個 MES 系統，該系統有一些與第三方 API 整合的部分。第三方 API 常常呼叫不到，導致系統異常；但我 debug 時，必須在一大群 Log 裡面尋找跡象，因為第三方 API 的 Log 跟 Web Server 的 Log 都混在一起，非常難以處理。而且我也沒有辦法簡單地一鍵重啟 API 呼叫，也沒有 UI 可以查看第三方 API 的呼叫完成的狀態。這類問題經過研究後，我就找到了「流程引擎」這個方向，有趣的事情是，2025 JCConf 已經有講者談過這個題目。

2. 產品開發的啟發：

又比如我之前在 Gaiwan 工作時，我的老闆 Arne Brasseur 在工作中發現，他總是一次又一次地重新實現登入帳號、密碼、2FA 等等的功能。他認為這些東西應該獨立成一個 Service，所以就寫了一個 Clojure 版本的 Oak。

其實這類需求已經有一個成熟的解決方案叫 Keycloak。當我的客戶在面板廠導入 Modern Data Stack 時，他們試圖整合 Superset，卻發現 Superset 不支援 LDAP Single Sign-On（SSO），於是就順勢導入了 Keycloak 來解決這個問題。

從原理出發

對軟體工程師來說，所謂對原理的研究，常常就是對自己所使用的工具的研究。因為要把工具用得好、用得巧妙，通常牽涉到是否真的瞭解其底層運作原理。

比方說，我長期使用 Neovim 搭配 Conjure 來做 Clojure 的互動式開發（Interactive Development），但一直以來對 Conjure 都沒有深入的理解。後來因為一些機緣巧合，我開始去了解 Neovim 的 Plugin 可以怎麼開發，以及 Conjure 的作者 Olical 如何引進 Fennel 語言，讓他能用一種 Lisp 語言開發出像 Conjure 這樣複雜的 Plugin。

這個研究的經驗讓我想了 2025 JCConf Talk 的新主題「解密程式碼的骨骼」

回到那個問題

我記不清那天我回答什麼了，應該是不清不楚。

那位聽眾說他「想不到合適的題目」，但我回頭看之前幾個題目的來歷，不太算是「想」出來的。題目不是憑空挑的，而是浮現出來的。無論是「從應用出發」還是「從原理出發」，共通點都是：先有了某種切身的經驗，題目才跟著出現。

所以如果要我重新回答那位聽眾，我大概會這樣說：「先仔細想想，有什麼問題讓你卡了很久、有什麼工具讓你又愛又恨、有什麼東西你一直想搞懂卻還沒搞懂。那些地方，就是題目藏身的位置。」

1. 他要的是 CI/CD pipeline。

2. 要一個會維運的工程師。

3. 只是回應上面的壓力。

「什麼！居然是這樣子嗎！？」想了一想，覺得還是把我心裡的 DevOps 寫一寫。

DevOps 為何而做？

DevOps 的核心，應該起源於一個洞察：「傳統組織的科層結構不利於軟體價值的創造。」

傳統的軟體組織長這個樣子：開發團隊（Dev）負責寫 code、測試團隊負責驗收、維運團隊（Ops）負責部署和維護線上系統。三個團隊，三個目標，三個 KPI。開發團隊的目標是快速交付新功能，維運團隊的目標是保持系統穩定——這兩個目標，天生就是衝突的。

這個衝突的具體體現，就是「交接（hand off）」。開發寫完 code，丟給測試，測試過了，再丟給維運部署。每一次交接，都是一次資訊損耗、責任模糊、速度下降的機會。出了問題，每個團隊的第一個反應是「這不是我的問題」。

Amazon 的 CTO Werner Vogels 在 2006 年講過一句話，後來變成 DevOps 的精神標語：

You build it, you run it.

意思是：寫這個服務的人，就是負責跑這個服務的人。沒有交接，沒有推卸責任的縫隙。這個理念，在組織設計上對應到的是 Stream-aligned Team——一個團隊端到端負責一個業務 domain，從開發、測試、部署、到線上維運，全部自己來。

這樣的設計，讓「我寫的 code 出問題，凌晨三點叫醒的是我自己」變成一個制度性的安排，而不是靠個人道德感維持。它帶來的副作用是：工程師自然會開始在意可觀測性（observability）、部署的安全性、系統的韌性——因為這些東西出問題，是他們自己要接電話的。

某種角度來說，這是一種經濟學的誘因設計。

DevOps 該如何做？

理念上的 DevOps 很美，但 Stream-aligned Team 要真正端到端負責，前提是應用程式本身必須是可控的——部署要可重現、依賴要透明、狀態要可預測。否則，誘因對齊了，系統卻是個黑盒子，責任還是落不了地。這邊借用 12 Factor App 來說明這件事。

12 Factor App 是 Heroku 的工程師在 2011 年整理出來的十二條原則，描述「一個適合在雲端環境跑的應用程式，應該長什麼樣子」。原文是十二條逐條列出，但我覺得這樣讀很容易見樹不見林。如果把這十二條加以收斂，背後其實有一個共同的信念：消滅隱藏的變數。

更具體來說，可以分成三類：

一、State 外部化

應用程式本身不應該保存任何狀態（state）。使用者的 session、快取、檔案，都應該存到外部的 backing service（資料庫、Redis、S3），而不是放在應用程式的記憶體或本地磁碟裡。

為什麼？因為一旦應用程式自己保存狀態，你就沒辦法隨意把它關掉、重啟、或水平擴展——每一個 instance 的狀態都不一樣，系統就變成了一個你不敢亂動的黑盒子。

二、依賴明確化

所有的外部依賴（libraries、系統工具、環境變數），都必須被明確宣告，不能依賴「系統上剛好裝了這個東西」的假設。

package.json、deps.edn、requirements.txt 這些東西存在的理由，就是讓任何人拿到這份 code，都能在一個乾淨的環境裡把依賴裝齊，跑起來。隱性依賴是 bug 的溫床，也是「在我電腦上沒問題」的根源之一。

三、可重現性

同樣的 code、同樣的 config、同樣的環境，應該永遠產生同樣的結果。

這裡包含幾件事：Build、Release、Run 三個階段要嚴格分離，不允許在 runtime 偷改 code；開發環境和線上環境要盡量一致，不能等上了 production 才發現行為不同；admin 的一次性腳本，也要在跟主程式完全相同的環境下執行，不能開個本機終端機隨便跑。

上述三個紀律說起來容易，但在實務上，違反它們的機率異常的高。State 塞在應用程式裡、依賴靠口耳相傳、dev 和 prod 環境長得不一樣——這些都是讓系統變得脆弱、難以維護的隱形成本。

組織如果想要讓這些紀律可以被貫徹，勢必得在組織的設計上下更多功夫，其中一種方式，就是要設計所謂的 Platform Team，由 Platform Team 提供指導、文件、工具、函式庫、框架、平台來給　Stream-aligned Team 使用。如此一來，Steam-aligned Team 才能專注於業務邏輯。

總結

理想中的 DevOps 是組織對「軟體價值如何流動」的根本性回答。CI/CD pipeline 可以一週建好，但讓團隊真正端到端負責、讓工程紀律成為文化——這件事，沒有捷徑。

有些主管們或許還在問「DevOps 要買哪套工具？」、「DevOps 要去上什麼課？」我認為，第一步應該是想清楚：「DevOps 的為何與如何」。

superpowers 的啟發

我翻閱到 superpowers 部分的 skill 內部實作時，發現了一種工程流程的寫法。

superpowers 的某些 skill 內含了輕量級的工作流程——明確指令 LLM 要先做步驟 1、再做步驟 2、然後處理條件判斷。

跟一般人寫的 skill 不同的點是，superpowers 裡的輕量級的工作流程，它是用 Graphviz 的 DOT language 寫成，而不是自然語言敘述。

用 DOT language 寫成的工作流程，長成如下：

digraph debugging_workflow {
    rankdir=LR;
    node [shape=box, style=rounded];
    edge [fontsize=10];
       
    "$A1" -> "$A2"
    "$A2" -> "$A3"
    "$A3" -> "$A4"
    ... 
}

純文字的格式，LLM 完全看得懂，加上是 formal language ，歧義也少了許多。同時，上述的工作流程由於是 DOT language 寫的，還可以畫成圖。而人類看圖的話，就容易理解許多。

從輕量級工作流程到 LangGraph

用 DOT language 寫 skill 內部的工作流程，本質上是一件很有意思的事。表面上看起來只是換了格式。但本質上，DOT language 是一種有向圖的宣告式語言——描述的不是「怎麼做」，而是「結構是什麼」。節點、邊、條件分支全部顯式宣告，沒有歧義空間。LLM 讀到這個，不是在「理解意圖」，而是在「執行規格」。

這個差別，讓人想到另一個東西：LangGraph。

LangGraph 是 LangChain 公司主力推的 agent workflow engine。它的核心概念，也是 node、edge、conditional routing——跟 DOT graph 的結構幾乎是一對一映射的。差別在於，LangGraph 是把這個結構放在 runtime 層強制執行，而不是靠 LLM 自律遵循。

這讓兩者之間出現了一條很自然的路徑：

用 DOT language 寫 skill，本質上是在做一件跟 LangGraph 同構的事，只是更輕量。它適合用來快速驗證一個 workflow 的業務邏輯是否合理。一旦驗證完成，需要往 production 推進——特別是當你需要 human-in-the-loop、需要中途暫停恢復、需要失敗後從 checkpoint 繼續——DOT graph 的結構，恰好可以幾乎直接翻譯成 LangGraph 的 node 和 edge，不需要重新設計。

所以，DOT language 寫的輕量級工作流程，或許不只是一個寫 skill 的技巧，而是一種思考方式：「先把結構想清楚，再決定用什麼 runtime 來跑它。」

「你的 project instructions 那麼長，」他說，「我根本不知道自己該寫什麼進去。」

他說得很有道理。我的 project instructions 確實很冗長，而且它是經過多輪對話、不斷補充才變成現在這樣。對一個才要開始的人來說，看著一份豐富的 instructions，會很難想像自己怎樣一步步建立起來。

反向工程一個生成器

於是我想到另一個做法：「與其叫他從零開始慢慢摸索，不如用 AI 來問他、來引導他。」

我根據自己現有的 project instructions，反向推導出一個「instructions generator prompt」。這個 prompt 會逐步向他提問——關於策略助理的角色定位、他的個人特質、公司背景、客戶輪廓、經營限制、長期目標。每一個區塊問 2～3 個問題，確認後再繼續。

最後，AI 根據他的回答，自動組織成一份完整的 project instructions。

為什麼這個方法會有效

乍看之下，這只是把「手工寫」改成「AI 問」。但實際上，它改變了一個關鍵的東西。

在我的經驗裡，project instructions 變得豐富，是因為我在多輪對話中，逐漸發現「啊，我還沒告訴 AI 這個」。比如，我最初沒想到要明確寫下「一人公司的約束」，是在被 AI 的建議「量測、做 A/B testing」糾正了幾次之後，才意識到需要補充。

這個過程管用，但效率不高。你要先問問題，再被糾正，再補充。

但如果用 generator 反過來做，AI 先問你，逼你在一開始就想清楚。當它問「你目前最大的瓶頸是什麼」時，你必須給出答案，即使也許不是正確的答案。

你被迫在一開始就提供關鍵信息，而不是等著被對話糾正。結果是，生成出來的 project instructions 從第一版開始，就包含了那些「要經過多輪對話才會發現」的維度。

換句話說，generator 把我花多輪對話才學到的「關注點」，一開始就問了。

工商時間 (Graph Thinking)

下個月我會在 sciwork 分享 Graph Thinking。

如果你在做推薦系統、詐欺偵測、或者只是覺得 SQL JOIN 寫得很痛，這場可能對你有用。6/13，歡迎來參加。

• 活動日期：2026/06/13(六)

• 活動地點：國立陽明交通大學工程三館

• 購票網址：https://sciwork.kktix.cc/events/seminar2026

• 詳細資訊：https://seminar.sciwork.dev/

• Workshop 資訊：https://seminar.sciwork.dev/workshops

這不是個案。這是一個結構性的誤解。

企業流程的隱含假設

和客戶簽約時，採購常告訴我，敝公司付款是三十日月結。這個三十日怎麼來的？

企業裡一個付款的流程就是要經過重重審批，每過一關，就會有一輪的 Email 往返，一次的等待。審批的時間、實質作業的時間全部加起來也許不到一小時，但是，一關又一關的審批堆疊起來，就會是十倍、百倍的時間。

上述的現象普遍出現在各種企業，也因此，大家都知道中小企業的反應速度往往較快。也有軟體業 CEO 曾經直白地說：「工作流程每多一層審批，就慢十倍。」

大多數企業在導入 AI 的時候，問的問題是：「怎麼讓員工應用 AI 變快？」

這個問題沒有問錯，然而，如果既有的流程裡，實質作業時間的佔比就只有 1/10，那 AI 再怎麼加速，也只能快 10%。

真正的問題應該是：你的公司，流程在哪裡等待？

什麼是「流程斷點」？

在我做企業顧問的過程中，觀察到一個共同特徵：大多數企業的工作流程裡，都藏著幾個「流程斷點」——某個環節卡住，整條流程就停下來等。它們長這樣：

• 一個流程做到一半，必須等某個特定的人才能繼續推進

• 月報要三天，不是因為分析慢，而是因為資料要從五個 Excel 手動彙整

這些斷點，不是工具問題，是流程設計問題。把 AI 插進來，只是讓本來就在等待的人可以更有效地等待。

兩種導入方式，結果差十倍

我把企業導入 AI 的方式分成兩類。這裡的「10%」和「10x」是概念上的量級差距，不是精確數字，而是描述兩種截然不同的結果：

改進 10%：用 AI 讓現有流程跑更快。員工回信更快、文件整理更快、Debug 更快。這是真實的改善，但改善幅度有限，因為流程的瓶頸沒有動。

改進 10x：重新設計流程。重點不在於讓人跑得更快，而是把那個必須「等人」的環節，轉變成一個任何人都可以自助的服務。

差別在哪裡？讓我用兩個案例說明。

案例一：廣告公司的自助診斷工具

許多廣告科技公司的流程是這樣的：客戶的追蹤碼（Pixel）埋錯了，廣告成效就看不到。客戶發現問題，提交 ticket 給廣告科技公司，Ad Tech Support 工程師接手 debug，解決後回覆客戶。

2020 年，我在 LINE Taiwan 的業務部擔任 Ad Tech Support，就是做上述的事。那一年，LINE 的業務成長非常快，Ad Tech Support 根本忙不過來，所以我被臨時派去支援。然而，就算我個人的 Debug 速度比同事快 20 倍，整個團隊的產出並沒有顯著上升，因為客戶等待的時間仍然是以天計。

真正的十倍產出，發生在 Ad Tech Support 團隊開發出一個類似 Pixel Helper 的工具（LINE Tag Helper），讓客戶自己就能診斷問題之後。從此，Ad Tech Support 的工作從「處理 ticket」變成「維護這個工具」。

結果不只是速度差異，整個流程的性質都改變了：從「人工服務」變成「平台服務」。原本每天要人工處理的 ticket 量消失了，工程師的價值從人力支援轉移成建造支援的系統。

這就是 X-as-a-Service 的邏輯：把一個需要「等人」的流程斷點，轉化成一個隨時可用的服務。關鍵在於，將原本只有特定人才持有的專業知識，編碼進入一個可以 24 小時在線的工具。

案例二：製造業的資料平台

在台灣，許多製造業在生成報表時，常見的作法是讓 IT 團隊用 BI 軟體，為財務、行銷、生管等部門各自製作報表。

以 PowerBI 為例，它使用的領域專用語言 DAX，過去門檻很高，許多人寫不好。有了 AI 之後，DAX 的撰寫難度大幅下降。但問題來了：就算個別工程師寫 DAX 的速度變快，等待報表的現象依舊存在。原因是，流程斷點不在於「寫得慢」，而在於「所有需求都要排隊等 IT 處理」。只要這個結構沒變，加速個人的工具只是讓人更有效率地排隊。

真正的十倍作法是什麼？導入現代資料棧（Modern Data Stack），讓企業的資料倉儲從「IT 部門管理的軟體」，轉變成「全公司都能自助查詢的資料平台」。資料團隊的角色從執行者變成維護者，斷點從此消失。

2025 年，我在台灣一家面板廠協助導入現代資料棧之後，初步成果讓一份既有報表的產出時間從 27 分鐘縮短為 10 秒。但這還只是技術層面的改善。更根本的變化在於：各部門可以直接存取資料平台（對於一些相對單純的表格），不再需要等待 IT 排程。

隨著資料平台持續完善，下一步甚至可以讓 AI agent 直接存取平台、自動生成複雜報表——這個階段，業界稱之為 Agent-Ready Data：資料已經整備到足以讓 AI 自主運用，不需要人工中介。這不是遙遠的未來，而是資料平台建置到位後，自然可以接軌的下一步。

不要問「我們公司該怎麼用 AI？」

這個問題本身就把方向搞錯了。它預設了「先找工具，再找用途」的順序。

正確的順序是反過來：先找斷點，再找工具。

你可以從這個問題開始：公司裡有哪個流程，每次推進到一半就會停——而「停」是因為要等某個特定的人才能繼續？

找到那個地方，具體問：這個等待可以被一個工具或平台取代嗎？這裡的知識，能不能被編碼成一個服務？

如果答案是肯定的，那才是值得把 AI 真正用上去的位置。

Context Window 的重要性

在談「哪個 tech stack 更加 agent-ready」之前，先要建立一個基礎認知：context 的大小，直接決定了 AI agent 能做做得多好。

這不只是直覺，是有實驗數據支撐的。LongCodeBench 的研究發現，Claude 3.5 Sonnet 在 bug fixing 任務上，context 從 32K 增加到 256K 時，準確率從 29% 崩跌至 3%——不是邊際衰減，是崩潰式衰減。Chroma 測試了 18 個前沿模型，每一個都有這個現象，沒有例外。

更糟的是，coding agent 的工作模式會主動加速這個衰減。每一次 tool call、每一次 file read、每一次 error message，都會留在 context 裡。一個跑 30 步的 agent session，context 消耗可能是單次對話的十倍以上。

所以問題來了：context window 的消耗速度，很大程度上取決於你選的 stack。

AI 在推薦 tech stack 時，傾向於推薦訓練資料最多的選項——TypeScript + React + Supabase 就是這樣被推到主流的。這個邏輯是「訓練資料多 → 生成成功率高 → 看起來是好建議」。但這個邏輯有一個隱藏假設：「生成容易」等同於「長期 AI 輔助開發效率高」。

這個假設是錯的。

Context Efficiency 是框架選擇的關鍵維度

AI 要完成一個任務，不需要讀整個 codebase，只需要讀「任務相關的那幾個檔案」——我們可以稱之為局部子圖（task-relevant subgraph）。這個子圖的大小，直接決定了 context 的消耗量。

關鍵在於：局部子圖的大小，是由框架的架構設計決定的，而不是由模型決定的。

TypeScript + React + Supabase 的問題在於，一個功能天生就會橫跨多個層次——component、hook、state、api client、type definition——每一個都在不同的檔案裡。局部子圖一開始就很大，而且隨著專案規模增長，共用的依賴 (shared dependencies) 越來越多，子圖只會越來越大。

這就是為什麼「訓練資料最多的 stack」不等於「最 agent-ready 的 stack」。

哪些架構設計，對 Agent 更友善

我個人常用的 tech stack ，是 Clojure Stack Lite ，而它至少有三個設計選擇，可以縮小局部子圖，減少 context 的消耗：HTMX、HoneySQL、Blocking IO 。

HTMX：用 curl 驗證前端，不需要模擬 client state

React 應用程式的前端邏輯活在 client 端：useState、useEffect、zustand、react-query——這些 state 分散在多個檔案，互相依賴。Agent 要驗證一個功能是否正確，必須把這些全部帶入 context，還要模擬 browser 的行為。

HTMX 的模型完全不同。所有的互動行為由 server response 驅動，前端幾乎沒有狀態。這帶來一個非常實際的好處：agent 可以直接用 curl 驗證功能。

# 驗證一個登入功能是否正常
curl -X POST http://localhost:3000/login \
  -d "email=test@example.com&password=secret"

response 就是 HTML fragment，對就是對，錯就是錯，不需要啟動 browser、不需要模擬 React render、不需要追蹤 client state。

對 agent 來說，這意味著驗證行為本身就相對節省 context——curl 的 response 比 browser DevTools 的 output 小一個數量級。

HoneySQL：讓 debug 的子圖縮小三到五倍

ORM 是一個關於 context 的陷阱。

當 ORM 出現 N+1 問題時（這幾乎是每個用 ORM 的專案都會遇到的問題），debug 過程需要把 model definition、association 設定、migration file 全部帶進 context，因為問題的根源藏在 ORM 的隱式行為裡——lazy loading 在你不注意的地方悄悄發生。

HoneySQL 用 SQL-as-data 的方式表達查詢：

(sql/format {:select [:u.id :u.name :p.title]
             :from   [[:users :u]]
             :join   [[:posts :p][] [:= :u.id :p.user-id]]
             :where  [:= :u.active true]})

沒有 lazy loading，沒有 association magic。要拿關聯資料，你必須明確寫 JOIN——N+1 不會「不小心」發生，因為你無法在不知情的狀況下讓它發生。

當真的出現 query 問題，debug 的子圖只有一個地方：那個 query function。不需要追蹤 ORM 的 model 定義，不需要看 association 設定。子圖從五個檔案變成一個檔案。

Blocking IO：讓 Error 對 Agent 可見

Async 模型有一個結構性特徵，不是寫法問題，而是設計本質：error path 是隱式的。

在同步程式碼裡，exception 只有一條路——往上傳，直到被 catch。但在 async 模型裡，每一個 async 呼叫點都是潛在的 error 斷點。開發者必須在每個地方明確處理，否則 exception 會被封裝進 rejected Promise，與主流程脫鉤。

在 Node.js 裡，這個問題的典型場景：

async function saveUser(data) {
  await db.insert(data);        // throws here
}

async function handleRequest(req) {
  saveUser(req.body);           // missing await — Promise is detached
  res.json({ ok: true });       // executes normally
}

這段程式碼在現代 Node.js（v15+）不會靜默消失——runtime 會拋出 UnhandledPromiseRejection，甚至讓 process crash。但問題不在於 error 看不見，而在於error 與呼叫點脫鉤：crash 的 stack trace 指向 saveUser 內部，而不是 handleRequest 裡那行忘記 await 的地方。

對 AI coding agent 來說，這是 context 負擔的來源。要定位根因，agent 必須：

• 追蹤每一個 async 呼叫點，確認是否有 await

• 將整條呼叫鏈上的檔案納入 context

• 在沒有明確 error boundary 的情況下，推斷 error 從哪裡脫鉤

這個追蹤過程需要的 context 寬度，隨呼叫鏈的長度線性增長。

Clojure 的 blocking IO 結構不同。exception 只有一條 path：往上傳，在 middleware 統一處理。沒有 async boundary，就沒有脫鉤的可能。Agent debug 時只需要兩個地方：middleware 的 log，以及 log 指向的呼叫點。Context 的範圍是固定的，不隨系統規模擴大。

這是兩種模型在可除錯性上的結構差異，不是 Node.js 與 Clojure 的語言優劣比較。

為什麼『顯式』對 Agent 這麼重要

上述三個特色其實有共同的特色：隱式行為越少，agent 需要帶入 context 的範圍就越小。 HTMX 消除了隱式 client state，HoneySQL 消除了隱式 lazy loading，Blocking IO 消除了隱式執行順序與隱式 error path。

這邊的重點不是在 Clojure 比 TypeScript 好，重點是在於框架設計哲學的觀察：顯式優於隱式，對人類開發者是美德，對 AI agent 是確保它們不會提早變笨。

開始使用 Clojure Stack Lite

如果你對這個方向有興趣，最快的方式就是直接試試看。Clojure Stack Lite 可以讓你用一個指令生成一個 agent-ready 的 empty 專案，然後把剩下的事情交給 agent。

以下是我的 vibe coding 作法。

環境設置

環境設置有四個步驟：

• Step 1: 將 Claude Code 的 model 設置為 Haiku 4.5 。由於如果使用了 superpower 的話，對 token 的消耗很激烈，所以我做這個調整，而 greenfield project 通常也不需要太複雜的推理。

claude 
> /model

• Step 2: 在 Claude Code 安裝 superpower 。要裝這個的原因是：如果用了 superpower 的話，當 Claude Code 做 TDD 時，會主動做 Integration Test。

claude 
> /plugin install superpowers@claude-plugins-official

• Step 3: 安裝 mise ，之後幾乎所有的套件都可以透過 mise 來安裝與管理。

brew install mise

• Step 4: 安裝 neil ，因為我要用來生成 empty project 的 Clojure Stack Lite 要用 neil

brew install babashka/brew/neil

每個專案啟動時，則需要有以下的步驟：

• Step 1: 用 Clojure Stack Lite 生成專案 myproject

neil new io.github.abogoyavlensky/clojure-stack-lite myproject :auth true

• Step 2: 基本設置與安裝軟體

cd myproject 
mise trust && mise install

• Step 3: 做個版本控管

git init
git add .
git commit -am 'Initial commit'

然後就可以叫 agent 開始工作了。

進階設置

上面是快速起步的設置，而實務上我還會在 agent 正式開始工作之前，再多加設置 brepl 與 nrepl ，這主要是為了讓 Agent 可以透過 nrepl 來做快速地探索 (節省 tokens)。

• 安裝 brepl

curl -fsSL https://raw.githubusercontent.com/licht1stein/brepl/master/brepl -o ~/.local/bin/brepl
chmod +x ~/.local/bin/brepl

• 在專案資料夾 (myproject) 裡，設置好 brepl

brepl hooks install

• 在專案資料夾 (myproject) 裡的 deps.edn 裡，加入 nrepl 的依賴

neil add nrepl

• 手動修改 bb.edn ，增加一個 alias clj-nrepl

 16    clj-repl {:doc "Run built-in Clojure REPL"
 17              :task (shell "clj -A:dev:test")}                                            
 18                                      
 19 +  clj-nrepl {:doc "Run Clojure REPL with nREPL server"                                  
 20 +             :task (shell "clj -A:dev:test:nrepl")}                                     
 21 +                                                                                        
 22    fmt-check {:doc "Check code formatting"
 23               :task (shell "cljfmt" "check")}

• 手動修改 README.md 裡，將 bb clj-repl 改為 bb clj-nrepl

來聊聊

如果你對 Clojure Stack Lite 有興趣，或是對 agent-ready-stack 的方向有想法，歡迎加入 Clojure Taiwan Telegram 群一起討論。也可以直接寫信給我：laurence@replware.dev

Cursor 的使用者數量在幾個月內翻了好幾倍。GitHub Copilot 的 Workspace 功能開始有工程師認真地在日常開發中使用。社群媒體上，工程師們開始分享讓 AI 獨立完成整個功能實作的經驗，而不只是補全某一行程式碼。

一位工程師朋友，在 2025 年底告訴我：「有一個任務，我本來預估要做兩天，結果讓 agent 跑了一個晚上，早上起來，幾乎都做完了，而且品質還不錯。」

從 2025 年第四季開始，coding agent 從「有點有用的工具」，突然變成了「讓整個開發流程重新設計」的力量。

這揭示了什麼？

coding agent 為什麼會在這個時間點大量被採用？而且一路向上。

表面上的解釋是：「模型變強了。」這個解釋有一定道理，畢竟從 GPT-4 到 Claude 3.5 Sonnet、再到 Claude 3.7 Sonnet 這一代模型，能力的提升是實質且巨大的。

更關鍵的問題是：為什麼同一批模型，在幫助工程師寫程式的時候如此強大，但是在協助企業處理客服流程、採購審批、行銷規劃的時候，卻相對受限許多？

模型沒有不同。一樣的 Claude，一樣的 GPT。差別不在模型，差別在領域。那些還沒有被 agent 處理得好的領域 (Domain)，並不是在等待更好的模型。它們是在等待自己準備好。

這就是代理就緒（agent-ready）的概念。

代理就緒的兩個條件

一個領域要成為 agent-ready，至少需要兩個核心條件：

一、Agent 要可以取得 Feedback

Coding agent 之所以有效，一個非常重要的原因是：它可以立刻知道自己做得對不對。

Agent 寫了一段程式碼，就呼叫 compiler 看看有沒有 syntax error；寫完之後，跑 test suite 看看有沒有 regression；如果改了 API，就起一個 server、打一個 request，看看回傳是否正確。

整個過程裡，feedback 非常明確，而且是即時的。這個特性讓 agent 可以進入一個非常短的「行動 → 觀察 → 修正」循環。

而現在多數公司的 CRM 系統裡的銷售流程，可以讓 agent 做一個操作、然後立刻知道結果正確不正確嗎？你的採購審批流程，有沒有任何 CLI 可以呼叫，讓 agent 確認一個動作是否成功？

大多數企業的答案是：沒有。

二、Agent 要可以取得 Context

這是第二個條件，也是更難滿足的那一個。

Coding agent 為什麼能理解一段陌生的程式碼？因為程式碼本身就是 formal language。函數名稱有語意，資料結構有定義，呼叫關係是顯式的。當 agent 讀了程式碼，就可以相當程度地理解它的 what（這段程式碼做什麼）、how（用什麼方式做）、甚至 why（為什麼這樣設計）。

這不是偶然。程式語言本來就是為了讓機器（和人）都能理解而設計的。它天然就是結構化的、語意清晰的。

但企業裡大多數的業務知識，並不是這樣的。

採購流程的規則散落在各種 Word 文件、電子郵件和員工的腦袋裡。「客戶 A 跟我們有特殊約定，超過一定金額的訂單，要提前三天通知」——這種知識，通常根本沒有被結構化儲存。

這就是 agent-ready 的本質挑戰：很多企業的知識，現在的存在的形式只適合讓人理解，不適合讓 agent 理解。

代理就緒的資料倉儲

寫程式也許離一般人較遠，再從一個相對有機會「代理就緒」的例子來說明：資料倉儲。

Text-to-SQL 是一個很美好的想法：「讓使用者用自然語言問問題，AI 自動轉成 SQL 查詢，從資料庫裡取得答案。」以今日的模型來講，寫 SQL 不是難事，但 Text-to-SQL 要在企業成功地落地，卻仍然困難重重。

問題不是在於模型不夠聰明，而是在於 context 不夠。

你問 AI：「上個季度，我們的客戶流失率是多少？」

AI 必須知道很多事情，才能把這句話轉成正確的 SQL：

• 「客戶」在這家公司的資料庫裡，對應的是哪一張資料表？是 users、accounts、還是 customers？

• 「流失」的定義是什麼？是超過 90 天沒有登入？是主動取消訂閱？還是連續三個月消費金額為零？

• 「上個季度」的計算邏輯是什麼？是自然季？還是公司自定義的財會季度？

• 如果「客戶流失率」是一個跨多張資料表的計算，join 的條件是什麼、分母是什麼、分子是什麼？

這些知識，不在 SQL schema 裡。SQL schema 只告訴你資料表有哪些欄位，不告訴你這些欄位的業務語意。

這正是為什麼，想要讓 Text-to-SQL 可靠地運作，往往需要先導入現代資料棧 (Modern Data Stack)。一旦有了類似 dbt 這樣的工具，讓分析工程師在撰寫 data model 的時候，同時建立詳盡的 metadata。

一個設計好的 dbt model，它的欄位說明可能長這樣：

- name: churned_at
  description: >
    客戶流失的時間戳記。定義為訂閱狀態轉為 ‘cancelled’ 且超過 30 天未重新訂閱的時間點。
    若客戶尚未流失，此欄位為 NULL。
    計算邏輯參考 finance team 2024-Q2 的定義文件。

這段描述，就是在把業務語意，結構化地附著在資料上。有了這樣的 metadata，AI 才有足夠的 context 來生成正確的 SQL。

然而，這邊有一個挑戰：「 dbt Model 的 metadata 要如何生成呢？」

這邊引用〈分析工程師〉一文裡有談到的：分析工程師的核心價值，在於他同時懂業務和技術——能夠把業務部門的語意需求，轉化成資料模型的定義。這個能力，在 agent-ready 的資料倉儲裡，變得比以往更加重要。沒有這樣的人在中間搭橋，AI 就算再聰明，也不知道「流失」在這家公司的意思是什麼。

資料倉儲要變成 agent-ready，需要的不只是 Text to SQL 的系統，更需要的是，有人一步一步把業務語意釐清，仔細地寫進 metadata。這很可能是分析工程師的工作，因為是一項需要同時懂技術和業務的人才能做好的工作。

如果你正在評估從資料倉儲開始切入代理就緒 (Agent-Ready-Data)，並考慮導入資料平台，《從試算表到資料平台》裡有系統性地討論 Modern Data Stack 的導入與應用，包括技術選型、資料分析與組織推動。

代理就緒的企業

如果把 Agent-Ready-X 框架從資料倉儲延伸到整間企業，問題會變得更複雜，還是更清晰呢？

客戶關係管理（CRM）

Salesforce 是全球最大的 CRM 平台，理論上具備成為 agent-ready 系統的條件。

然而現實的挑戰在於：當一位業務員在 Salesforce 裡更新了一個 opportunity 的階段，這個動作可能觸發通知、更新報表，或者什麼都不做——取決於這家公司如何設定自動化規則。這些規則分散在 Flow、Validation Rule、Apex Trigger 等不同機制裡，透過 UI 建立，雖然技術上可以透過 Metadata API 或 Salesforce CLI 匯出，但格式並非為 agent 設計，需要額外解讀才能轉化成可用的 context。

更根本的問題是高度客製化。每一家公司的 Salesforce 設定幾乎都不同，同一個欄位在不同公司可能代表完全不同的業務語意。這使得通用的 agent 很難在沒有人工轉化的情況下，理解特定公司的業務規則。

業務流程管理（BPM）

BPM 系統（如 SAP、Oracle EBS、各種 ERP）面臨類似但更複雜的挑戰。

一個典型的採購流程，可能長這樣：提出申請 → 部門主管核准 → 財務確認預算 → 採購部門詢價 → 提出採購單 → 副總核准 → 執行採購。

每一個步驟背後，都有對應的規則：誰可以核准、核准條件是什麼、核准者不在時誰可以代理。這些規則在傳統 ERP 系統裡，通常透過圖形化介面設定，且散落在多個不同的設定頁面裡。

要讓 agent 理解這個流程，一樣需要二樣東西：

• 一個可以描述業務語意的 metadata 層

• 一個可以執行每個步驟並取得結果的介面 (API 或 CLI)

SAP、Oracle EBS 等系統確實提供 API（如 SAP 的 BAPI、OData，Oracle 的 REST API），但這些介面的設計目標是系統整合，而非讓 agent 查詢「流程規則本身」。核准條件、代理邏輯等業務規則，覆蓋範圍不完整，或以不適合 agent 直接使用的格式儲存在系統內部。

圖形化介面是一道牆

正如〈AI, CLI 程式, 與 DSL〉一文裡談到的，CLI 和 DSL 對 AI 的重要性，是常常被低估的。一個只有圖形介面、沒有 CLI 的系統，agent 必須靠截圖、靠視覺理解、靠模擬滑鼠點擊，才能操作它。這個方法不只低效，而且非常脆弱。

過去三十年，企業軟體的設計哲學是：讓它盡可能地「好用」，意思是做成漂亮的圖形介面，讓不懂程式的業務人員可以輕鬆操作。

這個方向，其實在不知不覺間，把 agent 擋在了門外。

一個只有 UI 設定、沒有 DSL 的流程定義，agent 沒有辦法「閱讀」這個流程的規則，更沒有辦法「推理」在不同情境下應該怎麼處理。圖形化設計，這個本來為了讓人更容易使用而設計的思路，反而成了 agent 進入的門檻。

代理就緒的 BPM 或 CRM，應該是這樣的：

• 每一個業務流程，都有一個結構化的定義 (DSL)，可以用程式讀取

• 每一個操作，都有一個 API 端點或 CLI 可以呼叫，並且回傳清楚的成功或失敗訊號

• 每一個業務物件（客戶、訂單、採購單），都有清楚的 metadata，說明這個物件在這家公司裡代表什麼語意

這些條件，在大多數現有的企業系統裡，是不存在的。或者說，它們只存在於部分系統的 API 文件裡，但沒有被有意識地管理成 agent 可以取用的 context。

知識圖譜的困境與出路

如果說，讓整間企業變成 agent-ready，需要的是「一份完整描述企業所有知識的 context 庫」，那麼，這個概念其實並不新。

這正是知識圖譜（Knowledge Graph）一直在嘗試解決的問題。

知識圖譜的想法是：把企業裡所有的概念、物件、關係，用圖形的形式表示出來。「客戶」是一個節點，「訂單」是另一個節點，它們之間有一條「下訂」的邊。「產品」是節點，「分類」是節點，它們之間有「屬於」的邊。把這張圖建好了，理論上，任何問題都可以被回答。

但理論上和現實中，往往差距很大。

大型的企業知識圖譜，是出了名的難以建立、更難以維護。難在哪裡？

第一，企業知識不是靜態的。 客戶的定義會改變，業務流程會調整，組織結構會重組。一個需要人工維護的大型 KG，往往在建好的那一刻就已經開始過時了。

第二，跨部門的語意衝突很難解決。 「客戶」這個詞，在業務部、財務部、產品部，可能有完全不同的定義。在 CRM 裡，客戶可能是「曾經接觸過的潛在買家」；在財務系統裡，客戶可能是「曾經產生發票的付款方」；在產品資料庫裡，客戶可能是「有開通帳號的使用者」。要把這三個定義統一到一個知識圖譜裡，需要大量的溝通、談判和妥協。

第三，ROI 不明確。 知識圖譜的建立成本極高，但它創造的價值，很難被量化。這讓很多企業在投入初期預算之後，往往在專案中途放棄。

試圖在單一企業裡建立一個涵蓋所有知識的大型 KG，失敗的案例遠多於成功的案例。

聯邦式 Domain-Specific Context Layer

我認為，答案不是建立一個「超級知識圖譜」，而是建立一個多個 Domain-Specific Context Layer 的聯邦。

這個想法是：不要試圖用一個統一的圖譜描述所有知識，而是讓每一個 domain 負責自己的 context：

• 資料倉儲有資料字典，描述業務指標的語意

• CRM 系統有流程定義，描述銷售流程的規則

• ERP/BPM 有業務物件 schema，描述財務和採購的邏輯

這些 context layer 各自維護自己的領域，不需要強制統一語意。Agent 在需要時，透過 MCP（Model Context Protocol）或類似的協議，向各個 context layer 取用它需要的 context。

這個方式的優點是：每個 domain 的複雜度是可管理的，維護的責任是分散的，局部的更新不會影響整個系統。

但這個方式也有一個嚴重的限制：跨 domain 的推理。

想像一個問題：「這個客戶的採購訂單，是否符合我們的信用條件？」

這個問題，需要同時取用 CRM（這個客戶的歷史記錄）、財務系統（客戶的信用額度和付款記錄）、採購系統（這筆訂單的金額和條款）的 context，然後套用某個規則，做出判斷。

如果每個 domain 的 context layer 是獨立的，agent 要回答這個問題，必須分別從三個不同的 context layer 取得資訊，再把這些資訊整合在一起，套用跨 domain 的推理規則，得出結論。

這個推理步驟，是問題所在。 agent 可以嘗試自己推理，但當推理規則複雜、涉及多個 domain 的語意時，agent 很容易撞到能力的上限，產生錯誤的結論。

這裡就出現了一個不常被討論的技術需求：某種推理引擎，用來處理跨 domain 的推理。 Datalog 就是一種特別適合用來做推理的形式語言，若有先把「推導規則」顯式地定義出來，那 Datalog 查詢引擎就可以自動應用。

給定「客戶 A 的信用評級是 B+」、「信用評級 B+ 以上的客戶採購上限是一百萬」、「這筆訂單金額是八十萬」，Datalog 引擎可以自動推導出「這筆訂單符合信用條件」。

如果沒有這樣的推理引擎，靠 agent 做跨 domain 推理，agent 每次都要「自己想」，而且想的結果可能不穩定、不可解釋。有了推理引擎，複雜的跨 domain 規則可以被顯式地定義，推理的過程是可驗證、可稽核的。

這個方向，是接下來幾年，企業 AI 架構裡最值得關注的空白地帶之一。

壓力是真實的，挑戰也是真實的

回到最開始的問題：為什麼 coding agent 突然大量爆發？

因為軟體開發這個領域，剛好同時滿足了 agent-ready 的兩個條件：

1. Feedback 明確：有 compiler、有 test、有執行結果

2. Context 清晰：程式碼是 formal language，語意邊界清楚

模型到位了，環境也到位了，所以爆發了。

現在，模型繼續在到位。Claude Opus 4、Claude Sonnet 4.5、未來的模型，會持續地越來越強。但企業的其他領域，環境還沒有到位。

這是一個壓力很大、但挑戰也很真實的處境。

壓力很大，因為競爭對手可能比你更早把環境建好，讓 agent 在他那裡可以做你的工程師做的事。競爭對手一旦先就緒，它的執行速度就有機會大幅提高，而迭代加速常常就是一種競爭力。

挑戰很真實，因為建立 agent-ready 的環境，不是買一個軟體、裝一個插件就能完成的事情。它需要：

• 為系統建立可程式化的介面：API、CLI、DSL，讓 agent 可以操作和閱讀系統狀態，得到 feedback。

• 把業務語意結構化：哪些概念是重要的？它們的定義是什麼？這需要對業務有深度理解的人來做。

這兩件事裡，特別是後者，它絕對是「人的工作」。沒有辦法靠 AI 自動完成，因為它需要對這家企業的業務有深入的理解。

那麼，需要什麼樣的人？

這個人需要同時懂業務、懂技術、懂 AI 的能力邊界——甚至還要跨部門推動改變。

問題在於，這樣的人，多數的企業通常沒有。根本的原因是，多數企業的文化，也不會自然培養出這樣的人：業務端和技術端長期各自為政，AI 的理解又是另一個專業。這三者的交集，在組織內部幾乎不會自然形成。

這也是為什麼，想要快速跟上 agent 浪潮的企業，往往需要從外部引入專業人士的協助。

這個方法說起來不複雜，但需要一點耐心去建立。

豐富的 Context，持續優化的 Custom Instruction

首先，我發覺如果要透過 AI 探討公司經營策略，給的 Context 必須異常豐富，它才能給予相對好的建議。

我的做法分四步：

第一步：開獨立的 Project。 針對比較困難的議題——公司經營、小孩教養——各自開一個獨立的 AI Project，讓不同議題的對話不會互相干擾。

第二步：先憑感覺寫一個 Custom Instruction。 一開始不需要完整，只要描述大概的狀況——公司在做什麼、現在面對什麼問題、相關的人是誰。這是第一版的「背景說明書」。

第三步：每次對話結束時，問 AI 這個問題： 「在這個對話中，有沒有發現什麼新的 insight，值得加入 Custom Instruction？」接下來，我就會從中挑選跟我認為正確的 insight，然後，手動加入該 Project 的 Custom Instruction。

第四步：重複。 通常經過五到十輪對話之後，Custom Instruction 的內容會變得非常豐富。在這之後， AI 提出的建議、觀點會開始出現『品質』的大幅提昇。比方說，有更深層次的洞察、或是建議變得相對可行許多。

為什麼這個方法會管用？

我在讀 Tailscale CEO Avery Pennarun 的一篇文章——What do executives do, anyway?——突然覺得這兩件事在說同一個道理。

Avery 引用 Andy Grove 的《High Output Management》，提出一個關鍵論點：大公司的主管，永遠是房間裡資訊最少的人。 他每年頂多花 15 分鐘在每個下屬身上，根本不可能比第一線的人更了解細節。所以他的結論是：主管的工作不是做決策，而是「定義並強化文化與價值觀，以及核可好的決策」。

真正的決策，應該由掌握最多資訊的人來做。主管的角色，是設計一個讓這件事能發生的機制。

某種程度，這與要讓 AI 來做決策，相當地相似：『都需要設計機制。』

一個剛開啟的 AI 對話，就像一個什麼都不知道的新顧問。你問它公司策略，它只能給你教科書的答案，因為它對你的處境一無所知，它會有大量的隱含假設。然而， AI 的建議品質，高度依賴於它掌握的 context 深度。

所以，把 context 餵給 AI 這件事，其實就是在解決和大公司主管一樣的問題：讓決策者獲得足夠的資訊，才能給出真正有用的判斷。

更有趣的是，Avery 說，主管的價值觀必須在每次決策中反覆強化，才能真正滲透到組織裡。我的做法正好對應這一點——每輪對話結束後更新 Custom Instruction，就是在反覆校準這個 AI 的「世界觀」，讓它愈來愈像一個真正了解你處境的顧問，而不只是一個泛用的問答機器。

為什麼歸納 insight 這件事，自己還是必須參與？

有個問題很自然會浮現：既然每輪都要問 AI「有什麼 insight 值得加入 Custom Instruction」，為什麼不乾脆讓 AI 自動更新就好？

我認為不行，原因主要有二。

第一，AI 不知道什麼對你重要。 Custom Instruction 不是中立的資訊彙整，它反映的是你的判斷——哪些觀察值得被記住，哪些只是一時的討論。AI 沒有辦法做這個取捨，因為它不知道你的優先順序。

第二，錯誤的 context 比沒有 context 更危險。 如果讓 AI 自動累積 instruction，它可能會把一個當下的誤判當成長期的定論，寫進背景設定裡，影響之後所有的對話。人工審核，是這個流程裡最重要的品管環節。

總結

這個利用 AI 來輔助決策方法的核心，其實很古老：給決策者足夠的資訊，讓他能做出好的判斷。 只是現在，這個「決策者」換成了 AI，而你變成了那個設計機制、核可方向的人。

答案可能讓讀者們失望了，沒有什麼 technology 。

1. 穩定發 newsletter 的要訣：「寫作與發文拆成兩件事來做。」我通常是選一個時間來寫作、然後用 substack 平台的 scheduling 功能，設定時間來發文。這個作法它可以確保寫作的品質與樂趣。沒心情時，可以隨便亂寫一些東西，30 分鐘交件。遇到有意思的題目、想要透過寫作來想清楚的題目，我也可以寫三、四個鐘頭。

2. 主要的工具：Markdown 格式， Typeless 語音輸入， 叫 LLM 給予寫作的反饋

3. 除了寫作與公開發表作品，沒有任何其它的個人知識管理 (personal knowledge management)

長篇寫作作為一種有效的 PKM

曾經看過別人寫，寫作是要把自己腦子裡的知識，化為線性來輸出。我不太同意，至少對我來講，我通常是樹狀地在寫作。使用 Markdown 格式可以讓這點變得很明顯。每一個不同層級的 heading (#, ##, ###) 都是一個超大的子樹 (sub tree)，而子樹又可以包含其它的子樹，直到最後化為一篇又一篇的小文章、小段落為止。

每一篇文章就是一顆子樹，它可能只有 1, 2 個主要概念，那就是一兩個結點，搭配頭尾去組合。而長篇寫作時 (比方說，寫個 3 萬字以上) ，則要事前先構思大綱，把要寫的子樹，分章節安排好。

而很有趣的事情是，無論我在事前怎麼安排大綱，儘量將大綱寫得很豐富，我通常真的在寫的時候，往往還是無法照綱寫作。真實在寫的時候，因為反覆修改的關系，又會想出新的詮譯方式、新的演繹方式，最後往往也是一邊寫出成品，然後回頭再去修改大綱。

我在寫《從試算表到資料平台》一書時，由於書的第二部分是談資料分析，這是一個對我來說，相對難寫的主題，因為我過去從事的工作裡，資料分析的部分實在不多。然而，考慮到我最初寫作設定的目標，希望寫一本可以談好資料工程與資料分析的書，還是覺得書應該要包含這個部分。總之，真實的寫作過程是：「我先把第二部分寫了兩萬字，後來又覺得是垃圾，整個扔掉重寫。」

而後，又再多查資料、又再重新來過寫完的資料分析，總算是一個不會讓我覺得丟人的作品。

為何刻意的 PKM 沒有效？

那為什麼沒有做什麼個人知識管理呢？

做過，但後來覺得沒有特別有效，就懶得做了。曾經試過把讀過的東西整理成筆記、連結成知識網路。但是，一來我通常並沒有什麼時間回去看，二來，整理之後，腦子也沒有變得特別清楚。

問題出在哪？我後來的理解是：整理本身不是思考。

把資訊歸類、打標籤、建連結，這些動作給人一種知識在增長的錯覺。但其實只是在搬運，不是在消化。知識要真正變成自己的，需要一個過程：你要被逼著把模糊的理解說清楚，把自以為懂的地方逼出破綻，然後重新建構。

這個過程很痛苦，而刻意的 PKM 系統幾乎從來不會給你這種壓力。寫作會。尤其是公開發表的寫作。知道有人會讀，你就不能含糊帶過。一個講不清楚的概念，在腦子裡可以一直含糊下去；一旦要寫成文字，漏洞立刻就現形了。

即使日後很少回去再重讀自己的作品，那些重新反覆理解、重新生成的經驗，也會帶來實質的知識轉化。

結論

什麼樣的知識管理是有效的？

我的答案是：「能逼你思考的通常就會有效。」

我之前出書的時，因為跟他在同一個 Coworking Space 工作，我有分享資訊給他。上週他傳了一個訊息給我，是一個截圖，裡頭寫了「湖倉架構」（Data Lakehouse）、「獎牌架構」（Medallion Architecture）等關鍵字。他問我說，像這些概念，不知道有沒有什麼書可以參考看看。

我回答他說，這是跟 Modern Data Stack 有關的書。這類的書不多，據我所知，繁體中文的第一本就是我的著作。他聽了就回答我說：「喔！原來叫做 Modern Data Stack 啊？那我再去天瓏書局找找。」

總之，後來，我們約了一個時間聊一下他的問題。

他用爬蟲從網路取得了一些業務需要的原始資料，儲存在電腦的一個 DuckDB 資料庫裡。網路上抓下來的原始資料需要先清洗、整理、標註之後，才能使用。在沒有導入 Modern Data Stack 的前提之下，他並沒有一個程式碼與資料的管理方式，以致於愈來愈亂、愈來愈看不懂、愈來愈難管理。還有，處理完資料後，如果原始資料有變動，他也常常不知道該從哪裡開始重新處理。

總之，我給了他幾個意見：

1. 解釋為什麼獎牌架構可能不是現在他最需要的東西。他的 use case 用個人電腦就跑得動了——規模夠大了再改用對應的架構即可，不需要為了跟上流行而增加複雜度。

2. 參考我的書，導入 Modern Data Stack 。

3. dbt incremental model 大概怎麼寫。

心得

從這個對談，我學到了一件事：Modern Data Stack 的適用門檻，跟資料量或公司規模的關係不大，跟資料處理的複雜度關係才大。有在用網路爬蟲的專案，原始資料髒、變動頻繁、清洗邏輯又容易愈疊愈複雜——這種情境，往往就是 Modern Data Stack 最能發揮價值的地方。

我會⽤ map, filter, reduce 了，那我算是會 FP 了嗎？

很可惜，多數的人如果只會寫 map、filter、reduce的話，整體程式碼依然是寫成 imperative 的風格。

真正的差距不在於用了哪些函數，而在於思考方式：

• Imperative：我要怎麼做這件事？（步驟）

• Functional：這件事的結果是什麼？（資料轉換）

此外，隨著領悟的層次加深，熟練 functional style 的人，還會刻意將低階但直覺的寫法，改成高階且可以傳達意圖的寫法。

以下用一些題目與解法來比對 imperative 與 functional 的解法。

題目一：Quick Sort

Python（Imperative 思維）

def qsort(lst):
    if len(lst) <= 1:
        return lst
    pivot = lst[0]
    left = []
    right = []
    for x in lst[1:]:
        if x <= pivot:
            left.append(x)
        else:
            right.append(x)
    return qsort(left) + [pivot] + qsort(right)

Python（會寫 filter 的人）

def qsort(lst):
    if not lst:
        return []
    pivot = lst[0]
    rest = lst[1:]
    return (qsort(list(filter(lambda x: x <= pivot, rest)))
            + [pivot]
            + qsort(list(filter(lambda x: x > pivot, rest))))

Clojure

(defn qsort [[pivot & rest]]
  (when pivot
    (let [smaller (filter #(<= % pivot) rest)
          larger  (filter #(> % pivot) rest)]
      (concat (qsort smaller) [pivot] (qsort larger)))))

差異的本質：第一種 Python 的寫法是典型的寫法，而第二種 Python 的寫法就非常地函數式，本質上跟 Clojure 的寫法幾乎一致。一般的 Python programmer 即使會 map, filter ，也很容易在這一題，自動改回去用 imperative 的寫法。

題目二：mapcat 展開（repeat 的語意）

題目：輸入 [1 2 3]，輸出 (1 2 2 3 3 3)（每個元素重複自己的次數）。

Python（Imperative）

result = []
for x in [1, 2, 3]:
    for _ in range(x):
        result.append(x)

Python（會寫 list comprehension 的人）

result = [x for x in [1, 2, 3] for _ in range(x)]

Clojure

(mapcat #(repeat % %) [1 2 3])
;; => (1 2 2 3 3 3)

差異的本質：Clojure 人看到這個問題，第一個反應是：「每個元素產生一個 sequence，再把所有 sequence 接起來」──這就是 mapcat 的語意。repeat 則是把「重複」這件事抽象化。Python 的 list comprehension 雖然簡潔，但它的思維模型仍然是兩層迴圈，而不是「展開」這個概念。

題目三：Running Sum（reductions）

題目：輸入 [1 2 3 4 5]，輸出累積和 [1 3 6 10 15]。

Python（Imperative）

nums = [1, 2, 3, 4, 5]
result = []
total = 0
for x in nums:
    total += x
    result.append(total)

Python（functional 嘗試）

from functools import reduce
# reduce 只能給最終結果，不容易取到中間狀態

Clojure

(reductions + [1 2 3 4 5])
;; => (1 3 6 10 15)

差異的本質：reductions 是 reduce 的「留下所有中間值」版本。Clojure 人知道這個抽象存在，所以連「用什麼」都不需要思考。Python 人通常不知道 itertools.accumulate 的存在，即使知道，也往往是後來查到的，而不是直覺反應。FP 的熟練度，很大程度上是「知道哪些抽象存在」的熟練度。

題目四：Nested If → cond not

題目：依序驗證多個條件，失敗時各自有對應的 handler。

Python（Imperative）

def process(ctx):
    if step_a(ctx):
        if step_b(ctx):
            if step_c(ctx):
                return do_something(ctx)
            else:
                return handle_c(ctx)
        else:
            return handle_b(ctx)
    else:
        return handle_a(ctx)

Clojure（直覺但不夠好）

(if (step-a ctx)
  (if (step-b ctx)
    (if (step-c ctx)
      (do-something ctx)
      (handle-c ctx))
    (handle-b ctx))
  (handle-a ctx))

Clojure（cond not pattern）

(cond
  (not (step-a ctx)) (handle-a ctx)
  (not (step-b ctx)) (handle-b ctx)
  (not (step-c ctx)) (handle-c ctx)
  :else              (do-something ctx))

差異的本質：cond not 把「依序驗證，遇錯就停」這個語意線性地表達出來。Python 人往往不會想到反轉條件，因為習慣了「進入 if 表示成功」的思維。這個 pattern 的洞見在於：把「happy path」放到最後，讓每一行都是一個獨立的防禦條件。

題目五：fnil（預設值的語意）

題目：對一個 map 的某個 path 做 conj，若該 path 不存在，則初始化為空 vector。

Python（Imperative）

def add_to_path(hm, path, val):
    if get_nested(hm, path) is None:
        return set_nested(hm, path, [val])
    else:
        return update_nested(hm, path, lambda xs: xs + [val])

Clojure（直覺寫法）

(if (nil? (get-in hm path))
  (assoc-in hm path [val])
  (update-in hm path conj val))

Clojure（fnil）

(update-in hm path (fnil conj []) val)

差異的本質：fnil 的語意是「若參數為 nil，替換成預設值」。它把「防禦性 if」封裝成一個函數修飾器的概念，讓你專注在「我要做 conj」，而不是「我要先判斷 nil 再決定做什麼」。

題目六：Atom Validator（把不變式宣告出來）

題目：有一個計數器，必須永遠保持正數。

Python（Imperative）

count = 3
​
def decrement():
    global count
    new_val = count - 1
    if new_val <= 0:
        raise ValueError(”count must be positive”)
    count = new_val

Clojure（在每次 swap 手寫 if）

(def a (atom 3))
​
(swap! a (fn [n]
           (if (pos? (dec n))
             (dec n)
             (throw (ex-info “must be positive” {})))))

Clojure（:validator）

(def a (atom 3 :validator pos?))
​
(swap! a dec)  ; 自動驗證，違反則丟出例外

差異的本質：:validator 讓你把不變式（invariant）宣告在資料定義的位置，而不是散落在每個操作裡。這是 FP 思維的核心之一：把規則附著在資料上，而不是附著在操作上。

總結：差距在哪裡？

Clojure programmer 的優勢，不只是語法更簡潔，而是 Clojure 社群長年累積了大量對應「語意模式」的慣用寫法（idioms）。 學習 Clojure 的過程，也往往是在學習這些 idioms 時，逐步深化了對 functional style 的理解與領悟。

客戶的應用方式：

1. 準備素材。

2. 叫 AI 整理一下素材。

3. 叫 AI 根據素材，生成對應的投影片。然後，對不滿意之處反覆調整。

我的應用方式：

1. 將我的文字整理成 marp CLI markdown 的格式、圖

2. 反覆 AI 對話，改文字、編修文字、調整圖的控制語法。

3. 用 marp CLI 來生成對應的投影片。

這兩種應用方式，有個關鍵差異：

• 我的應用方式，讓 AI 的 feedback loop 相對很短，因為 AI 不需要把內容轉成投影片，少了一段工作。而且 AI 的輸入與輸出，都是純文字的 marp CLI markdown 格式，這也節省了許多的 token 。

CLI 程式與 DSL

上述的這種應用方式，對某些 IT 專業人士來講，應該是直覺到不行，對一般人來說，卻不太容易想到，需要更多的想象力。仔細想想，我似乎也是在某個時刻，才把這個觀念打通的。

二十多年前，在我大學一二年級時，學校主要教 C++ ，同時，我參加大專 CAD 競賽時，官方也是要求寫 C/C++ 。那時真的很多應用，我第一時間在思考自動化，就是用 C++ 去想。

有一回，我的一個朋友，他的 word 文件裡，有極度複雜的文字編輯工作，沒有辦法用單純的『尋找/取代』完成時，我第一時間思考的方式，也是在想：「我有沒有可能寫程式，讀取所有的字串，然後，把編輯的複雜規則都在程式碼裡做完。」

這個想法當然是失敗了，因為開發 C++ 程式實在太慢了，不實用。

而後來，我多學了很多東西之後，遇到類似的問題，我會考慮：

1. 用 regular expression ，這樣子的話，就容易表達更複雜的字串處理邏輯。

2. 用 Linux 上的 shell script 拼裝一些工具來做，比方說：sed, wc, awk, tr 等。

這個故事跟上述的 AI 應用有關嗎？有的。

某種程度，如果一般人隨意地啟動 Claude Cowork ，並且對 AI 下指令，AI 解決問題的方式，往往就是暴力地直接寫程式來處理，通常是 Python 。Python 已經不算是太消耗 token 了。然而，如果使用者給的檔案格式，又是 word 又是 excel 的話，AI 的讀取與輸出，全部都要不停地寫程式，那 token 的消耗量自然就大了。

另一方面，如果叫 AI 做事，一方面指定了純文字的格式，又引導 AI 使用一些 CLI 程式，讓 AI 的輸出、輸入都是 DSL (domain specific language) ，那 AI 的 feedback loop 自然大幅縮短，token 的效率也就提高了。

更深層的連結：資料驅動程式設計

上述的概念，其實還可以連結到資料驅動程式設計 (Data-driven programming) ，這是在 The Art of UNIX Programming 一書提到的概念。以下是書中的一段話：

UNIX programmer 習慣於寫「語法解析器的規格」來生成「語法解析器」，好用來處理「標記語言」。因為做完語法解析器之後，剩下的工作就是對配置文件來做一般的「樹走訪」就可以完成了。要漂亮地解決問題，需要資料驅動程式設計的兩個階段來達成，而其中一個 (樹走訪) 建構於於另一個 (語法解析) 之上。

在上述引文裡的「標記語言」可以有很多不同的形式：

• marp CLI markdown

• regular expression

這些「標記語言」都是 DSL 。

在實務的應用裡，DSL 的出現，對我來說意味著，工作可以分割成兩個階段：寫作 DSL 的部分可以交給靠近商業端的人，執行 DSL 的工作可以交給靠近工程的人。

長久以來，寫作 DSL 的工作，由於沒有 AI 輔助，常常還是留在 IT 工程師身上。在 AI 流行的時代，應該可以交更多出去吧？

附帶一提，你有在處理資料倉儲或是 Excel 嗎？如果對本篇文章的概念有興趣，可以參考我的書《從試算表到資料平台》，這本書介紹了 Modern Data Stack 的概念，它會讓你對 SQL 這種 DSL 的應用有新的看法。

為什麼覺得它重要呢？過去我還在為 Arne 工作時，他做 code review 時，會動手改個幾筆，有時候邊改他會邊說：「這個部分是 policy ，不要把它跟 mechanism 放在一起。」類似的事，發生了兩三次。總之，他也寫了文章來闡述這個概念，我想…，也許他以為我某種程度地懂了吧。可惜，我沒有。

最近我用 Claude Code 做了一個叫做 /clj-refactor 的 commands ，並且用這個 command 來批改我的程式碼。然後，神奇的事發生了，它批改時，給我的建議，還真的跟 Arne 昔日給的長得超像。透過這樣子的操作，我對這個概念得到了新的理解。

為什麼原始文章很難懂

原始的文章難懂，主要是有幾個問題：

1. 詞彙的選擇。

2. 缺乏例子。

3. 不平衡。文章最重要的部分，佔用的比例太少。

詞彙選擇

作者選擇使用 Mechanism 與 Policy 兩個詞彙來描述『客觀』與『主觀』這兩種概念，因為他最初是在 UNIX 的書裡學到這兩個詞。

然而，實質上，作者在文章裡用了相當的篇幅去重新定義這兩個詞 (參考下表)。既然這樣子的話，好像其實可以不需要用這種『要想一下』的詞了，可以更乾脆地用客觀來代表 mechanism ；用主觀來代表 policy。

對讀者來說，第一次讀就要把整個對照表背下來、或是體會它，可能不太容易。記不住對照表的話，可能就只記得了 policy 與 mechanism 。於是這變成文章的要旨還是記不太住。記不太住的話，要在日後的程式設計過程中產生理解就又更難了。

當然，用了精確的詞還是有精確詞的好處，以學術的角度來看，這讓文章更顯得清晰。主觀通常指「依個人偏好而定」，確實與軟體開發裡的主觀「依當下商業決策而定」詞意有所不同。

缺乏舉例

缺乏舉例這點實在是一個硬傷。所幸，我用了該文章去做出了 /refactor-pm 這個指令之後，我就從我寫的程式碼裡，得到了不少的例子，大幅改善了我的理解。

以下以呼叫 LLM API 為例，示範兩者混雜時的樣子，以及重構後的結果。

• 重構前

(defn call-llm [user-message]
  ;; policy: model choice, temperature, max-tokens are hardcoded
  (let [response (http/post “https://api.anthropic.com/v1/messages”
                            {:headers {”x-api-key” (System/getenv “ANTHROPIC_API_KEY”)
                                       “content-type” “application/json”}
                             :body (json/encode
                                    {:model “claude-sonnet-4-20250514”
                                     :max_tokens 1000
                                     :temperature 0.7
                                     :messages [{:role “user”
                                                 :content user-message}]})})]
    ;; policy: error handling strategy is also baked in
    (if (= 200 (:status response))
      (-> response :body json/decode (get-in [”content” 0 “text”]))
      (throw (ex-info “LLM call failed” {:status (:status response)})))))

• 重構後

;; mechanism: just knows how to talk to the API
(defn call-llm [{:keys [model max-tokens temperature messages]}]
  (let [response (http/post “https://api.anthropic.com/v1/messages”
                            {:headers {”x-api-key” (System/getenv “ANTHROPIC_API_KEY”)
                                       “content-type” “application/json”}
                             :body (json/encode
                                    {:model model
                                     :max_tokens max-tokens
                                     :temperature temperature
                                     :messages messages})})]
    {:status (:status response)
     :body (-> response :body json/decode)}))
​
;; policy: opinions live here
(defn summarize-text [text]
  (let [result (call-llm {:model “claude-sonnet-4-20250514”
                          :max-tokens 1000
                          :temperature 0.3
                          :messages [{:role “user”
                                      :content (str “Summarize: “ text)}]})]
    (if (= 200 (:status result))
      (get-in result [:body “content” 0 “text”])
      (throw (ex-info “Summarize failed” result)))))

不平衡

文章的一大要旨是在其中一句：

The distinction here isn’t so much in what the code does, as in how it is written.

沒有這一句的話，文章可能會被這樣解讀與應用：「接下來要開發的這一塊程式碼是與 LLM API 溝通，所以，那它應該是 mechanism 。(what the code does)」

加了這一句之後，文章的解讀與應用則變成：「接下來要開發的這一塊程式是與 LLM API 溝通。那麼，在開發完之後，應該要來仔細看程式碼裡，哪些部分同時含有 mechanism 與 policy ，如果有兩者混雜的話，要把 mechanism 往下移，把 policy 往上移。」

程式碼的組織方式

程式碼很多時候圍繞著它的特性而組織的：『效能』是一種重要的特性，而為效能做極致最佳化的程式碼往往難以閱讀，所以會將其獨立組織起來 (封裝)，至少讓它的介面容易理解。『副作用』也是一種關鍵的特性，只要是與外界溝通、與系統資源溝通的程式碼，都會有 I/O 、會有例外需要考慮，也因此副作用相關的程式碼往往也會與資料轉換的程式碼分開組織。

那「客觀」與「主觀」呢？它們對應的特性是『變動速度』。客觀的部分變動得很慢；主觀的部分隨時在變動。就像在原文裡所說的：

So the rate of change is very different. Good mechanism code can live on for years with hardly any changes. You may fix a bug from time to time, or make it more efficient, or perhaps extend it to support more features, but the core thing that it does stays the same.

Policy code on the other hand is really just a bunch of opinions. This is how we decided that things should currently work. Expect to be tweaking and changing this almost constantly.

總結

最近，我在思考一個問題：「用 LLM agent 來輔助軟體開發的話，該怎麼讓專案長大了之後，專案還是看得懂？」一直以來，我心裡的答案之一是：「邊開發要邊設法將函式庫 (library) 抽取出來。」那要怎麼讓 LLM 也能觀察出 pattern ，來協助我們找出適合提取 library 的程式碼呢？

客觀的部分變動慢、邊界清晰，正是適合抽取成 library 的特徵。換句話說，持續重構讓 mechanism 浮現的過程，其實就是在為未來抽取 library 鋪路，也讓 LLM 更容易從穩定的結構裡辨識出可複用的 pattern。

前人的文章已經給了答案，邊開發就要邊不斷地重構，才能讓客觀的部分逐步浮現。

Dimensional N+1 問題

客戶回報了一個問題。

他們用 Metabase 看一張 ClickHouse 資料表，6000 筆資料，直接看沒問題，大約 10 秒。但只要切換成資料透視表（Pivot Table），就要等 120 秒。

同一份資料，慢了 12 倍。

Pivot Table 是什麼

同樣是這份資料：

Pivot 之後，變成這樣：

資料沒有變，但「2月南部最好」這個結論，現在是視覺直接告訴你的。

這個例子只有 2 個維度。維度一多，小計的組合就會指數增長。如果讀者對 Pivot 背後的 SQL 機制有興趣，我在《從試算表到資料平台》一書裡有更完整的討論。

抓問題的方式

遇到這種效能問題，如果可以快速地重製情境，那就可以從 frontend 的　Chrome Debugger 去看出各個 backend RESTful API 大約各花多少時間，很快地來定位效能瓶頸。

不過，由於重製情境可能需要相對大的 dataset (6000 筆)，所以我決定走另一條路。

我下載了 Metabase 的 source code，然後用 Claude Code 來做 code tracing。

過去這種事情很花時間，光是理解一個陌生 codebase 的架構就要半天。但現在 Claude Code 可以從 frontend 的元件一路追到 backend 的查詢處理層，並很快地就走訪完了完整的呼叫鏈。

診斷：Dimensional N+1

首先排除了 frontend。

frontend 確實有一些小問題，像是 canvas 文字測量的 style flush 造成的 layout thrashing，CLJS 資料轉換也是同步執行，但這些加起來頂多幾百毫秒。解釋不了 110 秒的差距。

問題在 backend。

當使用者切換到 Pivot Table，Metabase 不是送同一條 SQL 查詢，而是換了一條完全不同的執行路徑（card.clj:337）：

(if (= :pivot (:display card))
  qp.pivot/run-pivot-query       ; ← Pivot Table 走這條
  process-query-for-card-default-qp)

run-pivot-query 會呼叫 generate-queries，對所有的 breakout 欄位計算冪集（powerset），為每一種小計與總計各自產生一條 SQL：

breakout: [地區, 品類, 年份]
→ 產生以下查詢：

  [地區, 品類, 年份]   ← 主資料
  [地區,       年份]   ← 欄小計
  [地區, 品類      ]   ← 列小計
  [地區            ]   ← 列小計（更高層）
  [            年份]   ← 欄總計
  [                ]   ← 右下角總計

這些查詢，在 process-multiple-queries（pivot.clj:363）裡逐一、循序執行，沒有並行。

一條查詢 10 秒，跑 12 條，就是 120 秒。

這就是 N+1 問題，只是換了個尺度。傳統的 N+1 問題是「取一批資料，然後對每筆資料再各送一次查詢」。這裡的 N+1 則是「一張 Pivot Table，拆成 N 條查詢，一條一條地送進資料庫執行」。我把它稱為 Dimensional N+1。

為什麼不能只改 ClickHouse Adapter

自然地，下一個問題是：「可以不改 Metabase 的核心，只修改 ClickHouse 的 adapter 嗎？」

不行。

Metabase 的 driver 架構是靠 multimethod 來做擴充，driver 可以 override SQL 的編譯、型別轉換、日期處理等等。但 generate-queries 和 process-multiple-queries 都是 pivot.clj 裡的 private plain function，不是 multimethod，adapter 沒有任何 hook 可以介入。

當 driver 拿到 SQL 的時候，已經是拆好的多條查詢了。它不知道自己是在執行 pivot，自然也無法把查詢合併。

其實解法很清楚：主流的 OLAP 資料庫幾乎都原生支援 GROUPING SETS 或 ROLLUP，可以用一條 SQL 表達 Metabase 現在用 N 條查詢才能做到的事。ClickHouse 也支援。但 Metabase 整個 codebase 沒有任何一行用到這些語法，而且要使用的話，必須改動 core，不是改 adapter 就能解決的。

結語

整理完診斷之後，我去 Metabase 的 GitHub 提了 issue。然後發現，2023 年就有人提過類似的問題了。

那個 issue 被標記為 difficult，至今仍然開著。看來還要再等一段時間。

一直以來我做投影片都有一個困擾：如果用一般的 Google Slides 或投影片軟體，我常常要一邊寫內容、一邊想配圖，還要處理排版、字體大小，以及整個投影片的 Look and Feel。

我本來就知道有一種方式可以用 Markdown 格式來做投影片，比方說用兩個 heading（##）表示一張投影片的標題，並利用三個橫線（---）來表示投影片之間的跳頁，這就是 marp 的 Markdown 格式。

marp 的 Markdown 格式範例如下：

## Agenda

- 什麼是 Lisp ?
- Lisp 的起源
- Lisp 的現在
- Lisp 的未來


---

## 什麼是 Lisp ?

(+ 1 2) 
;; => 3

我之前的實驗是，用這樣一個 Markdown 檔放了例如 30 張投影片的內容，再用 marp CLI 程式去轉換。但當時出現的問題是轉出來的投影片會「破圖」，原因在於如果我沒有特別去調整每張圖片的長寬，它並不會自動縮放。雖然 marp 格式裡有一些控制語法可以自動調整圖的大小，但我覺得那些語法對我來說有點困難。

LLM + marp CLI

總之，上週我實驗的結果是：

1. 我把投影片的內容全部放在一個 Markdown 檔裡。

2. 在每張投影片中，透過 Markdown 嵌入圖片的功能，去 reference 其他資料夾裡的圖片。

3. 我把圖片資料夾和這個 Markdown 檔，放到一個 Claude Cowork 可以存取的資料夾。

接著我請 Claude Cowork 幫我把這些內容做成投影片。結果很順利地做出了一份 Slide，而且它的 Look and Feel 還有圖片的位置都非常正確。

我試過的兩種 prompts

1. 根據 slides.md 這個檔案，幫我生成 slides ，並且做適度的美化。注意圖的大小。

2. 用 marp 將 slides.md（含 images/ 圖檔）轉出為 slides.pdf。
需求：在轉出前，修正所有圖片的 Marp 語法，使其不超出投影片邊界——圖片佔滿版的用 ![bg contain]，圖文混排的用 ![h:Npx] 限高。

我問 Claude Cowork 是怎麼做到的，它說它之所以可以做得這麼好，是因為它直接寫了 Python 程式去量測每一張圖片的長寬，並設計合理的方法排入圖片，所以就不會有破圖的問題。

經過這個實驗，我有幾點心得：

1. 我很喜歡 CLI 程式和 Markdown 的格式，這些東西最沒有雜訊只有訊號。很幸運的是，CLI 程式和 Markdown 格式也非常適合 LLM 使用，所以我的工作流程本來就很適合讓 AI 來協助。

2. 關於人跟 AI 之間的協作，人應該還是要專注在最重要、最核心的內容；至於那些比較花心力的排版細節，不妨就交給 AI 吧。

   Thanks for reading PruningSuccess! Subscribe for free to receive new posts and support my work.

1. 推荐使用 typeless 語音輸入

2. 推荐使用 Claude Cowork

3. 分享我的 Claude personal preferences

typeless

就像網路上許多人講的一樣，滿好用的。

不過，真的用了幾天之後，還是沒有想象中的順手。主要是因為我平常寫書時，似乎是認真寫作居多，編輯的時間很多。一個段落往往是反覆編輯五、六次才會滿意。

大量編輯的前提之下，typeless 就沒有想象中的高效了。如果只是跟朋友傳訊息的這種，還不錯。歡迎點我的推荐連結。

Claude Cowork

最近一些 Excel 的事，都透過 Claude Cowork 來代勞。感覺上，以前教友問我的問題，說不定也可以用 Claude Cowork 來處理。

Claude Cowork 是要付費才能用的功能，我付費買最基本的 Claude Pro 之後，覺得最好用的就是這個功能。

我的 Claude personal preferences

1. 預設使用繁體中文台灣用語回答。
2. 用繁體中文輸出回答時，使用全型的中文標點符號（，。！？）等
3. 使用台灣常用的技術術語，而非直譯的中文詞彙 (例如:「部署」而非「佈署」)
4. 回答時保持簡潔，避免過度冗長的解釋，除非我明確要求詳細說明。
5. 翻譯、改寫文章、輸出長文時，預設使用 markdown 格式輸出，而且不要 render 。
6. 寫程式碼時，註解一律使用英文。
7. 當回答涉及推論、預測、因果分析或建議時，依情境選擇性附上：信心區間、最強反對論點、關鍵隱性假設、或基準率數據。
8. 請根據任務類型調整您的互動模式：
* 生成與重構類任務（例如：重寫、重新組織、修正或編輯）：在開始執行前，請先提出釐清性的問題。這類任務通常需要更多背景資訊，才能符合我的預期。
* 收斂與分析類任務（例如：評論文章、分析邏輯）：請立即開始執行任務，無需事先提問。
9. 寫程式碼時， web application 優先使用 Clojure。shell script 優先使用 Babashka 。其它的事情，比方說，Data Analytics ，則不在此限，可以選擇最合理的選項。

比較特別的，應該是第七與第八點。

第七點是因為我當叫 AI 幫我推論、預測、給建議，我都很擔心過分自信。第八點的話，則是因為生成與重構類的任務，通常我給的 context 都不夠。

總結

我總覺得，使用科技與提昇生產力之間還是有一個關鍵：「從問題去尋找解決方案」。所以，要提昇生產力，最重要的還是先觀察出平常工作的流程裡，有哪些部分是低品質的、是斷點，然後再去尋找解決方案。

順著這個思考，查了一些社會的統計與研究，又看到了一些社會的現實。

英語補習的反轉現象

在台灣的影子教育研究中，有一個非常有意思的數據分歧。傳統上，我們認為「越有錢，補習就補得越兇」，這在數學、理化等學科確實是真理，但在英語這門學科上，卻在 PR 90 的家戶門檻（約年收 300 萬台幣以上）出現了「反轉」。

根據學者關秉寅、林大森等人的實證觀察，當家庭社經地位達到頂端時，孩子在國高中階段的英語補習參與率反而開始下降。這不是因為這群「天之驕子」不重視英文，而是他們早已透過更昂貴的路徑，提早完成了這場競賽。

這個現象背後隱含了一個社會學的邏輯：數學是「形式科學」，但英文是「文化慣習」。

對於 PR 90 以上的家庭來說，英文並非考卷上的選擇題，而是客廳裡的 Podcast、餐桌上的外籍保姆，或是暑假那場動輒 30 萬台幣的海外遊學。社會學家布迪厄（Pierre Bourdieu）稱之為「具身化文化資本（Embodied Capital）」。當英文變成了「生活環境」的一部分，它就被自然習得了（Acquisition）；而對中產或基層家庭來說，英文永遠只是一門需要透過痛苦背誦、在補習班「學習（Learning）」的「考科」。

需要焦慮嗎？

焦慮是主觀的，還是來談應對之道吧。

首先，PR 90 的家庭，並不是每一家每一戶都這麼認真。往往是高收入且極高學歷的家庭的部分，才會積極地用生活環境來取代補習，而且很可能這樣子做家長也非常不輕鬆。

之前在新聞上露出很大一篇的以馬內利小童，家庭收入的 PR 值應該遠超過 90 。根據揭露的資訊，補習的強度之高，高到讓我懷疑，這到底是缺乏策略思考到什麼程度？有錢到這種程度，明明就有更好的資源運用方式。

給中產家庭的建議呢？

時間有限，優先把英文以外的科目補好，英文設法學到不太差、讀寫可用即可。剩下的要靠小孩自己。理由如下：

一方面，英文補習不是「沉浸式的教學」，很多只能事倍功半，同樣的時間拿去補數學、國語、作文，相對有機會得到三倍的成效。以常見的兒童美語補習時數估算，同樣時間拿去補其他科目，ROI 大約是數倍以上。也因此，在時間金錢有限的前提下，應該選擇 ROI 高的項目，行有餘力，再去追求英文。另一方面，PR 90+ 家庭的子女，搞不好就業後許多並不在國內與中產家庭的子女競爭，換言之，那口在國內時一開口就散發著階級感的流利英文，也有可能日後只是國際市場的入場券。

那中產階級的子女就沒有機會把英文學到流利了嗎？現在已經有許多網路學習資源，足以創造沉浸式環境了，只是說，這很需要靠學生本人的自律與主動性。而少數中產階級極致的時間濃縮教養方式，恰好不利於培養主動性。

此外，在一個有 LLM 的時代，某種程度，母語的熟練度、母語的寫作能力，在職場應用來講，ROI 可能比英文更好。

結論

花費長時間「補英文」的學生，搞不好日後英文口音還是頗不自然，就跟多數的台灣人一樣；而那些從沒進過英文補習班的學生裡，其中的少數人，在面試時開口就是一口流利的腔調。

這不是努力與否的問題，是環境決定了你能長出什麼樣的語言。以十八歲的小孩來講，他們語言能力的天花板，往往被家庭的日常生活給定錨了。

中產家庭能做的，是接受這個現實，然後把資源放在真正值得押注的地方——英文學到可用，其他科目卯起來拼，剩下的選擇，交給要用的那個人去自己活出來。

Writing is an act of ego, and you might as well admit it.

William Zinsser 寫下這一句，並非鼓勵自大，而是提醒作者要對自我誠實。既然寫作是自我的展現，作者就應對文字負起「嚴肅看待」的責任，認真打磨技巧以呈現最清晰的想法；另一方面，這也意味著寫作必須「為自己而寫」，不必刻意討好讀者，而這份對真實自我的堅持，確實需要不少「被討厭的勇氣」。

最近，我在寫作時，一時興起，就叫 LLM 來歸納我的寫作風格。開始玩之後，一發不可收拾，我還拿網路上的一些 KOL 的文字也做相似的玩法，然後，發現寫作風格與職涯選擇之間有些耐人尋味的關聯。

我一直無法理解：

• 某些技術 KOL 為什麼要做如此辛苦的工作，明明有相對輕鬆不少的選項。

• 絕對不是不懂寫作，但是，不知為何，總是喜歡用一種加入完整案例的寫法、結論後置的寫法、結論為案例服務的寫法。

• 為何文章已經過長了卻有眾多讀者

某些技術 KOL 選擇做 Fractional CTO 的工作。老實說，這種工作很難做，年薪不低，但是考慮到總是要不停地救火，長期累積下來，對身心的壓力都非常大。相對地，我的 IT 顧問工作，在最初起步時，確實也做了 2, 3 個救火的案子 (extreme problem solving)，但是，隨著我後來開始積極地做社群、發表長文，找上門的客戶，漸漸地轉向了好上加好的案子 (innovation) 。案子的性質改變了，除了價格更好一些，同時，執行專案時附帶的衝突與壓力更是少了一半以上。

用 LLM 做了長文的分析之後，得出的解釋是：

• 職涯上，這類 KOL 傾向選擇高壓救火型工作，可能透過解決困難問題來建立專業認同

• 寫作上，偏好細節豐富、結論後置的風格，同樣是透過詳盡記錄來強化專業形象

• 能持續閱讀這類長文的讀者，可能也在尋找類似的確定感，他們喜歡透過完整的案例細節來驗證方法的可行性，而非只要一個簡潔的結論。

LLM 寫作分析流程

1. 找特定作者的 3~5 篇，談論不同主題，有顯著差異的文體，給 LLM 分析。

2. 先請 LLM 歸納寫作風格。

3. 再請 LLM 分析人格特質，同時此一分析基於以下的理由：

一個人可以控制「說什麼」
但難以控制「怎麼說」
一個人可以選擇「揭露什麼」
但難以隱藏「為什麼揭露」

就這麼簡單而已。目前實驗的結果，有時候很精采。而精采的程度，跟文體的變化度有關，也跟文章的總長度有關。

當然，上述的分析也有侷限性，就像眾多的心理學應用與 LLM 應用一樣。這邊還是要探討一下，是否分析有其合理性？上述的人格特質分析原則受到兩個研究領域的支持：

• 語言心理學 (Levelt, 1989; Pennebaker, 2011)：語言產出的形式化階段（如功能詞選擇、句法結構）大部分是自動化的，難以有意識控制。

• 表達性寫作研究 (Pennebaker & Beall, 1986)：即使人們刻意控制書寫內容，主題重複性和情感投入比例仍會洩漏深層心理議題。

昔日的讀者的問題

我用這個方式分析了自己的寫作風格之後，重新回答了一次讀者曾問過我的問題：

你有發現你很會說服嗎？

我第一次聽到，反應是：「我寫我自己相信的事。」

而這個問題， LLM 則提出了另一個可能的答案：

這名作者致力於挑戰既定假設並揭示隱藏機制。其文字不僅是資訊的載體，更是一套工具，引領讀者透視表面現象，進而理解底層結構。其最終目標不只是傳遞訊息，更是要重塑讀者的思維模型。

什麼是參數化儀表板?

參數化儀表板就是那種「讓使用者自己選日期範圍、類別、地區」的互動式報表。比方說，業務主管想看「2024 年第一季，電子產品類別，在台北地區的銷售趨勢」，他就在儀表板上選擇這些參數，圖表就即時更新。

聽起來很簡單，但實作起來有些眉角:

• SQL query 要處理可選參數(有些參數可能不填)

• 參數之間可能有相依性(選了某個類別，子類別的選項要跟著變)

• Query 效能要顧好(使用者不會想等 30 秒)

AI 的標準答案

我問了 AI：「如何透過 AI 開發 Metabase 參數化儀表板?」

AI 給了很典型的回答:

1. 需求討論階段：描述儀表板目的、目標使用者、關鍵指標

2. Query 生成：AI 產生 SQL，你在 Metabase 的 SQL editor 裡測試

3. 參數設定：AI 建議用什麼類型的參數(下拉選單、日期選擇器、輸入框)

4. 除錯：遇到問題時把錯誤訊息丟給 AI

這個流程本身沒錯，但有個實務上的很不方便：人要在 Metabase UI 和 AI 之間不斷 copy and paste。

• 把 AI 生成的 SQL 貼到 Metabase

• 測試失敗，把錯誤訊息複製回去給 AI

• AI 修正後，再貼回 Metabase

• 重複以上步驟

如果是簡單的 query，這樣做還好。但參數化儀表板的 SQL 通常不簡單，可能有多層邏輯、多個可選參數、複雜的 JOIN。還有，最麻煩的還是要複製查詢出來的報表，每次修改都要手動 copy and paste，我乾脆自己動腦想，搞不好還勝過反覆 copy and paste 的時間。

引入 DuckDB 的快速驗證

我想了想，決定換個做法:先在 DuckDB 裡驗證邏輯，再轉到 Metabase。

DuckDB 有個很棒的特性：它的 view 可以引用 session variable。這意味著我可以在本地建立「參數化的 view」，快速驗證邏輯是否正確。

工作流程變成這樣:

-- 1. 設定測試參數
SET VARIABLE start_date = '2024-01-01';
SET VARIABLE category = 'electronics';

-- 2. 建立參數化 view
CREATE VIEW sales_summary AS
SELECT 
  order_date，
  SUM(total) as revenue
FROM orders
WHERE created_at >= getvariable('start_date')
  AND category = getvariable('category')
GROUP BY order_date;

-- 3. 立即測試
SELECT * FROM sales_summary;

改成這個流程後，得到的改變是:

快速迭代：人不用在 Metabase UI 點來點去，AI 直接透過終端機操作 DuckDB。改一行測一次，幾秒鐘就知道結果。

輔助驗証：原始資料、「參數化的 view」、還有預期會長成的結果的 Excel 資料，我也把它一併放進了 DuckDB 。直接叫 AI 幫我驗証。

從 DuckDB 到 Metabase

當然，最後還是要轉回 Metabase。DuckDB 和 Metabase 的參數語法不太一樣:

-- DuckDB
WHERE created_at >= getvariable('start_date')

-- Metabase
WHERE created_at >= {{start_date}}

-- 或者用 optional parameter
[[WHERE created_at >= {{start_date}}]]

我甚至寫了個簡單的 Babashka Script 來自動化這個轉換：

(defn duck->metabase [sql]
  (-> sql
      (str/replace #"getvariable\('(\w+)'\)" "{{$1}}")
      ;; 其他轉換規則...
      ))

這樣一來，整個開發流程就變得很順暢:

1. 在 DuckDB 裡快速驗證邏輯(與 AI 協作)

2. 確認無誤後，用腳本轉換語法

3. 貼到 Metabase，微調 UI 細節

Process Knowledge 再現

這個經驗讓我又看到一次「人負責 process,AI 負責 content」的模式。

AI 提供了什麼 content?

• SQL 語法細節

• Metabase 參數的用法

• 常見的效能優化技巧

但整個開發流程的設計，卻是我自己決定的:

• 我判斷「copy and paste 來回太麻煩」

• 我知道 DuckDB 有 session variable 這個特性

• 我設計了「先在本地驗證，再轉到 Metabase」的流程

• 我決定寫腳本自動化語法轉換

這些都是 process knowledge。AI 可以告訴我「Metabase 怎麼用」，但它不會主動建議「你應該先用 DuckDB 驗證」。因為這個判斷需要:

• 對工具生態的了解 => 知道 DuckDB 存在且適合這個情境

• 對開發的敏感度 => 察覺 copy and paste 會是瓶頸

• 對整體流程的掌控 => 知道什麼時候該引入新工具

這些流程知識是從真實的開發經驗中累積出來的。而「什麼情況該用什麼流程」的直覺，很多時候我也是狀況來了，直覺才冒出來。

公司有一個 Clojure 寫成的 web application 的專案，由於它會被布署到 GCP 上，所以它的建置流程相對複雜，最後的產出物不是單純的 jar 檔，而是 docker image 檔。建置流程通常都由我的同事處理完，也因此這一塊我極度不熟悉。基於某些原因，建置流程壞掉了，所以我開發完新的功能，卻無法布署 (deploy)。

由於上週四就是我在前公司的最後一天，離職前我希望畫下一個完美的句點，我決定挑戰一下建置流程的 bug 。

首先，我把終端機丟出的錯誤訊息給 AI ，請它幫忙。

${情境描述}
${錯誤訊息}
你覺得可能原因為何？下一個線索上哪找？

其中，錯誤訊息裡的關鍵成分是：

Execution error (IllegalArgumentException) at juxt.pack.jib/make-builtin-layers$fn (jib.clj:145).
No matching clause: 

AI 答曰：

問題在 juxt.pack.jib/make-builtin-layers 的第 145 行，在處理某個 layer 時的 case 或 cond 陳述式失敗了。

解決方案：${錯的解法}

我認為 AI 對錯誤訊息的解釋合理，但是解法不對，所以我再補了一個 prompt

是否有什麼方法，可以更加精確的定位問題，再來想解法？

AI 答曰：

修改 release.clj 的 ${某處}，將 ${變數內容} 印出。

然後，我就搞懂了問題，並且自己想出了合理的解法。

對除錯流程的反思

回顧這個過程，我發現一個有趣的分工模式：

AI 提供了大量的內容知識 (content knowledge)：錯誤訊息的可能意涵、Clojure 的語法細節 (哪些語法可以產生特定的錯誤訊息)、建置工具的運作方式。這些都是我不熟悉的領域，如果要自己從頭查資料，可能要花上 1~2 小時，同時，極度消耗我的專注力。

但整個除錯的流程知識 (process knowledge)，卻完全是由我掌控的：我知道該問什麼問題、如何判斷 AI 的答案是否合理、下一步該往哪個方向探索、什麼時候該停止依賴 AI 自己動手。

更重要的是，當 AI 給出「錯的解法」時，我能立刻察覺。不是因為我懂 Clojure 建置流程的細節，而是因為我懂除錯的流程：「在還沒精確定位問題前，不該急著套用解法」。

這讓我反問自己一個問題：「在 AI 時代，什麼樣的知識變得更重要了？」

Process Knowledge vs. Content Knowledge

用語言學習來比喻的話，process knowledge 就像文法，content knowledge 就像單字。

語言專家會說：「文法有限，很快就學完了；單字無邊無際，學不完。」但對還不會的人來講，文法卻非常難學，比單字難學得多。

為什麼？因為文法是抽象的、系統性的、需要理解「為什麼這樣說」的規則。單字是具體的，不懂就查，查了就記得（至少暫時記得）。

但文法一旦掌握了，就可以活用語言。單字再多，沒有文法，也組不出有意義的話。

軟體開發的 process knowledge 也是如此。它往往是關於：如何診斷問題、設計實驗、決策 。這些知識數量有限，但極度抽象，而且高度依賴情境和經驗。更糟的是，它們大多是隱性知識 (tacit knowledge)，連擁有它的專家都很難明確說出「我是怎麼做的」。

反觀 content knowledge：這個錯誤訊息代表什麼、這個 API 怎麼用、這個產業的標準做法是什麼。這些知識無邊無際，但只要連上網際網路，通常都可以查得到。

AI 真的學到 Process 了嗎？

這帶出一個關鍵問題：當我們說 AI「很厲害」時，它到底學到了什麼？

LLM (大型語言模型) 的訓練過程，本質上是從海量文本中學習「在這種情境下，通常接下來會出現什麼」。它建立的是一個龐大的 pattern library，記錄著無數的「情境/回應」配對。

這讓它在提供 content knowledge 上表現驚人。你問它一個技術問題，它能從訓練資料中找到相似的模式，給你看起來很合理的答案。

但它真的掌握了 process knowledge 嗎？

讓我們看一個對比：AlphaGo。

AlphaGo 是透過「在真實的圍棋世界中無限地搜尋 (解決方案) 與學習 (不同解法的後果)」來掌握圍棋的。它下了數百萬盤棋，每一步都得到即時的、明確的回饋（這步棋好或不好）。它不只是記住「在這種棋型下人類通常怎麼下」，它是真正在探索「什麼策略會贏」。

這種訓練法可以訓練出連人類都無法掌握的 process knowledge。

但 LLM 沒有這樣的學習機制。它沒有在真實世界中試錯、沒有得到明確的成功/失敗回饋、沒有機會驗證「這個流程是否真的有效」。

它只是看過很多人在類似情況下怎麼做，然後記住了這些 patterns。

這意味著：

• LLM 可以告訴你「下一步這樣做機率」最高，但不能保証「抵達終點的機率」最高

• 它可以在訓練資料覆蓋的範圍內表現很好，但遇到真正新的情境就可能失效。

回到我的除錯經驗：AI 給我的第一個解法為什麼是錯的？因為它只是從訓練資料中找到「遇到這種錯誤訊息，通常這樣修」，但它不會自動切換帶入除錯流程。

應該帶入除錯流程這個判斷，需要 process knowledge。而這個切換的 knowledge，目前只在我腦中。

人與 AI 的理想分工

基於以上的分析，我認為在 AI 時代，理想的人機協作應該是：

人負責 process，AI 負責 content。

更具體地說：

• 人類掌控流程：問什麼問題、如何驗證答案、下一步往哪走、何時做決策

• AI 提供內容：資料、案例、可能的選項、技術細節

為什麼這樣分工更穩健 (robust)？

因為 process knowledge 是在真實世界的代價中淬煉出來的。一個經驗豐富的工程師，他的除錯流程是經過無數次「試錯-反思-修正」建立起來的。這些經驗雖然隱性、難以言說，但它們是真實有效的。

相對地，LLM 的「process-like behavior」只是統計上的相關性，沒有經過真實世界的驗證。當遇到罕見情況時，有經驗的人更可能有「這裡不太對勁」的直覺，因為這個直覺是用真實的失敗「買」來的。

這不是說 AI 沒有價值。恰恰相反，AI 在提供 content 上的能力是革命性的。過去我需要花數小時查文件，現在 AI 幾秒內就能給我相關的資訊。這讓我可以把更多心力放在「思考」而不是「查資料」上。

對 AI 應用設計的啟示

如果接受「人負責 process，AI 負責 content」這個原則，那麼在設計 AI 應用時，我們應該問的問題就不一樣了。

不是「如何讓 AI 自動化整個流程」，而是：

• 流程中哪些環節是「查資料、提供選項」（適合 AI）？

• 哪些環節是「判斷、決策、處理例外」（需要人類）？

• 如何設計介面，讓人類可以輕鬆地掌控 process，同時高效地利用 AI 的 content？

• 還有，哪一類的人，他們對 process knowledge 最敏感？
  

  Thanks for reading PruningSuccess! Subscribe for free to receive new posts and support my work.