一篇研究引发的思考
2026 年 1 月 29 日，Anthropic 发布了一篇研究：How AI assistance impacts the formation of coding skills（论文原文）。起因是一个矛盾的现象：一方面，Anthropic 自己的研究表明 AI 能将某些任务提速 80%；另一方面，其他研究发现使用 AI 后，人会减少思考投入，把认知负担卸载给 AI。这项研究想回答的问题是：效率提升的同时，你的编程能力还能不能跟着成长，还是会因此退化？
研究团队做了一个随机对照试验（RCT）。52 名初级软件工程师，学习一个他们不熟悉的 Python 库 —— Trio（用于异步编程），模拟的是工作中学新工具的场景。一半人可以用 AI 辅助，另一半手写代码。完成编码后参加测验，覆盖四个维度：调试、代码阅读、代码编写、概念理解。研究者特意侧重了调试、代码阅读和概念理解，理由是：未来越来越多代码由 AI 生成，人类最需要的能力不是写代码，而是审查代码 —— 能看出 AI 写的东西哪里不对、为什么不对。
结果：AI 辅助组平均答对 50%，手写组 67%。其中差距最大的维度是调试能力。手写组遇到了更多报错，但正是在独立解决这些报错的过程中，他们建立了对 Trio 概念的理解。换句话说，AI 帮你绕过了犯错，也帮你绕过了学习新知识本身。
还有一个反直觉的发现：AI 组的完成速度只比手写组快了约 2 分钟，差异不具统计显著性（换句话说，快的这 2 分钟可能只是巧合）。与此同时，部分参与者花了最多 30% 的时间在编写 prompt 上。也就是说，至少在学新东西的场景下，AI 并没有带来预期中的效率优势。
NOTE
当然这项研究也有局限：样本只有 52 人，测的是即时记忆而非长期技能发展，实验场景是学新技能而非运用已有技能。
不过比起”用 AI 会不会变差”这个笼统的问题，研究里更有价值的部分是：AI 组内部的表现分化很大，关键在于怎么用。研究团队通过屏幕录像，分析出了 6 种不同的交互模式。
6 种 AI 编程姿势，你是哪种？
研究团队把 AI 组的屏幕录像做了定性分析，根据参与者与 AI 交互的方式，归纳出 6 种模式。按测验得分分成两组，结果分化明显。
低分组（平均 <40%）有三种模式：
- 全权委托（AI delegation）：全程让 AI 写代码，自己基本不动手。完成速度最快，得分最低。
- 逐步依赖（Progressive AI reliance）：一开始还自己写，但逐渐把所有代码都交给 AI。实验一共有两个编码任务，这组人到第二个任务时已经完全依赖 AI，对应的概念在测验中基本没答对。
- 反复调试（Iterative AI debugging）：自己写代码，遇到报错就让 AI 修，修完再报错，再让 AI 修。看似在积极交互，但始终是把问题抛给 AI，而不是借助 AI 理解问题本身。结果既没有省时间，也没有建立理解，得分也低。
高分组（平均 ≥65%）也有三种模式：
- 先生成再理解（Generation-then-comprehension）：先让 AI 生成代码，然后追问”为什么这样写”。操作上和全权委托组几乎一样，唯一的区别是多了追问理解这一步。
- 代码+解释（Hybrid code-explanation）：要求 AI 生成代码的同时给出解释。花的时间更多，但理解程度更高。
- 概念探究（Conceptual inquiry）：只向 AI 提概念性问题，代码全靠自己写。过程中遇到不少报错，但都是独立解决的。这组是高分组里速度最快的，整体仅次于全权委托组。
高分组和低分组之间最值得注意的对比是：全权委托组和先生成再理解组，操作上几乎一样，唯一的区别是后者多了一步追问。就这一步，得分从不到 40% 拉到了 65% 以上。同时，概念探究组得分最高，速度也仅次于全权委托组 —— 理解得最深的人，反而是高分组里最快的。
我在 fathom 项目里的经历
看到这 6 种模式的时候，我想到了自己最近在做 fathom（一个深度分析本地代码并生成 wiki 文档的工具）时的经历。项目初期我用 BUN 实现 CLI，遇到了依赖安装不稳定的问题，同时我还一心想用 Claude Agent SDK 来简化 agent 开发。这两件事上，我的做法是一样的：遇到问题就让 AI 调，方案不对就让 AI 换，来回几轮，上下文烧了不少，问题都没解决。直到我意识到这样下去不对 —— 不是 AI 不行，是我一直在让它处理表层问题。于是我换了个方式：让 AI 描述当前的整体架构，我自己从数据流转和交互设计的角度审视。跳出细节之后才发现，BUN 依赖的问题远不止表面上的报错，而 Claude Agent SDK 更多是我的一厢情愿，强行引入反而把简单问题复杂化了。最终转向 Go + eino + SubAgents，架构更清晰，问题也解决了。在这个过程中，AI 不再替我做决定，而是帮我验证决定、检查答案。
如果用研究的分类来看，我经历了一个从低分模式到高分模式的切换。但实际工作比研究的分类更复杂 —— 我不是切到了某一种高分模式，而是在不同环节用不同的方式：有时候问概念，有时候让 AI review，有时候让它出方案我来判断。能灵活切换，可能比固定用哪种模式更重要。
四个值得留意的点
犯错引发调试，调试带来理解 —— AI 帮你跳过了犯错，后续的理解也就没了
研究数据很直接：手写组遇到了更多报错，但调试得分反而更高。调试能力不是从看正确代码中长出来的，而是从自己踩坑、自己排查的过程中长出来的。AI 帮你绕过这些报错，等于帮你绕过了学习本身。
经验决定了你能不能”用好”AI
我在 fathom 项目里能从调试循环中跳出来，从架构层面重新审视问题，是因为做了多年后端，对数据流和系统设计有基本判断力。一个初级开发者面对同样的情况，大概率会一直在单点问题上跟 AI 反复消耗 —— 不是因为他不努力，而是他还没有建立起”退一步看全局”的能力。而且他可能根本意识不到，不跳出来从更高维度引导 AI，只会在同一个问题上越陷越深。
IMPORTANT
AI 是一个放大器，但它放大的是你已有的能力，而不是你还没建立的能力。
在不熟悉的领域，你的先入为主会限制 AI 的发挥
影响成长的不只是用 AI 的方式，还有你带着什么样的认知去用它。这一点研究没有覆盖，但我觉得比前两个更值得警惕。我在做 fathom 的时候，预设了要用 Claude Agent SDK，跟 AI 聊的时候直接说”基于 Claude Agent SDK 看看怎么实现”，AI 自然就往那个方向靠。结果是简单问题复杂化，浪费了大量时间才意识到方向不对。问题不在 AI，在于我用自己有限的认知框住了它的探索范围。
类似的情况在社区里也常见。比如最近 Agent Skills 很火，有人想所有场景都套 Skills，但没有理清 SubAgent、Workflow、Slash Command、Skills 各自的适用边界（详见附录）。强行让 AI 往 Skills 上靠，AI 会配合地给你一个方案 —— 但那不一定是对的方案。
CAUTION
AI 不会说”你的前提可能是错的”，它会在你给定的框架里尽力发挥，甚至强化你的偏见。
什么时候该 Vibe，什么时候该深入
并不是每个场景都需要追求深入理解，关键是分清哪些场景值得为成长投入时间。我自己的判断依据很简单：这个东西如果出了问题，我能不能自己发现？ 如果能，Vibe 没问题；如果不能，就值得花时间深入理解。不过要注意：在你不熟悉的领域，“我能发现问题”这个判断本身可能就是错的。这时候一个简单的检验方式是 —— 你能不能向别人解释清楚 AI 给出的方案为什么是对的。如果只是觉得”看着没问题”，那大概率理解还不够。
比如后端开发者搭个前端原型验证想法，基本功能跑通、交互和页面过得去、能验证想法就行，不需要理解每行代码。周末想做个提效的小工具，Vibe Coding 半天搞定，比花几天时间从头学更划算。但如果是核心系统的技术选型，或者你正在学一个新框架，跳过理解这一步，后面大概率要还债。
写在最后
在 Coding Agent 时代，逐行 review 代码已经不现实，真正需要守住的是架构层面的判断力 —— 系统该怎么设计、技术选型对不对、整体方案是否合理。这些判断力不会从 Vibe Coding 里长出来，只能从自己啃过的坑里来。
我在上一篇文章《从 Vibe 到 Spec：我的 AI Coding 工作流》里分享了具体的做法 —— 用 Vibe 探索方向，用 Spec 保证质量。这篇算是从 Anthropic 的研究出发，补上了”为什么要这么做”的认知基础。
AI 能帮你跑得更快，但方向得你自己把握。
希望这篇文章能帮你在用 AI 的时候，分清什么该交给它，什么该留给自己。
附录
关于 SubAgent、Workflow、Slash Command、Skills 的适用边界，这里展开说一下。
Skills（技能包）
Agent 的背景知识库。采用渐进式加载，Agent 启动时只读名称和描述，触发时才加载完整内容。适合反复出现的领域知识 —— 比如你的编码规范、项目的架构模式、某个工具的使用指南。核心特征是被动触发、跨项目复用。如果你发现同一件事跟 AI 解释了三次以上，就该写成 Skill。
Slash Command（斜杠命令）
用户手动触发的快捷操作。用 /command 显式调用，支持参数传递和权限控制。适合日常重复操作 —— 比如 /commit 自动生成提交信息、/release 执行发版流程。核心特征是主动触发、一次性执行。
SubAgent（子代理）
独立的 Agent 实例，拥有自己的上下文窗口。主 Agent 把任务分发给 SubAgent，SubAgent 独立执行后返回结果，中间过程不污染主 Agent 的上下文。适合需要并行处理的复杂子任务 —— 比如同时让一个 SubAgent 做架构分析、另一个做技术方案。核心特征是上下文隔离、支持并行。
Workflow（工作流）
结构化的端到端开发流程。定义阶段性工作（需求 → 设计 → 任务拆分 → 实现 → 归档），每个阶段有明确的输入输出和人工审查节点。适合大型功能开发和需要可追溯性的项目。核心特征是全生命周期管理、规范驱动。
怎么选？
| 你的场景 | 该用 |
|---|---|
| 同一件事跟 AI 解释了三次以上 | Skills |
| 某个操作你每天都手动执行一遍 | Slash Command |
| 多个独立子任务需要并行，或不想污染主上下文 | SubAgent |
| 一个完整功能从需求到交付，需要多轮 review | Workflow |
四者不互斥，可以组合使用。但前提是理清各自的边界，而不是把所有场景都往其中一个上套。
