docs(zh-cn): add translation for quick-dev-new-preview

Translate docs/explanation/quick-dev-new-preview.md to Chinese.
This document explains the experimental Quick Flow improvement
that reduces human-in-the-loop friction while maintaining quality.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/zh-cn/explanation/quick-dev-new-preview.md

@@ -0,0 +1,73 @@
+---
+title: "快速开发新预览"
+description: 在不牺牲输出质量检查点的情况下减少人机交互的摩擦
+sidebar:
+  order: 2
+---
+
+`bmad-quick-dev-new-preview` 是对快速流程（Quick Flow）的一次实验性改进：输入意图，输出代码变更，减少流程仪式和人机交互轮次，同时不牺牲质量。
+
+它让模型在检查点之间运行更长时间，只有在任务无法在没有人类判断的情况下安全继续时，或者需要审查最终结果时，才会让人类介入。
+
+![快速开发新预览工作流图](/diagrams/quick-dev-diagram.png)
+
+## 为什么需要这个功能
+
+人机交互轮次既必要又昂贵。
+
+当前的 LLM 仍然会以可预测的方式失败：它们误读意图、用自信的猜测填补空白、偏离到不相关的工作中，并生成嘈杂的审查输出。与此同时，持续的人工干预限制了开发速度。人类注意力是瓶颈。
+
+这个快速流程的实验版本是对这种权衡的重新平衡尝试。它信任模型在更长的时间段内无监督运行，但前提是工作流已经创建了足够强的边界来确保安全。
+
+## 核心设计
+
+### 1. 首先压缩意图
+
+工作流首先让人类和模型将请求压缩成一个连贯的目标。输入可以从粗略的意图表达开始，但在工作流自主运行之前，它必须变得足够小、足够清晰、没有矛盾。
+
+意图可以以多种形式出现：几句话、一个错误追踪器链接、计划模式的输出、从聊天会话复制的文本，甚至来自 BMAD 自己的 `epics.md` 的故事编号。在最后一种情况下，工作流不会理解 BMAD 故事跟踪语义，但它仍然可以获取故事本身并继续执行。
+
+这个工作流并不会消除人类的控制。它将其重新定位到少数几个高价值时刻：
+
+- **意图澄清** - 将混乱的请求转化为一个没有隐藏矛盾的连贯目标
+- **规范审批** - 确认冻结的理解是正确要构建的东西
+- **最终产品审查** - 主要检查点，人类在最后决定结果是否可接受
+
+### 2. 路由到最小安全路径
+
+一旦目标清晰，工作流就会决定这是一个真正的单次变更还是需要更完整的路径。小的、零爆炸半径的变更可以直接进入实现。其他所有内容都需要经过规划，这样模型在独自运行更长时间之前就有更强的边界。
+
+### 3. 以更少的监督运行更长时间
+
+在那个路由决策之后，模型可以自己承担更多工作。在更完整的路径上，批准的规范成为模型在较少监督下执行的边界，这正是实验的全部意义。
+
+### 4. 在正确的层诊断失败
+
+如果实现是错误的，因为意图是错误的，修补代码是错误的修复。如果代码是错误的，因为规范太弱，修补差异也是错误的修复。工作流旨在诊断失败从系统的哪个层面进入，回到那个层面，并从那里重新生成。
+
+审查发现用于确定问题来自意图、规范生成还是本地实现。只有真正的本地问题才会在本地修补。
+
+### 5. 只在需要时让人类回来
+
+意图访谈是人机交互，但它不是与重复检查点相同类型的中断。工作流试图将那些重复检查点保持在最低限度。在初始意图塑造之后，人类主要在工作流无法在没有判断的情况下安全继续时，以及在最后需要审查结果时才回来。
+
+- **意图差距解决** - 当审查证明工作流无法安全推断出原本意图时重新介入
+
+其他一切都是更长自主执行的候选。这种权衡是经过深思熟虑的。旧模式在持续监督上花费更多的人类注意力。快速开发新预览在模型上投入更多信任，但将人类注意力保留在人类推理具有最高杠杆作用的时刻。
+
+## 为什么审查系统很重要
+
+审查阶段不仅仅是为了发现错误。它是为了在不破坏动力的情况下路由修正。
+
+这个工作流在能够生成子智能体的平台上效果最好，或者至少可以通过命令行调用另一个 LLM 并等待结果。如果你的平台本身不支持这一点，你可以添加一个技能来做。无上下文子智能体是审查设计的基石。
+
+智能体审查经常以两种方式出错：
+
+- 它们生成太多发现，迫使人类在噪音中筛选
+- 它们通过提出不相关的问题并使每次运行变成临时清理项目来使当前变更脱轨
+
+快速开发新预览通过将审查视为分诊来解决这两个问题。
+
+一些发现属于当前变更。一些不属于。如果一个发现是附带的而不是与当前工作有因果关系，工作流可以推迟它，而不是强迫人类立即处理它。这使运行保持专注，并防止随机的分支话题消耗注意力的预算。
+
+那个分诊有时会不完美。这是可以接受的。通常，误判一些发现比用成千上万个低价值的审查评论淹没人类要好。系统正在优化信号质量，而不是详尽的召回率。