AI写代码飞快，但真正值钱的是判断力

上周组里来了个实习生，午饭时跟我吐槽，说他用 AI 十分钟就把一个爬虫脚本跑通了，然后突然有点慌——"那我学 Python 还有什么意义？"我当时没直接回答，而是让他把那段 AI 生成的代码拿给我看。结果不到三十行，里面有三处异常没处理，翻页逻辑在遇到空页时会直接崩，还有一个正则写得过于贪婪，稍微改一下网页结构就全废了。

他愣了几秒，说："原来它只是看起来能跑。"

这大概就是当下很多初级开发者的真实处境：AI 出代码的速度确实快得吓人，但"能跑"和"能上线"之间，隔着一条很宽的沟。这篇文章不打算贩卖焦虑，也不想灌鸡汤，就想聊聊我这两年带人、写代码、用 AI 的真实感受——当写代码这件事本身被加速之后，我们到底该把力气花在哪。

先说结论：AI 替代的是"敲键盘"，不是"做判断"

很多人对 AI 编程的恐惧，本质上是把"写代码"等同于"编程"。但真正做过项目的人都清楚，敲代码在整个开发流程里占的时间其实没那么多。更多时间花在：需求到底要什么、这个方案会不会埋坑、线上出问题怎么快速定位、这段逻辑三个月后别人能不能看懂。

AI 现在很擅长第一层——把自然语言翻译成语法正确的代码。但它不擅长后面几层，因为它不知道你的业务背景，不知道你们团队的历史包袱，也不知道这个接口半夜挂了会影响到哪个客户。

换句话说，AI 是个执行力极强的"手"，但它没有"脑子"去替你承担后果。而职场里真正值钱的，恰恰是愿意并且能够承担后果的那部分能力。

一个真实对比：同样的需求，人和 AI 差在哪

举个特别普通的例子。需求是：读取一个 CSV 文件，按城市统计订单金额，输出前 10 名。

AI 大概率会给你这样的代码：

import pandas as pd

df = pd.read_csv("orders.csv")
result = df.groupby("city")["amount"].sum().sort_values(ascending=False).head(10)
print(result)

干净、简洁、能跑。但如果你真把它放进生产环境，问题马上就来了：文件有几百万行怎么办？金额列里混了空值和字符串怎么办？城市名有"北京市"和"北京"两种写法怎么办？编码是 GBK 不是 UTF-8 怎么办？

一个有点经验的开发者，会把它改成这样：

import pandas as pd

def top_cities(path: str, top_n: int = 10) -> pd.Series:
# 大文件分块读取，避免一次性吃满内存
chunks = pd.read_csv(
path,
encoding="utf-8",
dtype={"amount": "float64"},
chunksize=200_000,
on_bad_lines="skip",
)
total = pd.Series(dtype="float64")
for chunk in chunks:
chunk["city"] = chunk["city"].astype(str).str.strip().str.replace("市$", "", regex=True)
chunk["amount"] = pd.to_numeric(chunk["amount"], errors="coerce").fillna(0)
total = total.add(chunk.groupby("city")["amount"].sum(), fill_value=0)
return total.sort_values(ascending=False).head(top_n)

if __name__ == "__main__":
print(top_cities("orders.csv"))

代码长了不少，但每一行都在回答一个"如果……怎么办"。这些判断，AI 不会主动替你想，因为它不知道你的数据长什么样。而知道数据会长什么样、线上会怎么坏，正是人的价值。

那初级开发者到底该往哪使劲？

我的建议很朴素，就三条，但每一条都需要时间沉淀。

1. 把"能跑"的标准提高到"能扛"

AI 给你的代码，永远当成"草稿"而不是"成品"。拿到之后先问自己几个问题：边界情况覆盖了吗？异常有没有兜底？日志够不够排查问题？性能在数据量放大十倍后还撑得住吗？养成这个习惯，你和只会复制粘贴的人差距会迅速拉开。

2. 补上 AI 最弱的那块：系统设计和调试能力

AI 写单个函数很强，但让它设计一个完整的模块，经常会出现职责混乱、耦合过重的问题。你可以试着做一件事：拿 AI 生成的代码，自己动手重构一遍，把重复逻辑抽出来，把副作用收拢，把命名改清楚。这个过程比单纯写新代码更能长本事。

调试同理。线上报错时，AI 能给你一堆可能原因，但真正定位问题靠的是你看日志、看监控、复现路径的能力。这种能力没法速成，只能靠一次次踩坑积累。

3. 学会"指挥"AI，而不是"依赖"AI

这其实是一项新技能。同样一个需求，会提问的人能让 AI 产出可用度 80% 的代码，不会提问的人只能拿到 30% 的毛坯。关键在于把上下文说清楚：数据规模、运行环境、异常处理要求、团队代码规范。你描述得越像一份需求文档，AI 给的东西就越靠谱。

下面这个小工具，就是我用 AI 辅助写出来的，用来批量检查项目里的 Python 文件是否符合基本规范：

import ast
import sys
from pathlib import Path

def check_file(path: Path) -> list[str]:
issues = []
try:
tree = ast.parse(path.read_text(encoding="utf-8"))
except SyntaxError as e:
return [f"{path}: 语法错误 -> {e}"]

for node in ast.walk(tree):
# 函数过长提醒
if isinstance(node, ast.FunctionDef) and len(node.body) > 50:
issues.append(f"{path}:{node.lineno} 函数 {node.name} 超过 50 行，建议拆分")
# 裸 except 提醒
if isinstance(node, ast.ExceptHandler) and node.type is None:
issues.append(f"{path}:{node.lineno} 使用了裸 except，建议指定异常类型")
return issues

if __name__ == "__main__":
root = Path(sys.argv[1] if len(sys.argv) > 1 else ".")
all_issues = []
for py in root.rglob("*.py"):
all_issues.extend(check_file(py))
print("\\n".join(all_issues) or "检查通过，未发现问题")

这段代码本身不难，难的是想清楚"要检查哪些规则""误报怎么控制""怎么接入 CI"。这些思考，AI 帮不了你，但它能帮你把想法快速变成可运行的原型——这才是正确的使用姿势。

最后说点实在的

我见过太多人把 AI 当成威胁，也见过一些人把它当成外挂，半年时间能力肉眼可见地涨。区别不在于谁更聪明，而在于谁更早想明白一件事：工具越强，使用工具的人的判断力就越值钱。

AI 写 Python 确实比我快，这点我认。但它不知道这个需求背后是哪个客户在催，不知道这段代码半年后谁来维护，也不知道上线出问题时要给谁打电话。这些"不知道"，就是初级开发者现在最该去补的功课。

与其焦虑，不如今天就做一件小事：把 AI 给你的一段代码，认真改到你自己敢拍胸脯说"这个能上线"。改上十次，你就不会再慌了。