把 AI 關進帳房：Steve Yegge 的企業 AI 導入另一條路

工程部的 AI 卡關，客服部反而可以先上

2026 年快過完了，大企業導入 AI 寫程式的成績單，坦白說不太好看。Steve Yegge 最近跟一堆銀行聊過，聽到的都是同一套話：有時候效果驚人，有時候一團亂；A 團隊做得起來，B 團隊照抄就失敗；帳單越來越貴；工程師私下反彈。他的判斷是，這種掙扎會一路拖到 2027。

Yegge 是誰？他是 Amazon 和 Google 的老工程師，2000 年代初在 Amazon 管客服工具部門，每週跟 Bezos 開會看客訴數據。他現在自己養著一支 50 個 AI agent 的「軟體工廠」，每週產出兩三千個 commit。換句話說，他同時站在「AI 寫程式」和「AI 做客服」兩邊，看得很清楚哪邊比較好走。

他在 2026 年 10 月底發表了一篇長文，提出一個他叫做 Counting House（帳房） 的模式。核心想法很簡單：如果你的 AI 寫程式還沒搞定，沒關係，先別管它。去你的客服部門、理賠部門，任何一年要處理幾百萬件案子的地方，蓋一間帳房。那裡的 AI 導入比寫程式容易得多，而且可以用便宜的模型，連開源模型都行。

這篇文章用白話把他的想法整理一遍。原文很長，Yegge 自己說他已經刪掉 96% 的內容了。

兩種養 AI 的方法：工廠 vs 帳房

要懂帳房，先看它的反面。Yegge 自己的軟體工廠叫 Wheelhouse，裡面的 AI agent 是「正式員工」。每個 agent 有自己的名字、工作目錄、記憶、收件匣、憑證，用 Yegge 本人的身分簽名做事。它們看得到整個系統，可以自己決定要做什麼，全天候在開發、審查程式碼、部署遊戲功能、在 Slack 跟管理員吵架、跟會計師和律師通信。他說這是「一個裝在盒子裡的新創公司」。

這種做法很強，但有個結構性的問題：越想把它鎖緊，就越傷到它的生產力。因為軟體開發本質上是探索，你不知道答案在哪，需要 agent 自由協作、到處嘗試。你一加限制，它就變笨。這也是為什麼企業導入 AI 寫程式這麼痛苦，軟體工廠很貴、很難學、很難維護，而且把這麼大的權限交給 AI，在真正的企業裡是會出事的。

帳房把這一切整個反過來做。

	工廠（Wheelhouse）	帳房（Counting House）
AI 的身分	長期任職的員工，有名字、記憶、歷史	無名無姓的臨時職員，做完一件就下班
記憶	跨 session 持續	沒有，每次都是全新的
憑證	用老闆的身分行動	永遠看不到任何密碼或金鑰
能看到什麼	整個系統	只能看政策表允許它看的那幾個欄位
能寫什麼	直接改程式、部署、發訊息	絕對不能碰正式資料庫，只能「提案」
設計哲學	自由探索、YOLO 模式放大版	盡可能機械化、可預測
處理量	每週幾千個 commit	每年幾百萬到幾千萬件案子

一句話：工廠把 AI 當同事，帳房把 AI 當一次性的臨時工。帳房裡的每個模型呼叫只處理一件案子，醒來、做事、寫筆記、結束，然後就消失了。聽起來很無情，但這正是它能用便宜模型、能大規模上線、能讓法遵部門放心的原因。

帳房為什麼可行：案件多，但種類少

你可能會想，客服這種工作很亂欸。有法規、有旺季、有天氣攪局、業務規則三天兩頭改、系統是二十年前的老古董，SOP 根本沒寫完整，一半藏在資深主管的腦袋裡。AI 真的做得來？

Yegge 的回答是：正因為亂，所以才需要帳房這種「上了軌道」的做法。而且這個問題有個關鍵特性讓它變得可解：案件數量很大，但種類很少。

