这两天优化了自己在用的开发工作流，好处是比 OpenSpec 的上下文维护轻量得多，但不丢框架深度和交付细节。
经过测试，在较短的开发周期下，已经能体现较 OpenSpec 超过 -30% 的 token 成本、-48% 的 cache-read 以及 -51% 的文档维护。仓库里还放了一次单会话的开放任务 A/B，方向和这个一致（模型成本 −29.9%、输入+输出 tokens −36.2%、cache-read −48.6%、留存文档 −51.6%）。
同时，记账与开发完全分离，确保开发过程不会被过期设计或旧想法污染。
它是什么
一套面向独立开发者的五步功能开发循环，以 skill 的形式加载到 Claude Code、Codex、pi、DeepSeek Harness 等编码 agent 里：
- 设计澄清 + 意图卡
- 单个能独立验收的端到端切片
- 实现 + 验证
- 独立审核（普通功能一次；框架级改动加一次结构审）
- 验收 + 合并
和常见的规格驱动工具不同，它不维护 proposal / tasks / archive，仓库里只保留现行设计：设计变了就原地覆盖或删除，功能收尾就删卡。决策历史（包括被否掉的方案）写进项目之外的私有 git 账本；强隔离下，dev 容器没有账本挂载、没有路径、没有凭证，开发 agent 读不到。
这条边界是文件系统级的，不是 prompt 约定。README 里把隔离分成弱 / 中 / 强三档，明确写了只有容器方案才叫"保证"。
最新 A/B：省在哪
同一个 records CLI 开放任务、每个 skill 一个会话、最终交付物盲评：
| 相对 OpenSpec | Dev-circuit-ultra | OpenSpec | 差异 |
|---|---|---|---|
| 模型成本 | $0.0743 | $0.1060 | −29.9% | |
| 输入 + 输出 tokens | 72,308 | 113,337 | −36.2% |
| 缓存读取 tokens | 1,891,968 | 3,678,333 | −48.6% |
| assistant 轮次 | 39 | 50 | −22% |
| 留存文档 | 2 文件 / 132 行 | 3 文件 / 273 行 | −51.6% |
| 盲评总分（30） | 27 | 26 | +1 |
欢迎大家一起探讨，跟大家学习！
Select Language