文章目录一、问题现象点击一次却创建了两条订单二、第一步收集最小证据1. 看浏览器网络面板2. 看后端日志3. 保留相关代码不上传整个项目三、第二步把事实交给 AI 分析四、第三步检查最可能的问题点五、第四步做最小修复六、修复重复调用不等于解决所有重复订单风险七、让 AI 帮你补充验证场景八、这个案例中AI 真正帮了什么九、一份可复用的排查模板总结✍创作者全栈弄潮儿 个人主页全栈弄潮儿的个人主页️ 个人社区欢迎你的加入全栈开发社区 专栏地址AI 编程提效实战代码出现问题时很多人会直接把一句“为什么重复提交”发给 AI。这样得到的答案往往是一长串可能性缓存、网络重试、数据库重复写入、按钮连点、接口幂等……看起来都对但很难马上解决问题。真正高效的方式是先收集事实再让 AI 根据事实缩小排查范围。这篇文章用一个经过脱敏的典型案例带你走一遍完整过程。一、问题现象点击一次却创建了两条订单一个 Vue 3 订单创建页面出现了问题用户点击一次“提交订单”。页面显示提交成功。后台却创建了两条内容相同的订单。第一反应很容易是“数据库写重复了”。但这个阶段不能下结论因为重复数据可能发生在不同位置前端调用了两次接口。浏览器或网络层重试了请求。后端路由被执行两次。数据库写入逻辑重复执行。用户快速连续点击了按钮。先把问题拆开才能避免一开始就查错方向。二、第一步收集最小证据排查前先记录可以确认的事实。1. 看浏览器网络面板打开浏览器开发者工具的 Network 面板筛选创建订单接口POST /api/orders 201 10:12:08.421 POST /api/orders 201 10:12:08.435两次请求间隔只有 14 毫秒请求体也完全一致。这时可以确认一件事重复请求在浏览器发出请求之前或浏览器发出请求时就已经发生了。因此优先检查前端事件绑定和请求函数而不是先修改数据库。2. 看后端日志后端日志中也能看到两次请求POST /api/orders requestIdreq_demo_001 POST /api/orders requestIdreq_demo_002这说明后端确实分别收到了两次请求并不是同一次请求被日志重复打印。3. 保留相关代码不上传整个项目此时只需要收集表单模板。提交函数。请求函数。两条脱敏后的网络记录。运行环境和复现步骤。不需要把整个项目、数据库配置或真实订单数据交给 AI。三、第二步把事实交给 AI 分析不要这样问订单为什么会重复创建更有效的 Prompt 是请帮我分析一个 Vue 3 页面重复提交订单的问题。 已确认事实 1. 用户只点击了一次提交按钮。 2. 浏览器 Network 面板出现两次 POST /api/orders。 3. 两次请求体相同时间间隔约 14 毫秒。 4. 后端收到两个不同 requestId 的请求。 5. 没有看到 3xx 跳转或网络重试标记。 相关代码 [粘贴表单模板、提交函数和请求函数] 请输出 1. 最可能的 3 个原因按概率排序。 2. 每个原因对应的验证方法。 3. 下一步优先检查哪个位置为什么。 要求 - 不要直接修改代码。 - 不要把未确认的原因当成结论。 - 区分“已知事实”和“待验证假设”。这个 Prompt 的重点不是让 AI 立即给答案而是让它生成一份可验证的排查路线。四、第三步检查最可能的问题点相关模板代码如下form submit.preventsubmitOrder input v-modelform.productId / button typesubmit clicksubmitOrder提交订单/button /form提交函数asyncfunctionsubmitOrder(){awaitcreateOrder({productId:form.productId});}AI 的第一条假设通常会是button的click事件会调用一次submitOrder而typesubmit又会触发表单的submit事件再调用一次submitOrder。这不是最终结论但它可以立刻验证。在函数开头临时加入一条本地日志asyncfunctionsubmitOrder(){console.count(submitOrder called);awaitcreateOrder({productId:form.productId});}点击一次后控制台输出submitOrder called: 1 submitOrder called: 2至此我们拿到了完整证据链一次点击 ↓ click 事件调用 submitOrder ↓ submit 事件再次调用 submitOrder ↓ 浏览器发出两次 POST 请求 ↓ 后端创建两条订单注意console.count只用于本地定位问题修复后要删除不能带到正式环境。五、第四步做最小修复表单提交只保留一种触发方式即可。这里保留表单的submit事件删除按钮上的click事件form submit.preventsubmitOrder input v-modelform.productId / button typesubmit提交订单/button /form为什么推荐保留submit点击按钮可以提交。用户在输入框中按 Enter 也可以提交。表单行为集中在一个入口更容易维护。修改完成后再点击一次按钮并检查 Network 面板POST /api/orders 201 10:26:18.702只剩下一条请求问题得到修复。六、修复重复调用不等于解决所有重复订单风险前端事件冲突解决后仍然要考虑用户快速连续点击的情况。可以在请求期间禁用按钮button typesubmit :disabledsubmitting 提交订单 /buttonasyncfunctionsubmitOrder(){if(submitting.value){return;}submitting.valuetrue;try{awaitcreateOrder({productId:form.productId});}finally{submitting.valuefalse;}}这能减少重复点击但不能替代后端保护。对于订单、支付、扣库存等高风险接口后端还应该根据业务设计幂等机制例如使用客户端提交标识重复请求返回同一个结果。使用业务唯一键防止重复创建。在数据库层增加合适的唯一约束。具体方案取决于业务不能只复制一段通用代码。七、让 AI 帮你补充验证场景修复后可以继续让 AI 列出测试场景订单提交重复调用问题已经修复。 修复方式 - 删除按钮上的 click 提交逻辑。 - 只保留 form 的 submit 事件。 - 请求期间禁用提交按钮。 请列出需要手动验证和自动化测试的场景。 要求覆盖 1. 鼠标点击提交。 2. 在输入框按 Enter 提交。 3. 快速连续点击。 4. 请求成功。 5. 请求失败后再次提交。 6. 表单校验失败。 每个场景说明操作、预期请求次数、预期页面结果。我们至少要验证下面这些内容场景操作预期结果鼠标提交点击一次提交按钮只发起一次请求键盘提交在输入框按 Enter只发起一次请求连续点击请求未完成时连续点击只发起一次请求请求失败接口返回错误后再次提交按钮恢复可用可再次提交校验失败商品未选择就提交不发起创建订单请求八、这个案例中AI 真正帮了什么AI 没有替我们“猜中答案”它主要帮助完成了三件事根据已有事实列出排查假设。把“重复订单”拆成前端、网络、后端和数据库几个层次。提醒我们在修复事件冲突后继续考虑重复点击和接口幂等。真正定位问题的证据仍然来自Network 面板中的两次请求。后端的两个请求记录。console.count的两次函数调用。修复后只剩一次请求的验证结果。这也是使用 AI 排查问题的正确方式让 AI 帮你提出下一步而不是替代证据。九、一份可复用的排查模板以后遇到报错或异常行为可以先按下面格式整理再发给 AI问题现象 [用户看到了什么] 复现步骤 1. [步骤 1] 2. [步骤 2] 已确认事实 - [网络、日志、调用次数或返回数据] 运行环境 - [框架、版本、浏览器或服务信息] 相关代码 [最小相关代码] 已经尝试 - [已经做过的检查或修改] 请输出 1. 最可能原因按优先级排序。 2. 每个原因的验证方法。 3. 最小修复建议。 4. 修复后需要补充的测试。 要求先分析不要直接重写整个项目区分事实与假设。总结AI 能帮助我们更快定位问题但前提是先给它可靠的上下文。这个案例的排查顺序是发现重复数据 ↓ 查看 Network 和后端日志 ↓ 确认是两次独立请求 ↓ 让 AI 提供可验证假设 ↓ 用最小日志确认函数调用次数 ↓ 最小修改并再次验证 ↓ 补充防重复提交和幂等保护记住AI 给出的“可能原因”只是排查起点日志、请求记录、测试结果才是最终证据。下一篇文章将介绍《我的 AI 编程日常习惯如何真正提升效率》✍坚持原创求关注点赞收藏