第 06 章意向圖:品質的清算
Chapter 06 · audit

品質的清算 — 一場一場會談地解剖

2026 年 4 月 14 日 – 4 月 26 日

真正理解教練品質,必須敢把每一回合攤開來問:做對了什麼、錯過了什麼。

2026 年 4 月 14 日 – 4 月 26 日

全專案最密集的兩週。單日 60、53、52、48 個提交。單日 20 到 28 個「保留/否決」判決。我們把幾十場真實會談攤開,一回合一回合地審。


核心啟發

如果你沒有勇氣把一場會談攤開來、一回合接一回合地問「這一輪做對了什麼、錯過了什麼」,你就無法真正理解「教練品質」這四個字。對開發者而言,這場清算不是為了打分數,而是為了看見原本看不見的東西——包括那些讓我們很不舒服的東西。


觀|思維

Reynolds 對「聆聽」有非常具體的指引。教練不是漫無目的地聽,而是聆聽幾類特定訊號——其中最關鍵的是三個詞:really(真的)、but(但是)、should(應該)——以及客戶自問的問題、情緒轉變的信號、敘事中的矛盾點。

她也指出,犯錯在教練對話中並不可怕:

「Being wrong can prompt them to think more deeply.」

(說錯了,反而可能促使他們想得更深。)

這構成了這兩週的開發命題:如果「好的聆聽」是聆聽特定訊號,那麼品質清算就是回頭檢視——這些訊號,系統到底接住了沒有?


為|實務與實現

幾十場會談的逐回合解剖。 這兩週做了一件前所未有的開發工作:取數十場真實會談,逐回合深度分析。每一回合都追問:客戶這句話背後的情緒與需求是什麼?系統的回應瞄準了什麼、實際觸及了什麼?有沒有錯過的信號?下一回合,客戶是更深入了還是退回去了?每一場都產出 3 到 9 個待修問題。

把問題分類,才能對症。 逐場修是不夠的,必須讓問題浮現共通型態:抗拒偵測失靈(客戶說「嗯,或許吧」被當成同意——正是 Reynolds 的 "but" 訊號被漏掉)、承諾追蹤失準、洞察過早報告、收尾壓縮成機械問卷、危機誤判(某些正常華文用語被誤判為危機關鍵字)。

每天幾十個「保留與否決」。 這兩週的判決密度是全專案最高的——單日 20 到 28 個 KEEP/DISCARD。承諾守門從「計算次數」改為「計算品質」;危機偵測加入「否定情境判斷」;洞察偵測加入「最低深化要求」。但也有慘痛的回退:某些修復在一個場景救了分,卻在另一個場景造成災難性退步(承諾分數掉了 0.20),只能整個退回。

一條用血換來的鐵律。 我們試圖加入「必須由客戶主動提出行動」的守門規則,結果發現有些客戶確實需要引導才能把模糊意向具體化,強制等待只會讓對話卡住。開發上這留下一條鐵律:每一個守門規則,都是一把雙面刃——它防止一種錯誤,也可能阻擋一種正確。

會談實例:被錯過的 "but"

Reynolds 說要聆聽 "but"。一個被系統錯過的 "but",在解剖中長這樣——

客戶:「我老闆其實人很好啦,但……算了,反正我自己調整一下心態就好。」

沒接住訊號的回應:「很好,能自己調整心態是很成熟的態度。那你打算怎麼調整呢?」

接住 "but" 的回應:「我想倒帶一下。你說『他人很好』,接了一個『但是』,又自己把它收掉了。那個被你吞回去的『但是』,後面本來想說什麼?」

前者順著客戶的「自我調整」往下走,等於配合客戶把那個 "but" 永遠埋起來;後者聽見了被吞掉的轉折,把它請回桌面。在幾十場解剖中,這類「被漏掉的訊號」是最常見、也最關鍵的品質殺手。


得|成果與心得

這兩週的成果,是建立了「逐回合解剖」這套品質分析方法,並從幾十場會談中提煉出可對症的問題分類與大量修復。

開發心得:品質改善不是「加規則」,而是「提升判斷力」。 解剖了這麼多場後我們發現一個反直覺現象——增加更多守門規則往往讓系統更僵硬,而非更敏銳。規則能防止最明顯的錯誤,卻無法幫系統聽見一個被吞掉的「但是」。這個認識,最終在數週後逼出了一次重大的策略轉向。這兩週的瘋狂節奏(一天 60 個提交),其實藏著一個還沒被說出口的疑慮:我們這樣一條一條地補,真的補得完嗎?

對專業教練,這兩週的提醒是:真正的好教練靠的不是「避免犯錯」,而是「做出精準的判斷」——尤其是接住那些客戶自己都想跳過的訊號。而「退回」的勇氣同樣重要:承認「這一步走錯了」並回頭調整,比堅持一個錯誤的介入更有專業價值。


下一章:瘋狂的修復節奏之後,我們踩下煞車——凍結架構、改用更嚴謹的流程,把「快」換成「穩」。