生成式 AI 显著压低了编写代码的时间成本，但它没有替团队承担代码合并后的责任。测试、评审、部署、监控、安全更新、故障处理和最终下线仍然需要工程师完成。因此，评估一个需求是否“便宜”，不能只看完成首个版本需要几小时，还要计算它会在未来几年里制造多少持续工作。
实现成本下降，不等于总成本下降
过去，团队拒绝一个边缘需求，常见理由是“开发要两周”。当 AI 能快速生成接口、页面、测试框架甚至部署配置后，这个理由的说服力正在减弱。问题随之转移：代码生成出来以后，谁来验证它，谁来维护它，出现事故时谁负责？
可以把一次变更的总成本粗略拆成：
总成本 = 实现 + 评审 + 验证 + 发布 + 运行 + 维护 + 退出
AI 主要压缩的是“实现”部分，也可能辅助评审和测试，但其余项目不会自动消失。例如，一个只需半天生成的第三方集成，仍可能带来这些长期负担：
- 上游 API 改版时需要迁移；
- 访问令牌需要轮换，权限需要审计；
- 新增依赖要持续修补漏洞；
- 客户开始使用后，兼容性就变成产品承诺；
- 服务异常时，值班工程师必须判断故障来自本方还是供应商；
- 停用功能时，还要迁移数据并通知用户。
这解释了一个容易被忽略的现象：代码越容易生成，仓库越可能快速扩张，而团队的评审和维护能力并不会同步增长。瓶颈会从“写不出来”转向“无法可靠地拥有”。
用三个问题判断一个改动是否真的便宜
1. 它会扩大多少行为表面积
代码行数不能准确表示风险。新增一个纯函数和新增一个公开 API，即使实现规模相同，后者也更昂贵。公开 API 会形成调用方依赖，还涉及鉴权、速率限制、兼容性和文档。
评审需求时，可以检查它是否新增：
- 对外接口或持久化数据；
- 第三方服务、运行时或基础设施依赖；
- 权限、安全边界或敏感数据流；
- 需要告警和人工响应的失败模式；
- 必须长期兼容的配置与用户行为。
这些项目越多，未来变更的自由度越低。
2. 失败时需要谁介入
真正便宜的功能应当容易观测、容易回滚，并且失败影响有限。如果一个 AI 生成的小功能需要全天候值班支持，它就不是小改动。
团队应在合并前回答：
- 哪个指标能证明功能正常？
- 错误会自动降级，还是直接影响主流程？
- 能否通过配置或功能开关停用？
- 谁拥有告警、运行手册和事故处理责任？
- 回滚会不会破坏已经写入的数据？
如果这些问题没有负责人，团队实际上只是把实现成本换成了未来的应急成本。
3. 删除它有多困难
容易删除的实验，通常比永久写入核心模型的实验便宜。边界清楚、没有不可逆数据迁移、能够独立关闭的功能，可以在价值不足时快速退出。
因此，AI 时代值得优先接受的改动往往具备这些特征：作用域受限、接口私有、依赖少、可观测、可回滚，并且预先定义了删除条件。
可以这样实践：给需求增加“所有权预算”
下面是一个可直接运行的 Python 小工具。它不是来源中规定的标准，而是一种可改造的团队实践：通过几个可讨论的维度，为候选改动计算所有权分数。分数不是审批机器，它的作用是暴露那些被“实现只需一天”掩盖的长期责任。
将以下内容保存为 ownership_score.py，然后运行 python ownership_score.py。根据团队实际情况修改 change 中的数值；每项取值范围为 0 到 5。
from dataclasses import dataclass
@dataclass(frozen=True)
class Change:
name: str
public_api: int
persistent_data: int
external_dependency: int
operational_burden: int
security_impact: int
removal_difficulty: int
implementation_days: float
def validate(self) -> None:
dimensions = {
"public_api": self.public_api,
"persistent_data": self.persistent_data,
"external_dependency": self.external_dependency,
"operational_burden": self.operational_burden,
"security_impact": self.security_impact,
"removal_difficulty": self.removal_difficulty,
}
for key, value in dimensions.items():
if not 0 <= value <= 5:
raise ValueError(f"{key} must be between 0 and 5")
def ownership_score(self) -> int:
self.validate()
weights = {
"public_api": 3,
"persistent_data": 3,
"external_dependency": 2,
"operational_burden": 4,
"security_impact": 4,
"removal_difficulty": 3,
}
return sum(getattr(self, key) * weight for key, weight in weights.items())
def recommendation(self) -> str:
score = self.ownership_score()
if score < 25:
return "低所有权成本：可以进入常规评审"
if score < 50:
return "中等所有权成本：先明确负责人、监控与回滚方案"
return "高所有权成本：需要架构和运营评审，或进一步缩小范围"
change = Change(
name="新增第三方工单同步",
public_api=2,
persistent_data=3,
external_dependency=5,
operational_burden=4,
security_impact=3,
removal_difficulty=4,
implementation_days=1.0,
)
print(f"变更：{change.name}")
print(f"预计实现时间：{change.implementation_days} 天")
print(f"所有权分数：{change.ownership_score()}")
print(f"建议：{change.recommendation()}")
这个例子会刻意呈现一种常见反差：实现时间可能只有一天，但第三方依赖、运行负担和退出难度会把所有权分数推高。权重不应被当作通用事实；更合理的做法是根据事故记录和维护数据，每个季度调整一次。
对于进入开发的改动，还可以把责任写入仓库。以下 YAML 同样是假设性的实践格式，可以由 CI 校验必填字段：
change:
name: ticket-sync
owner: team-integrations
expires_on: 2026-09-30
success_metric: successful_sync_rate >= 99.5%
rollback:
feature_flag: integrations.ticket_sync.enabled
data_reversible: true
operations:
dashboard: ticket-sync-overview
alert_owner: team-integrations
runbook: docs/runbooks/ticket-sync.md
removal_trigger: fewer than 20 active accounts after 90 days
expires_on 不一定意味着自动删除功能，它要求团队在指定日期重新确认价值。removal_trigger 则把“以后再看”改成可以执行的退出条件。
把 AI 节省的时间投入验证和退出设计
AI 带来的效率不应只用于接受更多需求。更稳妥的分配方式，是把省下来的实现时间投入测试、可观测性、故障演练、文档和简化设计。
合并前可以使用一份简短检查表：
- 是否指定了长期负责人，而不只是实现者？
- 是否记录了新增接口、数据、依赖和权限？
- 是否有成功指标、错误指标和告警接收方？
- 是否能在不重新部署的情况下关闭功能？
- 是否验证过回滚和数据恢复路径？
- 是否定义了复审日期或删除条件？
- 如果代码量在 AI 帮助下扩大十倍，现有评审是否仍然可信？
“答应”一个需求的门槛确实变了，但它没有简单地降低。团队现在可以更快获得代码，也必须更准确地区分一次性实现成本与长期所有权成本。真正便宜的改动，不只是今天容易写，更是明天容易理解、运行、修改和删除。