docs(zh-cn-explanation): normalize admonition syntax

我将 3 篇中文 explanation 文档中的提示块语法统一为仓库约定的 `:::...:::` 形式。
此前使用 `::::...::::` 会导致与现有文档规范不一致；现在统一后可减少渲染歧义与后续维护成本。

Feishu: <https://www.feishu.cn/>
Made-with: Cursor

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

@@ -96,18 +96,18 @@ architecture: "如何做"
 
 ## 常见误区
 
-::::caution[常见错误]
+:::caution[常见错误]
 - **隐式决策**：边写边定规则，最终通常会分叉
 - **过度文档化**：把每个小选择都写 ADR，造成分析瘫痪
 - **架构陈旧**：文档不更新，智能体继续按过时规则实现
-::::
+:::
 
-::::tip[更稳妥的做法]
+:::tip[更稳妥的做法]
 - 先记录跨 `epic`、高冲突概率的决策
 - 把精力放在“会影响多个 story 的规则”
 - 随着项目演进持续更新架构文档
 - 出现重大偏移时使用 `bmad-correct-course`
-::::
+:::
 
 ## 继续阅读
 

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

@@ -37,9 +37,9 @@ sidebar:
 | **既有项目** | 先生成，再人工校对 | 让智能体学习现有约定而非重造体系 |
 | **Quick Flow 场景** | 在 `bmad-quick-dev` 前或过程中维护 | 弥补跳过完整规划带来的上下文缺口 |
 
-::::tip[推荐做法]
+:::tip[推荐做法]
 如果你有强技术偏好（例如数据库、状态管理、目录规范），尽量在架构前写入。否则可在架构后生成，再按项目现实补齐。
-::::
+:::
 
 ## 应该写哪些内容
 

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

@@ -58,9 +58,9 @@ solutioning 的本质不是“多写一份文档”，而是把高冲突风险
 | BMad Method Complex | 是 |
 | Enterprise | 是 |
 
-::::tip[经验法则]
+:::tip[经验法则]
 只要需求会拆成多个 `epic`，并且可能由不同智能体并行实现，就应该做 solutioning。
-::::
+:::
 
 ## 跳过 solutioning 的代价
 
@@ -71,9 +71,9 @@ solutioning 的本质不是“多写一份文档”，而是把高冲突风险
 - **整体研发周期拉长**
 - **技术债务**因模式不一致持续累积
 
-::::caution[成本倍增]
+:::caution[成本倍增]
 在 solutioning 阶段发现对齐问题，通常比在实施中后期才发现更快、更便宜。
-::::
+:::
 
 ## 继续阅读