沒辦法嘲笑「漂亮手法」的故事

前幾天，我偶然看到隔壁座位年輕工程師的畫面，手就停住了。

出現錯誤。
複製。
貼給 AI。
把回傳的程式碼貼回去。
能跑了。接下一個任務。

大概就是這樣，來回幾次，總共約 3 秒。漂亮，真的很漂亮。
但是，他本人一次都沒有讀過錯誤訊息。

我不是想談「現在的年輕人」怎樣。重點從這裡開始。

當天下午，我自己的畫面也出現了不熟悉的錯誤。和平常一樣，我正要丟給 AI，忽然停手，想試著靠自己讀看看。

讀不懂。

更精確地說，在我開始讀之前，「丟給 AI 就好了」的念頭插進來了，於是我已經無法像幾年前那樣，從上往下追著堆疊追蹤（stack trace）看完。那本來應該是理所當然能做到的事，現在卻做不到了。

看到年輕工程師的畫面時，我背脊一陣發涼，是因為那根本就是我自己的樣子。

回到主管的立場，還有更糟的問題等著我。在績效面談時，當我想談「他的實力」時，卻找不到可依據的東西。成果是 AI 寫的。速度是 AI 產生的。提交紀錄是和 AI 的共同作品。我能說的，說實話只剩下「感覺」。

因為放不下這種違和感，我和夥伴一起做了產品。這篇文章就是介紹它。

這篇文章發出後，收到了經營層、經理、工程師等許多回饋，也讓我們知道有很多人有類似的課題感。未來不只想用在開發，也會考慮更廣泛的使用場景。

正在發生的事 — AI 讓開發變快，也讓實力變得看不見

生成式 AI 確實讓開發速度變快了。另一方面，我感覺有股逆流正在悄悄發生。

先從個人層面說起。

• 出現錯誤就貼給 AI，拿修正程式碼
• 能跑了就往下個任務走。至於為什麼壞、為什麼修好，仍然不知道
• 下一次還是卡在同一個地方。而且本人也隱隱約約知道這不太妙

我覺得最後這點最重要。做產品時，我去訪談年輕工程師，發現他們對「沒有 AI 就解不出錯誤的自己」這件事的不安，比我想像中更普遍。但在交期面前，優先順序一定是先解決，而不是先學習。這不是靠個人意志就能解決的問題。

而且這不只是年輕人的課題。訪談中，主管和人資雖然立場不同，但也都說出了同樣的問題。

組織層面會以 3 種形式反撲回來。

#組織層面會發生的事1成員的實力看不見。 因為 AI 讓成果物有了加成，無法只靠產出來衡量基本功2培育變得高度依賴個人。 會教「怎麼看錯誤訊息」的人，往往只有少數資深工程師3評估依據變成主觀。 技術力評價容易依賴印象和自我申報「不要依賴 AI」講起來很簡單。但如果不能靠本人意志，也不能靠組織號令，那就只能用機制來解。

所以，我們反過來想了。

發想反轉 — 不是讓 AI 給答案，而是讓 AI 出問題

我們做的是一個叫做 SocraMetry（ソクラメトリー） 的 Web 服務。

一句話來說，這是一個丟出錯誤後，不回答案而是回「問題」的 AI 導師。

AI 其實在內部已經把原因找出來了。找出來之後，不說。 介面看起來像聊天，但沒有讓使用者自由提問的欄位。使用者能做的，只有丟出錯誤、選擇選項，以及用自己的話宣告原因。從結構上封住了「問 AI 就好」這條退路。

這就是這個產品必須是 AI 的理由。對眼前的每個錯誤，先在內部判定原因，再即時產生「不碰答案的問題」——這不是固定教材或 FAQ 能做到的；如果每次都要有看得懂原因的前輩全程陪著，也本末倒置。必須是知道答案、卻不說出口的對象。這件事只有 LLM 做得到。

名稱的由來也很直白，Socrates（蘇格拉底式問答）+ Metrics（評量指標）。把蘇格拉底那種不直接給答案、而是用提問引導的對話法，和對話歷程——提示依賴度、思考過程、解決時間——轉成評估資料，這兩個功能一起收進了名字裡。

