用TRAE实现AI辅助开发与自动化测试：从项目生成到全链路落地

1. 项目背景与整体设计思路拆解

1.1 为什么选 TRAE 做“开发 + 测试”的全链路实践

先说结论：我最近用 TRAE 完整跑了一个模拟业务系统从创建到测试自动化的小项目，整体感受就四个字——效率恐怖。这个标题里三个关键词其实是一条链路：用 TRAE 创建系统，用 TRAE 生成测试用例，再把测试用例自动化跑起来。它不是三个孤立的事，而是 AI 辅助开发从“能写代码”到“能用代码干活”的一次递进。

先交代一下背景。我手头有个长期维护的项目，业务逻辑不复杂，但接口多、场景杂，最头疼的是每次改完代码都要手动过一遍核心回归用例。过去我试过 Cursor、通义灵码这类 AI 工具，它们补全函数、写胶水代码确实利索，但到了“生成一整套贴合业务的测试用例并自动化执行”这个环节，经常是给的模板很漂亮，落地跑起来各种翻车。TRAE 这次让我改观的地方在于：它能跟我在同一个会话里来回拉扯，我告诉它“这个接口的幂等性怎么处理”，它能顺着我的业务规则去调整生成的测试代码，而不是只给我一段泛泛的 Mock。

这个项目我给它起名叫“模拟订单管理系统 X”。它包含用户登录、商品查询、下单、库存扣减、订单状态流转五个核心模块，后端用 Python FastAPI 重写，前端保持原有 Vue 版本不动。是的，你没看错，用 TRAE 创建系统并不是说让 AI 从零给你变出一整个前后端项目，而是把项目骨架、数据模型、接口逻辑、测试代码全部用对话方式产出，我再做代码审查和少量调整。这套玩法适用于任何想快速搭一个 Demo、或是给老系统补一套自动化测试的人。

1.2 方案选型背后的三个关键决策

很多人问，直接用 pytest 手写测试用例不就完了，为什么要绕 TRAE 一圈？我的回答是：你手写用例的速度，永远赶不上需求变更的速度。在业务系统里，接口字段从add_time改成created_at，或者下单流程里插入一个风控校验，这种变更每隔几天就来一次。每次手动改测试代码，重复劳动不说，还容易漏改断言，导致测试跑出来是绿的，实际上根本没覆盖新逻辑。

第一决策：让 AI 生成基础用例，人工只补业务规则的边界。TRAE 最擅长的是根据接口定义和数据结构生成标准的 CRUD 测试骨架，覆盖正常路径和基础异常路径。但业务规则这东西，比如“下单后 30 分钟内可以取消，超过就不能取消”，AI 从接口签名里是看不出来的，需要我用自然语言告诉它,或者直接在提示词里贴业务文档。所以我的策略是：80% 的重复性用例交给 TRAE 批量产出，20% 的关键业务断言我自己手写并教会 TRAE 理解规则，后续它就能举一反三。

第二决策：测试脚本必须能本地一键执行，而不是依赖 IDE 插件。TRAE 这类 AI 工具生成的代码，最大的坑是环境耦合。它默认你可能在某个 IDE 里点一下就跑，但自动化测试的核心是要在命令行、CI 流水线里无人值守地跑。所以我在项目初期就定了一个规矩：TRAE 生成的所有测试文件，必须用 pytest 格式组织，必须可以在终端用pytest tests/一条命令全部执行，任何需要点击操作去完成的东西都视为不合格。这个约束我直接写进了给 TRAE 的提示词里，效果非常明显。

第三决策：参数化数据用固定 fixture 加边界值集合。自动化测试最耗时间的不是写代码，是准备数据。我用 TRAE 生成了一组 fixtures，包括正常用户、已锁定用户、库存为 0 的商品、超时未支付的订单等等。这些数据集合只要定义一次，所有测试用例都能复用。这样做的好处是，当测试失败时，你可以快速判断是代码 bug 还是数据问题，而不是在几十个用例里一个个找干系。

