复杂度阶梯与演进时机
§1摘要与结论
在简单与复杂方案之间选择与进阶时机：复杂方案的建设、延迟与一致性成本更高，应先跑通最简单可工作的方案，待出现明确且当前的跨域或规模需求时再逐步演进，而非为预想的未来提前复杂化。
别名：0813 维度8 图谱时机、复杂度阶梯、简单与复杂、何时上高级方案、YAGNI | 英文：Complexity Ladder and Evolution Timing | 类型：方法 / decision-framework
§2局部关系图
§3原理 · 为什么
方案的复杂度不是能力标签，而是需要持续偿付的成本：分布式、异步、多副本等复杂方案在获得扩展性、隔离性等属性的同时，带来通信、一致性、调试、部署与运维的额外负担，且这些负担随系统运行长期存在。因此架构选择应遵循复杂度阶梯——从单体或模块化单体起步，当出现明确的、当前存在的需求（如多团队独立部署、跨地域规模、强隔离）时才升级到微服务、事件驱动或分布式方案。提前上复杂方案的风险在于：预想的需求可能永不发生，而复杂度却是即时且确定的；即便需求发生，早期对问题性质的理解往往不足，仓促定下的复杂结构反而限制后续演进。「能用简单方案解决就不上复杂方案」不是保守，而是把复杂度预算留到真正需要时支取。阶梯的存在并不否定预判，而是要求预判以「为演进留出空间」而非「提前实现复杂结构」的方式表达，例如先划清模块边界、后按需拆分。因此判断的重点不是「哪种架构更强」，而是「当前问题处在阶梯的哪一级、下一级的先决条件是否已经具备」。把阶梯显式化并写下每一级的进入与退出条件，能让团队在讨论架构时比较级别而非比较偏好，也使升级或维持简单的决定都可被复核。
§4机制 · 如何运作
复杂度阶梯的运作逻辑是「先问问题性质，再决定结构」。分析问题时先判断它属于单跳还是多跳、是局部还是全局、数据是静态还是高动态、一致性要求强弱、变更与团队边界如何，再据此选择匹配的方案，而非从候选架构清单中挑最强大的。每一级复杂度都应绑定其成立的先决条件：微服务需要成熟的 DevOps 与自动化实践，事件驱动需要消费者对异步与最终一致的承受力，多副本需要能真正隔离故障域。进阶应由可观测的触发条件驱动，如团队数量增长导致协调成本上升、单体的部署耦合成为瓶颈、负载或规模超出单机能力。先让最简单方案在真实环境中运行并暴露约束，再沿阶梯逐级演进，每一步都保留回退路径，使复杂度增长与真实需求同步。触发条件应尽量客观可观测，如协调成本、部署耦合或规模指标，避免用「感觉变复杂了」这类主观信号驱动重大结构调整。
§5工程 · 怎么落地
实践中先以最小可行结构交付，明确它当前满足与不满足的场景，并记录可预见的升级触发条件。当触发条件出现时，评估升级带来的属性收益与新增复杂度，选择阶梯上的下一级而非一次跳到最顶端。为每次升级设定目标属性、验收场景与回退方案；优先采用演进式手段（如模块化边界先行、绞杀者逐步替换），避免一次性重写。用可观测指标追踪系统的真实瓶颈与协调成本，让进阶决策基于证据而非猜测。保留架构决策记录，说明当前为何停留在某一级、升级的前提是什么。周期性复核这些前提是否仍成立，若预想需求未出现则维持简单方案，若已出现则及时演进，使结构复杂度始终与真实需求对齐，而非被预想的未来绑架。每次升级后复盘触发条件是否确如预期，把偏差反哺到下一次判断，使阶梯经验可积累而非每次凭直觉。
§6权衡卡
其一是把「简单优先」绝对化，长期停留在无法承载真实增长的方案上，等到问题爆发才仓促重写，代价远高于适时演进；其二是低估简单方案的隐性极限，误以为可以无限扩展。
还有一点常被忽略：简单方案也需要为演化保留最低限度的结构秩序，否则一旦需要升级，缺乏边界的代码会令演进成本骤增。
- 复杂度阶梯也有两种误用。
- 因此应以可观测触发条件与真实需求为准绳，在该简单时抵御诱惑、在该演进时果断投入，并把前提与触发条件显式记录，使阶梯判断可复核、可调整。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7冲突 / 对比表
| 对照维度 | 复杂度阶梯与演进时机 | 技术选型的够用原则 |
|---|---|---|
| 定位 / 依据层 | 复杂度阶梯与演进时机 · Complexity Ladder and Evolution Timing | 技术选型的够用原则 · Least Sufficient Technology Selection |
| 核心定义（原文） | 在简单与复杂方案之间选择与进阶时机：复杂方案的建设、延迟与一致性成本更高，应先跑通最简单可工作的方案，待出现明确且当前的跨域或规模需求时再逐步演进，而非为预想的未来提前复杂化。 | 技术选型方法处理的是在标准、框架、架构风格与外部构件之间做选择的问题：按适用域与约束匹配需求，挑出刚好覆盖质量属性场景的方案，因为任何额外能力都伴随新的复杂度。 |
| 首条机制断言（原文） | 方案的复杂度不是能力标签，而是需要持续偿付的成本：分布式、异步、多副本等复杂方案在获得扩展性、隔离性等属性的同时，带来通信、一致性、调试、部署与运维的额外负担，且这些负担随系统运行长期存在。 | 任何技术、框架或风格都不是零代价的：它在带来期望属性的同时，必然把新的依赖关系、通信路径、一致性负担与运维复杂度一并引入。 |
| 对照关系 | 静态选型与动态进阶是同一成本观的两面（对照） | 同一条 对照 边的另一端 |
| 典型反例（原文） | 反例之一是过早复杂化：为想象中的规模与团队预置微服务或分布式结构，结果复杂度的代价已经支付，收益却未兑现（YAGNI 的反面）；反例之二是无止境地推迟升级，把「以后再说」当成原则，积累的技术债在关键时刻集中爆发。此外，升级本身可能引入新的失败模式而不是简单加和。 | 「够用」并非可以一劳永逸的静态结论，它有两个反面风险：把简化推到极致，可能连必要能力一并舍弃；而以简洁为由拒用成熟方案，则容易重复造轮子。 |
| 处置要点（原文） | 实践中先以最小可行结构交付，明确它当前满足与不满足的场景，并记录可预见的升级触发条件。 | 工程上，选型的第一步是划出可行域：架构驱动中的约束会直接删掉一部分候选，例如组织规定所用库与框架必须持合规许可，则许可不符者即便功能再合适也只能出局。 |
§8案例带
去中心化聊天架构逆向
对一个仅有 58 份设计文档、尚未实现的开源去中心化聊天项目做架构逆向：从设计文本提炼 18 个模块及其依赖关系，重建模块依赖 DAG 与三条核心数据流 DAG，并输出全景理解与深度需求分析。
网申填写扩展逆向架构
对 Chrome MV3 网申自动填写扩展的逆向架构分析：梳理 popup、content、background、options 四模块职责，解剖 12 个站点适配器、双通道消息协议与隐私脱敏机制，并评估其零依赖零构建选型。
网申 v2 深度重构
一次由「改一处漏多处」症状触发的深度重构：定位到接口定义散落 12 个文件、存在 7 种接口形态的根因后，以单一契约源、dispatch 消息表与能力注册中心重建三层契约系统，恢复可审计与可校验性。
dsh-manager 插件深度分析
以「编译依赖、运行时注入、组合装配」三硬依据加源码行号，对第三方插件做依赖、功能、需求溯源与设计问题裁决，并复用上游 DAG 知识库节点标识，使分析结果可与主图互查。
dsh 插件依赖增量定位
以官方插件 DAG 为蓝本，对一个官方清单之外的全新社区插件做功能定位与依赖位置增量分析，产出可下钻交互依赖图与多形态文档的源码级架构逆向案例。
MCP 四件套选型对比
对四个同类 MCP 服务器做源码级能力与成本对比，并以常驻 token 预算为轴给出分级接入策略的技术选型实战案例。
Claude Code 架构逆向
以社区逆向源码、系统提示词与官方文档三源交叉验证，还原一个商业 Agent 的查询引擎、子Agent、工具与权限体系的逆向分析案例。
控制理论⊗Agent 设计
将控制理论五维（负反馈 / 状态估计 / PID / 鲁棒 / 分层）系统映射到 Agent 工程环节，并以真实产品案例验证的跨学科方法论案例。
AI Agent 架构 DAG 复盘
对四个工作日内独立完成三个异构对象 DAG 分析的方法论复盘，总结「采集→建模→生成→门控→交付」可复用管线与关键教训。
§9信源与核验
核验结论：复杂方案的建设、延迟与一致性成本确定且长期存在，而预想需求未必发生；应先跑通最简单可工作方案，待出现明确且当前的需求再沿复杂度阶梯演进 [WEB-023]
§10原始关系清单
展开：本节点的全部原始关系边（4 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 对照 | ← MTH-O-03 | 技术选型的够用原则 E-704 | 静态选型与动态进阶是同一成本观的两面 |
| 依赖关联 | → MTH-O-09 | 理解成本优先的简单原则 E-696 | 复杂度阶梯的选择依赖理解成本原则 |
| 依据推导 | → ESS-O-01 | 本质复杂度与偶然复杂度 E-690 | 复杂度阶梯以降低认知复杂度为目标 |
| 细化 | → MTH-O-03 | 技术选型的够用原则 E-695 | 复杂度阶梯是选型够用原则的时序细化 |