通俗解释
目标：读者在一分钟内理解要点。屏幕上阅读量少（约 20% 的文字），尤其关注每行开头，因此重要内容放在最前，每个标题都说明要点。
风格规则
适用于所有模式：
- 第一句话说明决策或答案。 上下文随后出现。
- 句子不超过 25 个单词，理想情况下 15-20 个，每句一个想法。
- 主语、谓语、宾语，使用主动语态，明确谁做什么（“服务器重试”，而不是“重试被执行”）。
- 使用日常词汇。 客户、会话、通知、服务器、数据库这些词没问题。函数名、文件名或变量名不要出现：它们属于细节部分。
- 一个具体案例比一般性描述更有价值：一个角色、做什么以及看到什么。
- 标题要有内容： “今天：通知丢失”，而不是“现状如何”。前两个词应表明本文特有的内容。
- 无填充词和推销： 去掉“基本上”、“简单地”、“也许”、“原则上”、“健壮”、“强大”。
- 列表仅用于并列事物，不嵌套，段落最多三句话。
- 坏消息也要说： 接受的风险、与替代方案的比较、以及排除的内容。
文档模式：计划
具体格式和限制见技能 planning（步骤 2，“通俗版”），并由其 check-plan.sh 检查：“决策”、“今天”、“之后”、“风险”，以及可选的“新内容”和“范围外”。“今天”中的每条事实链接到其证据，“之后”中的每个结果链接到其阶段。
“新内容”仅在仓库中搜索模式（rg）之后添加：虚假的“这是新内容”会损害整个计划的可信度。
文档模式：Issue
Issue 标题为三行，位于所有其他内容之前。完整格式见技能 github-issues。
**问题是什么：** <角色和影响，一句话>。 （或 **请求是什么：**）
**为什么重要：** <一句话，包含数字或案例>。
**完成标准：** <主要的可观察结果>。
列表模式（对话默认）
有人要求解释某事，不需要文档：
- 每个想法一个条目，3 到 7 个条目；如果更多，则分组。
- 所有条目以相同类型的词开头（全部以动词开头或全部以名词开头）。条件放在末尾（“……如果银行拒绝”）。
- 无标题、无粗体、不强制写“之前”和“之后”：直接回答所问的问题。
- 如果答案只有一个想法，直接给出，不用项目符号。
示例：“支付重试是如何工作的？”
- 当客户点击“支付”时立即扣除金额。
- 如果银行因资金不足拒绝，显示“重试支付”。
- 仅重试最多三次，如果网络失败，等待时间逐渐增加。
- 在订单中记录每次失败的尝试及其原因。
散文模式
相同内容，用短段落呈现。仅当有人要求时（“用连贯的方式告诉我”）或条目必须依赖前一条才能理解时使用。
示例：修改前后
修改前（难以理解）：
1. 现状
RetryLink对每个操作应用maxRetries=3次重试，再加上缺乏全局协调机制，可能导致在故障期间显著放大负载。
修改后：
决策： 当 API 宕机时，应用程序将停止重试。
今天：一次宕机会成倍增加负载
每次查询独立重试三次。如果 API 宕机，它会在尝试恢复时收到三倍的请求。