Session 3: 技术选型 - 在 AI 的建议中做明智选择

这节课是整个课程最重要的一课。学会判断 AI 的技术建议，比学会任何具体技术都重要。

🎬 开场故事：同样的问题，不同的命运

小李的灾难

小李问 AI："我想做个个人博客，推荐什么技术？"

AI："推荐你用 Next.js 14 + Vercel + Sanity CMS + Tailwind CSS + TypeScript。这是现代前端最佳实践，支持 SSR、ISR、Edge Functions..."

小李：听起来很专业，就用这个吧。

（一周后）

小李："这报错是什么意思？什么是 hydration error？"

AI："这是 Next.js 的服务端渲染和客户端渲染不匹配..."

小李："？？？"

又一周后，小李的博客还没上线，他已经学了：

• Next.js 的 App Router
• TypeScript 的类型系统
• Sanity 的 GROQ 查询语言
• ISR 的 revalidate 策略

而他原本只想要一个能发文章的网页。

小李的问题：盲目相信 AI 的"最佳实践"建议，没有评估是否适合自己。

小王的成功

小王也问 AI："我想做个个人博客，推荐什么技术？"

但他加了约束： "我是新手，完全不懂现代前端框架。我想要最简单的方案，能快速上线，以后维护也简单。"

AI 给了三个选项：

方案 A（最简）：用 Markdown 文件 + HTML 模板，直接用 GitHub Pages 托管。不需要学任何框架。

方案 B（中等）：用静态网站生成器 Hugo/Jekyll，有主题可用，只需写 Markdown。

方案 C（现代）：用 Next.js + Headless CMS，功能强大但学习曲线陡峭。

小王用评估框架打分：

小王选了方案 A。

两天后，他的博客上线了。

小王的秘诀：用了评估框架，根据自己的约束选择了最适合的方案，而不是"最好"的方案。

🧠 核心概念：没有最好的技术，只有最适合的技术

程序员 vs 指挥官的技术选型思维

关键洞察：AI 通常给出"程序员思维"的建议，因为训练数据来自程序员社区。但你需要的是"指挥官思维"的建议。

为什么 AI 会推荐过度设计？

原因 1：训练数据偏差

• AI 学的是技术文章、教程、最佳实践
• 这些内容通常面向专业开发者
• "用最新技术"是技术社区的主流声音

原因 2：缺乏约束信息

• 如果你没有明确说"我是新手"，AI 假设你有一定基础
• 如果你没有说"要简单"，AI 假设你要"最佳"方案
• 如果你没有说预算/时间限制，AI 不考虑这些

原因 3：技术人员的惯性

• 专业程序员倾向于选择他们熟悉/喜欢的技术
• AI 继承了这种倾向
• "Vue 比 jQuery 好"→但对你可能是"Vue 比 jQuery 更难"

🛠️ 实战工具：技术选型评估框架

这是整个课程最重要的工具。每次 AI 推荐技术方案时，用这个框架评估。

评估维度

1. 简单性（Simple）

问自己：

• 我需要学多少新东西才能用上？
• 出问题时，我能自己解决吗？还是需要依赖别人？
• 部署和维护复杂吗？
• 如果 AI 不帮我了，我还能维护这个项目吗？

评分（1-5）：

• 5 = 几乎不需要学习，出问题时能自己解决
• 3 = 需要学一些新概念，但文档齐全
• 1 = 需要深入理解才能使用

2. 足够性（Sufficient）

问自己：

• 能满足我的核心需求吗？
• 性能够用吗？（不要超前优化）
• 扩展性足够未来 6 个月吗？
• 有没有我不需要但硬塞进来的功能？（过度设计）

评分（1-5）：

• 5 = 完美满足需求，不多不少
• 3 = 满足需求，但有一些多余功能
• 1 = 不够或者过度

3. 成本（Cost）

问自己：

• 金钱成本：服务器、域名、第三方服务费用
• 时间成本：学习、开发、调试时间
• 维护成本：后续需要投入多少时间维护
• 迁移成本：如果以后想换技术，容易吗？

评分（1-5）：

• 5 = 几乎零成本
• 3 = 有一些成本，但可接受
• 1 = 成本高，超出预算

计算公式

总分 = 简单性 × 0.4 + 足够性 × 0.4 + 成本 × 0.2

