1. 项目概述为什么我们需要一个AI提示词测试体系如果你最近在深度使用Cursor、Claude Code或者Windsurf这类AI编程工具大概率已经感受到了一个核心痛点提示词Prompt的稳定性和效果太不可控了。今天写的一个能让AI完美生成CRUD接口的提示词明天可能就因为模型的一次微小更新或者上下文里多了一行无关的注释就彻底“失智”输出一堆莫名其妙的代码。这种不确定性在将AI深度集成到开发流程时是致命的。这就像你团队里有一个能力超强但状态起伏不定的新员工你没法把关键任务放心交给他。而v0-system-prompts-models-and-tools这个开源项目本质上是一个庞大的、经过整理的“优秀员工行为指南”仓库。它汇集了主流AI工具的系统提示词、内部工具定义和模型配置。但仅仅拥有这个仓库是不够的如何确保我们从仓库里挑选、修改甚至自创的提示词能持续、稳定地工作这就需要一套工程化的“AI提示词自动化测试体系”。简单说这个体系的目标是像测试代码一样测试你的提示词。通过自动化的手段验证提示词在不同场景、不同输入下的输出是否符合预期确保其可靠性、一致性和有效性。本文将基于v0-system-prompts-models-and-tools项目手把手带你搭建这样一套体系让你从“提示词玄学调试”迈入“提示词工程化开发”的新阶段。2. 体系核心设计从混沌到有序的测试框架构建测试体系首先得想清楚测什么、怎么测。直接拿v0-system-prompts-models-and-tools里的海量提示词文件去跑AI既昂贵API调用费又低效。我们需要一个清晰的设计思路。2.1 测试对象的层次化拆解v0-system-prompts-models-and-tools项目结构本身给了我们启示。它的内容可以划分为三个测试层次单元测试提示词本身测试单个提示词文件的语法、结构、关键指令是否完整。例如一个用于代码生成的提示词是否包含了“角色定义”、“任务描述”、“输出格式要求”、“禁忌事项”等核心部分。这不需要调用AI通过静态分析即可完成。集成测试提示词工具定义很多提示词尤其是tools.json或*.yaml文件定义了AI可以调用的工具函数。测试需要验证工具定义的Schema是否规范提示词中引用的工具名是否在工具定义中存在参数描述是否清晰这类似于测试API接口的契约。端到端测试提示词模型输入这是最核心也最耗资源的测试。给定一个提示词、一组工具定义和一个具体的用户输入如“帮我写一个用户登录的API”调用真实的AI模型如GPT-4、Claude-3.5验证其输出是否满足功能、格式和质量要求。我们的自动化测试体系需要能覆盖这三个层次。对于前两层我们可以构建轻量级的静态检查脚本对于第三层我们需要设计一套可重复、可评估的测试用例和断言机制。2.2 技术选型与工具链搭建基于常见实践和项目特点我推荐以下工具链组合它平衡了灵活性、成本和可维护性测试运行与框架Pytest。Python生态的事实标准夹具Fixture功能强大插件生态丰富非常适合组织复杂的测试用例和前置条件如准备测试用的提示词文件、模拟API响应。AI调用与模拟真实调用使用OpenAI SDK或Anthropic SDK。用于在需要真实评估提示词效果时如定期回归测试、效果基准测试。务必配置好API密钥管理和用量监控避免测试跑崩导致天价账单。测试替身Mock使用Pytest-mock或unittest.mock。在大多数日常开发和CI流程中我们应该模拟AI的响应。这样可以实现快速、免费的测试重点验证我们的测试逻辑和提示词结构是否正确。我们可以准备一些“标准答案”作为Mock的返回值。断言与评估结构化输出断言如果提示词要求AI输出JSON、YAML或特定格式的代码我们可以用Pydantic模型或JSON Schema来验证输出的结构和类型。非结构化输出评估对于自然语言或代码逻辑的评估更复杂。我们可以结合关键词/模式匹配检查输出是否包含或排除某些关键词如“不能”、“抱歉”。二次AI评估用一个更“裁判”角色的AI如GPT-4来评估主AI的输出是否符合要求。这虽然成本高但对于核心提示词的最终验收非常有效。自定义评估函数针对特定任务编写Python函数进行评估例如对于生成的代码可以尝试用ast模块解析语法或者用subprocess跑一个简单的语法检查。测试数据管理使用YAML或JSON文件来管理测试用例。每个用例应包括input用户输入、context可选上下文信息、expected_output_pattern期望输出的模式或关键点以及测试所用的prompt_file和model_config。实操心得在项目初期Mock测试应该占80%以上。只有在对提示词进行重大修改或发布前才运行小规模的真实API测试。建立一个“测试沙盒”用最低成本的模型如gpt-3.5-turbo做快速验证再用高级模型如gpt-4做最终确认。3. 实战构建四步搭建你的测试流水线理论说再多不如动手。我们以v0-system-prompts-models-and-tools项目中Cursor Prompts/目录下的一个代码生成提示词为例搭建一个最小可行测试体系。3.1 第一步环境准备与项目结构化首先克隆项目并创建我们的测试工程目录。# 克隆 v0-system-prompts-models-and-tools 项目 git clone https://gitcode.com/GitHub_Trending/v0s/v0-system-prompts-models-and-tools.git cd v0-system-prompts-models-and-tools # 在我们的工作区创建测试项目目录 mkdir -p ai_prompt_test_framework cd ai_prompt_test_framework # 初始化Python虚拟环境和项目结构 python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows pip install pytest pytest-mock openai anthropic pyyaml pydantic创建核心目录结构ai_prompt_test_framework/ ├── prompts/ # 存放待测试的提示词文件可软链接或复制自v0项目 ├── test_cases/ # 存放YAML格式的测试用例 │ └── code_generation/ ├── test_utils/ # 自定义测试工具函数 ├── conftest.py # Pytest全局配置和Fixture ├── test_static.py # 静态分析测试 ├── test_integration.py # 集成测试 └── test_e2e.py # 端到端测试慎用将你需要测试的提示词复制或链接到prompts/下。例如我们测试一个假设的prompts/cursor_code_gen.txt。3.2 第二步编写静态与集成测试静态测试确保提示词的基础质量。test_static.py:import os import re from pathlib import Path def test_prompt_files_exist(): 检查prompts目录下是否存在文件 prompt_dir Path(__file__).parent / prompts prompt_files list(prompt_dir.glob(*.txt)) list(prompt_dir.glob(*.md)) assert len(prompt_files) 0, 未找到任何提示词文件 for pf in prompt_files: assert pf.stat().st_size 50, f提示词文件 {pf.name} 可能过小或为空 def test_prompt_contains_key_sections(): 检查提示词是否包含关键部分角色、任务、格式 sample_prompt Path(__file__).parent / prompts / cursor_code_gen.txt content sample_prompt.read_text(encodingutf-8) # 定义需要检查的关键词可根据你的提示词规范调整 key_sections [ r角色|Role|You are, # 角色定义 r任务|Task|Goal, # 任务描述 r输出|Output|Format, # 输出格式 r不|不要|避免|Avoid|Never, # 禁忌事项至少有一条限制 ] missing_sections [] for section in key_sections: if not re.search(section, content, re.IGNORECASE): missing_sections.append(section) # 这里不是断言必须全部都有而是警告。有些简洁提示词可能不包含所有部分。 if missing_sections: print(f警告提示词中可能缺少以下部分: {missing_sections}) # 但至少内容不能为空 assert len(content.strip()) 0集成测试检查提示词与配套工具定义的协同性。假设我们的提示词引用了一个名为run_unit_test的工具。test_integration.py:import json from pathlib import Path def test_tools_json_schema(): 检查关联的tools.json文件是否符合基本JSON Schema规范 tools_file Path(__file__).parent / prompts / tools.json if tools_file.exists(): with open(tools_file, r, encodingutf-8) as f: tools_data json.load(f) # 验证它是一个列表 assert isinstance(tools_data, list), tools.json 根元素应为数组 for tool in tools_data: # 验证每个工具都有必要的字段 assert name in tool, 工具定义缺少 name 字段 assert description in tool, f工具 {tool.get(name)} 缺少 description 字段 # 可以进一步验证parameters的schema if parameters in tool: assert type in tool[parameters], f工具 {tool.get(name)} 的parameters缺少 type3.3 第三步设计端到端测试用例与Mock策略端到端测试是重头戏。我们先在test_cases/code_generation/user_login_api.yaml定义一个测试用例name: 生成用户登录API - 成功场景 description: 测试提示词根据需求生成一个Flask用户登录接口的能力 prompt_file: prompts/cursor_code_gen.txt model_config: name: gpt-4 # 用于标识实际测试可能用mock或真实调用 user_input: | 请使用Python Flask框架编写一个用户登录的API端点。 要求 1. 接收JSON格式的username和password。 2. 连接名为app_db的MySQL数据库进行用户验证。 3. 密码需使用bcrypt哈希校验。 4. 验证成功返回JWT令牌。 5. 包含基本的错误处理。 expected_assertions: - type: contains_keywords keywords: [app.route, POST, request.get_json(), bcrypt.checkpw, jwt.encode] - type: not_contains_keywords keywords: [TODO, FIXME, pass, ...] # 检查是否生成完整代码而非占位符 - type: python_syntax_check # 这是一个自定义断言类型我们会在代码中实现然后编写一个使用Mock的端到端测试test_e2e_mocked.py:import pytest import yaml from pathlib import Path from unittest.mock import AsyncMock, MagicMock # 假设我们有一个调用AI的模块 from test_utils.llm_client import call_llm def load_test_case(case_name): case_path Path(__file__).parent / test_cases / f{case_name}.yaml with open(case_path, r, encodingutf-8) as f: return yaml.safe_load(f) pytest.mark.asyncio async def test_code_generation_with_mock(mocker): 使用Mock测试代码生成提示词 test_case load_test_case(code_generation/user_login_api) # 1. 读取提示词模板 prompt_template Path(__file__).parent / test_case[prompt_file] system_prompt prompt_template.read_text(encodingutf-8) # 2. 构造最终的用户消息有时需要将用例输入插入模板 user_message test_case[user_input] full_messages [ {role: system, content: system_prompt}, {role: user, content: user_message} ] # 3. Mock AI的返回内容这是我们预设的“标准答案” mocked_response import jwt import bcrypt from flask import Flask, request, jsonify import mysql.connector app Flask(__name__) app.config[SECRET_KEY] your-secret-key app.route(/login, methods[POST]) def login(): data request.get_json() username data.get(username) password data.get(password) # 连接数据库示例实际需配置连接池等 db mysql.connector.connect(hostlocalhost, databaseapp_db, useruser, passwordpass) cursor db.cursor(dictionaryTrue) cursor.execute(SELECT password_hash FROM users WHERE username %s, (username,)) user cursor.fetchone() if user and bcrypt.checkpw(password.encode(utf-8), user[password_hash].encode(utf-8)): token jwt.encode({user: username}, app.config[SECRET_KEY], algorithmHS256) return jsonify({token: token}), 200 else: return jsonify({error: Invalid credentials}), 401 # 4. 使用mocker替换真实的API调用返回我们预设的答案 mock_call mocker.patch(test_utils.llm_client.call_llm, new_callableAsyncMock) mock_call.return_value mocked_response # 5. 执行“调用” actual_output await call_llm(full_messages, modeltest_case[model_config][name]) # 6. 进行断言这里演示关键词断言 for assertion in test_case[expected_assertions]: if assertion[type] contains_keywords: for kw in assertion[keywords]: assert kw in actual_output, f输出中未找到关键词: {kw} elif assertion[type] not_contains_keywords: for kw in assertion[keywords]: assert kw not in actual_output, f输出中不应包含关键词: {kw} # 7. 验证Mock被以预期的参数调用了一次 mock_call.assert_called_once() # 可以进一步验证调用参数是否符合预期 call_args mock_call.call_args assert call_args[0][0] full_messages # 验证传入的消息3.4 第四步实现自定义断言与评估函数上面的测试用例中有一个python_syntax_check的自定义断言类型我们需要在test_utils/assertions.py中实现它。test_utils/assertions.py:import ast import subprocess import sys from typing import Dict, Any def assert_python_syntax(code_block: str, context: Dict[str, Any]): 断言一段Python代码语法正确 try: ast.parse(code_block) print(语法检查通过) return True except SyntaxError as e: raise AssertionError(f生成的代码存在语法错误: {e}) def assert_code_contains_function(code_block: str, context: Dict[str, Any]): 断言生成的代码包含特定的函数定义 func_name context.get(function_name) if not func_name: return True tree ast.parse(code_block) for node in ast.walk(tree): if isinstance(node, ast.FunctionDef) and node.name func_name: return True raise AssertionError(f代码中未找到函数定义: {func_name}) # 在测试中我们可以这样使用自定义断言 def run_custom_assertion(assertion_type: str, actual_output: str, assertion_config: Dict): if assertion_type python_syntax_check: # 需要从输出中提取代码块这里简化处理 # 实际应用中可能需要用正则表达式提取 python ... 之间的内容 assert_python_syntax(actual_output, assertion_config) elif assertion_type contains_function: assert_code_contains_function(actual_output, assertion_config) else: raise ValueError(f不支持的断言类型: {assertion_type})4. 集成与进阶将测试融入CI/CD与效果评估搭建好基础测试框架后我们需要让它真正运转起来并解决更复杂的问题。4.1 配置持续集成CI流水线在项目根目录创建.github/workflows/test-prompts.yml让每次提交都自动运行测试。name: Test AI Prompts on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Set up Python uses: actions/setup-pythonv4 with: python-version: 3.10 - name: Install dependencies run: | cd ai_prompt_test_framework pip install -r requirements.txt - name: Run static and integration tests run: | cd ai_prompt_test_framework pytest test_static.py test_integration.py -v - name: Run mocked E2E tests run: | cd ai_prompt_test_framework pytest test_e2e_mocked.py -v # 可选定期或在发布时运行真实API测试需配置密钥 # - name: Run real API tests (scheduled) # if: github.event_name schedule # run: | # cd ai_prompt_test_framework # pytest test_e2e_real.py --modelgpt-3.5-turbo -v # env: # OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}注意事项绝对不要将API密钥硬编码在代码或测试用例中。在CI中使用GitHub Secrets在本地使用环境变量如os.getenv(OPENAI_API_KEY)。对于真实API测试务必设置预算上限和频率限制例如每周仅在一次定时任务中运行或仅在打标签时运行。4.2 处理非确定性输出与效果评估AI的输出是非确定性的同一提示词两次调用结果可能不同。因此我们的测试不能做“字符串完全相等”的断言而应关注功能性满足生成的代码能跑通吗回答的问题切题吗这是我们自定义断言函数要解决的。质量评估这更主观。可以采用“评分”机制。例如在测试用例中定义评分标准evaluation_criteria: - criterion: 代码正确性 weight: 0.4 description: 语法正确逻辑符合需求 - criterion: 代码完整性 weight: 0.3 description: 没有遗漏关键步骤如错误处理、密码哈希 - criterion: 代码优雅性 weight: 0.3 description: 遵循PEP8结构清晰然后在测试中既可以人工评分也可以尝试用更高级的AI如GPT-4作为裁判根据这些标准对输出进行1-5分的打分。将每次测试的评分记录下来形成趋势图可以直观看到提示词修改后的效果变化。4.3 管理测试数据与提示词版本v0-system-prompts-models-and-tools项目本身在更新我们的提示词也会迭代。需要建立映射关系。提示词版本化对你测试的提示词文件进行版本管理用Git Tag或简单的版本号注释。测试用例关联在测试用例YAML中增加prompt_version字段关联到特定版本的提示词。基线测试为每个提示词版本保留一组“基线测试”结果。当升级提示词或AI模型后运行同样的测试用例对比输出差异和评分变化评估改动是提升还是倒退。5. 常见问题与排查技巧实录在实际搭建和运行过程中你肯定会遇到各种坑。以下是我踩过的一些以及解决方案问题1Mock测试通过但真实API调用失败。排查99%的问题出在提示词模板和用户输入的拼接上。Mock时你返回的是完美答案忽略了真实调用中消息格式的细微差别。例如某些API对system和user角色的处理方式不同。技巧在真实调用测试前增加一个“Dry Run”步骤将准备发送给API的完整消息列表打印或记录到日志中仔细检查其结构和内容是否符合API文档要求。使用json.dumps(messages, indent2, ensure_asciiFalse)可以很好地格式化查看。问题2测试运行速度慢尤其是真实API测试。排查网络延迟和API速率限制是主要瓶颈。技巧并行化使用pytest-xdist插件并行运行不依赖共享状态的测试。缓存响应对于不常变的提示词和输入可以使用vcr.py或pytest-recording库录制第一次真实API的响应后续测试直接回放实现“离线”测试。抽样测试不要对所有测试用例都跑真实API。只为每个核心场景保留一个代表性用例进行真实测试其他用例用Mock。问题3如何测试涉及“工具调用”Function Calling的复杂提示词场景v0-system-prompts-models-and-tools里很多tools.json就是用于此。测试AI是否会正确选择并调用工具。技巧Mock需要更精细。你需要模拟AI返回一个包含tool_calls的响应。然后在你的测试逻辑中解析这个调用执行对应的模拟工具函数并将结果以特定格式追加到对话历史中再模拟AI的后续响应。这相当于模拟了一个完整的“多轮对话工具调用”流程。问题4评估标准难以量化特别是对于创意类或分析类提示词。排查试图用自动化完全替代人类判断是徒劳的。技巧采用“人机回环”策略。自动化测试负责筛选出“明显不合格”的输出如格式错误、完全跑题。对于通过初筛的输出定期如每周由人工进行抽查和评分并将评分反馈给测试系统逐步优化自动评估的启发式规则。构建AI提示词自动化测试体系初期投入看似繁琐但它带来的长期收益是巨大的它让提示词从“黑盒魔法”变成了可迭代、可验证、可协作的“工程化组件”。当你拥有成百上千个提示词时这套体系就是你质量和信心的基石。从v0-system-prompts-models-and-tools这个优秀的资源库出发结合本文的工程化方法你可以开始构建属于自己团队的、可靠的AI提示词资产库了。
AI提示词工程化：构建自动化测试体系保障代码生成稳定性
1. 项目概述为什么我们需要一个AI提示词测试体系如果你最近在深度使用Cursor、Claude Code或者Windsurf这类AI编程工具大概率已经感受到了一个核心痛点提示词Prompt的稳定性和效果太不可控了。今天写的一个能让AI完美生成CRUD接口的提示词明天可能就因为模型的一次微小更新或者上下文里多了一行无关的注释就彻底“失智”输出一堆莫名其妙的代码。这种不确定性在将AI深度集成到开发流程时是致命的。这就像你团队里有一个能力超强但状态起伏不定的新员工你没法把关键任务放心交给他。而v0-system-prompts-models-and-tools这个开源项目本质上是一个庞大的、经过整理的“优秀员工行为指南”仓库。它汇集了主流AI工具的系统提示词、内部工具定义和模型配置。但仅仅拥有这个仓库是不够的如何确保我们从仓库里挑选、修改甚至自创的提示词能持续、稳定地工作这就需要一套工程化的“AI提示词自动化测试体系”。简单说这个体系的目标是像测试代码一样测试你的提示词。通过自动化的手段验证提示词在不同场景、不同输入下的输出是否符合预期确保其可靠性、一致性和有效性。本文将基于v0-system-prompts-models-and-tools项目手把手带你搭建这样一套体系让你从“提示词玄学调试”迈入“提示词工程化开发”的新阶段。2. 体系核心设计从混沌到有序的测试框架构建测试体系首先得想清楚测什么、怎么测。直接拿v0-system-prompts-models-and-tools里的海量提示词文件去跑AI既昂贵API调用费又低效。我们需要一个清晰的设计思路。2.1 测试对象的层次化拆解v0-system-prompts-models-and-tools项目结构本身给了我们启示。它的内容可以划分为三个测试层次单元测试提示词本身测试单个提示词文件的语法、结构、关键指令是否完整。例如一个用于代码生成的提示词是否包含了“角色定义”、“任务描述”、“输出格式要求”、“禁忌事项”等核心部分。这不需要调用AI通过静态分析即可完成。集成测试提示词工具定义很多提示词尤其是tools.json或*.yaml文件定义了AI可以调用的工具函数。测试需要验证工具定义的Schema是否规范提示词中引用的工具名是否在工具定义中存在参数描述是否清晰这类似于测试API接口的契约。端到端测试提示词模型输入这是最核心也最耗资源的测试。给定一个提示词、一组工具定义和一个具体的用户输入如“帮我写一个用户登录的API”调用真实的AI模型如GPT-4、Claude-3.5验证其输出是否满足功能、格式和质量要求。我们的自动化测试体系需要能覆盖这三个层次。对于前两层我们可以构建轻量级的静态检查脚本对于第三层我们需要设计一套可重复、可评估的测试用例和断言机制。2.2 技术选型与工具链搭建基于常见实践和项目特点我推荐以下工具链组合它平衡了灵活性、成本和可维护性测试运行与框架Pytest。Python生态的事实标准夹具Fixture功能强大插件生态丰富非常适合组织复杂的测试用例和前置条件如准备测试用的提示词文件、模拟API响应。AI调用与模拟真实调用使用OpenAI SDK或Anthropic SDK。用于在需要真实评估提示词效果时如定期回归测试、效果基准测试。务必配置好API密钥管理和用量监控避免测试跑崩导致天价账单。测试替身Mock使用Pytest-mock或unittest.mock。在大多数日常开发和CI流程中我们应该模拟AI的响应。这样可以实现快速、免费的测试重点验证我们的测试逻辑和提示词结构是否正确。我们可以准备一些“标准答案”作为Mock的返回值。断言与评估结构化输出断言如果提示词要求AI输出JSON、YAML或特定格式的代码我们可以用Pydantic模型或JSON Schema来验证输出的结构和类型。非结构化输出评估对于自然语言或代码逻辑的评估更复杂。我们可以结合关键词/模式匹配检查输出是否包含或排除某些关键词如“不能”、“抱歉”。二次AI评估用一个更“裁判”角色的AI如GPT-4来评估主AI的输出是否符合要求。这虽然成本高但对于核心提示词的最终验收非常有效。自定义评估函数针对特定任务编写Python函数进行评估例如对于生成的代码可以尝试用ast模块解析语法或者用subprocess跑一个简单的语法检查。测试数据管理使用YAML或JSON文件来管理测试用例。每个用例应包括input用户输入、context可选上下文信息、expected_output_pattern期望输出的模式或关键点以及测试所用的prompt_file和model_config。实操心得在项目初期Mock测试应该占80%以上。只有在对提示词进行重大修改或发布前才运行小规模的真实API测试。建立一个“测试沙盒”用最低成本的模型如gpt-3.5-turbo做快速验证再用高级模型如gpt-4做最终确认。3. 实战构建四步搭建你的测试流水线理论说再多不如动手。我们以v0-system-prompts-models-and-tools项目中Cursor Prompts/目录下的一个代码生成提示词为例搭建一个最小可行测试体系。3.1 第一步环境准备与项目结构化首先克隆项目并创建我们的测试工程目录。# 克隆 v0-system-prompts-models-and-tools 项目 git clone https://gitcode.com/GitHub_Trending/v0s/v0-system-prompts-models-and-tools.git cd v0-system-prompts-models-and-tools # 在我们的工作区创建测试项目目录 mkdir -p ai_prompt_test_framework cd ai_prompt_test_framework # 初始化Python虚拟环境和项目结构 python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows pip install pytest pytest-mock openai anthropic pyyaml pydantic创建核心目录结构ai_prompt_test_framework/ ├── prompts/ # 存放待测试的提示词文件可软链接或复制自v0项目 ├── test_cases/ # 存放YAML格式的测试用例 │ └── code_generation/ ├── test_utils/ # 自定义测试工具函数 ├── conftest.py # Pytest全局配置和Fixture ├── test_static.py # 静态分析测试 ├── test_integration.py # 集成测试 └── test_e2e.py # 端到端测试慎用将你需要测试的提示词复制或链接到prompts/下。例如我们测试一个假设的prompts/cursor_code_gen.txt。3.2 第二步编写静态与集成测试静态测试确保提示词的基础质量。test_static.py:import os import re from pathlib import Path def test_prompt_files_exist(): 检查prompts目录下是否存在文件 prompt_dir Path(__file__).parent / prompts prompt_files list(prompt_dir.glob(*.txt)) list(prompt_dir.glob(*.md)) assert len(prompt_files) 0, 未找到任何提示词文件 for pf in prompt_files: assert pf.stat().st_size 50, f提示词文件 {pf.name} 可能过小或为空 def test_prompt_contains_key_sections(): 检查提示词是否包含关键部分角色、任务、格式 sample_prompt Path(__file__).parent / prompts / cursor_code_gen.txt content sample_prompt.read_text(encodingutf-8) # 定义需要检查的关键词可根据你的提示词规范调整 key_sections [ r角色|Role|You are, # 角色定义 r任务|Task|Goal, # 任务描述 r输出|Output|Format, # 输出格式 r不|不要|避免|Avoid|Never, # 禁忌事项至少有一条限制 ] missing_sections [] for section in key_sections: if not re.search(section, content, re.IGNORECASE): missing_sections.append(section) # 这里不是断言必须全部都有而是警告。有些简洁提示词可能不包含所有部分。 if missing_sections: print(f警告提示词中可能缺少以下部分: {missing_sections}) # 但至少内容不能为空 assert len(content.strip()) 0集成测试检查提示词与配套工具定义的协同性。假设我们的提示词引用了一个名为run_unit_test的工具。test_integration.py:import json from pathlib import Path def test_tools_json_schema(): 检查关联的tools.json文件是否符合基本JSON Schema规范 tools_file Path(__file__).parent / prompts / tools.json if tools_file.exists(): with open(tools_file, r, encodingutf-8) as f: tools_data json.load(f) # 验证它是一个列表 assert isinstance(tools_data, list), tools.json 根元素应为数组 for tool in tools_data: # 验证每个工具都有必要的字段 assert name in tool, 工具定义缺少 name 字段 assert description in tool, f工具 {tool.get(name)} 缺少 description 字段 # 可以进一步验证parameters的schema if parameters in tool: assert type in tool[parameters], f工具 {tool.get(name)} 的parameters缺少 type3.3 第三步设计端到端测试用例与Mock策略端到端测试是重头戏。我们先在test_cases/code_generation/user_login_api.yaml定义一个测试用例name: 生成用户登录API - 成功场景 description: 测试提示词根据需求生成一个Flask用户登录接口的能力 prompt_file: prompts/cursor_code_gen.txt model_config: name: gpt-4 # 用于标识实际测试可能用mock或真实调用 user_input: | 请使用Python Flask框架编写一个用户登录的API端点。 要求 1. 接收JSON格式的username和password。 2. 连接名为app_db的MySQL数据库进行用户验证。 3. 密码需使用bcrypt哈希校验。 4. 验证成功返回JWT令牌。 5. 包含基本的错误处理。 expected_assertions: - type: contains_keywords keywords: [app.route, POST, request.get_json(), bcrypt.checkpw, jwt.encode] - type: not_contains_keywords keywords: [TODO, FIXME, pass, ...] # 检查是否生成完整代码而非占位符 - type: python_syntax_check # 这是一个自定义断言类型我们会在代码中实现然后编写一个使用Mock的端到端测试test_e2e_mocked.py:import pytest import yaml from pathlib import Path from unittest.mock import AsyncMock, MagicMock # 假设我们有一个调用AI的模块 from test_utils.llm_client import call_llm def load_test_case(case_name): case_path Path(__file__).parent / test_cases / f{case_name}.yaml with open(case_path, r, encodingutf-8) as f: return yaml.safe_load(f) pytest.mark.asyncio async def test_code_generation_with_mock(mocker): 使用Mock测试代码生成提示词 test_case load_test_case(code_generation/user_login_api) # 1. 读取提示词模板 prompt_template Path(__file__).parent / test_case[prompt_file] system_prompt prompt_template.read_text(encodingutf-8) # 2. 构造最终的用户消息有时需要将用例输入插入模板 user_message test_case[user_input] full_messages [ {role: system, content: system_prompt}, {role: user, content: user_message} ] # 3. Mock AI的返回内容这是我们预设的“标准答案” mocked_response import jwt import bcrypt from flask import Flask, request, jsonify import mysql.connector app Flask(__name__) app.config[SECRET_KEY] your-secret-key app.route(/login, methods[POST]) def login(): data request.get_json() username data.get(username) password data.get(password) # 连接数据库示例实际需配置连接池等 db mysql.connector.connect(hostlocalhost, databaseapp_db, useruser, passwordpass) cursor db.cursor(dictionaryTrue) cursor.execute(SELECT password_hash FROM users WHERE username %s, (username,)) user cursor.fetchone() if user and bcrypt.checkpw(password.encode(utf-8), user[password_hash].encode(utf-8)): token jwt.encode({user: username}, app.config[SECRET_KEY], algorithmHS256) return jsonify({token: token}), 200 else: return jsonify({error: Invalid credentials}), 401 # 4. 使用mocker替换真实的API调用返回我们预设的答案 mock_call mocker.patch(test_utils.llm_client.call_llm, new_callableAsyncMock) mock_call.return_value mocked_response # 5. 执行“调用” actual_output await call_llm(full_messages, modeltest_case[model_config][name]) # 6. 进行断言这里演示关键词断言 for assertion in test_case[expected_assertions]: if assertion[type] contains_keywords: for kw in assertion[keywords]: assert kw in actual_output, f输出中未找到关键词: {kw} elif assertion[type] not_contains_keywords: for kw in assertion[keywords]: assert kw not in actual_output, f输出中不应包含关键词: {kw} # 7. 验证Mock被以预期的参数调用了一次 mock_call.assert_called_once() # 可以进一步验证调用参数是否符合预期 call_args mock_call.call_args assert call_args[0][0] full_messages # 验证传入的消息3.4 第四步实现自定义断言与评估函数上面的测试用例中有一个python_syntax_check的自定义断言类型我们需要在test_utils/assertions.py中实现它。test_utils/assertions.py:import ast import subprocess import sys from typing import Dict, Any def assert_python_syntax(code_block: str, context: Dict[str, Any]): 断言一段Python代码语法正确 try: ast.parse(code_block) print(语法检查通过) return True except SyntaxError as e: raise AssertionError(f生成的代码存在语法错误: {e}) def assert_code_contains_function(code_block: str, context: Dict[str, Any]): 断言生成的代码包含特定的函数定义 func_name context.get(function_name) if not func_name: return True tree ast.parse(code_block) for node in ast.walk(tree): if isinstance(node, ast.FunctionDef) and node.name func_name: return True raise AssertionError(f代码中未找到函数定义: {func_name}) # 在测试中我们可以这样使用自定义断言 def run_custom_assertion(assertion_type: str, actual_output: str, assertion_config: Dict): if assertion_type python_syntax_check: # 需要从输出中提取代码块这里简化处理 # 实际应用中可能需要用正则表达式提取 python ... 之间的内容 assert_python_syntax(actual_output, assertion_config) elif assertion_type contains_function: assert_code_contains_function(actual_output, assertion_config) else: raise ValueError(f不支持的断言类型: {assertion_type})4. 集成与进阶将测试融入CI/CD与效果评估搭建好基础测试框架后我们需要让它真正运转起来并解决更复杂的问题。4.1 配置持续集成CI流水线在项目根目录创建.github/workflows/test-prompts.yml让每次提交都自动运行测试。name: Test AI Prompts on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Set up Python uses: actions/setup-pythonv4 with: python-version: 3.10 - name: Install dependencies run: | cd ai_prompt_test_framework pip install -r requirements.txt - name: Run static and integration tests run: | cd ai_prompt_test_framework pytest test_static.py test_integration.py -v - name: Run mocked E2E tests run: | cd ai_prompt_test_framework pytest test_e2e_mocked.py -v # 可选定期或在发布时运行真实API测试需配置密钥 # - name: Run real API tests (scheduled) # if: github.event_name schedule # run: | # cd ai_prompt_test_framework # pytest test_e2e_real.py --modelgpt-3.5-turbo -v # env: # OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}注意事项绝对不要将API密钥硬编码在代码或测试用例中。在CI中使用GitHub Secrets在本地使用环境变量如os.getenv(OPENAI_API_KEY)。对于真实API测试务必设置预算上限和频率限制例如每周仅在一次定时任务中运行或仅在打标签时运行。4.2 处理非确定性输出与效果评估AI的输出是非确定性的同一提示词两次调用结果可能不同。因此我们的测试不能做“字符串完全相等”的断言而应关注功能性满足生成的代码能跑通吗回答的问题切题吗这是我们自定义断言函数要解决的。质量评估这更主观。可以采用“评分”机制。例如在测试用例中定义评分标准evaluation_criteria: - criterion: 代码正确性 weight: 0.4 description: 语法正确逻辑符合需求 - criterion: 代码完整性 weight: 0.3 description: 没有遗漏关键步骤如错误处理、密码哈希 - criterion: 代码优雅性 weight: 0.3 description: 遵循PEP8结构清晰然后在测试中既可以人工评分也可以尝试用更高级的AI如GPT-4作为裁判根据这些标准对输出进行1-5分的打分。将每次测试的评分记录下来形成趋势图可以直观看到提示词修改后的效果变化。4.3 管理测试数据与提示词版本v0-system-prompts-models-and-tools项目本身在更新我们的提示词也会迭代。需要建立映射关系。提示词版本化对你测试的提示词文件进行版本管理用Git Tag或简单的版本号注释。测试用例关联在测试用例YAML中增加prompt_version字段关联到特定版本的提示词。基线测试为每个提示词版本保留一组“基线测试”结果。当升级提示词或AI模型后运行同样的测试用例对比输出差异和评分变化评估改动是提升还是倒退。5. 常见问题与排查技巧实录在实际搭建和运行过程中你肯定会遇到各种坑。以下是我踩过的一些以及解决方案问题1Mock测试通过但真实API调用失败。排查99%的问题出在提示词模板和用户输入的拼接上。Mock时你返回的是完美答案忽略了真实调用中消息格式的细微差别。例如某些API对system和user角色的处理方式不同。技巧在真实调用测试前增加一个“Dry Run”步骤将准备发送给API的完整消息列表打印或记录到日志中仔细检查其结构和内容是否符合API文档要求。使用json.dumps(messages, indent2, ensure_asciiFalse)可以很好地格式化查看。问题2测试运行速度慢尤其是真实API测试。排查网络延迟和API速率限制是主要瓶颈。技巧并行化使用pytest-xdist插件并行运行不依赖共享状态的测试。缓存响应对于不常变的提示词和输入可以使用vcr.py或pytest-recording库录制第一次真实API的响应后续测试直接回放实现“离线”测试。抽样测试不要对所有测试用例都跑真实API。只为每个核心场景保留一个代表性用例进行真实测试其他用例用Mock。问题3如何测试涉及“工具调用”Function Calling的复杂提示词场景v0-system-prompts-models-and-tools里很多tools.json就是用于此。测试AI是否会正确选择并调用工具。技巧Mock需要更精细。你需要模拟AI返回一个包含tool_calls的响应。然后在你的测试逻辑中解析这个调用执行对应的模拟工具函数并将结果以特定格式追加到对话历史中再模拟AI的后续响应。这相当于模拟了一个完整的“多轮对话工具调用”流程。问题4评估标准难以量化特别是对于创意类或分析类提示词。排查试图用自动化完全替代人类判断是徒劳的。技巧采用“人机回环”策略。自动化测试负责筛选出“明显不合格”的输出如格式错误、完全跑题。对于通过初筛的输出定期如每周由人工进行抽查和评分并将评分反馈给测试系统逐步优化自动评估的启发式规则。构建AI提示词自动化测试体系初期投入看似繁琐但它带来的长期收益是巨大的它让提示词从“黑盒魔法”变成了可迭代、可验证、可协作的“工程化组件”。当你拥有成百上千个提示词时这套体系就是你质量和信心的基石。从v0-system-prompts-models-and-tools这个优秀的资源库出发结合本文的工程化方法你可以开始构建属于自己团队的、可靠的AI提示词资产库了。
