BWorkflow：给人 + Claude Code 团队用的项目交付“规则层”

分享一个我自己总结的软件研发工作流，在Claude Code上基于这个工作流严格把控产品研发质量。也是因为一些工作痛点，以及自己结合cc开发了一些工具后，沉淀的一套工作流。

使用也很简单，在研发项目根目录，把包解压到对应目录，然后根CLAUDE.md增加依据规则关联，就可以用起来。具体在gitee上的部署指南，给你的Claude Code看，它就会懂。

BWorkflow 是一套面向「人 + AI 编程助手」团队的项目交付规则层，通过显式

gate、可验证的退出标准和最小化的人为决策点，让中小规模项目在高速迭代中仍保持可控。

这套流程不是发明，而是复原------复原软件工程面对复杂交付时本该有的样子。以下各个阶段都不是创新，只是忠实地遵循了这条早已被反复验证的路：分阶段是为了把复杂性拆开、让它可被逐段消化，而每一个阶段，都在回答一个具体的质量问题。

问题从来不是"没人知道该这么做"------TDD、代码审查、设计先行，这些是写进教科书的常识。真正的问题是人守不住：在实现落地的疲惫里、在赶工的压力下、在"就这一次先跳过"的侥幸中，纪律恰恰在最该坚持的地方被一点点磨掉。这份不可控，过去没有好的解法，只能靠自觉和意志力去扛。

Agent Coding 第一次让它有了确定性的解法：AI 不会累、不会为赶进度而偷工，而明确的 gate 让"跳过"在结构上就不可能------机器门禁不绿就进不去，人该拍板的地方机器代不了。它把"人会跳过"这个最大的不可控，降到了最低。

所以，哪怕你不使用 BWorkflow 的规则与 runtime，这套流程本身依然成立、依然是一份值得依循的指导；BWorkflow 做的，只是借着 AI 与 gate，把这份人人认同却难以坚持的纪律，第一次变得可执行、可裁决、不可绕过。

解决问题

AI 写代码越来越快，但"方向跑偏、设计没锁就动手、验收标准靠感觉、同一个 bug 反复修"的问题反而更突出了。

BWorkflow 不是项目管理软件，也不是一套提示词模板。它是一套用 Markdown + Node.js runtime 落地的交付规则层：

阶段清晰：S0 定级 → S1 调研 → S2 设计锁定 → S3 Spike → S4 开发 → S5 验证 → S7 总结；轻量项目走 S0 → SL → S4 → S5。
三角色分工：人只做不可逆的价值判断；Agent 负责执行与事实核查；Gate（bwf.js）机械守卫阶段边界。
三档判定： $M-cmd$ 机器命令退出码 0 即过， $V$ 工具说不清时请人选， $H$ 涉及方向/资源/风险必须由人拍板。
规则与项目分离：规则层在 BWorkflow 仓库，目标项目只复制 runtime/ 为 .b_workflow/，由 skill 生成报告、由 bwf.js 维护状态。

核心就一句话：不是让 Agent 变得更聪明，而是让"错的东西过不了 gate"。

建议阅读顺序：

也在持续积累自己的Agentic Engineering的实践笔记，目前积累在飞书中，里面有更详细的BWorkflow介绍：
https://ccnz3jgnolv7.feishu.cn/wiki/Vtg2wXbA1ihF3Kkam97cyRPKnVh

我自己在积累自己的AI笔记知识库，也算是一个"成长"的知识库，里面记录了我的学习笔记、落地实践、实践思考，以及一些学习的个人心得。主要想让自己保持"输出"的习惯，持续积累，能够逐渐产出更优质的资源。