“AI写的代码不是缺分号就是逻辑对不上，最多帮我补全个函数签名。”

这话是我一个在大厂做了六年后端的朋友说的，时间是2025年中。

上个月我又跟他聊，他沉默了一会儿说：“我现在写代码的时间，可能还没Review AI写的多。”

这个转变不夸张。过去一年，AI编程工具从“代码补全”跳到了“自主干活”的阶段。我拿几个公开数据和真实工具跑了一遍，今天不聊趋势，聊具体的东西——AI到底在GitHub上干了哪些Senior该干的活，怎么干的，你该怎么用。

先看几个硬数据
SemiAnalysis的报告显示，Anthropic的Claude Code已经贡献了GitHub上4%的公开提交量，预计到2026年底这个数字会达到20%。不是补全，是提交。

日本电商巨头Rakuten用Claude Code对一个1250万行代码的开源项目做了复杂功能实现，AI连续自主编码7小时，代码精度99.9%。注意“自主”两个字——不是人写一步它跟一步，是给了任务它自己跑。

高级工程师的平均SWE-bench通过率大约30%，而Devin 2.0在部分评测中达到了86.4%。当然这个数字有争议，Devin在另一些独立测试中面对20个真实GitHub Issue只成功修复了3个，失败率70%。但同一时期，Cognition公司内部披露89%的代码提交由Devin完成，高盛、Nubank等企业已经规模化部署。

这些数字单独看都有水分，放在一起看就说明一件事：AI在特定类型的工程任务上，已经超过了大部分工程师。

它具体在干什么：修Issue、写PR、做重构
场景一：GitHub Issue自动修复

我在一个中等规模的开源项目里配了claude-queue（一个基于Claude Code的CLI工具），逻辑很简单：

npx claude-queue --repo my-org/my-project
它自动拉取仓库里所有标记为bug的open issue，逐个分析、生成修复方案、写代码、跑测试，最后开PR。

我故意挑了几个有代表性的issue测试：

一个数组越界的边界问题（涉及3个文件的调用链）
一个并发场景下的状态不一致（需要理解业务状态机）
一个配置项默认值错误（跨模块依赖）
第一个和第三个都一次修复通过。第二个它改对了方向但漏了一个竞态条件，人工补了两行。

关键不是成功率，是工作模式的改变。 以前我要花时间读issue、定位代码、想修复方案，现在我要做的是：确认它改得对不对。

场景二：Claude Code GitHub Actions——在PR里@一下就完事

Claude Code官方提供了GitHub Actions集成，配好之后在issue或PR评论里打一句@claude，它就自己跑起来分析代码、改东西、开PR。

配置步骤：

第一步，在Claude Code终端里执行：

/install-github-app
这个命令会在你的仓库上安装Claude GitHub App，交互式引导你完成授权。

第二步，去GitHub仓库的Settings → Secrets and variables → Actions，新建一个repository secret，命名为ANTHROPIC_API_KEY，把Claude的API Key粘贴进去。

第三步，在项目里建一个workflow文件：

.github/workflows/claude.yml

name:ClaudeAutoFix
on:
issue_comment:
types:[created]

jobs:
claude-fix:
if:contains(github.event.comment.body,'@claude')
runs-on:ubuntu-latest
steps:
-uses:anthropics/claude-code-action@v1
with:
anthropic_api_key:${ {secrets.ANTHROPIC_API_KEY}}
github_token:${ {secrets.GITHUB_TOKEN}}
配好之后，团队里任何人发现bug，在issue里写清楚复现步骤，打上@claude，AI就会自动分析代码、提交修复PR。你不需要打开IDE，不需要本地复现，PR会自己出现在你面前。

有人可能会问：万一它改错了怎么办？它开的PR走的是正常审查流程，你可以review、request changes、或者直接关掉。你的工作从“修bug”变成了“审bug修复”。

场景三：跨仓库重构

这是2026年最有意思的变化。GitHub Copilot Workspace在2026年正式支持了多仓库同时操作，AI能跨仓库重构、分析依赖链、传播变更。

我实测了一个场景：一个API的响应字段从user_id改成userId。手动做的话，要改服务端、改三个消费方的客户端代码、改文档、更新集成测试，至少半天。

