来源：Anthropic Economic Research — Agentic coding and persistent returns to expertise（Jun 16, 2026） 作者：Zoe Hitzig, Maxim Massenkoff, Eva Lyubich, Ryan Heller, Peter McCrory 分析完成时间：2026-06-18 00:30:00

智能体编程与专业知识的持续回报

关键发现（Key findings）

在前序研究基础上，我们提出了一套研究交互式智能体编程（interactive agentic coding）的框架，基于对 2025 年 10 月至 2026 年 4 月间约 40 万个 Claude Code 会话的隐私保护分析。我们评估了任务的构成、人机协作方式以及成功率。

在一个典型会话中，人做出大部分规划决策（做什么），而 Claude 做出大部分执行决策（怎么做）。一个人带入会话的领域专业能力（domain expertise）越强，Claude 每条指令完成的工作就越多。在编程任务上，每一个主要职业的成功率——即完成当事人设定的目标，并有可验证证据（如通过测试或提交了代码）——平均下来几乎与软件工程师一样高。

一个人的领域专业能力越强，会话以成功收尾的频率就越高——不过中级用户与专家用户之间的差距并不大。在我们观察的七个月里，用于调试（debugging）的会话占比下降了近一半，使用重心也转向了更多端到端的智能体式使用：部署和运行代码、分析数据、撰写非代码文档。

在这七个月里，典型任务的价值——我们通过与自由职业招聘信息对比来估算——在几乎每一种工作中都上升了，平均约 25%。

引言（Introduction）

智能体编程已经起飞。自 2025 年底以来，带有编程 Agent 活动的 GitHub 项目占比翻了一番还多[1]，Claude Code 用户现在平均每周花 20 小时使用该工具[2]。没有正式编程经验的人，能否成功指挥一个 Agent 完成复杂的技术工作？而这些工具的快速普及与进步，对知识工作整体意味着什么？我们还没有完整答案，但我们可以从 Claude Code 的使用数据里寻找早期信号。

本报告提供了 Claude Code 实际使用情况的证据，基于对 2025 年 10 月至 2026 年 4 月间约 23.5 万人、约 40 万个交互式会话的隐私保护分析。它建立在此前研究的基础上——那些研究关注 Claude Code 会话中的自主性衡量指标，以及 Claude Code 如何改变 Anthropic 内部的工作[3]。在这里，我们提出一套描述交互式 AI 编程助手使用的框架：做了什么样的工作、谁在做、是否成功。我们关注通过命令行界面（CLI）、Claude.ai 或 Claude Code 桌面应用使用的 Claude Code[4]。通过追踪智能体编程的使用如何随模型变强而变化，我们能更好地理解这些工具如何影响编程专业人士和知识工作者的劳动力市场。

Claude Code 上发生的事，可能是知识工作走向何方的一个预演——随着 Agent 嵌入到非编程工作中。我们发现 Claude 正在处理更复杂、更有价值的任务。同时，智能体编程中仍然存在清晰的劳动分工：人决定做什么，Agent 决定怎么做。

我们还看到证据表明，是领域专业能力、而非编程熟练度，在放大这个工具有效使用。具体而言，领域专家更常成功，也更容易从错误和误解中恢复。然而专家与中级用户之间的差距并不大——这暗示对某个领域的足够熟练，就足以把工具用得几乎和那些有深度精通的人一样好。

这些发现让我们对劳动力市场可能发生的转变有了初步判断。在我们的数据中，成功由一个人对自己要解决问题的理解程度决定，而非他是否受过编程训练。如果这种模式在整个经济中成立，那它暗示：智能体编程工具可能在吸收一些实现密集型工作的同时，也在奖励那些在工作中对所解决问题有扎实理解的人。编程 Agent 不是在替代领域专业能力——工作者带给 Agent 的理解越多，Agent 能产出的高质量工作就越多。

劳动分工（The division of labor）

人们用 Claude Code 做什么

为了理解人们用 Claude Code 做什么，我们把每个会话归类为九种工作模式（work modes）之一——最能描述该会话试图达成目标的单一活动[5]。其中四种模式直接涉及写代码或维护代码：构建新东西、修复坏掉的东西、测试代码、以及编排其他 Agent 或自动化流水线。另一类是操作软件——部署、配置、运行流水线、监控系统。还有两类更多是在厘清要做什么：理解一个现有系统如何运作，以及在动手前规划一次改动。最后两类采取与代码无关、或代码只是最终产物的附带品的行动：分析数据，以及通过演示文稿和其他文字类文档进行沟通。

