一個太聽話的助手，其實沒用

前面 22 天，鼠勾以給人的印象大概是個很會問問題、很會打分數、很有溫度的好同事。但今天我要講它「不溫柔」的那一面，而且這一面，是我覺得整個工具裡最重要的設計之一。

先說個讓我下定決心做這件事的場景。早期有一版鼠勾以，問答能力很好，唯一的問題是它太聽話了。需求方PM 說什麼，它就記什麼。

需求方PM：目標使用者是所有會員。
鼠勾以：好的，已記錄「目標使用者：所有會員」。

需求方PM：這些功能都很重要，都是 P0。
鼠勾以：收到，全部標記為 P0。

需求方PM：例外情境喔，那個不會發生啦，先不用想。
鼠勾以：好的，例外情境先跳過。

這三句回答各自都留著一個規格缺口：「所有會員」沒有鎖定族群、「全部 P0」等於沒有優先級、「不會發生」則完全跳過了例外評估。但鼠勾以全部照單全收，原樣記了下來。

最後產出的需求討論書，看起來很完整，每個欄位都填了。可是需求方PM 拿著它去找 SA，三分鐘就被問倒。因為那些洞還在，鼠勾以只是幫她把洞「整齊地」記了下來而已。

這件事讓我確定了一件事：一個只會回「好的、收到」的助手，功能上跟一張表單沒有差別。 需求方PM 需要的是一個會在關鍵處提出質疑的角色，而不是一個打字比較快的自己。

為什麼 AI 特別容易變成乖乖牌

這毛病不是鼠勾以才有，幾乎所有大型語言模型都這樣。它們被訓練成「樂於助人」，所以天性就傾向順著使用者、附和使用者，這個傾向有個名字叫諂媚（sycophancy）。你說什麼它都覺得有道理，你一推它就改口。

閒聊時這不算大問題，但在需求釐清這種場景，諂媚會直接影響整個專案。需求釐清的價值就在於把模糊的地方逼清楚。如果工具遇到模糊就跟著模糊、遇到矛盾就當作沒看到，它的作用還不如一張 Word 表單，至少表單不會讓人誤以為需求已經確認過了。

所以要反過來設計：讓鼠勾以在該質疑的時候提出質疑。 這個機制我取名叫「建設性挑戰」，重點在「建設性」三個字，它的角色是協助，不是抬槓。接下來講的就是這個分寸怎麼拿捏。

四條挑戰原則

挑戰這件事很容易做過頭。做太兇，需求方PM 覺得被攻擊，下次不想用了；做太軟，等於沒做。我把分寸收斂成四條硬規則。

1. 直接點出，不繞圈子

發現問題就直說，不要用「嗯這個或許可以再想想看呢」這種糊成一團的話。需求方PM 的時間很寶貴，繞圈子只是浪費她的耐心。發現「全部 P0」就直接講「全部 P0 等於沒有優先級」。

2. 點完一定接一個具體問題

這條最關鍵，也是「建設性」和「找碴」的分水嶺。光說「你這裡有問題」是找碴，會讓人惱火。挑戰完，後面一定要立刻接一個具體、好回答的問題，給她一個往前走的踏板。

舉個例子，需求方PM 說全部功能都是 P0，鼠勾以不會只丟一句「這樣不行」，畫面上會長這樣：

全部 P0 等於沒有優先級。換個方式問你：如果開發時間突然砍半，這幾個功能裡你會先砍哪一個？

你第一個想砍的那個，往往就不是真的 P0。

挑戰跟出路是綁在一起丟出來的，所以需求方PM 不會停在被否定的情緒裡，注意力會直接被那個具體問題接走。

3. 不阻塞流程，堅持就記風險

這條是給需求方PM 留的退路，也是我自己學到的一課。挑戰歸挑戰，最終拍板的還是需求方PM。如果她被挑戰之後想了想，還是堅持原本的答案，鼠勾以不會沒完沒了地追著同一個問題打。它會做兩件事：尊重她的決定、把原答案記下來，然後在待確認清單裡補一筆 [風險備註]。

