把架构判断变成可验证假设
学习架构设计时，我最容易犯的错误不是不知道某个框架，而是过早把“听起来合理”当成“已经成立”。一个可靠的决定应该写清楚目标、约束、证据和失败条件。
例如，系统需要在模型调用失败时继续保存用户草稿。这里真正的不变量是 draft persistence 不依赖模型响应，而不是笼统地追求“高可用”。
def should_retry(status_code: int, attempt: int) -> bool:
retryable = status_code == 429 or status_code >= 500
return retryable and attempt < 3这段代码很短，但仍然需要回答三个问题：哪些错误可以重试、最多重试几次，以及重试会不会重复产生副作用。
架构图表达的是组件关系；验收条件表达的是系统在现实中是否成立。
验证一个 AI 功能时，我会先检查：
权威数据是否先于派生任务提交
模型超时后，草稿仍然存在
重试使用相同的幂等键
失败是否可以观察和恢复
成本是否有明确上限
| 验证对象 | 失败条件 | 可观察证据 |
|---|---|---|
| 草稿保存 | 模型超时导致草稿丢失 | 保存事务与模型调用相互独立 |
| AI 讲解 | 重试产生重复扣费 | 使用记录按幂等键唯一 |
type ArchitectureDecision = {
invariant: string;
evidence: string[];
failureCondition: string;
};补全函数，使它只重试可恢复的错误。
def should_retry(status_code: int, attempt: int) -> bool:
# 在这里补全条件
return False这篇笔记目前也是 Omnilio Phase 0A 的真实测试语料：正文、行内代码、两个代码块、引用、嵌套列表、表格和练习必须在导入、编辑、阅读与复制过程中保持语义一致。