cekura-fixing-prod-issues

修复生产环境调用问题

完整工作流——先调试，修复前先复现，全面测试，然后提交 PR。

Phase 1      Phase 2         Phase 3     Phase 4        Phase 5        Phase 6
Debug   →   Reproduce   →   Fix    →   Verify    →   Regression  →   PR
Understand   Confirm bug     Write the   Same eval      Happy paths    All result
root cause   on Cekura       code fix    must PASS      + edge cases   URLs in PR
             BEFORE fix      + commit    now            pass too

6 个阶段

阶段	文件	处理内容
1	phase1-debug.md	获取生产环境调用和日志，找出根因，并与用户确认
2	phase2-reproduce.md	构建评估器，附加指标并运行——修复前，评估必须失败
3	phase3-fix.md	编写代码修复并在本地提交
4	phase4-verify.md	重新运行同一评估器——此时评估必须通过
5	phase5-regression.md	测试所有受影响的正常流程和边界情况
6	phase6-pr.md	创建 PR，并附上所有 Cekura 结果 URL

---

严格规则——开始前请阅读

这些规则不可妥协。未满足条件前，不得通过关卡继续操作。

规则 0——使用与生产环境调用相同的连接方式，不得例外。

每项复现、验证和回归测试都必须在 Cekura 上进行完整的端到端模拟，并使用 Agent 配置的相同传输方式。 获取 Agent 记录（GET /test_framework/v1/ai-agents/{id}/）以确认其传输方式。最有可能是电话，但应以 Agent 的实际配置为准。

❌ 文本模式绝不是有效的替代方案。❌ 不要在不同阶段切换传输方式。

问题存在于真实调用路径中；只有通过相同方式进行模拟，才能确认问题。

规则 1——各阶段必须按顺序进行，不得跳过。

每个阶段都有一道关卡。不能凭假设通过关卡——必须有证据。设定这些顺序是因为：

• 不理解根因，就无法编写有效的修复（阶段 1 关卡）
• 未先以受控方式证明问题存在，就无法信任修复（阶段 2 关卡）
• 修复验证通过前，回归测试就无从谈起（阶段 4 关卡）

规则 2——阶段 2 是最难通过的关卡，务必认真对待。

复现问题是最关键的步骤。在 Cekura 上确认评估明确失败且指标评分显示存在失败之前，不得进入阶段 3。 如果无法确定问题是否确实已复现，请停下来询问用户。不要猜测。

规则 3——有疑问时就询问。

如果不确定该使用哪些指标、根因是否正确、边界条件是否合理，或结果是否模棱两可——请停下来询问用户。错误的假设会浪费整个工作流。

规则 4——阶段 5 完成前，绝不推送代码。

在阶段 3 进行提交。只有阶段 5 的所有回归测试通过后，才能推送代码。