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

就在此时，你的笔记本电脑里的某个角落正存放着你的团队有史以来最详尽的工程决策记录，却没有任何人读过其中的一个字。每一个智能体会话 —— 无论是每一次 Claude Code 的运行、每一次 Cursor 对话，还是持续数小时的重构历程 —— 都会被记录成一份转录文本（transcript）。它包含了尝试过又被放弃的三种方案、导致产生这种丑陋临时方案的约束条件，以及你否决模型建议的时刻及其原因。然后会话结束，PR 带着一行 commit message 被合并，所有这些上下文都进入了一个永远不会被打开的 JSONL 文件。

以前，我们丢失这些信息是“理所当然”的。某个设计选择背后的推导过程只存在于某个人的脑子里，随着时间推移而淡忘，并在他们换工作时彻底流失。当时没有什么可以保存的，因为根本没有记录下来。这种借口已经不复存在了。现在的推导过程正被逐字逐句地记录下来，带有时间戳，机器可读 —— 而我们却将其视为随手可弃的废气。

2026 年 1 月，curl 关闭了其漏洞赏金项目。六年的时间，86,000 美元的支出，以及源源不断的真实漏洞 —— 计划的结束并非因为资金耗尽，而是因为有效信号消失了。从历史上看，超过 15% 的提交最终被确认为真实的漏洞。但到了 2025 年底，这一比例降至接近三十分之一，而提交量却激增至正常水平的八倍。队列中充满了冗长、自信、却完全编造的报告 —— 其中一份报告甚至附带了 GDB 会话和寄存器转储，引用了一个在 curl 中根本不存在的函数。

令人不安的事实是：产生这些垃圾信息的人并不是恶棍。他们中的许多人是像你一样的工程师，运行着像你一样的智能体，对准了你的产品所依赖的代码库。AI 将“产出”一项贡献的成本压缩到了接近于零，但它对“审核”贡献的成本却毫无助益。任何具有这种形态的经济系统 —— 发射成本极低，吸收成本极高 —— 最终都会演变成垃圾信息问题，而吸收端则是那些在你那不知疲倦的智能体出现之前，就已经在义务工作的志愿者。

一年前，你的团队采用了 PR 描述模板。它包含 ## Summary、## Changes、## Test plan 和一排复选框。审查者非常喜欢它：每个 PR 都有上下文，每个 PR 都有测试计划，每个 PR 都有结构。六个月后，编程助手学会了填写它。现在，每个 PR 依然有 ## Summary、## Changes、## Test plan 和一排复选框 —— 但审查者不再阅读标题以外的内容了。曾经聚焦注意力的格式，现在反而成了“此处不值得关注”的信号。结构比它所承载的信号寿命更长。

这不是代码质量问题。这些 PR 中的代码通常是没问题的。问题在于，撰写描述的行为已经从思考变更的行为中被剥离，而描述正是审查者用来分级处理（triage）其有限注意力的工具。当该工具变得格式统一、措辞合理，且与其他所有 PR 毫无区别时，审查者的注意力分级机制就失效了。曾经用于挖掘异常情况的系统，现在将所有内容摊平成了同样的形状。

关于编码智能体（coding agents）提高生产力的说法是，它们消除了打字瓶颈。但在实践中，工程师真正遇到的瓶颈却截然不同。工程师再也无法在脑中掌握整个系统，因为智能体修改文件的速度快于工程师阅读的速度，编写测试的速度快于工程师推断覆盖率的速度，重构抽象的速度快于工程师在设计层面（而不仅仅是编译器层面）验证类型检查的速度。

那个紧凑的内环——假设、更改、观察、优化——定义了胜任的工程工作，但它正悄然瓦解为另一种循环。工程师现在是在审查智能体的输出，而不是建立对系统的直觉。2025 年中期的一项 METR 随机对照试验发现，经验丰富的开源开发人员在使用 AI 助手处理熟悉的代码库时，速度慢了 19%，但他们却报告感觉快了 20%。认知感知的生产力与实际生产力之间这 39 个百分点的差距并非测量误差。这是为了吞吐量而默默牺牲理解力的代价。

一名新工程师加入了一个重度依赖 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 智能体做出了选择，代码正常运行，而背后的推理过程却消失得无影无踪。

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