如何在不弄坏的前提下迭代 AI 构建的应用

要在不弄坏 AI 构建的应用的前提下进行迭代，请每条提示词只改一件事，在预览中检查，并在继续之前保存一个检查点。描述你看到的情况，而不是你猜测代码是如何运作的；在动手构建大的改动之前先做规划；当某个改动出了问题时，回滚到最后一个正常的版本，而不是要求 AI 去修复它自己的修复。

应用的第一个版本通常几分钟就能完成。难的是第五十次改动，因为每一条新提示词都可能弄坏已经正常工作的东西。本指南介绍的就是避免这种情况的循环。

迭代循环

1. 选定一个改动。 一个功能、一个问题或一个页面。
2. 用用户看到和做到的事情来描述它。
3. 大的改动先规划。 先请 AI 给出计划，阅读后再开始构建。
4. 在预览中检查结果。 检查改动本身，以及它附近的流程。
5. 保存检查点或提交。
6. 重复。

每一步都是为了让改动保持小而可逆。

第一步：保留一份简短的清单

在写提示词之前，把你想改动的内容按重要性顺序写下来。这样可以避免你在一条消息中提出十个愿望，也让你在做到一半时突然冒出的新想法，有一个“先不做”的理由。

如果某个改动很大，就把它拆开。“添加团队账户”可以拆分为：创建团队、邀请成员、在团队之间切换、把数据限制在当前团队内。每一项都是一条单独的提示词。编写用户故事是完成这种拆分的好方法。

第二步：描述你看到的情况

除非你告诉 AI，否则它看不到你的屏幕。请指出具体的问题，并说明应该出现什么结果：

在手机上打开定价页面时，Pro 卡片的按钮在右边缘被截断。桌面端布局保持不变；在 640px 以下的屏幕上，让卡片纵向堆叠，并让按钮占满整个宽度。

对比一下“定价页面在手机上看起来很糟糕”。前者可以一次性完成并检查；后者则可能引来你并未要求的重新设计。

截图会有帮助。如果你的构建工具支持图片，请附上一张，并圈出问题所在。

第三步：大改动前先规划

对于会影响应用多个部分的任何改动（新的数据模型、支付、用户角色），请在代码修改之前先要求给出计划：

先不要修改代码。我希望用户属于某个团队，并且只能看到自己团队的项目。请规划这项改动：哪些表、页面和 API 路由会变化，现有用户的数据会发生什么，以及你会按什么顺序构建。

仔细阅读计划。如果计划有误，修正计划的成本远低于撤销一次已经完成的构建。

第四步：说明什么绝不能改变

AI 工具有时会“顺手整理”你没有要求改动的东西。请保护那些已经正常工作的部分：

在订单表格中添加日期筛选。不要改动表格的列、样式或导出按钮。

对于适用于所有地方的规则（品牌颜色、语气风格、“未经确认绝不删除数据”），请把它们放进 AI 每次都会读取的项目笔记文件或知识设置中，而不是每次都重复说明。

第五步：检查的不仅仅是改动本身

每条提示词之后，请测试：

• 改动本身。 它是否按你的要求工作，在桌面端和手机上都是如此？
• 相邻的部分。 同一页面上的其他内容，以及使用相同数据的流程。
• 关键路径。 注册、登录、主要操作、支付。每次大改动之后用三十秒做一次快速检查，就能在早期捕获大部分问题。

如果发现问题，请准确地描述它。参见如何写好一份 bug 报告。

第六步：回滚，而不是不断叠加

当一个改动弄坏了某个东西，而第一次修复又没有成功时，请停下来。每一次额外的“修复”都是建立在已损坏的状态之上的，问题会不断复合。

这时应该：

1. 回滚到最后一个正常工作的版本（检查点或 Git 提交）。
2. 找出提示词中哪里不够清晰。
3. 用更小或更清晰的请求重新尝试。

那次改动破坏了保存草稿的功能，我已经回滚。这一次：只添加自动保存指示器，以文字形式显示在页眉中。不要改变草稿的保存方式。

第七步：什么时候重建才是正确的

从头重建会丢弃大量已有的细节。只有在以下情况下才值得这么做：

• 产品构想已完全改变。
• 底层结构无法支撑你现在需要的功能，例如，它最初是作为静态网站构建的，而现在需要账户和数据库。
• 项目仍然接近空白。

如果要重建，请列出需要保留的内容：名称、颜色、文案，以及用户喜欢的部分。

示例提示词

在我们继续之前，请总结应用目前的工作方式：页面、它存储的数据，以及你认为脆弱的地方。

我想添加定期预订功能。最小的有用版本是什么？请把它建议为三个可以逐一完成的独立改动。

检查最近三次改动，看看是否有可能弄坏结账流程的地方。先不要编辑。

常见错误

• 一条提示词里提十个要求。 有些会完成，有些只完成一半，而你无法分辨哪些是哪些。
• 反馈含糊。“它坏了”或“让它更好”只会让 AI 去猜。
• 从不检查相邻的部分。 对某个共享组件的改动，可能会弄坏另外三个页面。
• 修复修复。 当一个问题已经深入到第四条提示词时，就应该回滚。
• 每次都重复背景信息，而不是把长期规则保存在项目笔记中。
• 卡住了就重建。 大多数“从头开始”的时刻，其实只需要回滚两步。

检查清单

• 每条提示词只有一个目标。
• 我描述了我看到的情况，以及应该出现的结果。
• 大的改动在编写任何代码之前都有计划。
• 我说明了什么绝不能改变。
• 每次改动后，我测试了它、它附近的部分以及关键路径。
• 每次成功的改动之后，我都保存检查点或提交。
• 修复失败时，我会回滚，而不是叠加修复。
• 长期规则保存在 AI 每次都会读取的项目笔记中。

在 Mythex 中迭代

Mythex 围绕这一循环而设计：

• 规划、构建和提问模式。 规划模式在编辑前讨论方案；提问模式只回答问题，不改动代码；构建模式负责实施改动。参见聊天。
• 检查点。 每次成功的回合之后，Mythex 都会保存一个 git 检查点；还原到此时间点可以回滚。你也可以编辑之前的一条消息，然后使用放弃并重新发送，从那一点开始尝试不同的提示词。参见无需重建即可迭代。
• 知识。 项目设置 → 知识 中保存着智能体在每条消息中都会遵循的长期笔记。
• /test 会让智能体在大改动之后，像用户一样点击预览界面。

较小的请求也消耗更少的积分。关于如何编写提示词本身，请参阅如何为 AI 应用构建器编写提示词；当出现问题时，请参阅如何调试 AI 构建的应用。

常见问题