2. 用 TRAE 从零创建系统：关键提示词设计与代码产出实录

2.1 把需求讲清楚的第一份提示词

创建系统这件事，最忌一上来就说“帮我写一个订单系统”。AI 不是人，它不会猜你的业务边界。我踩过很多次坑之后，总结了一套给 AI 传达需求的模板，核心是四个维度：技术栈、模块清单、数据结构、接口行为约束。下面这份是我提交给 TRAE 的第一份提示词，你可以直接抄作业：

请帮我创建一个订单管理系统的后端项目，要求如下： 1. 技术栈：Python 3.10 + FastAPI + SQLite，ORM 用 SQLAlchemy 2.0。 2. 模块划分：用户模块（注册、登录、查询用户信息）、商品模块（商品列表、商品详情、库存扣减）、订单模块（创建订单、取消订单、查询订单详情、订单状态流转）。 3. 数据模型：用户（id, username, password_hash, status, locked_reason, created_at）；商品（id, name, price, stock, sales, status）；订单（id, order_no, user_id, product_id, quantity, total_price, status, created_at, updated_at）。 4. 接口行为约束： - 创建订单时校验用户状态和商品库存，校验失败返回 400。 - 创建订单成功后自动扣减库存。 - 取消订单仅允许状态为待支付的订单，取消后库存加回。 - 订单状态流转顺序：待支付 -> 已支付 -> 已发货 -> 已完成；任何非法流转返回 400。 5. 输出要求：生成完整可运行的 FastAPI 项目，包括 main.py、models.py、schemas.py、crud.py、routers/ 目录，每个文件有明确的函数注释，不需要生成前端页面。

这份提示词的关键在于“行为约束”这一块。TRAE 是纯语言模型，它看了models.py里的字段列表，能知道数据长什么样，但不知道你的业务规则。你把规则用自然语言列清楚，它生成的接口代码就会自动带上if order.status != '待支付'这类判断。实测下来，第一次生成的代码约 85% 可以直接运行，剩下的 15% 主要是 import 路径错误和 SQLAlchemy 外键声明的写法问题，修一修就通了。

2.2 从对话到可运行代码：实际生成效果与修正记录

TRAE 生成项目时，不是一个文件一次性给你，而是按模块切分的。比如我先让它写models.py，它给出三个类的完整定义，然后我让它写crud.py，它会自动 import 前面生成的模型。这个顺序对我做代码审查特别友好，我可以一块一块确认，而不是等它一次性吐出 1000 行代码再慢慢看。

初次生成完毕后，我注意到crud.py里创建订单的函数，逻辑上是先查库存、再锁行、再减库存。这个顺序在 SQLite 单连接场景下没啥问题，但如果未来切到 PostgreSQL 多并发，就有超卖风险。我在回复里直接对 TRAE 说：“这个创建订单的函数里，把库存扣减改为返回受影响行数，如果行数为零说明商品库存已不足。”它立刻就把代码改成了 SQLAlchemy 的with_for_update()写法，并额外加了一个rowcount == 0的判定分支。这种“语义级修正”正是我坚持用 TRAE 而不是复制粘贴 Stack Overflow 代码的原因。

修正后的创建订单接口逻辑，核心代码长这样（这是代码审查后的最终版）：

@router.post("/orders", response_model=OrderOut) def create_order(order_in: OrderCreate, db: Session = Depends(get_db)): user = db.query(User).filter(User.id == order_in.user_id).with_for_update().first() if not user or user.status != "active": raise HTTPException(status_code=400, detail="用户不存在或已被锁定") product = db.query(Product).filter(Product.id == order_in.product_id).with_for_update().first() if not product or product.stock < order_in.quantity: raise HTTPException(status_code=400, detail="商品不存在或库存不足") order_no = generate_order_no() order = Order( order_no=order_no, user_id=user.id, product_id=product.id, quantity=order_in.quantity, total_price=product.price * order_in.quantity, status="待支付" ) db.add(order) result = db.execute( update(Product) .where(Product.id == product.id, Product.stock >= order_in.quantity) .values(stock=Product.stock - order_in.quantity) ) if result.rowcount == 0: db.rollback() raise HTTPException(status_code=400, detail="库存不足，订单创建失败") db.commit() db.refresh(order) return order

