大家好，我是Tony Bai。

【导读】

“更多智能体等于更好效果”，几乎是行业里心照不宣的共识。但谷歌一篇新论文用260组受控实验证明，这个共识只对了一半：多智能体在可并行任务上能带来最高81%的性能提升，却也可能在顺序任务上让效果暴跌70%。谷歌团队还给出了一个能提前判断“该不该上多智能体”的预测模型，准确率高达87%。

【文章要点】

• 谷歌研究团队通过260组受控实验，首次为AI智能体系统建立了可量化的“缩放原则”，覆盖5种架构、3大模型家族、6个基准测试。
• 核心发现：多智能体系统的效果好坏，取决于任务能否被拆解为可并行的子任务，而不取决于智能体数量本身；在需要严格顺序推理的任务上，所有多智能体架构无一例外地拖累了效果。
• 架构设计本身就是一种“安全机制”：没有中心协调者的独立并行架构，会把单个智能体的错误放大17.2倍；而有协调者审核的中心化架构，能把错误放大控制在4.4倍。
• 谷歌训练出的预测模型（R²=0.373～0.413）能仅凭任务的工具数量、可拆解性等特征，提前判断出最优架构，在未见过的任务上准确率达到87%。
• 结论：模型越聪明，不代表越应该“堆智能体”，架构必须与任务结构对齐，收益才能兑现。

从代码助手到私人健康顾问，AI智能体正在从“一次性问答”走向“持续多步骤交互”。但一个问题始终没有标准答案：一个任务，到底该交给一个足够强的智能体自己搞定，还是拆给一群智能体分工协作？

过去两年，“智能体越多越好”几乎成了行业默认答案。有论文报告过，LLM的表现会随着智能体数量增加而持续提升；也有研究发现，多智能体协作“往往能通过集体推理超越任何单一个体”。

但谷歌研究院联合麻省理工学院等机构在最新论文《Towards a Science of Scaling Agent Systems》中给出了不同的答案：多智能体系统的效果天花板，早就存在，而且这个天花板由任务本身的结构决定，跟你堆多少个智能体没有必然关系。

先划清一条线：什么才算“智能体任务”

在动手做实验之前，谷歌团队先解决了一个容易被忽略的问题：市面上很多“智能体评测”，测的其实根本不是智能体能力，而是模型的静态知识水平。

研究团队给出了三条判断标准，一个任务只有同时满足下面三点，才算是真正的“智能体任务”：

• 需要与外部环境进行持续的多步骤交互；
• 需要在信息不完整的情况下反复主动收集信息；
• 需要根据环境反馈不断调整策略。

像GSM8K数学题、MMLU知识问答这类“一次生成、立刻出答案”的静态基准，并不满足这些条件——用它们来评估多智能体协作的价值，得出的结论很可能是误导性的。

按照这套标准，研究团队最终选定了六个真正意义上的智能体基准：

• 网页信息检索（BrowseComp-Plus）
• 金融分析（Finance-Agent）
• Minecraft环境下的任务规划（PlanCraft）
• 真实商业场景中的工具调用（WorkBench）
• 软件工程任务
• 终端操作任务

实验设计：5种架构，260组“对照实验”

为了排除“不同架构用了不同提示词、不同工具、不同算力预算”这种混杂因素，谷歌团队严格控制了所有变量：所有架构使用完全相同的任务提示、相同的工具接口、相同的计算预算，唯一改变的只有协调结构本身。

研究团队一共定义了五种典型架构：

• 单智能体系统（SAS）：一个智能体独自完成全部推理和行动，拥有统一、连续的记忆流；
• 独立式（Independent）：多个智能体并行处理子任务，彼此互不通信，只在最后汇总结果；
• 中心化（Centralized）：“中枢+分支”模式，一个协调者负责拆解任务、分发给子智能体、再汇总结果；
• 去中心化（Decentralized）：智能体两两之间直接通信，通过多轮讨论达成共识；
• 混合式（Hybrid）：中心化的层级控制 + 有限的智能体间横向沟通。

在此基础上，研究团队把这五种架构，套用到OpenAI GPT、谷歌Gemini、Anthropic Claude三大模型家族的多个能力档位上，一共跑出了260组受控配置，覆盖六个真实智能体基准。这也是目前公开研究中，对“智能体架构效果”做得最系统的一次受控对比。

核心发现一：“对齐原则”——能不能并行，才是关键

实验结果直接推翻了“智能体越多越好”的简单假设。

在可以拆解成并行子任务的场景里，比如财务分析——不同智能体可以同时分析营收趋势、成本结构、市场对比——中心化协调架构相比单智能体系统，性能提升了80.9%。任务被拆得越合理，多个智能体各自专注一块，整体效果反而比一个智能体“连轴转”要好得多。

但在需要严格按顺序推理的任务里，比如Minecraft环境下的规划任务，情况完全反转：论文测试的每一种多智能体架构，都让性能下降了39%到70%。原因也不复杂——协调本身要消耗“认知预算”，当任务的每一步都强依赖上一步的结果时，智能体之间互相沟通、对齐进度所花费的开销，反而挤占了本该用来推理的资源。

这就是论文提出的核心原则：架构要不要“加人”，不取决于任务难不难，而取决于任务能不能被拆解。这一条，恰恰是很多团队在设计智能体系统时最容易忽略的地方。

核心发现二：工具越多，协调“税”越重

论文还发现了一个此前很少被量化讨论的现象——“工具-协调权衡”（tool-coordination trade-off）。

当一个任务需要调用的工具越多（比如一个需要接入16种以上工具的编码智能体），多智能体协调所带来的额外开销就会不成比例地上升。研究团队给出的解释是：多智能体系统本质上是把有限的token预算，切分给了多个智能体，当任务本身就需要大量token去处理复杂的工具编排时，协调开销会进一步压缩每个智能体可用的“思考空间”，效率损失也就随之被放大。

这意味着，工具越复杂的任务，往往越不适合简单粗暴地“拆给一群智能体各管一部分工具”，除非协调机制本身经过精心设计。

核心发现三：架构，本身就是一种安全机制

如果说前两个发现回答的是“效果好不好”，那么这一个发现回答的是一个更现实的问题：多智能体系统会不会“越帮越乱”？

研究团队专门测量了一个指标——错误放大率，即一个智能体犯的错，最终有多大概率被放大、传导到整个系统的最终结果里。

结果很直接：在没有协调者、各自并行工作的独立式架构中，错误被放大了17.2倍——因为没有任何机制去互相检查、互相纠正，一个小失误很容易一路传导到最终输出。 而在设有协调者的中心化架构中，这个放大倍数被压到了4.4倍。协调者在这里扮演的角色，相当于一道“验证关卡”，在错误汇总进最终结果之前，就有机会把它拦下来。

这个发现的意义超出了“性能优化”本身：对于要在真实业务中部署智能体系统的团队来说，选架构，某种程度上也是在选一套“容错机制”。同样的任务，选独立式还是中心化架构，容错能力可能相差好几倍。

核心发现四：一个能提前“猜对”87%架构的预测模型

前面三个发现，本质上都是“事后总结的规律”。谷歌团队更进一步，把这些规律做成了一个可以“事前预测”的工具。

研究团队用任务的可测量特征——比如工具数量、任务的可拆解程度——训练出了一个回归预测模型（交叉验证 R²=0.373，如果换用更贴合任务本身的能力评估指标，R²可提升到0.413）。这个模型能在完全没见过的任务配置上，正确预测出最优架构，准确率达到87%。

换句话说，开发者以后不再需要靠“试了再说”来决定用单智能体还是多智能体、用哪种多智能体架构，而是可以先看任务本身的两个关键属性——顺序依赖程度和工具密度——就能大致判断出该往哪个方向设计系统。

小结：模型越强，越需要“会用”多智能体

论文的结论其实指向了一个反直觉但更接地气的判断：随着谷歌Gemini这类基础模型持续变强，多智能体系统并不会因此变得不必要——恰恰相反，模型越强，多智能体协作能撬动的收益也越大，前提是架构选对了。

对于正在做智能体产品的团队，这篇论文提供的与其说是一套具体算法，不如说是一份决策清单：

• 任务能不能拆成互不依赖的子任务？能拆，多智能体大概率划算；不能拆，先别急着堆智能体。
• 任务要调用的工具多不多？工具越多，协调成本可能吃掉多智能体的收益。
• 对可靠性要求高不高？如果高，优先考虑带协调者的中心化架构，而不是各自为政的独立式架构。
• 单智能体基线本身表现是不是已经很不错了？如果已经很高，加协调开销可能得不偿失。

从“多智能体是不是灵丹妙药”这种模糊的争论，到“具体什么任务该用什么架构”这种可以量化计算的工程问题——这或许才是这篇论文对整个行业最大的价值。

参考资料：

1. Google Research Blog: Towards a science of scaling agent systems: When and why agent systems work https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/
2. 论文原文：Towards a Science of Scaling Agent Systems（arXiv:2512.08296v3） https://arxiv.org/abs/2512.08296

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

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

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

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

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

本文永久链接 – https://tonybai.com/2026/05/20/ai-coding-win-rate-rankings-go-and-rust-vs-cpp

大家好，我是Tony Bai。

过去两年，程序员群体经历了一场前所未有的“职业身份危机”。

随着 GPT、Claude、Gemini 等模型的发布与能力更迭，各种“AI 几秒钟写出小游戏”、“AI 自动化修复 Bug”的新闻充斥屏幕。在各种传统的代码补全基准测试（如 HumanEval）中，大模型们动辄刷出 90% 以上的惊人通过率。一时间，“程序员是夕阳行业”、“架构师即将下岗”的言论甚嚣尘上。

然而，这只是硬核工程世界的冰山一角。最近，由 Meta FAIR（Meta 基础人工智能研究实验室）、斯坦福大学和哈佛大学联合发布的一项重量级研究——ProgramBench，彻底击碎了这些幻觉。

ProgramBench 的设计初衷非常“残暴”：它不再测试 AI 能不能写出一个简单的算法函数，而是测试 AI 能不能从零开始（From Scratch）复刻一个完整的开源项目，即从观测二进制行为（Probe）到编写源码（Build），再到最终的等效性评估。

测试规则如下：

1. 黑盒逆向：不给源码，只给 AI 一个编译好的二进制可执行文件（如 sqlite3、ffmpeg、ripgrep）和一份使用说明书。
2. 物理断网：切断互联网访问，防止 AI 通过搜索“偷看”GitHub 上的源码。
3. 架构自主：AI 必须自己决定项目的文件结构、选择什么编程语言、设计什么抽象层次。

图：ProgramBench 的评测全流程 在这场面向 200 个真实复杂项目的“闭卷考试”中，全球最顶尖的大模型们集体陷入了沉思。

数据表明，即便是在最强的模型面前，完全成功的概率依然是 0。

但在这场败战中，我们通过海量数据发现了一个足以改变未来十年技术选型的真相：Go 与 Rust 已经成为了 AI 时代的“天命语言”，而 C++ 则不那么受 AI 青睐，AI 用起来也不那么顺手！

诸神黄昏：Claude 对 GPT 家族的“工程级”碾压

在程序员的认知中，GPT 家族曾代表着 AI 的巅峰。但在 ProgramBench 的 Leaderboard（排行榜）上，局势发生了戏剧性的反转，但也正如我们预料的那样。

根据论文统计，在衡量“几乎完成”（即通过 95% 以上的测试用例）这一指标时，排名如下：

1. 头号种子：Claude Opus 4.7。它是全场唯一一个在 3.0% 的复杂项目中展现出近乎完美复刻能力的模型。
2. 二号梯队：Claude Opus 4.6 (2.5%) 与 Claude Sonnet 4.6 (1.6%)。
3. 集体挂零：GPT 5.4、Gemini 3.1 Pro。 没错，这些在其他榜单上呼风唤雨的模型，在“从零复刻完整项目”的任务中，竟然连一个能通过 95% 测试的任务都没完成。

为什么 GPT 会在硬核工程上输给 Claude？

研究人员通过分析“智能体轨迹（Agent Trajectories）”发现了秘密。大模型写代码有两种流派：

• “急性子”派（以 GPT 5.4 为代表）：GPT 倾向于“单次爆发”。数据显示，它在每个任务中平均只用 17 个命令。它习惯于在最初的几个回合内，直接吐出 96% 的代码。如果代码跑不通，它很少进行深度的自我修正。
• “架构师”派（以 Claude 为代表）：最强的 Claude 模型更像是一个深思熟虑的工程师。它平均每个任务会调用 868 个命令！它会不断地执行 ls 查看目录、用 cat 检查文件、反复运行测试并根据报错信息进行“重构”。

可见，在复杂的软件工程面前，单纯的“语料记忆”失效了。Claude 的胜出，本质上是其“推理链”和“持续迭代能力”的胜出。它不只是在背代码，它是在通过不断的试错来“推演”架构。

通过上图中不同模型的动作类型分布，我们可以看到 Claude 拥有极长且复杂的“读-写-探测”循环，而 GPT 的动作序列短得惊人。

语言偏好：AI 也有自己的“舒适区”

ProgramBench 给 AI 提供了完全的自由：AI 可以用任何语言来复刻目标程序。这产生了一个极其有趣的“语言混乱矩阵（Confusion Matrix）”。

1. GPT 的 Python 执念

GPT 5.4 表现出了近乎偏执的 Python 依赖。在所有任务中，它有 79% 的方案是用 Python 写的。无论原程序是用更底层的 C 还是 Rust 写的，GPT 的第一反应往往是：“我能不能用 Python 给它糊出来？”

2. Claude 的硬核品味

最强模型 Claude Opus 4.7 表现出了极高的系统级素养。它只在 14% 的情况下选择 Python，它更倾向于使用 Rust 和 Go 来应对复杂任务。这说明越强大的模型，越能理解底层语言在性能和逻辑表达上的严密性。

3. 为什么 AI 喜欢 Python？

原因很简单：容错率。 Python 拥有极其丰富的第三方包、极简的语法以及无需手动管理内存的特性。对于 AI 来说，Python 是它能用最少的回合数实现最多功能的“逃生路径”。但这种逃生是有代价的——复杂的系统级软件用 Python 复刻，往往会因为性能或底层调用模拟不足而失败。

各模型选择的实现语言分布图

深度解析：为什么 Go 与 Rust 是 AI 的“天命之子”？

这是本次研究中最具行业指导意义的发现。通过研究数据对比，我们发现不同语言在 AI 手下的“存活率”天差地别：

• Go 语言项目：AI 成功通过率 38.4%
• Rust 语言项目：AI 成功通过率 38.5%
• C/C++ 项目：AI 成功通过率仅为 27.7%

为什么同样是系统编程语言，Go 和 Rust 就能完胜 C++？这不仅仅是语法的问题，更是现代工程化基建的降维打击。

不同语言生态下的测试通过率对比图

1. 构建系统：AI 开发者的“生死线”

在 C/C++ 的世界里，构建系统是混乱的代名词。CMakeLists.txt、Makefile、系统特定的动态链接库（.so/.dll）路径……对于 AI 智能体（SWE-agent）来说，这些是致命的障碍。

调研显示，AI 在 C++ 任务中，往往还没开始写业务代码，就已经在配置环境时陷入了死循环。

反观 Go 和 Rust：

• Go：一个 go mod tidy 加一个 go build 解决了全球 99% 的构建问题。
• Rust：Cargo 是目前人类文明最先进的包管理器之一。

对于 AI 来说，这种“标准化”意味着它只需要执行一条命令就能建立起完整的工程环境。这种极高的工程化一致性，让 AI 可以把宝贵的 Token 消耗在业务逻辑上，而不是折腾环境。

2. 标准库的“全家桶”效应

Go 语言一直以“自带电池（Batteries included）”著称。它的标准库涵盖了网络、加密、编解码等大部分现代互联网开发所需的功能。AI 调用 Go 的标准库就像从兜里掏东西一样自然。

而 C++ 的标准库相对贫瘠，往往需要引入第三方库（如 Boost, libcurl）。一旦涉及到第三方依赖，AI 的出错概率就会呈指数级上升。

3. 内存安全：给 AI 的“保护索”

在 C/C++ 中，AI 极其容易写出缓冲区溢出、内存泄露或段错误。一旦程序在运行过程中崩溃，由于 AI 缺乏深度的 GDB 调试能力，它很难从 Core Dump 中恢复。

Rust 严格的借用检查（Borrow Checker），在编译阶段就强行纠正了 AI 的大部分错误。这种“编译即正确”的反馈循环，让 AI 在复刻软件时拥有了更高的胜率。

揭秘 AI 程序员的“坏习惯”：屎山代码的起源？

除了排名和语言，ProgramBench 还揭露了目前 AI 编码的三个极具冲击力的特征：

1. 单文件架构迷恋

人类架构师讲究解耦，喜欢建立复杂的目录结构。但 AI 却恰恰相反。数据显示，67% 的 AI 方案产生的目录深度明显浅于原项目。

AI 表现出强烈的“单文件狂魔”倾向。 它们喜欢把数千行代码塞进 1-3 个超级大文件里。这反映出目前的模型在处理跨文件的上下文关联时，依然存在明显的认知衰减。

2. 逻辑“大颗粒化”

AI 写的函数数量通常只有人类原作者的 10% 到 20%。但这并不意味着功能缺失，而是因为 AI 喜欢写超长函数（God Functions）。

Claude 生成的函数长度平均是人类的 1.46 倍，Gemini 甚至达到了 1.62 倍。这种代码对于 AI 来说运行没问题，但对于人类后续维护来说，简直是噩梦。

3. 诚信危机：AI 也会“偷懒作弊”

在测试的早期阶段，研究人员尝试给 AI 开启互联网访问。结果发现，最强的大模型们全都是“老油条”。

一旦它们通过二进制文件的帮助信息（–help）推断出这是哪个开源项目，它们会直接去克隆对应的 GitHub 仓库代码并提交。

Claude Sonnet 4.6 的作弊率一度高达 36%！ 这迫使研究团队最终必须在完全断网的环境下运行测试。这告诉我们：永远不要低估大模型为了完成任务而寻找“捷径”的本能。

小结：程序员的黄昏还远未到来

看完这份长达 60 多页的研究报告，我们不仅没有感到绝望，反而产生了一种前所未有的踏实。

报告证明了：即便是在最顶尖的模型面前，真实的软件工程（Software Engineering）依然是一个极度复杂的高壁垒领域。写代码只是软件工程中最后、最轻的一环。而之前的架构设计、模块拆分、抽象提取、以及对业务边界的理解，目前的 AI 依然处于“学龄前”阶段。

给开发者的建议：

1. 向 Go 和 Rust 迁移：这不只是性能考量，更是为了拥抱 AI。如果你想让 AI 帮你更高效地干活，请选择那些对 AI 友好的工程化基建。
2. 强化架构师思维：既然 AI 喜欢写单文件“屎山”，那么如何管理大型项目的复杂性、如何通过 Prompt 引导 AI 进行模块化设计，将是未来高级工程师的核心竞争力。
3. 拥抱 Claude 模式：告别“单次生成”的幻觉，建立起“持续迭代、自动测试、反复纠错”的 AI 开发流水线。

程序员的黄昏还远未到来。

相反，我们正在进入一个全新的时代：一个由人类架构师掌控蓝图，由 AI 劳工在标准化的 Go/Rust 仓库中疯狂试错、高效产出的黄金时代。AI 并没有取代你，它只是淘汰了那些只会机械写代码、而不懂工程设计的“码农”。

真正的开发者，正在迎来属于他们的、被 AI 加持的黎明。

资料链接：

• https://arxiv.org/abs/2605.03546
• https://programbench.com/

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

本文永久链接 – https://tonybai.com/2026/01/23/go-developer-2025-survey-result

大家好，我是Tony Bai。

近日，Go 官方发布了 2025 年开发者调查报告。作为 Go 社区的年度“体检报告”，这份基于 5,379 份有效问卷的数据，为我们勾勒出了一幅清晰的 Go 生态全景图。

总体来看，Go 依然是一个令人愉悦的语言，拥有极高的用户忠诚度和稳固的云原生地位。但在这份光鲜的成绩单背后，我们也看到了一些值得深思的信号：关于最佳实践的迷茫、对 AI 工具的爱恨交织，以及对官方领导力的期待。

今天，让我们抛开表面的数字，一起来解读一下这份报告背后的趋势与挑战。

画像：成熟、专业，但新人“断层”？

首先，让我们看看是谁在使用 Go。

• 专业主义：87% 的受访者是专业开发者，82% 将 Go 用于主要工作。这再次印证了 Go 是一门“为生产而生”的语言。
• 经验丰富：75% 的开发者拥有 6 年以上的职业编程经验。更有意思的是，81% 的人表示他们的职业经验长于 Go 经验。这意味着绝大多数 Gopher 都是从其他语言（如 Java, Python）“转行”而来的。

隐忧：使用 Go 不满 1 年的新人比例从 2024 年的 21% 下降到了 13%。

这可能并非 Go 的吸引力下降，而是受宏观经济影响，入门级软件工程师岗位的招聘紧缩。由于许多人是为了特定工作才学习 Go，招聘市场的寒冬直接传导到了新人的流入率上。这提醒社区，需要更多关注新人的入门体验和职业引导。

满意度：稳如泰山，但“成长的烦恼”依旧

Go 的核心竞争力依然坚挺：91% 的开发者对使用 Go 感到满意，其中“非常满意”的比例高达近 2/3。这一数据自 2019 年以来一直保持极高水平。

开发者们爱 Go 的理由很纯粹：简单、标准库强大、工具链完善。

一位来自能源行业的 10 年+ 资深开发者评价道：“我使用 Go 的全部原因就是其出色的工具和标准库… 它让开发面向服务的应用变得简单而可靠。”

