Specification Skill 怎麼練 — 把模糊目標翻成設計問題的四個動作

Specification skill 不是品味，也不是資歷，是一套翻譯流程：把「老闆的一句話」翻成「有邊界、可檢核的設計問題」。這套流程可以拆成四個動作，每個動作都能單獨練，練壞了也看得出來壞在哪。

大部分人練不起來，不是因為不夠聰明，是因為把它歸類錯了。觀察一下團隊裡「需求理解很強」的人怎麼被描述——「他就是有 sense」「他資歷夠」。這個描述本身就洩漏了問題所在：連做得到的人自己都說不清楚他是怎麼做到的。哲學家 Michael Polanyi 討論默會知識（tacit knowledge）時有一句常被引用的話：我們知道的，比我們能說出來的更多。specification 練得好的人通常正是這種狀態，判斷已經內化到不需要意識介入的程度，卻也因此失去了向別人解釋步驟的語言。組織拿不到一套可以教的步驟，只好用「sense」「資歷」這種特質詞去描述它，這不是懶惰，是真的沒有詞彙可用。歸類成天賦的東西沒有人會去練，所以它一直稀缺；稀缺，所以在 AI 把執行成本壓到接近零的現在，它變成定價最高的那層能力。

這篇文章要做的，就是把這個默會的判斷拆回可以教、可以練的步驟。

以下四個動作，順序不能換。後一個動作要吃前一個動作的產出，跳著做，代價會在後面加倍付出來。

動作一：先盤限制，不是先想方案

拿到「我們要做一個會員系統改版」這種需求，執行型的反應是打開 Figma；specification 型的反應是先列出「不能動的東西」。

限制分兩種，混在一起就會做白工：

假限制之所以會被誤認為硬限制，是因為組織裡沒人再去追問源頭：沒人記得為什麼要這樣做，只記得一直都這樣做。追問一次的成本，遠低於整個團隊繞著它設計三個月的成本。

練法：接下來每個需求，動手前先寫五條限制，然後逐條標「硬 / 假」。兩週後回頭看標錯了幾條——標錯的那幾條，就是你對組織脈絡的盲區。

動作二：把「夠好」寫成一句可以被否證的話

「做出好的體驗」不是目標，是逃避定義的說法。可檢核的版本長這樣：「新註冊用戶在第一次進站的 60 秒內，能不看說明完成綁定」。

判斷一句「夠好」有沒有寫到位，測試方法只有一個：這句話能不能被人反對。這個測試不是我自己發明的，它是科學哲學家 Karl Popper 用來區分「科學」與「非科學」陳述的可否證性（falsifiability）判準的翻版：一個理論如果沒有任何可能的觀測結果能推翻它，它就不是在描述世界，只是在描述自己的信仰。「體驗要好」正是這種不可否證的句子。不管上線後發生什麼，這句話都不會被證明是錯的，因為它從一開始就沒有具體到「可以錯」。「60 秒內不看說明完成綁定」不一樣：上線之後有明確的方式判斷它是否成立。可否證性不是學術裝飾，是判斷一句目標句子有沒有實際約束力最快的方法。

練法：把你手上專案的目標句子拿出來，改寫到「有人會想反對」為止。反對出現的那一刻，specification 才開始。

動作三：預判 stakeholder 嘴上沒說的那個待辦任務

Stakeholder 說「要有質感」，字面翻譯是視覺升級，實際判準可能是「上次被 CEO 說介面像工程師做的，這次不能再發生」。字面需求和真實判準的落差，就是改版做完被打回票的主因。

這個落差，Clayton Christensen 在待辦任務（Jobs to be Done）理論裡講得很清楚：顧客要的從來不是產品規格本身，是他要完成的那個任務。他常被引用的例子是奶昔，顧客買的不是奶昔的口味，是通勤路上一個能單手拿、吃得夠久、不會太快餓的早餐。字面需求（要有質感）是產品規格層級的語言，真實判準（不能再被說像工程師做的）才是待辦任務層級的語言。specification 要翻的不是「他說了什麼」，是「他要完成什麼任務」，也就是那句話字面之下，他真正想解決的處境。

預判不是通靈，是三個可查的來源：這個人上次否決設計時說了什麼；他的 KPI 這一季掛什麼；他要拿這個東西去跟誰交代。三個問題的答案通常不在會議裡，在會議前後的走廊對話和上一季的檢討文件裡。

練法：下次 kickoff 前，先寫下你猜的「真實判準」，會後對答案。猜錯的原因寫下來，那是你的脈絡資料庫。

動作四：用一頁 spec 對賭

前三個動作的產出，收斂成一頁：限制清單、一句可以被否證的「夠好」、每個關鍵 stakeholder 的真實待辦任務。然後拿去給人打臉。

這一頁的價值不在寫對，在寫「錯得夠具體」。模糊的理解不會被糾正，因為沒有人知道你理解錯了；寫下來的錯誤會在十分鐘內被指出。被打臉的速度，就是 specification skill 成長的速度。

這套方法什麼時候會反噬你

把「夠好」寫成一句可以被否證的話，好處是有邊界，代價是它容易被單一化。經濟學家 Charles Goodhart 提出、後來被通稱為 Goodhart's law 的觀察是：一旦某個衡量指標變成被追逐的目標，它就不再是好的衡量指標。「60 秒內完成綁定」寫進 spec 之後，最快達成它的方法不一定是把體驗做好，也可能是把驗證步驟拿掉、把風險判斷跳過。指標達成了，但你原本想守護的東西被犧牲了。

處理方式不是放棄可檢核的目標句，是同時寫一句「這個目標不能用什麼方式達成」，排除條款要跟目標句一樣認真對待。

這套方法還有一個更根本的前提：它假設「真實判準」找得到，這個人可觸及、可觀察。如果需求本身是多方角力，沒有人能代表「真實判準」，三個部門主管各自要不同的東西，動作四交出去的就不是一個答案，是三份互相衝突的答案。這種情況下，一頁 spec 的價值不是收斂決策，是把衝突攤開，讓真正該拍板的人自己選。

常見的三個坑

第一個坑：把 spec 寫成 solution。「做一個浮動客服按鈕」是方案不是問題；問題是「用戶在結帳失敗時找不到求助入口」。寫成方案，等於把翻譯的工作丟回給自己的偏好。

第二個坑：把假限制當硬限制供著。組織裡最貴的浪費，是整個團隊繞著一個「其實可以動」的東西設計了三個月。

第三個坑：spec 寫完就鎖起來。一頁 spec 是拿來被推翻的，兩週沒被任何人挑戰過的 spec，不是寫得太好，是沒有人在讀。

你的下一步

本週挑一個正在跑的需求，做動作一和動作二就好：五條限制標硬假，一句「夠好」改寫到可以被否證為止——也就是改到有人願意站出來反對它。四個動作全套跑起來大概要三個專案的週期，但前兩個動作這週就能開始。

執行的成本已經塌了，翻譯的價值還站著。練的人現在還不多——這是時間差，不是天賦差。