系列：30 天打造企業級 PLM｜面向：全端｜素材：全系列

30 天前的問題，現在可以回答了

Day 1 的問題是：從 0 打造企業系統可能嗎？走完 30 天，答案是可能，而且系統已經在跑。約 83,000 行後端、77,000 行前端、84 張資料表，撐過 250 VU 壓測，接住了從 Oracle Agile 考古出來的十幾年資料。

不過這個系列真正想說的從來不是「可能」——「可能」是個廉價的答案，任何一篇技術部落格都能給你。這 30 天想留下的是可能的代價與細節長什麼樣：哪些地方比想像中簡單（REST API、前端元件），哪些地方比想像中兇惡（交易傳播、快取失效、十幾年資料的考古），以及在每一個分岔路口，決定往哪走的判準是什麼。

全系列技術地圖

這張地圖刻意按「階段」而非「模組」分區。七個階段的順序不是功能的重要性排序，是依賴關係的排序：沒有 metadata 地基就做不出動態表單，沒有動態表單就沒有流程引擎可掛，沒有 E2E 就不敢碰前面任何一層。右側三條主軸是回頭看才浮現的東西——當下每天都只是在解眼前的問題，寫完 30 篇才看見它們一直在同一個位置。

全系列架構演進總結：從 EJB 巨石到現代輕量架構

回顧這 30 天，我們不僅完成了一套系統，更完成了一次從 2000 年代 J2EE/EJB 沉重體系 到 2026 年現代雲原生輕量架構 的跨時代洗禮：

商業邏輯設計回顧

全系列反覆出現的一課：技術取捨的背後都是商業取捨。失敗策略是風險觀（Day 11/12），遷移範圍是成本觀（Day 23），權限粒度是管理成本觀（Day 6），retention 是儲存與分析的平衡（Day 22）。而貫穿一切的架構主軸是把規則做成資料：欄位（Day 4）、流程（Day 9）、路由矩陣（Day 10）、trigger（Day 11）、匯入對應（Day 26），讓業務自助、IT 治理。這個決定在最後一天還會再賺一次利息，見 AI roadmap。

十大踩坑排行榜

全部是前面 29 天出現過的坑，這裡只做回顧排名，不出新料。評選標準：偵錯時長 × 症狀與病灶的距離。

1. @CreatedBy cascade 清空登入者帳號：「Item Type 不見了」的東牆西牆（Day 8）
2. REQUIRES_NEW 讀不到未 commit 簽核紀錄：自動加簽永遠找不到人（Day 12）
3. afterCommit 回呼裡 REQUIRED 寫入靜默蒸發：log 說做了、資料說沒做（Day 12）
4. vendor chunk 細拆 → 生產白畫面，dev 模式永遠測不到（Day 2）
5. Trigger Previous Step 整包遺失：從 dangling blob 考古救回（Day 11）
6. 帳號鎖定 projection 斷流：資安功能整組靜默失效（Day 7/28）
7. 軟刪除佔用唯一鍵：刪了卻建不回來的 409（Day 7）
8. Oracle CLOB + SELECT DISTINCT 的 ORA-00932：H2 測不出來（Day 27）
9. 權限/選單更新使用者還是舊畫面：快取失效沒有配套（Day 19）
10. entity 直接序列化成 API 回應：循環引用、lazy 連鎖查詢，@JsonIgnore 打地鼠打出百餘處彈痕（Day 5）

落榜但值得一提：單筆也包陣列的統一回應——前端報錯但其實成功（Day 5）、SSE fallback 沒判新鮮度（Day 19）、Flyway 改已 applied migration（Day 27）、無權限欄位的傳輸設計（Day 8）、path 授權規則膨脹（Day 6）。十四選十，每一條的共同標籤都是：沒踩過就不知道，踩過就不會忘。

未來 roadmap：AI 的六個切入面

開發階段 AI 幫我們寫系統（心路歷程篇會講），下一階段換 AI 進到系統裡幫使用者。

