模块五：领域知识深度
你自己懂得越深，AI 给你的上限越高
AI 在你手里的上限 = min(AI 能力, 你的判断力)。整门课最重要的一讲：What/How/Why 三层知识模型、语言框架 / 领域概念 / 工程实践 / 系统架构 / 历史上下文五大维度。
这是整门课最重要的一课
前四个模块教的都是"怎么和 AI 协作"的技巧。这个模块不一样——它教的是你自己。
一个残酷的等式：
AI 在你手里的上限 = min(AI 的能力, 你的判断力)
如果 AI 能力是 90 分，你的判断力是 60 分，那 AI 在你手里就是 60 分——因为超出 60 分的部分你分不清对错。
反过来，如果你的判断力是 95 分，AI 能力是 90 分，你能把 AI 的 90 分几乎全部利用，还能补上 AI 缺的 10 分。
领域知识不是 AI 时代的"可选项"，而是"放大器的底座"。底座越高，放大效果越好。
"深度"意味着什么
领域知识的深度不是"知道更多 API"，而是在三个层次上有理解：
┌─────────────────────────────────────────────┐
│ Level 3：为什么（Why） │
│ 架构决策背后的权衡、技术选型的原因 │
│ "为什么用 MobX 而不用 Redux" │
│ "为什么 fftSize 设 2048 而不是 256" │
├─────────────────────────────────────────────┤
│ Level 2：怎么做（How） │
│ 具体实现方式、最佳实践 │
│ "怎么用 AnalyserNode 实现音量检测" │
│ "MobX store 的 action 怎么写" │
├─────────────────────────────────────────────┤
│ Level 1：是什么（What） │
│ API 文档级的知识 │
│ "getUserMedia 返回 MediaStream" │
│ "MobX 有 observable/action/computed" │
└─────────────────────────────────────────────┘
AI 在 Level 1 和 Level 2 上很强，在 Level 3 上很弱。
AI 知道 AnalyserNode 的所有 API 参数（What），也知道怎么用它做音量检测（How），但它不知道在你的项目中为什么选择 fftSize = 2048 而不是 1024（Why）——也许是因为你的音频源是语音而非音乐，需要更高的频率分辨率来区分不同元音。
你的价值就在 Level 3。
领域深度如何影响 AI 协作
场景一：判断输出正确性
AI 生成了这段代码：
const audioContext = new AudioContext({ sampleRate: 44100 });
- 浅层知识："44100 是 CD 音质的采样率，应该没问题"
- 深层知识："我们的 ASR 服务只接受 16000Hz 的输入。虽然 44100 能录音，但后端还要做降采样，白白浪费计算。应该设 16000。而且 getUserMedia 中设 sampleRate 在部分浏览器不生效，真正的重采样得在 AudioContext 层做"
深层知识让你在 5 秒内判断出 AI 输出虽然"能跑"但"不是最优解"。
场景二：提供精确的上下文
AI 写了一个行泊切换的处理函数：
if (isParking) {
this.driveMode = EDriveMode.Parking;
}
- 浅层反馈："这个判断不完整"
- 深层反馈："这里需要区分 papStatus === 2（泊车）和 papStatus === 1（行车），不能只处理泊车。另外在 replay 模式下不应该 reload 页面，参考 updateDriveModeFromBack 方法的第 270 行"
深层知识让你的反馈精确到代码行级别，AI 一轮就能改对。
场景三：架构决策
AI 建议用 Redux Toolkit 重构状态管理。
- 浅层判断："Redux 也可以啊，都是状态管理"
- 深层判断："我们的项目用 MobX 不是偶然的——3D 渲染场景需要细粒度的响应式更新，MobX 的 observable 比 Redux 的 selector 更适合高频数据流。而且整个团队对 MobX 的 decorator 模式已经形成了肌肉记忆，迁移成本远大于收益"
深层知识让你在 5 秒内否决一个方向完全错误的建议，省下可能浪费的几小时。
五个领域知识维度
在 AI 辅助开发中，以下五个维度的知识深度直接决定你的效率：
维度一：语言和框架
不只是会用 API，而是理解设计哲学和内部机制。
| 浅层 | 深层 |
|---|---|
知道 useEffect 的用法 | 理解 React 的渲染周期、闭包陷阱、依赖数组的原理 |
会写 MobX action | 理解 MobX 的代理机制、何时触发重渲染、计算属性的缓存策略 |
| 会用 TypeScript 泛型 | 理解类型收窄、条件类型、模板字面量类型的组合用法 |
AI 在这个维度上能帮你"查文档"，但不能帮你理解"为什么这样设计"。
维度二：领域概念
你的业务领域中的核心概念和数据模型。
例如在 HMI（人机交互）系统中：
| 浅层 | 深层 |
|---|---|
| 知道有行车和泊车两种模式 | 理解行泊状态机（None → Driving ↔ Parking）的完整跳转条件 |
| 知道 WebSocket 传数据 | 理解 MULTI_WS 和 CMD_WS 的分工、数据帧格式、心跳机制 |
| 知道 3D 场景会渲染障碍物 | 理解坐标系统（车体坐标 vs 世界坐标）、渲染层级、LOD 策略 |
领域概念是 AI 最缺的——因为它不了解你的具体业务。
维度三：工程实践
超越代码本身的工程知识。
| 浅层 | 深层 |
|---|---|
| 知道要写测试 | 知道在这个项目中测什么（纯逻辑函数）、不测什么（Three.js 渲染） |
| 知道要做性能优化 | 知道瓶颈在哪里（Canvas 重绘、TypedArray GC、WebSocket 消息频率） |
| 知道要处理错误 | 知道哪些错误可恢复（网络断连重试）、哪些不可恢复（麦克风权限被拒） |
维度四：系统架构
组件之间如何组合、数据如何流动。
用户操作 → 组件 → MobX Store → WebSocket → 后端
↓
渲染管线 → Three.js → Canvas
知道这个全景图，你才能判断 AI 改某个 Store 的代码是否会影响渲染管线。
维度五：历史上下文
项目中那些"为什么这样写"的历史原因。
- "这个 HACK 是因为后端在某个版本有 bug，不得不在前端绕过"
- "这个 setTimeout 100ms 是实测出来的最小延时，低于这个值界面会闪烁"
- "这个字段叫 papStatus 而不是 parkingStatus 是因为 PAP（Parking Assist Pilot）是产品的正式命名"
这类知识 AI 永远不知道，只有你知道。 这也是你最不可替代的价值。
如何加深领域知识
方法一：用 AI 加速学习
讽刺的是，AI 是加深领域知识的最好工具。
"解释一下 Web Audio API 的 AnalyserNode 的 fftSize 参数，
在不同值下频率分辨率和时间分辨率怎么变化，
用表格对比 256/1024/2048/8192 的区别"
AI 给你的解释比大多数文档更清晰、更有针对性。然后你用这些知识来指导 AI 写更好的代码——正反馈循环。
方法二：读代码比写代码更重要
在一个已有项目中，读懂现有代码的价值远大于"能写新代码"。
建议的阅读路径：
- 从入口文件开始（
index.tsx→App.tsx→ 路由 → 页面） - 追踪一条完整的数据流（用户点击 → 状态变更 → 渲染更新）
- 找到项目中最复杂的模块，理解它为什么这么复杂
方法三：刻意做"Why"练习
每天花 10 分钟看项目中的某段代码，问自己三个"为什么"：
为什么 updateDriveModeFromBack 在 replay 模式下不 reload 页面？
→ 因为 replay 模式是回放数据，reload 会打断回放流程
为什么 triggerDriveMode 要发 3 次 pap_switch_req？
→ 因为 WebSocket 消息可能丢包，发 3 次是冗余保证
为什么 AudioContext 创建后要检查 state 是否为 suspended？
→ 因为浏览器的自动播放策略，非用户交互创建的 AudioContext 不会自动运行
方法四：参与架构讨论
即使你当前是执行者角色，也要关注团队的架构决策讨论——为什么选这个技术栈、为什么这样拆模块、为什么这个接口这样设计。
这些 "Why" 级别的知识，只有在讨论中才能获得。
方法五：让 AI 帮你整理知识
"帮我把前端音频处理的所有知识整理成一份完整的技术文档，
从采集到编码到分析到播放"
AI 帮你生成草稿，你在 review 中补充你的项目特定知识。最终产出既是团队文档，也是你的知识沉淀。
反模式 vs 正确做法
反模式一：只学 AI 工具，不学技术本身
差：花大量时间研究各种 AI 工具的 Prompt 技巧，但对 React、TypeScript 只停留在"能用"的程度
好：把 70% 的学习时间投入技术深度，30% 投入 AI 协作技巧
Prompt 技巧有天花板（这门课 5 个模块就讲完了），但技术深度没有天花板。
反模式二：知其然不知其所以然
差：AI 说 fftSize 用 2048，就用 2048，不问为什么
好：AI 说 fftSize 用 2048，我追问为什么不用 1024，
理解了频率分辨率和时间分辨率的权衡后，
根据我的场景（语音 vs 音乐）做出自己的判断
反模式三：不积累项目知识
差：每次碰到不懂的代码就让 AI 解释，用完就忘
好：碰到重要的代码逻辑，理解后写进团队文档或 Rules 文件，
下次自己和 AI 都能直接引用
实战练习
练习 1：数据流追踪
选你项目中一个核心功能（比如行泊切换），从用户触发到最终 UI 更新，画出完整的数据流图。标注：
- 经过了哪些文件/模块
- 每一步数据的格式是什么
- 哪些环节是同步的，哪些是异步的
练习 2：三个为什么
打开你项目中一个你没写过但经常碰到的文件，找 3 段代码，对每段问"为什么这样写"。
- 如果能答上来：说明你对这个模块理解够深
- 如果答不上来：这就是你的知识盲区，需要深入了解
练习 3：知识对比实验
选一个你非常熟悉的技术领域和一个你不太熟的领域，分别让 AI 帮你完成一个中等复杂度的任务。对比：
- 两个任务各迭代了几轮
- 你在熟悉领域给的反馈有多精确
- 你在不熟领域是否接受了 AI 的错误输出而不自知
练习 4：教学输出
选一个你深入理解的技术点，让 AI 帮你写成教学文档（类似 audio-guide.md）。在 review 过程中：
- AI 写对了哪些？（验证 AI 的 Level 1 和 Level 2 能力）
- AI 写错或遗漏了哪些？（找到 AI 的 Level 3 盲区）
- 你补充了哪些 AI 不知道的知识？（这就是你的独特价值）
练习 5：领域知识投资规划
列出你当前工作中涉及的 5 个技术领域，对每个领域评估自己在 What/How/Why 三个层次的掌握程度（1-5 分）。找到 Why 层得分最低的 2 个领域，制定未来一个月的学习计划。
思考题
AI 会取代哪些知识：随着 AI 越来越强，What 层和 How 层的知识价值会持续下降。那 Why 层呢？有没有一天 AI 也能理解"为什么"？如果那一天来了，开发者的不可替代性在哪里？
T 型能力 vs I 型能力：在 AI 时代，是该广泛了解多个领域（T 型），还是深入精通一个领域（I 型）？AI 是否改变了这个权衡？
知识的半衰期：前端技术迭代极快，今天学的框架 3 年后可能过时。但"为什么这样设计"的思维方式不会过时。你怎么分配学习时间在"会过时的知识"和"不会过时的思维"之间？
团队知识分布：在一个使用 AI 的团队中，是应该每个人都深入了解整个项目，还是每个人深入了解一部分然后通过 AI 覆盖其余部分？哪种模式更健壮？
知识输出的价值：写文档、做分享、带新人——这些"输出型"活动是否在 AI 时代变得更有价值了？因为你整理好的知识可以直接写进 Rules 文件，让 AI 也学会？