八把鑰匙 — 一把沒有上鎖的鎖

2026 年 8 月 9 日 – 8 月 18 日

十天，四百多個改動。我們要求系統回答十件事，它從頭到尾只回答八件。追查下去，問題不在它聽不懂——我們以為自己掛上了一把鎖，但在其中一條路上，那把鎖根本沒有上鎖，而且它安靜地假裝鎖上了。這一章沒有更動教練說過的任何一個字，卻決定了後面每一章能不能被相信。

核心啟發

你寫下來的要求，不等於成立的契約。契約要成立只有一個條件：你真的去看對方交回了什麼，而且你們兩個看到的是同一幅畫面。少了這個動作，你手上握著的不是要求，是願望——而願望沒有辦法驗收。

觀｜思維

Reynolds 談「想要的結果」時，把標準訂得很硬：

「Coach them to paint the observable picture of what they yearn for that you can both agree on.」

（引導他們描繪出那幅他們所渴望的、可被觀察的畫面——一幅你們兩人都能共同認可的畫面。）

注意這裡同時有兩個條件：可被觀察，以及兩人都能同意。只有一個人看得見的畫面不算數；兩個人各說各話、點頭帶過的也不算數。教練的工作不是「聽懂客戶想要什麼」，而是陪他一起把渴望畫到兩個人都能指著同一處說「就是這個」。書上接著補了一句更不客氣的話：在畫面清楚之前，不要假設你知道他要什麼。

這句話在這一章裡，指的對象不是客戶，是我們自己。

我們對系統下了一份要求清單，卻從來沒有真的坐下來看它交回什麼。我們以為「寫在指示裡」就等於「要求成立」。這裡藏著一個很容易被忽略的陷阱：當對方交回來的答案看起來很合理，你就不會去檢查它少了什麼。而少掉的那幾項，正是後來所有測量都會歪掉的地方。

為｜實務與實現

第一幕：它交回八件事，而且每次都是同八件。 這一章的起點，是一次再普通不過的抱怨：系統的判讀結果，偶爾會少幾個欄位。於是我們把它每一次的判讀記錄攤開，逐欄盤點。盤點的結果比抱怨難看：那份要求清單其實是兩套八欄位的聯集，合起來十欄；而系統穩定交回的，是其中六欄，加上另外兩欄，等於八欄。剩下兩欄——一欄描述議題類型，一欄描述情緒強度——在十二次盤點裡，一次都沒有出現過。

換句話說，它不是在「答錯」，它是在照著自己的一套八欄規矩答。而我們手上的清單比它實際在做的事多了兩欄。

第二幕：先問哪些欄位真的承重。 接下來的動作，是這一章最關鍵、也最不浪漫的一步。我們沒有急著把系統調成十欄，而是先問：這十欄裡，後續流程真的會讀的有哪幾欄？答案把清單劈成三層。第一層是四個當場決定走向的欄位，缺了會直接影響下一次回應；第二層是兩個共同決定要看哪一層的欄位，缺了會安靜地退回預設值——不是壞掉，是悄悄地改用一個沒人選過的值；第三層是純粹的觀測欄位，只寫進紀錄，不影響行為。另外還有兩個欄位，只有在一個特定的開關被打開時才生效，預設關閉。

於是一個原本聽起來很嚇人的結論出現了：真正該被鎖住的，不是那份十欄清單，而是「八欄的底座，加上一組有條件的延伸」。 如果我們直接把十欄當成契約去鎖，我們鎖住的是一個從來不存在的東西——而且會把「安靜退回預設值」這個真實的毛病，連同假契約一起固定下來。

第三幕：一把沒有上鎖的鎖。 有了清單，下一步是讓要求真的成立。做法很直覺：既然模型常常少給欄位，那就交給它一份欄位規格，讓它只能在規格內作答。我們在三道題目上試了三種掛法：不掛規格、掛一個寬鬆的格式要求、掛一份完整的規格。三種掛法、九組題目，全都交出了格式合法的結果——但精確命中的欄位數，三種掛法都是零。

真正的發現還在後面。複查時我們逐一檢查那些「應該要生效」的機制，發現其中一個路徑上的規格要求被整個忽略：模型依然只給六欄，依然沒有任何錯誤訊息，一切看起來正常。更精確地說，在那條路上，「一定要有八欄」這個要求從未被執行——包括一個號稱能鎖住「至少要有八個欄位」的設定，以及一份完整的語法遮罩，都攔不住它。它照樣交出六欄，而且回報成功。

