docs: refine GitHub reply tone

Co-authored-by: Codex <noreply@openai.com>
2026-11-06 00:06:08 +00:00 · 2026-10-31 21:09:49 +08:00
parent bcf0582814
commit 839054cdaf
2 changed files with 4 additions and 2 deletions
@@ -44,7 +44,9 @@ Issue 可记录复现、排查和变更经过；涉及常规文档修改时执

 草拟、发布或修改 Issue 回复时，按 [GitHub 回复口吻](../../../CONTRIBUTING.md#github-回复口吻)将核实结果写成面向提问者的交流答复，具体口吻规则集中维护在该节

-发送或更新前从提问者视角通读：是否接住了他的目标和困难，建议是否便于尝试，补充材料的用途是否清楚，澄清或拒绝是否耐心解释了原因，能提供的替代办法是否说清。发现生硬时调整整句措辞与前后衔接，不能仅加缓和词；保留已核实的结论
+按平常回帖的口吻写，语气自然、委婉，说清判断和原因，少用铺垫、转折和自我说明；暂不采纳或提出不同意见时说明具体原因
+
+发送或更新前从提问者视角通读：判断和原因是否清楚，建议是否便于尝试，补充材料的用途是否明确。删去不影响理解的客套、重复解释和过程说明；发现生硬时调整整句，不能仅加缓和词，保留已核实的结论

 ## 发布与收尾

@@ -26,7 +26,7 @@ AI 草拟、发布或修改 Issue、PR 讨论及审查意见的回复时，以
 - 围绕问题、事实和结论展开，能自然省略主语时省略；需要说明个人判断或行动归属时用“我”，避免反复以“我”起句或强调自己，不用“我们”“本助手”代称自己
 - 普通回复直接回应问题，不加问候语或称呼；向对方提问时称呼“佬”，同一条回复不重复称呼
 - 先接住对方想完成的事和遇到的困难，再给出核实结果与建议；回复让对方感到问题被理解、有下一步可做，避免一上来归类、纠正或划定责任
- 建议用商量的口吻，说明尝试某个操作能帮助判断什么，给对方留出选择空间；“可以试试”“方便的话”等表达随语境使用，整句仍需自然，不靠堆叠缓和词修饰命令
+- 给出操作建议时说明它能帮助判断什么，措辞自然、委婉，不靠堆叠缓和词修饰命令
 - 回应已有能力、暂不支持或未采纳的建议时，结合场景说明可用入口或具体原因，有可行替代办法时一并说明，再交代必要边界；避免只回复“已有功能”“重复问题”“不在范围内”等结论
 - 需要补充材料或配合操作时，先利用已有信息，只询问仍缺少的部分，说明用途和最小范围；例如“佬，方便再观察几次吗？如果还出现，可以附一下对应请求的诊断包，便于对照终态用量”
 - 澄清误解或提出不同意见时，从观察和依据说起，照顾对方的使用环境与理解路径，避免责备、反问或居高临下的判断；已确认的事实保持明确，尚未确认的原因保留余地