AI网页调试如何描述问题?

把“页面有问题”交给 AI，通常只能得到一轮猜测式修改。网页调试的关键不是描述现象，而是把问题转化为可复现、可验证、可限制的任务：在哪种视口或操作条件下出现，用户原本期待什么，实际发生了什么，以及问题影响了哪些区域。信息越接近故障边界，AI越容易定位原因，也越不容易为了修复局部问题而重写整页代码。

一条合格的问题描述应包含什么

首先写清复现步骤。不要只说“移动端错位”，而应说明打开页面后执行了什么操作、在哪种屏幕状态下出现异常，以及问题是否能稳定重现。其次区分预期结果和实际结果，例如“预期导航收起并保持单列，实际按钮换行且标题与内容重叠”。最后补充影响范围：桌面端是否正常、问题只影响导航还是整个首屏、是否与连续点击或切换窗口尺寸有关。

描述时还应明确调试边界。需要告诉 AI 哪些结构、类名或桌面布局不能改动，并要求优先分析现有规则，再进行最小范围修改。这样可以避免“修复按钮却破坏卡片样式”的连锁变化。

用状态描述交互故障

交互问题不能只描述视觉结果，还要说明状态变化。以移动端菜单为例，需要交代菜单初始是关闭还是展开，点击后哪些区域变化，再次点击是否关闭，点击导航项后是否恢复初始状态，以及快速连续操作时是否出现残留。对于折叠面板、弹窗和表单反馈，同样应说明触发条件、结束状态和异常路径。

一个更有效的调试请求，通常包含四层信息：

• 复现条件：操作顺序、视口状态和出现位置。
• 实际与预期：当前行为和目标行为分别是什么。
• 约束范围：允许修改哪些区域，哪些代码必须保留。
• 交付方式：先解释可能原因，再给出最小修改，并说明改动位置。

让调试结果可验证

AI提出修改后，不要立即接受整份重写代码。先检查它是否解释了宽度、溢出、定位、层叠或事件绑定等具体原因，再在原场景中重新复现。一次只验证一个问题，并保留修改前后的版本。

高质量的调试描述，本质上是在建立共同上下文：让 AI 知道问题如何发生、什么结果才算修好，以及不能为了局部修复牺牲什么。描述越具体，生成速度带来的返工成本就越低。