全文摘要：替代「写代码」这个动作已经在发生，替代「程序员」这个职业在可验证数据里还没发生。2023 年的对照实验测到 55.8% 提速，2025 年的对照实验测到 19% 变慢，两个数字都真实。差别不在 AI 行不行，而在任务形状、人的资历和验证成本。本文用一个可运行的任务评分器，把「会不会被替代」拆成四个可打分的维度。
目录
- 先说结论
- 两组互相打脸的数据
- 为什么「感觉快了」和「实测变慢」能同时成立
- 一个任务级模型：可替代性四维
- 一个能跑的替代性评分器
- 症状 → 原因 → 解法对照表
- 就业市场已经给出的答案
- 哪些能力反而升值
1. 先说结论（The Verdict）
结论分两层，而且这两层经常被混为一谈 👀。
第一层，动作层：替代已经发生。 写样板代码、补单元测试骨架、把一段 Python 翻译成 Go、给报错信息找根因------这些动作的边际成本已经被压到接近零。如果你的日常工作是「把明确的需求转成语法正确的代码」，那你被替代的不是职业，是工序。
第二层，职业层：替代没有发生。 2025 年美国劳工统计局（Bureau of Labor Statistics，BLS）的十年预测里，软件开发者的岗位数量预计从 2024 年到 2034 年增长 15.8%，绝对增量约 267,700 个，是所有职业平均增速（约 4%）的近四倍。
同一个市场，一边在砍初级岗，一边在加总岗位。这不是矛盾数据，这是结构在换血。
打个比方 🎭：电梯普及之后，电梯操作员这个工种消失了，但「盖楼」这个行业没有消失，反而盖得更多了。AI 现在扮演的不是「替代建筑工人」的角色，它更像电梯------把某一层工位整层拆掉，同时让楼能盖得更高。
2. 两组互相打脸的数据（The Contradiction）
先把最反直觉的两个数字摆在一起，因为几乎所有关于这个话题的争论，都在这两个数字之间来回撞墙 🧱。
2.1 2023 年：快 55.8%
Peng 等人在 2023 年做了一个随机对照试验（Randomized Controlled Trial，RCT），招募 95 名职业开发者，任务是「用 JavaScript 实现一个 HTTP 服务器，越快越好」。实验组可以用 GitHub Copilot，对照组只能用搜索引擎和 Stack Overflow。
结果是实验组平均快 55.8% （95% 置信区间内统计显著）：平均完成时间 1 小时 11 分 ，对照组 2 小时 41 分；任务完成率 78% 对 70%。
更值得注意的是分层结果：收益最大的是经验较少的开发者，资深开发者的提速幅度明显更小。这个细节后面会变得非常关键。
参考资料：
2.2 2025 年：慢 19%
两年后，METR（Model Evaluation and Threat Research）做了另一个 RCT，设计几乎是冲着上面那个实验来的：16 名资深 开源开发者，在自己熟悉 的仓库上处理 246 个真实 issue，随机分配「允许用 AI」和「禁止用 AI」。工具有 Cursor Pro 加 Claude 3.5/3.7 Sonnet。
三方预测全部偏乐观，实测全部相反：
| 谁在预测 | 预测的提速 | 实测结果 |
|---|---|---|
| 开发者开工前 | 缩短 24% | ------ |
| 开发者完工后自评 | 缩短 20% | ------ |
| 经济学专家 | 缩短 39% | ------ |
| 机器学习专家 | 缩短 38% | ------ |
| 实际测量 | ------ | 变慢 19% |
同一批人在做完任务之后，主观感受是「AI 让我快了 20%」，客观计时是「慢了 19%」。主观与客观的偏差达到约 39 个百分点，而且这个偏差不是随机噪声，是系统性的方向错误。
参考资料：
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity -- arXiv ⭐值得阅读
2.3 两个数字并不冲突
把两个实验的关键条件并排看，会发现它们测的其实是两件不同的事 ⚖️：
| 维度 | Peng 2023 | METR 2025 |
|---|---|---|
| 样本 | 95 人 | 16 人 |
| 任务 | 单一、自包含、从零写 | 真实、跨文件、改存量 |
| 代码库 | 空 | 自己维护多年的仓库 |
| 开发者资历 | 混合，含新手 | 全部资深 |
| AI 工具 | 2023 年的代码补全 | 2025 年的 agent 工具 |
| 结果 | 快 55.8% | 慢 19% |
结论不是「谁造假了」，而是：AI 的收益强烈依赖于任务是否自包含、代码库是否陌生、人是否新手。三个条件同时有利时，你拿到 55.8%；三个条件同时不利时，你拿到 −19%。
3. 为什么「感觉快了」和「实测变慢」能同时成立（The Perception Gap）
这个问题比「AI 行不行」重要得多，因为如果连当事人都测不准自己快没快，那所有靠自评得出的效率结论都不可信。
3.1 不信任在涨，使用量也在涨
Stack Overflow 2025 年开发者调查（84% 的受访者使用或计划使用 AI 工具，较 2024 年的 76% 上升）给出了一个非常拧巴的画像：
- 46% 明确不信任 AI 输出的准确性（2024 年为 31%）
- 33% 表示信任
- 仅 3% 表示「高度信任」
- 使用率创新高，信任度创新低
参考资料：
这不是「大家嘴上骂手上用」这么简单。它说明开发者已经把 AI 当成一个默认不可信、必须复核的外部依赖------而这个复核动作的成本，通常不计入「我用 AI 省了多少时间」的自评里。
3.2 验证成本是隐藏账单
Ziegler 等人对 GitHub Copilot 的内部数据分析显示，代码建议的接受率大约在 27% 量级，即接近四分之三的建议被开发者当场丢弃。
参考资料：
被丢弃的那 73% 就是纯成本：生成、阅读、判断、删除。这部分时间在任何「AI 帮我写了多少行」的统计里都不会出现。
类比 🎭：这就像请一个语速极快但偶尔胡说的助手帮你记会议纪要。会议结束你拿到 10 页纸，看起来效率爆炸，实际上你要逐句核对哪句是他真听到的、哪句是他脑补的。核对时间不计入「纪要生成速度」，但它确实被花掉了。
3.3 一个可复算的推论
用 METR 的数字做一个粗算：假设一个任务原本需要 100 分钟人工完成。AI 让你在生成环节省下 24 分钟（开发者的预估值），但引入了复核与纠偏成本；最终实测耗时 119 分钟。那么隐含的复核成本约为 43 分钟，占原任务时长的 43%。
这个数字在不同任务上差别巨大，但它的存在方式很稳定：任务越难验证，复核成本越接近甚至超过生成成本。这就是为什么写测试用例比自己写业务代码更安全------测试天然自带验证器（跑一下就知道红绿）。
4. 一个任务级模型：可替代性四维（Four Dimensions）
既然「AI 会不会替代程序员」这个问法太粗，那就换一个能算的问法：这个具体任务，有多容易被替代？
我把它拆成四个可以主观打分的维度，每维 0 到 5 分 👇
4.1 规格确定性（Spec Certainty）
需求有多明确。5 分代表「输入输出格式、边界条件、异常处理都写清楚了」，0 分代表「先做出来看看，老板说要那种感觉」。
确定性越高，越容易被替代。 这是四个维度里权重最大的一项，因为 AI 最擅长的就是把明确规格翻译成实现。
4.2 验证成本（Verification Cost）
判断结果对不对要花多少力气。5 分代表「只能上线一周后看业务指标」，0 分代表「跑一遍单测就知道」。
验证成本越高，越难被替代。 注意方向：难验证不是 AI 的护城河，是人的护城河------因为必须有人承担「我认为它是对的」这个判断。
4.3 上下文耦合（Context Coupling）
任务依赖多少没写进代码里的隐性知识。5 分代表「改这里会踩到三年前某个客户的特殊约定」，0 分代表「一个独立的工具函数」。
耦合越强，越难被替代。 这类知识的载体是人脑和聊天记录，不在上下文窗口里。
4.4 责任归属（Accountability）
出了问题谁签字。5 分代表「涉及资金、合规、人身安全，必须有人负责」，0 分代表「错了重跑一遍就行」。
责任越重，越难被替代。 这是最被低估的一维：AI 可以给出方案，但不能承担后果。监管、合同、事故复盘，需要的都是一个可被追责的主体。
4.5 四个维度的组合直觉
把四维放在一起，能解释前面所有矛盾数据：
| 任务类型 | 规格确定性 | 验证成本 | 上下文耦合 | 责任归属 | 替代风险 |
|---|---|---|---|---|---|
| 写 CRUD 接口 | 高 | 低 | 低 | 低 | 极高 |
| 补单元测试 | 高 | 极低 | 低 | 低 | 极高 |
| 迁移一个老模块 | 中 | 中 | 高 | 中 | 中 |
| 排查偶发死锁 | 低 | 高 | 高 | 中 | 低 |
| 设计跨部门权限模型 | 低 | 高 | 极高 | 高 | 极低 |
Peng 实验里的「从零写一个 HTTP 服务器」落在第一行，METR 实验里的「在自己仓库里处理真实 issue」落在第三、四行。同一批技术，风险等级差了两个数量级。
5. 一个能跑的替代性评分器（Runnable Scorer）
光靠嘴说四个维度很难对齐，把它写成代码就具体了。下面这段可以直接复制运行，只依赖标准库 🐍。
python
"""任务可替代性评分器：给定开发任务的四个维度打分，输出 AI 替代风险分（0-100）。
维度说明（每项 0-5 分）：
spec_certainty 规格确定性：需求写得越清楚越高
verification_cost 验证成本：判断结果对不对越费劲越高
context_coupling 上下文耦合：依赖的隐性知识越多越高
accountability 责任归属：出错后要人担责的程度越高越高
"""
from dataclasses import dataclass
# 四个维度的权重，合计 1.0；规格确定性权重最高，因为它最直接决定 AI 能否接手
WEIGHTS = {
"spec": 0.35, # 规格确定性
"verify": 0.25, # 易验证性（验证成本取反）
"coupling": 0.20, # 低耦合
"duty": 0.20, # 低责任
}
@dataclass
class Task:
"""一个待评估的开发任务。
属性:
name: 任务名称，仅用于输出展示
spec_certainty: 规格确定性 0-5
verification_cost: 验证成本 0-5
context_coupling: 上下文耦合 0-5
accountability: 责任归属 0-5
"""
name: str
spec_certainty: int
verification_cost: int
context_coupling: int
accountability: int
def score(task: Task) -> tuple[float, dict[str, float]]:
"""计算任务的 AI 替代风险分。
参数:
task: 待评估的任务
返回:
(风险分 0-100, 各维度归一化贡献字典)
数据流示例：spec_certainty=5 → 5/5 = 1.0 → 1.0 * 0.35 = 0.35
"""
parts = {
"spec": task.spec_certainty / 5, # 确定性越高，风险越高
"verify": 1 - task.verification_cost / 5, # 验证成本越低，风险越高
"coupling": 1 - task.context_coupling / 5, # 耦合越低，风险越高
"duty": 1 - task.accountability / 5, # 责任越轻，风险越高
} # 每项都归一化到 0-1
total = sum(parts[key] * weight for key, weight in WEIGHTS.items()) # 加权求和 0-1
return round(total * 100, 1), {key: round(value, 3) for key, value in parts.items()}
def verdict(risk: float) -> str:
"""把风险分翻译成人话判断。
参数:
risk: score() 返回的风险分
返回:
风险等级字符串
"""
if risk >= 75: # 高确定性 + 低验证成本 + 低耦合 + 低责任
return "高：AI 可以先出稿，人只做抽查"
if risk >= 45: # 至少有两维对 AI 有利
return "中：AI 做草稿，人做主要修改"
return "低：人主导，AI 只提供备选思路" # 多维不利，AI 只能当助手
TASKS = [
Task("写一个 CSV 导出函数", spec_certainty=5, verification_cost=1,
context_coupling=1, accountability=1),
Task("排查线上偶发死锁", spec_certainty=2, verification_cost=5,
context_coupling=4, accountability=3),
Task("设计跨部门权限模型", spec_certainty=2, verification_cost=3,
context_coupling=5, accountability=5),
]
for item in TASKS: # 逐个任务评估
risk_score, detail = score(item) # 得到风险分与维度明细
print(f"{item.name}：{risk_score} 分 → {verdict(risk_score)}")
print(f" 维度明细 {detail}\n") # 打印归一化后的四维贡献实际输出：
text
写一个 CSV 导出函数：87.0 分 → 高：AI 可以先出稿，人只做抽查
维度明细 {'spec': 1.0, 'verify': 0.8, 'coupling': 0.8, 'duty': 0.8}
排查线上偶发死锁：26.0 分 → 低：人主导，AI 只提供备选思路
维度明细 {'spec': 0.4, 'verify': 0.0, 'coupling': 0.2, 'duty': 0.4}
设计跨部门权限模型：24.0 分 → 低：人主导，AI 只提供备选思路
维度明细 {'spec': 0.4, 'verify': 0.4, 'coupling': 0.0, 'duty': 0.0}这个评分器的价值不在于分数准不准（权重是我拍的），而在于它逼你把「会不会被替代」拆成四个能被追问的问题。你答不出「这个任务的验证成本是多少」，就说明你还没想清楚自己在这件事里到底值钱在哪。
6. 症状 → 原因 → 解法对照表（Symptom Table）
下面这张表把日常可观察到的现象，直接映射到它的机制与应对动作。建议按「我最近最像哪一行」来读，而不是从头读到底 📋。
| 症状 | 原因 | 解法 |
|---|---|---|
| AI 生成的代码看着都对，合进主干后一周内返工率上升 | 交付稳定性随 AI 采纳度下降，DORA 2024 实测每 25% 的采纳度提升对应 7.2% 稳定性下降、1.5% 吞吐下降 | 把小批量提交和自动化测试当成前置条件，而不是事后补救；AI 产的代码强制进入同一套 CI 关卡 |
| 团队自评「效率提升明显」，但迭代周期没变短 | 主观感受与客观计时系统性偏离（METR 实测自评快 20%、实际慢 19%） | 只信可计时的指标：需求进入与上线的 lead time、单位时间合并的可运行 PR 数 |
| 项目越往后越难改，重复代码越来越多 | 代码块重复率逐年上升，GitClear 统计从 2023 年的每百万变更行 40.3 升至 2025 年的 69.7（2026 年至今 73.0），三年增幅约 81% | 在 code review 里显式检查「这段是不是已有实现的复制」，把重复率作为可观测指标 |
| 新手能很快出活，但三个月后仍讲不清自己的架构 | 生成式工具压低了「写」的门槛，没有压低「理解」的门槛 | 强制新人用自己的话复述改动理由；把「能解释」写进验收标准，而不只是「能跑」 |
| 资深开发用 AI 反而更慢，觉得是工具不行 | 任务耦合度高、验证成本高时，AI 的错解会把上下文污染放大 | 只在低耦合、强验证的环节启用 agent；高耦合排查类任务让 AI 做「提供假设」而非「直接改」 |
| 团队砍掉初级岗，同时招不到能带 AI 的中级 | 就业调整主要发生在入口层，资深层反而稳定 | 把初级岗的职责从「写代码」改为「审代码 + 写测试」，用 AI 产能养出判断力 |
| 老板要求「全面 AI 化」，团队抵触 | 缺少可验证的收益口径，双方都在拿感觉吵架 | 先选一个四维评分高（规格确定、易验证、低耦合、低责任）的子任务做试点，用 lead time 出结论 |
DORA 那组数字值得单独说清楚，因为它是目前少见的、按组织级指标测出来的负向结果：每 25% 的 AI 采纳度提升，对应交付吞吐量约 1.5% 的下降和交付稳定性约 7.2% 的下降（稳定性由变更失败率与返工率构成）。
参考资料：
这里必须给一个反直觉取舍的理由 ：为什么吞吐量只掉了 1.5%，稳定性却掉了 7.2%，两者差了近五倍？因为 AI 主要压缩的是「写」这一段，而吞吐量的瓶颈通常在后半段------评审、联调、发布、灰度。稳定性则直接暴露在「写」的产出质量上，所以它对 AI 的边际变化最敏感。这个不对称本身就是判据：哪一段是你的瓶颈，AI 就在哪一段失效。
7. 就业市场已经给出的答案（The Labor Signal）
讨论到这里，可以离开实验室数据看真实市场了。市场给出的答案比任何一篇论文都直接，而且分层极其明显 💼。
7.1 入口层在收缩
Brynjolfsson、Chandar、Chen 三位用美国最大的薪酬软件供应商的行政数据（覆盖数千万雇员）做了分析，结论是六条事实，其中最刺眼的一条是：生成式 AI 广泛采用之后，AI 暴露度最高职业中 22 至 25 岁的早期职业者，就业相对下降 13%（已控制企业层面的冲击）；而同一批职业中经验更丰富的从业者，就业保持稳定甚至继续增长。
参考资料：
注意 13% 的口径：「相对下降」是相对于低暴露职业的对照组，不是绝对失业率。不同二手报道在绝对降幅上给出过更大的数字，但论文本身的可复算口径是 13% 的相对降幅。
7.2 总量层在扩张
同一时间，BLS 的十年预测给出的是增长：软件开发者岗位 2024 至 2034 年预计增长 15.8% ，绝对增量约 267,700 个，行业基数在 2024 年约为 169 万人。作为对照，全美所有职业的平均预测增速约为 4%。
把两条放在一起，得到的不是「程序员要消失了」，而是金字塔的底座被抽走、中上层被加厚。这个结构的后果比「消失」更难处理：入口消失意味着没有人再通过打杂成长为资深。
类比 🎭：这像一家餐厅把学徒岗全部取消，只留主厨。短期看成本降了、出菜没受影响；三年后发现没人能接主厨的班，因为主厨是学徒熬出来的。
7.3 需求侧在改口径
招聘市场的变化比就业统计更快。2026 年对约 4.5 万条软件工程师在招岗位的分析显示，明确提到新一代生成式 AI 技能的比例约 20.5% ，若把传统机器学习算进来则升至约 28.3%。
2026 年 3 月《财富》杂志把一类新角色称为「supervisor class（监督者阶层）」：他们的主要价值不再是写代码，而是编排写代码的 agent、审查产出、做高层架构决策。Karpathy 在 2026 年的 Sequoia Ascent 上把这个转向讲得更直白------他把自己 2025 年 2 月提出的 vibe coding（氛围编程）划给「所有人的下限工具」，而把专业软件需要的部分改称 agentic engineering（智能体工程）：你可以更快，但你依然要为软件负责，不允许因为「氛围」引入漏洞。
参考资料：
- Sequoia Ascent 2026 summary -- karpathy ⭐值得阅读
- AI Agents Are Now in 1 in 10 Software Engineer Job Postings -- InterviewStack
8. 哪些能力反而升值（What Appreciates）
如果四维模型成立，那「升值的能力」不需要靠猜，直接取四个维度的补集就行 🎯。
8.1 规格能力：把模糊需求变成可验证表述
规格确定性是权重最高的一维，而它的供给方是人。能把「老板说要那种感觉」翻译成「输入 3 类、边界 5 条、异常 2 种、验收标准 4 项」的人，在任何 AI 工具面前都是稀缺的。
这也是为什么 prompt 技巧本身在贬值、而需求拆解在升值：前者是让 AI 听懂你，后者是让你自己先想清楚。
8.2 验证能力：设计「跑一下就知道对不对」的关卡
前面的推论已经算过账：任务越难验证，复核成本越接近生成成本。所以能把难验证的任务改造成易验证的人，直接吃掉了那笔隐藏账单。
具体动作很朴素：写契约测试、造最小复现、把灰度指标提前定义好、把「我觉得对」换成「这个断言通过」。这类工作从前被看作杂活，现在是杠杆最高的位置。
8.3 上下文能力：把隐性知识显性化
上下文耦合是 AI 最难攻的一维，但它的壁垒性质很尴尬：它保护的是「知道这件事的人」，而不是「这个人所在的公司」。一旦隐性知识被写成文档、ADR（Architecture Decision Record，架构决策记录）或测试用例，它就从人的护城河变成了组织的资产。
所以更准确的说法是：懂隐性知识的人短期升值，长期任务是把这份知识交出去，然后换到下一层隐性知识上去。
8.4 责任能力：成为能签字的那个人
责任归属是唯一一维 AI 在结构上无法接管的东西。不是因为模型不够强，而是因为它不能成为被追责的主体------监管、合同、事故复盘都需要一个能承担后果的人。
这意味着「能签字」本身就是一种稀缺资源，而签字资格来自可追溯的判断记录：你过去做的技术决策、你留下的复盘、你在关键节点说过的话。
8.5 一个诚实的反面
最后要说清楚不适用的场景，否则前面全是在自我安慰 ⚠️：如果你的工作长期停留在「规格明确、验证便宜、耦合很低、责任很轻」象限内，那么四维模型给出的结论就是高替代风险，而且这个结论不会因为你把它读成励志文而改变。
真正的选择只有两个：往四维中的任意一维上移，或者接受这个工序正在被压缩的事实并提前换道。前者需要时间，后者需要勇气，两个都不轻松。
决定某个环节要不要接 agent，先用第 4 节四维打分：规格确定、验证便宜、耦合低、责任轻的直接上；需要有人签字的，AI 只能出草稿。
本专栏《AI开发范式》聚焦 AI 进入工程流程后的真实约束------接口可靠性、成本控制、任务可替代性与协作方式变化，每篇配一段可直接运行的代码或一份判据表，每月更新两到三篇。想按顺序读完，可在专栏页订阅。