最近和几个朋友聊到一个特别真实的感受AI 写代码的效率确实上来了但项目里的系统却越来越像黑盒。过去改一行配置、跑一遍测试大概能猜出整个模块的前后关联现在一段段代码丢给 AI 改完功能跑得通可真要我指出来它改了什么、动了哪些依赖、有没有碰到别的模块我反而讲不清楚了。这种状态持续了几个月后我开始认真复盘问题不在 AI 写代码快不快而在于我把太多“理解系统”的工作外包了出去。今天这篇东西就是把这几个月踩过的坑、试过的方法、以及最后怎么把“系统认知”找回来的过程梳理一遍。顺带把 AI 编程提示词、AI agent、多 AI 协作这些身边天天在聊的东西串起来讲清楚希望能给同样困惑的人一些参考。1. 现象代码交付变快了系统却变“黑”了1.1 快是快了但我开始看不懂昨天的代码最常见的场景是这样的早上接到需求对着 AI 工具描述了一通业务逻辑几十秒后一段能跑的代码就出来了。复制、粘贴、改几个参数单元测试一过功能就完事了。一开始你会觉得很爽一天能顶过去三天。可两周后回头看自己拼出来的模块连“这段代码为什么会这样写”都得问 AI 才能回忆起来。这种状态有个名字叫“生成式盲区”。你拿到了结果但没有拿到产生这个结果的推理过程。代码在运行层面是对的但它没有在你的大脑里形成对应的因果模型。一旦系统出了线上问题你在 IDE 里面对这一堆 AI 生成的函数根本没有“哪里可能藏雷”的方向感。更麻烦的是AI agent 和代码补全工具会主动替你决策变量怎么命名、函数怎么拆分、异常怎么处理。这些决策看起来无害但每一个都在悄悄塑造系统结构。等你发现系统里到处都是风格不一的代码块、同一件事有三种实现方式时系统已经变成了一个“局部清晰、全局混沌”的状态。1.2 为什么速度越快理解越容易缺位过去我们写代码是“慢工出细活”。一行一行手打的过程中大脑会不自觉建立变量之间的关系、函数之间的调用链、模块之间的依赖。这个过程虽然慢但它本质上是一种认知训练代码写完了系统的地图也画完了。AI 写代码最大的变化是它把“敲键过程”压缩掉了。你从执行者变成了审查者而审查者通常只看结果不看路径。结果导向没问题但代价是你对系统的心智模型越来越模糊。一个真实的例子之前用 AI 辅助重构一个老模块AI 生成的新实现比旧代码短了三分之一逻辑看起来也更整洁。我急着确认行为一致就跑了几个关键测试用例全过于是高高兴兴提交了。结果一周后同事告诉我某个边缘场景的行为完全变了不是坏就是变成了“另一个合理但没人想改”的行为。这类问题就是典型的“我看不懂系统”的症状你只知道功能对不对不知道系统整体是不是还是原来那个系统。AI 压缩了编码时间但它没有代替你完成对系统的理解。理解这件事仍然只能由人来完成。1.3 “能跑”和“看得懂”是两件事我后来给自己定了一个标准能跑的代码不等于我拥有的代码。所谓“拥有”是指当别人指着系统里任何一个函数问我“这里为什么这样写”时我能讲出设计意图、调用来源、失败模式。达不到这个标准的代码本质上只是一段寄生在仓库里的文本。这就像你请了个管家帮你管家他把所有账单都付了、客厅也收拾了但若哪天他请假了你不知道水电费在哪交、备用钥匙放哪、哪个开关控制哪盏灯整个家就瘫痪了。AI 会写代码不代表你懂系统懂系统的人也不会因为 AI 的出现就突然不需要懂系统。想通这一点之后我开始把“建立系统理解”放回工作清单的最高优先级而不是继续盲目追求“AI 生成代码的速度”。后面的章节就是我在实践里总结出来的一些具体做法。2. 最容易让人“看不懂系统”的三个现场2.1 生成完就跑跳过了“因果链”第一个典型场景把需求往 AI 工具里一丢拿到代码直接运行。这个流程的问题在于你跳过了整个“为什么”的环节。AI 会根据输入需求给出实现但你怎么知道它选这个方案而不是另一个方案你怎么知道它为什么用这个数据结构为什么在这个位置加缓存为什么这么拆分函数真实项目里这种“不知道原因但能跑”的代码会迅速累积。一开始你还能通过上下文猜个大概但一旦模块之间有了交互你连猜的素材都没有了。比如 WMS 系统里库存扣减和订单状态变更经常是耦合的。AI 如果帮你改了一段扣减逻辑但它没有同步理解订单状态机里那些状态的值是怎么流转的它给出的代码在单独测试时没问题放在整个系统里就可能导致状态不一致。我的经验是AI 生成的代码一定要先让它解释“为什么”再运行。你可以在提示词里直接要求“请解释这段代码的完整思路、它对哪些模块有副作用、你做了哪些取舍”。如果解释里有任何一点让你觉得奇怪就该停下来追问。2.2 非关键代码系统一耦合就麻第二个典型场景发生在“你以为 AI 只改了一个小地方”的时候。AI 编程工具很多时候做的是局部修改你丢给它一个函数它改了这个函数你丢给它一个类它改了类。但它不会主动告诉你说这个类的构造函数变了之后下游有三个模块会受到隐式影响。举个例子智能家居系统里有个设备管理模块设备状态上报的逻辑分散在好几个服务里。某次我想让 AI 优化状态上报频率的处理它给我改了一个公共工具方法。单看这个方法确实干净了。但设备状态的上报链路有个隐式约定消息顺序必须保持否则状态会回退到旧值。AI 优化后为了性能给消息增加了并发处理顺序全乱了。这类问题的根源在于AI 不理解系统的耦合点而你把系统的耦合点也忘了。你以为自己在做局部重构其实动了全局契约。为了避免这种情况我对 AI 的所有改动都会加一句约束“在回答前先列出所有调用此题的关键位置。”虽然不能完全替代人工排查但至少能逼它给出一个方向也逼我自己去看那个方向。2.3 老系统改造AI 改的是表面破的是结构第三个更隐蔽的场景是改造老系统。老系统最大的问题不是脏代码而是隐式约定太多注释里没写、文档里没有、只有线上行为能推断出来。AI 读代码看的是语法和常见模式它很难理解这些隐式约定。比如有一个比较老的设备管理系统自动化控制系统里的设备调度一直依赖一个“序号即优先级”的隐性规则。这个规则没有任何注释只体现在某段看起来有点奇怪的条件判断里。我想让 AI 把这段逻辑改成更现代的状态机AI 生成的新版本优雅很多但原来的优先级排序规则被丢掉了因为没有任何提示让它注意这个隐性依赖。这个坑让我明白一个道理老系统改造的核心难点从来不是“改代码”而是“梳理约束”。AI 可以帮你把代码改得快但它不能帮你把约束找出来。约束只有人能发现你需要跑业务线、看日志、找老同事确认。在这些约束没有被老老实实记录成文档之前不该让 AI 大范围重构。3. 解药一把 AI 当“结对同事”别当“代笔”3.1 先拿解释再拿代码我调整的第一个习惯是改变和 AI 协作的提示词结构。过去我会写“帮我实现一个 xxx”现在我会写“请先分析这个问题给出你的设计思路和可能的方案对比然后给出你认为最合适的实现并在代码中加入注释解释关键决策”。这个变化看上去很小但效果非常明显。当你让 AI 先讲思路它相当于在脑内过了一遍“为什么”。这份思路其实就是它的心智模型。你可以拿这份心智模型和你自己的理解做对比不一致的地方立刻讨论清楚。到了这一步你拿到的就不再只是一段代码而是一段“有上下文”的代码。实际上这一步也会反过来提高代码质量。AI 在解释阶段如果发现自己给不出清晰的方案它会倾向于在代码里增加防御性逻辑或注释这等于逼它在生成前先整理逻辑。对比实验下来用“先解释再写代码”的方式AI 生成的代码在后期 review 中要改的概率明显低很多。3.2 把 review 清单搬到 AI 生成代码上第二个改变是建立针对 AI 生成代码的 review 清单。以前我们的 review 是人工流程看逻辑、看格式、看边界。对 AI 代码我额外加了几个专属问题这段代码有重复实现吗是否动到了公共逻辑这个函数的副作用是什么它改写了哪些共享状态异常处理的方式符合系统约定吗这个数据结构的选取是否和本模块现有风格一致这些问题不复杂但它们就像筛子能把 AI 代码里那些“看起来精致、实际上很随意”的地方捞出来。AI 对代码风格的一致性感知很弱它在同一个项目里生成不同模块时经常会出现同一逻辑的不同写法。你如果不在 review 阶段收紧系统内部的“方言”就会越来越多。3.3 让 AI 补“为什么”注释而不是补“在做什么”第三点我觉得值得单独说在 AI 生成的代码里最缺少的注释永远是“为什么”。AI 很擅长写“在做什么”的注释比如// 从缓存中读取数据但这类注释对理解系统的价值很低——代码本身就在表达这件事。真正有价值的是“为什么”。比如“为什么这里用了悲观锁而不是乐观锁”“为什么这里要延迟两秒再重试”“为什么这里的排序不按时间而是按状态权重”这类问题AI 如果不问它的实现就只是一个偶然的选择。你在 review 时如果发现 AI 代码里有任何“看起来可以换个写法”的地方直接让 AI 解释“为什么这么写”。如果它解释得含糊你就该考虑改掉这段代码。解释不清楚的实现哪怕能跑也是一颗定时炸弹。4. 解药二重建系统心智图让 AI 帮你画4.1 系统心智图是什么所谓系统心智图就是你对一个系统“结构和行为”的直觉。你看到一个模块名就能大概说出它上下游是谁看到一条异常日志就能想到它最可能从哪个服务里来听到一次功能变更就能预判影响面。这种能力不是天生的全是靠读代码和跑系统堆出来的。AI 时代最大的风险就是有了 AI 之后很多新人根本不再尝试画心智图。他们直接问 AI“这个系统怎么跑起来的”AI 也能给一份答案但那份答案是 AI 读代码后的推断不是你的。你如果只是复述 AI 的解释你依然没有理解系统你只是理解了一段描述。所以我的建议是心智图必须由你自己构建AI 只能当一个“快进按钮”。4.2 具体做法从入口到大模块我在实践里用的方法很简单就是“从入口倒推法”。拿一个系统先找到它的入口API 网关、定时任务、消息队列然后沿着调用链一路往下点名每经过一个模块就记录下干什么的、依赖谁、被谁依赖、有什么核心状态。这个过程很费时间但它会让你获得一个只存在于脑海里的调用链。之后再用 AI 去做增量验证你可以把你手画的链路图贴给 AI让它检查遗漏也可以让它列出某个模块的所有外部依赖再和你自己的图做对比。这样 AI 就不是“替你理解”而是“帮你的理解纠错”。体会下来最花时间也最有价值的部分不是画图而是“不理解的地方停下来”。当你发现自己画到某处卡住了那不是坏事那是系统在告诉你你的认知边界就在这里。解决它你的系统理解就会往前推进一大块。4.3 让 AI 在输出这份图时的正确用法有人可能会问让 AI 一次生成整个系统架构不行吗我的回答是可以生成但要用对方式。一次性让 AI 输出一张完整架构图会让人产生一种“我已经懂了”的错觉。其实你只是拿到了一张外部视角的示意图它回答了系统大概长什么样但没有回答系统为什么长这样。比较靠谱的方式是“分段构建”先要求 AI 分析系统入口与顶层模块你自己看完验证后再让 AI 深入某个模块的细节。如此一层层下去每一步你都亲自验证过。这很像组装一台服务器你可以看装机视频但亲手插过内存条、拧过散热器螺丝之后你才真正理解内存通道和风道是怎么走的。这套方法的额外收益是如果你用的代码库有自动化测试分段构建心智图的过程其实就是测试用例的现成来源。每画一段你就写一个测试用例去验证这段链路的行为既加固系统也巩固认知。5. 解药三守住“手写底线”永远留一块自己的训练场5.1 哪些代码必须手写AI 再怎么强有些能力是我坚持人工完成的。第一个是核心算法尤其是那些涉及业务命脉的逻辑库存扣减、金额计算、订单状态流转。第二个是异常边界比如并发冲突、重试逻辑、超时处理。第三个是性能关键路径这类代码对性能的每一毫秒都敏感AI 生成的通用版本往往不是最优解。我这么做不是不相信 AI而是因为这些地方一旦理解缺失出事故的代价极高。整段代码虽然可以让 AI 写但我必须手写至少 30% 的骨架然后让 AI 帮我补全剩下的 70%。这个过程能保证我对核心逻辑有第一手的感觉。举个容易理解的生活类比你可以用洗碗机洗碗但让你手洗一个传家瓷碗时你就会格外小心记住它的釉面有多脆弱。AI 帮你写核心模块就像洗碗机洗传家宝它转得很快但你对这件瓷器的特性没有任何感知。手写不是为了写得更好而是为了“感知”那个模块。5.2 给自己设一个“无 AI 日”我试过的另一个很有效的方法是“无 AI 日”也就是每周固定一天所有代码都手写禁止使用 AI 补全与生成。那一天效率会特别低但也是我对系统重获掌控感最强的一天。因为手写逼你逐行读代码、慢慢查引用、仔细想命名所有这些慢动作都在构建被你遗忘的心智模型。刚开始你会很别扭甚至会怀疑这是不是在浪费时间。但坚持几周之后你会发现自己对系统的整体把握能力回来了你能准确说出某个类上游有哪些调用者能感受到某个改动的副作用范围能在面对线上问题时迅速定位到可疑模块。这种能力在日常 AI 辅助编码时被悄悄隐藏了但它才是你作为一个“系统负责人”的核心竞争力。如果你觉得每周一天太奢侈可以退一步至少保住“每次重构前手写一遍旧代码”的习惯。把旧代码重新打一遍的过程实际就是一次深读很多之前忽略的细节都会浮现出来。5.3 团队层面的“理解门槛”规则写到这我觉得必须再说一点这件事不该只是个人行为它应该变成一个团队约定。我所在的小组现在有一个不成文的规则任何 AI 生成的代码必须由提交者向团队讲清楚三件事这段代码解决了什么问题、它怎么融入现有结构、它可能影响哪些模块。讲不清楚就不合入主分支这不是刁难而是防止系统内部的知识断层加速扩大。实际上这种做法的回报是立竿见影的。过去大家各自用 AI 改代码系统内部经常出现“这个变量怎么突然变了”的争论。有了这条规则之后很多争议在提交阶段就被消化掉了。代码合入后大家的认知比较统一系统没有变得四分五裂。6. 常见问题与排查技巧实录6.1 当 AI 改坏了系统怎么找回失控如果已经出现“看不懂系统”的失控状态第一步不是急着让 AI 再修而是先用版本管理工具把最近的改动全部回退。对是全部回退而不是只回退你认为有问题的那个文件。因为 AI 改动的影响面往往比你以为的大局部回退可能留下半套新逻辑和半套旧逻辑混在一起。回退之后建议用“二分比较法”排查把 AI 生成的代码和上一个可用版本的代码做 diff逐段对比。每一次对比都追问“这段变了是为了什么”如果有一个改动解释不出来就优先怀疑它。这个排查过程很枯燥但它能帮你重新建立对系统改动链路的敏感度。还有一个小实操在让 AI 动手改任何共享代码之前先要求它“给出所有调用该函数的入口清单”。把这个清单存下来。如果线上出问题这个清单就是你排查的地图。AI 自己往往不会主动给这份清单你必须在提示词里明确要求。6.2 已经长期失联从哪里开始重新接上如果你已经有一阵子只是 review AI 的代码而没有真正下钻过系统建议从“最不常用的模块”开始而不是从核心模块开始。核心模块通常牵一发动全身一上来就深读会让你压力很大。找一个边缘小模块从它的入口到出口完整读一遍画出链路再让 AI 帮你验证遗漏的引用关系。这有点像一个跑惯了高速的人想重新熟悉城市道路你不可能一上来就走市中心高架先从小路、支路开始把街区和地标对应起来对城市的地图感就会慢慢回来。系统理解也是一样从小模块到核心模块一步步重新建立地图感。6.3 我踩过的几个具体坑我把这段时间踩过的最典型的坑列成一个速查表也当作给自己留的一份备忘坑现象原因避免办法局部优化条全局改动公共方法后多个下游模块行为改变没检查调用链强制让 AI 先列调用方隐式规则丢失老系统重构后边缘行为变化AI 没掌握无注释约定重构前先人工梳理约束文档重复逻辑扩散同一业务逻辑多套实现没有代码风格约束review 阶段做抽象收敛异常处理不一致相同错误处理路径不同方式缺乏系统约定提示在提示词中带系统规范性能劣化AI 生成代码在流量高峰卡住通用实现不考虑热点路径性能关键路径手写回头看这些坑并不是 AI 的锅而是我在“把理解责任转交给 AI”的过程中放弃了自己作为系统主人的审查职责。AI 是放大器你的方法论正确它会放大效率你的认知模糊它就把模糊以同样快的速度复制到全系统里。6.4 可以放进下一个项目的小习惯最后说一个我现在每接一个新项目都会做的事先花半天时间把手头的核心链路用文字写出来不依赖任何 AI。写完之后再让 AI 去生成同样的描述逐行对比。AI 的版本大概率更全但我手写的版本才是我真正理解的版本后者才是未来遇到问题时的参考基准。另外建议在代码仓库里维护一个“系统决策记录”目录把每个关键模块为什么这么设计写成一个简短文档。AI 生成的代码再好如果背后没有这些决策记录后来的人翻代码时还是在猜谜。这种文档不需要很长每篇几百字足够但它能让整个团队在 AI 时代仍然拥有一个共享的系统心智图。我自己在实际操作中最大的体会是AI 写代码很快但正因为它快我才必须更慢地理解系统。快与慢不是对立的而是互补的。把“理解系统”这件事牢牢握在自己手里AI 写得越快你的产出质量才越高。 
长河君 · 2026/10/29 16:25:06 · 阅读 1.2k AI写代码虽快，但别丢了系统理解：找回系统认知的三种方法
最近和几个朋友聊到一个特别真实的感受AI 写代码的效率确实上来了但项目里的系统却越来越像黑盒。过去改一行配置、跑一遍测试大概能猜出整个模块的前后关联现在一段段代码丢给 AI 改完功能跑得通可真要我指出来它改了什么、动了哪些依赖、有没有碰到别的模块我反而讲不清楚了。这种状态持续了几个月后我开始认真复盘问题不在 AI 写代码快不快而在于我把太多“理解系统”的工作外包了出去。今天这篇东西就是把这几个月踩过的坑、试过的方法、以及最后怎么把“系统认知”找回来的过程梳理一遍。顺带把 AI 编程提示词、AI agent、多 AI 协作这些身边天天在聊的东西串起来讲清楚希望能给同样困惑的人一些参考。1. 现象代码交付变快了系统却变“黑”了1.1 快是快了但我开始看不懂昨天的代码最常见的场景是这样的早上接到需求对着 AI 工具描述了一通业务逻辑几十秒后一段能跑的代码就出来了。复制、粘贴、改几个参数单元测试一过功能就完事了。一开始你会觉得很爽一天能顶过去三天。可两周后回头看自己拼出来的模块连“这段代码为什么会这样写”都得问 AI 才能回忆起来。这种状态有个名字叫“生成式盲区”。你拿到了结果但没有拿到产生这个结果的推理过程。代码在运行层面是对的但它没有在你的大脑里形成对应的因果模型。一旦系统出了线上问题你在 IDE 里面对这一堆 AI 生成的函数根本没有“哪里可能藏雷”的方向感。更麻烦的是AI agent 和代码补全工具会主动替你决策变量怎么命名、函数怎么拆分、异常怎么处理。这些决策看起来无害但每一个都在悄悄塑造系统结构。等你发现系统里到处都是风格不一的代码块、同一件事有三种实现方式时系统已经变成了一个“局部清晰、全局混沌”的状态。1.2 为什么速度越快理解越容易缺位过去我们写代码是“慢工出细活”。一行一行手打的过程中大脑会不自觉建立变量之间的关系、函数之间的调用链、模块之间的依赖。这个过程虽然慢但它本质上是一种认知训练代码写完了系统的地图也画完了。AI 写代码最大的变化是它把“敲键过程”压缩掉了。你从执行者变成了审查者而审查者通常只看结果不看路径。结果导向没问题但代价是你对系统的心智模型越来越模糊。一个真实的例子之前用 AI 辅助重构一个老模块AI 生成的新实现比旧代码短了三分之一逻辑看起来也更整洁。我急着确认行为一致就跑了几个关键测试用例全过于是高高兴兴提交了。结果一周后同事告诉我某个边缘场景的行为完全变了不是坏就是变成了“另一个合理但没人想改”的行为。这类问题就是典型的“我看不懂系统”的症状你只知道功能对不对不知道系统整体是不是还是原来那个系统。AI 压缩了编码时间但它没有代替你完成对系统的理解。理解这件事仍然只能由人来完成。1.3 “能跑”和“看得懂”是两件事我后来给自己定了一个标准能跑的代码不等于我拥有的代码。所谓“拥有”是指当别人指着系统里任何一个函数问我“这里为什么这样写”时我能讲出设计意图、调用来源、失败模式。达不到这个标准的代码本质上只是一段寄生在仓库里的文本。这就像你请了个管家帮你管家他把所有账单都付了、客厅也收拾了但若哪天他请假了你不知道水电费在哪交、备用钥匙放哪、哪个开关控制哪盏灯整个家就瘫痪了。AI 会写代码不代表你懂系统懂系统的人也不会因为 AI 的出现就突然不需要懂系统。想通这一点之后我开始把“建立系统理解”放回工作清单的最高优先级而不是继续盲目追求“AI 生成代码的速度”。后面的章节就是我在实践里总结出来的一些具体做法。2. 最容易让人“看不懂系统”的三个现场2.1 生成完就跑跳过了“因果链”第一个典型场景把需求往 AI 工具里一丢拿到代码直接运行。这个流程的问题在于你跳过了整个“为什么”的环节。AI 会根据输入需求给出实现但你怎么知道它选这个方案而不是另一个方案你怎么知道它为什么用这个数据结构为什么在这个位置加缓存为什么这么拆分函数真实项目里这种“不知道原因但能跑”的代码会迅速累积。一开始你还能通过上下文猜个大概但一旦模块之间有了交互你连猜的素材都没有了。比如 WMS 系统里库存扣减和订单状态变更经常是耦合的。AI 如果帮你改了一段扣减逻辑但它没有同步理解订单状态机里那些状态的值是怎么流转的它给出的代码在单独测试时没问题放在整个系统里就可能导致状态不一致。我的经验是AI 生成的代码一定要先让它解释“为什么”再运行。你可以在提示词里直接要求“请解释这段代码的完整思路、它对哪些模块有副作用、你做了哪些取舍”。如果解释里有任何一点让你觉得奇怪就该停下来追问。2.2 非关键代码系统一耦合就麻第二个典型场景发生在“你以为 AI 只改了一个小地方”的时候。AI 编程工具很多时候做的是局部修改你丢给它一个函数它改了这个函数你丢给它一个类它改了类。但它不会主动告诉你说这个类的构造函数变了之后下游有三个模块会受到隐式影响。举个例子智能家居系统里有个设备管理模块设备状态上报的逻辑分散在好几个服务里。某次我想让 AI 优化状态上报频率的处理它给我改了一个公共工具方法。单看这个方法确实干净了。但设备状态的上报链路有个隐式约定消息顺序必须保持否则状态会回退到旧值。AI 优化后为了性能给消息增加了并发处理顺序全乱了。这类问题的根源在于AI 不理解系统的耦合点而你把系统的耦合点也忘了。你以为自己在做局部重构其实动了全局契约。为了避免这种情况我对 AI 的所有改动都会加一句约束“在回答前先列出所有调用此题的关键位置。”虽然不能完全替代人工排查但至少能逼它给出一个方向也逼我自己去看那个方向。2.3 老系统改造AI 改的是表面破的是结构第三个更隐蔽的场景是改造老系统。老系统最大的问题不是脏代码而是隐式约定太多注释里没写、文档里没有、只有线上行为能推断出来。AI 读代码看的是语法和常见模式它很难理解这些隐式约定。比如有一个比较老的设备管理系统自动化控制系统里的设备调度一直依赖一个“序号即优先级”的隐性规则。这个规则没有任何注释只体现在某段看起来有点奇怪的条件判断里。我想让 AI 把这段逻辑改成更现代的状态机AI 生成的新版本优雅很多但原来的优先级排序规则被丢掉了因为没有任何提示让它注意这个隐性依赖。这个坑让我明白一个道理老系统改造的核心难点从来不是“改代码”而是“梳理约束”。AI 可以帮你把代码改得快但它不能帮你把约束找出来。约束只有人能发现你需要跑业务线、看日志、找老同事确认。在这些约束没有被老老实实记录成文档之前不该让 AI 大范围重构。3. 解药一把 AI 当“结对同事”别当“代笔”3.1 先拿解释再拿代码我调整的第一个习惯是改变和 AI 协作的提示词结构。过去我会写“帮我实现一个 xxx”现在我会写“请先分析这个问题给出你的设计思路和可能的方案对比然后给出你认为最合适的实现并在代码中加入注释解释关键决策”。这个变化看上去很小但效果非常明显。当你让 AI 先讲思路它相当于在脑内过了一遍“为什么”。这份思路其实就是它的心智模型。你可以拿这份心智模型和你自己的理解做对比不一致的地方立刻讨论清楚。到了这一步你拿到的就不再只是一段代码而是一段“有上下文”的代码。实际上这一步也会反过来提高代码质量。AI 在解释阶段如果发现自己给不出清晰的方案它会倾向于在代码里增加防御性逻辑或注释这等于逼它在生成前先整理逻辑。对比实验下来用“先解释再写代码”的方式AI 生成的代码在后期 review 中要改的概率明显低很多。3.2 把 review 清单搬到 AI 生成代码上第二个改变是建立针对 AI 生成代码的 review 清单。以前我们的 review 是人工流程看逻辑、看格式、看边界。对 AI 代码我额外加了几个专属问题这段代码有重复实现吗是否动到了公共逻辑这个函数的副作用是什么它改写了哪些共享状态异常处理的方式符合系统约定吗这个数据结构的选取是否和本模块现有风格一致这些问题不复杂但它们就像筛子能把 AI 代码里那些“看起来精致、实际上很随意”的地方捞出来。AI 对代码风格的一致性感知很弱它在同一个项目里生成不同模块时经常会出现同一逻辑的不同写法。你如果不在 review 阶段收紧系统内部的“方言”就会越来越多。3.3 让 AI 补“为什么”注释而不是补“在做什么”第三点我觉得值得单独说在 AI 生成的代码里最缺少的注释永远是“为什么”。AI 很擅长写“在做什么”的注释比如// 从缓存中读取数据但这类注释对理解系统的价值很低——代码本身就在表达这件事。真正有价值的是“为什么”。比如“为什么这里用了悲观锁而不是乐观锁”“为什么这里要延迟两秒再重试”“为什么这里的排序不按时间而是按状态权重”这类问题AI 如果不问它的实现就只是一个偶然的选择。你在 review 时如果发现 AI 代码里有任何“看起来可以换个写法”的地方直接让 AI 解释“为什么这么写”。如果它解释得含糊你就该考虑改掉这段代码。解释不清楚的实现哪怕能跑也是一颗定时炸弹。4. 解药二重建系统心智图让 AI 帮你画4.1 系统心智图是什么所谓系统心智图就是你对一个系统“结构和行为”的直觉。你看到一个模块名就能大概说出它上下游是谁看到一条异常日志就能想到它最可能从哪个服务里来听到一次功能变更就能预判影响面。这种能力不是天生的全是靠读代码和跑系统堆出来的。AI 时代最大的风险就是有了 AI 之后很多新人根本不再尝试画心智图。他们直接问 AI“这个系统怎么跑起来的”AI 也能给一份答案但那份答案是 AI 读代码后的推断不是你的。你如果只是复述 AI 的解释你依然没有理解系统你只是理解了一段描述。所以我的建议是心智图必须由你自己构建AI 只能当一个“快进按钮”。4.2 具体做法从入口到大模块我在实践里用的方法很简单就是“从入口倒推法”。拿一个系统先找到它的入口API 网关、定时任务、消息队列然后沿着调用链一路往下点名每经过一个模块就记录下干什么的、依赖谁、被谁依赖、有什么核心状态。这个过程很费时间但它会让你获得一个只存在于脑海里的调用链。之后再用 AI 去做增量验证你可以把你手画的链路图贴给 AI让它检查遗漏也可以让它列出某个模块的所有外部依赖再和你自己的图做对比。这样 AI 就不是“替你理解”而是“帮你的理解纠错”。体会下来最花时间也最有价值的部分不是画图而是“不理解的地方停下来”。当你发现自己画到某处卡住了那不是坏事那是系统在告诉你你的认知边界就在这里。解决它你的系统理解就会往前推进一大块。4.3 让 AI 在输出这份图时的正确用法有人可能会问让 AI 一次生成整个系统架构不行吗我的回答是可以生成但要用对方式。一次性让 AI 输出一张完整架构图会让人产生一种“我已经懂了”的错觉。其实你只是拿到了一张外部视角的示意图它回答了系统大概长什么样但没有回答系统为什么长这样。比较靠谱的方式是“分段构建”先要求 AI 分析系统入口与顶层模块你自己看完验证后再让 AI 深入某个模块的细节。如此一层层下去每一步你都亲自验证过。这很像组装一台服务器你可以看装机视频但亲手插过内存条、拧过散热器螺丝之后你才真正理解内存通道和风道是怎么走的。这套方法的额外收益是如果你用的代码库有自动化测试分段构建心智图的过程其实就是测试用例的现成来源。每画一段你就写一个测试用例去验证这段链路的行为既加固系统也巩固认知。5. 解药三守住“手写底线”永远留一块自己的训练场5.1 哪些代码必须手写AI 再怎么强有些能力是我坚持人工完成的。第一个是核心算法尤其是那些涉及业务命脉的逻辑库存扣减、金额计算、订单状态流转。第二个是异常边界比如并发冲突、重试逻辑、超时处理。第三个是性能关键路径这类代码对性能的每一毫秒都敏感AI 生成的通用版本往往不是最优解。我这么做不是不相信 AI而是因为这些地方一旦理解缺失出事故的代价极高。整段代码虽然可以让 AI 写但我必须手写至少 30% 的骨架然后让 AI 帮我补全剩下的 70%。这个过程能保证我对核心逻辑有第一手的感觉。举个容易理解的生活类比你可以用洗碗机洗碗但让你手洗一个传家瓷碗时你就会格外小心记住它的釉面有多脆弱。AI 帮你写核心模块就像洗碗机洗传家宝它转得很快但你对这件瓷器的特性没有任何感知。手写不是为了写得更好而是为了“感知”那个模块。5.2 给自己设一个“无 AI 日”我试过的另一个很有效的方法是“无 AI 日”也就是每周固定一天所有代码都手写禁止使用 AI 补全与生成。那一天效率会特别低但也是我对系统重获掌控感最强的一天。因为手写逼你逐行读代码、慢慢查引用、仔细想命名所有这些慢动作都在构建被你遗忘的心智模型。刚开始你会很别扭甚至会怀疑这是不是在浪费时间。但坚持几周之后你会发现自己对系统的整体把握能力回来了你能准确说出某个类上游有哪些调用者能感受到某个改动的副作用范围能在面对线上问题时迅速定位到可疑模块。这种能力在日常 AI 辅助编码时被悄悄隐藏了但它才是你作为一个“系统负责人”的核心竞争力。如果你觉得每周一天太奢侈可以退一步至少保住“每次重构前手写一遍旧代码”的习惯。把旧代码重新打一遍的过程实际就是一次深读很多之前忽略的细节都会浮现出来。5.3 团队层面的“理解门槛”规则写到这我觉得必须再说一点这件事不该只是个人行为它应该变成一个团队约定。我所在的小组现在有一个不成文的规则任何 AI 生成的代码必须由提交者向团队讲清楚三件事这段代码解决了什么问题、它怎么融入现有结构、它可能影响哪些模块。讲不清楚就不合入主分支这不是刁难而是防止系统内部的知识断层加速扩大。实际上这种做法的回报是立竿见影的。过去大家各自用 AI 改代码系统内部经常出现“这个变量怎么突然变了”的争论。有了这条规则之后很多争议在提交阶段就被消化掉了。代码合入后大家的认知比较统一系统没有变得四分五裂。6. 常见问题与排查技巧实录6.1 当 AI 改坏了系统怎么找回失控如果已经出现“看不懂系统”的失控状态第一步不是急着让 AI 再修而是先用版本管理工具把最近的改动全部回退。对是全部回退而不是只回退你认为有问题的那个文件。因为 AI 改动的影响面往往比你以为的大局部回退可能留下半套新逻辑和半套旧逻辑混在一起。回退之后建议用“二分比较法”排查把 AI 生成的代码和上一个可用版本的代码做 diff逐段对比。每一次对比都追问“这段变了是为了什么”如果有一个改动解释不出来就优先怀疑它。这个排查过程很枯燥但它能帮你重新建立对系统改动链路的敏感度。还有一个小实操在让 AI 动手改任何共享代码之前先要求它“给出所有调用该函数的入口清单”。把这个清单存下来。如果线上出问题这个清单就是你排查的地图。AI 自己往往不会主动给这份清单你必须在提示词里明确要求。6.2 已经长期失联从哪里开始重新接上如果你已经有一阵子只是 review AI 的代码而没有真正下钻过系统建议从“最不常用的模块”开始而不是从核心模块开始。核心模块通常牵一发动全身一上来就深读会让你压力很大。找一个边缘小模块从它的入口到出口完整读一遍画出链路再让 AI 帮你验证遗漏的引用关系。这有点像一个跑惯了高速的人想重新熟悉城市道路你不可能一上来就走市中心高架先从小路、支路开始把街区和地标对应起来对城市的地图感就会慢慢回来。系统理解也是一样从小模块到核心模块一步步重新建立地图感。6.3 我踩过的几个具体坑我把这段时间踩过的最典型的坑列成一个速查表也当作给自己留的一份备忘坑现象原因避免办法局部优化条全局改动公共方法后多个下游模块行为改变没检查调用链强制让 AI 先列调用方隐式规则丢失老系统重构后边缘行为变化AI 没掌握无注释约定重构前先人工梳理约束文档重复逻辑扩散同一业务逻辑多套实现没有代码风格约束review 阶段做抽象收敛异常处理不一致相同错误处理路径不同方式缺乏系统约定提示在提示词中带系统规范性能劣化AI 生成代码在流量高峰卡住通用实现不考虑热点路径性能关键路径手写回头看这些坑并不是 AI 的锅而是我在“把理解责任转交给 AI”的过程中放弃了自己作为系统主人的审查职责。AI 是放大器你的方法论正确它会放大效率你的认知模糊它就把模糊以同样快的速度复制到全系统里。6.4 可以放进下一个项目的小习惯最后说一个我现在每接一个新项目都会做的事先花半天时间把手头的核心链路用文字写出来不依赖任何 AI。写完之后再让 AI 去生成同样的描述逐行对比。AI 的版本大概率更全但我手写的版本才是我真正理解的版本后者才是未来遇到问题时的参考基准。另外建议在代码仓库里维护一个“系统决策记录”目录把每个关键模块为什么这么设计写成一个简短文档。AI 生成的代码再好如果背后没有这些决策记录后来的人翻代码时还是在猜谜。这种文档不需要很长每篇几百字足够但它能让整个团队在 AI 时代仍然拥有一个共享的系统心智图。我自己在实际操作中最大的体会是AI 写代码很快但正因为它快我才必须更慢地理解系统。快与慢不是对立的而是互补的。把“理解系统”这件事牢牢握在自己手里AI 写得越快你的产出质量才越高。