請看實際互動

與其說明，不如直接體驗。下面是把常見錯誤丟進去時，實際的對話流程。

重點是，AI 一次都沒有直接說答案。丟出錯誤的工程師，是靠提示和題目，一步一步自己找到原因的。

實際體驗後就會知道，被告知答案，和自己察覺答案，記憶留下來的方式完全不同。而且下一次再看到同樣類型的錯誤時，第一眼會注意的地方也會改變。

「不教答案，怎麼可能拿來工作？」的回應

你是不是第一時間也這樣想？我一開始也是這麼想的。如果卡住就導致工作停擺，根本沒人會用。沒人用的工具，不可能拿來學習或評估。

所以我們不是把答案永遠藏起來，而是設計成在使用者嘗試到一定程度之後才開放的 3 階段流程。

走到底一定能拿到答案。工作不會停。 為了救那些卡住卻不會自己往前推的人，從提示階段（Gate A）到題目階段（Gate B），只要時間到了就會自動往前。越是不會自己說「我要往前」，就越容易把卡住的狀況吞下去。不過，會記錄是在哪個 Gate 解決、用了多少提示。開放答案不是失敗，而是「正確落點之一」；同時只保留一個很直觀的激勵：越不靠提示與引導解出來，評價越高。

「在 AI 時代，還需要除錯能力嗎？」的回答

再來，還有一個一定會出現的反對意見，我先回應。

AI 越來越聰明了，人類還需要看懂錯誤嗎？
這不就像電腦出來之後還要練心算一樣嗎？

我同意一半。未來大部分制式錯誤，AI 很可能會比人更準確地處理掉。即便如此，理由還有 3 個。

#仍然需要的理由1如果沒有人能驗證 AI 的修正建議，上線時就會卡死。
「看起來能動」和「真的正確」是兩回事，而辨別這件事本身就是除錯能力。整個團隊如果都放掉這能力，就會在無法審查 AI 輸出的情況下直接釋出2AI 解不出來的錯誤，才會變成人類的工作。
AI 越擅長處理制式問題，人類接手的就越是非典型難題，要求反而更高3觀察 → 切分 → 假設 → 驗證 這個流程，同樣適用於指揮 AI。
除錯思維不是會消失的能力，而是把 AI 當工具用好的基礎如果用心算來比喻，我們真正要鍛鍊的不是大位數乘法，而是「這個計算結果，位數看起來對嗎？」的敏感度。即使有電算機，這種能力仍然一直有用。

要測什麼 — 除錯腦分數

回到開頭那個問題：「看不見實力」。

SocraMetry 不只是問答而已。它把熟練者無意識在做的除錯流程拆成 5 個階段，並從對話紀錄中分別測量。

軸｜測量什麼｜問題例子
---|---|---
觀察 | 是否能準確讀懂錯誤 | 「這個訊息是在說哪個東西是 undefined？」
切分 | 是否能縮小問題範圍 | 「錯誤發生前，你改了哪個檔案？」
假設 | 是否能推論原因 | 「那個變數，是從哪裡來的？」
驗證 | 是否能驗證假設 | 「要確認的話，先印出什麼？」
修正 | 是否能選擇不會再犯的修法 | 「為了避免再發生，你要在哪裡加什麼？」

重點不是說「技術力高 / 低」，而是要能進一步說成「觀察很強，但驗證較弱」。這樣培育負責人就知道該教誰什麼，當事人也知道自己該往哪裡補強。

這裡有一個必須老實說的限制。最高層級的到達——只靠提示就自行解決的情況——5 個軸都會變成同一個值。 因為根本沒有做題，沒有可供軸向差異判斷的資料。這不是實作缺陷，而是「不讓他做題、直接靠自己解決」被設計成最佳結果之後，必然產生的結構性結果。如果為了測量而強迫他作答，就會失去自主解決的價值。所以在 v0.1，我們不隱藏這件事：自力解決時的 5 軸會明確標示為參考值，而且不納入成長率計算。

「這不就是監控工具嗎？」的回應

