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”。
链接
🔗 Gitee 仓库:https://gitee.com/being_xyk/bworkflow
建议阅读顺序:
- README.md
- reference/KEY-ELEMENTS.md
- reference/BWorkflow-diagram.html(浏览器打开可看完整关系图)
- rules/S0-项目定级.md
也在持续积累自己的Agentic Engineering的实践笔记,目前积累在飞书中,里面有更详细的BWorkflow介绍:
https://ccnz3jgnolv7.feishu.cn/wiki/Vtg2wXbA1ihF3Kkam97cyRPKnVh
其它
我自己在积累自己的AI笔记知识库,也算是一个“成长”的知识库,里面记录了我的学习笔记、落地实践、实践思考,以及一些学习的个人心得。主要想让自己保持“输出”的习惯,持续积累,能够逐渐产出更优质的资源。
https://ccnz3jgnolv7.feishu.cn/wiki/EPtjwHBCtiPUVmkoedIcbnVxnFN
更多推荐




所有评论(0)