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

本文永久链接 – https://tonybai.com/2025/12/25/go-next-frontier-gophercon-2025

大家好，我是Tony Bai。

“AI 正在重塑软件工程，但它并没有改变软件工程的本质。”

在 GopherCon 2025 上，Go 语言产品负责人 Cameron Balahan 发表了一场题为《Go 的下一个前沿领域》的主题演讲，重点关注了AI 时代的软件工程这个重要的主题。在这个充满焦虑与炒作的时代，Cameron 没有贩卖焦虑，也没有盲目追逐热点。相反，他通过一组冷静的数据和深刻的洞察，为我们描绘了一幅清晰的蓝图：Go 语言的核心原则——简单、高效、工程化——在 AI 时代不仅没有过时，反而变得比以往任何时候都更加重要。

本文将带你深入这场演讲的核心，解读 Go 团队如何看待 AI 对软件工程的冲击，以及他们正在构建什么样的未来。

AI 时代的“软件工程失衡”

Cameron 首先抛出了一个尖锐的观察：AI 的引入，打破了软件工程现有的平衡。

根据 Stack Overflow 的调查，近 60% 的开发者使用 AI 来写代码，但只有 10% 的人使用 AI 来进行部署和监控，用 AI 进行代码审查的人也仅有20%出头儿。

这就导致了一个尴尬的局面：

生产过剩：AI 大幅降低了生成代码的成本，代码量激增。
审查瓶颈：人类使用AI审查代码比例不高，而人工审查代码的速度并没有显著提升，导致开发者不得不花费更多时间在 Code Review 上。
“洗碗效应”：正如一位开发者所吐槽的：“我希望 AI 帮我洗衣服、洗碗，让我能去搞艺术。但现在是 AI 在搞艺术写代码，而我却在洗碗（修 Bug、调配置）。”

这样一来，在一个代码生成成本趋近于零的时代，代码的可读性、一致性和可维护性变得前所未有的重要。而这，恰恰是 Go 语言自诞生之日起就坚守的阵地。

Go —— 天生适合 AI 的语言

有趣的是，Go 语言的设计者们当年并没有以此为目标，但 Go 却意外地成为了最适合 LLM 生成的语言之一。

Cameron 引用了 Thomas Ptacek 的观点：

“Go 拥有恰到好处的类型安全、丰富的标准库，以及一种推崇（虽然有时显得重复）惯用语的文化。这使得 LLM 生成 Go 代码的效果极佳。”

为什么 Go 对 AI 如此友好？

强类型与静态检查：能让 AI 生成的代码在编译期就暴露大部分错误，减少运行时调试的痛苦。
标准库与惯用语：Go 社区高度统一的代码风格和丰富的标准库，为 AI 提供了高质量、一致性极强的训练语料。
工程化工具链：Go 强大的 gofmt, go vet, gopls 等工具，能帮助人类快速验证和修复 AI 生成的代码。

Go 的“简单”和“显式”，曾经被视为一种对人类的妥协，如今却成为了 AI 时代最大的资产。

破局 —— Go 团队的三大应对策略

面对 AI 带来的挑战，Go 团队并未坐视不管。Cameron 详细阐述了未来的三大战略方向。

解决“停在过去”问题 (Stuck in the Past)

LLM 是基于历史数据训练的，因此它们倾向于生成“老式”的代码（例如使用 ioutil.ReadFile 而不是 os.ReadFile）。

对策：Go 团队正在开发 Modernizers 和 Auto-Inliner 等工具，通过自动化的方式，将旧代码一键升级为使用新特性的 Modern Go 代码。这不仅帮助了开发者，也通过更新开源生态，反哺了未来的 AI 模型。

让 AI 使用 Go 工具 (MCP SDK)

AI 不应只是一个生成器，它应该成为一个能使用工具的“智能体”。

对策：Go 团队已经构建了官方的 MCP (Model Context Protocol) SDK。这将允许 AI 助手直接调用 gopls 等工具，理解项目结构、进行类型检查、甚至运行测试。想象一下，你的 AI 助手不仅能写代码，还能自己运行 go test 并修复错误！

质量信号左移

随着 AI 开始自主选择依赖库，我们需要确保它选择的是安全、可靠的库。

对策：Go 团队将把漏洞扫描、质量评分等信号，通过 MCP 等渠道直接暴露给 AI，让 AI 在写代码的第一时间就能做出明智的依赖选择。