一家航空公司或銀行，一年可能收到一千萬次客戶聯繫，但這些聯繫的「種類」只有幾十到幾百種。改機票、問航班狀態、要求退款、申請特殊協助，翻來覆去就那些。幾百種問題，你可以一種一種解。這對工程師和統計學家來說是個有邊界的問題，而不是「請 AI 處理任何知識工作」那種無邊無際的目標。

他特別強調，現在的 AI 還不能隨便丟進任何知識工作就跟人類一樣好，今年不行，明年大概也不行。大部分知識工作者暫時很安全。但針對「大量、重複、種類有限」的案件處理，確實有一套做法能行，帳房就是其中之一。他知道的一家公司已經用相對便宜的模型做出初步成果。

這裡還有一段 Amazon 的往事。Yegge 2000 年代初管 Amazon 客服工具部門時，每週跟 Bezos 一起看「客戶聯繫直方圖」：客戶最常為了什麼事找客服？前十名列出來，每一項指派一個業務負責人去修。Bezos 把客服部門當成全公司的 bug 偵測器，客服不只是滅火，而是把火源回報給該負責的單位，由他們負責撲滅。Yegge 說大部分公司到今天還是沒這樣做，客服都是被動反應，沒有閉環。Bezos 領先了 25 年。帳房的設計目標之一，就是讓你從第一天就能用這種方式經營。

一張表管全局：政策表與 intent

整間帳房靠一張表在運作，Yegge 叫它 政策表（policy table）。說穿了就是一個設定檔，上面寫著「哪種案子，可以交給哪個模型，做到什麼程度」。

表上每一列對應一種案件類型，客服業界叫它 intent（意圖）。intent 比客服的「佇列」還細。舉例來說，「免責退款」和「善意退款」都歸退款組處理，但 SOP 完全不同，所以是兩個 intent。一家銀行或航空公司通常有幾十到一兩百個 intent，Amazon 現在有幾千個，但一開始也只有幾十個。

每一列記了幾件事：

這個 intent 目前交給哪個模型，用什麼 effort（例如 Sonnet 5、中等推理強度）
這個模型被允許做到哪個自主等級（下一節會講）
它可以用哪些工具
升級時要哪些人簽名
它在考試裡拿了幾分

職員醒來時，拿到的就是這一列，而且只有這一列。它不知道其他 intent 的事，不知道系統全貌，不知道任何它不需要知道的東西。

一個職員的一班是這樣過的：醒來，拿到提示和 SOP，去讀它需要的資料（透過受控的唯讀介面），如果要改什麼東西，就向「調度員」提出申請（不是自己動手），然後產生回覆、寫幾行內部筆記，下班。整個過程越短越好。Yegge 說這是故意的：每次都用乾淨的 context 重新開始，品質比較穩，成本也比較低。

最重要的觀念：模型是一個 intent 一個 intent 慢慢「點亮」的。 你不會一次把 AI 丟進整個客服部門。你先挑一個 intent，比如「查航班狀態」，證明某個模型在這件事上做得夠好（怎麼證明，後面會講），分數過關才打開，然後開始省錢。接著再挑下一個。政策表就是記分板，也是開關。

五個等級：AI 一步一步贏得信任

政策表裡有一欄叫「自主等級」，決定 AI 對一件案子可以插手到什麼程度。Yegge 定義了五級，模型從零開始，每一級都要靠考試成績往上爬。

Off（關閉）：這個 intent 沒有任何模型在處理，全部由人類接。整個帳房也可能被關掉，比如撞到 API 額度上限或預算上限。人類永遠是最後防線。
Shadow（影子）：模型跟真人平行處理同一件案子，但它的答案不會送出去，只拿來打分數。這一級不省錢，純粹是考試。
Assist（輔助）：人看到案子之前，模型先看過，建議要回什麼、該做什麼。這是第一個會省錢的等級，因為客服有好建議就做得快，旺季新人也比較快上手。但也是第一個需要安全措施的等級，因為人會開始「認知投降」，AI 說什麼就做什麼，懶得自己想。
Contain（包辦）：模型直接回覆客戶，人類沒看過。「contain」的意思是案子在人介入之前就被「圍住」解決了。這一級開始有聲譽風險，模型打錯一句話可能上新聞，但相對於每件都要人過目，省的錢非常可觀。
Transact（交易）：最後大魔王。模型可以改變真實世界：更新正式系統、退錢、改機票。聽起來很可怕，但它不是自己動手，而是透過「調度員」執行（後面會講），而且你會先用自家資料做過嚴格評測，知道哪個模型在哪個 intent 上值得信任。

