第 8 章：为 AI 选择兼容的技术栈

"过于新的技术堆栈，AI 没有能力掌握，因为训练数据过少……兼容性这个词有了新的涵义。"

延伸阅读：小团队如何更有效地利用 AI 兼容的技术栈，参见AI-Native 小团队的结构性优势。规范如何与技术栈选择配合工作，参见Convention 与开发规范——让 AI 带着镣铐跳舞。

1. “AI 兼容性”是一种新的兼容性

传统上，我们谈“兼容性”，指的是：

• 浏览器兼容性
• 平台兼容性
• 第三方库的 API 兼容性

在 AI-native 的时代，又多了一层：

• 技术栈是否对 AI 友好？
• AI 是否在这个栈上有足够多的训练数据和实战样本？

“过于新的技术堆栈，AI 没有能力掌握，因为训练数据过少，例如 Deno；
但如果是成熟的如 Next.js，AI 可以很快地吐出正确的代码。”

这就意味着：

• 技术选型不再只是“性能、生态、稳定性”的博弈
• 还要考虑：“AI 在这个栈上能帮你干多少活？”

2. 选择成熟栈，是为了让 AI 多干一点

如果你选择的是一个非常新的、生态还很薄弱的栈：

• 文档不全，社区实践样本少
• 训练数据中的代码样本也很少
• AI 在这个栈上的“熟练度”就会明显偏低

反过来，如果你选择的是一个已经被海量项目验证过的栈：

• 各种典型用法、最佳实践、反模式，AI 都“见过很多遍”
• 你让它写代码、写测试、重构，成功率会高很多
• 你可以把更多心力放在业务和工作流设计上，而不是和栈本身较劲

这就是“AI 兼容性”的现实含义：

• 不是说新栈不值得关注
• 而是说，当你的团队人手有限、又强依赖 AI 产能的时候，
  选一个 AI 非常熟的栈，往往更划算。

3. 实际决策建议

在一个两人小团队、强依赖 AI 的前提下，可以用一套相对朴素的决策原则：

1. 优先选 AI 非常熟悉的栈

   • Web 前端：Next.js / React / Tailwind / 常见 UI 库
   • 后端：Node/TypeScript + Postgres，或者成熟的 serverless 组合

2. 优先选 AST / 符号友好的语言和工具链

   • 方便 AI IDE 和 CLI 工具做智能 refactor、导航和测试生成

3. 有意识地避免过“先锋”的技术组合

   • 如果一个栈在社区里都还处于“尝鲜期”，大概率 AI 也帮不了太多

技术选型永远是 trade-off，但在 AI-native 的世界里，
如果你希望 AI 真正成为团队的一员，技术栈就必须对 AI 友好。