如何调试 AI 搭建的应用：一套实用方法

要调试 AI 搭建的应用，先主动让 bug 再次出现，然后收集证据——确切的操作步骤、错误信息，以及浏览器控制台和网络面板显示的内容——并以“我做了 X，期望 Y，得到 Z”的形式交给 AI。如果某个修复让情况变得更糟，就回滚到最后一个能正常工作的版本，而不是在它上面继续叠加修改。你不需要读懂代码也能把这一切做好。

本指南涵盖完整的循环，并为非开发者快速介绍浏览器开发者工具。

调试循环

无论是人还是 AI 来修复 bug，每一次都遵循同样的循环：

1. 复现——让 bug 稳定地出现。
2. 观察——收集错误信息以及应用当时在做什么。
3. 描述——给 AI 准确的步骤、预期结果和实际结果。
4. 修复——让 AI 只改一件事。
5. 验证——重复完全相同的步骤，确认已修复，并且附近的功能没有被破坏。
6. 必要时回滚——如果情况变糟，撤销并带着更好的信息重新尝试。

在 AI 搭建的应用上，大部分浪费的时间来自跳过第 1、2、5 步：只说一句“坏了”，不测试就接受改动，然后在一个已经坏掉的版本上继续要求修复。

第 1 步：复现 bug

能按需触发的 bug，已经解决了一半。尽量找到引发它的最短操作步骤。

问问自己：

• **每次都会发生吗？**如果只是偶尔出现，那么发生时有什么不同——某条特定记录、较慢的网络，还是已经退出登录？
• **所有用户都会遇到吗？**用另一个账户登录。很多 bug 只会在没有任何数据的新用户，或具有不同角色的用户身上出现。
• **所有设备上都会发生吗？**试试手机宽度的屏幕和另一款浏览器。
• **是某次特定改动之后才开始的吗？**如果昨天还正常，那么最近的几次改动是首要怀疑对象。

把步骤写成一个简短的编号列表。稍后你会把它粘贴到提示词中。

第 2 步：读懂错误信息

错误信息看起来很吓人，但你只需要其中的几个部分。

你不需要完全理解它，只需要原样复制。“Cannot read properties of undefined (reading 'name')”告诉 AI，代码期望的某些数据（很可能是一条预订或一个用户）没有出现。如果你改写成“某个 undefined 错误”，就丢失了这些关键信息。

一些常见的错误，大致翻译如下：

• undefined / null 错误——代码期望的数据没有到达。通常是加载状态或空列表没有被代码妥善处理。
• 404 Not Found——页面或 API 地址不存在。通常是路由拼写错误，或者链接指向的页面已被重命名。
• 401 Unauthorized / 403 Forbidden——请求没有登录，或者该用户无权执行该操作。
• 500 Internal Server Error——服务器端代码崩溃了。真正的原因在服务器日志中，而不在浏览器里。
• CORS 错误——浏览器阻止了对另一个域名的请求。通常是服务器端的配置问题。

第 3 步：使用浏览器开发者工具

每个桌面浏览器都内置了开发者工具（“devtools”），它们会显示页面在幕后的运行情况。在 Chrome、Edge 和 Firefox 中，在页面任意位置右键点击并选择检查，或按 F12（Mac 上为 Cmd+Option+I）。在 Safari 中，需要先在 Safari 设置里开启“开发”菜单。

你只需要用到三个标签页。

控制台

控制台（Console）标签页列出页面代码产生的错误和消息。错误以红色显示。如果点击某个按钮没有任何反应，控制台通常会在你点击的那一刻显示一条红色错误。复制完整的错误文本（大多数浏览器中右键即可看到复制选项）。

网络

网络（Network）标签页列出页面发出的每一个请求——加载数据、保存表单、登录。打开它，然后重复导致 bug 的操作。

• 查找显示为红色、或状态码在 400 及以上的记录。
• 点击失败的记录，查看它的响应（Response）。服务器错误的响应里通常包含比屏幕上任何内容都更有用的信息。
• 记下请求的 URL 和状态码——“对 /api/bookings 的 POST 请求返回了 500”是一句非常有用的话，可以直接交给 AI。

如果 bug 涉及页面刷新或重定向，请勾选保留日志（Preserve log），这样请求就不会消失。

元素

