从一次接口 Bug 排查出发，记录一套可验证的 AI 辅助流程

2601_95491659

16人浏览 · 2026-06-26 11:25:33

2601_95491659 · 2026-06-26 11:25:33 发布

最近团队里有个很典型的小问题：一个订单状态查询接口，在测试环境偶尔返回“已取消”，但数据库里查到的状态却是“待支付”。问题不大，却很烦，因为它不是稳定复现的异常。以前遇到这种情况，通常是翻日志、看代码、问上下游、补测试，一圈下来半天很容易过去。

这类场景其实很适合让 AI 参与，但前提是别把它当“自动修 Bug 的人”，而是当一个能帮你整理线索、提出假设、生成测试样例和 Review 代码的助手。国内开发者如果想低门槛对比 ChatGPT、Claude、Gemini、DeepSeek、Grok 这类模型，也可以选择统一的多模型调用环境，在同一个工作流里切换模型看差异，不必一开始就纠结“哪个模型一定最好”。

本文不讨论玄学提示词，也不写排行榜，只记录一套我觉得在 CSDN 读者里比较实用的流程：用 AI 辅助排查 Bug、生成测试用例、整理技术文档，并说明哪些结果可以采纳，哪些必须人工验证。

一、先说结论：AI 更适合做“中间环节”

在研发工作里，AI 并不是最适合直接做最终决策。它更适合参与这些中间环节：

从日志和代码片段中提取异常线索；
根据业务规则列出可能原因；
帮忙补充边界测试用例；
对代码改动做第一轮 Review；
把排查过程整理成技术文档；
对比不同实现方案的风险点。

但下面这些事情不建议直接交给 AI：

直接把公司完整源码、生产日志、用户数据发给模型；
不经测试就上线 AI 生成的代码；
让 AI 判断线上事故最终原因；
让 AI 替代安全评审、性能压测和代码审查；
对涉及权限、支付、订单、风控的逻辑只做文本层面的确认。

一句话：AI 可以帮你少走弯路，但不能替你承担工程责任。

二、场景设定：订单状态偶发错误

假设有一个 Java 后端接口：

java

@GetMapping("/orders/{orderId}/status")public OrderStatusVO getOrderStatus(@PathVariable Long orderId) {    Order order = orderService.getById(orderId);    Payment payment = paymentService.getLatestPayment(orderId);
    if (payment != null && payment.getStatus() == PaymentStatus.CANCELLED) {        return new OrderStatusVO(orderId, "CANCELLED");    }
    return new OrderStatusVO(orderId, order.getStatus().name());}

测试同事反馈：

查询订单状态时，少量订单实际状态是 WAIT_PAY，但接口返回 CANCELLED。

相关日志片段如下，已经做过脱敏：

text

2026-06-18 10:21:12 INFO orderId=10001 orderStatus=WAIT_PAY2026-06-18 10:21:12 INFO orderId=10001 latestPaymentStatus=CANCELLED2026-06-18 10:21:12 INFO responseStatus=CANCELLED

这里的代码看上去没报错，但业务逻辑很可能有问题：订单状态不一定应该被最近一笔支付记录覆盖。

这个时候，我一般不会直接问 AI：“帮我修复这个 Bug。”
这种问法太宽泛，模型很容易给一段看似合理、实际脱离业务的代码。

更好的做法是把任务拆开。

三、第一步：让 AI 先做问题假设，而不是直接改代码

可以先给模型一个约束清楚的 Prompt。

Prompt 示例 1：Bug 初步分析

text

你是 Java 后端代码 Review 助手。下面是一段订单状态查询代码和脱敏日志。
请你只做三件事：1. 根据代码和日志列出可能导致接口返回 CANCELLED 的原因；2. 区分“代码逻辑问题”“数据问题”“并发/时序问题”；3. 不要直接给最终修复代码，先给排查清单。
业务背景：- 订单状态 WAIT_PAY 表示待支付；- 支付记录 CANCELLED 表示某次支付尝试已取消；- 一个订单可能有多次支付尝试；- 接口目标是返回订单当前状态，而不是支付记录状态。
代码：{粘贴脱敏后的代码}
日志：{粘贴脱敏后的日志}

比较稳定的 AI 输出通常会指出：

getLatestPayment(orderId) 取到的是最近一笔支付记录，但最近一笔支付取消，不代表订单取消；
支付状态和订单状态可能属于不同聚合，不应该直接覆盖；
如果一个订单有多次支付尝试，需要明确“订单状态”和“支付状态”的映射规则；
需要检查订单状态更新链路，而不是只看查询接口；
需要确认是否存在异步回调延迟、消息乱序或缓存未刷新问题。

这一步的价值不在于“AI 找到了真相”，而是它能帮你把排查方向列全一点。尤其是新人排查问题时，很容易只盯着某一行代码。

四、不同模型在这个任务里的差异

同一个问题，我通常会用两个或三个模型交叉看一下，尤其是涉及业务逻辑时。