这里有个容易被忽略的细节：db.execute(update(...))的行数检查必须放在db.add(order)之后、db.commit()之前，顺序不能乱。如果先 commit 再检查行数，错误已经落库了。TRAE 第一次生成时就是先 commit 再检查的，被我一问“你想想 rowcount 检查应该在什么时候”，它自己就改对了。这提醒我们，AI 生成的代码必须审逻辑顺序，而不是看语法对不对。

2.3 AI 生成代码的边界与人工审查清单

给 TRAE 提示词的时候，我习惯先明确哪些部分不能让它发挥：

• 密码加密不能用明文存储，必须用 bcrypt 或 passlib，如果 AI 用了 MD5，直接让重写。
• 所有金额计算用 Decimal 而不是 float，避免浮点精度问题。
• GET 接口必须带分页参数，不提供limit和offset的直接改掉。
• 所有对外接口统一返回 JSON 结构{"code": 0, "message": "ok", "data": ...}，错误码为 0 表示成功，非 0 表示业务错误。

这些约束如果写在初始提示词里，TRAE 生成的代码会直接符合你的项目风格，省掉大量 review 返工。如果项目已经写了一半才说，它确实能改，但你人肉检查改了多少地方这个工作量也不小。

人工审查我只看三类问题：安全问题（SQL 拼接、敏感信息泄露）、事务问题（commit/rollback 顺序、分布式事务缺失）、并发问题（超卖、重复提交）。AI 不会主动帮你处理这些，只有你在提示词里点破，或者 code review 时发现，它才会跟着你的方向修正。

注意：用 AI 创建系统时，别把 AI 当架构师。它可以当你的高级码农，但数据一致性方案、事务边界、权限模型这些架构决策还是得人来定。我一般让 AI 先出代码，我再以架构师视角去 review，发现问题再让 AI 改，这个循环非常高效。

3. 借助 TRAE 生成高质量测试用例：从零到 90% 覆盖

3.1 引导 TRAE 理解业务规则的方法

创建完系统只是第一步，真正的重头戏是测试用例生成。这里很多人犯的错误是直接说“帮我写测试”，TRAE 会给你生成一个只测200 OK的空壳测试，断言全是assert response.status_code == 200。这种测试跑了等于没跑。我用的方法是先给 TRAE 一张业务规则表，让它根据规则去生成负例和边界测试。

我给 TRAE 的第二份提示词长这样：

基于以下业务规则，为订单管理系统的订单模块生成 pytest 测试用例。 业务规则： 1. 用户状态为 locked 时，任何下单请求都必须返回 400，提示"用户已被锁定"。 2. 商品库存为 0 时，下单必须返回 400，提示"商品库存不足"。 3. 下单成功后，商品库存必须减少对应数量。 4. 取消订单时，订单状态必须是"待支付"，否则返回 400。 5. 取消订单成功后，商品库存必须增加回对应数量。 6. 订单状态不能从"待支付"直接跳到"已完成"，必须依次流转。 要求： - 使用 pytest + fastapi.testclient - 每个规则至少 2 个测试用例：一个正常路径，一个边界路径 - 测试数据用 fixture 方式定义在 conftest.py 中 - 断言必须包含业务错误码提示文案的具体值，比如 {"code": 20001}

关键在最后一条。很多 AI 生成的测试断言只检查状态码，不检查业务错误码和提示文案长度。真实业务里，状态码一样但错误码不同意味着完全不同的失败原因。把错误码写进断言要求后，TRAE 生成的测试从“有没有报错”升级到了“报错是否符合预期业务语义”，这直接决定测试能不能在回归时帮我们定位问题。

