昨天講的「建設性挑戰」管的是單一個答案夠不夠扎實。今天要處理的問題更難抓：每個答案分開看都合理，挑不出毛病，但放在一起對照就會發現彼此矛盾。

我自己第一次被這種矛盾坑到，是一份看起來超完整的需求。背景寫得清清楚楚：「我們的目標是降低客服進線量。」使用者寫得明明白白：「保戶。」功能清單列了十幾項，每一項都合理。指標也漂亮：「客服進線量下降兩成。」

每一段我都點頭。然後到了排畫面清單那一步，我才發現整份需求裡，沒有任何一個讓保戶「自己查、自己改、自己完成」的流程。全部功能都是後台給內部人員用的。

那客服進線量要靠什麼降下來？整份需求裡找不到答案。

為什麼矛盾這麼難抓

因為它不住在任何一個區塊裡。

挑戰機制是局部的，它盯著當下這一題。你說「目標是降客服」，它頂多回你一句「降客服是好目標，那具體是哪一類問題的客服？」這個挑戰是對的，但它管不到三個區塊之後你列的功能清單。等你寫到區塊 4，前面那個目標早就滑出對話的視線了。

人在會議裡也一樣。需求方PM 講背景的時候大家在想背景，講功能的時候大家在想功能。沒有人會在第 47 分鐘突然把第 8 分鐘講的那句話拉回來對照。需求審查會之所以常常要開第二次、第三次，很多時候哪一段都沒錯，問題出在段跟段之間兜不起來，而那個縫隙當場沒人看見。

需求工程領域很早就知道這件事不好處理。Nuseibeh、Easterbrook 跟 Russo 在 2000 年那篇〈Leveraging Inconsistency in Software Development〉裡主張：不一致不該被當成錯誤一律消滅，有時候它暴露的是利害關係人之間真正的歧見，值得留下來攤開談。我認同這個觀點，所以鼠勾以的設計不是偵測到矛盾就擋住流程，而是把矛盾指出來，要求當場做一個決定。

要做到這件事，它得在每個區塊結束時，回頭把前面記下來的東西重新讀一遍，拿這一塊的新答案去比對舊答案。等於是讓 GPT 隨身帶一份會議記錄，而且它真的會翻。

五種典型不一致

我把實務上最常見的矛盾收斂成五種。它們的共通結構都是「區塊 A 講了一件事，區塊 B 講了另一件事，兩件事放一起站不住」。

1. 目標 vs 功能脫節

開頭那個故事就是這一型。區塊 1 說目標是「減少客服量」，區塊 4 的功能清單裡卻沒有任何自助服務流程。

鼠勾以會這樣問：

你在區塊 1 說目標是減少客服電話，但功能清單裡沒有看到自助服務的流程。客服量打算靠什麼降下來？

這一問通常會逼出兩種結果之一：要嘛需求方PM 想起來「對欸，我們漏了自助查詢」，補一個功能；要嘛需求方PM 發現真正的目標其實另有所指、根本不是降客服，那就回頭把區塊 1 改對。兩種都是好結果。

2. 使用者 vs 功能不符

區塊 2 說主要使用者是「保戶」，區塊 4 卻列了一大票後台管理功能。

你說主要使用者是保戶，但功能列表裡有很多後台管理功能。這次是要做前台給保戶用的，還是後台給內部用的？還是兩邊都要？

這個矛盾背後常常藏著一個沒講清楚的範圍問題：需求方PM 心裡其實想做兩套系統，但只描述了一群使用者。早點問出來，工時估算才不會少算一半。

3. 時程 vs 範圍不符

需求方PM 在優先級那邊提到一個硬性截止日，但功能數量明顯塞不進那個時間。

你提到某個日期要上線，但目前有十幾個功能。這個時程跟範圍之間有風險，建議先確認 MVP 只包含哪些。

這型矛盾最容易被情緒蓋過去，大家都很興奮要做一堆功能，沒人想當那個說「時間不夠」的人。鼠勾以不怕當這個人，它沒有面子問題。

4. 指標 vs 功能脫節

跟第一型很像，但矛頭對著成功指標。區塊 3 說北極星指標是「提升轉換率」，區塊 4 的功能裡卻沒有任何一項直接碰得到轉換。

你的北極星指標是轉換率，可是功能清單裡沒看到直接影響轉換的功能。這兩件事怎麼連起來？