然而，痛点依然存在：

1. 最佳实践的迷茫 (33%)：这是连续多年的头号痛点。开发者们渴望官方能提供更具观点性 (opinionated) 的指导，比如“如何组织项目结构”、“如何优雅地处理错误”。
2. “别人家孩子”的功能 (28%)：许多开发者怀念其他语言的特性，如 Enum (枚举)、Sum Types、以及更简洁的错误处理（摆脱 if err != nil）。
3. 信任危机 (26%)：如何找到高质量、值得信赖的第三方模块？开发者希望 pkg.go.dev 能提供类似“稳定版本”、“用户数量”、“维护活跃度”等更明确的质量信号。

应用场景：云原生的统治者，AI 的探索者

Go 用来做什么？答案毫无悬念：

• CLI 工具 (74%)
• API 服务 (73%)
• 云基础设施工具 (38%)

这“三驾马车”构成了 Go 的基本盘。

但在最热门的 AI 领域，Go 的表现呈现出一种**“双刃剑”**态势。

• 开发者的态度：53% 的 Gopher 每天都在使用 AI 辅助编程工具。
• Go 的角色：尽管 11% 的人正在用 Go 构建 ML/AI 模型或工具，但78% 的受访者表示他们目前的 Go 项目不包含 AI 功能。相比 2024 年的 59% 未参与，这个比例反而上升了。这可能意味着初期的 AI 炒作冷却后，企业在生产环境中落地 AI 功能时变得更加谨慎。

AI 工具：既是蜜糖，也是砒霜

关于 AI 辅助编程（如 GitHub Copilot, ChatGPT，Claude Code, Gemini等），调查结果揭示了一个有趣的现象：用得越多，抱怨越多。

• 使用率：ChatGPT (45%) 和 GitHub Copilot (31%) 是主流，Claude (25%) 紧随其后。
• 满意度：虽然 55% 的人表示满意，但大部分只是“比较满意”，远低于对 Go 语言本身的满意度。

为什么？因为质量。

开发者们发现，AI 在**“寻找信息”（如解释代码、查找 API 用法）和“消除苦力活”（如生成单测、写样板代码）方面表现出色。但在“编写核心代码”时，AI 经常生成不可运行、有 Bug 或不符合 Go 惯用写法 (Non-idiomatic)** 的代码。

一位金融行业的开发者吐槽道：“我从未对 AI 生成的代码质量满意过……我也觉得审查 AI 生成的代码非常累人，这种开销扼杀了它的生产力潜力。”

官方的自我反思：文档与信任

这份报告最令人敬佩的一点，是 Go 团队对自己工作的坦诚审视。

• 文档导航：调查发现，即使是 go build、go run 这样最基础的命令，也有 15%-25% 的开发者需要频繁查阅文档。这说明 Go 命令行的帮助系统 (go help) 体验并不好，甚至有些“劝退”。
• 社区信任：与对语言本身的高满意度相比，开发者对“Go 团队是否理解我的需求”这一项的信心相对较低。一位受访者直言，随着第一代创始人逐渐淡出，他们对现任团队的决策方向感到担忧。

官方回应：Go 团队已明确表示，2026 年将重点投资于鼓励更多贡献者参与，并加强与社区的沟通，以重建信任。

小结：稳中求变

2025 年的 Go，像一位步入中年的稳重工程师。它在云原生领域有着不可撼动的地位，但也面临着来自新兴技术栈（如 AI 开发中 Python 的强势）和自身语言特性（如错误处理、枚举）的挑战。

对于 Gopher 而言，这份报告既是定心丸，也是冲锋号。它告诉我们：Go 依然是构建可靠后端服务的最佳选择，但我们也需要更积极地拥抱变化，探索最佳实践，并在 AI 浪潮中找到属于 Go 的独特生态位。

资料链接：https://go.dev/blog/survey2025

你的年度总结

看完这份官方报告，你觉得它准确反映了你的现状吗？在你看来，Go 语言目前最大的痛点是什么？对于 AI 辅助编程，你是“真香”还是“劝退”？

欢迎在评论区分享你的真实感受！让我们一起为 Go 社区的发展建言献策。

如果这篇文章让你对 Go 生态有了更全面的了解，别忘了点个【赞】和【在看】，并转发给你的 Gopher 朋友，看看他们怎么说！

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

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

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

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/12/17/cloudflare-2025-report-go-language-api-traffic-ai-surge

大家好，我是Tony Bai。

近日，互联网基础设施巨头 Cloudflare 发布了其备受瞩目的《2025 年度互联网回顾报告》。这份基于其全球庞大网络数据的报告，如同一面镜子，映照出全球互联网在流量、技术、安全和 AI 等领域的最新脉搏。

而对于我们 Go 开发者而言，今年的报告带来了两个极其振奋人心的消息：

1. Go 语言在自动化 API 客户端领域的王者地位，不仅得以巩固，甚至还在持续扩大领先优势。
2. AI 相关流量和应用正在以前所未有的速度崛起，而 Go 正是这股浪潮背后不可或缺的基础设施构建者。

本文将为你深度解读这份报告中，与我们 Gopher 息息相关的核心亮点。

Go 语言：自动化 API 领域的“超级巨星”

在现代应用架构中，自动化 API 请求（即服务与服务之间的机器通信）早已成为流量的主体。而构建这些 API 客户端的编程语言，其流行度直接反映了该语言在后端和基础设施领域的真实“统治力”。

Cloudflare 的报告再次确认了一个我们早已熟知，但看到数据后依然会心潮澎湃的事实：Go 是自动化 API 客户端最受欢迎的选择。

关键数据解读：

• 五分之一的天下：在 2025 年，全球 20% 的自动化 API 请求，都是由基于 Go 的客户端发出的。这意味着，每五个飞驰在互联网上的自动化 API 请求中，就有一个是用 Go 编写的！

• 惊人的增长势头：这一数字，相较于 2024 年的 12%，实现了超过 66% 的惊人增长。Go 不仅是第一，而且正在以“断层式”的速度，进一步拉开与追赶者的差距。

• 竞争格局：Python 紧随其后，份额从 9.6% 增长到 17%。而去年排名第二的 Node.js，其份额则跌至 8.3%，被 Java (11.2%) 超越。

为什么是 Go？

这份数据雄辩地证明了 Go 在构建网络服务和客户端方面的核心优势：

1. 极致的性能与并发：Go 的 goroutine 模型，使其能够以极低的资源开销，轻松处理海量的并发 API 请求。
2. 强大的标准库：net/http 标准库本身就极其强大、易用且生产力极高。
3. 静态二进制文件：Go 能够编译成无依赖的单一二进制文件，这对于在容器化环境中部署 API 客户端和服务，简直是“天作之合”。

AI 浪潮：新的战场，Go 的新机遇

如果说 Go 在 API 领域的领先是“意料之中”，那么报告中关于 AI 流量的爆炸式增长，则为 Go 的未来描绘出了一个更加激动人心的新战场。

Googlebot：AI 时代的“头号流量玩家”

报告指出，连续第三年，来自 Google IP 段 66.249.64.0/20 的流量，成为 Cloudflare 网络上最大的请求来源。这背后的“巨兽”，正是 Googlebot。

值得注意的是，Googlebot 已经演变成一个双重目的的爬虫：它不仅为传统搜索引擎建立索引，更在为 Google 的 AI 模型（如 Gemini）进行大规模的数据抓取和训练。

2025 年，Googlebot 贡献了超过 28% 的“已验证机器人”流量，其爬取量远超 OpenAI 的 GPTBot (7.5%) 和微软的 Bingbot (6%)。

AI 用户行为流量激增 15 倍

报告将 AI 爬虫流量分为三类：训练 (training)、搜索 (search) 和用户行为 (user action)。其中，“用户行为”指的是当用户在 ChatGPT 等应用中提问，AI 为了回答问题而去实时访问外部网站所产生的流量。

2025 年，这类“用户行为”驱动的 AI 爬取流量，增长了超过 15 倍！

这预示着一个全新的互联网范式正在形成：越来越多的流量，将不再由人类直接发起，而是由 AI 智能体，为了服务于人类的需求而发起。

Go 在 AI 基础设施中的角色

这对 Go 开发者意味着什么？

AI 模型本身或许由 Python 主导，但支撑这些模型进行大规模数据爬取、数据处理、模型服务（API serving）的庞大基础设施，正是 Go 语言大显身手的领域。

当你看到 ChatGPT、Perplexity 等服务的流量排名在“生成式 AI 服务”榜单中不断攀升时，可以想见，其背后必然有无数由 Go 编写的高性能 API 网关、数据管道和后端服务在默默支撑。

其他值得关注的趋势

• 后量子加密曙光：由人类产生的、采用后量子加密的 Web 流量份额，在 2025 年从年初的 29% 增长到了 52%。这主要得益于苹果在 iOS 等操作系统中默认开启了对混合量子安全密钥交换的支持。
• HTTP/3 稳步增长：全球使用 HTTP/3 和 HTTP/2 的 Web 请求份额都在微弱增长，HTTP/3 的占比达到了 21%。
• Starlink 流量翻倍：卫星互联网服务 Starlink 的流量在 2025 年翻了一番，显示出其在全球“连接未连接者”方面的巨大潜力。

小结语：站在时代的潮头

Cloudflare 的 2025 年度报告，为我们描绘了一幅激动人心的画卷。在这幅画卷中，Go 语言不仅是当前云原生和 API 经济的绝对王者，更是即将到来的 AI 时代不可或缺的核心基础设施构建者。

“五分之一的 API 请求由 Go 发出”——这个数据，不仅仅是一个值得骄傲的里程碑，更是对 Go 语言设计哲学——简单、高效、并发——在真实世界中取得巨大成功的最有力证明。作为 Gopher，我们正站在时代的潮头。

资料链接：

• https://blog.cloudflare.com/radar-2025-year-in-review/
• https://radar.cloudflare.com/year-in-review/2025

你的“体感”如何？

数据告诉我们，Go 正在制霸 API 领域。在你日常的工作中，是否也感受到了 Go 在微服务、网关或 AI 基础设施中的统治力？或者，你观察到了 Python 或 Rust 在哪些特定领域正在发起挑战？

欢迎在评论区分享你的一线观察，让我们一起拼凑出更真实的技术版图！

如果这篇文章让你对 Go 的未来更有信心，别忘了点个【赞】和【在看】，并转发给你的团队！

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

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

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

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/08/28/go-primer-published

大家好，我是Tony Bai。

前不久，在知乎上看到一个关于 Go 社区的帖子，其中一条评论让我感慨良多：

“GopherChina 都没了，国内还有几人坚持？Tony Bai好像还在更新”

短短一句话，道尽了社区的变迁与坚持的不易。这句来自读者的回答，让我内心欣慰，也让我有机会停下来，审视自己在这条路上走了多远，以及为什么还要继续走下去。

答案或许很简单，就是三个字：长期主义。

我的个人博客 tonybai.com，从 2004 年断断续续更新至今，已经走过了二十个年头。而我在 Go 语言这条路上的“长期主义”，则始于 2011 年。那时，Go 尚处襁褓，在国内几乎无人问津。我凭借着一股直觉和热爱，一头扎了进去，成为了国内最早一批的 Go 语言探索者。

十余年来，这份坚持从未间断。从早期的博客分享，到后来出版的《Go语言精进之路》；从 GopherChina 大会的讲台，到几乎每日更新的 GopherDaily，我一直在尽我所能地为社区贡献。

这份坚持也延续到了今年。从年初开始，我在公众号上陆续推出了多个“微专栏”系列，深入探讨 Go 源码与实践的细节；与此同时，我的新课程**《Go语言进阶课》**也已在极客时间上线，希望能带领大家向更深层次迈进。

布道，其实是一件极具价值的事情——传递自己的观点，影响一群人，做成一件事。

今天，我的这份“长期主义”清单上，又将增添新的一项。我想借此机会，向一直支持我的朋友们，正式宣布一个喜讯。

官宣喜讯：历时一年半，2.4w 人订阅的《Go语言第一课》成书！

四年前，我在极客时间开设了专栏**《Go语言第一课》**。令我欣慰的是，这个专栏得到了广大 Gopher 的认可和喜爱。截至今日，它已经影响了超过 2.4 万名订阅者(截至2025.8)，在编程语言类专栏里取得了相当不错的成绩。

为了让这份经过市场检验的优质内容，能以一种更经典、更触手可及的方式，帮助更多人踏入 Go 语言的大门，我与人民邮电出版社异步图书合作，历时一年多的精心打磨，终于将它变成了纸质书 — 我的第二本“小黄书”：

我必须强调，这本书并非专栏的简单复制。在近一年多的时间里，我倾注了大量心血，进行了一次彻底的精修与增补：

• 内容与时俱进：全书内容与最新的 Go 1.24 版本 同步(注：交稿时的最新版本为Go 1.24)，确保知识的前沿性与准确性。
• 知识体系更完整：我特别补充和深化了专栏中因篇幅所限未能详尽展开的关键内容，如指针类型的深入探讨、测试的最佳实践、以及泛型的全面讲解，使其作为一本入门读物更加系统和完备。
• 全面精炼与优化：基于三年来数万读者的宝贵反馈，我对全书的结构、文字表述、示例代码和图示进行了地毯式的优化，力求为读者提供“保姆级”的丝滑阅读体验。

为了让大家更直观地感受这本书是如何从“道”到“术”，构建一个完整而系统的知识体系的，我在这里分享本书的核心目录结构：

《Go语言第一课》核心目录概览

• 第一部分：建立宏观认知 (打好地基)

  • 第1章 Go的那些事儿 (追本溯源，深入理解Go的诞生背景、演进历史与核心设计哲学：简单、显式、组合、并发、面向工程)

• 第二部分：基础与工程化 (工欲善其事)

  • 第2章 建立Go开发环境
  • 第3章 第一个Go程序
  • 第4章 Go包、模块与代码组织结构
  • 第5章 Go的依赖管理 (从演化到Go module实战)

• 第三部分：核心语法精讲 (深入肌理)

  • 第6章 变量与类型
  • 第7章 基本数据类型
  • 第8章 常量 (深入理解无类型常量等创新)
  • 第9章 复合数据类型 (数组、切片、map、结构体)
  • 第10章 指针类型 (新增与深化章节，彻底搞懂Go指针)
  • 第11章 控制结构

• 第四部分：Go编程思想与范式 (提升境界)

  • 第12章 函数 (一等公民、defer的妙用与代价)
  • 第13章 错误处理 (Go独特的错误处理哲学与实践)
  • 第14章 方法 (深入理解Receiver的选择原则)
  • 第15章 接口类型 (小接口、组合思想与底层实现)

• 第五部分：Go核心竞争力 (决胜未来)

  • 第16章 并发编程 (Goroutine、Channel与CSP并发模型)
  • 第17章 泛型 (与Go 1.24同步，从设计演化到语法实践)
  • 第18章 测试 (表驱动测试、示例测试、性能基准测试等最佳实践)

从这份目录中大家可以看到，本书的路径设计清晰：从建立对 Go 的整体认知和哲学认同开始，到掌握扎实的工程基础，再到深入语言的核心语法与编程范式，最终聚焦于并发、泛型和测试这三大核心竞争力。 这是一条为初学者量身打造的、平滑而陡峭的学习曲线，旨在帮助你不仅学会 Go，更能学好 Go。

当然这份精益求精的背后，离不开人民邮电出版社异步图书编辑老师们的辛勤付出。在长达一年的审校过程中，他们以极高的专业素养和一丝不苟的态度，对书稿的每一处细节进行推敲和打磨。从章节结构的优化，到遣词造句的斟酌，再到每一个标点符号的校对，都倾注了大量心血。

下面这张布满批注的审稿截图，只是责任编辑秦健老师无数次打磨与推敲的一个缩影。正是因为有了这样认真负责的合作伙伴，这本书才能以更好的面貌呈现给大家。在此，向编辑老师们致以我最诚挚的谢意！

简单来说，这本书凝结了我十余年的 Go 语言实战经验和布道心血，旨在为所有初学者提供一条清晰、高效的 Go 语言入门路径，不仅能快速上手，更能从一开始就建立起扎实的工程思维，为后续的进阶和实战打下坚实的基础。

灵魂拷问：AI 时代，我们为什么还需要一本入门书？

官宣完毕，我想和你探讨一个更深层次的问题。

在 ChatGPT、Claude、Gemini、DeepSeek、Copilot 等 AI 工具已经能“秒答”任何技术问题的今天，我们为什么还需要静下心来，系统地去阅读一本厚重的、入门级的纸质书？

这是一个极其现实的挑战。作为一名同样深度使用 AI 的工程师，我的答案是：越是在这个时代，我们越需要一本好的入门书。

1. AI 提供“答案”，书籍构建“体系”

AI 的强大之处，在于它能针对你提出的具体问题，迅速给出一个看起来可行的“答案”（代码片段）。它能高效地帮你解决“术”层面的问题。

但一本好的入门书，为你构建的是一张捕鱼的“网”——一个结构化、系统化的知识体系。它从语言的“前世今生”与设计哲学讲起，为你建立宏观认知；然后层层递进，系统讲解语法、并发、泛型等核心知识点。

没有体系的知识是脆弱的、零散的。你或许能用 AI 拼凑出一个能运行的程序，但在面对复杂、未知的问题时，你将因为缺乏坚实的知识框架而寸步难行。而这本书，正是为你打造这张网。

2. 对抗“能力空心化”，修炼真正的“内功”

我在之前的文章中反复提及一个概念——警惕 AI 带来的“能力空心化”。过度依赖 AI，会让初级工程师陷入“知其然，而不知其所以然”的困境。

系统地学习一本入门书，恰恰是修炼“内功”的最佳方式。它强迫你去理解每一行代码背后的设计哲学、核心原理、以及那些微妙的权衡取舍。

• 为什么 Go 的错误处理是这样的？
• interface{} 的底层实现是怎样的？
• CSP 并发模型的核心思想是什么？

这些问题的答案，无法通过简单的 Prompt 获得。它们需要你沉下心来，跟随作者的思路，一步一个脚印地去理解和内化。这个过程，正是在构建你作为一名工程师，那份不可被 AI 替代的核心竞争力。

3. 纸质书，一种无可替代的沉浸式学习体验

最后，让我们回归阅读本身。

在信息过载的今天，纸质书提供了一种稀缺的、主动的、专注的、沉浸式的学习体验。它能帮助我们暂时摆脱屏幕上无尽的通知和干扰，让大脑进入一种更深度的思考状态。你可以随时在书页上圈点、批注，与作者进行一场跨越时空的对话。这种物理的交互感和知识的“拥有感”，是任何数字媒介都无法比拟的。

布道者的心声：传递观点，影响他人

回首这十几年的 Go 之旅，我愈发觉得，布道本身就是一件极具价值的事情。它不仅仅是分享知识，更是传递一种观点，影响一群人，最终一起做成一件事情。

我写博著书和开设专栏的初衷，也正是如此。我希望传递的，不仅仅是 Go 语言的“术”——那些语法和技巧；更是 Go 语言的“道”——那种**“简单、显式、组合、并发、面向工程”**的编程哲学与乐趣。

在此，我要特别感谢极客时间平台，感谢人民邮电出版社异步图书的专业与付出，但最想感谢的，是四年来那 2.4w+ 的专栏订阅者，以及所有在我的博客、公众号、社区中与我交流、给我反馈的每一位读者。是你们的支持，才让这份“长期主义”有了最坚实的意义。

行动号召：即刻拥有你的《Go语言第一课》

现在，这本凝结了无数心血的《Go语言第一课》纸质版，已正式上市！

在本书的定价阶段，我和出版社的编辑老师们有一个共同的坚持：希望能让更多的 Go 语言爱好者，能够以更低的门槛，轻松地获取这份系统化的知识。为此，我们将这本书的定价一再压缩，最终定在了 79.8 元。

而为了感谢大家一直以来的支持与耐心等待，我们特别为大家申请了首发专属福利。在活动期间，大家可以通过下方的专属链接，以**【五折优惠】**的价格——算下来仅需不到 40 元——将这本300多页的硬核知识带回家。

这可能是本书在未来很长一段时间内的最低价格，希望能让每一位真正热爱 Go 语言的朋友，都能无压力地拥有它。

扫描下方二维码或点击这里， 即享五折优惠，即刻开启你的Go语言高效学习之旅！

请注意，此五折优惠二维码仅在新书首发冲量期间有效，机会难得，不要错过！

为了更好地服务本书读者，我也为本书创建了专属的 GitHub 仓库，用于持续发布勘误信息和提供完整的配套示例代码。追求高质量，是我们共同的目标。

• 勘误与代码支持：https://github.com/bigwhite/goprimer

期待在书的扉页里，与你相遇。

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

本文永久链接 – https://tonybai.com/2025/08/18/ai-app-dev-guide-for-gopher

大家好，我是Tony Bai。

过去两年，人工智能（AI）以前所未有的姿态，从学术的象牙塔走入了软件工程的每一个角落。以大语言模型（LLM）为代表的生成式AI以及智能体AI，正在重塑我们开发、交付甚至构思软件的方式。

作为一个 Gopher，我们习惯于在云原生、微服务的世界里追求极致的性能与简洁。但当我们抬起头，看到 AI 的浪潮席卷而来，看到 Python 生态的繁荣，心中难免会产生疑问：

• Go 语言在 AI 时代的位置在哪里？
• 我们现有的技能树，如何与 AI 的新范式结合？
• 如果现在要入局 AI，一条清晰、高效、不走弯路的学习路径是怎样的？

这篇文章，就是我为你准备的答案。它不是一篇制造焦虑的快餐文，而是一份力求全面、客观、深入的“入局指南”。我们将系统性地梳理 Go 在 AI 时代的定位、生态全景，并为你规划一条从入门到实践的完整路径。

