別再跟試算表聊天了——專訪 Monzo 的 Francesco Galletta 與 Felippe Felisola Caso

Francesco Galletta 與 Felippe Felisola Caso 在 Monzo 為資料團隊打造 AI 驅動的內部工具。他們的論點是：AI 財務分析的瓶頸已不再是速度，而是信任；而信任必須被「工程化」進一套專為此目的打造的 harness（駕馭框架）之中，而不是靠提示詞塞進一個通用代理裡。這場議程大部分是五項設計原則的實作導覽——共享領域、一致性、證據、問責、驗證——並透過一個觀眾可在本機端執行的婚禮預算規劃工具來示範；「別再跟試算表聊天」這個框架只是前提，並非討論的主體。

兩位講者都在 Monzo 的資料部門任職，先前也待過其他金融服務公司，包括 NewBank。他們明確表示這個 demo 不是 Monzo 的產品，真正的重點是原則，而非程式碼。讀者讀完應該帶走一個具體的心智模型：在代理式（agentic）財務工作流程中，決定性（determinism）該放在哪裡；「收據」（receipts）與高訊號的審核關卡在實務上長什麼樣子；以及為什麼一個 skill 或提示詞檔案不等同於一套 harness。

真正的限制是信任，不是吞吐量

Galletta 開場先承認「信任」這個詞聽起來「虛無縹緲」，接著論證它才是重點：「我們早就過了得花好幾個小時猛敲鍵盤、才能做出一個你信得過的成果的階段。」他的論點是：代理已經能快速產出結果——現場許多觀眾大概都掛著背景的 Claude 任務在跑——所以落差在於結果如何回接到那個必須據此行動的人身上。金錢是他們能挑的最高風險領域，這也是他們選擇它的原因。

五項原則被呈現為一套層層遞進的序列，而非任君挑選的選單。Galletta 點名了那些常見的建立信任元件——trace、eval、迴圈、圖、單元測試、可觀測性——然後把它們擺到一邊：「它們基本上只是零件。」真正的貢獻是把它們組裝起來的設計原則。Felippe 補充提醒，這「不是一顆銀彈」，他們也不宣稱這是唯一正解，只是在 Monzo 內外多個使用案例中都奏效的一套方法。

示範載體刻意選得平凡而貼身：Galletta 請全場幫他規劃婚禮預算，並就賓客人數現場投票（50 人以下、約 100、約 150、200）。他拿自己和女友的預算爭論當例子——她引用了一個單次餐費成本，他則指出上面還疊了另外兩項變動成本——來說明一個「簡單計算」有多快就不再簡單。

共享領域，意味著逼模型先來訪談你

第一項原則是在動手之前，先讓人與模型對齊同一套定義。Galletta 的說法是：「模型知道的，未必是你以為的。」因為除非你有專為你訓練的模型，否則你對某個詞的定義，不會和模型學習來源的群體平均值一致。harness 的任務就是讓這個落差現形。

在 demo 中，使用者在對話窗裡輸入一個雜亂、不完整的問題——三筆各 6,000 美元的付款、一筆未知金額、「剩下的部分」，加上 DJ 與佈置的固定成本、每人約 150 美元的未知餐費、500 美元的花卉、一套要買的西裝、零存款，以及媽媽可能贊助的 5,000 美元。harness 拒絕直接跳進實作。它提出釐清問題，在資訊足夠之前不產出計畫。Galletta 強調這是刻意的反諂媚（anti-sycophancy）：harness 不該「立刻進入應聲蟲模式，把你隨口冒出的任何瘋狂點子照單全收」。

計畫一旦被接受，就會渲染成一棵由節點構成的決策樹，每個節點都標註了來源——使用者提供、代理推論，或仍待確認。點選節點會顯示模型為何把它視為決策點，以及關鍵的是，哪些假設來自使用者的措辭。Galletta 示範了一個案例：含糊的語言讓代理推論出某種含意，而介面把這項推論攤在檯面上，而不是埋起來。

接著他做了一場現場投票，帶出設計理由：誰曾在超過十輪的對話中，不得不說「讓我從頭講一遍，這根本說不通」？他主張，問題在於當今的 harness 是為線性對話而打造，所有東西都塞在同一個上下文視窗裡。節點式結構讓你得以討論個別元素，而不會汙染整體。

算術該放進受測的程式碼，而不是模型的腦袋裡

一致性原則是最具體的一項，也是失效模式最清楚的一項。Galletta 問有誰在對話裡做過預算或財務計算，全場的信心很低。他描述自己的經驗：代理回傳了一個排版漂亮、斜體化的公式，看起來很有權威感，結果卻是錯的。一位觀眾給出更犀利的版本——同一個查詢跑兩次，得到不同的數字，你就知道哪裡不對勁了。