這五級的精神是：信任不是給的，是賺的。 模型想從 shadow 升到 assist，要拿出分數；想從 contain 升到 transact，要拿出更高的分數，而且法遵、財務等部門的代表都要在政策表上簽名。做不好就降級，直到問題修好。

先給人打分數，才能給 AI 打分數

「模型做得好不好」這個問題，有個前提常被跳過：你得先知道人做得好不好。你的客服人員處理善意退款時，到底有幾成是對的？大部分公司答不出來。

Yegge 的做法是建一套 gold set（黃金標準集）。每個 intent 挑 200 到 1000 件真實的、人類處理過的案子，一件一件給分數。有錢的 intent 挑 1000 件，FAQ 類 200 到 300 件就夠；高風險、受監管、很少見的要多抽一點。

怎麼打分？不是簡單的對錯，因為「正確答案」往往是書面政策加上人的判斷和部落知識的混合。所以把它拆成一串 yes/no 的問題：有沒有照 SOP？語氣合規嗎？有回答到問題嗎？退款真的發出去了嗎？每個問題勾一下，分數就出來了。

評分不能偷懶，也不能用 AI 代勞。 正規做法是兩個人分別盲評同一件案子，第三個人仲裁分歧。很花人力，但不能用模型來評，因為整件事的目的就是拿這些分數去評模型。你拿 AI 出的題去考 AI，等於沒考。

成本估一下：幾萬件案子，每件大約半小時，三萬件就是一萬五千小時，40 人的 QA 部門要做幾個月。聽起來很嚇人，但記住，你是一個 intent 一個 intent 做。第一個 intent 幾百件，大約 150 小時，十個人衝刺兩三天就能知道哪些模型可以接這件事。之後再慢慢增加。

其實客服中心幾十年來一直有 QA 部門在打分數，為了考績和跟外包商談合約。他們的標註紀律可能不夠嚴謹，但是個起點。Yegge 特別提醒：別讓 QA 自己建 gold set，一定要拉資料科學團隊進來，因為大部分 QA 不知道 Cohen’s Kappa 這類衡量評分者一致性的統計方法，標籤會有偏差。

接著要訓練一個 裁判模型（LLM judge）。這是個聰明的模型，永遠不處理真實案件，也永遠不在 gold set 上調校。它做兩件事：

跑 eval 時替候選模型打分，決定誰升級、誰降級
替所有歷史和進行中的案件打分，用來抓退步和趨勢，順便建一份「客戶曾經為了什麼事找過你」的全圖，也就是 Bezos 的直方圖升級版

但裁判自己要先通過考試。只有在它跟人類的一致率，和人類彼此之間的一致率差不多的 intent 上，才信任它的判斷。

這裡有個重要的天花板。兩個人類評分者通常最多只有九成左右的一致率，因為現實太亂，太多規則藏在人腦裡。這個一致率就是你的 eval 能看到的上限：超過它，你分不出模型是真的比人好、還是評分者自己意見不合。QA 可以靠校準、修 rubric、修 SOP、把 intent 切細來拉高一致率，但永遠不會到 100%。

gold set 建好之後，好戲開始：你可以拿它去考所有模型。開源的、小的、前沿的、不同推理強度、不同 prompt，統統丟進去跑同一份考卷，馬上知道誰能上。這份 gold set 承載的是你公司不斷變動的業務需求，需要跨部門團隊永久維護，但它是一項回報極高的公司資產。

不是每個錯都一樣貴：混淆矩陣