3.2 一组覆盖核心业务的测试用例样例

TRAE 生成的测试代码，去掉多余的注释后大概是这样：

def test_create_order_success(client, auth_headers, db_session): user = create_test_user(db_session, status="active") product = create_test_product(db_session, stock=10) payload = {"user_id": user.id, "product_id": product.id, "quantity": 2} resp = client.post("/api/orders", json=payload, headers=auth_headers) assert resp.status_code == 200 data = resp.json()["data"] assert data["status"] == "待支付" assert data["total_price"] == product.price * 2 refresh_product = db_session.query(Product).filter(Product.id == product.id).first() assert refresh_product.stock == 8 def test_create_order_insufficient_stock(client, auth_headers, db_session): user = create_test_user(db_session, status="active") product = create_test_product(db_session, stock=1) payload = {"user_id": user.id, "product_id": product.id, "quantity": 3} resp = client.post("/api/orders", json=payload, headers=auth_headers) assert resp.status_code == 400 assert resp.json()["message"] == "商品库存不足" # 关键：验证失败时库存没有被扣减 refresh_product = db_session.query(Product).filter(Product.id == product.id).first() assert refresh_product.stock == 1

这两个用例一正一反，把“成功扣库存”和“失败不动库存”都覆盖到了。落在测试里最值钱的断言往往是这句assert refresh_product.stock == 1，它验证的是接口的事务性——失败时不能留下脏数据。如果你用 AI 生成测试，务必在提示词里加一句：“所有失败路径的用例，都要验证数据没有被部分修改”。这句话是提升测试质量最有效的一味药。

3.3 用参数化把冗余用例压缩干净

翻完 TRAE 生成的测试，我做的第一件事是把 6 条规则拆成参数化用例，而不是让它生成 12 个重复函数。参数化是 pytest 的灵魂，也是给 AI 提需求时必须讲清楚的约束。我对 TRAE 说：“把这四个异常的测试都改成 pytest.mark.parametrize，四个场景一个函数。”它生成的代码长这样：

@pytest.mark.parametrize( "prepare_func, expect_message", [ (prepare_locked_user, "用户已被锁定"), (prepare_out_of_stock, "商品库存不足"), (prepare_invalid_product, "商品不存在"), (prepare_exceed_stock, "商品库存不足"), ], ids=["locked-user", "out-of-stock", "invalid-product", "exceed-stock"] ) def test_create_order_various_failures(client, auth_headers, db_session, prepare_func, expect_message): req_payload = prepare_func(db_session) resp = client.post("/api/orders", json=req_payload, headers=auth_headers) assert resp.status_code == 400 assert resp.json()["message"] == expect_message

这样做的收益是肉眼可见的：测试报告里失败用例能通过 parametrize 的 id 直接定位到具体场景（比如test_create_order_various_failures[locked-user]），而不是靠一堆堆栈日志猜是哪条数据出了问题。

3.4 覆盖率到底有没有 90%

TRAE 生成的用例全部接上后，我跑了句pytest --cov --cov-report=term-missing，结果算是符合预期：代码行覆盖率 91%，分支覆盖率 84%。没覆盖到的主要是crud.py里生成订单号时的一个异常分支和用户模块的locked_reason更新接口。

覆盖率不是越高越好，但低于 80% 你要警惕。91% 意味着核心业务逻辑基本全部跑过，剩下的 9% 多是防御性代码和极少触发的异常分支，可以接受。如果你发现覆盖率卡在 70% 上不去，别急着硬补用例，先去看看是不是有很多接口压根没有被测到，大概率是你的 conftest 里 fixture 没初始化好，导致所有测试都在同一份脏数据上跑。

4. 测试用例自动化落地：从单测到可执行流水线

4.1 测试目录结构与 pytest 配置

写了测试用例，下一步是让它自动化跑起来，而不是在 IDE 里点一下玩完。我的项目测试目录长这样：

