docs(zh-cn): refine Epic3 story 3.3 and 3.4 explanations (#2099)
* docs(zh-cn-explanation): refine epic3 stories 3.3-3.4 我重写头脑风暴、高级启发与 Party Mode 的中文说明，明确三者在适用场景、价值和边界上的差异，避免字面对译带来的误用。 我同步收敛 Quick Dev 与对抗性评审文案，强调各自定位与配合关系，并补齐中文优先链路和当前 workflow 命名。 feishu: https://feishu.cn/wiki/TODO Made-with: Cursor * docs(zh-cn-explanation): 统一提示块围栏语法 我将五篇 explanation 文档里的四冒号提示块语法统一为三冒号，确保与当前文档渲染规则一致。 此前这些文档混用不同围栏写法，容易在审阅和渲染中引入不必要差异；现在统一后可减少维护噪音。 feishu: https://feishu.cn/wiki/TODO Made-with: Cursor --------- Co-authored-by: leon <leon.liang@hairobotics.com>
This commit is contained in:
梁山河
GitHub
parent
8b0754106d
commit
94831cbb1e
|
|
@ -5,58 +5,53 @@ sidebar:
|
||||||
order: 6
|
order: 6
|
||||||
---
|
---
|
||||||
|
|
||||||
让 LLM 重新审视它刚刚生成的内容。你选择一种推理方法，它将该方法应用于自己的输出，然后你决定是否保留改进。
|
高级启发（advanced elicitation）是“第二轮思考”机制：不是笼统地让模型“再来一次”，而是让它按指定推理方法重审自己的输出。
|
||||||
|
|
||||||
## 什么是高级启发？
|
## 它是什么
|
||||||
|
|
||||||
结构化的第二轮处理。与其要求 AI "再试一次" 或 "做得更好"，不如选择一种特定的推理方法，让 AI 通过该视角重新审视自己的输出。
|
你先有一版输出（方案、文案、分析或规范），再通过某种推理框架做二次审视，例如：
|
||||||
|
- 事前复盘（Pre-mortem）
|
||||||
|
- 第一性原理
|
||||||
|
- 逆向思维（Inversion）
|
||||||
|
- 红队/蓝队
|
||||||
|
- 苏格拉底式追问
|
||||||
|
|
||||||
这种区别很重要。模糊的请求会产生模糊的修订。命名的方法会强制采用特定的攻击角度，揭示出通用重试会遗漏的见解。
|
这种“带方法名的重审”通常比“再优化一下”更有效，因为它会强制模型从特定角度进攻已有答案。
|
||||||
|
|
||||||
## 何时使用
|
## 什么时候使用
|
||||||
|
|
||||||
- 在工作流生成内容后，你想要替代方案
|
- 你已有可用初稿，但怀疑还不够扎实
|
||||||
- 当输出看起来还可以，但你怀疑还有更深层次的内容
|
- 你想压力测试关键假设或找潜在漏洞
|
||||||
- 对假设进行压力测试或发现弱点
|
- 你面对高风险内容，需要更高置信度
|
||||||
- 对于重新思考有帮助的高风险内容
|
- 你想要替代解法，而不是同义改写
|
||||||
|
|
||||||
工作流在决策点提供高级启发——在 LLM 生成某些内容后，系统会询问你是否要运行它。
|
## 它如何运行
|
||||||
|
|
||||||
## 工作原理
|
1. 模型先给出若干与你内容相关的方法候选
|
||||||
|
2. 你选择一种（或重抽）
|
||||||
|
3. 模型按该方法重审并展示改进
|
||||||
|
4. 你决定采纳、丢弃、继续下一轮或结束
|
||||||
|
|
||||||
1. LLM 为你的内容建议 5 种相关方法
|
:::tip[实战建议]
|
||||||
2. 你选择一种（或重新洗牌以获取不同选项）
|
做规格、方案或计划时，先跑一次“事前复盘”通常收益最高，容易提前暴露隐藏风险。
|
||||||
3. 应用方法，显示改进
|
|
||||||
4. 接受或丢弃，重复或继续
|
|
||||||
|
|
||||||
## 内置方法
|
|
||||||
|
|
||||||
有数十种推理方法可用。几个示例：
|
|
||||||
|
|
||||||
- **事前复盘** - 假设项目已经失败，反向推导找出原因
|
|
||||||
- **第一性原理思维** - 剥离假设，从基本事实重建
|
|
||||||
- **逆向思维** - 询问如何保证失败，然后避免这些事情
|
|
||||||
- **红队对蓝队** - 攻击你自己的工作，然后为它辩护
|
|
||||||
- **苏格拉底式提问** - 用"为什么？"和"你怎么知道？"挑战每个主张
|
|
||||||
- **约束移除** - 放下所有约束，看看有什么变化，然后有选择地加回
|
|
||||||
- **利益相关者映射** - 从每个利益相关者的角度重新评估
|
|
||||||
- **类比推理** - 在其他领域找到平行案例并应用其教训
|
|
||||||
|
|
||||||
还有更多。AI 会为你的内容选择最相关的选项——你选择运行哪一个。
|
|
||||||
|
|
||||||
:::tip[从这里开始]
|
|
||||||
对于任何规范或计划，事前复盘都是一个很好的首选。它始终能找到标准审查会遗漏的空白。
|
|
||||||
:::
|
:::
|
||||||
|
|
||||||
---
|
## 与相近模式的区别
|
||||||
## 术语说明
|
|
||||||
|
|
||||||
- **LLM**：大语言模型。一种基于深度学习的自然语言处理模型，能够理解和生成人类语言。
|
| 模式 | 核心目标 | 典型输入 | 典型输出 |
|
||||||
- **elicitation**：启发。在人工智能与提示工程中，指通过特定方法引导模型生成更高质量或更符合预期的输出。
|
| ----- | ----- | ----- | ----- |
|
||||||
- **pre-mortem analysis**：事前复盘。一种风险管理技术，假设项目已经失败，然后反向推导可能的原因，以提前识别和预防潜在问题。
|
| `advanced elicitation` | 二次推理与补强 | 已有初稿/方案 | 风险更清晰、论证更完整的改进版 |
|
||||||
- **first principles thinking**：第一性原理思维。一种将复杂问题分解为最基本事实或假设，然后从这些基本要素重新构建解决方案的思维方式。
|
| `bmad-brainstorming` | 发散创意并收敛 | 目标模糊或方向开放 | 想法池与行动方向 |
|
||||||
- **inversion**：逆向思维。通过思考如何导致失败来避免失败，从而找到成功路径的思维方式。
|
| `bmad-party-mode` | 多角色讨论权衡 | 需要跨角色协同判断 | 多视角共识或争议点 |
|
||||||
- **red team vs blue team**：红队对蓝队。一种模拟对抗的方法，红队负责攻击和发现问题，蓝队负责防御和解决问题。
|
|
||||||
- **socratic questioning**：苏格拉底式提问。一种通过连续提问来揭示假设、澄清概念和深入思考的对话方法。
|
## 使用边界
|
||||||
- **stakeholder mapping**：利益相关者映射。识别并分析项目中所有利益相关者及其利益、影响和关系的系统性方法。
|
|
||||||
- **analogical reasoning**：类比推理。通过将当前问题与已知相似领域的问题进行比较，从而借鉴解决方案或见解的推理方式。
|
- 它不能替代原始输入质量：初稿太空，二次推理也会受限
|
||||||
|
- 它会产出更多“可疑问题”，需要你做人工判别
|
||||||
|
- 连续多轮会出现收益递减，建议在关键决策点使用
|
||||||
|
|
||||||
|
## 继续阅读
|
||||||
|
|
||||||
|
- [头脑风暴](./brainstorming.md)
|
||||||
|
- [派对模式](./party-mode.md)
|
||||||
|
- [对抗性评审](./adversarial-review.md)
|
||||||
|
|
|
||||||
|
|
@ -1,71 +1,71 @@
|
||||||
---
|
---
|
||||||
title: "对抗性评审"
|
title: "对抗性评审"
|
||||||
description: 防止懒惰"看起来不错"评审的强制推理技术
|
description: 防止懒惰“看起来不错”评审的强制推理技术
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 5
|
order: 5
|
||||||
---
|
---
|
||||||
|
|
||||||
通过要求发现问题来强制进行更深入的分析。
|
对抗性评审（adversarial review）是一种“强制找问题”的评审方法：不允许直接“Looks good”，必须给出可验证发现，或者明确解释为什么没有发现。
|
||||||
|
|
||||||
## 什么是对抗性评审？
|
## 它是什么
|
||||||
|
|
||||||
一种评审技术，评审者*必须*发现问题。不允许"看起来不错"。评审者采取怀疑态度——假设问题存在并找到它们。
|
常规评审容易落入确认偏差：快速扫一遍，没有明显报错，就批准。
|
||||||
|
对抗性评审反过来要求评审者先假设“问题存在”，再去定位证据。
|
||||||
|
|
||||||
这不是为了消极。而是为了强制进行真正的分析，而不是对提交的内容进行草率浏览并盖章批准。
|
核心规则：
|
||||||
|
- 必须产出问题发现或明确的无发现理由
|
||||||
**核心规则：**你必须发现问题。零发现会触发停止——重新分析或解释原因。
|
- 发现要具体、可追溯、可操作
|
||||||
|
- 评审对象是工件本身，而不是作者意图
|
||||||
|
|
||||||
## 为什么有效
|
## 为什么有效
|
||||||
|
|
||||||
普通评审容易受到确认偏差的影响。你浏览工作，没有发现突出的问题，就批准了它。"发现问题"的指令打破了这种模式：
|
- 强制深入阅读，减少“浏览式批准”
|
||||||
|
- 更容易发现“缺了什么”，不只看“写错了什么”
|
||||||
- **强制彻底性**——在你足够努力地查看以发现问题之前，不能批准
|
- 发现通常更结构化，便于后续分诊与修复
|
||||||
- **捕捉遗漏**——"这里缺少什么？"成为一个自然的问题
|
- 在新上下文评审时，能降低“先入为主”偏差
|
||||||
- **提高信号质量**——发现是具体且可操作的，而不是模糊的担忧
|
|
||||||
- **信息不对称**——在新的上下文中运行评审（无法访问原始推理），以便你评估的是工件，而不是意图
|
|
||||||
|
|
||||||
## 在哪里使用
|
## 在哪里使用
|
||||||
|
|
||||||
对抗性评审出现在 BMad 工作流程的各个地方——代码评审、实施就绪检查、规范验证等。有时它是必需步骤，有时是可选的（如高级启发或派对模式）。该模式适应任何需要审查的工件。
|
它不是某个单一 workflow 独占，而是一种可复用评审模式，常见于：
|
||||||
|
- 代码评审
|
||||||
|
- 规范/方案评审
|
||||||
|
- 实施就绪检查
|
||||||
|
- 高风险改动复核
|
||||||
|
|
||||||
## 需要人工过滤
|
## 你需要知道的限制
|
||||||
|
|
||||||
因为 AI 被*指示*要发现问题，它就会发现问题——即使问题不存在。预期会有误报：伪装成问题的吹毛求疵、对意图的误解，或完全幻觉化的担忧。
|
因为系统被要求“必须找问题”，它会提高召回率，也会提高误报率。
|
||||||
|
你会看到：
|
||||||
|
- 吹毛求疵型发现
|
||||||
|
- 语义误解型发现
|
||||||
|
- 偶发幻觉型发现
|
||||||
|
|
||||||
**你决定什么是真实的。**审查每个发现，忽略噪音，修复重要的内容。
|
所以它本质上是**高召回、需人工分诊**的策略，而不是“自动真理机”。
|
||||||
|
|
||||||
## 示例
|
:::caution[关键心法]
|
||||||
|
把发现分成三类：必须修、可延后、可忽略。评审质量的关键不在“发现数量”，而在分诊质量。
|
||||||
而不是：
|
|
||||||
|
|
||||||
> "身份验证实现看起来合理。已批准。"
|
|
||||||
|
|
||||||
对抗性评审产生：
|
|
||||||
|
|
||||||
> 1. **高** - `login.ts:47` - 失败尝试没有速率限制
|
|
||||||
> 2. **高** - 会话令牌存储在 localStorage 中（易受 XSS 攻击）
|
|
||||||
> 3. **中** - 密码验证仅在客户端进行
|
|
||||||
> 4. **中** - 失败登录尝试没有审计日志
|
|
||||||
> 5. **低** - 魔法数字 `3600` 应该是 `SESSION_TIMEOUT_SECONDS`
|
|
||||||
|
|
||||||
第一个评审可能会遗漏安全漏洞。第二个发现了四个。
|
|
||||||
|
|
||||||
## 迭代和收益递减
|
|
||||||
|
|
||||||
在处理发现后，考虑再次运行。第二轮通常会捕获更多。第三轮也不总是无用的。但每一轮都需要时间，最终你会遇到收益递减——只是吹毛求疵和虚假发现。
|
|
||||||
|
|
||||||
:::tip[更好的评审]
|
|
||||||
假设问题存在。寻找缺失的内容，而不仅仅是错误的内容。
|
|
||||||
:::
|
:::
|
||||||
|
|
||||||
---
|
## 与 Quick Dev 的关系
|
||||||
## 术语说明
|
|
||||||
|
|
||||||
- **adversarial review**：对抗性评审。一种强制评审者必须发现问题的评审技术，旨在防止草率批准。
|
`bmad-quick-dev` 关注执行效率与边界控制；对抗性评审关注问题发现质量。
|
||||||
- **confirmation bias**：确认偏差。倾向于寻找、解释和记忆符合自己已有信念的信息的心理倾向。
|
一个解决“跑得稳不稳”，一个解决“看得深不深”，两者互补而非替代。
|
||||||
- **information asymmetry**：信息不对称。交易或评审中一方拥有比另一方更多或更好信息的情况。
|
|
||||||
- **false positives**：误报。错误地将不存在的问题识别为存在的问题。
|
## 示例（对比）
|
||||||
- **diminishing returns**：收益递减。在投入持续增加的情况下，产出增长逐渐减少的现象。
|
|
||||||
- **XSS**：跨站脚本攻击（Cross-Site Scripting）。一种安全漏洞，攻击者可在网页中注入恶意脚本。
|
普通评审可能是：
|
||||||
- **localStorage**：本地存储。浏览器提供的 Web Storage API，用于在客户端存储键值对数据。
|
> “实现基本没问题，先过。”
|
||||||
- **magic number**：魔法数字。代码中直接出现的未命名数值常量，缺乏语义含义。
|
|
||||||
|
对抗性评审更像：
|
||||||
|
> 1. HIGH：`login.ts` 缺失失败重试限流
|
||||||
|
> 2. HIGH：会话令牌存储在 `localStorage`，存在 XSS 风险
|
||||||
|
> 3. MEDIUM：失败登录缺少审计日志
|
||||||
|
> 4. LOW：魔法数字 `3600` 建议替换为命名常量
|
||||||
|
|
||||||
|
重点不是“更凶”，而是“更可执行”。
|
||||||
|
|
||||||
|
## 继续阅读
|
||||||
|
|
||||||
|
- [快速开发](./quick-dev.md)
|
||||||
|
- [高级启发](./advanced-elicitation.md)
|
||||||
|
- [工作流地图](../reference/workflow-map.md)
|
||||||
|
|
|
||||||
|
|
@ -5,39 +5,57 @@ sidebar:
|
||||||
order: 2
|
order: 2
|
||||||
---
|
---
|
||||||
|
|
||||||
通过引导式探索释放你的创造力。
|
`bmad-brainstorming` 是一个“思考引导”工作流：它不替你拍脑袋给答案，而是用结构化提问把你的想法挖出来、扩展开、再收敛成可执行方向。
|
||||||
|
|
||||||
## 什么是头脑风暴？
|
## 它是什么
|
||||||
|
|
||||||
运行 `brainstorming`，你就拥有了一位创意引导者，帮助你从自身挖掘想法——而不是替你生成想法。AI 充当教练和向导，使用经过验证的技术，创造让你最佳思维涌现的条件。
|
头脑风暴（brainstorming）适合“我有方向，但还不够清晰”的阶段。你会和 AI 进行来回探索：
|
||||||
|
- 明确问题和约束
|
||||||
|
- 生成备选想法
|
||||||
|
- 对想法分组和优先级排序
|
||||||
|
- 形成下一步行动
|
||||||
|
|
||||||
**适用于：**
|
产出通常是一份可回看的会话文档，便于继续深化或与团队同步。
|
||||||
|
|
||||||
- 突破创意瓶颈
|
## 什么时候使用
|
||||||
- 生成产品或功能想法
|
|
||||||
- 从新角度探索问题
|
|
||||||
- 将原始概念发展为行动计划
|
|
||||||
|
|
||||||
## 工作原理
|
- 你卡在创意瓶颈，知道问题但想不到可行解
|
||||||
|
- 你要做新功能或新产品，需要更多备选方案
|
||||||
|
- 你希望从不同角度挑战既有假设
|
||||||
|
- 你希望把“模糊想法”推进到“可执行方向”
|
||||||
|
|
||||||
1. **设置** - 定义主题、目标、约束
|
## 不适合的场景
|
||||||
2. **选择方法** - 自己选择技术、获取 AI 推荐、随机选择或遵循渐进式流程
|
|
||||||
3. **引导** - 通过探索性问题和协作式教练引导完成技术
|
|
||||||
4. **组织** - 将想法按主题分组并确定优先级
|
|
||||||
5. **行动** - 为顶级想法制定下一步和成功指标
|
|
||||||
|
|
||||||
所有内容都会被记录在会议文档中，你可以稍后参考或与利益相关者分享。
|
- 你已经有清晰方案，只差落地实现
|
||||||
|
- 你需要的是对现有文本做二次推理校验
|
||||||
|
- 你需要多角色辩论来做跨职能权衡
|
||||||
|
|
||||||
:::note[你的想法]
|
在这些场景下，更合适的是：
|
||||||
每个想法都来自你。工作流程创造洞察的条件——你是源头。
|
- `advanced elicitation`：对已有输出做结构化二次推理
|
||||||
|
- `bmad-party-mode`：让多个角色在同一会话内讨论权衡
|
||||||
|
|
||||||
|
## 它怎么推进思考
|
||||||
|
|
||||||
|
1. **设定主题**：定义目标、边界、约束
|
||||||
|
2. **选择方法**：手动选、让 AI 推荐、随机抽取或渐进流程
|
||||||
|
3. **引导展开**：通过连续问题挖掘更多可能性
|
||||||
|
4. **组织收敛**：按主题聚类并排序
|
||||||
|
5. **行动化**：给重点方向定义下一步和衡量标准
|
||||||
|
|
||||||
|
:::note[核心原则]
|
||||||
|
想法来源于你，workflow 负责构建“更容易产生好想法”的过程。
|
||||||
:::
|
:::
|
||||||
|
|
||||||
---
|
## 与相近模式的区别
|
||||||
## 术语说明
|
|
||||||
|
|
||||||
- **brainstorming**：头脑风暴。一种集体或个人的创意生成方法，通过自由联想和发散思维产生大量想法。
|
| 模式 | 核心目标 | 输入状态 | 典型输出 |
|
||||||
- **ideation**：构思。产生想法、概念或解决方案的过程。
|
| ----- | ----- | ----- | ----- |
|
||||||
- **facilitator**：引导者。在会议或工作坊中引导讨论、促进参与并帮助达成目标的人。
|
| `bmad-brainstorming` | 发散并收敛想法 | 方向模糊、问题开放 | 想法清单、优先级、下一步 |
|
||||||
- **creative blocks**：创意瓶颈。在创意过程中遇到的思维停滞或灵感枯竭状态。
|
| `advanced elicitation` | 对已有内容做二次推理 | 已有初稿或方案 | 改进版内容与推理补强 |
|
||||||
- **probing questions**：探索性问题。旨在深入挖掘信息、激发思考或揭示潜在见解的问题。
|
| `bmad-party-mode` | 多角色协同讨论与对齐 | 涉及多方权衡的议题 | 角色视角下的共识或分歧 |
|
||||||
- **stakeholders**：利益相关者。对项目或决策有利益关系或受其影响的个人或群体。
|
|
||||||
|
## 继续阅读
|
||||||
|
|
||||||
|
- [高级启发](./advanced-elicitation.md)
|
||||||
|
- [派对模式](./party-mode.md)
|
||||||
|
- [工作流地图](../reference/workflow-map.md)
|
||||||
|
|
|
||||||
|
|
@ -5,75 +5,54 @@ sidebar:
|
||||||
order: 7
|
order: 7
|
||||||
---
|
---
|
||||||
|
|
||||||
将所有 AI 智能体汇聚到一次对话中。
|
`bmad-party-mode` 用于多角色协作讨论：把 PM、架构、开发、UX 等视角放到同一轮对话里，快速暴露分歧、对齐取舍。
|
||||||
|
|
||||||
## 什么是 Party Mode？
|
## 它是什么
|
||||||
|
|
||||||
运行 `party-mode`，你的整个 AI 团队就齐聚一堂——PM、架构师、开发者、UX 设计师，任何你需要的人。BMad Master 负责编排，根据每条消息选择相关的智能体。智能体以角色身份回应，彼此同意、反对，并在彼此的想法基础上继续构建。
|
Party Mode 不是单角色问答，也不是单文档改写。它更像一次“有主持人的多方评审会”：
|
||||||
|
- BMad Master 根据你的问题调度相关角色
|
||||||
|
- 各角色以自身关注点回应
|
||||||
|
- 角色间会互相补充、质疑、修正
|
||||||
|
|
||||||
对话可以持续到你想要的时间。提出追问、对答案提出质疑、引导讨论方向——这是与智能体之间真正的来回交流，直到你完成目标。
|
你可以连续追问，直到形成可执行结论。
|
||||||
|
|
||||||
**适用于：**
|
## 什么时候使用
|
||||||
|
|
||||||
- 需要权衡的重大决策
|
- 面临高影响决策，且存在明确 trade-off
|
||||||
- 头脑风暴会议
|
- 需要跨角色快速对齐（产品、技术、交互、测试）
|
||||||
- 出现问题时的复盘
|
- 出现故障或争议，需要复盘责任和改进方向
|
||||||
- 冲刺回顾与规划
|
- 做 sprint 规划或回顾，需要多视角共识
|
||||||
|
|
||||||
## 示例
|
## 不适合的场景
|
||||||
|
|
||||||
### 指出糟糕的架构
|
- 你只需要单一角色的直接执行（例如仅改一段文案）
|
||||||
|
- 你已有明确决策，只需进入实现
|
||||||
|
- 你需要的是对同一输出做深度二次推理
|
||||||
|
|
||||||
**You:** "好了团队，我们上个冲刺是一场灾难。认证服务宕机了三次。谁搞砸了这件事？"
|
这些场景通常更适合：
|
||||||
|
- `bmad-quick-dev`（直接进入实现）
|
||||||
|
- `advanced elicitation`（二次推理补强）
|
||||||
|
|
||||||
**Architect:** "设计本身是合理的——分布式认证，有适当的回退机制。如果实现偏离了规范……"
|
## 价值与边界
|
||||||
|
|
||||||
**Dev:** "我完全按照架构文档执行的。规范没有考虑到并发会话失效的竞态条件。"
|
Party Mode 的价值在于“更快看见盲区”：
|
||||||
|
- 优势：视角多、分歧显性、对齐速度快
|
||||||
|
- 代价：讨论信息量大，需要你主动控节奏和收敛
|
||||||
|
|
||||||
**PM:** "你们两个都忽略了更大的问题——我们没有在 PRD 中验证会话管理需求。这是我的错，没有发现这一点。"
|
:::caution[使用建议]
|
||||||
|
先给清晰议题，再给决策约束（时间、风险、成本、成功标准），讨论质量会明显更高。
|
||||||
**TEA:** "我也应该在集成测试中发现这一点。测试场景没有覆盖并发失效。"
|
|
||||||
|
|
||||||
### 创意头脑风暴
|
|
||||||
|
|
||||||
**You:** "我们如何让入职体验变得神奇，而不是无聊？"
|
|
||||||
|
|
||||||
**UX Designer:** "从渐进式披露开始——在用户需要时揭示功能，而不是在教程中一次性展示所有内容。"
|
|
||||||
|
|
||||||
**Storyteller:** "如果入职是一个故事会怎样？每一步都揭示一个角色的旅程——用户就是英雄。"
|
|
||||||
|
|
||||||
**Game Designer:** "在此基础上——如果第一个'任务'实际上是解决一个真实的用户问题会怎样？他们通过做有价值的事情来学习。"
|
|
||||||
|
|
||||||
### 技术决策
|
|
||||||
|
|
||||||
**You:** "MVP 用单体还是微服务？"
|
|
||||||
|
|
||||||
**Architect:** "从单体开始。微服务会增加你在 1000 用户时不需要的复杂性。"
|
|
||||||
|
|
||||||
**PM:** "同意。上市时间比理论上的可扩展性更重要。"
|
|
||||||
|
|
||||||
**Dev:** "单体，但要有清晰的模块边界。如果需要，我们以后可以提取服务。"
|
|
||||||
|
|
||||||
:::tip[Better Decisions]
|
|
||||||
通过多元视角做出更好的决策。欢迎来到 party mode。
|
|
||||||
:::
|
:::
|
||||||
|
|
||||||
---
|
## 与相近模式的区别
|
||||||
## 术语说明
|
|
||||||
|
|
||||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
| 模式 | 核心目标 | 最佳场景 | 输出形态 |
|
||||||
- **PM**：产品经理（Product Manager）。
|
| ----- | ----- | ----- | ----- |
|
||||||
- **Architect**：架构师。
|
| `bmad-party-mode` | 多角色对齐与权衡 | 跨职能决策、复盘、规划 | 共识点、争议点、决策建议 |
|
||||||
- **Dev**：开发者（Developer）。
|
| `bmad-brainstorming` | 发散创意并收敛 | 方向探索、创意卡点 | 想法池与优先级 |
|
||||||
- **UX Designer**：用户体验设计师。
|
| `advanced elicitation` | 对现有输出做二次推理 | 规格/方案补强 | 改进版内容与风险补充 |
|
||||||
- **TEA**：测试工程师（Test Engineer/Automation）。
|
|
||||||
- **PRD**：产品需求文档（Product Requirements Document）。
|
## 继续阅读
|
||||||
- **MVP**：最小可行产品（Minimum Viable Product）。
|
|
||||||
- **monolith**：单体架构。一种将应用程序构建为单一、统一单元的架构风格。
|
- [头脑风暴](./brainstorming.md)
|
||||||
- **microservices**：微服务。一种将应用程序构建为一组小型、独立服务的架构风格。
|
- [高级启发](./advanced-elicitation.md)
|
||||||
- **progressive disclosure**：渐进式披露。一种交互设计模式，仅在用户需要时显示信息或功能。
|
- [工作流地图](../reference/workflow-map.md)
|
||||||
- **post-mortem**：复盘。对事件或项目进行事后分析，以了解发生了什么以及如何改进。
|
|
||||||
- **sprint**：冲刺。敏捷开发中的固定时间周期，通常为 1-4 周。
|
|
||||||
- **race condition**：竞态条件。当多个进程或线程同时访问和操作共享数据时，系统行为取决于执行顺序的一种情况。
|
|
||||||
- **fallback**：回退机制。当主要方法失败时使用的备用方案。
|
|
||||||
- **time to market**：上市时间。产品从概念到推向市场所需的时间。
|
|
||||||
|
|
|
||||||
|
|
@ -5,69 +5,82 @@ sidebar:
|
||||||
order: 2
|
order: 2
|
||||||
---
|
---
|
||||||
|
|
||||||
输入意图，输出代码变更，尽可能少的人机交互轮次——同时不牺牲质量。
|
`bmad-quick-dev` 的目标很直接：在保证质量边界的前提下，把“意图到代码”的人机往返轮次降到最低。
|
||||||
|
|
||||||
它让模型在检查点之间运行更长时间，只有在任务无法在没有人类判断的情况下安全继续时，或者需要审查最终结果时，才会让人类介入。
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## 为什么需要这个功能
|
## 它解决什么问题
|
||||||
|
|
||||||
人机交互轮次既必要又昂贵。
|
纯人工频繁盯流程会拖慢速度，纯自动又容易偏航。Quick Dev 做的是中间解：
|
||||||
|
- 在关键节点保留人工判断
|
||||||
|
- 在可控区间放大模型自主执行时长
|
||||||
|
- 通过规范与审查把偏航风险收回来
|
||||||
|
|
||||||
当前的 LLM 仍然会以可预测的方式失败：它们误读意图、用自信的猜测填补空白、偏离到不相关的工作中，并生成嘈杂的审查输出。与此同时，持续的人工干预限制了开发速度。人类注意力是瓶颈。
|
## Quick Dev 的核心机制
|
||||||
|
|
||||||
`bmad-quick-dev` 重新平衡了这种权衡。它信任模型在更长的时间段内无监督运行，但前提是工作流已经创建了足够强的边界来确保安全。
|
### 1. 先把意图压缩成单一目标
|
||||||
|
|
||||||
## 核心设计
|
无论输入来自几句话、issue 链接、计划稿，还是 `epics.md` 的 `story`，都要先压缩成一个可执行目标。
|
||||||
|
目标不清晰时，后续自动化越强，偏差成本越高。
|
||||||
|
|
||||||
### 1. 首先压缩意图
|
### 2. 选择最小安全路径
|
||||||
|
|
||||||
工作流首先让人类和模型将请求压缩成一个连贯的目标。输入可以从粗略的意图表达开始，但在工作流自主运行之前，它必须变得足够小、足够清晰、没有矛盾。
|
目标明确后，workflow 会判断：
|
||||||
|
- 是不是“零爆炸半径”的 one-shot 变更
|
||||||
|
- 还是必须先走 planning 再实现
|
||||||
|
|
||||||
意图可以以多种形式出现：几句话、一个错误追踪器链接、计划模式的输出、从聊天会话复制的文本，甚至来自 BMAD 自己的 `epics.md` 的故事编号。在最后一种情况下，工作流不会理解 BMAD 故事跟踪语义，但它仍然可以获取故事本身并继续执行。
|
原则是：能走短路径就不走长路径，但不能为了快跳过必要边界。
|
||||||
|
|
||||||
这个工作流并不会消除人类的控制。它将其重新定位到少数几个高价值时刻：
|
### 3. 在边界内长时自主执行
|
||||||
|
|
||||||
- **意图澄清** - 将混乱的请求转化为一个没有隐藏矛盾的连贯目标
|
当目标与规范足够清晰，模型会承担更长段的连续实现。
|
||||||
- **规范审批** - 确认冻结的理解是正确要构建的东西
|
这一步省下的是“重复确认成本”，不是“质量成本”。
|
||||||
- **最终产品审查** - 主要检查点，人类在最后决定结果是否可接受
|
|
||||||
|
|
||||||
### 2. 路由到最小安全路径
|
### 4. 在正确层级修复问题
|
||||||
|
|
||||||
一旦目标清晰，工作流就会决定这是一个真正的单次变更还是需要更完整的路径。小的、零爆炸半径的变更可以直接进入实现。其他所有内容都需要经过规划，这样模型在独自运行更长时间之前就有更强的边界。
|
Quick Dev 会区分问题来源：
|
||||||
|
- **意图层问题**：需求理解本身不对
|
||||||
|
- **规范层问题**：tech-spec 边界不够强
|
||||||
|
- **实现层问题**：本地代码缺陷
|
||||||
|
|
||||||
### 3. 以更少的监督运行更长时间
|
只有实现层问题才直接补代码；上层问题要回到对应层级重做。
|
||||||
|
|
||||||
在那个路由决策之后，模型可以自己承担更多工作。在更完整的路径上，批准的规范成为模型在较少监督下执行的边界，这正是设计的全部意义。
|
### 5. 只在必要时拉回人工
|
||||||
|
|
||||||
### 4. 在正确的层诊断失败
|
人类主要在三个高杠杆时刻介入：
|
||||||
|
- 意图澄清
|
||||||
|
- 规范确认
|
||||||
|
- 最终结果审查
|
||||||
|
|
||||||
如果实现是错误的，因为意图是错误的，修补代码是错误的修复。如果代码是错误的，因为规范太弱，修补差异也是错误的修复。工作流旨在诊断失败从系统的哪个层面进入，回到那个层面，并从那里重新生成。
|
## 为什么它和“普通自动化”不一样
|
||||||
|
|
||||||
审查发现用于确定问题来自意图、规范生成还是本地实现。只有真正的本地问题才会在本地修补。
|
Quick Dev 不追求“全自动”，而是追求“最少但有效的人类判断”。
|
||||||
|
它把人工注意力从大量低价值确认，转移到少量高价值决策。
|
||||||
|
|
||||||
### 5. 只在需要时让人类回来
|
## 与对抗性评审的关系
|
||||||
|
|
||||||
意图访谈是人机交互，但它不是与重复检查点相同类型的中断。工作流试图将那些重复检查点保持在最低限度。在初始意图塑造之后，人类主要在工作流无法在没有判断的情况下安全继续时，以及在最后需要审查结果时才回来。
|
Quick Dev 是执行节奏设计；`adversarial review` 是审查策略。二者经常配合：
|
||||||
|
- Quick Dev 负责高效推进实现
|
||||||
|
- 对抗性评审负责提高问题发现率并做分诊
|
||||||
|
|
||||||
- **意图差距解决** - 当审查证明工作流无法安全推断出原本意图时重新介入
|
也就是说，Quick Dev 解决“怎么更快且更稳地跑”，对抗性评审解决“怎么更狠地查问题”。
|
||||||
|
|
||||||
其他一切都是更长自主执行的候选。这种权衡是经过深思熟虑的。旧模式在持续监督上花费更多的人类注意力。快速开发在模型上投入更多信任，但将人类注意力保留在人类推理具有最高杠杆作用的时刻。
|
## 适用边界
|
||||||
|
|
||||||
## 为什么审查系统很重要
|
**适合：**
|
||||||
|
- 目标可定义、可验收的实现任务
|
||||||
|
- 希望减少流程摩擦但不放弃质量门
|
||||||
|
|
||||||
审查阶段不仅仅是为了发现错误。它是为了在不破坏动力的情况下路由修正。
|
**不适合：**
|
||||||
|
- 目标长期模糊且频繁变化
|
||||||
|
- 团队尚未接受“先规格后长时执行”的工作方式
|
||||||
|
|
||||||
这个工作流在能够生成子智能体的平台上效果最好，或者至少可以通过命令行调用另一个 LLM 并等待结果。如果你的平台本身不支持这一点，你可以添加一个技能来做。无上下文子智能体是审查设计的基石。
|
:::tip[实践建议]
|
||||||
|
先把成功标准写清楚，再启用 Quick Dev。目标越清楚，自动化收益越大。
|
||||||
|
:::
|
||||||
|
|
||||||
智能体审查经常以两种方式出错：
|
## 继续阅读
|
||||||
|
|
||||||
- 它们生成太多发现，迫使人类在噪音中筛选
|
- [对抗性评审](./adversarial-review.md)
|
||||||
- 它们通过提出不相关的问题并使每次运行变成临时清理项目来使当前变更脱轨
|
- [高级启发](./advanced-elicitation.md)
|
||||||
|
- [工作流地图](../reference/workflow-map.md)
|
||||||
快速开发通过将审查视为分诊来解决这两个问题。
|
|
||||||
|
|
||||||
一些发现属于当前变更。一些不属于。如果一个发现是附带的而不是与当前工作有因果关系，工作流可以推迟它，而不是强迫人类立即处理它。这使运行保持专注，并防止随机的分支话题消耗注意力的预算。
|
|
||||||
|
|
||||||
那个分诊有时会不完美。这是可以接受的。通常，误判一些发现比用成千上万个低价值的审查评论淹没人类要好。系统正在优化信号质量，而不是详尽的召回率。
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue