企业官网建设流程全解析

网站怎么上百度,烟花代码编程,网站内容创造,民治营销型网站设计哪家好近日#xff0c;Anthropic 发布了 《How AI assistance impacts the formation of coding skills》 #xff0c;这篇论文主要核心解释了一个问题#xff1a;AI 写代码能让你更快交付#xff0c;但会不会让你“学得更慢、懂得更少”#xff1f; 因为 Anthropic 发现#…近日Anthropic 发布了 《How AI assistance impacts the formation of coding skills》 这篇论文主要核心解释了一个问题AI 写代码能让你更快交付但会不会让你“学得更慢、懂得更少”因为 Anthropic 发现在对 Claude.ai 数据的观察性研究中虽然 AI 可以将某些任务的速度提高 80%但这种生产力的提升是否会带来一些弊端呢因为有其他研究表明当人们使用 AI 辅助时他们对工作的投入度会降低 投入的精力也会减少 换句话说他们把自己的思考工作交给了人工智能。或者再贴近生活点你多久没有自己从头到尾阅读一篇文章或者论文了你是不是都是通过 AI 去总结和思考是不是只是在获得知识而不是学会技能所以 Anthropic 这篇研究主要测试的是被试者的学习速度和掌握程度让开发者在短时间内学习一个自己没用过的 Python 异步库Trio做两段功能开发然后立刻做测验看是否真正理解“刚刚用到的概念”用测验题覆盖他们刚刚接触到的关键能力Debugging定位/解释错误Code reading读懂代码在干嘛Code writing选择正确写法/方法Conceptual概念理解并且论文更偏重前三者因为作者认为未来 AI 写的代码越多人类越需要这些能力来做监督与把关。为了比“问卷”更有说服力这是一个随机对比实验而且对象是真实软件工程师受试者52 名多数偏初级工程师Python 使用至少 1 年且每周都用没用过 Trio但又要对 AI 辅助写码不陌生过程热身 → 用 Trio 写两个功能像自学教程那种题目 starter code 简短概念说明→ 立刻测验AI 组侧边栏有 AI 助手能读到当前代码也“随时可以在你要求时给出正确代码”在这个过程里还做了定性分析人工标注屏幕录制统计花多少时间问 AI、问了什么类型的问题、哪里出错、是否自己动手改等这套设计的目的不是让被试者主观汇报“我觉得我学会了/我觉得我更快了”而是让你做题来验证“你到底会不会”。而测试结果也很出乎意料更快一点点但懂得少一截根据结果可以看到速度提升不明显AI 组平均快大约 2 分钟但没达到统计显著对此作者也解释这类任务是“学习新库 非重复性”AI 的生产力优势不一定能充分体现AI 更可能在“熟悉/重复性任务”上显著提速。掌握程度显著下降AI 组测验平均50%手写组平均67%差距相当于“接近两个等级”例如从 B 跌到 D 的差距并且统计上显著文中给了 Cohen’s d0.738, p0.01最明显的差距出现在 Debugging 题也就是“知道哪里不对、为什么不对”这对“AI 时代的工程师”反而是更关键的能力。所以针对结果可以总结AI 没让你稳定更快但更容易让你“做完了却没学会”。而对于这篇论文最有价值的部分不是“用 AI 就完了”而是“你怎么用” 作者发现 AI 并不必然导致低分关键在“交互模式”他们从录屏里归纳出6 种模式并且能对应到明显不同的学习结果一、低分模式把脑子外包给 AIcognitive offloading这些模式平均分 40%1、AI delegation完全委托写代码最快、几乎不出错因为 AI 帮你躲开了错误但测验最差被试人没经历“犯错—定位—修复—理解”的循环2、Progressive AI reliance越写越依赖一开始问一两次后面逐渐把写法都交给 AI特别是第二个任务的概念更没掌握3、Iterative AI debugging让 AI 负责排错/验证问得多但问法是“帮我修/帮我确认对不对”结果既不快、也没学会因为关键的诊断推理被外包了这里有个很反直觉的点手写组更容易遇到 Trio 概念相关的错误而这些错误恰好对应测验内容所以作者推测你在自己解决这些错误的过程中debug 能力反而被训练起来了。二、高分模式用 AI 当“解释器/教练”而不是“代写员”作者把平均分 ≥65% 的行为看成“保学习”的模式1、Generation-then-comprehension先生成再逼自己理解看起来和“全委托”很像也是先让 AI 给代码但差别在于后续会追问解释、验证理解再自己整合2、Hybrid code-explanation要代码也要解释提示词里同时要求生成 逐段解释/关键概念说明更慢但理解更好你花时间读解释3、Conceptual inquiry只问概念不让它替你写只问“Trio 的这个机制是什么/为什么这么写”代码主要自己写错误也自己修这个模式在高分里反而速度还不错总体第二快仅次于完全委托在这里作者强调这些模式和分数是“相关”而非严格因果因为样本小但它清楚地指出用 AI 也可以学得好只是你要把它用成“促进理解”的工具。当然作何也认为这不只是“写码圈焦虑”论文认为AI 会让人降低认知投入、更不投入地完成任务cognitive offloading例如一篇 Microsoft Research 的工作知识工作者调查讨论了在使用生成式 AI 时人们会自我报告“认知努力降低”且“对 AI 更有信心”与“更少进行批判性思考”相关还有研究指出人机协作可能提升即时表现但对后续独立工作/动机等带来复杂影响所以可以认为使用 AI 的过程就是一个把“认知外包”的过程这个过程现在从抽象概念落到了一个非常具体的技能上异步编程库的学习与调试能力。实际上作者在结论里更想表达的是在“组织风险”如果企业用 AI 把初级工程师的产出拉起来但同时把他们的调试/理解能力压下去那么当 AI 输出出错或系统进入高风险场景时“最后兜底的人”反而更弱。这和之前大家关心的“Agent/自动化把活干完”是同一条线自动化越强人类越像“监督者”但监督者最需要的技能读懂、诊断、概念把握却可能被自动化削弱于是出现一种结构性悖论越依赖 AI越缺乏监督 AI 的能力。那怎么把这篇研究落到开发者日常用 AI 写码”如何“既提速又不丢技能”其实可以直接对照他们的高分模式做几个很具体的操作习惯默认不让 AI 直接给最终代码先让它解释概念/给方案/指出坑点你自己写第一版。如果要生成代码强制解释 你复述例如提示词里加两句“先给代码再逐段解释每一段为什么需要。”“最后用三条 bullet 总结该库/该模式的约束。”Debug 时别让 AI 直接修先让它“定位与假设”让它列出 3 个可能原因 你应该如何验证打印什么、看哪段源码、查哪个 API 合同这能把“诊断推理”留在你这边而不是直接外包成补丁。把“卡住”当作训练而不是失败文章的过程其实明确表达过认知努力、甚至“痛苦地卡住”可能正是形成掌握度的重要条件当然作者自己也承认它是“第一步”因此具备局限性样本量不大52 人测的是“刚学完立刻测验”的短期理解长期是否会追平还未知任务是“学新库”不等同于你平时做的所有开发比如熟悉业务的 CRUD、重构、加测试等所以它更合理的结论不是“AI 会让人变菜”而是在“学习新东西”的场景里AI 最容易让你用最小阻力完成任务但学习需要摩擦你要主动把摩擦留住。而更长远的考虑是你是不是在使用 AI 的过程中丧失了思考随着 AI 越来越强你是不是越来越弱特别是初级工程师过度依赖 AI 可能会导致“技能发育不良”在学习新东西时应该刻意进行“认知投入”比如遇到错误先尝试自己解决或者强迫自己阅读并理解 AI 生成的每一行代码。而对企业/管理者短期生产力的提升AI 带来的效率可能以长期专业能力的流失为代价如果工程师失去了审查和调试 AI 代码的能力未来的系统风险将增加。参考原文https://www.anthropic.com/research/AI-assistance-coding-skills