用智能体化解技术债的实用指南

为什么会积累债务

大多数工程团队都会背负一份计划逐步偿还的技术债务 backlog。它往往会不断增长，而不是缩小，因为偿还这些债务会与功能开发争夺同样的工程时间，而功能通常优先级更高。

在 @cognition，我们看到团队在不占用工程师时间的情况下，使用 @DevinAI 将债务工作与 roadmap 并行推进。本文接下来的内容会介绍这在实践中是什么样子，以及如何把这些 workflows 用到你自己的 backlog 上。

当优先级超过产能时，债务项几乎总是最先被砍掉的，因为处理每一项都意味着一名工程师必须停下手头更紧急的工作。

像 linters、SonarQube 和 Dependabot 这样的工具降低了识别债务的成本，但修复工作仍然要落到人工身上。工程师本来就只有不到 20% 的时间在写代码，这使得可用于处理债务的时间池既很小又很紧张。

Cloud Agents 如何增加产能

Cloud agent 会在现有资源池之外，为团队的总产能增加额外供给。它在自己的隔离环境中按自己的 schedule 运行，可由 API call 或 webhook、Linear 或 Jira ticket、cron job，或者 Slack message 触发。它可以在夜间运行、在多个 sessions 中并行运行，或者按 recurring schedule 运行，而不需要任何人在每次运行时手动发起。

有四项能力对债务工作最重要

Autonomy 让 agent 能在自己的 cloud environment 中独立运行，而不需要任何人守在键盘前。团队启动 sessions 后，就可以等回来查看已经完成的 PRs，无论当时是否有人在线。

Parallelism 让团队可以同时运行很多 agent sessions。

Scheduling 让债务工作按照自己的节奏运行，无论是 daily triage、weekly maintenance，还是与特定事件相关的一次性 cleanup。

Long horizons 让 agent 可以在同一个项目上跨越几十个 sessions 工作，保持 state，并根据每个 session 暴露出的内容进行调整。那些需要连贯 multi-week effort 的 modernization work 之所以变得可行，是因为 agent 不会在中途被拉去做别的工作。

模式

下面这些模式描述了团队现在通过 cloud agents 执行的债务工作。

运行大规模迁移

给 agent 一条 prompt，要求它评估 surface area，提出无冲突的 work packages，并为每个 package 启动一个 parallel session，同时遵循一份共享 playbook 以保持输出一致。PRs 会在接下来的几天里陆续合并。适用于 JavaScript 到 TypeScript、REST 到 GraphQL、MongoDB 到 Postgres，或者 Angular 16 到 18 之类的迁移。

保持依赖项最新

设置一个每周运行的 scheduled session，每周一执行。patch 和 minor bump 会被批量合并到一个 PR 中，并附上 test results。每一个 major-version bump 都会单独打开一个 PR，包含来自 changelog 的 breaking-change notes，以及已经应用好的必要兼容性修改。工程师只需要介入那些需要判断的情况。

按计划移除 feature flags

在某个 flag 发布的当天，安排一个 30 天后执行的一次性 session。当日期到来时，session 会追踪该 flag 的每一次使用，保留 enabled path，删除 disabled path，更新 tests，并打开一个 PR，附上被移除内容的摘要。

批量补全 test coverage

提示 agent 找出 coverage 最低的模块，并为每个模块派发一个 parallel session，每个 session 持续编写 tests，直到该模块的 line-coverage 超过 80%。八个 sessions 连夜运行，可以在一个周期内把 codebase 的覆盖率从 44% 提升到 68%。

每日 triage 生产错误

设置一个与 Sentry 集成的 daily scheduled session。它会拉取最严重的未解决错误，获取 stack traces 和 breadcrumbs，在 repo 中定位相关文件，识别 root cause，并为每个问题打开一个有针对性的修复 PR，同时附带 regression test。那些原本很难达到 sprint ticket 门槛的 long-tail errors，也会在同一轮中被处理。

捕捉 design system drift

运行一个 daily scheduled session，扫描已合并的 PRs，标记硬编码的 hex values、缺失的 spacing tokens，以及那些重复 shared library 的一次性 components，并针对每一项打开 auto-fix PR。

拆分单体文件

通过 Slack、IDE 或 agent 的 web UI 发起一个 ad-hoc session，并附上描述目标结构的 prompt。一个 2,000 行的 Express router 会被拆分成按 domain 划分的 route files，shared middleware 会被提取到自己的 module 中，原有 URL paths 保持不变，现有 test suite 会验证这次 refactor。整个工作会在周末以一个 PR 的形式落地。

让 docs 与 code 保持同步

运行一个 daily scheduled session，将昨天合并的 PRs 与 docs repo 做 diff，并针对重命名的 endpoints、已弃用的 options，以及现在行为与过去不同的 features 打开修正 PRs。

自动调查 bug reports

给 Linear、Jira 或 GitHub issue 添加一个 label，以触发一个 agent session，尝试在浏览器中复现该问题，附加 screen recording 和 steps-to-reproduce，并把复现结果回复到 ticket 上。

预防

这些模式既能清除现有 debt，也能防止新的 debt 形成。Agent 参与的 PR review 会把这件事前移。Bug、标准违规以及缺失的 tests 会在 PR 本身中被发现并修复。

一旦这些 cadence 建立起来，债务维护就会作为一项常规流程运行，而不是周期性的清理工作。

经济性

那些以前从未跨过优先级门槛的工作，现在可以被处理了，因为它们不再与工程师时间竞争；而决定要处理什么，也变成了一个 scoping 问题：哪种 debt 的成功标准足够明确，可以交给 agent，哪种仍然需要人工关注。

试试看

大多数团队会从每周的依赖更新或每日的 Sentry triage 开始。这两种方式都能快速落地并建立信任。在 devin.ai 试试 Devin。

• 原文链接： x.com/dabit3/status/2047...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～