应用生成后怎么继续改迭代

第一个版本上线只是开始。真实使用中，改文案、调布局、加功能是常态。这一页讲在 App 里迭代一个已生成应用的方法，以及什么时候该推倒重来。

三种迭代手段

• 插话改需求：对现运行的应用说「导航栏加一个联系入口」，Agent 在现有代码基础上改。适合一切增量化调整，机制见任务跑到一半还能插话改需求吗。
• 检查点回溯：某次改动方向错了，回到改动前的节点重新走，避免错误改动污染后续版本，机制见任务走偏了用检查点倒回去重来。
• 给参考再改：视觉类改动（配色、版式）给一张参考图或截图，一轮到位的概率远高于文字描述，这是官方明确建议的做法。

迭代的节奏建议

小步快跑是省积分的迭代方式：一次插话解决一个问题，改完验收再提下一个。把十条需求攒成一次大改，风险在于方向性错误发现得晚、返工范围大。

每轮迭代后重复同样的验收动作：主流程走一遍、新改动重点测、真实数据再验一次——与初版验收一致，见生成的应用谁来测试稳定性。

什么时候该重开任务

遇到这几种情况，重新描述一个新任务往往比继续打补丁更省：

• 需求本身换了：原来的工具站要变成电商站，核心目标变了，补丁会越打越乱。
• 技术方向性返工：数据结构层面的调整反复出错，从零重建可能比修补快。
• 任务记录已经很长：超长任务流的上下文负担会拖慢执行质量，新开任务并把成品代码作为背景材料上传是干净的路径。

重开任务时的材料准备，见把材料交给AI什么格式都能读吗。

迭代方法依据官方使用技巧整理，具体操作形式以实际版本为准。