让我下定决心把用户中心那两千行代码全部删掉的是一个周六凌晨两点半的告警电话。线上订单状态出现了不该出现的穿越——从已发货跳回待支付。我顺着日志一层层翻到源头发现生产环境里躺着一套智能缓存逻辑。那段代码是AI写的也是我亲手提交的但那一刻我完全无法在十分钟内解释清楚它为什么会把状态写回去。这就是氛围编码两年攒下的烂摊子。所谓氛围编码指的是我们这一代开发者的一种新工作状态不是自己在写代码而是围着AI编码助手打转——它生成我审查我微调我提交。表面上每天产出很多功能也按时上线但代码库里正在悄悄沉淀一大批看起来合理、没人能真正讲清的逻辑。这篇文章不是要批判AI工具而是想把这两年里我踩过的坑、攒下的技术债、以及最后逼着我回到手工重写现场的完整过程原原本本讲清楚。如果你也正在一边用AI辅助写业务逻辑一边隐隐觉得代码库里有些地方有点不太对劲这篇文章应该对你有用。1. 所谓的“氛围编码”两年里是怎么一步步把我带偏的1.1 从“AI帮我写CRUD”到“AI替我写核心逻辑”最早用AI编码助手的时候我给自己划了条线只让它生成样板代码比如DTO、接口定义、单元测试的壳、数据库访问这类无脑内容。那段时间确实爽枯燥的重复劳动消失了我腾出不少精力去思考业务流程。但这条线在不知不觉中就被侵蚀了。原因是每当接到需求打开编辑器光标停在空函数体旁边我的第一反应已经不再是自己动手去填而是先让AI写一版。刚开始还只是让AI补全常规实现后来慢慢就变成了让AI设计状态机的流转、制定缓存策略、决定数据库索引的组合。到了第二年我已经在让AI替我决定一个模块该分成几个类、每个方法应该承担什么职责。最典型的滑坡场景发生在一次优惠券模块的改造里。需求是新增部分商品可用券的规则。我让AI分析现有的券匹配逻辑它给了我一个方案把原来的大判断拆成了七个策略类每个类里还有自己的工厂方法。我当时review的时候只是扫了一遍嗯策略模式挺正规的。我甚至没逐行去看每个策略类里的边界判断是怎么写的。结果上线后不到两周就出现了一个组合券叠加后比原价还贵的问题。后来我反思了一下那条只用AI写样板的线其实早在第一次发现AI写出来的东西比我想的更完整时就已经断了。完整感是一种特别有迷惑性的东西AI生成的代码注释齐全、分层讲究、命名规整你会下意识觉得它已经想清楚了从而降低自己的审查标准。1.2 短期反馈的陷阱功能都按时交付了为什么还会崩更让我警惕的是这种工作方式在很长一段时间里完全没有暴露问题。迭代照常走接口照常发布产品经理问我进度我还能提前报个做完。因为氛围编码省掉的是打字时间而打字这个动作在传统开发流程里恰恰承载了一个非常重要的隐性功能——思考。以前手写一版逻辑你从头敲到结尾会经历需求→抽象→建模→实现→验证的完整回路。每敲一行代码你都在逼自己回答下一步应该怎么走。而AI代写时代的回路变成了需求→提示词→生成→审查→接受。这个回路里缺了一环你没有真正构建过那个模型所以你审查的时候只能抓住语法层面的问题抓不住业务层面的漏洞。功能能跑、测试能过、前端联调没问题这些短期反馈全部正常。但真正的代价在三个时间点集中爆发一是需求变更的时候AI生成的代码往往只贴合当时的理解一旦语义变了改起来比重新写还难二是线上数据出问题的时候排查链路长到让人崩溃三是代码需要被别人接手的时候没人能回答为什么这里要用这样一套结构。我当时完全没有意识到自己正在干一件很危险的事把最需要人类决策的环节——技术方案设计和业务逻辑建模——交给了概率模型。等到发现的时候代码库已经不是我熟悉的那个代码库了。2. 烂摊子的五种典型症状AI生成代码在真实项目里的失控现场老话说得好所有的技术债都会以某种方式找上门但不会以一种整齐划一的姿态。这两年攒下来的烂摊子在我决定重构之前已经以五种非常具体的形态暴露出来了。2.1 同一个业务逻辑的“五个尸体”重复代码的滋生速度远比想象中快最让我沉默的不是代码写得烂而是同一套业务逻辑在项目里被复制了五份每一份还都略有不同。比如订单超时关单的逻辑我在订单服务里看到一个if判断版本在营销服务里看到一个状态机版本在定时任务里看到一段直接操作数据库的脚本版本在消息队列的消费者里又看到一个加锁版本。为什么会出现这种情况因为每当我丢给AI一个新的需求场景它不会去全局扫描这个项目里是否已经有一个类似的逻辑它只会在当前上下文里生成一个看起来合理的新实现。而我当时也没有意识要去推动复用——我觉得反正AI写得快新写一份的成本极低没必要去翻旧代码。于是两年下来系统中同一个概念有N种表达。明明都是订单状态有的模块用整数枚举有的用字符串常量有的用一个布尔字段做推断。这种重复代码的可怕之处在于它不是一眼就能看出来的简单复制而是每个副本都进行了小幅度的定制有的加了日志、有的换了缓存逻辑、有的包装了领域事件。等到业务要统一规则的时候你必须同时改动五个地方而每一次改动都会引出新的不一致。2.2 套娃式抽象每一层都没有非存在不可的理由AI生成代码还有一个显著倾向就是特别热衷于抽象。曾经有一段时间我们的业务代码层的结构是Controller → Service → Manager → Repository → DomainService → Executor。每次排查一个问题都要在六层之间跳来跳去每一层做的事情都是把参数从一个对象赋值到另一个结构几乎完全相同的对象。这个抽象层次里很大一部分是AI根据提示词里的可扩展性单一职责等词汇生成的。它可能是在海量开源代码中见惯了这种分层就把这个结构搬了过来。但实际上我们绝大多数业务逻辑根本不需要那么深的调用链。多出来的层既没有带来可测试性也没有带来清晰的职责边界反而制造了一种很规范的幻觉。我后来总结出一个标准一个方法如果说不清自己存在的理由那它就不应该存在。重构的时候我删掉了一个Manager层和一个Executor层后整个模块的行数少了一半而行为完全没变。那些层从诞生到死亡几乎没有任何业务真正从中受益。2.3 异常处理的两张面孔要么吞掉异常要么原地爆炸AI生成的异常处理总是走向两个极端。第一个极端是吞掉异常。比如很多AI生成的catch块会写成catch (Exception e) { log.error(..., e); return null; }然后在调用方没有任何兜底。这种代码在单测阶段完全无恙因为正常路径走不到异常分支。可一旦线上存储抖动、网络超时或者并发冲突函数直接返回null上层代码根本不知道发生了什么业务数据静默丢失。第二个极端是原地爆炸。AI为了让错误可见会把异常直接抛出去但抛的是最顶层的Exception连最基本的错误分类都没有。这一头调用方拿到一条无法判断是参数错误还是系统故障的异常只能统一变成500给前端。排查一个简单的校验失败要翻完整条调用链才发现其实只是缺了一个必填字段。健康的异常处理应该做三件事识别异常的类型、决定是重试还是降级、记录足够定位的上下文。但AI生成的代码大多数时候只会机械地打印日志或者向上抛出这两个动作其实都不算处理。这个问题的本质也还是同一个——模型不理解你的系统里哪些错误是可预期的哪些是不应发生的。2.4 命名和风格的“精神分裂”同一个对象的三张脸代码风格不一致的问题在很多团队里本来就有但AI把这个问题放大了好几倍。因为AI模型会根据上下文中已有的代码样本去模仿风格可是你喂给它的每个人工示例本身风格就不统一。同一个用户在用户模块叫user在账户模块叫account在会员模块叫member。同一个动作在一个文件里叫query在一个文件里叫fetch在另一个文件里叫search。更头疼的是格式化习惯。有的方法参数换行缩进四格有的用注释块把函数分节有的喜欢把类型断言堆在一起有的又完全依赖隐式类型转换。这些差异单看某一处都不致命但整库混在一起的时候人脑光处理风格差异就要消耗很多注意力解读代码的脑力被白白浪费掉了。我还见过一个极端的例子AI在一个方法内部同时混用了两种命名规范局部变量用小驼峰函数内部的中间状态又用下划线风格。原因大概就是模型训练数据里这两种风格都存在它在生成时随机选择了。这种代码格式化工具可以修复一部分但命名所代表的概念一致性问题格式化救不了只能靠人重新定义统一词汇表。2.5 莫名其妙的高级特性炫技最后一种症状最让人无语也最危险——AI特别喜欢用一些看起来很酷、实际上完全不必要的高级特性。可能是因为训练数据里优秀开源项目的影子太深了AI在生成代码时倾向于把简单问题复杂化。我见过一个只有三个字段的配置读取逻辑AI给它设计了一个泛型工厂加策略注册表加函数式接口的组合目的只是为了读取一个字符串配置。还见过一段找最大值的小逻辑被写成了三行流的链式调用加自定义Collector。另一个同事接手的时候惊呼这段代码是要参加比赛吗炫技代码的直接后果是提高了理解门槛。本来三分钟能读懂的逻辑变成了需要查文档才能明白的黑魔法。在AI辅助编码的语境下这其实是模型自身的过度拟合——它见多了工业级代码里复杂的抽象模式却没有判断这段业务配不上这么高级的写法的能力。3. 真正逼我动手的那次事故从一次线上告警到全面代码体检3.1 事故还原一个“看起来没什么问题”的PR直接把我逼到墙角的那次事故发生在一个再平常不过的周三。业务方反馈部分用户账户里的逾期金额计算有误个别单子多扣了钱。排查的过程非常痛苦。这个计算逻辑在两个服务里各有一份服务A是先查余额再算减免服务B是先算减免再查余额。两个服务都用了同一个优惠金额取整的公共工具函数。我一行行翻git提交记录发现这个工具函数在三个月前被重构优化过——从原来的向下取整改成了四舍五入。当时改动这个函数的人是谁是AI提交者是我。我甚至能回想起那个下午我提交需求让AI优化这段代码它给了个新函数我没仔细看取整规则就点了接受。业务上逾期金额一直采用向下取整四舍五入会导致优惠多算零点几元。单看一笔账没什么但系统每个月处理百万级订单这个差异被放大了成百上千倍。整个排查花了八个小时。八个小时里我在翻提交记录、比对历史版本、看当时的PR描述、复盘当时的review心态。真正让我背后发凉的是如果这是一个必须由我承担责任的生产事故那么我甚至无法在事发时第一时间说出这个改动是怎么回事。我对自己提交的代码的理解还不如对AI生成它的完整度有把握。3.2 体检结果比我想象的更糟处理完事故我给技术负责人提了一个请求把核心交易链路和用户中心的存量代码做一次全面体检。体检的方式不是纯人工阅读因为代码体量太大了我先把能量化的指标全部跑了一遍。体检结果让我彻底清醒。全库重复代码率接近32%核心业务模块的圈复杂度普遍偏高有六个函数的圈复杂度超过了30说明它们内部塞了太多分支。单元测试覆盖率名义上有55%但把冗余断言和只跑正常路径的用例去掉真正有行为验证能力的不足20%。更扎心的是可解释性测试我随机挑出核心模块的十五个方法让团队里负责这块业务的同事在不看git记录的前提下解释每个方法的完整业务意图结果有九个说不清。那种感觉就像是你在年底盘点仓库本来以为只是有点乱结果发现架子上堆满了没有标签的箱子有些箱子你甚至不知道是谁放进去的更不知道里面装的是什么。体检报告给出了一个再清晰不过的结论这不是局部需要优化的问题是一套系统性失控的代码库。体检指标健康参考区间实测情况说明重复代码率低于10%约32%同一业务逻辑多份实现圈复杂度平均不超过10多个函数超过30长函数、深分支、状态处理混乱有效测试覆盖率高于60%低于20%大量用例无行为验证能力模块可解释性高于80%40%左右团队无法讲清方法的业务意图提交记录可追溯性明显大量AI生成代码无设计说明只知道改了不知道为什么改3.3 最后一根稻草新需求没人敢改体检报告是冷冰冰的真正让我破防的是接下来发生的事。新的迭代里业务方要调整订单取消规则。放在以前这是一个中等复杂度的需求两个后端开发一周就能完成。但这次没有人愿意接。模块的负责人私下跟我说我不是不想改是我不敢改。那个状态机我点进去看过三次到现在都没彻底搞明白它怎么从退款中变到已关闭的。这句话比任何体检报告都有杀伤力。一个代码库一旦让维护它的人产生了恐惧它的维护成本就已经失控了。于是我做了个决定先停两个迭代的新功能把订单状态管理和用户账户金额计算这两个核心域全面重写。是的手动重写不是一个函数一个函数地找AI要补丁而是先让代码回到一个人能够理解的状态。4. 重构前必须做对的三件事先给系统做一次存量盘点我在开始动手之前心里很清楚一件事重构最忌讳的就是情绪化推翻。看着旧代码难受就直接开删最后很容易删掉还活着的逻辑。所以我在动手前花了整整一周时间只做盘点不写代码。4.1 定义边界哪些代码“能救”哪些代码“该扔”我把模块里的代码分出了三档保留、改造、重写。保留的标准有三个。第一有测试保护至少覆盖了主路径和关键异常路径第二结构简单一眼能看懂改起来有信心第三自上次上线以来需求稳定没有反复变动。这类代码我不会碰哪怕它写得不够优雅也不碰因为重构它们不产生业务价值反而引入回归风险。改造的标准也有三个。第一逻辑本身是对的但可读性太差第二存在明显的重复实现可以收敛到一个公共逻辑第三单测缺失但业务路径稳定先补测试再改结构。至于重写我判断的核心标准只有一条模块内没有任何人能清晰解释它为什么要这样设计。不管这个逻辑是AI生成的还是历史遗留的只要团队失去了对它的理解能力它就已经是负债而不是资产。另一个信号是这个模块每次出问题都集中在同一片区域而且每次修复都只是打补丁从不触及根因。4.2 用静态分析指标给代码库做一次量化体检光靠感觉判断该扔还是该救还不够我用工具跑了一套量化指标。先统计重复代码分布定位哪些文件是高发区再算每个函数的圈复杂度和认知复杂度找出那些看一眼就头疼的长函数最后检查模块之间的耦合关系找出那种改一个方法会波及八个服务的中心节点。这里有一个非常实用的经验把圈复杂度和最近三个月的变更频率放在同一张四象限图里看。高复杂度低变更频率的代码属于沉睡的雷区暂时别动但要做好标记高复杂度高变更频率的代码是重写的首选目标因为改得频繁说明业务活跃你每一次改动都在反复为之前的设计付费低复杂度高变更频率的代码往往是被过度拆分或者被外部依赖反复拖累的需要顺着引用链重新梳理。用这套方法我在用户中心里圈定了重写范围订单状态流转、账户金额计算、优惠规则匹配三个域。其他的哪怕也有点乱我忍住没碰。4.3 建立一个可回滚的基线任何重构都有翻车风险所以我的原则是在重写核心模块之前先建立一个行为基线。具体做法是三步。第一步把现有系统的重要输入输出记录成契约样本包括典型的正常路径、边界路径和异常路径至少覆盖线上出现过的情况第二步为现有模块补一层特征测试——不验证内部结构只用固定输入去对比输出确保重写后的行为能与旧行为对齐第三步在版本管理工具上切一个独立的实验分支把重写工作全部隔离在这个分支里主分支冻结非必要的结构性变更。我特别强调一致行为对比这一条。重写核心业务的时候最怕的不是写不出新代码而是写出一个看起来更优雅但行为和旧系统不一致的新代码。特征测试的意义就在于当你重构到一半的时候随时可以跑一遍对比知道自己目前偏离了基准行为多远。那些偏差里有的是故意修正的bug有的则是意外引入的回归——后者必须在合并之前处理干净。5. 我如何重新手写一套可落地的“反氛围编码”重构方法盘点做完基线建立好接下来就是真正的重写阶段。这一阶段我给自己定了一个特别的规矩核心逻辑从设计到实现必须是我本人手写。AI可以用在辅助验证、生成测试框架和样例数据上但不能再替我决定业务逻辑的结构。5.1 从“让AI写代码”切换到“让AI当输入法”写作姿势的改变很多人的AI辅助开发其实就是AI直接产出代码我来审核。我这次重构全程回避了这种模式换成了另一个姿势——让AI做输入法它负责把文字变成代码的候选但最终要打什么字、选什么词完全由我做主。落到操作层面是这样的接手一段旧逻辑时先不打开编辑器看代码而是让AI帮我把这段逻辑翻译成自然语言的业务描述然后我拿着业务描述自己画一遍数据流转图、状态迁移表和边界条件清单接着我把这份文档作为设计说明书反过来要求AI用它在另一个临时目录里生成若干参考版本最后我自己动手在本项目的真实结构里亲手把实现写出来。AI生成的参考版本不是没有价值它能提示我遗漏的边缘分支但它的设计决策我不会直接采用。有一次我手写订单状态流转逻辑AI给出了一个基于事件总线的异步方案它说这样可以避免状态冲突。我看了之后没采用因为在我们的实际部署规模下同步校验比异步最终一致更容易控制而且团队后面对事件溯源这套模式的维护成本远高于收益。手动选择不用某个先进方案和因为AI直接生成了高级方案而被迫维护它是两种完全不同的境遇。5.2 一次只重写一条业务链路用测试围栏做安全网重构犯过最大的错误就是试图一口气把整个模块推倒重来。这种重写方式风险极高因为你根本没有能力在一两周内同时消化一个复杂域的全部细节。我这次沿用了一套被反复验证的流程一次只挑一条业务链路走完五步定义输入输出契约、编写特征测试、手工重写实现、对比新旧行为、差异审查合并。拿订单自动关单这个链路举例。我先列出它的输入订单创建时间、超时时长、当前状态、支付回调结果输出关单动作、通知事件、状态变更记录。接着写特征测试把线上近一个月的各种组合都抽成数据样本。然后才开始手写实现。写的时候我会刻意不看旧代码因为看了容易被旧结构带着走我只看契约样本和业务说明。写完跑测试对比找到行为差异逐条确认差异是旧bug被修复了还是新bug被引入了。这个流程看起来慢但每一步都有明确的验证闸门我不会允许自己在没有特征测试覆盖的情况下删掉任何旧代码。事实也证明这条慢路径其实比让AI快速重写然后线上返工快得多。5.3 手写代码的三个具体习惯先写注释、拒绝嵌套、克制抽象经过这次重写我重新总结出了三个手写代码时要刻意保持的习惯它们看似基础但我发现正是AI编码时代最容易丢掉的东西。第一个习惯先写注释再写代码。我手写每一个稍微复杂的方法之前会先用注释把这个方法要解决什么问题、输入是什么、输出是什么、有哪些边界情况完整写出来。当注释里出现情况A要做X情况B要做Y的时候说明这个方法的职责已经过于混杂了我会停下来拆方法。AI生成代码时常因为缺乏这个前置约束直接给你造出一个三百行的巨无霸方法。第二个习惯拒绝超过两层嵌套。代码里最深的问题往往出现在多层条件嵌套里读代码的人每多退一格就要多记一个状态。我给自己定了硬规矩一个方法里嵌套超过两层要么提前return要么拆子方法要么用查表替代分支。AI不会自觉遵守这个约束它只会按照上下文的统计规律生成所以这个审查责任必须由人来扛。第三个习惯克制抽象。我这次重写过程中每添加一个接口、一个抽象类、一个工厂方法都会逼自己回答一个问题这个抽象能为当前项目的维护者节省多少理解成本如果答案说不清我就用最朴素的类结构直接写。抽象不是越多越好抽象是为了减少重复而不是为了消除所有if。过度抽象比重复代码更伤人因为重复代码至少一眼能看到逻辑抽象层散落的职责分派则让人必须全局脑补拼接。有一段我亲手重写的订单状态流转代码足以说明这三种习惯的作用// 把订单状态从A迁移到B function transitionOrder(order, targetStatus, context) { const rule statusRules[order.status]; if (!rule) { throw new Error(未定义的订单状态: ${order.status}); } if (!rule.transitions.includes(targetStatus)) { throw new Error(不允许从 ${order.status} 迁移到 ${targetStatus}); } const validator rule.validators?.[targetStatus]; if (validator !validator(order, context)) { throw new Error(状态迁移校验未通过: ${targetStatus}); } order.status targetStatus; order.statusHistory.push({ from: rule.name, to: targetStatus, operator: context.operator, at: new Date().toISOString(), }); return order; }这段代码的整个状态迁移规则就是一个配置表加一个校验函数加一段状态历史记录。没有事件总线没有策略工厂没有装饰器链。状态机的设计意图从函数签名里就能读出来维护者不需要跳转好几个文件才能理解状态流转的前提和后果。5.4 重写过程中如何处理AI曾经写对了的部分并不是所有AI生成的代码都写错了。有些逻辑当时确实是合理的只是后来的需求变了显得它不够贴切也有些逻辑虽然结构难看但算法选型是对的。我在重写的时候不会因为来源是AI就一律重来而是会从行为上确认旧实现里哪些决策仍然成立。比如在账户金额计算里旧的AI实现里有一个先扣本金、后扣利息的处理顺序业务方确认这是有意设计的因为要保证每次对账单里本金扣减优先、避免利息倒挂。那这个顺序我重写时会原样保留并单独写一条注释说明业务上有意如此防止后来的AI再自作主张优化掉。这个经验非常重要重写的目标不是消灭AI的痕迹而是消灭无人能解释的决策。凡是能解释清楚并且当下仍然正确的决策无论当初是谁写的都值得保留。凡是解释不清、只能靠周边调试去猜的逻辑才是必须重写的对象。6. 手写不等于弃用AI现在的混合工作模式与边界设定说回到工具本身。经历了这次大重构之后我并没有把AI编码助手卸载。恰恰相反我还在重度使用——期待它替代那些非核心的体力劳动。真正的调整在于我重新定义了让AI参与的边界并且这个边界比两年前严格得多。6.1 我把AI的使用场景重新限定在了哪里现在我用AI做的事情每一项都经过挑选生成DTO和接口样板、写单元测试的数据构造函数、把一段长日志翻译成可读的时序说明、根据我的设计文件生成注释骨架、帮我提取重复代码片段。这些场景有一个共同点无论AI怎么发挥都不会直接影响业务逻辑的内在一致性。而下面这些场景我会坚决关掉AI的决策权核心业务的状态流转、涉及金额的计算规则、数据一致性和并发控制策略、数据库索引与查询方案、模块拆分的架构决策。一旦进入这些领域我会自己动手哪怕动得慢一些。原因很简单金额计算错一个取整规则就是线上事故状态流转错一个前置条件就是数据混乱。这些模块的价值不在于代码量而在于决策质量。AI可以作为一个知识库告诉我业界常见做法有哪些但最终的取舍和责任必须落在能对系统负责的人手里。AI使用场景我的处理方式原因DTO、样板接口、数据构造函数放心让AI生成不影响业务决策可被编译器验证正则表达式、日志解析辅助让AI生成人工验证语法正确性容易检查业务语义独立代码注释骨架、文档初稿让AI生成人工纠正节省时间最终内容仍由人确认单元测试框架与数据样本让AI生成人工核对断言测试意图必须由人来定义核心业务的状态流转禁止AI直接生成状态一致性依赖全局理解金额计算、优惠规则逻辑禁止AI直接生成取整/顺序/精度均关乎真金白银并发与数据一致性方案禁止AI直接生成需结合部署规模和业务语义选型架构分层与模块拆分禁止AI直接生成需对后续维护成本负责6.2 把代码评审从“看语法”变成“追问设计”重新手写了一个多月之后我发现自己对代码评审这个动作的理解也变了。以前评审AI生成的代码我默认的视角是检查它有没有写错现在我对任何代码都换成了一种考察设计意图的视角。评审时我会追着问几个问题这个方法存在的原因是什么它把约束放在哪一层如果需求变成X改动范围会多大如果这个函数被并发调用一万次结果是什么面对AI生成的代码这些问题经常得不到清晰回答面对手写并注明了设计意图的代码回答这些问题几乎不费力气。不过度设计那段状态迁移逻辑本质上是把想清楚再编码这个过程找回来了。代码评审要审查的不只是代码本身还有写这段代码的人有没有经历过完整的思考。6.3 团队协作层面的约定所有人的代码所有人都要能读懂重构中后期团队里其他同事也开始介入新代码的维护。我顺势和合作方定了几条简单的约定把这次重构的经验固化下来防止氛围编码的毛病复发。第一条约定是模块的代码提交必须有设计意图说明。哪怕是PR描述里写三行也行但必须说清楚这里为什么用这套方案。看着改的AI生成的这种描述在合并请求里是不被接受的。第二条约定是核心业务逻辑上新代码必须配行为测试至少覆盖一条正常路径和一条边界路径。评审时没有测试的行为变更会被打回。第三条约定是任何人读代码时如果遇到看不懂的地方不许跳过必须追查清楚后更新注释或重构让代码自解释。代码库里不允许长期存在解释不清的区域。这些约定没有任何高深之处甚至可以说很朴素。但它们非常有效地阻止了代码库重新滑向一种无人理解的复杂状态。现在复盘这两年的经历我最大的体会其实就一句话AI写代码最大的风险不是写错而是让你误以为自己已经理解了。氛围编码最迷人的地方在于它让你感觉每天都有产出又不用承受独自面对空白编辑器的那种思考压力。但代码的本质不是文字而是决策决策的质量永远取决于做决策的人对业务和系统理解的深度。所以我最后的选择是让AI继续做那个帮我打字的人而重新做回了那个用笔在草稿纸上画状态流、亲手敲下每一行核心逻辑的人。如果你也发现自己正在被AI生成的代码带着走我建议你从下周开始做一次小范围试验挑一个你最熟悉的模块关掉自动补全手动重写其中的核心方法。你可能会发现手写代码的感觉虽然慢但那种代码在脑子里有了清晰形状的状态是AI时代快要被遗忘的奢侈。