你真实的系统大概率对不上。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/jsonAuthorization: Bearer请求体 {“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”}}复制代码第四步把抓到的信息 对功能的简单描述一起给 AI复制代码Agent 模式我抓到了一个创建订单的接口信息如下接口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.pyclass 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 201data response.json()[“data”]assert “order_id” in dataassert data[“status”] “pending”复制代码现在你想写查询订单详情的测试用例你只需要告诉 AI帮我编写一个查询订单的测试用例。 它的测试步骤创建订单获取订单ID查询订单 检验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 里早期写的字段名不一样api_client.post(“/api/v2/orders”, json{“productId”: “p1”, “qty”: 1, …})测试文件 C 里用了另一套封装order_service.create(product“p1”, count1)复制代码AI 做语义检索时可能找到旧的、不规范的写法导致生成的代码风格不一致甚至用了已经废弃的字段名。问题二检索噪音增大100 个文件里有大量相似的接口调用代码AI 在检索时需要处理大量干扰项可能反而找不到最相关的参考生成质量下降。解决方案API 层 Service 层工程化的解法是将代码分成三层复制代码tests/ ← 测试用例层只关心测试逻辑└── order/└── test_create_order.pyservices/ ← 业务逻辑层封装多个接口的串联调用└── order_service.pyapi/ ← 接口调用层每个接口对应一个函数一处定义└── order_api.py复制代码api/order_api.py接口调用层每个接口只在这里定义一次是整个工程的接口字典复制代码api/order_api.py“”订单模块接口定义所有订单相关接口的调用都从这里发出禁止在测试文件中直接拼接接口路径。“”from utils.http_client import APIClientdef create_order(client: APIClient, product_id: str, quantity: int,address_id: str, coupon_code: str None, remark: str None):“”“创建订单”“”payload {“product_id”: product_id,“quantity”: quantity,“address_id”: address_id,}if coupon_code:payload[“coupon_code”] coupon_codeif remark:payload[“remark”] remarkreturn client.post(“/api/v2/orders”, jsonpayload)def get_order(client: APIClient, order_id: str):“”“查询订单详情”“”return client.get(f/api/v2/orders/{order_id})def list_orders(client: APIClient, page: int 1, page_size: int 20, status: str None):“”“查询订单列表”“”params {“page”: page, “page_size”: page_size}if status:params[“status”] statusreturn client.get(“/api/v2/orders”, paramsparams)def cancel_order(client: APIClient, order_id: str, reason: str):“”“取消订单”“”return client.post(f/api/v2/orders/{order_id}/cancel, json{“reason”: reason})复制代码services/order_service.py业务逻辑层把需要多个接口串联的常见业务流程封装成公共方法复制代码services/order_service.py“”订单业务逻辑层封装常用的多步骤业务流程供测试用例直接调用。“”from api.order_api import create_order, get_order, cancel_orderfrom utils.http_client import APIClientdef create_and_get_order(client: APIClient, product_id: str, quantity: int,address_id: str) - dict:“”创建订单并立即查询返回完整订单信息。适用于需要验证创建后状态的测试场景。“”create_resp create_order(client, product_id, quantity, address_id)assert create_resp.status_code 201, f创建订单失败: {create_resp.text}order_id create_resp.json()[“data”][“order_id”]get_resp get_order(client, order_id) assert get_resp.status_code 200 return get_resp.json()[data]def create_pending_order(client: APIClient) - str:“”使用默认参数快速创建一个待支付订单返回 order_id。适用于其他测试如支付测试、取消测试的前置条件。“”resp create_order(client,product_id“prod_test_001”,quantity1,address_id“addr_test_001”)assert resp.status_code 201return resp.json()[“data”][“order_id”]复制代码测试文件如何使用这两层复制代码tests/order/test_create_order.pyfrom api.order_api import create_orderfrom services.order_service import create_and_get_orderclass TestCreateOrder:def test_create_order_success(self, api_client):“”“正常创建订单”“”order create_and_get_order(api_client, “prod_001”, 2, “addr_123”)assert order[“status”] “pending”assert order[“total_amount”] 0def test_create_order_missing_product_id(self, api_client): 缺少必填字段 product_id resp create_order(api_client, product_id, quantity1, address_idaddr_123) assert resp.status_code 400 assert resp.json()[message] product_id 不能为空复制代码分层架构对 AI 的好处有了 API 层 Service 层之后AI 做语义检索的效果会大幅提升没有分层 有分层AI 在 100 个测试文件里搜索如何调用创建订单接口 AI 直接检索到 api/order_api.py一处即知找到多种写法不知道用哪个 接口层唯一写法统一多步骤流程散落在各个测试文件里 Service 层集中封装直接复用新测试参考旧测试风格越来越乱 新测试参考 API 层和 Service 层风格一致升级后的工程目录结构复制代码api-autotest/├── api/ ← 接口调用层每个接口定义一次│ ├── order_api.py│ ├── user_api.py│ └── product_api.py├── services/ ← 业务逻辑层多接口串联的公共流程│ ├── order_service.py│ └── user_service.py├── tests/ ← 测试用例层只关心测试逻辑│ ├── order/│ ├── user/│ └── product/├── utils/├── fixtures/├── config/├── conftest.py└── pytest.ini复制代码Rules 文件让 AI 遵守你的工程规范为什么需要 Rules 文件有了分层架构之后还有一个问题AI 不知道你定了这些规范。下次你让 AI 写测试用例时它可能还是会在测试文件里直接写 api_client.post(“/api/v2/orders”, …)而不是调用你封装好的 create_order() 函数。解决方法是使用 Cursor Rules 文件——这是 Cursor 的一个核心功能让你可以把工程规范直接写给 AI 看让它在每次生成代码时都遵守这些规则。Rules 文件是什么Rules 文件本质上是附加在每次 AI 对话中的系统提示词System Prompt。你在 Rules 文件里写的内容会在每次 AI 生成代码前被自动注入让 AI 理解你的项目规范。Cursor 支持两种 Rules类型 存放位置 作用范围Project Rules .cursor/rules/*.mdc 只对当前项目生效User Rules Cursor Settings → Rules 对所有项目全局生效推荐方案工程规范放 Project Rules个人偏好比如回复用中文放 User Rules。如何创建 Rules 文件方法一通过 Cursor 界面创建推荐新手打开 Cursor进入你的项目按 CmdShiftPmacOS/ CtrlShiftPWindows打开命令面板输入 New Cursor Rule回车输入规则名称比如 api-test-rules回车Cursor 会自动在 .cursor/rules/ 目录下创建 api-test-rules.mdc 文件方法二手动创建mkdir -p .cursor/rulestouch .cursor/rules/api-test-rules.mdc然后用 Cursor 打开这个文件开始编写规则内容。4.4 Rules 文件的格式.mdc 文件支持 Markdown 格式开头有一段 YAML Front Matter 用于配置规则的触发时机复制代码description: 接口自动化工程编码规范globs: # 匹配哪些文件时触发此规则“tests/**/*.py”“api/**/*.py”“services/**/*.py”alwaysApply: false # 是否对所有文件始终生效复制代码globs的作用当 AI 正在操作匹配这些路径的文件时自动附加此规则。比如你正在写测试文件Rules 会自动生效不需要你手动提醒 AI。alwaysApply: true如果你希望所有操作都遵守这条规则比如始终用中文回复可以设置为 true。4.5 为接口测试工程编写 Rules 文件下面是一个完整的示例可以直接用于你的接口测试工程复制代码description: 接口自动化工程编码规范globs:“tests/**/*.py”“api/**/*.py”“services/**/*.py”alwaysApply: false接口自动化工程编码规范工程结构本工程采用三层架构职责如下api/接口调用层每个接口有且只有一处定义命名规范为{模块名}_api.pyservices/业务逻辑层封装需要多接口串联的公共业务流程tests/测试用例层只关注测试逻辑不直接拼接接口路径编写测试用例的强制规范1. 禁止在测试文件中直接调用 HTTP 客户端错误示范禁止def test_create_order(api_client):api_client.post(“/api/v2/orders”, json{…}) # ❌ 禁止正确示范from api.order_api import create_orderfrom services.order_service import create_pending_orderdef test_create_order(api_client):resp create_order(api_client, …) # ✅ 使用 api 层2. 优先使用 Service 层的公共方法当一个操作需要多步接口调用时优先检查services/目录下是否已有封装好的方法。例如需要创建订单后查询时使用order_service.create_and_get_order()而不是手动写两次接口调用。3. 新增接口时必须先在 api 层定义如果需要调用一个api/目录下还没有的接口必须先在对应的{模块}_api.py文件中定义该接口函数然后再在测试文件中引用。4. 测试用例命名规范文件名test_{被测功能}.py如test_create_order.py类名Test{功能名驼峰}如TestCreateOrder方法名test_{场景描述}如test_create_order_missing_product_id5. 断言规范必须断言 HTTP 状态码必须断言响应体中的核心业务字段错误场景必须断言错误信息的具体内容message字段语言规范所有代码注释使用中文docstring 必须说明函数功能、适用测试场景复制代码4.6 Rules 文件生效后的效果有了这个 Rules 文件当你告诉 AI帮我写一个支付订单的测试用例接口是 POST /api/v2/orders/{order_id}/pay需要先有一个待支付的订单AI 会自动检查 api/order_api.py 是否已有 pay_order() 函数没有的话先补充检查 services/order_service.py 是否有 create_pending_order() 可复用有的话直接用生成符合命名规范的测试类和方法名断言状态码 业务字段复制代码AI 按照 Rules 规范自动生成1. 先补充 api 层如果没有api/order_api.pydef pay_order(client: APIClient, order_id: str, payment_method: str):“”“支付订单”“”return client.post(f/api/v2/orders/{order_id}/pay,json{“payment_method”: payment_method})2. 测试用例复用了 Service 层的 create_pending_ordertests/order/test_pay_order.pyfrom api.order_api import pay_orderfrom services.order_service import create_pending_orderclass TestPayOrder:def test_pay_order_success(self, api_client):“”“正常支付使用微信支付成功场景”“”order_id create_pending_order(api_client) # 复用 Service 层resp pay_order(api_client, order_id, “wechat”)assert resp.status_code 200assert resp.json()[“data”][“status”] “paid”def test_pay_order_already_paid(self, api_client): 异常重复支付已完成的订单 order_id create_pending_order(api_client) pay_order(api_client, order_id, wechat) # 第一次支付 resp pay_order(api_client, order_id, wechat) # 第二次支付 assert resp.status_code 409 assert resp.json()[message] 订单已支付复制代码完全符合你定义的规范不需要你再手动检查和纠正。4.7 Rules 文件的进阶技巧技巧一为不同目录创建不同 Rules.cursor/rules/ 目录下可以有多个 .mdc 文件每个针对不同场景.cursor/rules/├── api-test-rules.mdc # 接口测试规范作用于 tests/ api/ services/├── api-layer-rules.mdc # API 层开发规范作用于 api/└── general-rules.mdc # 通用规范alwaysApply: true技巧二在 Rules 中引用文件可以在 Rules 中指定参考这个文件的风格代码风格参考当生成新的接口函数时参考api/order_api.py的代码风格。当生成新的测试类时参考tests/order/test_create_order.py的结构。技巧三把常见错误场景也写进 Rules常见错误与修正不要使用 time.sleep()如需等待使用 pytest 的poll机制或重试装饰器不要硬编码 token必须从环境变量读取不要在测试中创建真实的外部资源如发短信、发邮件使用 mock完整实践流程总结把本篇所有内容串起来形成一套完整的工作流复制代码┌─────────────────────────────────┐│ Step 1喂知识给 AI ││ API 文档 OR F12 抓包 功能描述 │└──────────────┬──────────────────┘│┌──────────────▼──────────────────┐│ Step 2写第一个测试用例 ││ AI 生成 → 你校正 → 确认无误 │└──────────────┬──────────────────┘│┌──────────────▼──────────────────┐│ Step 3利用语义检索扩展 ││ 存量代码成为参考增量知识即可 │└──────────────┬──────────────────┘│ 代码多了语义噪音↑┌──────────────▼──────────────────┐│ Step 4抽象 API 层 Service 层 ││ 接口一处定义公共流程集中封装 │└──────────────┬──────────────────┘│┌──────────────▼──────────────────┐│ Step 5编写 Rules 文件 ││ 把工程规范写给 AI 看强制遵守 │└──────────────┬──────────────────┘│┌──────────────▼──────────────────┐│ 持续扩展只需录入增量知识 ││ 新接口 → 定义到 api 层 → 写测试 │└─────────────────────────────────┘复制代码阶段 你做什么 AI 做什么喂知识 提供接口信息或抓包数据 理解接口推断边界场景写第一个用例 审查并纠正 AI 的推断 生成完整测试代码扩展阶段 只说帮我写 XXX 的测试 语义检索参考存量代码自主生成工程治理 维护 api 层、service 层、rules 文件 严格遵守规范风格统一小结基本上掌握了今天讲的内容 基本上用于生成自动化测试用例领域的 AI 已经可以满足大部分需求。 事实上AI 生成测试用