Python - Tony Bai

本文永久链接 – https://tonybai.com/2026/02/01/go-rewrite-python-gateway-10x-performance-career-nightmare

大家好，我是Tony Bai。

“如果你没有坏，就不要修它。” (If it ain’t broke, don’t fix it.)

这句老生常谈的工程谚语，最近在 r/golang 社区的一次热议中再次得到了血淋淋的验证。

一位开发者分享了他即使成功将一个 Python 服务重写为 Go，并取得了显著的性能提升，却依然感到挫败和后悔的经历。

你可以将其看成是一个关于 Go vs Python 的技术故事，但在我眼中这更像是一堂关于技术决策、团队协作和职场生存的必修课。

故事：一场“完美”的技术胜利

故事的开端听起来像是一个典型的技术爽文。

作者说服了管理层，让他将现有的 API 网关从 Python/Flask 重写为 Go。理由非常充分且“正确”：性能和并发。

经过两个月的努力，重写非常成功：

吞吐量提升 10 倍。
内存占用减少到原来的 1/3。
部署时间从分钟级缩短到秒级。

从技术指标上看，这是一场完胜。Go 语言在这个场景下再次证明了其在云原生和高并发领域的统治力。

反转：一场“无感”的商业失败

然而，当新系统上线后，现实给了作者一记重拳。

用户感知到了什么？
Absolutely nothing.（完全没有。）

响应时间从 45ms 降到了 38ms。这 7ms 的提升，除了作者盯着 Grafana 监控面板自我陶醉外，没有任何用户能察觉到区别。

团队感知到了什么？

巨大的风险和负担。

原来的 Python 版本虽然性能稍逊，但完全能扛住现有的负载，而且团队所有人都知道如何维护它。现在，系统变成了一个只有作者一人能懂的 Go 服务。

结果就是：作者成为了唯一的维护者（Single Point of Failure），任何报警都只能找他，哪怕是在半夜或周末。

社区的“毒舌”与洞见

这篇帖子引发了数百条评论，虽然有些评论非常“毒舌”，但其中蕴含的工程智慧却发人深省。

技术正确 ≠ 商业价值

正如一位开发者指出的：“你花了公司两个月的薪水和机会成本，解决了一个并不存在的问题。”

在商业环境中，技术是手段，不是目的。如果性能提升不能转化为用户体验的改善（如更流畅的交互）或成本的显著降低（如服务器费用减半），那么这种优化就是没有商业价值的。

“简历驱动开发” (Resume-Driven Development)

不少人犀利地指出，这种重构往往是出自开发者的私心——为了学习新技术、为了给简历镀金。

“这就是为什么我不想让程序员做商业决策。他们会为了微秒级的性能提升，制造出一系列未来的维护挑战。”

团队同质性的重要性

在一个 Python 团队中引入 Go，打破了技术栈的同质性。这不仅增加了维护成本，还降低了团队的“巴士系数”（Bus Factor）。

“有时候，最好的技术选择，就是你团队已经掌握的那一个。”

注：巴士系数（Bus Factor）是一个用于衡量团队或项目中关键人员的依赖程度的指标。它的核心概念是，如果某些关键成员（例如开发人员、设计师或管理人员）因意外（如被公交车撞到）而无法继续工作，项目仍能以多大程度上保持运作。

Go 的正确打开方式

那么，这是否意味着我们在 Python/Java/Node 团队中就不能引入 Go 了？当然不是。但需要满足特定的前提：

痛点必须足够痛：现有的技术栈确实无法支撑业务发展（如严重的性能瓶颈、不可接受的延迟）。
团队共识：重写不应该是个人的“独角戏”，而必须是团队的战略决策。至少要有 2-3 人愿意学习并维护新语言。
渐进式引入：不要一上来就重写核心网关，可以从边缘服务或工具链开始，逐步培养团队的 Go 技能。

小结：成熟工程师的标志

这个故事告诉我们，成为一名 Senior 工程师，不仅仅意味着写出更快的代码，更意味着懂得何时不写代码。

