1. 当AI开始写代码我们到底在焦虑什么第一次用AI Coding工具补全一整段业务逻辑的时候我盯着屏幕上那几十行几乎不用改就能跑的代码心里冒出的不是兴奋而是一种很具体的危机感。这种感觉和当年从手写SQL转向ORM框架时完全不一样——那次只是换了个工具这次像是有人把手伸进了写代码这件事本身。AI Coding说白了就是让大语言模型参与到代码的生成、补全、重构、审查甚至调试环节里来。它现在能干的事情已经远超帮你补个for循环根据一段自然语言描述生成完整函数、读懂你项目里的上下文给出符合风格的实现、把一坨祖传代码翻译成另一种语言、自动写单元测试、在CI里当第一道代码审查员。适合谁来关注这件事我觉得不是只有一线开发技术负责人、测试、甚至产品经理都该了解它的边界因为这东西正在重新划分谁负责产出代码这条线。但热词里有个问题特别扎眼——AI Coding的到来会不会让代码质量下降。这个问题本身就说明大家已经默认了一件事AI写的代码量大、快、但未必靠谱。我自己的观察是代码质量会不会下降根本不取决于AI而取决于你有没有建立一套AI生成代码的治理规范。没有规范AI就是个不知疲倦的实习生一天给你提交两百个PR每个都埋着雷有了规范它就是个极其高效的结对伙伴。这篇东西我想聊的不是哪个AI工具最强这种会过时的对比而是把AI Coding真正落地到日常开发里需要想清楚哪些事、踩过哪些坑、以及那套让代码质量不降反升的规范到底长什么样。2. AI Coding工具的能力边界它到底擅长什么、在哪里翻车2.1 生成有明确模式的代码时它强得可怕我做过一个统计在三个不同类型的项目里记录AI补全的采纳率。结果很一致凡是有大量先例、模式固定的代码AI的采纳率能到70%以上。比如写一个标准的REST接口的Controller层、根据已有的DTO生成对应的Mapper、把一组字段拼成SQL的where条件、写一个符合项目规范的React函数组件。这类代码的特点是——结构高度重复变化点集中在少数几个字段名和类型上。AI在这种场景下几乎是降维打击因为它见过成千上万个类似的模式你项目里的那点变化对它来说就是填空题。我印象最深的一次是给一个老项目补数据导出功能。那个项目用的是自研的导出框架文档几乎没有但代码里有二十几个现成的导出实现。我把其中两个最典型的丢给AI当上下文然后描述照着这个模式给订单表加一个按时间范围导出的功能它一次就给出了能跑的实现连那个框架里一个很隐晦的分页参数都写对了。这种从现有代码里学模式的能力是AI Coding最被低估的价值——它不只是生成代码它是在帮你做代码风格的延续。2.2 涉及跨文件推理和隐含约定时它开始露怯但一旦任务需要跨越多个文件、依赖一些没写在代码里的隐含约定AI就开始出问题了。我踩过最典型的一个坑项目里有个全局的拦截器会在每个请求进来时往ThreadLocal里塞一个租户ID业务代码里到处都在用这个租户ID做数据隔离但没有任何一个地方显式地传递它。我让AI写一个新的查询接口它生成的代码逻辑完全正确但就是没考虑租户隔离——因为它看不到那个拦截器也理解不了这个项目里所有查询都必须带租户条件这条潜规则。这类问题的本质是AI看到的是代码的文本而不是代码运行时的上下文。它能读懂语法读不懂架构意图。所以我现在给AI派活有个原则——凡是涉及这个项目特有的、没写在类型系统里的约定我必须手动在prompt里点明或者干脆自己写这部分。指望AI自己悟出来等于赌它猜中了你团队三年的历史决策。2.3 一个实用的能力分级表为了让自己心里有数我整理过一张AI Coding任务的分级表按AI能独立完成的程度来分。这张表帮我决定哪些活可以直接甩给AI哪些必须自己盯着。任务类型AI独立完成度我的介入程度典型例子模式化代码生成高80%审查即可CRUD接口、DTO转换、单元测试骨架单文件逻辑实现中高60%补上下文审查一个独立的工具函数、算法实现跨文件功能开发中40%拆解任务逐段审查新增一个完整业务模块架构级重构低20%主导设计AI辅助拆分微服务、改数据模型疑难Bug定位低20%自己排查AI当助手并发问题、内存泄漏这张表不是绝对的随着模型能力提升每一档的完成度都在往上走。但跨文件和架构级这两档短期内我觉得AI都很难真正独立。原因很简单——这两类任务的核心难点不在写代码而在做决策而决策依赖的是对业务、对团队、对历史包袱的理解这些信息大部分不在代码里。3. 代码生成规范让AI产出能进主干的代码3.1 为什么必须有规范而不是靠审查时把关很多人觉得AI生成的代码反正要经过Code Review有问题review的时候拦下来就行了。我一开始也这么想直到有一次一个AI生成的工具函数被合并进主干两周后才发现它在处理空数组时返回了null而不是空数组导致下游一个统计功能静默出错。问题不在于这个bug多难发现而在于——当AI把代码产出速度提高三倍的时候review的压力也变成了三倍而人的注意力是有限的。你不可能对每一行AI代码都保持和手写代码一样的审查强度这不现实。所以规范的意义不是限制AI而是把审查成本前置。让AI在生成阶段就遵守规则比让reviewer在审查阶段抓问题要高效得多。我现在的做法是把团队的代码规范整理成一份专门给AI看的生成规范在每次让AI干活时作为系统提示的一部分。这份规范不需要很长但必须覆盖那些AI最容易违反、且违反了后果最严重的点。3.2 我实际在用的生成规范清单下面这份清单是我从踩坑里一条条攒出来的每一条背后都有至少一次真实的翻车经历。你可以直接拿去改改用。关于错误处理明确要求AI不允许吞异常。AI特别爱写try { ... } catch (e) { }这种空catch或者catch了只打一行日志就继续往下走。规范里必须写死catch块要么做有意义的恢复要么往上抛要么至少记录完整的堆栈和上下文。我见过AI生成的代码里一个关键的支付回调处理把异常吞了导致对账时才发现有订单状态没更新。关于空值和边界要求AI对每个入参做显式的空值判断并明确返回值语义。AI默认假设输入是正常的但生产环境的输入从来都不正常。规范里我会写集合类型返回空集合而非null字符串判空用工具类数值计算前校验范围。关于日志规定日志的级别和内容。AI生成的日志要么太多每个方法入口都打一行要么太少出错了什么都不打。我的规范是入口和出口不打日志关键分支和异常必须打日志里必须带可追踪的标识比如订单号、用户ID。关于命名和注释要求AI注释解释为什么而不是是什么。AI特别爱写// 设置name为张三这种废话注释。规范里明确禁止复述代码的注释只允许写为什么这么做的注释比如这里用悲观锁是因为并发下单场景下乐观锁重试成本太高。关于依赖规定不允许引入新的第三方依赖除非明确指定。AI有时候会自作主张引入一个你没用过的库来解决一个小问题这在有严格依赖管理的项目里是灾难。提示这份规范最好放在项目的根目录命名成类似AI_CODING_GUIDE.md然后在每次对话时让AI先读它。我试过把它塞进系统提示也试过放在文件里让AI自己读后者效果更稳因为AI能随时回看。3.3 规范要可执行不能只是原则我早期写的规范全是代码要健壮要考虑边界这种正确的废话AI看了等于没看。后来我改成可执行的写法效果立竿见影。举个例子要考虑边界改成对String类型入参必须判断null和空串对List类型入参必须判断null和isEmpty对数值入参必须校验是否在业务允许的范围内。这种写法AI能直接照着做因为它把边界这个抽象概念翻译成了具体的判断动作。再比如错误处理要合理改成catch块中禁止出现空实现如果选择记录日志日志必须包含异常对象本身而非仅异常消息如果选择恢复必须注释说明恢复策略。这种规范AI执行起来几乎没有歧义。我的经验是一份好的AI生成规范读起来应该像一份checklist而不是一篇散文。4. 多智能体协作当不止一个AI在帮你写代码4.1 单Agent的天花板在哪里用久了单个AI Coding助手你会发现它有个明显的天花板——它什么都得干但什么都干不深。你让它写代码它写让它审查它也审但它审查自己刚写的代码时往往看不出问题因为它带着我刚才就是这么想的这个偏见。这跟人是一样的自己写的代码自己review效果最差。多智能体Multi-Agent的思路就是把这个过程拆开一个Agent专门负责根据需求生成代码另一个Agent专门负责审查还有一个专门负责写测试。它们之间通过某种协议传递产物互相制衡。我实际搭过一套简单的三角色协作流程效果比单Agent好不少尤其是在代码质量上。4.2 我搭的三角色协作流程我的流程是这样的生成Agent拿到需求描述和项目上下文产出代码审查Agent拿到代码和一份审查清单逐条检查并输出问题列表测试Agent拿到代码和接口定义生成单元测试并实际运行。三个Agent的产物最后汇总到我这里我做最终决策。这里有个关键细节——审查Agent和生成Agent不能用同一个模型实例最好连提示词风格都不一样。我试过用同一个模型既生成又审查结果审查Agent几乎挑不出毛病因为它和生成Agent想法一致。换成不同模型后审查Agent能挑出不少生成Agent忽略的问题比如边界条件、异常路径。这其实很好理解不同的模型有不同的盲区让盲区不重叠的两个模型互相检查覆盖率自然高。4.3 协作流程里最容易失控的环节多Agent协作听起来很美但实际跑起来最容易失控的地方是上下文传递。生成Agent产出的代码审查Agent需要知道它的需求背景才能判断对错但如果你把完整的需求文档都传给审查Agent它又会被无关信息干扰。我踩过的坑是审查Agent拿到了一大段需求描述结果它开始审查需求本身是否合理而不是审查代码是否实现了需求。解决办法是给每个Agent定义清晰的输入契约。生成Agent的输入是需求上下文输出是代码一份简短的实现说明说明它做了什么假设、哪些地方不确定。审查Agent的输入是代码实现说明审查清单输出是问题列表。测试Agent的输入是代码接口定义输出是测试代码运行结果。每个Agent只关心自己那份输入不越界。这套契约定下来之后整个流程稳定了很多。5. 笔试场景下的AI Coding它到底在考什么5.1 笔试用AI考的是判断力而非记忆力现在越来越多的技术笔试开始允许甚至鼓励使用AI Coding工具这个变化让很多人不适应。传统的笔试考的是你能不能在有限时间里手写出正确代码而AI辅助下的笔试考的东西完全变了——它考的是你能不能快速判断AI给的代码对不对、能不能在AI卡住的时候自己顶上、能不能把一个大问题拆成AI能处理的小问题。我参与过几次这种形式的评估最大的感受是那些平时手写代码很强但不会用AI的人反而不占优势而那些平时就习惯用AI、知道怎么给AI喂上下文、知道AI会在哪里出错的人表现明显更好。这不是说手写能力不重要了而是说手写能力从必须现场展示变成了背后的基本功现场展示的是你和AI协作的能力。5.2 一个真实的笔试场景拆解我见过一道典型的AI辅助笔试题给一个已有的、有bug的排序函数要求修复它并补充测试。允许使用AI。这道题如果手写可能十分钟就搞定了。但在AI辅助下它其实在考几个层次的东西。第一层你能不能读懂这段代码的意图。AI能帮你分析但如果你自己读不懂你没法判断AI的分析对不对。第二层你能不能定位bug。AI可能会给你一个修复方案但这个方案可能只修了表面症状。第三层你能不能设计出覆盖边界情况的测试。AI生成的测试往往只覆盖正常路径边界情况得你自己想。第四层你能不能验证AI的修复真的有效。这需要你自己跑一遍而不是盲信。我观察下来很多人在这道题上翻车不是因为不会修bug而是因为太信任AI——AI说修好了他就提交了结果AI的修复引入了一个新的边界问题。所以笔试场景下AI Coding真正考的是你的验证意识和批判性思维。5.3 给准备这类笔试的人几条实在建议如果你要参加允许AI的笔试我的建议是第一提前熟悉你用的AI工具在读代码和改代码上的表现知道它的强项和弱项。第二养成AI给方案自己先质疑的习惯尤其是边界条件和异常路径。第三练习把问题拆解成AI能处理的小块而不是一股脑丢给AI。第四永远留出时间自己跑一遍验证别裸信AI的输出。第五如果AI卡住了别死磕自己上手写往往更快——AI不是万能的知道什么时候不用它也是一种能力。6. 代码质量会不会下降一个更诚实的回答6.1 质量下降的真实原因不是AI是审查赤字回到那个最扎心的问题。我的观察是AI Coding导致代码质量下降的案例几乎都有一个共同特征——团队把AI当成了产出加速器但没有同步增加审查投入。代码产出速度翻了三倍审查能力还是原来那点结果就是大量未经充分审查的代码涌入主干。这不是AI的错这是管理上的审查赤字。我见过一个团队引入AI后PR数量暴涨但reviewer还是那两个人结果就是review变成了走过场点个approve就合并。三个月后技术债爆发线上问题频出。后来他们的解法不是禁用AI而是把审查也AI化——用另一个AI做第一轮审查人只做第二轮。这样审查能力也翻了三倍才跟上了产出速度。6.2 质量不降反升的前提条件反过来我也见过AI Coding让代码质量提升的团队。他们的共同点是把AI生成规范做得非常细、把审查流程也AI化、并且坚持AI生成的代码必须有人类负责人。最后这条特别重要——每段AI代码都必须有一个明确的人类owner出了问题找这个人而不是这是AI写的。有了这个责任人机制人就会认真对待AI的产出而不是甩锅给工具。还有一个前提是测试覆盖率。AI写代码快写测试也快但前提是你要求它写。我现在的习惯是AI生成任何业务代码后必须紧接着让它生成对应的单元测试并且要求测试覆盖正常路径、边界路径、异常路径三类。测试跑不过代码不许合并。这条规则执行下来AI代码的线上故障率反而比手写代码低因为手写代码经常来不及写测试。6.3 一个反直觉的结论我现在的结论可能有点反直觉AI Coding本身不会让代码质量下降它只是把团队原有的问题放大了。一个本来就不重视审查、不写测试、没有规范的团队引入AI后质量会断崖式下跌而一个本来就有良好工程实践的团队引入AI后质量反而会上升因为AI能帮他们把那些知道该做但没时间做的事情比如写测试、补注释、统一风格真正做起来。所以与其担心AI让质量下降不如先审视一下自己的工程实践。AI是一面镜子照出的是团队本来的样子。7. 把AI Coding真正用顺手的几个实操心得7.1 上下文给得越具体产出越靠谱我试过同一个需求用两种方式让AI写。第一种是帮我写一个用户注册接口第二种是帮我写一个用户注册接口参考UserController里login方法的写法入参是RegisterRequest返回Result 需要校验手机号格式和密码强度密码用BCrypt加密注册成功后发一条欢迎消息到消息队列。第二种的产出质量比第一种高出一个档次几乎不用改。差别就在于上下文的具体程度。我的经验是给AI的上下文要包含四样东西参考代码让它学模式、接口定义让它知道输入输出、业务规则让它知道约束、边界要求让它知道异常怎么处理。这四样给全了AI的产出基本能直接进review。7.2 让AI先想后写能显著减少返工我现在让AI写复杂逻辑时会先要求它用自然语言描述你打算怎么实现先别写代码。这一步能过滤掉大量方向性错误。因为AI一旦开始写代码就会顺着第一行一路写下去哪怕方向错了也硬着头皮写完。而先让它描述思路你能在它写代码之前就发现这个思路不对省下大量返工时间。这个技巧在跨文件任务上尤其有用。让AI先列出我打算改哪几个文件、每个文件改什么你一眼就能看出它有没有理解错。确认思路没问题了再让它动手写。7.3 建立自己的AI代码审查清单最后分享一个我一直在用的东西——一份专门用来审查AI代码的清单。它和普通代码审查清单不一样针对的是AI特有的问题模式。审查项为什么AI容易在这里出问题空值和边界处理AI默认输入正常忽略异常输入异常是否被吞AI爱写空catch或只打日志是否有未使用的变量/导入AI生成时容易留下冗余日志级别和内容AI的日志要么太多要么太少是否引入了新依赖AI会自作主张用新库并发安全性AI很少主动考虑线程安全资源释放AI容易忘记关闭流、连接是否符合项目命名规范AI的命名风格可能和项目不一致每次审查AI代码我就对着这张表过一遍五分钟能筛掉大部分低级问题。这张表不是万能的但它能帮你把注意力集中在AI最容易犯错的地方而不是漫无目的地看。用AI Coding这一年多我最大的体会是它没有让我变懒反而让我对什么是好代码这件事想得更清楚了。因为当AI能瞬间产出大量代码时你被迫去思考——哪些代码是真正有价值的哪些只是看起来能跑。这种思考手写时代反而容易被能跑就行给糊弄过去。AI把能跑这件事变得太廉价了于是跑得好才真正凸显出来。