自从用上 Fable 5、K3 这些更强的大模型我就在琢磨BWorkflow-V1 是不是太重了v1 的思路是把大量规则约束架在 Agent 之上构成一层流程 harness——技术 harness 管 Agent 怎么跑得动流程 harness 管 Agent 按什么规矩跑让它在强规则环境下执行得更稳。在弱模型时代这层 harness 越厚越好——它替模型兜底。但模型换代之后我开始怀疑这层 harness 是不是厚过头了这次减法让我确认了一件事规则的有效性是会过期的——为补偿弱模型而写的每一条约束都该在模型换代后重新审一遍它还守着什么这篇文章记录的就是我把这层 harness 拆掉一半的完整过程删了什么、留了什么、两轮真实项目验证的结果。它真正想回答的是一个更普遍的问题当模型持续变强那些为弱模型设计的规则、流程、prompt该如何重新校准BWorkflow v2 是我的答案样本——规则做护栏不做车道。资源仓库https://gitee.com/being_xyk/bworkflow配套看板https://gitee.com/being_xyk/使用方法规则做护栏不做车道我为什么删掉了工作流里 60% 的规则BWorkflowBWorkflow 是一套面向「人 AI 编程助手」团队的项目交付规则层通过显式 gate、可验证的退出标准和最小化的人为决策点让中小规模项目在高速迭代中仍保持可控。这套流程不是发明而是复原——复原软件工程面对复杂交付时本该有的样子。以下各个阶段都不是创新只是忠实地遵循了这条早已被反复验证的路分阶段是为了把复杂性拆开、让它可被逐段消化而每一个阶段都在回答一个具体的质量问题。问题从来不是没人知道该这么做——TDD、代码审查、设计先行这些是写进教科书的常识。真正的问题是人守不住在实现落地的疲惫里、在赶工的压力下、在就这一次先跳过的侥幸中纪律恰恰在最该坚持的地方被一点点磨掉。这份不可控过去没有好的解法只能靠自觉和意志力去扛。Coding Agent 第一次让它有了确定性的解法AI 不会累、不会为赶进度而偷工而明确的 gate 让跳过在结构上就不可能——机器门禁不绿就进不去人该拍板的地方机器代不了。它把人会跳过这个最大的不可控降到了最低。所以哪怕你不使用 BWorkflow 的规则与 runtime这套流程本身依然成立、依然是一份值得依循的指导BWorkflow 做的只是借着 AI 与 gate把这份人人认同却难以坚持的纪律第一次变得可执行、可裁决、不可绕过。各阶段S0 项目定级 ★把「这项目该怎么做」的模糊拉回到确定的模式档位完整 / 轻量 / 拒绝拆分——不让流程用过轻或过重。S1 调研把零散、口头、隐含的输入拉回成结构化、可设计的清单——不让人带着未言明的假设开工。S2 设计锁定 ★把「边做边想」的设计漂移拉回到一份显式批准、锁定的设计包spec / plan / constitution复杂领域补 domain-model。S3 核心难点Spike把「不知道能不能做」的技术风险拉回成一个已验证的 Go/No-Go 事实——不让未验证的假设当地基。SL轻量设计锁定 ★轻量模式合并 S1/S2/S3小项目一次性锁方向输出 design-note.md。S4 开发落地把实现拉回到锁定的设计边界内——机器门禁测试 / 构建 / 审查不绿就过不去任何偏离都得走 S6。S5 用户验证 ★把「我以为做对了」拉回到「用户按验收场景确认对了」——不自证清白。S6 需求变更把一切变更缺陷 / 新需求 / 设计调整拉回统一通道分类 → 提案 → 审批 → 落地 → 回归 → 归档。其它原文在我的飞书知识库内BWorkflow-V2我的AI积累笔记也包含了其它的学习知识、思考笔记、实践记录Being的AI积累。