权重说明：
- 简单性 40%：最重要，因为你是指挥官不是程序员
- 足够性 40%：要能解决实际问题
- 成本 20%：对大多数个人项目来说，免费/低成本很重要

使用建议：

• 总分 ≥ 4.0：值得考虑
• 总分 3.0-4.0：勉强可用，但可能有更好的
• 总分 < 3.0：不要选，除非有特别理由

红旗警告：AI 建议中的过度设计信号

当 AI 推荐以下技术时，提高警惕：

🚩 微服务架构 → 你的用户量可能根本不需要 🚩 Kubernetes/Docker → 部署复杂度爆炸 🚩 Redis 缓存 → 先确认有性能问题再说 🚩 消息队列 → 99% 的个人项目不需要 🚩 最新的框架版本 → 可能不稳定，文档不全 🚩 "企业级"方案 → 对你可能是杀鸡用牛刀

正确反应： "你推荐的方案听起来很复杂。根据我的约束（新手、小项目、无服务器），有没有更简单的方案？"

📝 实战案例：技术选型决策

场景：做一个待办清单工具

需求回顾：

• 功能：添加、完成、删除待办，本地存储
• 用户：只有自己用
• 约束：无服务器、免费、一周内上线、代码简单

AI 给出的方案对比

方案 A：纯 HTML/CSS/JS

优点：
- 一个文件搞定
- 双击就能打开
- 数据存在浏览器 localStorage
- 不需要服务器
- 代码最简单

缺点：
- 界面需要自己写样式
- 功能扩展有限
- 换浏览器数据不共享

方案 B：React + Vite

优点：
- 现代开发体验
- 组件化，代码清晰
- 生态丰富

缺点：
- 需要学 React
- 需要构建步骤
- 对新手来说概念太多（state、props、hook）

方案 C：Next.js + MongoDB

优点：
- 功能强大
- 可以做多用户
- 可以同步数据

缺点：
- 需要服务器
- 需要数据库
- 学习曲线陡峭
- 有持续成本

用评估框架打分

结论：方案 A 完胜。

AI 建议评估

AI 可能会推荐方案 B 或 C：

• "用 React 是行业标准"
• "Next.js 是最佳实践"
• "localStorage 不够专业"

你的评估：

• ❌ "行业标准"不等于"适合我"
• ❌ "最佳实践"是给专业团队的，不是给个人项目的
• ❌ "不够专业"不等于"不能用"

正确回应： "根据我的约束（新手、小项目、无服务器），方案 A 是最合适的。虽然 React/Next.js 更先进，但它们增加了我不需要的复杂度。"

🤖 AI 协作技巧：引导 AI 给出合适的建议

技巧 1：明确约束前置

❌ 错误做法： "推荐一个技术方案"

✅ 正确做法：

我想做一个 [项目描述]。

约束条件（非常重要）：
- 我是非技术人员，要最简单的方案
- 无服务器优先
- 预算：免费
- 时间：一周内上线

请给我 2-3 个技术方案，并用以下框架评分：
1. 简单性（1-5）：我需要学多少新东西？
2. 足够性（1-5）：能满足需求吗？
3. 成本（1-5）：金钱+时间+维护成本

请推荐最适合我的方案，并解释为什么。

技巧 2：要求对比和理由

AI 推荐了方案 A，但我想知道：
1. 和方案 B 相比，优缺点是什么？
2. 如果我以后需要 [扩展功能]，方案 A 还能满足吗？迁移成本如何？
3. 这个方案的"坑"是什么？（即新手容易遇到的问题）

技巧 3：质疑过度设计

当 AI 推荐复杂方案时：

你推荐的方案听起来很复杂，涉及 [技术列表]。

我的约束是 [重复约束]。

请问：
1. 这些技术都是必须的吗？有没有可以去掉的？
2. 如果只用其中 1-2 个技术，能满足需求吗？
3. 请给我一个"最小可行方案"，只做核心功能。

技巧 4：要求逃生路线

如果我选择方案 A，以后想迁移到方案 B，容易吗？

请说明：
1. 数据如何导出？
2. 代码复用度如何？
3. 迁移大概需要多少工作量？

📊 常见技术选型决策表

前端方案对比

后端/数据方案对比

部署方案对比

⚠️ 常见陷阱

陷阱 1：追求"最新"技术

❌ "这个框架是上周发布的，应该很先进"

✅ 正确做法：

