AI - Tony Bai

标签 AI 下的文章

Dropbox最新研究解读：AI 正在拉平生产力差距，顶尖开发者如何脱颖而出？

九月 28, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/09/28/how-top-performers-stand-out-in-the-age-of-ai

大家好，我是Tony Bai。

AI 正在以前所未有的速度重塑软件开发领域。从代码生成到信息检索，AI 工具无疑极大地提升了工程师的生产力。一个普遍的假设是，谁能更好地利用 AI，谁就能成为新时代的顶尖人才。然而，Dropbox 最近发布的一项内部研究，却对这个看似理所当然的结论提出了一个深刻的挑战。

研究发现，虽然 AI 工具（如 ChatGPT 或 Dropbox Dash）确实让所有员工的效率都得到了提升，但它并不是区分最高绩效员工（即那些“卓越”的员工）与普通高绩效员工（“优秀”的员工）的关键因素。当 AI 将“写代码”的效率门槛普遍拉高后，一个更核心的问题浮出水面：在一个 AI 成为标配的时代，顶尖开发者究竟凭借什么脱颖而出？

本文将和大家一起解读这份研究报告，逐层剖析 AI 带来的生产力悖论，并揭示那些在 AI 时代真正让顶尖开发者与众不同的“剧本”和核心特质。

AI 生产力悖论：当所有人都开上了“跑车”

Dropbox 的研究首先确认了一个事实：AI 是强大的生产力引擎。在其内部，高达 78% 的员工认为 AI 工具提高了他们的工作效率，这一比例比去年大幅跃升了 20 个百分点。高达 96% 的员工每周都会使用 AI 来处理信息查找、头脑风暴、软件开发和草拟信息等任务。

然而，一个关键的发现随之而来：AI 带来的生产力增益是普惠的。无论是哪个级别、哪个岗位的员工，在使用 AI 后都报告了相似的效率提升。这意味着 AI 就像是给所有赛车手都换上了一辆更快的跑车——赛道上的整体速度都变快了，但车手之间的排名可能并没有因此改变。

当我们聚焦于那些同时具备高绩效和高敬业度的“卓越员工”（Thriving Employees）时，数据显示，87% 的卓越员工认为 AI 提升了他们的生产力，而其他员工中这个比例是 76%。这个差距是存在的，但并不足以解释他们之间的巨大表现差异。

这导出了研究的核心问题：如果 AI 只是新的“起跑线”，那么决定胜负的终极因素是什么？

高绩效开发者的“剧本”：AI 之外的差异化优势

为了回答这个问题，研究团队深入分析了开发者群体的具体数据，包括 PR 提交量、工作习惯的自我报告以及对工作体验的感受。结果清晰地描绘出了一幅“卓越开发者”的画像，他们的成功秘诀远不止于熟练使用 AI。

数据显示，卓越开发者提交的 PR 数量比同行多 20%。但这并非因为他们打字更快或工作时间更长。更高的产出速度，是他们更优秀的工作系统所带来的自然结果。这个系统由以下几个关键要素构成。

1. 专注工作的“不公平优势”

69% 的卓越开发者表示，他们有时间进行深度、专注的工作，而这一比例在其他开发者中仅为 51%。这是一个高达 18 个百分点的惊人差距。这表明，顶尖人才的核心能力之一，是主动设计自己的工作日程，以保护最宝贵的认知资源——专注力。

他们更倾向于：

批量处理会议，避免日程被零散的会议切割得支离破碎。
在日历上明确“封锁”出大块的“免打扰”时间，用于攻克复杂的技术难题。
刻意安排休息和体育活动，以实现强度与恢复的平衡，保持可持续的高输出。

2. 高质量代码的良性循环

研究揭示了一个关于代码质量的良性循环：

