某次會議上，大家在討論 AI 數據標註平台目前到底卡在哪裡，各自丟出幾個看法。我聽著聽著，開口說：「現在這個 AI 數據標註平台應該打掉重練，現在真的太疊床架屋了。不如重新梳理一次，直接做一套新的。」

話一出口，S 點點頭，其他人也沒什麼異議。

於是，「打掉重練」就這樣成了一個決定。

現在回頭看，這大概是我產品經驗還很不足時，做過很典型的一種決策。

一句「打掉重練」，其實暴露的是我太早開始想解法

當時為什麼會這麼自然地講出「打掉重練」？因為舊系統真的很亂。功能一層一層加上去，流程也不是一開始就設計好的，很多東西都是隨著專案需求慢慢長出來。站在開發或產品的角度看，很容易產生一種感覺：這東西已經沒救了，與其繼續補，不如重新來。

問題是，那個時候的我，其實還沒有真正搞懂使用者現在怎麼工作，也沒有完整理解整個標註流程到底卡在哪裡。我只是先看到了「系統很亂」，然後直接跳到「所以要做一個新系統」。甚至在決定重做之後，我還一股腦兒跑去研究外面的標註平台。我看別人的資料怎麼管理、任務怎麼分派、標註結果怎麼累積、品質怎麼控管。看得越多，就越覺得：「我們也應該有這些功能。」然後系統開始越想越完整。原本只是想改善內部工具，想著想著，產品方向甚至開始靠近一套完整的 SaaS 服務。但我們一直沒有真正停下來問：我們現在到底在解決什麼問題？

我們不是在做標註 SaaS，我們是在做標註生意

這個差異後來看起來很明顯，但當時我們沒有想清楚。我們並不是一家把「標註平台」賣給其他公司的 SaaS 公司。我們真正的商業模式，是承接資料標註專案。換句話說，平台最重要的任務，不是做到市場上功能最完整，也不是看起來最像一個成熟 SaaS。它最核心的價值其實很務實：**讓內部標註流程更順、成本更低、管理更容易、交付更穩定。**也就是降本增效。可是當時身為產品／開發經理的我，沒有先把這件事情想清楚。我先愛上了一個解法，才回過頭來替它找理由。這也是我後來越來越警覺的一件事：有時候我們以為自己在解決問題，其實只是在打造一個自己很想做的東西。

打掉重練了兩次，都沒有成功

決定重做之後，我們就真的開始如火如荼打造新的系統。而且我們不是想改善其中一段流程，而是希望：**用新系統完整取代舊系統。**這代表什麼？代表新系統的最低標準，就是至少要擁有舊系統原本已經存在的功能。舊系統再怎麼亂，它都是在真實專案裡一點一滴長出來的。那些看起來奇怪的功能、很醜的流程、甚至一些莫名其妙的例外處理，很多其實背後都有歷史原因。想一次全部重建，門檻自然非常高。結果也很直接，舊平台還是一直被大家使用，屹立不搖。反而是新平台蓋到一半，像一座施工中的廢墟，斷垣殘壁。

而且不是一次。

是兩次。

第一次失敗時，我們認為是 RD 團隊能力不夠。第二次，我們又覺得，是不是因為自己競品研究做得不夠，沒有真正理解外面的產品怎麼設計。也差不多是在那段時間，我們一直在討論：這到底應該是一套內部工具，還是一個 SaaS 產品？我們一直試著把「解法」變得更好。但真正沒有改變的是：我們還是沒有把問題想清楚。

第三次，我們不再想一次取代全部

直到第三次，我們才換了一個做法。我們不再先問：「新版系統應該長什麼樣子？」而是回過頭來看整個工作流程：
現在大家最痛的是哪一段？哪個問題真的影響效率？哪一個問題如果改善，使用者會立刻有感？哪一個改變可以先做，而且風險最低？這一次，我們沒有再想著一口氣把舊系統全部取代。而是先找到流程裡最值得處理的一小塊，把它做好。接著再做下一塊。新的做法、新的工具，就這樣慢慢滲進原本的工作流程裡。最後真的發生取代時，甚至不像是一場「系統大改版」。比較像是有一天回頭看，才發現：原本那套做法，大家已經不再用了。這次真正成功的原因，不是我們第三次終於把系統做得比較厲害。而是我們終於先搞清楚：到底哪一個問題值得被解決。

到了 AI 時代，這個陷阱反而更容易發生

我後來一直覺得，這段經驗到了 AI 時代，反而變得更重要。因為現在「做出一個東西」真的太容易了。以前想做一套系統，你還要先考慮工程人力、開發時間、技術成本。現在很多時候，只要描述需求，AI 很快就可以幫你長出 prototype，甚至直接開始寫功能。於是很容易產生一種誘惑：**既然舊的東西這麼麻煩，不如重新做一個。**但問題是：產出變快了，問題真的有被解決嗎？

甚至有時候，AI 讓我們更容易跳過原本就應該做的思考。流程還沒搞懂，就開始做工具。使用者痛點還沒釐清，就開始做 Agent。組織裡已經有十套工具了，再做第十一套、第十二套。最後工具很多，但工作反而變得更碎。

有趣的是，AI 其實更適合先拿來理解舊東西

以前大家很想打掉重練，其中一個原因，是整理舊東西真的很痛苦。看 legacy code 很痛苦。補文件很痛苦。理解為什麼當年會這樣設計，也很痛苦。把散落在不同人腦袋裡的流程重新拼回來，更痛苦。但這些事情，現在反而是 AI 很適合幫忙的地方。AI 可以協助閱讀舊程式、整理文件、追蹤功能之間的關聯、把散落的資訊重新結構化，也可以幫忙把原本模糊的流程畫出來。也就是說：**以前最想逃避的「理解成本」，現在反而正在快速下降。**所以我現在會覺得，如果第一個反應還是「這個太亂了，乾脆重做」，反而更值得停一下。也許真正應該先做的，不是再蓋一套新的。而是利用 AI，把原本很難理解的東西先理解清楚。

手上有了 AI 大鎚子，很容易看什麼都像釘子

AI 很強，也因此很危險。因為當一個工具可以快速產出東西時，我們很容易不知不覺變成：這裡做一個 Agent。那裡做一個小工具。這個流程很麻煩，重做一套。那個介面不好用，再生一個。手上多了一把 AI 大鎚子之後，很容易看什麼問題都像一根釘子。但工具變多，不代表問題變少，有時候甚至剛好相反。

所以現在如果再遇到類似的狀況，我反而不會那麼快討論「要做什麼」，我會先問：

現在卡住的，到底真的是工具不夠，還是我們還沒有理解流程？

這個問題如果不做新工具，有沒有其他解法？

如果真的需要重建，流程裡最關鍵、最值得先處理的是哪一小塊？

我們現在是在解決一個真實存在的問題，還是只是因為 AI 讓它變得很好做，所以忍不住想做？

這幾個問題，不一定會讓事情做得比較快，但通常可以讓我們少做很多不需要做的事情，後來我越來越篤定一件事：**快，不代表對。**AI 當然可以幫我們更快產出，但我覺得它更有價值的一種用法，是幫助我們更快理解原本很難理解的問題。當「把東西做出來」變得前所未有地容易，真正困難的，反而不再只是執行。而是：我們到底知不知道，自己正在解決什麼問題。