當AI給出的建議總是隔靴搔癢，問題可能出在提問方式上。本文透過職場項目推進的真實案例，揭示如何用BTICOE框架重構問題描述——從通用分析到精準診斷的關鍵躍遷，本質上是在訓練「精準定義問題」這項高階能力。

你有沒有這種體驗：

把一個職場困惑發給AI，它回了一大段，看著頭頭是道，但讀完之後你還是不知道自己該怎麼辦。

嗯，其實我也有過，哈哈哈。

不是AI不好。是因為你還沒想清楚，自己真正要問的是什麼。

同一件事，三種問法，三種完全不同的結果（第三種問法，我拿了王歡老師的方法，哎，真不錯呢！你也快拿去用吧~）。我來演示給你看。

場景：我是一名職場人，最近在推進一個重要項目，但感覺推不動，想搞清楚問題在哪。

版本一：零上下文

我發給AI：我的項目推不動，幫我分析原因。

AI給了一些：如目標模糊、需求管控失控、人力配置問題、資源供給不足等。

每一條看著都有道理，但放哪個行業都成立，套誰的情況都能用。這不是分析，是排列組合。我還是不知道自己的問題在哪。

版本二：有一點上下文

我發給AI：我是產品經理，負責一個內部系統改造項目，推進了兩個月，開發那邊總是說排期不夠，幫我分析一下。

現在好一點了。

AI開始按照需求側、開發側等方向具體分析了。方向有了針對性，但還是在猜，因為它不知道你們公司的具體情況，不知道真正的卡點在哪。

版本三：BTICOE完整版

我發給AI：

【背景B】我是一家製造業公司的產品經理，負責內部ERP改造專案，已推進兩個月。開發團隊上週第三次說排期不夠，但我注意到他們同期在做另一個業務部門的需求，優先級好像比我的高。上個月我和直屬leader彙報了一次，他說「繼續推」，沒有給出更多支持。
【任務T】分析專案推不動的最可能根本原因，以及我下一步能做什麼。
【指令I】按三個部分來：表層原因、深層原因（重點看優先級和決策層），以及我現在可以做的驗證動作，不是直接對抗，而是透過其他方式判斷。
【約束C】不要給通用建議。聚焦我自己能做的事，不要建議我去做我沒法控制的事。
【輸出O】三個部分，每部分不超過四條，直接可操作。
【示例E】風格：假設驅動，結論明確，不廢話。比如「最可能的原因是X，判斷依據是Y，可以透過Z驗證」。

我們再來看看。

AI識別到了「開發團隊同期在做另一個需求、優先級可能比你高」這個關鍵信號。它推斷：你的專案在內部可能已經被默默降級，leader說「繼續推」只是安撫，並沒有真正調動資源。

它給了一些不需要正面衝突就能驗證的動作：

1. 索要書面工時拆解：讓開發輸出本週工時分佈清單，驗證是否大部分工時投入其他業務需求，留存客觀數據。

2. 輸出專案阻塞對比表：記錄你的ERP專案停滯節點、另一業務需求的開發進度，驗證資源傾斜的真實差距。

3. 做優先級書面確認：極簡文字同步領導，明確詢問「兩個並行項目孰高孰低」，用書面記錄倒逼決策落地，結束模糊狀態。

4. 驗證項目剛性權重：梳理ERP改造的隱患（舊系統風險、效率損耗、後續迭代阻塞），對比並行業務需求價值，驗證自身項目的權重缺口。

像這個結果，明天就可以拿來做決策。和第一版的通用分析相比，已經是完全不同量級的東西。

BTICOE不是格式技巧，是思維品質的升級

你在寫BTICOE的過程中，同時在強迫自己想清楚「我到底要什麼」。

很多時候當你把背景和約束寫完，你對答案已經有了一半的判斷，因為你在寫的過程中，逼著自己回想所有關鍵資訊。

BTICOE最大的價值不是讓AI更好，是逼你自己想更清楚。

這種「把問題想清楚」的能力，不只用在和AI對話上。

在我做一對一陪跑諮詢的過程中，最難的那一步往往不是給建議，而是幫人把真正的問題從模糊的困惑裡挖出來。

很多人來找我的時候問的是「我該怎麼辦」，但其實需要先回答的是「我現在到底在哪個處境裡」。