站在被測量的一方，可能會很不舒服。工程師對測量工具抱有警戒心是合理的，而且指標一旦拿來評估就會失真（Goodhart 定律）。正因如此，我們從一開始就把讓被測量者不吃虧的設計放進去了。

• 任何計算依據，使用者都能隨時查看。 不只給總分，禁止出現無法說明的數值拿來評估人
• 主要指標看成長率，不看絕對值。 如果指標會讓經驗年數直接變成排名，那對年輕工程師來說就是「怎麼努力都翻不了盤」的指標，最後一定沒人用
• 不預設做排名。 預設的呈現方式是「看見成長」。我們刻意不做會自動串接人事系統的功能

另外，Gate C 的開放扣分也刻意設得很小。如果把開放當成懲罰，使用者卡住時就會直接去問 AI，學習和測量都無法成立。會讓使用者吃虧的設計，最後一定會被繞過——這是整個產品的設計原則。

技術面 — 「不說答案的 AI」怎麼做？

接下來才是重點（畢竟我是工程師）。

課題：LLM 再怎麼交代，也不會老實保密

如果叫 LLM 一次完成「找出原因、但不要直接說答案、只要用提問引導」，一定會漏。它會先說出像「看起來是某個變數變成 undefined 了，接著…」這種前言，等於先把答案說掉。就算提示詞再怎麼調，總有一天還是會漏。

所以我們不再用機率去防，而是改用結構去防。

解法：讓出題者不知道答案

我們把 LLM 拆成兩段式，分角色處理。

第一段 Diagnoser 負責判定原因，第二段 Questioner 只拿到「應該讓使用者注意哪裡」這件事。出題端根本不知道答案，所以不可能洩漏。

另外，為了保險，回傳給使用者前還會經過一個叫做 LeakGuard 的洩漏檢查。這一段刻意不用 LLM，而是用決定性規則實作。因為如果再叫 LLM 來判斷「有沒有洩漏」，那檢查本身也會變成機率性的。

在哪裡用 AI、在哪裡不用 AI——例如遮蔽敏感資訊是在送進 LLM 前處理，所以用正規表示式；分數計算需要可重現性，所以用純函式——這是貫穿整個產品的一致方針。

這個結構，直接變成成本設計

有趣的是，這種兩段式設計，同時解決了答案洩漏防護與成本最佳化。

這個服務在一個 session 會呼叫 LLM 10～15 次。內部有很明顯的偏重分布。

困難的處理只有 1 次，簡單的處理卻很多。那就把高品質模型留給那 1 次，其他部分交給便宜模型即可。

這裡派上用場的是我們採用的 LLM Gateway：OrcaRouter。OrcaRouter 是一個以 OpenAI 相容 API 提供多家模型的 Gateway，只要改 model 參數，就能跨不同供應商切換模型。客戶端維持一份，幾乎零成本就能做到依角色路由。

不過「全部都用便宜模型」也不行。Diagnoser 精度一掉，著眼點就會偏掉，後面所有出題都會失去意義。

最有效的不是「變便宜」，而是找出哪些地方可以便宜。
從次數 × 單價來看，該投資哪裡、該削減哪裡，會自動浮現。

而且這種切分也同時是品質設計。診斷每個 session 只執行一次並保存，不會重新診斷。因為每次都重跑，對原因的判斷就會飄移，題目的一致性也會壞掉。成本與品質能用同一個設計一起成立，這是做起來最舒服的瞬間之一。

實測後，和試算不一樣了（老實寫）

設計時原本估算，透過分流應該可以節省 74%。因為我們一開始就建立了「按請求單位記錄所有 LLM 呼叫」的機制（現在也會在 session 結束時的結果卡片上顯示這一輪的實測成本），所以直接用實際 LLM 跑完驗算後——

結果只有 45%。數字變小的原因其實很有意思，因為我們原本以為要省的部分（出題生成）比想像中便宜很多。實測顯示，每一題出題大約只要 0.043 日圓。整個 session 只有 3.4% 的成本在這裡，96% 的成本都花在高品質模型的 3 個角色（診斷、說明、回顧）。要省的地方本來就很小，節省額自然也不會大。這只是很普通的算術。

