软件工程理论这些年经历的最深刻变化，在我看来不是又多了几个新框架，也不是某种开发语言翻身做了主角，而是“经验主义”正在被“AI赋能”一点点改写底层逻辑。过去我们默认一个团队的技术上限，取决于最资深那个人脑子里的存货；现在，这个默认前提开始松动。我第一次强烈感受到这一点，是在一个重构项目的评审会上，两套方案吵到最后，居然不是靠“谁资历深谁说了算”，而是靠AI把两边的前提条件、影响面、隐藏成本全部拉出来，才真正收敛出结论。想聊的不是“AI帮你写代码”这种表层体验。我想复盘的是：软件工程理论里那些原本只可意会、不可言传的判断环节——需求分析、架构选型、代码评审、故障排查——如何被AI重新激活，以及当“经验”变成可以对话、可以验证、可以传承的东西之后，我们这些在一线干活的人，工作方式到底发生了哪些不可逆的改变。1. 经验主义曾是软件工程最后的“祖传秘方”1.1 第一次觉醒：把个人英雄变成流程规范软件工程成为一门学科，本身就是一次“觉醒”。在更早的编码年代，项目能不能成，基本取决于程序员个人的天赋和体力。后来有了结构化编程、设计模式、重构理论、敏捷开发、DevOps，我们做的事其实只有一件：把不可复制的个人能力，尽量翻译成组织可以执行的流程和规范。设计模式解决的是“通用场景下的最佳实践”，敏捷解决的是“需求变化下的响应机制”，DevOps解决的是“交付链条上的协作损耗”。这套东西走到今天，已经非常成熟。但也留下一个尴尬的事实：教科书能教你的永远是“原则”，到了具体项目里，什么时候该遵守、什么时候该打破，仍然靠经验。比如大家都知道单一职责原则，但一个订单服务里的状态判断散落在七个类里，要不要立刻收敛？资深的会说不收敛迟早出事，新手会说现在加需求都快来不及了。两边说得都有道理，只是谁也没法立刻证明自己的判断更值钱。这就是经验主义最真实的状态：它有价值，但它是私有财产，存在个别资深成员的脑子里，无法被批量复制，也很难被快速验证。1.2 经验是真的，但它私有化、易失真、难复制我带过不少项目，最深的体会是：一个团队踩过的坑，如果没被结构化地记录，那它下一次大概率还会踩。老同事凭直觉说“这个表不要加索引”，背后是他三年前在某个大促场景里被锁竞争折磨过的记忆。但这份记忆没有变成文档，更没有变成一条可执行的规则，它就随着这个人调岗、离职，直接蒸发。经验主义还有另一个问题：容易失真。同一个技术决策，十年前是正确的，放到今天的流量规模和硬件条件下不一定正确；同一个架构方案，在A团队能跑通，搬到B团队可能因为人力结构不同而崩溃。老经验只有在相当稳定的上下文里才成立，而软件行业恰恰是上下文变化最剧烈的行业之一。当系统复杂度越来越高，团队人数越来越多，光靠“老师傅说了算”的模式就开始出现裂缝。你会发现，真正难的往往不是写代码，而是没有一个可靠的机制把大家的经验拉齐、验证、比较、取舍。我一直在等一个能让“隐性知识显性化”的工具出现，AI实际上补上了这一环。2. AI赋能真正撬动的，是工程中那些“隐性知识”2.1 把“直觉”拆成可追问的上下文很多人在讨论AI辅助开发时，注意力都放在“让它生成一段代码”。说实话，生成代码只是最表层的能力，而且不是最不可替代的能力。AI真正厉害的地方在于：它可以快速把一个大型代码库、一份长文档、一堆历史故障记录读进去，然后以极低的时间成本给出“如果我理解得没错，这个问题的全貌是……”的假设。这本质上是在做“显性化”。过去你问一个资深架构师为什么某个设计不合理，他说得出来结论，但未必能在短时间内把三条支撑论据完整展开。AI不一样，你可以在它的回答基础上不断追问：这个影响面的判断依据是什么？哪些是静态分析出来的，哪些是根据常见模式推测的？如果换一种业务假设，结论会如何变化？这种可追问性，让技术讨论第一次有了对所有人透明的、可验证的“中间产物”，而不是只能靠资历来背书。我用一个表格来概括AI在不同阶段到底改变了什么，可能更直观：工程阶段传统经验主义做法AI辅助后的典型做法本质变化需求分析资深开发凭经验预估影响面AI先按代码结构生成影响面清单，人工再做业务确认隐性影响显性化架构评审评审者按个人偏好表态AI扮演不同角色对方案提出质询从“站队”变成“补盲区”代码评审评审者凭感觉找坏味道AI预扫描重复代码、长函数、循环依赖后给出标注评审聚焦在高价值判断故障排查老师傅靠回忆“以前这里出过事”AI对历史日志做聚类并给出相似度排序经验变成可检索资产表格里每一行都不是空想，下面详细说。2.2 需求分析：一句话需求如何变成一张影响面清单举一个最常见的例子。产品经理过来说：“我们想给订单增加一个分批发货的功能。”放在过去，靠谱的开发会沉默片刻，脑子里快速过一遍订单状态、库存流转、支付回调、物流单生成、售后校验……如果有漏掉的，只能等测试阶段炸出来。如果问一个刚工作两年的开发，他大概率会先回答“那就在订单表加个字段呗”。现在我的习惯是，先把需求原文连同订单模块的核心表结构、状态枚举、已有接口列表一起丢给AI，要求它“列出实现这个需求可能需要改动的所有业务对象和边界场景，不要着急给代码”。AI会给出一个清单，里面可能包含：订单主表的状态机变化、子订单拆分后原订单金额与已付金额的对账逻辑、拆单后部分退款如何校验、物流运单与子订单绑定关系、促销优惠分摊金额的重算……等等。这个清单不会百分百准确，但它的覆盖率往往超过团队里除最资深成员之外的大部分人。更重要的是，AI不懂你们的业务细节，它给的只是“极可能相关的项”，最终判断仍然要人来拍板。但当我拿着这张清单去问产品经理“拆单之后优惠金额怎么分摊”时，需求的模糊性就提前暴露了，而不是等开发到一半才暴露。2.3 架构评审：让AI同时扮演三名“最难缠的审查者”架构评审会是最能体现经验主义弊端的场合。一个方案扔出来，老同事关注性能，运维背景的同事关注部署复杂度，新同事关注自己能不能维护。每个人的发言都基于自己的经验半径，而经验半径之外的部分，往往没人关心。我后来养成一个习惯：正式评审之前，先让AI扮演三个角色，对同一份方案分别提出反对意见。第一个角色是“对性能极其敏感的系统架构师”，第二个是“上线后被凌晨三点报警电话吓怕的运维负责人”，第三个是“刚接手这个模块、之前毫无上下文的新人”。AI提的问题有时看起来有点外行，但恰恰是这些“外行问题”能点醒内部人。比如它可能问：“模块拆分之后，两个服务之间的事务一致性怎么保证？是最终一致还是强一致？如果消费者服务一直不返回，有什么兜底？”这些东西资深架构师当然懂，但方案文档里可能忘了写清楚。而在评审会上，大家默认“这还用说”，结果就是没人说。AI扮演的“新手”角色可以合法地问出那些“不好意思问”的问题。2.4 测试与排障：让踩坑经验变成可复用规则测试和故障排查领域，AI赋能的感受更直接。过去我们积累测试用例，靠的是测试工程师对业务的理解；积累排障经验，靠的是每一次事故后的复盘文档。但复盘文档写完之后，基本就躺进Wiki里吃灰了，下次遇到相似问题时，很少有人会去翻历史文档，大家还是凭记忆定位。现在我会把过去两年的生产故障记录做脱敏处理后喂给AI，让它提取“高复发概率的故障模式”，再转成一批针对性的测试用例建议。比如它可能发现下单链路里“库存预占成功但订单创建失败”这类异常特别多，那就应该重点补一个故障注入测试，验证超时补偿机制。这个过程本质上是把老师傅脑子里的“这个模块老出事”变成了一条可执行的回归测试规则，不再依赖某个人记性好。有一次线上报警说支付回调延迟，团队里新来的同事手忙脚乱地往数据库里翻数据，我直接让AI按历史故障模式给出排查顺序建议，它把“先确认消息队列堆积、再检查支付网关超时配置、最后核对幂等表”排了出来。这个顺序未必最优，但至少让一个没有经验的人可以立刻进入工作状态，而不是在搜索引擎里浪费时间。3. 完整复盘：一个遗留订单模块的AI辅助重构3.1 背景：两万行代码、两位专家、两个相反的方案下面用我最近实际做的一个重构来完整走一遍流程，为了表述方便，把项目叫作某订单系统。这个模块有两万多行Java代码，六个服务交错调用，业务涉及订单状态、库存扣减、支付回调、优惠分摊、物流回写。由于历史原因，订单状态机逻辑散落在一堆Service和Controller里，改一个状态要小心翼翼，因为不知道在哪里触发了回调。评审会上出现了两个方案。同事A主张必须拆分微服务，理由是订单、支付、库存耦合太深，再不拆后续没人敢改；同事B主张先在单体内部做模块化，理由是团队只有五个人，拆分之后的运维成本扛不住。两个人说的都是自己的真实经验推导出的结论，但谁的论据更扎实，当时谁也说服不了谁，会议不欢而散。放在以前，这种局面的结局大概率是：谁的职位高听谁的，或者谁脾气大听谁的。但这次我提了个建议——先别争方案，让AI把当前的依赖关系和重构影响面摸一遍，拿到数据再吵。3.2 我的第一轮AI诊断：把问法换成“先别给结论”很多人用AI做分析失败，是因为问法太着急：“帮我重构这个模块”。这种问法只会得到一份看起来正确但其实悬浮的建议。我的第一轮提示词是这样写的：现在你是一名有多年经验的软件架构师。我会分批提供某订单系统的代码结构和调用关系信息，你的任务是先做诊断，不要急着给重构方案。 请按以下顺序输出： 1. 当前存在哪些明显的循环依赖或跨层调用； 2. 哪些业务状态被分散在多个类中维护； 3. 按你的经验判断，最容易被后续需求频繁改动的高风险区域是什么； 4. 以上每一点，请你标注出判断依据，如果依据不足，直接告诉我“这里需要人工确认”。 这是第一部分信息：核心实体类、订单状态枚举、相关Service清单和调用入口。AI返回的分析里，最刺眼的结论是：订单状态机逻辑散落在七个类中，其中“已支付”和“已发货”两个状态在支付回调、客服改单、物流回写三条链路里都有重复判断；另外，订单模块对库存服务的调用存在一个A->B->A的循环依赖，这才是导致每次改动都“牵一发动全身”的真凶。这个结论并不意外，但之前它分散在不同人的经验里：A同事知道状态判断重复，但他没上过全链路图；B同事隐约知道有循环依赖，但没量化过影响范围。AI把这些信息拼成了一幅完整画像，两边第一次达成了“问题定义”的共识：核心矛盾不是拆不拆服务，而是状态机边界不清楚。3.3 第二轮：让AI对两个方案分别进行压力测试问题定义清楚后，我让AI做了第二轮分析：分别站在“三个月内拆分微服务”和“三个月内做模块化重构”两个前提下，列出各自需要完成的步骤清单、对人力的要求、最大的三个风险点，以及各自的最小可回退路径。AI给出的对比很现实：拆分微服务方案里，最大的风险不是拆分本身，而是数据一致性改造，订单与库存跨服务后的事务边界会逼迫团队引入更多中间件，这超出五个人团队在三个月内的承受范围；模块化重构方案里，最大的风险则是一不小心做成“换汤不换药”，如果没有把状态判断收敛到领域层，重构完只是换了个摆放位置。这个结果让会议的讨论方向变了。大家不再争“谁的方向对”，而是开始讨论“如何在模块化重构时确保状态逻辑真的收敛”。最后团队选了一条折中路径：先把散落在七个类中的状态机收敛到一个订单状态生命周期对象里，再在外部依赖边界加一层防腐层，隔离库存和支付接口的影响；等模块化稳定之后再评估按订单域拆出独立服务的时机。3.4 落地过程中AI的另一个用处：为重构加安全网重构老代码最怕的不是改错，而是改错之后没人发现。我们决定用AI辅助生成“重构前后行为对比测试”：让AI读取重构前核心Service的方法实现，列出所有分支条件和输入输出组合，然后转成测试用例骨架；再在重构后运行同一批用例，比较行为是否一致。举例来说，订单确认这个方法在重构前有一大段散落的逻辑，重构后收敛为状态机转移。AI生成的测试用例会覆盖“订单为未支付状态时调用确认方法”“订单已关闭时调用确认方法”“支付回调重复到达时调用确认方法”等场景。这些用例的覆盖面比我手动写出来的更广，因为AI会忠实读取代码分支，不依赖我脑子里的印象。最后这批用例在执行过程中抓到了两处行为差异，都是边界条件处理不一致导致的，如果不是AI辅助生成用例，靠人工评审很可能漏过去。重构上线之后，我的体会是：AI没有取代任何人的判断，但它让“经验”从双方各执一词变成了可以共同翻看的证据链。同事A的经验仍然体现在他知道“不拆迟早出事”，同事B的经验体现在“团队承载力有限”，而AI提供的分析让这两个经验都变成了可以被验证、被安放的前提，而不是吵架的立场。4. 觉醒之后，经验主义没有消失，它变成了AI的燃料4.1 AI说得再肯定，拍板的还是你要泼一盆冷水。AI在软件工程里的辅助能力越强，越容易让人产生一个危险的错觉：它说得那么详细，那就听它的吧。这是对“AI赋能”最大的误解。AI给出的分析是基于历史数据和常见模式做的概率预测，它不懂你们公司的合规约束、不懂客户合同的交付底线、不懂团队里谁可以长期维护某个模块、也不懂某个接口背后有多少历史包袱。在实际项目里，我给自己定了一条规则：凡是涉及对外承诺、资金安全、数据合规、不可逆迁移这类决策，AI的分析可以作为参考清单，但最终判断必须由人来复核每一项风险。AI说“这个方案可行”不等于它承担后果，买单的还是团队。它的价值是减少信息盲区，而不是替代责任主体。我们团队有一次在让AI做技术选型对比时，它给出的结论倾向某个更新潮的框架，理由是该框架社区活跃度更高、范例更丰富。但如果我们真选了它，后续三年的维护成本谁来扛？这种问题AI不会替你回答。所以我的习惯是：AI的结论里越有诱惑力，我越要追问它“这个结论的前提条件是什么，如果前提不成立，结论会怎样坍塌”。4.2 用“上下文契约”把团队经验喂给AI要把AI从一个通用的“理论高手”变成懂你们团队语境的“编外专家”，关键动作是建立一套可复用的上下文资产。我称之为“上下文契约”，它是一堆结构化的背景资料，在让AI做分析前先喂给它。包括：核心业务实体的定义和状态枚举、近半年的架构决策记录、团队长期遵守的编码约定、历史故障报告库、当前系统架构图。这些资产平时就整理好，而不是临时找材料。比如我让AI评审一个新方案时，会先给它一段固定格式的项目背景，里面写明“本系统是某订单系统，订单状态包含待支付、已支付、已发货、已完成、已关闭；支付回调必须保证幂等；库存扣减允许超时重试；历史故障中有三次因为状态重复判断导致重复发货”。当这些上下文给到位，AI给出的分析和团队经验高度一致，不会再说出“你可以直接改订单表状态”这类外行话。这也是二次觉醒里我个人认为最值得投入的部分：经验主义并没有消亡，它只是换了一种存在形式。以前经验存在某些人的记忆里，随着人员流动而流失；现在经验被写进结构化的上下文，伴随每次AI分析而重复激活。这并不是说成员不再重要，反而说明一个团队最宝贵的经验资产，值得被认真“编码”下来。4.3 现在就能落地的三件事，不用等任何平台最后说点能立刻做的事情。很多人觉得AI赋能是大公司的事，要等公司统一采购工具、搭建平台才开始。其实不是，以下三件事，个人开发者和小团队马上就能做：第一，把最近十次线上故障整理成结构化复盘，包括现象、根因、排查过程、最终修复方案，分批喂给AI，让它总结出“这个系统最容易出的三类问题”。然后你会发现，很多经验不再只是老人嘴里的一句话，而是变成了团队新人也能检索的排障手册。第二，在架构评审之前，先让AI做一轮反方辩论。把方案文档丢给它，让它分别从性能、运维、安全、可维护性四个角度挑毛病。你不需要同意所有结论，但至少能提前想清楚回应话术，避免在评审会上被问得措手不及。这一步每次只需十几分钟。第三，给代码评审加一道AI预检流程。现在很多开发环境自带AI能力，哪怕没有，你也可以把改动涉及的代码或diff提取出来，先让AI标注潜在的坏味道、缺失的分支处理、明显的重复逻辑，再进入人工评审环节。人工评审因此可以把时间花在真正需要经验判断的地方，而不是找括号大小和命名风格。我自己的实践感受是，这三件事一开始会有“多此一举”的不适感，但坚持两三周后，它会变成肌肉记忆。AI不再是你偶尔想起来用的工具，而是你做技术判断时默认启动的第一道信息过滤网。回到标题说的“二次觉醒”。软件工程理论第一次觉醒，是把软件开发的个人特质变成组织流程；第二次觉醒在我看来，是让经验本身成为可以被追问、被验证、被传承的数据资产。AI没有给出所有答案，但它把过去占据最高权重的“资历”拉下神坛，逼着每个工程师去思考：我的判断依据到底是什么？能不能说清楚？这个转变，比它多写几段代码更有意义。
软件工程理论这些年经历的最深刻变化，在我看来不是又多了几个新框架，也不是某种开发语言翻身做了主角，而是“经验主义”正在被“AI赋能”一点点改写底层逻辑。过去我们默认一个团队的技术上限，取决于最资深那个人脑子里的存货；现在，这个默认前提开始松动。我第一次强烈感受到这一点，是在一个重构项目的评审会上，两套方案吵到最后，居然不是靠“谁资历深谁说了算”，而是靠AI把两边的前提条件、影响面、隐藏成本全部拉出来，才真正收敛出结论。想聊的不是“AI帮你写代码”这种表层体验。我想复盘的是：软件工程理论里那些原本只可意会、不可言传的判断环节——需求分析、架构选型、代码评审、故障排查——如何被AI重新激活，以及当“经验”变成可以对话、可以验证、可以传承的东西之后，我们这些在一线干活的人，工作方式到底发生了哪些不可逆的改变。1. 经验主义曾是软件工程最后的“祖传秘方”1.1 第一次觉醒：把个人英雄变成流程规范软件工程成为一门学科，本身就是一次“觉醒”。在更早的编码年代，项目能不能成，基本取决于程序员个人的天赋和体力。后来有了结构化编程、设计模式、重构理论、敏捷开发、DevOps，我们做的事其实只有一件：把不可复制的个人能力，尽量翻译成组织可以执行的流程和规范。设计模式解决的是“通用场景下的最佳实践”，敏捷解决的是“需求变化下的响应机制”，DevOps解决的是“交付链条上的协作损耗”。这套东西走到今天，已经非常成熟。但也留下一个尴尬的事实：教科书能教你的永远是“原则”，到了具体项目里，什么时候该遵守、什么时候该打破，仍然靠经验。比如大家都知道单一职责原则，但一个订单服务里的状态判断散落在七个类里，要不要立刻收敛？资深的会说不收敛迟早出事，新手会说现在加需求都快来不及了。两边说得都有道理，只是谁也没法立刻证明自己的判断更值钱。这就是经验主义最真实的状态：它有价值，但它是私有财产，存在个别资深成员的脑子里，无法被批量复制，也很难被快速验证。1.2 经验是真的，但它私有化、易失真、难复制我带过不少项目，最深的体会是：一个团队踩过的坑，如果没被结构化地记录，那它下一次大概率还会踩。老同事凭直觉说“这个表不要加索引”，背后是他三年前在某个大促场景里被锁竞争折磨过的记忆。但这份记忆没有变成文档，更没有变成一条可执行的规则，它就随着这个人调岗、离职，直接蒸发。经验主义还有另一个问题：容易失真。同一个技术决策，十年前是正确的，放到今天的流量规模和硬件条件下不一定正确；同一个架构方案，在A团队能跑通，搬到B团队可能因为人力结构不同而崩溃。老经验只有在相当稳定的上下文里才成立，而软件行业恰恰是上下文变化最剧烈的行业之一。当系统复杂度越来越高，团队人数越来越多，光靠“老师傅说了算”的模式就开始出现裂缝。你会发现，真正难的往往不是写代码，而是没有一个可靠的机制把大家的经验拉齐、验证、比较、取舍。我一直在等一个能让“隐性知识显性化”的工具出现，AI实际上补上了这一环。2. AI赋能真正撬动的，是工程中那些“隐性知识”2.1 把“直觉”拆成可追问的上下文很多人在讨论AI辅助开发时，注意力都放在“让它生成一段代码”。说实话，生成代码只是最表层的能力，而且不是最不可替代的能力。AI真正厉害的地方在于：它可以快速把一个大型代码库、一份长文档、一堆历史故障记录读进去，然后以极低的时间成本给出“如果我理解得没错，这个问题的全貌是……”的假设。这本质上是在做“显性化”。过去你问一个资深架构师为什么某个设计不合理，他说得出来结论，但未必能在短时间内把三条支撑论据完整展开。AI不一样，你可以在它的回答基础上不断追问：这个影响面的判断依据是什么？哪些是静态分析出来的，哪些是根据常见模式推测的？如果换一种业务假设，结论会如何变化？这种可追问性，让技术讨论第一次有了对所有人透明的、可验证的“中间产物”，而不是只能靠资历来背书。我用一个表格来概括AI在不同阶段到底改变了什么，可能更直观：工程阶段传统经验主义做法AI辅助后的典型做法本质变化需求分析资深开发凭经验预估影响面AI先按代码结构生成影响面清单，人工再做业务确认隐性影响显性化架构评审评审者按个人偏好表态AI扮演不同角色对方案提出质询从“站队”变成“补盲区”代码评审评审者凭感觉找坏味道AI预扫描重复代码、长函数、循环依赖后给出标注评审聚焦在高价值判断故障排查老师傅靠回忆“以前这里出过事”AI对历史日志做聚类并给出相似度排序经验变成可检索资产表格里每一行都不是空想，下面详细说。2.2 需求分析：一句话需求如何变成一张影响面清单举一个最常见的例子。产品经理过来说：“我们想给订单增加一个分批发货的功能。”放在过去，靠谱的开发会沉默片刻，脑子里快速过一遍订单状态、库存流转、支付回调、物流单生成、售后校验……如果有漏掉的，只能等测试阶段炸出来。如果问一个刚工作两年的开发，他大概率会先回答“那就在订单表加个字段呗”。现在我的习惯是，先把需求原文连同订单模块的核心表结构、状态枚举、已有接口列表一起丢给AI，要求它“列出实现这个需求可能需要改动的所有业务对象和边界场景，不要着急给代码”。AI会给出一个清单，里面可能包含：订单主表的状态机变化、子订单拆分后原订单金额与已付金额的对账逻辑、拆单后部分退款如何校验、物流运单与子订单绑定关系、促销优惠分摊金额的重算……等等。这个清单不会百分百准确，但它的覆盖率往往超过团队里除最资深成员之外的大部分人。更重要的是，AI不懂你们的业务细节，它给的只是“极可能相关的项”，最终判断仍然要人来拍板。但当我拿着这张清单去问产品经理“拆单之后优惠金额怎么分摊”时，需求的模糊性就提前暴露了，而不是等开发到一半才暴露。2.3 架构评审：让AI同时扮演三名“最难缠的审查者”架构评审会是最能体现经验主义弊端的场合。一个方案扔出来，老同事关注性能，运维背景的同事关注部署复杂度，新同事关注自己能不能维护。每个人的发言都基于自己的经验半径，而经验半径之外的部分，往往没人关心。我后来养成一个习惯：正式评审之前，先让AI扮演三个角色，对同一份方案分别提出反对意见。第一个角色是“对性能极其敏感的系统架构师”，第二个是“上线后被凌晨三点报警电话吓怕的运维负责人”，第三个是“刚接手这个模块、之前毫无上下文的新人”。AI提的问题有时看起来有点外行，但恰恰是这些“外行问题”能点醒内部人。比如它可能问：“模块拆分之后，两个服务之间的事务一致性怎么保证？是最终一致还是强一致？如果消费者服务一直不返回，有什么兜底？”这些东西资深架构师当然懂，但方案文档里可能忘了写清楚。而在评审会上，大家默认“这还用说”，结果就是没人说。AI扮演的“新手”角色可以合法地问出那些“不好意思问”的问题。2.4 测试与排障：让踩坑经验变成可复用规则测试和故障排查领域，AI赋能的感受更直接。过去我们积累测试用例，靠的是测试工程师对业务的理解；积累排障经验，靠的是每一次事故后的复盘文档。但复盘文档写完之后，基本就躺进Wiki里吃灰了，下次遇到相似问题时，很少有人会去翻历史文档，大家还是凭记忆定位。现在我会把过去两年的生产故障记录做脱敏处理后喂给AI，让它提取“高复发概率的故障模式”，再转成一批针对性的测试用例建议。比如它可能发现下单链路里“库存预占成功但订单创建失败”这类异常特别多，那就应该重点补一个故障注入测试，验证超时补偿机制。这个过程本质上是把老师傅脑子里的“这个模块老出事”变成了一条可执行的回归测试规则，不再依赖某个人记性好。有一次线上报警说支付回调延迟，团队里新来的同事手忙脚乱地往数据库里翻数据，我直接让AI按历史故障模式给出排查顺序建议，它把“先确认消息队列堆积、再检查支付网关超时配置、最后核对幂等表”排了出来。这个顺序未必最优，但至少让一个没有经验的人可以立刻进入工作状态，而不是在搜索引擎里浪费时间。3. 完整复盘：一个遗留订单模块的AI辅助重构3.1 背景：两万行代码、两位专家、两个相反的方案下面用我最近实际做的一个重构来完整走一遍流程，为了表述方便，把项目叫作某订单系统。这个模块有两万多行Java代码，六个服务交错调用，业务涉及订单状态、库存扣减、支付回调、优惠分摊、物流回写。由于历史原因，订单状态机逻辑散落在一堆Service和Controller里，改一个状态要小心翼翼，因为不知道在哪里触发了回调。评审会上出现了两个方案。同事A主张必须拆分微服务，理由是订单、支付、库存耦合太深，再不拆后续没人敢改；同事B主张先在单体内部做模块化，理由是团队只有五个人，拆分之后的运维成本扛不住。两个人说的都是自己的真实经验推导出的结论，但谁的论据更扎实，当时谁也说服不了谁，会议不欢而散。放在以前，这种局面的结局大概率是：谁的职位高听谁的，或者谁脾气大听谁的。但这次我提了个建议——先别争方案，让AI把当前的依赖关系和重构影响面摸一遍，拿到数据再吵。3.2 我的第一轮AI诊断：把问法换成“先别给结论”很多人用AI做分析失败，是因为问法太着急：“帮我重构这个模块”。这种问法只会得到一份看起来正确但其实悬浮的建议。我的第一轮提示词是这样写的：现在你是一名有多年经验的软件架构师。我会分批提供某订单系统的代码结构和调用关系信息，你的任务是先做诊断，不要急着给重构方案。 请按以下顺序输出： 1. 当前存在哪些明显的循环依赖或跨层调用； 2. 哪些业务状态被分散在多个类中维护； 3. 按你的经验判断，最容易被后续需求频繁改动的高风险区域是什么； 4. 以上每一点，请你标注出判断依据，如果依据不足，直接告诉我“这里需要人工确认”。 这是第一部分信息：核心实体类、订单状态枚举、相关Service清单和调用入口。AI返回的分析里，最刺眼的结论是：订单状态机逻辑散落在七个类中，其中“已支付”和“已发货”两个状态在支付回调、客服改单、物流回写三条链路里都有重复判断；另外，订单模块对库存服务的调用存在一个A->B->A的循环依赖，这才是导致每次改动都“牵一发动全身”的真凶。这个结论并不意外，但之前它分散在不同人的经验里：A同事知道状态判断重复，但他没上过全链路图；B同事隐约知道有循环依赖，但没量化过影响范围。AI把这些信息拼成了一幅完整画像，两边第一次达成了“问题定义”的共识：核心矛盾不是拆不拆服务，而是状态机边界不清楚。3.3 第二轮：让AI对两个方案分别进行压力测试问题定义清楚后，我让AI做了第二轮分析：分别站在“三个月内拆分微服务”和“三个月内做模块化重构”两个前提下，列出各自需要完成的步骤清单、对人力的要求、最大的三个风险点，以及各自的最小可回退路径。AI给出的对比很现实：拆分微服务方案里，最大的风险不是拆分本身，而是数据一致性改造，订单与库存跨服务后的事务边界会逼迫团队引入更多中间件，这超出五个人团队在三个月内的承受范围；模块化重构方案里，最大的风险则是一不小心做成“换汤不换药”，如果没有把状态判断收敛到领域层，重构完只是换了个摆放位置。这个结果让会议的讨论方向变了。大家不再争“谁的方向对”，而是开始讨论“如何在模块化重构时确保状态逻辑真的收敛”。最后团队选了一条折中路径：先把散落在七个类中的状态机收敛到一个订单状态生命周期对象里，再在外部依赖边界加一层防腐层，隔离库存和支付接口的影响；等模块化稳定之后再评估按订单域拆出独立服务的时机。3.4 落地过程中AI的另一个用处：为重构加安全网重构老代码最怕的不是改错，而是改错之后没人发现。我们决定用AI辅助生成“重构前后行为对比测试”：让AI读取重构前核心Service的方法实现，列出所有分支条件和输入输出组合，然后转成测试用例骨架；再在重构后运行同一批用例，比较行为是否一致。举例来说，订单确认这个方法在重构前有一大段散落的逻辑，重构后收敛为状态机转移。AI生成的测试用例会覆盖“订单为未支付状态时调用确认方法”“订单已关闭时调用确认方法”“支付回调重复到达时调用确认方法”等场景。这些用例的覆盖面比我手动写出来的更广，因为AI会忠实读取代码分支，不依赖我脑子里的印象。最后这批用例在执行过程中抓到了两处行为差异，都是边界条件处理不一致导致的，如果不是AI辅助生成用例，靠人工评审很可能漏过去。重构上线之后，我的体会是：AI没有取代任何人的判断，但它让“经验”从双方各执一词变成了可以共同翻看的证据链。同事A的经验仍然体现在他知道“不拆迟早出事”，同事B的经验体现在“团队承载力有限”，而AI提供的分析让这两个经验都变成了可以被验证、被安放的前提，而不是吵架的立场。4. 觉醒之后，经验主义没有消失，它变成了AI的燃料4.1 AI说得再肯定，拍板的还是你要泼一盆冷水。AI在软件工程里的辅助能力越强，越容易让人产生一个危险的错觉：它说得那么详细，那就听它的吧。这是对“AI赋能”最大的误解。AI给出的分析是基于历史数据和常见模式做的概率预测，它不懂你们公司的合规约束、不懂客户合同的交付底线、不懂团队里谁可以长期维护某个模块、也不懂某个接口背后有多少历史包袱。在实际项目里，我给自己定了一条规则：凡是涉及对外承诺、资金安全、数据合规、不可逆迁移这类决策，AI的分析可以作为参考清单，但最终判断必须由人来复核每一项风险。AI说“这个方案可行”不等于它承担后果，买单的还是团队。它的价值是减少信息盲区，而不是替代责任主体。我们团队有一次在让AI做技术选型对比时，它给出的结论倾向某个更新潮的框架，理由是该框架社区活跃度更高、范例更丰富。但如果我们真选了它，后续三年的维护成本谁来扛？这种问题AI不会替你回答。所以我的习惯是：AI的结论里越有诱惑力，我越要追问它“这个结论的前提条件是什么，如果前提不成立，结论会怎样坍塌”。4.2 用“上下文契约”把团队经验喂给AI要把AI从一个通用的“理论高手”变成懂你们团队语境的“编外专家”，关键动作是建立一套可复用的上下文资产。我称之为“上下文契约”，它是一堆结构化的背景资料，在让AI做分析前先喂给它。包括：核心业务实体的定义和状态枚举、近半年的架构决策记录、团队长期遵守的编码约定、历史故障报告库、当前系统架构图。这些资产平时就整理好，而不是临时找材料。比如我让AI评审一个新方案时，会先给它一段固定格式的项目背景，里面写明“本系统是某订单系统，订单状态包含待支付、已支付、已发货、已完成、已关闭；支付回调必须保证幂等；库存扣减允许超时重试；历史故障中有三次因为状态重复判断导致重复发货”。当这些上下文给到位，AI给出的分析和团队经验高度一致，不会再说出“你可以直接改订单表状态”这类外行话。这也是二次觉醒里我个人认为最值得投入的部分：经验主义并没有消亡，它只是换了一种存在形式。以前经验存在某些人的记忆里，随着人员流动而流失；现在经验被写进结构化的上下文，伴随每次AI分析而重复激活。这并不是说成员不再重要，反而说明一个团队最宝贵的经验资产，值得被认真“编码”下来。4.3 现在就能落地的三件事，不用等任何平台最后说点能立刻做的事情。很多人觉得AI赋能是大公司的事，要等公司统一采购工具、搭建平台才开始。其实不是，以下三件事，个人开发者和小团队马上就能做：第一，把最近十次线上故障整理成结构化复盘，包括现象、根因、排查过程、最终修复方案，分批喂给AI，让它总结出“这个系统最容易出的三类问题”。然后你会发现，很多经验不再只是老人嘴里的一句话，而是变成了团队新人也能检索的排障手册。第二，在架构评审之前，先让AI做一轮反方辩论。把方案文档丢给它，让它分别从性能、运维、安全、可维护性四个角度挑毛病。你不需要同意所有结论，但至少能提前想清楚回应话术，避免在评审会上被问得措手不及。这一步每次只需十几分钟。第三，给代码评审加一道AI预检流程。现在很多开发环境自带AI能力，哪怕没有，你也可以把改动涉及的代码或diff提取出来，先让AI标注潜在的坏味道、缺失的分支处理、明显的重复逻辑，再进入人工评审环节。人工评审因此可以把时间花在真正需要经验判断的地方，而不是找括号大小和命名风格。我自己的实践感受是，这三件事一开始会有“多此一举”的不适感，但坚持两三周后，它会变成肌肉记忆。AI不再是你偶尔想起来用的工具，而是你做技术判断时默认启动的第一道信息过滤网。回到标题说的“二次觉醒”。软件工程理论第一次觉醒，是把软件开发的个人特质变成组织流程；第二次觉醒在我看来，是让经验本身成为可以被追问、被验证、被传承的数据资产。AI没有给出所有答案，但它把过去占据最高权重的“资历”拉下神坛，逼着每个工程师去思考：我的判断依据到底是什么？能不能说清楚？这个转变，比它多写几段代码更有意义。