2026 年 4 月 8 日 – 4 月 13 日
六天。架構從測試環境走進真實對話。第一個沉默的客戶，就推翻了我們所有「準備好了」的自信。
核心啟發
在測試環境中完美的系統，在真實對話中可能不堪一擊。不是因為架構錯了，而是因為真實的人類對話遠比任何測試案例複雜、混亂、而且美麗——這是每一個從測試走向真實的開發團隊都必經的震撼。
觀｜思維
Reynolds 對教練的核心要求是「臨在（presence）」，而她認為臨在比技巧更重要：
「Your clients need you to be present more than they need you to ask the perfect question.」
（比起你問出完美的問題，客戶更需要的是你真正地在場。）
「臨在」這件事，在測試環境裡是抽象的——因為測試案例不會打斷你、不會已讀不回、不會在你最精采的提問後說「我不知道」然後消失三小時。但真實的人會。這六天的第一課，就是讓「臨在」從一句方法論口號，變成了實際的開發課題。
為｜實務與實現
架構正式上線。 從這六天起，所有透過 LINE 使用服務的客戶，都由 Two-Pass 架構驅動。頭幾天一切看起來正常，然後真實對話進來了。
第一課：沉默的複雜性。 測試環境的沉默是乾淨的；真實對話的沉默截然不同——客戶在打字中（思考？猶豫？）、已讀不回（不想繼續？需要消化？）、長時間後回來卻講完全不同的話題（逃避？還是有了新想法？）。教練實務上，這幾種沉默需要完全不同的回應。開發上，我們讓系統開始區分不同類型的沉默，並加入「軟性挫折偵測」：當客戶反覆繞圈、無法深入時，能識別這種「卡住」並溫和地反映現象本身。
第二課：教練也需要被「記住」。 這六天上線了「教練檔案」（跨會談記憶，relationship memory）機制。每位真實客戶，系統都會建立一份持續更新的檔案——記的不是他們的「問題」，而是反覆出現的主題、曾觸及但未深入的議題、對不同人格的反應、跨場次的成長軌跡。這對應教練實務的一個真理：一場會談的價值，往往不只在那段對話裡，而是在客戶下一次回來時，教練還記得「我們上次談到哪裡」。
為系統裝上「人類督導的眼睛」。 這六天還建立了一套審查機制：讓有經驗的人類教練可以回顧系統的每一回合，標記哪些回應好、哪些需改進。開發上這是個重要決定——它讓「系統的學習」不再只依賴自動評分，而是有了真實人類專業判斷的校準。這套機制成了後續品質工作的核心驅動力。
會談實例：當「完美的下一個問題」遇上「真實的當下」
真實上線後，我們最常在審查中看到的失誤是這種——
客戶：「其實……算了，沒事，可能我想太多了。」
執著於推進流程的回應：「沒關係，我們繼續。回到剛剛說的職涯規劃——你提到想三年內轉管理職，那第一步想怎麼開始？」
選擇臨在的回應：「你說『算了，沒事』——可是你前面明明正要說一件事。我不急著往下走。如果那件『沒事』其實有點重要，你願意說說看嗎？」
前者有個「完美的下一個問題」，急著回到預設軌道；後者放掉那個漂亮的問題，留在客戶剛剛閃過的那道門前。開發上，這類對照成了我們訓練系統「何時該放棄預設下一步」的素材——而這恰恰是「臨在」最難寫成規則的部分。
得｜成果與心得
這六天的成果，是讓架構真正接觸了真實用戶，並建立了「教練檔案」與「人類審查」兩套支撐後續所有改進的基礎設施。
開發心得：測試永遠無法取代真實。 我們花了五週設計架構、訓練、調校，所有測試都說「準備好了」。但真實客戶的第一週就告訴我們：還差得遠。這不是失敗，而是任何專業養成必經的階段——系統的處境，和一位剛開始接案的新手教練完全一樣：有了正確的架構，但還需要大量真實對話經驗，才能把原則變成真正的臨在。
這六天也讓我們對接下來的工作有了清醒的預期：真實用戶不會配合你的腳本。下一章那場長達兩週、單日上看 60 個提交的「品質清算」，就是被這六天的真實對話逼出來的。
下一章：當真實對話的瑕疵全部攤開，我們進入了全專案最密集的兩週——一場一場會談地解剖、修復、再退回。