1. 项目概述让AI编码助手真正理解并执行API测试如果你和我一样日常工作中需要频繁地编写、维护和调试API测试那么你肯定遇到过这样的场景你向Claude Code、Cursor或者GitHub Copilot这样的AI编码助手描述一个测试需求比如“给/users端点写个冒烟测试”它确实能生成一段看起来不错的代码。但问题来了——这段代码真的能跑通吗它理解你项目的认证方式吗它知道你的API响应结构吗大多数时候答案是否定的。你得到的只是一段“看起来正确”的代码接下来你依然需要手动配置环境、安装依赖、处理认证、运行测试、解读失败信息、再回去修改代码……这个循环可能要重复好几次。这正是glubean/skill这个项目要解决的核心痛点。它不是一个独立的测试框架而是一个“技能包”专门用来教会你的AI编码助手Agent如何真正地编写、运行、修复API验证代码。简单来说它让AI从“猜测式代码生成”进化到“闭环式测试开发”。想象一下你只需要在聊天窗口里说一句“把我们的Postman集合迁移到Glubean”你的AI助手就能理解你的意图自动分析现有的Postman导出文件分步骤地将其转化为可执行、可维护的测试套件并且在转换过程中遇到认证等不确定因素时会主动向你确认。这不再是简单的代码补全而是一个拥有上下文理解和执行能力的智能工作流。这个技能包支持超过40种主流的AI编码助手包括Claude Code、Cursor、GitHub Copilot、Windsurf等。它的价值在于将测试资产那些.spec.ts或.test.js文件的生命周期从一次性的聊天产物变成了可以随着项目演进的活文档。AI助手生成的测试文件从一开始在explore/目录下的探索性草稿到稳定后进入tests/目录最终可以无缝集成到CI/CD流水线中整个过程无需人工重写。这对于追求开发效率和代码质量的团队来说意味着测试左移和自动化程度的质变。2. 核心设计思路从猜测到基于上下文的精确执行传统的AI编码助手在处理API测试任务时其工作模式本质上是“基于模式的猜测”。它根据你的提示词和它训练数据中的海量代码片段组合生成一个它认为最可能的测试文件。这种方式存在几个根本性缺陷缺乏项目上下文它不知道你项目里用的是JWT Bearer Token还是OAuth 2.0不知道你的基础URL是什么更不知道你的数据模型和响应结构。它只能生成一个通用的、需要你填入大量TODO的模板。无法验证结果它生成代码后就结束了。代码是否能编译运行起来是否报错断言是否通过这些都需要开发者手动操作切出聊天界面回到终端去验证形成了工作流的断层。没有迭代修复能力当测试失败时开发者需要将复杂的终端错误信息可能夹杂着网络错误、语法错误、运行时错误解读后再重新描述给AI进行又一轮猜测。glubean/skill引入了一种全新的范式我称之为“感知-执行-学习”循环。它的设计核心是赋予AI助手两种关键能力通过MCP读取运行时环境的能力以及遵循Glubean特定模式进行思考的能力。2.1 MCPAI的“眼睛和手”MCPModel Context Protocol是一个新兴的开放协议它允许AI模型安全地与外部工具、数据和操作进行交互。你可以把它理解为AI模型的插件系统或驱动程序。glubean/skill首先通过npx glubean config mcp命令为你的AI助手配置好与Glubean测试运行器交互的MCP工具。这个配置完成后你的AI助手就获得了“超能力”运行测试它可以直接在聊天环境中触发测试执行而无需你手动敲命令。检查结果更重要的是它能接收到结构化的测试结果而不是一坨杂乱的终端文本。这意味着它能清晰地知道是哪个断言失败了期望值是什么实际值又是什么。2.2 Glubean模式AI的“测试思维框架”仅仅能运行和查看结果还不够AI需要知道“如何写好一个Glubean测试”。这就是npx skills add glubean/skill这一步的作用。这个命令为你的AI助手加载了一套预设的“思维模式”或“最佳实践库”包含了21种针对API测试的专用模式。这些模式覆盖了测试的方方面面认证模式教导AI如何安全地处理Bearer Token、API Key、OAuth 2.0。关键的是它被设定为在生成任何包含真实认证凭证的代码前必须向用户明确确认这解决了AI处理敏感信息的安全隐患。数据驱动测试模式教导AI如何使用test.each、test.pick以及如何从YAML、JSON、CSV文件加载测试数据。迁移模式给AI一个清晰的步骤告诉它如何分析Postman、Apifox、OpenAPI等现有资产并进行分批次、有确认的迁移。契约优先模式当API还不存在时指导AI如何将自然语言描述转化为可执行的API契约放在contracts/目录下这些契约日后可直接作为验收测试。有了MCP提供的“执行能力”和Glubean技能包提供的“领域知识”你的AI助手就从一个被动的代码建议者转变为一个主动的、具备完整工作流能力的测试协作者。它可以根据你的指令自动选择正确的工作模式进入一个“编写 - 运行 - 分析失败 - 修复 - 再运行”的自治循环直到测试通过。这一切都可以在一个连贯的对话中完成。3. 两种核心工作流详解从现有API到API设计根据你手头项目的状态glubean/skill会智能地路由到两种截然不同但同样强大的工作流。你不需要手动选择模式只需提出你的需求AI会根据上下文自动判断。3.1 工作流一为已存在的API编写和迭代测试这是最常见的场景。你的后端服务已经在运行拥有一些API端点现在你需要为它们补充自动化测试。1. 项目上下文读取当你发出类似“为/api/v1/users编写CRUD测试”的指令时启用了技能的AI不会立刻开始编代码。它会首先尝试理解你的项目检查Glubean项目它会查看当前目录是否有glubean.json配置文件或者是否有Glubean的依赖。如果没有它会引导你运行glubean init进行初始化。扫描API表面如果可能它会尝试分析你的源代码如路由定义或现有的OpenAPI/Swagger文档来构建一个API端点列表。询问澄清点对于无法自动推断的关键信息如认证方式、特殊请求头、环境变量名它会主动向你提问。例如“我注意到需要认证。请问是使用Bearer Token吗Token应该从哪个环境变量读取”2. 测试生成与执行循环在获取足够上下文后AI开始生成测试代码。生成后关键的差异出现了它会自动运行这些测试。首次运行通过配置好的MCP工具AI执行新生成的测试文件。结构化分析如果测试失败AI收到的不是“Error: 401 Unauthorized”这样的文本而是一个结构化的错误对象例如{ testName: GET /users returns 200, assertion: status code, expected: 200, actual: 401, errorDetail: Missing Authorization header }自动修复基于这个清晰的诊断AI能够精准地定位问题。是认证没配好是请求路径错了还是响应体结构不匹配它会根据错误信息修改代码然后再次自动运行。这个循环会持续进行直到所有测试通过或者达到某个迭代上限。3. 测试资产提升一旦在explore/目录下生成的探索性测试稳定下来比如运行了多次都通过你可以指示AI“将这些冒烟测试提升为正式测试。”AI会理解这个意图将相关文件移动到tests/目录并可能为其添加更完整的标签、描述并将其纳入到项目的测试套件配置中为CI集成做好准备。实操心得从探索到固化的平滑过渡我特别喜欢explore/和tests/目录分离的设计。这完美匹配了实际工作流程前期快速验证想法时代码在explore里可以随意、快速迭代一旦模式稳定就将其“固化”到tests目录作为回归测试的一部分。AI技能让这两个阶段间的迁移变得无比顺畅几乎是一句话的事情。3.2 工作流二契约优先的API设计这是一个更具前瞻性的模式尤其适用于“API驱动开发”或“契约优先开发”的团队。当API还处于设计阶段甚至后端还没开始编码时你就可以利用AI来定义和验证API的行为。1. 从描述到可执行契约你向AI描述“我们需要一个计费API包含创建订阅、获取发票列表、下载发票PDF的功能。”AI不会去搜索不存在的代码而是会进入“契约优先”模式。生成契约文件它会在项目的contracts/目录下创建新的契约文件例如billing.contract.ts。这些文件使用Glubean的契约DSL定义了每个端点的预期HTTP方法、路径、请求头、请求体模式、预期的响应状态码和响应体模式。状态机与断言契约不仅仅是接口定义。它可以描述状态转换例如“创建订阅请求成功后后续获取该订阅的请求应返回状态active”。它还包含可执行的断言用于验证响应是否符合约定。2. 契约作为唯一真相源这些contracts/文件成为了前后端、甚至不同团队之间的协作基准。后端开发者的任务是实现满足这些契约的API前端开发者则可以依赖这些契约进行Mock或生成类型定义。3. 契约演变为测试当后端实现完成后这些契约文件的角色就自然发生了转变。你可以运行glubean verify contracts命令这时契约就变成了验收测试直接对运行中的API进行验证确保实现与最初的设计完全一致。AI在最初基于自然语言描述生成的契约此时直接成为了保障质量的自动化测试没有任何浪费。工作流阶段核心活动AI技能带来的价值现有API测试读取上下文、生成测试、运行验证、迭代修复、资产提升将零散的、手动的测试开发过程整合为一个AI驱动的自治闭环极大提升创建有效测试的效率。契约优先设计解析需求、生成可执行契约、验证实现将模糊的需求描述直接转化为机器可验证的、无二义性的契约打通了从设计到测试的链路确保“所建即所设”。4. 逐步上手指南与深度配置理论说了很多现在让我们动手看看如何将一个普通的AI编码助手改造成一个专业的API测试伙伴。整个过程非常清晰大约10分钟就能完成设置。4.1 基础环境准备首先你需要一个已经安装了Node.js ( 18) 和 npm/yarn/pnpm 的项目环境。Glubean本身是一个TypeScript优先的测试框架因此它对现代JS/TS项目支持最好。第一步在项目中初始化Glubean打开你的项目根目录在终端中运行npx glubean init这个命令会交互式地引导你完成初始化选择项目类型是普通的REST API还是GraphQL、gRPC等。配置基础URL设置你的API开发/测试环境的基础地址。设置认证选择并预配置一种认证方式如环境变量读取Token。这里只是预设具体密钥不会硬编码在配置文件中。生成配置文件最终会创建glubean.json配置文件和一个基础的tests/目录结构。第二步配置AI助手的MCP工具这是让AI获得“动手能力”的关键。在你的项目目录下运行npx glubean config mcp这个命令会做以下几件事检测你系统里正在使用的、支持MCP的AI助手如Claude for Desktop、Cursor。询问你是否要为检测到的助手安装Glubean MCP工具。得到确认后它会自动修改对应AI助手的MCP配置文件通常位于~/.config/下添加一个指向本地Glubean CLI的工具声明。配置完成后你需要完全重启你的AI助手应用比如完全退出Claude for Desktop再重新打开以确保MCP配置被加载。4.2 为AI助手安装技能包现在你的AI助手有了“手”MCP工具但还不知道“如何做测试”。我们需要给它安装“大脑”技能包。确保你位于项目根目录然后在终端运行npx skills add glubean/skillnpx skills是一个通用的技能管理CLI。这个命令会从网络获取最新的glubean/skill技能包。将其安装到你AI助手的技能库中。安装位置取决于你的AI助手例如对于Claude for Desktop可能会安装在~/Library/Application Support/Claude/claude_desktop_config/skills/这样的目录下。安装完成后同样需要重启你的AI助手。重启后当你新建一个聊天窗口并聚焦在你的项目文件上时AI助手就已经加载了Glubean的测试模式。注意事项技能的范围这个技能是“项目感知”的。它通常在检测到项目中有glubean.json文件或相关依赖时才会被高度激活。如果你在一个空白目录聊天它可能只会提供一些通用的Glubean介绍。因此最佳实践是在你的项目目录下直接与AI对话。4.3 验证安装与进行首次对话如何验证一切就绪很简单直接向你的AI助手提问。在你的项目里打开AI助手的聊天面板例如在Cursor里是CmdK在Claude Code里是侧边栏尝试输入“检查一下我们这个项目的Glubean配置并为健康检查端点 /health 写一个简单的冒烟测试。”如果配置成功你应该能看到AI助手识别出这是一个Glubean项目。读取你的glubean.json配置并可能提及其中设置的基础URL。生成一个格式良好的Glubean测试文件例如explore/health.smoke.ts。最关键的一步它可能会询问你是否要运行这个测试。你同意后它会通过MCP工具执行测试并将结构化的成功或失败结果返回在聊天中。这个完整的“理解-生成-执行-反馈”循环就是你成功安装并启用glubean/skill的标志。4.4 技能包更新与管理技能包和Glubean框架本身都在积极迭代。为了获得最新的模式和修复定期更新是必要的。更新技能包本身npx skills update这个命令会检查所有已安装技能包括glubean/skill的更新并应用。更新Glubean CLI和MCP工具npm update glubean/cli -g # 如果全局安装 # 或 npm update glubean/cli --save-dev # 如果项目内安装更新后如果MCP工具有重大变更可能需要重新运行npx glubean config mcp来更新AI助手侧的配置。5. 核心功能模式深度解析glubean/skill内置的21种模式是其智能的源泉。这些模式不是简单的代码模板而是引导AI解决特定测试场景的“思维链”和“最佳实践包”。我们来深入剖析几个最关键的模式理解它们如何在实际对话中发挥作用。5.1 认证处理模式安全与灵活的结合API测试中最棘手的问题之一就是认证。AI技能包在处理认证时遵循一个核心原则可以生成处理认证的逻辑但绝不能臆测或硬编码认证凭证。工作流程示例用户指令“给需要API Key认证的/admin/metrics端点写个测试。”AI的思考链技能模式引导模式匹配识别出“API Key认证”关键词触发认证处理模式。检查配置查看glubean.json中是否预定义了名为apiKey的认证方案。生成安全代码生成测试代码其中API Key的引用来自环境变量或配置对象例如import { test, expect } from glubean/core; import { setup } from ./setup; // 假设setup中配置了auth test(GET /admin/metrics returns data, async ({ api }) { // 技能引导AI使用项目中已定义的auth配置而不是写死key const response await api.get(/admin/metrics, { headers: { X-API-Key: process.env.ADMIN_API_KEY // 引用环境变量 } }); expect(response.status).toBe(200); expect(response.data).toHaveProperty(requests); });主动确认在输出代码后AI会附加一条重要消息“我已生成测试但其中引用了环境变量ADMIN_API_KEY。请确保该变量已在你的测试环境中设置。需要我帮你创建一个.env.test文件的示例吗”支持的认证类型该模式内置了对Bearer TokenAuthorization: Bearer token、OAuth 2.0 Client Credentials流、Basic Auth以及自定义Header API Key的完整支持逻辑。AI会根据你的描述或项目配置选择正确的认证方式生成代码。5.2 迁移模式从现有工具平滑过渡很多团队已经积累了大量的Postman集合、Apifox项目或Swagger文档。从头重写测试成本高昂。迁移模式将这个过程分解为可管理、可审查的步骤。工作流程示例用户指令“把我们团队的Postman集合production.postman_collection.json迁移成Glubean测试。”AI的思考链迁移模式引导模式启动识别“迁移”、“Postman”关键词触发迁移模式。询问意图“你是想创建一个新的Glubean项目来存放这些测试还是迁移到当前已有的项目中”用户选择分析阶段AI会读取Postman集合文件进行分析并生成一份报告“找到1个文件夹共23个请求。其中15个使用Bearer Token5个使用API Key3个无需认证。发现5个请求使用了动态变量如{{baseUrl}}。是否开始按文件夹分批转换”分步转换与确认AI不会一次性生成所有文件。它会建议“我们先转换‘用户管理’这个文件夹下的8个请求。在转换过程中对于每个不同的认证方式我会向你确认如何映射到Glubean的配置。可以开始吗”用户确认生成与解释AI生成第一批测试文件同时解释它所做的决策“我将Postman的baseUrl变量映射到了glubean.json中的baseUrl。将Authorization头中的Bearer Token替换为引用process.env.ACCESS_TOKEN。原来的Pre-request Scripts我转换成了Glubean的setup钩子。”迭代用户审查第一批文件确认无误后AI继续迁移下一批。这种方式让迁移过程可控、透明。5.3 契约优先与数据驱动测试模式契约优先模式的核心产出是contracts/目录下的.contract.ts文件。这些文件使用一种声明式的语法例如// contracts/billing.contract.ts import { defineContract } from glubean/core; export const billingContract defineContract({ name: Billing API, endpoints: [ { name: Create Subscription, method: POST, path: /v1/subscriptions, request: { body: { type: object, properties: { planId: { type: string }, customerId: { type: string } }, required: [planId, customerId] } }, response: { status: 201, body: { type: object, properties: { id: { type: string }, status: { type: string, enum: [active, pending, canceled] }, currentPeriodEnd: { type: string, format: date-time } } } } } ] });AI技能包指导AI如何将“创建一个订阅”这样的自然语言转化为上面这种结构化的、可执行的契约定义。数据驱动测试模式则教导AI如何利用Glubean的test.each等特性避免编写重复的测试逻辑。例如当用户说“用不同的用户角色测试这个端点”AI会生成类似下面的代码import { test } from glubean/core; const userRoles [ { role: admin, expectedStatus: 200 }, { role: editor, expectedStatus: 200 }, { role: viewer, expectedStatus: 403 }, { role: anonymous, expectedStatus: 401 } ]; test.each(userRoles)(Access control for $role, async ({ role, expectedStatus }, { api }) { const token await getTokenForRole(role); // AI会建议或生成这个辅助函数 const response await api.get(/secure-data, { headers: { Authorization: Bearer ${token} } }); expect(response.status).toBe(expectedStatus); });这些模式让AI生成的测试代码不再是简单的样板而是高效、可维护的最佳实践。6. 与CI/CD流水线集成AI在聊天窗口中生成的、并通过迭代变得稳定的测试其最终归宿是自动化流水线。glubean/skill也包含了CI集成的模式让AI能够协助你完成这“最后一公里”。典型对话流程用户指令“把我们刚刚为/users和/products写的测试加到GitHub Actions CI里只在主分支和PR上运行。”AI的响应与行动模式识别识别“CI”、“GitHub Actions”关键词触发CI集成模式。检查项目查看项目根目录下是否有.github/workflows目录。生成或更新工作流文件如果目录不存在AI会创建一个基本的test.yml工作流文件。如果已存在AI会建议在现有工作流中添加一个Glubean测试的job。生成智能配置AI生成的CI配置不是通用的它会结合项目上下文# .github/workflows/test.yml (部分) jobs: api-tests: runs-on: ubuntu-latest env: # AI会根据项目中的测试代码推断出需要哪些环境变量 API_BASE_URL: ${{ secrets.STAGING_API_URL }} ACCESS_TOKEN: ${{ secrets.STAGING_ACCESS_TOKEN }} steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm ci - run: npx glubean run tests/ # 运行正式测试目录 # AI可能会建议添加一个探索性测试的步骤用于PR预览 - name: Run exploratory tests (on PR) if: github.event_name pull_request run: npx glubean run explore/ --match ${{ github.head_ref }}安全提示AI会强调“我已生成GitHub Actions工作流配置。请注意ACCESS_TOKEN等敏感信息必须存储在GitHub仓库的Secrets中而不是直接写在文件里。你需要手动在仓库设置中配置STAGING_API_URL和STAGING_ACCESS_TOKEN这两个Secrets。”通过这种方式AI将本地交互式的测试开发与自动化的团队质量保障流程无缝连接了起来。7. 常见问题与实战排错指南在实际使用中你可能会遇到一些典型问题。以下是我在深度使用glubean/skill过程中总结的排查思路和解决方案。7.1 AI助手没有反应或未识别技能症状输入Glubean相关的指令后AI助手反应平淡就像没安装技能一样只是生成一些通用测试代码。排查步骤确认安装位置确保你是在项目目录下与AI对话。技能包对上下文的依赖很强在非项目目录或未初始化Glubean的目录下它的激活程度会降低。检查MCP配置运行npx glubean config mcp --check如果支持或手动检查你的AI助手MCP配置文件。确保其中包含指向glubean/cli的工具配置。重启AI助手安装技能或更新MCP后必须完全退出并重启AI助手应用如Claude for Desktop、Cursor。许多应用只在启动时加载配置和技能。验证技能列表在某些AI助手如Claude for Desktop的设置界面可能会有“已安装技能”的列表检查glubean/skill是否在其中。使用明确指令尝试更明确的指令如“使用Glubean技能为/api/health编写一个测试。”有时直接提及技能名称能帮助AI路由。7.2 测试运行失败或AI无法解析结果症状AI尝试运行测试但返回错误或者无法理解运行结果。排查步骤检查Glubean项目状态运行npx glubean info确保项目初始化正确且基础URL等配置有效。AI的运行依赖本地的Glubean CLI。手动运行测试在终端手动运行AI生成的测试文件例如npx glubean run explore/your-test.spec.ts。如果手动也失败那么问题在于测试代码或环境而非AI技能。根据终端报错修复问题。检查MCP服务器AI通过MCP与Glubean CLI通信。确保在运行测试时没有端口冲突或其他进程占用。可以尝试重启AI助手来重置MCP连接。查看结构化输出如果测试运行了但AI说无法解析可能是MCP工具返回的数据格式不符合预期。这通常是技能包或CLI版本的兼容性问题。尝试更新到最新版本npx skills update npm update glubean/cli。7.3 迁移过程中遇到复杂逻辑丢失症状从Postman等工具迁移时复杂的Pre-request Scripts或Tests脚本没有正确转换。解决方案与最佳实践分步迁移不要一次性迁移整个大型集合。利用AI迁移模式的分批功能先迁移逻辑简单的请求成功后再处理复杂的。手动重构复杂逻辑对于非常复杂的脚本逻辑如动态签名计算、加解密AI可能只能将其转换为一个// TODO: 需要手动实现 [原Postman脚本逻辑]的注释。这是合理的。将这些部分视为需要开发者手动介入的“边界”将脚本逻辑重构为Glubean项目中的一个辅助函数或自定义工具然后在生成的测试中调用它。提供上下文在迁移前可以告诉AI“这个集合里使用了pm.variables和pm.sendRequest请特别注意这些脚本的转换。”这能帮助AI更关注这些难点。7.4 性能与规模问题症状当API数量极大数百个或测试非常复杂时AI生成或迭代的速度变慢或者上下文长度不足。优化建议模块化指令不要一次性要求“为所有API生成测试”。按业务域划分例如“先为/v1/users下的所有端点生成CRUD测试”。利用已有代码如果项目已有部分测试AI技能可以读取并借鉴其模式。在指令中说明“参考tests/auth.spec.ts里的模式为/products生成类似的测试。”聚焦探索目录在初期快速验证阶段让AI将所有草稿生成在explore/目录。这个目录下的测试可以更自由、更独立避免过早考虑复杂的setup和teardown共享逻辑。定期清理与提升定期审查explore/目录将稳定、有价值的测试通过指令“提升到正式测试套件”移动到tests/并清理掉过时的探索文件保持工作区清晰。7.5 与其他测试框架的共存疑问我的项目已经用了Jest/Vitest做单元测试还需要用Glubean吗会不会冲突解答不会冲突它们是互补关系。Glubean专注于API集成测试和契约测试它模拟真实的HTTP请求关注端点行为、合同符合性和系统集成。Jest/Vitest更适合单元测试和组件测试。最佳实践在package.json中配置不同的脚本。{ scripts: { test:unit: vitest, test:api: glubean run tests/, test:explore: glubean run explore/, test: npm run test:unit npm run test:api } }AI技能的协同你可以指示AI“在__tests__/目录下用Vitest为这个工具函数写单元测试同时在explore/目录下用Glubean为使用这个函数的API端点写集成测试。”AI技能能理解上下文并选择正确的框架和模式来生成代码。8. 个人使用体会与进阶技巧经过一段时间的密集使用glubean/skill已经从一个新奇工具变成了我日常API开发工作流中不可或缺的一环。它改变的不仅仅是写测试的速度更是思考测试的方式。最大的价值在于“闭环”。以前让AI写测试是一个开环过程我发出指令 - AI返回代码 - 我手动运行、调试、再反馈。现在它变成了一个自治的对话循环。我可以一边喝着咖啡一边看着AI在聊天窗口里自己跑测试、读错误、改代码、再跑测试直到绿灯通过。这种体验极大地减少了上下文切换让思维保持连贯。它特别擅长处理“繁琐的样板代码”和“探索性任务”。比如一个新项目有50个API端点需要基础的CRUD测试。手动写虽然不难但极其枯燥。现在我只需要描述清楚数据模型和认证方式然后让AI“为/users、/products、/orders...生成完整的CRUD测试套件”它就能以惊人的速度生成结构良好、风格一致的测试文件。我再通过几次“运行并修复所有失败”的对话就能得到一个可用的测试基线。对于契约优先开发它是一个强大的推动者。在技术方案评审会上我们经常用白板画API设计。现在我会在会后立刻让AI根据会议记录生成可执行的契约文件。这些文件成为了前后端开发者的共同契约也成为了我们API设计讨论的具体载体模糊的设计在可执行的断言面前会立刻变得清晰。几个进阶技巧给AI更丰富的上下文在提出复杂请求前先让AI“阅读glubean.json和package.json文件来了解这个项目”。或者把OpenAPI文档的片段粘贴进聊天框。AI技能会利用这些上下文生成更精准的代码。使用“检查点”指令在迁移大型集合或生成大量测试时使用“暂停一下让我看看你目前生成的代码结构”这样的指令。这让你可以中途审查确保AI走在正确的方向上避免最后才发现整体思路有偏差。组合使用技能glubean/skill主要解决测试问题。但你完全可以结合其他技能比如代码重构技能、文档生成技能。你可以下这样的指令“用Glubean技能为这个端点生成测试然后用重构技能看看生成的测试代码有没有可以优化的地方最后用文档技能为这个测试生成描述。”这开启了AI助手多技能协同工作的可能性。将对话转化为知识库一次成功的、复杂的测试创建对话例如完整迁移了一个Postman集合其本身就是一个宝贵的案例。你可以将整个对话保存或导出作为团队的新手教程或知识库条目展示如何利用AI技能解决特定类型的问题。最后必须认识到它仍然是一个辅助工具。它的输出质量高度依赖于你输入的清晰度和项目本身的规范性。对于业务逻辑极其复杂、状态依赖严重的API测试仍然需要开发者深厚的领域知识来设计和验证。但无论如何glubean/skill已经将API测试中那些重复、机械、繁琐的部分自动化到了前所未有的程度让我能更专注于测试策略和复杂逻辑的设计本身。