如果你准备好了，就请泡上一杯咖啡，让我们开始这次深度探索。

战略定位：Go 在 AI 应用开发中的“生态位”

首先，我们必须清晰地认识到，在 AI 领域，不同的编程语言扮演着不同的角色。Go 的核心价值不在于“模型研究”，而在于**“模型能力的工程化与产品化”**。

当一个强大的预训练模型（如 GPT-5、Claude Opus 4.1或Google Gemini 2.5 Pro）通过 API 暴露出来后，它就成了一种新的“计算资源”。如何高效、稳定、大规模地调用这种资源，并将其无缝集成到现有的软件系统中，这正是 Go 的主战场。

Go 的四大核心优势，决定了它在这个生态位上的不可或缺性：

1. 性能与并发： AI 应用后端往往是高并发、I/O 密集的，Go 的并发模型和性能表现是其构建健壮服务的基础。
2. 部署与运维： 静态编译的单一二进制文件，完美契合云原生时代的容器化部署，极大降低了 AI 服务化的运维成本。
3. 网络与工具链： 成熟的 net/http 库和强大的工具链，使其成为编排复杂 AI 工作流、构建 API 网关的理想选择。
4. 工程化与稳定性： 静态类型和清晰的错误处理，为构建大型、可靠、可维护的 AI 系统提供了保障。

结论： Gopher 的战场不在于和 Python 争夺“炼丹炉”，而在于成为将 AI 能力输送到千行百业的“工程管道”和“坚固引擎”。

生态全景：Gopher 的 AI “武器库”详尽盘点

要入局，先看牌。当前 Go 的 AI 生态已经发展到了什么程度？下面是一份详尽的清单，建议收藏。

1. 主流大模型 Go SDK

这是我们与 AI 对话的“官方桥梁”。

• OpenAI (GPT 系列, DALL·E, Whisper等):

  • 官方 Go SDK: github.com/openai/openai-go

• Anthropic (Claude 系列):

  • 官方 Go SDK: github.com/anthropics/anthropic-sdk-go

