6 篇博文 含有标签「engineering-culture」

一名新工程师加入了一个重度依赖 AI 的团队。入职第三天，他们发现系统指令中有一个措辞别扭的双重否定。看起来像是个 bug。于是他们把它清理了——这是任何合理的人都会做的小小优化。两小时后，一条关键流水线的客户端分类准确率从 91% 跌至 74%。没有人知道原因。

这种情景以某种形式发生在几乎每一个基于 LLM 构建系统的团队中。新工程师并不粗心。那个提示词看起来确实有问题。但那个双重否定在某种意义上是"承重墙"——只有写下它的人才真正理解，而那是在经过数周实验之后才领悟到的。他们从未把这种理解写下来。

这就是 AI 入职差距：AI 代码库表面上的行为与实际行为之间的鸿沟，以及为什么这个鸿沟在有人掉进去之前是不可见的。

当生产环境出现 Bug 时，第一个仪式总是相同的：打开 git blame，找到写下那行代码的人，问他们为什么要这么写。这个仪式假设作者是有原因的——他们知道的某个限制、刻意处理的边缘情况，或者从三个季度的复盘报告中内化而来的业务规则。在软件史的大部分时间里，git blame 回答的是关于意图的问题。

现在，对于比例日益增长的提交，git blame 指向的是合并代码的人和生成代码的 AI。人类可能只花了 90 秒阅读 diff。而 AI 除了 prompt 之外没有任何上下文。那些让 git blame 变得有用的“为什么”——即组织知识——从未在任何地方被记录下来。

这就是代码所有权衰减。它不会自我宣告。没有哪一个单一的提交会破坏系统。相反，理解力会慢慢被掏空，直到团队到达一个决策点——一次重构、一次事故或一名新员工入职——才发现再也没有人能从内部解释这个系统了。

基准测试数据讲述了一个奇怪的故事。在 SWE-bench Verified 上，多个运行相同底层模型（均为 Opus 4.5）的智能体产品——Auggie、Cursor、Claude Code——产出了截然不同的结果。尽管“大脑”完全相同，Auggie 在 731 个问题中比最接近的对手多解决了 17 个。差距在于“脚手架”（scaffolding）：智能体是如何被提示的、被赋予了什么上下文、可以调用哪些工具，以及在困惑时测试框架（harness）做了什么。模型是商品，围绕它的脚手架才是产品。

这是成熟的工程团队在十年前对初级工程师达成的相同共识。一个聪明的毕业生能交付价值，并非仅仅因为模型优秀，而是因为 README 是最新的，测试套件运行迅速，代码审查标准每次都能捕捉到那六个同样的错误，并且有人编写了说明约束条件的 CONTRIBUTING.md。剥离这些脚手架，同一个人产出的代码可能局部连贯但全局错误，破坏了团队甚至没想到要写下来的生产环境不变量。

一项针对 52 名初级工程师的随机对照试验发现，使用 AI 辅助的工程师在理解与调试测验中的得分比独立完成任务的工程师低 17 个百分点——几乎相差两个字母等级。调试能力——恰恰是 AI 应该增强的技能——呈现出最大的差距。而这仅仅发生在一次学习课程之后。将此推演至一年的日常 AI 辅助使用，你就能理解，为何几家公司的资深工程师悄悄反映，团队推理复杂问题的方式已悄然改变。

AI 工具带来的技能萎缩问题是真实存在的，可以量化的，且对中级工程师的冲击最为显著。以下是研究所揭示的规律，以及你可以采取的应对措施。

当今大多数招聘 AI 工程师的团队，都在运行一套为一个根本不存在的岗位所优化的面试流程。他们筛查的是 LeetCode 刷题能力，考察候选人对 Transformer 内部机制的了解程度，并给那些能够自信地在白板上画出分布式系统的人加分。然而，这些候选人加入团队后，却在调试幻觉频发的检索流水线时束手无策，并且交付了一个在测试环境中表现完美、在生产中悄然退化的模型集成。

这不是人才问题，而是测量问题。预示 AI 工程成功的技能在传统面试循环中几乎是不可见的——而面试实际测量到的技能，与工作的真实需求相关性极低。

在一个金融科技团队推出 AI 编程智能体来处理日常后端任务的三个月后，一位资深工程师离职去了另一家公司。当团队试图还原六周前做出某些身份验证决策的原因时，却发现没有人能做到。PR 描述写着“按讨论实现”，提交信息写着“根据需求”。AI 智能体做出了选择，代码正常运行，而背后的推理过程却消失得无影无踪。

这并非文档记录的失败。当原本用于传递理解的渠道——工程师之间的往复沟通、解释带来的摩擦、向他人证明决策合理性的压力——被一个优化输出而非优化理解的系统所取代时，必然会发生这种情况。