Skip to main content

模块一：问题拆解能力

把大问题拆成 AI 能一次搞定的小问题

AI 编程第一课：把大需求拆成 AI 一次就能搞定的小任务。按技术层、变更范围、风险三种框架拆解，附反模式案例与实战练习。

为什么这是第一课​

AI 编程助手有一个根本性的限制：单次对话的上下文窗口是有限的。即使模型支持 128K tokens，真正高质量处理的信息量远小于此。

这意味着：你给 AI 一个巨大的、模糊的任务，它只能用"一次性猜测"去完成，命中率极低。但如果你给它一系列小而精确的任务，每次它都能做到 90%+。

10 个 90% 的小任务串联起来，远比 1 个 30% 的大任务可靠。

核心原则​

原则一：一次对话，一个清晰目标​

每次和 AI 的对话应该有且仅有一个目标。完成后验证，再开始下一个。

原则二：拆到"可验证"的粒度​

一个好的子任务应该满足：

  • 明确的输入输出：做什么、改哪里、期望什么效果
  • 可验证的完成标准：能跑 lint 通过、能跑测试通过、页面上能看到效果
  • 相对独立：不依赖其他未完成的子任务

原则三：按依赖关系排序​

拆完后要排出执行顺序——先做基础设施，再做业务逻辑，最后做界面。

拆解框架​

框架一：按技术层拆​

适用于"完整功能开发"场景：

需求：实现一个录音功能，带波形可视化和上传

拆解：
├── 1. 数据层：封装 useRecorder hook（getUserMedia + MediaRecorder）
├── 2. 分析层：集成 AnalyserNode 实时获取波形数据
├── 3. 视图层：Canvas 绘制波形动画
├── 4. 交互层：录音按钮状态机（idle → recording → paused → done）
└── 5. 网络层：录音文件分片上传

每一层都可以单独让 AI 做，做完就能独立验证。

框架二：按变更范围拆​

适用于"修 bug / 改需求"场景：

需求：行泊切换回放时 HMI 没有自动切到泊车布局

拆解：
├── 1. 定位：查看上次 git commit 改了什么
├── 2. 分析：哪条数据链路被破坏了
├── 3. 修复：恢复被误删的代码
└── 4. 验证：确认回放时能正常切换布局

框架三：按风险拆​

适用于"大型重构"场景：

需求：把状态管理从 class-based MobX 迁移到函数式写法

拆解（按风险从低到高）：
├── 1. 选一个最简单的 store 先迁移（如 monitorStore）
├── 2. 验证迁移后功能完全正常
├── 3. 总结迁移模式，形成模板
├── 4. 按模板批量迁移其他 store
└── 5. 处理边界 case（store 间互相引用、计算属性依赖等）

先小范围试错，成功后再扩大。

反模式 vs 正确做法​

反模式一：一口吃个胖子​

差：

帮我做一个完整的录音功能，要求：
1. 支持录音、暂停、继续、停止
2. 实时显示波形
3. 实时显示音量
4. 录完后可以回放
5. 支持上传到后端
6. 兼容 Safari
7. 加个降噪开关

AI 大概率会输出一个 300+ 行的大文件，里面充满了你不需要的假设、遗漏了关键细节、代码风格跟项目不一致。

好：

第1轮：帮我封装一个 useRecorder hook，只做录音的开始和停止，
      返回 { start, stop, audioBlob, isRecording }，
      参考 src/js/hooks/ 目录下的现有 hook 写法。

第2轮：在 useRecorder 基础上加暂停和继续功能，
      状态扩展为 idle | recording | paused。

第3轮：加一个 useWaveform hook，接收 MediaStream，
      用 AnalyserNode 每帧输出波形数据 Uint8Array。

...

反模式二：跳过验证直接继续​

拿到第一个任务的输出后，不验证就开始第二个。结果错误在后面放大，到第五步才发现第一步就错了。

正确做法：每一步完成后都验证——至少跑 lint，最好能在页面上看到效果。

反模式三：一步之内混合多种变更​

差：「帮我重构这个组件，顺便把它从 class 组件改成函数组件，还有里面的 API 调用也换成新的」

好：

第1轮：把这个 class 组件改成函数组件，逻辑不要改。
第2轮：API 调用从旧接口迁移到新接口。

一步只做一种变更，出了问题 git diff 一看就知道是哪种变更引入的。

实战练习​

练习 1：功能拆解​

选一个你项目中即将要做的需求，用"按技术层拆"的框架将它拆成 3-5 个子任务。要求：

  • 每个子任务用一句话描述清楚
  • 标注每个子任务的验证方式
  • 标注子任务之间的依赖关系

练习 2：Bug 修复拆解​

回忆一个最近修过的 bug，用"按变更范围拆"的框架重新拆解。对比你实际的修复过程，看看哪些步骤本可以更高效地交给 AI 做。

练习 3：逐步交付​

挑一个中等复杂度的功能，用拆解后的子任务逐步交给 AI 实现。刻意在每一步完成后做验证。记录：

  • AI 每一步的完成质量（满分 10 分打几分？）
  • 哪些步骤需要你介入修正？
  • 最终总耗时 vs 你估计一步到位让 AI 做的耗时

思考题​

  1. 粒度的权衡：子任务拆得越细越好吗？有没有"拆得太细"的情况？什么时候该合并几个子任务一起做？

  2. 拆解能力的来源：问题拆解能力和 AI 无关——它本质上是软件工程中的"任务分解"能力。你觉得这种能力怎么培养？看架构设计书？还是在项目中不断练习？

  3. AI 能帮你拆解吗：你能不能先让 AI 帮你拆解任务，然后再按拆解后的子任务逐步让 AI 执行？这种"AI 拆解 + AI 执行"的模式有什么优缺点？

  4. 团队协作中的拆解：如果你是 Tech Lead，需要把一个大需求拆成多个子任务分给团队成员（部分人用 AI 辅助，部分人不用）。拆解的粒度和方式会有什么不同？

  5. 重构场景的特殊性：重构（不改变行为，只改变结构）的拆解和新功能开发的拆解有什么根本区别？为什么重构更适合"按风险拆"？