tests/ ├── conftest.py # 全局 fixture：测试数据库、client、认证头 ├── test_users.py # 用户模块（登录、注册、锁定） ├── test_products.py # 商品模块（列表、详情、库存） ├── test_orders.py # 订单模块（创建、取消、状态流转） ├── test_stock.py # 库存一致性测试（并发下单） └── data/ ├── factories.py # 测试数据工厂 └── fixtures.json # 固定参数数据集

conftest.py是让测试能一键执行的关键。TRAE 生成的 fixture，默认会去连本地开发数据库，这在自动化环境里就是个坑。我的 conftest 固定写法是用一个内存级临时数据库，每个用例跑完自动回滚：

@pytest.fixture def db_session(): engine = create_engine("sqlite://", connect_args={"check_same_thread": False}) TestingSessionLocal = sessionmaker(bind=engine) Base.metadata.create_all(bind=engine) session = TestingSessionLocal() yield session session.rollback() session.close() Base.metadata.drop_all(bind=engine)

sqlite://是内存库，跑完即焚，不需要手工清理数据。代价是每次测试前都要重建表，速度稍慢。对于 60 个用例的规模，整体跑下来大概 12 秒，完全可接受。如果你追求更快，可以把内存库的建表动作只做一次，用事务回滚来保证隔离性，但那是性能优化阶段的事，初期用内存库最简单可靠。A同学要是问我自动化测试第一步做什么，我一定说：把 conftest 从“连本地库”改成“内存库”，这一步做完，自动化才可能无人值守地跑。

4.2 批量执行与覆盖率统计的标准命令

执行层我用的是 pytest 自带能力加两个插件：pytest-html出报告、pytest-cov出覆盖率。命令固定在 Makefile 里：

test: python -m pytest tests/ -v --tb=short --disable-warnings --html=report.html --self-contained-html --cov=app --cov-report=term-missing --cov-report=html

拆解一下每个参数的意义：

• -v：输出每个用例的测试结果，方便看哪个用例挂在哪。
• --tb=short：失败时堆栈只保留最短的两行，快速定位是断言失败还是代码异常。
• --disable-warnings：把第三方库的警告全部关掉，避免报告里全是无用噪音。
• --html=report.html：生成漂亮的可视化报告，每次跑完直接浏览器打开看。
• --cov=app --cov-report=term-missing：终端里直接列出哪些行没被覆盖到，比看整份报告快。

这里有一个坑：如果你直接用pytest tests/，它默认只跑匹配test_*.py或*_test.py的文件。TRAE 生成的测试文件如果不小心命名成unittest_orders.py，pytest 会直接跳过。我遇到过 trae 把文件命名成test_orders_and_products.py，没问题，但有一次它命名成orders_check.py，跑的时候完全没报错也没跑用例，排查了好久才发现是文件名不匹配。所以跑之前先执行pytest --collect-only -q看看收集了多少用例，如果数量明显少，先查文件名。

4.3 接入自动化流水线的步骤与临时屏蔽机制

有了本地一键执行，接入流水线就是水到渠成的事。我的做法是在代码仓库里加一个.github/workflows/test.yml（或任意你用的 CI 平台，通用语法都差不多）：

name: Run Tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Set up Python uses: actions/setup-python@v5 with: python-version: "3.10" - name: Install dependencies run: | pip install -r requirements.txt pip install pytest pytest-cov httpx - name: Run tests run: | python -m pytest tests/ -v --tb=short --disable-warnings

这段配置里有三个关键点值得注意：

1. 依赖安装要快准狠：不要用pip install -e . -q去装一整套开发依赖，直接指定测试所需的最小安装集，装得少出错少。
2. 不要跟真实数据库纠缠：流水线里跑测试，必须依赖sqlite://内存库，因为流水线环境里没有你本地的 MySQL。如果业务代码依赖 MySQL 特定函数，请加一个独立的测试数据库适配层，或者在 CI 环境里起一个 MySQL 容器。
3. 失败行为要明确：流水线上跑的是pytest返回码。任何用例失败，pytest 都会返回非 0 退出码，CI 平台会把 Job 标红。所以不需要写额外的逻辑判断测试是否通过，只要保证 pytest 是最后一条执行的命令即可。

