1. 从AI只能写Hello World说起一个被误读太久的判断AI写代码不就是补全个函数、生成个Hello World吗这句话我在过去一年里至少听过几十遍来自同事、来自评论区、来自一些做了十几年开发的老朋友。每次听到我都想把他们按在屏幕前让他们看看我本地终端里正在发生的事情一个AI Agent正在读我的仓库结构、翻我的issue列表、定位一个跨了七个文件的类型错误、改完之后自己跑测试、测试挂了再自己回去改最后给我一份带diff的PR描述。这不是科幻这是2024到2025年之间真实发生的事。关键词里那几个词——Claude Code、Devin、Copilot Workspace、AI Agent——不是营销词汇它们代表的是AI在软件工程领域从补全工具到协作主体的身份跃迁。标题里那句它已经在GitHub上替代Senior了听起来很标题党但我理解它想表达的核心意思AI已经能承担一部分过去只有资深工程师才能承担的、需要跨文件理解和上下文推理的工作。我写这篇东西不是要吹AI多神也不是要贩卖焦虑。我想做的是把这件事拆开给你看AI到底在GitHub这个场景里做到了什么程度、它是怎么做到的、哪些环节是真的能替代、哪些环节还差得远、以及一个普通开发者现在应该怎么上手。适合的读者是写过一点代码、对AI编程工具有好奇、但还没真正把Agent用进日常工作流的人。如果你已经在用Copilot补全但没试过Agent模式这篇就是写给你的。先把一个概念理清楚不然后面全是糊涂账。市面上大家嘴里的AI编程其实混着三个层次的东西能力差距是数量级的第一层代码补全Completion。代表是早期的GitHub Copilot。你在编辑器里敲一半它猜你下一行。它只看当前文件和少量上下文本质是高级输入法。第二层对话式编程Chat-based。代表是各种IDE里的Chat面板。你把一段代码贴进去问这里为什么报错它给你解释和修改建议。它能理解你贴给它的东西但不会主动去翻你的仓库。第三层Agent式编程Agentic Coding。代表是Claude Code、Devin、Copilot Workspace。你给它一个任务它自己去读文件、搜代码、改代码、跑命令、看结果、再迭代。它是一个会自己找活干的执行者而不是等你喂料的应答机。标题里说的替代Senior指的只可能是第三层。而绝大多数人对AI编程的印象还停留在第一层这就是误读的根源。下面我按这个三层框架把每一层在GitHub场景里的真实表现讲透。2. Agent式编程到底在GitHub上干了哪些Senior的活2.1 跨文件重构这是分水岭判断一个AI工具是不是真Agent我有个很土但很准的标准给它一个需要改三个以上文件的任务看它会不会自己去找那些文件。补全工具在这一步直接出局因为它根本不知道其他文件存在。对话式工具勉强能行但你得手动把相关文件一个个贴给它贴漏一个它就改错。而Agent不一样你只要说把项目里所有用到旧版API的地方迁移到新版它会自己执行搜索、列出命中文件、逐个读取、理解每个调用点的上下文、然后动手改。我实测过一个真实场景一个中等规模的TypeScript项目把某个工具库从v2升到v3涉及大约14个文件、20多处调用。用Claude Code跑它先grep出所有import点然后按依赖顺序逐个处理遇到一个它不确定的边界情况会停下来问我。整个过程我大概只做了三次确认剩下的它自己跑完最后还给我列了一份哪些地方我改了、哪些地方我拿不准、建议你人工复核的清单。这个清单是重点。一个靠谱的Agent不会假装自己全对它会标注自己的置信度。这恰恰是资深工程师的工作习惯——知道自己哪里不确定主动暴露风险点。这一点上很多初级工程师反而不如它。2.2 读issue、定位bug、写修复闭环能力GitHub上最耗senior时间的活是什么不是写新功能是排查那些描述模糊的bug。issue里写着登录偶尔失败没有复现步骤没有堆栈。人要去翻日志、猜路径、加断点。Agent在这件事上的表现让我意外。你把issue链接或者内容丢给它它会先去代码里搜和登录相关的模块找到认证流程然后开始推理偶尔失败可能对应哪些条件分支——超时并发token过期边界它会列出几个假设然后逐个去代码里找证据。我见过它做的一件很senior的事它发现某个失败路径只在特定时区下触发因为代码里用了本地时间做比较。这个bug人眼扫十遍都不一定看出来因为它藏在两个文件的交互里。Agent能发现是因为它会把时间处理这个横切关注点在整个仓库里追一遍。但这里必须泼冷水它的推理不是每次都对的。我遇到过它信誓旦旦给出一个修复结果根因判断错了改的地方根本不是问题所在。所以Agent产出的修复必须经过测试验证不能直接merge。这一点后面第4节会专门讲。2.3 写测试、跑测试、根据失败再改自我迭代循环这是Agent和高级补全最本质的区别也是我认为它真正够得上senior的地方它能形成改-测-改的闭环。传统工具给你一段代码对不对你自己跑。Agent给你代码之后会自己跑测试。测试挂了它读报错回去改再跑。这个循环它能自己转好几轮。我观察过它的迭代过程有个细节很有意思它第一次改完跑测试挂了它没有盲目乱改而是先去看测试断言到底期望什么然后判断是我的实现错了还是这个测试本身过时了。能区分代码错和测试错这是有经验的工程师才有的判断力。新手往往一看到测试红就慌要么改代码迁就测试要么改测试迁就代码两边都不对。不过这个循环有个前提你的项目得有一套能跑起来的测试。如果项目没有测试Agent的自我验证能力直接废掉一半它只能靠读代码觉得对来判断可靠性大打折扣。所以想用好Agent先把测试基建补上这是绕不过去的。2.4 写PR描述、整理变更那些没人爱干的杂活还有一类活技术含量不高但特别占时间写PR描述、整理changelog、给改动分类。资深工程师往往被要求你的PR要写清楚但写清楚很烦。Agent在这件事上是降维打击。它知道自己改了哪些文件、每个改动是为了什么所以能生成结构清晰的PR描述变更摘要、影响范围、测试情况、需要reviewer重点看的地方。我现在的习惯是让它先写一版我再改省掉至少一半时间。把上面这些能力放一起看你会发现一个规律Agent擅长的是那些需要理解上下文、需要跨文件推理、需要重复迭代的活。而这些恰恰是过去区分初级和资深的标尺。所以标题说替代Senior虽然夸张但方向没错——它替代的不是senior这个人是senior工作里那些上下文搬运和重复推理的部分。3. 拆开看Claude Code、Devin、Copilot Workspace 各自的路子热词里这三个名字出现频率最高很多人分不清它们的区别。我用一句话概括它们解决的是同一个问题但产品形态和工作方式完全不同。选哪个取决于你的工作习惯。3.1 Claude Code住在终端里的AgentClaude Code的形态很特别——它不是一个IDE插件而是一个跑在终端里的命令行工具。你在项目目录下启动它它就能访问你当前目录的所有文件执行shell命令读写代码。这个形态的好处是它离你的真实开发环境最近。它用的git是你本地的git跑的测试是你本地的测试改的文件就是你正在编辑的文件。没有同步到云端这一步没有环境差异。对习惯了命令行的开发者来说这种它就在我旁边干活的感觉非常自然。它的工作方式是对话驱动。你给它任务它执行把结果和它的思考过程打给你看你随时可以打断、纠正、追加要求。这种交互模式适合我大概知道要干什么但细节需要边做边定的场景。安装上它主要通过npm分发装完之后在项目根目录初始化一下就能用。配置层面最关键的是权限控制——你要决定它能不能自动执行命令、能不能自动改文件还是每步都要你确认。我的建议是新手阶段全部设成需要确认等你摸清它的脾气再逐步放开。3.2 Devin把整个开发环境打包给AIDevin的路子和Claude Code完全相反。它不是住在你本地而是给你一个完整的、云端的工作环境——有自己的终端、编辑器、浏览器。你给它任务它在这个隔离环境里从头到尾把活干完最后给你结果。这种形态适合**任务边界清晰、可以完全外包的场景**。比如给这个开源项目修一个文档里的错别字、实现一个独立的小功能模块。你不需要盯着它它自己干完通知你。代价是它和你的本地环境是隔离的。它改的东西要同步回来中间有摩擦。而且因为环境是它自己的有些依赖你本地特有的配置它可能没有跑出来的结果和你的实际环境可能有差异。3.3 Copilot Workspace贴着GitHub工作流走Copilot Workspace的定位最官方——它深度绑定GitHub本身的工作流。你从一个issue出发它帮你规划怎么改、生成计划、然后执行最后直接产出PR。它的优势是和GitHub生态无缝。issue、PR、review这些环节它都懂适合团队协作场景。如果你的团队重度使用GitHub它的融入成本最低。劣势是它相对更重启动一个任务的前置步骤比Claude Code多灵活性也稍差。它更像是把GitHub的issue到PR这条流水线自动化而不是一个随叫随到的编程搭子。我把三者的差异整理成一张表方便你按自己的情况选维度Claude CodeDevinCopilot Workspace运行位置本地终端云端隔离环境GitHub云端交互方式对话驱动、可随时打断任务外包、异步执行从issue到PR的流程化环境一致性最高就是你本地中独立环境中云端环境适合场景边做边定的探索性任务边界清晰的独立任务团队协作、issue驱动上手门槛中要会用命令行低网页操作低网页操作权限控制细粒度、可逐步放开环境隔离、相对安全绑定GitHub权限选型上我的经验是个人开发者、喜欢掌控感、任务需要反复调整的选Claude Code任务能清晰描述、想彻底甩手的试Devin团队重度用GitHub、想打通issue到PR的看Copilot Workspace。没有绝对最优只有合不合适。4. 别被替代Senior忽悠Agent真正会翻车的地方前面讲了很多它能干的活现在必须讲它干不了的。不把边界讲清楚你迟早会被它坑。这一节是我踩过的坑换来的每一条都真实发生过。4.1 它会自信地犯错而且错得很像对的Agent最大的风险不是它说不会而是它非常自信地给你一个错误答案。因为它生成的东西语法正确、逻辑自洽、看起来专业你很容易放松警惕直接采纳。我遇到过一次它帮我改一个并发相关的逻辑改完代码读起来完全合理注释也写得头头是道。但它引入了一个微妙的竞态条件只有在高并发下才暴露。单测跑过了因为单测是串行的。这个bug如果上了生产排查成本极高。教训是Agent产出的代码尤其是涉及并发、状态、边界条件的必须用能覆盖这些场景的测试去验证不能靠读起来对就放过。它读起来对恰恰是它最危险的时候。4.2 它不懂你的业务约束和历史包袱代码里有很多看起来多余但不能删的东西某个兼容旧版本的判断、某个为了绕过特定环境问题的hack、某个业务上约定俗成的特殊处理。这些约束往往不在代码里在老员工的脑子里。Agent不知道这些。它看到一段多余的代码很可能顺手给你优化掉然后线上就出问题了。我现在的做法是在让它动手前把关键的业务约束和历史原因用文字告诉它或者干脆在仓库里维护一个CONTEXT.md之类的文件把为什么这段代码长这样写清楚让它读。4.3 上下文窗口不是无限的大仓库会失忆Agent再强它的上下文也是有上限的。在一个几十万行的大仓库里它不可能同时看到所有代码。它会靠搜索来定位相关文件但搜索是有可能漏的。我遇到过它改一个功能时只找到了直接相关的三个文件漏掉了一个间接依赖的配置文件结果改完跑不起来。大仓库里用Agent一定要给它明确的线索——告诉它这个功能还和XX模块有关或者让它先做一轮探索、列出它认为相关的文件、你确认之后再动手。4.4 它不会为架构决策负责Agent能写代码但它不会为这个功能该不该这么设计负责。你让它实现一个功能它会按你说的实现哪怕这个设计本身是错的。它不会跳出来说你这个需求会导致后面的扩展性问题。架构决策、技术选型、长期演进方向这些还是人的活。Agent是执行者不是决策者。把它当决策者用迟早出事。把这几条放一起结论很清楚Agent能替代的是执行层面的上下文推理和重复劳动替代不了判断层面的责任和决策。标题说替代Senior准确的说法应该是替代Senior工作里那些机械的部分让Senior能把时间花在真正需要判断的地方。5. 想上手先搞清楚你的项目配不配不是所有项目都适合马上上Agent。我见过有人兴冲冲装了工具结果项目本身一团糟Agent进去之后越改越乱。Agent的能力很大程度上被项目本身的质量放大了或限制了。5.1 有测试的项目Agent能力翻倍前面反复提到测试。这里展开说为什么。Agent的自我迭代循环依赖它能知道自己改对没有。测试就是它的眼睛。有测试它能自己跑、自己看、自己改没测试它只能靠读代码觉得对可靠性断崖式下跌。所以如果你打算认真用Agent第一件事不是装工具是补测试。哪怕先补上核心路径的测试收益也是立竿见影的。我自己的项目在引入Agent之前专门花了两周把关键模块的测试覆盖率提上去后面用Agent的效率提升非常明显。5.2 代码规范统一的项目Agent少犯错Agent会模仿你项目里已有的风格。如果你的项目风格统一——命名一致、目录结构清晰、有明确的lint规则——它产出的代码会很自然地融入。反过来如果项目里三种命名风格混着来它也会跟着乱。lint和格式化工具是Agent的好朋友。让它在改完之后自动跑一遍lint和format能挡掉大量低级问题。这个配置一次长期受益。5.3 有清晰文档和注释的项目Agent理解更准Agent理解代码一部分靠读代码本身一部分靠读注释和文档。注释写得清楚的地方它改对的概率明显更高。这不是玄学是因为注释里往往藏着这段代码为什么这么写的信息而这正是它最容易搞错的地方。我现在的习惯是在让Agent改一个模块之前先花十分钟把这个模块的关键注释补一补。这十分钟的投入能省掉后面反复纠正它的时间。5.4 一个自检清单在你决定上Agent之前用下面这几条快速自检项目有没有能一键跑起来的测试命令没有的话先补。代码风格统一吗有没有lint配置没有的话先加。关键模块有没有注释说明为什么没有的话先补。仓库大不大大的话准备好给Agent提供线索。有没有把业务约束写下来的地方没有的话建一个。这几条都过了再上Agent体验会顺畅很多。过不了先补基建别急着上工具。6. 我的实操工作流怎么把Agent用成靠谱的搭子讲了这么多原理和边界最后落到实操。我现在的日常开发里Agent已经是一个固定角色但它不是我甩手它全干而是我定方向、它干重活、我把关。下面是我实际在用的工作流你可以直接抄。6.1 任务拆解先让它探索再让它动手我从不一上来就让Agent改代码。第一步永远是让它先探索给它任务描述让它读相关代码然后让它告诉我它打算怎么改、涉及哪些文件、有什么不确定的地方。这一步的价值在于暴露它的理解偏差。如果它列出的文件不对、或者对任务的理解跑偏了我在这一步就能发现成本很低。等它真动手改了再发现跑偏返工成本就高了。探索完之后我会根据它的输出调整任务描述把它的不确定点用文字澄清然后才让它动手。6.2 权限设置从每步确认开始新手阶段我把Agent的权限设成每一步都要我确认——改文件要确认、跑命令要确认。这样我能实时看到它在干什么及时喊停。用熟了之后我会逐步放开一些低风险操作的权限比如读文件不用确认、跑测试不用确认但改文件和执行任意命令还是保持确认。权限放开的节奏取决于你对它行为的预判能力。你能预判它下一步大概会干什么就可以多放开一点。6.3 验证闭环测试是底线人工review是保险Agent改完代码我的验证分两层。第一层是自动化跑测试、跑lint、跑类型检查。这一层能挡掉大部分低级错误。第二层是人工review我自己看一遍diff重点看那些涉及业务逻辑、边界条件、并发状态的地方。这两层缺一不可。只靠自动化挡不住逻辑对但业务错的问题只靠人工效率太低且容易漏。两层叠加才稳。6.4 一个具体的例子上周我让Agent帮我实现一个用户操作日志的批量导出功能。流程是这样的我先描述需求让它探索相关代码它列出了日志模块、导出模块、权限模块三个相关位置。我确认它找对了补充了一条业务约束导出要受权限控制只有管理员能导全量。它动手实现中间问了我两次边界情况导出量上限、时间范围格式我给了答复。它写完自己跑了测试挂了一次它读报错改了一版过了。我看diff发现它把权限检查放在了导出逻辑之后我让它挪到前面先检查再执行避免无权限也跑了导出。它改完我再跑一遍测试通过合并。整个过程大概四十分钟其中我实际动手的时间不到十分钟。如果我自己写估计要一个半小时。效率提升是真的但前提是每一步我都在把关。6.5 几个反复踩到的坑最后分享几个我反复踩到的坑帮你省点时间别让它一次改太多。任务越大它跑偏的概率越高。把大任务拆成小任务一个个来。别信它的我改好了。它说改好了你还是要跑测试。它有时候会漏跑或者误判测试结果。改完记得看diff。它偶尔会顺手改一些你没让它改的地方可能是优化也可能是引入问题。重要操作前先commit。让它动手前确保当前代码是干净的、已提交的。万一它改乱了你能一键回滚。把它的不确定当回事。它主动说这里我不确定的地方往往就是真正有风险的地方重点看。这套工作流用下来我的感受是Agent不是替代了我是把我从搬砖里解放出来让我能专注在判断和决策上。标题说替代Senior我理解成它把Senior从重复劳动里解放出来去做更Senior的事。这个方向我觉得是对的。至于它会不会真的替代掉某个具体的人那取决于这个人愿不愿意把重复劳动交出去、把判断力练上来。工具已经摆在这了怎么用是你的事。
