冲击不在“会不会写代码”，而在“写代码还值多少钱”
这两年最明显的变化，不是程序员突然被替代，而是写代码这件事被拆得更细了。过去一个需求下来，很多人先从建表、写接口、补参数校验、加单元测试开始；现在这些环节，AI 工具可以直接给出初稿。一个熟悉业务的程序员，把需求、表结构、约束条件和错误处理说清楚，往往几分钟就能拿到可运行的骨架。
冲击首先落在“只负责把明确指令翻译成代码”的岗位上。比如简单的后台管理页面、重复的 CRUD 接口、格式转换脚本、常见的测试用例，这些工作仍然需要人，但需要的人数和时间明显压缩。企业不会因为工具变强就停止招人，但会更谨慎地招“只能做这些事”的人。
初级岗位的门槛被抬高了
以前初级程序员的价值很大一部分来自“能写”。现在“能写”本身不再稀缺，招聘方自然会把门槛往前后两端挪：前端要能理解业务闭环，后端要能处理并发、权限、数据一致性和线上故障，测试要能设计验证策略。换句话说，入门岗位没有消失，但入口变窄了。
一个典型场景是代码审查。AI 生成的代码看起来完整，命名也漂亮，但它可能忽略项目里的隐性约束：某个字段不能为空、某个接口必须幂等、某类异常要转成特定错误码。新人如果只会“生成并提交”，问题会留到联调甚至线上才暴露。相反，能读懂上下文、能写出审查清单的人，价值反而更高。
调试、验证和系统理解正在升值
AI 擅长给出“可能的答案”，不擅长替你对结果负责。真实项目里，最耗时的往往不是写出第一版，而是定位为什么在某个边界条件下失败。比如一个缓存更新逻辑，模型生成的代码在单测里通过，但遇到并发写和失效顺序问题时就会出错。这个时候，需要有人看日志、复现路径、理解调用链，再决定是改代码还是改设计。
所以冲击的另一面是价值转移：从“产出代码行数”转向“定义问题、验证结果、维护系统”。能写出可测试、可回滚、可观测的代码，比写得多更重要。会用 AI 的人，不是把键盘交给模型，而是把模型放进一个有测试、有审查、有监控的工程流程里。
知识折旧加快，但基本功没有失效
框架和语法更新一直很快，AI 让这个速度更明显。昨天还要查半天的写法，今天可能一句话就能生成。但这不意味着基本功失效。数据结构、网络协议、数据库事务、操作系统调度、权限模型，这些知识决定了你能不能判断生成结果是否合理。
比如让工具生成一段分页查询，表面没问题，但如果表很大、索引设计不合理，线上依然会慢。再比如生成一段重试逻辑，如果没有区分可重试错误和不可重试错误，可能把故障放大。工具能加速“写”，但不能替代“判断”。
程序员该怎么应对
第一，把 AI 当协作者，而不是替代品。给它足够的上下文：业务规则、接口契约、异常约定、已有代码风格；要求它先给方案再写代码；生成后必须补测试和审查。
第二，刻意训练验证能力。每接一个生成结果，问自己三个问题：边界条件是什么？失败时系统会怎样？怎么证明它是对的？这比多背几个 API 更有长期价值。
第三，往业务和系统深处走。理解钱怎么流、权限怎么控、故障怎么兜底，这些是模型很难从公开语料里替你补齐的。
AI 对程序员的冲击是真实的，但它更像一次分工重排：重复编码被压缩，判断、验证、设计和责任被放大。真正的分水岭不是谁会用工具，而是谁能在工具之上，对结果负责。
