虽然听起来有点标题党但过去这一年我在GitHub上亲眼看着AI从一个“只会写Hello World的玩具”变成能自己读代码、改Bug、补测试、提PR的“准Senior”。前天早上我打开仓库看到一条bot提交的PR把一个月前的一个Issue修复了附带三个单元测试和一份更新的README没有人点任何按钮它自己跑完了整个流程。这篇东西我不想聊概念就想把这段实践从头到尾复盘一下AI到底是怎么在GitHub上干活的Senior的工作它替代到了什么程度哪里替代不了以及你自己上手应该怎么做。1. 从Hello World到自主提交PRAI编程能力的实际跃迁1.1 我早上在仓库里收到一条机器PR先讲个具体的场景。我维护了一个不算太大的Java开源项目平时靠社区报Issue和PR。前一阵子有个用户提交了一个Issue描述的是某个配置项在特定环境下没有生效的问题还贴了日志。按我以前的经验这种Issue至少要花一晚上去翻代码、试复现、定位根因、写修复补丁然后再设计用例防止回归。但这次不一样。我还没开始动手第二天早上就看到仓库里多了一条PR。打开一看提交者是一个bot账号PR标题清晰描述里列了根因分析、修改文件清单、测试结果。再看代码改动它在配置加载的初始化顺序上做了调整额外补了两个单元测试连CHANGELOG都更新了。我跑了一遍CI全绿。那一刻我真的愣住了。这条PR的完整度已经不是“AI补全一段代码”的水平而是“一个人明确了需求、翻了代码库、找到问题、完成修复、提交成果”的完整工作流。Hello World时代早就过去了现在AI在GitHub上干的是“全职开发”的活。1.2 从“补全代码”到“交付完整需求”中间差的不只是模型很多人对AI编程的印象还停留在GitHub Copilot刚出来的阶段你在编辑器里打字它帮你补下一个函数、下一行代码。再或者你给它一段题目它给你生成一段能跑的“Hello World”或者算法题答案。这种使用方式本质上还是在“辅助打字”AI是一个聪明一点的输入法。但现在真正引起质变的东西是AI Agent。它不再等着你一句一句喂而是给定一个目标之后自己去完成整套动作读取仓库目录结构搞清楚项目组织方式打开相关文件阅读现有代码逻辑全局搜索某个函数或常量的引用位置修改多个文件保持代码风格一致运行测试或编译命令根据报错自己调提交commit甚至直接push分支并创建PR。这中间每一步都对应着一类工程能力。过去的“AI写代码”只解决了其中“写”这一瞬间的动作而Agent把“读代码、理解需求、执行修改、验证结果、交付成果”这一整条链路都串起来了。从“输入法”到“实习生”这才是真正的能力跃迁。提示判断一个AI编程工具是不是Agent最简单的标准是看它能不能自己调用终端和文件系统。只会对话框生成代码的严格说还不算Agent。2. 把Senior的日常拆成六类工作逐项看AI替代到了哪个环节既然标题说“替代Senior”我们就别飘着聊把Senior工程师的日常工作摊开来看。我按自己带团队的经验把这类工作拆成六类列了一个对照表后面逐个展开说。Senior日常工作AI替代程度我的实际评价需求拆解约30%能生成拆解草案但方向判断还得人来拍板技术方案设计约30%能列出候选方案但选型理由经常“想当然”编码实现约80%模块级新功能开发最顺手老系统改造要人盯代码重构约70%小步重构很拿手大规模动架构容易翻车测试补齐约85%覆盖率比很多人类开发还高断言质量看上下文代码审查约50%能抓低级错误判断不了架构取舍发布准备约60%变更日志、Release Notes、基础发布脚本都是好手2.1 需求拆解和技术方案AI还到不了但能帮你快速出草案这个结论可能和很多人想的不一样。既然AI都能提交PR了怎么需求拆解只有30%因为需求拆解的本质是“将模糊的商业语言转化为精确的技术语言”。比如产品经理说“用户觉得页面有点卡优化一下”这句话落到代码层面可能是数据库慢查询、可能是前端渲染冗余、可能是接口并发瓶颈甚至可能是网络链路问题。AI在缺少系统上下文的情况下会基于统计规律给你一个“最常见的方案”但这个方案不一定适合你的业务。不过话说回来AI在生成“候选方案清单”这件事上非常有用。我曾让它为“订单超时未支付自动关闭”设计技术方案它在几秒内给出了定时任务轮询、延迟队列、消息中间件、事件驱动四套方案还附了各自的优缺点。这个信息量足够让我半小时内完成技术评审——这个速度放在以前至少要翻半天资料。所以我把它的角色定位成“技术预研助理”不替你做决策但帮你把决策所需的信息提前准备好。2.2 编码实现模块级开发最顺手AI能顶一个“熟练外包开发”编码实现是AI替代程度最高的环节尤其是新功能开发。在接口定义清晰、数据模型明确、周边代码风格统一的情况下AI写出来的代码质量相当能打。我用一个小型Spring Boot项目做过测试给它一份完整的需求描述和现有的Entity、Repository让它实现一个Restful接口包含参数校验、业务逻辑、异常处理、单元测试。最终PR的代码质量我给7.5分满分10分扣分点主要是两个地方一是有个并发场景没考虑线程安全二是异常的类型选择不够精准。但这些问题在代码审查阶段都能发现整体效率比人工开发高了一个量级。需要注意AI在老系统改造中的表现就没这么好了。面对祖传代码、魔法数字、隐藏依赖、设计极度混乱的模块AI的行为模式和人类一样会出现“水土不服”它会尽力仿照错误风格续写而不是主动告诉你“这块建议重构”。因为Agent的核心目标还是“完成任务”不是“指出问题”。2.3 测试补齐AI比很多开发更爱写测试这个结论非常反直觉但我测过好几个模型确实如此。AI的思维里没有“调休”和“偷懒”这回事只要你在提示词里写了“补全单元测试”它就会老老实实把正常路径、异常路径、边界值全覆盖一遍。我见过一个场景AI给一个工具类生成的测试里甚至包括了对空指针输入、超大数值、编码格式三种边界条件的断言。人类开发写测试普遍有“证明代码能跑”的心态AI写测试却有“把代码搞坏”的偏执。这一点在回归保障上价值很大。当然AI写测试的短板也很明显它倾向于“验证已经实现的行为”而不是“验证需求要求的行为”。如果主代码逻辑本身就写错了AI写出来的测试大概率会和错误实现“同流合污”测试全绿但需求是错的。所以测试代码同样需要人审。2.4 代码审查让AI给AI挑毛病可行吗我做过一个实验让AI A写一个功能再让AI B以“资深代码审查者”的身份检查AI A的提交。结果是AI B确实抓出了一些风格问题和几个潜在Bug比如未关闭的IO流、不一致的日志级别、缺失的NPE保护。这给我省了不少低级review时间。但AI的代码审查局限也明显它还不能判断“这个设计是否过度了”“这块逻辑移到这里会不会影响未来的扩展性”这类架构级问题。它对标准的把握是“通用最佳实践”而不是“你这个项目的实际情况”。所以我的经验是用AI做“带过滤器的静态检查”别指望它能替代整个Code Review流程。3. 让AI在真实项目里当一下午Senior一次完整实践复盘聊到这里光说不练没意思。我把最近一次真实实践的过程完整拆开从工具选型、提示词设计、过程干预到最终PR质量一步步讲清楚。3.1 工具选型Cline、Aider、Copilot Agent怎么挑现在能跑AI Agent方案的工具有不少Cline、Aider、GitHub Copilot的agent模式、开源的OpenHands原OpenDevin都在演进。我自己的选型建议看下表工具工作方式适合谁我的评价Aider命令行轻量和Git深度集成老手、终端党上手快repo map机制做得好适合日常提交ClineVS Code插件可视化Plan/Act两个阶段可视化偏好者可以看它读哪些文件、执行什么命令安全感强GitHub Copilot Agent深度集成GitHub生态重度用GitHub的团队原生支持按Issue工作对PR流程友好OpenHands独立调度框架想自建AI开发流程的团队灵活可控但配置成本高我这次项目用的是Cline理由是它的Plan/Act分阶段模式很适合“先让它读代码、讲思路再动手”的流程。这点很重要因为Agent最大的问题就是“过于自信”如果你连它看到的东西都不知道翻车时你根本不知道从哪排查。3.2 我用过的“Senior指令模板”很多人用AI写代码效果差问题出在任务描述太随意。我沉淀了一份相对好用的“Senior指令模板”核心就四段角色定义、需求描述、约束条件、交付要求。你是一名有十年经验的高级后端工程师。请以本仓库维护者的身份完成以下需求。 需求#128 用户列表支持导出CSV文件导出内容需与后台表格列一致包含注册时间。 约束 1. 使用项目现有UserRepository不引入新的ORM框架 2. CSV文件必须处理中文乱码采用UTF-8 with BOM 3. 日期格式统一为 yyyy-MM-dd HH:mm:ss 4. 导出接口需要复用现有权限校验注解。 要求 1. 先阅读相关代码文件输出你的实现计划 2. 计划确认后再动手修改 3. 补全单元测试覆盖正常导出、空列表导出、无权限访问三种场景 4. 更新README中的接口说明 5. 运行mvn test确认全部通过后提交PR。3.3 实践过程我插手干预了三个关键节点第一次跑下来整个流程大概三十五分钟。AI做了这些事情扫描目录结构、定位UserController和UserService、参考现有接口风格写CSV导出逻辑、引入了一个CSV处理库、生成测试、跑测试、修复两个编译错误、提交分支并推送PR。但中间我插手了三次每次都是很有代表性的问题。第一次AI在输出实现计划时把日期格式化方案理解成了 使用SimpleDateFormat在项目里注入了线程不安全的对象。我提示它“项目里其他地方用什么方式处理日期保持一致”它自己跑去查了现有工具类改用DateTimeFormatter。第二次它引入了一个CSV依赖库但在PR描述里没有说明为什么不用已有的工具类。考虑到项目对依赖数量有约束我让它重新评估能不能直接用现有工具类实现CSV拼接它乖乖改成了原始实现去掉了新增依赖。第三次导出的权限问题。它实现了导出逻辑但接权限注解时用错了常量把“管理员”写成了“超级管理员”我是在测试用例里发现这个问题的。它自己补的测试刚好也覆盖了这个场景可断言值写错了。这三次干预本质都是在补上下文。AI没有“项目惯例”的概念你告诉它“参考项目现有做法”它才能表现出符合团队规范的“Senior感”。3.4 最终PR的质量评估最终这个PR包含1个新的导出接口一个CSV工具类UserService增加了一段业务逻辑三个单元测试正常导出、空数据、无权限README接口文档更新CHANGELOG条目补充。代码质量和项目现有风格基本一致。说实话如果不看提交者邮箱我第一眼会以为这是团队里一位工作两年的开发写的PR整体完成度给了8分。不足的地方对权限边界理解不够准确、以及没有主动在PR里讨论这个接口的异常响应结构是否符合RESTful风格。这已经足以证明AI在GitHub上干那些“有规范、有上下文、有验证手段”的需求是真能干到接近初级到中级工程师水平的。4. 决定AI体验优劣的不是模型是上下文工程同样是打代码有人用AI像请了个实习生有人用AI像请了个Senior差别不在模型而在你喂进去的上下文。这点我用了好几个月才彻底想明白。4.1 上下文不是越长越好而是结构越清晰越好很多人以为上下文工程就是“把整个仓库所有文件都丢给AI”以为喂得越多它越聪明。实际上窗口一长模型反而容易迷失重点。真正的上下文工程是让AI知道“先看什么、再看什么、哪些是权威依据、哪些只是参考”。一个有效的做法是给AI一张“仓库地图”项目结构 - controller/ HTTP入口参数校验在这里 - service/ 业务逻辑层大部分规则在这层 - repository/ 数据库访问继承JpaRepository - common/ 通用工具类包括日期处理、Excel/CSV导出 关键文件 - UserController.java 需要修改的入口 - UserService.java 核心业务逻辑修改重点 - UserRepository.java 只读参考不要改 - AuditLogUtil.java 通用的操作日志方法新增导出时要记录日志这份地图不是给人类看的而是给AI的“导览手册”。它能在几秒之内把AI的代码搜索范围缩小到一个合理的子集效果远比把整个src目录丢进去好。4.2 让AI“进仓库干活”而不是“拿片段看题”我观察到很多人用AI习惯把代码拷贝粘贴到对话框里“这段代码哪里有问题”这是典型的“拿片段看题”思路。AI看到的只是一个孤立代码块它无法感知这个函数被谁调用、依赖什么全局状态、用什么风格组织。正确的用法是让AI真正“进仓库”。这就是为什么我前面特别推荐Cline或者Aider这类Agent工具它们可以读取文件、执行grep、运行测试。AI在这种模式下拿到的不再是“题目里的片段”而是“一个可以自己翻资料的开发环境”。这种模式带来的体验差异非常明显。我曾经把同一个问题分别用“粘贴代码”和“让Agent进仓库自查”跑了一遍前者给出的是一个泛泛的、存在几处明显误解的答案后者直接定位到了配置失效的根因并给出了符合项目风格的修复方案。这也是为什么说“同一个模型不同人用效果天差地别”。4.3 测试和编译错误是最好的反馈回路Agent能不能自我纠错是它表现“高级感”的关键。AI替你写代码写了之后怎么知道对不对最可靠的方法不是让AI自己“读一遍确认一下”而是让它跑起来。我在实践中逐渐形成了一个要求任何AI生成的PR至少得跑过项目现有的测试套件或者给出充分的理由说明为什么不需要跑。因为AI的幻觉往往藏在自己生成的代码里它检查自己的代码就像学生给同位改卷——容易“有默契地放水”。测试是外部的客观标准能给它一记沉闷但真实的反馈。一个典型的Agent工作流应该是这样的1. 人类给出需求 仓库地图 约束条件 2. Agent先阅读相关代码输出实现计划 3. Agent按计划修改文件 4. Agent运行测试/编译失败就回头读报错信息修改 5. 最多重试若干次若无法修复则停下来向人类求助 6. 人类审查改动补充遗漏约束条件 7. Agent提交PR。我在第4步见过一次很典型的场景AI改了Service层代码后原有的一个测试失败了。它自己读失败信息判断是修改后返回的字段类型不符合旧测试预期于是调整了返回结构最终让所有测试通过。这种“自己发现问题、定位原因、修复回归”的自愈能力才是它和普通代码生成器的分水岭。4.4 把复杂任务拆成多轮对话别让它一口气吃成大胖子AI Agent虽然能处理长流程但它不是没有上限的。当任务涉及十几个文件、几十个步骤时一次性让它端到端跑到头中途出错概率会急剧上升。我的经验是把大任务拆成几个子任务每个子任务独立开启一轮Agent对话。比如“实现一个用户订单导出功能”我不会让它一口气做完而是拆成三步第一步读现有订单和用户模块代码输出数据模型和接口设计第二步实现Service层逻辑和CSV工具类第三步实现Controller接口、权限注解、异常处理第四步补测试、跑CI、提交PR。每轮之间我都有机会检查思路、纠正方向。虽然看起来多了几轮交互但综合成功率反而更高。这个习惯和带新人很像你让实习生一口气搞定所有事大概率一地鸡毛你分阶段盯他就能一步步交出像样的成果。5. 数据敏感团队怎么让AI“上班”本地部署的配置思路聊到AI编程的落地一个绕不开的问题是数据安全。很多公司的代码仓库是企业核心资产。让AI读代码没问题但把代码发到外部API接口合规性上过不去。这种场景下本地部署一个开源模型就成了刚需。5.1 哪些团队必须走本地部署我的判断很简单只要你的代码包含未公开的商业逻辑、客户数据、算法策略或者公司审计要求明确禁止代码出域那本地部署就是唯一选择。别挣扎也别抱侥幸心理用外部API把代码传上去出了事不是模型的问题是人的问题。本地部署的好处是代码完全在内部环境流转外网断掉也能用。代价是模型能力通常比云端最强模型差一截硬件投入也不少。但它对“能不能用AI”这个从无到有的问题是决定性的。5.2 硬件门槛显存、内存、带宽怎么算本地跑模型先要有心理预期模型参数选多大和你能拿出多少显存强相关。我按常见量化方案给一个粗略的对照模型规模量化方式建议内存/显存能干什么7BQ4_K_M16G内存可跑CPU慢8G显存舒服代码补全、简单问题问答14BQ4_K_M32G内存可跑16G显存舒服有一定规划能力能处理中等重构32BQ4_K_M64G内存勉强24G显存起接近云端中端模型能跑复杂任务70BQ4_K_M48G显存起或双卡效果更好但对个人不现实内存和显存的换算逻辑很简单模型权重本身就要占这么多空间运行时还需要额外的KV Cache和激活内存。Q4量化意思是用4bit来表示大部分权重体积大约是FP16的四分之一。7B模型Q4量化后大约4-5G所以8G显存勉强能跑起来。14B量化后大约8-9G16G显存刚好。实际跑起来想舒服最好把显存占用控制在显存总量的70%以内留出空间给系统和其他程序。如果显存不够又想跑大模型就只能采用CPU内存方案了但推理速度会慢到让人失去耐心。5.3 Ollama Qwen2.5 Coder的落地配置本地部署工具链已经非常成熟最省事的方案是Ollama。它对硬件的调度做得不错一条命令就能拉起一个有OpenAI兼容API的模型服务。以阿里的Qwen2.5 Coder系列为例配置过程如下# 安装OllamamacOS / Linux / Windows都支持 curl -fsSL https://ollama.com/install.sh | sh # 拉取14B模型约9G左右 ollama pull qwen2.5-coder:14b # 启动服务 ollama serve # 新开一个终端跑起来测试 ollama run qwen2.5-coder:14b跑起来之后它默认监听本地11434端口Cline、Aider这类工具会自动识别本地模型配置。如果你想把它接入Cline一般只需要在模型设置里选“Ollama”然后填上模型名qwen2.5-coder:14b就行。如果你需要一个更接近OpenAI格式的网关Ollama自身就带也可以搭配vLLM或llama.cpp使用。我的建议是个人单机、低并发Ollama一条命令搞定团队共享服务、并发高vLLM吞吐量优势明显内存很小或嵌入式llama.cpp极致优化。5.4 本地部署的体验落差与取舍说实话我对本地模型的态度是“有条件地满意”。社区开源模型和商业API模型的差距在简单补全和标准化任务上已经很小但在长链路Agent任务上还是有明显区别。我拿一个“修Bug并补测试”的任务在三个模型上做过对比模型结果云端顶级模型一次跑通规划清晰本地14B开源模型思路对但连续执行中出错一次需要人类提醒本地7B开源模型只能做单步操作复杂任务明显吃力所以我的落地建议是混合部署外围的、非敏感的任务走云端最强模型涉密项目或核心代码走本地模型但把任务拆得更细人类介入更频繁。6. AI替代不了的那部分Senior工作边界与风险讲了这么多AI能干的事我反而更想强调它的边界。如果你迷信“AI已经替代Senior”真的把核心架构决策和跨团队协作全丢给它翻车是迟早的事。6.1 我踩过的三个“AI翻车”现场第一个翻车案例是AI理解错了“用户列表”的具体范围。它把管理员账号也包含进导出名单了。需求文档里写的“用户列表”在这个项目里特指“C端注册用户”但这个隐含前提既不在文档里也不在代码命名中。AI按统计规律推断“用户”包括所有账号结果就是数据泄漏隐患。这种问题要不是我在审查时懂业务根本发现不了。第二个案例是重构一个传统模块。AI建议并且执行了一次“看起来很优雅”的重构把一段二十年前的魔法数字逻辑抽成策略模式。单测全过了但线上老路径崩了——因为旧逻辑里有个隐藏的特殊顺序依赖测试代码没有覆盖。AI在重构时缺乏对历史包袱的敬畏它倾向于“按最合理的方式改”但系统里很多代码恰恰是“按最妥协的方式活下来的”。第三个案例更直白我让它“优化一下用户反馈的体验”。三分钟后它交了一个方案把反馈表单从三个字段改成两个字段。这就是典型的“无上下文执行”——体验优化在AI这里退化成界面删改而真实需求可能是反馈详情页加载速度太慢。模糊需求必须由人类先翻译成精确指令。6.2 离了上下文就崩AI打不了“混战”这三个案例的共同点不是AI不够聪明而是项目环境里充满了“没说出口的规则”。这些规则藏在业务历史里、藏在前任开发的手册里、藏在产品经理的偏好里唯独不在代码里。AI最大的短板就是它无法参与“组织记忆”的构建和传承——而这些恰是Senior工程师最核心的不可替代性。再反过来看“替代”这个说法。Senior一天八小时的工作里可能有三四小时在开会、对齐、评审、写方案、回答同事问题真正坐在那里写代码的时间可能只有两三个小时。AI替代掉的是其中“编码执行”这段但沟通协调、方案决策、风险判断、人才培养这些隐性工作AI完全接不了。所以更准确的说法是AI替代的不是Senior而是Senior工作中那些重复性编码执行环节。如果一个开发天天只写CRUD、只改样式、只拼接口那确实面临被替代但如果他的价值在于“知道为什么要这么写”和“出事之后能兜底”AI反而成了他放大产能的杠杆。6.3 团队落地AI编程的实战建议最后给正在读这篇文章、想带着团队把AI真正用起来的朋友几条实操建议。第一条从低危任务开始。别一上来就让AI重构核心模块先让它补测试、写注释、更新文档、修简单Bug。这个过程一方面验证工具能力另一方面让团队建立起对AI产出的“质检手感”。第二条所有AI生成的PR都要有人审。我见过不少团队在AI提PR后直接合并理由是“测试都过了”。这是非常危险的习惯。AI写的代码和人类写的代码一样需要走完整的Code Review流程尤其要关注它“不合理的合理改动”。第三条把提示词和上下文模板沉淀成团队资产。谁的提示词写得好谁就能让AI产出更好的结果。把那些经过验证的“项目惯例词”“仓库地图模板”“任务拆解模板”整理出来放在团队Wiki里让所有人都受益。第四条持续抽查AI产出质量别一劳永逸。模型在升级你的项目在变化今天好用的提示词三个月后可能失效。保持每两周复盘一次AI产出的习惯看哪些环节质量下降及时调整模板和工具。最后说点个人体会。在我这两三个月的实践里AI的能力边界其实一天一变今天觉得它做不了的事下个月可能就能做了。但有一点是确定的会用它的人已经不再把它当玩具。如果你还没试过从今天开始挑一个真实的Issue给它足够的上下文让它试着独立提交一个PR看看你回来会是什么心情。