一、为什么从测试自动化开始：价值稳定，风险可控

很多团队第一次使用 Codex 时，容易直接让它改业务代码。这样做并非不能尝试，但对团队流程要求更高：要有清晰权限、代码评审、测试覆盖和回滚机制。相比之下，让 Codex 先参与测试自动化，更容易稳定落地，因为它输出的是测试草稿、用例清单和失败分析，天然需要人工确认。

测试工作有一个特点：重复性高、边界多、上下文分散。开发者写完主流程后，常常漏掉空值、重复请求、权限不足、异常返回、旧数据兼容等情况。Codex 可以读取接口定义、业务函数和现有测试，先把可能遗漏的路径列出来，再给出测试样例。

通过灵能API统一接入后，团队可以把这类任务做成固定流程。每次接口或核心函数变化后，先生成测试建议，再由开发者选择是否采纳，最后把已采纳内容纳入测试集。这样既提高覆盖率，也不会让模型直接越过工程判断。

• 测试建议可以自动生成，但测试是否入库必须人工确认。
• 用例生成优先覆盖边界和异常，不只是重复主流程。
• 失败复盘要沉淀成清单，避免同类问题反复出现。

二、先统一入口：让测试任务使用同一套接入配置

测试自动化通常会被多人、多个分支、多个环境触发。如果每个成员都使用不同入口和不同模型，生成的测试风格、覆盖重点和失败表现都会不同。接入流程的第一步，是确认团队使用同一套基础配置。

建议从 https://www.lnsns.com/ 进入灵能API控制台，确认当前可用模型、接入说明和账号状态。团队文档只记录入口、变量名和负责人，不记录完整密钥。这样新成员可以按流程配置，但不会把敏感凭证复制到测试脚本或截图里。

统一入口之后，再规划测试任务的触发方式。不是所有代码变化都需要生成测试，优先关注接口变更、权限变更、数据处理逻辑、边界条件和历史故障相关模块。触发范围越明确，输出越有价值。

• 统一入口保证基础链路一致。
• 统一变量保证脚本和本地配置一致。
• 统一触发规则保证用量和输出质量可控。

三、明确测试范围：不要让 Codex 猜整个项目

让 Codex 生成测试时，最容易犯的错误是范围太大。比如直接说“帮我给这个项目补测试”，模型会很难判断优先级，也容易输出泛泛的建议。更好的方式，是指定一个函数、一个接口、一个模块，或者一次 PR 的变更集合。

测试范围最好包含三类材料：被测代码、已有测试、业务约束。被测代码告诉 Codex 逻辑是什么；已有测试告诉它当前覆盖到哪里；业务约束告诉它哪些边界不能随便推测。缺少其中任何一类，输出都可能变成表面正确、实际难用。

测试任务输入范围

读取：src/modules/payment/create-order.ts
读取：src/modules/payment/refund.ts
读取：tests/payment/*.spec.ts
读取：do**/api/payment.md

目标：生成缺失测试建议和可落地用例草稿
限制：不修改文件，不推测文档中不存在的计费规则

如果模块较大，可以先让 Codex 输出测试点清单，而不是直接写测试代码。清单确认后，再逐条生成用例。这个两步法能减少无效代码，也能让业务负责人先确认边界是否准确。

• 先指定范围，再要求生成。
• 先列测试点，再写测试代码。
• 不确定的业务规则必须进入待确认。

⚙️ 四、用 CC Switch 固定测试配置：把调试和正式任务分开

测试生成任务和日常问答不应该共用同一张配置卡。日常问答可以更自由，测试任务则需要稳定的输出结构和清晰的权限边界。建议在 CC Switch 中单独建立测试自动化配置卡，备注用途、模型、是否允许写入以及输出目录。

配置卡可以命名为 Lingneng-Codex-****-Draft 或 Lingneng-Codex-Regression-Review。默认建议只读代码并输出草稿，写入范围限制在 tests/drafts 或临时目录。等开发者确认后，再手动合并到正式测试文件中。

配置卡备注模板

用途：生成测试建议和用例草稿
权限：只读业务代码和已有测试
输出：测试点清单、用例草稿、失败复盘
写入：仅允许 drafts/ 或临时目录
复核：开发者确认后再进入正式测试集
最后验证：2026-09-04

• 测试配置卡不要混用代码重构配置。
• 默认只输出草稿，不自动覆盖正式测试。
• 配置变更后先跑小样本，再跑完整模块。

五、第一类任务：生成单元测试清单

单元测试清单是最适合起步的任务。它不要求 Codex 立刻写出可运行代码，而是先分析函数输入、输出、异常分支和依赖关系，列出应该覆盖的测试点。开发者确认清单后，再生成具体测试代码，成功率会高很多。