84% 的卓越开发者认为他们代码库易于理解和修改（vs. 同行的 62%）。
59% 的人认为调试生产环境问题很容易（vs. 同行的 38%）。
77% 的人感觉他们正在开发的产品具有很高的稳定性（vs. 同行的 65%）。

这三个数据点紧密相连。因为拥有更多深度工作时间，他们能够产出更高质量、更易于维护的代码。这使得后续的调试工作变得简单，产品的整体稳定性也更高。而一个更稳定的系统，又反过来减少了救火和紧急修复的需求，从而为他们赢得了更多可以用于深度工作的正向循环时间。

3. AI：不止是代码生成器，更是认知伙伴

虽然 AI 不是唯一的差异点，但卓越开发者使用 AI 的方式确实更胜一筹。73% 的卓越开发者每天都使用 AI 辅助，而其他开发者为 59%。

结合访谈数据，研究发现，顶尖人才不仅仅将 AI 视为“任务自动化”工具，更是将其作为“认知伙伴”。他们利用 AI 节省下来的时间（49% 的人表示会将节省的时间重新投入到更高价值的工作中），去从事更深层次的思考和创造：

超越产出，拥抱探索： 他们利用 AI 快速验证想法、进行头脑风暴、探索不熟悉的技术领域。
好奇心与自我导向： 他们不满足于 AI 给出的第一个答案，而是通过追问、提供更多上下文，来引导 AI 产出更具洞察力的结果。

正如 Dropbox 首席人事官 Melanie Rosenwasser 所言：

“AI 无疑能帮助我们更快地工作，但节省的时间不一定等于创造的价值。真正的机会在于我们如何利用收回的时间。我们的顶尖人才超越了产出本身，他们拥抱解决问题、好奇心和自我导向，利用技术去催生更深度的思考和更有意义的影响力。”

回归人性：AI 无法取代的核心特质

最终，研究将卓越员工的特质，归结为三个 AI 无法取代的、持久的人类技能：自主性、连接和平衡。

自主性 (Autonomy): 他们主动设计自己的工作系统和时间表，寻找能带来成长的“延伸项目”，其动力源于创造影响力，而非追求可见度。
连接 (Connection): 他们积极地与直属团队以外的人建立关系（即投资于“弱连接”），这能帮助他们获得新鲜的想法、提前发现潜在的障碍，并扩大自身的影响力。卓越员工在这方面的比例比其他人高出 18%。
平衡 (Balance): 他们懂得在高强度工作与恢复之间取得平衡，将体育活动等安排进工作日，以维持长期的、可持续的卓越表现。

小结：工程师的未来价值

Dropbox 的这项研究为我们描绘了一幅清晰的 AI 时代人才图景。当 AI 成为像编译器、IDE 一样普及的基础工具后，单纯比拼“工具使用效率”的时代正在过去。

对于我们工程师而言，未来的核心竞争力将无可替代地转向那些“元技能”：

深度工作的能力： 保护和运用专注力，解决复杂问题的能力。
构建高质量系统的能力： 编写清晰、可维护、稳定的代码，从而进入正向的开发循环。
战略性思考的能力： 将 AI 节省的时间，投资于更高层次的抽象、设计和创新。
人际连接的能力： 跨越团队边界，建立广泛的合作与影响。

AI 是一个强大的“能力放大器”，它能让你现有的工作习惯和思维模式变得更有效率。但最终，是那些持久的、独特的人类技能，如专注、好奇心、学习敏锐度和协作，真正驱动我们前进。在一个被 AI 加速的世界里，那些回归人性根本、修炼内功的工程师，将最终脱颖而出。

资料链接：https://blog.dropbox.com/topics/company/research-how-top-performers-stand-out-in-the-age-of-ai

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

“我们放弃了”——Go 团队坦诚布公，聊聊那些可能永远不会加入 Go 的功能

九月 22, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/09/22/go-team-gave-up-on-features

大家好，我是Tony Bai。