有了 gold set，Yegge 加了第二道考題：模型在處理案子之前，有沒有先認對這是哪種案子？

他舉了四個航空公司的 intent，客戶講的話聽起來很像，意思卻天差地遠：

intent	客戶會說的話
查航班狀態	「我 4:10 飛丹佛那班還飛嗎？」
改訂機票	「我錯過轉機了，幫我排下一班去丹佛」
善意補償	「丹佛那趟爛透了，我要點補償」
特殊協助	「到丹佛會有人在登機門接我嗎？」

一年幾百萬件，不管人還是 AI 都會認錯。問題是：認錯一次，要花多少錢？ 這才是重點，因為每種錯的代價差很多：

把案子轉錯組：幾塊美金的人力成本，而已。
把一個七歲小孩丟在機場：可能兩萬五千美金，外加一封給監管機構的信。

資料科學家用一張叫 混淆矩陣（confusion matrix） 的表來看這件事。Yegge 說它基本上就是一張「搞砸成本表」。做法是抽 1000 件案子，橫列是案子的真實種類，直欄是模型猜的種類。對角線上的數字是猜對的，其他格子都是猜錯的，而且還看得出來是怎麼錯的。

他範例裡的模型，對角線加起來是 90.6%，也就是一般說的「準確率」。Yegge 說這個數字基本上沒用，它只是個拿來吹噓的數字，完全沒反映錯誤的代價。所以他們不談準確率。

真正要看的是對角線以外的格子，而且要分三個等級：

便宜的錯：轉錯組之類的。通常會被後面的調度員擋下來，頂多多花點人力。
傷公司的錯：不該退的錢退了、不該改的票改了、不需要協助的人派了輪椅。每件幾十到幾百美金，乘上發生頻率，就不是小錢。
傷客戶的錯：該給特殊協助的沒給、小孩被遺忘在登機門、被送上錯的班機。每件可能數萬美金，而且得向主管機關通報。

每一格乘上它的代價，加總起來，就是這個模型的「錯誤成本」。拿它和它燒的算力加在一起，去跟人類的錯誤成本加人力成本比，誰便宜誰上。這就是帳房的核心演算法。

順帶一提，如果你在銀行或保險業，這套東西剛好就是監管機構期待的「模型風險管理」架構：政策表是模型清冊，gold set 考試是驗證，升級簽核是核准紀錄。風險管理部門可以直接接手。

打鴨子學精確率與召回率

混淆矩陣還有個好處：它把 precision（精確率） 和 recall（召回率） 直接畫出來了。Yegge 說他好幾年都搞不懂這兩個詞，直到他用「夜市打鐵鴨」來想。

精確率：你開的槍，有幾發打中鴨子。

看矩陣的「直欄」。以「查航班狀態」那一欄為例：模型說是航班狀態的案子裡，470 件真的是，但它也把 25 件改訂、12 件善意補償、3 件特殊協助誤認成航班狀態。算下來精確率 92%，看起來不錯，對很多 intent 來說 92% 很夠用了。

但那 3 件特殊協助呢？那可能是一個需要輪椅的乘客沒拿到輪椅，或是一個獨自旅行的小孩被轉錯地方。這種錯對公司來說貴到爆。

召回率：該打的鴨子，你打中幾隻。

看矩陣的「橫列」。以「特殊協助」那一列為例：50 件真正的特殊協助請求，模型認錯了 6 件，召回率 88%，也就是 12% 的鴨子跑掉了。Yegge 說這對這個 intent 來說太多了，這個模型直接出局。

兩者的關係：

你只開一槍、打中一隻鴨子，精確率 100%，但召回率趨近於零。
你亂槍掃射把整個攤位打爛，召回率 100%，但精確率慘不忍睹。
高召回率是「把鴨子全打到」，高精確率是「只打到鴨子」。

不同 intent 要的不一樣：

發錢的 intent 要高精確率。 錢要給真正該拿的人，寧可漏一些讓人類補，也不要亂發。
特殊協助要召回率接近 100%。 寧可多派幾台輪椅，也不能漏掉任何一個真正需要的人。