另外，在使用者卡住、題目一直往下解的情況下，削減率會提升到 68%。削減率取決於使用者解了幾題，所以不能只用單一數字來描述——這是實測後更準確的說法。

還有一點，這個「實測」不只是應用程式裡的推估。我們把單價表乘上 token 數得到的預估值，和 OrcaRouter 的實際帳單（credit 消耗）對照，確認誤差只有 6%（包含顯示解析度在內，最多 11%）。不是相信單價表，而是拿帳單對答案——既然要把數字拿出來，就應該做到這一步，這才配叫「實測」。

實測中發現，最有趣的結構

看著計量紀錄時，我注意到這件事。

成本不是由「用了多少」決定，而是由「啟動幾次」決定。

開始一個 session 的當下，約 4.2 日圓的成本就已經確定（診斷與回顧一定會跑）；就算解 100 題，也只會再增加+4.3 日圓。在實測中，只用提示就立刻解決的 session（約 4.9 日圓）與經過題目、看完說明的 session（約 6.8 日圓）之間，也只差了大約 2 日圓。

也就是說，使用者就算想很久，原價也幾乎不會變。對一個重視「讓人好好思考」的產品來說，思考時間不會大幅拉高成本的結構，雖然不是刻意設計出來的，卻意外地非常適合。

資安做得低調，但要確實

雖然寫起來很不起眼，但這是承接業務錯誤文字的服務，所以還是有做。

• API 金鑰只放在伺服器環境變數。 前端不直接打 LLM，全部統一透過 OrcaRouter
• 敏感資訊在送進 LLM 前先遮蔽（如前所述，這裡不用 LLM）。而且遮蔽結果會在送出前先顯示給使用者預覽。我特別在意的一點是，預覽時沒有把正規表示式再重寫到前端，而是直接讓瀏覽器和伺服器共用同一個遮蔽純函式。只要兩邊實作有一點偏差，就會變成「畫面上看不到，但送到伺服器的是原文」這種比不顯示還糟的情況。為了這件事，我原本打算不使用 bundler 的前端，最後還是加了一個。順帶一提，因為是以正規表示式為基礎，還是可能有無法遮住的專有名詞。所以才需要送出前預覽，讓使用者自己確認並手動修改
• 組織專屬的排除字典不發到 client 端，避免瀏覽器讀出正在處理哪家公司
• Log 不留 PII。 錯誤內容不寫進 log，只記錄 token 數與角色
• 不直接相信 LLM 的輸出。 產生的文字一定先過 LeakGuard（前述、不用 LLM 的決定性檢查），才會顯示到畫面上。為了防止答案外洩而設的關卡，也順便成了「不要未經檢查就把 AI 輸出給人看」的最後防線

誰會怎麼用 — 從使用情境來看

一邊做一邊越來越清楚，這個產品看起來像個人學習工具，但組織端的價值反而更大。下面整理我們預想的使用方式。
（其中一部分包含 v0.2 之後的構想。）

個人與培育負責人 — 訓練能在日常中運轉，處方也能個別化

對個人而言，只要把工作中遇到的錯誤直接丟進去，就能在不拖延交期的情況下，把「讀懂錯誤」的訓練融入日常。對培育負責人而言，系統可以看出像「觀察很強，但驗證較弱」這種細節，因此不必全員上同一套課，而能做個別化處方，也能把少數資深工程師的時間用在最有效的地方。

【培育負責人、主管、人資可以查看的組織儀表板示意】

組織 — 可視化實力，並把知識變成資產

我們為組織設計了 4 種價值。

#價值內容1個人相對評估用同一把尺量出來的 5 軸與成長率，可以讓成員之間的比較不再只是印象，而是資料。不過前面提到的不做排名原則，在這裡也不變。比較不是拿來排位，而是拿來決定培育資源該投在哪裡2對外的能力定位當作 SaaS 使用的組織越多，未來就越能透過匿名分布比較，知道「我們家的三年級工程師大概落在哪裡」（構想）3知識資產化把實務中發生的錯誤問答 session 匿名化、通用化後，累積成公司內部題庫。用得越多，越能把這家組織自己的卡點沉澱成資產。這是外部通用教材絕對做不出來的4解決實績紀錄因為 session 一開始就有記錄語言／框架背景，所以會留下「是哪個框架、解了什麼問題」這樣的歷史紀錄