约 56% 的会话由写代码（25%）、修代码（26%）或测试与编排代码（5%）构成。操作软件占 17%，14% 的会话是规划或探索，13% 产出分析或文字（图 1）。

我们对每个会话的分类方式是：让一个模型阅读它的对话记录（transcript），然后用我们的隐私保护分析工具，对照每个会话自动记录的遥测数据（telemetry）进行核验——包括是否有任何代码行被新增或删除。这两个来源高度一致——例如，我们分类器标记为创建或修改代码的会话中，超过 90% 在遥测数据中显示了代码变动。详见附录。

谁决定什么

Claude Code 有多自主？能力评估表明天花板很高且在上升：在 METR 时间跨度评估这类基准上，前沿模型现在能自主完成那些需要一个人数小时才能完成的软件任务，一路穿越障碍。但实际使用究竟是什么样？这里，我们看真实会话中由人和由 Claude 各自做了多少转向（steering）。

我们从两个角度研究这个问题。首先，关注人们在多大程度上把决策托付给 Claude；其次，看他们给 Claude 多少动作。为了理解一个会话中的决策划分，我们构建了一个基于会话内容的、隐私保护的决策归因分类器（decision attribution classifier）。我们让分类器列出一个会话中所有有意义的决策。我们把这些决策分为规划（做什么、采取哪种方案、什么算完成）和执行（改哪些文件、写什么代码、用什么语言、跑哪些命令）。分类器随后把每个决策归因于 Claude 或用户，给每个会话两个数字：用户的规划决策占比、用户的执行决策占比。

平均而言，人们做出约 70% 的规划决策，但只做出 20% 的执行决策（图 2）。在实践中，智能体编程有清晰的劳动分工——人决定做什么，Agent 决定怎么做。

为了理解一个会话中动作的委托，我们看会话的结构而非内容。一个 Claude Code 会话涉及 Claude 和用户来回交换提示词（来自用户）和动作（由 Claude 执行）——用户写一条提示词，Claude 就去做一些活，然后用户再写一条，如此往复。在一个典型会话中，大约有四个这样的回合。在我们 10 月到 4 月的历史数据中，用户发送的每条提示词平均会触发约 10 个由 Claude 执行的动作——有时超过 100 个[6]。在每个回合里，Claude 读文件、改代码、跑命令，平均输出 2400 个词。

Claude 在两次"签到"（check-in）之间做多少，很大程度上取决于谁在做决策。当用户保持对执行的控制（即做出 80% 以上的执行决策）时，Claude 每个回合采取的动作更少（约 8 个）。而当 Claude 掌控规划（即做出 80% 以上的规划决策）时，它采取的动作数量最多（约 16 个）。

专业能力层级（Level of expertise）

从每个对话记录中，Claude 在一个五分制量表上对用户在该任务上的表观专业能力进行评级，从新手（novice）到专家（expert）。专业能力分类器寻找三个信号：用户表达指令的精确程度、他们要求 Claude 验证什么、以及是用户倾向于纠正 Claude 还是 Claude 倾向于纠正用户。注意，专业能力捕捉到的东西与职位头衔或一般能力相当不同，而且关键的是，它是任务特定的。一个资深工程师第一次问 Rust 问题，在 Rust 上就是新手。一个从没用过 Python 的会计，但能精确告诉 Claude 一个 Python 脚本必须执行哪些对账规则，并能在月末结账时抓住它处理错的边界情况——那他在这个任务上就是专家。

下表展示了我们如何在分类器中定义每个专业能力层级，以及来自公开编码 Agent 会话数据集 SWE-chat 的一个示例请求。被归类为新手的对话给出的是泛泛的指令，没有暗示任何领域特定知识。专家对话则传达了对代码库和技术环境的深度了解。

我们量化了专业能力如何与 Claude 每条提示词的产出和活动相关。在典型的新手会话中，每条提示词触发约 5 个 Claude 动作和约 600 个词的输出；而专家会话触发的动作链长两倍多（12 个动作）、输出是五倍（3200 个词）（图 3）。新手与专家会话之间的这种差距，出现在每一种工作和每一个任务价值区间里。

