AI辅助编程的边界——Cursor实战与工程判断力

前言在蚂蚁集团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(){intindexcounter.getAndIncrement()%endpoints.size();returnendpoints.get(index);// 如果 endpoints 为空呢}// 我加的边界处理publicApiKeyEndpointnext(){if(endpoints.isEmpty()){thrownewNoAvailableEndpointException(所有API KEY不可用);}intindexcounter.getAndIncrement()%endpoints.size();returnendpoints.get(index);}AI的代码在正常情况下完全正常。但如果在健康检查摘除了所有故障节点后endpoints为空getAndIncrement() % 0会抛出ArithmeticException。AI很少主动考虑如果什么都没有怎么办。这是人的工作。陷阱二异常吞没// AI生成的API调用代码try{StringresponsewebClient.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给出的答案是对是错、在什么场景下适用、什么场景下需要换个方案