1. 能力坐标系从“写代码的执行者”变成“定义问题的决策者”先说结论当 AI 能自动生成代码、自动修 bug、自动做测试的时候程序员最核心的竞争力已经从“把需求变成代码”这一层整体上移到了“确认要做什么、为什么做、做到什么程度、怎么验证做对了”这一层。我用一个最常见的场景来说明这个转变。以前接到一个需求第一反应是查文档、写接口、调样式花 80% 的精力在“翻译”——把产品语言翻译成技术方案。现在不一样了AI 工具能在几分钟之内出第一版代码真正的问题变成了这个需求本身成不成立业务逻辑里有没有隐含的坑数据流和权限边界是否清晰性能瓶颈会出现在哪里这些问题如果不先想清楚AI 生成的代码再快也是在错误的地基上盖楼。很多朋友担心被 AI 取代但其实观察一下身边真实的开发场景就能发现被取代的不是程序员而是“只会照着需求说明书把代码敲出来”的那层动作。会提问、会拆解、会验证、会做技术决策的人反而因为 AI 的辅助而变得更值钱——因为同样的时间他们能交付的价值比原来翻了好几倍。所以这个问题的答案我的看法很明确程序员的能力应该体现在四个方向——定义问题的能力、判断取舍的能力、审查纠错的能力、以及把 AI 输出变成可靠系统的工程能力。下面一个一个拆开讲。2. 第一层能力把模糊需求变成精确技术命题这一层最容易被低估但也最致命。AI 再强你给它的输入是模糊的它回给你的就是一堆看似合理但方向错误的东西。做过几年开发的人应该都有体会大部分项目事故根源不在编码而在需求理解偏差。2.1 你能问出什么样的题决定了 AI 能给出什么样的解举个实际例子。某公司内部要做一个人力资源报表系统业务方最初的需求描述是“把考勤异常数据展示出来方便 hr 查看。”如果直接把这句话丢给 AI生成出来的大概率是一个简单的表格页面列出行、日期、异常原因。但一个经验丰富的程序员会先追问几个关键问题“考勤异常”的判断标准是什么迟到几分钟算异常跨天排班怎么处理数据量级多大几千条还是几百万条要不要分页、聚合、缓存谁可以看哪些人的数据部门主管能不能看全公司“查看”是只读还是要支持导出、批注、标记处理状态这四个问题问完之后技术命题就从“做一个表格页面”变成了“设计一个支持多角色权限、包含数据聚合与导出能力、能应对百万级数据查询的报表模块”。你会发现前后两者的复杂度完全不是一个量级。这就是我说的“定义问题”的能力。AI 生成的代码质量高度依赖你输入信息的质量和结构化程度。你喂给它“我要一个考勤异常列表”它给你 200 行代码你喂给它“我要一个支持多租户隔离、含数据脱敏、需要 3 秒内完成聚合查询的报表服务”它给你的就是完全另一套架构。2.2 业务逻辑的隐藏假设AI 是不会主动问你的再往深一层说。很多业务逻辑里藏着“隐含假设”这些假设如果不说清楚AI 是不可能替你识别出来的。举一个我和同事真实踩过的坑当时做一个订单系统改造需求描述很简单——“对已取消订单支持重新下单”。看起来人畜无害对吧但往细了想这里有一堆隐藏问题“已取消”包含哪些取消渠道用户主动取消、超时系统自动取消、客服后台取消这三种状态的订单重新下单逻辑是一样的吗重新下单后原订单的优惠券、满减、积分抵扣怎么处理退回还是作废库存扣减的时点怎么定重新下单时是先锁库存再支付还是支付成功才扣减原订单的支付渠道、发票信息要不要继承还是全部重新录入这些问题AI 一个都不会主动问你。如果你自己没想清楚直接把“支持重新下单”扔给 AI 实现生成的逻辑一定会有漏洞。等线上出问题的时候排查成本远比写代码成本高。所以我现在带新人的时候一定会讲写代码之前先把你脑海里所有“这还用问吗”的问题全部列出来自己答一遍。答不上来的去问产品、问业务、问上下游。这些问题才是程序员能力最直接的体现。2.3 把大问题拆成可验证的小粒度子任务问题定义清楚之后下一步是拆解。AI 擅长处理“明确的小任务”但它对“宏大且边界模糊的系统”很容易失控。一个好的程序员会把一个看似庞大的系统拆成几十个相互独立、边界清晰、可单独验证的小模块。这个拆解能力有多重要我打个比方。你要装修一套房子你找的施工队再厉害也得先有设计图纸。图纸上要标清楚哪里是承重墙、哪里走水电、哪里留插座。AI 就像是施工队图纸画得越细施工越不会跑偏。反过来你直接说“帮我装修一套三室一厅”施工队也能干但干成什么样全凭猜。实际开发中拆解的粒度怎么控制我的经验是有三条标准每个子任务必须有明确的完成定义。什么叫“完成”接口跑通、数据符合预期、错误处理覆盖核心场景——这些能写出来才算拆解完成。子任务之间尽可能减少隐性依赖。A 模块需要 B 模块的数据接口定义要提前约定清楚不要让 AI 自由发挥。每个子任务可以独立测试。测试成本越低你对系统质量的掌控就越强。把这三条做到位再配合 AI 去写具体代码你会发现整个开发节奏变得非常可控。你不再是“每行代码都要看”而是“每个关键节点的完成定义都要盯”。3. 第二层能力技术判断力与“做减法”的决策能力AI 给的方案往往不是错的而是“堆料”。它倾向于把各种技术手段都堆上去因为 AI 对上下文的理解是概率性的它不能真正理解“这个功能三年内根本用不到”这种业务语境的现实约束。这时候程序员的判断力就体现出来了。3.1 识别需求里的伪复杂度做技术减法我刚工作那会儿接手过一个老项目里面有相当复杂的配置系统支持几十个参数动态切换。我一开始以为业务真的这么复杂后来翻了两周代码才发现其中 80% 的参数从上线到现在三年从来没有被不同值跑过。这些参数对应的逻辑就是典型的“伪复杂度”——写了但从来没人用却把系统撑得臃肿无比。AI 时代“伪复杂度”只会更多不会更少。因为你给 AI 描述需求的时候它会倾向于把所有可能的情况都考虑进去生成一个“面面俱到”的方案。你要什么它给什么但它不会判断哪些是你短期要的、哪些是长期才需要的、哪些根本不需要。这时候程序员的职责就是做减法。我一般在设计阶段会强制自己做一个动作把需求清单里每一项拿出来问三个问题——这个功能这个季度用得到吗这个功能是为了解决某个真实用户场景还是为了“架构完备”如果不做会有什么实际损失这三个问题滤下来至少能砍掉三分之一的需求。砍完之后你再让 AI 帮你实现生成出来的系统会清爽得多。这个“敢砍需求”的魄力和判断力AI 是没有的。3.2 技术选型不是看谁的文档好看而是看边界在哪里技术选型这个老话题在 AI 辅助开发的语境下有了新的侧重点。以前选框架比的是文档全不全、社区活跃度高不高、生态丰富不丰富。现在的选型逻辑多了一个维度这个技术方案的“失误模式”你是否可控。什么意思呢就是当 AI 基于某个框架生成代码时它可能会在某些边界场景产生错误输出你对这个框架越熟悉你越能在早期识别出这些错误。反过来如果你只是听 AI 推荐了一个“热门框架”你自己完全没接触过那么 AI 生成的那些隐性问题你根本看不出来。所以我现在带团队做技术选型的时候定的原则是能用同事熟悉的技术就不要引入新框架如果能用一个简单方案解决就不要上微服务、消息队列、缓存那一套组合拳。技术栈每多一层排查问题的半径就扩大一圈。AI 可以把每一层的代码都写得像模像样但层与层之间交互出现的问题AI 是看不见的。有一次做数据同步服务最开始的方案用了两级缓存加分布锁加异步队列。听着很高级但实际线上数据量一天只有几万条并发峰值不过几十。后来我把缓存去掉、锁去掉、队列也去掉直接一个定时脚本加一个幂等校验代码量少了一半出问题的概率直接归零。这就是典型的“过度设计”而判断力就是识别出这种过度设计敢于拍板做减法。3.3 取舍透明化把“为什么这么选”写成文档比代码更重要说到做决策我特别想强调一点在 AI 辅助开发的时代代码的“解释”价值正在下降代码的“决策逻辑”价值正在上升。什么意思以前的代码注释写的都是“这一段是干嘛的”。但现在 AI 能生成代码也会生成注释这段代码本身做了什么AI 已经解释得很清楚了。真正缺失的是“为什么这么设计”。为什么这里用异步不用同步为什么这个字段加到订单表而不是单独建一张表为什么这个功能本次迭代不做这些决策逻辑如果不写成文档过两个月连你自己都想不起来。更麻烦的是AI 没有记忆你下次用 AI 改这个模块的时候它会基于代码现状重新生成如果现状里没有记录当初的取舍考量AI 就可能往完全不同的方向改制造大量无谓的重构。所以我的习惯是每次做完技术决策单独维护一个“决策日志”不需要长四五句话就够。记录这么几个维度当时面临的选择有哪些为什么选了当前方案这个方案的已知缺点是什么在什么条件下我们需要重新审视这个决策这个日志就是程序员的“思考外挂”。它把你的判断力固化下来AI 能学习代码库但学不到这些决策逻辑。这玩意儿才是你多年经验沉淀后真正值钱的部分。4. 第三层能力对 AI 输出的审查、纠错与信任管理很多朋友现在的日常是AI 写代码人复制粘贴跑通了就算完事。这种“信任式使用”在最开始确实效率很高但时间久了问题就会一点一点累积直到某一天集中爆发。我的观点是AI 生成的代码可以快速用但你必须建立一套自己的“审查方法论”把 AI 输出的可信度控制在你能掌控的范围内。先说一个我自己的教训。有一次我需要写一个解析日志的正则表达式日志格式比较特殊嵌套了多层引号和转义字符。我懒得自己做状态机直接让 AI 写了一个正则。跑测试样例全都通过我就上线了。结果上线第三天线上一条包含特殊 Unicode 字符的日志直接让整个正则进入灾难性的回溯CPU 被打满了将近十分钟。那十分钟里所有请求全部卡死。从那以后我学到一个原则AI 生成的代码尤其是涉及性能、并发、安全、数据一致性的部分绝不能只看功能正确性还必须审查它的边界行为和复杂度。功能跑通只是最表面的那一层。4.1 建立自己的 Code Review 清单不看“对不对”看“稳不稳”我自己现在审 AI 生成的代码有一套固定的检查清单。不一定适合所有人但可以参考第一条看错误处理。AI 生成的代码 happy path 往往没问题但异常分支处理得普遍很潦草。网络超时、接口返回格式异常、数据库连接中断、并发状态下重复提交——这些场景 AI 经常会漏掉或者处理得过糙。我审查时会把 AI 生成的代码里所有except、error、throw相关的位置单独挑出来看这些分支是不是真的覆盖了真实场景而不只是覆盖了“AI 想象中的异常”。第二条看数据校验边界。AI 对输入数据的“信任度”太高了。你让它写一个接口它默认调用方会乖乖传符合约束的参数。但真实系统里你会收到空字符串、超长文本、NaN、负数、带表情符号的字符串、未来时间戳——大概率都会出现。你需要在所有 AI 生成的代码入口处检查有没有给数据做约束校验。没有的话就得自己补上。第三条看幂等性。现在几乎所有系统都要考虑重试机制那 AI 生成的代码是不是天然幂等呢大概率不是。比如一个创建订单的接口AI 生成的是直接 INSERT 一条记录没有检查请求头里的幂等标识那一旦网络抖动触发重试用户就会看到两笔订单。审查 AI 代码时凡是涉及写入操作的位置都要问一句如果这个请求重复执行两次系统还正确吗这三条是我目前审查 AI 输出时最常用的过滤器。你会发现它们都不涉及深奥的算法或者复杂的架构就是非常朴素的工程经验。但就是这些朴素经验AI 暂时还不具备——它没有在真实系统里经历过大半夜被报警电话叫醒的痛所以它不会天然地对异常场景保持警觉。4.2 只信你验证过的建立自动化回归防线我比较反对的一种用法是“让 AI 直接改生产代码”。不是说 AI 不能改而是改完之后你没有快速验证的手段等于裸奔。如果你接手的是一个没有自动化测试、没有 CI/CD 的老项目用 AI 之前你要做的最紧急的事不是让 AI “帮我重构”而是先把手动验证的路径沉淀成自动化用例。我自己有个原则叫“先扎篱笆再放羊”。什么意思就是把系统里最关键的业务路径用自动化测试先锁住锁得死死的然后再让 AI 做修改。如果 AI 改坏了测试会报警你能在第一时间知道。如果没有这层保护AI 改坏了系统你往往要等几周以后业务方来投诉才发现到那个时候排查成本已经不可控了。具体做法上我的经验是优先给这三类逻辑写回归测试核心业务流程。比如下单、支付回调、库存扣减、积分入账这类逻辑一旦出错经济损失和用户信任度损失都是直接的。老系统里那些“改了容易炸”的地方。比如那种被十几个系统依赖的公共函数、状态机转换、复杂 SQL 拼接逻辑。外部接口调用。AI 在改这部分逻辑时很容易把超时参数弄乱、把重试机制去掉、把 header 里的认证信息丢掉。用 mockserver 把接口行为固定下来反复回归比较省心。这套防线搭起来以后AI 就成了一个非常趁手的工具——你信任它但你的信任是建立在验证体系之上的不是建立在“AI 看起来挺聪明”之上的。4.3 学会“反向验证”让 AI 解释它的方案而不是让你解释你的需求我发现很多朋友和 AI 协作的方式是单向的我提需求AI 给方案。方案如果看起来合理就直接用了。但真正高效的协作是双向的你要学会对 AI 生成的内容做反向提问。举个实际例子。我让 AI 做一个数据导出的功能AI 生成的方案是“启动导出任务 → 写入临时表 → 生成 CSV → 上传对象存储 → 推送下载链接”。看起来没什么问题但我会反问 AI如果生成 CSV 的过程中用户再次点击导出是允许并行生成两个文件还是需要把上一次的任务取消如果临时表写入一半失败了已经生成的文件怎么处理下载链接有效期设置多久过期后是否重新生成这些问题 AI 大部分时候能给出答案但关键在于——你不问它不答。它默认你的需求里没有这些约束于是它就按最简单的逻辑实现了。等上线后用户连续点了三次导出然后下载到三个内容不一致的文件这就是事故。所以我的一个核心习惯是拿到 AI 的方案不着急动手先花五分钟做反向验证把方案里所有不确定的分支全部问一遍。问的过程本质上就是在做系统设计的高层推演只不过把之前“对着问题冥思苦想”的过程变成了“和思维模型对话”的过程。这种互动模式的效率比一个人闷头思考高很多。5. 第四层能力架构思维与全局掌控力讲完日常开发中的实操层能力再往上一层架构能力。这一层放在最后讲是因为它最抽象但也是 AI 最难替代的部分。AI 能生成模块级代码能优化函数性能能在你给出的边界条件内实现功能但让 AI 去设计一个完整系统的长期演进路径我的体会是——距离还很远。5.1 架构师的工作不是画图而是制定“约束优先级”很多新手对架构设计有个误解觉得架构就是画那种漂亮的模块图、箭头图、分层图。其实真正的架构工作是在各种约束条件之间做权衡决策。比如你要做一个面向几十万用户的实时消息推送系统。摆在面前的约束有哪些响应时间不能超过 500 毫秒、推送可靠性需要在极端网络条件下保持 99.9%、服务端成本有上限、团队只有三个人、三个月内要上线。这些约束互相冲突——可靠性要求高了成本一定上去实时性要求高了可靠性实现难度就大团队人少复杂方案就不可行。架构师干的事情就是把这些约束排列优先级然后基于优先级去设计方案。这种情况下AI 能做什么呢它可以帮你算不同方案的性能指标可以帮你生成不同架构的代码骨架甚至可以帮你把你定的约束转成设计文档。但它无法替代你做那个最关键的决定这次到底优先保成本还是优先保可靠性。这种决策背后的依据一半来自业务理解一半来自工程经验。比如你判断这个产品阶段的核心目标是验证市场而不是追求完美体验那合理答案就是先保成本用最朴素的方案上线如果你判断这个产品的商业模式高度依赖用户信任那可靠性就是第一优先级不能省的东西不能省。5.2 技术债管理AI 会加速技术债累计你得会踩刹车这是我在实际工作中感受非常明显的一点。AI 写代码的速度非常快如果一个团队长期用 AI 但不做架构治理技术债的累积速度会比以前快好几倍。原因很简单。以前一个人一天写三百行代码写之前会反复想设计、看周边代码的风格、考虑复用性和一致性。现在 AI 一次生成三百行直接采用了和你项目现有架构完全不同的实现方式、不同的命名习惯、不同的错误处理逻辑。一个人一天可以这样生成几千行代码要不了两周整个代码库的风格就会分裂成“好几拨人写的”。更要命的是AI 可以在不改变外部行为的前提下用完全不同的内部实现去改一段代码这会让代码库的隐性依赖关系变得模糊。以前跨模块调用走的是明确的接口代码里一眼能看出来AI 生成的代码可能直接通过全局变量、隐式共享对象、甚至 URL 参数来传递状态你看到代码的时候只觉得“有点奇怪”但很难快速定位问题。所以AI 辅助开发想走得远必须有配套的技术债治理节奏。我现在的做法是每周固定留半天时间做宏观审查不是 review 每个函数对不对而是看整个代码库的整体结构是否还健康——模块划分是否依然清晰、依赖方向是否仍然正确、有没有出现“上帝类”或者“隐式状态”。如果发现偏差及时修正不要等到债台高筑再动手。5.3 跨领域知识拼接AI 的“单点优势”与你的“全局视野”最后说一个特别容易被忽略的能力跨领域知识拼接。AI 在某些单点技术上的表现确实已经非常出色。比如你要一个 HTTP 客户端的最佳写法、一个正则表达式、一个排序算法的优化版本AI 张口就来比大多数人自己写的都要好。但真实世界的系统级问题往往是跨领域的——你要做一个在线协同编辑功能涉及 WebSocket 通信、操作冲突解决CRDT 或 OT 算法、权限状态管理、数据持久化策略、前端渲染性能优化跨了好几个专业方向。AI 可以帮你写 WebSocket 服务端、可以帮你实现 CRDT 算法、可以帮你优化前端渲染但把这些东西整合成一个体验顺滑、扩展性合理、故障可控的完整系统需要的是跨领域理解和全局权衡。这种跨领域能力是怎么炼成的没什么捷径就是多做不同类型的项目多和不同分工的人协作。我自己写后端出身后来被迫去搞前端、搞运维、搞数据分析当时觉得挺烦的现在回头看正是这些跨界经验让我在做架构决策时能想到别人想不到的风险点。比如一个简单的文件上传功能前端同学可能只关注进度条后端同学只关注大文件处理但如果你两个方向都了解就会意识到还有 CORS、鉴权方式、断点续传协议兼容性、存储成本预估等一整套上下游问题。AI 时代单点技术能力可以被快速替代但这种跨领域拼接的能力恰恰是 AI 最难复制的东西。因为 AI 的知识是分布式的它可以在每个单点上给出合理回答但把这些单点串成一条完整的业务链路并且确保每个衔接点都逻辑自洽它还很吃力。6. 常见问题与实操心得这一篇真正落地的部分。聊几个我自己在实际工作中被问得最多的问题以及对应的处理思路。6.1 AI 写的代码风格和团队不一致要不要强制统一我的建议是不要一刀切强制统一而是定义“边界内的自由”。在模块级别AI 生成代码的内部实现风格可以适度宽容因为不影响系统的整体可维护性。但在接口级别、数据模型级别、错误处理约定级别必须强制统一。这些是系统的“骨架”骨架乱了肌肉长得再好也没用。具体的落地做法是在项目里放一个精简的“接口规范约定”内容包括命名规则、文件组织方式、错误返回格式、日志打印规范。每次让 AI 生成新模块之前先把这份规范贴进上下文要求 AI 严格遵守。多试几次AI 生成代码的风格偏差会明显减小。如果项目已经混乱了那就先把关键接口的规范立起来再逐步调整。6.2 AI 生成了一段完全看不懂的代码怎么办这里我有一个比较实用的判断标准如果一段 AI 生成的代码团队成员需要花费超过半小时才能理解它是干什么的那这段代码的直接价值大概率是负的。不要因为“它能跑”就放过它看不懂的代码等于潜在的事故现场。处理方法也很简单要求 AI 重构用更直白的方式实现。如果 AI 反复提供的方案你都看不懂那大概率是你对某个基础概念理解不够深这时候要做的不是硬啃代码而是退回去把涉及的基础知识补一补。别觉得丢人我也经常被 AI 写的精巧实现绕晕但绕完之后花点时间把思路理清楚反而进步更快。6.3 怎么避免 AI 生成代码中的“看着没问题但线上就挂”“看着没问题上线就挂”的深层次原因我总结下来有四类数据量比测试数据大几个数量级、并发场景触发竞态条件、外部依赖的极端行为没被处理、以及业务状态的异常组合。这四类问题的共同特点是你在测试阶段很难复现因为它们依赖的是真实环境里的不确定因素。避免方案有三个层次。第一层是审代码时带着那四类问题逐项自问。第二层是给系统加可观测性——日志、指标、链路追踪三件套配齐尤其是异常日志要打得足够详细。第三层是设计兜底机制——异步任务失败有重试、数据异常有告警、服务崩溃有熔断。有这三层保护即使 AI 代码犯了错你也来得及在用户感知之前修复。6.4 新手程序员还要不要刷题、学基础、啃源码我的看法很直接要而且比以前更重要。AI 可以把基础算法写好但你要能识别出它写得好不好这就需要你自己懂基础。就像你请了一个特别能干的助理如果你自己肚子里没有货你连助理干得好坏都判断不了更别提指导助理怎么改进。建议新手把刷题和啃源码当成“练内功”把 AI 当成“练招式”。内功决定你的上限招式决定你的效率。天天用 AI 生成代码但完全不理解底层原理短期内项目能跑遇到 AI 不擅长的边界场景就会卡壳。6.5 踩过的坑AI 生成配置的“隐形炸弹”最后分享一个特别典型的坑算是给大家提个醒。有一次我让 AI 帮忙生成部署配置它默认加了一个很常见的设置——把超时时间配置成了 30 秒。这个值本身没什么问题但这个模块实际依赖的下游接口正常响应就要 40 秒以上。这个配置上线后所有下游调用全部在 30 秒被切断那两天线上一直在报错排查了很久才发现是 AI 随手写的一个数字闯的祸。从那以后我养成了一个习惯AI 生成的所有配置类文件我会一个一个参数看不放过任何一个数字。尤其是超时时间、重试次数、线程池大小、队列容量、缓存过期时间这种“看起来常规”的参数这些数值没有一个可以“猜”出来全部必须和真实业务场景匹配。AI 不在乎你的下游响应要多长时间它只会给你一个在“普遍情况下”合理的默认值而这个普遍情况可能恰好和你的场景完全不符。6.6 关于协作心态把 AI 当成“高配实习生”而不是“全知顾问”这是我目前最推荐的心态模型。你带实习生是什么状态你会给他布置明确的任务你会给他划定边界你会检查他的产出你会在他犯错的时候告诉他哪里错了、为什么错。对待 AI 也是一样——你给它越明确的任务边界它犯错的概率越低你越频繁地检查它的产出你能产生的杠杆就越大。把 AI 当成全知顾问什么都问、什么都信任会让自己逐渐丧失思考的敏锐度这是我最担心的一种退化。一个程序员如果连续几个月只做“复制粘贴 AI 代码”这一种工作他的问题意识、边界感知、系统思考能力都会退化得很厉害。这个损失不是省下那点写代码时间能补回来的。反过来把 AI 当成实习生来用你的角色就变成了管理者你在持续地质疑它的产出你在提出更有挑战性的要求你在思考怎么把任务拆得更清晰、边界定得更准确。这个过程本身就是一种高强度的能力训练而且训练的全是 AI 时代最值钱的那几项技能。
1. 能力坐标系从“写代码的执行者”变成“定义问题的决策者”先说结论当 AI 能自动生成代码、自动修 bug、自动做测试的时候程序员最核心的竞争力已经从“把需求变成代码”这一层整体上移到了“确认要做什么、为什么做、做到什么程度、怎么验证做对了”这一层。我用一个最常见的场景来说明这个转变。以前接到一个需求第一反应是查文档、写接口、调样式花 80% 的精力在“翻译”——把产品语言翻译成技术方案。现在不一样了AI 工具能在几分钟之内出第一版代码真正的问题变成了这个需求本身成不成立业务逻辑里有没有隐含的坑数据流和权限边界是否清晰性能瓶颈会出现在哪里这些问题如果不先想清楚AI 生成的代码再快也是在错误的地基上盖楼。很多朋友担心被 AI 取代但其实观察一下身边真实的开发场景就能发现被取代的不是程序员而是“只会照着需求说明书把代码敲出来”的那层动作。会提问、会拆解、会验证、会做技术决策的人反而因为 AI 的辅助而变得更值钱——因为同样的时间他们能交付的价值比原来翻了好几倍。所以这个问题的答案我的看法很明确程序员的能力应该体现在四个方向——定义问题的能力、判断取舍的能力、审查纠错的能力、以及把 AI 输出变成可靠系统的工程能力。下面一个一个拆开讲。2. 第一层能力把模糊需求变成精确技术命题这一层最容易被低估但也最致命。AI 再强你给它的输入是模糊的它回给你的就是一堆看似合理但方向错误的东西。做过几年开发的人应该都有体会大部分项目事故根源不在编码而在需求理解偏差。2.1 你能问出什么样的题决定了 AI 能给出什么样的解举个实际例子。某公司内部要做一个人力资源报表系统业务方最初的需求描述是“把考勤异常数据展示出来方便 hr 查看。”如果直接把这句话丢给 AI生成出来的大概率是一个简单的表格页面列出行、日期、异常原因。但一个经验丰富的程序员会先追问几个关键问题“考勤异常”的判断标准是什么迟到几分钟算异常跨天排班怎么处理数据量级多大几千条还是几百万条要不要分页、聚合、缓存谁可以看哪些人的数据部门主管能不能看全公司“查看”是只读还是要支持导出、批注、标记处理状态这四个问题问完之后技术命题就从“做一个表格页面”变成了“设计一个支持多角色权限、包含数据聚合与导出能力、能应对百万级数据查询的报表模块”。你会发现前后两者的复杂度完全不是一个量级。这就是我说的“定义问题”的能力。AI 生成的代码质量高度依赖你输入信息的质量和结构化程度。你喂给它“我要一个考勤异常列表”它给你 200 行代码你喂给它“我要一个支持多租户隔离、含数据脱敏、需要 3 秒内完成聚合查询的报表服务”它给你的就是完全另一套架构。2.2 业务逻辑的隐藏假设AI 是不会主动问你的再往深一层说。很多业务逻辑里藏着“隐含假设”这些假设如果不说清楚AI 是不可能替你识别出来的。举一个我和同事真实踩过的坑当时做一个订单系统改造需求描述很简单——“对已取消订单支持重新下单”。看起来人畜无害对吧但往细了想这里有一堆隐藏问题“已取消”包含哪些取消渠道用户主动取消、超时系统自动取消、客服后台取消这三种状态的订单重新下单逻辑是一样的吗重新下单后原订单的优惠券、满减、积分抵扣怎么处理退回还是作废库存扣减的时点怎么定重新下单时是先锁库存再支付还是支付成功才扣减原订单的支付渠道、发票信息要不要继承还是全部重新录入这些问题AI 一个都不会主动问你。如果你自己没想清楚直接把“支持重新下单”扔给 AI 实现生成的逻辑一定会有漏洞。等线上出问题的时候排查成本远比写代码成本高。所以我现在带新人的时候一定会讲写代码之前先把你脑海里所有“这还用问吗”的问题全部列出来自己答一遍。答不上来的去问产品、问业务、问上下游。这些问题才是程序员能力最直接的体现。2.3 把大问题拆成可验证的小粒度子任务问题定义清楚之后下一步是拆解。AI 擅长处理“明确的小任务”但它对“宏大且边界模糊的系统”很容易失控。一个好的程序员会把一个看似庞大的系统拆成几十个相互独立、边界清晰、可单独验证的小模块。这个拆解能力有多重要我打个比方。你要装修一套房子你找的施工队再厉害也得先有设计图纸。图纸上要标清楚哪里是承重墙、哪里走水电、哪里留插座。AI 就像是施工队图纸画得越细施工越不会跑偏。反过来你直接说“帮我装修一套三室一厅”施工队也能干但干成什么样全凭猜。实际开发中拆解的粒度怎么控制我的经验是有三条标准每个子任务必须有明确的完成定义。什么叫“完成”接口跑通、数据符合预期、错误处理覆盖核心场景——这些能写出来才算拆解完成。子任务之间尽可能减少隐性依赖。A 模块需要 B 模块的数据接口定义要提前约定清楚不要让 AI 自由发挥。每个子任务可以独立测试。测试成本越低你对系统质量的掌控就越强。把这三条做到位再配合 AI 去写具体代码你会发现整个开发节奏变得非常可控。你不再是“每行代码都要看”而是“每个关键节点的完成定义都要盯”。3. 第二层能力技术判断力与“做减法”的决策能力AI 给的方案往往不是错的而是“堆料”。它倾向于把各种技术手段都堆上去因为 AI 对上下文的理解是概率性的它不能真正理解“这个功能三年内根本用不到”这种业务语境的现实约束。这时候程序员的判断力就体现出来了。3.1 识别需求里的伪复杂度做技术减法我刚工作那会儿接手过一个老项目里面有相当复杂的配置系统支持几十个参数动态切换。我一开始以为业务真的这么复杂后来翻了两周代码才发现其中 80% 的参数从上线到现在三年从来没有被不同值跑过。这些参数对应的逻辑就是典型的“伪复杂度”——写了但从来没人用却把系统撑得臃肿无比。AI 时代“伪复杂度”只会更多不会更少。因为你给 AI 描述需求的时候它会倾向于把所有可能的情况都考虑进去生成一个“面面俱到”的方案。你要什么它给什么但它不会判断哪些是你短期要的、哪些是长期才需要的、哪些根本不需要。这时候程序员的职责就是做减法。我一般在设计阶段会强制自己做一个动作把需求清单里每一项拿出来问三个问题——这个功能这个季度用得到吗这个功能是为了解决某个真实用户场景还是为了“架构完备”如果不做会有什么实际损失这三个问题滤下来至少能砍掉三分之一的需求。砍完之后你再让 AI 帮你实现生成出来的系统会清爽得多。这个“敢砍需求”的魄力和判断力AI 是没有的。3.2 技术选型不是看谁的文档好看而是看边界在哪里技术选型这个老话题在 AI 辅助开发的语境下有了新的侧重点。以前选框架比的是文档全不全、社区活跃度高不高、生态丰富不丰富。现在的选型逻辑多了一个维度这个技术方案的“失误模式”你是否可控。什么意思呢就是当 AI 基于某个框架生成代码时它可能会在某些边界场景产生错误输出你对这个框架越熟悉你越能在早期识别出这些错误。反过来如果你只是听 AI 推荐了一个“热门框架”你自己完全没接触过那么 AI 生成的那些隐性问题你根本看不出来。所以我现在带团队做技术选型的时候定的原则是能用同事熟悉的技术就不要引入新框架如果能用一个简单方案解决就不要上微服务、消息队列、缓存那一套组合拳。技术栈每多一层排查问题的半径就扩大一圈。AI 可以把每一层的代码都写得像模像样但层与层之间交互出现的问题AI 是看不见的。有一次做数据同步服务最开始的方案用了两级缓存加分布锁加异步队列。听着很高级但实际线上数据量一天只有几万条并发峰值不过几十。后来我把缓存去掉、锁去掉、队列也去掉直接一个定时脚本加一个幂等校验代码量少了一半出问题的概率直接归零。这就是典型的“过度设计”而判断力就是识别出这种过度设计敢于拍板做减法。3.3 取舍透明化把“为什么这么选”写成文档比代码更重要说到做决策我特别想强调一点在 AI 辅助开发的时代代码的“解释”价值正在下降代码的“决策逻辑”价值正在上升。什么意思以前的代码注释写的都是“这一段是干嘛的”。但现在 AI 能生成代码也会生成注释这段代码本身做了什么AI 已经解释得很清楚了。真正缺失的是“为什么这么设计”。为什么这里用异步不用同步为什么这个字段加到订单表而不是单独建一张表为什么这个功能本次迭代不做这些决策逻辑如果不写成文档过两个月连你自己都想不起来。更麻烦的是AI 没有记忆你下次用 AI 改这个模块的时候它会基于代码现状重新生成如果现状里没有记录当初的取舍考量AI 就可能往完全不同的方向改制造大量无谓的重构。所以我的习惯是每次做完技术决策单独维护一个“决策日志”不需要长四五句话就够。记录这么几个维度当时面临的选择有哪些为什么选了当前方案这个方案的已知缺点是什么在什么条件下我们需要重新审视这个决策这个日志就是程序员的“思考外挂”。它把你的判断力固化下来AI 能学习代码库但学不到这些决策逻辑。这玩意儿才是你多年经验沉淀后真正值钱的部分。4. 第三层能力对 AI 输出的审查、纠错与信任管理很多朋友现在的日常是AI 写代码人复制粘贴跑通了就算完事。这种“信任式使用”在最开始确实效率很高但时间久了问题就会一点一点累积直到某一天集中爆发。我的观点是AI 生成的代码可以快速用但你必须建立一套自己的“审查方法论”把 AI 输出的可信度控制在你能掌控的范围内。先说一个我自己的教训。有一次我需要写一个解析日志的正则表达式日志格式比较特殊嵌套了多层引号和转义字符。我懒得自己做状态机直接让 AI 写了一个正则。跑测试样例全都通过我就上线了。结果上线第三天线上一条包含特殊 Unicode 字符的日志直接让整个正则进入灾难性的回溯CPU 被打满了将近十分钟。那十分钟里所有请求全部卡死。从那以后我学到一个原则AI 生成的代码尤其是涉及性能、并发、安全、数据一致性的部分绝不能只看功能正确性还必须审查它的边界行为和复杂度。功能跑通只是最表面的那一层。4.1 建立自己的 Code Review 清单不看“对不对”看“稳不稳”我自己现在审 AI 生成的代码有一套固定的检查清单。不一定适合所有人但可以参考第一条看错误处理。AI 生成的代码 happy path 往往没问题但异常分支处理得普遍很潦草。网络超时、接口返回格式异常、数据库连接中断、并发状态下重复提交——这些场景 AI 经常会漏掉或者处理得过糙。我审查时会把 AI 生成的代码里所有except、error、throw相关的位置单独挑出来看这些分支是不是真的覆盖了真实场景而不只是覆盖了“AI 想象中的异常”。第二条看数据校验边界。AI 对输入数据的“信任度”太高了。你让它写一个接口它默认调用方会乖乖传符合约束的参数。但真实系统里你会收到空字符串、超长文本、NaN、负数、带表情符号的字符串、未来时间戳——大概率都会出现。你需要在所有 AI 生成的代码入口处检查有没有给数据做约束校验。没有的话就得自己补上。第三条看幂等性。现在几乎所有系统都要考虑重试机制那 AI 生成的代码是不是天然幂等呢大概率不是。比如一个创建订单的接口AI 生成的是直接 INSERT 一条记录没有检查请求头里的幂等标识那一旦网络抖动触发重试用户就会看到两笔订单。审查 AI 代码时凡是涉及写入操作的位置都要问一句如果这个请求重复执行两次系统还正确吗这三条是我目前审查 AI 输出时最常用的过滤器。你会发现它们都不涉及深奥的算法或者复杂的架构就是非常朴素的工程经验。但就是这些朴素经验AI 暂时还不具备——它没有在真实系统里经历过大半夜被报警电话叫醒的痛所以它不会天然地对异常场景保持警觉。4.2 只信你验证过的建立自动化回归防线我比较反对的一种用法是“让 AI 直接改生产代码”。不是说 AI 不能改而是改完之后你没有快速验证的手段等于裸奔。如果你接手的是一个没有自动化测试、没有 CI/CD 的老项目用 AI 之前你要做的最紧急的事不是让 AI “帮我重构”而是先把手动验证的路径沉淀成自动化用例。我自己有个原则叫“先扎篱笆再放羊”。什么意思就是把系统里最关键的业务路径用自动化测试先锁住锁得死死的然后再让 AI 做修改。如果 AI 改坏了测试会报警你能在第一时间知道。如果没有这层保护AI 改坏了系统你往往要等几周以后业务方来投诉才发现到那个时候排查成本已经不可控了。具体做法上我的经验是优先给这三类逻辑写回归测试核心业务流程。比如下单、支付回调、库存扣减、积分入账这类逻辑一旦出错经济损失和用户信任度损失都是直接的。老系统里那些“改了容易炸”的地方。比如那种被十几个系统依赖的公共函数、状态机转换、复杂 SQL 拼接逻辑。外部接口调用。AI 在改这部分逻辑时很容易把超时参数弄乱、把重试机制去掉、把 header 里的认证信息丢掉。用 mockserver 把接口行为固定下来反复回归比较省心。这套防线搭起来以后AI 就成了一个非常趁手的工具——你信任它但你的信任是建立在验证体系之上的不是建立在“AI 看起来挺聪明”之上的。4.3 学会“反向验证”让 AI 解释它的方案而不是让你解释你的需求我发现很多朋友和 AI 协作的方式是单向的我提需求AI 给方案。方案如果看起来合理就直接用了。但真正高效的协作是双向的你要学会对 AI 生成的内容做反向提问。举个实际例子。我让 AI 做一个数据导出的功能AI 生成的方案是“启动导出任务 → 写入临时表 → 生成 CSV → 上传对象存储 → 推送下载链接”。看起来没什么问题但我会反问 AI如果生成 CSV 的过程中用户再次点击导出是允许并行生成两个文件还是需要把上一次的任务取消如果临时表写入一半失败了已经生成的文件怎么处理下载链接有效期设置多久过期后是否重新生成这些问题 AI 大部分时候能给出答案但关键在于——你不问它不答。它默认你的需求里没有这些约束于是它就按最简单的逻辑实现了。等上线后用户连续点了三次导出然后下载到三个内容不一致的文件这就是事故。所以我的一个核心习惯是拿到 AI 的方案不着急动手先花五分钟做反向验证把方案里所有不确定的分支全部问一遍。问的过程本质上就是在做系统设计的高层推演只不过把之前“对着问题冥思苦想”的过程变成了“和思维模型对话”的过程。这种互动模式的效率比一个人闷头思考高很多。5. 第四层能力架构思维与全局掌控力讲完日常开发中的实操层能力再往上一层架构能力。这一层放在最后讲是因为它最抽象但也是 AI 最难替代的部分。AI 能生成模块级代码能优化函数性能能在你给出的边界条件内实现功能但让 AI 去设计一个完整系统的长期演进路径我的体会是——距离还很远。5.1 架构师的工作不是画图而是制定“约束优先级”很多新手对架构设计有个误解觉得架构就是画那种漂亮的模块图、箭头图、分层图。其实真正的架构工作是在各种约束条件之间做权衡决策。比如你要做一个面向几十万用户的实时消息推送系统。摆在面前的约束有哪些响应时间不能超过 500 毫秒、推送可靠性需要在极端网络条件下保持 99.9%、服务端成本有上限、团队只有三个人、三个月内要上线。这些约束互相冲突——可靠性要求高了成本一定上去实时性要求高了可靠性实现难度就大团队人少复杂方案就不可行。架构师干的事情就是把这些约束排列优先级然后基于优先级去设计方案。这种情况下AI 能做什么呢它可以帮你算不同方案的性能指标可以帮你生成不同架构的代码骨架甚至可以帮你把你定的约束转成设计文档。但它无法替代你做那个最关键的决定这次到底优先保成本还是优先保可靠性。这种决策背后的依据一半来自业务理解一半来自工程经验。比如你判断这个产品阶段的核心目标是验证市场而不是追求完美体验那合理答案就是先保成本用最朴素的方案上线如果你判断这个产品的商业模式高度依赖用户信任那可靠性就是第一优先级不能省的东西不能省。5.2 技术债管理AI 会加速技术债累计你得会踩刹车这是我在实际工作中感受非常明显的一点。AI 写代码的速度非常快如果一个团队长期用 AI 但不做架构治理技术债的累积速度会比以前快好几倍。原因很简单。以前一个人一天写三百行代码写之前会反复想设计、看周边代码的风格、考虑复用性和一致性。现在 AI 一次生成三百行直接采用了和你项目现有架构完全不同的实现方式、不同的命名习惯、不同的错误处理逻辑。一个人一天可以这样生成几千行代码要不了两周整个代码库的风格就会分裂成“好几拨人写的”。更要命的是AI 可以在不改变外部行为的前提下用完全不同的内部实现去改一段代码这会让代码库的隐性依赖关系变得模糊。以前跨模块调用走的是明确的接口代码里一眼能看出来AI 生成的代码可能直接通过全局变量、隐式共享对象、甚至 URL 参数来传递状态你看到代码的时候只觉得“有点奇怪”但很难快速定位问题。所以AI 辅助开发想走得远必须有配套的技术债治理节奏。我现在的做法是每周固定留半天时间做宏观审查不是 review 每个函数对不对而是看整个代码库的整体结构是否还健康——模块划分是否依然清晰、依赖方向是否仍然正确、有没有出现“上帝类”或者“隐式状态”。如果发现偏差及时修正不要等到债台高筑再动手。5.3 跨领域知识拼接AI 的“单点优势”与你的“全局视野”最后说一个特别容易被忽略的能力跨领域知识拼接。AI 在某些单点技术上的表现确实已经非常出色。比如你要一个 HTTP 客户端的最佳写法、一个正则表达式、一个排序算法的优化版本AI 张口就来比大多数人自己写的都要好。但真实世界的系统级问题往往是跨领域的——你要做一个在线协同编辑功能涉及 WebSocket 通信、操作冲突解决CRDT 或 OT 算法、权限状态管理、数据持久化策略、前端渲染性能优化跨了好几个专业方向。AI 可以帮你写 WebSocket 服务端、可以帮你实现 CRDT 算法、可以帮你优化前端渲染但把这些东西整合成一个体验顺滑、扩展性合理、故障可控的完整系统需要的是跨领域理解和全局权衡。这种跨领域能力是怎么炼成的没什么捷径就是多做不同类型的项目多和不同分工的人协作。我自己写后端出身后来被迫去搞前端、搞运维、搞数据分析当时觉得挺烦的现在回头看正是这些跨界经验让我在做架构决策时能想到别人想不到的风险点。比如一个简单的文件上传功能前端同学可能只关注进度条后端同学只关注大文件处理但如果你两个方向都了解就会意识到还有 CORS、鉴权方式、断点续传协议兼容性、存储成本预估等一整套上下游问题。AI 时代单点技术能力可以被快速替代但这种跨领域拼接的能力恰恰是 AI 最难复制的东西。因为 AI 的知识是分布式的它可以在每个单点上给出合理回答但把这些单点串成一条完整的业务链路并且确保每个衔接点都逻辑自洽它还很吃力。6. 常见问题与实操心得这一篇真正落地的部分。聊几个我自己在实际工作中被问得最多的问题以及对应的处理思路。6.1 AI 写的代码风格和团队不一致要不要强制统一我的建议是不要一刀切强制统一而是定义“边界内的自由”。在模块级别AI 生成代码的内部实现风格可以适度宽容因为不影响系统的整体可维护性。但在接口级别、数据模型级别、错误处理约定级别必须强制统一。这些是系统的“骨架”骨架乱了肌肉长得再好也没用。具体的落地做法是在项目里放一个精简的“接口规范约定”内容包括命名规则、文件组织方式、错误返回格式、日志打印规范。每次让 AI 生成新模块之前先把这份规范贴进上下文要求 AI 严格遵守。多试几次AI 生成代码的风格偏差会明显减小。如果项目已经混乱了那就先把关键接口的规范立起来再逐步调整。6.2 AI 生成了一段完全看不懂的代码怎么办这里我有一个比较实用的判断标准如果一段 AI 生成的代码团队成员需要花费超过半小时才能理解它是干什么的那这段代码的直接价值大概率是负的。不要因为“它能跑”就放过它看不懂的代码等于潜在的事故现场。处理方法也很简单要求 AI 重构用更直白的方式实现。如果 AI 反复提供的方案你都看不懂那大概率是你对某个基础概念理解不够深这时候要做的不是硬啃代码而是退回去把涉及的基础知识补一补。别觉得丢人我也经常被 AI 写的精巧实现绕晕但绕完之后花点时间把思路理清楚反而进步更快。6.3 怎么避免 AI 生成代码中的“看着没问题但线上就挂”“看着没问题上线就挂”的深层次原因我总结下来有四类数据量比测试数据大几个数量级、并发场景触发竞态条件、外部依赖的极端行为没被处理、以及业务状态的异常组合。这四类问题的共同特点是你在测试阶段很难复现因为它们依赖的是真实环境里的不确定因素。避免方案有三个层次。第一层是审代码时带着那四类问题逐项自问。第二层是给系统加可观测性——日志、指标、链路追踪三件套配齐尤其是异常日志要打得足够详细。第三层是设计兜底机制——异步任务失败有重试、数据异常有告警、服务崩溃有熔断。有这三层保护即使 AI 代码犯了错你也来得及在用户感知之前修复。6.4 新手程序员还要不要刷题、学基础、啃源码我的看法很直接要而且比以前更重要。AI 可以把基础算法写好但你要能识别出它写得好不好这就需要你自己懂基础。就像你请了一个特别能干的助理如果你自己肚子里没有货你连助理干得好坏都判断不了更别提指导助理怎么改进。建议新手把刷题和啃源码当成“练内功”把 AI 当成“练招式”。内功决定你的上限招式决定你的效率。天天用 AI 生成代码但完全不理解底层原理短期内项目能跑遇到 AI 不擅长的边界场景就会卡壳。6.5 踩过的坑AI 生成配置的“隐形炸弹”最后分享一个特别典型的坑算是给大家提个醒。有一次我让 AI 帮忙生成部署配置它默认加了一个很常见的设置——把超时时间配置成了 30 秒。这个值本身没什么问题但这个模块实际依赖的下游接口正常响应就要 40 秒以上。这个配置上线后所有下游调用全部在 30 秒被切断那两天线上一直在报错排查了很久才发现是 AI 随手写的一个数字闯的祸。从那以后我养成了一个习惯AI 生成的所有配置类文件我会一个一个参数看不放过任何一个数字。尤其是超时时间、重试次数、线程池大小、队列容量、缓存过期时间这种“看起来常规”的参数这些数值没有一个可以“猜”出来全部必须和真实业务场景匹配。AI 不在乎你的下游响应要多长时间它只会给你一个在“普遍情况下”合理的默认值而这个普遍情况可能恰好和你的场景完全不符。6.6 关于协作心态把 AI 当成“高配实习生”而不是“全知顾问”这是我目前最推荐的心态模型。你带实习生是什么状态你会给他布置明确的任务你会给他划定边界你会检查他的产出你会在他犯错的时候告诉他哪里错了、为什么错。对待 AI 也是一样——你给它越明确的任务边界它犯错的概率越低你越频繁地检查它的产出你能产生的杠杆就越大。把 AI 当成全知顾问什么都问、什么都信任会让自己逐渐丧失思考的敏锐度这是我最担心的一种退化。一个程序员如果连续几个月只做“复制粘贴 AI 代码”这一种工作他的问题意识、边界感知、系统思考能力都会退化得很厉害。这个损失不是省下那点写代码时间能补回来的。反过来把 AI 当成实习生来用你的角色就变成了管理者你在持续地质疑它的产出你在提出更有挑战性的要求你在思考怎么把任务拆得更清晰、边界定得更准确。这个过程本身就是一种高强度的能力训练而且训练的全是 AI 时代最值钱的那几项技能。
