2019年，專案會議上，幾位工程師夥伴包含我自己興高采烈的討論：「如果我們把這個標註工具做得更完整，是不是可以直接賣給其他企業，做成一個SaaS服務？」會議室裡的人眼睛都亮了，你一言我一語，開始討論起要加哪些功能、介面要做得多有「產品感」，才能拿出去跟市面上其他標註工具比。

同時，我腦中卻也浮現前幾天在標註現場看到的畫面：一位肢體障礙身障夥伴，手部有些張力，沒辦法像我們一樣穩定地用滑鼠拖拉出一個框，只能靠兩根手指，一下一下地點兩個點，慢慢框出範圍。那個畫面，跟會議室裡正在討論的「產品規格」，中間好像隔著一條很大的縫。

什麼都要，反而忘了眼前真正要解決的問題

在社會企業裡，同時要考量商業之外的公益價值，情況較為複雜。那場會議討論到後來，有人開始提議整個開發流程要比照外部產品的規格走，重新設計架構、補足文件、規劃版本release，聽起來都很合理，卻沒有人回頭問一句：眼前這位身障夥伴，需要的到底是什麼。幾經若干次的再設計、再開發，耗費資源與時間，RD開發的東西沒有一次幫上忙，年底的大清掃反省，RD的區塊貼了滿滿「被許願」的便條紙。

直到後來，我才決定與理解先聚焦在最核心的事：用科技的力量，讓有身障夥伴的數據標注工作做得更順。想清楚這一點之後，很多原本卡住的決定反而變得簡單，該優化哪個操作流程、該自動化哪個步驟，答案自然浮現出來。才有機會讓身障夥伴本身透過更順手的工具，標註效率提升，及業務PM一筆一筆確認標註成果合不合格的驗收流程也被自動化，整體案量才有辦法衝到四倍。

驗收標準就是將問題落地解決的關鍵

一開始，我沒辦法定義出一套很仔細的驗收標準，但我發現真正重要的不是先設計出一套很完整的驗收流程，是先把問題定義得夠清楚，這筆標註到底要解決什麼問題，符合這個目的，才算合格，如果連問題都講不清楚，驗收就只能靠人的各自感覺，PM說的有理，RD說的也有理，任何一個外在工具的成果拿來比較也合理，開發永遠如履薄冰。

這跟現在很多人用AI也是一樣的處境。不管是Vibe Coding，還是比較講究規格先行的Spec-Driven Development，工具再怎麼新，都跳不過同一個問題：要解決的是什麼？什麼叫做這件事做對了？如果連這個都講不清楚，就算把工作交給AI去做，拿回來的東西還是得自己整個重新檢查一遍，跟自己做沒有兩樣，也稱不上真的把事情交出去。

問題定義清楚了，驗收標準自然浮現，才敢真的把事情交出去，不用每一次都自己重做一遍。但驗收標準解決的是『怎麼判斷這件事有沒有做對』，沒解決另一件事：AI要怎麼一開始就做得離想要的不遠，這中間還缺了一塊，那就是習慣說Why。