> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh-hant/2025/w50-what-should-the-team-do-next-year-in-ai-coding.md).

# W50-明年在 AI Coding 上團隊應該幹什麼

這週讀到 a16z 和 OpenRouter 的[《State of AI》](https://openrouter.ai/state-of-ai)，他們用 OpenRouter 平臺上 100 萬億級別的真實 token 做了實證研究。 看了個開頭就有種時間錯亂的感覺，o1 正式版是 2024-12-05 發佈，離現在也就剛好一年。推理型模型承載的 token 佔比在 2025 年一路上升，最近已經超過一半。

假設未來幾年模型能力仍會持續變強（多模態、記憶、Agentic 都會繼續外溢），那團隊在 AI Coding 上的核心目標，就不應該只是引入幾個工具、攢幾套提示詞，而是建設 AI-Ready 的工程基礎。讓模型越強，我們的交付能力越能被解鎖。

讓工作可以長期發生在主航道上，以下五個方面都具備可積累性。

**1）架構**

一個講不清道不明的項目，AI 也很難發揮。不僅消耗大量 token，而且極易因忽略隱式依賴而引發迴歸 Bug。前端架構裡的主要問題，就是視圖和業務邏輯混在一起，邏輯與副作用的糾纏，易變的和不易變的拆不開。不是用了 MVVM、MVC 就能解決的。

項目應該能明確回答“核心代碼是什麼”。核心代碼承載所有業務邏輯與狀態演化，理想情況下，是純函數、框架無關、零環境依賴、可單測、輸入輸出確定的。其餘部分處理網絡I/O、副作用、UI渲染。這樣 AI 才有穩定的著力點，改動也更可控。

**2）上下文顯性化**

如果缺乏歷史背景，AI 也無法理解為什麼代碼中存在某些奇怪的 hack。文檔和註釋的重要性，已經不只是知識沉澱，而是直接影響代碼生成質量。

更具體一點，業務領域信息、架構約束、技術棧偏好、團隊工程規範都應該被顯性化，最好能沉澱成 AI 更容易消費的形式，例如 ADR、約束清單、README 的“不可破壞項”，配合合適的工具鏈，把上下文餵給模型。

**3）約束左移**

我很認同通過編譯器/靜態分析把問題左移的思路。嚴格編譯的代表語言是 Rust，但前端多數場景並不是非要 Rust 才能避免事故。真正的問題是 TS 的語言優勢沒有被充分地用起來。這個主要原因是歷史上為了更快的普及TS，允許以很寬鬆的方式使用TS，但事實上很多項目在類型和編譯約束上並沒有開全。

TS的 strict 模式是基礎，是不可協商的，必須激進地禁止像 any 這種無意義類型。統一自定義 Lint 規則是必要的，編寫自定義 ESLint 規則以強制執行架構邊界，統一語言風格，例如強制 Composition API 、禁止跨層依賴。

**4）程序化驗證**

代碼生成會越來越便宜，真正昂貴的是驗證代碼是否正確，讓低成本驗證的工作先發生。這既順應了 TDD 的思想，也解決了過往 TDD 落地成本高的痛點。

有了良好的架構就能很好地識別出核心代碼，對核心代碼做單測覆蓋就變成了性價比很高的事情。前後端是依據契約完成協作的，加入 Zod 保證對 Schema 的運行時驗證是有必要的。前端和 QA 是通過測試用例協作的，在實現前寫清楚驗收條件或自然語言測試用例，這看起來很無趣，但可能很有效。

**5）可觀測性與排查**

客訴響應、線上問題排查會隨著組織擴張和分工細化效率越來越低。各個服務日誌信息分散，群裡來回收集事實信息就能耗掉幾個小時。

打通日誌與可觀測性，讓 AI 能看到完整上下游數據。至少做到結構化日誌、統一 trace、關鍵鏈路可回放。先把事實收集自動化，工程師的響應才能更敏捷。同時也是 AI 自動化診斷的必要前置。