1. 先别急着下结论AI写的代码到底处在什么水平最近半年我一直在密集使用各种 AI 编程工具从 Cursor 到 Copilot再到字节的 Trae、阿里的通义灵码基本主流的都轮了一遍。实测下来的结论可能会出乎很多人的意料在不少场景里AI 生成的代码确实比大部分中级程序员写的要好而且不是好一点是全面碾压。但这恰恰是问题的核心。如果 AI 已经能闭着眼写出结构清晰的 CRUD、表结构设计、单元测试甚至能根据错误日志自动修 bug那程序员这个职业是不是要变成历史名词了很多人焦虑的点就在这。我认识几个团队已经出现了初级程序员写代码的速度赶不上 AI 的现象老板开始犹豫要不要继续招人。作为一线开发人员我觉得这件事值得掰开揉碎讲清楚因为这直接关系到你未来是涨薪还是被优化。先说清楚我口中的“中级程序员”是什么定义免得有歧义。按我的理解工作 2 到 5 年能独立完成模块开发能处理日常增删改查会写一点很基础的性能优化能照葫芦画瓢地搭框架但对系统的整体架构、业务本质、底层原理理解不透彻。这种人恰恰是 AI 冲击最严重的群体。为什么?因为他们的日常工作大多数是在“翻译需求”——把产品经理的需求文档翻译成代码。这种工作本质上是确定性极高的信息转换而 AI 最擅长的就是信息转换和模式匹配。一篇需求文档扔进去AI 能在十秒钟内给出可编译的 Python/Java/Go 代码还能顺手配上单元测试不用休息不用吃饭情绪稳定不离职。只比较代码产出量人类完败。那是不是意味着“中级程序员”这个岗位就真的没救了我的答案是单纯只负责写代码的中级程序员确实没救了。但这不代表程序员这个群体没有价值而是价值坐标系变了。就像计算器发明之后没有人再比拼手算速度会计这个行业消失了吗没有反而要求更高了因为计算工具普及后所有会计都要懂财务模型、税务规划和风险控制。程序员也是一样AI 把代码生产的成本打到接近于零之后人类程序员的不可替代性反而会浮出水面。这话并不是鸡汤是行为经济学里的“分工演化的必然”。我接下来的内容会从具体实测、能力模型、协作流程、避坑清单这几个维度展开。不管你是焦虑的初级工程师还是想转型的资深开发这篇文章都值得看完。2. 价值坐标系已经变了写代码只是程序员的最低技能2.1 AI 时代程序员的“能力金字塔”正在重构过去我们评价一个程序员最先看的是编码能力然后才是沟通、设计、业务理解。这也是为什么 LeetCode 刷题能成为大厂面试标配因为算法题是最容易量化“代码能力强不强”的方式。但你现在把同样的算法题扔给 GPT-5 级别的模型它能在几秒钟内给出多种解法甚至能分析时间复杂度和空间复杂度的权衡。如果在 2024 年之前你告诉我“需要靠刷题才能证明自己”我还能勉强点头。到了现在我再说服自己“刷题高手就是好程序员”就实在没有说服力了。现在真正的能力金字塔底层是“提出问题的能力”中层是“筛选和判断的能力”塔尖才是“编码能力和调试能力”。很多传统程序员的问题是把塔尖当成了底座每天钻研的是怎么写出更优雅的 lambda 表达式怎么把 if else 改成策略模式。这些当然有用但它只是塔尖。塔尖是可以被 AI 替代的因为模型的训练数据里有海量这种代码模式你的所谓“优雅”不过是统计学上的高频组合罢了。这里我引用一个实战案例。我们团队前段时间接了一个爬虫需求要求从某公开网站抓取行业数据做清洗后存入数据库支持增量更新。这需求如果扔给初级工程师至少要排三天工时中间还要处理各种反爬虫策略、字段缺失、类型转换的边角。我的实际操作是用 Cursor 打开项目描述清楚目标站点结构、渲染方式、存储字段然后让 AI 先写一版基础抓取逻辑。它十分钟就给出了完整代码附带重试机制、异常捕获、分页处理比我预期质量高得多。接下来的工作是什么是我在做代码审查的时候发现目标站点的数据是异步加载的AI 用的 requests 根本抓不到渲染后的内容得改成 Playwright 这种无头浏览器方案。这个判断AI 给不了你它只会按你给的信息去写。这个“判断”就是塔尖之下的核心能力。2.2 需求拆解与模糊信息清理AI 最怕“需求不清”和 AI 协作多了你会发现AI 的能力上限不取决于它自己而取决于你喂给它的上下文质量。你给它一句“帮我写个用户登录功能”它给出的泛化代码能跑但绝对无法直接引入生产环境。因为你没说清楚用户名登录还是手机号登录需不需要第三方登录密码要什么加密策略登录失败锁定策略怎么处理token 有效期多久需不需要刷新机制这些问题你自己没想明白的时候AI 只能给一个“平均水准”的答案。但一个优秀的程序员在面对这种模糊需求时的第一反应不是写代码而是把需求拆解成决策树逐层找产品经理确认。我见过太多工作了三四年的开发拿到需求直接开写写到一半发现逻辑边界没定义再回头问产品产品也说不清楚然后整个模块返工。这种场景在 AI 时代会显得极度低效因为 AI 写代码的速度已经快到让“返工成本”成了首要考量。如果你的需求拆解能力不行你让 AI 快速产出初稿的优势不仅发挥不出来还会变成灾难——AI 快速给了一堆烂需求的实现你得像伺候大爷一样去修改工作量比自己写还大。所以我说现在最值钱的程序员是“能把一句含糊的话变成可执行规格说明书”的人。比如产品经理说“要给用户推个性化内容”平庸程序员直接去写兴趣推荐算法厉害的程序员先反问什么叫个性化基于什么数据实时性要求多少人均成本预算多少推荐结果的效果怎么度量把这些问题梳理完你可能发现根本不需要上复杂的算法一个简单的规则引擎加埋点统计就能解决 80% 的需求。这种“四两拨千斤”的判断力是 AI 永远学不会的因为 AI 没有“业务语境”只有“文本概率”。2.3 “为什么”比“做什么”贵十倍系统设计决策的护城河我可以负责任地说当 AI 能写出高质量 CRUD 之后“系统设计能力”和“技术决策能力”就变成了工程师之间真正的分水岭。什么是系统设计举个简单例子电商平台要做订单超时自动关闭功能方案一用定时任务扫表方案二用延迟消息队列方案三用 Redis 过期事件监听。三个方案都能实现但性能、可靠性、复杂度天差地别。AI 可能会基于训练数据告诉你“业界常用方案是延迟队列”但它无法告诉你你们团队根本不熟悉 Kafka运维也没力气维护多一套中间件你们当前阶段就应该用稍微糙一点但完全够用的定时任务扫表方案。这种“基于团队现实的妥协决策”才是资深程序员的真正价值。我去年做过一个很有意思的对比实验。我把一个真实的系统设计考题扔给 AI 和组里的高级工程师分别作答题目是“设计一个支持千万级用户同时在线的实时弹幕系统”。AI 给出的答案是标准教科书WebSocket 长连接、Redis 缓存热点弹幕、消息队列异步削峰、分片部署。看起来无懈可击。但我们的高级工程师在方案里第一句话写的是评估一下业务是否真的需要千万级并发如果只是百万级用单机 Go 加协程就能搞定架构复杂度直接降两个量级。这就是差距。AI 只能给出“正确但昂贵”的方案而人类工程师知道“场景匹配”比“技术前瞻”更重要。这背后是成本意识、风险意识和业务理解绝对不是靠训练数据能攒出来的。所以我的结论很明确程序员的价值会从“代码产出者”迁移到“决策者和责任者”。代码越来越像是程序员表达决策的“草稿纸”而不是最终交付物。真正的交付物是全套技术解决方案包括架构、流程、成本、风险、运维等一揽子东西代码只是其中占比越来越小的一块。3. 与 AI 协作的新工作流我每天是怎么干活儿的3.1 从“亲手写”到“指挥与审查”Code Review 进入 2.0 时代过去我们写代码是一个字一个字敲出来的代码量直接代表工作量。你现在看我的屏幕输出大部分时间不是在敲代码而是敲提示词、看 diff、查文档、改测试。我在 Cursor 里的大致工作节奏是这样的先把需求按用户故事拆成小块每一块配上一段自然语言描述包含输入输出、边界条件、性能约束然后把描述喂给 AI让它生成候选实现。拿到候选实现后我开始做 Code Review。这个 Review 跟以前看同事代码还不太一样看同事代码时我默认他思路是对的只是检查细节和风格。看 AI 代码则默认它是错的每个逻辑分支都要自己推演一遍每个嵌套循环都要想清楚会不会越界每段和数据库交互的代码都要检查有没有事务边界和连接泄漏。有人会问这样审查下来工作量比我直接写代码还大图什么图的是效率差。AI 写一段带分页查询的 REST API 可能只需要 30 秒你审查它需要 20 分钟你自己写这段代码可能也要 1 到 2 个小时。更关键的是AI 在初稿阶段犯的低级错误变量名、格式、常规 API 用法概率极低它的“下限”比人类实习生高得多。所以只要你有能力把“审查”环节做到位整体产出效率的提升是非常可观的。我们团队实践下来的参考数据是在 AI 辅助下一个熟悉业务的资深工程师现在能撑起过去两到三个人的产出量。但这里有一个致命前提你必须有足够强的代码功底才能做这个“审查者”。如果你连死锁产生的条件都说不清楚、连 SQL 索引失效的场景都判断不了你根本审不出问题。你会发现让 AI 生成代码、然后自己完全信任不审阅等于把生产事故的雷埋进了代码库。这就是为什么网上总有人说“AI 生成的代码都是垃圾”——大概率不是 AI 垃圾而是使用它的人没有做审查或者做完审查也看不出来问题。“AI 写 bug人类背锅”的冤案会越来越多不想背锅的唯一办法是把自己训练成比 AI 更严格的质量把关者。3.2 Agent 化开发我如何让 AI 自己跑完一整个需求闭环如果你还在把 AI 当高级自动补全工具用那你的效率提升可能只有 20% 到 30%。真正的杠杆在于“Agent 化”——让 AI 不仅仅补全几行代码而是让它组合调用工具、自己读文件、自己跑测试自己去迭代修复形成一个半自动化的闭环。很多团队拿到 AI 编程的第一反应就是“让它写函数啊”这完全是用错了方向。函数级别的工作量太细了人的介入密度太高你一会儿要复制粘贴一会儿要补充上下文一会儿要切换模型累死人。正确的方式是像带实习生一样把“目标”讲清楚然后让 AI 自己拆解步骤去执行。以我自己最近做过的一个内部数据报表页面为例。我的提示词大概是这样的在现有 FastAPI 项目里新增一个接口读取 MySQL 中 order 表按天分组统计订单量和销售额支持 startDate 和 endDate 参数结果以 JSON 格式返回注意大时间范围下的查询要用到索引优化。如果是在 Copilot 时代这种需求 AI 只能给一个孤零零的函数体其余全靠我自己接。但现在用 Cursor 的 Agent 模式AI 会自己打开项目目录找到 models 和 routers 里的相关文件读懂现有的代码风格然后生成完整路由、依赖注入、参数校验最后还写好了 pytest 单元测试。整个过程我的工作只剩两步描述需求、审查最终改动。这种工作流下的单位时间产出是过去无论如何也达不到的。Agent 化开发有一个核心技巧——要把“上下文”喂得足够完整。AI 是个没有短期记忆的同事它每执行一个动作都只看到它文件里的内容和你对话里的内容。你如果指望它自动理解你项目里所有业务逻辑那就是做梦。高效的做法是在项目根目录放一份“上下文说明文件”有的地方叫 AGENTS.md把项目的技术栈、目录结构、编码规范、常用的设计模式都写清楚。AI 每开始一个新任务都会自动读这个文件这会让它的输出质量有质的飞跃。这个习惯我强烈建议每个人都建立起来成本极低收益极高。3.3 上下文工程提示词能力才是新时代的“编程基本功”我发现一个特别有意思的现象同样用 Cursor有人能半天完成一个模块有人折腾一天还在跟 AI 扯皮。核心差距在提示词质量。很多人写提示词就像在跟 AI 打哑谜比如“帮我修一下代码”AI 根本不知道代码在哪、什么报错、期望行为是什么只能给一堆正确但无用的废话。好的提示词应该遵循一个公式目标描述 约束条件 输入样例 输出预期 环境上下文如技术栈、框架版本、已有文件路径。拿修 bug 这个场景来举例差的提示词是“这段代码有问题帮我看看”好的提示词是在 src/utils/date.ts 文件里formatDate 函数输入的参数是 Date 对象但当参数是字符串时会返回 NaN。请修复这个问题并补充两条单元测试一条处理字符串输入一条处理空值输入。你看同样的场景后者的成功率比前者高了几个量级而且返回的解决方案精确匹配你的项目需求。很多人抱怨“AI 生成的东西根本没法用”八成是提问方式还在石器时代。这背后有一个重要的心智转变以前我们写代码是在“告诉计算机做什么”现在跟 AI 协作是在“告诉一个极度聪明但缺乏常识的合作者做什么跟不做什么”。这个合作者知道所有框架的标准写法但对你的业务、你的历史包袱一无所知。所以你需要像给新同事做交接一样把所有隐性知识翻译成显性文字。能做好这件事的人本质上已经是半个提示词工程师了。我坚定不移地认为未来五年的高薪技术岗位不会要求你背出各种 API 签名而是要求你能在最短时间内把一个模糊的业务需求结构化成清晰的 AI 可执行规格。4. 踩坑实录我在 AI 辅助开发中反复遇到的五个典型问题4.1 幻觉代码AI 一本正经地给你编造 API先讲最恶心的坑。你让 AI 调用某个开源库它可能给你“编造”一个根本不存在的函数名。表面上语法完全正确import 也通过可一运行就报 AttributeError。这种事情在 AI 训练语料覆盖不到的新版本库中尤为常见。比如去年我们项目引入了某个较新的流处理组件文档更新不太全AI 给出的代码里就出现了一个理论上该存在、但实际版本已经改名的方法。当时我还夸了它效率高结果编译阶段直接挂掉排查了二十分钟才发现是它编的。怎么防答案是建立“可验证闭环”。AI 写出来的任何涉及陌生 API 的代码都要去官方文档里搜一下函数签名或者直接在本地写一段最小白样例验证。不要相信 AI 的任何“自信输出”它没有推理能力本质上是概率生成只要语料里出现过类似模式它就可能张冠李戴。你越是在冷门框架、小众库的场景里依赖 AI越要给每段代码都加一个 mock 数据的小测试来验证。我还养成了一个习惯但凡 AI 给出的方案里出现我从未见过的库必定先查清楚这个库的 star 数和最后更新时间再决定要不要用它。冷门库就算能跑也可能活不过明年到时候维护成本全部自担。4.2 依赖与版本陷阱AI 不会看 changelog第二个高频问题就是 AI 给你的代码依赖版本混乱。你让它解决一个编译错误它建议升级某个包到最新版本但升级后其他模块因为 API 不兼容全炸了。你问它怎么办它又建议你回退版本来回拉锯原地推磨。这种版本协调问题本质上是 AI 缺乏“全局变更影响评估”能力的最好证明。它只能看到你给它看的局部文件看不到整个项目的依赖关系和兼容矩阵。我踩过一次特别深刻的坑。一次前端项目优化时AI 建议我把 element-plus 从 2.2 升到 2.4 来解决某个弹窗 bug。升级完弹窗倒是正常了但项目里所有用到日期组件的页面样式全乱了因为日期组件内部行为发生了变化。这个责任完全在我因为我信任了 AI 的建议没有在做版本变更前查看 changelog 和 breaking changes。后来我立了条规矩任何涉及依赖升级的 AI 建议必须先做一次全仓库的调用点检索再用视觉回归测试兜底。在 AI 时代你可以让 AI 去写代码但“变更影响分析”这件事永远是资深工程师不可推卸的责任。4.3 安全漏洞AI 的代码在攻击者面前脆弱得可怕这是我最担心的问题。AI 生成的业务代码看上去逻辑完备但在安全层面经常是裸奔状态。SQL 注入、XSS 脚本注入、CSRF、权限绕过这些问题 AI 并不是完全不懂训练数据里有大量安全编码的示例但它在具体实现的时候除非你明确要求否则它倾向于走“最短路”不会优先考虑安全性。我让 AI 写过一个文件上传接口它居然连文件类型校验都没有只检查了扩展名我随手把扩展名改成 .html 就能把木马传上去。这种事你让任何正规培训出来的中级程序员做都很难犯这种低级错误但 AI 模型就是这样它只是照着最常见范式往下顺。想让 AI 写出安全的代码有一个方法在提示词里显式声明安全基线。比如要求“所有 SQL 必须使用参数化查询禁止字符串拼接”“所有用户输入必须走统一校验函数”“所有文件上传必须做 Content-Type 白名单检验”。你得把你脑子里那些多年踩坑总结出来的安全规范逐条翻译给 AI 听。但更稳妥的方式是所有 AI 生成的代码都必须经过至少一次安全敏感性审查尤其关注它直接操作请求参数、文件系统、外部命令的部分。这个东西没法偷懒出了事检验的是你的责任心不是 AI 的训练数据。4.4 认知退化用多了 AI我发现自己写代码的能力在变弱这个发现来得特别突然。连续高强度使用 AI 助手三周之后有一次我离开电脑思考问题随手在白板上画一段链表反转的伪代码画完我愣了一下我居然在犹豫 next 指针和 current 指针的交换顺序。过去这是我闭着眼都能写出来的基本功。那一刻我意识到一个严重的问题过度依赖 AI 会让人的“手部技能”发生退化。人的技能有两种一种是显性操作技能一种是深层理解技能。写代码时双手的肌肉记忆和大脑快速路径会在反复训练中被强化如果你已经半年没有亲自模拟过底层逻辑那你的代码直觉一定会钝化。我的应对方案比较粗暴每周至少保留两个小时“离线写码时间”关闭所有 AI 工具从一个空白的编辑器和一段需求文档开始起手。写正式项目里最复杂的核心模块不用任何自动补全。这样做的目的不是保持手艺而是保持“对代码细节的直觉敏感度”。有了这种敏感度你才能在做 AI 代码审查时一眼看到问题所在。如果你已经完全丧失这种直觉那你不过是 AI 生成内容的搬运工迟早会被更快的人替代。这是我自己给自己设置的“防替代护栏”建议每位靠代码吃饭的人都认真考虑下这件事。4.5 团队协作摩擦不同人用 AI 的水平差距正在撕裂团队最后一个问题不是技术层面的而是协作层面的。AI 工具面前人和人的产出差异被无限放大。同一个需求组里擅长提示词工程的同事用一小时搞定另一个不太擅长表达和拆解的同事用了一天还在原地打转。这种差距过去也存在但没有那么刺眼。因为过去写代码拼的是手速和经验大家差不了太远。现在拼的是“拆解需求、组织上下文、审查判断”的抽象能力这玩意儿经验的代际差太大了。以前我习惯让新人从做小需求开始历练现在这招失效了。因为新人很可能直接把需求发给 AI得到一份自己看不懂的代码然后原样提交代码不仅质量堪忧而且新人自己完全没长进。我的解法是建立“AI 使用规范”和“结对审查制”团队里明确要求AI 生成的关键代码必须由负责人 Review新人必须能解释每一行代码的设计意图。同时定期开“提示词复盘会”让产出最高的人分享自己是怎么描述需求、怎么给 AI 下约束的。这种互相拉齐的方式能让团队下限不至于被 AI 拉得太低也能让上限继续突破。5. 想在 AI 时代不仅不被淘汰、反而更有竞争力我建议你这样做5.1 把“提问能力”当成核心技术练这是你新的编程基本功我开始强调一个训练方法每天用 30 分钟去练习“高质量提需求”。随便挑一个你熟悉的业务场景然后用文字写清楚要实现什么、不要什么、边界条件有哪些、性能数据要求是多少、错误处理长什么样。写完后再用 AI 去生成看看它给的结果跟你想的是否吻合再反过来改描述。这种练习表面上是在训练 AI 的输出质量本质上是在训练你自己结构化思考的能力。思考能力这个东西机器的训练数据里没有只有你自己加练才有。5.2 拥抱领域知识成为“懂业务的程序员”而非“会写代码的活工具”我观察到一个趋势AI 让通用编程技能加速贬值的同时让领域专家型程序员的溢价越来越明显。同样一个供应链系统AI 写的代码和普通工程师写的代码差不多但如果有人能说清楚供应链里的采购、库存、履约之间的业务闭环能知道某个节点上的数据延迟会导致报表失真到不可接受那这个人写的整个体系设计就是 AI 无法替代的。所以劝各位同龄的开发者别再沉迷于“各种框架的玩法”了多花时间在你的行业业务上去了解你的用户、你的商业链路、你的数据流转。代码会贬值但懂行业的人永远值钱。5.3 建立“人机团队”意识你管理的不只是代码更是 AI 的工作节奏最后一层建议来自组织层面。如果你的定位是技术负责人或架构师请不要把 AI 当成一个简单的效率工具来采购而是要把“AI 技能分层管理”纳入到你的团队建设里。比如给初级程序员分配任务时把需求拆到足够细让他们通过 AI 去执行并在 Review 中讲清楚逻辑给高级工程师安排任务时让他们主导 AI 的上下文工程和测试闭环让他们去定义 AI 工作的质量标准。这样一来AI 不是替代掉团队里的某个人而是成为了团队的“扩编的劳动力”但还是需要有经验的人来兜底掌舵。6. 写在最后我个人在实际操作中的体会是AI 写代码这件事带来的最大冲击不是代码生产的效率提升而是逼着整个行业重新定义“程序员”这个词的含义。以前我们自嘲是码农是因为我们的确像农民一样在耕地——把需求文档这块地一茬一茬地种成代码。现在 AI 能把这块地快速犁完我们就得从农民变成农场主负责判断种什么、什么时候种、卖给谁。看着好像角色变小了其实要求反而高了。未来能活得很好的那批程序员绝对不是代码写得最花哨的而是最清楚“为什么写这段代码”的人。你可以把 AI 当成你的对手跟它拼写代码速度然后你输得很惨也可以把它当成你的探测器去帮你快速验证想法、产生候选方案然后把你的大脑留给决策、判断和责任。这条路越早走通越舒服。