AI 能帮助经验较少的工程师成长吗？

AI 能帮助经验丰富的工程师，但对工程决策有困难的人会怎样？我认为编程助手可以通过提出更常见的解决方案、发现一些明显错误来提高下限。它们也可能让一个人更快产出有害改动，因此这只是对取舍的判断，并非保证。

我在回应 Sean Goedecke 关于 AI 让效率较低的工程师造成更少负面影响的文章。他认为工程产出差异很大，糟糕的改动可能给同事增加工作。我会把部分问题理解为能力与职责的不匹配，而不是把每个人固定排在一条单一的等级线上。

我自己也可能造成这种不匹配。我擅长快速推进和理解系统，但代码质量会有所变化。在团队里，我有时用一个不打算合并的拉取请求展示想法，让同事审视思路，再把它正确实现。

团队规模也很重要。Fred Brooks 的《人月神话》提醒，给延期项目增加人员可能让项目更晚完成，因为入职和协调会消耗时间。这并不是说增加人员永远无益；效果取决于工作如何拆分，以及引入新人的成本。

有人建议给延期的 T3 产品工作增加人手，我也会遇到这个问题。贡献者可以帮忙，但必须有人负责引导和协调改动。在过去的工作中，我有时通过缩小范围、优先处理真正能交付的内容来帮助延期项目，而不是假定扩大团队就能解决进度问题。

能力有多个维度，经验只是其中之一。我可能愿意投入时间培养经验较少、但成长潜力很大的工程师，而不是仅凭当前产出判断他们。这种投入短期可能拖慢团队，但如果人们得到支持，也有机会留下来成长，之后可能获得回报。

Goedecke 认为编程智能体提高了下限：过去可能包含明显局部错误的改动，现在可能更连贯。我见过不熟悉某种语言的人使用助手后出现类似改善。但看起来合理的拉取请求仍可能出错，尤其是需要跨系统上下文时。

智能体可能指出明显错误，例如缓存键没有包含用户信息，或者文件没有关闭。它也可能漏掉细微问题或接受糟糕的指令。把模型输出视为需要审查的工作，比假定 AI 辅助的每一项改动都能运行且安全更稳妥。

我想用过去的一段工作流程说明自己的挫败感，但首先要肯定 Twitch 的 Mod View 团队。他们是我合作过最优秀的团队之一，在紧迫期限下解决了困难问题。我为这个团队及其交付的产品感到骄傲。

我说的问题出在发布公告的博客文章，而不是 Mod View 产品。我们提供了视频演示，我记得最初的文章使用了体积很大的 GIF 转换文件，而不是轻量的视频嵌入，导致页面非常庞大。这是我对特定事件的回忆，并非对相关人员的独立调查。

我回忆了几次尝试修复的过程：使用 Twitch 视频嵌入、将演示转换成 WebM、提供 HTML 并安排存储。结果仍没有达到预期的自动播放效果，而视频中展示的文章后来出现了失效的嵌入内容。这个经历反映的是我所体验到的沟通和流程问题。

我也谈到自己当时非常愤怒的反应，以及这可能对晋升产生的影响。我想知道编程智能体是否能更好地处理一个直接的视频嵌入请求。这只是一个假设性的比较，并非对特定模型的测试；单个轶事也无法衡量同事的整体能力。

Goedecke 指出，如果一个人只是转发请求给助手，却不理解其工作，可能产生问题：同事等待回复更久，当事人学到更少，公司仍需承担员工和工具的成本。这些是对工作流程的担忧，并不能证明使用 AI 的人没有价值。

我画了一张粗略示意图，以经验为一个轴，以我对工程技能的主观判断为另一个轴。重点是区分经验和当前能力：有些新人学习很快，而任职多年也不保证掌握所有相关技能。这是概念草图，不是经过验证的人才排名方法。

为了说明这一点，我讲述了为 Ping 招聘 Mel 的经历。Ping 是一个直播协作产品，涉及 Web 开发、WebRTC 和直播集成。她来自游戏开发领域，正在构建自己的游戏引擎，而不是沿着传统 Web 工程路线成长。她的好奇心和已有项目让我看到了潜力。

