EvoLoop 目标规格测试驱动开发

要解决的问题

AI 辅助开发最典型的失败不是模型不会写代码，而是它在没人追问时会假装需求已经清楚。一句“帮我加个导出功能”，模型可能直接动手，把“导出成什么格式、失败怎么提示、是否需要权限控制”这些歧义全部埋进实现里。更隐蔽的是自我合理化：模型会悄悄告诉自己“太简单了不用测试”“就改一行不用写契约”，于是流程被绕过，事后也无法追溯。EvoLoop 针对的正是这两类问题。

核心思路

• 对抗性收敛：不是被动“理解需求”，而是故意尝试曲解需求，逼出隐藏的歧义，在动手前把话说清楚。
• 可执行契约：以 GIVEN/WHEN/THEN 场景作为后续所有阶段的唯一依据，相当于整个流程的“宪法”，设计与实现都不得偏离。
• 五层嵌套 Loop：Inner(TDD) → Task(review) → Phase(cross-check) → Project(post-mortem) → Meta(harness evolution)，从单条测试到工作流自身的演进逐层约束。
• 自适应深度：同一套流程按任务复杂度自动切换 brief / standard / comprehensive 三档。

关键步骤

1. 分类：根据请求特征选择 playbook（feature / bugfix / refactor / explore），用户显式指定优先于自动检测。
2. 先讨论再动手：进入 evoloop:define 的纯对话模式，做上下文画像、追问澄清、对抗审查、场景原型，不创建任何文件，直到用户确认。
3. 环境隔离：确认后才创建 git worktree，所有产物写入 docs/evoloop/{change_id}/ 下的 contract.md 与 .state.json。
4. 流水线执行：按 define → plan → implement → verify → finish → archive → reflect 调用子技能，每个 phase 之间有 gate 校验，loop 预算超过 80% 提醒，超出则停止并升级给用户决策，禁止死循环。
5. 断点恢复：会话中断后读 .state.json 的 current_phase 继续，已完成的 phase 不重跑。

适用边界与注意点

• explore playbook 是例外：不建 worktree、不建 change 目录，产物直接落在对话里。
• 技能内置了一张“合理化借口对照表”（“后补测试也一样”“手动测过了”等），规则明确写着：违反字面就是违反精神，没有措辞上的漏洞可钻。
• 平台适配针对 Claude Code 与 CodeBuddy，启动时检测结果存入 state file 供各 phase 读取。
• 这套流程有明显开销：契约、归档、对抗审查都需要真实上下文支撑，适合可追溯性要求高的功能开发与重构，小改动用 brief 档即可。