Felippe 點出那個促使大家打造 harness 的根本區別：給代理一套 skill 或指令、寫著「請做對的事」，等於把結果寄託在一個非決定性的流程上、期望它表現出決定性的行為。harness 的價值，在於把需要判斷的地方交給非決定性、不需要判斷的地方交給決定性的後端程式碼。

Galletta 的親身例子是一份有嚴格分類、退款與支出的月度預算。他讓代理自行決定如何分類與彙總，結果每次跑出來的結果都略有不同——「它已經對過三次，第四次就錯了。」解法是把計算寫成一次性的指令碼，並讓 harness 禁止模型透過解析 token 來做算術。

他列出略過這一步的失效模式：算術活在模型腦袋裡，隨著工作階段結束就消失；每個新問題都得重寫新程式碼；同一個問題得到不同答案。反向做法就是普通的軟體工程實務——把函式庫寫一次、做單元測試、納入版本控制，並讓 harness 在版本變動時提示出來，好讓使用者知道先前的結果可能不再成立。demo 展示了被標記為需要程式碼的節點、一個「建立程式碼」的提示，以及一次測試執行——整個過程沒有任何代理的「思考」動詞，因為那只是在環境裡跑測試而已。

一位觀眾追問，這不就是良好的工程實務嗎？並問背後有沒有經過測試的產品。Felippe 指向隔天早上 Monzo 的一場分場議程，談他們自家的遠端代理能力，並澄清 demo 的程式碼是 vibe coding 出來的，但決定性／非決定性的切分才是可移轉的部分。

收據：把事實、假設與詮釋分開標記

證據原則被包裝成資料專業人士的積怨。Galletta 指出「並非所有資訊都一樣」，而把所有東西都當成事實，正是反覆出現的錯誤。他的分類法：

| 資訊來源 | harness 該如何標記 |
|---|---|
| 送出的銀行對帳單、一份檔案 | 事實 |
| 代理的推理或從記憶中回想 | 假設 |
| 打進對話裡的天馬行空想法 | 詮釋 |
| 使用者在對話中途更正的數字 | 事實，並附上指向該次更正的追溯紀錄 |

婚禮的例子讓利害關係變得具體：他的未婚妻多邀了三個人卻沒告訴他，整個模型就全錯了。在對話裡，模型分不清硬事實與粗略估計，所以 harness 必須強制執行這個區別。

他把證據的範圍從資料延伸到程式碼，講了一個關於共用「主檔案」的軼事：所有人都信任它，而它卻悄悄改掉了自己對合理數值範圍的假設。分析師沒做錯任何事，結果卻完全錯誤。同樣的盲點也適用於 harness 裡的決定性程式碼：少了程式碼變更的可追溯性，相同的輸入可能產出不同的輸出，而沒有人會察覺。

一位觀眾說，這就是他們每次跟代理對話的寫照——「這個數字哪來的」——而一份完整的紀錄會是最有用的東西。Galletta 用自己的翻車經驗呼應：一個 Google Slides 的 harness，他給模型一個修改範例，模型卻緊咬著那個範例、把它複製擴散到整份給高階主管看的簡報裡，引來一句「你那個假設裡的數字是從哪來的？」

問責：關卡要少、訊號要強，而結果由人負責

Galletta 在這裡的核心主張很直白：「代理不會承受真實世界的後果，你會。」他把這連結到自己為何支薪——是為結果負責，不是為打字負責——並問有誰聽過「這是 Claude 給我的」這種解釋。設計上的意涵是：減少模糊，但不消除模糊。

他做了一場「Auto Mode 懷舊」投票——有誰想回到每次變更都得按 Enter 核准的日子——接著問那一百次點選裡，有多少是有意義的、多少隻是改一行。一位觀眾描述自己目前的做法：先審任務清單，讓代理去跑，最後再審。Galletta 完全認同這個形狀：審任務，而不是審每一個 diff。

兩邊的失效模式，一是每一筆計算都要核准（徒勞），二是每一行 PR 都逐行審（難以為繼）。處方是「關卡要少、訊號要極強」——例如，功能測試沒過就不準上線，而這道關卡之前的一切都可以寬鬆處理。他指出關卡必須切合用途，這需要對使用案例有充分理解；一句放諸四海的「任何決定前都先問我」，只會退化成低訊號。

示範的問責機制是決策圖裡的「分支再匯合」結構。一個決策可以由代理先行假設、再與使用者核實，或事後更正，而圖會顯示是哪一種。Galletta 解釋為何非線性的形狀很重要：線上性對話裡，中途插入一個更正可能毀掉整段分析，他就曾因為一句口述的話而丟掉整份分析。harness 讓你安全地修正方向，並看見下游的連帶影響。

