提案先做得出來，也要說得出何時該停

先寫想改變的行為

我以前寫需求，會先把功能和上線時間填滿。文件來回幾輪，最後才發現大家想像的畫面根本不同。現在遇到這種分歧，我先把問題縮成一句：哪種人，在什麼情境，要從哪個行為走到哪個行為。

拿匯入 CSV 的小工具當例子，我會先寫「使用者匯入資料後，看懂哪些項目需要回頭檢查」。這是一個示範需求。先把想觀察的行為寫出來，才知道原型要做哪幾步，不會一開始就把所有圖表和自動修正都塞進去。

接著我讓 AI 做一個能點的殼：只用假資料、不接真實服務，成功、錯誤與空白狀態都要看得到。先列畫面結構，再做核心動作。這一輪我關心的是流程點不點得通，排版可以慢慢修。

會議上我讓對方直接操作，看他在哪一步停住、以為下一步會出現什麼。我會記下這些分歧，回頭補進需求。以前卡在同一句話的不同解讀，能點的畫面讓討論有了共同參照，也讓後面的文件比較好寫。

但原型點得通，還沒回答值不值得做。我會再填三格：預期行為、主要證據、停止線。證據先選一個主要訊號，寫清楚基準、怎麼觀察、觀察多久。沒有基準，就先用便宜的小測試取得它，不急著替結果訂漂亮目標。

以剛才的工具為例，可以先約定「兩輪測試後仍無法指出待檢查資料，就回頭重看問題」，或「必須逐筆解釋才成立，就不擴大功能」。這些是示範條件。我在意的是看到結果前先約定，而不是結果不好才另找一個加功能的理由。

重要提案上桌前，我會另外留一輪紅隊。給 AI 會議要做的決定、方案主張、現有證據與限制，先拆主張、證據和隱含假設，找最弱的三個環節。沒有的資料就寫「尚無」，第一輪先不改簡報。

第二輪再站到決策者、執行者與受影響者的位置追問。我把問題收成補證據、縮主張、設停止線三種動作，再自己判斷哪些該改。這輪對我有用的地方，是提早知道哪句還不能保證；AI 提出的反例，我也會回頭查。

對齊之後，我把已確認的流程、未解問題、下一個驗證與負責人留下來。要進正式開發，再補資料處理、權限、例外、效能與驗收條件。原型讓大家看見方向，文件把邊界留下；兩份要能互相找到。

我也會在展示時先說清楚哪些是假資料、哪些還沒實作。材料如果含他人的資料或未公開內容，先確認能用的範圍，再整理必要的去識別化摘要。這樣談下一步時，大家知道現在拿到的是什麼，也知道還缺什麼。