这段时间在技术群、内部分享、甚至面试场景里我被同一个问题砸中的频率越来越高“AI 写代码这么猛程序员是不是真的没用了”问这话的有刚入行的新人也有写了十几年老代码的资深开发。问得多了我发现大家其实默认了一件不太对的事——把“程序员的能力”直接等同于“写代码的速度”。但只要你把一个软件项目从想法到上线、再到长期维护完整拆开看就会发现代码只是最外面的一层壳。真正决定一个系统能不能稳定跑下去、能不能在业务变化中活下来的是壳底下那些看不见的判断需求到底怎么理解才算对、方案上线后会不会出事故、出了问题由谁负责、改动对半年后的维护成本有什么影响。这些事AI 目前替代不了而且越往后越值钱。我并不是说 AI 不强。相反我现在每天的工作流里AI 承担了初稿生成、代码重构、测试数据准备、文档整理等等大量杂活效率提升是肉眼可见的。但用得越久我越清楚地意识到一件事AI 替代的是“编码动作”不是“编码背后的决策链”。这就像导航软件可以帮你规划路线但真遇到雨夜高速封路、前方事故、临时管制的时候绕不绕路、停在哪个服务区、要不要改坐高铁拍板的一定是坐在方向盘后面的那个人。程序员不是要成为跟机器比拼手速的岗位而是要成为那个在信息不完整、约束一堆的情况下依然敢做决策、并且能为决策负责的人。这篇文章不打算喊口号也不打算唱衰谁。我接下来要讲的是我在这几年实际开发、评审、排障过程中反复验证过的四种能力。每一种我都会拆到具体可落地的做法讲清楚为什么在 AI 时代它们反而更值钱。1. 先拆掉一个误区AI 省掉的到底是哪一部分工作量先说结论AI 目前最强的地方是“从一段明确描述到可运行代码”这段路的自动化。你给它一个定义良好的函数签名、一份清晰的数据结构、一串验收标准它可以在十几秒内生成初稿。这段路过去占一个程序员日常工作里的多少时间如果只算“敲键盘写代码”可能只占两到三成。真正的日常工作更多是花在理解需求、沟通对齐、排查问题、权衡方案、验证质量这些事情上。我举个例子。假如业务方提了一个需求“会员过期后发一条引导续费的消息。”这个描述看起来简单清楚程序员直接写代码似乎也没问题。但仔细一拆里面全是需要拍板的地方消息在什么时间点触发是过期当天零点还是扣费失败后的第三天如果用户已经续费到明年到期提醒要不要排除如果用户近期连续收到过提醒要不要限频免得变成骚扰如果用户已经退订了营销消息这条提醒还发不发这些都是业务规则不是语法问题。AI 写在表层很容易但把这些问题想清楚、列出来才是真正决定系统质量的那部分工作。我把这类工作叫“决策前置”。AI 时代代码生成成本趋近于零但决策成本没有变。过去一个方案写代码要花三天你想清楚只花半天边际收益可能不明显。现在写代码只要三分钟想清楚的那半天就成了整个任务里最具杠杆的部分。换句话说AI 把程序员的“操作成本”打了下来但把“判断密度”抬上去了。还有一个容易被忽略的点AI 生成的代码越多垃圾代码的积累速度也越快。过去一个人一天写 200 行现在 AI 一天能帮你产出 2000 行。如果这些代码没有经过人的思路过滤、没有落在统一的设计约束里半年后这个项目就会变成一座谁都不敢动的屎山。所以程序员的另一项能力浮出水面不是写代码而是决定哪些代码不该合入、哪些抽象不该加、哪些方案应该被推倒重来。2. 能力一把模糊的业务诉求翻译成机器能执行的任务这项能力听起来很基础但它是 AI 时代最被低估的硬功夫。原因很简单大模型的输出质量直接取决于输入质量。你给它的输入是一句模糊的“帮我实现一个会员挽留功能”它只能回你一堆正确但无用的通用代码你给它的输入是一份包含边界条件、异常分支、数据依赖、验收标准的任务描述它产出的代码才可能直接进入评审环节。2.1 反向提问清单先让业务方把话说明白我自己的习惯是拿到任何需求后先不急着写方案而是先列一份“反向提问清单”。清单本质上是在追问五个维度触发对象是什么谁会被这个功能影响触发条件是什么精确到数据状态和事件时序失败场景是什么拿不到数据、调用超时、重复执行时应该怎么表现约束条件是什么有没有合规、频控、成本限制验收标准是什么怎么判断这个功能做对了。举个实际例子。我在一个模拟电商项目里做过“支付成功后的优惠券发放”。业务方最初的需求非常简短“用户支付成功就发一张券。”我拿着清单问了一圈发现了大量没说出来的前提一笔订单拆成多次支付怎么办退款后再支付算不算新订单用户用券后再退款券要不要追回活动期间一人最多领几张发券动作失败了是否需要重试。这些问题如果让 AI 去猜它大概率会挑一个“最常见”的实现但业务方真正想要的可能完全不是默认逻辑。2.2 把问答结果固化成任务描述再交给 AI把这些问题问清楚之后我会整理成一段结构化的任务描述。描述里不写代码只写行为和约束。比如当且仅当订单完成全部支付且订单状态为已支付时触发优惠券发放。若用户在 30 分钟内支付多笔订单仅第一笔触发。发券失败时写入重试队列最多重试三次。已领取过同类型券的用户不再触发。发放成功后向用户推送站内信推送失败不影响主流程。这段描述看起来普通但它把 AI 最常见的“自由发挥空间”压缩到了最小。用这种描述去生成方案AI 很难给你跑偏。就算它生成了有问题评审的时候你拿着描述一句一句核对很快就能定位是哪段逻辑违背了哪条规则。这套做法说白了就是把“提示词工程”去神秘化。提示词不是魔法它的本质是让 AI 少猜。你替它把问题想清楚了它给你的东西才是真正可用的。反过来你扔给它一个标题让它自由发挥那它写出来的东西大概率要返工。我在团队里统计过超过一半的返工不是 AI 代码写错了而是最初的任务描述本身就是模糊的。所以会提问、会拆解的工程师在 AI 时代的第一项优势就是把需求变成规格的能力。3. 能力二用“验证思维”给 AI 产出兜底AI 生成的代码有一个很迷惑人的特点它错得很有欺骗性。语法是正确的结构是工整的还带着像模像样的注释和边界判断。你扫一眼会觉得“写得比我好”常规用例跑起来也全过。但恰恰因为太正常了那些藏在数据假设里的问题很容易被一眼带过。这时候程序员的第二项核心能力就凸显出来设计验证方案。我把验证拆成三层每一层都有对应的具体动作。3.1 静态层先找出代码默认了什么拿到 AI 的产出我第一步不是看它实现了什么而是看它默认了什么。它默认时间是东八区吗默认手机号一定是 11 位吗默认库存一定是正整数吗默认外部接口永远有返回吗这些默认值在训练语料里可能成立在真实业务里却完全不一定。有一次我让 AI 写一段“订单超时自动关闭”的定时任务。代码看起来非常完整扫描未支付订单、判断是否超过 30 分钟、更新状态、记录日志该有的都有了。但你要是顺着“默认了什么”去问问题马上就暴露了——它默认用户一旦下单状态只有“未支付”和“已支付”两种。而真实环境里完全存在“用户已经支付但支付回调还没返回”的中间状态。这种情况该怎么处理AI 没有写因为训练数据里这种业务时序问题太少了。3.2 数据层用边界数据做批量断言静态层靠的是经验和敏感度数据层则是更客观的手段。我会专门准备一份针对边界的测试数据集而不是跑一遍“用户正常下单、正常支付”的黄金路径。日期相关的代码我会放跨年、跨月、闰年、时区切换金额相关的我会放 0 元、负数、超大数、精度超标的浮点数状态机相关的我会把每个状态之间所有可能的跳转都列出来哪怕是业务上“不可能”的跳转。数据验证我常用一个办法叫“新旧对照”。同一份测试数据让新的 AI 生成代码和现有线上逻辑各跑一遍然后逐条对比输出。结果不一致的地方十有八九不是 AI 写得不好而是它的实现和你对业务的理解有偏差。这种对照在重构老系统时尤其有用它能把隐性差异变成显性列表省掉大量靠人肉读代码的时间。3.3 动态层灰度、监控和止损预案第三层是上线后的动态验证。AI 代码的风险比人写的代码更隐蔽因为它太“光滑”了异常不容易引起注意。所以我坚持让 AI 参与的关键逻辑先进灰度至少在一个小流量范围内跑一段时间观察错误率、超时率、重试次数这些指标。支付、订单、库存这类核心链路我还会额外加一条“资金或数据一致性巡检”确保即便逻辑写错了也能在几分钟内发现。还是回到那个“订单超时关闭”的例子。如果我们按这三层验证走下来静态层就能发现“支付回调延迟”的中间状态数据层再把这个状态放进测试集动态层上线后跟踪“已支付但被关闭”的异常告警这个问题根本走不到生产环境。可如果没有验证思维这种 bug 在测试环境几乎不可能被发现因为它不是语法错误而是业务时序错误。验证能力为什么比生成能力更稀缺因为 AI 可以在一小时内给你几十个候选实现但只有人能从里面挑出“在真实环境下依然成立”的那一个。未来的程序员未必是写得最快的人但一定得是最会设考题的人。你给代码出的题越多、越刁钻AI 产出的系统就越可靠。4. 能力三在不确定性面前承担最终责任我在团队里有个很深的体会AI 参与越多需要人来拍板的决定就越“重”。以前一个普通功能代码写错了影响范围可能只是某个页面报错现在 AI 自动生成的方案被直接采纳后一旦上线出问题第一个被追责的仍然是人。所谓的能力不只是能把代码写对更是在没人知道正确答案时敢做选择并且为选择的结果兜底。我习惯把这份责任拆成三层来看。第一层是代码责任合入的代码会在什么条件下触发什么行为出现异常时表现是什么。第二层是业务责任这个行为对用户、对营收、对品牌会产生什么影响。第三层是风险责任在信息不完整的情况下选了哪条路径有没有给自己留后路。举一个我踩过的坑。某个项目为了降低数据库压力AI 建议加一层缓存并生成了一套完整的缓存读写代码。代码本身无可挑剔读写策略、过期时间、缓存结构都很标准。但我们只看到了它的收益忽略了它的风险热点 key 过期的那一刻如果大量请求同时打到底层数据库因为旧逻辑的兜底已经被移除数据库负载瞬间飙升差点拖垮核心服务。复盘的时候结论很清楚——AI 只是提供了一个“看起来合理”的选项真正决定“能不能接受缓存空窗期”“要不要保留旧逻辑作为降级开关”的是人的判断。4.1 做技术决策时永远要问的三个默认问题后来我给自己定了一条规矩任何一个技术方案落地前先回答三个问题。第一个什么情况算这个方案“失败了”失败的标准必须明确比如错误率超过 0.1%、响应时间超过 500ms。第二个失败了怎么降级是切回旧逻辑还是停止流量还是降级成静态数据第三个谁在 10 分钟内有权限做判断没有预案的决策本质上是把风险裸奔到生产环境。AI 生成方案时默认一切正常网络不抖、数据不脏、第三方接口永远稳定。但现实的系统里这些都是常态不是异常。能在方案设计阶段就把“失败”当成一等公民来对待的人才是真正在承担最终责任的人。这不是过度悲观这是对系统最基本的敬畏。5. 能力四把技术方案放在“成本与演进”的上下文里还有一个被很多人忽略的能力是把技术方案放进成本与长期演进的约束里去看。AI 特别擅长在一个局部里给出最优解但它天生不关心这个局部和整体目标的匹配度。比如一个业务现在只需要快速上线活动页这时候最优解可能是直接改现有系统但如果团队正处于平台化改造的窗口期同一个需求放在整体架构里处理方式可能完全不同。这种“在什么上下文里做选择”的判断力目前 AI 给不了。我会在让 AI 生成方案前先把约束条件写进去时间成本是多少团队对技术栈的熟练度如何存量系统的兼容性要求是什么半年后这个模块是要保留、替换还是仅仅过渡。这些参数决定了一个方案是“能跑的方案”还是“合适的方案”。你写得越清楚AI 给的结果就越贴合真实需要你不写它只会给你一个架空的“标准答案”。另一个容易被 AI 带偏的是它天然没有成本意识。你让它生成一个抽象方案它倾向于加更多的层、更多的接口、更多的设计模式因为从文本生成的角度看500 行比 50 行显得更认真。但真实系统里每一行抽象都是长期的维护负担。保持简单、保持直接、让方案能一步步演进这种克制必须由人来主导。5.1 代码评审的新重心审“假设”而不是审“语法”AI 参与写代码之后代码评审这件事也变了。过去评审重点放在逐行挑语法、挑逻辑漏洞现在 AI 已经把这类工作完成得相当好了。剩下的评审重心应该转移到审“假设”上。合入一段代码前我会先问三句话这个方案默认了什么它排除了哪些情况如果这些前提不成立会发生什么这三句话问下来很多问题在评审阶段就暴露了比如依赖了某个不存在的索引、默认所有用户都有手机号、默认第三方接口不会超时。为了更直观我做了一张表能看到“局部最优”和“全局可演进”两种思维方式的差别维度局部最优思维全局可演进思维目标快速解决眼前问题降低未来一年的维护总成本决策习惯拿到需求马上写代码先问约束条件再给方案验收标准功能跑通包含边界、失败场景、监控、回滚预案工具使用让 AI 直接生成代码让 AI 先出方案再选代码代码风格抽象丰富结构炫技简单直接可替换可删除这两种思维没有绝对的好坏关键是你在什么阶段选择哪一种。能根据项目生命周期、团队状态、业务压力做出正确选择本身就是高级程序员的重要价值。AI 可以帮你把代码写得更好但很难帮你判断“这一阶段到底该激进还是该保守”。6. 给团队落地时我做的几项具体调整上面说的都是认知层面的东西但认知不能落地就只是鸡汤。这半年我在项目里做了几项很具体的工作方式调整效果比较明显分享出来供大家参考。6.1 把“提示词”改成“任务说明书”我要求团队在给 AI 派活时不再写“帮我写一个 XX 功能”这种话而是提交一份任务说明书。说明书的骨架固定是这样背景与目标、业务规则与约束、输入输出样例、边界条件与异常分支、验收标准、需要返回的内容形式。一份合格的任务说明书拿给任何一名工程师看他能不动脑直接去实现那么再拿给 AI 用效果才有保障。这套说明书看起来繁琐但有一次它的价值直接拉满。团队准备批量重构一批老接口我用说明书的方式把每个接口的行为定义清楚后AI 生成的重构代码几乎一次通过评审。原因很简单——过去的表述里全是“像原来一样”这类依赖人类背景知识的描述AI 根本没法理解改成说明书之后它才真正知道边界在哪里。6.2 让 AI 先出方案再出代码我不太允许 AI 直接跳到最终代码除非任务简单到像写一个工具函数。稍微有点业务逻辑的任务我要求它先输出方案数据结构怎么设计、外部依赖有哪些、核心流程分几步、哪些地方可能会失败、性能预期是多少。方案通过我的评审之后再让它进入代码细节。这一步多花的时间极少但能避免大量“看起来能跑、实际上思路就错了”的返工。方案翻车的成本永远低于代码翻车的成本。6.3 评审清单里加上三条必答题我调整了整个团队的代码评审清单新增了三道必答题和语法、性能、可读性并列这段代码默认了什么条件如果条件不满足会发生什么这个方案有没有考虑失败降级如果答案里有任何一条“我不确定”那这段代码不允许合入主分支。刚开始执行的时候大家觉得有点强迫症但连续拦下两个潜在的线上事故之后团队开始真香了。6.4 有些任务我会坚持不用 AI 代劳尽管我上面全是“如何用好 AI”但在某些任务上我反而坚持人工完成。比如资金相关的金额计算逻辑、数据的物理删除操作、对外服务承诺的文案、复杂业务中最终方案的拍板。不是因为 AI 一定做得不好而是因为这些任务的试错成本高到不允许有一点侥幸。人是这些责任的最终承担者AI 输出得再快也不该在这种位置直接裸跑。这种对风险的敬畏也是 AI 时代程序员另一种隐形能力。我个人的看法是AI 会把程序员的日常推得越来越快但它不会消除“做工程”这件事本身的不确定性。只要有不确定性就需要有人去定义问题、验证方案、承担责任、权衡取舍。如果只能留一句话我想说重要的从来不是跑得比 AI 快而是你比它更早看到问题在哪里。