虽然听起来有点标题党，但过去这一年，我在GitHub上亲眼看着AI从一个“只会写Hello World的玩具”，变成能自己读代码、改Bug、补测试、提PR的“准Senior”。前天早上我打开仓库，看到一条bot提交的PR，把一个月前的一个Issue修复了，附带三个单元测试和一份更新的README，没有人点任何按钮，它自己跑完了整个流程。这篇东西我不想聊概念，就想把这段实践从头到尾复盘一下：AI到底是怎么在GitHub上干活的，Senior的工作它替代到了什么程度，哪里替代不了，以及你自己上手应该怎么做。
1. 从Hello World到自主提交PR，AI编程能力的实际跃迁
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机制做得好，适合日常提交 |
| Cline | VS 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 硬件门槛：显存、内存、带宽怎么算
本地跑模型，先要有心理预期：模型参数选多大，和你能拿出多少显存强相关。我按常见量化方案给一个粗略的对照：
| 模型规模 | 量化方式 | 建议内存/显存 | 能干什么 |
|---|---|---|---|
| 7B | Q4_K_M | 16G内存可跑（CPU慢），8G显存舒服 | 代码补全、简单问题问答 |
| 14B | Q4_K_M | 32G内存可跑，16G显存舒服 | 有一定规划能力，能处理中等重构 |
| 32B | Q4_K_M | 64G内存勉强，24G显存起 | 接近云端中端模型，能跑复杂任务 |
| 70B+ | Q4_K_M | 48G显存起，或双卡 | 效果更好，但对个人不现实 |
内存和显存的换算逻辑很简单：模型权重本身就要占这么多空间，运行时还需要额外的KV Cache和激活内存。Q4量化意思是用4bit来表示大部分权重，体积大约是FP16的四分之一。7B模型Q4量化后大约4-5G，所以8G显存勉强能跑起来。14B量化后大约8-9G，16G显存刚好。
实际跑起来想舒服，最好把显存占用控制在显存总量的70%以内，留出空间给系统和其他程序。如果显存不够又想跑大模型，就只能采用CPU+内存方案了，但推理速度会慢到让人失去耐心。
5.3 Ollama + Qwen2.5 Coder的落地配置
本地部署工具链已经非常成熟，最省事的方案是Ollama。它对硬件的调度做得不错，一条命令就能拉起一个有OpenAI兼容API的模型服务。以阿里的Qwen2.5 Coder系列为例，配置过程如下：
# 安装Ollama（macOS / 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，看看你回来会是什么心情。
