GitHub 上的 EvanFlow 项目，做了一件很“反提速”的事。

在 Claude Code 里输入一句 let's evanflow this，它不会鼓励模型一路写到底，而是把任务带进一套固定流程：brainstorm → plan → execute → tdd → iterate → STOP。

这就有意思了。AI 编程工具这两年一直在比谁更快、更自动，EvanFlow 却在给 Claude Code 加停顿点。我的判断是，它不是在卖“更强的模型能力”，而是在补 AI 编程最容易缺的一块：过程约束。

EvanFlow 解决的不是写不写代码，而是怎么停下来

EvanFlow 的定位要先说清楚。

它是 Claude Code 的流程 / 技能插件，不是通用 AI IDE，也不是独立 coding model。按项目说明，它由 16 个 Claude Code skills 和 2 个自定义 subagents 组成。

它的主流程很直白：

环节EvanFlow 要 Claude Code 做什么对开发者的影响
brainstorm澄清意图，提出 2-3 个方案避免 AI 没听懂就开改
plan读文件结构，拆任务让人先看改动范围
execute按计划执行并做内联验证减少随手扩散修改
tdd垂直切片、先失败测试、最小实现用测试约束生成结果
iterate读 diff、跑检查，最多迭代 5 次防止无限修补、越改越偏
STOP迭代后停止把最终决定权交回人

几个约束比流程名更关键：设计要用户批准，计划要用户批准，迭代结束后必须 STOP。

项目还明确写了几个“不做”：不自动 commit，不自动 stage，不自动发 PR。

这说明 EvanFlow 的作者并不把 Claude Code 当“无人驾驶工程师”。它更像一个 conductor，负责组织节奏，而不是 autopilot，替人接管方向盘。

对正在用 Claude Code 的开发者，这个差别很实际。以前你可能给一段需求，等 AI 改完再看 diff。用了 EvanFlow 后，更合理的动作是：先让它出方案和计划，审批后再写；写完先看失败测试和最小实现，再决定要不要进入下一轮。

快是快了，但不能一路绿灯。

它把 TDD 塞回 AI 编程流程里

AI 写代码最麻烦的地方，不是它完全不会写，而是它经常写得“看起来差不多”。

文件路径可能编错，库 API 可能误用，修改范围可能变大。上下文一长，前面确认过的设计也可能被忘掉。

EvanFlow 的处理方式比较保守：不赌模型一次写对，而是把 TDD 放进流程。

这里的 TDD 不是口号。它强调几件具体动作：

  • 做 vertical slice，只切一条能工作的纵向路径；
  • 先写失败测试；
  • 再做最小实现；
  • 通过 public interface 验证行为，不去测内部实现细节。

这套要求对个人开发者有点“慢”。但对团队代码库，它反而省心。

因为团队真正担心的通常不是“AI 有没有产出代码”，而是三件事：改了哪里，为什么这么改，怎么证明没跑偏。

这也是 EvanFlow 和一些端到端自动代理的分界。端到端代理常见叙事是“给 issue，等结果”。EvanFlow 的叙事更克制：给需求，但中间要审批；给实现，但测试先说话；给迭代，但到点就停。

这个选择不炫，但更接近真实工程。

谁该用，谁该先观望

最相关的读者其实就两类。

一类是已经在用 Claude Code 的个人开发者。你可以把 EvanFlow 当成一套更硬的工作习惯：不要直接让 AI 改完整个功能，先让它 brainstorm 和 plan；计划没看懂，不进 execute；测试没失败过，不急着相信实现。

另一类是技术团队，尤其是已经允许 AI 改代码、但还没形成流程规范的团队。它们更应该关注 EvanFlow 的检查点，而不是把它当效率神药。

更具体一点，团队可以这样处理：

使用场景更合适的动作不建议的动作
单个明确功能用 EvanFlow 拆计划、写测试、做最小实现让 AI 一口气重构大块代码
多个独立开发单元3 个以上独立单元时，再考虑 coder / overseer 并行为了“多代理”而强行并行
团队代码库把 STOP、审批、测试接入现有 review 和 CI让插件绕过团队流程自动提交
采购或推广工具先小范围试在功能开发任务上直接承诺节省工时或降低缺陷率

并行模式也要看清楚。

当计划里有 3 个以上相互独立的开发单元，EvanFlow 可以使用 coder / overseer 编排。coder 负责具体单元，overseer 只读审查，不能改代码；集成 overseer 则在触点上跑具名集成测试。

这个设计的重点不是“多代理更热闹”，而是权限分离。写代码的人写，审查的人只读。古话说“事有分职”，放在 AI 代理里也适用。

它的边界同样清楚。

目前能确认的是项目本身、README 里的流程说明，以及安装方式。例如通过 Claude Code plugin marketplace 执行 /plugin marketplace add evanklem/evanflow 和 /plugin install evanflow@evanflow。

至于真实团队采用率、节省多少工时、缺陷率下降多少，项目没有给出可验证数据。README 中引用的行业研究数字，也不能直接当作 EvanFlow 的实测结果。

所以接下来不该只看 star 数。更该看两个变量：Claude Code 用户愿不愿意为“多停几次”付出流程成本；团队能不能把它的审批、测试、STOP 接进自己的 CI 和 code review。

如果接不进去，它只是一个好看的流程提示器。接得进去，它才可能变成 AI 编程的护栏。