接入流水线之后的收益是：我和团队每次提交代码，凡是有 PR/push 都会自动跑全量测试。某一周我发现测试在两天内挂了 12 次，其中 9 次是真实 bug（比如用户锁定逻辑的status字段传错枚举值），3 次是测试数据没清理干净导致的假失败。这个比例的教训是：AI 生成的代码，你改起来也快，但千万别在测试挂红时慌，先看失败用例的名字，90% 能直接判断是代码问题还是测试环境问题。

同时也要说一下带隔离的屏蔽机制：如果某条用例因为环境原因暂时无法修好（比如下游接口没部署），不要用@pytest.mark.skip去注释掉整段逻辑，而是用@pytest.mark.xfail(reason="已知问题，排队修复中")标记。这样测试报告里能清晰看到“预期失败”，而不是绿油油的一片假装一切都很稳。

5. 常见问题与排查技巧实录

5.1 TRAE 生成测试用例时的典型失败模式

我用 TRAE 生成了六轮测试用例，前两轮都有明显的质量问题。我把最常见的失败模式整理成了表格，方便你对照排查：

第三行“断言过强”是我重点想说的。TRAE 生成测试时，它在断言里写assert resp.json()["data"]["order_no"] == "202503121030001234"，这种断言第一次跑必挂，因为订单号是运行时生成的，你根本不知道 AI 会拿什么逻辑去生成预期值。正确的做法是让 AI 用正则或字符串长度校验：assert re.fullmatch(r"\d{20}", resp.json()["data"]["order_no"])。这个规则你必须在提示词里讲清楚，否则每次重新生成都会出同样的问题。

5.2 如何调教 TRAE 生成更可靠的测试代码

我在实际项目里掌握了一个“反馈-修正-沉淀”的调教方法，跟 TRAE 对话不是一次性的，需要来回迭代：

第一步，让它生成；第二步，跑一遍，把失败信息原封不动贴回它的会话里，问一句“这个用例为什么挂了，请给修复方案”；第三步，它给出修复后，再让它把所有同类问题的一次性掉。这个循环迭代三轮以上，它会慢慢摸清你项目的断言风格和数据构造习惯。

有个典型的例子：test_create_order_success第一次跑挂了，报错KeyError: 'data'。我把完整的 traceback 贴给 TRAE，它看了一眼说，是响应格式化层的问题，应该是{"code":0,"message":"ok","data": ...}的结构，但 fixture 里没有数据初始化。它给了两处修改：conftest 里加create_test_product的默认库存参数，断言里改用resp.json()["data"]["total_price"]。修完再跑，整个测试类全绿。

调教的关键点在于：不要只给 AI 一句“这段代码有问题”。你要把 traceback、失败断言、期望行为全贴进去。AI 是大语言模型，纯问题描述它只能猜，但你给它完整证据链，它就能把问题归因得八九不离十。实测下来，带 traceback 的修复准确率比不带的高 3 倍以上。

5.3 自动化测试稳定性问题的实战排查

自动化跑起来之后，稳定性成了新问题。我总结了三个最常见的不稳定源，也是你大概率会撞上的：

不稳定源一：测试数据相互干扰。某条用例在 CI 跑挂了，但本地重跑完全正常。第一反应别去改代码，去看 conftest 里是否有跨模块共享的 fixture。我的坑是用了同一个内存数据库，但没做事务回滚，test_stock.py里创建了一个库存为 0 的商品，test_orders.py的某些用例又恰好查询同一个商品名，直接爆ProductStockError。修复方案是确保 fixture 在每个用例开始前重建数据，或者给不同模块用不同的测试库标识。