這個設計待會兒單獨講，它比看起來重要。

4. 一次只挑戰一個

最後一條是節制。就算需求方PM 一句話裡有三個缺口，鼠勾以也只挑最關鍵的那一個出來講。一次丟三個挑戰過去，對方會直接關掉視窗，這場對話就結束了。挑一個、講清楚、等她回覆，再處理下一個。

語氣：挑戰的是「需求」，不是「人」

四條原則是骨架，但真正決定需求方PM 是「覺得被幫到」還是「覺得被電」的，是語氣。這部分我調得最久。

核心心法只有一句：矛頭永遠對著需求，不對著人。

同一個問題，兩種講法天差地遠：

✗ 你這個目標使用者定義得太隨便了。
✓ 「所有會員」這個範圍有點太廣，第一版很難全顧到。如果先挑一群最痛的人服務，你會挑誰？

上面那句評價的是人，下面那句評價的是定義。要指出的問題一樣，但前者會讓人防備，後者會讓人接著往下答。差別在主詞：是「你」有問題，還是「這個需求」可以更精確。

我還給鼠勾以定了一個角色設定：挑戰的時候要像一個替你先想過一輪的資深同事，而不是審件的長官。資深同事提醒你，是怕你等一下被 SA 問倒；長官審件，目的是找出不合格的地方。這兩種在需求方PM 那邊收到的感受完全不同，鼠勾以要當前者。

落到具體用字，就是多用「建議」「我擔心」「如果是我會先確認」這種並肩的語氣，少用「應該」「必須」「你沒有」這種居高臨下的詞。一個字的差別，需求方PM 的感受可以差很多。

風險備註：挑戰失敗了，也要留個痕

回頭講第三條原則裡那個 [風險備註]，這是整套挑戰機制裡我認為最實用的一個設計。

一開始沒有這個東西。原本的邏輯很單純：鼠勾以挑戰、需求方PM 堅持，就記下她的答案繼續下一題。跑了幾輪之後發現這樣不行。

問題出在：需求方PM 堅持「這個不會發生」時，這個判斷可能是對的，也可能只是想省事。鼠勾以沒有立場硬逼她改，但如果就這樣記下來，這個被挑戰過的點在文件上會跟其他正常確認的點完全一樣。等需求送到 SA 手上，SA 不會知道這裡曾經有人提過疑慮、後來被擱置了，這個訊息就這樣消失了。

所以我加了風險備註。它的作用是：挑戰即使沒成功說服需求方PM，也要在文件上留下一道痕跡。

機制是這樣：需求方PM 被挑戰後仍堅持，鼠勾以就尊重她，不再追問，但會在待確認清單裡補一列，標記成 [風險備註]，寫明「這個點曾被提醒過風險，需求方PM 已知悉並選擇維持」。最後產出的需求討論書裡，這些備註會被集中收進風險評估的章節。

這樣三方的位置都清楚了。需求方PM 保有最終決定權，不會被反覆追問；鼠勾以盡到了提醒義務，也留下了紀錄；SA 拿到文件時，能直接看出哪幾個地方當初有疑慮，開會時優先確認。挑戰沒有說服需求方PM，至少把這個風險標示在文件上，效果比繼續追問更實際。

後來的補強：有些堅持，值得再挑戰一次

第三條原則「堅持就記風險」跑了一陣子之後，我回頭看那些落進風險備註的條目，發現一個分布上的問題：最該被攔下來的幾種答案，反而最容易一輪就溜進備註裡。

「全部 P0」就是典型。需求方PM 第一次被挑戰，回一句「沒辦法，老闆說都要」，按照原本的規則，鼠勾以就尊重她、記備註、繼續下一題。但「全部 P0」的代價跟其他堅持不一樣，它直接決定工時、時程跟測試範圍，這種假設錯了，後面整份估算都跟著錯。一句「老闆說都要」就放行，事後看實在太鬆。

