1
软件可维护性讨论
维护主体、标准与量化指标
核心观点：维护主体应该按模块的风险等级分层，且这个分配应该随着"信任证据"的积累而动态调整，不是一次性设计。
维护主体分层策略（ToB 场景）
TIER 0
高风险核心 — 计费/合规/权限/数据隐私/跨租户隔离
维护：人主导，AI辅助生成 | 介入：强制人工签署 + 形式化约束
维护：人主导，AI辅助生成 | 介入：强制人工签署 + 形式化约束
TIER 1
业务逻辑 — 核心业务流程、客户定制逻辑
维护：AI自主生成，人抽样审计 | 介入：异步审查、失败率触发人工介入
维护：AI自主生成，人抽样审计 | 介入：异步审查、失败率触发人工介入
TIER 2
胶水代码 — CRUD、UI、集成适配层
维护：AI完全自主 | 介入：仅依赖测试门禁，无需人工review
维护：AI完全自主 | 介入：仅依赖测试门禁，无需人工review
关键提醒：这个分层不是静态的。一个模块能否从 Tier 1 降到 Tier 2，应该由量化指标驱动，而不是拍脑袋决定。这本质上是在用证据逐步扩大对 AI 的信任半径。
双重可维护性标准
人和 AI 阅读/修改代码的失败模式完全不同，需要同时满足两套标准：
人类维护者
核心约束：认知负荷
• 失败模式：读不懂、记不住、注意力有限
• 优化手段：命名规范、函数拆分、注释"为什么"、架构分层
AI 维护者
核心约束：上下文完整性
• 失败模式：看不到全局、隐性约定丢失、幻觉假设
• 优化手段：强类型/Schema、高覆盖测试、检索基础设施、可读ADR
量化指标体系 — A. AI 生成质量
指标
AI首过成功率 (AI-FPSR)
AI生成的变更中，未经人工修改直接通过CI+Review的比例。趋势比绝对值重要，持续下降说明代码库积累了AI难以理解的隐性复杂度。
指标
验证/生成时间比 (VGR)
人工验证一次AI变更的时间 ÷ AI生成该变更的时间。比值持续升高说明验证已成为新瓶颈，测试基础设施没跟上生成速度。
指标
重复逻辑密度
用语义相似度聚类（非简单文本diff）检测近似重复实现比例。这是AI-native开发中被低估的新型技术债：AI比人更容易无感知地重复造轮子。
量化指标体系 — B. 系统健壮性
| 指标 | 定义 | 意义 |
|---|---|---|
| 爆炸半径指数 | 一次变更实际影响的模块数 ÷ 预期影响范围 | 长期偏高说明模块边界设计不良，直接倒逼强边界契约式架构成为刚需 |
| 规格-代码漂移分数 | 用从Spec直接生成的属性测试跑现有代码，统计失败率 | 衡量"代码实际行为"与"最初声明意图"之间的累积漂移 |
| 回归复发率 | 修复过的bug类型再次出现的比例 | 衡量"教训"是否真正反哺进了Spec/测试集，而不只存在于某次对话上下文 |
量化指标体系 — C. 人工兜底能力（ToB 关键）
| 指标 | 定义 | 意义 |
|---|---|---|
| 冷启动 MTTR | AI工具不可用时，人工独立定位并修复生产事故的时间 | 可维护性的真正下限测试。若人丧失独立排障能力，系统稳定性单点绑定在AI服务可用性上 |
| 新人上手时间 | 无项目上下文的工程师独立做出一次安全变更所需时间 | 验证代码本身（非AI辅助）的可理解性下限 |
| 合规可审计覆盖率 | 关键模块中，人工可读文档+签署记录覆盖比例 | ToB刚性约束，不随AI能力提升而放松 |
ToB 特别风险："再生成债务"（Regeneration Debt）
ToB应用生命周期极长（5-10年），当前生成代码的模型/prompt几年后可能退役。届时能否用新模型基于旧Spec可靠地重新生成/理解旧代码，是一个全新且被低估的风险。
ToB应用生命周期极长（5-10年），当前生成代码的模型/prompt几年后可能退役。届时能否用新模型基于旧Spec可靠地重新生成/理解旧代码，是一个全新且被低估的风险。