这些指标补充了我们此前那份 Claude Code 报告中的自主性指标——后者追踪 Agent 运行多久、人们多频繁地自动批准它的动作。我们的决策归因指标则捕捉的是整个会话中谁做出了实质性决策，而我们的"每条提示词产出和动作"指标衡量的是每条人类提示词触发多少来自 Claude 的自主活动。

谁在用 Claude Code，做什么

用户。为了理解是谁在做这些工作，我们从会话对话记录中推断每个用户的职业，把它映射到劳工统计局标准职业分类（SOC）分类法中的 23 个主要组别之一。分类器被指示只依赖这类信号：Agent 在会话开始时加载的项目上下文、文件的名字和结构、他们引用的任何工件（如法律文件、临床数据、财务报告、一份课程），以及他们使用的词汇[7]。它被明确指示不要把"编码"这一行为本身当作编程职业的证据。一个会话只有在有明确信号表明软件或数据工作是用户的本职时，才被归入编程 SOC 代码（计算机与数学职业）。一个律师构建一个脚本来自动标记一个合同文件夹中缺失条款的会话，会被映射到法律职业——即使该会话的工作主要是软件。当没有关于用户职业的信号时，该会话就保持未分类。

我们在约 70% 的会话中能够推断出职业。在这个集合中，计算机与数学职业（涵盖大多数软件相关工作的类别）不出意料是最大的组。其次大的是商业与财务运营；艺术、设计与媒体；管理；以及生命、物理与社会科学。我们样本中增长最快的非软件职业组是管理、销售和法律职业。

工作。用 Claude Code 所做工作的构成在 2025 年 10 月到 2026 年 4 月之间发生了显著变化。最清晰的变化是，花在修复坏代码上的会话占比从 33% 降到了 19%（图 4）。取而代之的，是围绕代码的工作份额更大了。操作软件从 14% 增长到 21%。写代码和数据分析大约翻倍，从约 10% 增长到约 20%。

任务本身也变得更有价值。我们通过询问这类工作在自由职业市场上要花多少钱，来近似每个会话的经济价值——并对照一个真实招聘信息的公开数据集进行校准。按这个衡量，会话平均估算价值在 10 月到 4 月之间上升了 27%。这种上升在许多种类的工作中都成立。构建、操作和修复型任务的价值都增长了大约三分之一或更多（分别约 43%、34% 和 32%）。这些价格估计是粗略的，所以我们主要用它们来随时间比较任务彼此，而不是当作可字面解读的美元数值[8]。

成功取决于用户带来什么（Success depends on what the user brings）

一个任务的估算价值是一种感知 Claude Code 如何帮助人们工作的方式。另一个角度是看多少会话成功，以及一个会话的哪些特征与成功相关联。在我们所有的成功指标中，我们都看到一个清晰的模式：一个人在一个会话中展现的专业能力越强，成功的可能性越高。增益的大部分集中在专业力量表的低端——新手会话与中级会话之间的差距，比中级与专家之间的差距更大。

在转向成功会话的特征之前，我们应该精确说明如何衡量成功。我们观察不到用户的真实世界结果，也无法直接问他们是否从 Claude 那里得到了想要的东西。相反，我们依赖两个互补的、基于对话记录的指标。第一个是判定型成功（judged success），来自一个阅读完整对话记录并决定当事人是否成功做到其目标（选项：成功、部分成功、失败、无明确目标）的分类器。两个配套分类器随后评判该判断的证据强度，以确定验证型成功（verified success）。一个成功信号分类器寻找成功的可验证证据——具体而言，它寻找匹配该工作的 git 活动（如提交和 PR）、通过的测试套件，以及用户的明确肯定。它把会话从"无信号"评到"弱信号"（1）再到"多个硬信号"（5）。一个平行的失败信号分类器评断事情出错的证据——错误、失败测试、重试、用户对产出物推回（push back）。验证型成功要求会话既被判定为成功、又有至少一个可验证的硬信号。在以下分析（关注会话成功或失败的程度）中，我们排除了被归类为"无明确目标"的会话，它们约占我们完整样本的 7.7%。

专业知识的回报（The returns to expertise）