很多需求會把「想量的東西」跟「要做的東西」分開寫，寫的時候不覺得有問題，因為它們在不同段落。一比對才發現，你花力氣做的功能根本動不到你說要追的那個數字。

5. 資料 vs 流程不一致

這一型最偏技術，也最常在 SA 會議上被當場問出來。區塊 5 的流程裡用到了某個資料，區塊 6 的欄位清單裡卻沒有這個欄位。

流程中提到「會員等級」，但資料欄位清單裡沒有這一欄。是漏填了，還是這個資料要從別的系統取得？

如果是漏填，補上就好。如果是「從別的系統取得」，就會帶出下一個技術問題：哪個系統、哪支 API。這正是該事先帶去問 SA 的內容，而不是等 SA 在會議上自己發現。

什麼時候比對、靠什麼比對

光是「希望 GPT 注意一下矛盾」是沒用的，它會忘。要它穩定做到，得把時機跟做法都寫死在規則裡。

時機上有三個觸發點，一層比一層粗：

• 每收到一個回答：這是昨天講的局部挑戰，盯當下這一題。
• 每個區塊收尾：這就是今天的跨區塊偵測。GPT 填完這一塊，就拿剛拿到的答案去比對前面所有已經記下來的區塊，命中上面那五組對照的其中一組就發問。
• 產出 PRD 之前：最後還有一道全域自檢，把整份需求從頭到尾再掃一遍，補抓中途漏網的。這一道留到 Day 26 細講。

做法上，關鍵是不靠 GPT「靈光一閃」想起來，而是給它一張對照清單。那五種矛盾我沒有寫成一段文字叮嚀它「請小心」，而是寫成「A 欄位 vs B 欄位」的固定對照表放進知識庫：左邊是某個區塊的某種答案，右邊是另一個區塊該有、卻沒出現的東西，後面接一句現成的提問範本。GPT 到了區塊收尾，就照這張表逐列問自己「左邊成立嗎？成立的話右邊有嗎？」

寫成表格還有一個好處：實務上遇到新的矛盾類型，只要在表裡加一列，偵測範圍就擴一格，不用回頭去調整它的推理方式。比對邏輯放在資料裡，而不是依賴模型當下的判斷。

偵測到之後，做什麼

抓到矛盾只是第一步，怎麼收尾才是分寸所在。鼠勾以的處理跟昨天的挑戰機制一脈相承：指出來、接一個具體問題、不阻塞流程。

它不會跳出來說「偵測到矛盾，請修正後才能繼續」。它會把矛盾講清楚，接一個能往下走的問題，然後等回覆。使用者可以當場改，也可以回「我知道，但這版先這樣」。選後者的話它不會繼續追問，而是把這筆記進待確認清單、標上 [風險備註]，讓這個被擱置的矛盾出現在最後產出的需求討論書上。SA 翻到那一段，就知道需求方PM 本人也已經知道這裡有風險。

矛盾寫在文件上，後面的人至少知道要優先確認哪裡；把它磨平、讓文件讀起來完全沒有爭議，代價會落在上線之後。

小結

• 矛盾不住在任何一個區塊裡，它住在區塊跟區塊的縫隙，所以局部的挑戰機制抓不到，要靠跨區塊的回顧比對。
• 五種典型不一致都是同一個結構：A 說一件事、B 說另一件事，湊起來站不住，五組分別是目標 vs 功能、使用者 vs 功能、時程 vs 範圍、指標 vs 功能、資料 vs 流程。
• 做到的方式是把時機跟比對邏輯都寫死成規則：時機有三個觸發點（每收到一個回答、每個區塊收尾、產出 PRD 前），做法是給 GPT 一張「A vs B」的對照表逐列自問，而不是指望它自己想起來。
• 抓到之後不擋流程，指出來、問一句、你不改就留 [風險備註]，把矛盾誠實地寫進文件。

矛盾偵測管的是「同一份需求內部」一不一致。但鼠勾以還得先搞懂一件更前面的事：你這次來，到底是想從零探索一個新需求，還是手上已經有半成品要它幫你整理？是要更新一份舊清單，還是想叫它幫你健檢一份寫好的需求？這四種情況的接法完全不同。下一篇講「四種模式判定」，看鼠勾以怎麼自己判斷你是哪一種人、然後切換成對的工作方式。

這是 iThome 鐵人賽系列文章。明天見。