上周我让AI帮忙排查一个线上偶发队列堆积的问题它一口气给了五个方向我照着试了三个都是错的第四个试起来成本太高第五个其实是我自己想到的。同一周我的一个同事用AI把部门内部的一个数据清洗工具从设计到上线两天搞定了按我的经验这活儿以前至少得两到三周。同样的工具差别可以这么大这让我不得不认真琢磨一个问题AI程序员到底会革谁的命革我们自己的吗这个话题最近在技术社区里讨论得很凶。有人拿AI生成代码当段子讲说它写出各种离谱的函数也有人靠AI一个人撑起一整个小项目日子过得相当滋润。两个极端摆在一起很多人是分裂的一边在焦虑一边在观望。所以这篇文章我不想聊太虚的就把我自己用AI写代码的真实体验、观察到的岗位变化以及我现在实际在用的应对策略全部摊开来讲。1. 我用AI写代码的真实体验它到底在哪个段位1.1 顺手的场景样板代码、测试补全、临时脚本先说它用得特别顺的地方否则对AI也不公平。第一类是样板代码。记得有一次要做一组FastAPI的CRUD接口六个资源表每个都要写增删改查、分页、鉴权校验以前这种活最少要一个下午加一个晚上还要复制粘贴改字段名改到眼花。现在我把数据模型往对话里一贴告诉AI按项目里现有的分层风格生成它几十秒就能把六个接口文件全部写完字段名、类型注解、状态码全对齐我只需要过一遍逻辑改几处业务细节就合入。这种任务本质上是大量模式化输出AI做得又快又整齐。第二类是补测试。我手头有个老模块日志里面有几个分支条件常年没人覆盖我让AI先读源码再按已有的测试框架风格补齐用例它把正常路径、异常路径、边界值全部列出来还顺手把mock数据写好了。我只需要补充几条业务特有的脏数据案例。单测覆盖率从63%提到了89%这个数字以前靠人力去磨没两三个迭代磨不出来。第三类是临时脚本和数据处理。内网日志导出之后要做字段抽取、去重、排序、统计分布以前我会写个Python脚本每次大概要花半小时到一小时。现在直接把样本贴给AI描述清楚我要什么它给我生成脚本我改改路径和正则就跑。遇到不满足的地方直接把报错贴回去它迭代几版也就能用了。在这些场景里AI几乎是降维打击。它不会累不会漏写重复的字段也不会不耐烦。作为有经验的人我能清晰感觉到流水线性质的工作正在快速失去存在的意义。1.2 翻车的场景多文件耦合、环境依赖、隐蔽的边界条件但如果你以为AI已经能独立负责一个生产系统那距离还很远。我遇到过的翻车案例可以写一长串。最典型的一次是让AI给支付回调接口加幂等处理。它给我的方案是在数据库里加一个订单号唯一索引写入前先查一下。这个方案在教科书层面完全正确但它完全没有考虑我们的生产环境回调服务是多实例部署的查询和写入之间有时间窗两个实例同时收到重复回调就会同时查到不存在然后同时写入唯一索引此时确实能拦住后写入的请求但先写入的请求里可能还要执行异步通知、更新缓存、刷新对账表等一堆副操作。如果直接用AI给的方案日志里会多出一堆表面罕见、实际必然偶发的异常报警。最后我还是把原来手写的分布式锁方案捞出来改造了一遍。另一个例子是排查ES数据倾斜。系统里有几个索引的写入量不均衡我拿集群配置和分片设定丢给AI它一口气给了七八条建议从调整分片数到改路由规则都有。猛一看每条都专业但仔细一推它完全不知道我们的业务分片键是用户ID而且头部用户占了接近四成流量单纯的调整分片数量解决不了倾斜要改的是写入端的哈希策略。AI不掌握这些业务上下文它的建议就只能在通用层面正确到了具体系统里很可能把你带沟里。说到最坑的是那些和环境强相关的问题。有一次AI给我生成了一段grpc客户端重连代码逻辑看着没问题编译也通过但部署之后发现它对健康检查的处理完全错误会跳过初始连接失败后的退避逻辑导致服务雪崩。这种问题只有在真实流量下才会暴露AI在它的训练语料里根本找不到我们公司这台网关的配置细节。1.3 我的结论AI是个高配实习生不是资深架构师经历多了之后我给AI贴了个角色标签高配实习生。这个类比很贴近实际。实习生的优势是知识体系新、执行力强、给一个定义清楚的任务很快能交出像样的东西。但实习生的短板也很明显对系统全貌没有感知不知道存量代码里为什么这里加了个奇怪的if不知道某个边界条件是上次线上事故留下的教训更不知道怎么在多个约束条件之间权衡取舍。所以我现在带AI工作的方式和带实习生非常像我会给它足够清晰的上下文会把大任务拆成它能够理解的小模块会要求它先讲思路再动手等它给出结果之后我会做严格的review。我不会因为AI给出一版看起来合理的代码就放松警惕因为我知道它不懂我们的业务不懂我们踩过的坑更不会为线上事故承担责任。想明白这一点之后我反而不太焦虑了。AI让编码这个动作变得便宜但系统设计、边界判断、风险识别这些真正的工程能力依然稀缺甚至因为AI降低了产出代码的成本这些判断力的价值比以前更高了。2. AI革的不是程序员的命是岗位结构的命2.1 软件开发全流程中AI的介入度分布我试着把软件开发的完整链路列了一遍需求澄清、方案设计、任务拆分、编码实现、代码评审、测试验证、发布上线、监控排障、架构演进。AI在里头的介入程度差异极大。环节AI当前的介入程度对人工能力的要求变化需求澄清低能帮忙整理会议纪要、列出疑问点人工必须更懂业务否则需求本身就是错的方案设计中低能提供候选方案但缺少取舍依据需要人来定边界、做技术选型、评估成本和风险任务拆分中能按模板拆Epic和Story拆分颗粒度和依赖关系需要人来判断编码实现高能生成大量可编译的代码从写代码变成审代码、改代码仍然要懂底层原理代码评审中高能发现明显的坏味道和空指针风险重点审查语义、并发、业务规则等AI发现不了的问题测试验证高能生成单测和简单的集成测试测试场景设计仍然依赖对业务流程的理解发布上线中写CI/CD脚本很熟练灰度策略、回滚方案、变更风险需要人拍板监控排障中低能帮忙分析日志模式但定位根因仍需人主导系统全貌的掌控能力越来越值钱架构演进低能列举架构风格但做不了长期决策业务预判、成本权衡、组织协同这是核心竞争力这个表我反复看过很多次真正被AI大幅挤压的其实是编码实现环节。但编码实现从来不是程序员的全部价值甚至多年来被严重高估了。当编码成本趋向于零时链条上其他环节的价值占比会被重新放大这就是我所说的岗位结构变化。2.2 初级编码岗在收缩指挥AI的工程师在增长我自己近半年明显感觉到招聘市场的风向变化。以前团队招人常规路径是招初级工程师做执行层写接口、修bug、补测试慢慢培养系统认知。现在不一样了这类纯执行型岗位的需求在收缩不是业务不需要人而是这些活AI补上了大半。不少团队在招人时开始明确要求能熟练使用AI协作开发这不是噱头是成本压力倒逼的结果。我也观察到一个很有意思的现象以前做内部工具至少得拉两三个人一个前端一个后端外加测试因为内部工具的业务逻辑不复杂但涉及界面、存储、权限、部署这些边角料量大管饱。现在呢我一个同事用AI十几天就把一个运营后台从零到一搭完了报表、权限、审批流全都有。他原来是个不怎么写前端的人硬是靠在对话里描述组件结构把React页面搭出来了。这意味着过去四五个人的草台班子能干的事现在一两个人加AI也能干。当一个团队需要的人变少但每个人承担的职责范围更宽时岗位结构自然就变了。不是程序员消失了而是纯代码工人的位置消失了取而代之的是会指挥AI、会兜底、会拍照板的复合角色。2.3 一个人的现代开发团队不再是段子以前说一个人一个团队多少有点戏谑现在正慢慢变成现实。我一个自由职业的朋友最近一个人接了三个中小型外包项目他把自己的流程固定下来先跟客户聊需求回来把对话记录丢给AI做需求文档再自己把关键流程画出来让AI按模块生成代码每个模块生成后他自己build、跑测试、看日志有问题把报错贴回给AI迭代。遇到AI反复改不对的他才会打开源码自己下手。他说了一句话我印象很深我现在用的不是AI唯一的本事是它当个好用的外包团队而我自己的活变成了项目经理加架构师加测试负责人。这种模式能不能承接大型复杂系统短期内很难因为大型系统真正的难点在组织协作、数据一致性、灰度演进这些系统性约束上AI给不了默认最优解。但大量中小型业务场景确实会被这种模式覆盖掉这已经足够改变整个行业的用人结构了。3. 当AI能写代码程序员的核心竞争力开始迁移3.1 从把需求翻译成代码转向定义真问题过去很长一段时间程序员的日常就是接需求、做分解、写代码、交付。这套模式下最重要的是把业务方的语言准确翻译成技术实现。但现在AI把翻译这个动作的成本打了下来真正的瓶颈变成了需求本身是不是对的举个我经历过的例子。业务方提了个需求说我们要开发一个数据分析平台展示各渠道的投放转化情况。放在以前这就是一个明确的功能点排期开发就行。但现在你必须先问一句为什么业务方需要一个平台他跟你说这件事背后的真实诉求可能是投放经理每天要手动从三个后台导出数据做表格太慢了。那解决方案根本不是一个数据分析平台而是一张每天早上自动推送到群里的汇总报表一天就能上线。你要是直接去做平台两周后大概率发现业务方用了一周就不用了。定义真问题的能力来自领域知识来自跟业务方的深度沟通来自对数据指标的敏感度。这些AI很难替代因为问题在展开之前是一团模糊的、带着情绪和场景的碎片信息AI没有参与你说的那句我觉得这个数据不太对之前的语境。3.2 从实现功能转向决策与担责AI写代码这件事本身已经不需要太多讨论。可代码上线之后出了问题是AI还是人为事故答案肯定是人。我们团队就发生过一次因为AI生成的代码引起的事故。当时有个同事让AI优化一段字符串解析逻辑。AI给了一个看起来很精妙的正则表达式在处理常规字符时速度提升明显但上线后灰度环境出现了一批超长特殊字符请求CPU直接飙到100%。幸亏有灰度开关我们在十分钟内回滚了。事后排查发现AI选的这个正则存在灾难性回溯问题它没有在生成的代码里提示任何风险因为它不知道我们的请求长度分布也不知道我们的安全红线。从那次之后我们团队立了个规矩AI生成的每一段代码都必须经过需求反推边界条件审查上线观测三道人工关卡。这个规矩不是让我们的效率变低了恰恰相反它逼着每个工程师在做AI产出物审查时必须真正理解代码意图。原来的实现功能工作变成了决策这段代码可不可以上和担责出了问题我认。这才是值得程序员投入的领域。技术判断力、风险评估、灰度策略、回滚预案、安全生产这些责任AI承担不了但它是整个系统的安全保障。3.3 从码农转向业务翻译官系统医生我认识的工程师里被裁或者转岗的很少是因为AI太强更多是因为他们除了实现能力之外没有别的优势。反过来那些最能扛事的人都是既能读懂业务、又能诊断系统的复合型人才。做一个业务翻译官的意思是你能把业务方的模糊诉求翻译成清晰的技术方案再翻译回去让业务方确认保证双方在同一张图纸上干活。做一个系统医生的意思是线上出了问题、性能出现瓶颈、数据对不上了你能在最短时间内找到根因并给出治疗方案。这两类角色都需要长期积累的系统全貌认知和行业领域知识不是翻翻文档就能学的。最近身边不少朋友在搜各种Python和AI课程资料包有人甚至下载了上百G的视频但三个月过去还是只会跑教程里的示例。这里我想多说一句资料本身不是能力把资料变成你自己的项目、解决一个真实问题才是能力。真正的成长路径不是再囤一百个教程而是拿手头最头疼的问题去和AI一起解决解决完复盘AI推荐什么新思路就去查什么这种问题驱动的学习效率比把课程从头刷到尾高得多。4. 未来三五年什么样的程序员会被革命4.1 只会把需求翻译成代码的执行者说得直白一点AI最擅长替代的就是那种你给我充分明确的需求、我把它变成代码的执行者。这类工作不需要对业务负责不需要做技术选型甚至不需要理解系统全貌只需要把接口定义翻译成实现。以前这是很多初级程序员的日常也是大量外包和内部工具开发的常态。我曾见过一个很典型的场景一个同学每天的工作就是按照PRD写REST接口联调再改字段再联调。他做了三年简历上写的技术栈很全但对业务逻辑没有任何决策权。这样的人在AI加入之后被替代的风险是最高的因为AI写接口的速度和准确率已经不亚于两年经验的人。如果你发现自己就是这种状态我建议立刻开始改变工作方式。下一次接到需求时多问一句为什么要这个接口这个接口在业务链路里处于什么位置有没有其他方式可以实现同一个业务目标把这些问题养成习惯你才可能在AI时代建立起保护自己的护城河。4.2 拒绝更新工作方式、坚持手写一切的人和前面那种人相反的另一个极端是坚决不用AI的原教旨主义者。他们认为AI写的代码不可控、有安全风险、不如自己写的稳。我承认这些担忧有道理但用拒绝来应对变革和当年拒绝从汇编转向高级语言的人一样危险。我以前也坚持过一段时间觉得手写代码是基本功用AI是偷懒。后来有一次加班到凌晨三点反复调试一个字符编码问题第二天把同样的问题丢给AI它五分钟就指出了原因。从那时候我开始反思基本功是让你能判断AI输出的质量而不是让你事事亲力亲为。趋势已经很明显未来团队里一个人用AI就能顶过去两个人用传统方式的产出老板算账算得很清楚。坚持手写一切可能不再是美德而是团队里的效率瓶颈。4.3 把AI神话或妖魔化的人还有一类人容易被革命就是那些对AI抱有不切实际期待的人。有人觉得AI马上就能彻底替代程序员于是不再积累技术深度等着被淘汰有人觉得AI什么都做不了于是完全无视它的存在。这两种心态在极端时候都会让人停止真正的学习。我更愿意把AI看作一个能力放大器和效率杠杆。它能让一个本来只会写业务代码的人快速补上前端、运维、数据分析的能力也能让一个资深工程师从大量琐碎工作中解放出来把时间投入在更复杂的系统决策上。关键在于你要有足够强的底层能力去驾驭它而不是被它带着走。4.4 给自己做一次被革命风险自测我给自己设计了一套问题清单每隔几个月会重新过一遍你可以拿着它对照自己的状态你是否长期只会写固定几种CRUD接口从不主动接触系统其他模块你最近一次理解业务方的真实诉求而不是直接照单接需求是什么时候如果你的代码被AI生成的版本替换你能说出哪些地方是AI必然做不好的吗你是否能画出你所在系统从客户端到数据存储的完整请求链路线上出问题时你的第一反应是找日志、看监控、定位根因还是等着别人给你结论你是否知道系统中最大的性能瓶颈在哪个环节你最近半年有没有主动学习过一项和AI无关的技术比如网络协议、数据库引擎、分布式一致性你是否能把一个业务需求拆成可以并行推进的小任务并评估每项任务的风险你有没有自己拍板过的技术方案如果有你是否为这个决定承担过后果你对当前行业的业务数据指标、核心成本结构了解多少这些问题不一定都有标准答案但它们指向同一个方向你到底是一个只提供执行的零件还是一个能定义问题、承担责任的核心角色。前者很容易被替代后者随着AI普及会越来越稀缺。5. 我现在在用的应对策略可能对你有用5.1 让AI进入日常节奏而不是偶尔上网问一下很多人用AI的方式是遇到bug才去问一下这种用法只能拿到零散的答案价值非常有限。我的做法是把AI嵌入到整个研发流程的每一天。一个典型的工作流是这样的接到需求后先让AI根据对话记录生成需求清单和验收标准确定之后让AI基于历史代码风格输出两到三版候选方案我选择或合并其中一版方案定了之后让AI生成代码骨架、接口定义、mock数据拿到骨架后我自己搭建业务关键逻辑再让AI补齐边界分支和测试用例合入前用AI做一次代码审查把可疑点逐条过掉最后让AI起草变更说明和复盘文档。这一套流程走下来AI承担了大量上下文转换的成本我只需要在关键节点做判断。它让我每天真正动手敲键盘的时间减少了很多但产出的系统质量和稳定性反而提升了因为我有更多时间在思考而不是在敲字。5.2 刻意去做那些AI做不好但业务很痛的事要让自己不可替代最重要的策略不是和AI拼它擅长的东西而是去做它不擅长的事。我自己会刻意接这类的任务跨系统数据一致性问题、老系统的存量技术债梳理、核心链路压测与性能调优、跟业务多方对齐指标口径、处理线上紧急事故的指挥和复盘。这些工作的共同点是要么需要大量的领域知识和沟通协调要么需要在极端压力下做高风险的判断AI在这些场景里只能提供一些参考信息最终的决定和责任都在人身上。我也建议你在团队里主动认领这类脏活累活或模糊地带的活。这类活不容易出漂亮成果但它们在建立你的不可替代性方面效果远超多写一万行CRUD。5.3 建立AI输出审计的肌肉记忆最后一条也是我用血泪教训换来的任何AI生成的东西都必须经过审计。我给自己定了三个固定动作第一需求反推。拿到AI代码之后先不看代码本身闭上眼睛回忆原始需求然后问自己这段代码真的能满足这个需求吗这样做能先拦掉一批答非所问的输出。第二边界条件审查。专门列出那些正常情况下不会发生但发生了就会出事的输入空值、超长字符串、并发重复请求、下游服务超时。我习惯直接让AI先分析这段代码在这些条件下会怎么表现再人工核对它说的对不对。第三安全与资源使用检查。主要看AI生成的正则、循环、SQL查询、文件操作代码会不会在大数据量下出现资源耗尽或无限重试。这个环节别省因为AI默认不会考虑流量峰值和异常请求分布。我还养成了一个习惯要求AI在给出代码时同时给出一小段思考过程说明它为什么这么设计。不是为了欣赏它的逻辑而是方便我在review时快速定位它忽略了什么。把它想成一个实习生你会怎么看它的思路就怎么审查AI的方案。说到底AI程序员革不革我们的命单看标题是个开放式问题。我的答案已经很明确了AI会淘汰一部分岗位也会让另一部分人的价值指数上升分水岭不在技术多牛而在你是否愿意改变工作方式、是否真正理解业务、是否敢为自己的决策担责。革自己的命在我理解里不是把自己变成会写代码的AI而是把自己变成能和AI配合得最好的那个人。我现在每天的工作方式已经和两年前完全不同了我可以确定的是站在原地等答案一定不是选项。