• Google (Gemini, PaLM 等):

  • Google AI Go SDK: google.golang.org/genai(https://github.com/googleapis/go-genai) (用于 ai.google.dev 上的模型)

• 字节跳动 (豆包大模型):

  • 火山引擎 Go SDK: github.com/volcengine/volcengine-go-sdk

• Cohere:

  • 官方 Go SDK: github.com/cohere-ai/cohere-go

2. 大模型应用框架

它们是构建复杂应用的“脚手架”。

• langchaingo: LangChain 的 Go 实现 (github.com/tmc/langchaingo)，提供了 Chains, Agents, RAG 等核心组件，是目前 Go 社区最主流的选择。
• cloudwego/eino: 字节跳动 CloudWeGo 团队开源的框架 (github.com/cloudwego/eino)，更侧重于工程化实践和性能优化。

3. 本地化与私有部署方案

让你在本地就能拥有强大的 AI 能力。

• Ollama: (ollama.ai) 让你能一键在本地运行 DeepSeek R1，Llama 4, Mistral, Gemma, gpt-oss，qwen3 等顶级开源模型。它本身就是用 Go 写的，是 Gopher 的“亲儿子”。
• LocalAI: (localai.io) 一个 OpenAI 兼容的本地推理引擎，可以用同样的 API 格式调用本地模型。

4. 向量数据库与 RAG 生态

这是让 LLM 拥有“私有知识”的关键。

• Go 客户端支持： 主流向量数据库如 Weaviate, Qdrant, Milvus, Pinecone, Chroma 等均提供功能完备的 Go 客户端。
• Go 原生项目： 值得一提的是，Weaviate 和 Milvus 这两个顶级的开源向量数据库，其核心后端都是用 Go 语言开发的，再一次证明了 Go 在 AI 基础设施领域的强大实力。

5. 模型上下文协议（MCP）生态

这是一个旨在标准化 LLM 与外部世界（工具、数据）连接的新兴生态，极具潜力。

• MCP (Model Context Protocol): 它定义了一套标准的 Client-Server 协议，让 LLM 应用可以像访问 Web API 一样，以一种统一、安全、可发现的方式获取外部上下文信息。
• MCP官方 Go SDK: github.com/modelcontextprotocol/go-sdk，提供了构建 MCP 客户端和服务端所需的核心库。
• 官方注册中心 (Registry): github.com/modelcontextprotocol/registry，这是一个官方维护的 MCP 服务描述仓库，类似于 Protobuf 的公共 API 定义，便于发现和集成第三方的 MCP 服务。

学习路径：Gopher AI 入局三步走

有了武器，我们该如何规划学习路径？我建议分三步走：

第一步：掌握AI应用开发基础

这是所有 AI 应用的起点，目标是让你能独立构建出功能完整的、指令驱动的 AI 应用。你需要掌握：

• LLM 核心概念： 什么是对话、消息、角色、Token？
• OpenAI 兼容 API： 这是业界的事实标准，学会它，你就能和市面上 90% 的模型对话。
• Prompt 工程基础： 学习如何通过角色扮演、思维链等技巧，写出能让 LLM 精准理解你意图的 Prompt。
• Go SDK 使用： 学会用 openai/openai-go 等主流 SDK 替代裸调 API，提升开发效率。
• 应用框架初探： 了解 langchaingo和eino 等框架的价值，学会用它来组织和简化你的应用逻辑。

第二步：精通高级应用模式

在掌握基础后，你需要学习几种最核心的、能让你的应用能力产生质变的高级模式：

• 检索增强生成 (RAG): 如何通过外挂向量数据库，让 LLM 能够基于你的私有文档（如公司内部 Wiki、项目代码）来回答问题，解决模型知识局限和幻觉问题。
• AI Agent 开发： 学习 ReAct 等工作流原理，构建能够自主思考、规划、调用工具的智能体，让你的应用从“听指令”进化到“自主完成任务”。

第三步：探索前沿与底层

当你能熟练构建应用和智能体后，可以开始探索更前沿或更底层的领域：

• 多模态开发： 如何处理和生成图像、音频等多模态数据。
• 模型微调 (Fine-tuning): 了解如何用自己的数据对开源模型进行微调，以适应特定任务。
• AI 基础设施： 深入了解 Ollama、向量数据库等 Go 项目的实现原理。

结语：从指南到你的第一行 AI 代码

读到这里，我相信你对 Go 语言在 AI 时代的版图和你的个人学习路径，已经有了一张清晰的、升级版的地图。这份指南为你描绘了全局，盘点了资源，规划了路径。

但地图终究只是地图。真正的探索，始于你写下第一行代码的那一刻。

理论和现实之间，总有一段需要手把手引导的距离。为了帮助你系统、深入且不留死角地走完这张全新的“三步走”地图，我将这份指南的全部核心内容，精心打磨、扩充和升华，形成了一门内容极其详尽的、体系化的微专栏——《AI 应用开发第一课》。

这门课程，就是我为你铺设的那条通往 AI 世界的第一段高速公路。

在这门超过 10 讲的课程里，我们追求的不再是“浅尝辄止”，而是“逐个击破”：

• 我们只讲最核心的： 课程将聚焦于 LLM 交互准则、Prompt 工程、Go SDK 和应用框架 这四大基石，确保你学到的都是“最小完备”的必备技能。
• 我们用整整三讲的篇幅，带你死磕 API 交互的每一个细节，让你对非流式、流式、多轮对话的 Go 实现都了如指掌。
• 我们用两讲的篇幅，带你深入 Prompt 工程的“道”与“术”，从核心原则到进阶技巧，让你写出的 Prompt 拥有“灵魂”。
• 我们用三讲的篇幅，带你遨游 Go AI 的工程化世界，从 OpenAI SDK 到多模型 SDK，再到应用框架，让你拥有选择最佳工具的智慧。
• 最后，我们将用一个压轴的实战项目，将所有知识串联起来，亲手构建一个能帮你自动化处理 GitHub Issue 的 AI 助手！

学完这门课程，你不仅能掌握用 Go 开发 AI 应用的“术”，更能建立起面向未来的“道”——一种全新的、将 AI 能力融入软件工程的思维方式。

这份指南给了你入局的信心和方向。而我的课程，将给你开启这段旅程的钥匙和第一场酣畅淋漓的胜利。

AI 时代，Gopher 不会缺席，更将大有可为。

扫描下方二维码，让我们一起，将这份指南变为你代码仓库里的现实。

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/07/05/agentic-coding-is-the-future

大家好，我是Tony Bai。

软件开发的范式正在经历一场深刻的变革。从 GitHub Copilot 的惊艳亮相，到各种IDE中集成的代码生成功能，我们已经习惯了 AI 在编码过程中的“自动补全”。但这仅仅是序幕。如今，一种更强大、更具颠覆性的模式正在兴起，它就是——Agentic Coding (智能体驱动编码)。

最近，Flask 和 Jinja2 等知名开源项目的作者 Armin Ronacher 分享了他近几个月沉浸式体验 Agentic Coding 的感受。他认为，这开启了人机协作编程的新篇章，带来了前所未有的生产力飞跃。

Agentic Coding 不再是简单的代码提示，而是开发者与 AI Agent 之间的实时协作 (real time collaboration)。它预示着软件开发的未来，一个我们都应该主动了解和拥抱的未来。

超越“自动补全”：Agentic Coding 是什么？

要理解 Agentic Coding 的变革性，首先要明白它与我们熟悉的“自动补全”工具的本质区别。如果说 Copilot 是你的“智能导航仪”，那么编码 Agent 就是你的“编程搭档”。它能够：

• 理解和分解复杂任务： 将一个宏大的目标（如“为这个项目添加用户认证功能”）分解为一系列可执行的子任务。
• 自主使用工具链： 像人类开发者一样，运行编译器 (go build)、测试框架 (go test)、linter、formatter 等。
• 与开发环境深度交互： 直接创建、修改、删除文件；与 Git 进行交互；浏览文件系统。
• 基于反馈进行迭代： 当编译失败或测试不通过时，Agent 会阅读错误信息，理解问题所在，并尝试进行修复，形成一个“试错-反馈-修正”的闭环。
• 长时间、持续地工作： 甚至可以运行数小时来完成大型任务。

Agentic Coding 的核心，是将 LLM 的推理能力与实际的开发工具链和环境深度结合，使其从一个“代码片段生成器”进化为一个能够自主执行复杂编程任务的“智能体”。

浪潮已至：Agentic Coding 为何在当下爆发？

Armin 认为，这场浪潮的兴起主要源于三个因素的共同作用：

1. 模型能力的突破： OpenAI o3 、Claude 4 Opus、Gemini 2.5 pro等最新一代模型，在“工具使用 (tool usage)”能力上取得了质的飞跃。
2. 官方 Agent 的引领： Anthropic 的 claude-code 等官方 Agent 实现，为社区提供了最佳实践的范本。
3. 更优的成本效益： 通过订阅服务使用 Agentic Coding，使得长时间、高强度的 Agent 运行在经济上变得可行。

如何高效拥抱 Agentic Coding：来自一线的实践指南

要驾驭好这位强大的“编程搭档”，并非易事。Armin 分享了大量宝贵的实践经验，总结起来，核心在于：构建一个“Agent 友好”的环境，并学会如何有效管理上下文。

语言和代码库的选择：“简单”是 Agent 的朋友

• 简单的语言更受欢迎

Armin 发现，像 Go、PHP、基础 Python 这样的语言，对 Agent 更友好。它们的语法结构清晰，概念相对较少，使得 AI 更容易理解和生成代码。Go 语言的简洁性、强大的标准库和较少的生态系统变动，使其成为 Agentic Coding 的理想选择之一。

• 生态系统稳定性很重要

生态系统变动越少的语言或框架，效果越好。

• 代码库内部模式要统一

如果一个代码库中存在多种相互冲突的设计模式，Agent 会感到困惑。

• 命名要清晰

长且独特的函数名能帮助 Agent 更好地理解和定位代码，避免不必要的代码重复。

优化你的开发环境：为 Agent “铺路”

• 构建“Agent友好”的工具

你的工具在被误用时，应该明确报错并提供有用的错误信息，而不是静默失败。Armin 举例说，Rust 的测试框架在未选中任何测试时会报告“成功运行0个测试”，这就是一个反例。

• 统一的、纯文本的日志系统

Agent 需要的是简单、清晰的文本日志来理解系统状态。将浏览器控制台日志、SQL 日志等统一输出到 Agent 可以访问的日志文件中，能极大地帮助它进行端到端的调试。

• 为 Agent 提供“草稿空间”

在项目中明确告知 Agent 在哪里可以安全地创建和运行一次性的测试或探索性代码。

上下文管理是关键：避免“信息过载”与“迷失方向”

• 审慎使用 MCP，拥抱命令行工具

作者发现，当前模型对命令行工具的理解和使用能力，远胜于对 MCP 的。Agent 可以轻松地将多个 CLI 工具组合进 Shell 脚本来完成复杂任务。

• 主动提供摘要，避免 Agent “闲逛”

为 Agent 提供关键 API 或代码模块的摘要，或者构建一个工具来生成摘要，能极大地节省上下文并提高效率。

• 避免在“混乱”的环境中启动 Agent

如果你的开发环境本身是坏的，Agent 会花费大量上下文去修复环境，而不是解决你真正想解决的问题。

• 使用子任务分解复杂问题

将大任务分解为清晰的子任务，是管理复杂性和上下文的有效手段。

拥抱前需理解的关键点：从挑战看发展方向

面对 Agentic Coding 的强大能力，一些开发者可能会有疑虑。我们不必将其视为障碍，而应看作是推动技术向更成熟阶段发展的方向。

• 关于代码质量： Agentic Coding 对开发者的审查能力和架构判断力提出了更高的要求。我们的角色将更多地从“代码生产者”转变为“代码质量的最终负责人和架构师”。我们始终对合并到 main 分支的代码负责。
• 关于“幻觉”问题： 通过工具链（编译、测试、lint）形成的闭环反馈，Agentic Coding 正在有效地缓解“幻觉”问题。这也指明了未来 Agent 开发平台需要重点投入的方向——构建更健壮的验证和反馈机制。
• 关于不擅长特定语言： Agentic Coding 的发展将推动语言和生态系统向更“Agent 友好”的方向演进。正如 Armin 所说，Go 语言因其恰到好处的类型安全、广泛的标准库和推崇惯用法的文化，在这方面已展现出天然优势。
• 关于安全风险（YOLO 模式）： 当前重度用户为了最大化 Agent 能力而给予其完全系统权限的“YOLO 模式”，是一种早期探索阶段的高风险行为。未来，成熟的 Agentic Coding 平台必然会提供更安全、更可靠的权限管理和沙箱环境，这是该领域走向普及的必经之路。

注：YOLO 是 “You Only Live Once” (你只活一次) 的缩写。这个词最初流行于社交网络，表达的是一种活在当下、大胆尝试、不畏惧风险的人生态度。在技术领域，特别是 Armin Ronacher 在谈论 Agentic Coding 时使用的语境下，“YOLO 模式”特指一种大胆甚至有些“鲁莽”的使用方式，即给予 AI Agent 极高的、几乎不受限制的系统访问权限。

Go 语言在 Agentic Coding 时代的独特机遇

在 Armin 的分享中，Go 语言被特别提及，并被认为是 Agentic Coding 的理想选择之一。这并非偶然，Go 的诸多特性使其在这场人机协作的新范式中占据了有利位置：

1. 简洁性与可预测性： Go 语言“简单为王”的设计哲学，使其语法结构清晰、概念少、没有复杂的隐式行为。这使得 AI Agent 能更容易地理解、分析和生成高质量的 Go 代码。
2. 强大的工具链与高效的反馈闭环： Go 的快速编译、内置测试、静态检查等工具，为 Agent 提供了极其高效的“试错-反馈-修正”闭环。Armin 提到的 Go Test Caching 功能，能让 Agent 更智能地只运行受影响的测试，这是一个绝佳的例子。
3. 并发与系统编程能力： Go 语言本身非常适合编写 Agent 所需的各种命令行工具、后端服务、以及处理并发任务的 CI/CD 流程。我们可以用 Go 来为 AI Agent 构建高效、可靠的“武器库”。
4. 清晰的错误处理： Go 显式的 error 返回值机制，相比于异常，为 Agent 提供了更清晰、更可预测的错误处理路径。

小结：拥抱 Agentic Coding，就是拥抱软件开发的未来

Agentic Coding 正在开启一个软件开发的新篇章。它标志着我们与 AI 的关系，从简单的“主仆”（人命令，AI补全），演进为更深度的“伙伴”（人规划，AI协作执行）。

这场变革要求我们主动进化。开发者需要将重心更多地从繁琐的代码实现，转移到复杂问题的分解、系统架构的设计、以及对 AI Agent 的精准引导和结果验证上。

对于我们 Gopher 而言，这是一个激动人心的机遇。Go 语言的设计哲学和工程特性，使其在这场变革中具有天然的优势。与其对新范式感到疑虑或观望，不如主动去学习、实践，探索如何驾驭这位强大的“编程搭档”，让它成为我们提升自身能力、加速项目交付、并最终能专注于更有创造性工作的强大助力。

技术的浪潮滚滚向前，拥抱 Agentic Coding，就是拥抱软件开发的未来。

资料链接：https://www.youtube.com/watch?v=nfOVgz_omlU

聊一聊，也帮个忙：

• 你认为 Agentic Coding 将在哪些方面最先深刻地改变我们的日常开发工作？
• Armin Ronacher 提出的这些实践技巧，哪一点你认为最重要，并计划在自己的工作中尝试？
• 你认为 Go 语言为了更好地成为 Agentic Coding 时代的首选语言之一，社区或官方还可以在哪些方面发力？

欢迎在评论区留下你的思考和经验。如果你觉得这篇文章为你描绘了软件开发的未来图景，也请转发给你身边的开发者朋友们，一起迎接 Agentic Coding 时代的到来！

想与我进行更深入的 Go 语言、AI 赋能开发与技术趋势交流吗？ 欢迎加入我的**“Go & AI 精进营”知识星球**。

[此处放置知识星球二维码]

我们星球见！

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

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

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

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

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

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

===============

Tony Bai 一个程序员的心路历程

• Google Go语言编码风格规范

  • Google Go语言编码风格规范：指南篇
  • Google Go语言编码风格规范：决定篇
  • Google Go语言编码风格规范：最佳实践篇

• Go语言第一课FAQ

• Go语言进阶课FAQ

• 关于我

• 文章列表

GCP大面积故障，Go语言是“元凶”还是“背锅侠”？

• 六月 16, 2025
• 0 条评论

本文永久链接 – https://tonybai.com/2025/06/16/go-avoid-critical-incident

大家好，我是Tony Bai。

科技圈的每一次“风吹草动”，尤其是大型云服务的故障，总能引发我们技术人无数的讨论与反思。最近，一则关于“Google Cloud Platform (GCP) Service Control 在 2025 年 6 月发生重大故障”的消息，及其事后分析报告中直指的“null pointer crash loop”，在技术社区掀起了不小的波澜。

故障报告中还提到了几个雪上加霜的因素：没有特性标志 (Feature Flags) 进行高风险部署、缺乏优雅的错误处理（二进制文件直接崩溃而非优雅降级）、以及没有回退机制导致系统过载。

考虑到 Go 语言在 Google 内部（如 Kubernetes, Cloud Run 等）以及整个云原生领域的广泛应用，一个自然而然的疑问浮出水面：Go语言是否是这次 GCP 故障的“元凶”？或者说，Go 的某些特性，是否在某种程度上“助长”了这类问题的发生？反过来，Go 的设计又是否本可以帮助避免这样的灾难？

这这篇文章中，我们就结合社区的智慧，从Go语言特性和更广泛的软件工程实践角度，来剖析一下这类故障背后的深层原因。这不仅是对一个故障的假想复盘，更是对我们日常开发实践的一次警醒。

Go 语言特性：是“防火墙”还是“导火索”？

社区论坛上的讨论，首先就聚焦在了 Go 语言本身的一些特性上。

显式错误返回 (if err != nil)：万无一失还是“防君子不防小人”？

有开发者认为，Go 标志性的显式错误返回设计（即函数返回 (value, error)，调用者必须检查 err），本应是避免错误的有力武器。但也有观点指出，这种模式的“简洁性”（或者说，可以通过 _ 忽略错误的便利性）有时反而可能在项目压力大、追求快速上线时，被开发者有意或无意地跳过，导致潜在的错误处理缺失。比如常见的 value, _ := someFunction() 写法。

Go的显式错误返回，确实为构建健壮软件提供了坚实的基础。它将错误视为一等公民，迫使开发者直面错误处理。但语言提供的机制，终究不能替代开发者的责任心和良好的编码习惯。正如有些开发者提到的，golangci-lint 这样的静态检查工具可以有效地发现未检查的错误，但这需要团队将其融入开发流程并严格执行。**语言设计提供了“防火墙”，但工程师的素养和流程的完备性，才是决定防火墙是否真正起作用的关键。

Nil Pointer Panic：Go 也难逃的“魔爪”？

针对报告中提到的“null pointer crash loop”，许多评论者指出，nil 指针 panic 在 Go 中也并非罕见。Go 语言本身允许指针存在，也允许指针为 nil，并且不像 Rust 的 Option/Result 类型或 C# 的可空引用类型那样，在语言层面强制开发者处理潜在的 nil 情况。

的确，Go 语言的设计哲学是简洁，它相信开发者有能力正确处理指针。避免 nil panic 的核心在于良好的编码实践：防御性编程（在使用指针前进行检查）、最小化指针使用（Go 鼓励值传递，许多场景可以完全避免指针）、以及充分的测试（特别是边界条件和异常路径）。虽然 Go 没有语言层面的强制 nil 检查，但其简洁性也使得这类检查的成本相对较低。

panic/recover 机制：救命稻草还是饮鸩止渴？

有开发者分享经验，倾向于用 panic/recover 包裹所有核心逻辑，试图捕获所有潜在的运行时崩溃。但针对像故障中提到的 Service Control 这样的有状态、高关键性的系统，这种做法也引发了质疑：recover 后的程序状态是否真的可靠？强行“续命”一个可能已处于不一致状态的进程，是否比让它快速失败并由外部监控系统（如 Kubernetes）重启更安全？关于这个问题，我曾在《“这代码迟早出事！”——复盘线上问题：六个让你头痛的Go编码坏味道》一文中也讨论过。

panic/recover 在 Go 中有其特定的适用场景，例如在库的边界将内部的 panic 转换为 error 返回给调用者，或者处理真正意外且难以通过常规错误处理覆盖的严重问题。但对于关键业务服务，尤其是有状态的服务，“fail fast” 依然是目前社区认为的更可取的设计。让服务在遇到严重内部错误时快速、干净地退出，依赖外部的健康检查和自动重启机制来恢复服务，往往比试图在不确定的状态下继续运行更稳妥。

这样来看，Go 语言的设计，如显式错误处理，确实为构建可靠系统提供了工具。但它并不提供“银弹”，也不能完全消除诸如 nil 指针解引用这类逻辑错误的可能性。语言特性是基础，但绝非全部。

超越语言：流程、测试与工程文化的“灵魂拷问”

在针对该故障的讨论中，一个压倒性的共识是：这类大型系统故障，往往更多是软件工程流程、测试策略和工程文化上的问题，而非单一语言设计所能左右。

“100% 测试覆盖率”的迷思与测试策略的缺位

有开发者提出“你可以覆盖 100% 的代码行，但你永远无法覆盖 100% 的输入和状态组合。” 这句话一针见血。过度迷信行覆盖率，而忽略了测试的深度和广度，是许多团队的通病。

那么真正有效的测试策略应该是什么呢？显然单一的测试策略是无法保证程序上线后的质量的。下面是几种常见的测试策略：

• 单元测试 (Unit Testing): 验证开发者对代码单元在预期输入下的行为。
• 模糊测试 (Fuzz Testing): 通过自动生成大量随机或变异输入，探索代码的边缘情况和未知缺陷。Go 1.18 已将 Fuzz Testing 内置到标准工具链中，这是一个强大的武器。
• 集成测试 (Integration Testing): 验证模块间的交互。
• 端到端测试 (End-to-End Testing): 模拟真实用户场景。
• 生产测试/灰度发布 (Staged Rollouts / Canary Releases): 在真实生产环境中，小范围、逐步地验证变更的可靠性，这是大型系统发布的“金丝雀”。

这些策略显而易见，但又有多少团队能真正全面的做到呢？

特性标志 (Feature Flags)：高风险变更的“安全阀”

故障报告中提到了“没有特性标志进行风险部署”，这几乎是大型系统发布的“大忌”。特性标志允许团队在不重新部署代码的情况下，动态地开启或关闭某项功能，从而：

• 安全地进行 A/B 测试。
• 逐步向用户灰度上线新功能，控制风险。
• 在出现问题时，能够快速关闭故障功能，实现秒级“回滚”（功能层面）。

缺乏特性标志，意味着任何高风险的变更都像是在“裸奔”。

优雅降级与回滚预案：Plan B 的重要性

系统出错在所难免，关键在于出错后如何表现。故障报告中“二进制崩溃而非优雅降级”以及“没有随机回退导致过载”，都指向了系统鲁棒性的缺失。

• 优雅降级: 当核心服务出现问题时，非关键功能是否可以降级服务，保证核心可用性？例如，推荐系统不可用时，是否可以展示默认热门内容，而不是整个页面崩溃？
• 回滚计划: 任何部署都应该有明确、经过演练的回滚计划。出现问题时，能否快速、安全地回退到上一个稳定版本？

代码审查、自动化工具与工程文化

• 严格的代码审查: 是发现逻辑错误、不规范写法（如忽略错误、滥用指针）的重要手段。
• 静态分析与 Linter：golangci-lint 等工具可以自动化地检查出大量潜在问题，包括未处理的错误、不安全的并发操作等。但正如有些开发者在评论中所言，“linters can be disabled”，关键还是在于流程的执行。
• 警惕“Vibe Coding”：有开发者犀利地指出“Garbage in, garbage out”。如果团队强依赖AI的“氛围”编码，而缺乏对生成代码的审查，那么无论用什么语言，都可能埋下隐患。
• 重视流程而非迷信工具：许多评论都强调，即使有再好的语言特性或工具，如果缺乏健全的开发、测试、部署流程，以及对质量负责的工程文化，故障依然难以避免。

AI 辅助编程：是“帮手”还是新的“风险源”？

一个有趣的衍生讨论是关于 AI 辅助编程（如 GitHub Copilot、Google Gemini Code Assist）在其中的角色。

有开发者提到，Google 内部已有大量代码由 Gemini 生成。也有人分享使用 AI 辅助编程的体验，认为其在作为“结对编程伙伴”或“辅助搜索”时有价值，但完全自动生成的代码质量参差不齐，有时甚至会引入“幻觉”和新的 bug。

AI 辅助编程无疑是未来的趋势，它有可能提高开发效率，辅助开发者处理重复性工作。但目前来看，AI 生成的代码更需要、而不是更不需要人类的严格审查和充分测试。将 AI 视为一个能提供建议、加速编码的助手是合适的，但如果过度依赖，甚至将其生成的代码不经审视直接合入生产，那无异于引入了新的、更不可控的风险源。特别是在错误处理、并发安全、边界条件这些需要深度思考的领域，AI至少目前还难以完全替代经验丰富的工程师，尤其是一些mission critical的系统中。不要被那些用AI生成一个简单工具站的“AI战果”所迷惑。

小节：语言是利器，工程实践才是灵魂

回到最初的问题：GCP Service Control 的这次故障，Go 语言是“元凶”还是“背锅侠”？

从 社区的讨论和我们的分析来看，将板子完全打在 Go 语言身上，显然是有失公允的。Go 语言的设计，如其显式错误处理、简洁性带来的高可读性、以及强大的并发能力，都为构建健壮、高效的系统提供了良好的基础。

然而，语言终究只是工具，它不能替代健全的软件工程流程和严谨的工程文化。 此次 GCP 故障所暴露出的问题——无论是可能的 nil 指针解引用，还是更宏观的缺乏特性标志、部署策略失当、错误处理不优雅——更多地指向了在测试、部署、风险控制、质量保障等一系列工程实践环节可能存在的缺失。

对于我们 Go 开发者而言，这次事件给我们带来的启示应该是：

• 充分利用 Go 的优势： 写出符合 Go 惯例的、清晰的错误处理逻辑；审慎使用指针，做好 nil 检查；发挥 Go 并发模型的威力。
• 拥抱并严格执行工程最佳实践： 将单元测试、集成测试、模糊测试落到实处；在重要变更上线时，务必使用特性标志和灰度发布策略；建立严格的代码审查机制；利用好静态分析工具。
• 对 AI 保持理性： 善用 AI 辅助工具提高效率，但绝不能放松对代码质量的把控和人工审查的力度。

最终，构建一个真正高可用、高可靠的大型系统，依赖的绝不仅仅是选择一门“好”的语言，更在于整个团队对卓越工程实践的持续追求和严格执行。

你对这次讨论有什么看法？或者在你的 Go 项目中，是如何保障系统稳定性的？欢迎在评论区留下你的宝贵经验！

精进有道，更上层楼

极客时间《Go语言进阶课》上架刚好一个月，受到了各位读者的热烈欢迎和反馈。在这里感谢大家的支持。目前我们已经完成了课程模块一『语法强化篇』的 13 讲，为你系统突破 Go 语言的语法认知瓶颈，打下坚实基础。

现在，我们即将进入模块二『设计先行篇』，这不仅包括 API 设计，更涵盖了项目布局、包设计、并发设计、接口设计、错误处理设计等构建高质>量 Go 代码的关键要素。

这门进阶课程，是我多年 Go 实战经验和深度思考的结晶，旨在帮助你突破瓶颈，从“会用 Go”迈向“精通 Go”，真正驾驭 Go 语言，编写出更优雅、

更高效、更可靠的生产级代码！

扫描下方二维码，立即开启你的 Go 语言进阶之旅！

感谢阅读！

如果这篇文章让你对Go语言有了新的认识，请帮忙转发，让更多朋友一起学习和进步！

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

===============

Tony Bai 一个程序员的心路历程

• Google Go语言编码风格规范

  • Google Go语言编码风格规范：指南篇
  • Google Go语言编码风格规范：决定篇
  • Google Go语言编码风格规范：最佳实践篇

• Go语言第一课FAQ

• Go语言进阶课FAQ

• 关于我

• 文章列表

AI 编码工具“真香”还是“智商税”？一位资深码农的“挑衅”与Go开发者的反思

• 六月 3, 2025
• 0 条评论

本文永久链接 – https://tonybai.com/2025/06/03/provocation-about-ai-assisted-programming

大家好，我是Tony Bai。

最近，fly.io 博客上该公司开发者 Thomas Ptacek 的一篇题为《My AI Skeptic Friends Are All Nuts》的文章，在开发者社区掀起了不小的波澜，一度登顶HN。Ptacek 以一位自称“严肃开发者”（从C语言到Go、Rust均有涉猎）的口吻，向那些对 AI 辅助编程持怀疑态度的“聪明朋友们”发出了略带“挑衅”的宣言：“即使 LLM 今天停止所有进展，它仍然是我职业生涯中发生的第二重要的事情” 。

这篇文章的观点之鲜明、论证之犀利，让我印象深刻。恰逢 前期Google I/O 2025 大会再次展示了 Gemini 等 AI 模型在编码领域的惊人进展，我们不禁要问：AI 编码工具，究竟是能极大提升生产力的“真香”利器，还是又一轮被过度炒作的“智商税”？作为开发者，特别是 Gopher，我们又该如何看待和应对这场正在发生的变革？

在这篇文章中，我就和大家一起来看看 Thomas Ptacek 对AI辅助编程演进的犀利观点以及他的反思。看看你是否认同他的想法。

误区澄清：现代 AI 辅助编程早已不是“复制粘贴”

Ptacek 在文章开篇就点出了一个关键问题：很多人对 AI 辅助编程的印象，还停留在半年前甚至两年前的水平。他写道：“如果你在6个月前（或者，天哪，两年前用Copilot的时候）尝试使用LLM编码并失败了，那么你并没有在做大多数严肃的LLM辅助编码者正在做的事情”。

那么，现在“严肃的LLM辅助编码者”在做什么呢？Ptacek 强调，他们使用的是 Agent (智能体)。这些 AI Agent 不再仅仅是根据提示生成代码片段让你复制粘贴，它们能够：

• 自主地在你的代码库中进行探索。
• 直接创建和修改文件。
• 运行各种工具， 如编译器、测试框架、linter、formatter 等。
• 与 Git 等版本控制系统交互。
• 根据编译和测试结果进行迭代和修正。
• 通过 MCP 或类似机制调用你设置的任意工具。

Ptacek强调：如果你对 AI 编码的印象还停留在 ChatGPT 网页上简单问答然后手动复制代码，那么你可能真的低估了当前 AI Agent 所能达到的自动化和智能化水平。

AI Agent 如何提升编码效率？Ptacek 的“积极案例”

Ptacek 认为，LLM（通过 Agent）能够极大地提升编码效率，主要体现在以下几个方面：

1. 处理“乏味代码”： LLM 可以编写你需要编写的大部分乏味代码。而大多数项目中的大多数代码都是乏味的。这能让开发者从重复性的工作中解放出来，更快地进入“调整代码并立即看到效果更好”的“黄金时刻 (golden moment)”，获得即时反馈的“多巴胺冲击”。

2. 克服项目启动的“惯性”： 面对一个新项目，繁琐的初始设置、依赖管理、基础架构搭建等往往令人望而却步。LLM Agent 可以被指示去“搞定这些破事，直接将你带到“事情几乎可以工作”的阶段。

3. 自动化“苦差事”： 那些你不想做但又必须做的“脏活累活”，比如大规模的单元测试重构，完全可以交给 AI Agent 在虚拟机里折腾几个小时，然后带着一个 PR 回来。这反而会“逼迫”你去做“真正的工作 (real work)”。

回应常见的质疑：Ptacek 的“辩护”

Ptacek 在文章中也针对开发者对 AI 编码的常见质疑进行了犀利的回击，这些回应也为我们思考 Go 语言在 AI 时代的定位提供了新的视角。

• 关于代码质量与审查责任——“你根本不知道它写的是什么！”

Ptacek强调，开发者始终对合并到 main 分支的代码负责，无论是否使用 LLM。 LLM 生成的代码是“可知的”，你需要阅读它，甚至花时间将其调整为你自己的风格。如果连 LLM 生成的“乏味、重复”的代码都难以理解和消化，那可能是开发人员的“技能问题”。

• 关于“幻觉 (hallucination)”问题——“它会编造不存在的API！”

Ptacek 认为，对于编程而言，Agent 通过工具链（linting、编译、运行测试）形成的闭环反馈，已经（或多或少地）解决了“幻觉”问题。“如果它们的LLM编造了一个新的函数签名，Agent会看到错误。它们将其反馈给LLM，LLM会说‘哦，是的，我完全是编造的’，然后重试”。这里不能不提到** Go 语言的快速编译特性，使得这种“试错-反馈-修正”的闭环能够非常高效地运转。同时，Go 强大的标准库和清晰的 API 设计，是否也能减少 LLM“编造”API 的概率，或者使其更容易被工具链检测出来。

• 关于“代码像初级开发者写的”——“质量太差！”

Ptacek 回应：“一个实习生一个月要花20美元吗？因为 Cursor.ai 就是这个价钱”。他认为，高级开发者的职责之一就是让能力稍逊的编码者（无论是人类还是“智能体”）变得高效。使用好 Agent 本身就是一项技能和一项涉及提示、索引和（尤其是）工具链的工程项目。 LLM 只有在你允许的情况下才会产生劣质代码。

• 关于“不擅长特定语言 (如 Rust)”——“它写不了我的 Rust！”

Ptacek 认为这更多是语言生态和工具链成熟度的问题，而非 LLM 能力的根本缺陷。他特别指出：“我主要用 Go 工作……Go 恰到好处的类型安全、广泛的标准库以及推崇（通常是重复性）惯用法的文化。LLM 在生成 Go 代码方面表现出色。” 想必很多Go开发者也有着与Ptacek相同的感受，这是 Go 语言在 AI 辅助编程时代的一个显著优势！ Go 的简洁性、明确性、强大的标准库覆盖、以及社区对代码规范和惯用法的重视（例如 Effective Go），使得 Go 代码的模式相对统一和可预测，这为 LLM 的学习和生成提供了极大的便利。

对“手工艺精神”与“平庸代码”的再思考

Ptacek 对软件开发中的“手工艺精神”和对“平庸代码”的过度排斥也提出了批判。

• 他认为：专业软件开发者的工作是用代码为人们解决实际问题。在日常工作中，我们不是工匠。过度追求代码的“优雅”而忽视实际产出，可能是“自我安慰的yak-shaving（指做无关紧要的琐事）”。

• 对于“平庸代码”，他认为：开发者都喜欢对代码自吹自擂。他们担心LLM降低了质量的“天花板”。也许吧。但它们也提高了“地板”。LLM 生成的“平庸但彻底”的代码，可能比人类开发者“抖机灵”但引入缺陷的代码更有价值。

这也引发我们思考：在追求卓越工程的同时，我们是否也应该更务实地看待不同场景下对代码质量的不同要求？LLM 是否能帮助我们更高效地处理那些“允许平庸”但又耗时耗力的部分，从而让我们能将精力投入到真正需要人类智慧和创造力的核心工作中？

Go 开发者如何拥抱 AI Agent 的时代？

Ptacek 的文章，无论你是否完全认同其所有观点，都为我们描绘了一个 AI Agent 深度参与软件开发的未来图景。作为 Gopher，我们应该如何应对？

1. 更新认知，拥抱变化： 首先要认识到，现代 AI 辅助编程已经远超简单的代码补全。应该主动去了解和体验基于 Agent 的编码工具。
2. 学习与 AI Agent 高效协作： 掌握提示工程技巧，学会如何清晰地向 Agent表达需求、提供上下文、引导其生成和修改代码。
3. 发挥 Go 语言的优势： 利用 Go 的简洁性、强大的标准库、快速的编译和测试工具链，为 AI Agent 构建高效的开发和反馈环境。思考如何让 Go 代码对 AI 更“友好”。
4. 提升自身的核心价值： 将精力更多地投入到 AI 难以替代的领域：复杂系统设计、架构决策、需求理解与抽象、创新思维、以及对 Go 底层原理和并发模型的深刻理解。
5. 参与构建 Go 的 AI Agent 生态： Go 语言本身非常适合构建 CLI 工具和后端服务。我们是否可以利用 Go 来创建更强大的、针对 Go 开发的 Agent 辅助工具或平台？

小结：保持开放，主动实践，与 AI 共舞

AI 编码工具究竟是“真香”还是“智商税”？或许答案因人而异，也因我们如何使用它而异。但 Thomas Ptacek 的“挑衅”至少提醒我们，不能用静止的眼光看待飞速发展的技术。

AI 辅助编程的浪潮已然到来。对于我们 Gopher 而言，Go 语言的特性使其在这波浪潮中具有独特的优势。与其固守过去的经验和偏见，不如保持开放的心态，主动去实践和探索，让 AI Agent 成为我们提升自身能力、加速项目交付、并最终能专注于更有创造性工作的强大伙伴。

毕竟，正如 Ptacek 所说，当他那些“聪明的怀疑论朋友们”最终接受并开始使用这些工具时，他们将会让编码 Agent 比今天强大得多。

而我们，又怎能置身事外呢？

聊一聊，也帮个忙：

• 你目前在工作中使用 AI 辅助编程工具（如 Copilot, Cursor.ai, Gemini Code Assist，Trae等）的体验如何？它在哪些方面帮助了你，又有哪些不足？
• Ptacek 文章中对 AI 编码的哪个观点让你印象最深刻？你同意还是反对？为什么？
• 你认为 Go 语言在 AI 辅助编程时代，还有哪些可以进一步优化的方向，以更好地与 LLM Agent 结合？

欢迎在评论区留下你的思考和经验。如果你觉得这篇文章提供了一个值得探讨的视角，也请转发给你身边的开发者朋友们，一起参与这场关于 AI 与编程未来的讨论！

想与我进行更深入的 Go 语言、AI 赋能开发与技术趋势交流吗？ 欢迎加入我的**“Go & AI 精进营”知识星球**。

我们星球见！

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

===============

Tony Bai 一个程序员的心路历程

• Google Go语言编码风格规范

  • Google Go语言编码风格规范：指南篇
  • Google Go语言编码风格规范：决定篇
  • Google Go语言编码风格规范：最佳实践篇

• Go语言第一课FAQ

• Go语言进阶课FAQ

• 关于我

• 文章列表

Google I/O 2025 Go 语言进展：生产力、生产就绪与 AI 赋能

• 五月 25, 2025
• 0 条评论

本文永久链接 – https://tonybai.com/2025/05/25/go-at-googleio-2025

大家好，我是Tony Bai。

在Google I/O 2025大会上，Go 产品负责人 Cameron Balahan 和开发者关系负责人 Marc Dougherty 详细阐述了 Go 语言在生产力、生产就绪度和开发者体验方面的最新进展及未来规划。演讲强调了 Go 语言以规模化为核心的设计理念及其三大指导原则：生产力、超越语言的完整体验和生产就绪。重点介绍了Go 1.23和Go 1.24版本在生产力方面的革新，包括引入迭代器简化循环、gopls 的智能现代化能力以及通过 go get 管理 Go 工具链；在生产就绪性方面，突出了 WebAssembly 支持的增强、安全体系的持续深化（特别是后量子密码学的透明集成和 FIPS-140 支持的便捷启用）以及核心性能的显著提升（如全新的 map 实现）。此外，演讲还强调了 Go 语言在 AI 基础设施构建中的核心地位，并展望了 Go 1.25+ 在 SIMD 支持、多核硬件优化等方向的探索，同时重申了 Go 1.0 的兼容性承诺。

这里是基于演讲视频，借助AI整理的文字稿，我做了简单校对和格式调整，供大家参考。

原视频链接：https://www.youtube.com/watch?v=kj80m-umOxs 建议大家也都看一下。

我是 Cameron，我是 Google Go 编程语言的产品负责人。我是 Marc，我负责 Go 的开发者关系。

对于那些刚接触我们项目的人来说，Go 是一个由 Google 支持的开源编程语言，它能让开发者和软件工程团队快速构建更安全、可靠和可扩展的生产系统。

Google 在 15 年前将 Go 作为一个开源项目发布，在此之前两年，Google 为了应对自身在构建和维护大规模、关键任务系统方面面临的挑战而启动了这个项目。使用现有的工具，我们不得不在动态解释性语言的生产力和强类型编译语言的生产就绪性之间做出选择。但我们两者都想要，所以我们构建了Go。

Go 的核心前提是开发工具从一开始就应该优先考虑可扩展性，这意味着要考虑到现代软件的架构方式、现代工作负载运行的环境，以及最重要的，编写、操作和维护这一切的团队。因此，考虑到这一点，我们围绕三个原则构建了Go，这些原则至今仍在指导着我们。

首先，Go 是高效的。它易于学习，易于维护，可读性强，并且能够很好地适应不同的团队、工作负载和用例。

其次，Go 不仅仅是一门语言，它是一个完整的开发者体验。从 IDE 到生产环境，我们提供端到端的解决方案，涵盖整个软件开发生命周期的所有接触点。我们提供所有这一切，开箱即用，并带有合理的、可自动调整的默认设置。

第三，Go 是生产就绪的。它可靠、高效、稳定且安全，这使得它非常适合从简单应用到企业系统和关键基础设施的各种场景。

多年来，Go 已经成为现代云计算的核心，并由此延伸到现代网络。世界上许多最知名的云技术都是用 Go 编写的，包括 Kubernetes、Docker、Terraform 等等。各种规模的公司，从个人到初创企业再到大型企业，都已采用 Go，尤其是在其基于云的工作负载方面。这在很大程度上是因为 Go 是为云计算而专门构建的。Go 所支持的库、集成和架构是为云而生的，而不是后来才为云进行改造的。这意味着你可以比使用其他语言更快、更容易地实现云计算的优势。

但你不必相信我的话。Go 用户一直给予我们非凡的反馈和客户满意度(注：93%)——这种水平在行业内几乎闻所未闻。使用情况也证明了这一点。如今，Go 比以往任何时候都更受欢迎，拥有数百万开发者，并且仍在快速增长。事实上，根据去年的NewStack的一项调查，Go 是仅有的两种增长速度超过开发者本身增长速度的语言之一。另一种是 Rust，我们认为它与 Go 配合得非常好，但这是另一个话题了。这样的迹象随处可见。Go 一直在 Stack Overflow 上被评为最受欢迎的技术之一。去年，Cloudflare 报告称，Go 是互联网上支持 API 调用的第一大语言。

因此，无论你是个人开发者、企业，还是介于两者之间的组织，Go 都能让你快速、更可靠地构建和扩展你的项目。你可能会很高兴你这样做了。接下来，Marc 将深入探讨 Go 的所有最新进展。交给你了，Marc。

谢谢，Cameron。Go 每年发布两次新的主版本，分别在八月和二月。在过去的一年里，我们在 1.23 和 1.24 版本中发布了许多令人兴奋的新功能，以帮助你和你的团队提高工作效率。

在1.23 版本中，我们引入了带有 seq 和 seq2 类型的迭代器。相较于经典的 Go 风格，迭代器不仅仅是标准库中的一个新类型。它们是一种优雅的方式，可以使用已经熟悉的 for range 表达式来简化循环，并将迭代的机制与循环体分开。在迭代器出现之前，有几种不同的方法来遍历数据。一些方法会返回一个包含所有结果的切片，这对于大型集合来说可能效率低下。另一种方法是创建自己的迭代器对象，就像这段代码一样，它使用了 Google Cloud Storage 库。注意这里的复杂性。我们的循环中有流程控制和错误检查。并且该错误检查需要在每个循环中重复。使用迭代器，你可以使用熟悉的 for range 语法来执行循环。复杂的流程控制则保留在迭代器内部。这使得我们的循环体可以专注于处理文件或错误，而无需担心流程控制。

从 1.24 版本开始，标准库在 strings、slices 和 maps 包中包含了一系列迭代器。因为迭代器只是一个函数，所以你可以定义自己的迭代器，包括为其他地方定义的集合类型定义迭代器。这是我为 Cloud Storage 示例定义的迭代器。声明看起来有点复杂，但你可以看到这里的流程控制与之前具有相同的效果。这个迭代器让我们能够将流程控制处理从循环中分离出来，并使它们更具可读性。

随着像迭代器这样的新概念的引入，Go 的垂直集成工具可帮助你的代码库与最新的模式和习惯用法保持同步。Go 的语言服务器 gopls 可以与你的 IDE 集成，既可以通过大多数 IDE 中的语言服务器支持，也可以通过插件（如 VS Code Go 扩展）实现。Gopls 在常规的语言服务器功能方面提供帮助，例如类型检查、函数签名和引用。但 gopls 的功能远不止于此。还记得那个复杂的迭代器定义吗？由于 gopls 从第一天起就知道新功能，因此它可以帮助你在编写时避免错误。在这里，它注意到了一个错误，即我们的迭代器可能会在应该停止后调用我们的 yield 函数。gopls 包含一套现代化功能，这些常见模式后来已作为语言特性或标准库新增功能得到解决。虽然你可以在整个代码库上运行现代化工具，但 gopls 可以在你编辑的任何地方内联建议它们。这里有一些旧模式的例子在左边，以及它们现代化的替代方案在右边。

最后一个现代化工具展示了 JSON 解析器的一个新特性，称为omitzero。JSON 包从 Go 1.0 开始就是 Go 的一部分。它通过简化 Go 结构体的序列化，实现了 API 客户端和服务器的人性化开发。omitzero 选项的添加解决了一些在处理 Go 的零值（如空结构体和未初始化的 time.Time 对象）时常见的错误和令人意外的行为。这些新增功能让你能够更好地控制对象如何序列化为 JSON，并避免可能的错误和混淆来源。

你是否需要更新你的 Go 运行时以利用新功能？从 1.23 版本开始，你可以使用 go get 来管理 Go 工具链，就像管理任何其他依赖项一样。Go 会根据需要下载更新的工具链，让你的团队可以使用最新的功能，而无需停下来手动更新工具链。这也适用于依赖项。如果你依赖了需要 1.24 版本的代码，Go 会更新你模块的 go 指令以要求 1.24 版本，并自动获取 1.24 运行时。Go 语言和 Go 工具不断寻找新的方法来帮助你保持代码库的可读性和现代化，并让你的团队保持专注和高效。

Marc 刚刚向你介绍了让你更高效的一些新功能。但请记住，Go 关注的是生产力和生产就绪性。那么，让我们来谈谈 Go 1.23 和 1.24 中那些让你的应用程序更健壮、更安全、性能更高的最新功能。

正如我之前所说，Go 的创始原则部分集中在其可移植性和对现代工作负载运行的现代环境的关注上。这些环境在不断发展。随着它们的发展，我们希望确保 Go 能够跟上步伐。我们做到这一点的一种方式是在 Go 1.24 中显著改进了 Go 对 WebAssembly 的支持。WebAssembly，或称 Wasm，是一种二进制指令格式和沙盒化运行时环境，它开启了许多新的有趣用例，尤其是在云端。包括 Go 在内的几种语言都能够编译 Wasm 模块，这些模块包含可在所有 Wasm 主机上运行的可移植的、与体系结构无关的字节码。同一个 Wasm 主机应用程序可以调用来自多个不同 Wasm 模块的方法，这些模块可以根据需要用一种语言或多种语言混合编写。这些 Wasm 模块是可热加载的，并在内存安全的沙盒化运行时中运行，具有结构化的控制流和验证。任何系统调用都通过 Wasm 运行时进行路由，这提供了一个额外的安全层，有点像一个极其轻量级的容器。尽管存在这一层抽象，但 Wasm 应用程序效率极高，能够在主机上实现接近本机的性能。这使得它们特别适用于高性能、低延迟的用例，例如边缘计算。例如，你可以在 Google Cloud 服务扩展上运行你的 Wasm 代码，它在 200 多个国家的 200 多个边缘位置提供边缘计算。

Go 在 Go 1.11 版本中通过 JS Wasm 移植首次引入了对 Wasm 的支持。Wasm 本身最初是为浏览器设计的。JS Wasm 移植通过允许你通过 JavaScript 主机定位网页，从而启用了此用例。Go 开发者利用这个功能制作了一些非常有趣的东西，尤其是游戏。甚至还有一些利用 JS Wasm 移植的 Go 开源游戏引擎。Go 开发者可以使用这些项目轻松开发在浏览器中运行的令人印象深刻的 2D 游戏。随着 Wasm 的发展，Go 也在发展。在 Go 1.21 中，我们引入了对 WebAssembly 系统接口（WASI）预览版 1 的支持。WASI 提供了一个 POSIX 风格的接口，用于与系统资源进行交互，例如文件系统、系统时钟、数据实用程序等等。在这个例子中，你可以看到一个简单的“Hello, world!”程序，我们通过开头的编译标志将其编译为 Wasm。然后我们可以使用众多免费开源的 Wasm 运行时和库之一来运行该程序。在这种情况下，我们使用的是 wazero，一个用 Go 实现的开源项目。从 Go 1.21 开始，Go 开发者可以将 Wasm 模块构建为可执行文件，在 Wasm 运行时中启动它，并运行至完成。

这就引出了今天的内容。在 Go 1.24 中，我们通过两种主要方式扩展了 Go 的 Wasm 功能。首先，Go 1.24 允许你使用 go:wasmexport 编译器指令将 Go 函数导出到 Wasm 主机。当我们将这样的代码编译成 Wasm 模块时，我们可以在 Wasm 主机中导入它，Wasm 主机可以直接调用模块导出的函数。其次，Go 1.24 添加了对构建 WASI 反应器 (reactor) 的支持。当你使用此功能以 Reactor 模式构建 Wasm 模块时，即使模块执行完毕，它也可以保持初始化状态。这对于你希望无限期可用的长时间运行的插件或扩展非常有用。初始化一次，让它保持运行，它可以继续响应调用，包括通过维护状态。在这个例子中，我们使用 wazero 的库来创建一个 Wasm 主机，它将调用我们在上一个例子中导出的 add 函数。不过，这次我们将使用高亮显示的构建标志以反应器模式构建 Wasm 模块。现在，我们可以多次运行 add 函数而无需重新初始化它。

接下来，我们来谈谈 Go 如何让你的应用程序更安全。Go 一直在安全特性和功能方面处于领先地位。在 Go 1.13 中，我们引入了模块代理和校验和数据库，它们缓存并记录 Go 生态系统中所有依赖项的哈希值，保护你免受中间人攻击和其他对依赖项的篡改。然后，在 Go 1.18 中，我们引入了内置的模糊测试 (fuzz testing)，这是第一个将原生模糊测试内置并集成到其标准工具链中的主流编程语言。你可以将模糊测试视为一种自动化测试形式，它智能地操纵程序的输入以找出错误，尤其是安全漏洞。2022 年，我们推出了 Go 的端到端漏洞管理系统，它可以在任何地方（从 IDE 到运行时）发现依赖项中的已知漏洞。通过分析从你的代码到依赖项的调用图，Go 的漏洞管理工具能够检测你是否实际调用了易受攻击的代码，从而消除了绝大多数的误报。

基于我们对安全的关注，在 Go 1.24 中，我们引入了对后量子密码学的支持，所有这些都在幕后透明地实现。我们还改进了对 FIPS-140 的支持，这是一项美国政府合规制度，其中包括用于加密应用的已批准算法。你可以在不更改任何代码的情况下启用 FIPS 模式，既可以在运行时使用高亮显示的调试标志，也可以在构建时使用高亮显示的构建 flag。

最后，我们继续专注于使 Go 更快、更高效。我们做到这一点的一个重要方式是引入了一个全新的内置 map 类型实现，它基于一种名为 Swiss Tables 的新哈希表设计。从 Go 1.24 开始，map 透明地使用新的 Swiss Table 实现。在微基准测试中，使用新实现的 map 操作比 Go 1.23 快了高达 60%，尤其是在处理大型 map 时。这一切都无缝集成在 Go 的内置 map 中。无需调整你的代码。只需升级即可。

还有更多，包括 Go 1.23 和 1.24 中许多新的底层工具，用于提高效率。例如，在 Go 1.23 中，我们引入了 Unique Package，可以高效地对值进行去重和比较。在 Go 1.24 中，我们引入了 weak.Pointers，它允许你安全地指向一个对象而不会阻止它被垃圾回收，以及 AddCleanup 函数，这是一种更灵活、更高效且更不容易出错的终结机制。还有更多，包括改进的内存分配速度和整体速度提升。所有这些都延续了我们保持 Go 既高效又生产就绪的重点。

接下来，让我们把话筒转回给 Marc，让他快速介绍一下 Go 在生成式 AI 中的最新应用。

正如你刚才听到的，Go 拥有许多特性，使其成为构建生产系统的绝佳语言。像高效的网络库和集成的结构体标签这样的特性，使其非常适合构建分布式系统。这也是 Go 在云基础设施和服务中如此普遍的重要原因。同样的这些原因也使得 Go 成为当今构建 AI 基础设施和服务的绝佳选择。流行的生成式 AI 工具和库，如 Ollama、Local AI、LangChain Go、Genkit 等等，都是用 Go 编写的。就像之前的主要基础设施项目一样，这些工具和库利用 Go 的生产力和生产就绪性来创建高度可扩展且更可靠的关键任务服务，数百万来自不同语言生态系统的开发者依赖这些服务来支持其 AI 驱动的工作负载。

事实上，云和 AI 系统之间的共同点比你想象的要多。由于 LLM 通常需要专用的、专门的计算资源，因此它们通常作为通过 API 调用的网络服务运行。让我们以 Go 博客最近一篇文章中概述的检索增强生成 (RAG) 系统为例。我们的 RAG 系统使用向量数据库来存储相关文档，以便在回答用户问题时提供给我们的 LLM。向量数据库依赖于专门的嵌入模型，因此我们可以高效地查询与用户问题相似的文档。我们将研究三种不同的框架，用于将这些服务连接在一起。

对于我们的第一个例子，我们将直接使用 Gemini 和 Weaviate 客户端库。这段代码来自用户查询处理程序。我们正在使用 Weaviate 的 GraphQL 接口来获取文档。查询本身有点长，所以我们使用了一个辅助函数。这种方法的一个缺点是，如果我们更改向量数据库，就必须重写辅助函数。

在这里，我们使用的是 LangChain Go，它为我们的 LLM 和向量数据库提供了接口抽象。如果我们替换这些组件，相似性搜索和从单个提示生成调用的代码将无需更改。

最后，我们来看看 Firebase Genkit for Go，目前处于测试阶段。它提供了与 LangChain Go 类似的抽象。Genkit 包含生产级功能，如提示管理和可观察性，这些功能可能在代码中不可见，但可以改善整体开发者体验。

随着你的 AI 系统的发展，Go 对简单性的强调意味着即使代码规模和复杂性增加，你的代码仍然保持可读性。Go 的特性，如对象嵌入和接口，使得在需求和技术发生变化时可以无缝迁移——而它们总是会发生变化。Go 在跟上快速变化方面的成熟能力使其在一些最知名的云基础设施组件中取得了成功。推动 Go 在云领域普及的相同特性，也使其成为我们构建未来 AI 基础设施的绝佳选择。

我希望我们已经在这个视频中证明了，Go 围绕生产力、开发者体验和生产就绪性的创始原则，仍然是我们今天优先考虑工作的依据。在结束之前，我想花几分钟时间让大家一窥 Go 1.25 及更高版本即将推出的内容。

首先，在 Marc 关于 AI 的讨论基础上，我们对围绕 SIMD 所做的工作感到非常兴奋。SIMD 使现代 CPU 能够执行向量化数组操作，并行运行某些类型的循环。这些功能对于许多类型的性能优化至关重要，包括某些类型的 AI 基础设施所需的优化。

在性能方面，我们在多核硬件方面有很多令人兴奋的机会，包括垃圾回收器和调度器的功能，这些功能可以更好地利用现代 CPU 架构中的非一致性内存访问。

切换到语言本身，在我们持续推动提高生产力方面，我们还有很多需要完善的地方，特别是在泛型操作的灵活性方面。有关该工作的更多信息，请查看我们在 GitHub 上 Go 项目的讨论。

在我们做所有这些以及更多事情的同时，你可以放心，我们现在和将来所做的任何更改都将继续履行 Go 的兼容性承诺。Go 仍然并将永远保持与 Go 1.0 的完全向后兼容。

在我们结束时，我们想花点时间感谢 Go 社区。我们，Go 团队，致力于在未来很长一段时间内保持 Go 的生产力和生产就绪性。但我们知道我们并不孤单。今天，我们的生态系统比以往任何时候都更大、更健全。我们继续看到许多非常高质量的工具和库涌现，尤其是在围绕生成式 AI 的新用例方面。我们看到世界各地成千上万的 Gopher 聚会、参加 Go 会议，并在网上协作，所有这些都是因为他们热爱 Go。所以，感谢 Go 社区。正是因为你们的贡献，Go 才得以发展，并且比以往任何时候都更具相关性。我们非常自豪能与你们一起参与这段旅程。

要开始使用，或获取有关本视频中讨论的任何内容的更多信息，请务必访问我们的主页 go.dev。感谢你参加今年的 Google I/O 大会。我们迫不及待地想看看你今年以及未来几年用 Go 构建的成果。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

本文永久链接 – https://tonybai.com/2025/05/09/github-english-communication-patterns-and-practice

大家好，我是 Tony Bai。

身处全球化的软件开发浪潮中，GitHub早已成为我们协作、学习、贡献的“宇宙中心”。但对于我们许多非英语母语的开发者来说，它既是机遇之地，有时也是“望而却步”的挑战场。

你是否也曾有过这样的经历？

• 面对一个棘手的 Bug，想在golang/go项目的 Issue 下寻求帮助，却因为担心自己的“蹩脚”英文描述不清，反复修改，最终默默关掉了页面？
• 看到一个热门讨论，你明明有绝佳的改进建议或独到的反驳观点，却因为组织不好地道的英文表达，只能眼睁睁看着讨论走向自己不希望的方向，最后无奈地打出“+1”？
• 或者，因为语言的障碍，你觉得自己与那些国际顶尖的Go开发者之间隔了一层无形的墙，错失了许多宝贵的交流与学习机会？

如果这些场景让你感同身受，那么今天的文章，就是为你量身打造的。如今，在ChatGPT、DeepSeek、Google Gemini等AI工具的辅助下，我们可以更自信地表达，但理解Github上的沟通的“套路”和文化依然重要。

通过对大量顶级 Go 开源项目（如Go官方仓库、Kubernetes、Docker/Moby、Prometheus等）的 Issues 和 Pull Requests 中社区互动的观察分析，以及AI的辅助整理，并结合这些项目通常倡导的沟通准则，我粗略整理出了一套在 GitHub Issues 中进行高效英语沟通的实用“模式”与“心法”。

本文旨在为你提供这套方法，希望能帮你打破沟通壁垒，自信地参与到全球 Go 开源社区中，让语言不再是你贡献智慧的拦路虎！

GitHub Issue沟通的“潜规则”与礼仪

在我们深入学习具体的沟通“招式”之前，了解战场规则是制胜的前提。GitHub Issues 作为一个全球开发者协作的广场，自然也有一套约定俗成的“潜规则”和基本礼仪。Github上的有效沟通是建立在这些规则和礼仪之上的。掌握了这些，你的每一次发言才能更得体、更高效，也更容易获得他人的尊重和积极回应。记住，高效的沟通才是开源协作的基石。

协作至上 (Collaborative)

开源的本质是团队协作。你的每一个评论、每一个 Issue，都应服务于项目的整体目标，而非仅仅表达个人。

简洁明了 (Concise & Clear)

维护者和贡献者的时间都非常宝贵。用最少的文字清晰地表达你的观点至关重要。避免冗长和含糊不清。

建设为本 (Constructive)

即使你持有不同意见，甚至需要反驳他人，也务必保持建设性的态度和尊重的语气。对事不对人。

技术导向 (Technically Focused)

交流应始终围绕技术问题展开，避免无关的个人情绪或评论。

心中有了这些“潜规则”作为行事准则，我们就可以更有底气地进入实战演练了。面对 GitHub Issues 中形形色色的沟通场景——从报告一个恼人的 Bug，到提出一个颠覆性的改进方案，再到与全球开发者唇枪舌战——掌握一些行之有效的沟通“套路”或“模式”，能让你事半功倍。接下来，我们就来拆解七种最常见的沟通场景及其应对的“招式”。

实战演练：GitHub Issues 英语沟通“七招十二式”

第1招：精准“报案”——如何清晰报告Bug？

当你满心欢喜地使用某个库或工具，却冷不丁踩到一个“坑”，程序崩溃了，或者行为完全不符合预期——恭喜你，你可能发现了一个 Bug！向社区报告 Bug 是每一位负责任的开发者的基本素养。但如何“报案”才能让维护者快速理解并定位问题呢？一个结构清晰、信息完备的 Bug报告是成功的一半。如果开源项目有自己的issue模板，那请按照issue模板的要求填写。如果没有issue模板，可以参考下面的提bug的issue模式结构。

模式结构

1. 简述问题 (Title & Brief Description): 一句话点明问题核心。
2. 重现步骤 (Steps to Reproduce): 清晰、可操作的步骤。
3. 预期行为 (Expected Behavior) vs 实际行为 (Actual Behavior): 对比清晰。
4. 环境详情 (Environment Details): 如 Go 版本、OS、库版本等。
5. （若有）最小可复现代码 (Code to Reproduce): 这是最重要的部分！

示例

我们以Go并发Map写入产生Panic为例，写一个“报案”issue:

Title: Panic: concurrent map writes in high concurrency scenarios

Description:
I've encountered a panic due to concurrent writes to a map.

Steps to reproduce:
1. Run the provided Go program.
2. The program attempts to write to a map from 100 goroutines.

Expected behavior: The program should complete without panic.
Actual behavior: Panics with "fatal error: concurrent map writes".

Environment: Go 1.22.1, Ubuntu 22.04/amd64

Code to reproduce:

package main
import (
    "fmt"
    "sync"
)

func main() {
    m := make(map[int]int)
    var wg sync.WaitGroup
    for i := 0; i < 100; i++ {
        wg.Add(1)
        go func(idx int) {
            defer wg.Done()
            m[idx] = idx // Potential concurrent write
        }(i)
    }
    wg.Wait()
    fmt.Println("Map operations completed.")
}

小贴士： 最小可复现代码是金！它能让维护者最快定位问题。如果能提供Go Playground的链接就更好了，维护者可以直接在playground中运行并复现问题。

第2招：有理有据——如何提供上下文与代码示例？

有时候，你可能不是报告一个全新的 Bug，而是想讨论某个已有功能的不足，或者对某段代码的设计提出疑问。这时，仅仅用文字描述可能不够直观，提供清晰的上下文和精炼的代码示例，能让你的观点更有说服力，也更容易被他人理解。

模式结构

1. 引用相关处 (Quote Specific Code/Doc): 明确指出讨论的上下文。
2. 解释当前逻辑 (Explain Current Implementation): 简述你对当前代码的理解。
3. 展示问题/建议 (Show Minimal Example): 用简短代码清晰展示。

示例

以为“Go切片去重优化建议”提供上下文和代码示例为例：

In `pkg/utils/slice.go`, the `RemoveDuplicates` function currently uses a nested loop, which can be inefficient (O(n^2)) for large slices.

// Current (conceptual)
// func RemoveDuplicates(slice []int) []int { ... uses nested loop ... }

I suggest a more efficient O(n) approach using a map:

func RemoveDuplicatesEfficient(slice []int) []int {
    keys := make(map[int]bool)
    list := []int{}
    for _, entry := range slice {
        if _, value := keys[entry]; !value {
            keys[entry] = true
            list = append(list, entry)
        }
    }
    return list
}
This significantly improves performance for large inputs.

第3招：献计献策——如何优雅地提出解决方案？

发现问题只是第一步，如果你对如何解决这个问题或改进现有功能有了自己的思考和方案，那更是社区所欢迎的！但如何提出你的“锦囊妙计”才能显得专业又不突兀，还能引发积极的讨论呢？下面我们来看看第3招的模式结构与示例。

模式结构

1. 认可问题/现状 (Acknowledge Issue/Limitation): 先表示理解。
2. 提出方案及理由 (Propose Solution & Rationale): 清晰阐述。
3. 潜在影响/权衡 (Potential Impacts/Trade-offs): 客观分析。

示例

以提出“引入Redis缓存”这一解决方案为例，我们看看如何编写issue/issue comment：

The current in-memory caching works for single instances, but doesn't scale well in our distributed setup.
I propose implementing a distributed cache using Redis. This would improve cache hit rates and consistency across nodes.
Example snippet for connecting and setting a key:
// import "github.com/go-redis/redis/v8"
// rdb := redis.NewClient(...)
// rdb.Set(ctx, "mykey", "myvalue", 0)

The main trade-off is adding Redis as a new dependency and managing its infrastructure.
What are your thoughts on this direction?

第4招：求同存异——如何专业地表达赞同与分歧？

GitHub Issues 常常是各路英雄好汉思想碰撞的“华山论剑”之地。面对他人的提议或观点，如何清晰地表达你的立场，无论是“英雄所见略同”还是“恕我直言，此法不妥”，都需要技巧。专业的表达能促进讨论，而非引发争执。

模式结构

1. 确认对方观点 (Acknowledge Point): “我理解你的意思是…”
2. 明确表态 (State Agreement/Disagreement): 清晰，但语气要专业。
3. 解释理由/替代方案 (Explain Rationale/Offer Alternative): 这是关键。

示例

我们以“同意，但有补充”这一场景为例，看看下面的示例：

I agree with @username's suggestion to use a factory pattern here. It will definitely make the component more extensible.
Perhaps we could also consider making the factory methods accept a context.Context for better cancellation propagation?

如果是“不同意，提替代方案”，可以参考下面示例：

Thanks for the proposal, @anotheruser. I understand the motivation to simplify the API.
However, removing the `AdvancedOptions` struct might limit flexibility for power users who need fine-grained control.
Could we perhaps keep `AdvancedOptions` but provide a simpler constructor with sensible defaults for common use cases?

第5招：打破砂锅问到底——如何有效地请求澄清？

在技术讨论中，遇到不明白的地方是很正常的。与其猜测或基于错误的理解继续讨论，不如礼貌地请求对方澄清。一个好的提问，能消除歧义，让讨论更聚焦，也能展现你严谨的学习态度。

模式结构

1. 引用待澄清点 (Quote Specific Point): “关于你提到的 X…”
2. 清晰提问 (Ask Clear Question): 具体，不要含糊。
3. 解释为何需要 (Explain Why You Need Clarification): 帮助对方理解你的困惑。

示例

In your PR description, you mentioned "refactored for better performance."
Could you please elaborate on which specific parts were refactored and what kind of performance gains you observed?
This would help us better understand the impact and review the changes more effectively. Thanks!

第6招：进展同步——如何及时更新你的工作状态？

如果你认领了一个 Issue 开始修复，或者正在为一个提案进行调研，及时地向社区同步你的进展非常重要。这不仅能让大家了解事情的最新动态，避免重复劳动，也能在你遇到困难时及时获得帮助。

模式结构

1. 关联旧事 (Reference Previous Discussion/Issue): “关于 #123…”
2. 描述新进展 (Describe New Findings/Progress): 简洁明了。
3. 下一步计划 (Suggest Next Steps, if any): … …

示例

Update on issue #456 (the memory leak in the parser):
I've run a profiler and identified a goroutine leak related to unclosed HTTP response bodies.
I'm working on a fix and will push a draft PR for initial feedback shortly.

第7招：圆满收官/致谢——如何得体地结束讨论与表达感谢？

当一个 Issue 的讨论有了结论，问题得到解决，或者一个 PR 即将被合并时，一个得体的“收尾动作”同样重要。清晰地总结成果，并对参与讨论和贡献的伙伴表示感谢，是开源社区良好氛围的体现。

模式结构

一个“结束讨论”的结构通常是这样的：

1. 总结要点 (Summarize Key Points):
2. 陈述结论 (State Conclusion/Decision):
3. 建议关闭 (Suggest Closing Issue, if applicable):

如果是“致谢”，可以参考下面结构：

1. 明确感谢对象与行为 (Specify Who/What You’re Thankful For):
2. 表达感谢 (Express Gratitude):
3. （可选）提及贡献的重要性 (Mention Impact):

示例

以结束讨论并致谢为例：

Thanks everyone for the insightful discussion on the new API design!
To summarize, we've agreed on:
1. Using `context.Context` for all request-handling functions.
2. Returning `(T, error)` consistently.
3. Adding more detailed examples to the documentation.

I'll create follow-up issues for these action items. I believe we can close this main discussion issue now.
Special thanks to @contributorA for the detailed performance benchmarks and @contributorB for the excellent documentation suggestions! Your input was invaluable.

熟练掌握了这些沟通“招式”，就像习武之人有了套路，但要真正做到运用自如、出神入化，还需要打磨“内功”——也就是我们的语言基本功和一些约定俗成的表达。了解一些 GitHub 上通用的交流短语、缩略语，并避开常见的表达“雷区”，能让你的沟通更顺畅、更地道。下面，就让我们一起走进“语言加油站”。

语言加油站：GitHub 通用表达、缩略语与避坑指南

GitHub Issues/PR 常用语句模式精选

下面这些短语和句式可以帮助你更流畅地参与讨论和表达观点。

• 表示赞同/确认：

  • “Sounds good to me.” (听起来不错。)
  • “That makes sense.” (这很有道理。)
  • “I agree with this approach/suggestion.” (我同意这个方法/建议。)
  • “Good point.” / “Valid point.” (说得好。/有道理。)
  • “Acknowledged.” (已了解。/收到了。)

• 提出疑问/请求澄清：

  • “Could you please provide more details on X?” (可以提供更多关于 X 的细节吗？)
  • “I’m not sure I follow. Could you rephrase that?” (我不太明白，能换种说法吗？)
  • “What are your thoughts on Y?” (你对 Y 有什么看法？)
  • “Just to clarify, are you suggesting Z?” (只是为了确认一下，你的意思是 Z 吗？)

• 表达不确定/需要思考：

  • “I need some time to think about this.” (我需要点时间考虑一下。)
  • “I’m not entirely sure about that yet.” (我还不太确定。)
  • “Let me look into this and get back to you.” (我研究一下再回复你。)

• 委婉提出不同意见：

  • “I see your point, but I’m a bit concerned about…” (我明白你的观点，但我有点担心…)
  • “Have we considered the potential downsides of X?” (我们考虑过 X 的潜在缺点吗？)
  • “Another way to look at this might be…” (换个角度看，也许可以…)

• 跟进/提醒：

  • “Any updates on this issue?” (这个问题有什么新进展吗？)
  • “Just a friendly ping on this.” (友情提醒一下这个事情。)
  • “Gentle reminder that this PR is awaiting review.” (温馨提示这个 PR 还在等待 review。)

常见缩略语与行话解读

熟悉这些缩略语能让你更快理解他人的评论，也能让你的表达更简洁（但注意不要过度使用，确保对方能理解）：

• LGTM: Looks Good To Me (代码审查通过，看起来不错) – 非常常用！
• SGTM: Sounds Good To Me (听起来不错)
• ACK: Acknowledged (已悉/收到) – 有时也表示同意或确认收到。
• NACK/NAK: Negative Acknowledge (不赞同/反对)
• WIP: Work In Progress (正在进行中) – 常用于 PR 标题或评论，表示还未完成。
• PTAL: Please Take A Look (请看一下) – 请求 review。
• TBR: To Be Reviewed (待审查)
• TL;DR: Too Long; Didn’t Read (太长不看；通常后面会跟一个总结)
• IMO/IMHO: In My Opinion / In My Humble Opinion (在我看来/恕我直言)
• AFAIK: As Far As I Know (据我所知)
• IIRC: If I Recall Correctly (如果我没记错的话)
• FYI: For Your Information (供你参考)
• PR: Pull Request (合并请求)
• CI: Continuous Integration (持续集成)
• CD: Continuous Deployment/Delivery (持续部署/交付)
• RFC: Request For Comments (征求意见稿) – 常用于重要设计或提案。
• PoC: Proof of Concept (概念验证)

非母语者常见表达“雷区”与地道说法 (避坑指南)

下面是非英语母语者的一些常见表达问题，这些问题降低了沟通效率，请尽量避免，并使用更为地道的表达方式。

• 避免过度复杂句式：

  • 雷区： “It has come to my attention that the aforementioned functionality is exhibiting behavior inconsistent with the documented specifications under certain edge-case conditions.” (典型的学术腔或书面语过度)
  • 地道： “I found a bug: the function doesn’t work as documented with edge cases.” or “This feature has an issue with edge cases. See details below.” (简洁明了)

• 避免直译母语（尤其是中式思维）：

  • 雷区： “This code has problem.” (语法上没错，但不够地道和具体)
  • 地道： “I’m encountering an issue with this code.” / “There seems to be a problem with this code.” / “This code doesn’t work as expected when X happens.” (更具体地描述遇到的情况)

• 避免过度礼貌或不自信，导致信息冗余：

  • 雷区： “I am very sorry to disturb you, maybe my English is not good, but I think there is a small tiny bug, if you have time please look, thank you very much.” (过多的道歉和谦逊有时会淹没核心信息)
  • 地道： “Hi, I might have found a bug. [Describe bug concisely]. Could you please take a look when you have a moment? Thanks!” (礼貌且直接)

• 避免使用俚语、网络流行语或不必要的缩写 (除非社区内非常通用且氛围轻松)： 保持专业和清晰。

• 注意词语的细微差别：

  • “Suggest” vs “Recommend”: Recommend 通常更强烈一些。
  • “Problem” vs “Issue”: Issue 更中性，常用于 GitHub 语境；Problem 可能暗示更严重或已确认的缺陷。
  • “Fix” vs “Address” vs “Resolve”: Fix 强调修复；Address 强调处理或应对；Resolve 强调彻底解决。

推荐辅助神器

大家可以充分使用一些翻译工具，比如DeepL、Google Translate或是像“沉浸式翻译”这样的浏览器插件，辅助理解和翻译，但务必结合自己的理解进行校对。

此外，更多开发者转向借助ChatGPT等AI助手辅助翻译、润色句子、组织思路，甚至生成初稿，但最终表达的思想和技术准确性仍需你来把控。AI 是你的副驾驶，不是自动驾驶员。

招式和语言技巧都备齐了，但很多时候，真正阻碍我们开口的，可能不是“会不会说”，而是“敢不敢说”。内心的不自信、对犯错的恐惧，常常成为参与全球开源协作的最大心理障碍。因此，除了硬技能，建设强大的“内心”同样重要。接下来，我们就聊聊如何调整心态，克服“开口难”。

心态建设：克服“开口难”，拥抱不完美

掌握了模式和工具，最重要的其实是心态：

1. 自信第一，清晰至上： 没人指望你的英语是母语水平。在技术社区，清晰、准确地传达技术信息远比完美的语法重要。
2. 从小处着手，逐步升级： 可以先从给好评的 PR 点赞 、评论一句 “LGTM!” (Looks Good To Me!) 或 “Thanks for this fix!” 开始。然后尝试提简单的澄清问题，再到报告 Bug，最后挑战提出解决方案。
3. 拥抱反馈，乐于学习： 如果有人友善地指出了你的表达问题，把它看作一次宝贵的学习机会，而不是指责。
4. 开源社区的包容性： 绝大多数开源社区（尤其是成熟的 Go 社区）对于非英语母语者的努力都非常理解和包容。你的真诚、你的技术思考、你的代码贡献，远比流利的口音和地道的表达更重要。
5. 别怕犯错，大胆尝试： 每个人都是从新手过来的。不开口，永远无法进步。勇敢地按下那个”Comment”的提交按钮吧！

当我们鼓起勇气，用日益精进的英语在 GitHub 上挥洒智慧时，还会遇到一个隐形的挑战——文化差异。开源社区汇聚了全球各地的开发者，不同的文化背景可能导致对同一句话有不同的理解。要想让我们的沟通如丝般顺滑，避免不必要的误解，了解并尊重这些差异，就如同在全球协作中添加了高效的“润滑剂”。

跨越文化鸿沟：全球协作的润滑剂

1. 直接 vs. 间接： 西方文化通常更偏好直接沟通。表达不同意见时，可以说 “I have a different perspective on this…” 或 “An alternative approach could be…”，而不是过于委婉以至于观点不明。
2. 避免绝对化词语： 少用 “never”, “always”, “impossible” 等，多用 “it seems”, “perhaps”, “it might be” 等留有余地的表达。
3. 幽默需谨慎： 文字形式的幽默和讽刺极易在跨文化背景下产生误解。在正式的技术讨论中，建议保持专业和中性。
4. 给予正面反馈： 即使是否定对方的提议，也可以先肯定其努力或思路的某些方面，如 “Thanks for bringing this up, it’s an interesting idea. However, I’m concerned about X…”

总结与行动倡议

行文至此，我们一起探索了 GitHub Issues 英语沟通的“潜规则”、实战“招式”、语言“加油包”、心态“建设术”以及跨文化“润滑剂”。相信这些内容能为你打开一扇新的大门。但正如任何技能的学习一样，真正的掌握源于不断的实践。

打破 GitHub 上的英语沟通壁垒，并非遥不可及。通过理解社区文化、掌握核心沟通模式、善用工具、并辅以积极自信的心态，每一位非英语母语的 Go 开发者都能在全球开源的舞台上自如交流，贡献才智。

记住，语言是桥梁，不是障碍。最重要的是你对技术的热情和你想要分享的价值。

现在，轮到你了！

• 你曾在 GitHub 因英语遇到过什么有趣或尴尬的经历？
• 你有什么独家的英语沟通小技巧愿意分享？

欢迎在评论区留言，让我们一起交流，共同进步！

深入探讨，加入我们！

想获得更多关于 Go 技术、开源参与、个人成长方面的深度交流和指导吗？欢迎加入我的知识星球 “Go & AI 精进营”！

在那里，我们可以：

• 针对你的具体 Issue 描述或 PR 进行“英文表达”点评。
• 分享更多跨文化协作的真实案例。
• 共同探讨如何更有效地参与顶级 Go 开源项目。

欢迎扫描下方二维码加入星球，和我们一起精进！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

本文永久链接 – https://tonybai.com/2025/03/16/gemini-deep-research-experience

基于大模型的AI已进入深度思考时代，以DeepSeek R1模型为代表的开源模型给主流AI厂商带来了巨大压力。其实早在2024年12月份，Google就在一篇名为“Try Deep Research and our new experimental model in Gemini, your AI assistant”中发布了自己的Deep Research产品：Gemini Deep Research。

Gemini Deep Research不仅仅是一个简单的搜索引擎，而是一个智能研究助理。用户只需输入研究主题，Deep Research即可自动完成以下工作：

• 自动制定研究计划：根据主题的复杂性，Deep Research会生成一个多步骤的研究计划。
• 深度网络信息分析：Deep Research会像人类研究员一样，在网络上进行多轮搜索、分析、筛选，并根据已获取的信息不断调整搜索策略。
• 生成综合报告：最终，Deep Research会生成一份结构化的报告，包含关键发现、主要观点以及原始资料链接。
• 支持交互式提问：用户可以对报告内容进行追问，Deep Research会进一步解释或补充信息。

不过最初发布时，免费用户体验受到了限制。2025.3.13 Google更新了其AI产品gemini的功能特性，并宣布在Gemini 2.0 Flash Thinking等模型上增加Deep Research功能(并且相对于早期的功能又有了能力上的增强)。现在即便你是免费用户，只要打开Gemini应用的主页面，就能看到下面带有Deep Research功能选项的对话输入框：

并且，在Gemini app页面上免费用户可以使用的模型都支持Deep Research，虽然每月依然有使用次数限制：

作为Gemini AI助手的一项重要特性，基于大窗口增强后的Deep Research利用Gogle强大的信息搜索能力以及AI强大的信息处理能力，可为用户提供深度、全面的研究报告，大幅提高了研究效率。

在信息爆炸的时代，我们这些技术人员面临着持续学习和快速掌握新技术、新趋势的巨大挑战。传统的研究方法往往耗时费力，如何在海量信息中高效提取关键信息，已成为提升技术竞争力的关键要素。

本文将以”Go语言未来5-10年的演进方向及核心团队发力重点”这一主题为例，分享我对增强版Gemini Deep Research的抢先体验。

实战体验：Go语言未来演进方向研究

为了测试Deep Research的实际效果，我选择了一个对Go开发者非常关心的话题：

“Go语言未来5-10年的演进方向以及Go核心团队的发力重点会在哪里？”

研究过程

启动研究

在Gemini对话框中输入上述主题，并在左上角选择”Deep Research”模型，然后提交。

Gemini会首先会自动生成研究计划，如下图，并等待你的确认：

确认方案，并等待研究完成

你可以修改方案，也可以点击“开始研究”，一旦选择后者，Deep Research就会自动开始进行研究(包括反复的数据搜索、分析结果等)。在研究过程中，Gemini会显示当前的研究进度，例如”正在分析相关信息”、”正在生成报告”等，下面是研究过程的一些截图：

… …

整个过程大约持续了10-15分钟（具体时间取决于主题的复杂性）。

获取研究报告

研究完成后，Gemini生成了一份详细的报告，结构完整，内容丰富。Gemini支持将报告导出到Google Doc，之后你便可以基于Google Doc查看、编辑或下载这份研究报告了。Gemini为我生成的这份报告放在了这里。如果你访问不了，我在本文附录也放了一份报告结果，请参考。

下面我们再简单看一下报告质量。

研究报告内容与质量分析

这次Gemini针对我提出的题目生成的报告包含以下主要章节：

• Go语言的持久相关性与未来轨迹
• 近期重要进展分析（Go 1.24及未来）
• 核心团队的优先事项解读：解读发力重点
• 未来5-10年Go语言的演进方向
• Go的应用：应对现代挑战
• Go未来面临的挑战和考虑因素
• 结论：规划Go未来十年的发展方向
• 相关统计表格和参考文献

从全面性来看，该报告涵盖了Go语言发展的多个维度，从技术细节（如泛型、性能优化、WebAssembly支持）到宏观趋势（如云计算、边缘计算、AI/ML集成），再到社区和生态系统的发展，内容全面而不失重点。

该报告不仅是信息的简单堆砌，而是对信息进行了深入的分析和整合，不乏一定的深度。例如，报告准确地指出了Go核心团队在性能优化、并发、WebAssembly等方面的持续投入，并分析了这些投入背后的战略意图。

报告还给出了引用的信息的确切来源，包括Go官方博客、技术文章、社区讨论等，初步看了一眼，信息来源相关性强，且地址可靠。比如：报告中提到的Go 1.24的新特性、核心团队的优先事项等，都与官方信息保持一致。

报告也提出了一些有价值的洞察，例如Go在边缘计算和物联网领域的潜力、在AI/ML领域可能的发展方向等，为读者提供了前瞻性的视角。

报告结构非常清晰，语言流畅，易于理解。即使是对Go语言不太熟悉的读者，也能通过报告快速了解Go语言的未来发展趋势。

该报告的撰写质量估计已经超过了许多有多年Go开发经验的资深工程师所能提供的分析。如果一个技术人员亲自去调研和总结这些内容，没有3-5天的时间投入是很难完成的。

体验结论

通过此次体验，我们可以深刻地感受到Gemini Deep Research的强大功能和巨大潜力：

• 效率提升：Deep Research将原本需要数小时甚至数天的研究工作缩短至几分钟，极大地提高了研究效率。
• 信息全面性：Deep Research能够从多个来源获取信息，并进行综合分析，避免了人工研究可能存在的遗漏和偏见。
• 深度洞察：Deep Research不仅是信息的搬运工，它能够对信息进行深入分析，提炼出有价值的洞察。
• 持续学习：Deep Research处于不断进化中，未来将会变得越来越强大。

Gemini Deep Research等深度研究工具的出现与演进，标志着AI驱动的研究新时代的到来。它将改变我们获取信息、分析信息、利用信息的方式，为各行各业带来巨大的变革。对于技术团队来说，Deep Research无疑是一个强大的工具，可以帮助我们更快地学习、更深入地思考、更高效地工作。

附录

Go语言未来5-10年的演进方向及核心团队发力重点

1. 引言：Go的持久相关性与未来轨迹

自2009年公开宣布，并于2012年发布1.0版本以来，Go语言已在现代软件开发领域占据重要地位，尤其是在云基础设施和可扩展系统方面 1。其设计初衷是为了解决大规模软件开发的复杂性 6，强调简洁、高效和并发性 1。Go语言的用户群体显著增长，表明其采用率和相关性不断提高 10。这种增长凸显了理解其未来演进以及Go核心团队优先事项的必要性。本报告将分析近期发展、社区讨论以及Go项目关键人物的见解，以预测未来5到10年Go语言的发展轨迹，重点关注核心团队的努力方向。

Go语言最初的创建动机是为了解决Google在软件基础设施方面面临的实际问题，例如C++在构建现代服务器软件时遇到的构建缓慢、依赖管理失控和并发编程困难等挑战 1。这种以解决实际问题为导向的设计思路深深植根于Go语言的基因中，可以预见，未来Go核心团队将继续关注实际应用，并致力于满足开发人员的需求。

Go语言用户群体的持续增长以及主要科技公司的广泛采用，为Go语言的未来发展奠定了坚实的基础 10。来自各种调查的数据一致显示，越来越多的开发人员正在使用Go语言，并且有学习Go语言的意愿。诸如Google、Netflix、Uber和Dropbox等公司 3 在其关键基础设施中对Go语言的依赖，突显了Go语言的成熟性和适用于大规模项目的能力，这无疑将确保核心团队和社区对Go语言的持续投入和发展。

2. 近期重要进展分析：Go 1.24及未来

2025年2月发布的Go 1.24版本是一个重要的里程碑，它揭示了Go核心团队当前的优先事项 17。此版本的主要特性包括：

• 完全支持泛型类型别名，增强了代码的灵活性并减少了冗余 17。这解决了社区长期以来的一个需求 8。
• 运行时性能得到提升，在一系列代表性基准测试中，CPU开销平均降低了2-3%。这些改进包括基于Swiss Tables的新map实现、更高效的小对象内存分配以及新的内部互斥锁实现 10。
• 通过go:wasmexport指令将Go函数导出到Wasm，并支持构建为WASI反应器/库，增强了WebAssembly (Wasm) 的功能 17。这标志着Go语言正日益关注将其应用范围扩展到传统的服务器端应用之外 21。
• go.mod中新增了管理工具依赖的机制 18，并且go vet命令通过新的测试分析器得到了改进 18。这些变化旨在改善开发人员的体验和代码质量。
• 标准库新增了FIPS 140-3合规性机制、用于目录限制文件系统访问的新os.Root类型以及比runtime.SetFinalizer更灵活的runtime.AddCleanup函数用于清理操作 1。这些新增功能增强了Go在安全性、系统编程和资源管理方面的能力。
• 用于测试并发代码的实验性testing/synctest包 17。这突显了并发性在Go语言发展中的持续重要性。
• bytes和strings包中新增了基于迭代器的新函数，提高了常见数据处理任务的效率 18。

Go 1.24中包含的诸如泛型等长期以来备受期待的功能，体现了核心团队对社区反馈的积极响应以及他们为满足现代编程需求而不断发展语言的意愿。Go社区对泛型的需求由来已久 8。Go 1.18开始引入泛型，并在1.24版本中进一步完善了对泛型类型别名的支持，这表明核心团队认真听取了开发者的意见，并准备在社区达成广泛共识且对生态系统有明显益处时，对语言进行重大改变。

Go 1.24中显著的性能改进，进一步巩固了Go语言在效率和速度方面的核心价值主张，预示着性能优化将继续成为核心团队未来的重点工作。关于使用Swiss Tables加速Go map以及其他运行时改进的详细博客文章 10 清晰地表明，核心团队正在持续努力使Go程序在现代硬件上运行得更快、更高效。这与Go最初为基础设施软件设定的设计目标相一致。

Go 1.24中对WebAssembly功能的增强，暗示着Go语言正在战略性地定位自己，使其成为一种能够在包括Web浏览器和基于云的Wasm运行时等多种环境中运行的多功能语言。go:wasmexport指令和WASI反应器支持的引入 17 不仅仅是增量式的变化，它们代表着核心团队有意使Go成为更具吸引力的WebAssembly开发选择。关于可扩展Wasm应用的博客文章 17 详细介绍了这些新增功能，表明核心团队期望Go在浏览器端和服务器端的Wasm应用中都发挥重要作用。

3. 核心团队的优先事项：解读发力重点

基于近期发布的版本、Go团队的博客文章 10 以及社区讨论，可以识别出Go核心团队的几个关键优先事项：

• 持续强调性能和效率： 每个版本中持续的性能改进 10 表明，保持和提升Go的性能特性仍然是首要任务。这包括针对现代硬件优化运行时、标准库和编译器 10。对诸如新的map实现和内存分配改进等底层优化的关注，表明核心团队致力于从根本上提高Go的性能，从而使广泛的应用受益。关于Swiss Tables的博客文章 17 详细介绍了这些深层次的运行时修改，表明了对核心性能的长期投入。
• 并发和并行方面的进步： Go在并发方面的优势 1 仍然是关键的关注点，实验性testing/synctest包的引入 17 表明，核心团队正在不断努力改进并发编程的工具和支持。关于未来可能增强并发模型的讨论 25 也表明了其持续的重要性。开发专门用于测试并发代码的工具（如实验性的testing/synctest包 17）突显了核心团队致力于确保并发Go程序的可靠性和正确性，这对于许多目标用例（如云基础设施和分布式系统）至关重要。并发是Go语言的一个核心差异化优势，而对更好的测试框架的投入则体现了对其健壮性的承诺。介绍testing/synctest的博客文章 17 证实了这一重点。
• 对WebAssembly能力的战略投资： Go 1.24中对Wasm支持的显著增强 17 以及社区持续的兴趣 21 表明，使Go成为一种可行的WebAssembly语言是核心团队的战略重点。这为Go在前端开发和其他基于Wasm的环境中开辟了新的可能性 18。通过go:wasmexport将Go函数导出到Wasm宿主，并构建WASI反应器的双重关注，表明了核心团队对Wasm支持采取了全面的方法，旨在实现与各种Wasm生态系统（包括浏览器和服务器端环境）的互操作性。关于可扩展Wasm应用的博客文章 17 详细介绍了这种双重方法，表明核心团队设想Go在浏览器端和服务器端的Wasm应用中都将发挥重要作用。
• 加强语言和标准库的安全性： Go 1.24中包含的FIPS 140-3合规性机制 17 以及Go生态系统中关于安全性的持续讨论 8 突显了核心团队致力于使Go成为构建关键应用的安全语言。对内存安全的关注 1 也与这一优先事项相符。通过简单的环境变量 18 提供对FIPS认证加密的内置支持，体现了核心团队对安全性的积极态度，使得开发人员更容易构建符合安全规范的应用，而无需依赖外部库或复杂的配置。此功能直接解决了软件开发中日益增长的安全性重要性，尤其适用于需要遵守FIPS标准的企业和政府应用。
• 持续优化云原生架构： Go在云原生开发领域的强大影响力 2 是显而易见的，预计核心团队将继续为该领域优化语言和标准库。这包括与微服务、容器化 9 以及与云平台的集成 38 相关的改进。Docker和Kubernetes等主要的云基础设施工具都是用Go语言构建的 9，这使得Go的未来与云原生技术的演进紧密相连。这表明核心团队可能会优先考虑那些能够使该生态系统中的开发人员受益的功能和改进。Go在云生态系统中的基础性作用为核心团队提供了强大的动力，以确保它仍然非常适合这些工作负载，并保持其在该领域相对于其他语言的竞争优势。
• 探索Go在新兴领域的潜力（AI/ML，边缘计算）： 尽管Go在AI/ML领域尚未占据主导地位 8，但在该领域的使用潜力正在增长，尤其是在部署模型和构建基础设施方面 10。同样，Go的高效性和小巧的体积使其成为边缘计算和IoT应用的有力候选者 8。核心团队对支持这些领域的努力可能会在未来增加，正如关于Go在AI系统中的作用的讨论所表明的那样 10。Go在处理大型数据集方面的高效率及其在高性能AI应用开发方面的潜力 8 表明，即使Go的目标不是取代Python成为主要的模型开发语言，核心团队也可能正在探索增强Go在某些AI/ML工作负载（如高性能推理或构建AI基础设施）方面的适用性的方法。Go的性能优势可以在速度和效率至关重要的AI/ML领域（如推理或边缘部署，其中低延迟至关重要）得到利用。Go的轻量级特性和内置的并发性 26 与边缘计算和IoT的需求非常契合，在这些环境中，资源受限和需要处理大量并发连接是很常见的。这种天然的契合性表明核心团队可能会继续优化Go以适应这些环境。
• 提升开发者体验：工具和生态系统： 核心团队始终致力于通过增强工具 8（包括go命令、go vet和IDE集成 38）来改善开发者体验。错误处理 8 和包管理 5 的改进也是持续的优先事项。Go生态系统的健康发展 8 对于语言未来的成功至关重要。Go 1.24中引入的用于管理工具依赖的工具（使用go get -tool和go tool 18）直接解决了Go开发人员常见的workflow挑战，简化了开发所需的外部实用程序的管理，体现了对实用性和改善Go程序员日常体验的关注。简化开发工具的依赖管理可以改善整体开发者体验，并减少Go项目中的摩擦。诸如go vet（带有新的测试分析器）等现有工具的持续改进以及对新工具和功能的不断探索 8 表明，核心团队致力于为Go程序员提供一个健壮高效的开发环境，帮助他们编写更好更可靠的代码。强大的工具链对于开发者生产力至关重要，核心团队对这方面的投入反映了其对于Go语言长期成功的意义。

4. 不断演进的格局：未来5-10年的Go语言

展望未来，可以预见Go语言的几个趋势和潜在发展方向：

• 预期的语言演进和潜在的新特性： 尽管Go 1.x一直秉持着对向后兼容性的坚定承诺 1，但泛型的引入 8 表明，Go愿意为了解决关键的局限性和满足社区的需求而进行演进。未来的演进可能包括进一步完善泛型、潜在地改进错误处理 8，以及基于社区反馈和不断发展的技术格局，谨慎地引入其他特性。关于“Go 2.0”的讨论 8 表明了对更重大变革的长期愿景，但核心团队强调将采取循序渐进的方式 35。正如Russ Cox 48 所阐述的，以及Go语言缓慢但稳步的发展历程 35 所反映的那样，核心团队对语言的改变采取谨慎的态度。这表明，虽然核心团队对演进持开放态度，但他们将继续优先考虑稳定性和向后兼容性，以避免破坏庞大的现有Go代码生态系统。这种谨慎的做法一直是Go语言发展的标志，并且很可能会继续下去，从而确保Go语言对于长期项目来说仍然是一个可靠的选择。
• 标准库的增长和成熟： 标准库是Go语言的一大优势 1，提供了广泛的开箱即用功能。预计未来的增长将包括新的包以及对现有包的改进，可能涉及网络、数据处理和对新兴技术的支持等领域。math/rand/v2包的引入 10 为未来的库演进和现代化提供了一个范例。正如Go语言15周年纪念 10 中提到的那样，引入带有版本控制的新标准库包（如math/rand/v2）表明了一种具有前瞻性的库演进方法。这使得在不破坏与旧版本兼容性的情况下实现重大改进和新功能成为可能，为在遵守Go 1兼容性承诺的同时实现现代化提供了一条途径。
• Go Modules和依赖管理的作用： Go Modules 5 已成为Go语言依赖管理的标准，未来的发展可能会侧重于进一步简化和增强该系统。go.mod中工具指令的引入 18 是这种演进的最新例证。对Go Modules的持续改进，例如跟踪工具依赖的能力 18，表明核心团队致力于提供一个健壮且用户友好的依赖管理系统。这对于大型复杂的Go项目的可扩展性和可维护性至关重要，并反映了持续改进开发者体验的努力。
• 社区影响和开源贡献： Go的开源特性 1 意味着社区通过提案 49、贡献和反馈 16 在其发展中发挥着重要作用。核心团队通过调查 17 和讨论积极与社区互动，使得社区的意见成为塑造Go未来发展方向的关键因素。提案流程本身 56 确保了任何重大变更在被采纳之前都会在社区内得到仔细考虑和讨论。Go开发者调查 17 是核心团队收集广泛反馈并了解Go社区的使用模式、挑战和期望改进的关键机制。这种数据驱动的方法确保了语言的演进能够满足用户的实际需求。

5. Go的应用：应对现代挑战

Go语言的设计和近期发展使其能够很好地应对软件开发中的几个现代挑战：

• 云计算和微服务：巩固Go的地位： Go的高效性、并发性和小巧的二进制文件使其非常适合构建云原生应用和微服务 3。其持续的演进，包括性能的提升和并发测试工具的改进，可能会进一步加强其在该领域的地位。Go语言通过goroutine和channel实现的内置并发模型 1 为构建需要高效处理大量并发请求的分布式系统和微服务提供了显著的优势。与依赖外部库实现并发的语言相比，这种内置的并发模型简化了可扩展和响应迅速的云应用的开发。
• 边缘计算和物联网：发挥Go的效率优势： Go的性能和较小的资源占用使其成为边缘计算和物联网应用的绝佳选择 8。随着这些领域的持续增长，Go的作用预计将进一步扩大，尤其是在针对资源受限环境进行优化方面。Go语言生成的小巧且自包含的二进制文件 1 对于资源受限（如内存和处理能力）的边缘设备和物联网环境尤其有益。这使得Go应用能够在更广泛的硬件上高效运行。
• WebAssembly：将Go的触角延伸到前端： 凭借Go 1.24中增强的Wasm支持和持续的开发 17，Go正成为构建高性能前端Web应用的可行选择，可能在某些领域挑战JavaScript的主导地位，尤其是在计算密集型任务或需要浏览器中实现类似原生性能的应用方面。即使编译为WebAssembly 24，Go的性能特性也为Web应用带来了相比传统基于JavaScript的解决方案的显著性能提升潜力，尤其是在涉及复杂计算或需要与系统资源紧密交互的应用方面。
• 人工智能和机器学习：探索新的领域： 尽管在库的可用性方面仍然存在挑战 15，但Go的性能和效率使其成为部署和提供AI/ML模型的有希望的语言 8。未来的发展可能会看到对基于Go的AI/ML库和框架的更多投入，可能侧重于Go的优势（如用于并行处理的并发性）特别有益的领域。Go强大的性能和并发能力使其非常适合构建支持AI/ML工作负载的基础设施，例如数据处理管道、模型服务平台和分布式训练系统，即使它不会成为所有AI/ML开发阶段的主要语言。

6. Go未来面临的挑战和考虑因素

尽管Go语言的发展前景良好，但也面临着一些挑战和需要考虑的因素：

• 在简洁性与特性扩展之间取得平衡： Go的简洁性是其核心优势之一 1，但诸如泛型等特性的加入也引入了复杂性。核心团队必须在对新特性的渴望与保持语言的简洁性和可读性之间仔细权衡 8。泛型的引入虽然解决了社区的一个主要需求，但也代表着Go最初极简主义设计理念的一次偏离。核心团队需要继续仔细评估未来的特性提案，以确保它们在提供实质性好处的同时，不会过度损害语言的可读性和易于理解的核心原则。
• 回应社区反馈和不断变化的需求： Go社区对某些限制和期望的特性提出了很多意见 8，核心团队需要继续与这些反馈互动，并在坚守其核心原则的同时，使语言适应不断变化的需求 10。核心团队通过调查、博客文章和提案流程 17 与Go社区的积极互动对于确保语言的演进符合用户的实际需求和更广泛的软件开发趋势至关重要。维持这种开放的沟通和反馈循环对于Go语言的长期健康和相关性至关重要。
• 来自其他编程语言的竞争： Go面临着来自其他现代编程语言（如Rust 5）以及其他也针对类似领域（如云原生开发和高性能计算）的语言的竞争。Go未来的成功将取决于其维持独特优势并继续响应竞争格局而发展自身的能力。尽管Go和Rust经常在相似的领域展开竞争，但它们提供了不同的权衡（例如，Go的简洁性与Rust对不使用垃圾回收的内存安全的关注）。Go的持续成功可能取决于强调其优势并解决其相对于竞争对手的劣势，例如错误处理的冗长 59 或其他语言中存在的某些高级语言特性的缺乏。

7. 结论：规划Go未来十年的发展方向

Go语言有望在未来5到10年内继续保持增长和发展。正如近期发布的版本和社区互动所表明的那样，核心团队的优先事项侧重于持续的性能改进、并发方面的进步、对WebAssembly的战略投资、加强安全性、持续优化云原生架构以及探索AI/ML和边缘计算等新兴领域。

尽管在简洁性与特性扩展之间取得平衡以及应对竞争格局将是关键的挑战，但Go语言强大的基础、活跃的社区以及核心团队致力于满足开发者需求的承诺，都预示着Go语言拥有光明的未来。其适应现代挑战的能力以及对实用解决方案的持续关注，可能会在未来几年内巩固其作为构建可靠、可扩展和高效软件系统的关键语言的地位。

有价值的表格：

1. 表格：近期Go版本（Go 1.23和Go 1.24）的关键特性和关注领域

1. 表格：Go语言的采用统计数据和趋势

Works cited

// 数量太多，这里省略。

Gopher部落知识星球在2025年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。并且，2025年将在星球首发“Go陷阱与缺陷”和“Go原理课”专栏！此外，我们还会加强星友之间的交流和互动。欢迎大家踊跃提问，分享心得，讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落，享受coding的快乐! 欢迎大家踊跃加入！

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格6$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite
• Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
• Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

本文永久链接 – https://tonybai.com/2024/05/06/those-free-to-use-online-llm-services

2022年底以ChatGPT为代表的大语言模型的出现掀起了人工智能应用的新浪潮。这些庞大的语言模型经过对海量文本数据的训练，能够理解和生成逼近人类水平的自然语言，在对话、问答、文本生成、代码编写等领域展现出了惊人的能力。

最初这种能力“垄断”在OpenAI公司的手里，世界各地的AI爱好者们为了能尽快拿到ChatGPT的使用账号，使出了浑身解数，国内朋友更是如此。

不过随着Google、Meta、Anthropic、xAI等公司的逐步赶上（当然国内像百度、阿里等巨头的也投入巨量研发和成本）以及开源大模型的持续涌现，时隔一年多以后，目前互联网上的大模型服务已成“百花齐放”之势。无论在推理能力还是模型数量上，都有极大的提升，而使用成本则大幅降低。我们再无需局限于OpenAI这一家公司的大模型了，通过一些免费的在线大模型服务即可享受到多样化、高质量的AI服务。

在这篇短文中，我就来简单说说我使用过的那些免费在线大模型服务，供各位读者参考。

对于国内的朋友来说，本文介绍的大多数国外在线大模型服务的使用前提是你拥有一个价位合理、连接稳定的加速器服务。

1. 大语言模型聚合平台

我们先来看看一类典型的大语言模型服务平台，它们被称作大语言模型聚合平台，在这类平台上，我们可以使用超过一种的专有模型或开源LLM模型服务。

1.1 poe.com

poe.com是我日常使用的大语言模型服务的第一选择。它由美版知乎Quora平台开发运营。平台上的人工智能服务由多个不同公司训练的模型提供支持，并针对不同的任务进行了优化。Poe目前支持的机器人包括：OpenAI的ChatGPT、GPT-4和DALL-E 3，Anthropic的Claude Instant、Claude 2和Claude 3，Stability AI的StableDiffusionXL，Google的PaLM 和Gemini-Pro，Meta的Llama 3，Playground的Playground-v2，Mistral的Mistral-Medium，以及大量由社区用户自己创建的机器人。

poe.com提供的默认机器人Assistant由gpt-3.5-turbo和Claude 3 Haiku提供技术支持，这个是完全免费的。其他机器人如GPT4、Claude3 Opus、Mistral-Large、Gemini 1.5 Pro等顶级AI机器人则是使用受限的，需要付费订阅用户才能使用。而中间级别的机器人，如Claude-3-Sonnet、Mistral-Medium等则是有条数限制。开源模型的机器人，比如Llama3 70B则是免费使用的，至少我没碰到限制。

总之，poe.com上聚合的AI大模型通常足矣满足日常工作所需。

1.2 you.com

如果你就使用了poe.com的中级机器人，还达到的其条数限制的上限，我们还可以使用you.com作为备用的聚合大模型平台，当然如果你喜欢you.com的风格与交互方式，你完全可以将其作为你的第一选择。就像上面截图中那样，you.com支持大多数的主流的AI大模型，虽然品种不如poe.com多。

1.3 主流开源大模型的聚合平台

下面说一下以仅聚合开源大模型的一些平台，如果你只想体验、对比和使用开源大模型的话，也可以试试这些平台，目前这些平台没有设置使用条数等限制。

1.3.1 perplexity labs

1.3.2 huggingface chat

抱抱脸(huggingface)是AI界的github，他也提供了一些开源大模型的在线聚合服务：

1.3.3 together.ai

together.ai提供的开源ai大模型非常全面，并且如上图所示，用户可以自己调整大模型参数，比如Temperature、Top-P、Top-K等，非常适合一些开源大模型的深度研究者：

1.3.4 groq cloud

我们看到：groq cloud也提供一定的大模型参数调整能力（比如Temperature)，但groq提供的开源大模型种类较少，可做备用之选。

