为什么测试失败分析需要单独成流程

很多团队接入 Codex 后，会在测试失败时直接复制整段日志给它。这个动作看似自然，但在真实项目里经常不好用：日志里有构建噪声、依赖警告、重复堆栈、无关测试输出和环境信息。模型看到的信息越杂，越容易把注意力放错地方。

灵能API负责提供稳定的 API中转站入口，CC Switch负责保存可复用配置，但测试失败能不能分析清楚，关键在输入质量。你要先让 Codex 看到“失败测试名、第一处错误、相关文件、最近改动、运行命令”，而不是让它在几千行日志里自己捞针。

• 测试失败分析不是日志压缩，而是把失败证据整理成可判断的信息包。
• 先找第一处失败，再看连锁失败，不要反过来。
• 先让 Codex 给原因假设和复测方案，再决定是否让它修改代码。

第一步：确认中转站接入稳定

测试失败分析通常比普通问答更长，因为它会包含命令输出、错误栈、相关源码和最近改动摘要。所以开始之前，先通过 https://www.lnsns.com/ 进入灵能API，确认当前账号、*ase **L、模型权限和账户状态正常。不要在连接不稳定时直接跑长日志分析。

建议先用空目录短任务验证一次。短任务能返回，说明基础链路可用；再进入真实项目做日志分析。这样可以避免把“中转站未连通”和“测试本身失败”混在一起排查。

mkdir codex-test-analysis-check
cd codex-test-analysis-check
codex "请只回复：测试分析链路可用。不要创建、修改或删除文件。"

• 短任务失败时，先检查 *ase **L、Key、模型 ID 和**。
• 短任务通过后，再处理真实测试日志。
• 不要一开始就把完整测试输出交给 Codex。

第二步：建立专用分析配置卡

在 CC Switch 里建议单独建立一张“灵能API-Codex-****-Analysis”配置卡。它只用于测试失败、错误栈解释和复测建议，不和日常代码生成、长文档写作、CI 预检混用。配置卡分开后，团队更容易管理模型选择、任务边界和用量。

这张卡的默认规则应该偏保守：只读、先分析、后建议、不直接改文件。等 Codex 给出原因判断和修复路径后，再由开发者确认是否进入写入阶段。测试失败场景很容易误伤，因为一个错误可能由环境、数据、Mock、时区、缓存或依赖版本造成，不一定是代码逻辑本身。

• 配置卡名称要能看出用途，不要只写 default 或 test。
• 备注里写模型、用途、验证时间和只读边界。
• 真实 API Key 不写在配置卡备注和文章截图里。

第三步：核对接口字段和模型选择

测试失败分析对模型能力有要求，但不代表所有失败都要用最高能力模型。语法错误、断言差异、路径问题、环境变量缺失，通常用日常模型就能定位；跨模块逻辑错误、复杂异步问题、兼容性回归，才适合切到更强模型。

通过 https://www.lnsns.com/ 查看灵能API接入信息时，可以顺手维护一份模型策略：短错误栈用日常卡，长日志和跨模块失败用增强卡，批量失败先裁剪再决定模型。这样既能控制成本，也能提升分析稳定性。

• 单个断言失败：优先日常模型，输入保持短。
• 多个模块连锁失败：先找第一处失败，再决定是否增强模型。
• 环境类失败：先核对命令、变量、路径和依赖版本。

**步：收集最小失败信息包

给 Codex 的输入不要从完整日志开始，而是从最小失败信息包开始。信息包建议包含五项：运行命令、失败测试名、第一处错误栈、相关文件路径、最近变更摘要。只要这五项清楚，Codex 通常就能给出第一轮判断。

最小失败信息包：
1. 运行命令：npm test -- user.service.spec.ts
2. 失败测试名：should reject expired token
3. 第一处错误：Expected 401, received 200
4. 相关文件：src/user/user.service.ts、src/auth/token.ts
5. 最近变更：调整 token 过期判断和 mock 时间

如果第一轮信息不足，再让 Codex 明确提出需要补充哪段源码或哪段日志。不要主动把整个仓库、完整日志和所有测试文件都丢进去。好的分析流程应该是逐步补证据，而不是一次性堆材料。

• 先给第一处错误，不给所有重复错误。
• 先给相关路径，不让模型猜文件位置。
• 先给最近变更，帮助判断回归来源。

✂️ 第五步：错误栈要裁剪，不要整段复制

错误栈裁剪有一个简单原则：保留第一处失败、调用链核心、断言差异、文件路径和行号；删除重复堆栈、安装警告、无关模块输出和颜色控制字符。裁剪后的日志越干净，Codex 越容易给出**证结论。

建议保留：
- test name
- expected / received
- error message
- file path and line num*er
- relevant stack frames

建议删除：
- repeated stack *locks
- unrelated warnings
- full dependency install logs
- colored terminal control characters

如果你不确定怎么裁剪，可以先让 Codex 做“日志整理员”，但仍然要限定范围：只整理下面 200 行日志，找出第一处失败和相关路径，不分析业务原因。整理完成后，再开启第二轮原因分析。

• 裁剪不是美化日志，而是保留判断所需证据。
• 不要删掉行号和文件路径，它们是定位问题的关键。
• 重复错误只保留首个和一个代表样本。