SES／派遣 — 幫履歷表補上實績證明

我認為第 4 點在這裡最有感。做工程師提案的業務現場，提案方和接收方都知道履歷表上一行「React：3 年經驗」其實沒說什麼。SocraMetry 的紀錄就可以說到「曾經不靠提示，自行解決 React 非同步處理造成的問題」。不是看做了幾年，而是看解決過什麼，這無論是提案說服力還是議價能力，完全是不同層級。

訓練 — 昨天的障礙，變成今天的演練題

知識資產化（上面的第 3 點）還有後續。累積下來的 session 不只是讀完就算的事後檢討資料，而是會以可解的題目形式留下來。在演練模式（v0.2）裡，培育負責人可以從題庫派發 session，新人則用和實務完全一樣的 3 關問答來解題。因為題材全部都是真正發生在「我們公司」的事情，所以訓練和實務之間幾乎沒有距離。

【從知識庫產生的訓練畫面示意】

那，這能賣嗎？

我認為可以。更準確地說，我們先把能賣的形狀設計出來了。

上面那套分流設計後，LLM 原價換算成每人每月 39～55 日圓（以實測為基礎，按每週使用 2 次、每個 session 4.9～6.8 日圓估算。之所以要用區間，是因為不同 Gate 解出時，原價會差 40%）。我們正在驗證 B2B SaaS 每人每月 1,000～2,000 日圓的定價帶，但以這樣的成本結構來看，完全做得到。考量企業本來就會在工程師培育與評估上花很多錢（資深工時、外訓、評估制度運營），替代空間很夠。

「如果是要讓大家天天用，那不是越成功、原價越高、毛利越低嗎？」——這是團隊 QA 提出的問題。結構上確實如此，但哪裡會變成問題，可以用實測說明。若月費設 1,000 日圓，損益平衡點是每人每月146 個 session——是預期使用量（每週 2 次）的 18 倍。我們希望透過「日常化」增加的是每個 session 的深度使用，而這一部分就算解 100 題，也只會多 +4.3 日圓。真正會增加成本的只有開始次數，所以 v0.2 會加上日／週上限。

因為成本是由 session 開始次數決定的（前面也提過），所以能守住價格的閥門也只有一個：session 開始速率上限。實際上，token 上限在實測中只用了不到 20%，根本沒發揮防波堤作用。要守住成本，該鎖哪個閥門，是用實測找出來的——我認為價格設計就是這種一層一層把事情做實的工作。

而且如前面所說，這個結構會讓使用越久，該組織專屬的知識與實績資料就越多。會把資料變成資產的服務，通常越用越難離開。加上成本結構，這就是我認為它能作為 SaaS 成立的原因。

結尾前，聊聊基礎架構與使用到的服務

enebular

基礎架構是 enebular 的雲端執行環境。我們把用 TypeScript 寫的後端打成 ZIP 上傳，就能以無伺服器方式運作。所有東西都部署在這裡。

• API 和畫面都從同一個函式提供。 前端靜態檔案也由函式回傳（同源），所以部署點只剩一個，CORS 和 Cookie 設定也一起消失了
• 資料放在 enebular data store。 沒另外架 DB。而且「AI 在內部找出的原因（也就是答案）」絕不會放進 API 回應，只會存到隔離的資料表裡。不說答案的 AI，它的答案存放處就在這裡
• 部署流程用 GitHub Actions 搭配 enebular CLI 自動化。 push 後會建置 ZIP，@uhuru/enebular-cli 直接替換執行環境。從 merge 到幾分鐘內，staging 就能跑起真實 LLM 環境

目前的系統架構大致如下。
（因為是短期間內做概念驗證，所以採用了比較簡化的架構）

