AI 時代，軟體公司真正該重用的可能不是 Code，而是工程能力

每個接客戶軟體案子的公司，都很想做同一件事：把不同客戶的共同需求收斂成 reusable modules，然後期望下一個客戶進來，只要小改一點就可以 deliver。

但做軟體這麼多年，這個願望我幾乎沒有親眼看過真正實現。

原因也很簡單。不同客戶的硬體不同、架構不同、需求不同，尤其車用軟體又跟底層硬體和 E/E Architecture 綁得很深。原本以為可以 reuse 的 component，到了下一個客戶，常常改到最後還不如重寫。

但最近我反過來想到一個問題：

為什麼鴻海可以一直複製製造上的成功？

鴻海做 iPhone、MacBook、機器人、AI Server，這些東西用的零組件、製程、設備、產線通通不一樣。

顯然不是把 iPhone 的產線改一改，就可以拿去生產 AI Server。

真正可以 reuse 的，應該是幾十年製造累積下來的 know-how。

做過夠多產品之後，就知道哪裡容易有坑、什麼設計不容易量產、怎樣的材料跟接合方式比較可靠、怎麼提高良率、怎麼測試、怎麼從 prototype 一路 ramp-up 到 mass production。

Reuse 的不是產品本身，而是把產品做出來的經驗。

軟體其實也是一樣。

我們幫 OEM A、B、C 做的車用軟體可能差很多，甚至 Hardware Platform 都完全不同，code 真的沒辦法 reuse。

但做久了之後，其實會發現大家踩的坑大差不差。

Architecture 怎麼切、service 怎麼定義、哪些 dependency 之後一定會出問題、什麼東西 Unit Test 看不出來，到 System Integration 才會爆炸。

這些經驗以前最大的問題是：都長在人身上。

一個資深工程師做了十年，踩過幾百個坑。他一走，公司失去的不只是「一個很會寫 code 的人」，而是連他踩過的幾百個坑一起消失。

但 AI Coding Agent 出現之後，我覺得這件事情開始有不同的解法。

Project 做完，不應該只留下 repository。

我們可以把過程中累積的 architecture decisions、coding rules、踩過的坑、root cause、test strategy，寫進 CLAUDE.md，或整理成 Coding Agent 可以 access 的知識庫。

而且不能只寫「我們當時怎麼做」，更重要的是：

為什麼這樣做？當時有什麼限制？試過什麼方法失敗？換一個 Hardware Platform 之後這個做法還成立嗎？

這些才是真正有價值的東西。

所以我現在覺得，AI 時代做軟體 Platform，真正值得追求的可能不只是：

Reusable Code

而是：

Reusable Engineering Knowledge

我甚至想到一個很極端的 KPI：

如果明天 OEM A 的整個 team 全部離職，只留下 repository、累積下來的知識庫和 Claude Code，換一批全新的人進來，需要多久才能恢復 100% 戰力？

如果答案還是一年，代表大部分 know-how 還是在人腦裡。

如果可以縮短成三個月、一個月，那才代表這些 project 的經驗，真的開始變成公司的資產。

以前我們一直想辦法讓下一個 Project reuse 上一個 Project 的 code。

現在我反而覺得更值得想的是：

下一個 Project，能不能不要再踩一次上一個 Project 已經踩過的坑。