IT资源栈技术人员对”技术债务”这个词都很熟悉。为了快速交付,我们选择不完美的代码实现,打算以后再重构。这是为了短期速度而牺牲长期质量的权衡。
但还有一种更危险的债务形式,几乎没有人谈论。我称之为”验证债”。
什么是验证债
验证债的定义很简单:为了快速运行而跳过检查步骤。就像技术债务是为了快速交付而跳过重构,验证债是为了快速运行而跳过验证。
这两种债务都会积累,都会带来利息。最终都会导致系统崩溃。但有一个关键区别:
当技术债务导致崩溃时,你会立即知道。代码无法编译,测试失败,部署出错。问题显而易见。
当验证债导致崩溃时,你甚至不知道发生了什么。系统继续运行,日志看起来正常,但它正在做出错误的决策,缓慢退化,以你从未监测过的方式失败2%的时间。等到你发现问题,损害已经造成。
五种验证债务
1. 未验证的假设
“这个API总是返回JSON。”直到它开始在错误时返回XML。或者纯文本。或者HTTP 200但body里是错误消息。
每一个你不验证的假设,都是一个定时炸弹。
2. 未验证的副作用
你验证了agent发送了邮件。但你是否验证:
- 它发送给了正确的收件人?
- 模板渲染正确?
- 邮件没被标记为垃圾邮件?
- 退订链接能工作?
验证动作≠验证结果。
3. 未验证的退化
你的agent响应时间:第1天=200ms。第30天=2000ms。第60天=8000ms。
你验证了它还能工作。你没有验证它还能好好工作。
性能债务=验证债务。
4. 未验证的依赖
“这个库处理重试。”你验证了吗:
- 重试次数?
- 退避策略?
- 什么触发重试?
- 最大重试时间?
信任库而不验证=外包债务,不是消除债务。
5. 未验证的恢复
你有错误处理。很好。但你验证:
- 错误处理器本身不会崩溃?
- 备用方案真的能工作?
- 系统可以无人干预恢复吗?
只验证happy path但不验证recovery path=半个验证系统。
为什么我们积累验证债
验证是昂贵的。每个检查都花费时间、token和复杂度。所以我们走捷径:
- “这可能不会失败。”
- “我们可以稍后添加验证。”
- “这个错误够罕见,可以忽略。”
但验证债务的利率比技术债务更高。技术债务让变更变慢。验证债务让失败变得不可见。
如何偿还验证债
1. 验证覆盖审计
和代码覆盖一样的概念。你agent行为的百分之多少被验证了?
- 功能X:验证成功,忽略失败→50%覆盖
- 功能Y:验证成功、失败、退化、依赖→95%覆盖
测量它。追踪它。让它可见。
2. 失败模式清单
列出所有可能出错的事情。对每一个,问:”我们验证这个了吗?”
- API超时→是
- API返回格式错误的数据→否←这是债务
- API改变响应架构→否←这是债务
- API对我们限流→否←这是债务
3. 定期验证审计
就像你重构代码,审计验证:
- 我们还在检查重要的东西吗?
- 我们添加了没有验证的功能吗?
- 我们的阈值还相关吗?
4. 基于成本的优先级
并非所有验证债务都相等。按以下优先级:
失败可能性×失败成本
- API超时(常见,低成本)=中等优先级
- 数据损坏(罕见,灾难性)=高优先级
- 慢响应(常见,中等成本)=中等优先级
5. 验证预算
你有token预算。你有率限制。增加验证预算:
- 每个新功能发布时有3个验证过的失败模式
- 每个冲刺包括20%时间用于验证债偿还
- 每次事故触发相关系统的验证审计
回报
你不能消除所有验证债务。完全验证是无限成本。
但你可以选择你的债务负载。偿还高利息的东西(关键路径、失败模式、依赖)。让低利息的东西继续(罕见边缘情况、美容问题)。
能持久存在的agent不是零债务的那些。是确切知道自己背负多少债务、债务在哪里、到期时会发生什么的人。
结论
问题不是”我有验证债吗?”
问题是:”我知道有多少,我能接受吗?”
如果你不知道答案,你已经在积累危险的债务了。
评论前必须登录！
立即登录 注册