1. 项目概述当测试驱动遇上智能体生成最近在AI工程化领域一个名为TAG的轻量级框架开始引起不少开发者的讨论。它的全称是“Test-Driven Agentic Artifact Generation”直译过来就是“测试驱动的智能体工件生成框架”。这名字听起来有点拗口但拆解一下核心概念就清晰了它试图用写测试用例的方式来驱动和约束AI智能体Agent去生成我们想要的“工件”Artifact。这里的“工件”可以是一段代码、一份文档、一个配置脚本甚至是更复杂的业务流程设计图。我最初接触这个想法是因为在团队内部尝试用大语言模型LLM生成代码时遇到的老大难问题生成结果的不确定性。你让模型写一个函数它可能这次写得完美下次就漏了异常处理或者用了过时的API。传统的提示工程Prompt Engineering像是在“祈祷”调整措辞、增加示例希望模型能“理解”你的意图。而TAG框架引入的“测试驱动”思维则是一种更工程化的“契约”思维我先定义好这个工件必须通过哪些测试即满足什么标准然后让智能体去尝试生成直到产出的结果能通过所有测试为止。这就像你先写好单元测试再让一个不知疲倦的、知识渊博的“实习生”智能体去反复尝试实现功能直到测试全部变绿。这个框架的目标用户很明确任何需要频繁、可靠地由AI生成结构化产出的开发者、测试工程师或技术写作者。比如你需要批量生成符合公司规范的API客户端代码或者为一系列数据模型自动生成数据库迁移脚本和对应的CRUD接口。TAG不是要替代你的创造性工作而是要把那些重复、模板化但又容易出错的生成任务变得可预测、可验证。2. 核心理念与架构设计拆解2.1 为什么是“测试驱动”测试驱动开发TDD的理念是“红-绿-重构”先写一个失败的测试再写最少代码使其通过最后优化代码结构。TAG框架巧妙地将这一理念移植到了AI生成领域。其背后的逻辑是对于AI生成的内容我们往往难以用精确的指令描述所有细节要求但我们可以相对容易地定义出一组“验收标准”。这些标准以自动化测试的形式存在成为了衡量生成物质量的客观标尺。传统的AI生成流程是线性的输入提示Prompt - 模型生成 - 人工审查。审查环节耗时费力且依赖人的主观判断。TAG框架将其改造成了一个循环反馈系统定义测试 - 生成候选 - 执行测试 - 评估结果 - 如失败基于反馈调整或重新生成。这个循环的核心价值在于将模糊的质量要求转化为了可自动执行的、二元的通过/失败判断。智能体不再是被动地执行一次提示而是成为了一个在测试约束空间内主动寻找可行解的“问题解决者”。2.2 “轻量级”体现在何处市面上已经有一些复杂的AI应用编排框架如LangChain、LlamaIndex它们功能强大但学习曲线陡峭有时显得“重”。TAG框架的“轻量级”设计哲学体现在几个方面职责单一它不试图成为一个全功能的AI应用开发平台而是聚焦于“测试驱动生成”这一个核心工作流。它不内置向量数据库、不管理复杂的记忆流它的核心就是一个“生成-测试”循环引擎。依赖最小化框架本身对特定的大模型供应商、测试框架保持中立。它定义了一套清晰的接口你可以接入OpenAI的GPT、Anthropic的Claude或是本地的开源模型同样测试部分可以用pytest、unittest甚至是自定义的简单Python函数。这种设计让集成到现有项目变得非常容易。配置即代码整个生成任务称为一个“TAG任务”可以通过一个结构化的配置文件如YAML或JSON来定义。这个文件描述了目标工件是什么、使用什么模型、有哪些测试用例、失败后如何调整策略等。这种声明式的配置方式使得生成流程可版本化、可重复执行。2.3 核心组件交互逻辑一个典型的TAG框架内部可以抽象出四个核心组件它们协同工作构成了完整的生成流水线。Artifact Spec工件规格这是生成任务的蓝图。它不仅仅是一个简单的提示词而是一个结构化的描述可能包括目标描述用自然语言说明要生成什么例如“生成一个FastAPI的GET端点用于根据ID查询用户信息”。上下文信息提供必要的背景如相关的数据结构User模型的Pydantic定义、项目依赖等。约束条件非功能要求如“代码必须兼容Python 3.8”、“不能使用已弃用的库”。Test Suite测试套件这是质量守门员。一套与工件规格绑定的、可自动执行的测试集合。测试可以是单元测试针对生成代码的函数级测试。集成测试检查生成代码是否能与现有代码库正确编译或交互。静态分析用linter如flake8, pylint检查代码风格和潜在错误。自定义验证器一个简单的Python函数检查生成文档是否包含特定章节或配置文件的格式是否正确。Agentic Generator智能体生成器这是执行引擎。它接收工件规格和可选的历史反馈调用底层的大语言模型来生成候选工件。它的“智能体”特性体现在当测试失败时它并非简单地重试而是能够接收测试失败的错误信息或输出将其作为新一轮生成的“反馈”融入提示中引导模型进行针对性修正。这模拟了一个开发者根据测试错误调试代码的过程。Orchestrator编排器这是大脑。它控制整个“生成-测试”循环的流程初始化任务加载规格和测试。调用生成器产生第一个候选版本。在隔离环境如临时目录、沙箱中执行测试套件。分析测试结果。如果全部通过则返回成功的工件如果失败则提取失败信息决定下一步策略例如直接让生成器基于错误反馈重试、调整生成参数、或者触发更复杂的修复逻辑。管理重试次数和超时防止无限循环。这个架构的美妙之处在于它的清晰和可扩展性。每个组件都有明确的接口你可以替换其中的任何部分。例如你可以为生成器接入一个更强大的模型或者为测试套件增加更严格的安全扫描。3. 实战演练从零构建一个TAG任务纸上谈兵终觉浅我们通过一个具体的例子来看看如何用TAG框架解决一个实际问题。假设我们经常需要为不同的数据模型如Product,Order生成对应的RESTful API服务层代码。手动编写虽然不难但重复且容易在命名规范、错误处理上不一致。我们的目标是输入一个Pydantic模型定义自动生成包含CRUD端点、符合项目规范的FastAPI路由器代码。3.1 环境准备与框架安装首先由于TAG是一个相对新颖的概念你可能需要从开源仓库克隆或通过包管理器安装其实现。这里我们假设有一个名为tag-framework的Python包。# 假设通过pip安装 pip install tag-framework # 或者从源码安装 git clone TAG项目仓库地址 cd tag-framework pip install -e .接下来创建一个新的项目目录结构如下my_tag_project/ ├── config/ # 存放TAG任务配置文件 ├── artifacts/ # 成功生成的工件会存放 here ├── tests/ # 存放针对生成工件的测试用例 └── run_task.py # 主运行脚本3.2 定义工件规格Artifact Spec我们在config/product_api.yaml中定义第一个生成任务。# config/product_api.yaml artifact_spec: name: product_fastapi_router description: 为Product模型生成一个完整的FastAPI路由器文件包含增删改查端点。 context: # 提供模型定义这是生成代码的关键上下文 model_definition: | from pydantic import BaseModel from typing import Optional from datetime import datetime class Product(BaseModel): id: Optional[int] None name: str description: Optional[str] None price: float stock: int created_at: Optional[datetime] None # 提供项目规范示例 coding_standard: 使用snake_case命名变量和函数。使用类型注解。异常处理使用HTTPException。依赖注入使用Depends。 constraints: - 必须使用FastAPI和Pydantic。 - 代码必须通过mypy静态类型检查忽略缺失的导入。 - 需要包含以下端点GET /products, GET /products/{id}, POST /products, PUT /products/{id}, DELETE /products/{id}。 - POST和PUT端点必须验证输入数据。 - 使用异步SQLAlchemy假设进行数据库操作但生成时用伪代码注释代替具体连接逻辑。这个规格文件清晰地描述了“我们要什么”并且提供了生成所需的全部背景知识。3.3 构建测试套件Test Suite测试是TAG的灵魂。我们为这个生成任务编写一个测试文件tests/test_product_router.py。注意这些测试是在生成之后用于验证生成的代码是否合格。# tests/test_product_router.py import sys import os import tempfile import subprocess from pathlib import Path # 这是一个自定义验证器将被TAG框架调用 def validate_generated_router(router_code: str, spec: dict) - dict: 验证生成的router代码。 返回一个结果字典例如{passed: False, message: 错误信息} 或 {passed: True} results {all_passed: True, details: []} # 测试1语法检查 with tempfile.NamedTemporaryFile(modew, suffix.py, deleteFalse) as f: f.write(router_code) temp_file f.name try: # 使用python -m py_compile进行语法检查 result subprocess.run([sys.executable, -m, py_compile, temp_file], capture_outputTrue, textTrue) if result.returncode ! 0: results[all_passed] False results[details].append({test: syntax, passed: False, error: result.stderr}) else: results[details].append({test: syntax, passed: True}) finally: os.unlink(temp_file) # 测试2关键端点名称检查简单示例 required_endpoints [/products, /products/{id}] for endpoint in required_endpoints: if frouter.get({endpoint}) not in router_code and frouter.post({endpoint}) not in router_code: # 简化检查实际应更严谨 results[all_passed] False results[details].append({test: fendpoint_{endpoint}, passed: False, error: fMissing endpoint: {endpoint}}) else: results[details].append({test: fendpoint_{endpoint}, passed: True}) # 测试3是否包含必要的导入FastAPI, APIRouter, HTTPException等 required_imports [FastAPI, APIRouter, HTTPException, Depends] for imp in required_imports: if imp in router_code: results[details].append({test: fimport_{imp}, passed: True}) else: # 对于Depends可能以from fastapi import Depends形式存在这里做简单检查 if Depends not in router_code: results[all_passed] False results[details].append({test: fimport_{imp}, passed: False, error: fMissing import related to: {imp}}) return results这个测试套件包含了语法检查、功能点验证和基础规范检查。在实际项目中你可能会集成更强大的工具比如用ast模块进行抽象语法树分析或者用pytest直接导入生成的模块进行更真实的单元测试。3.4 配置与运行生成任务现在我们需要一个主脚本来粘合一切。创建run_task.py。# run_task.py import yaml import asyncio from tag_framework import Orchestrator, OpenAIGenerator, LocalTestExecutor # 假设框架提供了这些类 async def main(): # 1. 加载工件规格 with open(config/product_api.yaml, r) as f: config yaml.safe_load(f) artifact_spec config[artifact_spec] # 2. 初始化生成器这里以OpenAI为例 # 你需要设置你的OPENAI_API_KEY环境变量 generator OpenAIGenerator( modelgpt-4, system_prompt你是一个资深的Python后端开发者擅长编写高质量、符合规范的FastAPI代码。请根据用户提供的规格和上下文生成代码。 ) # 3. 初始化测试执行器 # 这里使用我们自定义的验证函数框架应能调用它 test_executor LocalTestExecutor( validation_functiontests.test_product_router.validate_generated_router ) # 4. 创建编排器 orchestrator Orchestrator( generatorgenerator, test_executortest_executor, max_retries3, # 最大重试次数 retry_delay1.0 # 重试间隔秒 ) # 5. 运行任务 print(开始执行TAG任务...) result await orchestrator.run(artifact_spec) # 6. 处理结果 if result.success: print(✅ 生成成功) print(f生成内容预览\n{result.artifact[:500]}...) # 打印前500字符 # 保存生成的工件 with open(artifacts/product_router.py, w) as f: f.write(result.artifact) print(工件已保存至 artifacts/product_router.py) print(f总共尝试了 {result.attempts} 次。) else: print(❌ 生成失败。) print(f最后一次错误{result.last_error}) print(f测试失败详情{result.test_failures}) if __name__ __main__: asyncio.run(main())运行这个脚本TAG框架就会开始工作。它会先让GPT-4根据我们的规格生成第一版代码然后调用我们的测试函数进行验证。如果测试失败比如漏了某个端点编排器会把错误信息反馈给生成器生成器会调整提示例如“上一版代码缺少对/products/{id}端点的实现请修正。”然后产生第二版代码。如此循环直到通过所有测试或达到最大重试次数。3.5 一次可能的生成结果经过一轮或几轮迭代后我们可能在artifacts/product_router.py中得到如下代码from fastapi import APIRouter, Depends, HTTPException, status from pydantic import BaseModel from typing import List, Optional from datetime import datetime # 假设的数据库依赖层实际项目中需要具体实现 from .database import get_db, AsyncSession from . import models # 假设Product SQLAlchemy模型已定义 router APIRouter(prefix/products, tags[products]) # 使用Pydantic模型定义请求/响应体 class ProductCreate(BaseModel): name: str description: Optional[str] None price: float stock: int class ProductResponse(ProductCreate): id: int created_at: datetime class Config: from_attributes True router.get(/, response_modelList[ProductResponse]) async def list_products( skip: int 0, limit: int 100, db: AsyncSession Depends(get_db) ): 获取产品列表。 # 伪代码实际应从数据库查询 # products await db.execute(select(models.Product).offset(skip).limit(limit)) # return products.scalars().all() return [] # 占位符 router.get(/{product_id}, response_modelProductResponse) async def get_product( product_id: int, db: AsyncSession Depends(get_db) ): 根据ID获取单个产品。 # 伪代码 # product await db.get(models.Product, product_id) # if product is None: # raise HTTPException(status_code404, detailProduct not found) # return product raise HTTPException(status_code404, detailProduct not found) # 占位符 router.post(/, response_modelProductResponse, status_codestatus.HTTP_201_CREATED) async def create_product( product_in: ProductCreate, db: AsyncSession Depends(get_db) ): 创建新产品。 # 伪代码数据验证和保存 # db_product models.Product(**product_in.dict()) # db.add(db_product) # await db.commit() # await db.refresh(db_product) # return db_product return ProductResponse(id1, created_atdatetime.now(), **product_in.dict()) # 占位符 # ... 省略PUT和DELETE端点实现可以看到生成的代码结构清晰包含了所有要求的端点使用了正确的FastAPI装饰器和依赖注入并且按照我们的约束使用了伪代码注释来替代具体的数据库操作。它通过了我们之前定义的语法检查、端点检查和导入检查。4. 深入核心智能体如何与测试反馈协同工作TAG框架最精妙的部分在于“智能体”Agentic与“测试驱动”Test-Driven的闭环。这不仅仅是“生成-检查-再生成”的简单循环而是一个有学习能力的反馈系统。4.1 反馈信息的结构化当测试失败时框架不能仅仅告诉模型“失败了”。它需要提供结构化、可操作的反馈。在我们的例子中自定义验证器返回的results[details]列表就是结构化的反馈。编排器会将这些信息提炼成给生成器的提示。例如初始提示“请根据提供的Product模型定义生成FastAPI路由器代码...”第一次生成后测试失败测试endpoint_/products/{id}未通过。第二次生成提示“请根据提供的Product模型定义生成FastAPI路由器代码。注意上一轮生成的代码缺少对GET /products/{product_id}端点的实现。请确保包含该端点。”更高级的框架实现可能会解析单元测试的堆栈跟踪Traceback提取出具体的错误行号和错误信息如AttributeError: NoneType object has no attribute name并将这些精准的信息反馈给模型引导其进行针对性修复。4.2 生成策略与重试机制编排器需要智能地管理重试过程。简单的“失败就重试”可能导致无限循环或陷入局部最优。TAG框架可能包含以下策略增量修正在后续提示中不仅包含原始规格和最新错误还附加上一轮生成的代码让模型在原有基础上修改。这通常比每次都从头生成更有效。提示升温如果连续失败可以逐步增加提示的“温度”Temperature参数让模型产生更多样化的输出以跳出当前的错误模式。规格分解对于复杂的生成任务如果整体失败编排器可以尝试将任务分解成多个子任务如先生成模型再生成CRUD端点逐个击破。备用模型回退如果主模型如GPT-4多次失败可以切换到备用模型如Claude或本地模型尝试不同的生成风格。4.3 测试的层次与成本在TAG流程中测试的执行是有成本的时间、API调用次数。因此设计一个分层测试策略至关重要快速静态检查低成本最先执行如语法检查、导入检查、关键词匹配。这些测试能快速过滤掉明显不合格的生成物。功能逻辑测试中成本随后执行如运行单元测试、检查生成的函数是否被正确定义。这可能需要在一个轻量级的隔离环境中执行代码。集成与运行测试高成本最后执行如将生成的模块导入真实项目环境、运行端到端测试。这类测试成本高通常只在快速检查通过后用于最终验证。一个好的TAG任务配置会按照这个顺序组织测试套件以最小的成本尽快淘汰不良候选将宝贵的重试机会留给最有希望的生成结果。5. 高级应用场景与模式扩展理解了基础原理后TAG框架的潜力远不止生成API代码。它的范式可以应用到任何需要高质量、结构化输出的AI生成任务中。5.1 场景一自动化文档生成问题为代码库生成或更新API文档如OpenAPI Spec但手动维护容易过时。TAG解决方案工件规格目标是根据当前代码的AST抽象语法树和已有的部分文档生成完整的openapi.yaml文件。测试套件验证生成的YAML语法正确。使用prance或openapi-spec-validator库验证是否符合OpenAPI 3.0规范。确保文档中提到的每个API路径都在实际代码中存在反向检查。检查必填字段如info.title,info.version是否齐全。智能体模型需要理解代码结构和OpenAPI规范的复杂关系。反馈循环可以纠正诸如数据类型映射错误、缺少参数描述等问题。5.2 场景二配置代码与基础设施即代码IaC生成问题为不同的微服务生成Kubernetes部署配置Deployment, Service, Ingress要求符合公司的安全策略和资源规范。TAG解决方案工件规格输入服务名称、镜像地址、端口、资源需求CPU/内存生成一套K8s YAML文件。测试套件使用kubeval或kubeconform验证YAML语法和K8s模式合规性。自定义检查确保没有使用latest标签、必须设置资源限制limits/requests、必须包含探针liveness/readiness配置等。可以运行kubectl apply --dry-runclient进行预演验证。智能体模型需要掌握K8s配置的最佳实践。测试反馈可以确保生成的配置不仅是语法正确更是生产就绪的。5.3 场景三测试用例本身生成问题为已有的复杂业务函数编写全面的单元测试用例费时费力。TAG解决方案工件规格输入函数的源代码及其签名生成对应的pytest单元测试文件。测试套件生成的测试文件本身必须语法正确。运行生成的测试它们必须能够成功导入被测函数。生成的测试用例执行时其断言assert必须全部通过。这里形成了一个有趣的“自举”用测试来验证生成的测试是否有效。可以计算测试覆盖率如使用coverage.py要求生成的测试达到一定的行覆盖率或分支覆盖率阈值。智能体模型需要理解代码逻辑并推断出各种边界条件。反馈循环可以补充遗漏的测试用例或修正错误的断言。5.4 模式扩展多智能体协作对于极其复杂的工件可以引入多智能体协作模式。例如生成一个完整的微服务代码库架构师智能体根据需求生成一个高层次的设计文档工件1。API智能体基于设计文档生成OpenAPI规范工件2。测试套件验证其与设计文档的一致性。后端智能体基于OpenAPI规范生成FastAPI服务器代码工件3。测试套件验证其符合OpenAPI规范。前端智能体基于同一个OpenAPI规范生成React/Vue客户端代码工件4。每个阶段都是一个独立的TAG任务上游任务的输出成为下游任务的输入和上下文。整个流程可以串联或并联执行形成一个强大的AI辅助开发流水线。6. 避坑指南与最佳实践在实际使用TAG模式或类似框架时我踩过不少坑也总结出一些让流程更顺畅的经验。6.1 测试设计是成败关键最大的误区认为测试只是最后的把关者。在TAG中测试是引导生成方向的导航仪。测试要原子化、快速一个测试最好只验证一件事。避免编写冗长、缓慢的集成测试作为第一道关卡这会严重拖慢迭代速度。优先使用静态分析、模式匹配等轻量级检查。提供清晰的失败信息测试失败时输出的错误信息要尽可能清晰、具体能被模型理解。避免AssertionError: False is not True这种信息而是生成的函数缺少对输入参数age的类型注解。从简到繁分层验证如前所述建立测试金字塔。先过语法关再过功能关最后过集成关。6.2 提示工程与规格编写上下文不是越多越好给模型的上下文如artifact_spec.context要精准相关。无关的代码或文档会成为噪声干扰模型判断。只提供生成当前工件所必需的信息。将约束明确写入规格不要指望模型能猜出你的潜规则。像“代码必须用Black格式化”、“所有字符串必须使用双引号”这类风格要求应明确写在constraints里。更好的做法是让一个格式化测试如调用black --check来强制执行。使用系统提示System Prompt塑造角色在初始化生成器时一个强大的系统提示能极大提升输出质量。例如“你是一个严谨的、注重细节的软件架构师擅长编写可维护、符合最佳实践的代码。你会严格遵循用户给出的所有约束。”6.3 成本与性能优化设置合理的重试上限和超时对于简单任务max_retries3可能足够对于复杂任务可能需要5-8次。同时设置总超时防止任务卡死。缓存测试结果如果测试执行成本高如启动一个数据库可以考虑缓存成功通过的生成物及其哈希值。当遇到相同或相似的规格时可以直接返回缓存结果节省资源和时间。考虑使用更便宜的模型进行初筛可以用GPT-3.5-turbo进行前几轮快速生成和简单测试只有通过初筛的候选才用更强大也更贵的GPT-4进行精修和复杂测试。6.4 集成到CI/CD流水线TAG框架的产出是代码或配置自然应该纳入版本控制和CI/CD流程。生成即代码将成功的工件保存到代码仓库中和手写代码一样进行代码审查Code Review。AI生成不是免检金牌人工审核对于关键业务逻辑仍然必要。TAG任务本身也是代码你的工件规格文件YAML和测试套件Python应该被版本化管理。它们的演变历史就是你对AI生成质量要求不断提高的历史。在CI中运行TAG验证可以在拉取请求PR中设置一个CI任务当相关模型或规格发生变化时自动触发TAG任务重新生成工件并运行测试。确保生成结果始终符合最新标准。7. 常见问题与故障排查在实际操作中你可能会遇到以下典型问题问题现象可能原因排查步骤与解决方案生成循环陷入死循环始终无法通过测试。1. 测试条件过于严苛或存在矛盾无解。2. 模型无法理解测试反馈。3. 提示词中上下文不足。1.简化测试暂时移除最严格的测试看是否能生成通过基础测试的版本逐步增加难度。2.优化反馈将测试错误信息用更自然、指令式的语言重新表述后再反馈给模型。例如将“AssertionError: ‘GET’ not found in [‘POST’, ‘PUT’]”改为“请确保为查询操作实现一个GET类型的端点。”3.增强上下文在规格中提供一两个近乎完美的示例Few-shot Learning让模型模仿。生成的代码语法正确但逻辑完全错误。模型“幻觉”Hallucination或误解了需求。1.分解任务不要试图让AI一步生成完整模块。先让它生成函数签名和文档字符串通过测试后再让它填充函数体。2.增加验收测试在测试套件中加入针对业务逻辑的验收测试虽然成本高。例如如果生成一个计算税款的函数就提供几组输入输出用例进行验证。测试执行环境与生成环境不一致导致失败。生成的代码依赖了特定库或环境但测试环境中没有。1.明确声明依赖在工件规格的constraints中明确指出允许和禁止的依赖。2.使用沙箱环境确保TAG的测试执行器在一个干净、可控的虚拟环境或容器中运行其依赖与项目要求一致。3.生成依赖声明让TAG同时生成requirements.txt或pyproject.toml片段并对其进行验证。API调用成本过高。任务复杂重试次数多使用了昂贵模型。1.优化提示和测试提高一次通过率是根本。清晰的规格和精准的测试能减少不必要的重试。2.使用本地模型对于风格固定、模式简单的生成任务如生成特定格式的配置文件可以微调一个较小的开源模型如CodeLlama在本地运行成本极低。3.设置预算警报在使用云模型API时设置每月预算和用量警报。生成的工件风格与项目现有代码不一致。模型没有学习到项目的代码风格和惯例。1.提供风格指南在规格上下文中加入项目的代码风格指南链接或关键规则摘要。2.引入风格检查器在测试套件中加入black,isort,flake8等检查强制风格一致。3.提供示例代码在上下文中粘贴几段项目中的典型代码作为风格参考这比文字描述更有效。TAG框架所代表的“测试驱动智能体生成”范式本质上是在用软件工程中最经典、最可靠的方法论——测试来驯服大语言模型生成的不确定性。它不是一个全自动的魔法盒而是一个强大的人机协同工具。开发者负责定义精确的规格和测试即“什么是对的”智能体负责在巨大的可能性空间中探索和实现即“怎么做”。这种分工将人的抽象思维、质量要求和AI的执行力、知识广度结合起来为自动化生成高质量、可信任的软件工件开辟了一条切实可行的道路。从我自己的使用体验来看最大的转变在于思维模式从“我该如何提示AI才能让它做对”变成了“我该如何定义测试才能判断AI做对了”。后者是一个更可控、更可重复、也更符合工程师直觉的过程。