技术栈选择

这一课你将能做到

1. 说清楚「AI 友好度」评估技术栈的三个维度
2. 给一个真实项目选出 AI 协作效率最高的技术组合
3. 避免「为了 AI 而选栈」的陷阱，平衡团队能力和生态

为什么要学

同一个需求，用不同技术栈让 AI 实现，质量差距可能是天壤之别。让 AI 写 Python Flask 的 REST API，它几乎不犯错；让它写一个冷门语言的 Web 框架，幻觉 API、编造配置、版本错乱会集中爆发。

人话：AI 的能力不是均匀的，它对「训练数据里出现得多」的技术栈掌握得好。选栈的本质是选 AI 的主场——用 AI 最熟悉的工具干活，出错率最低，返工最少。

真实项目中，技术栈选择还叠加了团队现有能力、运维成本、生态成熟度，AI 友好度只是其中一个新变量，但这个变量正在变得越来越重要。

先建立图像

AI 友好度三维度：

          流行度
         /     \
        /       \
       /         \
  类型安全 ———— 生态文档

流行度：训练数据多不多，社区问答多不多
类型安全：编译器能不能帮 AI 兜底
生态文档：官方文档是否清晰、结构化

跟着做

步骤 1：评估你当前技术栈的 AI 友好度

拿一张纸，按三维度给现有栈打分（1-5 分）：

Java + Spring Boot：
- 流行度：5（训练数据极多）
- 类型安全：5（编译器严格，AI 犯错会被编译器抓住）
- 生态文档：5（Spring 官方文档清晰）

Python + Django：
- 流行度：5
- 类型安全：3（动态类型，AI 幻觉的属性名运行时才发现）
- 生态文档：4

Rust + Axum：
- 流行度：3（训练数据少，新版本 API AI 常不知道）
- 类型安全：5
- 生态文档：3

Vue 3 + Element Plus：
- 流行度：4
- 类型安全：3（模板里 JS 弱类型）
- 生态文档：4

步骤 2：体验「AI 主场」和「AI 客场」的差距

用同一个需求分别让 AI 生成两个版本：

需求：实现一个带分页、按状态筛选、按创建时间排序的文章列表查询接口

版本 A（AI 主场）：Java + Spring Boot + MyBatis-Plus
版本 B（AI 客场）：Rust + Axum + SQLx

对比：

• 版本 A 的代码量、编译通过率、第一次就能跑的概率
• 版本 B 你手动修正了几处？修正的是幻觉 API 还是逻辑错误？

这个对比会让你对「AI 主场」有直观的体感。

步骤 3：为一个新项目做选型

假设要做一个「团队内部的知识库问答系统」，按以下决策树走：

1. 团队现有主力语言是什么？
   → Java：继续 Java 生态，加 AI 友好的框架
   → Python：继续 Python 生态
   → 无主力：选 AI 最友好的组合

2. 对类型安全要求高不高？
   → 高（金融、支付）：Java/C#/Go
   → 一般（内容、工具）：Python/Node.js 也可

3. 前端需要复杂交互吗？
   → 复杂（实时协作、富文本）：React + TypeScript（AI 训练数据最多）
   → 简单（CRUD、展示）：Vue 3 / React 均可

4. 数据库？
   → 关系型：PostgreSQL（AI 生成 SQL 质量最高）
   → 文档型：MongoDB（训练数据也多）
   → 键值缓存：Redis

步骤 4：给选定栈写「AI 使用说明」

在项目根目录的 PROJECT.md（或 CLAUDE.md / .cursor/rules）里加一段：

## AI 使用说明
- 本项目用 Java 17 + Spring Boot 3 + MyBatis-Plus
- 不要用 JPA/Hibernate，只用 MyBatis-Plus 的 QueryWrapper
- 数据库迁移用 Flyway，SQL 文件放 db/migration
- 单元测试用 JUnit 5 + Mockito，不要用 PowerMock
- 日志用 SLF4J，不要 System.out.println
- 引入新依赖前先说明理由，等我确认

这段说明的每一条都在「收窄 AI 的发挥空间」，让它在你选定的主场上干活。

讲清楚要点

1. 类型安全是 AI 时代的隐形护城河：编译器能抓住 AI 的错误，动态语言不能。Java/C#/Go 的 AI 容错率天然高于 Python/JavaScript。
2. 流行度决定训练数据量：Java、Python、JavaScript、React、Spring、Django 是 AI 的「母语」，冷门框架是「外语」。不是不能用，是错误率高。
3. 「不引入新依赖」是核心纪律：AI 有倾向加库解决问题（「装个 lodash 吧」「装个 axios 吧」）。每加一个依赖，供应链风险+维护成本就涨一分。能自己写的，不让 AI 装。
4. 数据库选型影响 SQL 质量：PostgreSQL 的文档和训练数据最丰富，AI 生成的 SQL 最可靠；冷门数据库的方言和函数 AI 常编错。
5. 前端框架的 AI 排序：React > Vue > Angular > Svelte（大致按训练数据量排）。不是说你必须选 React，而是说选 React 时 AI 的帮助最大。