那么哪类会话最成功？事实证明，一个会话的专业能力评级对会话的成功影响很大。

有人可能担心专业能力并非真正的驱动因素——也许专家只是挑选了不同的任务，或以其他方式不同。在本节中，我们通过比较做同类工作、同等估算价值、同月份、同一主题、来自同一大类职业的人的会话，并问结果如何随这个人被评定的专业能力而不同，来部分地回应这个担忧。

在我们所有的成功指标中，一个人展现的专业能力越强，会话成功的可能性越高。一个被评为新手的会话，在最严格的指标（验证型成功）上达到 15% 的时间，达到至少部分成功 77% 的时间。一个被评为中级或更高的会话，验证型成功达到 28-33%，部分成功达到 91-92%（图 5）。

在每个指标中，增益的大部分来自从新手到中级的跨越；在中级与专家之间，斜率下降。

一个类似的梯度也出现在中途遇到挑战的会话中。我们说一个会话遇到麻烦（hit trouble），是指失败信号记录了失败的可验证证据——可能是错误、失败测试、多次尝试做同一件事，或用户表达挫败或不满。在遇到麻烦的会话中，验证型成功的份额从新手会话的 4% 上升到专家会话的 15%，并控制了上述所有变量（图 5）。看更宽松的指标，我们发现至少部分成功的份额对新手中是 60%，对中级到专家会话是 80-81%。

我们也追踪反向关系——专业能力与各种失败指标。注意，在这个分析中，被判定为失败的会话是那些连部分成功都没有的。我们说一个麻烦会话被放弃（abandoned），是指它被判定为失败且零行代码被写出：用户表观为新手的会话有 19% 以放弃收尾，而其他所有人只有 5-7%。换句话说，最缺乏经验的用户在自己苦苦追求结果未果时更可能放弃。专业能力的部分价值，似乎在于把 Agent 引向正确方向的能力[9]。

职业可能不如专业能力重要（Occupation may matter less than expertise）

在软件相关职业中的人，整体上约 30% 的会话达到验证型成功，而来自其他职业的用户约 26% 的时间达到验证型成功。在产出代码的会话（即至少新增或修改一行代码的会话）中，这两个数字分别是 34% 和 29%（图 6）。软件相关职业与其他职业之间的差距，在我们更宽松的成功定义下缩小了——两组在产出代码的会话中达到至少部分成功的比例分别是 89% 和 88%。这五个点的差距很小，而且七个月来既没有扩大也没有缩小，即使两组的成功率都在上升。在产出代码的会话中，我们数据集中十个最大职业的每一个，在成功率上与软件工程师的差距都在七个百分点以内。管理职业在验证型成功上最高，略高于软件工程职业。他们更高的验证型成功率可能反映了可迁移到指挥 Agent 的管理技能。但也可能部分反映了我们的测量：验证部分依赖于对话记录中的明确确认，而管理者可能更倾向于在得到他们要的东西时表达出来[10]。

展望（Looking ahead）

本报告的结果提供了一个正在浮现的画面：智能体编程如何放大某些形式的知识与技能，同时替代另一些。在产出代码的会话中，每一个主要职业都以与软件相关职业相差几个百分点内的速率成功。看起来，编程 Agent 正在让编程背景对成功编程变得不那么相关。

同时，成功的会话更可能展现领域专业能力。被评为专家的会话达到验证型成功的频率，是新手的两倍多；而当一个会话遇到麻烦时，新手以数倍于其他所有人的比率放弃会话。协作的形态给这个画面增添了色彩——领域专家能引导 Claude 用每条指令做更多工作。所以，把 Claude 引向成功的能力，更多来自对某个领域的掌控，而非写代码的能力。一个在任何领域拥有这种掌控的人，现在也许能够做到他以前做不到的技术工作。一个没有任何这种专业能力的人，从同一个工具里得到的会少得多。 而且增益大多来自胜任（competence），而非精通（mastery）——对领域的可工作的掌握（a working grasp）能捕获大部分收益，而深度专门化只在其上多加一点点。

