BMAD 方法中的 Solutioning 阶段为什么在编码前做技术决策能决定多智能体项目的成败【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHODBMAD MethodBreakthrough Method for Agile AI Driven Development将软件交付组织为分析、规划、solutioning、实现四个阶段。其中阶段 3solutioning即解决方案设计负责把规划产出的要做什么转译为如何实现——在代码开始之前先锁定跨epic的关键技术决策为随后并行实施的story提供共享的一致性约束。本文基于仓库文档 docs/ko-kr/explanation/why-solutioning-matters.md 展开结合bmad-architecture、bmad-create-epics-and-stories、bmad-sprint-planning等模块的源码与模板讲清 solutioning 的必要性、边界、落地路径与跳过代价。读完你将掌握什么时候该做 solutioning、它和 planning 的职责如何划分、以及如何用ARCHITECTURE-SPINE.md让多个智能体并行开发而不互相踩踏。一、不做 solutioning 会发生什么当一个系统由多个 AI 智能体并行实现时每个智能体都会在缺乏共享架构约束的前提下做出局部最优的技术决策最终在集成阶段爆发冲突。文档给出了一个典型场景智能体 1 使用 REST API 实现 Epic 1 智能体 2 使用 GraphQL 实现 Epic 2 结果API 设计不一致集成成本暴涨这类问题的本质不是某个智能体写错了而是它们各自面对的技术决策空间不同REST 与 GraphQL 都是合理的 API 风格可一旦分散在同一个系统的不同epic里接口风格、数据形状、认证方式就会互相打架。仓库配套文档 docs/ko-kr/explanation/preventing-agent-conflicts.md 系统归纳了最常见的冲突类型API 风格冲突智能体 A 用 REST /users/{id}智能体 B 用 GraphQL mutationAPI 使用者面对两套不一致的交互模式数据库设计冲突智能体 A 用snake_case列名智能体 B 用camelCaseschema 与查询陷入混乱状态管理冲突智能体 A 用 Redux 全局状态智能体 B 用 React Context状态流被拆成多套命名规则、安全策略、目录结构等约定层面的漂移。关键判断当多个智能体在没有共享architecture指南的前提下并行实现不同epic时它们各自做出的决策单看都对合起来就冲突。这正是 solutioning 要提前消除的风险。二、做了 solutioning 之后会发生什么solutioning 的本质不是多写一份文档而是把高冲突风险的决策前置让它们成为所有story共享的上下文。文档中的对比示例architecture 工作流先定规则所有 API 使用 GraphQL 所有智能体按同一套决策实现 story 结果实现一致集成顺滑架构一旦显式存在每个实现者无论人或智能体读到的都是同一份约束契约接口风格已定、数据形状已定、状态变更路径已定。后续bmad-build实现的每个story天然收敛到同一条技术线上集成阶段不再需要对齐两套正确但不同的方案。仓库中 skills/bmad-architecture/SKILL.md 将这套约束称为architecture spine架构脊柱一份只固定让独立构建的单元不互相偏离的不变量的一致性契约。它明确区分了两类内容不变量invariants——设计范式、边界与依赖规则、状态如何变更、共享数据归谁所有。这些是未来构建者无法从合规代码中反推出来的持久决策必须写进 spine种子seed——技术栈、目录树、完整数据形状等结构性内容。它们只在冷启动时真实一旦代码存在就归代码所有spine 不做镜像维护。bmad-architecture用一个测试决定什么内容该进 spine如果下层两个单元独立构建它们会不会做出不兼容的选择只有答案是会且该决策不明显、且存在真实取舍时才把它固定下来否则归入 Deferred延后决策继续前进。 这一宁可少定、定则必准的原则让架构文档保持精简而不臃肿。三、solutioning 与 planning 的边界solutioning 不是 planning 的重复两者的产出物、主导角色与受众完全不同。文档中的对照表是理解这条边界的关键方面Planning阶段 2Solutioning阶段 3核心问题做什么为什么做如何做再如何拆分工作输出物FRs/NFRs需求architectureepic/story拆分主导角色PMArchitect → PM受众利益相关者开发人员文档PRDFRs/NFRs架构文档 epics 文件决策层级业务目标与范围技术策略与实现边界一句话概括planning 回答WHAT 与 WHYsolutioning 回答HOW 与 HOW TO SPLIT。PRD 锁定业务需求FRs/NFRs交给利益相关者确认architecture spine 锁定技术策略交给开发人员以及 AI 智能体执行。在 BMAD Method 的工作流地图docs/ko-kr/reference/workflow-map.md中阶段 3 由三个工作流组成恰好对应决策—拆分—就绪的完整链路工作流目的产出物bmad-architecture把技术决策显式化核心文档ARCHITECTURE-SPINE.md可按需扩展为报告或演示形式bmad-create-epics-and-stories把需求拆成可实现的epic与story带故事拆分的 epic 文件bmad-sprint-planning实现前的就绪度门禁 故事跟踪与状态视图PASS/CONCERNS/FAIL sprint-status.yaml值得注意的是阶段 3 同时覆盖了架构决策与工作拆分两块——这也解释了为什么 solutioning 的输出物是架构 epic/story 拆分的组合。四、核心原则让技术决策显式、可追溯、可复用solutioning 的核心原则是让跨epic的关键技术决策显式、可追溯、可复用。文档明确指出这能直接降低以下五类风险API 风格冲突REST vs GraphQL数据模型与命名约定不一致状态管理方案分裂安全策略分叉中后期返工成本在实现层bmad-architecture通过memlog ADArchitecture Decision机制保证决策的可追溯性每次运行先通过memlog.py init初始化.memlog.md工作记忆此后每个决策、约束、版本、假设、开放问题都以追加行记录例如uv run {project-root}/_bmad/scripts/memlog.py append \ --workspace {doc_workspace} --type decision --text …运行结束时spine 文件从 memlog 蒸馏distill生成而不是边写边改——每个存活下来的决策成为一条AD-n稳定 ID携带Binds约束哪些能力/单元、Prevents阻止何种偏离、Rule下游必须遵守的规则三段结构ADID 一旦分配永不重编号。更新已有 spine 时只允许原地修订 Rule 或追加新的AD-n下游story可以稳定引用这些 ID。spine 模板skills/bmad-architecture/assets/spine-template.md的 frontmatter 与结构体现了同样的显式决策哲学name: {name} type: architecture-spine purpose: build-substrate # build-substrate (默认) · discussion · report · deck altitude: feature # initiative统辖 features· feature统辖 epics· epic统辖 stories paradigm: {命名的设计模式如 hexagonal、layered、pipes-and-filters、actor} scope: {此 spine 管辖的范围} status: draft # draft · final正文按Design Paradigm → Inherited Invariants继承的不变量→ Invariants RulesAD 块→ Consistency Conventions一致性约定→ Stack种子→ Structural Seed → Capability → Architecture Map → Deferred组织。其中两个设计点值得展开Design Paradigm 先行spine 以命名一个已知设计范式开篇——一个被广泛理解的范式六边形、分层、管道过滤器、Actor 等能免费携带一整套模型与约束是最小也最持久的部分Deferred 是契约的另一半被延后的决策要写清为什么现在可以等包括当前层级尚不拥有的整个维度。Deferred 的存在让 spine 保持精简同时向未来构建者明确这里还没定别假设。一致性约定Consistency Conventions则用一张表把最容易漂移的默认定下来命名实体、文件、接口、事件、数据与格式ID、日期、错误形状、信封、状态与横切关注点变更、错误、日志、配置、认证。这正是智能体各自实现也能保持一致的落地机制。五、如何选择 solutioning 的深度solutioning 不是一刀切的全量流程。文档给出了一张按工作特征选择深度的决策表工作特征Solutioning 建议约定明确的局部变更通常不需要多个相关组件且约束已知按协同风险选择多个 epic 或跨系统决策需要用它对齐实施受监管、高风险或 enterprise 项目遵循必要的治理要求通常必须进行 solutioning结合bmad-architecture的实现深度选择还有两条补充维度altitude层级决定范围spine 的层级要镜像它所增补的对象——initiative 管 features、feature 管 epics、epic 管 stories。一个 feature 级 spine 只固定该 feature 下各 epic 必须共享的不变量不展开到每个 story 的细节一个小的改动可能只需要范式 几条 AD 约定继承约束不可覆盖当某 epic 的 spine 继承父级 spine 时父级的 AD、约定与范式是绑定且只读的约束必须按原始 ID 列入 Inherited Invariants不得重新编号或重新推导。子级 spine 只处理父级遗留的 Deferred 项与本 epic 可能触发的偏离新增 AD 若与继承项冲突是需要上报的冲突而非本地覆盖。bmad-architecture还内置了Coaching path / Fast path两种工作模式默认的 Coaching path 通过开放式提问把决策从用户口中引导出来并对薄弱处提出质疑Fast path 则直接生成带[ASSUMPTION]标记的完整 spine由用户在评审中纠正。无论哪条路径关键决策范式、技术栈、主要边界都展示给用户选择而不是静默决定。一个重要的边界条件solutioning 改变提供给bmad-build的上下文不改变实施 workflow。也就是说架构文档的价值在于每个实现单元读到的约束一致而不是引入一套新的编码流程——实施阶段仍然是按story走bmad-build/bmad-build-auto。六、跳过 solutioning 的代价文档明确列出复杂项目中跳过该阶段的四类后果集成问题在冲刺中期暴露返工由实现冲突引发整体研发周期拉长技术债务因模式不一致持续累积并给出了一条成本经验法则原文以 caution 标注方向跑偏的问题在 solutioning 阶段发现通常比在实施中后期才发现更快、更便宜原文表述为10 倍更快。这与bmad-sprint-planning的就绪度门禁readiness gate形成呼应——该技能在实现前先以怀疑者审阅交接物的姿态检查规划完整性PASS 才生成sprint-status.yaml进入实施。门禁与架构评审的共同逻辑是把问题拦在编码之前而不是让代码为错误的方向买单。七、把 solutioning 落到执行层与项目上下文联动架构约束要真正约束到每个智能体的日常实现还需要与执行层机制配合项目上下文bmad-project-context负责把架构中的关键规则沉淀为AGENTS.md中简洁、经过验证的规则块让 AI 智能体在所有工作流中都能读到项目规则。greenfield 项目从规格或架构起步brownfield 项目则从代码库中提取并验证规则冲突消解当实现过程中出现需要改变既定架构方向的情况使用bmad-correct-course处理而不是各智能体自行微调演进维护架构不是一次写完就束之高阁的文档。文档与源码均强调把学到的经验反馈回架构并更新避免出现过时架构让智能体沿用旧模式的反模式。推荐阅读链路均转换为仓库根目录相对路径冲突如何发生、架构如何消除docs/ko-kr/explanation/preventing-agent-conflicts.md执行层约束如何落地docs/ko-kr/explanation/project-context.mdsolutioning 在四阶段中的位置docs/ko-kr/reference/workflow-map.md架构 spine 的实现与模板skills/bmad-architecture/SKILL.md、skills/bmad-architecture/assets/spine-template.md史诗与故事拆分skills/bmad-create-epics-and-stories/SKILL.md就绪度门禁与冲刺跟踪skills/bmad-sprint-planning/SKILL.md结语在多智能体并行的开发模式下solutioning 是成本收益比最高的一个阶段它用一份精简的架构脊柱把最容易引发集成冲突的技术决策在编码前锁定为共享约束让每个智能体读同一份架构、实现同一条技术线成为现实。判断要不要做的经验法则很朴素——只要需求会拆成多个epic并且可能由不同智能体并行实现就应该做 solutioning。【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 BMAD 方法中的 Solutioning 阶段：为什么在编码前做技术决策能决定多智能体项目的成败
BMAD 方法中的 Solutioning 阶段为什么在编码前做技术决策能决定多智能体项目的成败【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHODBMAD MethodBreakthrough Method for Agile AI Driven Development将软件交付组织为分析、规划、solutioning、实现四个阶段。其中阶段 3solutioning即解决方案设计负责把规划产出的要做什么转译为如何实现——在代码开始之前先锁定跨epic的关键技术决策为随后并行实施的story提供共享的一致性约束。本文基于仓库文档 docs/ko-kr/explanation/why-solutioning-matters.md 展开结合bmad-architecture、bmad-create-epics-and-stories、bmad-sprint-planning等模块的源码与模板讲清 solutioning 的必要性、边界、落地路径与跳过代价。读完你将掌握什么时候该做 solutioning、它和 planning 的职责如何划分、以及如何用ARCHITECTURE-SPINE.md让多个智能体并行开发而不互相踩踏。一、不做 solutioning 会发生什么当一个系统由多个 AI 智能体并行实现时每个智能体都会在缺乏共享架构约束的前提下做出局部最优的技术决策最终在集成阶段爆发冲突。文档给出了一个典型场景智能体 1 使用 REST API 实现 Epic 1 智能体 2 使用 GraphQL 实现 Epic 2 结果API 设计不一致集成成本暴涨这类问题的本质不是某个智能体写错了而是它们各自面对的技术决策空间不同REST 与 GraphQL 都是合理的 API 风格可一旦分散在同一个系统的不同epic里接口风格、数据形状、认证方式就会互相打架。仓库配套文档 docs/ko-kr/explanation/preventing-agent-conflicts.md 系统归纳了最常见的冲突类型API 风格冲突智能体 A 用 REST /users/{id}智能体 B 用 GraphQL mutationAPI 使用者面对两套不一致的交互模式数据库设计冲突智能体 A 用snake_case列名智能体 B 用camelCaseschema 与查询陷入混乱状态管理冲突智能体 A 用 Redux 全局状态智能体 B 用 React Context状态流被拆成多套命名规则、安全策略、目录结构等约定层面的漂移。关键判断当多个智能体在没有共享architecture指南的前提下并行实现不同epic时它们各自做出的决策单看都对合起来就冲突。这正是 solutioning 要提前消除的风险。二、做了 solutioning 之后会发生什么solutioning 的本质不是多写一份文档而是把高冲突风险的决策前置让它们成为所有story共享的上下文。文档中的对比示例architecture 工作流先定规则所有 API 使用 GraphQL 所有智能体按同一套决策实现 story 结果实现一致集成顺滑架构一旦显式存在每个实现者无论人或智能体读到的都是同一份约束契约接口风格已定、数据形状已定、状态变更路径已定。后续bmad-build实现的每个story天然收敛到同一条技术线上集成阶段不再需要对齐两套正确但不同的方案。仓库中 skills/bmad-architecture/SKILL.md 将这套约束称为architecture spine架构脊柱一份只固定让独立构建的单元不互相偏离的不变量的一致性契约。它明确区分了两类内容不变量invariants——设计范式、边界与依赖规则、状态如何变更、共享数据归谁所有。这些是未来构建者无法从合规代码中反推出来的持久决策必须写进 spine种子seed——技术栈、目录树、完整数据形状等结构性内容。它们只在冷启动时真实一旦代码存在就归代码所有spine 不做镜像维护。bmad-architecture用一个测试决定什么内容该进 spine如果下层两个单元独立构建它们会不会做出不兼容的选择只有答案是会且该决策不明显、且存在真实取舍时才把它固定下来否则归入 Deferred延后决策继续前进。 这一宁可少定、定则必准的原则让架构文档保持精简而不臃肿。三、solutioning 与 planning 的边界solutioning 不是 planning 的重复两者的产出物、主导角色与受众完全不同。文档中的对照表是理解这条边界的关键方面Planning阶段 2Solutioning阶段 3核心问题做什么为什么做如何做再如何拆分工作输出物FRs/NFRs需求architectureepic/story拆分主导角色PMArchitect → PM受众利益相关者开发人员文档PRDFRs/NFRs架构文档 epics 文件决策层级业务目标与范围技术策略与实现边界一句话概括planning 回答WHAT 与 WHYsolutioning 回答HOW 与 HOW TO SPLIT。PRD 锁定业务需求FRs/NFRs交给利益相关者确认architecture spine 锁定技术策略交给开发人员以及 AI 智能体执行。在 BMAD Method 的工作流地图docs/ko-kr/reference/workflow-map.md中阶段 3 由三个工作流组成恰好对应决策—拆分—就绪的完整链路工作流目的产出物bmad-architecture把技术决策显式化核心文档ARCHITECTURE-SPINE.md可按需扩展为报告或演示形式bmad-create-epics-and-stories把需求拆成可实现的epic与story带故事拆分的 epic 文件bmad-sprint-planning实现前的就绪度门禁 故事跟踪与状态视图PASS/CONCERNS/FAIL sprint-status.yaml值得注意的是阶段 3 同时覆盖了架构决策与工作拆分两块——这也解释了为什么 solutioning 的输出物是架构 epic/story 拆分的组合。四、核心原则让技术决策显式、可追溯、可复用solutioning 的核心原则是让跨epic的关键技术决策显式、可追溯、可复用。文档明确指出这能直接降低以下五类风险API 风格冲突REST vs GraphQL数据模型与命名约定不一致状态管理方案分裂安全策略分叉中后期返工成本在实现层bmad-architecture通过memlog ADArchitecture Decision机制保证决策的可追溯性每次运行先通过memlog.py init初始化.memlog.md工作记忆此后每个决策、约束、版本、假设、开放问题都以追加行记录例如uv run {project-root}/_bmad/scripts/memlog.py append \ --workspace {doc_workspace} --type decision --text …运行结束时spine 文件从 memlog 蒸馏distill生成而不是边写边改——每个存活下来的决策成为一条AD-n稳定 ID携带Binds约束哪些能力/单元、Prevents阻止何种偏离、Rule下游必须遵守的规则三段结构ADID 一旦分配永不重编号。更新已有 spine 时只允许原地修订 Rule 或追加新的AD-n下游story可以稳定引用这些 ID。spine 模板skills/bmad-architecture/assets/spine-template.md的 frontmatter 与结构体现了同样的显式决策哲学name: {name} type: architecture-spine purpose: build-substrate # build-substrate (默认) · discussion · report · deck altitude: feature # initiative统辖 features· feature统辖 epics· epic统辖 stories paradigm: {命名的设计模式如 hexagonal、layered、pipes-and-filters、actor} scope: {此 spine 管辖的范围} status: draft # draft · final正文按Design Paradigm → Inherited Invariants继承的不变量→ Invariants RulesAD 块→ Consistency Conventions一致性约定→ Stack种子→ Structural Seed → Capability → Architecture Map → Deferred组织。其中两个设计点值得展开Design Paradigm 先行spine 以命名一个已知设计范式开篇——一个被广泛理解的范式六边形、分层、管道过滤器、Actor 等能免费携带一整套模型与约束是最小也最持久的部分Deferred 是契约的另一半被延后的决策要写清为什么现在可以等包括当前层级尚不拥有的整个维度。Deferred 的存在让 spine 保持精简同时向未来构建者明确这里还没定别假设。一致性约定Consistency Conventions则用一张表把最容易漂移的默认定下来命名实体、文件、接口、事件、数据与格式ID、日期、错误形状、信封、状态与横切关注点变更、错误、日志、配置、认证。这正是智能体各自实现也能保持一致的落地机制。五、如何选择 solutioning 的深度solutioning 不是一刀切的全量流程。文档给出了一张按工作特征选择深度的决策表工作特征Solutioning 建议约定明确的局部变更通常不需要多个相关组件且约束已知按协同风险选择多个 epic 或跨系统决策需要用它对齐实施受监管、高风险或 enterprise 项目遵循必要的治理要求通常必须进行 solutioning结合bmad-architecture的实现深度选择还有两条补充维度altitude层级决定范围spine 的层级要镜像它所增补的对象——initiative 管 features、feature 管 epics、epic 管 stories。一个 feature 级 spine 只固定该 feature 下各 epic 必须共享的不变量不展开到每个 story 的细节一个小的改动可能只需要范式 几条 AD 约定继承约束不可覆盖当某 epic 的 spine 继承父级 spine 时父级的 AD、约定与范式是绑定且只读的约束必须按原始 ID 列入 Inherited Invariants不得重新编号或重新推导。子级 spine 只处理父级遗留的 Deferred 项与本 epic 可能触发的偏离新增 AD 若与继承项冲突是需要上报的冲突而非本地覆盖。bmad-architecture还内置了Coaching path / Fast path两种工作模式默认的 Coaching path 通过开放式提问把决策从用户口中引导出来并对薄弱处提出质疑Fast path 则直接生成带[ASSUMPTION]标记的完整 spine由用户在评审中纠正。无论哪条路径关键决策范式、技术栈、主要边界都展示给用户选择而不是静默决定。一个重要的边界条件solutioning 改变提供给bmad-build的上下文不改变实施 workflow。也就是说架构文档的价值在于每个实现单元读到的约束一致而不是引入一套新的编码流程——实施阶段仍然是按story走bmad-build/bmad-build-auto。六、跳过 solutioning 的代价文档明确列出复杂项目中跳过该阶段的四类后果集成问题在冲刺中期暴露返工由实现冲突引发整体研发周期拉长技术债务因模式不一致持续累积并给出了一条成本经验法则原文以 caution 标注方向跑偏的问题在 solutioning 阶段发现通常比在实施中后期才发现更快、更便宜原文表述为10 倍更快。这与bmad-sprint-planning的就绪度门禁readiness gate形成呼应——该技能在实现前先以怀疑者审阅交接物的姿态检查规划完整性PASS 才生成sprint-status.yaml进入实施。门禁与架构评审的共同逻辑是把问题拦在编码之前而不是让代码为错误的方向买单。七、把 solutioning 落到执行层与项目上下文联动架构约束要真正约束到每个智能体的日常实现还需要与执行层机制配合项目上下文bmad-project-context负责把架构中的关键规则沉淀为AGENTS.md中简洁、经过验证的规则块让 AI 智能体在所有工作流中都能读到项目规则。greenfield 项目从规格或架构起步brownfield 项目则从代码库中提取并验证规则冲突消解当实现过程中出现需要改变既定架构方向的情况使用bmad-correct-course处理而不是各智能体自行微调演进维护架构不是一次写完就束之高阁的文档。文档与源码均强调把学到的经验反馈回架构并更新避免出现过时架构让智能体沿用旧模式的反模式。推荐阅读链路均转换为仓库根目录相对路径冲突如何发生、架构如何消除docs/ko-kr/explanation/preventing-agent-conflicts.md执行层约束如何落地docs/ko-kr/explanation/project-context.mdsolutioning 在四阶段中的位置docs/ko-kr/reference/workflow-map.md架构 spine 的实现与模板skills/bmad-architecture/SKILL.md、skills/bmad-architecture/assets/spine-template.md史诗与故事拆分skills/bmad-create-epics-and-stories/SKILL.md就绪度门禁与冲刺跟踪skills/bmad-sprint-planning/SKILL.md结语在多智能体并行的开发模式下solutioning 是成本收益比最高的一个阶段它用一份精简的架构脊柱把最容易引发集成冲突的技术决策在编码前锁定为共享约束让每个智能体读同一份架构、实现同一条技术线成为现实。判断要不要做的经验法则很朴素——只要需求会拆成多个epic并且可能由不同智能体并行实现就应该做 solutioning。【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考