我向 Mel 介绍技术栈后，她很快用它重建了自己的作品集，还开始了另一个项目，而那时我甚至还没准备好练习题。我聘用了她，后来她参与了产品工作、管理工具和视频录制基础设施。对我而言，教训是要看实际展示的学习能力和主动性，而不只看熟悉的履历。

大约一年后，我们一起规划录制存储系统。我有一条规则，让新员工每天至少提出一个问题，以减少担心自己显得不够有经验的顾虑。设计讨论结束后，Mel 问什么是 endpoint；她此前的工作方式让她还没有以同样方式接触过这个基础术语。

这个问题并不会抹去她此前已经构建的成果。在我们的技术栈中，许多通信以类似函数调用的方式呈现，而她之前的游戏引擎工作需求也不同。同一个知识缺口，放在不同人的经验、职责和学习意愿中，可能意味着不同的事情。

我认为有学习动力的新人可以用 AI 追问那些原本不好意思问、或找不到人问的问题，也可以用它探索不熟悉的图表或概念。这是学习机会，但答案仍需要核实，获得人类导师的指导也依然有价值。

我把这与仅仅利用助手显得有产出、却回避理解的做法作对比。我区分的是一个人如何使用工具，而不是是否使用工具。智能体可以让初稿更容易产生，但人仍需学到足够知识，判断初稿是否解决了真正的问题。

我重新绘制了示意图，让经验从新人延伸到资深，另一条轴表示我对技能的印象。我用它讨论经验有限却成长很快的人。这只是个人启发式模型，不能涵盖影响工程师工作的全部技能、机会或环境。

我还提到实习生 Yash 独立探索修改 Web 打包文件的经历，作为好奇心和主动性的另一个例子。我认为 AI 能为这样的人提供更多调查和实验的方法。至于个人会以多快的速度进步，那只是我的预期，不是经过测量的职业结果。

文章提出担忧：依赖生成的答案可能减少学习。我认为结果取决于使用者和工作方式：人可以用助手比较想法、追问解决方案为什么有效，也可以不加理解地接受输出。这两种情况都可能发生。

丢弃工作成果时也存在人际差异。有时同事投入了大量精力，即使改动不合适，我拒绝他们的拉取请求时也会感到内疚。我觉得丢弃 AI 生成的尝试更容易，也告诉团队，如果我的提案不合适，可以直接关闭。

但这并不能免除与人沟通时的体谅。如果同事使用 AI 并分享输出，接收反馈的仍然是人。团队需要讨论工作的实质，而不是把人当作一个工具。

我认为根深蒂固的偏好可能把智能体引向糟糕的选择，因为当用户自信地否定建议时，助手可能顺从。我对 React 的争议只是强烈技术偏好的一个例子；任何框架的优劣都取决于具体项目和限制。

虽然我强烈不同意 Alex Russell 关于 React 的部分观点，但我认可他对设备性能差距的研究。我展示的图表比较了部分手机随时间变化的单核基准分数。它说明了硬件差异，并不能全面衡量每位用户的 Web 体验。

助手既可能挑战用户的假设，也可能强化这些假设。我担心某人坚持偏好的方案，而模型在没有揭示取舍的情况下表示赞同。这种风险说明需要测试替代方案并检查结果，而不是认定所有对某框架的反对都是无知。

我预测，AI 可能拉大两类工程师之间的差距：一类用它学习，另一类依赖它却不建立理解。我直言了可能的就业后果，但所说的规模和时间只是个人推测，不是经过证明的统计，也不是对任何具体个人的预测。

我给新工程师的建议是继续提问、尝试，并记录学到的东西。不知道一个术语，与拒绝学习它是两回事。AI 可以成为有用的学习伙伴，但进步仍然需要好奇心、实践、反馈和对答案的核实。

核心机会是用这些工具促进成长，而不仅仅让产出看起来更漂亮。我预计这个领域会发生变化，并鼓励人们在变化中继续学习。我对个人结果的信心只是个人观点，并非保证。