你是不是也踩过这些坑：
- 工具换了三轮，提示词模板抄了满屏，任务一复杂还是半途而废
- 同事说「让 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 真正放大「懂问题的人」，而不是放大「会粘贴提示词的人」。
先换问题框架：缺的不是更强模型，是可验收的规划权
| 你现在常做的 | 它假装解决了什么 | 它其实没解决 |
|---|---|---|
| 换更大模型 / 更贵套餐 | 能力上限 | 你是否说清「完成标准」 |
| 堆提示词模板 | 输出格式 | 领域约束、边界案例 |
| 「全自动 agent」宣传 | 人手成本 | 规划权是否被悄悄让渡 |
| 只看最终 diff 行数 | 忙碌感 | 是否 commit、是否过测、是否可回滚 |
数据里的分工很清楚：人定 what，模型定 how。
你若在 what 层含糊，how 层再勤快也是在高速做错的方向上挖坑。
问题 1：为什么「提示词工程」救不了复杂任务？
现象
同一仓库、同一工具：
- A：一句话「帮我改登录」→ 模型改完一半就停，或改到无关模块
- B：写清目标用户、失败码、兼容旧 token、必须过的测试 → 模型能连着读文件、改实现、跑测
根因
会话里的「专长」不是职位，而是任务专属信号：
- 指令是否带领域精度（规则、接口契约、业务不变量）
- 你要求模型验证什么（测试、日志、对照表）
- 纠错方向：是你在纠正模型，还是模型在纠正你
专家不是「写更多代码的人」，而是能在出偏时把 agent 拽回正确约束的人。
卡住时：新手会话约19%被判定为放弃（失败且零行有效代码改动），中级/专家大约5–7%。
你可以怎么做
- 把每条主指令拆成四块（强制模板）
- 目标（可观察结果）
- 非目标（明确不改什么）
- 验收（测试名 / 命令 / 日志关键字）
- 风险边界（数据、权限、回滚）
- 禁止「帮我看看 / 优化一下」作为唯一输入——这类指令在分类器眼里接近 novice。
- 失败后先写约束再重生：把报错、错误假设、你拒绝的方案写进下一轮，而不是清空重来。
问题 2：团队为什么总把 AI 工具发给「会写代码的人」？
现象
名额、账号、培训优先给研发；业务、财务、法务、运营就算有清晰规则，也很难申请到「能跑通端到端」的 agent 环境。
根因
旧假设是：会写代码 = 能指挥代码 agent。
新信号是：在产出代码的会话里，职业是否「写代码」对成功率的影响，弱于任务专长；管理类等职业甚至在部分可验证成功指标上不落下风——更像是会拆任务、会确认完成的技能在迁移。
你可以怎么做
- 账号与培训按「问题所有权」分配，不按是否科班程序员。
- 为非研发角色提供受控脚手架：固定仓库模板、只读生产副本、一键测试脚本、禁止无审批的外网与密钥。
- 绩效上奖励「写清规则 + 抓住边界 case」的人，而不是「本周生成了多少行」。
问题 3：为什么你的 agent 会话越来越像「修修补补」？
现象
周报里全是：修 CI、修类型错误、修线上小问题；新功能与数据/运维类工作推不动。
根因
早期 agent 能力不稳时，自然会堆在fix模式。数据里七个月趋势是：修 bug 占比近乎腰斩，运维、数据分析、文档写作等占比上升——工具在从「补丁机」变成「交付面更宽的执行层」。
若你的团队指标仍只统计「修了多少 issue」，会系统性低估 agent 该去做的build / operate / analyze。
你可以怎么做
- 会话/工单打标至少四类：
build | fix | operate | analyze/write，周会看占比而不是只看 fix 清零。 - 给 agent运维与分析只读通道（部署预发、查指标、拉日志），避免只会改源码。
- 估算任务价值可用粗口径：对标外包报价或历史工时；关注相对上升，别迷信精确美元数。
问题 4：什么叫「成功」？为什么你感觉 AI 很猛，交付却对不上？
现象
聊天里模型说「已完成」，本地一跑就红；或者 diff 很大，但从未进主干。
根因
研究里区分了多层成功：
- 判定成功：从对话看是否达成意图
- 可验证成功：还要有硬信号——测试通过、git 活动与工作匹配、用户明确肯定等
只盯对话完成感，会严重高估。新手与中级在「可验证成功」上的分叉，比「感觉上差不多做完了」更大。
你可以怎么做（最小验收门禁）
每个 agent 任务关闭前勾这三条（缺一不可）：
- 命令级证据：贴出测试 / lint / 关键路径手动验证输出
- 版本级证据：commit 或 PR 链接，说明与需求的对应文件
- 人的明确判定：一句「接受 / 不接受 + 原因」，禁止默认当成功
没有硬信号的「看起来写完了」，一律记为partial，不得进发布清单。
问题 5：要不要追求「专家级」才能用 AI？
现象
有人觉得「我不是大牛，用 agent 也白搭」；另一拨人觉得「反正模型会，我不学业务细节了」。
根因
曲线形状很关键：新手 → 中级跃迁最大；中级到专家仍有收益，但斜率变缓。
含义是：
- 你不需要成为该领域的顶级专家才能吃到红利
- 但你不能长期停在 novice：含糊目标、不验证、卡住就弃
- 模型变强时，若「专长回报」开始下降，才可能意味着判断力被模型部分接管——目前数据仍显示专长回报稳健
你可以怎么做
- 个人：选一个本职高频任务，用两周把验收清单写到「中级」——能指出模型常见错法。
- 团队：新人 onboarding 先教如何验收 agent，再教快捷键。
- 组织：把「领域文档 / 决策记录 / 接口契约」当作 agent 生产力基础设施，而不是可有可无的 wiki。
本周可执行步骤（建议直接抄进迭代）
| 天 | 动作 | 完成标志 |
|---|---|---|
| Day 1 | 给团队发「目标/非目标/验收/边界」四段指令模板 | 模板进仓库.ai/TASK_TEMPLATE.md |
| Day 2 | 抽查 10 条历史会话，标 novice/intermediate | 至少 5 条补上验收命令 |
| Day 3 | 非研发角色选 1 个真实小任务走通受控脚手架 | 有测试或脚本输出截图 |
| Day 4 | 工单增加 work mode 标签 | 看板能看出 fix 是否过高 |
| Day 5 | 关闭任务强制三证据（命令/git/人判） | 无证据不得点「完成」 |
边界（避免误读）
- 这是交互式会话的隐私保护分析，不覆盖大量 headless / 第三方 IDE / SDK 嵌套用法。
- 成功与专长依赖分类器与遥测交叉验证，不是追踪代码上线后的真实业务 ROI。
- 任务「价值」来自与自由职业帖的粗对齐，适合看趋势，不适合当财务报表。
- 职业推断约覆盖 70% 会话；「管理类更高」也可能部分来自更爱在对话里明确确认。
一句话收束
Agent 正在降低「会不会写代码」的门槛，同时抬高「懂不懂问题」的回报。
别再把升级套餐当主策略——先把规划权、验收权和领域约束抓回自己手里；多数人从新手走到「够用的中级」，收益就比再堆十条万能提示词大得多。
参考来源（原文）
Agentic coding and persistent returns to expertise（2026-06-16）
https://www.anthropic.com/research/claude-code-expertise
