AI 测试生成工作流：从行为契约到有效回归保护

从调用者能观察到的输入、状态变化、输出或副作用开始，写清正常情况、边界、非法输入和错误行为。如果预期仍有争议，应先解决契约再生成断言。

要求代理先找到邻近测试并解释其 fixture、命名、辅助函数和目录约定。现有测试结构也是仓库契约的一部分。

稳定且确定的函数边界优先使用单元测试，组件契约使用集成测试，只有无法在更低层验证的用户路径才使用端到端测试。默认叠加每一层会增加维护成本，却未必增加新信号。

先按行为生成少量测试，审查名称与断言后再扩展。每个测试都应有明确的失败理由；只有序列化结果本身是稳定契约时才使用快照测试。

代理新增的 fixture 或 mock 都需要解释。隐藏的全局 setup 可能绕过测试声称覆盖的真实路径。

针对 Bug 修复，应在故障版本运行新测试，或临时撤销目标修正，确认断言检测到预期行为；随后恢复实现并验证通过，同时记录两次命令和结果。

如果测试在修改前后都通过，它仍可能有价值，但不能证明它保护了本次回归。

重复运行聚焦测试，再与相关测试和标准套件分片一起运行。检查顺序、时钟、随机数、临时文件、网络调用与清理，并确认失败信息能够指向目标行为。

保持测试意图清晰，合并重复 setup，并通过正常代码审查指定所有权。行为改变时应同步审查契约和测试，不能让代理静默改写预期结果去迎合回归。