核心思想：将 AI 从“代码生成器”升级为“架构执行者”。通过强制分离思考（Thinking）与编码（Coding），实现高质量、可维护的 AI 辅助开发。
痛点分析：为什么直接让 AI 写代码总是翻车？
很多开发者使用 AI 的习惯是线性的：输入 Prompt -> 生成代码 -> 运行报错 -> 把错误丢给 AI -> 修修补补 -> 代码成了一团乱麻。
这种模式在处理 Demo 级项目时很爽，但在面对企业级复杂业务时极易崩溃：
上下文丢失：AI 忘记了 10 分钟前的需求。
幻觉严重：引用了不存在的 API 或错误的依赖版本。
逻辑正确但架构错误：代码跑通了，但破坏了原有的设计模式（比如在纯函数里写了副作用）。
核心原则：批准计划前，禁止写一行代码
我的最佳实践是将开发流程严格拆分为三个阶段：深度调研 -> 书面规划 -> 机械执行。
第一阶段：深度调研 (Deep Research)
目标：让 AI 建立对项目的“空间感知”，防止盲人摸象。
在动手前，不要急着给需求，先让 AI “读透”相关代码。（推荐使用 Google Gemini Deep Research）
操作要点：要求 AI 遍历相关目录，理解架构、依赖和特定实现细节。
关键指令示例：
“请深入阅读
src/services/auth文件夹，透彻理解其工作原理、异常处理机制及所有特殊逻辑。请忽略测试文件。完成后，在docs/research.md中编写一份详细的研究报告，指出我如果修改登录逻辑可能会破坏哪些现有功能。”产出物：一份
research.md，确认 AI 真的懂了。
第二阶段：书面规划与批注循环 (The Annotation Cycle)
目标：把 AI 当成“主理建筑师”，而你是“总工”。这是最关键的一步。
生成计划：要求 AI 将实现思路写进
plan.md。必须包含：涉及的文件列表、核心代码片段（伪代码）、潜在风险、回滚方案。
人工批注 (The Human Touch)：
不要在聊天框里跟 AI 吵架。
直接在 IDE 里打开
plan.md，像做 Code Review 一样在文档里写注释：“❌ 这里不要引入新库，复用
utils/date.ts。”“⚠️ 注意，用户 ID 可能是字符串也可能是数字，这里要兼容。”
“🎨 参考
UserList组件的样式，保持 UI 一致。”
反馈迭代：告诉 AI：“我更新了 plan.md，请阅读并修正计划，先不要写代码”。
任务清单化：在计划定稿后，要求 AI 在文末生成一个 极细颗粒度 的 Checkbox 任务清单。
第三阶段：机械执行 (Automated Implementation)
目标：将编码变成“填空题”，降低 AI 的自由发挥空间。
一旦 plan.md 锁死，编码阶段应该是枯燥且标准的。
标准执行指令：
“现在开始全面执行计划。严格按照
plan.md的步骤进行。每完成一个 Task，请主动更新
plan.md中的复选框状态。保持严格的 TypeScript 类型定义，禁止使用
any。每修改一个文件，立即运行
npm run typecheck确保无类型错误。如果遇到不在计划内的意外情况，立即停止并询问我，不要擅自做决定。”
你的角色：从“架构师”转变为“监工”。你只需要在它跑偏时给一句简短的修正（例如：“样式再宽 2px”）。
进阶技巧：如何更好地驾驭 AI？
1. 上下文管理 (Context Management)
不要一股脑把整个项目丢给 AI。
减法艺术：在
.cursorrules或.windsurfrules中配置忽略文件（如package-lock.json,dist/,node_modules/）。按需投喂：只把当前任务相关的 3-5 个核心文件加入上下文。
2. 验证驱动 (Verification Driven)
在 Plan 阶段，要求 AI 包含“验证步骤”。
“在实现功能后，请编写一个单元测试
tests/auth.test.ts来验证登录失败的场景。”“请提供一个 cURL 命令，让我可以手动测试这个 API。”
3. 留痕 (Documentation)
这一套流程下来，你的 research.md 和 plan.md 本身就是极佳的项目文档。
建议：将这些文档归档到
docs/archived/，作为后续维护的重要参考。
总结：慢即是快
这套流程看起来比“直接生成代码”要繁琐，多了写文档的时间。
但在实际开发中，它能帮你省下 80% 的 Debug 和重构时间。
减少幻觉：因为有 Research 阶段。
减少返工：因为有 Plan 阶段的 Code Review。
可维护性：代码是按照你批准的架构写的，而不是 AI 随机生成的。
下次开发 Feature 时，试着先创建一个 plan.md，你会发现掌控感完全不同。