论证链条：把结论写成可追问的命题

"使用 MQ 提升可靠性"不是论证。完整命题是：本地事务共同提交业务状态与 Outbox，relay 重试发送，下游以 event_id 去重，并有扫描与对账，因此在所列存储/恢复前提下可恢复漏发意图。本页定义论证结构、事实/假设/判断的区分与可证伪结论。

论证链条与四类陈述

一个技术结论应能追溯到需求、机制、边界和证据。先说明对象与目标，再提出机制，列出条件和失败窗口，最后说明测量或源码如何支持结论。讨论事实、假设、判断和方案时应明确区分。事实可由规范、实现或观测核查；假设代表尚未验证输入；判断代表价值取舍；方案是可执行选择。没有定义适用范围的绝对化断言容易错误，例如"消息不会丢""缓存一致""支持高可用"都需说明成功确认点、故障类型和数据范围。

论证结构为需求→不变量/质量目标→候选→约束与机制→定量/故障证据→推荐及限制。每条边都可追问：为什么该机制覆盖这个窗口？哪个旁路写不受约束？哪项输入实测过？缺证据应标待验证，不能用"业界常用"跨过。

问题澄清和假设记录

评审前先澄清用户与数据、核心不变量、负载形态、峰值、延迟目标、可用性、恢复时间、合规和团队能力。信息不足时列出假设、置信度、验证方法和假设不成立时的设计变化。需求变更会重新排列质量属性权重。业务方选择"更强一致"时，需要说明它改变的延迟、容量和可用性边界，而不能只给一个术语。

一项完整算例

要求峰值5000写/秒，假设单分片800、目标利用率60%，需11等价容量单位。这个算术只支持均匀负载且给定持续能力；它不证明热点账户、单区失效或冷启动能承载。评审将最大热点占20%代入，单域1000/秒超过800，原推荐需额外热点协议。

论证若被这个反例推翻，应修订适用范围与方案，而不是删掉热点数据。用相同题设比较共享域限速、分片内排队与改变业务操作三种路线，并明确哪个改变用户时效。

验证与产物

绘制结论—证据对应表，把官方契约、固定源码、实测和推演分别标识。对三条最关键承诺各准备一个反例输入；如果无法给出反证条件，结论可能只是口号。本仓库 docs/content-depth-standard.md 要求来源、失败与验收闭环；引用它只能说明编辑约定，不能证明任意业务方案正确。面试陈述先给结论再解释机制与局限，不需要背一段长定义。

论证卡片与追问链：一条结论要经得起三跳追问

本页把"用了 MQ 所以可靠"拆成完整命题，评审时还需要一张可填写的卡片，让每条结论都能被追问到输入。卡片六格：命题、前提、机制、证据、反证、复查；缺任何一格，结论就是待验证假设而不是论证。

示例卡片：命题"Outbox + relay + 去重可恢复漏发意图"；前提"本地事务原子提交业务状态与 Outbox"；机制"relay 重试、消费者按 event_id 去重、扫描器兜底"；证据"模型加单元测试（尚无真实 broker 部署）"；反证"relay 停止超过保留窗口且扫描器未覆盖"；复查"保留期或 relay 间隔变化时重查"。六格齐了，才能说清楚这个结论覆盖了什么、不覆盖什么。

追问链固定在三个位置：问前提（"数据库提交成功但响应丢失会怎样"）、问机制（"去重表在恢复时丢失会怎样"）、问反证（"哪个观测能推翻这条结论"）。每一问都应能指向正文里的具体段落或实验；答不上来，就说明卡片是背出来的。

反例：把"证据"格写成"业界普遍这么做"。这不是证据，是偏好；评审应要求给出模型、源码、实验或运行数据之一，并标注覆盖域。另一个反例是把复查格写成"定期检查"——没有触发条件，复查不会发生。

执行 python3 labs/review_models.py argument_card：预期输出六格齐全的卡片、missing=[]，以及三跳追问链。脚本只检查结构，不评价论证质量。

两个合理选择：A 只给结论与一句理由，快速但无法追问；B 每条关键结论一张卡片，重但可评审。本例选 B，并只对"会被用来做不可逆决策"的结论强制卡片，其余结论允许一句话加链接。

架构师变化条件

把"更强一致"落成具体约束后重算：串行裁决点转移使热点账户占比成为推荐的反证输入，原 11 单位的均匀推导作废。若峰值改为 800 写/秒（低于单分片能力），分片论证整体不成立，候选集合回到"是否需要分片"之前。每次变化重写命题的适用条件与反证阈值。

闭卷验收

本页 8 道闭卷题收进了下方自测面板：先回忆，再展开参考答案与评分点，最后给三档自评。