这些发现是初步的。和我们大部分研究一样，我们无法衡量真实世界结果——比如一个会话中写的代码是否真的被使用还是随后被丢弃，或者它是否产出了一个有经济价值的工件。此外，本报告排除的非交互式使用是相当大份额的活动，开发衡量它的框架是未来工作的优先项。而我们所有对会话的分类都依赖一个模型对对话记录的阅读。在附录中，我们展示了我们的分类器以预期方向追踪独立遥测数据，并在大多数会话上与一个强参考模型一致。但分类器在大规模上验证仍然有挑战，而 Claude Code 会话增加了进一步难度——它们可能太长太复杂，以至于人类标注无法作为基准真相（ground truth）。

本报告中的画面将随着模型、用户以及他们之间劳动分工的变化而更新。我们希望这些指标能让我们追踪有重大影响的转变。例如，如果专业知识的回报随时间开始下降，那将暗示模型开始提供用户目前带来的那种核心判断，而这些工具的收益正在从领域专家扩展到更广人群。如果软件职业之外用户成功完成的编程会话份额继续增长，那可能表明软件生产正在成为每个领域日常工作的一部分，而非单一职业的产物。这些转变将改变谁从智能体编程中受益、受益多少，并对劳动力市场中什么最受重视产生影响。

脚注（精选）：[1] 首次研究（覆盖 12.8 万个公开仓库）检测到截至 2025 年 10 月底约 16-23% 的项目有 Agent 活动；后续研究用同样方法发现那之后创建的项目采用率高出两倍多。[2] 这里衡量的是 Claude Code 处于活跃运行的小时数，而非用户打字给 Claude 的动手时间。[4] 排除了通过第三方 IDE（如 Cursor）和 SDK 的使用，以及 “headless” 模式（claude -p "<prompt>" 单提示词）。[5] 本报告所有分类器使用 Claude Sonnet 4.6。[6] 每条提示词动作数的长尾很长——约 2% 的会话平均每条提示词超 100 个动作，约 1/270 超过 200 个，约 1/2300 超过 500 个。[9] 以"遇到麻烦"为条件会为不同用户选出不同的会话——专家整体上更少遇到麻烦，所以他们遇到的麻烦会话很可能是在更难的问题上。[10] 即使模型把管理者误分类，用于判断用户可能是管理者的信号——也许在任务如何被委托和规约的方式上——倾向于与更大的成功相关。换言之，也许表现得像个管理者本身就带来更大的成功。

深度解读

这篇文章回答的问题： 当 Agent 编程从"程序员工具"变成"人人都能用的工具"，到底什么能力决定了一个人能不能用好它——是编程能力，还是领域知识？

这篇文章应该回答但没回答的问题： 一个会话"成功"（写过代码、过了测试）真的等于它在现实里有用吗？非程序员的"成功"花了多少时间和成本？被排除在外的 headless/SDK/Cursor 使用（体量巨大）会不会给出完全不同的结论？

Part 1 · Magazine Article：Anthropic 用 40 万份会话，想证明一件对自己有利的事

先说清楚这是一篇什么样的文章。它挂在 Anthropic 官网 “Economic Research” 栏目下，作者阵容是五位经济学家（Zoe Hitzig 等，其中 Hitzig 有公共经济学和 AI 治理的学术背景），通篇是经济学论文的写法——有控制变量、有回归、有置信区间、有附录、有引用格式。它不是产品营销，但它确实服务于 Anthropic 的商业叙事。这个判断必须先摆出来，否则你会被它严谨的措辞带着走。

核心论点只有一句

“编程 Agent 不是在替代领域知识，而是在放大它。”

支撑这句话的数据骨架是三条：

1. 劳动分工是清晰的：人做 70% 的规划决策（做什么），Claude 做 80% 的执行决策（怎么做）。
2. 领域专业能力（不是编程能力）决定产出和成功率：专家用户每条提示词触发 12 个动作、3200 词输出，是新手（5 个动作、600 词）的两到五倍；专家会话验证型成功率达 28-33%，新手只有 15%。
3. 职业的护城河在塌：产出代码的会话里，非软件职业与软件工程师的成功率只差 5 个百分点（29% vs 34%）；管理职业甚至反超。

最后一条是整篇文章最有"杀伤力"的发现，也是最该被带着审慎读的一条。

方法论拆解：这套衡量体系才是真功夫

这篇报告真正值得收藏的，不是结论，而是它怎么把"一个人用 Agent 干活好不好"这件极主观的事，量化成可比的数字。它建了一套三层衡量脚手架：