在 GopherCon Europe 2025 的 Go 团队座谈会上，Michael Stapelberg(负责go protobuf)、Damien Neil(负责Go安全相关)、Michael Pratt(负责Go运行时和Go性能相关) 和 Jonathan Amsterdam(log/slog作者，负责Go工具相关) 四位核心成员与社区进行了一场坦诚的对话。他们不仅分享了诸如官方 MCP SDK、“裸金属”Go 等激动人心的进展，更以一种罕见的坦率，正面回应了社区长期以来关心的多个“老大难”问题——包括不可变类型、泛型错误处理和非 nil 指针。其中最引人注目的一句“我们放弃了”，几乎为 Go 语言在某些方向上的演进画上了句号。

本文将带你深入这场座谈会的核心内容，一探 Go 语言的现在与未来。

语言设计的哲学——“不做什么”比“做什么”更重要

座谈会最精彩的部分，莫过于对多个长期存在的语言功能提案的讨论。Go 团队的态度清晰而一致：为了维护 Go 的核心价值——简洁性和易读性，他们愿意对许多看似“美好”的功能说“不”。

不可变数据类型 (immutable)

社区的期待：为 Go 增加类似 immut和const(修饰变量的) 的关键字，以增强代码的安全性和可预测性。
团队的困境：Michael Pratt 承认，这是“可能做的最好的事情之一”，但他紧接着说，“我们不知道该如何实现它”。内部曾有多个提案，但都未成功。核心问题在于，任何这类功能都会像病毒一样在代码库中蔓延，迫使所有 API 都需要考虑 const 和非 const 两种版本，这与 Go 的设计哲学背道而驰。
结论：在社区提出一个绝佳的、能保持语言简洁性的提案之前，官方不会主动推进。

泛型错误处理 (减少 if err != nil)

社区的期待：引入 try/check 等机制，减少错误处理的冗余代码。
团队的“投降”：在经过长达数年的思考和无数次讨论后，Go团队给出了一个爆炸性的结论：“我们放弃了 (we give up)。” 团队承认，他们找不到任何一种能让所有人都满意的、既能减少冗余又不损失清晰性的方法。
新的焦点：这一“投降”反而让团队感到“极度兴奋”。因为它意味着可以停止在“冗余”这个问题上内耗，转而思考其他更重要的错误处理问题。Damien 明确指出，如何在错误中加入堆栈跟踪才是当前错误处理最大的痛点，也是团队更愿意投入精力去探索的方向。

非 Nil 指针 (non-nil)

社区的期待：通过语言机制在编译期防止 nil 指针解引用。
团队的权衡：Jonathan Amsterdam 解释道，虽然非 nil 指针很好，但它会引入两种指针类型，让一切都变成两倍。或者需要引入复杂的流式类型分析，这会使代码更难阅读和理解。
一个反直觉的洞见：“Nil 指针错误是最好的运行时错误”，因为它有确定性的堆栈跟踪，易于定位。团队更关心那些非确定性的、只在生产环境中出现的并发 bug，比如 goroutine 泄漏。

枚举 (enum)

社区的期待：提供比 iota 更强大、更类型安全的枚举支持。
团队的困惑：Damien 指出，社区对 enum 的需求至少有两种截然不同的解读：一种是“整数的枚举”，另一种是“类型的枚举”（即代数数据类型），两者差异巨大。在社区就“到底想要什么”达成共识之前，团队很难推进。

标准库的“新陈代谢”——演进、维护与“瘦身”

标准库是 Go 生态的基石，但随着时间的推移，一些包也显现出历史的痕迹。

哪些包应该被“移除”？

团队成员们“点名”了一些他们认为设计不佳或已不再主流的包：