Go 是一把锋利的“屠龙刀”，但如果你的面前并没有龙，用它来切菜，可能不仅切不好，还会伤到自己。

下次当你想要重写一个服务时，请先问自己三个问题：

它真的坏了吗？
这能为公司省钱或赚钱吗？
如果我离职了，谁来维护它？

如果答案不确定，或许最好的选择是——Don’t fix what’s not broke.

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

你的“重构”悔恨录

“重写”是每个程序员都曾有过的冲动。在你的职业生涯中，是否也曾因为执着于某种“新技术”或“极致性能”，而给团队带来了意想不到的麻烦？或者，你见过哪些典型的“简历驱动开发”案例？

欢迎在评论区分享你的故事！让我们在别人的教训中，学会做更成熟的决策。

如果这篇文章让你停下来思考了 30 秒，别忘了点个【赞】和【在看】，并转发给那个正准备“大干一场”的同事！

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

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

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

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2026/01/20/ai-and-go-opportunities-and-challenges

大家好，我是Tony Bai。

在 AI 的滔天巨浪面前，每一位 Go 开发者心中或许都曾闪过一丝不安：Python 似乎统治了一切，我的 Go 语言技能树还值钱吗？AI 会取代我写代码吗？我该如何在这个喧嚣的时代保持清醒？

在 GopherCon 2025 的压轴圆桌会议上，一场名为“AI 与 Go：机遇与挑战”的深度对话给出了答案。

嘉宾阵容堪称豪华(从左二到右分别是)：

Ian Cottrell: Google工程师，现从事 AI Agent 开发
Katie Hawkman: 前 Go 团队成员，现 Mercari 平台工程师
David Soria Parra: Anthropic 技术专家，MCP (Model Context Protocol) 联合创始人
Jaana Dogan: 前 Go团队成员，Google Gemini Serving 团队专家, adk-go项目成员
Samir Ajmani: Google Go 团队工程总监

他们没有贩卖焦虑，也没有盲目吹捧，而是用冷静、务实的工程师视角，为我们描绘了 Go 在 AI 时代的真实版图。

Go 的新机遇：AI 基础设施的“基石”

当被问及“Go 能提供什么 Python以及其他编程语言无法提供的价值”时，嘉宾们的回答出奇一致：生产级的可靠性与并发能力。

Samir Ajmani 提出了一个精准的洞察：Go 的崛起得益于云原生时代的爆发，而 AI 正在带来“第二次云原生机遇”。

现状：目前的 AI/ML 基础设施大量依赖 Python，适合快速原型和实验。
痛点：当这些原型需要走向大规模生产，需要处理高并发推理、构建复杂的 Agent 编排、或者实现像 MCP (Model Context Protocol) 这样需要高度可靠性的协议时，Python 的动态特性和性能瓶颈开始显现。
Go 的位置：Go 语言天生的高并发模型、静态类型安全、以及构建大规模分布式系统的基因，使其成为构建 AI 生产基础设施（Serving, Orchestration, Agent Protocols）的完美选择。

Katie 分享了一个真实案例：她在黑客马拉松中选择用 Go 而非 TypeScript 来编写 MCP Server，因为 Go 的代码在处理复杂协议逻辑时更易读、更易维护。

David(Anthropic)就个人经验和观察，认为Go 是目前AI最擅长生成的语言代码之一，这也是Go的一大优势！

Python 也许是 AI 的“训练语言”，但 Go 有望成为 AI 的“运行语言”。

职业焦虑：AI 会取代我们吗？

面对“AI 取代程序员”的言论，嘉宾们的态度是——“这只是另一种生产力工具，它改变了工作方式，但提升了人的价值。”

