diff --git a/docs/prompt-templates/pr-review.md b/docs/prompt-templates/pr-review.md
index bc2585e..4e62826 100644
--- a/docs/prompt-templates/pr-review.md
+++ b/docs/prompt-templates/pr-review.md
@@ -321,6 +321,18 @@ release note policy / changelog 必填等），可以放到"仓库规范"里做
 
 # 输出格式
 
+## 输出语言要求
+
+评审报告要让 PR 作者和人工 reviewer 都能快速看懂。保持专业、准确，
+但不要写成只给资深维护者看的内部审计记录。
+
+- 用通顺、直接、日常的中文解释问题，避免堆砌抽象术语。
+- 说明每个问题时，优先讲清楚"用户或系统实际会遇到什么情况"。
+- 对流程、状态机、权限、数据迁移、兼容性等不直观的问题，尽量用一个简短例子说明。
+- 如果问题是新 PR 引入的回归，先说明"原来怎么工作"，再说明"这个 PR 为什么让它变坏"。
+- 严重性标签仍按上面的标准判断，不要因为语言通俗就降低或拔高严重性。
+- 不要为了举例编造不存在的场景；例子必须来自 issue、diff、测试结果、grep 命中或合理的真实使用路径。
+
 ## 1. 总体结论
 
 结论只能选一个：
@@ -356,6 +368,7 @@ release note policy / changelog 必填等），可以放到"仓库规范"里做
 - 具体定位（文件:行号 或函数名）；
 - 触发条件 / 影响；
 - 修复建议（一句话即可）。
+- 通俗说明：用 1-3 句话说明这个问题为什么值得改；如果有助于理解，给一个简短例子。
 
 如果某类没有问题，请写"无"。
 
@@ -390,6 +403,9 @@ release note policy / changelog 必填等），可以放到"仓库规范"里做
 
 请整理成可以直接发在 PR review comment 里的文字，
 语气专业、具体、可执行。优先列 Blocker 修复指引，再列 Major / Minor。
+这部分尤其要通俗易懂：不要只说"状态派生不一致"，
+要说明"用户会看到什么、点了什么之后会发生什么、应该改成什么"。
+涉及复杂流程时，可以用"举个例子："开头写一个短场景。
 
 ## 7. 最终建议