看到那句我们公司80%的代码是AI写的所以呼吁暂停AI开发时我第一反应不是惊讶而是想弄清楚这句话里藏着几层意思。作为一个常年在前端、后端和脚本工具之间来回切换的人我太清楚AI写的代码在不同团队嘴里是完全不同的东西有人指的是补全了几个函数名有人指的是整条业务流水线由一个Agent从头搭到尾。这两种情况都被叫作AI写的代码但工程含义差了十万八千里。这篇文章想干三件事把80%AI写代码这个数字拆开看它到底怎么统计、怎么成立分析一个重度依赖AI产出的团队为什么反而会站出来喊停最后落到一线开发者身上讲清楚在这种高AI占比的工程环境里哪些能力反而变得更值钱、哪些坑必须提前堵。不管你是刚学会用补全的新手还是已经在团队里推行Agent工作流的人都能从中找到可以直接抄走的东西。1. 先把代码80%由AI写这句话拆开看1.1 按行数统计和按决策统计是两个世界绝大多数团队说80%的代码是AI写的用的是最省事的口径行数占比。做法通常是给提交打标记比如在 commit message 里加上协作声明再用git log统计带标记提交的增删行数除以总行数。这个口径的问题特别明显——删一行和加一行权重相同格式化重排算一次生成自动生成的类型定义、mock 数据、迁移脚本也全都算进去。你在做代码行统计的时候最好先把这几类文件排除掉否则数字会虚高得离谱。# 粗略统计带 AI 协作标记的提交占总提交的比例 total$(git log --oneline | wc -l) withai$(git log --grepCo-authored-by: ai --oneline | wc -l) echo 总提交 $total含AI协作标记 $withai # 排除自动生成目录后的行数占比 git log --grepCo-authored-by: ai --numstat --prettytformat: \ -- . :(exclude)dist :(exclude)*.lock :(exclude)generated \ | awk {add$1; del$2} END {print AI相关新增, add, 删除, del}而按决策统计是另一回事这段代码的接口签名是谁定的、数据结构是谁选的、错误处理策略是谁拍板的。我的经验是哪怕行数占比到80%真正的架构决策里人工拍板的比例也很难低于50%。所以看到类似数字时先问一句按什么口径算的,比争论数字本身有意义得多。1.2 补齐型生成和从零生成价值权重完全不同同样是AI产出补齐型代码你已经写好函数签名和一半逻辑模型补完分支和从零生成型代码你只给一句需求描述模型吐出整个模块在风险上完全不是一个量级。前者上下文充分、约束清晰出错概率低后者需要模型凭空补齐需求边界而需求边界恰恰是最容易出错的地方。我在实际项目里做过一个粗略的分类给自己看的不追求精确但很有用生成类型典型占比复查成本主要风险补全型函数内补分支、补测试用例约40%低逻辑偏移细微难察觉模板型CRUD、DTO、迁移脚本约25%低字段类型、可空性错配从零生成型整模块、整流程约20%高需求边界缺失、异常路径空白重构型拆函数、改命名、迁框架约15%中隐式行为变化测试若不全就会漏把这张表放在手边你就能明白为什么80%这个数字单独拿出来没有意义。真正值得关注的是从零生成型那20%——它决定了项目的技术债形态。1.3 高比例之所以能成立是因为代码本身高度重复说句可能不太好听的实话一个项目里能被稳定自动生成的代码比例高往往说明这个项目的代码同质化程度也高。标准的增删改查接口、千篇一律的校验逻辑、格式固定的配置文件、模式雷同的单元测试这些东西本来就适合被模板化。AI 只是把手写模板再改名这件事加速了它没有改变这类代码本来就缺乏独创性这个事实。所以当一个团队说他们80%的代码由AI写我听到的潜台词是他们的业务代码里有80%属于模式化部分剩下20%才是真正需要动脑子的地方。这不是贬低恰恰相反能把模式化部分压缩到80%并保持稳定说明团队在抽象、规范、测试上下了功夫。没有这些前置工作AI 生成的东西只会让代码更乱不会让比例更高。2. 一家重度依赖AI的团队为什么反过来喊暂停2.1 实践已经跑到认知前面时最先出问题的是节奏这个现象在工程史上出现过很多次。当一个团队在某个方向上的实践速度远超过整个行业的共识时他们最先感受到的不是优势而是失控感。原因很简单你比别人早半年用上某个能力就意味着你要独自承担它带来的全部副作用而行业里还没有人替你验证过这些副作用。放到AI辅助开发这个场景最直观的失控感来自三件事。第一是代码量的增长速度超过了团队理解代码的速度代码库每天都在变大但没有人能完整说出它的行为边界。第二是评审人员的认知负担急剧上升原本一屏能看完的提交变成三屏评审从判断对不对退化成扫一眼有没有明显问题。第三是事故归因变难出了问题以后翻提交记录发现改动是模型生成的写提示词的人也只记得个大概。这三件事叠加起来足以让一个技术负责人产生要不要先停一停的念头。2.2 快速产出改变的是债务结构不只是债务总量很多人以为AI带来的技术债就是更多烂代码这个理解太浅了。我观察到的情况是债务的类型结构发生了变化。传统技术债里占比最大的是知道该怎么做但没时间做比如知道要补测试、知道要拆函数、知道要加索引但排期不够。这类债务的特点是团队心里有数随时可以排期还。AI 高占比产出带来的债务是另一种没人意识到它存在。模型生成的代码在语法上完美、命名上规范、注释上完整看起来比人写的还整洁但它在某条边界路径上悄悄吞掉了异常或者在一个并发场景下用了一个非线程安全的写法。这种代码不会在评审中被一眼看穿因为它的外表太正常了。等到线上出问题归因成本极高。更麻烦的是这类债务会随着生成量的增加而指数级累积而不是线性累积。每多生成一千行未经验证的代码潜在的问题组合就多一层。当生成速度达到人工复查速度的三四倍时债务的积累速度就超过了偿还能力这时候任何一个负责任的负责人都会想按下暂停键。2.3 暂停更像是对产出节奏的重新定价我不太认同把呼吁暂停理解成反对技术发展。从工程视角看它更像是一种定价行为当某个能力的产出速度远超消化速度时主动放慢产出、把资源投到消化环节是理性的。这跟工厂在产能过剩时主动减产没有本质区别。具体到操作层面这种暂停往往表现为几个动作给AI生成代码设置强制的人工复核门槛、要求从零生成型代码必须配套测试才能合入、把生成速率和测试覆盖率挂钩、在某些高风险模块里暂时禁用自动生成。这些动作看起来是效率的倒退实际上是在给整个系统留出建立反馈机制的时间。这里有个经验值得分享别指望通过加强评审来解决这个问题。评审是被动的、抽样式的它无法覆盖全部增量。真正有效的是把约束前移到生成环节——让模型在生成时就必须满足类型检查、必须通过已有的测试用例、必须遵循项目里的错误处理规范。评审只负责检查那些无法自动化的部分。3. 把AI生成占比稳定做高的几层基础设施3.1 上下文工程决定了生成质量的上限很多人把AI编码的实际效果差归结为模型不够强但我的观察是八成问题出在上下文给得不对。模型看不到项目的错误处理约定它就会用自己的默认写法看不到已有的工具函数它就会重新实现一遍看不到接口的真实返回结构它就会按常见形态猜一个。做上下文工程有几个具体做法都是我这几年踩坑踩出来的维护一份项目规范文件放在仓库根目录写清楚命名约定、错误处理方式、日志格式、禁止使用的写法。很多工具会自动读取这类文件即使不自动读你也可以在提示词里显式引用。给调用示例不给整个文件。想让它写一个符合项目风格的服务方法就在提示里贴两三个已有的同类方法比贴一万字架构说明有效得多。明确列出约束条件比如这个方法不能抛异常失败返回空结果并记录日志、不能用新的第三方依赖、必须兼容已有的分页结构。约束越具体生成的代码越接近可直接合入的状态。把领域术语表准备好。业务里有特殊含义的词最容易让模型误解比如项目里的订单指的是聚合根还是单条记录一个术语理解错整个模块都要返工。3.2 编译、测试、静态检查构成的反馈闭环这是我认为最关键的一层。AI 之所以能在一个项目里把占比做高核心原因不是模型聪明而是这个项目有足够强的自动反馈写完就能编译、跑一下就有测试结果、静态检查立刻指出问题。有了这个闭环模型可以自己迭代你只需要做最后的判断。反过来说一个没有测试、没有类型检查、跑起来要靠手动点页面的项目AI 生成的代码占比永远上不去因为每次生成你都要人工验证一遍成本比手写还高。把闭环搭起来的顺序建议是这样类型系统或强约束的语言特性优先这是最快的反馈编译器能挡掉一大类错误。单元测试尤其是针对纯逻辑函数的测试让模型生成的实现立即有对错信号。静态分析与安全检查把常见模式问题空指针、资源未释放、拼接式查询交给工具。集成测试或契约测试覆盖跨模块的接口约定这是防止本地跑通线上炸的关键。这四层不需要一次做全但顺序别颠倒。跳过类型检查和单元测试直接上集成测试会非常痛苦。3.3 什么交给自动化什么必须攥在自己手里我自己摸索出来的一条线是结构清晰的、可被测试验证的、不涉及跨模块语义判断的工作可以放心交出去涉及数据契约、权限边界、状态机转换的工作必须自己定完框架再让模型填肉。具体分类大概是放心交出去单元测试用例给定接口写测试、数据转换与格式化、配置文件生成、正则表达式、文档与注释、重复度高的适配层代码。定完框架再交出去业务服务方法先定签名、异常策略、事务边界、数据访问层先定查询语义、接口层先定参数校验规则。自己写状态机的状态定义与转换规则、权限模型、跨服务的数据一致性方案、缓存失效策略、任何涉及金额与计量的计算逻辑。最后那一类我不是不信任模型而是这类逻辑一旦出错代价和排查成本都太高用它来省那点时间不划算。3.4 怎么知道自己真的提高了而不是在自我安慰度量这件事很容易自欺欺人。我建议盯住三个指标的组合而不是单看代码生成量指标观察方式健康区间参考生成代码的首次合入率模型产出到最终合入之间的修改幅度改动越小越说明上下文到位缺陷来源分布线上问题中由生成代码引入的比例与生成占比大致相当即为正常评审耗时占比团队花在评审上的时间占总工时比例稳定不持续上升即可如果生成占比在涨但首次合入率在跌、评审耗时在涨那就说明产出速度已经超过消化能力了这时候暂停是有道理的。如果三个指标都稳那继续加码也没什么问题。4. 那80%里真正需要人盯住的位置4.1 边界与错误处理是模型最容易偷懒的地方模型生成的代码有一个非常稳定的特征主路径写得漂亮异常路径写得敷衍。最典型的是把所有异常统一捕获然后打个日志就返回看起来无害实际上把调用方需要的错误信息全丢了。# 模型常见写法异常被吞掉调用方无从判断 def load_config(path): try: with open(path) as f: return json.load(f) except Exception: log.warning(load config failed) return {}这段代码在评审里几乎不会被拦因为它的写法符合很多项目的既有风格。问题在于配置文件不存在和配置格式错误是两种完全不同的故障前者可能用默认值就够后者必须让服务启动失败。正确的做法是把异常分类处理def load_config(path): try: with open(path, encodingutf-8) as f: return json.load(f) except FileNotFoundError: log.info(config file missing, fallback to defaults) return DEFAULT_CONFIG except json.JSONDecodeError as e: # 配置格式错误属于不可恢复问题必须让启动流程感知 raise ConfigError(finvalid config at {path}: {e}) from e我现在的习惯是只要看到生成代码里有裸的except Exception就一律要求改写并追问每种异常对应的业务语义。这个习惯帮我拦下过不少问题。4.2 依赖与接口是幻觉的高发区模型会编造包名、编造方法名、编造字段。这几个幻觉里编造包名最危险因为有些编造出来的包名是真实存在的第三方包只是跟你想用的那个毫无关系装进去就是一个不明来源的依赖。防这类问题的办法不复杂但必须做锁文件必须提交并校验任何新增依赖都要走明确的审批不要让模型随手加包。禁止在生成代码里直接引入未在依赖清单里声明的东西这条写进项目规范文件。接口调用一律以真实的类型定义或接口文档为准把接口签名放进上下文而不是让模型凭印象写。对时间、货币、编码、时区这类容易被默认值坑到的参数要求显式传参不要依赖隐含默认。接口字段的幻觉更难发现因为编译能过、测试可能也过。我的做法是给关键的对外接口写契约测试用一份固定的样例数据跑一遍真实的序列化与反序列化任何字段变动都会立刻暴露。4.3 生成代码的默认安全态是不安全这一点需要单独强调。模型在生成代码时默认目标是让功能跑起来而不是让功能在被攻击时安全。所以它会自然地写出字符串拼接的查询、不校验的路径拼接、把用户输入直接塞进命令、把敏感信息写进日志。这些写法不是恶意而是它的默认倾向。需要盯的高危位置基本固定任何把外部输入拼进查询、路径、命令的地方。权限判断的位置与时机尤其是生成代码里经常忘记在数据层加租户过滤。日志与异常信息里是否带出了敏感字段。反序列化的入口以及对反序列化结果的字段白名单校验。上传、下载、导出这类涉及文件路径与文件类型的功能。我一般的做法是让静态检查工具扫一遍再人工快速过一遍这几类位置。工具能挡掉明显的人工负责判断语义上的越权。4.4 本地能跑不代表并发下能跑生成代码在并发场景下的问题也很有规律循环里发请求、共享可变状态、缓存没有加锁、幂等没有做、重试没有退避。这些问题在小流量下完全看不出来等到有量了才开始出故障。我在评审时会对这几类信号特别敏感循环体里有网络调用、全局变量被多个请求路径写入、生成代码里出现了time.sleep、以及任何没有幂等键的写操作。看到这些我会直接要求改成批处理、加锁或改成幂等设计。5. 假设真的按下暂停键团队该留下什么5.1 值得沉淀的是规则和测试不是聊天记录如果明天整个团队决定放慢速度、回头梳理我建议第一件要做的事不是复盘用了多少AI而是把这几个月积累下来的隐式知识写成可执行的东西。聊天记录和提示词历史价值有限因为它们不可执行、无法自动校验而且高度依赖当时的具体上下文。真正值得沉淀的是三类资产项目规范文件把命名、异常、日志、依赖、安全要求写清楚成为生成时的约束、评审时的依据。测试用例体系尤其是覆盖边界和异常路径的那些它们是把人的判断固化成可重复验证的唯一手段。领域术语与数据契约文档让后来的人和模型不再靠猜理解业务语义。这三样东西的共同特点是它们不依赖任何特定的工具或模型换一套技术栈依然有效。这才是真正的资产。5.2 把判断写进约束里而不是写进记忆里我见过不少团队资深工程师心里清楚哪些写法不能用但这些判断只存在于他的脑子里和评审评论里。等他休假或者换项目同样的错误就会重新出现。AI 高占比产出会把这个问题放大因为生成量大了仅靠人脑记住所有约束根本不现实。解决办法是把约束变成机器能检查的规则类型检查规则、lint 规则、自定义的静态检查脚本、CI 里的门禁条件。每一条你希望反复强调的要求都应该有一个对应的自动检查。这个过程本身也是对自己判断的一次检验——如果你没法把某个要求写成规则很可能是因为你对这个要求本身还没想清楚。5.3 让知识资产的迁移路径尽量短团队规模一变、人员一换工具链往往会跟着变。这时候知识资产能不能低成本迁移直接决定了前期投入是不是白费。我的经验是凡是跟具体工具绑定的东西都要谨慎投入凡是通用的、标准化的东西可以多投入。具体来说用通用格式写的测试标准测试框架、用标准语法写的类型定义、用常见标记语言写的文档迁移成本都低。而那些深度绑定某个特定工作流平台的配置、只在该平台能解析的提示模板迁移成本很高。做沉淀的时候把这条记在心里能省掉很多重复劳动。6. 这件事对一线开发者最实际的三点影响6.1 代码阅读能力重新变成硬通货过去几年写得快是一种优势。现在生成速度快到一定程度以后写反而不稀缺了稀缺的是读懂并判断。你得能在一屏生成代码里迅速识别出异常处理是否合理、边界是否覆盖、依赖是否引入得当。这种能力没法靠刷题获得只能靠大量阅读真实代码来练。我自己现在有一个习惯每周挑一段生成代码逐行读一遍写下我会怎么改以及为什么。不是为了提交纯粹是训练判断力。坚持几个月以后看代码的速度和准度都有明显变化。6.2 需求拆解和追问的成本变成主要成本当写代码的时间被压缩之后项目的主要时间成本转移到了前面把需求拆成模型能正确执行的单元把隐含约束显式写出来把验收标准定义清楚。这一步做不好后面生成的代码越多越麻烦。所以我现在花在写提示词和整理上下文上的时间经常比写代码的时间还多。这不是效率降低而是工作量从敲键盘转移到了想清楚。想清楚这件事没法自动化也没法外包。6.3 与其纠结会不会被替代不如看清自己站在哪一环每次这类新闻出来讨论都会滑向会不会取代。我的看法是把这个问题换成我在整个链条里负责哪一环更实用。这个链条大概是定义问题、拆解需求、设计结构与契约、生成实现、验证与修正、维护与演进。越靠前的环节越依赖判断和人脉、业务理解越靠后的环节越容易被自动化。一个人如果只负责中间某一段的机械劳动压力确实大如果能往前后两端延伸空间反而比过去更大。这不是安慰话是我这几年在项目里亲眼看到的分化。最后分享一个我自己的小做法每次用AI生成一段代码之后我会强迫自己用一句话说出这段代码在什么情况下会出错。如果说不出来就说明我还没真正读懂它这时候不要合入先把它拆开看。这个习惯没什么技术含量但它帮我把很多问题拦在了提交之前比任何工具都管用。