用 AI 做开发：实战方法论

用 AI（Claude Code / Cursor）做了几个项目后，总结出一套实战方法论。核心思想：AI 是强大的执行者，但需要你提供清晰的上下文和指令。

一、上下文恢复：每次 Session 的第一件事

AI 没有记忆。每个新 Session 都是白纸，上下文恢复的质量直接决定工作质量。

建立一套文档体系：项目进度总结（全局状态）、AI_review.md（Session 级记录）、CLAUDE.md（常驻指令）。每次新 Session 的第一句话：

读 keyfield/项目进度总结.md + keyfield/AI_review.md（最后 3 个 Session）

先花 2 分钟恢复上下文，后面能省 2 小时排错。

二、需求沟通：先验证再动手

AI 最擅长「执行明确的指令」，不是「理解模糊的意图」。

分步确认法：先讨论方案 → 产出方案文档 → 确认后再执行。

什么时候需要先讨论：

• 改动 3 个以上文件
• 有多种实现路径
• 涉及核心业务流程
• 改了很难回头

三、验证策略：不要相信「应该没问题」

四层验证：

1. 单元验证：每个函数单独测试，打印原始输入输出
2. 业务逻辑验证：用已知数据对比输出，这是最快确认正确性的方式
3. 端到端验证：从输入到输出的完整链路
4. 部署验证：本地 OK 不代表服务器 OK

黄金法则：能用真实数据验证的，绝不用 mock 数据。

四、排错：从现象到根因

AI 排错的瓶颈不是「不会修」，是「不知道哪里坏了」。

通用流程：

1. 复现问题：打印原始数据，看 AI 看到的是什么
2. 隔离问题：在每一层的输入输出打印数据，找到「正确→错误」的转折点
3. 定位根因：不要假设，用数据说话
4. 修复并验证：修复后用同样用例验证，同时检查是否有同类问题

五、增量开发：分 Phase 推进

大改动拆成小步骤，每步可验证。要点：

• 每个 Phase 独立可验证
• Phase 之间有明确的依赖关系
• 即使中途停下，已完成的部分也是可用的
• 出问题时范围锁定在一个 Phase 内

当 AI 要一次改很多文件时，主动要求拆分 Phase。

六、架构决策：你做选择

AI 擅长列举方案和分析利弊，最终决策由你做。关键追问：

1. 这个方案有什么风险？
2. 如果后面需求变了，改起来难不难？
3. 有没有更简单的方案？

七、文档管理：Session 间信息传递

每个 Session 结束时的文档更新 = 下个 Session 的启动效率。

五条黄金法则

1. 先恢复上下文，再开始工作
2. 先讨论方案，再写代码
3. 每步都验证，不要攒到最后
4. 用真实数据验证，不用 mock
5. Session 结束时更新文档