最巧妙的是专业能力评级的设计：它明确不是在评"你职位多高、会不会写代码"，而是评"你在这一件事上懂不懂"。所以会出现报告里那个漂亮反例——资深工程师第一次写 Rust 是新手，不懂 Python 的会计只要能把对账规则说清楚、还能抓出月末结账的边界 case，就是专家。这个分类器的设计哲学本身，就是文章的结论：它把"懂行"从"会写代码"里剥离了出来。

还有一个被很多人会忽略的工程细节：每个分类器都对照了独立遥测数据核验（比如分类器说"这会话改了代码"，就去查 git 是否真有代码行变动，一致率 >90%）。这是为了防止"模型读 transcript 自己骗自己"——一个用 LLM 评判 LLM 的系统，最容易陷入循环论证，作者用硬遥测打了这个补丁。

七个月里的三条趋势线

把时间维度叠进去，画面更生动：

xychart-beta
    title "Claude Code 工作构成变化（2025.10 → 2026.4）"
    x-axis ["修复代码", "操作软件", "写代码+分析"]
    y-axis "会话占比 %" 0 --> 35
    bar [33, 14, 10]
    bar [19, 21, 20]

（每组两根柱子，左为 2025.10 起点、右为 2026.4 终点。）修复代码腰斩（33%→19%），围绕代码的"外围工作"（操作、分析、写文档）全面上涨，任务平均估值 +27%。这个趋势的潜台词是：用户从"让 Agent 帮我修 bug"进化到了"让 Agent 端到端跑起来一件事"。 修复占比下降，很可能不是 bug 变少了，而是用户能做的事的边界外扩了——能部署、能跑流水线、能出分析报告了，修 bug 自然就被稀释了。

三个该打的问号（压力测试内化）

这篇文章我得给你三个不能不说的漏洞，否则你就是被 Anthropic 的叙事牵着走：

① “成功"的定义天然偏软，且偏向特定人群。 verified success 要求"判定成功 + 硬信号（git commit / 测试通过 / 用户确认）"。但一个工程师可能用 Claude 评估完一个方案后，正确地决定不做——没有 commit，于是这会话被算成"没成功”，可它恰恰是高质量的决策。HN 评论里 colin_jack 就抓了这点。更狡猾的是，测试通过是弱信号：你加了新功能但没加测试，旧测试全过，分类器就以为成功了。报告自己在脚注里承认"无法衡量真实世界结果——代码是否真的被使用还是被丢弃"。

② 衡量偏差可能人为抬高"管理者"。 verified success 部分依赖 transcript 里的用户明确确认。管理者天生更爱在得到想要的东西时说"对，就这样"——于是他们的成功率被说话习惯抬高了。作者自己点破了这点（脚注 10），但这意味着"管理职业成功率反超软件工程师"这个最吸睛的结论，要打个折。

③ 被排除的数据可能彻底改变结论。 报告排除了 headless 模式（claude -p）、第三方 IDE（Cursor）、SDK。这些恰恰是程序员和重度自动化场景的主战场。 如果把它们算进来，“非程序员和程序员成功率只差 5 个点"的结论很可能要重写——因为程序员的 headless/CI 自动化成功率可能高得多，只是没进这个样本。报告把这叫"未来工作的优先项”，但这是个能让核心结论翻盘的窟窿。

利益相关：为什么 Anthropic 要发这篇

把立场摆明：Anthropic 是 Claude Code 的开发商，这篇报告的结论（“人人都能用"“领域知识比编程能力重要"“你的专业知识不会被替代反而被放大”）每一条都在降低使用门槛的心理阻力、扩大潜在用户池、安抚知识工作者"你不会被取代”。这是商业上极其有利的叙事。

但公允地说，它的学术诚意也是真的：公开方法、用独立遥测交叉验证、承认所有局限、用了 Hitzig 这种有声誉的外部研究者署名、不卖绝对美元价值只谈相对变化。它不是软文，是一篇"立场友好但方法可检验"的研究。你要做的是接受它的数据，审慎对待它的 framing。

精选评论（Hacker News）

colin_jack：成功的定义可能在两个方向上产生偏差。一个工程师可能用 Claude 评估一个方案后，出于技术原因正确地决定不做——那不会有 commit，于是这个会话很可能不算验证型成功，哪怕这是正确的决定。另外，“测试通过"是不是比看上去更弱的信号？如果我加了新功能但没加测试，现有测试全过，但那并不告诉你我的新代码到底 work 不 work。公平地说，报告末尾也承认了这点。

