Anthropic一天合并3万次，Claude Code仓库98%的issue无人认领

Anthropic 公开的 Claude Code GitHub 仓库里，有 16,060 个未关闭的 issue。其中 15,766 个没有指派给任何人，超过 98%。不少已经开了几个月，甚至几年。里面有安全漏洞，有隐私问题，也有普通功能缺陷。

一个还在发生的例子是 User-Agent 头。Claude Code 未经同意，把用户邮箱地址带给了第三方网站。同样的问题，几个月前的更早 issue 里就有人报过。那些报告今天仍然开放，也没有负责人。

对照另一组数字。Anthropic 自己的工程博客说，公司每天合并超过 30,000 次代码变更，这是上个月的数字。

一位自称高级开发者的发帖人把这两件事分得很清楚。他知道 30,000 次内部合并，不等于公开仓库里的 issue 被解决了。他的问题更窄。Claude 既然能在这个规模上写代码、审代码、合并代码，为什么不用它来分类 bug？为什么不用它给安全漏洞排优先级，把需要人处理的问题挑出来？为什么一个 issue 往往要在 Reddit 或 X 上传开，才会有人动手。

另一位用户注意到，Anthropic 有资源给 Windows 桌面应用加像素化的爱心——点屏幕多次就出现——却没余力清一清公开报告。

高票评论给了几种猜测。一种说法是，自动化处理公开 issue 会带来提示注入风险，所以要留人工审核环节；人一进来，速度就掉下去。另一种更彻底：Anthropic 可能根本不用 GitHub issue 做 bug 跟踪，内部另有系统，GitHub 只是对外的镜像。这在游戏开发里很常见。

有人讲了自己的经历。报了个问题，没有回复，没有指派，也没有评论，直到因为长期不活跃被关闭。看到关闭通知时他才发现，那个毛病已经有一阵子没再出现。他猜 Anthropic 在用代理在内部监控、分类、修复，只是不在 GitHub 上同步进度。

关于代码审查，一条评论说 Anthropic 已经表示不再做人工审查。另一条更激烈：所有人都在超时工作，成群代理在做没人说得清的事，没有工程纪律，没人愿意碰困难的架构或技术债。还有评论说，修安全漏洞拿不到五百万美元奖金，大家追的是万亿美元市场或者 AGI 名声。这些说法都没有被证实。它们指向的观感是一致的：工程规范排在了后面。

也有冷静的分析。一条评论指出，公开仓库处于对抗性环境，公开 issue 必须当作潜在攻击来评估——可能来自竞争对手，也可能是伪装成 bug 报告的注入。另一位评论者提到 2016 到 2017 年的区块大小战争。他自称当时处理过 Bitcoin Classic 的公开仓库破坏问题。按他的说法，要评估一处改动，得先把自己的安全模型完整写出来，再判断它是不是对模型的细微违反。这个成本很高。

还有一条判断更直白：安全不是优先事项，因为没有法规要求。除非影响底线，公司不会修。没有公司、也没有开发者会因为 GitHub issue 的数量，决定买不买 Anthropic 的服务。

30,000 这个数字本身也被质疑。评论说，如果它统计的是推送次数；如果公司对提交大小有严格内部规则，工程师一天推送几十次，这个数就没那么惊人。Meta 在 Facebook 上早就这么干了。还有人把那份工程博客称作营销话术。理由是：没有自研版本控制系统，用的只是所有繁忙仓库都会用的提交合并队列，加一道资格 CI。

也有评论从组织角度切入：没有产品经理，工程先行。同一条评论说，这种做法在任何大公司都没成功过。另一位评论者认为，发帖人问的是一个合理且有效的问题，Anthropic 应该直接回答。

一条短评论概括了最悲观的答案：你忘了，你不重要。另一条反问：何必在意人类提交的 bug，你可以让一千个 Claude 代理去测、去修。这套逻辑是不是 Anthropic 的实际做法，没有公开信息能确认。Anthropic 对公开 issue 有没有正式流程、有没有服务级别承诺，同样没有公开说明。30,000 次合并里有多少对应公开 issue 的修复，也没有数据。

超过 98% 的公开 issue 至今没有负责人。其中一个，是把用户邮箱地址泄露给第三方的那条。