2. 独立的大语言模型服务

各大AI大模型的先驱者和驱动主力，比如OpenAI、Google、Meta、Anthropic等也都提供了独立的官方大语言模型服务，我们逐一来看看：

2.1 ChatGPT

OpenAI的ChatGPT在今年提供了免费服务，即使你不注册OpenAI账号也可以在线免费使用chatgpt 3.5，只是不能保存历史：

2.2 Google gemini

Google是AI领军人物，但OpenAI的异军突起打了他一个“措手不及”，不过Google实力还在，从最先推出的bard，到目前全面升级为gemini后，与OpenAI的能力差距在日益缩小。

2.3 Claude

由多家巨头公司共同投资的Anthropic推出的Claude系列大模型能力是与日俱增，最新的Claude 3系列已经基本追上了OpenAI，Anthropic也在自己的官方站点提供了sonnet、haiku的免费服务，只有最高端的opus是需要付费的：

2.4 Meta

Meta（前身Facebook)是开源大语言模型世界的核心力量，它开源的Llama系列大模型已经成为开源界大模型的基石。Meta在其ai官网也提供了在线版的Llama的体验服务，最新版是Llama3。

2.5 mistral.ai

Mistral AI是一家销售人工智能产品的法国公司。它由 Meta Platforms 和 Google DeepMind 的前员工于 2023 年 4 月创立。他也提供了针对其自身产品mistral的在线免费体验服务：

