全文摘要：替代「写代码」这个动作已经在发生，替代「程序员」这个职业在可验证数据里还没发生。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）
光靠嘴说四个维度很难对齐，把它写成代码就具体了。下面这段可以直接复制运行，只依赖标准库 🐍。
"""任务可替代性评分器：给定开发任务的四个维度打分，输出 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") # 打印归一化后的四维贡献
实际输出：
写一个 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 进入工程流程后的真实约束——接口可靠性、成本控制、任务可替代性与协作方式变化，每篇配一段可直接运行的代码或一份判据表，每月更新两到三篇。想按顺序读完，可在专栏页订阅。
