從一個語言延伸到多語言，然後好好活著
一句話總結：先把一個語言做到完美（黃金版本），再用它當標準延伸到其他語言。Proto 是活的東西，不維護就會死。
結論先講：同時開發五個語言的 Proto 是最常見的錯誤。正確做法是一個一個來——先完成黃金版本，通過 Gap Analysis，再以它為標準延伸到其他語言。
黃金版本：先做一個做到好
選團隊最熟悉的語言，完整實作所有 10 個面向，通過 Gap Analysis 確認沒有落差，打上穩定版本 tag。這就是你的黃金版本。
黃金版本的價值是：它定義了「完整」的基準線。其他語言版本只需要回答一個問題——「黃金版本裡的這個面向，在我的語言裡怎麼實作？」
跨語言不是「完全一樣」
有些東西是跨語言的共同標準：統一的錯誤回應 JSON 格式、日誌欄位命名、Commit message 規範。
有些東西是語言特定的：Django 用 structlog、Spring Boot 用 logback、Express 用 winston——同樣是結構化 JSON 日誌，實作方式完全不同。
重點是：問題是固定的，答案隨語言而異。 每個語言版本都要回答同樣的問題（怎麼做認證？怎麼管環境變數？怎麼處理錯誤？），但答案可以不同。
版本管理
Proto 也需要語意化版本：
- Major：框架大版本升級（Django 4 → 5）或結構性重大變更
- Minor：新增面向或功能（加入 RBAC 範例）
- Patch：修正錯誤、更新依賴
每個穩定版本打 Git tag。新專案建立時記錄「從哪個版本複製」，以後需要追溯就有依據。
Proto 的四種死法
太重（Over-engineered）：clone 下來有一半的 code 要刪。原因是把「可能會用到」的東西都塞進去了——WebSocket、GraphQL、Message Queue。Proto 只放「每個專案都需要」的基礎建設，進階功能用擴展包。
太舊（Stale）：依賴版本過舊、安全漏洞沒修。沒人負責維護。解法：指定 Owner，設定 Dependabot 自動提 PR，每月檢查安全更新。
脫離現實（Disconnected）：Proto 的做法跟實際專案的做法已經分道揚鑣。每季做一次 Proto Review，將最近幾個新專案跟 Proto 對比。如果大多數專案都改了 Proto 的某個部分，那部分在 Proto 裡可能需要調整。
落差累積（Gap grows）：Notion 裡寫了一堆，Proto repo 裡很多沒做。用 Gap Analysis 定期對帳。
Proto 的演進流程
Proto 不是建完就不動了。正確的演進流程：
- 在實際專案中發現更好的做法
- 在 Proto repo 開 issue 討論
- 達成共識後更新 Proto
- 發布新版本
- 通知團隊——但不強制舊專案升級（COPY, not Reference）
依賴更新也有節奏：每月查安全更新、每季更新 minor 版本、每年評估 major 升級。
系列總結
五篇走完了 Proto 規劃的全貌：
| 篇章 | 核心重點 |
|---|---|
| 為什麼需要 Proto | COPY not Reference，四類分類，架構邊界 |
| 10 維度 | A-J 共 10 個面向的完整性檢查 |
| 各 Track 標準 | B2E / F2E / App 各自的核心需求 |
| Gap Analysis | 四步驟找出規劃與實作的落差 |
| 多語言與維護 | 黃金版本策略，版本管理，防止 Proto 死掉 |
Proto 的終極目標不是「有一套漂亮的模板」，而是讓團隊在新專案的第一天就能專注在業務邏輯上。
COPY, not Reference. 專案完整性 > DRY。
系列文章：
- Proto 規劃（一）：為什麼需要 Proto
- Proto 規劃（二）：10 維度完整性檢查
- Proto 規劃（三）：各 Track 標準
- Proto 規劃（四）：Gap Analysis
- 你在這裡 → Proto 規劃（五）：多語言延伸與維護
延伸閱讀：
「Proto 就像菜園——你不澆水它就死了，但只要你照顧它，每個季節都會有收穫。」