大模型并不认识你的系统很多人第一次使用 Cursor 生成接口测试时会困惑 大模型怎么知道我的系统的接口张什么样子如果我们强行让它写它绝对会写出一个假的的测试用例。这是因为大模型没有你系统的任何知识。它只能根据通用经验猜出一个看起来合理的接口但猜的结果和你真实的系统大概率对不上。AI 要生成准确的测试代码前提是你必须先把接口知识喂给它。知识的最佳来源API 文档如果你的团队有完善的 API 文档Swagger、Postman Collection、API Blueprint 等直接把相关接口文档丢给 AI 就可以了。在 Cursor 中你就可以Agent 模式 docs/api/order-api.md ← 引用文档文件 根据以上接口文档帮我编写创建订单接口的完整测试用例 包含正常创建、缺少必填字段、金额为负数三个场景。AI 拿到文档后可以准确理解接口的路径、方法、入参、返回值生成的代码会非常准确。没有文档怎么办用 F12 抓包现实情况是很多团队的 API 文档严重滞后于代码甚至根本没有文档。这时候最直接的办法是用浏览器开发者工具F12抓包。PS 我就是这么干的。操作步骤第一步打开浏览器进入你要测试的功能页面按F12打开开发者工具切换到 Network 标签页。第二步执行你要测试的操作比如点击创建订单按钮观察 Network 面板捕获到的请求。第三步找到目标请求右键 → Copy → Copy as cURL或者手动记录以下信息接口路径 POST /api/v2/orders 请求头 Content-Type: application/json Authorization: Bearer token 请求体 { product_id: prod_001, quantity: 2, address_id: addr_123, coupon_code: SAVE10, remark: 请尽快发货 } 响应状态码 201 响应体 { code: 0, message: success, data: { order_id: ord_20260613_001, status: pending, total_amount: 198.00, created_at: 2026-06-13T14:00:00Z } }第四步把抓到的信息 对功能的简单描述一起给 AIAgent 模式 我抓到了一个创建订单的接口信息如下 接口POST /api/v2/orders 请求体 { product_id: prod_001, quantity: 2, address_id: addr_123, coupon_code: SAVE10, remark: 请尽快发货 } 响应成功 { code: 0, data: { order_id: ord_20260613_001, status: pending, total_amount: 198.00 } } 功能说明用户选好商品后提交订单。product_id 和 quantity 是必填的 address_id 是收货地址coupon_code 是优惠券可选remark 是备注可选。 请根据以上信息帮我编写完整的接口测试用例。AI 会推理你没说清楚的部分你会发现上面的描述并没有告诉 AI 每个字段的所有细节比如 quantity 的取值范围、product_id 的格式约束。但这没关系——大模型会根据你描述的业务功能自主推理出合理的测试边界。比如 AI 会自动推断quantity可能有最小值不能为 0 或负数coupon_code是可选字段需要测试不传的情况product_id不存在时应该报错库存不足时应该有对应的错误响应AI 生成的测试用例可能包含你没想到的边界场景这正是它的价值所在。当 AI 推理错了怎么办直接纠正它你刚才假设 quantity 最大值是 99实际上我们的系统限制是 999 而且当超过库存数量时才会报错不是超过 999 就报错。请修正。AI 会立刻根据你的纠正更新测试用例并自动调整相关的边界测试场景。这个过程类似于代码审查——AI 写草稿你来校正效率远高于从零手写。 当然也可以从一开始就把完整的测试用例给 AI 这样就不用 AI 自己瞎猜了 事实上我们项目中基本都是这样的。 但如果我们刚刚开始接受项目 还没有完善的测试用例的时候 也可以让 AI 自己去探索 然后我们来纠正的这样一个模式。那么接下来问题就来了 以后我们每写一个自动化测试用例都需要这么麻烦的去抓每个接口的包么 事实上我们之前抓过的接口是不用重新给大模型的这就涉及到 AI 编程最重要的一个部分了 就是语义检索。语义检索存量代码就是最好的参考Cursor 的代码库索引机制当你在 Cursor 中打开一个项目Cursor 会在后台自动对整个代码库做 Embedding向量化并存入向量数据库。这意味着你写的每一行代码Cursor 都读过了当你提出新的需求时AI 会通过语义检索找到项目中最相关的代码作为参考它不是简单的关键词匹配而是理解代码的语义含义你可以在 Cursor 右下角看到索引进度Indexing codebase... (234/312 files)索引完成后所有文件都可以被语义检索到。PS版本不同这段信息的位置可能会有所不同。存量代码如何成为活文档让我们看一个具体的例子。假设你按照第之前教程的方法已经写好了第一个测试用例# tests/order/test_create_order.py class TestCreateOrder: def test_create_order_success(self, api_client): response api_client.post(/api/v2/orders, json{ product_id: prod_001, quantity: 2, address_id: addr_123 }) assert response.status_code 201 data response.json()[data] assert order_id in data assert data[status] pending现在你想写查询订单详情的测试用例你只需要告诉 AI帮我编写一个查询订单的测试用例。 它的测试步骤 1. 创建订单获取订单ID 2. 查询订单 检验XXXXXX。 PS: 如果查询订单之前没有写过相关用例 这里也需要去抓查询订单的接口的包。此时 AI 不需要你重新解释创建订单的接口大模型通过语义检索已经找到了test_create_order.py直接参考现有风格生成新用例# AI 自动生成风格与现有代码完全一致 class TestGetOrder: def test_get_order_success(self, api_client): # 先创建一个订单再查询它 create_resp api_client.post(/api/v2/orders, json{ product_id: prod_001, quantity: 2, address_id: addr_123 }) order_id create_resp.json()[data][order_id] response api_client.get(f/api/v2/orders/{order_id}) assert response.status_code 200 data response.json()[data] assert data[order_id] order_id assert data[status] pending assert items in data关键点甚至你可以只说查询订单详情AI 自己知道要先创建订单再查询因为它从已有代码中理解了这个业务流程。当然这样的形式实在过于代码冗余了我们需要更灵活的接口以及让我们的知识更加的简单。 毕竟以后代码库里的 case 越来越多 大模型的语义检索能力也会收到干扰并且我们的测试用例也得分层不能把所有东西都写在用例里 需要把 API业务逻辑等等单独分层。 那怎么办呢 看下面的内容。增量知识积累这就是语义检索带来的核心价值项目里的代码越多AI 能参考的知识越多生成的代码质量越高。第1个接口测试 → AI 需要你提供完整接口信息 第5个接口测试 → AI 已经理解了你的项目结构和风格 第20个接口测试 → AI 直接参考存量代码你只需说仿照 XXX 写一个 YYY 第50个接口测试 → AI 几乎不需要额外解释自主完成实践建议每次引入一个新模块时先手动写或精心指导 AI 写一个示范性测试用例这个示范用例会成为该模块所有后续测试的参考基准后续只需要增量录入新的业务知识新字段、新规则存量的调用方式 AI 自己会找当代码多起来Service 层抽象语义检索也会迷路随着项目发展测试代码会越来越多。假设你已经有了 100 个测试文件每个文件里都有调用各种接口的代码。这时候会出现两个问题问题一同一功能有多种实现方式# 测试文件 A 里创建订单的方式 api_client.post(/api/v2/orders, json{product_id: p1, quantity: 1, ...}) # 测试文件 B 里早期写的字段名不一样