背景：BMAD 方法的三个问题

此前使用 BMAD 方法驱动开发。其流程为：分析阶段产出 PRD，架构阶段产出架构文档，产品经理将需求拆分为 epic，scrum master 把 epic 展开为逐条 story 文件（含实现要点与验收标准），开发角色按 story 顺序实现，产品负责人执行交付审查。整个链条以持久化文档为媒介，约束全部通过 skill（提示词）实现。实际运行暴露三个问题：

1. 文档爆炸与状态不一致。每个需求产生 PRD、架构文档、epic 清单、story 文件、审查检查单等一系列文档。任一变更需要同步更新所有引用位置；更新遗漏任意一处，文档之间即出现矛盾，且不存在发现这种矛盾的机制。文档量超过可维护规模后，遗漏从偶发变为常态。
2. 顺序流程延迟。PRD、架构、epic 拆分、story 展开按顺序执行，每个环节完整产出文档后才进入下一环节，实现开始前已消耗大量时间与 token；实现阶段又被按 story 串行化。
3. skill 约束不构成控制。产出格式、审查门禁、实现边界全部是提示词层面的要求。模型可以偏离这些要求——省略要求的章节、降低审查严格度、在实现中越过 story 定义的范围——框架无法阻止，只能事后发现。补充更多 skill 与门禁角色可以缓解，但会进一步放大前两个问题。

第 3 点是根本缺陷：提示词是软约束，不构成对模型行为的控制。据此确定新方案的三个设计目标：状态集中于单一权威文档，而非平行文档；可并行的工作并行执行；关键约束由运行时能力边界与确定性验证承担，不依赖模型遵守提示词。实施载体是支持自定义角色与会话派发的工具（Lody）：每个角色有独立的系统规约、模型、推理配置和权限，角色之间通过创建会话协作。

七个角色，两层结构

模型配置有三个明确取舍。第一，按职责分层选择模型：决策层（orchestrator、planner、architecture）使用高推理预算模型；执行层（coder、tester）使用低成本模型并保持推理开启；explorer 关闭推理——该角色只执行只读检索与证据定位，关闭推理不影响交付质量，而单价最低。第二，reviewer 使用另一供应商的模型并以只读权限运行：不同供应商的模型系统性偏差不完全重合，在审查环节构成第二重独立性。第三，七个角色各自挂载独立记忆，explorer 除外：无状态使其输出可复现、会话可并行、不引入跨任务污染。

比模型配置更重要的是会话拓扑约束：

只有 orchestrator 和 planner 具备派发权限,且这两个主会话必须由用户亲自启动;全部执行角色禁止创建子会话。 执行角色需要代码探索时,在当轮回复中提出请求,由主会话创建平级 explorer 会话,结果送回原会话。早期版本允许执行角色互相调用，会话树快速增长并很快达到链式深度上限，故障后也无法确定哪个会话正在修改哪个文件。限制为两层之后：责任链为直线；全部探索请求经过主会话审核，执行角色无法借探索扩大授权范围；写入冲突可控——写入范围冲突的任务串行，其余并行。

与前一套方案的区别在于约束的执行位置：会话创建入口只存在于两个主会话的工具集中，执行角色在能力层面无法派发，这是工具配置而非提示词要求；平台在运行时强制执行反向通信禁止与因果链深度上限；reviewer 以只读权限模式运行。角色规约只承担无法用能力边界表达的部分。

三阶段流程与人工启动点

• 阶段一，整体设计。orchestrator 与 architecture 协作确定技术方案，需要了解代码现状时派发 explorer。产出三项：主文档、按业务行为拆分的子任务清单、每个子任务的启动说明。拆分原则固定写入规约：按内聚的业务行为拆分，不按技术层、文件数量或工作量机械拆分。
• 阶段二，各组并行实施。用户按启动说明为每个子任务启动一个 planner 主会话。planner 在组内派发 coder 与 tester；实现与验证完成后，组织 reviewer 与 architecture 对同一代码状态分别独立审查，两者均接受才构成准入（下称联合准入）。组间可并行。
• 阶段三，整体验收。orchestrator 组织新的 tester、reviewer、architecture，从真实业务入口验证到下游消费。组级通过仅是输入，不构成整体完成。

两条硬性规则：启动新阶段不构成对上一轮未决争议的接受；阶段交付后必须停止，不允许自动进入下一阶段。人工检查点的作用即在于阻断错误的跨阶段传播。

对失控行为的显式约束

多角色流程的主要风险不是执行效率，而是自动化失控。角色规约中约一半内容是以下约束：

