一開始，我以為這會是一個很單純的 專案設計過程 …… 先把需求與架構想清楚，再把規格文件整理完整，接著按照 Task 一個一個實作。尤其在 AI 開始大量參與開發之後，我更相信前期規劃的重要性：既然 AI 可以很快幫忙整理、比對、分析，那麼先把規格打磨得完整一些，後面的實作應該會更順利。 結果，我和 AI 一起把這件事情做得太認真了。最後甚至認真到，差點忘了我們原本是要做一個可以運作的系統。 # 🏗 起點：我以為把規格做好，專案就會更穩 為了還有機會能夠實現「跨足半導體產業」的這個職涯發展目標，我在近期展開了一項以「半導體晶圓廠的數位孿生模擬系統建構」為主軸的技術展示專案。 在真正開始寫程式之前，我先花了大量時間整理既有設計。這些內容原本也是我在另一段長期 AI 協作過程中逐步建立起來的，涵蓋資料庫、事件定義、派工邏輯、部署方式等。 問題是，多輪討論留下來的設計，難免會有前後不一致、細節缺漏，甚至某些地方只是為了讓文件看起來完整，而被暫時補上的內容。 所以我的第一個想法很自然： 先請 AI 把文件好好審一遍。第一輪發現問題，就修正；修完，再審；再發現問題，就再修。每一輪看起來都很合理，直到後來，我開始發現，這套流程正在悄悄改變自己的目的… 原本我們想確認的是： 「這個系統到底怎麼做？」 後來卻變成： 「這份文件和另一份文件，是不是完全一致？」 # 🌀 當品質控管開始檢查自己 最麻煩的地方是，每一次審查都真的有成果。AI 找出了矛盾，我們修掉它；補上缺漏，我們又增加對應的規則與紀錄。於是文件越來越完整，審查機制也越來越細緻。 可是回頭看最後幾輪時，我發現一個很不舒服的現象： 後面的很多問題，其實不是原始設計造成的，而是前面的審查與修正自己製造出來的。 我們建立了一套自我檢查、自我糾錯的機制，最後卻開始花大量時間檢查自己昨天留下來的東西。 更尷尬的是，真正需要被實作的程式，依然沒有因此更接近可以執行。 那一刻我才意識到，文件的「完整度」和專案的「進度」其實是兩件完全不同的事情。 有些工作看起來很像品質控管，但如果它不能幫助系統更接近可驗證的狀態，就值得重新檢查它存在的理由。 # 😶 AI 很快，但它不會替我決定「現在到底該做什麼」 這次經驗也讓我重新思考 AI 在專案中的位置。AI 很擅長分析、整理、比對與提出修正建議。只要我繼續提供問題，它就能非常有...