元素（Elements）或检查器（Inspector）标签页显示页面的结构和样式。它对布局问题最有用：把鼠标悬停在某个元素上，就能看到它的尺寸和间距高亮显示。你不需要在这里编辑任何内容，只要能说出“页脚在手机上宽达 2,000 像素，把页面挤得左右滚动”就足够了。

第 4 步：检查服务器日志

有些 bug 发生在服务器端，浏览器看不到。网络面板中的 500 错误就是典型的信号。服务器日志——后端运行时输出的文本——通常包含真正的错误以及调用堆栈（即失败时正在运行的函数列表）。

日志的位置取决于你使用的工具。在大多数 AI 应用搭建工具中，你可以打开项目的终端或日志视图，或者直接问 AI：“检查上一次请求的服务器日志中的错误，并告诉我哪里失败了。”

第 5 步：向 AI 描述 bug

把你收集到的信息整理成这样的形式：

在“预订”页面，以会员身份登录：我点击了明天 9:00 课程的取消。期望：该预订消失，课程多出一个空位。实际：屏幕上没有任何变化。控制台显示 BookingCard.tsx:31 处的 TypeError: Cannot read properties of undefined (reading 'id')，网络面板显示 DELETE /api/bookings/123 返回了 500。请找出原因、修复它，并检查会员只有一个预订和有多个预订时取消功能是否都正常。

每个部分为什么重要：

• 在哪里、以什么身份，把范围缩小到一个页面和一种角色。
• 确切的步骤，让 AI 能够复现。
• 期望与实际，定义了什么叫“修好了”。
• 错误文本和失败的请求，直接指向原因。
• “检查……”，要求 AI 去验证，而不只是修改。

如果 AI 已经尝试修复两次都失败了，请让它在改动任何代码之前先解释：

先不要改代码。你认为是什么原因造成的？有什么证据支持这个判断？

错误的推断一旦写出来就很容易识别，而且纠正它的成本远低于一次错误的修复。

第 6 步：验证，然后检查附近的功能

当 AI 说已经修好时，重复第 1 步中的确切操作。然后检查周围的内容：

• 同样的操作，换一个不同角色的用户
• 同样的操作，在没有数据和数据很多时各试一次
• 与你修复的页面共用组件的其他页面
• 如果修复涉及布局，就在手机宽度的屏幕上检查

AI 的改动有时会修好一条路径，却悄悄破坏另一条。现在花两分钟检查，能省下之后一个小时的困惑。

第 7 步：回滚，而不是继续叠加

如果某次修复让情况变得更糟，或者你已经尝试了三轮却没有进展，就退回去。回滚到最后一个能正常工作的版本，并用更好的证据重新表述，几乎总比在三次错误修复的基础上再要求第四次修复要好。每次失败的尝试都会留下代码，而这些代码会干扰下一次尝试。

让回滚变得容易的良好习惯：

• 每次改动后都要测试，这样你才知道是哪次改动破坏了功能。
• 保持改动小——每条消息只涉及一个功能或一个修复。
• 在做有风险的事情之前，记下最后一个正常版本。
• 如果代码在 Git 中，就把正常工作的版本提交保存下来，以便随时回到它。

AI 搭建应用中的常见 bug 模式

当问题不是 bug 时

有些所谓的“bug”其实是 AI 严格按照指令构建了东西，而描述本身有歧义。如果你要的修复实际上是行为的改变，就直接说明：“改成……”。如果你发现自己也不确定正确的行为应该是什么，那就先把它想清楚。我们关于为 AI 应用搭建工具编写提示词的指南涵盖了如何清楚地描述规则。如果你正准备让真实用户使用应用，将 AI 原型投入生产涵盖了上线前值得做的检查。

在 Mythex 中调试

Mythex 为循环的每一步都提供了工具：

• 预览，用于复现 bug，包括手机尺寸的画框。
• /test 让智能体像用户一样点击你的实时预览，并报告出错的流程。
• /fix 让智能体专门针对出错的部分进行处理。
• 计划模式让智能体在编辑任何内容之前先调查并解释。
• 代码 → 终端显示你应用的服务器日志。
• 任意一条回复上的恢复到此处，会把项目回滚到该检查点。

如果发布失败，发布对话框通常会提供用 AI 修复，它会读取构建输出或应用日志。参阅文档中的调试你的应用和发布故障排查。

常见问题