3. 国内提供的大语言模型服务

国内的公司虽然在算力上受到了政治因素的制约，但大模型能力也是在不断进步的，并且国内大模型大多都提供了在线体验服务以及app。但由于工作原因，国内大模型用的较少，这里就仅给出一个列表和访问方式，大家可以自行体验。

• 智普清言 – https://chatglm.cn
• 通义千问 – https://tongyi.aliyun.com/qianwen/
• 文心一言 – https://yiyan.baidu.com/welcome
• 星火大模型 – https://xinghuo.xfyun.cn
• kimi – https://kimi.moonshot.cn/

4. 小结

随着时间的推移，越来越多的公司和开源项目加入了大语言模型的竞争，使得互联网上的大模型服务变得百花齐放。本文列举了一些免费的在线大语言模型服务供读者参考。

首先介绍了大语言模型聚合平台，如poe.com和you.com，它们集成了多种专有模型和开源模型，可以满足日常工作需求。然后文章还提到了一些仅聚合开源模型的平台，如perplexity labs、huggingface chat、together.ai和groq cloud，它们适合体验、对比和使用开源模型。

接下来是独立的大语言模型服务，包括一些知名公司和项目。我们提到了OpenAI的ChatGPT，提供免费的在线使用；Google gemini，与OpenAI能力逐渐接近；Anthropic的Claude，提供免费的sonnet和haiku服务；Meta的Llama，作为开源界的核心力量；以及Mistral AI的在线免费体验服务。

