当 AI 公司开始研究自己：Anthropic 内部工作变革报告深度解读
当一家开发前沿 AI 的公司，把研究镜头转向自己的员工，会看到怎样的未来？
Anthropic 在 2025 年 12 月发布了 《How AI Is Transforming Work at Anthropic》。这不是一篇常见的“AI 提效案例”：研究结合了 132 名工程师与研究员的问卷、53 次深度访谈，以及约 20 万条内部 Claude Code 使用记录，试图回答一个更困难的问题：
AI 让人完成了更多工作之后，人的能力、协作关系和职业身份发生了什么？
答案并不简单。生产力显著上升，工程师也变得更“全栈”；但与此同时，深层技能可能失去练习机会，人与人的协作被重新分配，监督 AI 所需的判断力也面临退化风险。
先看结论：AI 带来的不是简单加速
报告最重要的发现，可以浓缩为四组数字：
| 指标 | 研究结果 | 应该如何理解 |
|---|---|---|
| Claude 参与日常工作的比例 | 约 59% | AI 已从偶尔使用的工具变成持续协作者 |
| 自报生产力提升 | 约 50% | 主要体现为产出量增加，而非所有任务都节省一半时间 |
| 原本不会开展的 AI 辅助工作 | 27% | AI 不只压缩成本，还扩大了工作的边界 |
| 可完全委派的工作 | 多数人仅为 0–20% | 高频使用不等于无人监督的自动化 |
过去一年，受访者自报的 Claude 使用比例从 28% 增至 59%，生产力增幅从 20% 上升至 50%。但这组数据不应被解读为“AI 替代了半个工程师”。
研究显示，AI 对工作的主要影响是：每类任务花费的时间略有下降，但完成的任务总量大幅增加。 工程师会修复更多小问题、补更多测试、制作以前不值得投入的内部工具，并探索更多候选方案。
这是一种典型的需求回弹：能力越便宜，组织越不会满足于维持原来的产出，而是会提高预期。
这项研究到底测量了什么？
理解结论之前，需要先分清三类证据：
| 证据 | 样本 | 能回答什么 | 不能回答什么 |
|---|---|---|---|
| 内部问卷 | 132 名工程师与研究员 | 员工如何感知生产力、委派比例与工作变化 | 不能证明真实工时下降了多少 |
| 深度访谈 | 53 名参与者 | 为什么委派、何时不信任 AI、技能与协作如何变化 | 不能直接量化全公司的变化 |
| Claude Code 记录 | 约 20 万条交互 | 任务类型、自主工具调用和人机轮次如何变化 | 看不到工具之外的沟通与长期维护成本 |
三种证据的价值在于相互补充：问卷提供主观体验，访谈解释行为动机，工具记录验证使用模式是否真的发生变化。它们共同描绘趋势，但仍不是随机对照实验。
“生产力提升”至少包含四层
很多组织只看节省了多少编码时间，这会低估 AI 的影响，也会掩盖新的成本。
- 速度：同样的任务是否更快完成；
- 吞吐：一个 Sprint 是否交付了更多有价值的工作；
- 范围：个人是否能跨越前端、后端、数据或研究工具的边界；
- 质量：测试、文档、可维护性和用户结果是否改善。
正确的管理方式不是追求“AI 使用率最大化”，而是观察这四层收益是否覆盖了上下文准备、审核、返工和事故风险。
变化一：工程师正在成为“更宽的人”
Claude 最常见的日常用途是调试、理解代码库和实现功能。55% 的受访者每天用它调试，42% 每天用它理解代码，37% 每天用它开发新功能。
更有意思的是，AI 正在降低跨专业工作的门槛：
- 后端工程师可以快速搭建前端界面；
- 安全团队可以分析不熟悉的代码；
- 研究人员可以自己制作交互式数据可视化；
- 不熟悉 Git、Linux 或数据库的人可以完成外围工程任务。
过去需要跨团队排期、开会和交接的原型，现在可能在一次工作会话中完成。工程师的能力边界因此从“I 型专才”向更宽的“T 型”甚至“梳子型”扩展。
但这里有一个容易忽略的区别：
AI 扩大的是一个人能够交付的范围，不一定同步扩大其真正理解的范围。
“做得出来”与“能够解释设计、识别风险、承担长期维护责任”不是同一件事。AI 可以填补 API 和语法知识，却不能自动补齐组织上下文、系统直觉与工程品味。
变化二：委派的核心不是能力，而是验证成本
Anthropic 员工并不是把最困难的任务统统交给 Claude。他们形成了一套更务实的委派直觉：优先交给 AI 的任务通常边界清楚、风险较低、结果容易验证，或执行过程重复乏味。
可以把这种判断抽象成一个简单公式：
委派收益 = 人工执行成本 -（提示与上下文成本 + 验证成本 + 出错风险）
| 任务特征 | 更适合 AI | 更适合人主导 |
|---|---|---|
| 结果验证 | 有测试、类型检查或明确输出 | 正确性依赖隐性知识 |
| 任务边界 | 独立、局部、可回滚 | 跨系统、强耦合 |
| 风险等级 | 原型、内部工具、重复劳动 | 安全、隐私、核心架构 |
| 上下文成本 | 仓库信息容易检索 | 依赖大量历史决策 |
| 判断类型 | 实现与搜索 | 战略、设计与“品味” |
这也解释了为何 AI 在陌生但低复杂度的领域可能非常有效，而在工程师极其熟悉的大型代码库中反而未必更快：后者拥有大量模型看不到的隐性上下文，人类自己完成可能比把上下文完整解释给 AI 更便宜。
真正成熟的 AI 工程能力，不是“什么都让 AI 做”，而是能够持续判断：
- 哪些工作可委派；
- 应该提供多少上下文；
- 用什么机制验证；
- 何时停止迭代并由人接管。
变化三：自主性正在快速增长
问卷是主观感受，Claude Code 的内部记录则展示了行为变化。Anthropic 对 2025 年 2 月和 8 月的使用数据进行比较后发现：
| 指标 | 2025 年 2 月 | 2025 年 8 月 | 变化 |
|---|---|---|---|
| 平均任务复杂度（1–5） | 3.2 | 3.8 | 上升 |
| 连续工具调用次数 | 9.8 | 21.2 | +116% |
| 每次会话的人类轮次 | 6.2 | 4.1 | -33% |
| 功能实现占使用比例 | 14% | 37% | 明显上升 |
| 设计与规划占比 | 1% | 10% | 明显上升 |
这说明变化不仅是“更多人开始用 AI”，也是同一个人正在把更复杂、更长链路的任务交给 AI。
不过，使用占比上升并不等于对应工作的绝对数量也同幅增长。报告采用按时期比例抽样，只能证明任务结构发生变化，不能直接推导整个组织完成了多少功能。
最危险的矛盾：监督悖论
AI 使用越多，工程师亲手调试、阅读文档和探索系统边界的机会可能越少。问题不只是“手生”，而是那些看似低效的过程，本来就在建立心智模型。
亲自追踪一次困难故障，往往会顺带理解调用链、缓存策略、配置约束与历史设计。AI 如果直接给出正确修改，人得到了答案，却可能跳过了形成判断力的过程。
于是出现一个关键悖论：
监督 AI 需要专业能力，但过度依赖 AI 又可能削弱这种专业能力。
资深工程师通常已经通过“困难模式”积累了对正确答案形态的直觉。初级工程师则可能在尚未形成判断力时，就直接进入审核者角色。这使传统的“先做简单任务，再承担复杂系统”的成长路径受到冲击。
解决方案不是禁止 AI，而是把学习从偶然副产品改造成显式机制：
- 保留定期的无 AI 编码、调试和系统推演；
- 要求工程师解释关键改动，而不只是让测试通过；
- 对核心模块实行设计评审、威胁建模和故障演练；
- 用 AI 生成多个方案，但由人比较权衡并记录决策；
- 将“能否审核和追责”作为委派上限，而不是模型能否生成代码。
团队协作：问题没有消失，只是换了接收者
过去，工程师遇到问题会询问同事；现在，Claude 往往成为第一站。一位受访者估计，自己 80%–90% 的问题先问 AI。
这带来明显收益：减少打断、降低提问心理负担，让同事集中处理真正需要组织上下文的问题。但它也可能侵蚀团队中最重要却最难量化的部分：
- 初级成员减少向资深成员提问，导师关系变弱；
- 偶然讨论和知识扩散减少；
- 一个人能独立完成更多事情，也更容易形成信息孤岛；
- 工作逐渐从共同创造变成各自管理一组 AI。
团队不能把“更少互相打扰”自动等同于“协作效率更高”。高质量协作不仅是传递答案，还包括建立信任、共享判断标准、发现未知问题和培养下一代工程师。
一个更健康的分工是：
| Claude 优先处理 | 人类协作优先处理 |
|---|---|
| API 用法、代码搜索、错误解释 | 目标冲突与优先级 |
| 局部实现与重复修改 | 架构权衡与组织上下文 |
| 草拟文档、测试和迁移脚本 | 复盘、导师制与职业反馈 |
| 快速探索多个候选方案 | 决定采用哪个方案及其原因 |
正确的管理模型：交付环 + 治理环
AI 进入研发流程后，最常见的错误是只优化执行阶段：团队购买工具、要求工程师多用，却没有改变任务定义、验收方式和组织学习。结果通常是代码产量上涨，评审队列、返工和技术债也同步上涨。
更稳健的方法是建立两个相互连接的循环：
- 交付环保证单个需求被正确实现，反馈周期应尽可能短。
- 治理环保证团队没有用短期吞吐换取长期能力退化，关注的是系统规则而非某一次 Prompt。
管理者的责任不是审批每次 AI 调用，而是设计清晰的委派边界、低成本验证和升级路径。
第一步：用四级风险矩阵决定委派方式
在进入 Sprint 前，先根据业务影响和可验证性为任务分级。模型能力不是唯一变量，错误能否及时被发现更加重要。
| 等级 | 典型任务 | AI 权限 | 必要控制 |
|---|---|---|---|
| L0 探索 | 调研、草稿、一次性分析、原型 | 可自主生成和反复试验 | 标注假设，不进入生产 |
| L1 低风险 | 文档、测试补全、局部重构、内部工具 | 可实现并自动验证 | CI 通过，普通代码评审 |
| L2 中风险 | 用户功能、数据库迁移、共享组件 | 人定义方案，AI 辅助实现 | 设计说明、集成测试、指定责任人 |
| L3 高风险 | 权限、支付、隐私、核心架构、生产操作 | 人主导，AI 仅作分析或候选方案 | 双人评审、安全审查、回滚与演练 |
风险等级应该记录在 Issue 或任务卡中，并允许在执行中升级。例如，原本的局部重构一旦触碰鉴权或共享数据模型，就应从 L1 升为 L2/L3，而不是沿用低风险流程。
第二步：建立 AI-Ready 的 Definition of Ready
传统用户故事经常只有一句“支持导出功能”。对人类成员而言，缺失的信息可以在会议和经验中补齐；AI 会把这些空白变成未经确认的假设。
一个任务只有满足以下条件才应进入 AI 执行：
- 目标明确：解决谁的什么问题，成功结果是什么；
- 范围明确：允许修改与禁止修改的模块；
- 上下文可定位：关键文件、接口、设计决策和参考实现可检索；
- 验收可执行：至少包含行为示例、测试或可观察结果；
- 风险已分级：明确 AI 的权限、人工检查点和责任人；
- 失败可恢复：有回滚方式，不在不可逆环境中直接试错。
推荐的任务卡模板：
## Outcome
用户完成 X 后，应看到 Y；业务指标 Z 不得下降。
## Scope
- 可以修改：src/export/\*\*、相关测试
- 禁止修改：鉴权、计费、公共数据模型
## Constraints
- 保持现有 API 兼容
- 不新增运行时依赖
## Acceptance Evidence
- 单元测试覆盖 A/B/C
- 集成测试验证失败重试
- 构建与类型检查通过
## Risk & Ownership
- 等级：L2
- 人类 Owner：Alice
- 必须评审：数据迁移、错误恢复
这里最关键的是 Acceptance Evidence。验收标准不能只写“实现完成”，而要写明由什么证据证明完成。
第三步：按七个阶段运行 AI Sprint
一个正确的迭代流程，不是“把 Ticket 发给 Claude，然后等 PR”，而是把决策、执行和验证拆成清晰的阶段。
阶段 1：Intake——先确认结果，不急着写方案
产品负责人说明用户问题、优先级和不可接受的结果。团队先判断需求是否值得做，避免 AI 让低价值想法因为“实现很便宜”而大量进入系统。
阶段 2：Classify——确定委派等级
技术负责人根据风险矩阵决定 L0–L3，并明确哪些决策必须由人完成。这个阶段还要识别数据权限、外部依赖、不可逆操作和合规要求。
阶段 3：Contract——签订可验证的工作合同
在动代码前，AI 可以先输出：
- 对现状的理解与关键文件；
- 2–3 个候选方案及权衡；
- 计划修改的文件；
- 测试计划和回滚方式；
- 仍需人回答的问题。
人类 Owner 审核这份计划。高风险任务如果方案阶段就无法清晰说明失败模式，不应进入实现。
阶段 4：Execute——用小批量闭环代替长时间放任
每次只完成一个可验证增量：
检索上下文 → 提出假设 → 修改最小范围 → 运行验证
↑ ↓
└──────── 根据证据修正，而非继续猜测 ────────┘
控制单次变更规模比控制 Prompt 长度更重要。小 PR、短分支和频繁测试能降低错误扩散，也让人工更容易理解 AI 做了什么。
阶段 5：Verify——验证输出，而不是验证模型“看起来很自信”
验证应按层次执行：
| 层次 | 证据 | 主要发现 |
|---|---|---|
| 静态门禁 | 格式、Lint、类型、依赖规则、密钥扫描 | 结构和规则违规 |
| 行为测试 | 单元、集成、端到端、契约测试 | 功能是否正确 |
| 非功能测试 | 性能、安全、可访问性、兼容性 | 功能之外的风险 |
| 运行时观测 | 日志、指标、追踪、业务 KPI | 真实环境中的未知问题 |
如果验证失败，应先分类：是上下文缺失、需求冲突、实现错误，还是测试本身错误。无限追加 Prompt 往往只是把问题隐藏得更深。
阶段 6：Human Gate——人对不可自动化的判断负责
人工评审不应重复检查格式，而应回答：
- 方案是否符合产品目标和系统方向？
- 代码是否引入了隐藏耦合或长期维护负担？
- 失败时影响范围和恢复方式是什么？
- 测试是否只证明“代码按实现运行”，还是证明“需求被满足”？
- 评审者能否向第三个人解释这次改动？
最后一个问题是重要门槛：不能解释的代码，不应因为测试通过就自动合并。
阶段 7：Release & Learn——发布不是流程终点
优先使用 Feature Flag、灰度发布、影子流量和自动回滚。发布后比较预期指标与真实指标，并记录：
- 哪类上下文最有帮助；
- 哪些验证发现了 AI 错误；
- 哪些人工检查其实可以自动化；
- 是否出现返工、事故或能力缺口；
- 下一轮应扩大还是收紧委派边界。
第四步：明确角色，避免“AI 做的”成为责任真空
AI 不是 RACI 表中的责任主体。无论代码由谁生成，都必须有可追责的人类 Owner。
| 角色 | 核心责任 |
|---|---|
| 产品负责人 | 定义用户结果、优先级和不可接受结果 |
| 技术负责人 | 风险分级、架构边界和升级决策 |
| 实现 Owner | 提供上下文、控制变更、解释输出并对交付负责 |
| 独立评审者 | 挑战假设，检查设计、风险和验收证据 |
| 平台/安全团队 | 提供统一工具、策略、权限、审计与自动门禁 |
对于 L2/L3 任务，实现者和最终评审者应尽量分离。让同一个人和同一个 AI 会话同时生成、解释并批准结果，容易产生确认偏差。
第五步：用正确指标管理，而不是统计 Token 和代码行
AI 管理最危险的指标是“生成代码行数”“Prompt 次数”和“工具使用率”。这些指标容易上涨，却不能说明用户价值、质量或能力是否改善。
建议使用四组平衡指标：
| 维度 | 推荐指标 | 需要警惕 |
|---|---|---|
| 流动效率 | Lead Time、Cycle Time、部署频率、等待评审时间 | 生成更快但评审队列变长 |
| 交付质量 | 变更失败率、回滚率、逃逸缺陷、返工比例 | 测试通过但生产事故增加 |
| AI 经济性 | 接受率、首次通过率、验证耗时、上下文准备时间 | 模型成本下降但人类审核成本上升 |
| 团队能力 | 关键模块覆盖人数、设计评审质量、故障恢复能力 | 只有少数人能解释系统 |
可以使用下面的复合判断，而不是单一“提效百分比”：
净收益 = 用户价值增量
- 返工成本
- 审核与上下文成本
- 事故风险
- 长期维护与能力损耗
建议的管理节奏
| 频率 | 活动 | 产出 |
|---|---|---|
| 每日 | 检查阻塞、失败验证和风险升级 | 需要人工介入的任务清单 |
| 每周 | Sprint Review + AI 使用复盘 | 有效模式、失败案例、待自动化门禁 |
| 每月 | 质量与能力审查 | 委派矩阵调整、培训和平台改进 |
| 每季度 | 组合与治理复盘 | 工具策略、权限政策、角色与投资方向 |
月度复盘应抽样阅读成功和失败的 AI 辅助任务，而不是只看仪表盘。定性检查可以发现“指标很好，但团队已经无法解释核心系统”这类慢性风险。
第六步：保护学习路径与团队记忆
AI 提效之后，节省出的时间应有一部分被明确投入能力建设，否则监督悖论会逐渐放大。
可采用以下机制：
- Explain-back：实现者在评审中解释关键控制流、失败模式和取舍；
- 无 AI 演练：定期进行故障排查、系统设计和核心算法练习；
- 结对审核：初级成员与资深成员共同审核 AI 生成的复杂改动；
- 决策日志：记录为什么采用方案，而不是只保留最终代码；
- 轮值 Ownership：避免某个模块只有一个人和其私人 Prompt 历史能维护；
- 失败案例库：保存模型常见误判、缺失上下文和有效验证方式。
知识库应该记录稳定规则、系统地图和决策，而不是堆积未经整理的聊天记录。AI 需要的是高信噪比上下文，人类团队同样如此。
常见反模式：看似提效，实际在透支系统
1. AI-first，而不是 Outcome-first
为了展示 AI 使用率，把本不值得做的功能也塞进 Sprint。正确顺序始终是先确认用户价值，再选择执行工具。
2. 一次性生成大型 PR
几千行修改可能“能运行”，却几乎无法可靠评审。把工作拆成可独立验证的小增量，并限制同时在制品数量。
3. 让生成者自我验收
同一上下文容易延续错误假设。关键任务使用独立评审者、独立测试或新的 AI 会话进行反证。
4. 只看测试是否绿色
测试可能遗漏需求，也可能由 AI 按错误实现反向编写。验收必须同时检查用户结果、设计约束和运行时信号。
5. 默认所有员工都应采用同一委派比例
熟悉度、任务类型和风险不同，最佳 AI 使用比例也不同。管理的是边界与结果，不是统一使用配额。
6. 把节省的时间全部转化为更多任务
如果吞吐提升只带来更高负荷，没有投入测试基础设施、知识共享和人员成长，团队最终会被评审债与技术债反噬。
给工程团队的落地清单
- 每个任务都有 L0–L3 风险等级；
- 进入 Sprint 前满足 AI-Ready Definition of Ready；
- 验收标准包含可执行证据，而不是抽象描述；
- AI 每次只处理可验证的小增量；
- L2/L3 任务有独立的人类评审者；
- CI 覆盖类型、测试、安全和依赖规则；
- 发布具备灰度、观测与回滚能力；
- Sprint 复盘同时检查速度、质量、成本和能力；
- 每月根据事故与返工调整委派边界；
- 团队保留显式的深层技能训练。
AI 负责扩大搜索空间，人负责压缩决策空间。 让 AI 快速探索实现、资料和候选方案；让人基于目标、风险、品味和责任做最终选择。
如何看待“生产力提升 50%”
这份研究有很高的观察价值，但不能被当成普遍适用的因果结论：
- 样本特殊：参与者来自开发 AI 的公司，拥有前沿模型、较高技术水平和强烈使用动机。
- 生产力主要来自自报：人对节省时间的感受可能与真实完成时间不同。
- 研究发生在特定时间点：数据采集于 2025 年 8 月，当时的主力模型是 Claude Sonnet 4 和 Opus 4。
- 记录只能观察工具内行为：无法完整衡量线下讨论、设计质量、长期维护成本与机会成本。
- 相对占比不等于绝对产量：某类任务在 Claude Code 中占比上升，不代表全公司的此类工作按同样比例增长。
Anthropic 也引用了 METR 关于资深开发者使用 AI 编程工具的研究。该研究发现，在熟悉的大型开源代码库中，开发者可能高估 AI 带来的速度提升。两份研究并不必然矛盾：它们共同说明，任务选择、代码库熟悉度、上下文成本和验证方式，会决定 AI 到底是加速器还是额外负担。
结语：工程师的工作正在从“生产代码”转向“承担判断”
这份报告最值得关注的，不是 Claude 写了多少代码，而是软件工程的价值重心正在迁移：
- 从记忆 API 转向定义问题；
- 从亲手完成每一步转向设计反馈回路；
- 从单点实现能力转向跨领域交付；
- 从代码产量转向验证、判断与责任；
- 从“我会不会写”转向“我是否知道什么是对的”。
短期看，AI 让优秀工程师完成更多工作。长期看，真正的挑战是：当实现越来越便宜，我们能否继续培养有能力审查实现、理解系统并为结果负责的人。
AI 不会自动创造更好的工程组织。它只会放大现有系统：清晰的目标、可靠的验证和健康的协作会被放大；模糊的责任、薄弱的测试和缺失的培养机制也会被放大。
这或许才是 Anthropic 内部研究给整个行业最重要的提醒。
参考资料
- Anthropic, How AI Is Transforming Work at Anthropic, 2025-12-02.
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025-07-10.