技术栈选择

这一课你将能做到

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 的发挥空间」，让它在你选定的主场上干活。