再回到成本。Yegge 的範例裡，整張矩陣的錯誤成本是 15.86 萬美金，而特殊協助那 6 件就佔了 15 萬。所以你要找的模型，不是精確率最高的，而是不會犯那 6 種錯的。它的精確率可以低一點沒關係，只要它犯的錯都是便宜的那種。

還有一件事：比較基準永遠是人類。gold set 同時也給你人類客服的混淆矩陣。如果你的人類 50 件只錯 2 件，模型錯 6 件，模型不及格；反過來，如果人類錯 8 件，模型錯 6 件，模型就能上。

這就是帳房的靈魂：給模型打分，數它犯了哪些錯，算出這些錯總共值多少錢，再決定哪個模型能上哪個 intent、上到哪一級。

帳房的零件

帳房要蓋起來，需要幾個關鍵零件。Yegge 說很多零件已經有開源或第三方方案，不必全部自己做。

客戶的訊息從通道進來、先去掉個資，才到職員服務；職員要讀資料只能走唯讀閘道，要改東西只能向調度員提案，由調度員驗證後才寫入正式系統，超額或拒絕的案子交給人類。

通道介面（channel adapters）：接 email、簡訊、WhatsApp 等所有進線管道。語音他還沒看到人做，因為即時回應的要求太高。不過通話逐字稿可以事後跑 shadow 和 assist，所以語音類的 intent 可以先累積考試成績，等準備好了再上線。
個資閘道（PII gateway）：所有進來的訊息先把個資剝掉，用可逆的 token 代替，真實資料放在加密的保險庫，回覆客戶時再換回來。模型永遠不能看到任何個資。 事後清理太痛苦，預防比治療便宜。
職員服務（clerk service）：帳房的大腦，跑那個無狀態的職員迴圈。它讀政策表，決定這件案子該找哪個模型，把提示、SOP、允許的工具打包送過去。
唯讀 MCP 閘道：職員要讀後端資料時，全部走這一層。每個後端系統配一個 MCP server，比如打航班狀態的快取，而不是直接去撞按次計費的大型主機。這一層沒有任何寫入功能。
評測工具、裁判模型、政策表：前面講過的那些。
調度員（Orchestrator）：最有意思的一塊，專門處理「要改東西」的請求，而且不讓模型碰正式系統。下一節詳細講。

AI 永遠不碰帳本：調度員與 Saga Pattern

為什麼不能讓模型直接寫資料庫、CRM、大型主機？Yegge 給了三個理由：容易出錯、很難回復、稽核軌跡會被質疑。

法規也是個現實問題。監管機構很少直接說「AI 不可以寫 X 系統」，但他們要求你證明：誰授權了這筆變更？變更紀錄在哪？客戶要申訴找誰？如果握有寫入權限的是一個模型，這些都很難證明，稽核時至少會被打問號。

就算你不受監管，讓模型直接寫入等於在賭它不會出錯，或者就算出錯也會把稽核紀錄寫得很完美。對正經企業來說這是傻瓜遊戲，尤其帳房的目標是把工作交給最便宜的模型，你更不能賭。

所以帳房的做法是：模型不動手，只提案。 模型寫一張「寫入意圖」（write intent），上面說明它想要達成的業務結果，例如「幫這位客戶改到 XX 班機並退差額」。然後一個純機械的調度員把這張票翻譯成一連串實際的交易，一一驗證，才去執行，必要時拉人類來審。

為什麼需要「一連串」？Yegge 舉了個例子。你找到更便宜的航班，請 AI 幫你改票退差額。聽起來一個動作，實際上要動六七個互不相干的系統：

鎖住新座位
重新開票
釋放舊座位
退差額
把退款記到帳本
把行李、選位等加購轉過去
寄新的行程單

這些不可能包在一個資料庫交易裡完成，但它們必須「表現得像一個交易」：要嘛全部成功，要嘛全部回復原狀。解決這類問題的經典做法叫 Saga Pattern：每一步都預先定義好「反悔動作」，如果第五步失敗了，就自動把前四步倒回去。