测试清单建议分成正常路径、边界路径、异常路径、兼容路径四类。正常路径用于确认主流程；边界路径用于覆盖空值、最大值、最小值、重复输入；异常路径用于覆盖权限不足、依赖失败、非法状态；兼容路径用于确认旧字段、旧调用方和历史数据仍然可用。

请读取指定函数和已有测试，输出单元测试清单。

输出结构：
1. 正常路径
2. 边界路径
3. 异常路径
4. 兼容路径
5. 需要 mock 的依赖
6. 当前测试缺口
7. 待人工确认的业务规则

限制：不要直接修改测试文件。

• 单元测试先列清单，减少直接生成无效代码。
• 异常路径要单独列，不要夹在正常路径里。
• 需要 mock 的依赖要提前说明。

六、第二类任务：生成可运行测试草稿

当测试点清单确认后，再让 Codex 生成可运行测试草稿。这里要明确测试框架、断言风格、mock 方式和文件位置。不要只说“帮我写测试”，否则输出可能和项目现有风格不一致，需要大量返工。

提示词里应要求 Codex 先读取已有测试文件，模仿项目的 import、descri*e、it、*eforeEach、mock 写法。这样生成的测试更容易贴近仓库风格，也更方便开发者复制到正式文件中。

请参考 tests/payment/create-order.spec.ts 的写法，
为 createOrder 增加测试草稿。

要求：
- 使用项目现有测试框架和断言风格
- mock 方式与已有测试一致
- 每个用例名称说明业务场景
- 不引入新测试库
- 输出代码块，不直接写文件
- 最后列出仍需人工确认的断言

生成草稿后，不要直接合并。先把测试放进临时分支或草稿目录运行，确认 import、mock、异步处理和断言都符合项目实际。模型可能理解逻辑，但不一定完全掌握本地测试环境的细节。

• 先模仿现有测试风格，再生成新用例。
• 不要引入未经讨论的新测试库。
• 生成代码后必须本地运行。

七、第三类任务：整理回归测试用例

回归测试的重点不是覆盖所有功能，而是覆盖最可能被本次改动影响的旧行为。Codex 可以读取变更文件、接口文档和历史测试，帮助团队整理一份回归清单。这个清单尤其适合发布前使用。

回归用例要写清楚前置条件、操作步骤、预期结果和风险等级。不要只写“测试登录”“测试下单”这种粗粒度条目，否则执行时仍然需要测试人员重新拆解。

回归用例输出模板

用例名称：旧用户资料接口兼容性检查
风险等级：中
前置条件：存在历史用户数据，包含旧字段 nickname
操作步骤：调用资料接口，检查返回结构
预期结果：旧字段仍可读取，新字段按默认规则返回
关联变更：src/modules/mem*er/profile.ts
待确认：旧字段计划废弃日期

通过灵能API统一入口运行这类任务，可以让不同项目保持接近的输出结构。回归清单一旦稳定，就可以放进发布流程，每次发布前让 Codex 先根据变更生成草稿，再由测试负责人确认执行范围。

• 回归测试关注旧行为是否被影响。
• 每条用例都要有前置条件和预期结果。
• 发布前回归清单必须由测试负责人确认。

八、**类任务：分析测试失败日志

测试失败后，很多团队会把整段日志丢给模型，希望它直接判断原因。更稳的方式，是先截取关键片段：失败用例名称、错误堆栈、相关断言、最近变更文件。输入越干净，Codex 给出的结论越容易复核。

失败分析的输出也要固定。建议包含失败现象、可能原因、优先检查项、建议补充信息、是否疑似环境问题。这样开发者可以先按优先级排查，而不是在一段长解释里找重点。

失败日志分析提示词

请读取以下测试失败片段和最近变更摘要。
输出：
1. 失败现象
2. 最可能原因
3. 第二可能原因
4. 建议先检查的文件
5. 需要补充的上下文
6. 是否可能是环境变量或依赖问题

限制：不要把猜测写成确定结论。

• 失败日志要截取关键片段，不要整包塞入。
• 原因判断要按概率排序。
• 环境问题和代码问题要分开标记。

九、把失败复盘沉淀成测试知识库

测试失败处理完之后，最容易被忽略的是复盘沉淀。很多问题当时解决了，过几周另一个成员又遇到同样现象，只能重新查。Codex 可以帮助把失败日志、处理过程和最终原因整理成简短知识库条目。

