vibe‑coding 九阳神功之扩：AI 帮你扩展认知边界，但学到的必须可验证

vibe‑coding 九阳神功之扩：AI 帮你扩展认知边界，但学到的必须可验证

系列顺序：夯（Git） → 抄 → 学 → 喂 → 规 → 验 → 测 → 扩 → 收 一句话：AI 能让你碰到以前碰不到的技术，但”AI 说能用”不等于”真能用”——学到的必须能跑。

AI 编程现在最大的坑不是”不会写”，而是：

• 写得太快
• 改得太多
• 炸了没后路
• 炸完你甚至不知道它到底改了哪些文件

所以我准备写一套 vibe‑coding 九阳神功：核心不是提示词，而是把 AI 变成”可控交付的队友”。

这套”九阳神功”我先定了九个字诀：

• 夯：Git 生存技能（刹车 / 保险 / 录像）
• 抄：拆解 yfge/orion、ai-shifu/ai-shifu 的优秀骨架，搭底盘
• 学：学习行业黑话，会组合技术栈、不懂原理也能不翻车
• 喂：把 API 文档 / 资料结构化成可执行知识
• 规：让 AI 出计划 + tasks.md，按清单推进
• 验：多模型交叉验证，专治幻觉
• 测：自动测试，交付有证据
• 扩：扩展认知边界，但必须可验证
• 收：上线交付、监控回滚、复盘闭环

这篇咱们讲第八式 扩：用 AI 突破技术栈的边界，但学到的每一样都必须能验证。

---

“扩”是什么意思？

前面几式——学、喂、规、验、测——都是在你已有能力范围内提效。

“扩”不一样。它是说：借助 AI，你可以快速上手一个你从来没碰过的技术栈/领域，而且不翻车。

举几个真实场景：

• 你是 Java 后端，突然要写 React 前端
• 你从没搞过 K8s，现在要把服务容器编排上线
• 你不懂机器学习，但要给系统加一个推荐算法
• 你没写过 iOS，但要出一个简单的 Swift 原型

以前这些场景意味着”学两周再开干”。现在有了 AI，你可以”边干边学”——但前提是：学到的东西必须可验证。

---

扩的反面：盲目信任

我见过最多的翻车是这样的：

一个后端同学用 AI 写了一套 React 前端，看起来能跑。上线后发现：

• 没有 error boundary，白屏频率 20%
• 状态管理用了 3 种方案混着来（Redux + Context + useState）
• 没有做路由懒加载，首屏 5 秒
• 没有做响应式，手机端全崩

代码能跑 ≠ 代码能用。AI 帮你”扩”的东西，你不验证就上线，那不叫扩展边界，叫制造债务。

---

“扩”的正确姿势：5 步法

第 1 步：让 AI 给你画地图

你要学一个新领域，先让 AI 给你一张”最小知识地图”：

我是 Java 后端开发，现在需要写 React 前端。

请给我一张"最小知识地图"：
1) 我必须理解的 5 个核心概念（不要超过 5 个）
2) 每个概念用一句话解释 + 一个代码片段
3) 这些概念之间的关系（画个依赖图）
4) 我可以不管的东西（明确说"这些你先别管"）

AI 会告诉你：

## React 最小知识地图（给 Java 后端看的）

### 必须懂的 5 个概念
1. **组件（Component）**：就是 Java 的 class，但返回 HTML
   - `function App() { return <div>Hello</div> }`
2. **Props**：就是方法参数，父组件传给子组件
   - `function Card({ title }) { return <h1>{title}</h1> }`
3. **State（useState）**：组件内部的变量，改了会自动刷新页面
   - `const [count, setCount] = useState(0)`
4. **Effect（useEffect）**：生命周期钩子，类似 @PostConstruct
   - `useEffect(() => { fetchData() }, [])`
5. **路由（React Router）**：URL 到组件的映射，类似 @RequestMapping
   - `<Route path="/users" element={<UserList />} />`

### 先别管的
- Redux、MobX（状态管理框架，小项目用 useState 够了）
- SSR（服务端渲染，后面再说）
- CSS-in-JS 各种方案（先用最简单的 CSS Modules）

为什么这一步重要？ 因为 AI 有个毛病：你问它一个新领域，它会把所有东西都倒给你。”最小知识地图”逼它只说最关键的。

第 2 步：让 AI 用你熟悉的概念做类比

请把 React 的概念映射到 Java/Spring Boot 的概念：
| React 概念 | Java/Spring 对应物 | 差异点 |

AI 输出：

React 概念	Java/Spring 对应物	关键差异
Component	Controller + Template	React 是前端渲染，不是服务端
Props	方法参数 / DTO	单向数据流，父→子
useState	实例变量	改值会自动触发重渲染
useEffect	@PostConstruct / @Scheduled	组件挂载/更新/卸载时执行
React Router	@RequestMapping	前端路由，不走服务器

这张表让你用已有知识理解新知识，不需要从零学起。

第 3 步：写一个最小可运行示例

请给我一个最小的 React 项目，验证我理解了以上 5 个概念：
- 有 2 个页面（首页 + 用户列表）
- 首页有个计数器（验证 useState）
- 用户列表从 API 加载（验证 useEffect）
- 两个页面之间能跳转（验证 Router）

要求：
1) 给我创建命令（用 Vite）
2) 给我完整代码
3) 给我运行命令
4) 告诉我打开后应该看到什么

