漏洞报告暴增十倍，Go 团队：我们睡不好了
内容提要
在GopherCon EU 2026的Go团队圆桌上，团队透露AI使安全报告从每月5-10份增至100-200份，其中多为Bug而非漏洞。团队应对措施包括重新分级、内部用LLM提效、安全左移，但不效仿Linux公开所有AI发现的漏洞。团队将AI视为“初级工程师”，强调人必须在回路中。路线图包括后量子签名（Go 1.27已发布crypto/mldsa）、SIMD、高层密码学API及对LLM友好的生态。团队坚持克制原则：每个API都是永久承诺，“No is temporary, yes is forever”，以保持Go为最简单的主流语言。
延伸解读
报告洪水的真实构成：Bug 多于漏洞
Go 安全团队每月报告量从 5～10 份增至 100～200 份，但 Roland 强调其中很多是 Bug 而非安全漏洞。原因在于 LLM 会出错，且使用者不理解 Go 的威胁模型。这意味着维护者面对的不只是数量压力，还有信号与噪声比例的变化。对开源维护者而言，单纯增加人力未必有效，更关键的是先区分报告性质，再决定处理优先级。
重新分级：panic 不再等同高危漏洞
过去报告少，每份都能按最高优先级处理；现在团队必须重新分级。Roland 举例，给解析 API 喂畸形输入导致 panic 虽不是好事，但与绕过工具链数据库校验完全不是一个量级。这种分级调整也意味着更多问题可能在修复前就公开。读者应留意：安全报告的严重性判断正在从“是否崩溃”转向“是否可被利用造成实质危害”。
AI 是初级工程师，人必须在回路里
两位嘉宾都用 AI，但风格不同。Roland 少用，因为必须完全吃透的代码自己写更快；Jonathan 把 AI 当初级工程师，用于生成简单代码、写测试和循环做覆盖率检查，但每一轮都停下来让人确认，原则是“一切都是建议性的”。这为团队使用 AI 提供了可操作边界：让 AI 多干活，但保留人工检查点，避免无人审查的大段生成代码进入关键路径。
克制原则：No is temporary, yes is forever
Go 团队只有两位数人数，一年两次发布，因此对新增 API 极度克制。Roland 说每加一个包就意味着永远维护，审查提案的核心不是“有它好不好”，而是“有没有时间长期维护”。Jonathan 引用 Rob Pike 的话：“No is temporary, yes is forever.” 这解释了 Go 为何不轻易加入 Optional、immutable 等特性，也提醒贡献者：新增 API 需走漫长提案流程，改文档、修 Bug 和带基准测试的优化通常更快被处理。
Q&A
Go 安全团队每月收到的安全报告数量变化有多大？
从过去糟糕月份的约 5～10 份，增长到现在的约 100～200 份，其中很多其实是 Bug 报告而非安全漏洞。
Go 团队如何应对 AI 带来的安全报告暴增？
采取三步应对：重新分级（区分严重性，如畸形输入导致 panic 不再视为头等大事）、内部用 LLM 提效（主动检测和处理报告）、安全左移（在 Bug 进入标准库前拦截）。
Go 团队会像 Linux 那样公开所有 AI 发现的漏洞吗？
不会。Roland 表示公开所有 AI 发现的漏洞会让别人的生活难很多，且最强漏洞挖掘模型并非人人可用，负责任披露仍有价值。
Go 团队自己如何使用 AI 工具？
Roland 少用，因为需要完全吃透代码，自己写更快；Jonathan 把 AI 当初级工程师，用于生成简单代码、写测试和循环做覆盖率检查，但每一步都让人确认，保持人在回路中。
Go 语言路线图中包括哪些重要方向？
包括后量子签名（Go 1.27 已发布 crypto/mldsa）、SIMD（已有实验开关）、高层密码学 API（让用户无需做选择）、对 LLM 友好的生态（如包站点 API 提供 OpenAPI 文档）。
Go 团队在语言设计上为什么如此克制？
因为每个新 API 都是永远的承诺，团队遵循“No is temporary, yes is forever”原则，确保 Go 保持为最简单的主流语言，避免过度复杂化。
