Vibe Coding 技术债排序：用风险、频率与修复窗口替代直觉

让 AI “扫描仓库并列出技术债”，几分钟就能得到几十项：函数太长、命名不统一、依赖陈旧、测试少、目录层级深。清单看似全面，却没有说明哪一项正在伤害用户、拖慢高频改动或放大事故。Vibe Coding 降低了改代码的成本，也降低了发起无必要重写的心理门槛；维护队列若按模型最容易解释的坏味道排序，会持续挤压真正有价值的工作。

技术债候选应是一个可验证的决策对象，而不是一句审美评价。先借助编程 Agent 的仓库地图定位模块入口、消费者和 owner，再记录触发证据：近期缺陷、值班手工步骤、构建耗时、修改冲突、交付等待、支持请求或安全例外。Google SRE 关于 simplicity 和 toil 的章节强调简单系统与减少重复、人工、可自动化工作的价值；它们提供判断方向，不替具体项目给出万能分数。

用候选卡片代替坏味道清单

每张债务卡至少包含：问题陈述、受影响任务、证据时间窗、代码范围、调用者、变化频率、失败后果、现有缓解、未知项、候选动作、预估验证成本和 owner。把“支付模块耦合严重”改写为“过去六次税率改动有四次同时修改三个适配器，其中两次漏改重试分类；目标是让税率规则只有一个批准入口”。后者能被证伪，也能判断完成。

影响面不能只靠目录大小。使用仓库依赖图驱动改动规划查直接与间接消费者，再补运行入口、配置、脚本和人工流程。若图谱不新鲜或动态调用未知，明确降低置信度；不要让 AI 把“没搜索到”写成“没有影响”。尚未证实的价值和范围进入Vibe Coding 假设与未知账本。

候选动作不一定是重构。它可以是补观测、加测试、写运行手册、限制新用法、删除废弃路径、替换一段手工操作，或接受当前成本。通用 AI 重构方法已有AI 辅助代码重构覆盖；债务排序首先决定“是否值得动、现在是否具备条件”，而不是预先认定重写就是答案。

按四个维度做相对排序

第一是风险与用户影响：权限、金额、数据丢失和频繁故障通常比格式不一致更紧迫。第二是摩擦频率：每周阻塞发布的十分钟手工步骤，可能比一年触发一次的复杂模块更值得先处理。第三是杠杆：该动作是否解锁已批准产品工作、减少多支队伍的重复成本，或只让一处代码更漂亮。第四是准备度：行为合同、测试、owner、迁移窗口和回退路径是否已经存在。

不要把四项机械相乘得出伪精确分数。先按证据分为 urgent-control-gap、high-leverage-ready、needs-discovery、local-hygiene 和 accept，再在同组比较。高风险但准备度低的项目先安排有上限的 discovery，目标是补齐未知和安全路径，而不是立即授权大改。低风险且顺路可修的卫生项可以进入相邻任务，但必须限制范围，避免“顺手整理”吞掉交付。

排序还要考虑修复窗口。某模块下月会退役，就不值得做全面抽象；某协议变更即将到来，当前最优动作可能是加隔离层而不是清理内部命名。记录下一次重新评估日期和触发器，例如事故、调用量变化、框架支持期或产品里程碑。长期没有新证据的卡片自动降级或关闭，不能靠“也许以后有用”永久占位。

用小额验证校准价值

在承诺大项目之前，安排一个不会改变外部行为的小实验：补一条特征测试、测量一次构建阶段、统计调用点、演练删除一个叶子路径，或记录一周人工操作。实验有时间和文件范围上限，输出新增证据，而不是偷偷开始完整重构。若实验推翻原假设，关闭或改写卡片；负面结果同样节省维护预算。

进入实施前，卡片必须给出完成信号和停止条件。完成信号可能是目标改动只需触碰一个规则入口、重复值守步骤被自动门禁替代、已知调用者迁移完成。停止条件包括行为基线不清、影响闭包扩大、关键测试无法稳定、需要未批准的数据迁移或收益证据失效。所有补丁仍走编程 Agent 的改动验证门，不能因为标签是“技术债”就降低用户行为要求。

最后由维护队列统一比较债务与功能、事故和安全工作，而不是单独维护一个永远排不到头的“重构 backlog”。排序记录保留证据日期、决策人和未选原因，使下一次评审能看到事实变化。技术债管理的产物不是最长的清单，而是较少、边界清楚且真有修复窗口的任务，以及一批有理由暂不处理的候选。

延伸阅读

• 编程 Agent 的仓库地图
• 仓库依赖图驱动改动规划
• Vibe Coding 假设与未知账本
• AI 辅助代码重构
• 编程 Agent 的改动验证门