用户说登录后偶尔回到登录页，你在本地试了多次，却始终正常。此时，与编程智能体结对，不是让它猜一个原因并提交修改，而是一起缩小未知范围。你负责提供现场信息、决定操作边界；智能体负责阅读代码、整理线索、提出实验。第一轮的目标不是宣布修好，而是找到下一条值得验证的线索。
第一步：把“偶尔出错”整理成故障卡片
先别让智能体扫描整个项目。给它一张简短的故障卡片，写清预期行为、实际行为、发生时间和受影响范围。以登录回跳为例，还应记录浏览器类型、应用版本、是否开启多个标签页，以及问题发生前做过什么。
- 已知事实：用户完成登录后，页面再次显示登录入口。
- 尚不确定：登录状态是否成功保存，后续请求是否携带凭据。
- 缺失证据：相关请求的关联编号、状态变化顺序和服务端处理结果。
把事实与猜测分开，能避免智能体把一句“可能是缓存”当成已经确认的原因。分享日志前，删除口令、令牌、个人信息和其他敏感内容。
第二步：先约定只读排查边界
给智能体一段明确指令：“先不要修改代码。请阅读登录入口、登录状态保存和页面跳转相关代码，列出三条以内的原因假设。每条说明依据、缺少的证据，以及最小验证方法。”
同时要求它标注查看过的文件与函数。没有看到的配置，不能默认存在；没有执行的测试，不能写成通过。涉及生产环境、依赖升级或数据修改的操作，必须先征得你的确认。
第三步：把每个猜测改写成可推翻的实验
假设智能体怀疑页面跳转早于登录状态保存完成，就追问：“看到什么结果，才能说明这个判断不成立？”可验证的答案应指向具体事件顺序，而不是“再多试几次”。
接下来只改变一个条件，例如人为延迟登录状态保存，观察跳转是否提前发生。再分别检查多标签页、旧版本页面和凭据过期等条件。一次混入多个变化，即使故障出现，也很难判断是哪一个变化触发的。
第四步：仍然复现不了，就补最小观测
本地实验没有结果，不等于用户反馈有误。可以请智能体设计一份小范围的日志补丁：用同一个关联编号串起登录响应、状态保存、页面跳转和首次鉴权请求，只记录必要的结果与顺序。
不要记录完整凭据，也不要为了排查长期保留大量用户数据。上线前检查日志内容、采样范围、访问权限与移除条件。用于排查的开关应当能够关闭；观测补丁与业务修复最好分开提交，方便审查和撤回。
第五步：让修复对应一条失败测试
拿到证据后，再让智能体构造最小测试。如果确认是保存尚未完成就发生跳转，测试应控制保存过程的完成时机，验证页面不会提前进入下一步，而不是依赖碰巧合适的等待时间。
先确认测试能在旧代码上暴露问题，再验证修改后的代码能够通过，并运行相邻流程的测试。若测试只证明了某种可能机制，尚未对应真实现场，就把修改标为待验证，不要把合理推测包装成已确认修复。
第六步：保留排查记录，再交给下一轮
结束前，让智能体整理四项内容：确认了什么、排除了什么、改动了什么、还缺什么。附上测试结果与撤回办法。即使这一轮没有找到根因，下一位接手者也不必重新走一遍弯路。
如果你需要为现有编程工具接入模型，推荐使用本站的按量中转服务，并注册账号领取新账户赠送的小额额度，先在脱敏的小项目中练习这套流程。工具负责协助阅读和实验，你仍负责证据、权限与最终判断。