本文是 Vibe Coding 工程化 专栏里的一篇。专栏收集与整理 Vibe Coding 工程化的设想与落地实践。
Baton Stack 是面向「委托协作」的全栈脚手架——建立在一套持续演进的理论语料之上，好让人、Agent 与子 Agent 任意组合时，也能在长期交付中稳妥地把工作交出去、接得住。
Baton Stack 要给 Agent 定的唯一默认语言，得覆盖从 Web 到 App 的全栈：Web、后端、CLI、Windows、macOS、iOS、Android。内部工具和 C 端同权，没有排序。默认只能是一门语言，不能按模块再拆第二门，也不能把函数算力绑死在某一家云控制台上。
所以这不是给某一端挑惯用栈，而是要回答一个更基础的问题：人把活委托出去、Agent 负责把代码写出来时，仓库里默认只认哪一门源码语言？而且这门语言得在从 Web 到 App 的全栈里同等优先时站得住，不能只在某一端好用。
我没有因为自己更熟悉 TypeScript，就把它当成默认答案。我对比了九门语言，都按 2026 年中的稳定版、预发和官方路线图看过：TypeScript、Python、Kotlin、Swift、Rust、Go、Java、C#、Dart。标准来自 Baton Stack 的理论语料，不靠旧印象。最后落到 TypeScript，作为唯一默认语言。但这不是一劳永逸的答案——标准或约束变了，这个结论也要重开。
先别急着选语言，先问要不要「就一门」
Baton Stack 的理论语料 并不规定世界上只准一门语言。它管的是委托下的软件生产：意图怎么进来、空白怎么被关掉、证据怎么留下、参与者能力画像一变哪些做法会过期。
在这个透镜下，「尽量一门默认语言」说得通，也值得做默认方向。一门语言让人和 Agent 都更好懂、好转手，少掉「这个仓库到底用哪门语言」这类残留决策，也让类型检查、测试、契约更容易钉在同一工具链上。Agent 负责写代码、人偏委托和验收时，少一套跨语言心智税，通常更划算。
但「绝对唯一、零例外」是推不出来的。系统 API、商店壳、驱动这类边界，往往只能用一点点别的语言，核心仍是默认语言。更干净的说法是：
在
Baton Stack治理的业务空间里，默认单一主语言与单一工具链；例外必须标出来，并说明为什么不能迁进主语言，且不依赖某一家商业云才能成立。
我打分时在问什么
评分时把「选对」当成唯一目标，实现成本不计入。成熟的外部机制只要生产可达，都算进该语言的能力：严格检查配置、契约库、官方 MCP、稳定打包链，不要求一切都长在语法里。
| 维度 | 在问什么 |
|---|---|
| 好懂、好转手 | 同一套写法能否降低跨模块的理解和交接成本 |
| 意图可执行 | 类型、测试、契约能否把「应当怎样」钉成能检查、能跑验的东西 |
| 证据与检查 | 结论检查起来是否不费劲、难伪造、钉在精确版本上 |
| 有界上下文 | Agent 是否容易在一次工作单元里做完，并留下可交接物 |
| 改完还敢信 | 代码写得很快之后，再确认这版能用要花多少力气 |
| 多端到达 | 从 Web 到 App 的全栈同等优先时，是否都生产可达 |
| 人读协作 | 人审、人委托时的阅读税 |
这七个维度不是打分结果，而是评分之前先定好的标尺——先固定问什么，再去看每门语言答得怎样，避免边打分边改标准。
「2026 年 Agent 更熟哪门语言」只作观察项，权重封顶，不写进永久规则。能力画像会变，把某一时期谁更熟写成死规则，过两年规则还在假装适用。
在这套标尺之上，还钉死了几条不能含糊的边界。默认只能一门语言，而且不能绑死某一家商业云；后端需要一条非实验的通用路径；Agent 编码的闭环必须今天就能用，不能把默认语言押在 Alpha 特性上；运行时类型会被擦掉，可以用强制检查加契约补上。Tauri 这类「界面一门语言、壳另一门语言」算违约，那不是边界上的小例外，而是直接踩线。
这几门为什么被我划掉
这里不写排行榜，只写哪几门没法同时满足「从 Web 到 App 的全栈同等优先」和「Agent 今天就能用」。
Swift：服务端和 Apple 端很强，官方也有 Wasm / Android SDK，但浏览器 UI 和 Android UI 的主路径仍要实质异语言，这和「唯一默认语言、各环境同等优先」对不上。
Go / Java：更适合后端与 CLI 同构，一旦 Web UI、移动端和后端同权，就很难不引入第二套 UI 语言，或者把本就窄的框架硬说成已经和后端同等成熟。
Python：在后端、CLI、Agent 编码上很顺，但 iOS / Android 仍是官方 Tier 3（官方明确列为支持力度最弱的一档），浏览器侧也弱一截。
Rust：改完之后更容易再确认能用，适合高信任边界，但应用 UI 多半要押 Tauri 或 Dioxus，Tauri 又撞上「壳不能是第二语言」这条红线，叠加 Agent 单次工作单元里借用与编译反馈的成本，也不适合当唯一默认语言。
Dart：客户端多端同构和官方 MCP 很诱人，但后端若要求非实验、且不能绑死某一商业云函数产品，通用后端的成熟度还撑不起和客户端同等。
Kotlin：官方多端矩阵很齐，但 Compose for Web / Wasm 仍偏 Beta，面向 Agent 的 LSP 闭环也还在 Alpha / Preview，闭环必须今天能用，不宜当作默认。
C# / .NET：九门里最接近的一个，全栈可以同语言，Agent 框架也有生产档，但浏览器侧和移动 AOT 仍有运行时分叉，等于额外接受「同一语言、不同运行时成熟度」这道隐性折扣。
TypeScript 也不是每一项都满分。约束叠在一起之后，缺口可以靠边界上的少量异语言和强制工具链补上，而且不必把关键能力押在仍标实验的一关上。
那为什么还是 TypeScript
先说它补得上的，再说补不上、必须写进重开条件的。
应用面上，从 Web 到 App 的全栈它都能站住。后端走 Deno、Bun 这类通用宿主，TypeScript 是一等公民；云上的 Workers 形态也能跑，但不能把某一家的 Workers 写成唯一后端。各运行时还在把一套最小公共 Web API 收拢到同一标准里（WinterTC，草案编号 ECMA-429，目标是让不同 JS 运行时对齐同一批基础接口）。也就是说，后端要等于通用后端，而不是某一云厂商控制台里的方言。CLI 可以同语言。桌面可以用 Electron 一类，主路径仍是 TypeScript。iOS / Android 可以走 Expo / React Native；按已裁定的边界例外，只有系统 API 插件才允许少量 Swift / Kotlin / C++。
所以它能当唯一默认语言，是因为在「从 Web 到 App 的全栈同等优先、就一门语言、Agent 今天就能用」这几条叠在一起时，缺口还能补，而且补法今天就能用。
意图与证据上，语言本身在某些目标环境会擦掉运行时类型，但按裁定，这不算自动出局：把严格 tsc（含一组最严的可选开关）、lint 类、测试，以及 Zod 一类运行时契约写进仓库约定，意图就能同时落在「编得过」和「跑得验」两层。证据仍要钉版本——绿勾不能跟着下一轮生成漂走。这和 Baton Stack 的理论语料里「自述不是证据」「证据钉文本版本」是同一类要求。
给 Agent 编码用时，开源项目里这套写法有多常见、脚手架默认用哪门语言、编辑器和语言服务有多成熟，目前仍明显偏向 TypeScript。但这只说明 2026 年中的观察，不证明永远如此，它只用来解释眼下定它为什么说得通。真正用来对比的，仍是上面那些可重推的标准。
定了之后，仓库要钉死什么
必须钉死的生产约定：
- 检查：
strict是地板，仓库再打开更严的可选开关。 - 契约：跨边界的输入输出必须有运行时 schema，只靠类型声明不够。
- 后端宿主：在 Deno 与 Bun 一类里钉死一个作为默认，避免宿主选择变成永久残留决策。可以部署到多家云，但不能让协议依赖单一厂商专有运行时。
- 移动与桌面：应用 UI 主路径保持 TypeScript，原生插件写进例外清单。
- 明确不做：Tauri 壳、按模块再拆第二门语言、把某一云函数产品写成唯一后端。
写作时的版本快照（2026-08-13 复核）：语言钉 TypeScript 7.0.x，也就是 Go 原生编译器稳定线。官方在 2026-07-08 发了 Announcing TypeScript 7.0。7.0 还没有稳定的嵌入式 compiler API；依赖这层 API 的工具链，在 7.1 落地前允许与 6.x 并存，但要写明，不能假装没有空窗。后续节奏以 TypeScript 7.1 Iteration Plan 为准，目前写的是 Beta 2026-09-09、RC 2026-10-20、Stable 2026-11-10。
什么时候必须重开
结论可废。下面任一成立，就应重新跑同一套标准，不要靠打补丁硬把 TypeScript 留成永远正确：
- 要求商店包与仓库对原生层也不许再用别的语言，连边界插件也不再合法。
- 默认 Agent 编码闭环迁到另一门语言，且在真实仓库里稳定优于 TypeScript 工具链。
- 出现一门语言，在 Web / 通用后端 / CLI / 桌面 / iOS / Android 上同时达到「官方生产封顶 + 后端不绑云」，并且 Agent 闭环也已生产可用。
- 类型擦除再也没法用强制契约补到「改完还敢信」的程度。
我选 TypeScript 作为唯一默认语言，是在 Agent 编码、就一门语言、从 Web 到 App 的全栈同等优先这些约束下，用 Baton Stack 的理论语料里不怎么随工具变的标准做对比，再用 2026 年的版本事实校准。它是当前最能同时站住的点。如果将来约束变了，那就重开。
