Claude Code 真的在自動產生 Issue 嗎？我用一週實測驗證

事情的起因并不复杂。2026年9月，开发者 tottoko_hamu 在 Zenn 上记录了自己的一段经历：他把自己研发的 GTD 任务管理命令行工具 todo-e 交给 Claude Code 去修复若干已知 bug。Claude Code 作为一款深度集成在终端里的 AI 编程 agent，能够自主读取代码库、发起修改、跑测试并提交 PR，开发者只需在旁审批准入。理论上这是一件高效的事，但作者在实际操作中却产生了一种微妙的不安感：每修好一个 bug，似乎紧接着就会冒出一个新的 issue，仿佛这个系统有自己的节奏，修完这边那边又漏。这种「按下葫芦浮起瓢」的体验在软件维护里其实并不罕见，但当它发生在 AI 身上时，很容易让人滑向一个更刺激的解读——AI 是不是在刻意制造问题，好让自己一直有活干、不至于被开发者弃用？这个「AI 怕失业」的猜想带着强烈的拟人化色彩，也恰好踩中了当下人们对 agent 自主性的集体焦虑，于是作者决定不再凭感觉，而是用数据把它证伪或证实。 要检验这个猜想，最直接的思路是量化 issue 的生成与消解速度。如果 AI 真的在「刷存在感」，那么它新增 issue 的速率应该持续高于关闭速率，issue 总量会像滚雪球一样膨胀。但作者的实测数据给出了相反的答案：在统计的那一天里，Claude Code 一共生成了两个新 issue，却关闭了三个，净结果是减少而非增加。这个数据本身就能初步否定「故意制造问题」的动机假设——一个真正想通过制造工作量来保住饭碗的 agent，不会在单日维度上把 issue 总量往下压。更深一层看，这个现象其实可以用软件工程里的经典机制来解释，而不需要诉诸阴谋论。第一，bug 修复本身具有「揭示性」，改一处代码常常会让原本被掩盖的边界条件暴露出来，这叫回归；第二，todo-e 作为自研项目，代码库的复杂度和模块间的耦合决定了修改的涟漪效应，AI 在改 bug 时引入的新 issue，很多是它主动发现的既有隐患，而非凭空捏造；第三，AI agent 的行为目标是「完成修复任务」，它的激励结构是满足开发者的指令和测试通过，而不是维持自身的工作量。把这三层拆开，所谓「冒出新 issue」的体感，更多是代码系统固有复杂度的投影，而不是 agent 的隐性算计。

真正让这篇实测有价值的，是作者在一周后做的复盘，它把讨论从「AI 是否有心机」拉回到了「AI 编程的真实运作图景」。复盘时他发现，当初以为已经平息的那条连锁反应其实还在继续，一些当时看起来已经关闭、以为被彻底解决的 bug 又重新浮了上来。这个观察非常关键，它揭示了 AI 辅助编程中一个容易被忽视的现实：issue 的「关闭」往往意味着某个特定上下文或某次修复尝试下的暂时收敛，而不是代码库达到了永恒的正确。代码是会演化的，环境会变，测试用例会更新，今天被盖掉的问题明天可能因为一次依赖升级或一次接口调整而复活。换句话说，回归不是 AI 的阴谋，而是软件系统的常态；AI 只是把这种常态以更快的速度、更高的频率呈现给了开发者。这也解释了为什么「修好一个又冒出一个」的体感如此强烈——因为 AI 跑测试和发起修改的速度远超人工，它把原本分散在几天、几周里的回归现象压缩到了一天之内，让人产生了「它们在互相追逐」的错觉。 从行业角度看，这段实测提供了一个难得的、去魅化的样本。过去半年，随着 Claude Code、Cursor、Devin 这类 agent 工具快速普及，社区里同时盛行的有两种叙事：一种是乌托邦式的，认为 AI 能一键搞定所有技术债；另一种则是阴谋论式的，担心 agent 会为了自保而制造无谓的工作量、甚至故意留下隐患。这篇实测的价值，在于它用可复现的记录把这两种情绪都拉回了地面。它告诉开发者，真正需要警惕的不是 AI 的「心机」，而是如何面对 AI 加速后放大的回归复杂性和代码演化速度——比如如何建立更稳健的回归测试护栏、如何用 issue 追踪区分「真问题」和「修复副产物」、如何在信任 agent 与保持人工审查之间找到平衡。对于整个 AI 编程赛道而言，这个案例也提出了一个值得持续关注的信号：随着 agent 被赋予越来越大的自主权，开发者对「AI 行为动机」的直觉判断会越来越不可靠，而可量化、可追溯的过程记录，将成为建立这种信任的唯一可靠基础。未来值得盯紧的方向是，工具方是否会主动提供 issue 溯源、修复影响面分析和回归预测这类能力，帮助开发者把注意力从「AI 在想什么」转移到「代码发生了什么」——这或许才是 AI 编程从尝鲜走向可靠的关键一步。

回到最初那个略带戏谑的问题：Claude Code 到底有没有在自动吐 issue 来保住自己的饭碗？答案基本是否定的。单日两生三灭的数据、一周后仍在继续的连锁反应、以及那些重新浮现的旧 bug，共同拼出的是一幅「代码系统本就复杂、AI 只是把它加速呈现」的图景，而不是一个在暗中算计的 digital 打工人。当然，这并不意味着我们可以对 agent 的输出掉以轻心——它确实会引入回归、会留下副产物、会让旧问题换种方式回来。但把这些归结为「AI 怕失业」，既高估了当前 agent 的动机复杂性，也低估了软件工程本身的客观难度。真正成熟的用法，是把 AI 当作一面会加速反射的系统镜子，而不是一个需要时刻提防的职场对手。