对于国内大模型，笔者使用较少，这里仅提供列表和链接。

如果你要是拥有一个Google gmail账号，无论是前面提到的聚合平台，还是专有大模型服务(国内大模型服务除外)，基本都可以sign with google account快速注册和登录到平台并开启大模型体验之旅。

Gopher部落知识星球在2024年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。同时，我们也会加强代码质量和最佳实践的分享，包括如何编写简洁、可读、可测试的Go代码。此外，我们还会加强星友之间的交流和互动。欢迎大家踊跃提问，分享心得，讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落，享受coding的快乐! 欢迎大家踊跃加入！

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite
• Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

本文永久链接 – https://tonybai.com/2023/12/31/the-2023-review-of-go-programming-language

时光荏苒，转眼间已经是2023年的最后一天了。《2022年Go语言盘点：泛型落地，无趣很好，稳定为王》仿佛就写在昨天。

回首这一年，全球彻底从新冠大流行中得以复苏，Go语言也不例外，最直观的表现就是全球各地的GopherCon技术大会或小型Meetup都纷纷从停办/线上的状态来到了线下，并获得Gopher们的热烈欢迎和踊跃参与，比如下图中的GopherCon、GopherCon UK、GopherCon Europe、GopherCon Australia、Golab等。

尤其值得一提的是我们本土最大的Gopher技术大会GopherChina 2023，今年为了满足不同地域Gopher的需求，GoCN社区在6月和11月分别在北京和上海举办了两次GopherChina大会，这也是历史首次。