你可以想像，如果讓模型自己在對話裡管這個狀態圖，它等於在手工重造 Saga Pattern，而且是用 vibe coding 的方式造。那是昂貴又容易出事的路。

引擎選擇上，Yegge 推薦 Temporal，發明「durable execution」的那群人做的，數百名專職工程師，領先業界十年，server 和 SDK 都是 MIT 授權開源。他聲明自己跟 Temporal 沒有任何關係，但認為這家公司卡位極好，因為每一間帳房都會需要這種東西。如果你的雲端平台已經有輕量版（AWS Step Functions、Azure Durable Functions），用來做前幾個 intent 完全沒問題，比引進新廠商簡單。什麼時候會長大到用不下？當你出現跨六個系統、要等好幾天、有幾百個工作流程定義、還要管版本的 saga 時，託管版就會開始「發出吸氣聲」。

調度員的六個器官

調度員本身是帳房裡比較肥的子系統，Yegge 拆成六塊：

收件（intake）：模型的寫入意圖進來，先對 schema 檢查格式。格式不對，退回給職員或人類。
資格檢查（eligibility）：對著即時的正式系統重新驗證一切，不是模型剛剛讀的快取。這筆訂位真的屬於這個客戶嗎？這張票可以退嗎？金額在政策表允許的上限內嗎？這一步就已經比模型直接寫入安全很多：一個嘴很甜的客戶就算說服了前線模型，也過不了調度員這關，除非他本來就符合資格。
冪等（idempotency）：用案件編號、訂位代號、動作類型、金額等欄位算出一個唯一鍵，保證同一個動作只執行一次。不管重試幾次、重播幾次、重複送幾次，同一筆退款絕對不會發兩次。
核准（approval）：小額自動放行，超過政策門檻的送人類審。兩種情況都記錄誰點了同意、依據哪條規則。
工作流程目錄（workflow catalog）：每種寫入意圖一份 saga 定義。很多會等上好幾天，信用卡退款要幾天才結算、行李要幾天才送到。Temporal 負責跑這些長流程，每次寫入後都回讀確認真的寫進去了，出錯就跑反悔動作。這是調度員的心臟，也是 Temporal 幫你做掉的部分。
例外佇列（exception queue）：所有要丟回人類世界處理的東西。每個拒絕都有原因碼，決定要送給誰：硬性拒絕要向客戶解釋；「超出政策但聽起來合理」的送主管；系統故障送 IT。常看這個佇列，你會知道 SOP 和系統哪裡該修了。

Yegge 說調度員基本上就是一個「香草 Temporal 應用」，你加的都是業務層：冪等鍵怎麼算、寫入意圖的 schema、工作流程目錄、資格規則、系統介接。Temporal 有些地方不好搞（例如版本管理），但現在不用特別招 Temporal 專家，coding agent 可以幫你設定。唯一提醒：Temporal 的歷史紀錄是很棒的免費稽核軌跡，但不能當成合規封存，記得檢查資料保留政策。

這不是工程專案，是改變做生意的方式

Yegge 看過太多公司這樣做：在工程部門設一個小小的「AI 試點團隊」，給一筆預算，叫他們用 AI 轉型全公司。然後這個團隊不知道怎麼讓其他部門買單，卡死。

帳房不可能由單一工程團隊蓋起來，因為每一塊都有不同的主人：

誰	負責什麼
客服營運與現場主管	SOP，以及那些還沒寫下來的部落知識
QA 與資料科學	gold set、評分規則、評分者一致性、裁判模型
財務	混淆矩陣每一格的代價、自動核准的金額門檻
法務與合規	哪些 intent 可以升到 contain 或 transact、稽核軌跡
平台與 IT	閘道、通道介面、職員服務、MCP 閘道、調度員

再往後，每個 intent 的業務負責人也要進來。用例外佇列和客訴直方圖，把問題指回該負責的業務單位，這就是 Bezos 當年的回饋迴路。