驗證：一雙不會替你扛責任的第二雙眼

最後一項原則，講的是如何避免盲點、又不把責任甩出去。Galletta 提出「vibe coding」把正確性的全部重擔都壓到審查者身上的模式，他稱之為令人洩氣。驗證是從不同來源加上回饋迴圈；它不會移除問責。

他觀察到，財務專家很少逐格檢查——他們開啟試算表，看那幾個能給出大概的儲存格，覺得不對勁就反應（「我們怎麼會在行銷上花這麼多？」）。這種直覺檢查既便宜又有價值，而 harness 應該複製它。他提到那個廣為流傳的爆紅說法：伊隆·馬斯克的財富足以給地球上每個人一百萬美元——他指出這讀起來煞有介事，直到你真的去驗算。

一位觀眾問黃金答案（golden answer）該怎麼放進來。Galletta 的回答是：黃金範例定義了你的基準真相，但沒有哪個領域是孤立的。他的 BI 分析師軼事：他的查詢看起來正確、每一項檢查都通過，結果另一個團隊的利害關係人立刻說數字錯了，因為他們從自己的領域知道真實的數量。轉譯到代理身上：為某個領域挑選的黃金範例，會帶著該領域的選擇偏誤，而一個看似不相干的來源，可能不必重算就能揭穿錯誤。他把人的版本稱為「薄片擷取」（thin slicing）——從經驗的薄片做出判斷——並指出模型握有的是所有人經驗的平均值，不是你的。harness 必須搭起兩者之間的橋。

在示範中，一條「挑戰」分支會啟動一個獨立代理來審查計畫與假設，其發現會匯回主幹，並可能改變計畫。Galletta 明確表示，這刻意不是 LLM-as-a-judge：沒有回饋迴圈的審查，並不會改善決策。之所以保留「駁回」選項，是因為有些挑戰並不重要，使用者應該能這麼說。

何時該打造 harness，而不是一個 skill

問答環節承載了大部分的實務指引，也是講者對取捨最坦率的地方。

談到通用性，Felippe 把它描述成一道光譜：一端是「我用 Claude Code 或 Codex 搭上 skill 和指令來做所有事」，另一端是「每個小任務都從零重造」，並警告後者會變成磨斧頭（axe-sharpening，意指把時間花在磨利工具而非砍柴）。決策取決於：可重現性的需求、現成做法出錯的頻率、會有多少使用者碰它，以及問題有多關鍵。一個有人審核產出的非關鍵任務，用通用代理就好；但交給五十位信用分析師、用來支撐公司決策的東西，就不行。

Galletta 補充，這套配方是專門為高風險的信任領域而設。對於 AI 生成的社群媒體內容，蒐集證據與驗證就沒那麼重要。他啟動打造 harness 的觸發點是：你發現自己在對話之間複製貼上、一直開新工作階段，或反覆跳同一套三到五步的舞——那就一次把它做出來。

談到 skill 與 harness 之別，Felippe 的說法是：skill 就是「請照這一切做、拜託別出錯」——對一臺隨機性機器下指令，而它 99% 的時候會照辦。出錯就出在那 1%：邊界案例、一個和使用者層級指令檔互相矛盾的 skill、釋出給眾多使用者。他描述自己看過內部共用的 skill 不斷累積防禦性指令，像是「如果使用者想這麼做，就告訴他這個 skill 不支援」——這些是為了補漏洞而打的補丁，而決定性的後端程式碼本可直接把洞封死。

談到多代理拆解（餐飲代理、場地代理），Galletta 坦承他自己婚禮試過，還說 Anthropic 因為他的用量而「虧損中」。網路搜尋驅動的研究效果很好——馬德里前五名攝影師、比較、聯絡。但凡是財務上細膩、他想要掌控與可預測性的地方，最後他都得打造一套夠穩固的東西，包括有一次開了一小時的車，同一段語音模式的對話重跑了三次，因為每一輪都出狀況。

談到如何管理高層的期待，Felippe 的答案是先講成果、別先講工具：我們要推動什麼結果、怎麼衡量（更少的來回往返、更少的「這數字看起來不對」工單），然後讓實作跟上。Galletta 以同樣的調子收尾——模型進步得很快，但「它們還是得贏得信任」，而在金錢上，錯個百分之一可能就是一大筆錢。

值得持續關注的未解張力，正是觀眾直接點出的那一個：harness 究竟是一門真正的新學科，還是軟體工程與 BI 治理的換皮。講者傾向後者——原則是幾十年的老東西，組裝方式才是新的——這意味著真正懸而未決的問題是組織面的，而非技術面的：誰擁有這套 harness、誰在前提與來源資料變動時維護那個決定性層，以及各團隊如何避免在每個領域裡重造同一道關卡。