新公司2个月我用AI写了90%的代码但我劝你别学我。先说明这不是炫耀贴更不是劝退贴。我入职第3天就开始用AI写代码2个月过去业务代码里超过90%都经过了AI生成、改写或者辅助重构。团队没炸代码没烂项目按期上了线。但我还是要说别学我尤其别学我这个“用法”。为什么劝你别学因为“用AI写代码”最大的坑不是AI写得不好而是你把AI当成一个“能出活的黑盒”。我见过太多人让AI生成一堆看起来没问题、实际跑起来处处是地雷的代码然后甩给验收的人出了问题直接一句“AI写的”就完了。这事我在前一家公司就亲眼看过一个项目组怎么把一个简单的登录模块写得比业务逻辑还复杂——不是因为AI不聪明而是使用AI的人根本不知道自己在干什么。这篇内容我打算彻底拆开讲清楚我是怎么在2个月内用AI扛下90%的代码量、中间踩了哪些坑、哪些地方AI真的能救命、哪些地方绝对不能交给AI。我还会给出我实际用的工作流以及一套“人工审查AI生成”的配合方法——因为我这2个月真正在做的事不是“用AI替代写代码”而是“重构自己写代码的方式”。如果你也想让AI成为项目加速器而不是拆弹器下面的内容值得你认真看完。1. 这90%是怎么构成的先算一笔真实账目先说清楚“90%”这个数字是指什么。我统计的维度很粗暴提交到代码仓库里的最终代码行数凡是通过AI对话生成、由AI提示然后我手写确认逻辑、或者由AI做大规模重构的都算AI参与。比如空行、注释、配置文件都不算在内。这样算下来2个月工资周期里我负责的模块AI参与度大约在90%左右。剩下10%是手写的老接口适配和几个极其特殊的加密逻辑。但我得先坦白这个数字有水分。因为代码量本身不等于代码价值。一个项目里最值钱的往往不是代码本身而是边界条件的识别、异常流的处理、数据一致性的保障。这些恰恰是AI最不擅长、也最容易装懂的部分。AI能帮你写出优雅的代码块却很难帮你从全局判断“这个字段在第三方的回调里有可能为空要单独处理”。所以我的“90%”是分模块统计出来的不是总工程量的90%。核心模块至少有一半逻辑是我手写大纲、让AI填充实现然后我再逐行审。而那些CRUD、样板代码、配置转换、简单的单元测试才是真正意义的“AI全权负责”。这种分工逻辑后面会详细说这里先给个结论性判断在熟悉的业务领域里AI可以将纯写码效率提升2到3倍但想靠它完全替代开发、跨过设计决策那是在给自己挖坑。我入职这家新公司时项目已经进行了6个月历史代码有大约20万行技术栈是Java 17 Spring Boot 3 PostgreSQL前端是Vue 3。这意味着我面对的并不是一页空白画布而是要在既有代码风格和历史技术债务里夹缝求生。AI在这种环境里的发挥空间比从零开始写新项目要窄很多但你只要把“AI能做什么边界”划清楚它依然能成为主力生产工具。2. 为什么我敢把代码交给AI方法论先于工具我在上一家待了4年的公司工具链相对保守直到离开前半年我才开始认真把AI引入日常工作。前3个月我把让AI写代码当成一个游戏什么代码都丢进去让它跑一遍然后看它翻车看它一本正经地给出错误方案。事实证明这才是最佳学习路径——AI不是用来“信任”的是用来“驯化”的。但驯化的前提是你得先搞清楚它会在哪些地方犯蠢然后划定能交给它的场景。这套方法论是我用几个月的时间总结出来的我给它起了个名字叫“三层边界”第一层是“样板层”。这一层包括标准CRUD接口、实体类、DTO转换、简单的分页查询、配置文件、测试数据构造等。这类代码有明确的套路每个项目的写法可能不同但内部结构高度相似。AI在这层的表现极其稳定甚至可以用“完美”来形容——因为它是从海量训练数据里学出来的通用模式本身就是同类代码的“平均解”。第二层是“逻辑层”。这一层包括状态机流转、权限校验、批量处理、复杂的SQL聚合、缓存策略等。AI可以生成初稿但你必须让它理解业务背景而且必须强调约束条件。它常常会在某一块写出完全合理的代码可一到跨模块交互就开始短路。比如我让它写一个“库存扣减并记录流水”的接口它写出来的逻辑在单测里看起来完美可如果并发请求同时打到这个接口上库存直接变成负数。这不是写代码的问题是“并发控制意识”的问题——AI模型没有真正经历过线上事故它就很难主动加上分布式锁。第三层是“决策层”。这一层包括接口设计、数据结构设计、数据库表拆分、事务边界划分、技术选型、重构策略等。这一层我从来不交给AI最多让它提供参考方案、对比优缺点、列个checklist。AI在决策层表现最好的状态不是“替你做决定”而是“提供一个让你不遗漏任何选项的视角”。比如在选择“订单状态字段用什么枚举还是常量类”这种问题上它能帮你列出两者在可维护性、可读性、空间占用上的差异但它不会知道你团队里的同事更习惯哪种风格。我在这家新公司的头两周做的一件事就是先把公司现有代码里高频出现的模式提取出来喂给AI当Few-shot示例。比如我们项目的分页返回结构、统一异常格式、审计日志注解、权限注解写法我都会在生成指令里贴上一两个真实示例让AI照着现有风格写。这个动作把我的代码review成本直接砍掉了三分之一——因为AI生成的代码从一开始就贴合团队规范而不是需要我再花时间改写成统一格式。3. 实操工作流从需求到提交的6个关卡用AI写代码最容易犯的错误是把AI当成“翻译机”——你给它一句“写一个订单导出功能”它输出一个满足表面需求的实现然后你直接提交。这种做法在Demo阶段可能没问题但在生产环境就是灾难。我自己搭的一套流程有6个关卡严格按顺序执行每个关口都不能跳过。你可以把它理解成“用AI之前先给自己加一段编译期检查”第一关需求拆解与提示词设计。这一步是最耗心力的。需求和功能描述大部分都很口语化、很零散比如“用户反馈说导出Excel太慢了需要优化”。这种需求如果你原封不动丢给AI它可能输出一个分页查询的优化方案但它不知道导出的关键瓶颈在“大数据量下的内存溢出”还是“数据库查询慢”。我通常会把需求拆成两个部分业务规则做什么和约束条件怎么做/不能做什么然后分别转换为AI能理解的上下文。举个例子一个导出需求我会这样写背景订单表数据量在百万级用户导出Excel时需要按筛选条件导出目前导出的最大瓶颈是内存占用过高。 任务请实现一个订单导出接口返回一个zip压缩包包含多个Excel文件。 约束不能使用内存拼接Excel文件Project X方案不可行需要按批次从数据库读取数据格式需要和现有导出模板保持一致超出10万行需要拆分为多个sheet。 请在代码中标注关键实现点的注释并补充对应单元测试。这样喂进去AI的产出质量就完全不一样。它在生成时会自动绕开你用plain内存拼接的方案也会主动考虑拆分逻辑。相比之下直接写“用EasyExcel导出订单”出来的代码大部分情况需要重写。第二关上下文锚定。这里我要特别强调一点现在的AI工具已经能做到上下文窗口非常大大到可以塞进整个项目的核心代码但这不代表你应该用“把整个项目贴上”的暴力方式对话。上下文越长AI反而越容易在无关信息里迷失方向生成的代码会“平均化”而不是“贴合你的业务”。我的做法是“按需拉取上下文”。需要写Controller就把现有的Controller拎出来需要写Service就把现有的Entity、Repository、以及相关的Service代码贴上去。一次对话只聚焦一个模块拒绝“一锅炖”。比如我做“库存同步”功能的时候我只贴库存表结构、现有库存Service、对外的HTTP接口定义其他一概不管。这会让AI在生成时始终围绕你给出的实际数据结构来展开而不是凭空创建一个“OrderEntity”出来。第三关逐模块验收与编译检查。AI生成代码后我不会直接粘进IDE里而是先复制到一个临时目录里用编译器和静态检查工具过一遍——这一步在命令行就能完成不用手动点击。检查通过后再进入代码审查阶段。这里推荐一个我自己的习惯把AI生成代码中所有“TODO”、不完整的异常处理、以及对自己也不确定的地方全部标记出来强制让AI解释“为什么这里用了这个方式”如果它解释不清大概率就是“平均解”。很多人忽略的一步是单元测试。我要求AI生成的每个业务模块至少配套一个Happy Path的核心流程测试。别指望AI能覆盖异常流但至少验证正常路径不炸。如果你让它生成一个带状态流转的接口它通常会漏掉“重复提交幂等性”这种测试——这种边界情况必须由人来补。第四关代码审查与模式校验。代码审查阶段我只检查五件事异常处理是否完整、事务边界是否合理、并发是否安全、是否存在内存泄漏风险、是否与现有团队规范一致。其他一般性问题能用工具自动扫描的就不用人肉看。这里我想讲一个特别值得注意的坑AI非常喜欢生成“自己风格的代码”而不是“你项目风格的代码”。比如同一个功能的写法你项目里习惯用Optional收尾、Objects.equals判断AI一旦没有示例可参考就极有可能写成if (obj null) return。判别代码是否属于“项目风格”其实用正则或静态扫描工具就能做到但“为什么这样写”这种背后逻辑需要人来过。第五关集成联调与数据验证。这是我最看重的一关。AI生成的代码单独编译通过不等于它能和整个系统协作。特别是数据库迁移、缓存失效、消息队列交互这些场景AI的几何级想象力在运行时完全失效。我测试时永远带着真实生产的匿名数据跑一遍而不是只靠mock数据。举个具体的例子我写一个“用户积分变动通知”功能AI生成的代码在单元测试时完美通过可一旦接入真实消息队列才发现它把“积分变动”和“通知发送”放在同一个事务里结果发消息失败会直接导致积分回滚。这就是典型的“局部最优全局停滞”——AI无法看到消息队列失败应该独立补偿这种业务语义。第六关提交前再想想“反例”。提交代码之前我给自己设置一个强制问句“这个功能在什么情况下会出错”。然后让AI反向生成几个“故障场景”。你会发现AI在这方面的潜力惊人它能把对应的边界情况列得很全。我只会挑出其中有价值的场景手动补测试和防御代码。这一步花的时间不多但极大地减少了生产事故。我在新公司提交的第一周代码因为有这一道关口review阶段几乎没有被打回重写——不是代码有多完美而是已知的坑大部分在提交前就被找出来了。4. AI的四种翻车模式与我的排查实录我知道上面那套流程看下来你可能会觉得“太麻烦了用AI不就是为了省事吗”——但我必须说省的是打字时间和搜索时间而不是思考时间。AI真正让你少做的事是“从零写起”的重复劳动而不是“判断这段代码是否正确”的心智负担。为了让你少踩坑我把这2个月里真实遇到过的AI翻车情况按类型整理成表你也可以当作一份“AI生成代码排雷清单”来用翻车类型典型表现根因分析我的处理方式需求幻觉型把“导出Excel”理解成“生成PDF报表”提示词缺少领域限定词把核心名词用中英文双写并附一个示例上下文漂移型生成第二段代码时忘了第一段的设计对话上下文过长注意力分散分ファイル、一次性只聚焦当前模块不跨功能对话过度自信型用不存在的API或者错误参数还标注正确知识截止时间Cutoff与最新框架版本不匹配禁止AI引用未经验证的API让它标注版本信息风格漂移型代码与项目现有写法完全不同缺少Few-shot示例生成指令开头就先贴两段现有代码关于过度自信型翻车我想多说几句。有个经典案例是我让AI写一个“批量插入10万条订单数据到PostgreSQL”的方法它给出的方案是使用JDBC Batch参数是合理的但它又额外加了一句“使用INSERT ... ON CONFLICT DO UPDATE实现幂等”这句对于遇到的业务来说并不合适——因为那两张表的业务不允许重复更新。我一开始被它带偏了直到压测时才反应过来。这个教训让我养成了一个习惯AI在方案上给了两个以上的选项时我默认只当作参考资料最终决策永远自己拍板。上下文漂移型也比较典型。我一开始试图在一个长对话里让AI把整个微服务的代码都写完到了第5个模块它竟然把之前定义好的返回结构体给忘了新模块直接用了另一个名字。这种“跨模块记忆失效”是AI模型的固有限制不是调prompt就能解决的。最稳妥的方案是把“每个模块之间的接口契约”单独拎出来写明然后每次对话开始前都重新粘贴一遍契约让AI老老实实基于最新契约干活。风格漂移型在团队协作的语境里特别危险。一个项目有多人在维护代码风格如果不统一后面维护的人会崩溃。我测试过让AI生成两种风格的循环写法——一种是传统的for循环一种是Java 8的stream它在一半情况下会选stream而项目里大部分业务循环都是传统for。AI并没有能力提前了解到项目的风格偏好这个只能靠“人工给示例”去约束。5. 与新同事的协作模式AI不止是你一个人的工具新公司有个特别好的氛围团队里几乎每个人都在用AI但用法和深度各不相同。有人只拿它补注释、写日报有人拿它写单元测试也有人像我一样直接把它推上一线生产。这种差异让我明白一个道理AI在团队里能不能发挥价值不是看工具的先进程度而是看有没有一套被大多数人认同的协作方式。所以我在第二周做了一件小事在团队内部文档里写了一个简短的“AI辅助开发公约”。内容很简单就4条AI生成代码必须经过人工审查才能在代码库中出现工时归人、责任也归人。AI产出的代码必须有相应的单元测试覆盖不能只测主流程。涉及数据库迁移、第三方对接、复杂事务链路的代码必须人工手写或逐行确认。任何人禁止把自己不理解的代码提交进代码库。这4条规定靠团队的力量落实下来了也让我的“AI重度用法”没有成为团队的乌云反而变成一种可以参考、可借鉴的模式。其他同事也开始尝试用自己的方式让AI参与比如有人专门负责归纳“AI使用技巧”的文档有人整理“AI生成代码常见错误清单”。这个文档越写越厚我从里面受益不少。6. 劝你别学我的真正原因文章开头我说“劝你别学我”这里必须解释清楚。你可以学我的方法论但不要直接学我的“2个月90%代码”这件事本身。直接学的风险在于第一我的90%是有前提的。我来这家公司前已经在同类型系统上积累了3年经验。代码里的领域模型、业务流程、常见坑位我心里都有数。这让我敢用AI填剩余的部分。如果你是个刚入行的新人没有主干逻辑在脑子里AI给你生成的代码就是你全部的理解——一旦它出错你连排查的入口都找不到。第二AI生成代码的速度会给你极大的“进度感”但进度感和真正的质量感是完全两回事。我在新公司头一个月每天提交的PR数量比老员工多出很多但review的人可不是吃素的。有好几次是我觉得AI写的已经很好了被老手一句话打回说“这种并发场景你怎么敢这么写”第三我没有告诉你的是那2个月里我的加班时长不降反升。AI帮我写了90%的代码但为了确认那剩下的10%边界条件、补那90%的坑我花的时间比纯手写还多。你说“效率提升”了吗提升了提升的是“我把时间花在更难、更值得花的地方”。原来一天的工作有两小时在敲样板代码现在那两个小时被我用在思考数据一致性和接口设计上。所以我的体感是AI不能让一个平庸的开发者变得优秀但它能激励一个尚可的开发者把时间花在刀刃上。7. 最后再分享一个小技巧让AI给自己做代码体检我在这个项目学到的最有价值的一个习惯不是让AI写代码而是让AI“审”自己的代码——用两个独立的对话会话一个生成一个审查审查时不共享生成时的上下文让AI从纯粹的表层逻辑去客观看待这段代码。相当于是“AI写、我审、AI再审”——三个视角交叉能找出大量两两配合也查不出的问题。做法非常简单把AI生成的代码复制出来粘贴到一个新会话。让它扮演一个资深代码审查专家分别从性能、安全、代码风格、异常处理、复杂度5个维度给出意见。对每个意见都要求它给出“规范化修改建议”和“理由”只接受有理有据的不接受“看起来更好”的。人工对修改意见做优先级排序按照“高风险改动”“中风险改动”“纯风格改动”分别决定是否采纳。这个技巧最惊人之处在于AI审查自己的代码时经常会先指出它在生成时已经忽略的边界情况——就好像它回答“我知道这里有问题但我没告诉你”。整个过程只需要5分钟但几乎每次都能抓到一两个有价值的改进点。如果你也在用AI写代码强烈建议你把这一步养成肌肉记忆。用AI写代码这件事放到今天已经不值得大张旗鼓讨论了。工具就在那里每个人都能用。真正拉开差距的依然是编写代码背后的人怎么问需求、怎么拆问题、怎么把握好审查粒度、怎么让AI产出与你团队文化兼容的结果。这4个能力才是AI时代程序员真正的核心竞争力。我在新公司的第二个月已经能明显感觉到AI写代码的速度终有一天会稳定在某个水位线上而人的判断力和工程经验才是决定代码能不能落地的天花板。你要做的不是追上AI的速度而是让自己成为那个拿着棋盘的人。