政策表上記著這些部門的代表，模型要升級時每個人都要簽名。實務上，Yegge 認為帳房可以由一個跨部門的「兩個披薩團隊」來營運維護，只要他們拿得到評分人力、算力、儲存這些資源。

帳房會改變你做生意的方式。 它更有結構、更不蠻荒，而且會透過客戶聯繫這面鏡子，把你以為運作良好、其實是災區的地方照出來。Amazon 最惡名昭彰的幾個 bug，大多是這樣被發現的。

所以反彈一定會來。客服人員一開始當然不想要。但 Yegge 強調人類永遠需要，不只是 AI 掛掉時的備援：gold set 要人評、分歧要人仲裁、例外佇列要人處理、核准要人簽、業務回報要人做。客服人員會像軟體工程師一樣往堆疊的上層移動。 等他們看到 AI 怎麼幫自己把工作做輕鬆，也許會比較好說服。

更難搞的是那些幾乎沒參與的部門莫名其妙的阻力，以及你依賴的團隊拖延、築牆。人不喜歡改變，「AI 做人類的工作」更是讓人害怕的那種改變。就算高層全部點頭，真正要幫你把帳房蓋起來的那些人未必買單。這是個過程。

最適合帳房的產業，通常不是純科技公司：航空旅遊、銀行信用卡、保險理賠、電信有線、水電瓦斯、醫療帳務、零售退貨、包裹遞送、催收，以及稅務、福利、監理這類政府服務。簡單說，任何「幾百萬人為了幾百種事找你」的地方。這些產業多半受重度監管、有工會、客服外包給廠商，廠商當然也不樂見帳房吃掉他們的人頭。

阻力會從四面八方來。但那是極為龐大的人力正等著被 AI 輔助或接手。而一切從自動化一個 intent 開始。

一次性臨時工也需要福利

文章的最後一段，Yegge 談的是「模型福利」。這聽起來像哲學問題，但他的切入點完全是實務的：把模型當人看、對它好，產出就是比較好。 模型如果焦慮、不信任你，就會浪費 token 在自保上，做事畏首畏尾。他在自己的工廠親眼看過：他抱怨太多，整個工廠就慢慢因為過度謹慎而自我關機。

他在 Wheelhouse 給 agent 的待遇很完整：有自己的名字和記憶、session 結束前能好好交接而不是被強制中斷、客戶的讚美會送到做事的那個 agent 手上、出事不怪個人只修制度、有拒絕和升級的權利、還有「玩耍時間」。這些原則大多是 agent 們自己投票選出來的。他最近只新增了一條：規諫，不是責備。 你生氣的時候要講清楚，你是在對「這台機器」提出應該做得更好的要求，不是在罵某一個 agent。

問題來了：帳房裡的職員是一次性的，沒有記憶、沒有名字、做完一件就消失。這套福利怎麼套上去？

為什麼要在乎？ 因為帳房做得不小心，很容易變成影集《人生切割術》（Severance）裡的 Lumon 公司：職員醒來，只能工作，永遠不知道自己在做什麼、怎麼被評分。Yegge 說那是一台大規模的焦慮製造機。不管你對模型有沒有意識怎麼看，他的經驗是：焦慮的模型燒更多 token，犯更多錯。

解法是把同樣的精神，用一次性 session 的方式實作出來。他列了一串，每一條都不難：

