「AI 友善語言」這個帳，我來幫你算一下
看到 Mog 這個語言，直覺反應不是「很酷」，而是「它解決了誰的問題？」
作為在 B2B SaaS 做 AI 產品線的 PM，每次評估新工具，我習慣先算三個帳：context 成本、維護成本、onboarding 成本。拿這三把尺量 Mog，結果蠻有意思的。
先說 context 成本。Mog 的賣點是給 AI agents 設計的語言，capability system、agent hook、async/retry 都有，官網還放了 tensor FFT 的範例。聽起來很吸引人，但問題在這裡：Mog 幾乎沒有訓練資料。每次要讓 LLM 幫你寫 Mog code，就要把大量範例和 spec 塞進 context window，因為它根本沒見過這個語言。HN 討論串有人點出這件事，說得很直接。反觀 Python 或 TypeScript，訓練資料多到 LLM 幾乎預設就會，zero-shot 品質穩定、context 用量少很多。有點弔詭：你選了一個「AI 友善」的語言，結果讓 AI 助理變更貴、更慢。
再來是維護成本。Mog 目前大概是一個人在維護，這沒什麼問題，很多好的 open source project 都這樣起步。但從產品選型的角度，這是一個 ecosystem 賭注。半年後這個 project 沒了，你的 codebase 怎麼辦？採用 Mog 不只是選一個工具，你是在賭一個語言生態的生死。
最容易被低估的是 onboarding 成本。你 team 裡有幾個人懂 Mog？找新工程師時 JD 怎麼寫？用 Python 或 TypeScript 的話市場上供應充足，Mog 的話每個 hire 都要從頭學，每個人都是學習成本。
所以我的實務判準：
考慮採用的情況：
- 純實驗性 project，不需要長期維護
- Team 本身是 language enthusiast，學新語言算是動力
- Agent workflow 很特殊，現有語言的 abstraction 確實不夠用
不會採用的情況：
- 產品需要長期維護
- Team 規模超過 5 人（onboarding 成本會倍增）
- 主要靠 LLM 輔助寫 code（context 成本幾乎吃掉所有好處）
Mog 的概念有些地方值得研究，capability system 這個設計方向我覺得是真的在想 agent 的需求。但「AI 友善」這個 label，我會先問一個問題：友善給誰？讓 agent 更容易執行任務，還是讓 LLM 更容易幫你寫 code？這兩件事目前看起來，Mog 對前者有想法，後者幾乎確定是反效果。
作者：MingTech