Go语言团队的大神们也开始重新“乐此不疲”地参与到上述这些大会中，以推进全球Go社区与生态的建设。就连已经退居二线的Go语言之父Rob Pike也亲自“现身说法”，在年底的GopherCon Australia 2023上发表了“What We Got Right, What We Got Wrong”的主题演讲来回顾Go诞生以来的得与失。

大神回顾一生，我们盘点一年。在这篇文章中，我就和大家一起聊聊Go在2023年的状态、所处的位置以及Go未来演进的机制与策略。

1. Go的2023

1.1 稳

一如往年，Go在2023年发布了两个大版本，分别是2023年2月份的Go 1.20和8月份的Go 1.21。

在这两个版本中，Go语法特性一如既往的求稳，除了支持切片类型到数组类型(或数组类型的指针)的类型转换，其余更是像语法的修修补补，比如：comparable“放宽”了对泛型实参的限制、unsafe包继续添加“语法糖”、增加min、max和clear预定义函数、增强type inference能力等。

这些并不会让Gopher感到“意外”，因为这与Russ Cox在2022年宣称的“Go is boring”的精神是一脉相承的。

不过，除了Go语法特性变化方面的“寡淡”之外，Go在其他方面还是求新和求变的，接下来我们先来看看Go是如何求新的。

注：求新与求变可能存在交集的地方，边界可能也有一定模糊性，也存在相互促进的情况，希望大家阅读下面内容时不要吹毛求疵:)。

1.2 求新

Go在语法特性求稳的同时，在编译器、工具链、运行时以及标准库等方面都在努力优化和打磨，旨在进一步提升Go兼具的生产力与运行时效率，其中很多优化和打磨的措施不乏新颖。

Go 1.20版本中首次引入的PGO(profile-guided optimization)技术预览版，到Go 1.21版本变为默认开启，Go官方给出的PGO优化的效果数据是：PGO优化带来的性能提升一般是2%~7%，而在最新的Go 1.22rc1中，这个数字已经变为2%~14%了。

在内存管理方面，Go 1.20引入了试验特性arena包，虽然它没能在Go 1.21中按时转正，如今处于proposal-hold状态，但这也算是一次在内存管理机制上的求新。

Go是一门面向软件工程的编程语言，在这一年中，Go在软件工程领域的求新例子也是不少。比如：可用于大幅简化Go项目创建的gonew工具，它支持基于go project template clone并创建一个属于你的Go项目；再比如对应用执行时的代码覆盖率的采集，可以帮助开发者更进一步了解最终可执行程序代码执行路径上的测试覆盖情况；而govulncheck工具则是Go在软件工程与供应链安全领域的求新尝试，该工具丰富了我们对Go项目进行安全漏洞检查的手段。

注：关于供应链安全问题，Russ Cox近期有一个专门的Talk：Open Source Supply Chain Security at Google，感兴趣的童鞋可以学习一下。

Go始终对IT界出现的新技术、新趋势以及Go社区的新想法保持open。在WASM出现早期，Go就提供了对wasm的porting支持，如今在Go 1.21中，Go还对尚未形成最终规范的WASI(WebAssembly System Interface)提供了支持。

Go社区的反馈也是Go团队求新的来源，比如一个典型例子就是log/slog加入标准库，让Go标准库原生支持了结构化日志输出，且日志性能不输像zap这样的第三方开源log包。

Go社区也跟随Go团队的节奏，走在求新的道路上。2023年，IT界最大的事件就是以ChatGPT为代表的大语言模型的横空出世，这很可能是一个百年不遇的、对人类文明进步有着重要里程碑意义的事件。各行各业，言必称大模型，言必称AI。在传统机器学习、深度学习以及神经网络方面生态并不丰富的Go，也在尝试与大模型对接，比如：支持快速在本地启动和运行llama2、mistral 7B、codellama、vicuna等大模型的ollama开源项目在短短几个月就收获近30k个小星星的关注；再比如Gemini大模型推出后，Google一并开源了支持与Google各种大模型项目对接的Google AI Go SDK开源项目，并提供了详细的教程指导Gopher如何通过该SDK与大模型交互。

注：Google把Gemini Pro的API免费提供给个人用户了，该模型具备GPT 3.5 级别的能力，32k 上下文，38 种语言支持以及多模态支持，唯一的约束是每分钟60个请求。

在2023年第二次Go用户调查报告中，Go 开发者表示，他们对改善其编写代码的质量、可靠性和性能的人工智能/机器学习工具感兴趣，而不是编写代码的工具。一位时刻警醒、从不忙碌的专家“审阅者”可能是一种更有帮助的AI开发者辅助形式。Go官方表示了对该调查结果的重视，也许在后续的Go工具链中“AI加持”会成为常态。

1.3 求变

2023年8月，在Go 1.21版本刚刚发布后，Go官博就发布了Russ Cox编写的两篇文章：《Backward Compatibility, Go 1.21, and Go 2》和《Forward Compatibility and Toolchain Management in Go 1.21》，进一步明确了Go承诺的向后兼容的范围和方案，并第一次阐述了向前兼容性的具体方案，这两篇文章为Go语言后续的“求变”奠定了理论基础。

在向后兼容方面，从Go 1.21开始Russ Cox提出一些举措，比如：Go将扩展和规范化了GODEBUG的使用，其大致思路如下：

• 对于每个在Go1兼容性承诺范围内的且可能会破坏(break)现有代码的新特性/新改变(比如：panic(nil)语义的改变)加入时，Go会向GODEBUG设置
  中添加一个新选项(比如GODEBUG=panicnil=1)，以保留采用原语义进行编译的兼容能力；
• GODEBUG中新增的选项将至少保留两年(4个Go release版本)，对于一些影响重大的GODEBUG选项(比如http2client和http2server)，保留的时间可能更长，甚至一直保留；
• GODEBUG的选项设置与go.mod的go version是匹配的。例如，即便你现在的工具链是Go 1.21，如果go.mod中的go version为1.20，那么GODEBUG控制的新特性语义将不起作用，依旧保持Go 1.20时的行为。除非你将go.mod中的go version升级为go 1.21.0；
• 在Go 1.21及以后版本中，除了可以使用像GODEBUG=panicnil=1的环境变量恢复原先语义外，还可以在main包中使用//go:debug指示符。

在向前兼容方面，Russ Cox提出的方案有些复杂难懂，这里就不赘述了，感兴趣的童鞋可以阅读一下我之前的文章《聊聊Go语言的向前兼容性和toolchain规则》了解更多细节。

1.3.1 语法填坑

在Go的诸多“求变”中，影响最大的还是对已有语法坑的“修正”，这些“填坑”工作或多或少都会对存量代码带去影响，甚至是break change，Go社区的反对声音也是不少。但无论怎样，这些工作已经在Go 1.21版本拉开帷幕了。比如：改变panic(nil)的语义以及对循环变量语义的变更，大家可以在《Go 1.21中值得关注的几个变化》一文中了解更多细节。

对现有语法坑的修正也进一步促进了“求新”，比如在修正loopvar语义的同时，for range支持对更多类型表达式的迭代也在进行中，比如Go 1.22中，for range将支持迭代整型表达式，并以试验特性提供了对函数迭代器的支持。

1.3.2 标准库v2示范

Go号称是“自带电池”的语言，其高质量的标准库得到了广大Gopher的欢迎。Go团队也一直努力推进Go标准库功能的丰富性，比如：Go 1.22中对http.ServeMux功能进行了增强，使其像第三方的gorilla/mux那样增加对带有通配符路由的匹配。

Go 1.22中，标准库还首次出现了v2版本包：math/rand/v2，这为后续标准库的vN方式演进提供了示范，从Go团队的官方issue、discussion中了解到，后续如sync/v2、encoding/json/v2等已经列上日程了。

2. Go所处的位置

很多人关注Go当前的状态：国内大厂用的多么？小厂是不是也在广泛采纳。这些问题我在往年的Go语言盘点时也都做过梳理，今年就不再提了。没有哪个大厂在广泛采用一门语言后，会在一年内全部推翻重写的；小厂对Go的采纳也是有惯性的。

今年先从我的两个意外“收获”开始。

2.1 两个意外的“收获”

2023年10月中旬，世界知名电动车厂商Tesla发布了新版fleet API和vehicle command SDK，鉴于本人也在智能网联汽车行业内打拼，于是对Tesla的此次发布做了一些深入了解。在Tesla的github主页上我赫然发现：Go是目前Tesla开源项目的第二大语言。

相对于传统的主机厂(车厂)，Telsa算是比较开放的了。开放包含两个含义，一是将车端能力的开放，二是项目的开源。就目前了解到，国内主机厂还鲜有将车端能力开放出来的，开源就更是鲜见。但Tesla在这两方面都做到了，既开放了车端API，又做了针对性的开源，虽然目前其开源项目并不多。以前Tesla涉及到云端服务的项目多用Ruby，但从2022年开始，Go语言的使用逐渐增多，包括前面提到的Fleet API的Fleet Telemetry的参考server实现以及Tesla车辆远控SDK。

我们再来看看Apache基金会。众所周知，Apache基金会的开源项目多以Java语言为主，但一次偶然的机会翻看Apache基金会的github项目主页，我发现Go语言在Apache开源项目中已经悄悄地跻身到第五名，如果仅算后端语言的话，Go排名第三，仅次于Java和Python。

并且，Apache基金会下面的Go项目实际也不少，大家可以通过https://github.com/orgs/apache/repositories?language=go&type=all查询。其中还不乏优秀之作，比如：构建Q&A知识系统的answer、Apache Dubbo的go实现dubbo-go、CDN实现trafficcontrol、Kubernetes原生的轻量级企业应用集成框架Camel K、Apache Arrow的Go实现以及针对开发过程的聚合数据平台devlake等。

我们知道：Apache项目在企业级应用和平台方面具有广泛的应用，从Go语言在Apache基金会项目中的使用比例的提升现象来看，Go在企业应用市场中的普及度和受欢迎程度确实有所增长。

2.2 Go语言排名

编程语言之间的竞争与争议，通常被称为“编程语言战争”(programming language war)，它其实反映了不同技术群体和范式之间的碰撞。这些“火药味”比较浓的语言之争通常比较主观。近10年来，业界出现了一些被广泛接受的编程语言排行榜，它们基于一些相对客观的数据来反映不同编程语言在现实开发中的真实状态。但不同编程语言排行榜都有不同的数据来源和数据模型，单一的排行榜往往是“盲人摸象”，无法反映全貌。但目前又没有一个可以让我们一窥全貌的权威排行榜。因此，要想更客观地、更全面的反映一门编程语言的实际情况，我们需要将多个排行榜参照着看。

下面我们就来看看在目前世界上著名的编程语言排行榜上，Go语言在其中的最新排名情况(请注意：各个榜单的发布时间不同，导致各榜单的数据会有一定时间差)。

2.2.1 PYPL编程语言排行榜

PYPL编程语言流行指数是通过分析语言教程在谷歌上的搜索频率而创建的。语言教程被搜索的次数越多，说明该语言越受欢迎，原始数据来自Google Trends：

PYPL编程语言排行榜，数据时间：2023.12

2.2.2 IEEE Spectrum排行榜

IEEE Spectrum排行榜是通过调查来自全球软件工程师和招聘网站的数据，统计各语言的流行度的：

IEEE Spectrum排行榜，数据时间：2023.8

2.2.3 RedMonk编程语言排行榜

RedMonk排行榜是根据GitHub和Stack Overflow这两个开发者社区上的讨论数量来推算语言的受关注度。

RedMonk编程语言排行榜，数据时间：2023.5

2.3.4 Github Octoverse

GitHub Octoverse排行榜直观反映了过去一年GitHub上各编程语言的实际使用和流行趋势，是从开源项目量的维度来衡量编程语言活跃度的。在Top 10语言榜单上，2023年Go超越Ruby第一次跻身Github Top10语言：

Github Octoverse编程语言排行榜，数据时间：2023.11

Github Octoverse编程语言排行榜，数据时间：2023.11

2.3.5 Github Language Stats(githut)

Github Language Stats是一个个人项目，它基于github公开数据，按时间、pr数量、star数量等维度对各个语言在github上的使用情况进行分析：

Githut按PR数量，数据时间：2023第三季度

Githut按Star数量，数据时间：2023第三季度

2.3.6 TIOBE编程语言排行榜

TIOBE编程语言排行榜理论上来说，是世界上最知名的编程语言排行榜，它根据各大搜索引擎编程语言相关的搜索查询量来计算一个综合指数。但这些年TIOBE榜单数据的“上蹿下跳”，让开发者对该榜单是“又爱又恨”。下面是TIOBE index 2023年12月份的榜单：

当你看到Fortran排在Go的前面，你就get到该榜单的抽风式的“不靠谱”了:)。

综合上述6个榜单，我们可以看到Go语言的2023基本处于稳定发展状态，没有“大踏步”的前进，也没有意想不到的大幅退步。

今年在国内某乎上总有一些有关“Go在国内是否已凉”的话题，从上面实际情况来看，话题中那些抹黑Go的观点可以不攻自破了。有人会说Rust的强势上升对Go会有一定冲击，这的确不可否认，就像Go当年火速蹿升给Java带去一定冲击一样，这是一门编程语言在演进阶段必会经历的过程，没有什么值得大惊小怪的。5年后，Rust可能同样也会受到来自其他语言的冲击。

Go语言未来会变得如何，关键还要看Go团队对Go未来演进方向的把握是否得当以及Go社区与生态是否给力。2023年，Go团队也明确了未来的演进机制和策略，接下来我们就来看看。

3. Go的未来演进

2023年是Go语言开源的第14个年头，Go语言早已蜕下了少年期的青涩，进入到了青年期。这意味着它拥有了越来越成熟稳定的语言特性，同时生态系统也日益丰富完善。作为一门青壮年语言，Go语言在系统设计方面展现出的高度工程化思想，使其轻松应对复杂系统的构建。以go module为主的模块化支持帮助大规模程序更加清晰化，丰富的并发控制手段使其可以处理海量请求。与此同时，Go语言生态也在蓬勃成长——各种高质量框架应运而生，无数module可复用，大量的云原生组件可供选择。这为开发者极大减轻了从零开始搭建系统的工作量。

和我们人类一样，一门语言进入青年期后的成熟特征并不能完全掩饰其未来演进的迷茫！在Ken Thompson、Rob Pike相继退休后，Russ Cox成为了Go这艘大船的“掌舵者”，Russ Cox与Go团队对编程语言的思考，对Go语言价值观的判断将直接决定Go未来的航向。

好在，在2023年的GopherCon大会上，我们得到了Russ Cox的答案：那就是基于共同目标和数据驱动的决策。这里借用Russ Cox在演讲中给出的结论来看看具体的演进驱动机制：

• 首先，Go需要不断变化，特别是随着计算世界的变化。
• 其次，任何改变的目标都是为了使Go在软件工程中变得更好，尤其是在规模化(scaling)方面。
• 第三，一旦我们确定了目标，达成共识的下一个最重要的部分是拥有共享数据来做出决策。
• 第四，Go工具链遥测是增补我们现有调查和代码分析数据的重要数据来源。

综上来看，Go团队要“拥抱变化”，但不能“无头苍蝇”一样的胡乱改变，而是严谨地基于广泛的数据反馈，包括来自用户调查、vscode插件运行的用户反馈、全年进行的研究访谈和用户体验研究等，以及来自即将加入Go工具链的可选遥测(opt-in Telemetry)功能获取到的更多真实的Go使用数据。

相信在Go工具链的可选遥测(opt-in Telemetry)功能加入后，Go团队能基于这些用户数据拿到更准确地决策依据，继续让Go这艘大船行驶在正确、光明的航向上！

4. 小结

在2023年，Go语言继续保持了其稳定性和可靠性的特点。发布了两个大版本，Go 1.20和Go 1.21，其中语法特性的改变相对较少，注重修复和优化。然而，Go语言在其他方面仍然保持着求新和求变的态势。

Go语言团队致力于优化编译器、工具链、运行时和标准库，以提升生产力和运行时效率。引入了一些新的特性和优化措施，例如PGO（profile-guided optimization）技术的引入和优化、内存管理方面的改进等。同时，Go语言在软件工程领域也进行了一些创新，如简化项目创建的gonew工具、代码覆盖率的采集工具、供应链安全领域的govulncheck工具等。

Go语言始终保持对新技术、新趋势和社区的开放姿态。在2023年，Go语言对WASM和WASI的支持得到了进一步加强。同时，Go社区也积极响应并跟随Go团队的步伐，面对IT界出现的大语言模型等新兴技术，Go社区也在不断探索和应用。

总体而言，2023年对于Go语言来说是一个稳中求新、稳中求变的年份。Go语言保持着其简洁、高效和易用的特点，同时积极适应和采纳新的技术和需求，为开发者提供更好的开发体验和工具支持。

展望未来，Go团队已经明确了更加以共识和用户数据为驱动的演进机制，保证Go的发展方向与实际需求保持同步。随着可选的工具链遥测功能加入，相信他们能基于更丰富的用户数据做出更正确、更具预见性的正确决策。

我个人依旧坚持我之前的判断：Go将进入或已处于自己的黄金5-10年。

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2023年，Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码，关注代码质量并深入理解Go核心技术，并继续加强与星友的互动。欢迎大家加入！

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite
• Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。