Samir Ajmani：未来的软件构建方式可能会变成“组件组装”。但这依然需要懂系统设计、安全性和可靠性的专业人士来构建这些高质量的组件。对于初级开发者，门槛确实变高了（简单的代码生成不再是技能壁垒），但对于具备系统思维的工程师，这是最好的时代。
Jaana Dogan (Google)：她提出了一个令人耳目一新的视角——“代码写得快了，不仅没让我失业，反而让我更强大了。” AI 极大地缩短了编码时间，这意味着工程师可以更快地去“连接点” (connect the dots)：将孤立的组件串联成系统，与更多人协作，验证更多设计想法。个人的产出能力被放大了，你不再是一个单纯的“螺丝钉制造者”，而更容易成为一名“系统架构师”。
David Suryapara (Anthropic)：作为一名非 Go 核心开发者，David 的观察更为冷静。他认为，纯粹的“代码编写”技能（例如熟练背诵 API、手写 CSS）确实面临贬值。但核心工程能力——如拆解复杂需求、设计分布式系统、处理边缘情况——将变得前所未有的重要。 AI 抬高了入行的地板，但也让那些拥有深厚解决问题能力的工程师变得更加不可替代。
Katie Hawkman：写代码从来不是工作中“最难”的部分，而是“最有趣”的部分。真正的难点在于——如何渐进式交付？如何设计良好的 UX？如何优化系统性能？这些是 AI 短期内无法完全替代的工程智慧。
Ian Cottrell：我有 40 年的开发经验，每一次生产力工具的飞跃（从汇编到 C，从 IDE 到自动补全），人们都说“不需要程序员了”。结果呢？我们的需求量反而更大了。我们只是在提升期望值，尝试解决更难的问题。

不要试图成为每一个 AI 工具的专家。选择一个工具（如 Cursor 或 Claude Code），深入掌握它，让它服务于你的工作流，而不是被它淹没。

理性审视：算力、能源与负责任的 AI

主持人提出了一个尖锐的问题：在区块链曾因高能耗饱受诟病之后，我们该如何理性看待 AI 巨大的算力和能源消耗？作为开发者，我们该如何权衡使用 AI 工具的成本？

嘉宾们的回答，揭示了工程优化在 AI 时代的巨大潜力：

Samir Ajmani (Google) 分享了一个令人振奋的实验：Go 团队尝试将 MCP 支持集成到 Go 语言服务器 (LSP) 中。结果发现，当 AI 能够直接调用精确的工具（Tools）而不是在那“空想”时，任务完成率提高了，延迟降低了，最重要的是——Token 消耗量减少了近 50%。 这意味着，通过优秀的工程工具（如 Go），我们可以显著降低 AI 的运行成本和碳排放。
Jaana Dogan (Google) 认为我们正处于优化的早期阶段。就像当年的数据库优化一样，模型推理 (Inference) 的效率优化将是接下来的重头戏。缓存、量化、专用硬件，这些工程手段将大幅抵消模型增长带来的成本。
David Suryapara (Anthropic) 提到了“小模型与蒸馏”。我们不需要每次都动用最昂贵、最慢的“超大模型”来解决所有问题。未来，针对特定领域（如代码生成）进行微调和蒸馏的小模型，将在效能和成本之间找到完美的平衡点。

不要盲目堆砌算力。“负责任的 AI”不仅是道德要求，更是工程优化的必然方向。 用更少的 Token 做更多的事，这本身就是 Go 开发者擅长的“资源优化”技能的延伸。

务实派的生存指南：过滤噪音，回归本质

在 AI 炒作的喧嚣中，如何保持清醒？

从“小”开始：不要被“AGI 即将到来”的宏大叙事吓倒。像 Katie 建议的那样，承认自己是初学者，哪怕是 MCP 的创始人也说“现在没有所谓的专家”。放下包袱，去尝试写一个简单的 Agent，去用 Go 写一个 MCP Server。
关注“确定性”：Jaana 和 Ian 都提到，AI 模型本质上是概率性的（非确定性），而工程系统需要确定性。Go 语言强大的静态分析、测试工具链和类型系统，是约束 AI 幻觉、构建可靠系统的最佳防线。用 Go 的“确定性”去包裹 AI 的“不确定性”，是未来的核心工程模式之一。
解决实际问题：不要为了 AI 而 AI。如果老板让你“加点 AI 进去”，试着去寻找那些真正能通过 AI 提升效率的痛点（比如自动化文档更新、复杂日志分析），而不是生搬硬套。