Go 生态的“飞轮效应”

演讲的最后，Cameron 展示了一个令人振奋的“飞轮模型”：

更强的 Go 生态（高质量代码、文档、工具） -> 训练出更懂 Go 的 AI。
更懂 Go 的 AI -> 帮助开发者更高效地构建 Go 应用。
更多的 Go 应用 -> 吸引更多开发者加入社区，贡献更多开源代码。
更多开源代码 -> 进一步增强 Go 生态，回馈 AI 训练。

这个飞轮正在加速旋转。Cloudflare 的数据显示，2025 年全球 20% 的自动化 API 请求由 Go 客户端发起，而在 AI 基础设施领域，Go 更是扮演着核心角色。

小结

Cameron 用他对纽约这座城市的热爱作为比喻：“务实、真诚、充满能量”。这不仅是纽约的特质，也是 Go 社区的特质。

在 AI 时代，Go 并没有被边缘化，反而因为其坚守的工程价值观，成为了连接人类智慧与 AI 能力的坚实桥梁。未来不是 AI 取代我们，而是我们与 AI 一起，用 Go 构建出更伟大的软件。

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

还在为“复制粘贴喂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/24/bash-vs-go-10x-code-100x-maintainability

大家好，我是Tony Bai。

“Bash 是一种很棒的胶水语言，但 Go 是更好的胶水。”

在日常开发中，我们经常会写一些 Bash 脚本来处理本地环境配置、启动 Docker 容器、同步密钥等琐碎任务。起初，它们只是几行简单的命令；但随着时间推移，它们逐渐膨胀成包含数百行 jq、sed、awk 的怪物，充斥着针对 macOS 和 Linux 的条件分支，以及“千万别动这行代码”的注释。

近日，一位开发者分享了他用 Go 重写这些 Bash 脚本的经历，引发了一场Go社区的关于工程可维护性与“胶水代码”治理的深度探讨。

在本文中，我们将跟随这位开发者的视角，深入剖析这次从脚本到工程的“降熵”之旅，并探讨在 AI 辅助编程日益普及的今天，这一选择背后的新逻辑。

Bash 脚本的“熵增”之路

许多团队的本地开发环境脚本，往往始于一个简单的需求：从 AWS SSM 或 Vault 拉取密钥，生成 .env 文件，然后启动服务。

最初的 Bash 脚本可能只有 10 行。但随着需求增加，它变成了这样：

工具链依赖地狱：脚本依赖特定版本的 sed、grep 或 jq。一旦某个同事更新了系统工具，脚本就挂了。
跨平台噩梦：sed 在 macOS 和 Linux 上的行为不一致，导致脚本中充斥着 if [[ "$OS" == "darwin" ]] 这样的分支。
调试困难：当脚本出错时，你很难知道是哪一行管道（pipe）出了问题，也没有类型检查来帮你发现潜在错误。

正如评论区一位开发者所言：“Bash 脚本就像是一堆没有明确所有权的‘杂物’。每个人都在上面打补丁，直到它变成一个没人敢碰的定时炸弹。”

Go 作为“强力胶水”的优势

原作者将这堆复杂的 Bash 逻辑重构为一个名为 envmap 的小型 Go CLI 工具。虽然代码行数可能增加了（Go 确实比 Bash 繁琐），但他收获了工程质量的质变：

结构化配置与类型安全

不再有脆弱的字符串解析。配置被定义为强类型的 struct，编译器会帮你检查拼写错误和类型不匹配。

// Bash: 祈祷这个字符串解析是对的...
// Go: 编译器保证它是对的
type Config struct {
    Env      string json:"env"
    Region   string json:"region"
    UseVault bool   json:"use_vault"
}

接口抽象与可测试性

原作者定义了一个 Provider 接口来抽象不同的密钥后端（AWS SSM, Vault, 本地文件）。这不仅让代码结构清晰，更重要的是，它变得可测试了。你可以轻松编写单元测试来验证逻辑，而无需真的连接到 AWS。

type Provider interface {
    Get(ctx context.Context, key string) (string, error)
    // ...
}

跨平台的一致性

Go 编译出的静态二进制文件，消除了“它在我的机器上能跑”的问题。无论同事使用 macOS、Linux 还是 Windows，他们运行的都是相同的逻辑，不再受系统自带 Shell 工具版本的影响。