模型	更适合的环节	可能的不足
ChatGPT	问题拆解、代码草稿、测试思路、Prompt 迭代	有时会给出过度完整但未必贴合业务的实现
Claude	长上下文需求理解、复杂业务规则整理、文档重写	对代码细节的判断仍需人工验证
Gemini	资料整理、多文件摘要、结构化信息提取	中文业务语义下偶尔需要补充上下文
DeepSeek	中文技术问答、代码解释、推理型排查	需要注意是否编造不存在的 API 或框架能力
Grok	多观点讨论、开放式假设、热点技术理解	工程落地时要收敛，不宜只看发散结论
Seedance 2.0	技术科普视频、产品演示、短视频分镜	不适合直接参与代码逻辑判断
ChatGPT Image 2.0	技术配图、架构图草稿、运营配图	生成图像需做版权、品牌和准确性审核

如果任务是 Bug 排查，我会优先选择 ChatGPT、Claude、DeepSeek 这类文本和代码能力较强的模型。
如果后续要把排查过程做成技术分享、培训材料或公众号配图，再考虑用图像/视频模型生成视觉素材。

五、第二步：让 AI 帮忙生成测试用例，但不要照单全收

在确认问题可能出在“支付状态覆盖订单状态”后，可以让 AI 根据业务规则生成测试用例。

Prompt 示例 2：生成测试用例

text

请基于以下业务规则，为订单状态查询接口生成测试用例。
业务规则：1. 接口返回订单当前状态；2. 支付记录状态不能直接覆盖订单状态；3. 一个订单可能有多次支付记录；4. 最近一次支付取消，不代表订单取消；5. 只有订单表状态为 CANCELLED 时，接口才应返回 CANCELLED。
请输出：- 用例名称；- 前置数据；- 请求参数；- 预期返回；- 需要额外验证的数据库字段。
要求：- 使用 Markdown 表格；- 覆盖正常、边界、异常数据；- 不要生成无关场景。

AI 可能会生成类似这样的用例：

用例	订单状态	最近支付状态	预期接口返回
待支付订单，无支付记录	WAIT_PAY	null	WAIT_PAY
待支付订单，最近支付取消	WAIT_PAY	CANCELLED	WAIT_PAY
已取消订单，支付记录为空	CANCELLED	null	CANCELLED
已取消订单，最近支付成功	CANCELLED	SUCCESS	CANCELLED
已支付订单，存在取消支付记录	PAID	CANCELLED	PAID

这类输出可以作为测试设计草稿，但还需要人工补充几个问题：

订单状态是否允许从 PAID 回退到 CANCELLED？
支付记录是否有逻辑删除？
getLatestPayment 的排序依据是创建时间、更新时间还是支付流水时间？
是否存在缓存层？
是否有异步消息更新订单状态？

AI 不知道你的系统真实约束，测试工程师和开发必须把业务规则补进去。

六、第三步：生成修复方案前，先让 AI 写“改动风险”

很多人用 AI 写代码时会跳过风险分析，直接让它生成新代码。这样做效率看似高，实际上容易把 Bug 从一个地方搬到另一个地方。

我更建议先问：

text

基于上面的业务规则，如果要修复该接口，请先不要写代码。
请输出：1. 可能的修复方案；2. 每个方案的优缺点；3. 对历史数据、缓存、异步消息、接口兼容性的影响；4. 需要补充的单元测试和集成测试。

比较合理的方案可能有两类。

方案 A：接口只返回订单表状态

java

public OrderStatusVO getOrderStatus(Long orderId) {    Order order = orderService.getById(orderId);    if (order == null) {        throw new BizException("ORDER_NOT_FOUND");    }    return new OrderStatusVO(orderId, order.getStatus().name());}

优点是逻辑清晰，符合“订单状态以订单聚合为准”的原则。
风险是如果历史上接口调用方已经依赖了支付状态覆盖逻辑，需要确认兼容性。

方案 B：返回订单状态，同时附带支付状态

java

public OrderStatusVO getOrderStatus(Long orderId) {    Order order = orderService.getById(orderId);    Payment payment = paymentService.getLatestPayment(orderId);
    return new OrderStatusVO(        orderId,        order.getStatus().name(),        payment == null ? null : payment.getStatus().name()    );}

这个方案更适合前端确实需要展示支付尝试状态的场景。
但它涉及接口字段变化，需要考虑版本兼容。

七、一个简单的验证流程

技术社区里讨论 AI 辅助开发，最容易忽略的是验证。下面这个流程比较朴素，但很实用。

text

输入脱敏信息    ↓AI 生成问题假设    ↓人工筛选可验证假设    ↓AI 辅助生成测试用例    ↓开发补充业务边界    ↓本地单元测试 / 集成测试    ↓Code Review    ↓测试环境回归    ↓灰度或小流量验证

也可以写成伪代码：

pseudo

context = collect(masked_code, masked_log, business_rules)
hypotheses = AI.analyze(context)valid_hypotheses = developer.filter(hypotheses)
test_cases = AI.generate_tests(valid_hypotheses, business_rules)test_cases = tester.review_and_extend(test_cases)
patch = developer.implement_fix()
run_unit_tests(patch)run_integration_tests(patch)review_code(patch)
if all_checks_pass:    deploy_to_test_env()else:    rollback_patch()

这里有个关键点：AI 生成的是候选项，不是结论。