• 文档即状态。每个需求一份唯一主文档，由 orchestrator 维护，是需求的唯一权威；每个组一份临时任务文档，引用主文档版本，交付后标记“待汇入”，由 orchestrator 在阶段交接时核实合并。约束：临时任务文档不能成为新需求来源；角色自行产生的判断与建议不构成授权。相对前一方案的差异：状态只有一份权威记录，变更只发生在一处；临时文档通过显式版本引用与汇入纪律关联主文档，不存在需要人工保持同步的平行文档。
• 纠正预算。初始实现与审查为第 0 轮；每个需求全局共享两轮纠正额度，planner 无权增加或重置。额度耗尽即停止派发，仅在用户明确追加授权后继续。目的：为无界重试设定上界。
• 失败分类。确认缺陷、验证缺口、环境问题、文档误述、非阻塞建议五类，各有不同处理路径。缺少该分类时，环境故障同样消耗纠正预算。
• 写安全。任何角色不得擅自回滚、丢弃、重置或覆盖已有或并行修改，不得自行 commit、merge、push、deploy；撤销须说明具体操作并等待授权。该约束来自实际故障：实现失败后的未授权恢复操作会破坏并行会话的成果。
• 异步纪律。派发后结束当前回合、等待结果自动回传，不轮询、不反向通信；仅允许携带实质任务或新信息的跟进消息，禁止致谢与确认类消息——它们只消耗上下文与 token。

联合准入与反作弊

实现完成后，reviewer（正确性、安全、回归）与 architecture（架构一致性）对同一份代码状态分别独立审查，两者均接受才构成准入；planner 不得修改代码以消除审查异议，不得更换审查者绕过未解决的结论。

测试反作弊条款全部来自实际故障案例。成功用例必须具备非空的有效前置状态，断言作用于真实目标记录——以空列表查询并通过空断言不构成成功验证；失败用例必须证明目标条件确实被触发，不能被其他前置错误掩盖；禁止通过修改断言、放宽门禁、刷新基线制造通过。reviewer 必须追踪到调用方与下游消费：代码存在不等于已被接入，数据结构层面的单元测试通过不等于业务闭环。

内部审计工具：唯一的确定性事实来源

前述全部角色协作机制的本质是让多个模型互相校验，而模型输出不是事实——前一方案的审查门禁与本文的联合准入同为模型审查模型，可靠性上限相同。整套流程的验证基础是一套内部审计工具：统一入口的确定性验证通道--环境与工具链固定,单条命令执行覆盖整个仓库的检查链(类型检查、静态检查、全量回归、仓库门禁),输出与当前代码状态绑定的完整结果记录。所有角色不自行构造验证命令,一律经由该工具执行;tester 的"验证通过"与 reviewer 的"无回归",引用的都是该工具的实际输出,而非任何角色的自我汇报。

该工具的价值集中于两点：

• 覆盖面。检查链横向覆盖整个仓库。角色在任何位置的修改，无论是否属于本次需求范围，都进入检查。依靠模型注意力覆盖全仓库回归不可行，依靠固定的检查链可行。且覆盖面随时间单调增长：每个在人工环节才发现的缺陷，事后固化为新的检查项。
• 稳定性。相同的代码状态输入，输出相同结果。在全部环节均由概率模型构成的流水线中，这是唯一的确定性事实来源；前述反作弊条款的本质都是保护该事实来源的完整性——确定性证据一旦可被绕过，审查退化为模型之间的相互确认。附带收益：环境问题与代码缺陷可以确定性地区分——同一失败在另一环境复跑，结果稳定复现或稳定消失，分类即可得出。

模型会更换，角色规约已迭代多版，编排结构经过数次推翻重建；三者之中只有审计工具的价值随时间单调增长。多角色编排可以整体替换，该工具存在即可重新构建；反之，缺少该工具时，所有"通过"结论都缺乏可信依据。

实际运行效果与局限

以一个常见需求为例:按条件筛选并导出订单报表。阶段一拆分为筛选查询、导出任务、前端入口三组;用户按三份启动说明各启动一个 planner,联合准入通过后回到 orchestrator 启动终验。全程人工操作为：三次阶段启动、一次跨组接口争议裁决、一轮纠正额度追加。此前使用 BMAD 完成同类需求，人工时间主要消耗在文档链的生成、同步与纠偏上；现在人工投入集中于决策点，交付物附带可核查的证据。

相对 BMAD 方案的对应变化有三点。状态：从平行文档链（PRD、架构、story 文件）收敛为一份主文档加版本引用的临时文档，组内细化由 planner 按需完成，不再预先全量展开。执行：从顺序 story 链改为并行组，写入冲突由设计阶段排定顺序。约束：从提示词门禁改为能力边界（派发入口收敛、只读权限、运行时通信限制）加确定性验证（审计工具）。

局限有两点。其一，该流程有固定开销，小规模修改（例如单行样式调整）不适用——每个角色的规约开头均声明流程不强制套用于所有场景。其二，低成本模型的执行角色在理解复杂指派时仍会偏离目标；依靠规约中"报告冲突而不是擅自改造"一类的约束，损失被控制在一次报告之内，而非依赖执行角色不出错。

核心设计原则归纳：职责分离，每个角色只承担一项职能；状态全部落在文档，不落在会话记忆；所有可能失控的循环——重试、跨阶段推进、范围扩张、递归派发——均受显式约束，控制权保留在用户；一切结论锚定于确定性验证证据，不采信任何角色的自我汇报。自动化承担执行，人工承担启动与裁决。