有趣的是，平台限制反而讓設計更好了。雲端執行環境不支援串流回應，所以我們放棄原本打算用的 SSE，把耗時的診斷（實測約 21 秒）拆成另一個 request。結果形成的「診斷只跑一次並保存、不再重跑」結構，正如前面提到的，是成本和品質的關鍵。enebular 的 data store 也是沒有 JOIN 和聚合的 Key-Value store，所以我們只能從存取模式出發設計 key，把一個 session 收斂成少數幾筆 item。限制不是讓事情變複雜，而是幫我們縮小選擇，讓設計更快。

整體流程是這樣。

OrcaRouter

這次是第一次使用，所以我用實測來講感想。
先說，實際上有 3 個很有感的地方。

1. 可以用 1 個客戶端，操作 3 家供應商的模型。 高品質模型用 Anthropic、便宜的用 OpenAI、備援用 Google，能分別從不同供應商挑最適合的模型。API 金鑰也只要管理一份。正如本文所說，依角色路由這個核心設計，能只靠改 model 就成立，就是因為它
2. 因為對 token 沒有加價，所以帳單對得起來。 文章中提到「單價表 × token 數與實際帳單差 6%」的驗證，能成立就是因為 gateway 沒有偷偷改價格。能寫出一篇靠實測講成本的文章，老實說底層就是靠這點
3. 可以追蹤 credit 消耗，和自己的紀錄比對。 之所以能找出「1 個 session 的原價看起來只剩一半」這種混亂的原因（混入 MOCK session），是因為有一個不會動的帳單基準

雖然這次沒用到，但我已經很明確知道下次想用哪些功能了。

• Prompt Caching — 下一版預計的演練模式是「同樣的診斷、同樣的題目」由整個組織一起解，這種結構最適合快取。下一階段的 LLM 成本優化，這應該會是主力
• 預算上限與範圍限定 API 金鑰 — 前面說過，守成本的閥門是 session 開始速率上限這一條，但如果平台也能再加一層預算上限，就會變成雙重防線。想和 v0.2 的日／週上限一起用
• 自動路由 — 這次為了保持診斷一致性而採角色固定分流，但出題端（那 10 次以上的低成本部分）我很想實驗看看「自動分給最適合這段 prompt 的模型」

老實說，一開始對要用新服務還是有技術面和經驗上的疑慮，但因為 API 相容，所以實際導入得很順。

結語 — 這是「要讓 AI 不做什麼」的設計時代

很多 AI 產品都在比「要讓 AI 做什麼」。但這次自己做下來後，我更確信未來 AI 產品的差異化，也在於「要讓 AI 不做什麼」的設計。

• 讓知道答案的 AI，不要說答案（靠結構）
• 在檢查與評分上，不要用 AI（為了確定性）
• 只有在需要高精度的地方，才呼叫高階模型（依次數 × 單價）

而且這個「不要」，不是用 prompt 去拜託 AI 配合而已。讓出題者不知道答案、不讓 LLM 參與檢查、只把高品質模型放在需要精度的地方——禁止不是靠約定，而是靠結構實作。這是我這次學到最多的事。

SocraMetry 是一個透過從 AI 手中拿走答案，讓 AI 時代裡看不見的工程師實力，重新變得可見的產品。

最後，也把開頭那兩個問題留給你。

下次出現錯誤時，你有自信在貼給 AI 之前，自己先讀懂嗎？

如果你是帶團隊的人——
你現在能不能用資料，說明成員能不能自己讀懂錯誤？

這個產品是我們 2 人團隊在 AI HACK 2026 這個黑客松中做出來的。
一開始提出課題時我們意見就很一致，因此做出了 SocraMetry，作為解決組織、工程經理與年輕工程師課題的服務。
黑客松只有 9 天，時間很短，但我想類似的課題感應該很多。如果能獲得一定程度的支持，我們也想持續開發下去。

服務介紹影片：https://youtu.be/fyF0V7fPG0U
Repository：https://github.com/junichikatsu/SocraMetry
服務網址：https://lcdp003.enebular.com/socrametry/
※ 使用需要邀請碼。內容請參考介紹影片

原文出處：https://qiita.com/jksoft/items/65f7824679ddf171a93d