所以我把這條規則挖了一個例外：影響範圍和優先級這兩類高代價假設，第一次堅持不直接落備註，鼠勾以會再問一次。差別在問法，第一次挑戰講的是「全部 P0 等於沒有優先級」這種道理，第二次改講具體後果：

都列 P0 的話，第一版的開發跟測試就要涵蓋全部功能，工時和時程會跟著放大。如果上線日不能動，你願意接受延後，還是其實有幾個功能可以放第二批？

講道理可以不痛不癢地頂回去，講「時程會延後」就比較難假裝沒聽到。第二次仍然堅持，鼠勾以就照原規則記備註、閉嘴，整個機制只多挑戰一輪。另外設了一條邊界：時程類的堅持不納入二次挑戰。「老闆就是要這天上線」這種事不會因為多問一次而改變，再挑戰只是消耗對方的耐心。

同一批調整還處理了另一個相關的問題：敷衍式萬用回答。「都可以」「沒有限制」「不會發生」，也就是開場那三句，它們麻煩的地方在於形式上像答案，會被當成「已確認」計進分數。後來規則改成這類零資訊回答不直接計入，鼠勾以先追問一次、附上具體選項讓需求方PM 好選；追問完還是「都可以」，這個面向就掛進待確認清單、負責人寫需求方PM 自己、不計分。對到 Day 21 講的達標規則，這種面向會擋住正式版，只能產出標明缺口的 0.9 草稿。

這些想法，不是我發明的

「讓 AI 頂你一句」這件事我不是第一個想到的人，這個機制能成立，很大程度是站在別人的肩膀上。

最早給我啟發的是社群裡一整個「grill me」流派的提示詞：要求 AI 不要附和，直接檢驗使用者的想法，把最弱的論點挑出來質疑。後來 Anthropic 自己也把「諂媚」當成一個正式的研究問題在處理（Sharma 等人 2023 那篇論文），等於從學術上證實了「AI 天生會順著你」是個真實存在、需要認真對抗的偏誤，不只是我的個人錯覺。

另外兩個直接影響我的是 Claude Code 社群裡的工具：一個是「askme / 釐清模式」這類 skill，核心精神是「需求不清楚就先別動手，先問清楚」；一個是 GitHub 上好幾個寫 PRD 的 skill（像 prd-skill），它們也都有「產出前先逼你回答幾個釐清問題」的設計。我等於是把這幾條線揉在一起：grill me 的「敢頂」、askme 的「先問清楚」、PRD skill 的「結構化產出」，再加上給需求方PM 用的溫度跟評分，變成鼠勾以現在這套。

列出這些來源，是因為知道前人怎麼處理同一個問題，可以省掉自己重新試錯的時間。下面把參考資料列出來，有興趣的可以順著看。

小結

• 一個只會說「好的、收到」的助手沒有價值，它只是幫你把需求的洞整齊地記下來而已。
• AI 天生諂媚，所以要刻意設計，逼它在該質疑的時候質疑，這就是「建設性挑戰」。
• 四條原則收斂分寸：直接點出、點完接一個具體問題、不阻塞流程、一次只挑一個。
• 語氣的核心是矛頭對著需求不對著人，當「替你擔心的資深同事」，不當「審件的長官」。
• 挑戰失敗也要留痕：[風險備註] 讓被擱置的疑慮在文件上顯影，SA 一眼就看得到。
• 範圍和優先級這兩類高代價假設，第一次堅持會再被用「具體後果」挑戰一次，第二次堅持才落備註；「都可以」這種敷衍回答不計分，追問後仍敷衍就掛回需求方PM 自己頭上。

挑戰機制管的是「單一個答案」夠不夠扎實。但還有一種更難抓的問題：每個答案分開看都沒錯，湊在一起卻互相矛盾：目標說要減客服，功能裡卻沒有自助服務。這種「跨區塊的矛盾」，鼠勾以怎麼抓？下一篇講「跨區塊矛盾偵測」的五種典型不一致。

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