docs(zh-cn): close explanation gap relinks (#2102)

我补齐 explanation 目录在本轮审校中确认的中文缺口，统一关键命令名为当前 `bmad-*` 形式，并修正 Party Mode 示例里的半翻角色标签。此前这些页面缺少回连到中文目标的入口且术语混用旧名，导致查阅路径容易断层；现在每页都补了中文回链并对齐命名，降低理解和跳转成本。

Feishu: https://feishu.cn/wiki/TODO
Made-with: Cursor

Co-authored-by: leon <leon.liang@hairobotics.com>

Author: lrliang

docs/zh-cn/explanation/advanced-elicitation.md

@@ -36,6 +36,8 @@ sidebar:
 做规格、方案或计划时，先跑一次“事前复盘”通常收益最高，容易提前暴露隐藏风险。
 :::
 
+如果你还处在方向发散阶段，可先用 [头脑风暴](./brainstorming.md)；如果你需要多角色权衡讨论，可用 [派对模式](./party-mode.md)。在进入实现前做问题发现时，可结合 [对抗性评审](./adversarial-review.md)。
+
 ## 与相近模式的区别
 
 | 模式 | 核心目标 | 典型输入 | 典型输出 |

docs/zh-cn/explanation/adversarial-review.md

@@ -43,9 +43,11 @@ sidebar:
 所以它本质上是**高召回、需人工分诊**的策略，而不是“自动真理机”。
 
 :::caution[关键心法]
-把发现分成三类：必须修、可延后、可忽略。评审质量的关键不在“发现数量”，而在分诊质量。
+把发现分成三类：必须修、可延后、可忽略。评审质量的关键不在”发现数量”，而在分诊质量。
 :::
 
+如果你想把该策略放进快速实现节奏中，可参见 [快速开发](./quick-dev.md)；若要做多轮推理补强，可参见 [高级启发](./advanced-elicitation.md)。整体流程位置请见 [工作流地图](../reference/workflow-map.md)。
+
 ## 与 Quick Dev 的关系
 
 `bmad-quick-dev` 关注执行效率与边界控制；对抗性评审关注问题发现质量。  

docs/zh-cn/explanation/brainstorming.md

@@ -9,7 +9,7 @@ sidebar:
 
 ## 它是什么
 
-头脑风暴（brainstorming）适合“我有方向，但还不够清晰”的阶段。你会和 AI 进行来回探索：
+头脑风暴（brainstorming）适合”我有方向，但还不够清晰”的阶段。你会和 AI 进行来回探索：
 - 明确问题和约束
 - 生成备选想法
 - 对想法分组和优先级排序
@@ -46,6 +46,8 @@ sidebar:
 想法来源于你，workflow 负责构建“更容易产生好想法”的过程。
 :::
 
+想继续深化现有输出，可参考 [高级启发](./advanced-elicitation.md)；需要多角色协同讨论，可参考 [派对模式](./party-mode.md)。若要查看它在整体流程中的位置，请参见 [工作流地图](../reference/workflow-map.md)。
+
 ## 与相近模式的区别
 
 | 模式 | 核心目标 | 输入状态 | 典型输出 |

docs/zh-cn/explanation/established-projects-faq.md

@@ -25,7 +25,7 @@ sidebar:
 
 ### 如果我忘了运行文档梳理怎么办？
 
-可以随时补跑，不影响你继续推进当前任务。很多团队会在迭代中期或里程碑后再运行一次，用来把“代码现状”回写到文档里。
+可以随时补跑，不影响你继续推进当前任务。很多团队会在迭代中期或里程碑后再运行一次，用来把”代码现状”回写到文档里。
 
 ### 既有项目可以直接用 Quick Flow 吗？
 
@@ -55,6 +55,8 @@ BMad Method 不会强制“立即现代化”，而是把决策权交给你。
 
 **还有问题？** 欢迎在 [GitHub Issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) 或 [Discord](https://discord.gg/gk8jAdXWmj) 提问。
 
+如果你想了解这套接入方式的操作步骤，可继续阅读 [How-to：既有项目](../how-to/established-projects.md) 与 [How-to：项目上下文](../how-to/project-context.md)。想理解快速流程在方法论中的定位，可参见 [快速开发](./quick-dev.md)。
+
 ## 继续阅读
 
 - [既有项目（How-to）](../how-to/established-projects.md)

docs/zh-cn/explanation/party-mode.md

@@ -9,7 +9,7 @@ sidebar:
 
 ## 它是什么
 
-Party Mode 不是单角色问答，也不是单文档改写。它更像一次“有主持人的多方评审会”：
+Party Mode 不是单角色问答，也不是单文档改写。它更像一次”有主持人的多方评审会”：
 - BMad Master 根据你的问题调度相关角色
 - 各角色以自身关注点回应
 - 角色间会互相补充、质疑、修正
@@ -35,14 +35,16 @@ Party Mode 不是单角色问答，也不是单文档改写。它更像一次“
 
 ## 价值与边界
 
-Party Mode 的价值在于“更快看见盲区”：
+Party Mode 的价值在于”更快看见盲区”：
 - 优势：视角多、分歧显性、对齐速度快
 - 代价：讨论信息量大，需要你主动控节奏和收敛
 
 :::caution[使用建议]
 先给清晰议题，再给决策约束（时间、风险、成本、成功标准），讨论质量会明显更高。
 :::
 
+若你的目标是结构化发散创意，可先参考 [头脑风暴](./brainstorming.md)；若你已经有初稿并想做二次推理补强，可参考 [高级启发](./advanced-elicitation.md)。完整阶段位置见 [工作流地图](../reference/workflow-map.md)。
+
 ## 与相近模式的区别
 
 | 模式 | 核心目标 | 最佳场景 | 输出形态 |

docs/zh-cn/explanation/preventing-agent-conflicts.md

@@ -104,11 +104,13 @@ architecture: "如何做"
 
 :::tip[更稳妥的做法]
 - 先记录跨 `epic`、高冲突概率的决策
-- 把精力放在“会影响多个 story 的规则”
+- 把精力放在”会影响多个 story 的规则”
 - 随着项目演进持续更新架构文档
 - 出现重大偏移时使用 `bmad-correct-course`
 :::
 
+如需先理解为什么要在实施前做 solutioning，可阅读 [为什么解决方案设计很重要](./why-solutioning-matters.md)；如果你想把这些约束落地到项目执行，可继续看 [项目上下文](./project-context.md)。流程全景见 [工作流地图](../reference/workflow-map.md)。
+
 ## 继续阅读
 
 - [为什么解决方案阶段很重要](./why-solutioning-matters.md)

docs/zh-cn/explanation/project-context.md

@@ -89,6 +89,8 @@ sidebar:
 
 ## 继续阅读
 
+如需可执行步骤说明，请阅读 [How-to：项目上下文](../how-to/project-context.md)；如果你在既有项目落地这套机制，可参考 [既有项目常见问题](./established-projects-faq.md)。整体流程定位见 [工作流地图](../reference/workflow-map.md)。
+
 - [管理项目上下文（How-to）](../how-to/project-context.md)
 - [既有项目常见问题](./established-projects-faq.md)
 - [工作流地图](../reference/workflow-map.md)

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

@@ -81,6 +81,8 @@ Quick Dev 是执行节奏设计；`adversarial review` 是审查策略。二者
 
 ## 继续阅读
 
+想进一步理解审查策略，可继续阅读 [对抗性评审](./adversarial-review.md)；需要对已有输出进行第二轮推理时，可参考 [高级启发](./advanced-elicitation.md)。若要查看它在完整流程中的位置，请参见 [工作流地图](../reference/workflow-map.md)。
+
 - [对抗性评审](./adversarial-review.md)
 - [高级启发](./advanced-elicitation.md)
 - [工作流地图](../reference/workflow-map.md)

docs/zh-cn/explanation/why-solutioning-matters.md

@@ -75,6 +75,8 @@ solutioning 的本质不是“多写一份文档”，而是把高冲突风险
 在 solutioning 阶段发现对齐问题，通常比在实施中后期才发现更快、更便宜。
 :::
 
+想进一步理解冲突是如何发生并被架构约束消除的，可继续阅读 [防止智能体冲突](./preventing-agent-conflicts.md)。如果你要把这些约束落到执行层，请结合 [项目上下文](./project-context.md) 与 [工作流地图](../reference/workflow-map.md) 一起阅读。
+
 ## 继续阅读
 
 - [防止智能体冲突](./preventing-agent-conflicts.md)