云、微服务和生成式 AI 经常被包装成一次全新的技术断代，但许多架构争论并没有消失，只是换了基础设施、成本结构和术语。Holly Cummins 对“太阳底下无新事”的讨论，提供了一种更实用的观察方式：不要只问某项技术是否先进，而要检查它依赖哪些假设、重新引入了哪些历史权衡，以及组织正在用什么形式偿还代价。
新名字背后仍是旧权衡
技术理念会循环出现，是因为软件工程长期面对的核心矛盾相当稳定：集中还是分散，复用还是自治，一致性还是可用性，开发速度还是运行复杂度。
微服务把部署和团队边界拆开，却需要付出网络调用、可观测性、数据一致性和发布协调的成本。云服务降低了资源获取门槛，同时引入供应商边界、持续费用和治理问题。AI 编程工具提高了代码生成速度，却可能让验证、理解和维护成为新的瓶颈。
这并不意味着新技术没有价值。真正需要警惕的是，把过去成立于特定条件下的结论当成永恒规律。例如，低利率和充裕资本时期，团队可能更愿意用基础设施成本换增长速度；资金成本改变后，同样的架构就可能暴露出闲置容量、服务碎片化和人员负担。
评估一项“新”方案时，可以连续追问四个问题：
- 它解决的是新问题，还是用新工具处理旧问题？
- 它把复杂度消除了，还是转移给了平台团队、值班人员或未来维护者？
- 哪些经济、组织和流量假设必须成立，它才比现有方案更划算？
- 当这些假设失效时，系统能否低成本退出？
债务不只存在于代码里
技术债务容易被识别：重复代码、过时依赖、脆弱测试和难以修改的接口都能进入待办列表。但工程决策还会积累另外几类债务。
财务债务表现为长期云账单、最低消费承诺、许可证费用，以及为了支撑复杂架构而持续扩大的平台投入。单次资源价格很低，不等于系统的总拥有成本低。
认知债务，也可以理解为 epistemic debt，来自团队“正在使用某项技术，却说不清为什么”。决策背景丢失、指标没有基线、架构假设未经验证，都会让后续团队只能依赖传闻继续建设。
睡眠债务则把代价落到人身上。过多服务、噪声告警和缺少自动恢复能力，会通过夜间值班和长期疲劳补贴系统。这样的系统即使账面可用，也不能称为可持续。
这些债务会相互转换。为了赶进度跳过验证，会形成认知债务；不清楚系统边界，又会制造技术债务；技术债务增加故障和人工操作，最终变成睡眠债务。工程领导者需要观察整个链条，而不只是代码扫描报告。
可以这样实践：维护一份“假设账本”
下面是一个可复制运行的最小示例。它不是演讲中提供的正式工具，而是一种可改造的实践：用 JSON 记录架构决策依赖的假设，再用 Python 找出高风险、长期未验证的条目。
创建 assumptions.json：
[
{
"name": "拆分订单服务能提升团队交付速度",
"owner": "commerce-platform",
"impact": 5,
"uncertainty": 4,
"days_since_review": 120,
"exit_plan": false
},
{
"name": "AI 生成代码能减少需求交付周期",
"owner": "developer-experience",
"impact": 4,
"uncertainty": 3,
"days_since_review": 25,
"exit_plan": true
},
{
"name": "当前云承诺消费在未来一年仍可用满",
"owner": "finops",
"impact": 5,
"uncertainty": 5,
"days_since_review": 75,
"exit_plan": false
}
]
再创建 review_assumptions.py：
#!/usr/bin/env python3
import json
from pathlib import Path
items = json.loads(Path("assumptions.json").read_text(encoding="utf-8"))
for item in items:
age_factor = min(item["days_since_review"] / 30, 4)
exit_penalty = 0 if item["exit_plan"] else 3
item["risk_score"] = round(
item["impact"] * item["uncertainty"] + age_factor + exit_penalty,
1,
)
items.sort(key=lambda item: item["risk_score"], reverse=True)
print("score\towner\tassumption")
for item in items:
marker = "REVIEW" if item["risk_score"] >= 20 else "watch"
print(
f'{item["risk_score"]:>5}\t{item["owner"]}\t'
f'{marker}: {item["name"]}'
)
运行时只需要 Python 3：
python3 review_assumptions.py
分数不是精确的风险模型，它的作用是迫使团队显式写下影响、置信度、复查时间和退出方案。实际项目中还可以增加可验证指标，例如部署前置时间、跨服务故障率、每笔交易的云成本、AI 生成代码的返工率，以及非工作时间告警次数。
把架构评审改成假设评审
传统架构评审经常围绕组件图展开，但组件本身很少是问题的根源。更有效的评审可以把讨论集中到以下内容：
- 基线：采用方案前，当前成本、交付速度和可靠性分别是多少？
- 触发条件：流量、团队规模或监管要求达到什么水平后，复杂方案才有收益？
- 反证指标：出现什么数据，就说明原决策已经失效？
- 退出成本：能否回到模块化单体、更换供应商或停止使用 AI 工具？
- 人员负担：方案会增加多少值班、告警、认知切换和专门技能要求？
例如，团队计划拆分服务时，不应只记录“为了可扩展性”。更可执行的描述是：“当单体部署每周造成超过两次团队阻塞，且订单模块需要独立扩缩容时，才启动拆分；六个月后按交付前置时间、故障率和基础设施成本复查。”这样的决策能够被验证，也允许被撤销。
采用建议：恢复纪律，而不是拒绝变化
面对下一轮云、微服务或 AI 热潮，组织没有必要退回旧技术，也不应因为历史上出现过类似思想就否定创新。更稳健的做法，是恢复那些经过长期验证的工程纪律：小步实验、容量测量、成本归属、自动化测试、清晰边界、可观测性和可逆决策。
落地时可以使用一份简短清单：
- 写下新方案成立所需的经济、组织和技术假设。
- 为每个关键假设指定负责人、指标和复查日期。
- 同时计算云费用、维护工时和非工作时间告警。
- 在扩大采用范围前，用真实负载验证收益。
- 保留退出路径，避免把试验迅速变成不可逆的平台承诺。
- 当假设变化时允许架构变化，不把撤销旧决策视为失败。
技术理念会循环，但团队不必重复支付同一笔学费。保存决策背景、持续验证假设，并把人的可持续工作状态纳入系统指标，才能在潮流变化时保留真正有价值的工程能力。