如果你正在用 AI 写代码已经写了三到四个月大概率会碰到一个奇怪的时刻工具还是那个工具模型还是那个模型但它生成的东西越来越“不对味”。半个月前还是神兵利器现在却要反复修改、删掉重写。不是你的操作方式变了也不是 AI 变笨了而是你正在进入 AI 编程真正困难的阶段。AI 写代码这件事最容易被误解的地方就在这里前三个月的“爽”不是 AI 的上限而是你的项目复杂度还没到暴露问题的临界点。一旦代码库膨胀、业务规则变多、多人协作开始交叉AI 生成代码的边际收益会快速下降甚至会变成负收益。这篇文章想认真聊一聊AI 写代码爽过三个月之后到底会发生什么。不是劝退也不是无脑吹捧而是从工程实践的角度把 AI 编程从“个人效率工具”转向“团队工程能力”这条路上真正要面对的问题、边界和方法梳理一遍。如果你刚开始用 AI 写代码这篇文章能帮你提前避开几个大坑如果你已经用了三个月正在陷入“AI 生成→我不满意→我改说明词→再生成→还是不对”的循环这篇文章应该能解释为什么。1. AI 写代码的“三个月定律”先说一个观察大量 AI 编程工具的深度用户都逃不过一个时间尺度大约三个月。第一个月你会用它写脚本、写工具函数、写 demo、写 LeetCode 风格的小算法。这个阶段 AI 表现非常惊艳因为你给的上下文足够小任务足够独立。生成结果稍微改改就能跑甚至直接跑通。第二个月你会开始让它接手业务模块用户管理、订单状态机、支付回调、权限校验。这个阶段你发现它开始“有主见”了会生成你自己都没想到的边界逻辑也会在一些不该秀操作的地方秀操作。但整体上还可以接受因为你心里清楚每个模块的上下文边界。第三个月情况开始变化。代码库已经有几万行到十几万行跨模块的依赖关系变得复杂。你让 AI 改一个接口的实现它会根据“项目里其他地方的同类代码”推断出一些不存在的约定。你让它新增一个功能它会用三年前的写法模拟因为训练数据里那个模式最常见。你开始频繁地跟它复述需求它频繁地忘记你两轮对话前强调过的约束。这个阶段最典型的情绪是焦虑不是焦虑 AI 会替代你而是焦虑自己是不是哪里操作不对怎么 AI 越用越难用了。其实你没有做错什么。真正的原因是AI 编程的瓶颈正在从“能不能生成代码”转移到“能不能正确理解一个复杂系统的现状”。第一代 AI 编程工具解决的问题是“单点生成”给我一个函数签名我帮你填充函数体。它的能力边界在函数和类这个粒度。到了第三个月你真正需要的不是“单点生成”而是“跨文件理解”——你需要 AI 知道订单模块的状态机、用户模块的字段定义、支付回调里那个奇怪的重试逻辑、以及上周刚加的灰度开关分别在哪里。这不是 Prompt 能简单解决的而是需要整个工程链路重新设计。所以把前三个月的快感归结为“工具强”是一个常见的误判。更准确的描述是前三个月的快感来源于你把项目复杂度控制在了 AI 的理解能力之内。问题从来不是“AI 能不能写代码”而是“你所在的代码库复杂度是否已经超出了 AI 的上下文和推理边界”。理解这一点你就明白为什么接下来要聊的那些坑不是靠换一个更强模型就能绕过去的。2. 核心问题AI 把成本转移到了哪个环节很多团队引入 AI 编程后的第一个季度会明显感觉到“写代码变快了”。但如果你把视角拉长用研发全流程来看会发现成本并没有消失而是发生了转移。传统开发模式中最大的成本集中在“编写”和“调试”。程序员花大量时间敲代码、编译、跑测试、看日志。AI 编程下来之后“编写”这一环的成本被大幅降低但“理解”和“验证”的成本被急剧拉高。过去你写一个函数写完你会自然知道它做了什么因为你是从零开始推演出来的。现在 AI 写了一个函数你需要读懂它的实现确认它是否符合业务预期检查它有没有引入隐藏副作用。过去你改一个模块你会顺带记住模块之间的关系。现在你让 AI 改完一个模块它不会自动把受影响的两个调用方改掉也不会主动提醒你缓存策略已经失效。这就像你以前自己做饭虽然累但你知道每道菜放了多少盐。现在你请了个大厨帮你切好菜配好料你只需要下锅炒。表面上看你省了切菜的时间但你炒之前得先检查他配的料对不对。遇到怪味还得倒回去查他放了什么。在软件工程里这个转移可以用一句话概括AI 降低了“生产代码”的成本却没有降低“理解代码”的成本反而因为生成的代码不是你亲笔写的理解成本变得更高了。另一个被忽略的成本是“信任成本”。当你连续遇到几次 AI 生成了看起来很对、实际有 bug 的代码之后你会下意识地检查它的每一行输出。这种检查比你自己写代码还累因为你自己写的时候思路是连续的而看 AI 写的代码你是在判读一个陌生人的逻辑。这个阶段特别容易让团队产生一种错觉“AI 写代码效率就是不行。” 其实不是不行而是团队还没有建立起一套适配 AI 编程的“校验流程”。没有校验流程AI 的输出质量就是不可控的不可控就意味着你要用更多的注意力去兜底最终总成本反而上升。所以要不要长期用 AI 写代码本质上不是一道“效率题”而是一道“工程管控题”。你需要回答的是你有没有一套机制让 AI 产出代码的质量可以快速验证让错误可以被低成本兜住。如果答案是否定的那么 AI 写代码的收益就只会停留在“个人玩具”和“原型验证”层面无法变成团队级的研发效能。3. AI 写代码不可忽视的安全边界提到安全边界很多人第一反应是“AI 生成的代码有没有漏洞”。这当然重要但更常见、更容易踩到的安全坑往往不在代码里而是在 AI 编程工具的“工作方式”里。第一类风险代码与数据的隐私泄漏。现在很多 AI 编程工具默认会把代码内容发到云端模型服务用来生成补全或修改建议。如果你的项目涉及商业机密、金融数据、未公开的产品策略又或者你所在的公司有严格的数据合规要求那么直接把整个代码库开放给 AI 工具本身就是一次安全事故。更隐蔽的是有些 AI 编辑器插件会在后台自动收集光标附近的代码片段哪怕你没有主动发起 AI 请求它也在悄悄地工作。你很难感知到但代码的“上下文”已经被传输出去了。这里不是要否定云端 AI 编程工具而是要提醒一个原则代码片段是否允许出网应该由公司策略决定而不是由开发者个人的便利性决定。如果项目处于保密阶段优先考虑私有化部署模型、使用企业版白名单功能或者在网络边界上做一层代理只允许经过脱敏的代码进入模型服务。第二类风险生成的代码引入不可控依赖。AI 模型训练数据里包含了大量真实开源项目的代码在生成代码时它会“顺手”引用一些库、函数、API有时还会给出生僻的依赖坐标。这些依赖可能来自不权威的仓库可能存在版本冲突甚至有极小概率被恶意投毒——即攻击者故意在训练数据里埋入带漏洞的代码诱导 AI 生成并让开发者引入。从工程实践角度这里最有效的防线不是靠 AI 厂商自己去过滤而是要在开发流程里强制加入两件事依赖来源审查和依赖漏洞扫描。任何由 AI 生成代码引入的新依赖都必须像人工写的代码一样进入正常的依赖审查流程。第三类风险凭据与密钥。AI 生成代码时最容易出现的“危险品”是硬编码的 API Key、数据库连接串、第三方服务的 Secret。原因很简单训练数据里有大量这类样例模型生成时觉得这是“常见模式”。你如果习惯性地用 AI 生成配置类代码很可能就在某个配置文件里埋下了一个真实可用的密钥。所以凡是由 AI 生成的代码提交之前必须做一次纵深搜索检查有没有类似password、secret、api_key、token的字段以及这些字段的赋值是否来自环境变量。不要把这一步省略掉因为在 AI 时代“看到代码就以为它安全”的直觉已经不成立了。4. 从“代码生成器”到“结对工程师”工作方式的转变如果你已经过了三个月的蜜月期下一步最应该做的不是寻找“更聪明的补全工具”而是重新定位 AI 在你工作流中的角色。很多人把 AI 当成一个“代码生成器”我提需求你给我代码然后就完了。这个模式在简单任务上很快但一旦进入复杂项目就成了灾难。因为你把 AI 当成生成器时你其实是把“需求分析、设计约束、可行性判断”全都压在自己的脑子里AI 只是你的打字员。当这个打字员疯狂输出之后你要检查的文字量远远超过手写时代于是你成了它的校对员。真正有效的用法是把它当成一个“结对工程师”。你们不是上下级关系而是合作者。你要做的不是给它指令而是跟它一起梳理上下文。举个例子。你让 AI“给用户中心加一个修改手机号的功能”这是生成器模式。结对模式则是先告诉它“用户表中phone字段是唯一索引修改时需要事务保护短信验证码校验在SmsCodeService里历史变更需要记录到UserPhoneChangeLog并且修改后要清理手机号相关的缓存键”。这样 AI 生成的代码才是基于项目真实约束的产物而不是模型训练数据里的“平均味道”代码。这个转变意味着你的 Prompt 不再是“帮我写个 XX”而是变成了一个类似“需求文档片段 技术约束列表 验收标准”的组合。而这个东西其实比 AI 本身更能决定产出质量。这里有一个很多人忽略的细节AI 不懂你的代码库除非你把它应该知道的东西喂给它。哪怕是最强的模型如果没有给它数据库表结构、缓存策略、异常处理规范、团队命名风格它也只能按“通用最佳实践”来生成。通用最佳实践没有错但它很容易成为你们代码库里第一个风格不一致的“异类”。所以从三个月往后你真正要投入精力打磨的不是“怎么能让 AI 写得更多”而是“怎么把上下文整理得更清楚”让 AI 在你限定的边界内发挥。这个技能业内通常叫“上下文工程”它是 Prompt Engineering 的下一代形态。下面是两个可以直接落地的角色转型方案。4.1 用 AI Assistant 规则文件固定项目上下文无论你用 Cursor、Cline、Continue 还是其他 AI 编程工具强烈建议在项目根目录维护一个 AI 规则文件例如CLAUDE.md或.cursorrules。内容是把项目里“人知道但 AI 不知道”的约定写下来。# 项目技术栈 - 语言Java 17 - 框架Spring Boot 3.2.x - 数据库MySQL 8.0 - 缓存Rediskey 统一前缀 app:{module}: - ORMMyBatis-Plus禁止在循环中单条查询 # 编码约定 - Controller 层只做参数校验和协议转换不写业务逻辑 - Service 层统一事务边界方法名使用 doXxx 风格 - DTO 禁止直接暴露数据库实体对象 - 异常统一抛出 BizException错误码在 ErrorCodeEnum 中定义 # 常见约束 - 所有修改尽量兼容 MySQL 5.7 的 SQL 语法 - 定时任务必须加 Scheduled 注释并说明执行间隔 - 涉及资金或用户状态变更必须在事务内并补充操作日志 - 不得硬编码配置项统一走配置中心这个文件的价值在于它把你团队积累了半年甚至一年的隐性知识显性化给 AI 看。AI 每次生成代码之前只要读了这份规则输出的代码就会更接近团队风格审查成本会明显下降。4.2 把需求描述切分成“可验证的单元”很多人在让 AI 写代码时喜欢一次性把所有需求都说完得到一个很大的代码块。这个做法的问题在于需求越复杂AI 的推理链越长出错率越高。更稳妥的方法是把它拆成几个可独立验证的小任务。任务修改用户状态更新接口 背景 - 接口路径PUT /api/v1/users/{userId}/status - 业务规则用户状态只能从“正常(NORMAL)”切到“禁用(DISABLED)”或“销户(DELETED)”禁止反向修改 - 必须检查当前用户是否为管理员无权限时返回 403 - 必须记录修改前状态、修改后状态、操作人 ID写入 user_status_change_log 表 输出要求 1. 更新 UserStatusService 中的 updateStatus 方法 2. 补充单元测试覆盖权限不足、非法状态流转、正常流转三条用例 3. 不要修改数据库表结构这种写法的好处是AI 的任务边界非常清楚它不会自由发挥去重构整个模块。即使生成结果有问题你也能快速定位到具体方法而不是在一个 500 行的“大礼包”代码里找茬。5. 用工程指标守住 AI 编程的底线聊了很多理念现在落到工程实践。无论 AI 写代码的能力多强只要进入了团队代码库就必须过工程化这一关。否则三个月后你得到的不只是慢而是一坨难以维护、无法上线、甚至没人敢动的历史包袱。从实际操作层面建议至少守住下面三条底线。5.1 没有测试不允许合并这一点在 AI 编程时代尤其重要。人工写的代码提交者至少大概率知道代码要干嘛。AI 写的代码提交者如果不去读完全不知道里面发生了什么。唯一的护栏就是自动化测试。如果团队还没有可执行的测试基线请从 AI 生成代码的那一刻开始补齐。比如你可以要求 AI 在生成业务代码的同时生成对应的单元测试SpringBootTest class UserStatusServiceTest { Autowired private UserStatusService userStatusService; Test void shouldSwitchNormalToDisabled() { User user new User(); user.setStatus(UserStatus.NORMAL); user.setOperatorId(1001L); userStatusService.updateStatus(user, UserStatus.DISABLED); Assertions.assertEquals(UserStatus.DISABLED, user.getStatus()); } Test void shouldThrowExceptionWhenStatusFlowIllegal() { User user new User(); user.setStatus(UserStatus.DISABLED); Assertions.assertThrows(BizException.class, () - userStatusService.updateStatus(user, UserStatus.NORMAL)); } }这里有个关键原则AI 生成测试代码的能力通常比生成业务代码更可靠。因为测试代码的上下文边界比较清晰适合 AI 发挥。如果 AI 生成的测试覆盖了核心分支你审查业务实现代码的压力会小很多。5.2 代码评审必须追问“AI 为什么这么写”很多团队的 Code Review 还是老一套看实现是否正确看有没有明显 bug。在 AI 编程时代评审的维度应该增加一个为什么 AI 会选择这个方案它是否理解和遵循了项目的架构约束如果评审时只看了 AI 生成的代码本尊而不追问它的生成逻辑很容易出现一种局面所有代码局部都对合在一起却不是这个项目的代码。最常见的问题包括使用了项目里根本不存在的工具类直接在 Controller 里写了事务逻辑绕开了 Service 层把不该脱敏的字段脱敏了该加的敏感标签没加生成了完全没必要的分布式锁自行引入了一个“更好用”的 JSON 库跟团队标准冲突针对这些问题评审时可以把“AI 写的代码”当成“实习生写的代码”来审。它很认真但它不知道你们团队过去踩过的所有坑。评审者的价值就是把这些坑提前堵上。5.3 建立“AI 修改审计”机制如果你的代码量开始大范围由 AI 生成建议在 Git 提交信息里标注是哪一种来源。比如在 commit message 中增加AI-generated标签或者在 MR 描述里说明“本次修改由 AI 辅助完成关键逻辑已人工复核”。这个机制不是为了甩锅而是为了建立数据基线。当你可以统计“AI 生成的代码占比”和“由 AI 代码引发的线上问题占比”时你才能判断 AI 编程对你团队到底有没有带来正向收益。没有数据你只能靠感觉管理这在工程上是很危险的。6. 完整示例把 AI 编程接入团队开发流程为了让前面的思路更落地下面用一个最小化的示例展示如何把一个 AI 编程任务接入规范流程。假设业务需求在订单完成后给用户发放一张限时优惠券。传统做法是产品写需求 → 开发读需求 → 开发写代码 → 开发自测 → 提交评审。AI 编程的做法可以长这样第一步整理任务上下文功能背景 - 订单状态变为 COMPLETED 时触发 - 优惠券为满 100 减 10 - 每人每个自然月最多领取 1 张 - 优惠券 30 天内有效 技术约束 - 优惠券服务在 coupon-service 模块 - 消息通过 RocketMQ 异步处理topic 为 ORDER_COMPLETED - 幂等键使用 orderId userId 拼接 - 需在 t_coupon_record 表写入发放记录 - 重复发放时返回成功但不执行发放动作 请输出 1. Consumer 监听逻辑 2. 发放服务的核心方法 3. 幂等校验逻辑 4. 单测覆盖“首次发放”和“重复发放”两个场景第二步把 AI 生成的代码放入项目运行测试这一步的关键是不要直接复制粘贴。先把代码放在本地分支然后跑编译、跑测试看是否通过。mvn clean compile mvn test -DtestCouponConsumerTest第三步人工评审重点关注边界条件AI 生成的代码可能没有考虑到消息消费失败时的重试次数上限、优惠券过期时间的时区问题、用户已经注销的情况。这些边界不是训练数据里最常见的模式需要人工把最后一道关。第四步提交合并并在 MR 描述中写清楚 AI 辅助情况变更说明 - 新增订单完成发券逻辑 - 由 AI 辅助生成核心代码人工复核并补充边界处理 - 测试覆盖首次发放、重复发放、幂等校验 - 已验证 RocketMQ 消费者幂等性这个流程的最大价值不是让 AI 自己“跑完全程”而是把 AI 的产出纳入正常的工程质检体系。AI 可以承担从“需求”到“代码初稿”这部分的效率红利剩下的审查、验证、边界补全依然是工程师的核心价值。7. AI 写代码三个月的常见问题与排查思路问题现象可能原因排查方式解决方案之前生成效果很好现在生成烂代码项目上下文超出模型理解范围查看最近代码库变更确认是否有大规模重构给 AI 提供更精确的上下文文件如数据库结构、接口文档拆分任务粒度AI 生成了项目里不存在的 API模型训练数据中的“常见 API”与项目实际依赖不符检查 import 和依赖坐标在规则文件中固定依赖版本和核心类路径AI 修改 A 模块导致 B 模块报错跨模块依赖关系未被模型感知检查 A、B 模块间的编译依赖和调用链让 AI 先输出改动影响范围再自动执行测试用 AI 生成的代码引入安全漏洞训练样本中存在不安全代码模式使用 SAST 工具扫描搜索硬编码密钥增加安全扫描环节要求 AI 输出时遵循安全编码约束团队大量使用 AI 后代码风格混乱没有统一的项目规则上下文统计不同风格代码比例建立代码规范文档强制 AI 工具读取配置统一的 formatter 和 lint 规则AI 写代码很爽但改 AI 的代码很痛苦缺乏对 AI 生成代码的理解成本观察需求变更频率和返工率改 prompt 策略让 AI 生成结构更简单、可读性更强的代码而不是炫技代码AI 生成代码后测试用例全部要自己重写测试输入输出没被 AI 正确理解查看测试失败日志确认是逻辑错误还是理解偏差给 AI 补充“测试需要覆盖哪些分支”的明确说明8. AI 编程的最佳实践与工程建议从大量团队实践来看AI 编程真正生效的前提不是“AI 有多强”而是“团队有没有准备好接住 AI 的输出”。下面这些都是可以直接使用的工程建议。维护项目级 AI 上下文文件每个项目都应该有一个 AI 可读的“项目指南”内容包含技术栈、模块划分、关键表结构、异常处理规范、命名风格、部署方式、禁止事项。不要让它成为一份“写给人看、AI 不读”的文档要在 AI 工具配置里确保它会自动加载。把 AI 生成代码纳入常规评审流程不要因为 AI 生成速度快就走一套“快速合并”的特殊通道。评审标准应该和人工代码一致正确性、可维护性、安全隐患、性能、架构一致性、测试覆盖。禁止用 AI 直接操作生产环境任何涉及生产环境的变更不管是改配置还是执行脚本都必须在本地测试环境预演并经过人工确认。AI 的工具调用能力越强越要设置准入边界。线上环境的权限不应该直接暴露给 AI 工具自动执行。对 AI 生成代码做依赖隔离如果 AI 建议引入一个新依赖必须确认依赖来源、版本安全性、许可证合规。不要因为“AI 推荐”就盲目添加。建立回归测试基线AI 代码合入后最怕的是“本地跑通了线上炸了”。回归测试是最后防线。如果没有回归测试至少要跑通核心链路的一键测试脚本。迭代 Prompt 和规则文件Prompt 不是写一次就完事的。每次遇到 AI 生成质量不佳的情况回到规则文件里找原因是没写数据库表结构没写事务边界还是没写 API 风格把这些信息补进去。三个月后你会发现规则文件本身就是团队最宝贵的资产之一。别用它写你完全不懂的领域代码这是最容易踩的坑。AI 可以写一个你从未接触过的协议解析器而且看起来非常专业。但如果出错你连排查的方向都没有。对于完全陌生的领域最好先人工理解核心流程再让 AI 辅助生成细节而不是把整个模块直接交给 AI。速度不是唯一指标衡量 AI 编程的效果不能只看“代码生成的速度”还要看“代码上线后的问题数”“返工时长”“维护成本”。如果一个 AI 工具让你第一周写代码快了一倍但三个月后让你排查 bug 的时间翻了两倍那它在工程上可能是负收益。9. 从“让 AI 写代码”到“让 AI 写对代码”回到标题的问题AI 写代码爽三个月然后呢更准确的回答是三个月之后你不能再把 AI 当成“黑盒生成器”来用。你需要开始管理 AI 的上下文、校验它的输出、评估它的影响面、约束它的依赖把它嵌入到工程流程里。“让 AI 写代码”只是入门“让 AI 写对代码”才是真正的工程能力。“写对”包括符合团队规范、不破坏现有功能、不引入安全漏洞、有测试覆盖、能被后续阅读和维护。这个过程里最核心的转变是你从“告诉 AI 做什么”变成“定义 AI 做事的边界”。这个边界不仅是代码级的技术约束还包括安全边界、权限边界、依赖边界。一个 AI 编程能力强的工程师本质上是一个能把需求、上下文、约束、验收标准描述得特别清楚的工程师。这种能力在 AI 出现之前叫“分析设计能力”在 AI 时代依然存在只是载体从“写代码”变成了“写上下文”。最后给一个很实际的建议如果你现在正处于“AI 写代码爽三个月”的后期最该做的不是研究更多魔法提示词而是把这三个月的 AI 生成代码拿出来做个审计。看看哪些代码是稳定可维护的哪些已经让你看到就想重写。如果大部分都需要重写不是 AI 的问题是你在生成之前没有给它足够的“边界”。把边界补上然后再让 AI 接着写它会给你一个完全不一样的结果。
