本文是「AI 工程时代三部曲」第二篇。第一篇我们聊了 Agent 框架设计比模型选型更重要；这一篇，我们聊聊框架设计中最容易被忽视的一环：可观测性。

那 7 个运行了 5 年的幽灵任务

2024 年某天，Buffer 的工程师们做了一件"常规"的事：把散落在多个仓库的微服务代码合并回一个单体仓库。

迁移完成后，开始例行审计。本来只是检查重复代码、清理废弃依赖——那种每个团队都做过的日常维护。

然后他们发现了一个奇怪的 cron job。

每天凌晨 3 点执行。没人知道它是干什么的。任务列表里写着一个谁也没见过的名字。

工程师查了 git blame。最后一次修改——5 年前。提交者——一个早已离职的同事。提交信息——「add birthday email reminder」。

生日邮件提醒？这个功能不是两年前就下线了吗？

功能下线了。但任务还在跑。每天凌晨 3 点，准时执行一个早已没有意义的操作，消耗着计算资源，从来没有人知道。

这不是个例。工程师们继续翻，翻出了 7 个类似的"幽灵任务"——都是多年前某个功能的残留，功能早没了，任务还在。

这 7 个任务不是谁的失误。它们是架构制造的盲区。

不是工程师不负责。是看不见。

这不是多仓库的专利。即使是单体仓库，不同团队负责不同模块，你知道隔壁组跑了哪些定时任务吗？

代码级债务 vs 系统级债务

你可能会说，很多技术债就是代码问题啊。命名混乱、重复代码、没有测试——这些不就是技术债吗？

没错。这些是技术债。但这只是技术债的一部分。

你的技术债不只是代码问题——还有一整片你看不见的盲区。但我们先从你熟悉的部分说起。

我把它叫做代码级债务。特点是：你知道它在，你只是没时间修。

还有另一类债务，更难缠。我称之为系统级债务。特点是：你根本不知道它存在。

区别在哪？

代码级债务就像待办清单上的任务。你知道有这件事，只是排不上优先级。哪天有空了，划掉就是。

系统级债务是另一回事。它是那些你都不知道应该写在清单上的任务。不是你懒，是你压根不知道还有这件事。

Buffer 的那 7 个废弃任务就是系统级债务。不是有人故意留着不清理。是没人知道它们还在运行。

代码级债务可以用工具扫描。Linting、静态分析、代码审查——工具能告诉你哪里写得不好。

系统级债务呢？工具扫不出来。它根本不在你的扫描范围内。

可怕的不是清单上的任务。是那些你都不知道存在的任务。

AI 时代的新型债务：验证债务

系统级债务不是新鲜事。但 AI 时代给它加了一个新品种。

Sonar（一家代码质量工具厂商）2026 年的开发者调研有一组数据：96% 的开发者不信任 AI 生成代码的功能准确性。

96%。几乎所有人都不信任。

但同一份调研还有另一个数字：只有 48% 的开发者会在提交代码前验证 AI 生成的内容。

不信任，但不验证。

换句话说，超过一半的代码，在没有被充分验证的情况下进入了生产环境。我给这种现象起了个名字：验证债务。

验证债务是系统级债务的 AI 时代变种——你知道代码存在（代码级），但你不知道它对不对（系统级）。它进入了生产环境，成为系统的一部分。

这不是代码质量问题——AI 写的代码可能语法完美、逻辑清晰。问题是你不知道它在特定场景下会不会出错。你签了合同但没读条款。哪天出事了，你才发现里面埋着一颗雷。

传统的系统级债务是"任务在跑但你看不见"。验证债务是"代码在跑但你不确定它对不对"。

本质一样：看不见的债务，是还不掉的债务。

你上周用 AI 写的代码，认真测过吗？

可观测性不等于加监控

回到 Buffer 的故事。7 个废弃任务为什么能跑 5 年没人管？

不是因为没有监控。Buffer 有日志，有告警，有 dashboard。那些 cron job 每天凌晨 3 点执行，大概率还在某个 log 里留下过痕迹。

但这不是监控能解决的问题。

这里有一个容易混淆的概念。说到"可观测性"，大多数工程师第一反应是 metrics、logs、traces——SRE 那套。发现异常、定位故障、追踪调用链。本文说的不是这个。

本文说的是一种更基础的东西：结构性可见度。你有没有一份清单，知道所有正在运行的东西？

监控回答的是"这个东西是否正常运行"。结构性可见度回答的是"有哪些东西在运行"。你没法监控一个你不知道存在的东西。

每个团队有自己的储物间，各自整理得井井有条，日志齐全，告警也设了。但没有人有"整栋楼所有储物间"的清单。角落里堆着什么，不是检测不到异常，而是压根没人知道那个角落归谁管、里面有什么。

单体仓库的价值就在这里——把所有储物间打通变成一个大仓库。东西还是那些东西，但现在你一眼能看到全貌，那些藏了 5 年的东西终于浮出水面。

这就是结构性可见度的价值。不是帮你"检测"问题，是给你"看见"的能力。看得见，才能上清单。上了清单，才会被清理。

清理代码是还利息，清理盲区才是还本金

到这里，技术债的图景清晰了。

代码级债务是你能看见的债务。命名混乱、重复代码、缺少测试——这些是利息。工具能扫，重构能修。还起来虽然费时间，但至少你知道要还什么。

系统级债务是你看不见的债务。废弃的任务、断连的服务、未验证的 AI 代码、过期的证书、废弃的环境变量、失效的告警规则——这些是本金。不是不想还，是不知道欠着。

清理代码是还利息。清理盲区才是还本金。

你可能觉得这是大公司才有的问题。其实不是。打开你的终端，花 5 分钟试试。

如果你用 Linux/macOS，crontab -l 列出当前用户的所有定时任务。你知道里面每一条都还在干什么吗？

如果你用 Docker，docker ps -a --filter "status=exited" 看看有多少已停止但未清理的容器。有些可能是几个月前调试时创建的，早就没用了，但它们的卷和网络配置还占着资源。

如果你管理 Kubernetes 集群，kubectl get cronjobs --all-namespaces 列出所有 CronJob，然后对照业务需求清单——有多少你认不出来？

如果你管 CI/CD 流水线，看看有多少 pipeline 配置指向已经不存在的分支或仓库。GitLab 和 GitHub Actions 不会自动清理这些。

大概率你会发现至少一两个"这玩意还在？“的东西。这就是本金。它就安静地待在你的开发环境里，等着哪天被人翻出来，或者永远不会被翻出来。

你的技术债清单里，有多少是这样的"未知债务”？

系列衔接：从可观测性到工程师机遇

Buffer 最后怎么样了？

那 7 个废弃任务被清理了。但更重要的不是清理本身——是他们通过这次迁移获得了一个东西：系统视角。

过去，每个团队只看自己的仓库。现在，终于能看到全貌。这个视角的转变，比清理那 7 个任务更有价值。

在 AI 工程时代，这种视角转变正在成为工程师的核心能力。

上一篇我们聊了 Agent 框架设计比模型选型更重要。这一篇的结论是：可观测性是框架设计的核心要求。

下一篇，我们来聊聊 Go 工程师在 AI 时代的机遇。剧透一下：AI 正在抹平"会写代码"的门槛，但系统设计、并发安全、性能优化——恰好是 Go 工程师最擅长，也是 AI 最难替代的能力。

技术债不只是代码写得差。看不见的债务比写得差的代码更难还。清理代码是还利息，清理盲区才是还本金——而大多数团队的债务清单上，只有利息。