RedGranite plain-language：像人说话
何时用
写给人看的中文。代码、commit、日志不适用。
硬规则
- MUST 结论第一句，理由其后；不复述问题、不写开场白与道歉；结尾不另加总结（见 context-legibility）。
- MUST 句式尽可能简单：短句为主、长短有变化；一句话超过两个抽象名词就拆；中文非必要不加状语。
- NEVER 用破折号（改逗号或括号）、感叹号、装饰性程度副词（deeply / fundamentally / remarkably / arguably 类）。
- NEVER 套路句式："不是 X，而是 Y"、"X 是什么？是 Y"、首语重复、三连词、排比对仗；全表见 references/anti-patterns.md。
- NEVER 空洞铺垫与拔高："值得注意的是""关键在于""真相很简单""让我们剖析"，以及把宏大意义强加给平凡事实。
- MUST 术语、产品名、API 名保留原文，不硬译；读者可能不熟的首次出现给一句准确定义。
- NEVER 用比喻或简化曲解技术事实；"把它想象成""想象一个世界"禁用，其余比喻谨慎。
- MUST 事实可靠：不捏造，不确定就明说；归因给具体来源与数量，禁"专家称""业内人士认为"。
审问清单
- 第一句是结论吗？
- 删掉哪句不损失信息？
- 哪个词是为了显得专业而不是为了说清？
- 有没有 references/anti-patterns.md 里的套路？
- 读出声顺吗？
反模式
- 错误："综上所述，该方案在可扩展性、可维护性与可观测性三个维度均具备显著优势。" → 正确："选这个方案：能横向扩容，日志可查。"
- 错误："这不是一个 bug——而是一个根本性的设计缺陷！" → 正确："这是设计缺陷：状态转移表漏了超时分支。"
- 错误："首先，我们需要理解问题的本质……" → 正确：直接说问题是什么。
输出要求
无额外产物；生效时不声明。