天花板 — 反覆撞牆，與承認極限的勇氣

2026 年 5 月 11 日 – 5 月 21 日

11 天裡，單日 49、51 個提交的爆發，伴隨著一次又一次的「災難性退步」與全部退回。我們終於說出那句最難說的話：在這個架構下，我們碰到天花板了。

核心啟發

每一個系統（無論是人還是機器）都有能力的上限。對開發者而言，真正的專業不是否認天花板的存在，而是準確地辨識它的高度，然後決定：是繼續在現有架構內優化，還是改變架構本身。

觀｜思維

Reynolds 對「客戶反覆繞圈」有一個明確處方——當客戶一直在原地打轉、反覆談論是什麼阻礙了他們時，教練應轉向更深的層次：

「Whenever coachees go in circles talking about what is holding them back, shift to talking about who they want to become.」

（每當客戶在原地繞圈、反覆談論是什麼阻礙了他們時，就把話題轉向：他們想成為什麼樣的人。）

這句話本來是關於客戶的，但這 11 天它照進了我們自己：當系統在某個品質維度上反覆卡住、怎麼微調都上不去時，「繞圈」是一個訊號。你正在錯的層次上努力。

為｜實務與實現

反覆的災難性退步。 這 11 天的特徵，是一連串「改了、測了、災難、退回」的循環。我們嘗試擴充關鍵字偵測、調整語義錨點的來源——結果某個場景的收尾分數掉了 0.18，只能整批退回。單日 49、51 個提交的爆發，背後不是順利，而是反覆撞牆的焦灼。

承認天花板。 在一連串退回之後，我們做出了一個重要的開發判斷：在現有架構下，當系統使用較輕量的思考資源時，它的回應傾向公式化——即使加再多守門規則（出口守門，post-check），也改變不了「它無法進行真正的深層理解」這個事實。 這不是失敗宣告，而是範圍的確認：在這個架構內可以把品質推到某個水準，但要再上去，需要不同的方法。經過一輪嚴格的外部覆核，我們正式接受了這條線。

在天花板之下，仍把每一吋做到最好。 即使承認了天花板，我們仍進行許多微調——防止把淺層理解誤判為深層洞察、防止系統在早期就暗示收尾、修正一個讓職涯類會談承諾分數從 0 跳到 0.8 的重要錯誤。最有代表性的是收尾優化：我們試了多達八個版本，大部分失敗，最終存活的方案把某一類會談推到了歷史新高。承認天花板，不等於放棄在天花板下爭取每一分。

會談實例：在錯的層次上「繞圈」

我們自己撞牆的方式，恰恰是系統最常犯的錯——讀不出「該換層次了」的訊號：

客戶（第五次回到同一個點）：「所以我又得加班，因為這個案子沒人能接。上次也是這樣，上上次也是。我真的不知道為什麼每次都這樣。」

繼續在表層繞圈的回應：「那這次，你想過可以怎麼把工作分配出去嗎？要不要一起看看哪些任務能交給別人？」

轉向更深層次的回應：「我注意到我們繞回這個點好幾次了。我想換個方向問——一個『能把案子交出去、能讓自己準時下班』的你，會是什麼樣的人？那個人，和現在這個『每次都得自己扛』的你，差在哪裡？」

前者停在「問題解決」的層次，於是和客戶一起繞了第六圈；後者識別出「繞圈」這個訊號，把對話轉向「你想成為誰」。開發上，我們發現「識別繞圈、並轉換層次」正是輕量系統最難跨過的能力。這也成了判定天花板高度的關鍵指標。

得｜成果與心得

這 11 天的成果，是一組在天花板之下的紮實微調，以及一個更重要的判斷——清楚畫出了現有架構的能力上限。

開發心得：「知道天花板在哪」本身就是價值。 它讓我們不再把力氣花在注定無效的微調上。同時這 11 天也教會我們，每一次改善都有代價：你加強承諾追蹤，可能讓系統在探索階段變急躁；你抑制過早收尾，可能讓它在該收尾時猶豫。最難的是，你往往要在改動之後，才看得到它破壞了什麼。承認天花板，其實是承認「我們不能再靠蠻力了」——接下來的問題就變成：真正的突破口在哪裡。

對專業教練，這一章最實用的提醒是：當客戶反覆卡在同一個地方，不要再加一個更聰明的解決方案——那只會繞第七圈。繞圈是一個訊號，告訴你該換層次了。

下一章：撞牆之後，我們把全部力氣押在一個極其精細的判斷能力上——一場長達 27 輪、近乎偏執的打磨。