Anthropic 80%代码由AI写？拆解递归自我改进真相与程序员应对

你看到“Anthropic 80% 代码是 AI 写的”这种消息的时候第一反应是什么我身边不少人的反应分成两派一派觉得程序员快没了另一派觉得这只是PR噱头。作为一个从 Copilot 时代就开始用 AI 补代码、最近半年几乎把 Claude 和 Cursor 用成日常主力工具的人我的第一反应其实是另一个问题——这句话里的“AI 写的”到底是怎么定义的以及那个更唬人的词“递归自我改进”Anthropic 真的已经做到了吗这个话题值得拆开聊。它牵涉到代码生产方式的真实变化、AI Agent 当前的能力边界以及我们这些靠写代码吃饭的人该怎么调整自己的位置。我不打算堆概念就按我自己的观察和实操经验把这几年看到的、亲手用过的、踩过坑的东西整理一遍。1. 先拆解Anthropic 那个 80% 的数字是怎么来的1.1 原话与语境不是“AI 自己写”而是“AI 深度参与”先说消息源头。Anthropic 的 CEO Dario Amodei 在一次访谈里提到公司内部大部分代码是由 Claude 生成的不同转录稿里数字有些出入有的说“约 90%”有的媒体标题写成“80%”。不管哪个数量级本身已经足够说明问题一家全球头部 AI 公司把自家模型用进了日常研发流程而且不是实验室玩具级别是真正在生产代码里跑。但这里有个很容易被忽略的点他说的是“由 Claude 生成”这并不等于“Claude 自己决定写什么”。真实的开发过程是工程师把任务拆好、把接口定好、把上下文喂给 Claude再由 Claude 生成大量代码工程师做 review、改 bug、调逻辑。也就是说AI 是那个写得很快的“手”但“脑”仍然长在人身上。就好比盖房子。80% 的砖头是机器臂搬的甚至砌墙也是机器臂按图纸砌的但图纸是人画的地基要不要加深、承重墙放哪个位置这些决定还是人来拍板。你不能因为砖头都是机器臂放的就说房子是机器臂自己设计的。1.2 拆开看80% 到底指什么如果去深究统计口径“AI 写的代码占比”其实有几种完全不同的算法。第一种是按代码行数 diff 来算。一次 PR 里AI 生成的代码占了多少行这可能是最常用的口径。第二种是按 PR 数量来算一个功能模块如果大部分代码是 AI 生成、人只做修改和审查整个 PR 都可以算作“AI 辅助完成”。第三种是只看主体逻辑把注释、样板代码、测试代码这些“水分”剔除掉只统计核心业务逻辑中 AI 的贡献比例。三种口径算出来的数会差很多。样板代码和单元测试恰恰是 AI 最擅长的领域如果把这些都算进去比例轻松超过 80%但如果只看核心架构和复杂业务逻辑比例会明显下降。我自己在团队里做过一次粗略统计用一个内部工具项目做实验把所有 git diff 按来源标记最后发现 AI 生成的代码行数确实能到 70% 左右但其中一半以上是 CRUD 接口、数据校验、单元测试、配置文件这些“体力活”。真正需要设计思考和业务理解的代码AI 的贡献率大概只有三成。所以 Anthropic 内部能到 80%我相信是真实的但那个数字里的“含金量”和外界想象的不太一样。1.3 为什么这个数据值得信也值得打个问号往深一层说Anthropic 自己就是卖 AI 工具的他们公布这样的数据客观上就是产品的最大广告。但我不觉得这是在吹牛因为 Claude 写代码的能力确实已经强到了可以深度介入生产的程度尤其在 Ananthropic 这种 AI 公司里工程师本来就是对 AI 工具接受度最高的一群人内部工具链也天然适配模型生成代码。但我也会打个问号一家 AI 公司里跑着大量 AI 生成的代码这算是“最前沿的实践”还是“最激进的内测”对大多数普通团队来说直接照搬这个比例是有风险的。他们的工程师人均对模型边界有极深的理解知道哪些 prompt 能压榨出好结果也知道哪些输出要立刻丢掉。换成普通团队同样的工具效果可能会打对折。2. “递归自我改进”被严重误读了2.1 教科书里的递归自我改进长什么样“递归自我改进”是个学术味道很重的词英文是 recursive self-improvement。它指的是一种循环一个 AI 系统能够改进自身改进之后的系统能力更强于是又能进一步改进自己如此往复形成越来越快的上升螺旋。这个概念的极端形态叫“智能爆炸”在很多 AI 安全讨论里都被当成一个需要严肃对待的阈值事件。关键点是这个循环里AI 是主体人是旁观者。系统自己发现自己哪里弱自己改算法、改模型、改训练方式然后自己验证改完是否真的变强了。注意这里说的是“改自己”不是“帮人写代码”。写代码只是在构建软件系统而递归自我改进要求的是 AI 去修改那个产生智能的系统本身。举个类比。一个人如果会用计算器不算“变得更聪明”如果他设计了一个更好的计算器然后用这个更好的计算器去计算怎么设计再下一代的更好计算器这才算进入了递归改进的通道。现在的 AI 写代码本质上还是在“用计算器”而不是在“设计下一代的自己”。2.2 AI 辅助编码离“自举”还有多远Anthropic 用 Claude 写代码其中也包括写 Anthropic 自己的训练和基础设施代码。这个事实让很多人觉得“AI 在写 AI 自己”看起来已经很接近自举了。但从工程视角看这中间仍然隔着一道深沟。真正的自举场景应该是这样的Claude 接收到一个高层级目标比如“降低下一代模型的推理延迟”然后它自己去设计新的算子、重写推理引擎、决定训练策略、跑实验、分析结果、再迭代。现在这个链条的每一环拆开看都有人在指挥工程师定义问题空间工程师评估结果工程师决定下一步方向。我见过最接近“自我改进”的场景是让 Agent 自动跑测试、根据报错修代码。它能在一个极窄的闭环里循环改代码 → 跑测试 → 看失败信息 → 再改。但一旦问题超出这个闭环比如需要重新设计表结构、需要换一种算法思路Agent 就会开始原地打转。因为它没有能力定义“更好的方案”到底是什么这个判断标准还是人给的。2.3 我为什么反对把“AI 写代码”翻译成“AI 自我进化”说白了“AI 写代码”和“AI 自我进化”之间差着一整个研究的距离。媒体喜欢用后者因为“AI 自己写自己”听起来比“AI 辅助工程师写代码”有传播力得多。但作为从业者如果我们也把这两个概念混着用会严重影响对技术现状的判断。我自己的看法是Anthropic 的 80% 是一个非常强烈的信号但它说明的是“AI 作为编程工具已经成熟到可以大规模应用”而不是“递归自我改进已经发生”。前者是生产效率问题后者是智能本质问题。把两者混为一谈要么会让人过度恐慌要么会让人对 AI 能力产生不切实际的期待。3. 我实际跑通的 AI 写代码工作流什么能扛什么不能扛3.1 一个最小闭环从需求到测试的 AI 辅助开发我自己过去半年最常用的工作流不是让 AI 一句话生成整个项目而是把它嵌进一个比较严格的流程里。每个需求先写成清晰的 issue包含背景、接口约定、验收标准、已知约束。然后让 AI 先列实现计划再逐文件生成代码。我逐段 review重点看并发、异常处理、边界条件、安全性跑完测试再把红色测试和堆栈信息贴回给 AI让它认领问题并修复最后我再人工过一遍可读性和一致性。这种流程跑顺之后效率提升非常明显。以前一个中等复杂度的后端接口从建表到写 CRUD、写单元测试、补接口文档可能要花大半天现在 AI 在几分钟内就能生成初版剩下时间全部花在 review 和修 bug 上。这其实就是 Anthropic 内部那个 80% 的日常版本只是规模小很多。这个工作流里最关键的一步是“需求拆解”。AI 不需要你告诉它“写一个用户管理模块”它需要的是“用户表有这些字段注册流程要校验手机号密码用 bcrypt接口返回结构是……”描述得越具体AI 生成的代码越能用。很多抱怨 AI 代码不能用的人问题往往出在需求描述太模糊AI 只能猜猜就必然错。3.2 一个代码例子AI 写出来的初版和我让它改的版本我拿一个实际例子说明。有一次我需要写一个脚本从日志文件里统计每个接口的平均响应时间按平均耗时倒序输出。第一个版本是 AI 直接生成的初版长这样import re from collections import defaultdict def parse_log(log_path: str) - dict: result {} endpoint_times defaultdict(list) pattern re.compile(r(\S) (\d)ms) with open(log_path, r, encodingutf-8) as f: for line in f: match pattern.search(line) if match: endpoint match.group(1) duration int(match.group(2)) endpoint_times[endpoint].append(duration) for endpoint, times in endpoint_times.items(): result[endpoint] { count: len(times), avg_ms: sum(times) / len(times) } return result def format_report(data: dict) - str: lines [] for endpoint, info in sorted( data.items(), keylambda item: item[1][avg_ms], reverseTrue ): lines.append( f{endpoint} avg{info[avg_ms]:.1f}ms count{info[count]} ) return \n.join(lines) if __name__ __main__: data parse_log(access.log) print(format_report(data))第一眼看上去代码整洁、结构也清楚但如果真拿去跑生产日志问题马上就来了。\S这个正则太贪婪会把一行的开头到接口路径全部吞掉日志里如果混入非标准格式的行int(match.group(2))直接抛异常文件不存在时也只是裸抛FileNotFoundError缺少友好的错误提示5xx 超时的请求也没有单独处理。我把这些问题写成 review 意见贴回给 AI让它按意见修改。第二版明显扎实很多import re from collections import defaultdict from pathlib import Path LOG_PATTERN re.compile( r^(?Pip\S) .*? (?:GET|POST|PUT|DELETE) (?Ppath\S) HTTP/[\d.] r(?Pstatus\d{3}) (?Pms\d)ms ) def parse_log(log_path: str) - dict: path Path(log_path) if not path.exists(): raise FileNotFoundError(flog not found: {log_path}) records defaultdict(list) with path.open(r, encodingutf-8) as f: for line in f: match LOG_PATTERN.search(line) if not match: continue status int(match.group(status)) if 500 status 600: continue try: ms int(match.group(ms)) except ValueError: continue records[match.group(path)].append(ms) return { endpoint: { count: len(times), avg_ms: round(sum(times) / len(times), 1) } for endpoint, times in records.items() }这个例子特别能说明问题AI 确实能写出初版代码但判断“哪里不够好”的能力仍然掌握在人的手里。如果没有我的反馈第一版就会带着正则错误和异常隐患直接进生产。3.3 AI 翻车的两个常见现场第一类翻车是“一本正经编 API”。AI 会基于训练数据里的印象自信地写出某个库根本不存在的方法或参数。有一次我让 Claude 用某个比较少见的 SDK 写一段调用代码跑起来直接 AttributeError我去查官方文档才发现根本没有这个方法。语言模型优化的是“看起来合理”的代码序列不是“真实存在”的代码序列这在冷门库和文档不全的框架里尤其明显。第二类翻车是“安慰剂式测试”。AI 生成的单元测试经常只覆盖正常路径断言也写得很宽松比如只检查返回值不为空不检查具体值是否正确。当年我让 AI 给一个金额计算函数写测试它写了 5 个用例全部通过但我手动检查时发现它把一个错得离谱的边界条件直接写进了预期结果里。测试全绿恰恰因为它把 bug 抄进了断言。这不是模型笨而是模型在补全“看起来规范的测试代码”而不是在验证业务逻辑。3.4 让 AI 写好代码的 Prompt 要点给足上下文。项目结构、依赖版本、相关文件的内容都要贴进去AI 最怕的是在一个空环境里猜你的业务。先给方案再给代码。让 AI 先说明准备怎么实现列出文件清单和接口签名确认思路后再生成代码比让它直接开写靠谱得多。明确约束。要求“不要引入新的第三方依赖”“不允许大循环里调外部接口”“所有外部输入都要校验”这些约束能拦掉很多坑。让它解释关键设计。生成完代码后让 AI 说明为什么这么写复杂度是多少可以在 review 时快速抓住它的设计意图。4. 程序员的价值正在从“写代码”变成“审代码”4.1 初级工程师的处境被加速也被放大风险90% 到 80% 这种事情一旦成为常态最先被冲垮的其实是初级工程师的成长路径。以前新人进团队通过一行一行写业务代码来积累手感这个过程虽然慢但能让人理解系统是怎么长出来的。现在新人的日常变成了“看 AI 怎么写、觉得没毛病就合进去”。问题是新手恰恰是最没有能力判断 AI 代码对不对的人。我在团队里就观察到一个很有趣的现象同样用 AI 辅助开发老手和新手产出的代码质量差距非常大。老手知道哪类代码适合交给 AI哪类必须自己写新手则是无差别信任输出出了问题再去翻文档。AI 成了一个放大器它把老手的经验放大成效率也把新手的判断力不足放大成线上事故。4.2 新团队分工架构师定边界工程师做验收代码生产工具的变革最终会重塑团队分工。以前一个功能从设计到落地主要瓶颈是“写代码的时间”现在写代码的时间被压缩到很短瓶颈转移到了“设计决策”和“质量验收”。这意味着架构师的角色会更重。AI 生成代码像积木它能快速产出大量模块但模块之间怎么切分、数据流怎么走、依赖怎么控制仍然需要人来做架构层面的决策。而普通工程师的核心能力也在从“熟练写代码”变成“准确地评审代码”——你要能看出来 AI 生成的 try/except 会不会吞异常要能识别出某段排序算法在超大数据量下会不会超时要能判断某个字段没有唯一索引会不会在并发场景下产生脏数据。4.3 一份可以直接抄走的 AI 代码评审清单错误处理异常被捕获后是真处理了还是静默吞掉生产环境里最怕“日志里什么都没有用户却报告功能异常”。边界条件空列表、空字符串、超大数值、并发请求、超时响应这些输入 AI 生成的代码往往考虑不周。安全与权限有没有 SQL 拼接、路径拼接、越权访问、敏感信息打印依赖引入这个新依赖真的需要吗AI 特别喜欢为了一个小功能引入一个重型库。性能陷阱循环里有没有调用外部接口N1 查询大对象有没有被反复复制可测试性测试断言是否真的在验证核心行为还是只检查了“能跑”可读性与可维护性命名是否表达了业务含义AI 生成的注释经常是废话或者更糟是误导。这份清单我整理成了一张卡片贴在自己屏幕上每次 review AI 代码就逐项过一遍。有了它之后我合入的 AI 生成代码出问题的概率明显下降。5. 递归自我改进真正落地还缺什么5.1 目前 Agent 能做到的“自我修复”边界我觉得目前最能接近“自我改进”的工程实践是 Agent 自动修复代码。我自己写过一个很小的循环实验启动一个子进程跑测试如果失败就把失败输出丢给模型让它生成补丁重新跑最多迭代五次。这个循环跑出来的结果很有意思对于类型错误、缺失导入、简单的断言错误Agent 修复成功率非常高一但问题出在跨模块的设计缺陷比如两个文件之间的接口不匹配Agent 就开始陷入“改了 A 文件、破坏了 B 文件、再改 B 文件、又破坏了 A”的循环。这个实验让我意识到一个关键区别现在的 AI 能做的是闭环内的“参数调整”不是开放式的“系统改进”。它能在人类给定的框架里寻找局部最优但无法自己重新定义问题。真正的递归自我改进要求它能跳出框架这就涉及到它是否有生成全新抽象的能力而不仅仅是模式匹配。5.2 三个硬约束评估器、稳定性、失控风险第一可靠的评估器是最大的缺口。AI 要自我改进首先得能判断“改完是不是更好了”。现实中的系统改进往往没有单一指标性能变好了可能成本变高了速度变快了可能准确性变差了。没有可靠的评估器AI 就是在黑暗里乱撞。第二稳定性和可复现性不够。模型输出本身有随机性同一个改动反复运行可能出现不同结果。这种不确定性放在生产系统里是致命的。自我改进的前提是每一次改进都能被验证、被回滚、被审计而目前的 Agent 架构离这个标准还有距离。第三失控风险和安全护栏。递归自我改进一旦真正跑通改进速度可能是指数级的人类能不能在每一轮迭代里及时介入如果系统目标设置得有一点偏差这个偏差也会被指数级放大。这也是为什么 Anthropic 这类公司把 AI 安全研究放在那么重要的位置——他们比谁都清楚递归改进这辆车的刹车型号还不够可靠。5.3 我的判断这条路还差临门一脚回到标题那个问题递归自我改进走到哪了我的判断是工具层面的“局部自修复”已经开始系统层面的“自我改进”还没有发生。Anthropic 的 80% 是一个了不起的工程成果但它是“人类用 AI 大量生产代码”而不是“AI 自己在进化”。这两者之间的差距不是靠堆算力和数据就能填平的它需要模型在抽象能力、自我评估能力、长期规划能力上出现质的突破。作为一个每天都在写代码、也在用 AI 写代码的人我其实不太关心那个临界点哪天来。我现在更关心的是团队里有多少人能在 AI 生成的代码面前保持判断力。如果你能让 AI 产出 80% 的代码自己能稳稳接住剩下的 20% 的评审和决策你的价值就比那个 80% 更值钱。最后再分享一个小的个人体会我现在看到一条代码最在意的不是它是不是 AI 写的而是提交它的人有没有真正看懂它。工具会一代比一代强但“判断什么是对的”这件事很长一段时间内仍然得靠人。