Kevin 是一家跨國物流公司的人，這幾天主動回我，表態認同 Claude 確實比較強，順手問了 Copilot Cowork 怎麼啟用。看起來像是一個很順的培訓案：客戶買單、客戶想用、客戶問操作。但他緊接著補了一句反問：「萬一連 Cowork 也開不了，還有什麼替代方案？」
這句話我聽進去了。它表面是在問工具，底下其實是在替我把整個案子的前提抽掉——如果我把培訓綁在「等某個工具確定能用」上，那只要工具卡住，案子就跟著卡住。
我用 first-principles 把這個繼承來的假設砍掉。「等工具確定才培訓」根本是個沒必要的綁定。工具落地是一條線，能力培養是另一條線，這兩條本來就可以平行跑，不必互相等待。想通這點之後，我擬了三線方案給他：C 是走公司雲內的 Claude（Bedrock 或 Vertex，在他們自己雲環境裡跑）；A+B 是用個人帳號加 mock data，現在立刻就能練，跟公司開不開工具完全無關；D 是地端 Qwen，當保底，先放著沒推。
第二次飄是在他下一句追問。他說：「their system can’t access Claude，這會不會限制可能性？我甚至想自己建一個 webapp 當 hub。」
到這裡我心裡的判讀就清楚了。第一，他對「練 muscle」這件事的價值是半信半疑的——他不太相信光是培養能力會有用。第二，這是他第三次往「給我一個 artifact」的方向飄了。第一次是希望 AI 幫忙做 PPT，第二次是 Q2 那種 agentic 的東西，這次是 webapp hub。他是 builder 性格，手會一直癢，想要一個摸得到的成品，而不是一身看不見的能力。
我回他的時候做了三件事：先反問封鎖到底是哪一層級；接著主張先培訓；至於 webapp hub，我誠實表態——開發 app 不是我的強項，我不會硬接，但我可以幫他引介。
真正的鬆手動作藏在一句話的改字裡。我原本寫的是「after the training」，我們先培訓，之後再看 hub。後來我把它改成「if the priority is to build the hub」——如果你的優先順序就是要先把 hub 蓋出來。
差別在哪？「after the training」是我替他排好了順序，培訓在前、hub 在後，等於我還抓著主導權，也預設了這是一個培訓案。改成「if the priority」之後，我把順序的綁定整個拿掉，把球交回他手上。這是一個 qualifying 的動作：他怎麼選，直接判定這案子的性質。他選先培訓，這就是培訓案；他選先蓋 hub，那這就是一個引介案，我把開發的部分轉介出去。兩種結果我都不虧。
寫到這個份上我不太放心，丟了兩個 subagent 去審——一個 /minimalist-entrepreneur，一個 /street-smarts。它們挑出三個盲點。第一，我的報價跟客戶的真實意圖根本沒對齊，再這樣下去我恐怕會報出一張幻覺單，報的是培訓，他要的是系統。第二，免費引介這件事，等於把一個比主案還大的金流無償讓出去——開發案的盤子比培訓大得多，我卻打算白送。第三，我鬆手的時機早了一步，而且還摻了情緒。
然後 Kevin 回了封鎖層級：是 network block，三層裡最嚴的那層。
這個答案反而把局面收斂了。技術上判讀下來：A+B 的培訓完全不受 network block 影響，照樣能跑；而 webapp hub 在這種封鎖下，唯一合規的路就是雲端後端加上 webapp 前台。換句話說，他想要的那個 hub，跟唯一合規的架構，其實是同一條路。原本看起來互斥的「他要系統」和「我能合規交付」，被這個最嚴的限制逼成了同一個方向。
下一回合我打算攤桌：把「系統 vs 能力」這件事直接講開；引介的部分改成有償的監理顧問，另外報價，不再白送;然後用 mock data 跑一個 30 分鐘的 demo 給他看。
回頭看這整件事，最關鍵的不是哪個方案技術上最漂亮，而是那個改字。把「after」換成「if the priority」，本質上就是承認我控制不了他的順序，也不該假裝這一定是個培訓案。剩下的就交給他選——怎麼選，怎麼報，都不虧。