text/tabwriter: Damien 认为其设计不佳，如果现在重来，会做一个 v2 版本。
运行时的诊断(diagnostic) API: Michael Pratt 认为现有的 API “有点陈旧，难以使用”，希望能有更好的 API，但不确定是否值得为此做一个 v2。
net/rpc: 被 gRPC 全面超越。
expvar: 非常小众，很少有人使用。
syscall: 正在被 golang.org/x/sys 逐步取代，以实现更灵活的更新。
net/mail, syslog: 社区已经有了功能更强大、更受青睐的替代方案，标准库的实现已沦为“鸡肋”。

虽然因为 Go 1 的兼容性承诺无法真正移除它们，但团队的态度表明，未来的发展重心将不会在这些包上。

拥抱 v2，但极其审慎

json/v2 和 math/rand/v2 的出现，标志着 Go 团队愿意为那些存在根本性设计缺陷的包创建 v2 版本。但团队强调，这是一个极为例外的手段，只有在“现有 API 框架内无法做出改进”时才会考虑，因为 v2 会带来生态的分裂和迁移成本。

Go 在新时代的定位与机遇

面对 AI、裸金属(bare metal)等新兴领域，Go 将如何定位自己？

Go 在 AI 与数据科学领域的角色

清晰的边界：Go 团队不会去开发一个与 LangChain 或 Genkit 竞争的官方 AI 框架，也不会深入数值计算（社区的 gonum 已经很出色）。
专注“生产化” (Productionization)：团队认为，Go 的核心优势在于将 Python 中训练和设计的模型，部署到高性能、高并发的生产环境中。这是 Go 想要“拥有”的领域。Jonathan Amsterdam 更是直言：“你用 numpy 把东西搭起来，但你不会想用 Python 把它部署到生产环境。这时候你就该用 Go 了。”
提供核心 SDK 支持：团队将致力于为重要的 AI 规范和平台（如 MCP, Gemini, Genkit）提供高质量的官方 Go SDK。

“裸金属” Go (Bare metal Go)

进展：Michael Pratt 确认，一项由 Tamago 项目推动的新提案正在讨论中，旨在为 Go 运行时提供一个更稳定的内部 API，使其能更好地与底层系统交互。
价值：这将使 Go 在嵌入式、unikernel 等领域的应用变得更加容易，并且其设计是通用的，不局限于特定 CPU 架构。

激动人心的地平线——运行时与工具链的前沿探索

座谈会也透露了几个正在进行中的、令人兴奋的底层项目：

官方 MCP SDK：Jonathan Amsterdam 确认，官方的 Go MCP SDK 随时可能发布正式版，它吸取了社区现有实现的经验，设计更清晰，旨在成为官方标准。
Green Tea GC：Michael Pratt 提到，Michael Knyszek 正在进行一项名为“Green Tea”的 GC 改进提案，旨在提升 GC 在超多核（如 256 核）机器上的可扩展性和局部性 (locality)，以应对现代服务器硬件的发展。
Goroutine 泄漏检测：团队正在与 Uber 的工程师合作，计划将一项利用 GC 来动态检测部分死锁（即 goroutine 泄漏）的技术引入 Go。这项技术能找出那些“永远等待”在一个无人能触及的 channel 上的 goroutine，并将其报告出来。
WASM 的原生 GC 集成：团队希望未来能让 Go 编译的 WebAssembly 使用宿主环境（如浏览器）的原生 GC，但这面临着 Go 严重依赖“内部指针”（interior pointers）而 WASM GC 不支持的巨大技术挑战。
结构体对齐优化：David Chase 正在推动一个“个人激情项目”，目标是让编译器自动优化结构体字段的顺序，以减少内存空洞和提高空间效率。未来开发者将不再需要手动调整字段顺序。相关的提示功能已在 gopls 中提供。

开发者的日常——工具、协作与社区

座谈会的最后，团队成员分享了他们作为开发者的工作日常和对社区的看法。

