AI 辅助编程工具的普及让代码生成效率大幅提升，但随之而来的质量问题也日益凸显。根据 DAPLab 与哥伦比亚大学的研究，编码代理存在五大失败模式：幻觉动作、范围蔓延、级联错误、上下文丢失、工具误用。这些问题导致企业在生产环境中部署 AI 编码工具时顾虑重重。EvanFlow 作为专为 Claude Code 设计的 TDD 驱动迭代反馈循环，通过结构化的技能编排与硬性规则约束，为 AI 编码工作流提供了可落地的工程化方案。
反馈循环的核心架构
EvanFlow 的设计理念是将 AI 编码从「自动驾驶」模式转变为「 conductor」模式 —— 即有节制的协作而非完全放手。完整的反馈循环遵循固定流程：brainstorm（头脑风暴）→ plan（规划）→ execute（执行）→ tdd（测试驱动开发）→ iterate（迭代）→ STOP。在这个循环中，开发者始终掌握控制权，AI 代理在关键节点停下来等待人工批准。
这个架构与传统 AI 编程助手的本质区别在于「检查点」（checkpoint）机制。在 brainstorm 阶段，AI 会澄清需求并提出 2 到 3 种实现方案，同时进行嵌入式「烤问」（grill）即压力测试，最终由开发者批准设计方案后才进入下一阶段。plan 阶段同样如此 ——AI 先绘制文件结构图，验证模块划分是否遵循深模块原则，只有获得计划批准后才开始执行。这种门控机制有效防止了 AI 沿着错误方向一路狂奔的问题。
十六个技能的职责分工
EvanFlow 包含十六个预置技能，分别承担不同职责。默认循环包含五个核心技能：evanflow-brainstorming 负责需求澄清与方案对比，evanflow-writing-plans 负责任务拆解与文件结构规划，evanflow-executing-plans 负责按序执行任务并内联验证，evanflow-tdd 负责垂直切片式的测试驱动开发，evanflow-iterate 负责自我审查与质量检查。特殊用途技能则覆盖调试、重构、代码审查、PRD 撰写等场景。跨域技能 evanflow-compact 负责长会话的上下文管理，在检测到上下文漂移迹象时触发主动摘要。
值得特别关注的是 evanflow-tdd 的实现方式。它严格遵循垂直切片原则：一次只写一个失败的测试，然后编写最少的实现代码让测试通过，循环往复。这种方式与许多 AI 工具「先生成完整功能再补测试」的做法形成鲜明对比。测试通过公共接口验证行为，这样在后续重构时测试仍然有效。垂直切片的核心优势在于每个切片都是可运行的增量，开发者可以随时看到工作进展，而不是面对一个长期处于「Almost Done」状态的功能。
双子代理的并行编排
当规划涉及三个以上相互独立的单元时，EvanFlow 会自动切换到并行编码模式，通过双子代理架构实现：每个编码单元分配一个 evanflow-coder 子代理和一个 evanflow-overseer 监督代理。coder 代理拥有完整的代码修改权限（Read、Edit、Write、Glob、Grep、Bash、TodoWrite），而 overseer 代理仅拥有只读权限（Read、Grep、Glob），物理上杜绝了它直接修改代码的可能。
这种设计的精妙之处在于「合约即测试」：每个 coder 与 overseer 之间通过命名化的集成测试建立合约，测试同时位于两端的代码库中。任何接口漂移都会导致测试失败，开发者无需手动检查两边是否保持一致。集成监督代理会在每个接触点运行这些测试，确保并行开发不会导致集成灾难。
双子代理的工具限制也内置了安全防护。coder 代理的系统提示明确禁止执行 git 操作、禁止修改超出范围的代码、禁止虚构值。如果不确定某个文件路径或 API 名称，代理会主动停下来询问而不是猜测。根据行业数据，值虚构是 AI 编码代理最危险的失败模式 —— 一个看似合理的错误路径可能导致数小时的调试浪费。
断言正确性的工程保障
EvanFlow 在设计中特别关注了一个被广泛忽视的问题：根据 arXiv 2402.13521 论文的研究，62% 的 LLM 生成测试断言是错误的。这些错误的断言会让有缺陷的代码通过测试，从而破坏测试的价值。EvanFlow 在 evanflow-tdd 和 overseer 审查中都内置了「断言正确性警告」机制。
这个机制的工作方式是：代理会显式检查 —— 如果实现中有恰好一个字符的 bug，这个断言还能通过吗？如果答案是肯定的，断言就被判定为不够严格。代理会要求重新设计断言，直到它真正能够捕获预期的错误。这种防御性检查显著提升了测试的可靠性，让 TDD 的核心承诺 —— 测试作为行为的可执行规范 —— 得以兑现。
上下文漂移的主动防控
长会话中的上下文漂移是另一个关键挑战。根据 2026 年 Anthropic Agentic Coding Trends Report，约 65% 的企业 AI 编码失败可以追溯到上下文漂移而非 token 耗尽。EvanFlow 通过 evanflow-compact 技能实现主动管理。
这个技能包含一套完整的漂移症状检查清单：当代理开始重新询问已经确定的问题，或者开始与之前的决策产生矛盾时，就是触发上下文压缩的信号。压缩策略包括在清晰的边界处进行主动摘要、提取关键决策到独立的上下文文件、以及重置会话状态到已知的良好点。与其等待问题出现再补救，EvanFlow 选择主动监控并预防。
Five Failure Modes 的显式审查
在迭代阶段，EvanFlow 强制执行 Five Failure Modes 检查清单。这个清单逐项验证：是否存在幻觉动作（AI 声称做了但实际没做的事）、是否存在范围蔓延（功能边界悄悄扩大）、是否存在级联错误（修复一个问题引入了三个新问题）、是否存在上下文丢失（早期讨论的约束被遗忘）、是否存在工具误用（用错误的方式调用 API）。每次迭代都会进行这个检查，形成显式的质量门禁。
迭代阶段还有硬性的次数上限：最多五轮。这个限制看似保守，实际上是在效率与风险之间的工程化取舍。没有上限的迭代可能导致 AI 在细节中迷失方向，或者在错误的解决方案上越走越远。五轮迭代足以完成大多数增量功能的改进，同时为人工干预留出机会。
破坏性操作的自动拦截
EvanFlow 捆绑了一个名为 block-dangerous-git.sh 的 PreToolUse hook。当开发者通过 Bash 工具执行 git push、git reset --hard、git clean -f、git branch -D、git checkout .、git restore . 等破坏性操作时，hook 会自动拦截并阻止执行。这个 hook 在插件安装路径下自动激活，无需手动修改 settings.json。
这个设计体现了 EvanFlow 的核心理念：AI 代理永远不应该在未经明确指令的情况下修改版本历史。所有 git 写操作都必须由开发者在当前对话轮次中显式请求。这种约束在并行开发场景中尤为重要 —— 当多个 coder 代理同时工作时，防止某个代理意外覆盖他人的成果是基本的工程纪律。
工程落地的关键参数
在项目中启用 EvanFlow 的推荐方式是使用 Claude Code 插件市场：/plugin marketplace add evanklem/evanflow 后跟 /plugin install evanflow@evanflow。安装完成后，技能以 evanflow: 命名空间呈现，如 /evanflow:evanflow-go。一个入口指令即可触发完整循环："let's evanflow this — I want to add a small feature that does X"。
可选依赖包括 jq（用于 hook 脚本解析 JSON）和 chromium（用于 evanflow-iterate 的无头截图验证）。如果 jq 缺失，guardrail hook 会静默失败，破坏性 git 操作将不会被拦截。视觉验证步骤会在 chromium 不可用时优雅降级，提示开发者手动验证。
在定制层面，每个技能的 <frontend> 和 <backend> 占位符需要替换为实际项目路径。项目的质量检查命令（typecheck、lint、test）应在 CLAUDE.md 中明确记录，这样技能才能在验证阶段调用正确的检查。EvanFlow 的技能被设计为可编辑的起点而非不可更改的教条，根据项目实际调整是预期内的使用方式。
从工作流到工程文化
EvanFlow 不仅仅是一套技能集合，它代表了一种 AI 辅助编程的工程哲学：将 AI 视为需要结构化约束的协作者，而非可以自主决策的执行者。通过将 TDD 的核心纪律（测试先行、小步增量、持续验证）嵌入到 AI 工作流中，EvanFlow 试图解决一个根本问题 —— 如何在保持 AI 编程效率的同时，确保代码质量和工程可控性。
对于已经在使用 Claude Code 的开发团队，引入 EvanFlow 的成本相对较低 —— 插件形式安装、技能即插即用、存量项目无需大规模重构。但更深层的收益在于团队工程文化的演进：当每个功能开发都经历设计审查、计划批准、测试驱动、迭代检查的完整循环时，代码质量的提升是附带的结果而非额外的努力。
资料来源：EvanFlow GitHub 仓库（https://github.com/evanklem/evanflow）