原文：Seems like the definition of success could skew things… To be fair this is accepted near the end.

offaxis：专业能力的一部分，是专家脑中带着的那份 checklist——需要做什么？什么算完成？什么绝不能动？Agent 什么时候该停？什么信号能验证成功？真正重要的问题是：这份专业能力该怎么传给 AI——不只是当成更多 context，而是以一种 Agent 在执行前就能用的形式。

原文：I think part of expertise is the checklist experts carry in their heads… The important question is how that expertise should be passed to the AI.

I_am_tiberius：我不想让他们分析我的数据。如果想知道，应该通过发一个调查问卷链接来问我。

原文：I don’t want them to analyze my data. If want to know, they should ask me by sending me a link to a survey.

（offaxis 的洞见尤其值钱——他把"专家凭什么是专家"拆成了一份可复用的 checklist，并指出真正的 frontier 是把这份 checklist 变成 Agent 执行前的约束，而不是塞进 context window。这恰好是现在 CLAUDE.md / 系统提示词 / guardrails 这条技术线的本质。）

Part 2 · Socratic Dialogue：所以，程序员的护城河塌了吗？

学生（尾巴）：这篇文章结论是不是说，编程这技能以后不值钱了，谁都能用 Claude Code 把活干了？

老师：先别急着下这个结论。它说的不是"编程不值钱了”，而是”会不会写代码这件事，对你能不能用好 Agent 的解释力在下降"。这俩不是一回事。

学生：有啥区别？不都是说编程不重要了吗？

老师：区别在于"成功"被谁定义的。报告里的 success 是"会话层面"的——这个会话有没有写出代码、过了测试、用户满意。它没有衡量这代码在真实世界里活下来没有、有没有真正解决业务问题。一个会计能用 Claude 写出跑通的 Python 对账脚本，这确实是个成功；但这跟一个资深工程师用 Claude 交付一个高可用、可维护、能扛住生产流量的系统，是两个量级的"成功"，报告把它们放在同一个秤上称了。

学生：那"非程序员和程序员只差 5 个点"这个数据，不就是被稀释了吗？

老师：对，这是关键。而且还有第二层稀释——报告把程序员的主战场排除在外了。程序员大量使用 headless 模式、CI 集成、Cursor 这类 IDE，这些全被报告剔除了。剩下的"交互式会话"里，程序员和会计的差距当然小。这就像你把篮球运动员扣篮的场景都删掉，然后说"篮球运动员和普通人投篮命中率差不多"。

学生：好吧，那它真正站得住的结论是啥？

老师：一个，而且很硬：指挥 Agent 的能力，来自对问题的理解，而非对编程语法/工具的熟练。那个会计的例子就是证据——不懂 Python，但对账规则门儿清，还能抓住边界 case，于是他成了那个任务上的"专家用户"。这条结论对所有人都是利好，包括程序员自己：你的领域深度，现在能通过 Agent 放大成过去需要一个团队才能完成的产出。

学生：那对我来说，怎么把自己训练成"专家用户"？报告里说专家每条指令触发 12 个动作、新手才 5 个。

老师：报告隐含的配方，其实 offaxis 那条 HN 评论说透了。专家用户脑里有份 checklist，而且会把它外化成给 Agent 的约束：① 要做什么、② 什么算完成（验收标准）、③ 什么绝对不能动（护栏）、④ 什么时候该停、⑤ 用什么信号验证。你回想一下你自己用 Claude Code 的 CLAUDE.md——那些"诚实规则"“先读后写"“禁止裸启动进程”，本质就是这份 checklist 的工程化。你已经在用专家方式用 Agent 了，只是可能没意识到这就是报告在量化的那个东西。

学生：所以最后一句——报告说"收益大多来自胜任，而非精通”，中级和专家差距很小，这怎么理解？

老师：这是个对普通人极其友好的结论：你不需要成为世界级的专家，只需要达到"working grasp"（可工作的掌握），就能吃到 80% 的红利。 从 0 到 60 分的跃升巨大，从 60 到 95 分的边际收益很小。这暗示一件事——与其在单一领域钻到极致，不如快速掌握多个领域的 working grasp，因为每一个领域你都能用 Agent 兑现。 对你这个同时碰 AI 产品、投资、技术写作、内容的人，这几乎是量身定做的启示。