第六步：先让 Codex 做只读原因分析

把最小失败信息包准备好后，第一轮只让 Codex 做原因分析，不让它修改文件。提示词要写清楚输出格式：可能原因、证据、需要补充的信息、建议复测命令。这样你得到的是判断框架，而不是直接改代码。

请只根据下面的测试失败信息做分析，不要修改文件。
输出格式：
1. 最可能原因
2. 证据来自哪几行日志或哪几个文件路径
3. 还需要补充哪些信息
4. 建议先运行哪条复测命令
5. 如果要修复，建议从哪个文件开始看

如果 Codex 的结论没有引用具体证据，要让它重新回答。测试失败分析不能只靠“可能是异步问题”“可能是 mock 不一致”这种泛泛判断，必须回到错误栈、断言差异和文件路径。

• 第一轮只读分析，不改文件。
• 结论必须绑定证据。
• 上下文不足时要让 Codex 明确要哪些材料。

第七步：把修复建议拆成**证动作

原因分析之后，不要直接让 Codex 大范围修改。先让它把修复建议拆成小动作：改哪个文件、改哪段逻辑、为什么这样改、改完运行什么测试、如果失败怎么回退。修复建议越具体，越容易人工判断是否可靠。

对于测试失败，最稳的修复闭环是“小改动 单测复测 相关测试复测 全量测试观察”。如果 Codex 建议一次性重构多个模块，要让它先解释为什么必须跨模块改。很多测试失败只需要修正 mock、时区、边界条件或断言，不需要动核心逻辑。

修复计划模板：
- 修改文件：src/auth/token.ts
- 修改目标：统一 token 过期判断边界
- 修改理由：当前测试 expected 401 received 200，说明过期边界未命中
- 第一条复测：npm test -- user.service.spec.ts
- 第二条复测：npm test -- auth
- 回退方式：恢复本次改动并重新查看 mock 时间

• 修复建议必须带复测命令。
• 一次只改最小必要范围。
• 涉及核心逻辑时先人工确认，再执行修改。

第八步：控制长日志成本和触发频率

测试失败分析很容易变成高频消耗。每次保存、每次提交、每次测试失败都自动调用 Codex 分析完整日志，成本会很快上来。更合理的方式是：短失败手动触发，CI 连续失败再触发，长日志先裁剪后触发。

通过灵能API查看账户状态时，可以把测试分析任务单独归类。比如日常本地失败由开发者手动发起，CI 主分支失败由负责人触发，夜间全量测试失败只取第一处失败样本。这样不会因为自动化反复重试，把额度花在重复日志上。

• 短日志可以直接分析，长日志先裁剪。
• CI 失败不要无限重试调用 Codex。
• 批量失败先找第一处根因，再看后续连锁错误。

第九步：把分析结果沉淀成问题记录

一次测试失败解决后，不要只留下最终补丁。建议把 Codex 的分析结果整理成问题记录：失败命令、失败现象、根因、修复动作、复测命令、是否需要补测试。这样下次遇到类似问题时，不需要重新从日志里挖。

问题记录里同样不要放完整密钥、完整生产日志或客户数据。灵能API的接入入口和配置思路可以写，敏感凭证不能写。测试分析记录应该帮助团队复盘技术问题，而不是制造新的信息泄**。

问题记录：
失败命令：npm test -- user.service.spec.ts
失败现象：过期 token 返回 200，而不是 401
根因：mock 时间和过期判断边界不一致
修复动作：统一边界判断，补充等值边界测试
复测命令：npm test -- user.service.spec.ts && npm test -- auth
后续动作：把 token 边界规则写进测试说明

• 问题记录要能让后来的人复现。
• 根因和修复动作分开写，不要混成一句话。
• 复测命令必须保留，方便验证修复是否真的有效。

第十步：形成团队版测试分析模板

当团队多次使用 Codex 分析测试失败后，应该把有效提示词固定下来。模板可以按测试类型拆分：单元测试、集成测试、端到端测试、构建失败、依赖冲突。不同类型关注点不同，不要用一个万能模板处理所有失败。

单元测试模板关注断言和函数边界，集成测试模板关注服务依赖和数据准备，端到端测试模板关注环境、浏览器、网络和等待条件，构建失败模板关注依赖版本、脚本和平台差异。模板越贴近场景，Codex 输出越少套话。

• 单元测试：关注输入、输出、边界和 mock。
• 集成测试：关注数据库、服务依赖、事务和清理。
• 端到端测试：关注等待条件、选择器、网络和环境状态。
• 构建失败：关注依赖版本、脚本参数和平台差异。

✅ 收尾：让测试失败从噪声变成证据

Codex 接入 API中转站后，测试失败分析的质量取决于流程，而不只是模型能力。灵能API提供稳定入口，CC Switch沉淀测试分析配置卡，最小失败信息包和错误栈裁剪负责把噪声变成证据。这样 Codex 才能真正帮助团队定位问题，而不是在长日志里绕圈。

建议从下一次测试失败开始实践：先确认灵能API链路可用，再收集运行命令、失败测试名、第一处错误、相关文件和最近变更；让 Codex 先做只读原因分析，再拆修复计划和复测命令。这个闭环跑顺以后，测试失败会从烦人的红色输出，变成可复盘、可沉淀、可持续优化的工程材料。