社区的思辨——“杀鸡用牛刀”吗？

这场重构也引发了激烈的讨论。有开发者质疑：用 Go 写脚本是不是太重了？Python 或 TypeScript 岂不是更好的替代品？甚至，为什么不直接用 Makefile？

反方观点：复杂度的转移

“代码更多了”：Go 的 verbose（繁琐）是公认的。简单的 cp a b 在 Go 中需要写不少代码。
“编译步骤”：虽然 go run很快，但毕竟多了一个编译环节。

正方观点：维护性的胜利

“长期收益”：一位开发者分享了他将 40k 行 Bash/Perl 脚本重构为 10k 行 Go 代码的经历。虽然初期投入大，但获得了测试覆盖、文档化和零依赖部署的巨大收益。
“显式契约”：Bash 脚本之间往往通过不稳定的文本流（stdout/stdin）通信，极其脆弱。而 Go 代码之间通过明确的接口和模块调用通信，更加稳健。

正如一位评论者总结的：“如果你只是写一个 10 行的脚本，Bash 是完美的。但如果你的脚本开始需要处理复杂的逻辑、状态和错误，那么它就不再是一个脚本，而是一个程序。既然是程序，就应该用编写程序的语言（如 Go）来写。”

AI 时代的变量——“繁琐”不再是借口

在过去，阻碍开发者用 Go 替代 Bash 的最大阻力往往是编写效率。写一个几十行的 Go 程序来替换一行 sed 命令，听起来确实不仅“繁琐”，而且“低效”。

然而，在 AI 辅助编程（如 Copilot, Cursor, Claude Code等）普及的今天，这个天平正在发生倾斜。

AI 为 Go 支付了“样板税”

Go 语言的 verbose（繁琐）特性——显式的错误处理、结构体定义、库的引入——曾经是手写代码的负担。但在 AI 时代，这些标准化的样板代码恰恰是 LLM（大语言模型）最擅长生成的。

你只需要告诉 AI：“写一个 CLI，读取环境变量，请求 AWS SSM，如果有错误就打印红色日志。” AI 能瞬间生成 80% 的 Go 代码骨架。开发者只需专注于核心逻辑的微调。

编译器是 AI 最好的“质检员”

用 AI 生成 Bash 脚本是一场赌博。LLM 可能会编造出不存在的 awk 参数，或者写出在某些 Shell 下不兼容的语法，而这些错误往往要在运行时才能发现（甚至引发灾难性的 rm -rf）。

相比之下，用 AI 生成 Go 代码具有天然的安全屏障：

静态类型检查：如果 AI 幻觉了不存在的方法，编译器会立刻报错，而不是等到运行时崩溃。
确定性：Go 的语法规范极其严格，减少了 AI 生成“虽然能跑但很奇怪”的代码的概率。

正如原作者在回复中所承认的：“我使用了 Cursor 和 Codex，代码的复杂性主要来自业务逻辑，而非语言本身。” 在 AI 的加持下，获得一个类型安全、跨平台、易维护的 Go 二进制文件，其生产效率已经并不输给编写和调试一个脆弱的 Bash 脚本。

小结：从脚本到工程，从手写到 AI 共生

这个案例告诉我们，“胶水代码”也需要工程化治理。

当你的 Bash 脚本开始变得让你感到恐惧、难以维护时，不要犹豫，用 Go 重写它吧。虽然你会多写一些 if err != nil，但你换来的是确定性、可维护性和内心的宁静。

特别是在 AI 时代，Go 语言的“繁琐”已被智能助手和编码智能体消解，而它带来的“稳健”却愈发珍贵。Go 也许不是最简洁的胶水，但在 AI 的帮助下，它绝对是性价比最高、最牢固的胶水。

资料链接：https://www.reddit.com/r/golang/comments/1pb7t1q/show_tell_bash_is_great_glue_go_is_better_glue/

你的“胶水”选型

“Bash 还是 Go/Python？”这可能是每个团队都会面临的选择题。在你的工作中，你会为多大规模的脚本选择改用 Go 或 Python 重写？你是否有过被复杂 Bash 脚本“坑”惨的经历？

欢迎在评论区分享你的“血泪史”或“重构心得”！ 让我们一起探讨如何让工具代码更优雅。

如果这篇文章给了你重构旧脚本的勇气，别忘了点个【赞】和【在看】，并分享给你的团队！