本篇是故事一的「踩雷」篇。

本篇要回答：技術問題問得很專業，為什麼專案仍可能從第一天就開始走偏？

當時發生了什麼

場景是 AOI（Automated Optical Inspection，自動光學檢測）專案的廠勘現場，我的第一反應是列出一整排問題：

• FOV（Field of View，視野）要多大？
• 用 M 還是 C-mount（鏡頭接環）？
• 可以用線掃（line scan）嗎？
• 可以用 GigE 嗎？
• 需要防爆箱嗎？

（本系列案例皆已去識別化，不對應特定公司、客戶與產品，情節細節經過簡化與調整。）

這些問題單獨看每一題都成立，也都是實際選型時遲早要回答的。但當下沒有人能立刻回答另一組問題：

• 要檢出什麼缺陷？缺陷的最小尺寸與外觀特徵是什麼？
• 工件如何移動？產線速度多快？安裝空間多大？
• 可接受的誤判率、漏判率與停線風險是多少？
• 判定結果要如何送往後段設備？

於是出現一個奇怪的現場：技術討論熱烈進行，規格數字滿天飛，但整個專案「要交出什麼結果」還是一片空白。

我原本怎麼判斷

當時我相信的局部證據是：問題越具體，代表越專業、越接近落地。規格表、型錄、解析度換算公式都有標準答案，查得到、算得出來，做起來有進度感；而「要檢出什麼缺陷」這種問題沒有標準答案，還得去找人談，自然被排到後面。

背後的執行假設是：只要先把硬體規格收斂，需求自然會跟著清楚。這個假設在當下看起來合理，因為每一個規格問題確實都會影響最後的選型——它們不是錯的問題，只是被放在錯的時間。

我怎麼查證或重現

把當時的提問清單重新攤開（依廠勘筆記與記憶回收整理，細節已去識別化），逐題分到三個欄位：

分完之後的結果很誠實：我的清單全部落在第一欄。

區分一下證據等級。已確認事實：當時的提問集中在規格與零件層。合理推論：這些問題的答案，每一題都依賴第二、三欄尚未確認的內容——最小缺陷尺寸沒定，FOV 與解析度算不出來；工件移動方式沒定，線掃或面掃無從選起。執行假設：若當時先確認「最小缺陷尺寸與產線速度」，大部分規格問題會自己收斂。

今天留下什麼方法

留下一個提問前的自我檢查：

這個技術問題的答案，會因為哪一個尚未確認的結果而改變？

列得出來，就先去確認那個結果；列不出來，代表這一題其實還不急。

本篇結論：

問題不是我問了太多技術細節，而是我還沒確認那些細節究竟要替哪個結果服務。

下一篇（Day 02）回頭處理另一個當時被我簡化的對象：利害關係人。他們不是需求轉接頭，而是最後要承擔結果的人。