AI写代码这事我原本是当个乐子看的。直到有个周末我把一个支付状态机的重构需求扔给大模型它回给我的第一版内容不是代码而是一张状态流转表——把每个事件、每个前置条件、每个异常分支都列得清清楚楚然后才附上实现。那一刻我后背是真的发凉。我干了十几年的后端带过不少中级工程师也面试过几百号人。过去我判断一个人靠不靠谱最直接的方式就是让他讲清楚一个复杂状态机怎么设计。结果现在AI连这种活都能干得又快又稳——这不是偶尔灵光一现是稳定输出。当AI写代码的水准已经稳定超过中级程序员的时候我们这些靠写代码吃饭的人到底还剩什么价值这个问题我认真想了很久也和团队里几个老同事反复聊过。今天把这段思考整理出来希望能让同样在焦虑的人找到一点方向。1. 先面对现实常规编码能力正在肉眼可见地贬值1.1 从Code Review的变化说起以前我们做Code Review关注什么命名规不规范、逻辑有没有漏洞、边界条件有没有处理好、性能有没有明显问题。这些被称为“代码基本功”的东西现在AI全都做得到而且做得比大部分中级程序员更稳定。我做过一个很实际的测试让AI写一个带有动态排序和分页的复杂SQL查询它连联合索引的选择、深分页的坑、排序字段的稳定性这些细节都主动考虑到了。这放在以前我至少要给中级工程师写两轮review意见才能改到这种程度。还有一次我让AI根据一份产品需求文档直接生成新接口的实现代码。它把文档里的业务规则、参数校验、错误码、幂等逻辑全部对应上了写出来就能跑跑起来不漏边界。甚至在异常日志的打印格式上它都遵循了团队现有的规范。说实话那天我是有点沮丧的。因为这意味着我们过去最引以为傲的“编码能力”正在变成一种可以被替代的常规能力。你可以不承认但数据不会骗人团队里用AI辅助编码之后初级和中级程序员的人均提测代码量大概提升了三到五倍代码缺陷率反而在下降。1.2 不只是写业务代码的人在受影响很多人觉得“被AI冲击”的只是写业务代码的程序员其实远不止如此。基础设施工程师要写运维脚本、配置管理代码测试开发工程师要写自动化用例数据分析师要写清洗逻辑和报表查询数据工程师要写同步任务和ETL脚本——这些岗位上的“写代码能力”同样在缩水。我之前跟一个做测试开发的朋友聊天他说现在接口自动化测试的用例AI能根据接口文档直接生成八九成的覆盖率。他们团队的策略已经从“写用例”改成“判断用例”从“执行测试”改成“设计测试策略”。这个转变放在三年前我完全无法想象但现在已经实打实发生了。2. 那我们的价值到底在哪三个真正的护城河2.1 需求拆解判断需求本身对不对AI很擅长把一个大需求变成代码但它不太擅长判断这个需求本身对不对。我早年带新人的时候经常遇到一个情况产品给了一句话需求初级工程师能照着做出来但做歪了中级工程师能问出两三个问题确保方向不偏而真正资深的人能在需求评审时就直接指出这个方案在技术上不可行或者提出一个更优的技术路径。这个能力AI现在没有短期也难有。因为判断一个需求是否合理需要你对业务背景有深度理解需要对技术方案有横向比较能力还需要你敢于在会议上说“这个需求有问题”。这是人特有的判断力不是模式匹配能解决的。现在团队里最稀缺的人才画像已经不是“代码写得好的人”而是“能帮助产品把需求定义清楚的人”。这恰恰是很多程序员过去最不爱干的事——觉得扯需求浪费时间不如早点上手写代码。如今这个认知该改改了。2.2 领域建模与架构决策敢于承担有风险的判断AI写单个模块很好但它对整个系统的依赖关系、演进方向、哪些地方该上分布式事务、哪些地方该用事件驱动这些问题是没有立场的。它只会给你一个“看起来合理”的答案。真正值钱的是你为这个系统做的那些有风险的决策。比如你决定把一个核心链路从同步调用改成异步消息驱动这个决策背后的理由比如你在缓存一致性方案里选了缓存旁路而不是直写这个选择带来的性能和一致性权衡。这些东西组内推导了两轮、线上验证了半年才敢定下来AI做不到因为它没有“经历过故障”没有“踩过线上的坑”。所以我对团队里想进阶的年轻人的建议一直是不要沉迷于写更多代码要沉迷于理解系统的全貌。你能不能在十分钟内说清楚你们系统的调用链路知不知道哪些环节是单点如果某个核心服务挂了你能不能立刻指出影响范围这些才是机器无法替代的“架构直觉”。2.3 代码审查意识从审查人到审查机器有一个特别反直觉的点AI其实放大了人的认知偏误。因为它很强所以你对它给的答案会更加不做检查更容易不加验证就上线——这是最危险的。我自己踩过这个坑。有次让AI生成一段数据处理逻辑它跑出来的结果看着很合理但后来我多看了一眼边界条件发现它在处理空字符串时和团队约定的逻辑不一致。如果那个数据直接进了报表结果会错得很隐蔽。这时候团队里真正给力的不再是代码写得好的而是那些会质疑、会做取舍、会为了一个边界条件跟AI纠缠到底的人。这个技能原本叫“代码审查意识”现在它的重要性被拉到了最高等级——之前审查的是人写的代码现在审查的是机器生成的代码但审查的难度一点都没降低。所以我现在给团队成员的建议是不要以“能写出AI写不出的代码”为目标要以“能发现AI察觉不到的问题”为目标。这个能力值钱得多也稀缺得多。3. 从“用AI写代码”到“用AI思考”我自己的实践转变3.1 我现在的日常工作流可能很多人觉得“思考”这种事不会被工具辅助。我原来的想法也一样但最近习惯变了而且变化很彻底。以前遇到一个难题我会先翻资料、再问同事、最后动手写。现在我会先把自己的思路完整地跟AI描述一遍让它帮我检查这个思路的漏洞。有意思的是AI有时候能指出我方案里没考虑到的数据一致性风险也能提醒我这个做法在特定并发量下会有性能隐患。它不是替我思考而是在帮我把思考变得更严苛。举个例子我们在设计一个对账系统的补偿机制。我初步想的是失败任务进重试队列超过三次转人工。这个方案看起来没什么问题但我让AI帮我把这个思路拆了一遍它马上指出——如果在同一批对账数据中某一条记录已经转人工而它关联的另一条记录还卡在重试队列里后续的对账结果可能出现中间状态不一致。这个问题我之前完全没想到因为那是一条链路底部的“理论情况”我就是跳过了。这件事对我的冲击比“AI能写代码”还要大。因为这说明即便是思考过程也有可能被工具化、被辅助化。反过来看这也说明真正稀缺的其实是提出好问题的能力。AI给不了你问题但它可以帮你把问题拆得更细。3.2 我的提效组合拳现在我的日常编码工作流大概是这样的先花时间把业务规则和约束写清楚然后用自然语言描述给AI让它先生成接口设计和领域模型同步让AI根据我们已有的代码规范生成代码但我会明确要求它保留边界处理和日志格式生成之后我不急着跑先做一次代码审查把AI代码当作“新人的代码”来看专门挑它容易忽视的点真正复杂的难点比如分布式锁的粒度设计、消息顺序性保障我才会亲手写因为那是核心中的核心这套流程走下来我发现自己花在“敲键盘”上的时间少了大概六成花在“想清楚”上的时间多了一倍。但产出的代码质量更稳定线上问题也肉眼可见地变少了。这说明AI切走的只是体力活真正的脑力支出反而被放大了。4. AI来了为什么反而有些程序员更值钱了4.1 信息差和经验判断的价值被重新放大有个很实际的场景假设你是一个五到十年的后端团队里来了一个特别会用AI的新人。他能用半天时间生成一版功能完整、风格统一的服务端代码你能做什么来保住你在这张桌上的位置我的答案是你做的不是跟他比写代码快慢而是一起把那段代码拆到业务层面去复盘。比如“这个接口为什么需要保证幂等如果失败后重试的间隔怎么设计回滚时哪些数据要连动清理”这些问题是AI不会主动提出来的这是你区别于新人的信息差也是你职业护城河里最坚固的一块。这意味着经验没有贬值只是它的兑现方式变了。过去经验体现在你写的每一行代码里现在经验体现在你问的每一个问题里、你做的每一个判断里。AI处理信息的能力再强也不会自动给你这样的判断力——因为它没有经历过业务从0到1的痛苦没有面对过线上故障时的紧张也没有被凌晨三点的报警吵醒过。4.2 技术翻译能力连接业务和技术的那座桥还有一项技能的价值在同步上升把技术翻译成业务语言、再把业务需求转化成技术方案的那种反复横跳的能力。AI能直接根据接口文档生成代码但它不能替你去跟产品经理说清楚“这个需求为什么需要拆分五期来做”也不能替你在技术评审会上解释“为什么我们要优先处理读路径的延迟而不是写路径的吞吐量”。这些场景需要的是人对业务痛点的理解、对技术选型利弊的权衡、对团队节奏和风险容量的判断。这是最纯粹的“人味”也是跨部门协作中最值钱的能力。每一次你把“客户要一个报表”翻译成“我们需要建一个宽表并配置定时同步任务”你都在完成一次AI做不到的语义映射。5. 如果你还在焦虑我建议你现在就做这三件事5.1 把你最核心的业务流程画出来找一张白纸把你负责的最核心业务流程画出来从触发入口一直画到数据落库。然后试着用三句话把它讲清楚它解决了什么问题它为什么这样设计如果流量翻十倍它哪里会先扛不住这三句话你要是能在一分钟内讲清楚说明你对业务有真理解如果你发现讲着讲着卡住了或者需要翻代码才能回答那这就是你和AI之间真正的差距——AI比你更懂代码语法但你却不一定比AI更懂自己的业务。5.2 写一份属于你自己的架构决策记录选一个你负责过的系统试着写出它的架构决策记录把你当时为什么选择A而不是B的理由写下来。你会发现很多当时看起来“自然而然”的决定其实都有隐含的工程约束和业务权衡在背后。把这些理由清清楚楚地写下来强迫自己把每个决策都变成可表达、可辩护、可传承的知识。这份文档就是你的“个人护城河说明书”。它比代码更有价值因为代码可以被AI重新生成但决策背后的思考过程是你的独家资产。5.3 找一段AI生成的代码认认真真地审查一遍别把AI代码当标准答案把它当成一个“很努力的初级工程师”交上来的代码。从头到尾过一遍边界条件有没有处理异常路径会不会造成数据不一致掉线重试的机制合理吗日志够不够排查问题用你会惊讶地发现AI代码里能挑出来的问题远比你想象中多。不是因为AI差而是因为它没有你的业务上下文也没有你对线上环境的敬畏心。你每挑出并补上一个问题就完成了一次“人机协同”的正确示范——AI负责生成你负责让它变可靠。我个人体会是这三件事做完你对“程序员价值”的理解会发生根本变化。你不会再焦虑AI会取代你因为你已经看到了自己的价值根本不在代码里。写在最后我一直在调整自己在团队里的定位。以前别人提到我可能是“那个写状态机很严谨的人”我希望以后别人提到我是“那个能指出系统演进方向的人”。这中间差的不是代码量是判断力和视野。AI取代的不是程序员它正在取代的是“只会写代码的程序员”。真正稀缺的是你对业务的理解、你在复杂系统里做判断的能力、你敢为决策负责的态度以及你反复横跳于技术与业务之间的那种能力。AI可以把这些都变得更高效但它不会替你拥有。写代码的时代正在过去但思考的时代才刚刚开始。