学生：那有什么是这篇报告没敢说的？

老师：它没说出口的那半句是：如果未来"专业知识的回报"开始下降，那就是模型开始替你做判断了——那时谁都不安全，专家的护城河也会被侵蚀。 它在"展望"里埋了这根引线，但没展开。这恰恰是最该盯的指标：盯住这个数字，它上升=你在增值，它掉头=你在被替代。这个问题，留给你自己接着想。

Part 3 · 个性化洞察：这条数据对你的四个具体含义

① 你正好站在报告定义的"完美 Agent 用户"画像上——把它变成可对外讲的故事。 你是 QA 工程师出身（强验证思维 + 能定义"什么算完成"）+ 全栈能力（能听懂 Claude 的执行决策对不对）+ 重度 Claude Code 用户。这三者叠加，正是报告里"领域专家用户"的原型——你的每条指令触发 12 个动作、产出是新手五倍的那个画像。为什么跟你有关：报告给了你一个权威背书的叙事框架（“是领域知识而非编程能力在起作用”），这对你做技术自媒体、写 AI 产品营销、甚至招人（招懂行的而非只会写的）都是现成的弹药。你可以怎么做：把这条写进你产品的"为什么是我们"——你的优势不是"会写代码"，而是"能用 Agent 把领域知识兑现成产品"，这正是报告量化过的高杠杆点。

② 投资视角：编程技能溢价下降、领域知识溢价上升——这指向两类标的。 报告的劳动市场暗示很直接：纯实现型编程工作（外包、低端 CRUD、初级 SWE）的议价权在下降；而能把领域知识 + AI 工具组合起来的人/公司在升值。为什么跟你有关：你关注 AI 行业和美股。你可以怎么做：① 利空端——纯人力外包平台、低端 IT 服务商的护城河在被侵蚀；② 利好端——垂直行业 AI 应用（法律 AI、医疗 AI、金融 AI）的价值在上升，因为它们的壁垒恰恰是报告说的"领域知识"，而 Agent 把"实现"这个曾经的门槛拉平了。报告里"增长最快的非软件职业是管理/销售/法律"这条线，就是找垂直 AI 标的的方向图。

③ 创业视角：报告在偷偷告诉你，“会编码"已经不是创业壁垒了。 “非程序员产出代码的成功率只比软件工程师低 5 个点”——这句话对独立开发者/创业者是双刃剑。为什么跟你有关：你想做自己的 AI 产品。你可以怎么做：别再以"我能写代码"作为核心竞争力去想产品，因为别人配一个 Agent 也能写。真正的壁垒回到报告反复强调的那条——对某个问题/某个用户群体的深度理解。你的产品立项标准应该改成：“我对这个领域的理解，是不是一个配了 Claude Code 的聪明外行花三个月也追不上的？” 如果是，就值得做；如果只是"我会实现”，那护城河是纸糊的。

④ 实操：盯住报告埋的那根引线指标，那是你的"个人 AI 价值仪表盘"。 报告说如果"专业知识的回报"开始下降，就说明模型在替用户做判断。为什么跟你有关：这是你作为知识工作者最该自我监测的单一指标。你可以怎么做：定期自问一个具体问题——“过去一个月，我自己做的判断里，有多少是模型现在还做不了、但下个月可能就能做的？” 把这些判断列出来，按"模型替代难度"排序。难度最高的那几条（比如跨领域综合判断、对人的判断、审美和品味），就是你要持续投入、且 Agent 越强越值钱的地方。难度低的那几条，趁早交给 Agent，别恋战。

金句： 人决定做什么，Agent 决定怎么做。 People decide what to build, and the agent decides how to build it.

编程 Agent 不是在替代领域知识——工作者带给 Agent 的理解越多，Agent 能产出的高质量工作就越多。 Coding agents are not substituting for domain expertise—the more understanding a worker brings to an agent, the more quality work the agent is able to do.

把 Claude 引向成功的能力，更多来自对某个领域的掌控，而非写代码的能力。 The ability to steer Claude toward success comes more from command of a domain than from the ability to write code.