去年年初有人找我帮忙看一个项目。说是“看”其实就是“你帮我们看看这玩意儿还能不能救”。这项目是用 AI 助手写的——不是“AI 辅助”是“AI 全程代笔”。团队挺自豪说程序员负责提需求AI 负责写代码效率拉满。然后我打开了代码库。果然很满。几千行代码全都能编译。全都能通过测试。但有一半左右的函数你根本无法在代码里找到任何调用它们的痕迹。举个例子一个叫processLegacyOrder的函数定义得整整齐齐文档也写了参数也传了返回值也设计了——然后它这辈子都没被叫过。还有个normalizeInputV2后面又出现了V3和V4三个同时存在各自独立演化互不干扰。说实话看到这种情况的第一反应不是“这帮人怎么会写出这种代码”而是“我很清楚这是怎么发生的”AI 助手写了一个函数用了一次然后 refactor 把调用删了。但函数还在因为 AI 不会回头去删“自己写的但不再需要的东西”。它没有“记忆”它只管生成不管清理。编译器不会告诉你什么代码在“装死”Go 的编译器不是侦探是检查员。它能告诉你类型对不对、语法通不通但它不关心某个函数有没有被调用。你写一百个没人调的函数它照样给你编译成功。go vet不会眨眼go build不会抱怨测试会全绿。代码“正确”地躺在那里只是毫无意义。这就是 AI 编程时代的一个“脏秘密”AI 写出了函数然后忘记了。你合并了这些函数然后也忘记了。最后代码库里的“僵尸代码”比活代码还多。一个救了我的工具deadcode在花了一个周末徒手分析哪些函数还活着之后我发现了 Go 团队自己写的一个工具名字很直白就叫deadcode。它干的事很简单从你的程序入口点出发构建整个调用图然后告诉你“这个函数没有任何代码能到达它。”比如你写了这样一段代码packagemainimport(fmtstrings)functoUpper(sstring)string{returnstrings.ToUpper(s)}funcgreet(namestring)string{returnfmt.Sprintf(hello, %s,name)}funcmain(){fmt.Println(greet(world))}toUpper没被调用但它能编译。你猜编译器会不会提醒你不会。运行deadcodego run golang.org/x/tools/cmd/deadcodelatest ./...它直接告诉你main.go:7:6: unreachable: function toUpper is unreachable就这一行。完事。为什么现在这比以前重要得多我后来总结了一下AI 生成的代码里死代码的比例明显更高。不是因为它写得差而是因为它没有长期记忆。一个 AI 生成函数的时候它不知道五分钟前自己已经生成过一个类似的函数也不知道那个函数后来被删掉了。换句话说AI 每次会话都是“第一次见面”。而代码库偏偏是个需要长期记忆的东西。这个问题最麻烦的地方不是技术是认知——你不确定代码库里有 50 个还是 500 个“没用的函数”。你不敢删因为“也许某个地方用到了”。你也不敢留因为它们在消耗你的注意力。那应该怎么办别自己写一个 deadcode 分析器。我干过这件事花了一个周末写 AST 遍历器然后发现go/types跨包分析有多复杂。最后用官方工具一分钟解决。官方工具已经写了直接用。在 CI 里加一步go run golang.org/x/tools/cmd/deadcodelatest ./...。如果发现有死代码让 CI 失败。这样 AI 生成的死代码就不会悄无声息地进主分支。Code Review 的时候多问一句“这个函数谁在用”如果没人用删掉。AI 不会自己清理自己留下的垃圾——但你作为代码的最终负责人有这个能力。说到底AI 写死代码不是 bug是特性——它本来就没有记忆。但你作为最终 push 代码的人有。既然你有就别让它继续装死了。