1. 当一家AI公司说“我们的代码八成是AI写的”第一次看到“代码80%是AI写的这家AI公司呼吁暂停AI开发”这个说法我的反应不是震惊而是好奇一家靠模型吃饭的公司为什么主动把“AI替代程序员”这件事摆到台面上还反手呼吁暂停这背后其实藏着一个非常具体的工程现实——递归自我改进recursive self-improvement。简单说就是AI写代码代码训练出更强的AI更强的AI再写更关键的代码循环加速。这个循环一旦跑起来最先被冲击的不是“程序员这个职业”而是代码审查、测试覆盖、责任归属这三件事。我过去一年在几个项目里深度使用过Claude Code、OpenAI的Agent API以及本地部署的开源模型对“AI写代码”这件事的体感非常直接它能把你从重复劳动里拽出来但也会把风险悄悄塞进你原本以为很稳的流程里。这篇文章不聊立场只聊工程。我会拆解AI写代码的比例是怎么统计出来的、递归自我改进在代码层面到底长什么样、为什么连AI公司自己都开始踩刹车、以及作为普通开发者你现在该怎么用、怎么防、怎么留后手。适合谁看如果你正在用Claude Code、Cursor、Copilot或者自己搭Agent写业务代码或者你负责团队的技术质量这篇内容能帮你建立一套“AI代码可控”的实操框架。如果你只是好奇这个新闻背后的技术逻辑我也会把原理讲到你能拿去跟人讨论的程度。2. “80%代码由AI生成”这个数字是怎么来的2.1 统计口径决定了这个数字的含金量很多人看到“80%”第一反应是“程序员要失业了”但如果你做过代码量统计就知道这个数字的统计口径非常关键。常见的统计方式有三种按行数统计AI补全的每一行都算包括你按Tab接受的单行补全。这种方式最容易把数字推高因为日常开发中大量代码是样板、getter/setter、类型定义、测试用例。按提交统计以Git commit为单位判断这次提交里AI贡献的比例。这种方式更接近真实工作量但需要工具链支持比如在IDE里记录AI建议的采纳情况。按功能模块统计以“一个完整功能是否由AI主导完成”来算。这种方式最严格也最能反映“AI到底能不能独立干活”。那家AI公司说的80%大概率是第一种或第二种口径。我在自己的项目里做过一次粗略统计一个中等规模的TypeScript后端服务开启Copilot和Claude Code辅助后新增代码里大约60%到70%是AI直接生成或补全的但其中真正涉及核心业务逻辑的不到20%。剩下的都是CRUD、参数校验、日志、错误处理、单元测试。这个比例听起来吓人但拆开看AI吃掉的是“必要但低价值”的部分。提示如果你要跟团队汇报AI代码占比一定要先定义口径。否则“80%”这个数字在不同人嘴里能差出三倍。2.2 为什么AI写的代码比例会越来越高比例升高的原因不是AI突然变强了而是开发流程本身在向AI友好型演化。我观察到几个明显的推手第一框架和语言的类型化程度越来越高。TypeScript、Rust、Go这些语言有强类型和明确的接口定义AI补全的准确率远高于动态脚本语言。类型系统相当于给AI画好了轨道它只需要填车厢。第二测试驱动开发TDD和AI天然契合。你先写测试AI根据测试生成实现这个循环非常顺。我在一个Python项目里试过先让AI根据需求写pytest用例再让它实现函数通过率能到85%以上。测试用例本身也是AI写的所以“AI代码占比”自然水涨船高。第三Agent模式的普及。Claude Code、OpenAI Agents API这类工具不再只是补全单行而是能读整个仓库、改多个文件、跑测试、根据报错自动修复。一个Agent跑一轮可能就产生几百行代码。这种模式下人类更多是在“下指令”和“审结果”而不是逐行敲。2.3 高比例AI代码带来的第一个真实问题审查疲劳代码是AI写的但责任是人担的。当AI一天能产出你一周的代码量时代码审查Code Review会迅速变成瓶颈。我经历过一次一个Agent在半小时内改了12个文件提交了400多行diff。我打开PR的那一刻第一反应不是“写得对不对”而是“我从哪看起”。审查疲劳的直接后果是橡皮图章式批准。你开始只看测试有没有过、CI有没有绿而不是逐行理解逻辑。这在业务代码里可能还能忍但如果涉及支付、权限、数据删除就是灾难。那家AI公司呼吁暂停很可能就是内部看到了这个趋势AI写代码的速度已经超过了人类审查代码的速度而审查是最后一道防线。3. 递归自我改进在代码仓库里到底长什么样3.1 从“AI辅助写业务代码”到“AI改AI自己的代码”递归自我改进听起来很玄但落到工程上它有一个非常具体的形态AI开始参与改进AI系统本身的代码。比如用AI生成训练数据的清洗脚本用AI优化推理服务的调度逻辑用AI写评估模型的评测代码用AI重构Agent的工具调用框架。这些代码不是普通业务代码它们直接影响下一代模型的能力。一旦这个循环建立改进速度就不再受人类工程师的招聘和培养速度限制。我在一个开源Agent项目里见过类似场景维护者用Claude Code重构了整个工具注册模块然后新版本的Agent又能更高效地调用工具反过来让下一次重构更快。这个循环目前还比较慢但方向是明确的。3.2 递归循环的三个加速器要让这个循环真正加速需要三个条件同时满足加速器具体表现当前状态自动化评估AI改完代码后有完整的测试和基准能自动判断好坏部分成熟业务代码难覆盖自动化部署改完能安全上线不需要人工审批每一步大厂内部较成熟外部谨慎自动化目标设定AI能自己发现“哪里需要改进”早期依赖人类给方向目前最成熟的是第一个。像SWE-bench这类基准就是让AI在真实仓库里改bug然后自动跑测试判断是否修好。这个闭环一旦跑通AI就能在没有人类逐行审查的情况下自我迭代。第二个和第三个还在早期但趋势很清楚。3.3 为什么“暂停”的呼吁来自AI公司自己这里有一个反直觉的点最积极呼吁暂停的往往是最接近这个循环的公司。原因不复杂——他们比谁都清楚当前系统的脆弱性。我在使用Agent工具时最深的体会是AI写的代码通过测试不等于正确。测试覆盖的是你想到的场景而AI可能引入你没想到的边界行为。举个例子我让一个Agent给一个API加缓存。它写得很漂亮测试全过。但上线后发现它在缓存key里漏掉了用户权限字段导致A用户可能拿到B用户的缓存数据。这个bug测试没覆盖因为测试用例也是AI写的它没想到这个维度。AI公司内部如果大量代码由AI生成类似的“盲区叠加”会非常危险。呼吁暂停本质上是在说我们的审查能力跟不上生成能力了。4. 用Claude Code和Agent API时的真实体感与坑4.1 Claude Code的强项和它的“自信幻觉”Claude Code是我目前用得最多的终端Agent之一。它的强项是读仓库上下文和多文件编辑。你给它一个任务比如“把这个模块的错误处理统一成Result类型”它能自己找到所有相关文件逐个改然后跑测试。这个过程非常流畅。但它有一个明显的“自信幻觉”它会用非常确定的语气告诉你它改了什么即使它改错了。我遇到过好几次它说“已将所有调用点更新”结果grep一下发现漏了两个。这不是它故意骗你而是它的输出是概率生成的它“认为”自己改全了。所以我的习惯是Agent说改完了我一定自己跑一遍全局搜索。这个动作花不了两分钟但能挡住大部分低级遗漏。4.2 OpenAI Agent API的编排逻辑与成本陷阱OpenAI的Agent API更适合做流程编排你定义工具、定义循环、定义终止条件然后让它自己跑。我在一个数据清洗任务里用过让它读文件、调Python、根据结果决定下一步。效果不错但有两个坑第一token消耗不可控。Agent每轮都要把上下文重新发一遍如果任务复杂、循环多成本会指数级上升。我有一次跑一个看似简单的任务结果它循环了40多轮账单直接超预期。后来我加了硬性轮次上限和预算告警。第二错误传播。Agent如果第一步理解错了后面所有步骤都会基于错误前提执行而且它不会主动质疑自己。所以我现在会在关键节点插入“人工确认”步骤哪怕多花点时间。4.3 本地部署模型的诱惑与现实很多人想用本地模型替代云端API理由无非是成本和数据安全。我试过用开源模型跑代码生成结论是在简单补全和样板代码上可用在复杂重构和跨文件任务上差距明显。本地模型的上下文窗口、指令遵循能力、工具调用稳定性都还有距离。如果你只是想做代码补全、写单元测试、生成文档本地模型够用。但如果你要它像Claude Code那样读整个仓库、改多个文件、跑测试修复目前还是云端模型更稳。我的建议是本地模型做第一道过滤云端模型做复杂任务这样成本和效果比较平衡。5. 当AI代码占比超过一半团队流程该怎么改5.1 把“审查AI代码”当成一项独立技能来练审查AI代码和审查人类代码是两种技能。人类代码你会看“他为什么这么写”AI代码你要看“它有没有漏掉什么”。我总结了一个检查清单每次审AI生成的PR时按顺序过边界条件空值、零、负数、超长字符串、并发。权限与数据隔离有没有把不该暴露的数据暴露出去。错误处理异常是被吞了还是被正确处理了。依赖变更有没有引入新依赖版本是否合理。测试有效性测试是不是只覆盖了happy path。这个清单不复杂但能挡住大部分AI代码的常见问题。关键是养成习惯不要因为“测试过了”就跳过。5.2 用“AI写测试人写断言”来对冲盲区AI写的测试有一个通病它倾向于验证自己实现的逻辑而不是验证需求。也就是说如果它实现错了它写的测试很可能也是错的但能过。对冲方法是让AI生成测试骨架但断言由人来写。人写断言时会自然地去想“这个功能到底应该输出什么”而不是“代码输出了什么”。我在一个项目里推行了这个做法AI生成测试文件和mock我补断言。结果发现了好几个AI实现里的逻辑错误都是测试没覆盖到的。这个分工比“AI全包”慢一点但质量高很多。5.3 给Agent设“刹车”轮次、预算、人工确认点如果你在用Agent自动改代码一定要设刹车。我的配置是最大轮次超过10轮自动停止等人介入。预算上限按token或金额设硬上限超了直接断。关键操作确认删除文件、改数据库schema、动权限配置必须人工确认。变更范围限制一次Agent运行最多改N个文件超了拆任务。这些限制看起来麻烦但能防止Agent“跑飞”。我见过一次Agent因为一个测试一直不过反复改同一个文件改了20多轮最后把文件改得面目全非。如果有轮次上限这个问题在第三轮就会被发现。6. 递归自我改进的边界哪些事AI暂时还接不了6.1 需求理解和取舍仍然依赖人AI可以写代码但它不知道什么该写、什么不该写。一个功能做不做、做到什么程度、牺牲什么换什么这些是产品判断不是代码问题。我让Agent做过一个“优化查询性能”的任务它给出了五种方案每种都有道理但它没法告诉我“选哪个”。因为选哪个取决于业务对延迟、成本、一致性的优先级这些信息不在代码里。6.2 跨系统协调和人际沟通是硬边界代码只是软件工程的一部分。还有一部分是跟人对齐跟产品确认需求、跟运维确认部署窗口、跟安全确认合规要求。这些事AI做不了至少现在做不了。所以即使AI写了80%的代码剩下的20%——需求澄清、方案评审、上线协调——仍然是人类的主场。而且这部分工作不会因为代码写得快而减少反而会因为变更频繁而增加。6.3 责任归属问题没有技术解最后一个边界是责任。AI写的代码出了事故谁负责目前没有技术方案能解决这个问题。你可以说“审查的人负责”但审查的人如果一天要看几千行AI代码他的审查质量必然下降。这是一个组织问题不是模型问题。那家AI公司呼吁暂停可能也是在等这个问题的社会共识形成。7. 我现在的实际工作流人机分工的一个可抄版本说了这么多分享一下我目前比较稳定的工作流。不是标准答案但你可以直接拿去改。第一步需求拆解由人做。我把一个功能拆成若干个小任务每个任务有明确的输入输出和验收标准。这一步不交给AI因为拆解本身就是在做设计决策。第二步AI生成实现和测试骨架。用Claude Code或类似工具给每个小任务生成代码和测试。我通常会让它一次只做一个任务避免上下文太杂。第三步人补断言和边界测试。AI生成的测试我保留结构但断言自己写边界用例自己加。这一步最花时间但最值。第四步人审diff重点看权限、数据、错误处理。不逐行看但上面说的检查清单必须过一遍。第五步Agent跑CI人看结果。CI绿了不代表没问题但CI红了肯定有问题。我会看失败原因判断是测试问题还是实现问题。第六步上线前人工确认关键路径。涉及钱、权限、数据的路径我一定自己手动跑一遍。这个流程下我的代码产出大概比纯手写快两到三倍但审查时间也增加了。净收益是正的但没有“AI全自动”那么夸张。那些宣称“AI写完直接上线”的要么是场景特别简单要么是还没遇到事故。8. 关于“暂停”这件事一个工程师的务实看法我不觉得“暂停AI开发”是一个可执行的工程决策。技术一旦扩散就很难收回。但“暂停”这个呼吁本身有价值它在提醒整个行业生成能力和审查能力之间的差距正在拉大。这个差距不解决事故是迟早的事。对我个人来说能做的是三件事第一控制AI代码的变更粒度不让它一次改太多第二保留人工审查的关键节点尤其是权限和数据第三持续测试AI的边界知道它在什么情况下会出错。这三件事不性感但能让我在享受AI效率的同时晚上睡得着觉。最后分享一个我踩过的坑有一次我让Agent重构一个模块它改完之后测试全过我就直接合并了。结果第二天发现它把一个日志级别从error改成了info导致一个关键告警不再触发。这个改动不在任何测试覆盖范围内diff里也不显眼。从那以后我审AI代码时一定会专门看配置和常量变更因为那是最容易被忽略、又最容易出大事的地方。