AI 一直改不对怎么办？
先理解原理和示例，再练习完整口述与追问。
回答要点
先复现和缩小问题，检查接口响应、控制台、网络及调用链，提出可验证的假设。把具体错误、预期与实际差异补给 AI，逐步验证。必要时自己定位根因，避免让它无依据地反复重写。
原理拆解
反复修不对通常需要重新建立问题模型。先停止叠加补丁，确认可复现步骤、预期、实际输出和最小相关代码，再检查模型假设与真实系统哪里不一致。把复杂问题拆成能单独验证的假设，逐个排除，而不是不断让模型“再想想”。
示例与推演
例如 watcher 不触发：确认字段是否在 data 初始化、修改的是不是同一引用、是否使用 Vue2 数组下标直接写入、模板是否读取当前字段，再看组件是否被缓存。每次只改变一个原因，并用相同操作复现。若新的方案引入无关重构，先回到最小差异重新定位。
易错点
不要静默吞掉异常、删测试或增加延时来制造通过。模型不确定时应给证据缺口，不能用更长解释替代验证。
参考回答可直接练习口述
我先停止无依据的连续修改，复现问题并收集明确证据：请求参数和响应、控制台堆栈、状态变化、触发顺序。然后提出一个可检验假设，让 AI 只围绕相关调用链分析或做小改动，每次修改后验证。如果证据表明需求理解错了，先重新澄清；上下文不足就补正确接口和相关代码；实现错了则用最小复现定位。AI 帮我分析，不替代对根因负责。
面试官可能继续问追问与完整解答展开收起
追问
你怎么知道是业务理解错误、上下文不足，还是代码实现错误？
追问回答
业务理解错误通常表现为实现与明确需求矛盾；上下文不足表现为缺接口、遗漏调用方或假设版本；实现错误则是在契约已清楚时仍出现可复现的逻辑缺陷。先把预期、实际与证据对应起来，再补材料或修代码；不能仅靠模型自己的归因下结论。