這一幕值得停下來看久一點。我們掛鎖的動作做對了，鎖的位置卻在門的另一側。 系統沒有說謊，它只是從來沒有被真正要求過；而我們因為看到「流程正常結束」，就以為鎖已經上好了。這是整個專案最常見的一種故障：不是東西壞了，是它安靜地沒有作用，而沒有任何一處會告訴你。

第四幕：換一條路，同一顆心。 既然那一條路根本不執行規則，就把同一顆模型、同一份要求、同一組題目，換到另一條會真正執行規則的路徑上重跑。結果是十二次全部精確命中。接著再把正式環境裡的實際形狀原封不動搬過來，仍然是十二次全部命中——先前在舊路上「怎麼弄都只有六欄」的現象，一次都沒有出現。

同一顆心、同一份指示、同一組題目，唯一的差別是這次的鎖真的鎖上了。所以那兩欄從來沒有出現過，不是能力問題，是要求從未成立。如果我們當時急著「訓練它學會那兩欄」，就是把一個契約問題誤判成能力問題，然後花幾週去修一個不存在的缺陷。

同一段時間的其餘四件事。 這十天不只做這件事。我們把量測的日常管線接上（每週固定產出一份自己的健康報告，讓「這週的證據到齊了嗎」變成一份可查的表）；把一個長期掛在旁邊觀察的評分器正式常態啟用；把自動化檢查從外部服務搬回自己的機器，讓每一次改動都能被獨立跑一遍；也順手清掉一個讓系統在告別時機上說錯話的老缺口。這些看似無關，其實都在做同一件事：縮短「我們以為的」與「實際發生的」之間的距離。

會談實例：用他的詞，問他的事

客戶：「我不知道下一步要做什麼。」

照著表單問的回應：「那你接下來有沒有想過可以先做什麼？」

讀著訊號問的回應：「你說『不知道』——是還沒想出來，還是其實想出來了，但不想選那一個？」

第一種回應把客戶交回的八件事硬塞進我們想要的十件：他說了「不知道」，我們卻當成「他需要一個行動清單」，於是送他一個問題，讓他再答一次不知道。第二種回應先用他自己的詞把那句話舉起來，再從那個詞往下問。差別看起來很小，但它決定了下一輪是繼續原地打轉，還是真的往前走。書上的說法是：不要用通用的問題，要用他們的詞把問題客製出來。

這一章我們在系統身上學到的，正是同一個道理的另一面：如果你沒有真的去看對方交回什麼，你以為的「要求」，對他來說從來沒有存在過。 客戶答的不是我們問的，系統給的不是我們要的，這兩件事是同一件事。

得｜成果與心得

具體成果：八欄的契約被真正鎖住，正式環境的實際形狀十二次全部精確命中；「哪幾欄是承重的」有了逐欄清單；兩個從來沒被真正要求的欄位，現在可以被有條件地要求；量測的日常管線接上，自動化檢查搬回自家機器。還有一個不在計畫裡的收穫：我們抓到了「安靜地沒有作用」這個故障形狀的具體長相，它會在往後的日子裡一再出現。

開發心得：這十天，我們一個字都沒有改動教練的說話方式，也完全沒有推進「真實會談總分 0.6」這個北極星。從成績單的角度看，這是十天的零分。但如果沒有先讓「要求」與「實際」對上，後面每一次實驗的數字都可以被一句話推翻：你確定你量的是你以為的那件事嗎？在一個要拿數字做決定的專案裡，先把尺與鎖修好，不是基礎工程，是全部。

也誠實記下代價：四百多個改動裡，真正解決問題的只有那一小步「換一條路」；前面九成的力氣，花在證明「原本那條路不會執行規則」。證明一件事情沒有效，聽起來很浪費——但它讓正確的那一步變成一句話就能完成，而不是幾週的猜測。

給教練的反問：你上一次檢查「你以為已經說清楚的要求」，是什麼時候？你怎麼知道對方收到的，和你以為你送出的，是同一件事？

下一章預告：工具修好了，第一件事是回頭量那把尺。結果分數真的上升了——但上升的不是教練。