1. AI for User（使用者側）：自然語言查詢（「找出上季改過的電源料」直接變 Day 16 的搜尋條件）、智慧簽核輔助（自動摘要這張變更單改了什麼、給簽核者重點提示）、對話式操作
2. AI for Setup（設定側）：自然語言描述需求，AI 產生表單欄位、簽核流程、trigger 規則草稿，管理員審核後套用。Day 4/8/11 的 metadata-driven 地基正好是 AI 最好的操作介面：規則都是資料，AI 產草稿、人拍板
3. AI for Maintain（維運側）：錯誤指紋的 AI 根因診斷（直接接手 Day 22 的規則式解讀，格式與流程都鋪好了，換個解讀器）、效能樣本異常偵測、log 摘要
4. AI for Analytics（資料側）：資料品質偵測（重複料號、異常 BOM 自動盤查）、變更影響深度分析（這次改版牽動哪些產品線）、簽核卡關洞察
5. AI for Knowledge（知識側）：十幾年的變更歷史與簽核意見是公司最深的工程知識庫。做成 RAG 之後直接問「上次這顆料為什麼改版」，把 PLM 從紀錄系統變成知識系統
6. AI for Compliance（合規側）：簽核合規自動檢查（該簽的人簽了嗎、順序對嗎）、稽核報告草稿自動產生

還在思考的候選：AI for Migration，AI 讀 schema 猜欄位語意、產抽取 SQL 草稿，把 Day 23–24 的手工考古自動化。

未來 roadmap：架構面

• 分散式架構：水平擴展與節點複製（Day 2/29 埋的伏筆）、快取層外移（本地快取到分散式快取）、檔案儲存抽象化再進一步（Day 25 的 provider 介面到物件儲存）、匯入匯出批次拆獨立 worker。以及最重要的取捨：什麼規模才值得走到這一步。250 VU 無斷崖的單機，跑道其實還很長
• 待實作清單：AML 功能完整版、視覺化設計器演進、i18n key 的 CI 檢查

給想自建 PLM 的人的建議

該自建的訊號：需求收斂（你只要瑞士刀的三個功能）、領域理解深（團隊裡有人被 PLM 磨過整個職涯）、有被商用授權費長期綁架的痛。

不該自建的訊號：需要 CAD 深度整合與 3D Viewer（那 20 年的累積買比做便宜）、組織隨時要跟業界最佳實踐對齊、沒有長期維護的人力承諾。自建的總成本在第二年才開始付。

最值得先投資的三件事，我的排序是 metadata-driven（它是之後所有彈性的地基）、E2E（它是之後所有重構與升級的安全網）、監控（它是上線後你唯一的眼睛）。

心路歷程

從收到 Oracle 那封分手信，到自己的系統掛上生產環境，這一路最深的感受不是技術的難，是孤獨。沒有原廠支援，沒有 Stack Overflow 上現成的答案（誰會po「PLM 簽核引擎的交易傳播」的問題呢），每個坑都要自己爬出來，爬出來還要自己寫下來，因為下一個踩坑的還是自己。

最挫折的一刻，是發現 Previous Step 整包程式碼蒸發的那晚，那種「我做過的事情不存在了」的荒謬感。最有成就感的一刻，不是壓測全綠也不是上線成功，是第一張變更單全流程跑通的下午。開單、簽核、放行、改版、Redline 全部亮起來的瞬間，這堆表和程式碼突然變成了一個「系統」。

AI Coding 改變了什麼？Form 與流程設定改成 Canva 式視覺化介面，過去要排一季的改版只花不到一週。AI 把小團隊自建企業系統從勵志口號變成可執行的計畫。但這 30 天的踩坑排行榜也是誠實的證詞：AI 不會替你扛住交易傳播與快取失效的坑，判斷力還是自己的。AI 放大的是產出速度，不是領域理解，而 PLM 恰好是領域理解占七成的系統。Day 1 就說過了，30 天後我更確定。

「範例專案」與「企業系統」的距離，是這 30 天每一篇的踩坑段加起來的總和。真正花時間的從來不是功能，是細節與信任。如果重來一次，會做一樣的決定嗎？會。但我會第一天就把 E2E 和監控建起來，而不是第三週。

給同樣被商用軟體 EOL 逼到牆角的團隊一句真心話：分手信不是災難通知，是一次被迫誠實盤點需求的機會。盤點完你可能發現該換家、該上雲，也可能發現，你需要的那 20%，自己做得出來。

完賽感言

30 天寫作本身也是一個專案。囤稿策略（概念篇與 Migration 篇先寫完）救了賽程中段需要重新驗證程式碼的日子；素材紀律（每個坑當下就記錄，含錯誤碼與 commit hash）讓踩坑段全部有據可查；寫到斷炊的日子，靠的是回去翻執行紀錄。寫作和寫系統一樣，靠的不是靈感，是留下來的證據。

謝謝讀到這裡的你。程式碼會過時，但「症狀在東邊、病灶在西邊」的除錯直覺、「技術取捨背後是商業取捨」的判斷框架，希望能多陪你幾年。

我們下個系列見。

——凱文大叔