AI IDE 工作流技巧：用 Agent 工具拆需求、定位问题

AI IDE 最大的风险是过早动手。没有读过项目结构、测试、现有模式和最近改动，就开始生成代码，很容易写出风格不一致或破坏边界的实现。

我更常做的第一步是让工具找文件、读测试、看数据流，再总结修改面。这样后面的实现会贴近现有系统，而不是重新发明一套写法。

这和普通开发一样：先理解上下文，再动手。AI 只是加快了搜索和比对，不应该跳过判断。

一个模糊需求交给 AI，很容易得到一大坨不可验证的改动。更稳的方法是拆成测试、实现、文档、验证几个小任务。

比如新增作品集项目，不是“帮我加一个项目”，而是先加内容测试，再补首页数据，再补 case study，再更新 sitemap 和路线图。每一步都有失败和通过的证据。

AI IDE 的价值不只是写代码快，而是能帮助维持这种小步推进的节奏。

遇到测试失败时，不要让 AI 直接猜修法。先读错误、复现、找最近改动、比较工作样例，再形成假设。

这次作品集里 sitemap 测试失败就是一个例子：根因不是页面坏了，而是新增 case study 后 sitemap 动态生成了更多路由，测试期望需要同步。

AI 工具很适合快速收集证据，但最终判断仍然要回到根因，而不是把第一个报错当作修复方向。

计划文档很有用，它能把文件、测试、验证命令和提交范围写清楚。但计划也可能犯错，比如数量不一致、范围膨胀、测试和实现不匹配。

所以执行前要先 review 计划。发现计划说 5 篇笔记、实际又加第 6 篇，就应该先修正，而不是硬着头皮执行。

AI IDE 工作流的重点不是盲目信任代理，而是把代理输出纳入正常工程复核。

完成任务前，必须跑能证明结果的命令：typecheck、lint、单测、构建，必要时再跑浏览器检查。

这不是形式主义。没有验证输出，就无法区分“我觉得改好了”和“系统确认可以工作”。

AI IDE 可以提高速度，但不能替代工程里的证据链。真正可交付的工作，最后一定要回到验证结果。