AI 工具的使用：团队成员普遍开始使用 LLM。Jonathan Amsterdam 发现它是学习 OAUTH2 这类复杂规范的“极有耐心的老师”；Michael Stapelberg 则用它来学习 NixOS。Damien 更是认为 LLM 在处理 Go 代码时表现出色，因为 Go 的简洁性和向后兼容性为模型提供了高质量的训练数据。
编辑器之争：Michael Stapelberg 坦诚自己已从 Vim 叛逃至 Emacs，引发了现场的善意哄笑。
对 Go 社区的信心：当被问及“如果 Google 不再支持 Go，社区能否接手”时，团队成员们毫不犹豫地表示肯定。他们认为 Go 社区非常强大且自给自足，拥有大量非 Google 的核心贡献者（并以 Filippo Valsorda 为例），社区的繁荣并不完全依赖于 Google。

拾遗——关于性能、安全与其他语言的思考

除了上述重大议题，座谈会还触及了许多开发者关心的具体问题，这些简短的问答同样充满了来自 Go 团队的深刻洞见。

Go 与 Rust：灵感的源泉

当被问及对 Rust 等其他语言的看法时，团队表现出开放和欣赏的态度。

并发安全：Jonathan Amsterdam 坦言，Rust 提供的并发安全模型是他们“都希望在 Go 中拥有”的东西，因为它能极大地提升程序的可靠性。但他同时指出，在不让 Go 变得像 Rust 一样复杂的前提下，目前还没有找到实现路径。
不同的演进道路：团队也关注 OCaml 在并发安全上的探索。Jane Street 采用了一种与 Rust 完全不同的方法来实现并发安全，这表明解决同一问题可以有多条路径，Go 也在持续观察和学习。

性能：一个“双峰分布”的社区

Michael Pratt 对 Go 的性能有一个有趣的观察，他认为社区对此的感受呈现“双峰分布”：

一端是极其满意的用户：他们可能从 Python 等动态语言迁移而来，享受到了数十倍的性能提升，对现状非常满意。
另一端是要求极致性能的用户：大厂在海量部署下，对性能的渴求永无止境，任何微小的优化都能带来巨大的成本节约。

Go 团队的性能优化工作，主要聚焦于服务后一类用户，例如 json/v2、新的 map 实现以及 Green Tea GC。

安全：API 优于“模式开关”

对于“能否为 Go 增加一个‘高安全模式’开关”的问题，团队更倾向于通过改进 API 来解决安全问题。

**Damien ** 提到，一个可能的方向是为 net/http 包增加一个“高安全服务器”标志，该标志将启用一系列更安全的默认配置（例如，更严格的超时），以修正十年前设定的一些已过时的默认值。
Michael Stapelberg 补充道，Go 已经提供了像 os.ReadDirFS 这样更安全的路径遍历 API，并且 Go 程序与 Seccomp、Landlock 等 Linux 沙箱技术能很好地集成。从 API 和系统层面入手，是比引入一个全局的、模糊的“安全模式”更精细、更合理的做法。

io_uring：令人兴奋但为时过早

对于 Linux 下备受瞩的 io_uring，Michael Stapelberg 表达了谨慎的乐观。他承认 io_uring 性能惊人，但其复杂的 API 和过去暴露出的严重安全问题，使得 Google 内部服务器完全禁用了该功能。他认为，在它变得更成熟、更安全之前，考虑将其大规模引入 Go 还为时过早。此外，Michael Pratt 补充说，Go 的运行时和调度器已经通过 goroutine 隐藏了大部分 I/O 异步的复杂性，因此 io_uring 能带来的部分核心优势，Go 已经通过不同的方式实现了。

Go 作为 DevOps 脚本语言

当被问及 Go 能否取代 Python 成为 DevOps 脚本语言时，团队成员们几乎异口同声地表示：“在 Google 内部，这已经发生了。” Michael Stapelberg 分享说，他自己现在会避免编写任何中等复杂度的 shell 脚本，而是直接从 Go 开始，因为 Go 的强类型和工程化能力，能避免脚本在变复杂后迅速变得难以维护。