本文永久链接 – https://tonybai.com/2026/10/19/gophercon-eu-2026-go-team-panel

大家好，我是Tony Bai。

【导读】

AI 找漏洞的本事越来越强，最先“遭殃”的，其实是维护者。GopherCon EU 2026 的 Go 团队圆桌上，安全团队负责人 Roland Shoemaker 说，团队每月收到的安全报告，已经从最糟糕时的 5～10 份，涨到了 100～200 份。他还有一句大实话：“我的团队压力大得多，大家都睡得少了。”

这场圆桌只有半小时，信息量却很大。两位嘉宾一位是 Go 安全团队负责人，一位是 log/slog 的作者之一、现在主攻 Go 的 iter、集合类库与包站点 API 的 Jonathan Amsterdam。这篇文章，我们把对话拆开，结合 Go 1.26／1.27 的发布说明和行业数据，看看 Go 团队在 AI 时代到底怎么想、怎么做。

【文章要点】

  1. 报告洪水是真的：Go 安全团队的报告量从“糟糕月份 5～10 份”涨到 100～200 份，其中大量是 Bug 而非漏洞。
  2. 优先级正在被重新定义：构造恶意输入导致 panic，不再被当作头等大事；不会学 Linux 把 AI 发现的漏洞全部公开。
  3. Go 团队用 AI 很克制：像对待“初级工程师”，人必须在回路里（in the loop）。
  4. 路线图：后量子签名（Go 1.27 已发布 crypto/mldsa）、SIMD、高层密码学 API、对 LLM 友好的生态。
  5. 永远的取舍：Yes is forever，No is temporary；Go 要保持“最简单的主流语言”。

做得好，就没人知道你们存在

先认识一下 Roland 的团队。

他自己的说法是：“我们把工作做好的标志，就是没人知道我们存在。”

具体干什么？

  • 每天处理安全研究员发来的邮件，判断是否真的是安全问题；
  • 协调分诊、修复、发布的整条流水线；
  • 维护所有和安全相关的包：crypto/x509、crypto/tls、net、net/http、encoding/json……基本就是“一个生产服务需要的全套栈”。

他们的设计信条也很朴素：尽量不要给用户“带刃的 API”，让做错事变得很难。

这也解释了为什么，当 AI 开始大规模“挖洞”，这个团队是最先感受到压力的人之一。

冲击波：从每月 5 份到 200 份

1. 团队的真实感受

Roland 给出了一组很直观的数字：

时间 每月安全报告量
过去（糟糕的月份） 约 5～10 份
现在 约 100～200 份

同时他强调，这里面很多其实是 Bug 报告，而不是安全报告。原因有两类：

  • LLM 并非无所不能，会出错；
  • 使用 LLM 的人，不理解 Go 的威胁模型。

这不是 Go 一家的遭遇，行业数据也在印证：

  • curl 先在 2026 年 2 月关闭了漏洞赏金，又宣布 7 月 1 日至 8 月 3 日不再接收任何漏洞报告，官方称之为“summer of bliss”（极乐之夏）；
  • Epoch AI 统计显示，2026 年 6 月，21 家机构披露了约 1,500 个高危或严重漏洞，是此前单月纪录的 3.5 倍以上，拐点出现在 4 月；
  • Google GTIG 报告称，月度漏洞披露量从 1 月的 5,045 个涨到 8 月的 10,740 个；
  • 据报道，Linus Torvalds 也表示 AI 报告洪水已经让 Linux 安全邮件列表几乎无法管理。

需要说明：行业数据的成因并不全是 AI，GTIG 的报告自己也强调不能把所有增长都归因于 AI。

2. Go 团队的三步应对

Roland 透露了三个方向，我整理成一张图：

① 重新分级。

过去报告少，每一份都能按最高优先级处理。现在不行了。比如，给一个解析 API 喂入畸形输入导致 panic，虽然“让 Go 程序崩溃不是好事”，但它和“绕过工具链里的数据库校验”完全不是一个量级。Roland 的判断是：这种局面下，更多问题会在修复之前就变成公开的。

② 内部提效。

用 LLM 主动做检测，同时用它帮忙处理报告本身，从“被动响应”变成“主动发现”。

③ 左移。

这是我最喜欢的一点：安全报告之所以存在，是因为有 Bug 进了标准库。所以更好的办法，是在 Bug 进来之前就拦住。他提到的方向，是让 CI 里的机器人跑 LLM 工具，但“具体长什么样，我们还没完全想清楚”。

3. 他们明确不会做的事

Linux 内核的立场，据 Roland 转述，是所有 AI 发现的安全 Bug 都应该公开，理由是“你能跑这个工具，别人也能跑”。