复盘条目不要写成流水账，而要面向下一次排查。建议包含错误现象、触发条件、根因、排查步骤、修复方式、预防动作。这样团队后续能直接复用，而不是只看到一段历史描述。

测试失败复盘模板

标题：支付回调测试偶发 timeout
现象：CI 中支付回调测试间歇失败
触发条件：外部依赖 mock 未稳定返回
根因：测试未等待异步队列处理完成
排查步骤：查看失败用例、确认 mock、检查异步等待
修复方式：增加队列完成等待和超时断言
预防动作：新增异步测试编写规范

• 复盘条目要面向未来排查。
• 根因和猜测要区分。
• 每次典型失败都要沉淀一条可搜索记录。

十、控制用量：测试生成也要分任务重量

测试自动化看似比代码生成轻，但如果每次提交都让 Codex 读取大量文件并生成完整测试报告，成本也会快速上升。建议按任务重量分流：短日志解释走轻量路线，单文件测试清单走标准路线，跨模块回归清单手动触发。

在灵能API控制台查看模型和资源状态时，可以把团队策略写下来。比如：每次 PR 只生成测试缺口摘要；接口变化时生成详细用例草稿；发布前才生成完整回归清单；测试失败后只分析关键日志片段。

测试任务触发策略

每次 PR：生成测试缺口摘要
接口变化：生成单模块测试清单
测试失败：分析关键失败日志
发布前：生成回归测试草稿
跨模块影响：人工触发深度分析

• 高频任务输出要短。
• 长上下文任务要低频或手动触发。
• 连续失败时先停止重试，再排查原因。

十一、提示词模板：让输出能直接进入测试流程

测试提示词要避免空泛，最好固定为“目标、输入、范围、项目风格、输出结构、限制、待确认”七个部分。这样不同成员触发任务时，输出不会忽长忽短，也更容易进入团队测试流程。

你是团队测试用例助手。

目标：为指定模块生成测试点和用例草稿。
输入：读取指定业务文件、sche** 文件和已有测试文件。
范围：只分析本次指定模块，不扩展到其他目录。
项目风格：参考已有测试文件的命名、断言和 mock 写法。
输出结构：测试点清单、用例草稿、测试缺口、待确认事项。
限制：不修改文件，不引入新测试库，不推测未出现的业务规则。
待确认：单独列出需要开发、测试或产品确认的问题。

这个模板的好处是把模型能力限制在可复核范围内。Codex 可以做大量整理和草稿生成，但它必须说明哪些内容是确定的，哪些内容需要人确认。测试代码尤其需要这种边界，因为一个看似合理的断言，如果业务规则不对，反而会把错误固化下来。

• 提示词要先写限制，再要求输出。
• 输出结构固定，后续才能自动检查。
• 待确认事项必须独立列出。

十二、入库前检查：测试草稿不能直接变成正式测试

Codex 生成的测试草稿进入仓库前，必须经过检查。第一看能不能运行，第二看断言是否真的验证业务，第三看 mock 是否遮蔽了真实问题，**看用例名称是否能被后续维护者理解。

尤其要警惕两类测试：一种是只验证函数被调用，却不验证结果；另一种是 mock 过多，导致测试永远通过但没有覆盖真实逻辑。模型生成代码时容易追求形式完整，人工复核时要回到测试价值本身。

测试入库检查清单

[ ] 测试能在本地和 CI 中运行
[ ] 断言覆盖关键返回值或状态变化
[ ] mock 没有遮蔽核心逻辑
[ ] 异常路径有明确断言
[ ] 用例名称能说明业务场景
[ ] 不引入无关测试库
[ ] 待确认规则已由负责人确认

• 能运行不等于有价值。
• 断言必须验证业务结果。
• 入库前要经过开发者和评审人确认。

✅ 十三、收尾：把测试生成做成团队质量入口

Codex 接入 API中转站 后，测试自动化是非常适合长期落地的方向。它不会直接替团队决定业务逻辑，却能持续提醒边界、异常、兼容性和回归风险。只要流程设计得当，它会成为代码合并前的一层质量入口。

落地顺序可以很清楚：先通过灵能API统一接入入口，再用 CC Switch 固化测试配置卡，随后从单元测试清单开始，逐步扩展到测试草稿、回归用例和失败复盘。每一步都保留人工确认，让生成内容真正进入工程闭环。

最终目标不是让测试数量看起来更多，而是让每一条测试都能解释它保护了什么风险。做到这一点，Codex 就不只是帮你写几段测试代码，而是在帮助团队把质量意识变成可执行的日常动作。

• 先生成测试点，再生成测试代码。
• 先确认业务规则，再把测试入库。
• 先沉淀失败复盘，再扩展自动化范围。