衡量AI的意外后果
内容提要
本文讨论如何衡量AI对软件开发的隐性成本：AI虽提升速度，却可能损害可维护性、加剧倦怠与供应商锁定，造成实际经济影响。核心指标是“变更成本”，可通过增值工作占比、DORA指标和token用量观察，并建议结合可维护性、代码行数和锁定等模型做情景规划。同时需警惕指标被操纵，应评估方法而非考核个人。
延伸解读
为什么可维护性有经济影响
文章指出，AI虽能提升开发速度，但可能带来可维护性下降、倦怠和供应商锁定等隐性成本。这些并非软性问题：代码难维护会导致功能开发更慢、缺陷修复更久；人员倦怠会降低投入并引发离职，带走组织知识；锁定则使企业在AI token成本上涨时陷入两难。因此，衡量这些意外后果具有实际经济意义。
变更成本：一个统摄性指标
文章提出“变更成本”作为捕捉多数意外后果的核心概念。它像对软件变更征收的税：成本低时，复杂变更虽耗时但可完成；成本高时，简单变更也需数周，复杂变更遥不可及。变更成本不易直接测量，但可通过增值工作占比、DORA指标和token用量等指标间接观察，辅助判断。
增值工作占比：最受信任的指标
增值工作占比衡量开发精力中用于新功能等增值活动的比例，其余为muda（如修bug、事故处理）。文章作者作为工程VP时将其作为关键指标，三年内使增值占比翻倍，从而在不增加人手的情况下腾出资源。该指标虽噪声大、趋势需3-6个月显现，但操作轻量，建议按月审视，下降时深入调查。
用模型和情景规划补充指标
由于变更成本指标噪声大且滞后，文章建议辅以模型和情景规划。可维护性模型将维护视为强制税，估算每月可用于增值的工程日；代码行数模型则用提交数据估算维护代码变动。例如，若AI提速50%，但token成本导致人员减少25%且维护成本翻倍，可能仅收支平衡。模型帮助探索可能性，而非预测未来。
Q&A
AI提升开发速度的同时，可能带来哪些隐性成本？
AI可能损害代码可维护性、加剧开发者倦怠、导致供应商锁定，这些都会造成实际经济影响，如功能开发变慢、bug修复时间增加、人员流失和成本上升。
什么是变更成本？为什么它是衡量AI影响的核心指标？
变更成本是对软件修改的“税收”。变更成本低时，复杂修改仍可完成；变更成本高时，简单修改也可能耗时数周。它能综合反映可维护性、倦怠、锁定等大多数意外后果。
如何通过增值工作占比来观察AI对开发的影响？
增值工作占比是花在增值工作（如新功能）上的努力百分比，非增值工作称为muda（如修bug、事故处理）。跟踪该指标可了解时间去向，建议每月审查，但趋势需3-6个月才显现。
有哪些模型可以用来情景规划AI的意外后果？
可维护性模型（将维护视为强制税）、代码行数模型（用代码变动量估算维护成本）、锁定模型（模拟token成本上升的影响）以及倦怠监测（通过调查和离职率）。
为什么增值工作占比指标容易被操纵？应该如何正确使用？
因为管理者可能为了考核而调整工作分类，甚至推迟维护。应使用该指标评估方法而非考核个人，并谨慎对待。
AI导致的开发者倦怠如何衡量？
可将心理疲劳纳入开发速度研究，定期进行单问题调查，关注实际离职率与历史对比，并在离职面谈中留意对AI的抱怨。