你可能会懵的地方

• 我们项目已经在用冷门框架了，要不要为了 AI 换栈？ 不要。换栈的成本远高于 AI 效率提升。正确做法：在 PROJECT.md 里写清楚「本项目用 X 框架，AI 请参考以下关键约定」，把 AI 的效率损失控制在可接受范围。换栈只在项目启动前评估。

• TypeScript 比 JavaScript 更适合 AI 协作吗？ 是。TypeScript 的类型注解让 AI 的补全更准，编译器能抓住 AI 的类型错误。JavaScript 项目里 AI 幻觉一个属性名，运行时才发现；TypeScript 里编译就报错。新项目优先 TypeScript。

• Python 的动态类型是不是 AI 协作的硬伤？ 是劣势但不是绝症。用类型注解（def get_user(id: int) -> User:）+ Pydantic 模型 + mypy 检查，可以把 Python 的 AI 容错率拉到接近静态语言的水平。

• AI 总推荐过时的依赖版本怎么办？ 在 PROJECT.md 里写死版本号：「Spring Boot 3.2.x，MyBatis-Plus 3.5.x」。AI 训练数据有滞后性，明确版本是最有效的约束。生成后检查 pom.xml / package.json 的版本号是否真实存在（可以去 Maven Central / npmjs 验证）。

• 微服务架构对 AI 协作有影响吗？ 有。单体应用 AI 更容易理解全貌；微服务多了，AI 不知道服务间的契约。对策：每个服务的 CLAUDE.md 里写清楚「我调谁、谁调我、接口契约在哪」。

错法对照

错法	问题	正解
为了 AI 选冷门语言	AI 客场作战，错误率飙升	选 AI 主场（Java/Python/JS/Go）
动态语言不写类型注解	AI 幻觉属性名运行时才炸	Python 加类型注解，JS 项目迁 TS
让 AI 自由装依赖	供应链风险+版本冲突	「不引入新依赖」写进规则
数据库选最冷门的	AI 生成 SQL 错误率高	关系型优先 PostgreSQL/MySQL
微服务间契约不写文档	AI 不知道跨服务调用细节	每个服务的规则文件写明上下游

卡点急救

1. AI 用了你不想要的框架/库：提示词里明确禁止（「不要用 JPA，只用 MyBatis-Plus」），并把它写进规则文件。
2. AI 生成的 SQL 语法在你的数据库上跑不通：把数据库类型和版本写进上下文（「MySQL 8.0，不要用 PostgreSQL 方言」），或让 AI 先输出执行计划再生成 SQL。
3. AI 推荐的依赖版本不存在：去 Maven Central / npmjs 搜索验证，把真实版本号写进 PROJECT.md，后续会话 AI 就不会再编错。

面试常问

• AI 时代技术选型有什么新考量？ 高分回答：新增「AI 友好度」维度——流行度（训练数据量）、类型安全（编译器兜底）、生态文档质量。但强调这不是唯一标准，要平衡团队能力、运维成本、生态成熟度。举例说明为什么 Java/Spring 和 Python/Django 是 AI 主场。

• 如何在动态语言项目中提升 AI 协作质量？ 类型注解全覆盖、Pydantic/TypeScript 模型定义、mypy/tsc 静态检查进 CI、PROJECT.md 里写死关键约定。核心思路是「用工具链补语言的短板」。

• AI 生成代码引入的依赖风险怎么控制？ 规则文件里禁止 AI 自主引入新依赖；新依赖必须人工确认；CI 里跑依赖漏洞扫描（OWASP Dependency-Check / Snyk）；定期检查 AI 是否幻觉出不存在的包名。

自测三问

1. 评估技术栈 AI 友好度的三个维度是什么？
2. 为什么类型安全的语言在 AI 协作中容错率更高？
3. 你的项目 PROJECT.md 里应该写死哪些「不许 AI 自由发挥」的约束？

小结一句话

技术栈选择是在给 AI 选主场——流行度高、类型安全、文档清晰的栈，AI 犯错少，你的验收成本低。

延伸

• Spring Boot 官方文档
• PostgreSQL 官方文档
• 下一课：提示与上下文——让 AI 精准理解你意图的工程方法。