关键：这个示例不是为了”做东西”，是为了验证你确实理解了。

第 4 步：在真实项目中限定范围使用

理解了基础概念后，在真实项目里用，但要限定范围：

我要给 Orion 项目加一个前端管理页面。

约束：
- 只用 useState 和 useEffect，不引入状态管理库
- 只做 3 个页面：通知列表、通知详情、发送通知
- 用 CSS Modules，不用 Tailwind/styled-components
- 先做能用的，不追求完美

请出 tasks.md。

“限定范围”是扩的核心：你刚学的东西，用最小子集做最小功能。等这一轮做完，你对 React 的理解就从”AI 说的”变成”我亲手验证过的”了。

第 5 步：踩坑记录——从”AI 教的”变成”我自己的”

每次扩展新领域，我都会让 AI 帮我维护一个”踩坑笔记”：

请帮我更新 docs/learning/react-gotchas.md，记录以下踩坑：
1) useState 在 useEffect 里直接用会导致死循环
2) useEffect 的依赖数组不能省，否则每次渲染都执行
3) 跨组件传数据不要用全局变量，用 props 或 context

这个笔记就是你的”扩展验证记录”——不光记录你学了什么，还记录你踩了什么坑。

---

实战案例：从 Python 扩展到 K8s 部署

在 ai-shifu 项目中，我们一开始用 Docker Compose 部署。后来用户量上来，需要上 K8s。团队没人专门搞过 K8s。

我的做法：

第 1 步：画地图

我们现在用 Docker Compose 部署（5 个服务：nginx/web/api/mysql/redis）。
要迁移到 K8s。

请给我最小知识地图：
1) 从 Docker Compose 到 K8s，我必须理解哪些概念？
2) 每个概念对应 docker-compose.yml 里的什么？
3) 我可以先不管什么？

第 2 步：映射概念

Docker Compose	K8s 对应物	作用
service	Deployment + Service	定义容器怎么跑 + 怎么被访问
ports	Service (NodePort/LoadBalancer)	暴露端口
volumes	PersistentVolumeClaim	持久化存储
depends_on	没有直接对应，用 initContainer	启动顺序
docker-compose.yml	一堆 yaml 文件	你没看错，K8s 就是写 yaml

第 3 步：最小验证

请把我们的 docker-compose.yml 转成 K8s 配置：
- 只转 api 和 redis 两个服务（最小子集）
- 给我 kubectl 部署命令
- 给我验证命令（怎么确认跑起来了）
- 用 minikube 本地测试

第 4 步：验证能跑

# 先在本地 minikube 验证
minikube start
kubectl apply -f k8s/
kubectl get pods          # 确认 pod 都 Running
kubectl port-forward svc/api 8080:8080
curl http://localhost:8080/api/healthz   # 确认能访问

第 5 步：记录踩坑

## K8s 踩坑笔记

1. ConfigMap 改了不会自动重启 Pod，需要手动 rollout restart
2. MySQL 必须用 StatefulSet，不能用 Deployment（有状态服务）
3. PVC 的 accessModes 在不同云厂商支持不一样
4. Service 的 ClusterIP 只能集群内访问，外部要用 NodePort 或 Ingress

---

扩的边界：什么该扩，什么不该扩

适合用 AI 扩展的

• 新语言/框架的基础使用：Java→Go、React→Vue
• 运维工具：Docker→K8s、Nginx→Traefik
• 新 API/SDK 的对接：从没用过的第三方服务
• 简单算法实现：排序、搜索、简单推荐

不适合盲目扩展的

• 安全领域：加密、认证方案不能只靠 AI，必须有专业审查
• 性能优化：AI 给的优化建议可能适得其反，必须有 benchmark
• 架构决策：微服务还是单体、用什么数据库，这些需要人的判断
• 合规相关：GDPR、数据安全，AI 不懂你的业务上下文

---

扩的心法：可验证 > 看起来对

“扩”的核心不是”AI 教了我多少新东西”，而是”我能验证多少新东西”。

AI 说能用  →  不算
你抄了一遍  →  不算
跑起来了  →  勉强算
有测试证明  →  才算
上线没出事  →  真的算

每次扩展新领域，问自己一个问题：“如果半夜 3 点这个东西挂了，我能修吗？”

• 能修 → 你真的学到了
• 不能修 → 你只是在用 AI 搭积木，迟早要倒

---

和前面几式的配合

“扩”不是孤立的，它需要前面所有招式的支撑：

• 学：先用”学”的方法搞懂新领域的黑话
• 喂：把新领域的官方文档喂给 AI
• 规：用 tasks.md 控制扩展的节奏（别一口吃太多）
• 验：新领域的代码更需要交叉验证
• 测：新领域的代码更需要测试（你不熟的东西，更不能靠”感觉”）

---

总结

“扩”的核心就一句话：AI 帮你扩展认知边界，但学到的必须能验证。

• 先画地图（5 个核心概念就够）
• 用已有知识做类比（降低学习成本）
• 最小示例验证理解
• 限定范围在真实项目使用
• 踩坑记录沉淀为自己的知识

AI 是最好的老师，但老师说的不一定对——你得自己做题验证。

下一式（也是最后一式）我们讲 收：东西做完了，怎么上线、怎么监控、怎么复盘。