ARTICLE · 1193616
AI 30秒写完一个订单接口,为什么我却不敢合并上线
既然生成式 AI 已经能写代码、补单测、查日志，甚至能作为 Coding Agent 在整个仓库里跨文件重构，那过去分配给初级开发者的工作还剩多少？未来的工程师到底该怎么成长？《Junior Developer in the Age of AI》
这两年做业务研发、系统架构，也在不断尝试 Cursor、Claude Code 等工具。用得越多，越能体会到：代码写得快了，需求理解、方案取舍和交付把关上的功夫，一点也省不下来。
我想结合这些体会，分三期和大家聊聊 AI 时代软件工程的变化。今天这第一篇，先从一个普遍的困惑说起：当写代码变得越来越快，为什么做出一套“好软件”依然那么难？
01代码廉价了，但“好软件”没有
在计算机工业的历史上，工具的演进从未停止过。
高级语言取代了汇编和机器码，Spring、Vue 等现代框架把我们从繁琐的底层 API 和 DOM 操作中解放出来，云计算抽象了物理机房，DevOps 则把打包部署变成了自动化流水线。
生成式 AI 与以往工具的一个明显区别，是它开始直接参与任务的执行。
过去，无论是 IDE 的快捷操作，还是 MyBatis-Plus 这样的代码生成器，主要都是帮助我们更高效地执行开发任务，具体步骤仍然由开发者推进。
今天的生成式 AI 与 Coding Agent，已经可以直接接手其中一部分任务。
给它一个目标，它能自己检索工程目录、分析调用链路、跨十几个文件修改源码、在终端运行测试套件，再根据报错继续修复。
这正在改变软件开发的成本结构：生成“代码”所需的时间和成本，都在下降。
但在真实项目里，我们也看到：团队写代码的速度确实快了好几倍，可线上的故障率并没有因此大幅下降，复杂业务系统的交付仍然磕磕绊绊。为什么？
因为生产“代码”的成本暴跌，绝不等于生产“好软件”的成本也同步暴跌。
代码承载实现，软件最终要交付业务价值。一套能在生产环境里可靠运行的软件，要解决实际的业务问题，在硬件和预算约束下运行，还要保护核心数据、应对网络抖动与并发冲击，并保持长期可维护。
当“生成代码”变得极度廉价时，真正变得昂贵的，是代码之外的工程判断力。
02从“写代码”到“做工程”：一个订单接口的灵魂八问
在过去很长一段时间里，我们默认的开发者成长路径是线性的：先学一门语言的语法，做几个 CRUD 的小项目，进公司后从修简单 Bug 开始，接着独立写业务接口，在日常编码中积累经验，逐步接触更大的系统。
这条路径成立的核心前提是：“把逻辑翻译成代码”是整个研发流程中最大的产能瓶颈。那时候，团队需要大量初级开发者作为“人肉编译器”，把需求文档变成一行行 Java、Python 或 TypeScript。
AI 正在改变这个前提。当“翻译代码”不再是主要瓶颈时，过去被实现工作掩盖的工程问题，就更容易显现出来。
举一个我们在日常研发中再熟悉不过的场景。假设产品经理提了一个需求：
“帮我开发一个订单管理系统的 API。”
如果把这个需求扔给现在的 AI 编程工具，它能在 30 秒内生成一套包含 Controller、Service、数据访问层的完整代码，甚至连文档注解都能一并生成。初看之下，以前两三天的工作量被压缩到了半分钟。
但这段代码你敢直接 Merge 到主干分支上线吗？绝对不敢。因为这个需求还有太多关键信息没有交代。
在真实的生产环境里，面对“订单系统 API”这几个字，一个有经验的工程师至少会追问下面 8 个问题：
用户点击“取消订单”时会发生什么？如果订单已经支付成功了，还允许直接取消吗？
库存是在什么时机预占或扣减的？下单锁库存，还是支付成功才扣库存？
如果第三方支付渠道回调成功了，但本地数据库更新订单状态失败了（俗称“掉单”），怎么保证最终一致性？
如果客户端因为网络抖动，连续发送了两次一模一样的下单请求，接口的幂等性（Idempotency）怎么保证？
谁有权限取消订单？普通买家、商家客服，还是系统的超时自动关单任务？它们触发的状态机流转规则一样吗？
退款怎么处理？原路退回还是退余额？部分退款时优惠券怎么分摊？
当外部支付网关响应超时（Timeout）时，系统应该立即报错、同步重试，还是丢进消息队列异步轮询？
面对大促峰值流量，数据库行锁扛不住怎么办？
回头看这 8 个问题，没有一个是在问“语法怎么写”或者“框架注解怎么配”。它们都是软件工程问题。
这些问题涉及具体的工程设计与业务权衡：高并发防超卖机制、分布式事务与对账补偿、接口防重设计、复杂状态机建模，以及细粒度的权限控制和越权防护。
AI 可以迅速给你生成一个“能编译通过的答案”。但这个答案是否适合当前业务，能否满足实际约束，还需要结合上下文逐项判断和验证。
为了看清这两者的本质差异，我们可以做个直观的对比：
AI 越擅长写代码，Coding（编码）与 Engineering（工程）之间的差别就越明显。只把需求文档机械翻译成代码，已经很难体现开发者的价值；定义边界、控制复杂度的能力，会变得更重要。
03AI 是能力的放大器，也是愚蠢的放大器
每当讨论 AI 对程序员的冲击，最常见的问法就是：“AI 会取代开发者吗？”
这个问题很难用“会”或“不会”回答。一份研发工作拆开来看，包含许多不同性质的任务。AI 对它们的影响各不相同，也在改变软件工程内部的任务分工。
在这个过程中，AI 同时扮演着两个角色：自动化与增强。
当你让 AI 自动生成样板代码、转换数据格式、编写常规单测，或者在庞大的代码库里检索定位时，这属于自动化，可以省下不少重复操作的时间。
当你面对一个复杂的架构演进难题，让 AI 生成三种备选方案，并要求它列出各自的迁移成本、回滚风险和性能瓶颈供你拍板时，这属于增强，可以帮助你比较方案，检查有没有遗漏的风险。
“AI 变强了，对人的技术要求就变低了”，这种看法很常见。但在实际研发中，AI 更像一个“能力乘数”，使用者的工程判断会直接影响结果。
同样的模型，交给工程经验不同的人使用，结果可能相差很大：
一个懂数据库底层原理的工程师，可以借助 AI 分析复杂的 SQL 执行计划，排查索引失效与锁竞争；缺乏相关经验的新手，则可能直接把 AI 生成的 SQL 用到生产环境，没有发现全表扫描或隐式类型转换等风险，导致慢查询堆积，甚至耗尽数据库连接池。
一个懂安全架构的工程师，可以用 AI 快速审计代码中的越权漏洞与注入风险；缺乏安全意识的人，则可能在加快提交代码的同时，也把更多安全隐患带进主干分支。
AI 不仅是人类工程能力的放大器，它同时也是人类工程盲区与错误决策的放大器。
打个比方，如果把 AI 看作乘数 100，当你的工程底座是 1 时，你的产出能放大到 100；但如果你的工程判断力是 -1，AI 就会以百倍的效率帮你制造出一场 -100 的线上灾难。
04新的研发瓶颈：你真的“理解”要构建什么吗？
按照约束理论的思路，当写代码这一环节明显提速，原来不突出的环节就可能成为新的瓶颈。
在 AI 辅助研发的过程中，越来越多的时间需要花在“真正理解并清晰定义到底要构建什么”上，“怎么写出来”已经不再是唯一的难题。
在日常带团队或评审需求时，我们经常听到类似这样的模糊指令：
“这个数据看板（Dashboard）加载太慢了，用 AI 优化一下代码。”
如果你把这种模棱两可的话直接扔给 AI，它可能会加上本地缓存、改写 SQL，甚至建议你引入一套复杂的预计算框架。但这些改动很可能完全偏离了实际场景。
一个具备工程素养的开发者，会先把这句抱怨转化为一条可量化、可验证的工程规约：
“在预期的生产高峰负载（QPS 500，核心单表 2000 万行数据）下，该看板聚合接口的 P95 响应时间必须控制在 2 秒以内，业务上允许最多 5 分钟的数据延迟。”
问题定义到这个程度，技术方案就有了比较的依据。既然业务允许 5 分钟延迟，就可以考虑 Redis 短时缓存或定时刷新的物化视图，不必只盯着实时大表 Join 调优。能否达到目标，再通过测试验证。
问题定义得是否清楚、提供的上下文（Context）是否充分，都会直接影响 AI 的输出质量。
为什么很多人抱怨 AI 写出的代码“驴唇不对马嘴”，或者“改了一个 Bug 又引出三个新 Bug”？除了模型本身的能力限制，一个常见原因是业务边界还没有想清楚，就把一句模糊的要求交给了 AI。
当 AI 能快速给出技术建议时，我们更需要判断该问什么，以及回答是否适用：
怎么区分业务方嘴里的“表面症状”与真实的“底层根因”？
怎么把产品经理脑子里认为“理所应当、不用写进文档”的隐含假设全部挖出来？
怎么在动手写第一行代码前，明确定义什么叫做“完成”？
05写在最后
回头看这些变化，很多过去容易被编码工作掩盖的问题，如今都需要认真面对。
过去，繁琐的 CRUD 样板代码占据了大量时间。“我今天敲了 1000 行代码、很忙很充实”，很容易让我们把编码工作量当成职业安全感的来源。
现在，AI 接手了一部分机械的编码工作，我们也需要把更多精力放到理解业务、定义问题、权衡架构，以及为系统运行兜底上。
那么，新的问题来了：
既然“定义问题”和“提供工程上下文”成了新的研发瓶颈，我们在日常写业务、做设计时，到底该如何告别低效的“提示词玄学”，建立起一套结构化的 AI 工程工作流？面对能力越来越强的 Coding Agent，有经验的工程师又是如何给 AI 派活、划定禁区并做验收把关的？
下一篇，我们就来聊聊“规约工程”与“上下文工程”，以及“AI 任务派发五要素模型”。
AI 探索不迷路，关注我不走弯路