• 新技术 = 文档不全 + Bug 多 + 社区支持少
• 对你这样的指挥官来说，稳定 > 先进
• 选择发布至少 1 年以上的技术

陷阱 2：相信"行业标准"

❌ "大公司都用这个，我也应该用"

✅ 正确做法：

• 大公司的"标准"是给大团队、大项目、大流量设计的
• 你的小项目不需要那些复杂度
• 适合你的 > 行业标准的

陷阱 3：忽视维护成本

❌ "这个方案开发很快，先用着"

✅ 正确做法：

• 问自己：3 个月后，我还能维护这个项目吗？
• 如果 AI 不帮你了，你自己能搞定吗？
• 可持续的 > 开发快的

陷阱 4：不做逃生计划

❌ "先做这个方案，以后再说"

✅ 正确做法：

• 每个选择都要考虑：如果不行，怎么换？
• 数据能导出吗？
• 代码能复用吗？

✅ 本节课作业

作业 1：评估框架练习

选一个你想做的项目，列出至少 2 个技术方案，用评估框架打分。

项目：_________________

方案 A：_________________
- 简单性（1-5）：_____ 理由：_____
- 足够性（1-5）：_____ 理由：_____
- 成本（1-5）：_____ 理由：_____
- 加权总分：_____

方案 B：_________________
- 简单性（1-5）：_____ 理由：_____
- 足够性（1-5）：_____ 理由：_____
- 成本（1-5）：_____ 理由：_____
- 加权总分：_____

选择：方案 _____
理由：_____

作业 2：AI 对话练习

用上面的 Prompt 模板问 AI，获取技术选型建议。

然后做 AI 建议评估：

• AI 推荐的方案得分如何？
• 有没有红旗警告（过度设计）？
• 你会采纳 AI 的建议吗？为什么？

作业 3：质疑练习

当 AI 推荐复杂方案时，练习说"不"。

写一段回复：

你推荐的方案涉及 [技术列表]，听起来比较复杂。

根据我的约束 [你的约束]，我担心：
1. [具体问题]
2. [具体问题]

请给我一个更简单的方案，满足 [核心需求] 即可。

作业 4（进阶）：复盘一个失败经历

想想你过去某个项目失败的经历（如果有）。

分析：

• 当时选的技术方案是什么？
• 用评估框架打分，得分如何？
• 如果重来，你会怎么选？

📎 模板下载

技术选型决策模板

# 技术选型决策

## 项目背景
项目名称：
核心需求：
约束条件：
- 技术能力：
- 预算：
- 时间：
- 其他：

## 候选方案

### 方案 A：
描述：

评分：
- 简单性：/5 （理由：）
- 足够性：/5 （理由：）
- 成本：/5 （理由：）
- 加权总分：

优缺点：
- 优点：
- 缺点：
- 风险：

### 方案 B：
[同上格式]

### 方案 C：
[同上格式]

## 决策

选择方案：

理由：

逃生计划（如果需要迁移）：

## AI 建议评估

AI 推荐方案：

评估：
- 是否符合约束：
- 是否有红旗警告：
- 是否采纳：
- 理由：

🎯 下节课预告

Session 4: 模块化设计 - 把大象切成能吃的块

我们会学习：

• 如何把项目拆成 AI 能一口消化的小模块
• 模块之间的接口设计
• 如何用模块化降低复杂度

记得带上你的技术选型决策！

💬 常见问题

Q: AI 推荐的"最佳实践"真的不好吗？

A: 不是不好，是不适合你。最佳实践是给专业团队、大项目设计的。你的目标是用最简单的方式解决自己的问题。

Q: 我怎么知道一个技术"简不简单"？

A: 问自己：

1. 我能在 1 小时内理解它的核心概念吗？
2. 如果报错，我能根据错误信息自己解决吗？
3. 我需要学多少新概念才能用上它？

Q: 以后需要扩展怎么办？

A: 先解决现在的问题，再考虑以后。大多数项目活不到需要"扩展"的那一天。而且，简单的方案通常也更容易扩展。

Q: AI 说"这个方案太简单了，不够专业"怎么办？

A: 坚持你的约束。对指挥官来说，"简单能用"就是专业。"复杂但用不上"才是业余。

完成这节课，你学会了最重要的技能：在 AI 的建议中做明智选择。

记住：你不是在找"最好的技术"，你是在找"最适合你的技术"。

下一节课见！ 🚀