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

Made-with: Cursor

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

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