最近有个朋友兴冲冲地跟我说他花了三天时间用 Cursor 加 ChatGPT做出了一个能下单、能支付、能后台管理的 App demo感觉“人人都是程序员”的时代真的来了。我没泼冷水只是问了一句你那个支付回调做幂等了吗并发扣库存怎么办数据库有索引吗他沉默了。这恰恰是我今天想写这篇文章的原因——AI 编程确实把门槛从“会写语法”降到了“懂业务逻辑”但它并没有把“做出一个东西”和“交付一个能稳定运行的系统”之间的鸿沟填平。别被“人人都是程序员”这句鬼话骗了AI 编程的尽头依然是硬核技术。1. 人人都是程序员这话只说对了一半1.1 门槛确实降了这是事实先说公道话。AI 编程工具这两年的进步确实肉眼可见GitHub Copilot、Cursor、CodeWhisperer外加各种 AI Agent已经可以做到你描述一句需求它给你生成一段大体能跑的代码。过去一个完全零基础的人想写个爬虫、做个自动化表格、搭个个人网站少说也得先啃两个月语法现在一张嘴AI 就把初稿整出来了。我自己也用。写个 Python 脚本处理 CSV让 AI 生成一个 React 组件甚至写个正则表达式AI 都能给出一版让我改改就能用的结果。对非科班出身的人来说这确实是前所未有的友好。我也见过有产品经理用 AI 工具搭出了内部工具原型有运营用 AI 写 SQL 拉数据有设计师用 AI 生成前端页面——这些都是实打实提效的场景。但问题在于工具使用者很容易把“我能用 AI 生成代码”误当成“我具备工程能力”。GitHub 上一堆 AI 生成的“看起来很牛”的项目真正部署到生产环境、应对真实流量后就露了馅。就像人人家里都有烤箱但不代表人人都是烘焙师——烤糊了可以重烤但软件线上崩了损失的是真金白银和用户信任。1.2 但能跑起来和能上线是两个世界我的经验是AI 能帮你快速搭出一个“看起来能跑”的 demo但软件工程真正烧钱、烧脑的部分几乎都在“看起来能跑”之后。举几个我在实际项目里反复踩的坑边界情况AI 生成的代码通常只覆盖“正常路径”。用户输入了空字符串怎么办文件编码不是 UTF-8 怎么办网络超时重试几次并发请求同时改同一条数据怎么办这些“大概率不出现一出现就出大事”的场景AI 通常想不到。安全性AI 会让你拼 SQL 它就拼 SQL不会主动提醒你防注入你让它读文件路径它就拼接路径不会考虑目录穿越。所有安全防护的意识和习惯都得靠人的经验来兜底。性能AI 生成的代码在小数据量下没问题但数据量涨一百倍写个 O(n²) 的循环就能让你的接口从 10ms 变成 10 秒。它不会主动给你做复杂度分析更不会告诉你这条查询该加什么样的索引。可维护性AI 生成的代码风格不统一、模块边界混乱是常态。今天它给你写一段明天再生成几段拼在一起你的代码库很快就会变成“只有 AI 自己看得懂的屎山”。所以我对“人人都是程序员”的理解是一半真一半假。真的是工具普及率假的是能力替代性。一个人用上了电钻不意味着他拥有了建筑工程师的技能包。门槛降低只是让你更容易“入场”并不意味着你能“站上领奖台”。2. 一次完整的 AI 编程实战复盘从惊艳到翻车我想用一次真实的开发经历把 AI 编程的优势和边界说明白。这是我去年做的一个订单导出工具逻辑非常简单从数据库读取订单表按时间范围导出成 Excel 给运营同事用。2.1 需求背景与 AI 生成结果需求描述是“查询订单表按创建时间筛选导出字段包括订单号、用户ID、商品名称、数量、金额、订单状态输出为 Excel 文件。”我把这段需求原封不动抛给 AI 编程工具它很快就生成了一版代码Python 的 pandas 读取数据库然后to_excel输出文件。第一眼看上去代码结构清晰、命名规范、甚至还有注释和异常处理。我当时的想法是就这以后确实可以躺平了。但真正放到生产环境问题接踵而至。2.2 翻车点逐个拆解以下是我在实际运行和后续压测中遇到的问题做了一个归类翻车点AI 为什么没想到需要什么样的硬核能力订单表数据量 200 万行pandas 全量读入内存服务器直接 OOM 崩溃AI 默认数据量很小不会考虑内存上限内存模型的直觉知道一次全量加载的成本能想到分页/流式读取商品名称包含中文和特殊字符默认编码写错导致 Excel 乱码AI 不会感知数据实际的编码特征对字符编码体系有基本认知知道 UTF-8、GBK 的差异导出 10 万行时接口耗时 40 秒用户反复点击触发多个并发导出任务数据库连接池被打满AI 不会考虑并发控制和任务队列并发编程知识线程池、队列、异步任务、限流查询语句用了LIKE %关键词%全表扫描数据量一大查询时间指数级上升AI 不会分析 SQL 执行计划数据库索引原理知道 B 树、覆盖索引、explain 命令用户 ID 是脱敏字段业务方要求只能导出最近 3 个月数据AI 完全不知道这条隐含业务规则AI 不了解领域规则和合规要求业务理解能力和合规意识逐条拆解一下。第一内存 OOM这个是最基础也最致命的。200 万行订单数据每行几十个字段加载进 pandas DataFrame 大概要几个 GB 内存。生产服务器 JVM 堆内存一般也就 2-4GB直接崩给你看。解决办法是分页查库、流式写 Excel或者用fetchmany分批处理再或者直接改用数据库导出命令。这些思路 AI 不会主动给你因为它的“想象力”建立在训练语料的统计规律上而不是对当前系统资源的实时感知。第二编码问题。AI 生成的代码默认用 UTF-8 写 CSV/Excel但很多老的 Excel 客户端的默认编码是 GBK/GB18030。你用 UTF-8 生成的文件用户用 WPS 或老版 Excel 打开中文直接乱码。这个问题的本质是“你知道文件最终会被谁用什么软件打开”AI 不掌握这种上下文。第三并发问题。运营同事看到导出功能一定会多个人同时点再加上自动重试脚本瞬时并发可能到几十。几十个 pandas 任务同时跑每个都在申请大量内存和数据库连接不把连接池打满才怪。这需要你提前设计任务队列、加锁、限流或者用异步任务框架如 Celery串行化处理。第四索引问题。LIKE %关键词%这种模糊查询在 MySQL 里走不上索引只能全表扫。200 万行的表全表扫描一次几秒到几十秒再叠加并发数据库 CPU 直接拉满。一个称职的后端工程师拿到这个需求的第一反应就是导出列表页的筛选条件怎么做索引、模糊查询要不要换方案。AI 给你的就是一版“看起来对但效率极低”的代码。第五业务规则问题。字段脱敏、数据保留期限、权限控制这些隐含规则埋藏在业务逻辑和合规要求里需求文档里不会写AI 也看不到。你能指靠 AI 帮你查漏但最终把关的一定是懂业务、懂领域的“人”。2.3 复盘结论这个项目最终的完整实现其实只靠 AI 生成了约三成代码剩下的全是我的“硬核经验”在补位。AI 帮我把“把代码从 0 写到 1”的时间压缩到了几十分钟但后面的内存管理、并发控制、SQL 优化、索引设计、事务边界、权限校验、日志监控……每一层都需要实打实的技术功底去填坑。换句话说AI 改变的是“打字”的速度不是“思考”的深度。你可以让 AI 代理你的手指但代理不了你的大脑。3. 硬核技术到底硬在哪AI 替代不了的四类能力既然要聊 AI 编程的尽头我们就得把“硬核技术”拆开说清楚它具体指什么、为什么 AI 替代不了。我把它归成四类每一类都对应我在一线踩过的坑和解决过的问题。3.1 数据结构与算法同样一段需求天壤之别的性能很多初学者觉得数据结构与算法是面试造火箭、工作拧螺丝。但真实场景中算法功底直接决定系统能不能扛住流量。举个例子。一个用户标签系统要根据用户 ID 批量查询用户所在的群组再根据群组查群组标签最终聚合出用户标签。如果你用线性遍历每个用户查一遍群组表1000 个用户就是 1000 次查询。如果用户量到 10 万你的接口就得跑几个小时。懂哈希表的人会提前把群组 ID 到用户列表的映射加载到内存做成一个 HashMap然后直接 O(1) 查出每个用户的群组集合再把集合间的并集、交集计算用位运算优化。同样的需求不懂算法的人写出来的代码就是灾难。AI 能帮你写哈希表的代码但“在什么场景下应该用哈希表而不是嵌套循环”这个决策它不会替你拍板。当系统出现性能瓶颈时你更需要的是算法直觉——能预判哪种数据规模下该用哪种数据结构这决定你是“解决问题”还是“制造事故”。3.2 操作系统与网络线上故障时的“透视眼”线上服务崩溃、接口超时、CPU 飙升、内存泄漏这些问题出现时AI 是帮不上忙的。因为诊断这些问题的核心能力是你懂不懂操作系统原理、懂不懂网络协议、懂不懂 JVM/GC、懂不懂 Linux 的排查命令。我做过的另一个项目线上服务每天早上 10 点准时卡顿。AI 分析代码半天也看不出毛病因为问题根本不在代码逻辑而在操作系统的文件句柄泄露——程序每次打开文件都没关闭日积月累把进程的文件描述符耗尽了。排查手段是lsof、/proc文件系统、GC 日志分析最终发现是某个第三方 SDK 的 bug 导致句柄泄漏。这种问题你让 AI 看代码永远找不到根因因为它在语料里“读过”的知识跟你生产环境里实际发生的诡异故障差了十万八千里。再比如 TCP 半连接队列溢出、TIME_WAIT 堆积、网络抖动重传这些线上问题每一个都要求你把 OSI 七层模型、TCP 状态机、Linux 内核参数背得滚瓜烂熟。AI 可以给你背出一堆命令但真正故障发生时是你在台前一步步netstat、ss、tcpdump靠你的“透视眼”定位问题。3.3 数据库与事务数据一致性不是“能查就行”“AI 能写 SQL”这个说法我相信很多人都信了。但实际开发中SQL 只是最底层的一环真正难的是表结构设计、索引设计、事务隔离级别、分布式事务以及最终一致性方案。举个例子。电商下单时要扣库存、生成订单、更新用户积分这三个操作必须保证原子性。最原始的做法是开一个数据库事务把三个操作包进去。但当你发现单库事务扛不住并发时就得拆分库表跨库事务变成分布式事务这时候你要面临的就是最终一致性怎么保证消息队列的重复消费怎么处理幂等表怎么建补偿事务怎么做AI 能帮你写一个BEGIN TRANSACTION包裹的简单类但“什么时候该用 TCC、什么时候该用 SAGA、什么时候该用本地消息表”这种架构决策AI 给不了你答案因为答案藏在你的业务场景、数据量、可用性要求等综合权衡里。我自己带过团队见过太多“AI 觉得没问题”的 SQL大表 JOIN 小表、无索引的 WHERE 条件、把 1 万条数据循环 UPDATE。这些代码在小数据量下跑得欢一到线上就拉胯。数据库设计是数学题不是语文题AI 撑不起来。3.4 编译原理与底层原理代码“行驶的道路”很多前端程序员觉得自己不用懂编译原理反正有 webpack、vite 帮我们打包。但这个观点正在被 AI 时代快速打脸。为什么这么说因为 AI 生成代码的速度越快你越需要理解代码背后的运行机制——你写的 TypeScript 经过哪些编译步骤变成了 JavaScriptTree-shaking 为什么有时候不生效为什么同样的代码在 V8 里性能差 10 倍再往底层看很多人觉得“windows核心编程”、“hdfs编程实践”、“plc编程”这些偏硬核的课程离 AI 时代很远。恰恰相反越底层的知识越难被 AI 替代。AI 可以生成一段 Python 代码但它理解不了 GIL 对并发的影响AI 可以给你一段 Java 代码但它感知不到垃圾回收器 STW 的停顿AI 可以写一个 MapReduce 作业但它看不懂 HDFS 的数据副本机制不知道在数据倾斜时该怎么做程序优化。你会说这些知识不是所有人都会用到。没错但关键在于这些底层能力决定了你在遇到问题时能深入到哪一层。只停留在“会调用 API”的层面等于一个只会按按钮的人出了问题就只能干瞪眼。懂底层原理的人能拆开黑盒找到问题根源。AI 编程的尽头是硬核技术很大程度指的就是这种“往下钻”的能力。4. AI 编程时代的正确姿势让 AI 干活让自己把关聊完了 AI 的边界和硬核技术的定义很多读者可能会问那我到底该怎么用 AI我的答案是四个字定位清晰。AI 是提效工具不是替你思考的大脑。下面分享我在实际项目里的协作方法。4.1 哪些环节 AI 是真的提效我从自己的使用经验出发整理了一份“AI 提效清单”和对应的场景AI 提效场景说明示例样板代码生成CRUD 接口、DTO、配置文件、Dockerfile、CI 脚本这些高度模板化的代码写一个 Spring Boot 的 REST 接口让 AI 先搭好框架单元测试生成给已有函数生成单元测试虽然边界条件自己补但初始覆盖率高给一个工具类生成 JUnit 测试用例脚本编写数据处理、文件整理、日志分析类的一次性脚本Python 脚本批量重命名文件、清洗数据重构成熟模型把一段能跑但写得很烂的代码改成更符合规范的结构让 AI 把 if-else 链改成策略模式概念科普与代码解释让 AI 解释一段不熟悉的代码或者了解不熟悉的技术概念“解释一下 JVM 的类加载机制”这些场景的共同特点是需求明确、产出标准化、容错空间大。AI 在这些场景里效率极高因为我只需要花 10% 的时间检查 AI 的输出比我从零手写快 5 倍以上。4.2 哪些环节必须自己上手反过来说这些环节我基本不依赖 AI或只把 AI 当参考系统架构设计模块怎么划分、服务怎么拆分、数据怎么流转这些决策影响系统未来三年的演进必须自己做。AI 可以给你一个“标准答案”但标准答案不一定适合你的业务规模和团队情况。核心业务逻辑涉及金钱、安全、合规的核心链路每一行代码都要经过严格的评审和推敲。AI 生成的代码可以作为初稿但最终必须有人逐行 Review而且这个人一定要懂业务。线上问题排查故障面前分秒必争你让 AI 分析半天它只是在猜。真正的排查思路是“假设-验证-排除”这个环节靠的是人的经验积累和快速的逻辑推理。技术选型决策用 PostgreSQL 还是 MySQL用 Kafka 还是 RabbitMQ用微服务还是单体这些决策依赖对团队能力、运维成本、生态的全面考量AI 只会在技术维度上给你一个推理想答案对现实因素无感。4.3 一套可落地的“AI人工”工作流我现在做项目的标准流程是这样的供你参考需求分析这部分完全不碰 AI自己写文档把业务规则、边界条件、非功能需求性能、安全、并发列清楚。方案设计AI 辅助。我会把需求喂给 AI让它给我三套技术方案我再结合团队技术栈和部署环境做决策。AI 扮演的是“顾问”角色它帮我打开思路但最终拍板要靠我。代码生成AI 先写初稿生成 80% 的代码骨架和基础逻辑。人工 Review 与补全这是整个流程里最核心的一环。我会逐行检查 AI 生成的代码重点审查边界条件、异常处理、安全性、性能问题。同时补全 AI 缺失的部分参数校验、日志埋点、监控指标、幂等控制。这个过程很难速成恰恰是硬核技术的用武之地。测试与验证让 AI 辅助生成单元测试和集成测试用例但测试用例的边界条件由我自己补充。写缺陷单、回归测试全靠人。部署与监控优化 Dockerfile、配置健康检查、采集关键指标、设置告警这些 AI 可以给建议但最终的执行和验证必须人来。你可以发现AI 出现在第 2、3、5 步但第 1、4、6 步——决定质量的步骤——全部掌握在人手里。AI 再强也只是流程里的“加速器”不是“决策者”。4.4 写提示词的实用技巧别让 AI 猜你想要什么既然要让 AI 干活那写提示词就是基本功。我的经验是给 AI 的提示词越具体越好模糊的需求只会返回模糊的代码。一个实用的公式是角色 目标 输入数据 约束条件 输出格式 反例举例说明你是一名资深 Java 后端工程师。请帮我实现一个订单导出接口。 需求从订单表按创建时间范围导出数据支持分页查询每批 1000 条 输出先写一个 Stream 式读取的工具类再写一个 Controller 和 Service 层代码 注意需要处理数据库连接超时需要防止 SQL 注入字段脱敏规则不在此接口处理 输出格式Java 代码附必要的注释。对比一下“帮我写一个订单导出接口”这种一句话需求结果质量天差地别。重点在“约束条件”和“反例”——你把不想要的东西说清楚AI 才会避开常见的坑。4.5 验证 AI 输出的检查清单最后我每次用 AI 生成的代码都会过一遍检查清单建议你也收藏[ ] 边界条件空集合、最大值、最小值、null、非法格式[ ] 异常处理外部服务超时、数据库断连、文件不存在[ ] 并发安全共享变量、线程池、资源释放[ ] 性能隐患循环内查询数据库、全表扫描、内存泄漏[ ] 安全性SQL 注入、XSS、路径穿越、敏感数据泄露[ ] 可维护性命名规范、模块边界、注释清晰[ ] 依赖管理依赖注入是否合理、是否需要升级版本如果 AI 生成的代码在这些检查项里全部通过你才敢把它合进主干。否则就要回到第 4.3 节的第 4 步人工兜底。5. 给新手的路线图AI 时代该怎么学编程聊了这么多肯定有很多小伙伴问那我在 AI 时代到底该怎么学编程是不是可以直接跳过基础课直接用 AI 生成代码我的答案很明确不行且恰恰相反。5.1 别被“人人都是 AI 程序员”带节奏短视频里那种“人人都是 AI 程序员”的标题本质是割韭菜的流量密码。你去知识付费平台搜一下铺天盖地的“AI 编程速成”“零基础用 AI 做网站月入十万”课程。真正靠这些赚钱的人不是卖课的就是做流量 IP 的。真让他们拿 AI 去交付一个企业级项目他们大概率连灰度发布、监控告警、降级熔断都一头雾水。我认识不少做程序员接单平台的人。前两年接单还是靠人海战术现在大家都会用 AI 提效了反而更卷了。为什么因为 AI 把低价重复劳动力的门槛拉平了谁都能用 AI 快速交付“从 0 到 1”的项目但能做好“从 1 到 100”的人依然稀缺。真正稀缺的还是那些能解决复杂问题、能扛住线上故障、能设计高可用架构的人——而这些能力恰恰不是 AI 能给你的。所以别用战术上的勤奋掩盖战略上的懒惰。你花 100 个小时学怎么给 AI 写提示词不如先花 100 个小时把数据结构与算法、操作系统、计算机网络、数据库原理这些硬核基础啃下来。提示词只是放大器你本身的实力才是底数。底数是 0放大器再强结果还是 0。5.2 学习路径建议先打地基再谈 AI那么具体怎么学我推荐一条务实的路径分三个阶段第一阶段死磕基础6-12 个月《Java 基础入门》或 Python 入门选一本经典教材系统地啃不要跳着学数据结构与算法掌握数组、链表、栈、队列、哈希表、树、图、排序、二分、动态规划操作系统进程线程、内存管理、文件系统、IO 模型计算机网络TCP/IP、HTTP、HTTPS、DNS、负载均衡数据库SQL 语法、索引原理、事务、锁、范式设计这个阶段你会觉得痛苦因为看不到成果。但相信我这是你以后能“接住”AI 的底层能力。现在很多“软考初级程序员”的考点其实就是这些基础考下来既是对自己能力的证明也能倒逼自己系统学习。第二阶段工程实践6-12 个月选择一个方向深入后端 Java/Go、前端 React/Vue、大数据 Hadoop/Spark自己动手写项目可以借助 AI 提效但每行代码都要看懂学习 Linux、Git、Docker、CI/CD 这些工程化工具尝试部署自己的服务观察日志处理线上问题这个阶段 AI 是一个很好的教练但你要让它“解释”而不是“代劳”。遇到不懂的概念让 AI 给你讲原理、举例子而不是直接让它帮你写代码。写代码之前先在纸上画出模块图、画出数据流向再让 AI 帮你实现。第三阶段深化领域持续进行深入一门语言/框架的底层源码学习分布式系统、微服务架构、消息队列、缓存关注行业方向大数据、云原生、AI Infra 这些领域依然需要大量硬核工程师建立自己的技术博客或知识库持续输出沉淀这三个阶段走完你再回头看 AI 编程会发现它只是一个帮手而不是救世主。你会清楚地知道哪些环节可以放心交给 AI哪些环节必须自己死磕。5.3 关于“硬核技术”的最后一个观察说了这么多我还想从另一个角度聊聊“硬核”。硬核不只是数据结构、操作系统这种计算机科学知识它还包括一种更务实的工程素养责任心、判断力和质量意识。AI 生成 100 行代码只花了 10 秒但这 100 行代码从“能跑”到“可靠”依然需要人来负责。谁负责程序员。什么时候加班线上出故障时。AI 可以帮你 10 倍速写代码但线上 2 点的故障电话可不会因为“这是 AI 写的代码”而少打一个。所以我特别想对刚入行的朋友说别幻想“会用 AI 会编程”也别因为“人人都是程序员”的口号而焦虑。AI 不会让程序员这个职业消失它只会淘汰那些只会搬砖的“代码搬运工”留下那些真正具备硬核技术的人。这个逻辑不会变。如果你愿意不妨从今天开始选一本经典教材翻开第一页。哪怕只学一章你也是在为 AI 时代的硬核之路打地基。这东西谁也抢不走。