Roland 的回答很干脆：“这会让我的生活轻松很多，但会让很多别人的生活难很多。”

Jonathan 在旁边补了一刀：“这也不完全成立，因为 Mythos 目前只开放给少数人。”

这句调侃背后是个真问题：如果最强的漏洞挖掘模型并不是人人可用，那么“反正大家都能发现”就不成立，负责任披露依然有它的价值。

Go 团队自己怎么用 AI？

主持人问的第一个问题，很接地气：你们自己用 AI 吗？

两位都用，而且都用 Google 的内部工具（Antigravity 和 Gemini）。但风格迥异。

Roland：少用。

他做的是必须“完全吃透”的代码，AI 一口气吐出几百行，他没时间逐行看，“往往自己写更快”。不过，他们正在更多地把 AI 用于漏洞分析，认为还有很多工作要做，但已经“相当有用”。

Jonathan：当初级工程师用。

他主要用在三类场景：

  1. 增量生成“不想自己写”的简单代码；
  2. 写测试；
  3. 自定义一个 skill，让它循环做覆盖率检查。

他分享的那个 skill，我觉得值得抄作业：

关键点只有一个：每一轮都停下来，让人确认。

Jonathan 的原则是：一切都是建议性的（advisory）。他不会说“AI 写了一个 1 万行的程序，我一行都没看”——“我还没到那一步”。

Go 还缺什么？一张路线图

主持人问：你觉得 Go 最缺什么？答案是一串关键词。

1. 后量子密码：已经落地

Roland 说，安全方向最担心的是“即将到来的后量子末日”，团队在 1.27 和 1.28 中重点准备签名相关的包。

时间线对得上：Go 1.27 已于 2026 年 8 月 19 日发布，新增 crypto/mldsa 包，实现 FIPS 204 标准的 ML-DSA 后量子签名，并集成进了 crypto/x509 和 crypto/tls。这件事的前置工作，其实在 Go 1.26 就以内部实现的形式做好了。

2. SIMD：已有实验开关

Jonathan 说 SIMD 会“打开一整类应用场景”，而且现在就能用实验标志体验。

确实如此。Go 1.26 引入了实验性的 simd/archsimd 包，需要在构建时设置环境变量：

GOEXPERIMENT=simd go build ./...

Go 1.27 的发布博客里，simd 与 simd/archsimd 仍标注为“实验性”支持。

3. 高层密码学 API：别让用户做选择

这是 Roland 个人最想改善的点。Go 早期的密码学 API，是为“真正懂密码学的人”设计的，对大多数人来说是带刃的，需要大量研究才能用对。

方向是提供更高层的 API，类似：

“给你一个 Reader，我们还你密文，用的就是我们认为最安全的方式。你不需要做任何选择。”

4. 对 LLM 友好

这是 Jonathan 的一个判断：让语言、生态、标准库和工具对 LLM 更友好，虽然这件事“变化得非常快”。

他正在做的包站点（pkg.go.dev）API，目前已有 Beta 版，设计时就考虑了 LLM：比如提供可直接下载的 OpenAPI 文档，文档本身既是人类可读的，也是 LLM 可读的。

他还特别指出，这类设计往往“对人友好的，也就对 LLM 友好”，两者重合度很高。

5. MCP SDK：早就发布了

有观众问 MCP SDK 什么时候发布，答案是“已经发布了”：github.com/modelcontextprotocol/go-sdk。Jonathan 是原作者之一，现在由 Google 的另一支更偏生产运维的团队维护，他本人只做顾问。

这里有个有趣的细节：他说，Go 团队并不是“生产团队”，除了模块代理和包站点，基本不运维生产系统。所以他们把 SDK 孵化出来，再交给更合适的人。从 GitHub 仓库看，SDK 已发布稳定的 v1.x 版本，并持续跟进 MCP 规范版本。

不到 100 人的团队，怎么决定做什么？

Go 团队有多小？主持人说“曾经可能只有 30 人”，Jonathan 说，“具体不公开，但是是两位数”。

一年两次发布、人数两位数，必然要极度克制。他们的几条原则：

1. 每一个新 API，都是永远的承诺。

Roland 说：每加一个包，就意味着要永远维护。所以提案审查时，核心问题不是“有它好不好”，而是“我们有没有时间长期维护，它是否持续产生价值”。

Jonathan 引用了 Rob Pike 教他的话：

“No is temporary, yes is forever.”（“不”是暂时的，“好”是永远的。）

2. 不是所有东西都该进标准库。

Roland 的原话大意是：标准库大是 Go 最好的特点之一，但这也是巨大的责任，因为不能破坏兼容性。

3. 把更多工作交给社区。

