前言
在蚂蚁集团AI Coding笔试中，我用Cursor在1小时内完成了一个大模型推理网关的完整实现。坦白说，如果没有AI辅助，这个速度我做不到。但面试官可能会追问一句：“既然AI这么厉害，那程序员的价值在哪？”
这是一个非常好的问题。经过几个月的AI辅助开发实践，我有了一些自己的思考。这篇文章不讲"怎么用Cursor"，而是讲"什么时候该用、什么时候该停、以及为什么AI不能替代工程判断"。
本文核心问题：
- Cursor在你的开发流程中扮演什么角色？代码生成 vs 代码Review？
- 什么时候让AI写，什么时候必须自己写？
- AI生成的代码有哪些常见坑？举几个具体例子
- "1小时完成推理网关"这件事，AI帮了多少？人做了哪些决策？
- AI辅助开发的核心能力是什么？
- 未来AI会替代初级程序员吗？你的判断是什么？
一、AI在我开发流程中的真实位置
疑问：你用AI写代码，那你自己还写什么？
回答：我写的是"定义问题"和"做决策"，AI帮我完成的是"实现细节"。
1.1 一个典型的工作流
我：设计网关架构 → 画架构图 → 确定各层职责 → 定义接口 ↓ AI：根据我的设计生成Controller、Service层的基础代码骨架 ↓ 我：Review → 修改配置和参数 → 添加边界判断 → 补充异常处理 ↓ AI：生成单元测试用例 → 生成压测脚本 ↓ 我：跑用例看覆盖率 → 分析哪些测试是有效的，哪些是凑数的 ↓ AI：生成文档和配置说明 ↓ 我：检查是否有过时描述 → 发布AI做了大约60%的工作量，但做了0%的决策。
1.2 AI擅长什么？不擅长什么？
| AI擅长 | AI不擅长 |
|---|---|
| 生成CRUD代码 | 理解业务需求 |
| 转换技术栈（如把Java代码转成Go） | 判断哪个技术栈更适合当前场景 |
| 补充注释和文档 | 判断什么值得注释，什么不值得 |
| 生成测试用例 | 判断什么场景应该测，什么不用测 |
| 解释报错信息 | 从一堆报错中定位真正的根因 |
| 写出多种实现方案 | 在多个方案之间做取舍 |
模式很清晰：AI擅长"怎么做"，不擅长"做什么"和"为什么"。
二、什么时候让AI写，什么时候必须自己写？
疑问：有AI了，是不是所有代码都让它写？
回答：恰恰相反。越关键的代码，越不应该让AI写。
2.1 我的判断框架
代码重要程度 高 低 ┌─────────┬─────────┐ 核心逻辑 │ 自己写 │ AI+审查 │ ├─────────┼─────────┤ 非核心 │ AI+审查 │ 全让AI │ └─────────┴─────────┘自己写：核心业务逻辑、涉及钱和安全的代码、复杂的状态机转换。这些代码一旦出错，AI无法帮你定位根因。
AI写+严格审查：代码骨架、工具类、配置类、单元测试。AI生成后需要逐行验证逻辑正确性。
全让AI写：文档、脚本、格式化代码、重复性模板代码。出错影响可控，效率收益最大。
2.2 一个反例：让AI写分布式锁
在秒杀项目中，我试过让AI生成"Redis分布式锁"的代码。它输出了一份看起来很专业的实现，包含setnx、过期时间、异常释放。
但我发现三个问题：
- 它没有处理锁续期——如果业务执行超过锁过期时间，锁会被自动释放，其他线程可能拿到锁
- 它用
del释放锁，没有检查锁是否属于当前线程——可能把别人的锁误删 - 它没有考虑Redis主从切换时锁丢失的问题
这些问题AI都"不知道"——因为它只是生成了网上最常见的分布式锁实现。网上的代码大多数是Demo级别的，根本不考虑极端情况。这段代码如果是初级程序员写的，我还能理解。但如果我作为Reviewer放过了它，就是我的问题。
2.3 一个正例：让AI写网关骨架
推理网关的application.yml配置、Spring Boot启动类、Controller层的基础注解——这些都是标准化、重复性高的工作。让AI生成后，我只需要检查几个关键配置项（端口、超时时间、Nacos地址），几分钟就能完成。这些地方用AI，省下的时间可以用来仔细设计限流算法和健康检查策略。
三、AI生成代码的三个典型陷阱
疑问：AI的代码看起来都挺对的，怎么判断它有没有问题？
回答：AI生成的代码有三个高频陷阱——看起来对、跑起来也正常、但极端情况下会炸。
陷阱一：边界条件缺失
// AI生成的负载均衡代码publicApiKeyEndpointnext(){intindex=counter.getAndIncrement()%endpoints.size();returnendpoints.get(index);// 如果 endpoints 为空呢？}// 我加的边界处理publicApiKeyEndpointnext(){if(endpoints.isEmpty()){thrownewNoAvailableEndpointException("所有API KEY不可用");}intindex=counter.getAndIncrement()%endpoints.size();returnendpoints.get(index);}AI的代码在正常情况下完全正常。但如果在健康检查摘除了所有故障节点后，endpoints为空，getAndIncrement() % 0会抛出ArithmeticException。
AI很少主动考虑"如果什么都没有怎么办"。这是人的工作。
陷阱二：异常吞没
// AI生成的API调用代码try{Stringresponse=webClient.post().uri(endpoint).bodyValue(request).retrieve().bodyToMono(String.class).block();returnresponse;}catch(Exceptione){log.error("调用失败",e);returnnull;// 返回null，调用方不知道发生了什么}调用方拿到null，不知道是因为超时、限流、KEY过期还是网络抖动。它只能展示"系统繁忙"。排查时看日志，看到的只有"调用失败"四个字，不知道哪个KEY、什么原因。AI的异常处理通常是"打日志+返回空值"，但真正的工程需要把异常分类、分级、传播到正确的处理逻辑中。
陷阱三：配置硬编码与占位符残留
// AI生成的配置openai:api-key:sk-your-api-key-here # ← 如果忘了改，代码跑不起来 timeout:30s # ←30秒对生成500字回答的场景来说可能不够AI不知道这个网关部署在哪个机房、到OpenAI服务器的平均延迟是多少、500字回答通常需要多长时间。它只能给一个它从训练数据中见过的常见值。但真实环境中，每个配置值都代表一个设计决策。30秒还是60秒，取决于你观察过多少次超时、后端API的P99响应时间分布、以及你的用户对超时的容忍度。
四、"1小时完成推理网关"的真相
疑问：你说AI帮你1小时完成了网关，那你自己做了什么？
回答：那一小时里，AI写了大约70%的代码，但我做了以下几个AI做不了的决策。
4.1 时间分配
| 时间 | 我做了什么 | AI做了什么 |
|---|---|---|
| 0-10min | 设计架构图，确定各层职责 | — |
| 10-25min | 定义接口和数据结构 | 生成Controller和实体类 |
| 25-40min | 设计限流和负载均衡算法 | 生成算法的代码骨架 |
| 40-50min | 补充异常处理和边界判断 | 生成配置文件 |
| 50-60min | 检查所有代码，修复3个边界问题 | — |
AI写的代码不是"直接用"，而是"先过筛"。每一段AI生成的代码，我都要问自己三个问题：空值会进来吗——如果endpoints为空、如果request的某个字段缺失，这段代码会怎样？超时之后呢——如果后端慢到30秒还没返回、如果重试时KEY已经到了限流阈值，处理逻辑对吗？错误去哪里了——如果这个异常被吞了，上层能知道发生了什么吗？
4.2 我做的三个关键决策
决策一：限流算法选滑动窗口而非令牌桶
AI给出了两种都用上的建议。但我判断这个网关不是流量入口，而是API保护层。滑动窗口更精确、实现更简单，且能精确统计窗口内请求数用于后续的配额分析。令牌桶多出来的弹性突发能力在这个场景中没有实际收益。
决策二：健康检查用主动探测而非被动标记
AI建议"根据请求失败来判断KEY不可用"。但这意味着故障的KEY在被探测到之前，可能已经接受并浪费了多个用户请求。主动探测虽然消耗极少的Token，但能让故障KEY在几秒内就被隔离——主动探测的成本远小于被动发现的损失。
决策三：负载均衡用权重轮询而非最少连接
AI默认用最少连接数。但大模型API的"负载"不是连接数——一个请求可能生成10个Token，也可能生成500个Token，连接数体现不出实际的配额消耗。权重轮询直接按KEY配额比例分配，哪个KEY额度多就多分一些，最直接也最公平。
五、AI辅助开发的核心能力是什么？
疑问：如果AI写代码越来越强，程序员的核心竞争力是什么？
回答：不是写代码的速度，而是"定义问题"和"做取舍"的能力。
5.1 定义问题——AI需要你告诉它"要解决什么"
❌ 模糊的Prompt： "帮我写一个网关" → AI会输出一个通用网关，可能用Spring MVC，不加限流，不处理异常 ✅ 精确的Prompt： "写一个面向大模型API的HTTP网关，使用WebFlux响应式编程， 支持以下功能：多API KEY的权重轮询负载均衡、滑动窗口限流、 健康检查自动摘除、故障注入测试。先设计接口结构，再逐一实现。" → AI需要的信息都在这里了 两个Prompt的差距，就是你会不会定义问题的差距。5.2 做取舍——AI给方案，你选方案
AI能告诉你"滑动窗口和令牌桶的算法原理"，甚至能给出两种方案的对比。但它判断不了当前场景该选哪个。这个判断需要你理解系统的核心瓶颈、分析各方案在本场景下的适配度和弊端的容忍度、最终在多个合理选项中做出选择并对结果负责。
5.3 审查力——你永远要为AI的代码负责
代码是谁写的，谁就要为它的行为负责。如果你让AI生成代码并直接合并上线，一旦出问题责任在你——公司不知道这段代码是AI写的，只知道是你提交的。审查力，就是你发现代码中潜在问题的能力，也是AI时代最被低估的核心技能。
六、AI会替代初级程序员吗？
疑问：你的判断是什么？
回答：不会替代"愿意思考"的初级程序员，但会淘汰"只会执行"的。
6.1 AI改变了什么？
AI把程序员从"翻译机器"中解放出来——以前你需要自己把需求翻译成代码，现在AI可以帮你做这件事。但需求本身仍然需要人来理解、拆解和验证。
以前，从需求到代码的转换是由程序员手动完成的。现在AI加速了中间的编码环节，写代码的时间缩短了，但理解需求、设计架构、测试验证这些事仍然完全依赖人的判断。编码本身从来都是成本，不是价值。价值产生在编码之前——理解问题、设计方案、做取舍；价值验证在编码之后——测试、审查、优化、维护。AI让中间的实现成本趋近于零，但无法替你做开头和收尾。
6.2 什么人会被淘汰？
只会"把需求翻译成代码"的人会被淘汰。AI做翻译的速度和准确度已经超过大多数初级程序员。如果你的核心竞争力是"我写CRUD写得快"，AI的威胁是真实存在的。
但AI永远代替不了"能定义问题、做取舍、判断合理性"的人。AI能提供答案，但对真正复杂的工程问题，AI的答案缺少上下文适应性和边界判断。你需要懂到能判断AI的答案是对是错的程度，你需要知道在特定场景下哪个方案更合适、为什么。而这些能力，靠的从来都不是写代码本身——是写过很多错误代码后的反思，是系统出过故障后的排查经验，是见过不同架构后的比较和总结。
总结
- AI的角色是"执行者"，不是"决策者"。它完成60%的工作量，但做0%的决策
- 越关键的代码越不能全交给AI。核心逻辑自己写，标准化工作交给AI。错误不在AI，在使用AI的人
- AI生成代码的三个陷阱：边界条件缺失、异常被静默吞没、配置值是占位符。每一个都需要人来发现和修复
- "1小时完成网关"不是魔法——AI写代码，人做决策。限流算法选什么、健康检查怎么做、负载均衡怎么分——这些AI给不了答案
- AI辅助开发的核心能力：定义问题（让AI知道要解决什么）、做取舍（在AI给的方案中选择）、审查力（为AI的代码负责）
- AI不会淘汰"思考者"，但会淘汰"执行器"。初级程序员的核心任务是尽快从执行者成长为思考者——不只是会用AI，而是能判断AI给出的答案是对是错、在什么场景下适用、什么场景下需要换个方案
