你是不是也踩过这些坑：

• 工具换了三轮，提示词模板抄了满屏，任务一复杂还是半途而废
• 同事说「让 AI 全自动就行」，结果 PR 里一堆似是而非的实现，你连验收标准都说不清
• 非研发同学开始用 AI 写脚本，团队却仍按「谁会敲代码」分配任务，真正懂业务的人反而被晾在一边
• 出了 bug 只会「再生成一次」，从不会把失败信号变成下一轮约束

一组对约40 万次交互式 agentic coding 会话（约23.5 万人，2025-10 至 2026-04）的隐私保护分析，给出了很工程化的信号：

• 典型会话里，人做约70%的规划决策（做什么、选哪条路、怎样算完成），模型做约80%的执行决策（改哪些文件、写什么代码、跑什么命令）
• 用户在该任务上的领域专长度越高，同一条指令触发的模型工作量越大：新手量级约5 次动作 / 600 词输出，专家量级约12 次动作 / 3200 词输出
• 可验证成功（commit / 测试通过 / 用户明确确认等硬信号）：新手约15%，中级及以上约28–33%；至少部分成功：新手约77%，中级及以上约91–92%
• 收益主要发生在新手 → 中级；中级与专家差距不大——够用的领域把握往往就够吃到大部分红利
• 七个月内，修 bug 类会话占比从约 33% 降到约 19%，运维/数据分析/文档等「围着代码转」的工作在涨；会话的估算任务价值平均约+25%～27%
• 在产出代码的会话里，非软件职业与软件职业的成功率往往只差几个百分点（十大职业组多落在软件组 ±7 个点内）

下面不写论文复述，只写：你怎么改分工、改验收、改提示与门禁，让 AI 真正放大「懂问题的人」，而不是放大「会粘贴提示词的人」。

先换问题框架：缺的不是更强模型，是可验收的规划权

数据里的分工很清楚：人定 what，模型定 how。
你若在 what 层含糊，how 层再勤快也是在高速做错的方向上挖坑。

问题 1：为什么「提示词工程」救不了复杂任务？

现象

同一仓库、同一工具：

• A：一句话「帮我改登录」→ 模型改完一半就停，或改到无关模块
• B：写清目标用户、失败码、兼容旧 token、必须过的测试 → 模型能连着读文件、改实现、跑测

根因

会话里的「专长」不是职位，而是任务专属信号：

1. 指令是否带领域精度（规则、接口契约、业务不变量）
2. 你要求模型验证什么（测试、日志、对照表）
3. 纠错方向：是你在纠正模型，还是模型在纠正你

专家不是「写更多代码的人」，而是能在出偏时把 agent 拽回正确约束的人。
卡住时：新手会话约19%被判定为放弃（失败且零行有效代码改动），中级/专家大约5–7%。

你可以怎么做

1. 把每条主指令拆成四块（强制模板）
   • 目标（可观察结果）
   • 非目标（明确不改什么）
   • 验收（测试名 / 命令 / 日志关键字）
   • 风险边界（数据、权限、回滚）
2. 禁止「帮我看看 / 优化一下」作为唯一输入——这类指令在分类器眼里接近 novice。
3. 失败后先写约束再重生：把报错、错误假设、你拒绝的方案写进下一轮，而不是清空重来。

问题 2：团队为什么总把 AI 工具发给「会写代码的人」？

现象

名额、账号、培训优先给研发；业务、财务、法务、运营就算有清晰规则，也很难申请到「能跑通端到端」的 agent 环境。

根因

旧假设是：会写代码 = 能指挥代码 agent。
新信号是：在产出代码的会话里，职业是否「写代码」对成功率的影响，弱于任务专长；管理类等职业甚至在部分可验证成功指标上不落下风——更像是会拆任务、会确认完成的技能在迁移。

你可以怎么做