Copilot Workspace的做法是：你描述变更需求，它先生成依赖图，然后一次性提交所有关联仓库的修改PR。三个仓库、7个文件、2个测试文件，一次PR全部覆盖。

Cursor Composer也支持类似能力，可以链式调用25次工具调用（读文件、搜索、编辑、执行命令），用于大型重构和架构迁移。

场景四：CI失败自动修复

这个是运维测试同学最能感受到价值的。

传统流程：CI挂了 → 收到邮件 → 拉日志 → 本地复现 → 修复 → 推送 → 重新跑。一套下来半小时。

Codex介入GitHub Actions之后，CI失败会触发自动分析：判断是代码问题还是环境问题，如果是简单的类型错误、缺少依赖、断言过时，它直接提交修复PR。

有个叫github-sre-agent的项目做得更彻底，用GitHub Copilot SDK做了一个自主SRE agent，监控workflow失败、分析根因、执行补救措施。本质上就是把on-call工程师的职责自动化了。

但别被宣传骗了：这些活它干不了
我试过拿Devin 2.0处理一个微服务间的分布式事务问题，结果它改了三个文件、加了两个重试机制，但根本没理解事务补偿的逻辑，最后PR被全量回滚。独立测试也证实了这个问题——Devin面对20个真实开源项目的GitHub Issue，只成功修复了3个。

当前AI agent的真实能力边界：

能干的： 单文件bug修复、类型错误、依赖更新、测试用例补充、简单的CRUD接口实现、代码格式化和lint修复、跨文件的字段重命名。

干不了的： 涉及分布式一致性的改动、需要理解业务领域知识的状态机、性能优化（需要benchmark和profiling）、安全敏感逻辑（权限、加密）、以及任何“改错了后果严重”的代码。

有个数据很说明问题：Devin在标准无辅助模式下SWE-bench得分45.8%，排名第7。它前面的Claude Code、Cursor Composer、Copilot Workspace各有所长。没有哪个工具全面碾压，选型要看场景。

对测试同学意味着什么
上面聊的都是开发场景，但测试流程里的变化同样明显。

以前测试工程师要手动写用例、跑回归、整理报告。现在的工具链已经能做到：需求文档进去 → 自动提取功能点和边界条件 → 生成接口测试和UI用例 → 执行 → 出报告。

跟AI修Issue的逻辑一样，你的角色从“执行者”变成了“监督者”和“决策者” 。你不需要逐条写用例，但你需要判断AI生成的用例覆盖够不够、优先级对不对、断言是不是在验证真正的业务逻辑。

这个转变对测试工程师来说其实是好事。写用例、修脚本这些重复劳动被接走了，省下来的时间花在理解业务、设计场景、分析风险上——这才是测试真正的价值所在。

给想动手的人几条实操建议
第一，从Issue自动修复开始试。 配好claude-queue或者Claude Code GitHub Actions，挑几个低风险bug让AI修，观察它的准确率和修复质量。别一上来就跑全量。

第二，CI自动修复先限制范围。 只让AI处理lint错误、类型错误、依赖版本冲突这类确定性高的失败。涉及业务逻辑的失败还是人工处理。

第三，跨仓库重构先跑依赖分析。 Copilot Workspace的Plan Mode会先生成依赖图，确认依赖关系没有遗漏再执行变更。

第四，API Key和Token消耗要有监控。 自主agent跑起来Token消耗不低，尤其是长任务。设好预算上限和告警。

第五，PR审查不能省。 不管AI多自信，它开的PR你都得看。Devin的89%提交率不代表89%不需要review，只是review的工作量比从头写小得多。

第六，先跑通一条链路再铺开。 挑一个模块、一类任务，验证生成质量和执行效果，确认没问题再推广到其他模块。跟任何自动化一样，先证明它值得信任。

最后说两句实在的
“AI替代Senior”这个说法不准确。准确的说法是：AI替代了Senior工作中那些不需要真正思考的部分。

写样板代码、修简单bug、更新依赖、格式化代码、补测试用例——这些活Senior干了十年，不是因为只有Senior能干，是因为以前没有更好的工具。

现在有了。

对工程师来说，这不是威胁，是解放。把80%的重复劳动交给AI，剩下20%的架构决策、技术选型、复杂问题攻关，才是真正体现价值的地方。

对测试同学来说同理。写用例、跑回归这些活被接走之后，你终于有时间去做真正重要的判断了。