1. 为什么手工测试经验总是“用完就丢”做测试的同学大概率都经历过这个循环需求评审完手工点一遍主流程发现几个边界问题写进用例文档然后下一个版本继续手工点。等到想把这些经验变成 Playwright 自动化脚本时又得从头回忆“上次那个优惠券重复领取是怎么验的”“库存扣减到底查哪张表”。我试过把测试规范写成提示词收藏夹每次让 Codex 生成用例时复制粘贴。前几轮还行但很快暴露三个问题一是不同人写的提示词标准不一致有人强调幂等性有人只写主流程二是时间久了关键要求容易漏比如“绕过前端直接调接口”这种高风险场景经常被忘掉三是 Codex 把每次提示词当成一次性要求不会形成长期习惯。Codex Skill 解决的正是这个断层。它把“反复说了三次以上”的测试规范固化成 Codex 自动加载的规则文件配合 Playwright 脚本模板让测试经验一次编写、多项目复用。这篇面向测试用例沉淀与回归场景交付 Skill 目录骨架、config.toml 配置片段和 Playwright 脚本模板并给出本地运行验证步骤。适合已经会用 Playwright 写基础脚本、但想让 Codex 稳定输出团队级测试资产的测试工程师。2. TaoToken 前置给 Codex 配一个稳定的模型入口Codex Skill 本身是本地文件但 Codex 在生成用例和脚本时需要调用大模型。如果你直接用官方入口可能会遇到网络波动、额度限制或团队多人共用时的并发问题。TaoToken 提供 OpenAI 兼容的 API 入口把 Codex 的模型请求指向它可以获得更稳定的调用体验。你需要先拿到一个 API Key。访问 TaoToken 控制台创建密钥https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcodex_skill_playwright创建完成后在 API Keys 页面复制密钥格式类似sk-xxxxxxxx。这个 Key 后面会写进 Codex 的 config.toml。注意API Key 只显示一次建议创建后立即保存到密码管理器。不要把它提交到 Git 仓库也不要在 Skill 文件里硬编码。TaoToken 的 API 基础地址是https://taotoken.net/api这个地址兼容 OpenAI 的/v1/chat/completions和/v1/models接口Codex 配置时直接填这个 base URL 即可。如果你用的是 Claude Code 或 Anthropic 风格的客户端TaoToken 也提供对应的接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcodex_skill_playwright对于长期做编码和 Agent 任务的团队Coding Plan 比按量计费更划算适合把 Codex Skill 接入日常回归流程https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcodex_skill_playwright3. 可复制配置Skill 目录骨架与 config.toml3.1 Skill 目录结构Codex 加载 Skill 的方式是扫描指定目录下的SKILL.md文件。一个最小可用的 Skill 只需要一个目录加一个 Markdown 文件。推荐按任务类型拆分而不是写一个“大而全”的测试 Skill。~/.codex/ ├── config.toml └── skills/ ├── test-case-and-playwright/ │ └── SKILL.md ├── api-test-design/ │ └── SKILL.md └── security-test-checklist/ └── SKILL.mdWindows 下对应路径是C:\Users\你的用户名\.codex\skills\。Mac 和 Linux 下是~/.codex/skills/。创建完成后重新打开 Codex 或开启新会话让它重新加载技能列表。3.2 config.toml 配置片段Codex 的模型入口配置在~/.codex/config.toml。把 base URL 指向 TaoToken并填入你创建的 API Key# ~/.codex/config.toml model gpt-4o model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY [skills] # Skill 扫描目录支持多个路径 paths [~/.codex/skills]然后在 shell 里导出环境变量避免把 Key 写死在配置文件里# ~/.bashrc 或 ~/.zshrc export TAOTOKEN_API_KEYsk-你的实际密钥Windows PowerShell 下用$env:TAOTOKEN_API_KEY sk-你的实际密钥配置完成后Codex 启动时会读取TAOTOKEN_API_KEY并通过https://taotoken.net/api发送模型请求。你可以先用一条简单命令验证连通性curl https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_API_KEY如果返回模型列表 JSON说明入口配置正确。3.3 SKILL.md 最小可用版SKILL.md最重要的是开头的 YAML 元信息。description要写清楚“什么时候触发这个 Skill”因为 Codex 判断是否加载主要看这个描述。--- name: test-case-and-playwright description: 根据需求、PRD、接口文档或代码变更生成测试点、测试用例、测试数据设计、Playwright 自动化脚本时使用。适用于功能测试、接口测试、Web UI 自动化、优惠券、订单、支付、权限等业务测试场景。 --- # 测试用例与 Playwright 自动化规范 ## 测试点生成规则 生成测试点时必须覆盖以下维度 1. 主流程 2. 异常流程 3. 边界值 4. 权限校验 5. 幂等性 6. 数据一致性 7. 异常恢复 输出测试点时优先使用 Markdown 表格字段包含模块、场景、操作、预期结果、验证方式、优先级。 ## Playwright 脚本规则 生成 Playwright 脚本时必须遵守 1. 使用 playwright/test 2. 优先使用 getByRole、getByText、getByTestId 3. 不使用 XPath除非用户明确要求 4. 测试环境地址从 TEST_BASE_URL 读取 5. 账号密码从环境变量读取 6. 不写死真实域名、真实账号、token、cookie 7. 核心业务场景必须补接口断言或数据断言 8. 不要只断言页面文案要验证业务结果 ## 业务专项规则 涉及优惠券时必须重点关注是否允许重复领取、库存是否正确扣减、用户券包是否能查询到、活动未开始/已结束的处理、库存不足时是否仍然发券、绕过前端直接请求接口是否能成功、多端同时领取是否只成功一次。 涉及订单时必须重点关注重复提交、金额计算、优惠抵扣、库存扣减、订单状态流转、支付失败后的恢复、取消订单后的库存回滚。 涉及权限时必须重点关注水平越权、垂直越权、资源归属校验、修改请求参数后的访问结果、前端隐藏按钮不等于后端已鉴权。 ## 脱敏规则 不要输出真实账号、真实 token、真实 cookie、真实生产域名。这个版本已经能覆盖大部分测试点生成和 Playwright 脚本生成场景。先让它跑起来比一开始追求完美更重要。4. 验证请求用优惠券场景跑通 Skill 与 Playwright4.1 用 Skill 生成测试用例配置好 Skill 后在 Codex 里输入一个真实需求用户进入活动页后可以领取一张优惠券。 每个用户只能领取一次。 优惠券有活动时间、库存数量、使用门槛。 未登录、活动未开始、活动已结束、库存不足、重复领取都需要给出对应提示。没有 Skill 时Codex 可能只输出主流程和简单异常。加载 Skill 后期望输出应该包含验证方式、接口断言、并发场景和优先级。你可以用下面这张表对照检查场景操作预期结果验证方式优先级正常领取登录用户点击领取提示领取成功页面提示 查询用户券包P0重复领取已领取用户再次点击提示已领取接口返回码 券包数量不变P0库存不足库存为 0 时领取提示已领完库存不变 未新增用户券P0活动未开始活动开始前领取提示活动未开始页面提示 接口返回码P1活动已结束活动结束后领取提示活动已结束页面提示 接口返回码P1绕过前端直接调用领取接口后端仍然拦截非法请求接口校验P0并发领取同一用户多端同时领取只能成功一次接口响应 券包数量P0判断 Skill 是否有效不是看输出更长了而是看它有没有稳定补出你最关心的风险点验证方式、接口断言、数据状态、并发场景、绕过前端、优先级。4.2 用 Skill 生成 Playwright 脚本接着让 Codex 基于上面的需求生成一条自动化用例基于上面的优惠券领取需求生成一条 Playwright 自动化用例 用户成功领取优惠券后券包中可以查询到该券。期望输出应该接近下面这个模板import { test, expect } from playwright/test; const baseUrl process.env.TEST_BASE_URL; const username process.env.TEST_USERNAME; const password process.env.TEST_PASSWORD; async function login(page: Page) { await page.goto(${baseUrl}/login); await page.getByRole(textbox, { name: 账号 }).fill(username!); await page.getByRole(textbox, { name: 密码 }).fill(password!); await page.getByRole(button, { name: 登录 }).click(); } test(用户成功领取优惠券后券包中可以查询到该券, async ({ page, request }) { await login(page); await page.goto(${baseUrl}/activity/coupon); await page.getByRole(button, { name: 立即领取 }).click(); await expect(page.getByText(领取成功)).toBeVisible(); const response await request.get(${baseUrl}/api/user/coupons); expect(response.status()).toBe(200); const data await response.json(); expect(data.list.some((item: any) item.couponName 活动优惠券)).toBeTruthy(); });注意几个关键点没有写死真实环境账号密码来自环境变量没用 XPath不只断言页面提示补了券包接口校验。这就比单纯生成一段 UI 点击脚本靠谱很多。4.3 本地运行验证把生成的脚本保存到项目里安装依赖并运行npm init -y npm install -D playwright/test npx playwright install chromium创建playwright.config.tsimport { defineConfig } from playwright/test; export default defineConfig({ testDir: ./tests, timeout: 30000, use: { baseURL: process.env.TEST_BASE_URL, headless: true, }, });设置环境变量后运行export TEST_BASE_URLhttps://你的测试环境地址 export TEST_USERNAME测试账号 export TEST_PASSWORD测试密码 npx playwright test tests/coupon.spec.ts --reporterlist如果看到1 passed说明 Skill 生成的脚本可以直接跑通。如果失败先看是定位器问题还是接口断言问题再回到 Skill 里补充对应规则。5. 本篇常见错排查5.1 Skill 不触发最常见的原因是description写得太虚。不要写“帮助测试工作”要写清楚触发场景比如“根据需求、PRD、接口文档或代码变更生成测试点、测试用例、Playwright 自动化脚本时使用”。描述越具体Codex 越容易判断何时加载。另一个原因是目录路径不对。确认config.toml里的paths指向了正确的 skills 目录并且SKILL.md文件名大小写正确。修改后需要重启 Codex 或开启新会话。5.2 生成的脚本写死了账号或域名检查 Skill 里是否明确写了“不写死真实域名、真实账号、token、cookie”。如果规则太笼统Codex 可能忽略。建议在 Playwright 规则里逐条列出环境变量名比如TEST_BASE_URL、TEST_USERNAME、TEST_PASSWORD让 Codex 有明确的替换目标。5.3 接口断言缺失如果生成的脚本只有 UI 点击和文案断言说明 Skill 里“核心业务场景必须补接口断言或数据断言”这条规则不够具体。可以补充示例领取优惠券后必须调用/api/user/coupons并校验券包数量变化。5.4 模型请求失败如果 Codex 报连接错误先检查TAOTOKEN_API_KEY是否导出成功再确认base_url是https://taotoken.net/api而不是带/v1的完整路径。用 curl 测试/v1/models接口能快速定位是 Key 问题还是网络问题。需要重新生成 Key 时去 API Keys 页面操作https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcodex_skill_playwright5.5 Skill 太大导致重点模糊我踩过一个坑一开始想把接口测试、安全测试、性能测试、用例设计全写到一个 Skill 里结果 Codex 抓不住重点。后来按场景拆成test-case-and-playwright、api-test-design、security-test-checklist三个独立 Skill每个只解决一类问题输出稳定性明显提升。6. 把测试经验变成可复用能力Skill 的价值不是让 Codex 变聪明而是让它更懂你的团队习惯。提示词解决的是一次任务Skill 解决的是长期重复任务。对测试团队来说最适合沉淀的是用例设计习惯、业务风险清单、自动化脚本规范、接口断言要求、安全测试检查点和日志分析方法。如果你还在用复制粘贴提示词的方式让 Codex 写用例建议先从test-case-and-playwright这个最小 Skill 开始拿三个真实需求验证效果再根据输出问题调整规则。稳定后再拆分接口测试、安全测试、缺陷分析等专项 Skill。需要验证模型输出效果时可以直接在模型对话里测试 Skill 触发情况https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcodex_skill_playwright长期做编码和 Agent 任务的团队建议用 Coding Plan 把 Codex Skill 接入日常回归流程避免按量计费带来的成本波动。接入文档里有完整的 config.toml 示例和 Claude Code 配置说明照着改就能跑。