拓冰网站定制 
1. 接口测试新手为什么总在“造数据”上卡住刚接触接口自动化测试时最容易陷入的误区是以为让 AI 写测试代码就是打开 Cursor 敲一句“帮我写个创建订单的接口测试”然后坐等可运行的代码。我试过结果 AI 给出的接口路径、字段名、状态码全是它根据通用经验“猜”出来的和真实系统大概率对不上。这不是 AI 不行而是它手里没有你系统的接口知识。接口测试的本质是“用代码模拟客户端发请求再校验服务端响应”。要让 AI 生成能跑的自动化测试代码前提是你先把接口知识喂给它。知识来源无非两种一是团队已有的 API 文档Swagger、Postman Collection、API Blueprint 等二是没有文档时用浏览器 F12 抓包把请求路径、请求头、请求体、响应体原样记录下来。但光有知识还不够。当你写了第 1 个、第 5 个、第 20 个测试用例后会发现两个新问题一是同一功能在代码库里出现多种写法AI 语义检索时可能找到旧的、不规范的版本二是检索噪音增大AI 反而找不到最相关的参考。这时候就需要工程化手段把接口调用抽到 API 层把多接口串联的业务流程抽到 Service 层再用 Cursor Rules 文件把规范“写给 AI 看”。这篇内容面向接口测试新手以 Cursor 为 AI 工具通过 TaoToken 统一 Key/API 通道接入模型演示从零生成接口自动化测试代码的完整闭环。你会拿到可复制的 Cursor 配置骨架、settings.json 关键字段、一次生成测试代码后的运行验证动作以及分层架构和 Rules 文件的落地写法。适合谁刚学 pytest、想用 AI 提效但总被“AI 瞎猜接口”困扰的测试同学。2. 前置准备TaoToken 统一 Key 与 Cursor 接入TaoToken 在这里扮演的角色是“统一 Key/API 通道”。你可以把它理解成一个模型调用的统一入口不管底层用哪个模型Cursor 里只配一个 base_url 和一个 API Key就能完成对话、代码生成、语义检索等操作。对接口测试新手来说好处是不用在多个模型平台之间来回切换配置一次即可。先拿到 Key。打开 TaoToken 控制台进入 API Keys 页面创建一个新 Key复制保存。注意 Key 只在创建时完整显示一次丢了就重新建一个。控制台地址https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcursor_api_test拿到 Key 后在 Cursor 里配置模型通道。Cursor 支持 OpenAI 兼容协议所以只需要填 base_url 和 api_key。base_url 用 https://taotoken.net/api 不要加 UTM 参数。如果你用的是 Claude Code 这类 Anthropic 协议工具接入文档里有对应的配置说明https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcursor_api_test注意Key 不要硬编码进代码或提交到 Git。测试工程里统一从环境变量读取后面 Rules 文件会强制这一点。配置完成后建议先在模型对话里做一次连通性验证确认 Key 和通道都正常https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcursor_api_test3. 可复制配置Cursor 配置文件骨架与 settings.json 关键字段Cursor 的模型配置分两层一层是应用级设置settings.json一层是项目级规则.cursor/rules/*.mdc。先给一份可直接复制的 settings.json 骨架关键字段我都标了注释。{ openai.apiKey: 从环境变量或 TaoToken 控制台获取不要写死, openai.baseUrl: https://taotoken.net/api, cursor.general.enableCodebaseIndexing: true, cursor.chat.defaultModel: 你接入的模型名称, editor.formatOnSave: true, python.defaultInterpreterPath: .venv/bin/python, python.testing.pytestEnabled: true, python.testing.pytestArgs: [tests] }几个字段说明。openai.baseUrl指向 TaoToken 的 API 地址Cursor 会按 OpenAI 兼容协议发请求。cursor.general.enableCodebaseIndexing必须为 true这是语义检索的基础Cursor 会在后台对整个代码库做 Embedding 并存入向量数据库你可以在右下角看到Indexing codebase...的进度。python.testing.pytestEnabled打开后Cursor 能识别 pytest 测试并在编辑器里直接运行。项目级配置还需要一个.cursor/rules/目录。先建目录mkdir -p .cursor/rules touch .cursor/rules/api-test-rules.mdc.mdc文件开头是 YAML Front Matter用来控制规则触发时机--- description: 接口自动化工程编码规范 globs: - tests/**/*.py - api/**/*.py - services/**/*.py alwaysApply: false ---globs的作用是当 AI 正在操作匹配这些路径的文件时自动附加此规则不需要你每次手动提醒。alwaysApply: true则对所有文件始终生效适合放“始终用中文回复”这类个人偏好。工程目录骨架建议这样组织后面所有步骤都基于它api-autotest/ ├── api/ # 接口调用层每个接口定义一次 │ └── order_api.py ├── services/ # 业务逻辑层多接口串联的公共流程 │ └── order_service.py ├── tests/ # 测试用例层只关心测试逻辑 │ └── order/ │ └── test_create_order.py ├── utils/ │ └── http_client.py ├── conftest.py └── pytest.ini4. 从零生成接口测试代码抓包、喂知识、跑通闭环4.1 没有文档时用 F12 抓包拿到接口知识很多团队的 API 文档滞后于代码甚至没有文档。最直接的办法是浏览器开发者工具抓包。打开目标功能页面按 F12 切到 Network 标签执行一次真实操作比如点击“创建订单”找到目标请求右键 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 } }把这些信息加上一句功能描述一起丢给 Cursor 的 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 拿到这些信息后能准确理解接口的路径、方法、入参、返回值生成的代码会非常接近真实可用。它还会自主推理出你没说清楚的边界比如 quantity 不能为 0 或负数、coupon_code 不传时的行为、product_id 不存在时应报错。如果 AI 推理错了直接纠正它“quantity 最大值不是 99系统限制是 999超过库存数量才报错。”它会立刻更新测试用例并调整相关边界场景。4.2 用 API 层和 Service 层消除语义检索噪音当测试文件多起来语义检索会“迷路”。同一功能可能有多种写法有的用api_client.post(/api/v2/orders, json{product_id: ...})有的用{productId: ..., qty: ...}还有的用了另一套封装。AI 检索时可能找到旧的、不规范的写法生成风格不一致的代码。解法是三层架构。api/order_api.py是接口调用层每个接口只定义一次是整个工程的“接口字典”# api/order_api.py 订单模块接口定义。所有订单相关接口调用都从这里发出禁止在测试文件中直接拼接接口路径。 from utils.http_client import APIClient def 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_code if remark: payload[remark] remark return client.post(/api/v2/orders, jsonpayload) def get_order(client: APIClient, order_id: str): 查询订单详情 return client.get(f/api/v2/orders/{order_id})services/order_service.py是业务逻辑层封装多接口串联的公共流程# services/order_service.py 订单业务逻辑层。封装常用的多步骤业务流程供测试用例直接调用。 from api.order_api import create_order, get_order from utils.http_client import APIClient def 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_idprod_test_001, quantity1, address_idaddr_test_001) assert resp.status_code 201 return resp.json()[data][order_id]测试文件只关心测试逻辑引用这两层# tests/order/test_create_order.py from api.order_api import create_order from services.order_service import create_and_get_order class 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] 0 def 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/order_api.py一处即知不会再被 100 个测试文件里的多种写法干扰。新测试参考 API 层和 Service 层风格自然统一。4.3 用 Rules 文件把工程规范写给 AI 看有了分层架构还要让 AI 知道这些规范。否则下次它可能还是在测试文件里直接写api_client.post(...)。Cursor Rules 文件本质上是附加在每次对话中的系统提示词你写的内容会在 AI 生成代码前自动注入。一个可直接用于接口测试工程的 Rules 文件示例--- description: 接口自动化工程编码规范 globs: - tests/**/*.py - api/**/*.py - services/**/*.py alwaysApply: false --- # 接口自动化工程编码规范 ## 工程结构 - api/接口调用层每个接口有且只有一处定义命名规范为 {模块名}_api.py - services/业务逻辑层封装需要多接口串联的公共业务流程 - tests/测试用例层只关注测试逻辑不直接拼接接口路径 ## 编写测试用例的强制规范 ### 1. 禁止在测试文件中直接调用 HTTP 客户端 错误示范api_client.post(/api/v2/orders, json{...}) 正确示范from api.order_api import create_order 后调用 create_order(...) ### 2. 优先使用 Service 层的公共方法 需要“创建订单后查询”时使用 order_service.create_and_get_order()不要手动写两次接口调用。 ### 3. 新增接口时必须先在 api 层定义 调用 api/ 目录下还没有的接口时必须先在对应 {模块}_api.py 中定义该接口函数。 ### 4. 测试用例命名规范 - 文件名test_{被测功能}.py - 类名Test{功能名驼峰} - 方法名test_{场景描述} ### 5. 断言规范 - 必须断言 HTTP 状态码 - 必须断言响应体中的核心业务字段 - 错误场景必须断言错误信息的具体内容message 字段 ## 语言规范 - 所有代码注释使用中文 - docstring 必须说明函数功能和适用测试场景有了这个文件当你告诉 AI“帮我写一个支付订单的测试用例接口是 POST /api/v2/orders/{order_id}/pay需要先有一个待支付的订单”AI 会自动检查api/order_api.py是否已有pay_order()没有就先补充检查services/order_service.py是否有create_pending_order()可复用然后生成符合命名规范的测试类和方法名断言状态码和业务字段。5. 验证请求一次生成测试代码后的运行动作代码生成后必须跑一遍确认闭环。先确认conftest.py里的api_clientfixture 能正常发请求然后执行pytest tests/order/test_create_order.py -v预期输出类似tests/order/test_create_order.py::TestCreateOrder::test_create_order_success PASSED tests/order/test_create_order.py::TestCreateOrder::test_create_order_missing_product_id PASSED 2 passed in 1.23s 如果测试通过说明从抓包喂知识、AI 生成代码、分层引用到实际运行整条链路已经跑通。如果失败先看断言信息定位是接口路径、字段名还是状态码对不上把真实响应贴回 Cursor 让它修正。这一步是“AI 写草稿、你来校正”的代码审查过程效率远高于从零手写。6. 本篇常见错排查报错一openai.baseUrl配错导致 404 或连接失败。检查 base_url 是否为https://taotoken.net/api不要带多余路径或 UTM 参数。Key 是否从控制台正确复制有没有多余空格。报错二Cursor 语义检索找不到已有代码。确认cursor.general.enableCodebaseIndexing为 true右下角索引是否完成。如果项目刚打开等Indexing codebase...跑完再让 AI 生成代码。报错三AI 生成的测试直接拼接接口路径没用 API 层。说明 Rules 文件没生效。检查.cursor/rules/api-test-rules.mdc的globs是否覆盖了当前文件路径Front Matter 格式是否正确。报错四pytest 找不到api_clientfixture。检查conftest.py是否在项目根目录fixture 是否用pytest.fixture装饰作用域是否匹配。报错五断言状态码对不上。先用抓包结果核对真实状态码再检查 AI 是否把 201 写成了 200。错误场景的message字段也要和真实响应逐字比对。排障和接入相关的配置可以对照接入文档逐项检查https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcursor_api_test7. 继续扩展从单接口到工程化跑通第一个接口后后续扩展只需要录入增量知识。第 1 个接口测试AI 需要你提供完整接口信息第 5 个接口测试AI 已经理解你的项目结构和风格第 20 个接口测试你只需说“仿照test_create_order.py写一个查询订单的测试”第 50 个接口测试AI 几乎不需要额外解释自主完成。实践建议是每次引入新模块时先手动写或精心指导 AI 写一个“示范性”测试用例它会成为该模块后续测试的参考基准。后续只增量录入新字段、新规则存量的调用方式 AI 自己会从 API 层和 Service 层找到。如果你要长期做接口自动化、甚至让 AI 参与更多编码和 Agent 任务可以了解 Coding Plan 的额度方案https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcursor_api_test最后留一个我踩过的坑Rules 文件不要一次写太长先写最核心的三条禁止直接调 HTTP 客户端、优先用 Service 层、新增接口先定义到 API 层跑顺了再逐步补充。规则太多反而会让 AI 在生成时顾此失彼。 从 0 开始学习 AI 测试：用 Cursor 配 TaoToken 生成接口自动化测试代码
1. 接口测试新手为什么总在“造数据”上卡住刚接触接口自动化测试时最容易陷入的误区是以为让 AI 写测试代码就是打开 Cursor 敲一句“帮我写个创建订单的接口测试”然后坐等可运行的代码。我试过结果 AI 给出的接口路径、字段名、状态码全是它根据通用经验“猜”出来的和真实系统大概率对不上。这不是 AI 不行而是它手里没有你系统的接口知识。接口测试的本质是“用代码模拟客户端发请求再校验服务端响应”。要让 AI 生成能跑的自动化测试代码前提是你先把接口知识喂给它。知识来源无非两种一是团队已有的 API 文档Swagger、Postman Collection、API Blueprint 等二是没有文档时用浏览器 F12 抓包把请求路径、请求头、请求体、响应体原样记录下来。但光有知识还不够。当你写了第 1 个、第 5 个、第 20 个测试用例后会发现两个新问题一是同一功能在代码库里出现多种写法AI 语义检索时可能找到旧的、不规范的版本二是检索噪音增大AI 反而找不到最相关的参考。这时候就需要工程化手段把接口调用抽到 API 层把多接口串联的业务流程抽到 Service 层再用 Cursor Rules 文件把规范“写给 AI 看”。这篇内容面向接口测试新手以 Cursor 为 AI 工具通过 TaoToken 统一 Key/API 通道接入模型演示从零生成接口自动化测试代码的完整闭环。你会拿到可复制的 Cursor 配置骨架、settings.json 关键字段、一次生成测试代码后的运行验证动作以及分层架构和 Rules 文件的落地写法。适合谁刚学 pytest、想用 AI 提效但总被“AI 瞎猜接口”困扰的测试同学。2. 前置准备TaoToken 统一 Key 与 Cursor 接入TaoToken 在这里扮演的角色是“统一 Key/API 通道”。你可以把它理解成一个模型调用的统一入口不管底层用哪个模型Cursor 里只配一个 base_url 和一个 API Key就能完成对话、代码生成、语义检索等操作。对接口测试新手来说好处是不用在多个模型平台之间来回切换配置一次即可。先拿到 Key。打开 TaoToken 控制台进入 API Keys 页面创建一个新 Key复制保存。注意 Key 只在创建时完整显示一次丢了就重新建一个。控制台地址https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcursor_api_test拿到 Key 后在 Cursor 里配置模型通道。Cursor 支持 OpenAI 兼容协议所以只需要填 base_url 和 api_key。base_url 用 https://taotoken.net/api 不要加 UTM 参数。如果你用的是 Claude Code 这类 Anthropic 协议工具接入文档里有对应的配置说明https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcursor_api_test注意Key 不要硬编码进代码或提交到 Git。测试工程里统一从环境变量读取后面 Rules 文件会强制这一点。配置完成后建议先在模型对话里做一次连通性验证确认 Key 和通道都正常https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcursor_api_test3. 可复制配置Cursor 配置文件骨架与 settings.json 关键字段Cursor 的模型配置分两层一层是应用级设置settings.json一层是项目级规则.cursor/rules/*.mdc。先给一份可直接复制的 settings.json 骨架关键字段我都标了注释。{ openai.apiKey: 从环境变量或 TaoToken 控制台获取不要写死, openai.baseUrl: https://taotoken.net/api, cursor.general.enableCodebaseIndexing: true, cursor.chat.defaultModel: 你接入的模型名称, editor.formatOnSave: true, python.defaultInterpreterPath: .venv/bin/python, python.testing.pytestEnabled: true, python.testing.pytestArgs: [tests] }几个字段说明。openai.baseUrl指向 TaoToken 的 API 地址Cursor 会按 OpenAI 兼容协议发请求。cursor.general.enableCodebaseIndexing必须为 true这是语义检索的基础Cursor 会在后台对整个代码库做 Embedding 并存入向量数据库你可以在右下角看到Indexing codebase...的进度。python.testing.pytestEnabled打开后Cursor 能识别 pytest 测试并在编辑器里直接运行。项目级配置还需要一个.cursor/rules/目录。先建目录mkdir -p .cursor/rules touch .cursor/rules/api-test-rules.mdc.mdc文件开头是 YAML Front Matter用来控制规则触发时机--- description: 接口自动化工程编码规范 globs: - tests/**/*.py - api/**/*.py - services/**/*.py alwaysApply: false ---globs的作用是当 AI 正在操作匹配这些路径的文件时自动附加此规则不需要你每次手动提醒。alwaysApply: true则对所有文件始终生效适合放“始终用中文回复”这类个人偏好。工程目录骨架建议这样组织后面所有步骤都基于它api-autotest/ ├── api/ # 接口调用层每个接口定义一次 │ └── order_api.py ├── services/ # 业务逻辑层多接口串联的公共流程 │ └── order_service.py ├── tests/ # 测试用例层只关心测试逻辑 │ └── order/ │ └── test_create_order.py ├── utils/ │ └── http_client.py ├── conftest.py └── pytest.ini4. 从零生成接口测试代码抓包、喂知识、跑通闭环4.1 没有文档时用 F12 抓包拿到接口知识很多团队的 API 文档滞后于代码甚至没有文档。最直接的办法是浏览器开发者工具抓包。打开目标功能页面按 F12 切到 Network 标签执行一次真实操作比如点击“创建订单”找到目标请求右键 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 } }把这些信息加上一句功能描述一起丢给 Cursor 的 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 拿到这些信息后能准确理解接口的路径、方法、入参、返回值生成的代码会非常接近真实可用。它还会自主推理出你没说清楚的边界比如 quantity 不能为 0 或负数、coupon_code 不传时的行为、product_id 不存在时应报错。如果 AI 推理错了直接纠正它“quantity 最大值不是 99系统限制是 999超过库存数量才报错。”它会立刻更新测试用例并调整相关边界场景。4.2 用 API 层和 Service 层消除语义检索噪音当测试文件多起来语义检索会“迷路”。同一功能可能有多种写法有的用api_client.post(/api/v2/orders, json{product_id: ...})有的用{productId: ..., qty: ...}还有的用了另一套封装。AI 检索时可能找到旧的、不规范的写法生成风格不一致的代码。解法是三层架构。api/order_api.py是接口调用层每个接口只定义一次是整个工程的“接口字典”# api/order_api.py 订单模块接口定义。所有订单相关接口调用都从这里发出禁止在测试文件中直接拼接接口路径。 from utils.http_client import APIClient def 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_code if remark: payload[remark] remark return client.post(/api/v2/orders, jsonpayload) def get_order(client: APIClient, order_id: str): 查询订单详情 return client.get(f/api/v2/orders/{order_id})services/order_service.py是业务逻辑层封装多接口串联的公共流程# services/order_service.py 订单业务逻辑层。封装常用的多步骤业务流程供测试用例直接调用。 from api.order_api import create_order, get_order from utils.http_client import APIClient def 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_idprod_test_001, quantity1, address_idaddr_test_001) assert resp.status_code 201 return resp.json()[data][order_id]测试文件只关心测试逻辑引用这两层# tests/order/test_create_order.py from api.order_api import create_order from services.order_service import create_and_get_order class 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] 0 def 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/order_api.py一处即知不会再被 100 个测试文件里的多种写法干扰。新测试参考 API 层和 Service 层风格自然统一。4.3 用 Rules 文件把工程规范写给 AI 看有了分层架构还要让 AI 知道这些规范。否则下次它可能还是在测试文件里直接写api_client.post(...)。Cursor Rules 文件本质上是附加在每次对话中的系统提示词你写的内容会在 AI 生成代码前自动注入。一个可直接用于接口测试工程的 Rules 文件示例--- description: 接口自动化工程编码规范 globs: - tests/**/*.py - api/**/*.py - services/**/*.py alwaysApply: false --- # 接口自动化工程编码规范 ## 工程结构 - api/接口调用层每个接口有且只有一处定义命名规范为 {模块名}_api.py - services/业务逻辑层封装需要多接口串联的公共业务流程 - tests/测试用例层只关注测试逻辑不直接拼接接口路径 ## 编写测试用例的强制规范 ### 1. 禁止在测试文件中直接调用 HTTP 客户端 错误示范api_client.post(/api/v2/orders, json{...}) 正确示范from api.order_api import create_order 后调用 create_order(...) ### 2. 优先使用 Service 层的公共方法 需要“创建订单后查询”时使用 order_service.create_and_get_order()不要手动写两次接口调用。 ### 3. 新增接口时必须先在 api 层定义 调用 api/ 目录下还没有的接口时必须先在对应 {模块}_api.py 中定义该接口函数。 ### 4. 测试用例命名规范 - 文件名test_{被测功能}.py - 类名Test{功能名驼峰} - 方法名test_{场景描述} ### 5. 断言规范 - 必须断言 HTTP 状态码 - 必须断言响应体中的核心业务字段 - 错误场景必须断言错误信息的具体内容message 字段 ## 语言规范 - 所有代码注释使用中文 - docstring 必须说明函数功能和适用测试场景有了这个文件当你告诉 AI“帮我写一个支付订单的测试用例接口是 POST /api/v2/orders/{order_id}/pay需要先有一个待支付的订单”AI 会自动检查api/order_api.py是否已有pay_order()没有就先补充检查services/order_service.py是否有create_pending_order()可复用然后生成符合命名规范的测试类和方法名断言状态码和业务字段。5. 验证请求一次生成测试代码后的运行动作代码生成后必须跑一遍确认闭环。先确认conftest.py里的api_clientfixture 能正常发请求然后执行pytest tests/order/test_create_order.py -v预期输出类似tests/order/test_create_order.py::TestCreateOrder::test_create_order_success PASSED tests/order/test_create_order.py::TestCreateOrder::test_create_order_missing_product_id PASSED 2 passed in 1.23s 如果测试通过说明从抓包喂知识、AI 生成代码、分层引用到实际运行整条链路已经跑通。如果失败先看断言信息定位是接口路径、字段名还是状态码对不上把真实响应贴回 Cursor 让它修正。这一步是“AI 写草稿、你来校正”的代码审查过程效率远高于从零手写。6. 本篇常见错排查报错一openai.baseUrl配错导致 404 或连接失败。检查 base_url 是否为https://taotoken.net/api不要带多余路径或 UTM 参数。Key 是否从控制台正确复制有没有多余空格。报错二Cursor 语义检索找不到已有代码。确认cursor.general.enableCodebaseIndexing为 true右下角索引是否完成。如果项目刚打开等Indexing codebase...跑完再让 AI 生成代码。报错三AI 生成的测试直接拼接接口路径没用 API 层。说明 Rules 文件没生效。检查.cursor/rules/api-test-rules.mdc的globs是否覆盖了当前文件路径Front Matter 格式是否正确。报错四pytest 找不到api_clientfixture。检查conftest.py是否在项目根目录fixture 是否用pytest.fixture装饰作用域是否匹配。报错五断言状态码对不上。先用抓包结果核对真实状态码再检查 AI 是否把 201 写成了 200。错误场景的message字段也要和真实响应逐字比对。排障和接入相关的配置可以对照接入文档逐项检查https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcursor_api_test7. 继续扩展从单接口到工程化跑通第一个接口后后续扩展只需要录入增量知识。第 1 个接口测试AI 需要你提供完整接口信息第 5 个接口测试AI 已经理解你的项目结构和风格第 20 个接口测试你只需说“仿照test_create_order.py写一个查询订单的测试”第 50 个接口测试AI 几乎不需要额外解释自主完成。实践建议是每次引入新模块时先手动写或精心指导 AI 写一个“示范性”测试用例它会成为该模块后续测试的参考基准。后续只增量录入新字段、新规则存量的调用方式 AI 自己会从 API 层和 Service 层找到。如果你要长期做接口自动化、甚至让 AI 参与更多编码和 Agent 任务可以了解 Coding Plan 的额度方案https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcursor_api_test最后留一个我踩过的坑Rules 文件不要一次写太长先写最核心的三条禁止直接调 HTTP 客户端、优先用 Service 层、新增接口先定义到 API 层跑顺了再逐步补充。规则太多反而会让 AI 在生成时顾此失彼。