迭代开发节奏

用 AI 写代码时，项目不是一次“生成”出来的，而是一轮一轮推出来的。

如果你连续让 AI 做十几步，中间不运行、不检查、不提交，最后得到的可能是一堆看起来完整的代码：页面有了，接口也有了，类型也写了，但启动时报错，修一个地方又牵出另一个地方。最麻烦的是，你已经不知道问题是从哪一轮开始的。

迭代开发节奏讲的就是这件事：每次只推进一个可验证的小单元，写完就跑，跑完就看，看清楚再继续。

一轮到底是什么

在 AI 辅助开发里，一轮不是“AI 回复了一次”，也不是“生成了一段代码”。一轮应该包含完整的闭环：

明确本轮目标
让 AI 修改
运行项目或测试
检查结果
决定继续、修正或回退

比如你正在做 Todo 应用，本轮目标是“给 Todo 列表加删除功能”。这轮结束的标志不是 AI 说“删除功能已完成”，而是你能在页面上新增一条 Todo，点击删除后它确实从列表消失，控制台没有新的报错，相关测试也能通过。

如果没有验证，这轮就还没结束。

写、跑、看、继续

一个实用的节奏可以很朴素：

写：只让 AI 做当前小任务。
跑：运行 dev server、测试、lint 或最小复现。
看：看页面、终端、diff 和错误信息。
继续：稳定就进入下一轮，不稳定就先修当前轮。

“跑”不一定每次都是完整测试。前端页面改动可以先启动本地服务，点一遍关键路径；工具函数改动可以跑单测；文档或配置改动可以跑构建。关键是你要在这一轮里拿到真实反馈。

“看”也不只是看功能有没有出现。你还要看 diff 有没有越界：AI 有没有改了没提到的文件，有没有顺手重构，有没有把已有命名风格改掉。越早发现，越容易纠正。

不要把修错和做新功能混在一起

项目节奏开始乱，通常不是因为某一次改动特别大，而是你在同一轮里同时做了太多性质不同的事。

比如你让 AI 加筛选功能，它改完后页面报错。你把报错贴回去，它顺手改了状态结构，又补了样式，还调整了路由。看上去它一直在努力修，但你的任务已经从“加筛选”变成“重整 Todo 页面”。再往后，任何问题都很难定位。

更稳的做法是把本轮收窄：

刚才的目标仍然是“筛选功能”。
请只修复当前报错，不要改筛选逻辑以外的文件。
修复后说明错误原因和验证方式。

如果错误暴露出设计问题，比如状态结构确实不适合继续扩展，那就暂停当前轮，开一个新的任务处理重构。不要让重构混在 bugfix 里悄悄发生。

什么时候该开新对话

AI 对话不是越长越好。对话太长之后，它可能记住了大量过期信息：已经删除的文件、改过的方案、前几轮的错误猜测。你继续让它工作，它会把旧上下文带进新任务。

下面几种情况适合开新对话：

• 当前对话里出现过多次错误修复，AI 已经开始反复改同一个地方。
• 任务阶段变了，比如从本地状态切到后端 API，前面的讨论不再是主要上下文。
• 你已经完成一个稳定点，代码能跑，准备进入下一块功能。
• AI 开始引用不存在的文件、旧接口或你已经否定过的方案。

开新对话不是从零开始。你可以带上更干净的上下文：

当前项目已完成：
- Todo 页面骨架
- 新增、删除、完成
- localStorage 持久化

现在要做：
- 增加“全部 / 未完成 / 已完成”筛选

请先阅读 `src/pages/Todos.tsx` 和 `src/hooks/useTodos.ts`，不要改登录相关代码。
完成后运行现有测试，并告诉我手动验证步骤。

这比把旧对话继续拖下去更稳，因为你主动整理了当前事实。

用 git 做安全网

AI 辅助开发时，git 不只是最终提交工具，更像每一段稳定进度的存档。

一个简单习惯是：每完成一个能运行的功能单元，就提交一次。提交不用大，但要对应一个真实稳定点。

commit 1：搭建 Todo 页面骨架
commit 2：实现本地新增和删除
commit 3：加入 localStorage 持久化
commit 4：增加登录态保护

这样做有两个好处。第一，AI 改坏了你可以清楚看到它从哪个稳定点偏掉。第二，你 review diff 时不会一次面对几百行混杂改动。

在让 AI 做高风险修改前，也可以先确认工作区状态：

请先查看当前 git diff，总结已有改动。
接下来只修改筛选功能相关文件，不要碰已经完成的登录逻辑。

如果你还没准备提交，也至少保持“当前能跑”的节点清楚。不要在一个已经报错的状态上继续叠新功能。

怎么判断正在稳定推进

稳定推进不等于功能数量增加得快。更可靠的判断是：每一轮之后，项目都能回到一个可运行、可解释、可继续的状态。

你可以观察几个信号。

页面或测试能跑到下一步。哪怕功能还很小，只要它是真的可运行，就比一口气生成五个半成品更好。

diff 能讲清楚。你能看懂这轮为什么改这些文件，也能把无关改动指出来让 AI 收回。

错误不会越修越散。一个报错修完后，问题范围应该变小。如果修一次引出三个新文件变化，先停下来读 diff，不要继续让 AI 自由发挥。

上下文还能被一句话概括。比如“当前在做 Todo 筛选，数据仍然来自 localStorage”。如果你已经说不清现在到底在做登录、筛选、样式还是路由，说明节奏已经乱了。

一个小型迭代示例

仍然用 Todo 应用举例。你可以这样推进筛选功能：

本轮目标：
在 Todo 页面增加“全部 / 未完成 / 已完成”三个筛选按钮。

边界：
- 不改 Todo 数据结构
- 不改 localStorage 逻辑
- 不新增路由

验证：
- 添加两条 Todo
- 把其中一条标记完成
- 点击三个筛选按钮，列表数量正确变化

AI 改完后，你先跑页面并手动点一遍。如果按钮能工作，但样式很粗糙，这轮也可以先结束。样式优化可以是下一轮。不要因为“顺手美化一下”把一个已经可验证的功能拖进更大的改动里。

这种节奏一开始会显得慢，尤其是你看着 AI 明明可以一次写很多代码的时候。但项目真正变复杂之后，慢半拍验证，通常比后面花一下午定位混乱 diff 更省时间。