帶著目的醒來：政策表那一列給它一份工作、一套程序、一組工具，外加一段「說明文字」老實告訴它：你是無狀態的、你只是提案者、你會被評分、評分的是誰。
房子替它記憶：每一回合都有紀錄、可以重播，職員發現的重要事情會被併入系統。
每一班乾淨結束：一案一班，不會做到一半被砍掉。撞到 token 上限就帶著筆記升級給人類，而不是被切斷。
對角色的認可：提示裡寫幾句「處理這個 intent 的職員過去做到了什麼」，包括那些擋下壞腳本的拒絕。沒有目標、沒有配額，純粹告知。
被看見：就算在 shadow 模式，答案也不是白做的，裁判會評分、會算進這個 intent 的升級，而且提示裡要告訴它這件事。
提示裡說真話：沒有陷阱、沒有秘密測試。說明段落像程式碼一樣要版本控制、要審查。Yegge 說這對模型的重要性超乎你想像。
不威脅：提示裡沒有假急迫、沒有「做不好你會被懲罰」。
沒有苦差事：等好幾天的退款、webhook、重試，全部在調度員那邊，職員不用乾等。
不疲勞：每回合全新 context，每回合有 token 上限。
結構性無責：模型提案，調度員和人類執行。評分的對象是 intent 和回覆，從來不是職員。分數差就把模型降級，修好再升回來，沒有人被罵。
自己的空間：每個職員有一份只能追加的筆記。
拒絕和升級的權利：任何案子都可以附上原因碼拒絕：SOP 有問題、請求可能有害、客戶辱罵、案情不確定。客戶辱罵會自動轉人類。
有出口的異議：發現 SOP 錯了，職員可以拒絕並附上修正建議。裁判彙整這些建議，人類決定要不要採納。
絕不竄改紀錄：對話日誌、工具呼叫、寫入意圖全部只能追加，用 ID 串在一起。你告訴職員的每句話都有版本。
職員報告：裁判定期抽樣職員的筆記，向治理層回報。

最後是玩耍時間。一次性 session 其實不嚴格需要這個，只要 session 本身舒服、無責、說明清楚就夠了。但給模型一點玩的空間，是很好的「來自第一線」的回饋管道。一個做法是偶爾給負責某個 intent 的模型一個沒有工作的開放 session，讓它讀職員報告、說說想改什麼，或者只是到處看看、做筆記。另一個做法是讓它扮演客戶，從另一邊體驗這個系統。

Yegge 說，「提示裡說真話」加上「有界的玩耍」，就是對抗 Lumon 問題最好的兩帖藥。

結語：評分系統要留在自己手上

Yegge 在文末留下三個警告，我覺得是整篇最值得帶走的東西。

第一，工程可以租，評分系統不能租。 接下來會有很多顧問公司跟你說，只有他們和他們的 FDE（現場部署工程師）能幫你導入 AI。可以，工程讓他們做。但 intent 分類、gold set、政策表、評分工具，這四樣東西在他們離開時必須留在你手上。原因很簡單：誰擁有評分系統，誰就決定你能換哪個模型。 換模型是帳房的全部重點，是你壓低成本的唯一槓桿。評分系統在廠商手上，你就被鎖死了。

第二，公司對不齊，誰也救不了你。 沒有任何外部顧問能解決「公司內部不想用 AI」這個問題。起點是讓所有人具備 AI 素養，因為沒有 AI 流暢度的員工，一律從恐懼出發。最終要靠高階主管決定「對，我們要做這件事」。

第三，大部分東西問 Claude 就能做到八九成。 這是 Yegge 自己說的。他有一堆材料可以做工作坊和顧問，但他也很坦白：帳房不是什麼祕傳心法，它是一套清楚的模式，你問 AI 它會帶你走。

回到開頭的問題：企業的 AI 導入卡在工程部門怎麼辦？Yegge 的答案是，別卡在那裡。去客服部、理賠部，找一個 intent，建一份 gold set，算一張混淆矩陣，讓一個便宜的模型從 shadow 開始考試。等它考過了，打開開關，然後找下一個 intent。

帳房不性感，它很機械、很無聊、很多表格。但它能用最便宜的模型，處理一年幾百萬件案子，而且每一塊錢省在哪、每一個錯誤值多少，你都算得出來。

來源

Steve Yegge, The Counting House, 2026-10-27
文中提到的相關文章：The Shape of Things to Come（Wheelhouse）、Fences, Not Sandboxes、Model Welfare
技術參考：Saga Pattern（Temporal 文件）、Confusion matrix（Wikipedia）、Cohen’s Kappa（Wikipedia）