这一年多，我眼看着AI Coding从“偶尔拿来补个boilerplate代码”的小工具，变成团队里的默认生产方式。需求评审一结束，第一个动作就是开一个对话窗口，把上下文丢进去，让它先出一版，然后我们再进入code review。这个变化本身不是坏事，省掉了很多重复劳动，但正因为它来得太快太顺，很多现实问题反而被掩盖了。最近我在几个技术交流群和内部复盘里反复听到同一个困惑：代码好像都能跑，但review起来越来越费劲，线上问题并没有因为AI Coding变少，有些场景甚至更多了。这篇文章，我想把这些“现实问题”一块一块拆开，聊点结论性的、可操作的东西，而不是继续唱赞歌或者泼冷水。
1. 从尝鲜期走到生产依赖：AI Coding改变了我的工作模式
1.1 协作方式的三个明显变化
先说最直观的：协作方式变了。以前写一个模块，从接口设计、数据结构、异常分支到边界条件，很大一部分是在人脑里完成的，写代码只是把想清楚的东西落下来。现在很多人把“想清楚”这件事也外包给了AI，习惯性地先把需求扔进去，让模型先出一版“能跑的”，然后人再改。
这带来的第一个变化是：整体节奏变快了，但并行度反而变差了。以前两个工程师可以同时开发两个独立模块，各自清楚边界；现在一个人和AI交互、调整、再交互、再调整，这个循环是串行的。表面上单点产出速度快，但瓶颈转移到了“人审AI输出”这一环。我们团队里实测过，复杂的业务模块，AI初版的通过率大概只有两成，剩下八成的时间都花在挑毛病、补逻辑和重写关键分支上。
第二个变化是：白盒理解变成了黑盒信任。传统编码，你写下的每一行都代表着你对这个系统某个局部状态的理解。AI生成代码时，它是概率上“猜”出一段结果，而不是“理解”你的系统约束。我看到过很多同事拿着AI输出直接合入，理由非常统一：“看起来没什么问题。”这个“看起来没什么问题”恰恰是真正的问题——它把代码评审从“判断这段代码是否正确要我负责”变成了“这段代码看起来是否像正确的代码”。
第三个变化是：代码资产里开始混入大量非惯性代码。每个工程师都有自己的风格，但这种风格通常是稳定的、可预判的。AI不一样，它每次给出的是训练数据里最邻近的若干模式拼接，同一个团队里会出现风格完全不统一的代码段。这对长期维护来说是个隐患，因为代码的可读性很大程度来自可预测性，后面的人看到一段代码时，得先花时间弄明白“当时写这段的人为什么要这样写”。
1.2 为什么说“能跑”不是“能用”
我之前在一个支付项目里遇到过一次典型的AI Coding事故，印象很深。业务方要求增加一个“订单超时关单”的功能，需求很简单：下单后15分钟未支付，自动关闭订单。工程师把这个需求交给了AI，AI给出的实现是在订单创建时加一个定时任务，延迟15分钟执行，然后在这个任务里判断订单状态、执行关闭。
这套逻辑单独看完全正确，单测也过了。但走到线上之后，定时任务大量堆积，因为订单创建量一上来，每个订单都绑一个延迟任务，资源消耗直接翻倍。更麻烦的是，应用重启之后，内存里的延迟任务全部丢失，一部分订单永远不会被关闭。最终是我们review的人不够深，AI也没有“意识”到应该把这类功能设计成可持久化的调度或者用数据库状态扫描来处理。
这个案例很有代表性：编译能通过、单测能过、逻辑看起来也对，但放到整个分布式系统里，它缺少了“可恢复性”和“资源边界”的考量。这就是我强调的，AI Coding带来的不是代码质量断崖式下降，而是质量问题变得更隐蔽了。传统工程师可能在写代码时，因为熟悉系统，会自然避开这些坑；AI没有这个直觉，它给的是“局部正确”，而局部正确放进庞大系统里，很可能就是全局错误。
2. 代码质量有没有变差？只是劣质的来源换了
2.1 三类典型的AI生成代码问题
如果单纯用bug率去衡量，AI Coding时代的代码质量并不一定比人工时代更差。但这个指标是骗人的，因为劣质代码的分布发生了明显迁移。按我自己的观察，大体可以分成三类。
第一类是“过度自信”的逻辑漏洞。模型在生成代码时会自动补全一些看似合理的分支，但这些分支在真实场景里根本不会发生，或者恰恰把异常情况吞掉了。举例来说，AI经常倾向于在catch块里返回一个null或者空对象，然后调用方轻松解引用，直接NPE。这种问题我见过太多次了。你问AI它也会道歉，但下一条输出里它还是照样写。原因是训练数据里太多浅层处理异常的示例，模型学会了“看起来在处理异常”，其实并没有。
第二类是“架构无感”的局部实现。AI对整个系统的模块划分、依赖方向、事务边界是没有概念的。它只知道给你一个可以独立运行的片段。所以经常出现有人把一段通用逻辑直接写死在某个业务Service里，或者一个本该通过事件解耦的动作，被硬编码成同步远程调用，最后耦合得死死的。代码评审时你问“为什么要放在这里”，回答是“AI生成的，我没仔细想”。
第三类是“安全隐患”的低频渗透。这个最可怕。我做过一次摸底，拿一套常见业务CRUD让几个主流模型分别生成，然后让安全团队做扫描，结果涉及越权检查的地方几乎都遗漏了。因为模型对业务鉴权模型没有理解，它只能按接口参数是否传入去判断。代码质量在这里已经不是风格问题，而是底线问题。可以说，AI生成的代码在逻辑正确性上表现尚可，在安全边界、资源边界、事务边界这些“隐性约束”上，表现是明显偏弱的。
2.2 质量控制的重心必须前移
既然劣质来源变成了隐性约束，那质量控制就不能再依赖事后测试和线上监控。我现在的经验是，把控制重心前移到需求拆解和代码约束定义阶段。
以前我们做技术设计，核心是告诉“未来的自己或同事”这段代码如何工作。现在做技术设计，核心变成了“如何给AI划定边界”。我拿我们团队现在的一条workshop流程举例：在开工之前，必须先把接口契约、数据结构定义、异常码分段、事务边界、幂等方案画清楚，然后把这些内容连同需求一起喂给AI生成实现。这样做最大的好处是，AI的自由发挥空间被压缩了，它做的是“翻译”，而不是“创作”。
其次，测试策略也要变化。纯AI生成的代码，我会要求必须补三类测试：异常路径测试、并发/重复执行测试、依赖隔离测试。这三个方向是最容易暴露隐性约束缺失的地方。有同事问我为什么对AI代码这么苛刻，我说很简单：人工代码的错误常常是发散性的，例如业务理解偏了、逻辑漏了，这些问题在同行评审里容易被同行发现；AI代码的错误是聚集性的，它集中在那些“看起来像是那么回事但并没有真正符合系统规则”的地方，不刻意去逼它，它不会露馅。
3. “AI Coding工程师”究竟是工程师还是AI产品用户
3.1 标题背后的身份困惑是真实的
“AI Coding工程师属于人工智能工程师吗”这个热搜问题，我刷到的时候确实愣了一下。说实话，这个困惑不是凭空出现的。现在很多招聘JD上开始写“AI Coding工程师”，要求里通常列着会使用某某AI代码工具、能写Prompt、了解主流模型特性、能够对AI生成代码做校验。看起来，这好像和传统的“人工智能工程师”确实沾点边了，至少名字里都带“AI”。
但我的判断是：不要被名字带着走。人工智能工程师的核心工作在于模型训练、推理优化、数据闭环，背后是对机器学习算法原理、分布变化、评估体系的理解。AI Coding工程师的核心工作则是怎么在软件交付流程里高效使用AI作为生产力工具，并且保证输出质量。这两者确实有关系，但关系不在“算法”层面，而在“工程化应用”层面。一个会用AI写代码的人，离人工智能工程师的距离大概和一个会用机器学习库调参的人离算法科学家的距离一样远——能解决实际问题是好事，但职业底层的硬功夫是不同的。
我并不是说“会用AI写代码”这个技能没有价值。恰恰相反，这个技能在接下来几年会越来越值钱。但它的价值点是“帮你成为更好的软件工程师”，而不是“让你转行成为人工智能工程师”。很多年轻同事问我，说现在还需要不需要死磕数据结构和系统设计。我的回答一直没有变过：需要，而且比以往更需要。AI可以帮你写代码，但代码写完之后，它运行在什么体系里、瓶颈在哪里、如何评估取舍，这些决策仍然全部压在人的判断上。你在系统中的位子，取决于你在这条决策链上的贡献，而不是你调用了多少个AI输出。
3.2 工程师差异化能力在新的协作模型里被重新放大
还有一个角度也值得说：AI Coding真正淘汰的，不是编码能力弱的人，而是思考能力弱的人。工具本身并不会让平庸工程师变成优秀工程师，它只是把每个人的“判断力”更直接地暴露出来。
以前一个工程师判断力弱，写出来的代码可能是几百行冗余但基本能跑，一时半会看不出问题。现在判断力弱直接表现出来就是：给AI的输入是模糊的，出来的代码是拼凑的，评审时完全说不出为什么对或不对。这类工作流产出的问题代码比例非常高。反而是那些基础扎实、系统理解深的工程师，用AI Coding之后如虎添翼，因为他们能给出精准的约束和清晰的目标，也能快速识别AI输出的问题点。
所以我反而觉得，AI Coding流行之后，资深工程师的核心竞争力——系统设计能力、抽象能力、风险识别能力——被进一步放大了。工具提高了整体产出速度，但系统摩擦也同步放大了，太多人同时产出大量半成品代码，对整个架构的考验是空前的。这个局面对“资深的人”更有利，对“只会敲代码的人”更不利。把这一点想明白，大概就不会纠结称呼到底是工程师还是产品用户了。
4. 建立可执行的AI代码生成规范，比争论更重要
4.1 没有规范的AI Coding，是团队层面的技术债加速器
关于“AI Coding的到来会不会让代码质量下降”，我一直觉得这个问题问反了。AI本身不会让代码质量下降，但如果团队没有针对AI Coding的规范，它大概率会在短期内加速技术债的堆积。区别只在于谁来还，以及用什么利息还。
我们团队花了大概两个月时间，建立了一套比较落地的AI代码生成规范。核心不是限制使用AI，而是限定时AI可以参与的部分，以及它必须交出的最低质量。规范刚出来的时候有同事觉得多此一举，说AI不过是自动补全的升级版。等到真的执行了两周，几乎每个人都感受到了差别：之前那种“横七竖八什么风格都有”的review现场明显缓解了。
我简单分享几条现在对团队最有用的规则，它们都是踩过坑之后沉淀下来的，不一定适合所有团队，但可以当做一个起点。
第一条：AI生成的代码必须标注来源。我要求每个merge request里明确标出哪些代码由AI生成、哪些由人改写。看起来只是一行注释，但实际上它逼着每个人去区分“我审查过并理解了AI的输出”和“我直接粘贴了AI的输出”。区分这两者恰恰是评审的核心。
第二条：禁止AI直接生成跨模块调用代码。凡是涉及两个及以上模块协同的，必须由人写出调用的接口定义和依赖方向，AI只负责填充函数内部实现。这会损失一部分效率，但换来的是架构不会被AI的随机性侵蚀。
第三条：核心链路（支付、鉴权、数据一致性强相关逻辑）禁止AI从零生成，只能让AI在已有代码框架内做局部修改，并且必须补充对应场景的测试。给AI留一个可以自由发挥的区域，不给它在底线善变的区域表现的余地。
4.2 一个可供参考的AI Coding工作流模板
再深入一点，我们实际把AI Coding拆成了三个阶段的流水线，这样做是希望每一步的输出都能被检查、被控制。
需求解析阶段：把产品需求转化为技术任务，明确涉及的业务的上下文、数据库表、接口契约、异常处理要求。这一步完全由人来完成。现在很多AI Coding失败，本质上是需求没解析到位，而不是模型能力不行。把这一步做好了，后面大概能省一半的返工时间。
生成实现阶段：允许AI生成第一版代码。但给定输入不是一句话需求，而是一份结构化的任务描述，通常包括输入输出定义、边界条件说明、禁止使用的模式、参考的现有代码风格。我在实际使用中发现，给AI的上下文限制越明确，产出的代码越接近“团队风格”，后续人工修正成本越低。
评审落库阶段：人对AI生成的代码做逐行审查。这个环节我要求必须回答三个问题：这段代码有没有引入没想到的中间状态？它在这个系统的扩展方向下是否可持续？如果下个维护者是三个月后的新人，他能不能看懂？三个问题有一个答不上来，就退回重写或者改到通过为止。
这三个阶段听起来没什么科技含量，但真的严格执行之后，团队对AI Coding的信心反而增加了。以前大家用AI是“偷偷用”，出了锅还得藏着掖着；现在规则明确了，AI能做什么、不能做什么、人要负责什么，边界清楚了，协作起来反而坦荡。
5. 知识传承与新人培养：AI Coding给团队带来的长远问题
5.1 新人还能不能通过阅读代码来学习系统
我最近带了个转岗过来的中级工程师，基础不错，但在第一个复杂任务上出现了明显的瓶颈。那个任务牵扯到存量系统里几个模块的隐式协作，我让他先通读相关代码，把调用关系画出来。他看完之后跟我反馈：代码量有点大，但已经照着AI生成的注释梳理了一遍，感觉模块之间像是靠事件驱动的。
我打开他整理的文档一看就明白了。问题出在AI给存量代码生成的注释上。那些注释解释了这个函数是干什么的、参数是什么、返回值是什么，非常标准，但完全没有解释这些函数之间的时序关系、异常恢复顺序、以及为什么这个模块要先更新库再发事件。换句话说，AI生成的注释是高密度地解释“代码在做什么”，但没有解释“系统是如何运转的”。
这让我意识到一个问题：AI Coding正在悄悄改变新人的学习路径。以前一个新人进入团队，通过通读存量代码，能逐步建立对系统的整体心智模型，因为代码本身的风格、结构、蛛丝马迹都在讲述这个系统的演进过程。现在大量代码由AI生成之后，风格趋于平滑、结构趋于同质化、逻辑趋于局部正确，新人在阅读时获得的“历史信息量”大幅下降。他们能看到“现在长什么样”，但很难看到“为什么长成这个样”。
5.2 把“系统文档”和“业务决策记录”变成刚需
针对这个问题，我们做了一件新团队通常不爱做的事情：把系统设计文档和业务决策记录重新立起来，并且和AI生成代码强绑定。以前我们走敏捷，觉得文档是累赘，代码本身会说话。现在发现，在一个AI大量产码的世界里，代码不说话，它只会复述训练数据的平均态。真正让一段代码区别于AI平均态的，恰恰是那些写在文档里的业务约束和取舍过程——这些AI不知道，也不可能知道。
现在的规则是：任何核心模块的变更，merge request里必须带一段“决策说明”，不用很长，两三段就可以，写清楚为什么这样设计、有哪些取舍、和以前实现的差异是什么。这个东西不单是为了给AI提资，更是为了给后人保留“系统之所以是这样”的上下文。从长期来看，这比任何代码注释都重要。
新人培训也被迫改了方法。以前是“先读代码，再看文档，再上手”；现在是“先看决策记录，再带着问题读代码，再把AI当解说员用”。我把这套方法叫作“解题式入职”，效果不错。新人不会一头扎进迷宫的AI代码里，而是先建立骨架，再让AI帮他们快速了解局部细节。
6. 我的个人结论：与其抵制或者盲从，不如把AI Coding纳入工程体系
说回最初的热搜词：“AI Coding的到来会不会让代码质量下降”。我个人的结论很明确：如果不做干预，是的，它会下降；如果把它纳入工程体系认真治理，它反而可能是近年来少有的提升代码质量的机会。因为AI Coding第一次把“编码过程”和“编码意图”分开了，你有机会用一种以前做不到的方式去审计每一个产出单元——每一段代码都能被追溯到是AI生成的还是人工精调的，这在过去靠人肉风格识别是完全不可能的。
在这个前提下，我认为接下来最值得投入的事情有三件。第一，把“AI Coding规范”当成一等公民来建设，像当年推行代码规范、测试规范一样，认真定义生成边界、审查流程、红线场景。第二，加强人对系统的理解，尤其是资深工程师要主动承担“决策记录”的责任，把隐性知识显性化，否则AI会让我们这代系统的演化彻底变得不可解释。第三，每隔一段时间做一次代码资产体检，把AI生成比例最高的模块拉出来重点review，因为那里大概率是技术债最密集的地方。
我自己现在的实际体会是，AI Coding已经不是一个要不要用的问题，而是怎么用才能不失控的问题。你每天开多少个AI对话窗口不重要，重要的是你合入代码之前，有没有用人的判断力在AI输出上再踏踏实实踩一遍脚印。这个脚印，说到底才是区分“工程师在编程”和“程序员在搬运”的那道分界线。