Jonathan 说，团队正在扩大社区在“开发 Go 本身”上的角色：更高效地审 CL（也就是 PR）、清理 issue 积压，并把部分工作委托出去，比如包含外部贡献者的“集合工作组”。

想给 Go 贡献代码？

两位嘉宾的建议很实在：

  • 从带 help wanted 标签或者你熟悉的 issue 开始；
  • 改文档、修 Bug、做有基准测试证明的优化，这类 CL 通常处理得最快；
  • 避免新增 API，那需要走提案流程，可能耗时很久；
  • 看看去年 GopherCon EU 上 Artie 的分享，她完整讲述了自己的贡献经历，起起落落，但最终成功。

还有一个坦率的提醒：Go 目前没法“认领” issue，任何人都可能抢先提交 CL，即使提了 CL，团队也不保证很快审。这是流程的缺陷，但现实如此。

语言设计的克制：三个“为什么不”

圆桌后半段是语言设计问答，三个问题，Jonathan 都讲得很透。

1. 为什么要新增 hashmap 类型，而不让内置 map 支持自定义 Hash／Equal？

答案不是“感觉不对”，而是一个架构原则：

语言不应该依赖标准库。

如果内置 map 依赖标准库里定义的某个接口，就等于语言依赖了标准库。

有人反问：error 接口不就在标准库里吗？Jonathan 的回答是，error 在语言里其实只是一个普通接口，语言并不关心你是否返回它，你甚至可以把 error 当第一个返回值。至于格式化错误的特殊处理，那是 fmt 包的事。

他还幽默地补了一句：“就算有反例，也不意味着我们要再加一个。”

2. 要不要 Optional 类型？

Jonathan 的回答是：“我们已经有了，叫指针。”

当然也可以用泛型写一个 Optional[T]，但实践中，encoding/json、Google Cloud API 等都用指针表示可选。

为了让指针更好用，Go 1.26 做了一个小改进：new 现在可以接受表达式。

// Go 1.26 之前
age := yearsSince(born)
p := Person{Name: "Gopher", Age: &age}

// Go 1.26 起
p := Person{Name: "Gopher", Age: new(yearsSince(born))}

3. 为什么没有 immutable？

这是被企业开发者问得最多的问题。Jonathan 的回应相当长，核心是四个“复杂度炸弹”：

Roland 补充说，Go 团队内部每次聚会，这几个话题都会重复出现，“每次都觉得要是能有就好了，但一想真实的样子，就变成一团糟”。

Jonathan 的立场很明确：

Go 因为泛型、迭代器变复杂了一些，但它仍然是最简单的主流编程语言，我们要让它继续如此。我们不想变成 Rust 或 C++。（不是它们不好，只是“不是我们想住的地方”。）

“普通”不等于“笨”

主持人感叹 Rob Pike 能以学术高度为“普通开发者”设计语言。Jonathan 立刻纠正了一个误解：

“普通”不是“笨”。“普通”指的是每一个人，包括一年后回头看自己代码的你。

他还讲了一个小故事：自己曾写过一个“自以为很聪明”的改动，评审者提醒他：“想想两三年后你来维护它的时候。”他承认，确实存在一种不那么聪明、但更正确的写法。

他引用了 Brian Kernighan 的名言，大意是：写出那段极其聪明代码的你，永远比调试它的你更聪明，哪怕是同一个人。

彩蛋：Gopher 是谁画的？

最后一个问题很轻松：Go Gopher 吉祥物是谁创作的？

答案是 Renee French。她同时是 Rob Pike 的伴侣，也是一位严肃的艺术家，还为其他语言做过吉祥物，但 Gopher 无疑是她的代表作。Jonathan 还推荐了她在 GopherCon 2016 上的非技术分享，据说“非常有趣”。

小结：三个值得带走的判断

回看这场圆桌，我认为有三点，比任何一个具体特性都更值得记住。

1. AI 正在改变“信号与噪声”的比例，而不只是改变效率。

漏洞挖掘变得廉价，但读报告的人没有变得廉价。Go 团队的应对是：重新分级、提效、左移，不放弃负责任披露。这个思路，对任何开源维护者都有参考价值。

2. “克制”本身就是一种能力。

每一个 API 都是永远的承诺，每一个语言特性都有复杂度的税。Go 能保持“最简单的主流语言”，靠的不是不会做，而是知道不做什么。

3. 人要始终在回路里。

不管是写测试还是做漏洞分析，两位嘉宾的共识是：**AI 是初级工程师，不是架构师。**让它多干活，但每一步留一个“停下来给我看”的检查点。

最后留一个问题给你：如果你维护的项目，今天突然每月多收到 100 份“看起来很专业”的报告，你会怎么办？

参考资料

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

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

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

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

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

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

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