做了一个给 Codex 保存任务边界和开发进度的开源工具

[xiaomochao]

最近用 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 。

哪怕反馈是“这个东西比问题本身还麻烦”，对我也很有价值。