最近用 Codex 做稍微复杂一点的需求时，我一直遇到几个问题：
- 一个很小的需求，做着做着就开始顺手重构旁边的模块；
- 原本只需要跑几个定向测试，最后不断补边界用例、全量测试，验证范围越来越大；
- 会话变长、压缩或者重新开一个会话后，之前做到哪、哪些已经确认过，又要重新从代码和聊天记录里推断。
一开始我的解决办法也是在 Prompt 里反复强调：
不要扩大范围 不要做无关重构 只运行必要的定向测试 完成需求后就停止
确实有用，但这些约束本质上还是存在聊天上下文里。
所以后来做了一个开源项目：Dev Flow
GitHub：
https://github.com/Innocent-children/dev-flow
它的思路比较简单：
把开发任务本身的状态从聊天记录里拿出来，单独持久化。
一个 Task 会保存：
- 原始需求和明确不做的内容；
- 当前处于需求、设计、实现、测试还是交付阶段；
- 本次允许做多少验证；
- 已经完成了哪些证据；
- 当前允许进入哪些下一步；
- 会话中断或者一次写操作结果不确定时，应该恢复、阻塞还是安全重试。
默认流程大致是：
REQUIREMENTS → DESIGN → TASKS → IMPLEMENT → TEST → COMPREHENSION_REVIEW → DELIVERY → DONE
如果测试发现实现有问题，就明确返回 IMPLEMENT ；如果代码虽然能跑，但明显过度复杂，可以进入 REFACTOR ，然后重新经过 TEST 。
Codex 还是负责读代码、改代码、执行命令。
Dev Flow 本身不是另一个 Agent ，也不是多 Agent 编排器，它只是给一个开发任务加了一层本地的流程状态和恢复机制。
目前已经支持 Codex ，也做了 DeepSeek Harness Adapter 。状态由本地 Go Core + SQLite 保存，通过本地 MCP 和 Host 交互。
项目现在还比较早，我发出来主要也是想验证一个问题：
大家实际使用 Codex 做中大型需求时，会不会经常遇到“范围越做越大、测试越跑越多、换会话后丢进度”这几个问题？
如果这个问题确实普遍存在，我想继续把 Dev Flow 往“尽量少增加流程负担，但能把长任务控制住”的方向做。
如果有人愿意拿真实仓库试一下，也欢迎直接提 Issue 。
哪怕反馈是“这个东西比问题本身还麻烦”，对我也很有价值。
Select Language