AI 时代,如何选技术栈

2023 年之前,选技术栈是这么问的:

• 哪个语言性能好?
• 哪个框架生态成熟?
• 哪个数据库最稳?

2025 年之后,这些问题依然重要,但它们不再是决定性的。

决定性的问题变成了: “这个技术,AI 会不会把它用错?如果用错了,代价有多大?”

这篇文章想重新梳理一下选型逻辑,给一套新的评估框架。

一、旧选型逻辑:哪个最好用

1. 过去 20 年的选型主线

过去选技术,核心问题是"哪个最能解决我手头的问题"。

• 做网站 → Spring / Django / Rails
• 做大数据 → Hadoop / Spark
• 做前端 → React / Vue
• 做移动端 → Swift / Kotlin

选完之后,意味着你(和你的团队)要在上面投入几年。所以选型变成了一个"重决策"。

2. 旧选型逻辑的隐含假设

这些选型背后,有几个隐含假设:

• 人是主要的实现者 —— 选什么,人就要熟练什么
• 代码一旦写下去,改起来贵 —— 所以"对的"很重要
• 学习曲线存在 —— 切换栈的成本高

这些假设在 AI 时代,几乎都失效了。

二、新选型逻辑:哪个最不会被 AI 错配

1. AI 时代改变了什么

AI 改变的不是"哪个技术能解决问题"——这个没变。

AI 改变的是:

• 实现成本接近零 —— 切换栈的成本从"几月"变成"几小时"
• AI 是新的"实现者" —— 选什么,要考虑 AI 写起来对不对
• 代码不再是资产 —— 改起来便宜了,“对的"不再那么要命

也就是说,过去的"重的"决策,变"轻"了。

2. 新的核心问题:AI 会用错什么

新选型逻辑的核心问题只有一个:这个技术,AI 写起来容易写错吗?如果错了,后果严重吗?

这个问题拆开看,有三个子问题:

• (1) AI 的训练数据多不多? 数据多,AI 写得对;数据少,AI 容易胡编
• (2) 错的代价大不大? 即使 AI 写错,如果很快能发现,代价就小
• (3) 你的验证成本高不高? 验证成本高,错一次就亏一次

3. 一个简单的评估矩阵

把每个候选技术放进这个矩阵里:

粗略原则:

• 多 + 低 + 低 = 闭眼用 (例如:React、Vue 这类前端框架)
• 少 + 高 + 高 = 慎用 (例如:某些小众的、需要精确语义的语言或中间件)
• 多 + 高 + 中 = 视场景 (例如:数据库选型,要看你对一致性、性能的要求)

三、四个新的选型维度

具体来说,AI 时代的选型要看这四个维度:

1. 维度一:AI 友好度

• 这个技术有大量公开代码吗?
• 这个技术的官方文档,AI 读得懂吗?
• 这个技术的错误信息,AI 能诊断吗?

举例:

• React:训练数据多到 AI 都快背下来了 → 友好
• Solid.js:相对小众 → AI 容易"造"出不存在的 API
• Kafka:用法相对标准 → 友好
• Pulsar:文档少 → AI 容易给过时或错的示例

2. 维度二:错的爆炸半径

• AI 写错一个函数,影响范围多大?
• 是错在一个工具函数,还是错在认证逻辑、支付逻辑?

举例:

• 日志工具:AI 写错,顶多日志丢几条 → 小
• 认证授权:AI 写错,可能整个系统被穿透 → 大
• 业务核心算法:AI 写错,可能数据全错 → 大

错得起的栈,可以让 AI 自由发挥;错不起的栈,得人工一行行 review。

3. 维度三:反馈速度

• 这个技术,你能不能快速看到结果?
• 跑起来要多久?出错了定位要多久?

举例:

• 前端 + 浏览器:改一行刷新就看 → 快
• 后端 API:改一行要重启 + 调用 → 中
• 深度学习 + 训练任务:改一行要重训几小时 → 慢
• 嵌入式 + 硬件:改一行要刷固件、看示波器 → 极慢

反馈越慢,AI 帮忙的"乘数"越低。因为 AI 帮你的核心优势是"快速试错”,反馈慢就放大了它的缺点。

4. 维度四:可替代性

• 这个技术换掉,成本多高?
• 是不是有大量"如果不用它就得自己实现"的功能?

举例:

• 数据库:换数据库是个大工程 → 替代性低
• ORM:换一个 ORM 几天就行 → 替代性高
• 前端组件库:换一个组件库 1-2 周 → 替代性中

替代性低的技术,选的时候要更慎重;替代性高的,可以激进试错。

四、几个具体的"选型建议"

把上面的框架落到具体技术,给几个建议:

1. 编程语言

• AI 时代最值得用:TypeScript、Python、Go、Java
  • 训练数据多、AI 写得对、生态成熟
• AI 时代要谨慎用:Rust(语法严格,AI 容易写错)、新兴小众语言
  • 不是不好,是 AI 容易"造"代码
• 结论:大多数场景,选主流语言 + 主流框架,别追新

2. 前端框架

• AI 时代最值得用:React、Vue
  • 训练数据爆炸,AI 写得对
• 可以试:Svelte、Solid
  • AI 也支持,但出错概率稍高
• 结论:业务项目用 React/Vue 就行,别为"新潮"付出代价

3. 后端框架

• AI 时代最值得用:Spring Boot、Express、FastAPI、Gin
• 要慎用:某些内部框架(训练数据少)
• 结论:选社区大的,别选公司内部的(除非有特殊理由)

4. 数据库

• AI 时代最值得用:PostgreSQL、MySQL
  • 训练数据多,大多数 AI 写得对
• 要慎用:某些 NewSQL 的具体语法(AI 容易写错)
• 结论:大部分场景,PostgreSQL 一个就够

5. AI 工具链

• IDE:Cursor(主流)、Claude Code
• 助手:GPT 系列、Claude 系列
• 结论:选一个用熟,别每出来一个就换

五、选型的"反共识"

最后说几个反共识:

1. 不追新 ≠ 不学新

旧逻辑里,“追新 = 进步”。新逻辑里,“追新 = 风险”。

学新东西可以(在副项目里),但生产选型,要慎重。

2. 主流不是平庸,是安全

在 AI 时代,选主流技术,不是因为它"最酷",而是因为:

• AI 训练数据多
• 招人容易
• 出问题搜得到答案
• 切换成本相对低

这些"无聊"的理由,正是 AI 时代的护城河。

3. 别为"未来"选,为"现在"选

旧逻辑里,我们经常为"未来可能的需求"选技术(比如为了"高并发"上 Kafka,结果日活 100)。

AI 时代更要避免这一点:用 AI 写起来对、写起来快、错了能改,才是真的。

六、写在最后:选型变轻了,但判断变重了

AI 时代选技术的核心变化,不是"标准变了",而是"决策的重量变了"。

过去选错,代价是几年。

现在选错,代价是几天。

但这不意味着选型不重要了——反而更重要了。因为过去是"选对就稳了",现在是"选错了能改,所以你得更频繁地选"。

也就是说,选型从"一次性大决策",变成了"持续性小决策"。

这种决策,只有判断力强的人能做好——这又回到了上一篇聊的护城河。