2026 上半年，主要项目累计提交 7787 次（其中 newCodex 因为是 fork 项目，1922 次提交含上游历史；纯新增代码的项目是 yun-claude、yun-claw、new-openclaw 等）。提交数看起来多，但每个提交背后的价值不在数量，而在流程的可重复性。这篇文章把工作流写清楚。
流程的六个环节
整个开发周期分六步：需求澄清 → 设计文档审阅 → 拆实施计划 → 分阶段实现 → 代码审查 → 故障归档。每一步都有明确的输入输出和验证方式。
1. 需求澄清
开始前问清楚，不要猜。典型问题：这个功能要处理哪些用户场景？边界条件是什么？现有系统的哪部分会受影响？
这一步的产出是一份结构化的需求文档，包括功能范围、约束条件、风险假设。不是长篇幅的铺垫，而是一份清单式的澄清记录。
在 new-openclaw 项目里，这一步通常是用 Claude 的 superpowers:brainstorming skill 来展开。提问方式很重要：我会列出已知条件，然后问"这个设计下会遇到什么问题？"而不是"你觉得应该怎么做？"让 AI 在我的约束框架内工作。
2. 设计文档与人工审阅
这是整个流程里最关键的检查点。花一小时审一份 200 行的设计文档，比花五小时审一份 2000 行的代码便宜得多。而且回头修改设计的成本远低于修改实现。
new-openclaw 项目现有 30 份设计文档（specs 目录），每份文档都包括：
- 范围：这个设计覆盖什么、不覆盖什么
- 决策与权衡：为什么选这个方案，放弃了什么
- 接口契约：如果涉及多个模块，清晰定义每个边界
- 风险清单：已知的坑和防护措施
写完设计文档以后，我会读一遍、问几个"为什么"，然后提出修改意见。这一步排除了 80% 的方向错误。常见的修改方向有：缩小范围（第一个版本不用处理那么多边界情况）、明确约束（系统资源、网络延迟、并发数的假设）、补充防护（熔断、限流、幂等）。
3. 实施计划与 DoD 定义
设计文档定下来以后，拆成实施计划。计划的粒度是"一个可验证的功能单元"——通常是一个小时到半天的工作量，完成后能单独验证成功。
计划文档里必须写清完成定义（DoD，Definition of Done）。不是"实现登录功能"，而是"写出能拒绝无效格式的登录端点、覆盖单点故障下的重试、有端到端的冒烟测试"。
new-openclaw 项目现有 36 份实施计划（plans 目录），跨度从一周的 S0 阶段（骨架 + Mock 后台）到数周的 S1 阶段（真实业务后台）。每份计划都带着清晰的 checklist，这样我在执行时能随时问 Claude："下一步应该是什么？"而不是脑子里模糊地记着进度。
4. 分阶段实现与逐步验证
有了计划以后，按顺序实现。关键是每一步都要有验证：单元测试、集成测试、或者一个小的 end-to-end 冒烟测试。验证不通过就停在这一步，不往下推。
这一步会用到三个代理：
- superpowers:test-driven-development —— 先写测试，再写实现
- superpowers:subagent-driven-development —— 复杂任务拆成独立的子任务，并行推进
- superpowers:systematic-debugging —— 遇到测试失败，用这个代理追根溯源，不要盲目修改代码
实施过程中如果发现设计假设错了（比如某个接口响应时间远超预期，或者并发场景下出现竞态条件），就停下来回到第 2 步重新审视设计，而不是继续往下推。
5. 代码审查
实现完成以后，不是立即合并，而是过一遍 code-reviewer 代理。审查的重点不在代码风格（那个自动工具做），而在：
- 这段代码实现的是设计文档里的哪一部分？偏离了吗？
- 错误处理有没有遗漏？边界情况有没有考虑？
- 有没有意外改动无关的代码？
审查通常能抓住两类问题。一类是逻辑问题：某个条件判断漏了一个分支，或者并发场景下两个操作的顺序反了。另一类是"设计和实现对不上"：实现了一个设计里没提到的特性，或者某个约束（比如"这个值不能为空"）没在代码里强制。
6. 故障归档
系统上线以后，bug 是难免的。重要的是怎么处理它。new-openclaw 项目有一套 bug 知识库规范（CLAUDE.md 里定义），每个 bug 修好以后都要新建一份独立文档，包括：
- 现象和复现路径
- 根因分析：为什么会发生，触发链路是什么
- 修复方法：改了什么，为什么选这个方案
- 预防措施：代码改进、测试添加、还是构建期检查
80 份 bug 文档（截至 5 月中旬）不是问题的多，而是追根溯源的记录的多。下次遇到类似现象，能直接查库而不是重新排查。
三条铁律
1. 假设必须显式声明
不要猜。不清楚的地方就问，把问题写成澄清清单。"这个 API 能处理多大的请求体？"、"离线场景下要缓存多长时间？"、"错误重试间隔是指数退避还是固定时间？"。
这些问题看起来小，但决定了实现的复杂度和测试用例的多少。猜错了会导致前期设计精美，但方向错误，后面要推倒重来。
2. 修改必须精确
只改需要改的部分。这听起来像常识，但在实际工作中容易出现"顺手改一下边上的代码"的情况 —— 格式不规范了，变量命名不一致了，某个函数太长了，"顺便"重构一下。
结果是一个改动影响了五个文件，代码审查花了双倍时间，引入了新 bug 的风险。
规则是：改动必须对应需求的某一行。格式、风格、无关的重构，单独立项，不要混在功能改动里。
3. 成功标准必须可验证
"添加验证"这个说法是模糊的。改写成："写出一个测试用例，输入非法邮箱格式，验证 API 返回 400；输入合法邮箱，验证返回 200 和预期数据结构"。
每个 plan 文档里的 DoD 都是这样写的。拿一个阶段做例子：
S0 阶段的 DoD：
- openapi/api-v1.yaml 包含 spec 全部 11 个端点的字段级 schema，可被 swagger-ui 加载 ✓
- backend/ Mock 服务
npm start后能响应全部端点，返回符合契约的 mock 数据 ✓- launcher/ Rust 项目能编译为 launcher.exe，运行后完成所有阶段扫描并输出 diagnostics.json ✓
- 至少一个 end-to-end 冒烟测试通过（launcher 上报 → mock 后台收到 → 审计日志记录） ✓
每一条都能通过一个具体的命令来验证。"能工作"太模糊，"运行 npm test 且所有测试通过"才是可验证的。
流程失效的情况
这套流程在一个关键点会失效：需求本身没想清楚时。
我遇到过的例子是这样的。客户说"要支持 USB 存储检测"，这个需求很清楚，所以设计文档写了 20 多页，规划了三个阶段，列出了 30 多个 test case。然后两周后，客户补充说"哦对了，还要处理网络驱动器"。
这时前面的设计和计划都要回头改。检测逻辑复杂了，测试场景翻倍，阶段划分要调整。这不是流程的问题，这是需求的问题。流程本身反而帮助我及时暴露了这个风险 —— 如果没有设计文档，可能要到代码审查阶段，甚至系统上线以后才发现这个遗漏。
应对办法是在第 1 步（需求澄清）多花时间。列出你想到的所有场景，问"还有其他我忽略的情况吗？"。不是要求完全预测未来，而是把已知的不确定性显式写出来，而不是假设需求是固定的。
另一个失效的情况是设计和实现的沟通不畅。如果设计文档是给另一个人读的（或者给 AI 代理读的），但执行者没有理解透彻，实现出来会偏离设计。预防办法是在开始实施前，再过一遍设计文档，确认"我清楚要做什么"。
提交数字背后的故事
为什么能积累 7787 次提交？不是因为每次都在写新功能。真实的分布大概是：
- 功能实现：40%
- 设计文档编写和迭代：25%
- 测试编写：20%
- bug 修复与回归测试：15%
关键是这些提交都有上下文。每个提交的 message 都指向一个设计文档或一个 plan 的某个环节，或者一个 bug 记录。下次有问题要追查根因时，能快速定位到那个提交，看当时的设计决策是什么。
另外，有 80 份 bug 记录和 66 份设计 + 计划文档（30 specs + 36 plans）这件事本身说明了一点：文档不是负担，文档是工作的实际产出。代码只是文档的一个落地形式。
■