不稳定源二：外部依赖接口缓慢或不可用。TRAE 生成的测试里有一个用requests.get("https://example.com/")检查网络连通性的用例，跑流水线时这个请求超时了 10 秒，导致全量测试从 12 秒变成 45 秒。这种测试就不该出现在单元测试层，直接删掉。任何外部依赖应该用 Mock 替代，或者把超时时间缩短到 2 秒并跳过失败，否则自动化测试慢到没人愿意看测试报告那就废了。

不稳定源三：随机数据生成导致偶发失败。我让 TRAE 用factory_boy生成用户名和手机号，它有概率生成重复数据。当一批用例并行跑时，常出现“注册用户时用户名已存在”的偶发失败。解决方案是给每个 fixture 加一个唯一后缀，比如fake.user_name() + str(uuid.uuid4())[:8]。这个改动很小，但它去掉了所有随机干扰，测试的可重复性立刻提升一个档次。

5.4 测试报告的几个阅读技巧

看测试报告不是只看红绿。我个人的习惯是先看失败用例的断言行，再看覆盖率报告里Missing列。很多失败的断言会告诉你一个业务语义上的差距，而不只是代码缺陷。比如有一次测试挂了，断言是assert resp.json()["message"] == "用户已被锁定"，实际返回是"用户被锁定"。这不是代码 bug，是前后端文案不一致。测试帮我们抓到了这个问题，你改不了 API 文案，就要改测试期望值，并同步给前端团队。

另外，覆盖率报告的Missing列会精确到行号。所有未覆盖的代码行，逐行看一遍，能发现不少 AI 生成的防御代码其实没有被任何用例触达。这时你可以选择补一个针对它的负例测试，也可以选择把这些防御代码删掉。我的建议是先确认业务是否真的需要这段防御逻辑，如果从代码上下文看是永远不会执行的死分支，直接删掉比硬补测试强，毕竟死代码本身也是技术债。

6. 从这次实践中沉淀的经验与延伸空间

最后聊点心得体会。我个人在这套流程里最深的感触是：AI 工具在测试自动化的价值，不在于替你写测试，而在于帮你把“想清楚要测什么”这件事放大。以前我写用例，50% 时间在敲语法和查 API 文档，真正思考业务逻辑的时间被切得很碎。现在我把“想清楚”的环节拆成给 TRAE 的提示词，它负责把想清楚的规则变成代码，我反而能花更多时间在边界推演和异常流的复盘上。

比如我发现，一旦你在提示词里写了“库存扣减失败必须回滚”，TRAE 会生成测试用例去验证那个回滚分支。它不会漏掉这个点，而人写用例时特别容易顺着主流程一路绿到底，然后忘了验证失败分支的数据完整性。这就是 AI 辅助开发最有价值的模式：人给意图，AI 补全细节，人再做复审。

这套流程后续还有很大的扩展空间。我现在做的这个模拟订单系统 X 已经跑通了，接下来我计划把相同的模式应用到三个更偏业务的模块上：一个带定时任务的通知服务、一个对接第三方支付回调的接口、还有一个报表聚合系统。报表聚合系统的测试难点在于数据量大、逻辑嵌套深，这正是 AI 生成测试用例最头疼的场景，我打算用“先给 TRAE 一份报表计算规则文档，再让它按规则拆分验证点”的方式来试。如果效果好，我再单独写一篇经验分享。

还有一个特别实用的小技巧分享给所有实践者：每次给 TRAE 展示一个测试失败案例后，顺手问一句“这个失败暴露了我们测试设计上的哪些盲区”，它有时会给出很有价值的反馈，比如“你的测试没有覆盖数据库唯一约束冲突”这种提醒。这些来自 AI 的元思考，反过来会推动你把测试设计提升一个层次。

如果你只是想让项目更快跑起来，直接抄我这篇文章里的提示词和 conftest 模板即可。但如果你想在这个基础上积累一套真正属于自己团队的自动化测试资产，建议把每一次 AI 交互中修正过的代码、踩过坑的断言语义、以及让测试稳定的 fixture 规则全部沉淀成团队文档，这个文档的可复用价值，比单次生成的测试代码高得多。