1. 先交代背景校招生的困境与我的破局思路1.1 入职第一个月我被真实项目毒打的场景我是去年通过校招进的大厂做的后端开发。进组之前我自认为代码能力还行算法题刷了不少项目也做过几个。但真正入职之后面对的第一个任务就让我懵了在一个维护了五六年的老订单模块里新增一种订单状态。听起来不复杂对吧但真实情况是那个模块有几千个类状态流转散落在不同的Service里数据库表结构里埋了不少历史字段还有几个定时任务在背后改状态。我需要先搞懂当前有哪些状态、谁在什么条件下改状态、新增状态会不会影响对账、会不会影响已有的定时任务。光是理清这些我在代码里翻了一个下午效率低到怀疑人生。后来我发现不只是我同批进来的校招生普遍都有这个问题在学校里练的是从零写一个系统到了大厂却是在一个庞大系统里做局部修改。前者只要自己逻辑通就行后者要求你先理解一堆别人的逻辑再小心翼翼地改动。而理解代码恰恰是新人最耗时间、也最容易遗漏细节的环节。也就是这个时候我开始认真思考怎么把AI接进我的开发流程。我当时的想法很朴素AI最擅长的不就是快速处理大量文本和基于已有信息做推演吗读代码、理逻辑、找线索这些事情正好可以交给它先跑一遍我做校验和决策。1.2 我理解的AI Coding工作流不是多了一个ChatGPT而是每个环节都有AI很多人以为AI Coding就是打开一个对话窗口把问题扔进去拿答案抄下来。我刚入职那几周也是这么干的结果并不理想要么AI给的代码风格跟项目完全不一致要么它引用了一个我们项目里根本不存在的工具类要么它给的方案看着对一编译就报错。问题出在哪出在我把AI当成一个无所不知的答题机器却没有给它足够的上下文也没有把它放到一个明确的流程位置里。后来我调整了思路把开发流程拆成一个个环节——读需求、写方案、写代码、写单测、做Review、查问题然后在每个环节里给AI布置一个带有明确输入和输出的子任务。比如读代码环节输入是一段代码文件输出是这段代码的逻辑说明和需要注意的副作用写代码环节输入是方法签名、数据模型和项目约束输出是可编译的代码草稿。这样一来AI就不再是一个飘在流程外面的聊天框而是嵌在流程里的一个个节点。每个节点做的事情都很窄但它能做得很稳我只需要检查它的产出而不是每次从零开始跟它对话。这个思路是我整个AI Coding工作流的核心也是后面所有经验的地基。2. 我把AI嵌入开发流程的四个环节从需求到上线的完整链路2.1 需求理解与技术方案让AI当文档速读员和方案质疑者新人在大厂接触需求最先感受到的往往是文档怎么这么长。一份PRD动辄几十页里面有背景、有规则、有各种边界情况、还有历史决策记录。我第一次独立接需求时光读文档就读了大半天读完还不敢说自己全懂了因为一些隐含的业务规则散落在评论区和旧需求邮件里。我的做法是把PRD的核心部分复制给AI让它做三件事——用三句话概括需求本质、列出所有显式和隐式的验收标准、把可能影响到的现有模块列出来。AI做这件事非常快而且它的概括能力比我这个新人强得多。它列出的验收标准里有些是我自己读文档时忽略的边界条件比如超时时间从哪一秒开始计算重复触发怎么处理。在技术方案阶段我会让AI扮演方案质疑者。当时我在设计那个新增订单状态的方案时先自己想了一个基于状态机的实现又让AI从并发、幂等、数据迁移三个角度提出质疑。它指出了几个我没考虑到的问题比如状态变更和支付回调同时发生时要不要加锁历史订单里是否可能出现这个新状态。这些质疑不一定都对但确实逼着我去查证、去补全方案。我觉得这就是AI在方案阶段最大的价值它不替你做决策但它能帮你把思考的盲区照亮。2.2 编码实现AI补全、生成单测、批量重构编码阶段是我日常用AI最多的环节细分下来主要是三类场景。第一类是补全样板代码。比如我要写一个根据用户ID查询最近N条订单的方法我会先写上方法签名和一段注释剩下的交给IDE里的AI补全。它通常会生成一个基本能用的实现我再根据项目的实际情况调整查询条件和返回值。这类任务逻辑简单、模式固定AI补全的准确率很高能省不少敲键盘的时间。第二类是生成单元测试。写单测是新人最容易忽略、但又必须做的事情。我的习惯是先让AI读一读目标类的代码然后让它生成一组测试用例重点覆盖正常路径、空值、边界值和异常场景。AI生成的测试用例不一定都能直接通过但它的覆盖思路往往比我自己拍脑袋想出来的更全我只需要把不合适的用例删掉、把缺少的断言补上。第三类是批量重构。老项目里经常有把所有StringUtil的调用替换成内部公共类这类机械性改动。让AI去做替换比人肉眼搜索快得多也少了许多遗漏。我自己动手前会明确告诉AI只做等价替换不改变任何业务逻辑不顺手优化其他代码。改完之后我会把diff从头到尾看一遍重点确认没有误伤。2.3 Code Review与自测让AI先审一遍再交给人提交MR之前我习惯让AI先把我的diff审一遍。具体做法是把改动涉及的文件和相关代码贴给它让它重点排查几类问题空指针、资源没关闭、并发安全、数组越界、事务边界错位。这些是代码评审中最常见的模式化问题AI扫一遍往往能发现一些我写完代码后自己看不出来的低级错误。有一次我写了一个异步线程池提交的任务AI提醒我线程池使用了无界队列且没有拒绝策略极端情况下可能导致内存溢出。这个提醒点醒了我后来我专门去查了项目里线程池的标准用法改成有界队列加拒绝策略。那一轮Code Review人工评审几乎没有提出线程池相关的问题。不过我也要说清楚AI的Code Review是低配版预审它只能发现通用模式问题理解不了业务上下文。它看不出你这个状态字段是不是和支付网关的约定不符也判断不了这个接口的返回结构是否满足下游的兼容性要求。所以我的态度是AI审一遍我自己再审一遍最后提交给人评审。它帮我挡掉一批低级问题但背锅的还是我自己。2.4 定位线上问题把AI当成日志分析助手新人最怕的就是线上出问题一收到告警就慌。我后来慢慢总结出一个相对稳的排查流程先把异常堆栈、相关代码片段、最近的改动记录这三样东西收集起来然后一起扔给AI让它帮我梳理可能的原因。有一次线上出现偶发性的空指针堆栈指向一个异步回调方法。我没看懂调用链是怎么走到那里的就把堆栈和附近的代码贴给AI它分析说这个对象在主流程里已经走完了生命周期异步回调拿到的可能是一个已经被释放的引用。我顺着这个思路去查果然发现回调没有做判空保护。那次排查比我对着堆栈干瞪眼高效太多了。但这里有个重要的提醒AI给的是假设不是结论。它经常给出三四个可能原因里面第一个看起来最合理但实际可能不是。我会把每个假设当成一条待验证线索逐一用日志和代码去确认而不是看到第一个原因就下结论。排查线上问题AI负责把搜索空间缩小做最终判断的依然是人。3. 大厂环境下的AI Coding选型合规、效率与成本的三方平衡3.1 为什么我几乎不用外网AI处理公司代码大厂对信息安全的要求非常严格公司的代码、业务数据、用户信息都属于内部敏感信息。把一段包含业务逻辑的代码原封不动贴到一个外部公开的AI网站里这个动作本身就有很大的合规风险。刚入职的时候组长就专门提醒过不要图方便用外网AI处理公司代码出了问题追责不是开玩笑的。所以我的基本原则是优先使用公司内部统一接入的AI能力比如内部平台提供的代码助手、IDE插件。这些工具的数据链路经过了合规审批代码不会流出公司边界。如果某个场景确实需要用外部模型我也会先做脱敏处理去掉真实的业务名词、变量名、注释只保留问题的通用结构。这里我也特别想提醒一些刚入职的同学不要因为外部AI工具用起来顺手就忽略公司的信息安全红线。你觉得自己只是问一个问题但在审计视角里这就是敏感代码外发。我在团队里见过因为随手贴代码被通报的案例真的很不值。3.2 团队常用的三类AI Coding工具怎么选我在实际工作中观察和接触到的AI Coding工具大概分三类各有各的适用场景工具类型典型形态优势需要注意的点IDE插件编辑器内的代码补全、对话框与编码流程结合紧密补全体验好通常不支持超长上下文对老项目的背景理解有限内部AI平台网页端或命令行工具功能全支持长文档、长上下文可以喂入多份代码文件需要在工具和编辑器之间来回切换流程感稍弱私有化部署的开源模型本地或部门内网部署数据可控可以针对项目做微调工程成本高需要维护非大团队一般玩不转以我的实际体验来说日常写代码最顺手的是IDE插件因为它就在你写代码的地方补全和基于选区对话都非常自然。但到了解读整个模块梳理完整调用链这种需要大上下文的场景IDE插件就明显吃力了我会改用内部AI平台把相关文件一次性喂进去。所以我的做法不是只认一个工具而是根据任务大小选择合适的工具。3.3 我给自己定的红绿灯使用原则接触AI Coding久了之后我给自己定了一套红绿灯使用原则用来快速判断一个任务能不能交给AI绿灯任务通用算法题、学习示例、正则表达式、SQL生成、单元测试草稿、模板代码。这类内容不涉及具体业务可以放心让AI发挥。黄灯任务涉及业务逻辑的代码、稍大一点的方案设计。我会先把关键信息脱敏或者只给AI抽象后的伪代码让它生成草稿再由我结合真实业务改写。红灯任务包含密钥、token、真实用户数据、核心交易逻辑的原始代码。这些绝对不会出现在任何外部工具的对话框里。这套原则帮我省了很多纠结的时间。遇到一个任务先看它属于哪个颜色再决定给AI多少信息。不要一概而论地全部给或者全部不给那样要么低效要么危险。4. 提示词工程的开发态玩法不是聊天是写代码4.1 为什么开发态提示词不能照搬聊天惯用法很多人跟AI对话还停留在聊天习惯上帮我看看这个这个怎么改。但到了开发场景这种模糊的对话方式会吃大亏。因为AI不知道你的项目背景、不知道代码风格、不知道你想要的输出形式它只能靠猜而猜出来的结果往往就是看起来合理但没法用。我自己的理解是在开发流程里应该把AI当成一个刚入职的外包同事。你把任务交给一个外包同事之前是不是要交代背景、目标、约束和交付形式对AI也是一样。背景告诉它项目用什么框架、什么语言目标告诉它要做什么约束告诉它什么不能做、要符合什么规范交付形式告诉它给我方法实现和简要说明还是给我一个完整的测试类。把这个思路想清楚之后我写提示词的方式就彻底变了。不再说帮我写个查询而是像下工单一样把任务描述完整。AI的产出质量也随之提高了一大截。4.2 一套我反复用的代码生成提示词模板下面这套模板是我用得最多、成功率最高的分享出来供参考背景项目是Java 8Spring Boot 2.7MyBatis数据库MySQL。 任务在OrderMapper中新增方法查询某用户最近N条未支付订单按创建时间倒序。 输入OrderDO字段包括id、userId、status、amount、createTimeOrderMapper现有查询风格见下方代码。 约束 1. 不改变现有接口签名不新增依赖 2. 使用项目已有的日志框架不自行引入 3. 遵循现有Mapper的XML写法不要用注解SQL 4. 只提供方法实现和对应的XML片段不解释原因。 输出方法代码 XML片段。这套模板的关键在于把背景、任务、输入、约束、输出五个要素都填满了。尤其是约束这一栏很多人会忽略。你不说不要引入新依赖AI就真的可能顺手给你引一个commons-lang3你不说遵循现有XML写法它就可能给你写注解SQL跟项目习惯完全不一致。还有一种情况项目里已经有类似的方法那我会直接把那一段代码贴进提示词里告诉AI仿照这段的风格写新的。这比任何口头描述都管用因为代码本身就是最好的风格说明书。4.3 上下文注入技巧把项目语境喂给AIAI在代码生成上最大的短板是不了解你的项目语境。同样是查询订单它不知道你的订单状态字段有哪些取值不知道你的软删除规则不知道你的分页规范。如果你什么都不给它只能凭常识猜猜错是大概率事件。解决这个问题的方法是上下文注入在提问或生成代码之前先把相关的上下文喂给AI。具体有这么几种做法第一种使用IDE类工具提供的文件上下文功能比如通过文件的方式把相关文件引入对话。这样AI在生成代码时能看到你正在操作的项目文件生成的代码风格会贴近项目实际。第二种手动摘录关键信息。如果工具不支持文件引用我会把相关的类定义、接口方法签名、数据库字段列表复制进提示词让AI基于真实结构去写代码。哪怕只是粘贴几个关键类效果也比空手提问好得多。第三种让AI先读再写。我在需要AI理解现有逻辑时会先给它几个相关文件指令是先阅读以下代码理解现有逻辑然后……。这样做可以让AI先建立对项目的认知再在这个基础上完成任务。我自己试下来这一道工序能让代码生成的质量明显提升尤其是涉及多文件联动的改动。5. 实测踩坑记录AI生成的代码为什么不能直接信5.1 幻觉高发区盘点AI生成代码不是不出错而是出错的方式很有迷惑性。我整理了自己踩过的和一些同事遇到的坑发现幻觉集中在这几类第一是不存在的API。AI会编出一个看起来很像标准库但实际不存在的方法或者把某个类名写得很真但一编译就报找不到符号。这类错误相对容易发现因为编译是第一道关卡。第二是错误版本的依赖坐标。比如让AI写一个使用Redis的工具类它可能给你一个org.redisson:redisson:2.9.0这样的坐标看起来没问题但实际这个版本跟我们项目用的Spring Boot版本不兼容。这种坑比不存在的API更隐蔽因为依赖能拉下来启动才会报错排查起来很费劲。第三是过时的用法。AI的知识有截止日期它可能还在推荐十年前的老写法。比如在Java里用Vector、在Spring里用已经被废弃的Autowired构造器注入形式或者在MyBatis里写早就被淘汰的配置方式。这些代码在单测里可能都是绿的但Code Review阶段会被有经验的同事打回去。5.2 翻车案例AI修复了一个根本不存在的问题有一次我把一段自己刚写完的工具类代码贴给AI做Code Review它很认真地指出了一个严重的线程安全问题说这个静态方法里使用了SimpleDateFormat存在线程安全风险建议换成DateTimeFormatter或ThreadLocal。我一开始真被它说服了因为SimpleDateFormat线程不安全是个经典问题。我还仔细检查了那段代码确认确实用了SimpleDateFormat。但后来准备改的时候我又重新读了一遍调用方才发现问题所在这个方法每次调用都会new SimpleDateFormat并不会跨线程共享实例所以根本不存在它说的线程安全问题。这个翻车案例给我的教训很深AI的Review会基于常见代码模式来臆想问题而不是基于这个项目的实际运行方式来判断。它看到SimpleDateFormat就想到了线程安全但它没注意到实例作用域。从那以后我再也不无脑接受AI的Review意见了。每个问题都必须回到代码里核实一遍确认它说的是不是真的。5.3 翻车案例注释风格的污染还有一个看上去不算bug但实际很烦人的问题AI生成的注释风格会在不知不觉中污染整个代码库。我有一段时间图快让AI批量生成了一些工具方法和测试代码当时觉得挺省事。结果交上去做Code Review同事在diff里圈了好几个地方不是逻辑问题而是注释问题AI生成的中英文夹杂注释、一行空一行再注释、写了大量重复无意义的JavaDoc。同事直接问了一句这代码不是你写的吧然后要求我把所有注释改成项目统一的风格。这件事让我意识到代码风格也是团队规范的一部分。AI默认生成的注释常常过于啰嗦、格式夸张跟老项目的习惯格格不入。从那以后我在提示词里都会加一句注释风格与现有代码保持一致不写多余注释并且提交之前专门扫一遍AI改过的注释该删的删、该改的改免得给评审同事留下不好的印象。5.4 我的三层防线编译、单测、人工Review踩了这么多坑之后我给自己定了一套固定的三层防线所有AI生成或辅助编写的代码都要过了这三道关才算完成。第一层是编译和构建。AI生成的代码必须在我本地能编译通过、能启动起来。这一步能挡掉大部分不存在的API、错写的类名、漏掉的import。虽然低级但这是最基础的保底。第二层是单元测试。AI生成的业务代码我一定会让AI顺便生成一组覆盖关键分支的单元测试然后手动补充边界条件。测试过了代码大概率是正常跑的测试写不出来那说明代码本身可能有问题我会回头重新审视。第三层是人工Review。我会把AI生成的改动当成一个刚入职同事提交的草稿带着审视的眼光从头到尾检查一遍。重点看边界条件、异常处理、架构一致性、以及是否引入了不必要的依赖。说白了AI负责数量我负责质量。它帮我快速生成60分的代码再由我把它提到80分、90分。如果指望它直接交付90分的代码那大概率是要翻车的。6. 新人搭AI工作流的三个建议从能用到好用6.1 先固定环节再优化效率很多新人拿到AI工具之后第一个想法是我要找到最牛的提示词。但我的建议恰恰相反先别急着优化单次对话的效率先把整个开发流程梳理清楚。我是这样做的把一次完整的需求开发拆成固定的清单——读需求、提取要点、写方案、实现代码、写单测、自测、提交评审。然后在每一个环节旁边标注一个AI可用点写明这个环节里AI可以做什么、需要给它什么输入、期望它输出什么。比如读需求环节输入是PRD文本输出是需求要点和风险点实现代码环节输入是方法签名和约束输出是代码草稿。把流程固定下来之后你会发现每个环节的AI调用变得很机械、很稳定质量自然就稳了。这时候再去做效率优化比如改进某一个环节的提示词模板就能看得到明显的效果。先跑通流程再跑得更快这个顺序不能反。6.2 维护自己的AI命令集用久了之后我把自己经常用到的AI任务整理成了固定命令每个命令背后都对应一套完整的提示词模板。比如/explain解释一段代码输出逻辑说明、关键变量、潜在问题。/test根据一段代码生成单元测试覆盖正常、边界、异常场景。/review对一段diff做预审重点检查空指针、并发、资源释放等问题。/fix根据报错信息和相关代码给出修复建议或直接修改。每个命令我都在自己的笔记里存了固定的模板。这样每次使用我就不用重复组织语言直接套模板、填具体内容就行。这个动作看起来简单但长期积累下来节省的时间非常可观。更重要的是这个命令集是活的。我每个月会整理一次把哪些命令效果好、哪些命令经常翻车记录下来效果不好的就改进模板或者干脆废弃。半年下来整个工作流会越来越顺手。6.3 把踩坑心得变成团队文档最后这个建议是我觉得对新人最有长期价值的一件事把你在AI Coding过程中踩过的坑、验证过好用的模板、总结出来的原则沉淀成文字放到团队Wiki里。我在入职第四个月左右花了一个晚上把《AI Coding使用建议》整理了出来内容包括哪些场景适合用AI、哪些场景坚决不能用、我常用的几套提示词模板、几个典型的翻车案例。一开始我还担心写得不专业但后来团队里来了新的实习生和校招生他们看到这份文档之后少走了很多弯路。组长也因为这个事对我的印象分增加了不少。我觉得这就是AI Coding时代新人可以建立的一个独特优势你可能写业务代码的经验不如老同事但在怎么高效、安全地使用AI辅助开发这件事上你完全有机会成为团队里最熟的人。把这些经验固化成文档既帮了别人也帮了未来的自己。说到底AI Coding带给我的不是写代码更快这么简单。它让我这个经验不足的校招生在处理老项目、面对复杂需求时有了一份额外的底气。我始终记得一句话AI是我的外包队友而我才是那个要对最终结果负责的工程师。把这句话想清楚你就能在AI时代和所有新人拉开差距。
1. 先交代背景校招生的困境与我的破局思路1.1 入职第一个月我被真实项目毒打的场景我是去年通过校招进的大厂做的后端开发。进组之前我自认为代码能力还行算法题刷了不少项目也做过几个。但真正入职之后面对的第一个任务就让我懵了在一个维护了五六年的老订单模块里新增一种订单状态。听起来不复杂对吧但真实情况是那个模块有几千个类状态流转散落在不同的Service里数据库表结构里埋了不少历史字段还有几个定时任务在背后改状态。我需要先搞懂当前有哪些状态、谁在什么条件下改状态、新增状态会不会影响对账、会不会影响已有的定时任务。光是理清这些我在代码里翻了一个下午效率低到怀疑人生。后来我发现不只是我同批进来的校招生普遍都有这个问题在学校里练的是从零写一个系统到了大厂却是在一个庞大系统里做局部修改。前者只要自己逻辑通就行后者要求你先理解一堆别人的逻辑再小心翼翼地改动。而理解代码恰恰是新人最耗时间、也最容易遗漏细节的环节。也就是这个时候我开始认真思考怎么把AI接进我的开发流程。我当时的想法很朴素AI最擅长的不就是快速处理大量文本和基于已有信息做推演吗读代码、理逻辑、找线索这些事情正好可以交给它先跑一遍我做校验和决策。1.2 我理解的AI Coding工作流不是多了一个ChatGPT而是每个环节都有AI很多人以为AI Coding就是打开一个对话窗口把问题扔进去拿答案抄下来。我刚入职那几周也是这么干的结果并不理想要么AI给的代码风格跟项目完全不一致要么它引用了一个我们项目里根本不存在的工具类要么它给的方案看着对一编译就报错。问题出在哪出在我把AI当成一个无所不知的答题机器却没有给它足够的上下文也没有把它放到一个明确的流程位置里。后来我调整了思路把开发流程拆成一个个环节——读需求、写方案、写代码、写单测、做Review、查问题然后在每个环节里给AI布置一个带有明确输入和输出的子任务。比如读代码环节输入是一段代码文件输出是这段代码的逻辑说明和需要注意的副作用写代码环节输入是方法签名、数据模型和项目约束输出是可编译的代码草稿。这样一来AI就不再是一个飘在流程外面的聊天框而是嵌在流程里的一个个节点。每个节点做的事情都很窄但它能做得很稳我只需要检查它的产出而不是每次从零开始跟它对话。这个思路是我整个AI Coding工作流的核心也是后面所有经验的地基。2. 我把AI嵌入开发流程的四个环节从需求到上线的完整链路2.1 需求理解与技术方案让AI当文档速读员和方案质疑者新人在大厂接触需求最先感受到的往往是文档怎么这么长。一份PRD动辄几十页里面有背景、有规则、有各种边界情况、还有历史决策记录。我第一次独立接需求时光读文档就读了大半天读完还不敢说自己全懂了因为一些隐含的业务规则散落在评论区和旧需求邮件里。我的做法是把PRD的核心部分复制给AI让它做三件事——用三句话概括需求本质、列出所有显式和隐式的验收标准、把可能影响到的现有模块列出来。AI做这件事非常快而且它的概括能力比我这个新人强得多。它列出的验收标准里有些是我自己读文档时忽略的边界条件比如超时时间从哪一秒开始计算重复触发怎么处理。在技术方案阶段我会让AI扮演方案质疑者。当时我在设计那个新增订单状态的方案时先自己想了一个基于状态机的实现又让AI从并发、幂等、数据迁移三个角度提出质疑。它指出了几个我没考虑到的问题比如状态变更和支付回调同时发生时要不要加锁历史订单里是否可能出现这个新状态。这些质疑不一定都对但确实逼着我去查证、去补全方案。我觉得这就是AI在方案阶段最大的价值它不替你做决策但它能帮你把思考的盲区照亮。2.2 编码实现AI补全、生成单测、批量重构编码阶段是我日常用AI最多的环节细分下来主要是三类场景。第一类是补全样板代码。比如我要写一个根据用户ID查询最近N条订单的方法我会先写上方法签名和一段注释剩下的交给IDE里的AI补全。它通常会生成一个基本能用的实现我再根据项目的实际情况调整查询条件和返回值。这类任务逻辑简单、模式固定AI补全的准确率很高能省不少敲键盘的时间。第二类是生成单元测试。写单测是新人最容易忽略、但又必须做的事情。我的习惯是先让AI读一读目标类的代码然后让它生成一组测试用例重点覆盖正常路径、空值、边界值和异常场景。AI生成的测试用例不一定都能直接通过但它的覆盖思路往往比我自己拍脑袋想出来的更全我只需要把不合适的用例删掉、把缺少的断言补上。第三类是批量重构。老项目里经常有把所有StringUtil的调用替换成内部公共类这类机械性改动。让AI去做替换比人肉眼搜索快得多也少了许多遗漏。我自己动手前会明确告诉AI只做等价替换不改变任何业务逻辑不顺手优化其他代码。改完之后我会把diff从头到尾看一遍重点确认没有误伤。2.3 Code Review与自测让AI先审一遍再交给人提交MR之前我习惯让AI先把我的diff审一遍。具体做法是把改动涉及的文件和相关代码贴给它让它重点排查几类问题空指针、资源没关闭、并发安全、数组越界、事务边界错位。这些是代码评审中最常见的模式化问题AI扫一遍往往能发现一些我写完代码后自己看不出来的低级错误。有一次我写了一个异步线程池提交的任务AI提醒我线程池使用了无界队列且没有拒绝策略极端情况下可能导致内存溢出。这个提醒点醒了我后来我专门去查了项目里线程池的标准用法改成有界队列加拒绝策略。那一轮Code Review人工评审几乎没有提出线程池相关的问题。不过我也要说清楚AI的Code Review是低配版预审它只能发现通用模式问题理解不了业务上下文。它看不出你这个状态字段是不是和支付网关的约定不符也判断不了这个接口的返回结构是否满足下游的兼容性要求。所以我的态度是AI审一遍我自己再审一遍最后提交给人评审。它帮我挡掉一批低级问题但背锅的还是我自己。2.4 定位线上问题把AI当成日志分析助手新人最怕的就是线上出问题一收到告警就慌。我后来慢慢总结出一个相对稳的排查流程先把异常堆栈、相关代码片段、最近的改动记录这三样东西收集起来然后一起扔给AI让它帮我梳理可能的原因。有一次线上出现偶发性的空指针堆栈指向一个异步回调方法。我没看懂调用链是怎么走到那里的就把堆栈和附近的代码贴给AI它分析说这个对象在主流程里已经走完了生命周期异步回调拿到的可能是一个已经被释放的引用。我顺着这个思路去查果然发现回调没有做判空保护。那次排查比我对着堆栈干瞪眼高效太多了。但这里有个重要的提醒AI给的是假设不是结论。它经常给出三四个可能原因里面第一个看起来最合理但实际可能不是。我会把每个假设当成一条待验证线索逐一用日志和代码去确认而不是看到第一个原因就下结论。排查线上问题AI负责把搜索空间缩小做最终判断的依然是人。3. 大厂环境下的AI Coding选型合规、效率与成本的三方平衡3.1 为什么我几乎不用外网AI处理公司代码大厂对信息安全的要求非常严格公司的代码、业务数据、用户信息都属于内部敏感信息。把一段包含业务逻辑的代码原封不动贴到一个外部公开的AI网站里这个动作本身就有很大的合规风险。刚入职的时候组长就专门提醒过不要图方便用外网AI处理公司代码出了问题追责不是开玩笑的。所以我的基本原则是优先使用公司内部统一接入的AI能力比如内部平台提供的代码助手、IDE插件。这些工具的数据链路经过了合规审批代码不会流出公司边界。如果某个场景确实需要用外部模型我也会先做脱敏处理去掉真实的业务名词、变量名、注释只保留问题的通用结构。这里我也特别想提醒一些刚入职的同学不要因为外部AI工具用起来顺手就忽略公司的信息安全红线。你觉得自己只是问一个问题但在审计视角里这就是敏感代码外发。我在团队里见过因为随手贴代码被通报的案例真的很不值。3.2 团队常用的三类AI Coding工具怎么选我在实际工作中观察和接触到的AI Coding工具大概分三类各有各的适用场景工具类型典型形态优势需要注意的点IDE插件编辑器内的代码补全、对话框与编码流程结合紧密补全体验好通常不支持超长上下文对老项目的背景理解有限内部AI平台网页端或命令行工具功能全支持长文档、长上下文可以喂入多份代码文件需要在工具和编辑器之间来回切换流程感稍弱私有化部署的开源模型本地或部门内网部署数据可控可以针对项目做微调工程成本高需要维护非大团队一般玩不转以我的实际体验来说日常写代码最顺手的是IDE插件因为它就在你写代码的地方补全和基于选区对话都非常自然。但到了解读整个模块梳理完整调用链这种需要大上下文的场景IDE插件就明显吃力了我会改用内部AI平台把相关文件一次性喂进去。所以我的做法不是只认一个工具而是根据任务大小选择合适的工具。3.3 我给自己定的红绿灯使用原则接触AI Coding久了之后我给自己定了一套红绿灯使用原则用来快速判断一个任务能不能交给AI绿灯任务通用算法题、学习示例、正则表达式、SQL生成、单元测试草稿、模板代码。这类内容不涉及具体业务可以放心让AI发挥。黄灯任务涉及业务逻辑的代码、稍大一点的方案设计。我会先把关键信息脱敏或者只给AI抽象后的伪代码让它生成草稿再由我结合真实业务改写。红灯任务包含密钥、token、真实用户数据、核心交易逻辑的原始代码。这些绝对不会出现在任何外部工具的对话框里。这套原则帮我省了很多纠结的时间。遇到一个任务先看它属于哪个颜色再决定给AI多少信息。不要一概而论地全部给或者全部不给那样要么低效要么危险。4. 提示词工程的开发态玩法不是聊天是写代码4.1 为什么开发态提示词不能照搬聊天惯用法很多人跟AI对话还停留在聊天习惯上帮我看看这个这个怎么改。但到了开发场景这种模糊的对话方式会吃大亏。因为AI不知道你的项目背景、不知道代码风格、不知道你想要的输出形式它只能靠猜而猜出来的结果往往就是看起来合理但没法用。我自己的理解是在开发流程里应该把AI当成一个刚入职的外包同事。你把任务交给一个外包同事之前是不是要交代背景、目标、约束和交付形式对AI也是一样。背景告诉它项目用什么框架、什么语言目标告诉它要做什么约束告诉它什么不能做、要符合什么规范交付形式告诉它给我方法实现和简要说明还是给我一个完整的测试类。把这个思路想清楚之后我写提示词的方式就彻底变了。不再说帮我写个查询而是像下工单一样把任务描述完整。AI的产出质量也随之提高了一大截。4.2 一套我反复用的代码生成提示词模板下面这套模板是我用得最多、成功率最高的分享出来供参考背景项目是Java 8Spring Boot 2.7MyBatis数据库MySQL。 任务在OrderMapper中新增方法查询某用户最近N条未支付订单按创建时间倒序。 输入OrderDO字段包括id、userId、status、amount、createTimeOrderMapper现有查询风格见下方代码。 约束 1. 不改变现有接口签名不新增依赖 2. 使用项目已有的日志框架不自行引入 3. 遵循现有Mapper的XML写法不要用注解SQL 4. 只提供方法实现和对应的XML片段不解释原因。 输出方法代码 XML片段。这套模板的关键在于把背景、任务、输入、约束、输出五个要素都填满了。尤其是约束这一栏很多人会忽略。你不说不要引入新依赖AI就真的可能顺手给你引一个commons-lang3你不说遵循现有XML写法它就可能给你写注解SQL跟项目习惯完全不一致。还有一种情况项目里已经有类似的方法那我会直接把那一段代码贴进提示词里告诉AI仿照这段的风格写新的。这比任何口头描述都管用因为代码本身就是最好的风格说明书。4.3 上下文注入技巧把项目语境喂给AIAI在代码生成上最大的短板是不了解你的项目语境。同样是查询订单它不知道你的订单状态字段有哪些取值不知道你的软删除规则不知道你的分页规范。如果你什么都不给它只能凭常识猜猜错是大概率事件。解决这个问题的方法是上下文注入在提问或生成代码之前先把相关的上下文喂给AI。具体有这么几种做法第一种使用IDE类工具提供的文件上下文功能比如通过文件的方式把相关文件引入对话。这样AI在生成代码时能看到你正在操作的项目文件生成的代码风格会贴近项目实际。第二种手动摘录关键信息。如果工具不支持文件引用我会把相关的类定义、接口方法签名、数据库字段列表复制进提示词让AI基于真实结构去写代码。哪怕只是粘贴几个关键类效果也比空手提问好得多。第三种让AI先读再写。我在需要AI理解现有逻辑时会先给它几个相关文件指令是先阅读以下代码理解现有逻辑然后……。这样做可以让AI先建立对项目的认知再在这个基础上完成任务。我自己试下来这一道工序能让代码生成的质量明显提升尤其是涉及多文件联动的改动。5. 实测踩坑记录AI生成的代码为什么不能直接信5.1 幻觉高发区盘点AI生成代码不是不出错而是出错的方式很有迷惑性。我整理了自己踩过的和一些同事遇到的坑发现幻觉集中在这几类第一是不存在的API。AI会编出一个看起来很像标准库但实际不存在的方法或者把某个类名写得很真但一编译就报找不到符号。这类错误相对容易发现因为编译是第一道关卡。第二是错误版本的依赖坐标。比如让AI写一个使用Redis的工具类它可能给你一个org.redisson:redisson:2.9.0这样的坐标看起来没问题但实际这个版本跟我们项目用的Spring Boot版本不兼容。这种坑比不存在的API更隐蔽因为依赖能拉下来启动才会报错排查起来很费劲。第三是过时的用法。AI的知识有截止日期它可能还在推荐十年前的老写法。比如在Java里用Vector、在Spring里用已经被废弃的Autowired构造器注入形式或者在MyBatis里写早就被淘汰的配置方式。这些代码在单测里可能都是绿的但Code Review阶段会被有经验的同事打回去。5.2 翻车案例AI修复了一个根本不存在的问题有一次我把一段自己刚写完的工具类代码贴给AI做Code Review它很认真地指出了一个严重的线程安全问题说这个静态方法里使用了SimpleDateFormat存在线程安全风险建议换成DateTimeFormatter或ThreadLocal。我一开始真被它说服了因为SimpleDateFormat线程不安全是个经典问题。我还仔细检查了那段代码确认确实用了SimpleDateFormat。但后来准备改的时候我又重新读了一遍调用方才发现问题所在这个方法每次调用都会new SimpleDateFormat并不会跨线程共享实例所以根本不存在它说的线程安全问题。这个翻车案例给我的教训很深AI的Review会基于常见代码模式来臆想问题而不是基于这个项目的实际运行方式来判断。它看到SimpleDateFormat就想到了线程安全但它没注意到实例作用域。从那以后我再也不无脑接受AI的Review意见了。每个问题都必须回到代码里核实一遍确认它说的是不是真的。5.3 翻车案例注释风格的污染还有一个看上去不算bug但实际很烦人的问题AI生成的注释风格会在不知不觉中污染整个代码库。我有一段时间图快让AI批量生成了一些工具方法和测试代码当时觉得挺省事。结果交上去做Code Review同事在diff里圈了好几个地方不是逻辑问题而是注释问题AI生成的中英文夹杂注释、一行空一行再注释、写了大量重复无意义的JavaDoc。同事直接问了一句这代码不是你写的吧然后要求我把所有注释改成项目统一的风格。这件事让我意识到代码风格也是团队规范的一部分。AI默认生成的注释常常过于啰嗦、格式夸张跟老项目的习惯格格不入。从那以后我在提示词里都会加一句注释风格与现有代码保持一致不写多余注释并且提交之前专门扫一遍AI改过的注释该删的删、该改的改免得给评审同事留下不好的印象。5.4 我的三层防线编译、单测、人工Review踩了这么多坑之后我给自己定了一套固定的三层防线所有AI生成或辅助编写的代码都要过了这三道关才算完成。第一层是编译和构建。AI生成的代码必须在我本地能编译通过、能启动起来。这一步能挡掉大部分不存在的API、错写的类名、漏掉的import。虽然低级但这是最基础的保底。第二层是单元测试。AI生成的业务代码我一定会让AI顺便生成一组覆盖关键分支的单元测试然后手动补充边界条件。测试过了代码大概率是正常跑的测试写不出来那说明代码本身可能有问题我会回头重新审视。第三层是人工Review。我会把AI生成的改动当成一个刚入职同事提交的草稿带着审视的眼光从头到尾检查一遍。重点看边界条件、异常处理、架构一致性、以及是否引入了不必要的依赖。说白了AI负责数量我负责质量。它帮我快速生成60分的代码再由我把它提到80分、90分。如果指望它直接交付90分的代码那大概率是要翻车的。6. 新人搭AI工作流的三个建议从能用到好用6.1 先固定环节再优化效率很多新人拿到AI工具之后第一个想法是我要找到最牛的提示词。但我的建议恰恰相反先别急着优化单次对话的效率先把整个开发流程梳理清楚。我是这样做的把一次完整的需求开发拆成固定的清单——读需求、提取要点、写方案、实现代码、写单测、自测、提交评审。然后在每一个环节旁边标注一个AI可用点写明这个环节里AI可以做什么、需要给它什么输入、期望它输出什么。比如读需求环节输入是PRD文本输出是需求要点和风险点实现代码环节输入是方法签名和约束输出是代码草稿。把流程固定下来之后你会发现每个环节的AI调用变得很机械、很稳定质量自然就稳了。这时候再去做效率优化比如改进某一个环节的提示词模板就能看得到明显的效果。先跑通流程再跑得更快这个顺序不能反。6.2 维护自己的AI命令集用久了之后我把自己经常用到的AI任务整理成了固定命令每个命令背后都对应一套完整的提示词模板。比如/explain解释一段代码输出逻辑说明、关键变量、潜在问题。/test根据一段代码生成单元测试覆盖正常、边界、异常场景。/review对一段diff做预审重点检查空指针、并发、资源释放等问题。/fix根据报错信息和相关代码给出修复建议或直接修改。每个命令我都在自己的笔记里存了固定的模板。这样每次使用我就不用重复组织语言直接套模板、填具体内容就行。这个动作看起来简单但长期积累下来节省的时间非常可观。更重要的是这个命令集是活的。我每个月会整理一次把哪些命令效果好、哪些命令经常翻车记录下来效果不好的就改进模板或者干脆废弃。半年下来整个工作流会越来越顺手。6.3 把踩坑心得变成团队文档最后这个建议是我觉得对新人最有长期价值的一件事把你在AI Coding过程中踩过的坑、验证过好用的模板、总结出来的原则沉淀成文字放到团队Wiki里。我在入职第四个月左右花了一个晚上把《AI Coding使用建议》整理了出来内容包括哪些场景适合用AI、哪些场景坚决不能用、我常用的几套提示词模板、几个典型的翻车案例。一开始我还担心写得不专业但后来团队里来了新的实习生和校招生他们看到这份文档之后少走了很多弯路。组长也因为这个事对我的印象分增加了不少。我觉得这就是AI Coding时代新人可以建立的一个独特优势你可能写业务代码的经验不如老同事但在怎么高效、安全地使用AI辅助开发这件事上你完全有机会成为团队里最熟的人。把这些经验固化成文档既帮了别人也帮了未来的自己。说到底AI Coding带给我的不是写代码更快这么简单。它让我这个经验不足的校招生在处理老项目、面对复杂需求时有了一份额外的底气。我始终记得一句话AI是我的外包队友而我才是那个要对最终结果负责的工程师。把这句话想清楚你就能在AI时代和所有新人拉开差距。
