前阵子跟一个做后端的朋友吃饭他随口说了句“现在我们组新写的 Python 代码大概四分之三是 AI 先出草稿我只负责改。”我当时没太当回事回来翻了翻自己近半年的提交记录发现比例也差不多。这事儿细想起来挺有意思的——不是“AI 会不会取代程序员”这种老掉牙的讨论而是 Python 这门语言本身的使用方式正在被悄悄改写。一、先说说这个 75% 到底意味着什么很多人看到“75% 代码由 AI 生成”第一反应是那程序员是不是快没活干了其实恰恰相反。我观察到的真实情况是AI 承担的是那些结构清晰、模式固定、重复度高的部分比如数据清洗、接口封装、日志埋点、单元测试骨架。而人负责的是判断“该不该这么写”“这样写会不会埋坑”。举个最典型的例子。以前写一个 CSV 读取加清洗的函数我得先想好异常处理、编码问题、空值策略敲个二三十行。现在我会直接描述需求让 AI 出第一版然后重点看它有没有漏掉边界情况。import pandas as pd def load_user_data(path: str) - pd.DataFrame: 读取用户数据做基础清洗 df pd.read_csv(path, encodingutf-8) # AI 初版通常只写到这里下面这些才是人该补的 df.columns [c.strip().lower() for c in df.columns] df df.drop_duplicates(subset[user_id]) df[age] pd.to_numeric(df[age], errorscoerce) return df你看AI 给的那两行没错但真正决定这段代码能不能上生产的是后面那几行。所以 75% 这个数字说的是敲键盘的工作量不是思考的工作量。二、Python 为什么成了这场变化的主战场我琢磨了一下Python 被 AI 冲击得最明显不是偶然。第一它的语法容错率高。Python 接近自然语言的表达方式让 AI 生成的代码可读性强人一眼就能看出哪里不对。换成 C 那种模板满天飞的代码AI 写出来你还得花半天读。第二生态太成熟。requests、pandas、numpy 这些库的用法在网上有海量样本模型早就学透了。你让它写个 HTTP 请求它闭着眼都能写对。第三Python 大量用于“胶水”场景。脚本、爬虫、数据处理、自动化运维——这些活儿本身就是“拼装”性质天然适合 AI 介入。说白了越是“套路化”的语言和场景AI 的边际收益越高。Python 恰好两头都占了。三、被改写的三条“潜规则”1. 从“会写”到“会审”以前面试 Python 岗常考你手写一个装饰器、手写一个生成器。现在这类题的意义在下降因为 AI 三秒就能写出来。真正拉开差距的是你能不能一眼看出 AI 写的装饰器有没有处理好functools.wraps有没有在异常时正确传递上下文。import functools import time def timer(func): functools.wraps(func) # AI 有时会漏掉这一行 def wrapper(*args, **kwargs): start time.perf_counter() try: return func(*args, **kwargs) finally: cost time.perf_counter() - start print(f{func.__name__} 耗时 {cost:.4f}s) return wrapper这段代码 AI 大概率能写对但它不一定知道为什么要加functools.wraps。而知道为什么的人才是不可替代的。2. 代码评审的重心变了过去 review 代码重点在风格、命名、有没有重复逻辑。现在这些 AI 基本能保证review 的重心转向了业务语义正确性和安全边界。比如 AI 生成的 SQL 拼接你有没有检查过注入风险AI 写的文件操作路径有没有做校验3. 文档和注释反而更重要了这点挺反直觉的。AI 越能写代码人写的注释就越值钱——因为注释是你给 AI 的“需求说明书”。我现在写函数习惯先把 docstring 写清楚再让 AI 补实现效果比直接口述需求好得多。四、一个我自己的实践小例子上周要做一个批量重命名脚本需求是把目录下所有图片按拍摄时间重命名遇到重名加后缀。我先把规则写成注释AI 出了初版然后我补了两处它没想到的EXIF 缺失时的兜底、以及跨平台路径分隔符处理。from pathlib import Path from datetime import datetime import shutil def rename_by_time(folder: str) - None: base Path(folder) for img in base.glob(*.*): if img.suffix.lower() not in {.jpg, .png, .jpeg}: continue # EXIF 读不到时用文件修改时间兜底 ts datetime.fromtimestamp(img.stat().st_mtime) new_name ts.strftime(%Y%m%d_%H%M%S) img.suffix.lower() target base / new_name idx 1 while target.exists(): target base / f{ts.strftime(%Y%m%d_%H%M%S)}_{idx}{img.suffix.lower()} idx 1 shutil.move(str(img), str(target))整个过程大概十分钟其中八分钟在想边界情况两分钟在等 AI 输出。这个时间分配的变化可能就是未来 Python 开发的常态。五、写在最后75% 这个数字不必神化也不必恐慌。它反映的不是“人要被替代”而是人的价值正在从“产出代码”迁移到“定义问题”。Python 因为门槛低、生态好、场景广最先感受到了这股变化但它不会是唯一一个。对还在写 Python 的人来说我的建议很朴素别抗拒用 AI 出草稿但一定要练出“一眼看出问题”的本事。工具越强判断力越贵。这句话放在哪个语言上都成立。