“PythonAI结合落地实战接口自动化让代码如此简单~开整”——这个标题说实话挺能引起我共鸣的。我自己做接口自动化做了五六年早期写 pytest requests 的一套东西最耗时间的不是跑通一个用例而是面对几十个接口、几百个字段不断重复地写请求、写断言、造数据、查报错。最近一年我把 AI 大模型真正引入了日常的接口自动化开发流程最大的感受是代码量没有减少太多但“从零手写”变成了“生成改错调优”整体效率至少翻了一倍。这篇文章我不讲虚的直接把我的落地方式、提示词模板、踩过的坑都放出来适合正在做接口自动化测试的测试开发、刚入门想找方向的测试新人以及想让 AI 当编程助手的后端同学。我先把结论放在前面AI 接进来的核心价值不是“替你把整个自动化框架写出来”而是把“重复劳动”和“经验性工作”拆开AI 负责快速产出初稿、生成数据、辅助定位问题人负责架构设计、边界判断和代码审查。整篇文章会从真实痛点讲起到环境选型、AI 接入、用例生成、Demo 跑通、问题排查全部是可复现的操作。1. 为什么要把 AI 塞进接口自动化1.1 先聊聊接口自动化真实的痛点很多人觉得接口自动化难在“写代码”实际上我带的几个项目里真正让人痛苦的是下面几件事。第一是维护成本。接口字段变更、域名切换、鉴权方式调整、返回结构嵌套层数变化任何一个改动都可能让一批用例瞬间全红。而手工维护这些用例需要打开接口文档、对比线上返回、一行行改断言。这事重复度高、技能含量低但特别耗时AI 非常适合在这种场景里做辅助。第二是测试数据的准备。拿登录场景举例你不仅要有正常账号还要有密码错误、账号不存在、账号被锁定、验证码过期等各种状态的数据。很多数据依赖前置操作比如“订单已支付”“库存不足”这种状态靠手工造数能造到怀疑人生。AI 至少能帮你快速生成数据构造的代码逻辑减少一部分重复造轮子的时间。第三是断言写得太随意。很多同学写断言就只检查 HTTP 状态码是 200然后完事。真正上线后接口返回 200 但业务逻辑已经错了的情况比比皆是。状态码只是最浅的一层业务码、关键字段、字段类型、为空判断、时间范围、枚举值合法性这些都需要覆盖。可惜大部分人的接口自动化用例里断言不够规范AI 在这方面反而能补位只要你在提示词里把断言规则说清楚它生成出来的代码通常比新手手写更严谨。1.2 AI 在接口自动化里到底能干什么AI 不是银弹它不能完全替代测试开发工程师。在我实际使用中它最靠谱的几个场景是根据接口文档片段直接生成 pytest 测试函数包括请求构建、参数传递、断言代码。生成测试数据比如手机号、身份证、邮箱、边界值、异常值省去手写造数函数的时间。不过注意身份证这类数据要用生成器伪装不要拿真实信息。辅助理解接口返回结构当一个接口返回几十个字段时把 JSON 丢给 AI让它帮忙梳理字段含义和重点断言字段。定位代码报错把 Traceback 贴给 AI让它解释原因并给出修复建议省去到处百度的过程。自动生成参数化数据让一条用例覆盖多组输入提升覆盖度。一句话总结AI 是做“初稿生成、信息整理、代码解释”的人是做“架构设计、方案决策、质量兜底”的。这个定位想清楚后面全部工作都不会跑偏。2. 准备工作环境与框架选型2.1 先搞定 Python 环境不管你是 Windows、macOS 还是 Linux我都建议先装 Python 3.10 以上的版本原因很简单新版语法更简洁第三方库兼容性也更好。Python 2 和 Python 3.7 以下的老环境就不要再挣扎了接口自动化用新版会让你少踩很多编码、类型相关的坑。安装完成后最好给每个项目建独立的虚拟环境别把依赖装到全局。我的习惯是python -m venv .venv source .venv/bin/activate # Windows 下执行 .venv\Scripts\activate然后升级 pip 和安装依赖python -m pip install --upgrade pip pip install requests pytest pytest-html pyyaml openai如果你在国内pip 下载慢可以临时指定清华源pip install -i https://pypi.tuna.tsinghua.edu.cn/simple requests pytest编辑器方面日常写接口自动化用 VS Code 就足够装上 Python 插件和 REST Client 插件会很舒服。如果你接下来要用 AI 编程辅助VS Code 生态里的插件选择面也最广。2.2 项目依赖与目录结构接口自动化的技术栈市面上很多有 Java 系的有 Python 系的。Python 系里我强烈推荐 pytest requests pytest-html这套组合的优势很明显断言用原生assert就能写、fixture 管理前后置逻辑很方便、插件生态完善、报告生成简单。我把一个标准的项目目录结构列出来大家可以直接照着建api_auto/ ├── requirements.txt ├── conftest.py # pytest 全局 fixture读写配置、初始化客户端 ├── config/ │ ├── settings.yaml # 环境地址、超时时间、账号信息等配置 │ └── settings.py # 读取 yaml 的封装 ├── common/ │ ├── api_client.py # requests 会话封装处理鉴权、日志、超时 │ ├── assert_utils.py # 断言工具 │ └── data_utils.py # 测试数据生成 ├── testcases/ │ ├── test_login.py │ ├── test_user.py │ └── test_order.py ├── data/ │ └── user_cases.yaml # 数据驱动文件 └── reports/ # 测试报告输出目录目录结构不一定非要和我完全一样但核心原则是配置和代码分离、公共能力和用例分离、测试数据和用例分离。这样当接口地址变动、账号变动、用例增加时改起来不会像一团乱麻。2.3 AI 助手到底怎么接这是很多人卡住的第一步。目前接 AI 编程辅助主要有三种方式我逐个说下适用场景。第一种是“编辑器 AI 插件”比如 GitHub Copilot、通义灵码、CodeGeeX、Cursor 编辑器。这种适合在写代码过程中实时补全、生成函数、解释代码和 IDE 结合最紧密也是我平时用得最多的方式。你只要在 VS Code 里装好插件登录账号写注释说明意图它就能往下补代码。对接口自动化来说我会在test_user.py里先写一行注释比如“创建用户成功用例请求 POST /api/v1/user参数为姓名、手机号、邮箱”插件就开始自动生成测试函数。第二种是“云端大模型 API”通过代码直接调用。这种方式适合批量生成代码、搭建自动化的“AI 测试平台”或者处理编辑器插件搞不定的复杂逻辑。OpenAI 的 GPT 系列可以国内 DeepSeek、通义千问、智谱 GLM 这些也都有兼容接口成本很低我用得最多的是 DeepSeek 和通义生成接口测试用例完全够用。调用 API 时我习惯把 API Key 放到环境变量里而不是写死在代码中避免不小心提交到仓库导致泄露export DEEPSEEK_API_KEY你的key然后写一个简单的请求封装import os from openai import OpenAI client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com, ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一名资深的接口自动化测试开发工程师精通Python和pytest。}, {role: user, content: 帮我生成一个测试登录接口的pytest用例接口是POST /api/v1/login。}, ], ) print(resp.choices[0].message.content)第三种是“本地大模型”用 Ollama 跑 qwen2.5、llama3 这类开源模型然后通过本地接口调用。这种方式的好处是数据不出内网、免费、隐私性好适合公司有保密要求的环境。缺点是模型能力比云端大模型弱一点复杂代码生成质量会下降但用来生成常规的接口测试脚本完全没问题。三种方式不是互斥的我自己是“编辑器插件云端 API”组合使用既能实时补全又能批量生成效率最高。接入方式优点缺点适合场景编辑器AI插件实时补全、和IDE结合好批量处理能力弱日常写代码云端大模型API能力强、批量生成稳定需要网络、按量付费批量生成、自动平台本地模型数据安全、免费能力稍弱公司内网、保密项目3. 实战让 AI 帮你生成接口自动化用例3.1 从接口文档到测试用例的提示词写法很多朋友用 AI 生成代码效果差主要原因是提示词太笼统。你说“帮我写个测试登录的用例”它不知道该用什么框架、要不要 token、断言粒度多细。我的经验是把“角色、任务、输入、输出格式、约束条件”五要素说清楚。我自己常用的提示词模板是这样的角色你是一名资深接口自动化测试开发工程师精通 Python、pytest、requests 任务根据下面的接口文档生成一个 pytest 测试函数用于测试登录接口 接口文档 - 接口路径POST /api/v1/login - 请求头Content-Type: application/json - 请求体{username: admin, password: 123456} - 响应成功示例{code: 0, message: success, data: {token: abc123, nickname: 管理员}} - 失败场景密码错误时接口返回 HTTP 200但 code 为 1001message 为用户名或密码错误 输出格式只输出 Python 代码不要解释使用 pytest 风格断言要覆盖 HTTP 状态码、code、message、data.token 是否存在把这段提示词发给 AI我拿到过很多次结果质量通常都不错。大致是这样import pytest import requests BASE_URL http://127.0.0.1:8000 def test_login_success(): url f{BASE_URL}/api/v1/login payload {username: admin, password: 123456} resp requests.post(url, jsonpayload) assert resp.status_code 200, fHTTP状态码异常: {resp.status_code} body resp.json() assert body[code] 0 assert body[message] success assert token in body[data], 响应中缺少token字段 assert body[data][nickname] 管理员 def test_login_wrong_password(): url f{BASE_URL}/api/v1/login payload {username: admin, password: wrong} resp requests.post(url, jsonpayload) assert resp.status_code 200 body resp.json() assert body[code] 1001 assert body[message] 用户名或密码错误拿到代码以后不要直接用先做一轮“人工 review”。我会检查三件事一是 URL 和参数有没有按文档拼接正确二是断言有没有覆盖主要业务含义三是这个用例在项目里能不能复用现有封装的客户端。如果项目已经封装了api_client我会让 AI 用现有客户端重新生成提示词里加上“使用 common/api_client.py 中的 ApiClient 类发起请求不要直接用 requests”。3.2 让 AI 帮你写断言建议按这四层来接口断言是接口自动化里最容易翻车的地方。我见过太多只用assert resp.status_code 200的代码这种断言遇到“业务异常但 HTTP 正常”的情况就完全失效了。所以我一般会把断言拆成四层第一层HTTP 状态码判断网络和请求是否正常到达服务端。第二层业务状态码也就是响应体里的 code判断业务是否成功。第三层关键字段判断核心数据有没有返回比如 token、订单号、用户 ID。第四层字段类型和约束比如返回的 age 必须为 int、列表不能为空、时间格式要符合YYYY-MM-DD HH:mm:ss。让 AI 写断言时你可以直接把这四层要求写进提示词“请按四层断言规范生成代码状态码、业务码、关键字段存在性、字段类型校验”。它生成的代码通常会更完整。我整理了一个断言工具模块你也可以让 AI 对照这个风格写# common/assert_utils.py import json def assert_http_ok(resp): assert resp.status_code 200, fHTTP状态码异常: {resp.status_code}响应内容: {resp.text} def assert_code(resp, expect_code0): body resp.json() assert body.get(code) expect_code, f业务码异常: {body.get(code)}, 期望: {expect_code}, 响应: {body} def assert_key_exists(data, key): assert key in data, f响应中缺少字段: {key}, 完整返回: {data} def assert_field_type(data, key, expect_type): assert key in data, f响应中缺少字段: {key} assert isinstance(data[key], expect_type), f字段 {key} 类型错误: {type(data[key])}, 期望: {expect_type}然后在用例里这样用def test_get_user_success(api_client): resp api_client.get(/api/v1/user/1001) assert_http_ok(resp) assert_code(resp, 0) body resp.json()[data] assert_key_exists(body, username) assert_field_type(body, age, int)这么写的优势在于断言逻辑被统一封装后每个用例都遵循同一套规范维护成本大幅降低。3.3 参数化与数据驱动AI 是很好的“造数助手”接口自动化的覆盖率往往取决于测试数据的丰富程度。一个“创建用户”接口至少要覆盖正常数据、缺少必填字段、字段类型错误、字段长度越界、重复名称、特殊字符等场景。如果全部手写每个场景写一个函数代码会非常冗余。pytest 的参数化正好解决这个问题而 AI 可以帮我们快速生成参数化列表。我习惯的提示词是你是接口测试专家。请为“创建用户”接口生成 pytest.mark.parametrize 的参数化数据接口要求username必填3-20个字符age必填18-60的整数email可选格式需合法。请生成以下用例 1. 正常数据 2. username为空 3. username长度为2 4. username长度为21 5. age小于18 6. age大于60 7. email格式错误 8. 全部字段正常但email为空字符串 输出为可以直接拼接到 pytest 装饰器里的列表每个元素包含用例名、请求参数、期望的业务码。AI 给我的输出经过整理后大概是这样的import pytest from common.assert_utils import assert_http_ok, assert_code pytest.mark.parametrize(case_name,payload,expect_code, [ (正常创建, {username: 张三, age: 25, email: zhangsanexample.com}, 0), (用户名为空, {username: , age: 25}, 1001), (用户名过短, {username: 张, age: 25}, 1001), (用户名过长, {username: 张 * 21, age: 25}, 1001), (年龄过小, {username: 李四, age: 17}, 1001), (年龄过大, {username: 李四, age: 61}, 1001), (邮箱格式错误, {username: 王五, age: 30, email: not_an_email}, 1002), (邮箱为空字符串, {username: 王五, age: 30, email: }, 0), ]) def test_create_user(case_name, payload, expect_code, api_client): resp api_client.post(/api/v1/user, jsonpayload) assert_http_ok(resp) assert_code(resp, expect_code)这里有个经验不要把期望值写死成“全部成功”或者“全部失败”不同异常场景对应不同业务码AI 自动推断业务码时偶尔会猜错所以生成后一定要对着接口文档核一遍期望 code。如果你的用例数据量大建议把数据挪到独立的 YAML 文件里写一个动态加载参数的 fixtureimport yaml import pytest def load_cases_from_yaml(file_path): with open(file_path, encodingutf-8) as f: data yaml.safe_load(f) return [(case[name], case[payload], case[expect_code]) for case in data] pytest.mark.parametrize(case_name,payload,expect_code, load_cases_from_yaml(data/user_cases.yaml)) def test_create_user_from_yaml(case_name, payload, expect_code, api_client): ...这样测试用例和测试代码彻底分离后续新增数据只需要改 YAML不需要动 Python 代码。4. 项目落地一个可跑的接口自动化 Demo4.1 先搭一个被测接口服务为了完整演示 AI 辅助接口自动化的过程我直接用 FastAPI 写一个小服务作为被测目标。FastAPI 写接口非常简单适合做测试练习服务。# app.py from fastapi import FastAPI from pydantic import BaseModel, Field app FastAPI() class LoginRequest(BaseModel): username: str password: str class UserCreateRequest(BaseModel): username: str Field(..., min_length3, max_length20) age: int Field(..., ge18, le60) email: str app.post(/api/v1/login) def login(req: LoginRequest): if req.username admin and req.password 123456: return {code: 0, message: success, data: {token: test_token_123, nickname: 管理员}} return {code: 1001, message: 用户名或密码错误, data: None} app.post(/api/v1/user) def create_user(req: UserCreateRequest): return {code: 0, message: success, data: {user_id: 10001, username: req.username}} app.get(/api/v1/user/{user_id}) def get_user(user_id: int): if user_id 1001: return {code: 0, message: success, data: {user_id: 1001, username: 张三, age: 25}} return {code: 1003, message: 用户不存在, data: None}启动服务pip install fastapi uvicorn uvicorn app:app --host 127.0.0.1 --port 8000 --reload建议用 httpbin 这一类的在线服务也可以但本地 FastAPI 服务的好处是你能完全控制返回内容和各种异常场景跑用例的时候非常好排查。4.2 AI 生成的完整代码跑通全流程有了被测服务以后我把“项目结构 接口文档 现有公共代码”一并丢给 AI让它生成完整的接口自动化代码。这比单独让它生成某个测试函数效果更好因为 AI 能看到整体上下文。最终跑通的代码我给大家整理成一套最小可运行版本。先看conftest.py它的作用是把 api_client 作为 pytest 的 fixture 提供给每个用例import pytest import requests BASE_URL http://127.0.0.1:8000 pytest.fixture def api_client(): session requests.Session() session.base_url BASE_URL def _request(method, path, **kwargs): url f{session.base_url}{path} resp session.request(method, url, timeout5, **kwargs) print(f\n {method} {url} {resp.status_code} {resp.text}) return resp session.get lambda path, **kwargs: _request(GET, path, **kwargs) session.post lambda path, **kwargs: _request(POST, path, **kwargs) yield session session.close()这里面我用了很简单的封装只是为了演示。真实项目里还要处理登录态透传、超时配置、环境切换、请求日志等但核心思想是一样的把公共逻辑放进 fixture用例里只写业务逻辑。然后是被测服务的登录用例# testcases/test_login.py from common.assert_utils import assert_http_ok, assert_code, assert_key_exists, assert_field_type class TestLogin: def test_login_success(self, api_client): resp api_client.post(/api/v1/login, json{username: admin, password: 123456}) assert_http_ok(resp) assert_code(resp, 0) body resp.json()[data] assert_key_exists(body, token) assert_field_type(body, token, str) def test_login_wrong_password(self, api_client): resp api_client.post(/api/v1/login, json{username: admin, password: wrong}) assert_http_ok(resp) assert_code(resp, 1001) assert resp.json()[message] 用户名或密码错误用户相关的参数化用例# testcases/test_user.py import pytest from common.assert_utils import assert_http_ok, assert_code, assert_key_exists pytest.mark.parametrize(case_name,payload,expect_code, [ (正常创建, {username: 张三, age: 25, email: zhangsanexample.com}, 0), (用户名为空, {username: , age: 25}, 422), (用户名过短, {username: 张, age: 25}, 422), (年龄过小, {username: 李四, age: 17}, 422), (邮箱格式错误, {username: 王五, age: 30, email: not_an_email}, 0), ]) def test_create_user(case_name, payload, expect_code, api_client): resp api_client.post(/api/v1/user, jsonpayload) assert_http_ok(resp) assert resp.status_code ! 500, 服务端出现500错误 if expect_code 422: assert resp.status_code 422, f参数校验未生效: {resp.text} else: assert_code(resp, expect_code)注意这里有个细节FastAPI 的 pydantic 参数校验失败时会返回 HTTP 422所以断言逻辑要适配被测框架的行为。这也是我说“AI 生成的代码要人工 review”的原因之一它生成的断言可能基于自己的假设而实际接口行为要以文档和线上为准。跑测试pytest testcases -v --htmlreports/report.html到这一步一个冒烟级别的接口自动化就完整跑起来了。4.3 测试报告与 CI 接入pytest-html 会生成一份 HTML 报告我一般还会加两个插件让输出更好看pip install pytest-html allure-pytest如果你喜欢 Allure 那种带趋势图和步骤明细的报告也可以用pytest testcases --alluredir./reports/allure-results allure serve ./reports/allure-results接口自动化真正发挥价值不是本地跑一次而是持续跑、定时跑。我通常会把用例接入 CI最简单的方式是 GitHub Actionsname: API Auto Test on: push: schedule: - cron: 0 20 * * * jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv5 with: python-version: 3.11 - run: pip install -r requirements.txt - run: uvicorn app:app --host 127.0.0.1 --port 8000 - run: pytest testcases -v --htmlreports/report.html - uses: actions/upload-artifactv4 with: name: test-report path: reports/report.html这里有一个顺序问题先启动被测服务再跑 pytest否则用例会全部连接失败。真实项目里的被测服务可能是独立的测试环境CI 里只要把BASE_URL指向测试环境地址即可。5. 常见问题与排查技巧实录5.1 AI 生成代码跑不通的典型场景我用 AI 生成接口自动化代码也翻过不少车下面几个场景出现的频率最高。第一个是导入路径问题。AI 生成的代码可能使用from common.api_client import ApiClient但你的目录结构可能没有把项目根目录加入 Python 路径导致ModuleNotFoundError。解决方法是在项目根目录下建一个空文件pytest.ini或者在 conftest.py 里手动把项目根目录写入 sys.pathimport sys from pathlib import Path sys.path.insert(0, str(Path(__file__).parent))第二个是接口鉴权问题。很多接口需要登录后才能访问AI 生成的用例如果直接调请求没有带 token就会出现 401。解决方法是让 AI 在提示词里明确“先调用登录接口获取 token然后放到请求头中”或者我直接把登录态封装在 fixture 里。下面是一个简化的带 token fixturepytest.fixture def api_client(): session requests.Session() login_resp session.post(http://127.0.0.1:8000/api/v1/login, json{username: admin, password: 123456}) token login_resp.json()[data][token] session.headers.update({Authorization: fBearer {token}}) yield session session.close()第三个是编码问题。接口返回中文乱码或者生成的代码里中文硬编码导致编码错误通常是 requests 没有正确设置字符集或者 Python 文件没有声明 UTF-8。现在的 Python 3 默认 UTF-8一般不会出问题如果遇到乱码先检查是不是测试环境返回的 Content-Type 缺失字符集。第四个是异步接口的问题。有些项目接口是异步的返回的不是最终结果而是任务 IDAI 生成的同步用例就会失败。这时候要让 AI 明白“提交异步任务→轮询任务结果→断言最终结果”的流程而不是简单的一次请求断言。我用一个表格把常见问题整理出来常见问题主要原因解决方法ModuleNotFoundError项目根目录未加入模块搜索路径在 conftest.py 中手动添加 sys.path401 鉴权失败请求未携带登录 token封装登录态 fixture统一注入请求头中文乱码响应字符集识别错误使用 resp.encoding utf-8断言不通过AI 对业务返回理解错误人工对照接口文档修正期望值异步任务未完成接口返回任务ID而非最终结果增加轮询逻辑参数校验返回 422FastAPI 等框架的校验机制断言需匹配框架实际行为5.2 让 AI 更听话的三个提示词技巧同样是调用 AI有人生成出来的代码直接能用有人生成的代码各种跑不通。区别主要在提示词。我总结三个最有效的技巧。技巧一是“给足上下文而不是一句指令”。不要只写“帮我写个测试用例”而是把接口文档、返回示例、项目里已存在的封装类都贴进去。AI 的上下文窗口足够大你给的信息越全它生成的结果越贴近你的项目。技巧二是“限制输出格式”。在提示词末尾明确说“只输出 Python 代码不要解释代码风格遵循 PEP8断言使用 common/assert_utils.py 中的工具函数”。这样它就不会给你一堆废话也更容易直接复制运行。技巧三是“迭代式修正而不是一次到位”。AI 生成的第一个版本几乎不可能完美你可以把报错信息直接贴给它让它分析原因并给出修改后的完整代码。这个过程和人与人结对编程很像你可以说“这段代码运行报错KeyError: token请分析原因并修复”。多次迭代下来代码质量会明显提升。5.3 避坑AI 生成代码的安全与准确性最后聊一个我特别想强调的问题AI 生成代码虽然快但不能盲信。至少有三类风险你要留意。第一类风险是“幻觉数据”。AI 可能编造一个不存在的接口路径、字段名、业务码看起来像模像样实际上完全是假的。所以生成代码后的第一步永远是对着真实接口文档或线上接口核对关键字段。我见过有人把 AI 生成的接口地址原封不动提交到代码仓库结果引用了一个根本不存在的下单接口测试环境倒是跑不出问题一上真实环境就全红。第二类风险是“敏感信息泄露”。有些 AI 产品会把你的数据上传到云端。公司内部的接口地址、真实账号、数据库连接串、密钥千万不要随便贴给外部 AI 工具。建议在公司网络环境内使用本地模型或者公司自己部署的大模型服务或者至少对敏感信息做脱敏比如把username: admin改成username: 用户名把 IP 改成占位符再让 AI 分析。第三类风险是“代码质量隐患”。AI 生成的代码可能没有处理超时没有加日志没有做异常捕获接口调用失败时你根本不知道发生了什么。所以我把“打印请求信息和响应信息”作为强制要求写在提示词里哪条用例挂了看日志就能直接定位。还有一个小的建议AI 生成的代码尽量走一次人工 code review 再合入至少要有同事看一眼。我的实践是让 AI 写初稿然后我改 20% 的代码最终质量比我自己完全手写还要好因为 AI 的覆盖范围广而我的修改点在关键业务逻辑上。最后再分享两个实际操作中得到的经验我个人在实际操作中的体验是AI 辅助接口自动化真正节省的是“从空白编辑器开始写代码”的时间而不是“理解业务、设计用例”的时间。如果你本身对接口的业务逻辑一窍不通AI 帮不了你太多但只要你把接口文档、业务规则说清楚AI 就能像团队里一个经验丰富但不太熟悉你项目的新同事一样快速产出高质量的代码初稿。还有一个我最近一直在用的小技巧把过去人工 review 时提出的意见整理成规范文档每次让 AI 生成代码前都先把规范喂给它。比如“项目要求所有用例必须包含日志输出、所有请求必须设置超时、所有断言必须使用统一断言工具”。AI 在遵循明确规范时生成结果比没有规范时稳定得多。坚持用了半个月后我已经基本告别一行行手写测试函数的状态了。接口自动化的代码会变得越来越简单但“简单”背后是我们把脏活累活交给了 AI把判断和决策牢牢握在自己手里。