1. 账号与培训按「问题所有权」分配，不按是否科班程序员。
2. 为非研发角色提供受控脚手架：固定仓库模板、只读生产副本、一键测试脚本、禁止无审批的外网与密钥。
3. 绩效上奖励「写清规则 + 抓住边界 case」的人，而不是「本周生成了多少行」。

问题 3：为什么你的 agent 会话越来越像「修修补补」？

现象

周报里全是：修 CI、修类型错误、修线上小问题；新功能与数据/运维类工作推不动。

根因

早期 agent 能力不稳时，自然会堆在fix模式。数据里七个月趋势是：修 bug 占比近乎腰斩，运维、数据分析、文档写作等占比上升——工具在从「补丁机」变成「交付面更宽的执行层」。
若你的团队指标仍只统计「修了多少 issue」，会系统性低估 agent 该去做的build / operate / analyze。

你可以怎么做

1. 会话/工单打标至少四类：build | fix | operate | analyze/write，周会看占比而不是只看 fix 清零。
2. 给 agent运维与分析只读通道（部署预发、查指标、拉日志），避免只会改源码。
3. 估算任务价值可用粗口径：对标外包报价或历史工时；关注相对上升，别迷信精确美元数。

问题 4：什么叫「成功」？为什么你感觉 AI 很猛，交付却对不上？

现象

聊天里模型说「已完成」，本地一跑就红；或者 diff 很大，但从未进主干。

根因

研究里区分了多层成功：

• 判定成功：从对话看是否达成意图
• 可验证成功：还要有硬信号——测试通过、git 活动与工作匹配、用户明确肯定等

只盯对话完成感，会严重高估。新手与中级在「可验证成功」上的分叉，比「感觉上差不多做完了」更大。

你可以怎么做（最小验收门禁）

每个 agent 任务关闭前勾这三条（缺一不可）：

1. 命令级证据：贴出测试 / lint / 关键路径手动验证输出
2. 版本级证据：commit 或 PR 链接，说明与需求的对应文件
3. 人的明确判定：一句「接受 / 不接受 + 原因」，禁止默认当成功

没有硬信号的「看起来写完了」，一律记为partial，不得进发布清单。

问题 5：要不要追求「专家级」才能用 AI？

现象

有人觉得「我不是大牛，用 agent 也白搭」；另一拨人觉得「反正模型会，我不学业务细节了」。

根因

曲线形状很关键：新手 → 中级跃迁最大；中级到专家仍有收益，但斜率变缓。
含义是：

• 你不需要成为该领域的顶级专家才能吃到红利
• 但你不能长期停在 novice：含糊目标、不验证、卡住就弃
• 模型变强时，若「专长回报」开始下降，才可能意味着判断力被模型部分接管——目前数据仍显示专长回报稳健

你可以怎么做

1. 个人：选一个本职高频任务，用两周把验收清单写到「中级」——能指出模型常见错法。
2. 团队：新人 onboarding 先教如何验收 agent，再教快捷键。
3. 组织：把「领域文档 / 决策记录 / 接口契约」当作 agent 生产力基础设施，而不是可有可无的 wiki。

本周可执行步骤（建议直接抄进迭代）

边界（避免误读）

• 这是交互式会话的隐私保护分析，不覆盖大量 headless / 第三方 IDE / SDK 嵌套用法。
• 成功与专长依赖分类器与遥测交叉验证，不是追踪代码上线后的真实业务 ROI。
• 任务「价值」来自与自由职业帖的粗对齐，适合看趋势，不适合当财务报表。
• 职业推断约覆盖 70% 会话；「管理类更高」也可能部分来自更爱在对话里明确确认。

一句话收束

Agent 正在降低「会不会写代码」的门槛，同时抬高「懂不懂问题」的回报。
别再把升级套餐当主策略——先把规划权、验收权和领域约束抓回自己手里；多数人从新手走到「够用的中级」，收益就比再堆十条万能提示词大得多。

参考来源（原文）
Agentic coding and persistent returns to expertise（2026-06-16）
https://www.anthropic.com/research/claude-code-expertise