1. “90% Review”是怎么发生的先拆解这个比例背后的结构1.1 代码产出链路的重量偏移从“写”变成“选”最近和一个做了多年后端开发的朋友吃饭他说自己现在的工作日常非常单调白天大部分时间在Review AI编程助手生成的代码晚上还要去回复别人对他自己代码的评审意见。他很矛盾一方面确实不需要从零敲键盘了另一方面又觉得自己不像程序员更像一个流水线上的复检员。这个现象我太熟悉了过去几个月身边不少同行都在说类似的话代码生产率上来了但审阅负担也上来了甚至有人自嘲“工作变成了90%的Review”。这里的“Review”不光是正式的代码评审还包括每天对着AI生成结果一条条核对、修改、确认的隐性环节。如果我们把写代码这件事拆成“设计、实现、验证、维护”四个动作很多人会发现“实现”这个动作被压缩到了几乎没有而“验证”和“维护”被无限放大。以前写一个接口从建表语句到参数校验每一步都需要自己想清楚然后在编辑器里敲出来现在只需要用自然语言描述需求AI能在几十秒内给你一版完整代码。成本确实下降了但“想清楚”这件事并没有被替代它只是从“动手前”被转移到了“生成后”变成了更耗精力的辨别和修正。这个重量偏移就是“90% Review”说法的来源。你不再为每行代码付出手指成本却要为整个实现负全责。AI承担的是“草稿纸”而你从“执笔人”变成了“验收人”。听起来轻松实际上并不轻松因为验收一件不是自己亲手做的复杂产物往往比自己做一遍更费神尤其是当你不清楚它是怎么生成的时候。真正需要关注的核心也在这里不是比例本身而是我们有没有意识到这个转变正在重塑我们的技能结构。1.2 Review被拆成三层跑通、业务匹配、系统整合我后来把日常Review拆成了三个层面这样更容易定位精力消耗。第一层是“跑通检查”也就是编译能不能过、测试能不能跑、类型和明显的逻辑漏洞是否存在。过去这一层由编译器和单测承担大半但现在情况变了AI生成的代码第一眼往往很漂亮函数名规范、注释齐全却偶尔会有变量名弄混、参数顺序颠倒、边界条件少写等小毛病这些“看起来合理但实际有问题”的瑕疵非常依赖人眼去抓。第二层是“业务匹配检查”这一层恰恰是最难的。AI不知道你的业务上下文它以为的“用户”和你实际面对的“用户”不一样它默认的异常处理策略可能和你的合规要求冲突它理解的“订单状态”也许少了你业务里特有的中间态。很多Review不仅是看代码逻辑还要把代码映射回真实业务里去比对这是一项纯粹的、无法交给工具去自动化的判断。第三层是“系统整合检查”也就是新代码装进现有系统之后接口契约、数据流、权限边界、事务一致性是否仍然成立。这一层最累因为你不能只看这一段代码本身你要看它在整个系统里的上下游。AI生成单点代码通常没问题但一旦涉及跨模块、跨服务的连接它缺失背景知识的问题就会暴露。三个层面叠加在一起Review自然不会像想象中那么轻松。1.3 真正的风险不是工作量而是技能结构失衡把时间都花在“确认AI没做错”上意味着你反复练习的是鉴别能力而不是构建能力。鉴别能力有用但它的成长是有上限的就像你天天看别人做菜、评价别人做的菜自己动手的机会就会越来越少慢慢变成一个“什么都见过但自己不会上灶”的人。这种失衡短期看不出什么半年一年后就有明显体感设计新模块时思路不如以前开阔遇到复杂问题能想到的落地方案变少评审时提的意见越来越倾向于“细节修正”而不是“方向判断”。我并不是说AI辅助编码不好而是说当我们把精力结构从“构建为主、验证为辅”变成“验证为主、构建为辅”我们的能力分布就会跟着变。谁先意识到这一点谁才有机会主动调整方向而不是等到转型发生时发现自己手里只剩下一项正在贬值的能力。2. 被动Review是职业风险“确认机器”会越当越钝2.1 “AI写、人确认”的循环为什么会侵蚀判断力这里有个很隐蔽的机制值得展开说。当AI生成的代码90%看起来都是对的你的注意力会不自觉地放松到“扫一眼有没有明显错误”的程度而不是“验证每一步是否符合目标”。大脑天然会走捷径我们每天要处理的信息量那么大如果每一段AI代码都像审犯人一样从头到尾严格推理精力根本撑不住。于是你会开始依赖“整体印象”来做判断印象上没问题就通过。问题在于AI生成的错误很少是“整体看起来不对”的那种它往往是隐藏在正常结构里的逻辑偏斜比如某个边界条件没覆盖、某个异常路径被吞掉、某个状态更新顺序反了单看上下文不觉得有问题放回业务流程里才会引爆。一个只做“印象流Review”的人很容易漏掉这类问题而且更难察觉的是自己的判断在一次次“看起来没问题”里变得越来越钝。期待它是对的就会更容易看到它对的证据眼睛自动忽略了可疑处这个倾向几乎人人都有。时间一长你会发现自己从“评审者”退化成“确认者”。评审者的问题是我觉得哪里不对我要挖掘确认者的问题是看起来都还行那就算了吧。这是逆向进化的方向但很多被动Review的人正在不知不觉往里走。我的经验是必须主动给自己留出“找茬时间”在AI生成完代码后专门花几分钟挑刺不要马上进入“要不要通过”的判断而是先假定它有错看能不能找出证据。这个小习惯能把判断力拉回锋利的状态。2.2 手感丧失后评审质量会跟着塌我有过一段非常明显的退化经历。连续几周主要依赖AI写业务代码自己只做查看和修改后来接手一个老模块需要手写一段不算复杂的递归逻辑我竟然在几个方案之间犹豫了很久。那种生疏感非常真实就像常年骑电瓶车的人偶尔换回自行车明明会骑但操控自信已经没了。代码评审也是这样。如果你只读AI代码、只改AI代码没有亲自动手构建完整的东西你对“代价”的感觉会越来越弱。你会评估不出一段代码在维护阶段好不好改因为你自己很少经历“两星期后回头改这段代码”的痛感你也看不清代码里藏没藏复杂度因为你没有亲手体会过复杂度是怎么滚雪球变大的。于是评审意见会变得越来越琐碎盯的多是缩进、命名、注释风格而不是结构性问题。这是手感丧失后的必然结果也是“被动Review”最可怕的地方你还在做着评审的工作但评审的价值已经在悄悄缩水。2.3 “绿勾型Review”和“价值型Review”要分清楚我用两个词来区分两类评审状态。“绿勾型Review”很好理解CI过了吗测试过了吗Lint过了吗格式规范吗都过了就点通过整个流程像完成一张打卡表。“价值型Review”看的是另一组问题这个实现的维护代价是什么将来加需求时它容不容易改它有没有把复杂度藏在不该藏的地方它引入的依赖值不值得它会不会让整个系统的故障半径变大被动Review会把你推向绿勾型因为当你没有亲自构建过你对维护代价很难有真实体感。但是恰恰是价值型Review才值钱。团队里真正稀缺的人不是那个能快速确认“代码能跑”的人而是那个能看出“这段代码一年后是个坑”的人。想做到后者你就不能只当确认机器你必须保持自己构建的能力、设计的直觉还要不断积累对变更代价的判断经验。3. 主动进化的四个方向把精力从“审稿人”变回“总编辑”3.1 向上游迁移把输入做对评审判定难度会骤降我调整的第一个方向是把自己的工作重心尽量往上游移动。一个很简单的道理如果前期输入够清晰AI产出的结果就不会偏差太远。与其对着结果反复修改不如在让它动手之前把边界条件、约束、验收标准写明白。我现在会在任务描述里加一条类似“请先给出实现方案并解释关键取舍等我确认后再生成代码”的约束这样我Review的就不是已经成型的代码而是“方案的讨论”。讨论层面发现问题成本极低代码层面发现问题修改成本已经是前者的好几倍。这就好比你有两个审稿策略一个是让作者先把提纲和核心论点给你看你判断方向对不对另一个是等作者写完一万字再去逐段改。后者当然也能干活但效率天差地别。我意识到自己过去太多次跳过了“设计确认”这个环节直接跳到“跑通检查和业务匹配检查”等于把最贵的评审资源花在了最便宜的问题上。把输入做对之后我Review时看的重点就从“全不对”变成了“哪里偏”判断难度骤降。3.2 向复杂度迁移专挑AI不擅长的结构性判断AI擅长的是组合常见模式它不擅长的是在复杂系统里做权衡。既然写代码这件事已经被它拉低了门槛我们自然应该往门槛更高的地方走。我自己会把精力刻意放在四类问题上模块边界是否合理接口抽象是否恰到好处数据流经过多个服务时失败路径是否都被考虑这次改动是让系统变简单了还是变复杂了。这些结构性判断不需要每时每刻都做但它们应该成为你日常工作里最有分量的部分。我给自己定的原则是AI可以决定“怎么实现”但“在哪里实现”“把某个能力放在哪个模块”“允许哪些模块直接改、哪些模块必须人工评审”这类决定必须由人来拍板。这不是出于控制欲而是因为这类决策需要的是对系统全貌的理解、对团队分工的理解、对演进方向的判断这些是目前大模型最不擅长的地方。3.3 向反馈闭环迁移让Review结果反哺后续生成以前我给AI提意见总是就事论事地把它写的代码直接改掉结果发现类似的问题换个场景又会冒出来。后来我开始有意识地做反馈归集每次Review中重复出现的问题按照类型记录例如“老是漏判空指针”“总是忘了做幂等处理”“喜欢把工具类写得过于通用”然后把这些高频问题写进下一次生成时的约束条件里或者变成团队项目文档里的明确规则。这个动作看起来简单但效果很深远因为它把Review从“消耗型工作”变成了“积累型工作”。你不再只是每个任务消耗精力去检查一遍而是在不断训练一个属于自己团队的定制化约束系统让下一轮的生成起点越来越高。我甚至会在代码评审意见里顺手加一句“这个问题建议加入团队约定的检查清单”保持反馈闭环的畅通。一段时间以后AI生成代码的初版质量确实在提升因为约束它的是结构化信息每次都在起作用。3.4 向组织机制迁移把个人经验变成团队的约束一个人再仔细也有盲区把个人经验变成团队的约束才能放大价值。过去小半年我做得比较有效的几件事包括把Review里重复出现的高频错误转成自动化检查规则让静态检查在流水线阶段就拦截掉一部分问题把“哪些高风险模块禁止AI直接修改”写进协作约定要求任何涉及这些模块的改动必须有设计说明把评审清单从“个人备忘录”变成“团队共用的模板”大家用同一套标准看代码。这些措施做下来有个直接好处团队对“什么是好代码”有了共同语言评审会从“个人审美的碰撞”变成“共同标准下的讨论”。而且当规则是透明、公开、可讨论的新人上手也快很多。主动进化如果只停留在个人层面它的上限就是你的精力一旦上升到组织层面它就变成了团队基础设施的一部分能持续发挥作用。4. 我亲身跑过的三条路径工具与工作习惯的具体调整4.1 用规格化输入控制生成边界我摸索出来一个实用的模板每次让AI写代码之前先填一段结构化的背景信息。标准的字段包括目标对象、输入、输出、边界条件、失败处理、性能要求。下面是我实际在用的简化版本【需求目标】对外提供订单状态查询接口 【输入】订单ID、用户ID 【输出】订单当前状态、最近更新时间 【边界】订单ID为空返回400无权访问返回403超过30秒未响应按超时处理 【失败处理】数据库不可用时返回503不返回缓存脏数据 【性能要求】P95 200msQPS上限500这段输入花不了几分钟却把“事后挑错”改成了“事前对齐”。让AI生成代码之前先确认理解这个表格你会发现生成结果偏离需求的情况大幅减少Review时你要做的只是核对偏差而不是排查意外。一个额外的心得是边界条件写得越具体AI越容易给出直接可用的代码因为它不用猜你到底要什么。模糊的输入只会换来模糊的输出然后把解读成本全部留给Review阶段。4.2 给评审清单分级而不是给代码挑毛病现在Review我基本不会逐行看而是按一套分级清单走。第一级是必须修复的问题包括安全漏洞、数据一致性问题、明确的功能错误这类问题无论风格如何都必须拦下。第二级是应该调整的问题包括命名混乱、函数体过长、异常处理缺失它们不致命但会影响维护成本应当明确要求改动。第三级是可以讨论的问题比如风格偏好、未来的重构机会、性能优化空间这类问题我通常只记录不掉头强制修改。这个分级帮了我大忙。以前我评审容易犯一个错误把“可以讨论”级别的事当成“必须修改”来提结果团队里的人觉得评审就是找茬、吹毛求疵我自己也累。分级之后评审意见变得高效且友好每个人知道什么绝对要改什么可以商榷优先级被强行拉齐。对Review AI生成代码也适用我会先标记第一级问题再看第二级第三级往往直接忽略。防止把精力浪费在不重要的完美上本身就是一种效率革命。4.3 “先讲理由再看实现”的Review顺序我调整的另一个习惯是Review的顺序不再一打开代码就开始逐行看而是先要求AI附上一段简短的“设计说明”讲清楚为什么用这种方案、考虑过哪些取舍、里头的关键分支是怎么决定的。如果这段理由说得清晰我就集中精力核对“理由和实现是否一致”如果理由本身写得含糊那就要特别当心因为它很可能是在拼接常见代码片段而不是针对这个问题的明确设计。实践下来这个顺序让我单次Review的时间下降了大概三分之一而发现的实质问题反而更多。原因很简单注意力被集中到了“意图”和“实现”之间的差。“意图”和“实现”一致代码通常就没大问题“意图”和“实现”出现落差那里往往藏着真正的坑。逐行盯变量名很快会让人疲劳但对比设计说明与代码实现是在做一件有明确目标的事它能让人保持清醒也让AI生成过程从“黑盒翻看”变成了“白盒检验”。5. 我踩过的坑为什么有些“进化”反而让人更累5.1 评审规范过度设计流程开始膨胀我曾经犯过一个典型的错误想把所有Review经验都沉淀成规范结果写了十几个分类、几十条检查项打印出来好几页纸。团队里的人看到那个清单的第一反应是这里太复杂了根本记不住后来连我自己也用不下去。规则过度设计的问题在于它把Review变成了一种考试而不是一种判断每一条都要对照反而忽略了对整体质量的感受。后来我调整了策略只有那些重复出现三次以上的问题才值得进入规范整个评审清单控制在一页以内每两个月清理一次不再适用的条目。简洁才可能被执行被执行才可能积累出真正的经验库。想要“主动进化”不代表规则越多越好而是让每条规则都有明确的保护对象最好都能指向一个真实踩过的坑。5.2 把活完全推给AI再用双倍时间修另一个坑来自偷懒心态。有一段时间我为了“效率最大化”把一个模块整体交给AI生成然后自己从头到尾修改。结果改的时间比自己写还要长而且因为我不是一开始就参与设计修的时候完全没有掌控感总担心某个角落藏着没发现的问题。那种“看似快实际慢还让人焦虑”的状态非常消耗精力。我现在的做法是切小步一次只让AI生成一个函数、一个文件生成后立刻人工确认有问题马上调整确认无误再进入下一个单元。这种流水线式的节奏让Review与你自己的工作交替进行始终处在对上下文有掌控的状态。小步快跑看着没有“一次性生成整个模块”爽但总耗时反而低很多风险也更容易控制Review不再需要同时面对一片陌生的汪洋。5.3 强行拒绝AI的“手工人士”也是在另一种被动我也见过另一类人他们反着来坚持所有代码都要手写理由是AI写的不受控、不符合自己审美。我理解这种不安全感但坦白说把时间花在对抗工具上同样是一种被动。你并没有把精力配置到更高价值的判断、设计、反馈闭环上你只是换了一种方式让自己更忙忙到没空思考方向。我的态度是用工具但不依赖工具。让AI承担“起草”人承担“裁决”。重点在于你要始终保留裁决的依据也就是理解能力。如果一个人对AI产物没有足够的判断力他退回去手写问题并没有消失如果他足够懂行那么在AI辅助下他能产出三倍于手写时代的东西。主动进化的核心不是选边站队而是把手里的时间重新分配到更值钱的地方。6. 我建议的90天“主动进化”实验具体到每周可以做什么6.1 第一周记录时间找到你的Review黑洞不要凭感觉判断自己到底是不是90%的Review。我建议用一周时间做一次真实记录打开一个简单表格把每天的时间分成“设计、生成、验证、维护”四类凡是看代码、跑测试、改缺陷都算验证凡是写设计说明、定接口、拆模块都算设计。如实记七天不要边记边改工作习惯。做完这个记录你大概率会发现两个让自己吃惊的事实。第一Review相关的时间占比可能比想象中还要高因为它不止是正式的评审还包括大量碎片化的检查第二里面有相当一部分是低价值检查比如反复看同一个边界条件、反复试同一个异常分支。找到这些“Review黑洞”下一阶段才有明确的优化目标。顺带一提这个记录本身也能帮你避免“自己真的很忙”的错觉它把忙碌照出了形状。6.2 第二到第四周选一个模块做“设计先行”试点不需要全面铺开选一个你熟悉的模块就够了。从第二周开始每次动手前花十五分钟把设计说明写清楚边界、输入输出、失败处理、性能要求然后让AI在约束内生成生成后按分级清单Review。试运行两周之后和你过去的方式做对比重点观察两件事验证阶段的耗时是否下降Review里发现的问题是否从“低级错误”变成了“方案取舍问题”。根据我的经验这一步做完大部分人会被“设计先行”的效率震撼到。因为绝大多数无效Review来自模糊输入导致的方案错位而设计说明把这种错位提前消灭了。你每天Review的还是那些代码但你已经不是在海捞针而是在核对偏差。这个体验会直接改变你对“主动进化”的认识它不是什么宏大叙事就是一个个具体工作习惯的组合。6.3 第二个90天让Review产出变成团队资产第一个90天主要是个人习惯调整第二个阶段就要考虑沉淀和扩散了。我的建议是挑几件可复用的事情做下去把重复出现的高频问题转成自动化检查规则把设计说明模板分享给团队里的其他同事把容易出错的模块做成文档注明“改这里之前先读这几条背景知识”。你Review里积累下来的判断不应该只停留在邮件和评论里。这一步的意义在于你终于把Review从“每天消耗时间的负担”变成了“越来越聪明的约束系统”。哪怕以后换了项目、换了团队这套方法还是会跟你走因为它在任何代码库都能重新长出来。这也是我想强调的“主动进化”的最终形态不是某次升级、某个工具而是一套不断把个人判断变成可复用资产的工作方式。对我个人来说最舒服的状态不是躺平让AI写也不是硬扛着全部手写而是把Review当成一种真正的创造性工作。每一条有依据的评审意见、每一份清晰的设计说明、每一个沉淀下来的自动化检查项都是我们在庞大代码库里留下的路标。AI时代里工作比例的怎么变也许我们无法完全左右但手里有没有把这些路标越画越清晰是我们自己可以决定的。