Armin Ronacher —— Flask框架的创造者，Python 生态中一位标志性人物 —— 最近分享了一个让社区颇感意外的观点。他的AI创业公司代码库里，高达90%的代码由AI生成，而更关键的是，核心后端服务所用的语言并非Python。
是 Go。
这并非纸上谈兵或个人偏好，而是基于真实测试后的结论。背后的原因，也出乎很多人的第一直觉。
那场出乎意料的实验
在最近的一档播客中，Armin分享了他的发现：
“我真的做了测试……我发现AI Agent在Go上的表现明显比在Python上更好。”
说话者的身份让这句话格外有分量。这不是来自Go布道师的拉踩，而是来自一位深度参与并塑造了Python Web生态的资深开发者。他的观点并非反Python宣言。
Armin坦言他依然在用Python处理机器学习、数据分析和基础设施管理任务。他甚至承认：“不管你喜不喜欢，Python都会是你技术栈的一部分。”
但问题是，当他为公司选择承载核心业务逻辑的后端语言时，他选择了Go。其中一个决定性因素，正是 AI生成代码的质量。
这件事的关键之处不在于“Go打败了Python”，而在于：技术选型的评估维度已经悄然改变。
为什么AI“更懂”Go，而不是Python？
答案来自一个看似简单却致命的观察。Armin的原话是：
“因为这些抽象都很薄，AI就能更好地理解代码。”
这句话点中了AI编码时代的一个核心命门。
Go的特点是什么？
Go几乎没有“魔法”。没有复杂的元类、层层嵌套的装饰器、深度的继承树，或是难以捉摸的动态元编程。
AI阅读Go代码时，看到的东西基本就是系统实际运行的样子：
- 类型系统是显式的
- 错误处理模式稳定（尽管有些啰嗦）
- struct的方法一目了然
- 接口满足是隐式的，无需额外注册或神秘配置
Armin特别提到了Go的接口机制：
“Go有一种概念……有点像Python里的duck typing。如果某个东西有 doSomething 这个方法，那么它就满足了需要 doSomething 的接口。AI不需要理解复杂的类型层级，也不需要理解继承。它只需要知道：如果这个东西在那儿，而且它可以调用，那它大概率就能调。”
这揭示了一个现实：AI并不擅长推理深层、隐式、跨框架的抽象关系，它更擅长处理显式、直接、结构稳定的代码。 而Go恰好就是这种语言。
结果便是：AI生成的优质Go代码，与人类工程师手写的优质Go代码，风格上往往高度相似。 两者之间的差距很小，这才是其高效的关键。
Python给AI带来的“隐藏税”
很多人容易得出“Python不适合AI写代码”的粗暴结论，但这并不准确。Python的问题不在于性能或能力，而在于：生态太碎片化，编码风格太多样，实现路径太繁杂。
Armin认为，这种碎片化给AI Agent带来了三重摩擦。
1. 生态多元，写法不一
他说得很直接：
“Django的人写代码和Flask的人不一样，和机器学习领域的人也不一样。所以AI很难区分。它接触到的是一大堆彼此竞争的Python风格。”
换句话说，Python的自由度对人类是生态繁荣，对AI却常常是上下文噪音。如果约束不清，AI可能会在同一个项目中混合Django、FastAPI和数据科学脚本等多种风格，导致代码拼凑感强，缺乏一致性。对人类而言这是多样性，对AI而言则是上下文污染。
2. 类型系统“有，但不统一”
Python虽有类型提示，但其工具链的约束和执行标准并不统一。Armin提到了 mypy、微软的 pyright、Astral的 ty，它们的行为存在差异。
这会让AI困惑：
- 项目到底遵循哪套类型规则？
- 某个类型提示是建议还是强约束？
- 某个类型检查报错在当前环境下是否算问题？
更麻烦的是，AI有时甚至无法确定项目正在使用哪个类型检查器。这就像让实习生在不了解具体规范的情况下工作，处处碰壁。
3. 打包和依赖管理过于混乱
Armin对此颇感无奈：
“有时候它还是会想用pip，哪怕我明明已经告诉它用uv，只是因为训练语料里pip实在太多了。”
Python的依赖管理方案繁多：pip, uv, poetry, conda, pipenv, hatch，以及各种历史遗留方案。经验丰富的人类开发者可以明确指定“本项目就用uv”，但AI的“大脑”里充斥着海量的历史语料，很容易被旧世界的统计概率带偏。
Armin对此有一句精辟的总结：
“Python有七种不同的打包方案，这个代价其实很高。很多年里我们总说，‘你只要把这些读明白，这就是你的问题。’但这其实不只是你的问题——这是整个生态的问题。它就像是整个生态在持续缴的一种税。”
过去，这份税由人类开发者承担；现在，人工智能 也要缴纳。而AI交税的方式，就是产生更多的误判、需要更多的纠偏和来回拉扯。
“无限实习生传送带”的绝妙比喻
在Armin的分享中，最具启发性的莫过于这个归功于其同事Lukasz的比喻：
AI Agent不是那种会逐渐成长的实习生，它更像一条无限的实习生传送带。
每次来的都是一个全新的实习生，每次都是从零开始。它不会将经验积累到下一个实例中。Armin解释说：
“不停换新实习生的一个好处是，你可以把一个虚拟的人反复从零扔进问题里。它从来没见过这个项目。于是你就能衡量：一个全新的实习生，在这个项目上到底能工作得多好？”
这个视角一旦建立，项目所在生态的可进入性就被无限放大并暴露出来。
Go为何占优？
因为一个新的Go“实习生”进场时，面对的是：
- 相对统一的项目结构
- 非常稳定的错误处理模式
- 足够显式的类型规则
- 主流且单一的依赖管理思路（Go Modules）
因此，它可以几乎立刻开始有效工作。
Python为何更容易卡壳？
因为一个新的Python“实习生”进场后，首先需要应对一连串与业务无关但必须做出的决策：
- 用pip、uv、poetry还是conda？
- 这是Django、Flask还是FastAPI项目？
- 代码是async还是sync风格？
- 类型检查用mypy还是pyright？
- 用的是Pydantic v1还是v2？
这些并非业务核心，但AI会在此持续消耗其推理预算。从工程角度看，这就是认知摩擦。过去人类可以适应，但现在AI的参与将这种摩擦量化为了真实的生产力损失。
一场“反抽象”的逆袭
这场讨论背后有一个更深层的原则。Armin提到了Flickr和Slack前CTO Cal Henderson的观点：直接写SQL，不要过度依赖ORM。 因为ORM终将遇到边界，届时仍需回归SQL，不如早点面对现实。
在过去，这个观点并不太受欢迎，因为开发者天然喜欢抽象（ORM比SQL好写，框架魔法比底层细节省心）。但AI的出现改写了这个等式。Armin说得直白：
“没人喜欢写SQL，所以我们才有ORM。但现在如果Agent能替我写SQL，那么SQL的成本就没那么高了。”
这意味着：AI降低了编写低抽象代码的成本，但并未同比例降低理解高抽象代码的成本。
简而言之：
- 以前我们使用高抽象，是为了让人类写得更省事。
- 现在AI能帮忙写出底层代码。
- 那么，“为书写便利而增加抽象”的价值就被相对削弱了。
这也解释了为何Go这种曾被吐槽“太简单”、“不够抽象”的语言，在AI时代反而显得顺手。不是它突然变强了，而是时代的约束条件变了。从追求“人类写得爽”，转向考虑“AI理解得顺不顺”。
实际观察：这并非空谈
根据原文作者的补充观察，在实际使用中，这一结论得到了印证。
在Go项目中使用Claude Code等工具时，生成的代码通常第一次就接近可用，即使有问题，严谨的编译器也能快速揪出剩余瑕疵。整个反馈回路紧密高效：写 → 编译 → 修正类型错误 → 完成。
而在Python项目中，情况则可能变为：
- “不，这里用uv，不要用pip。”
- “不，这个项目是pydantic v2，不是v1。”
- “不，不要在这里加async，我们这套代码不是async风格。”
这些纠正看似都是小问题，但积少成多便形成了显著的摩擦成本。这并非Python语言的原罪，更像是一个历经几十年自然生长形成的丰富生态，在AI时代所暴露出的另一面。对人类是成熟与多元，对AI则是规则的不确定性。
这对你的技术栈意味着什么？
Armin的决策逻辑值得拆解：
Python依然不可替代
在机器学习/数据科学、数据处理、特定基础设施任务等领域，Python的地位依然稳固。因此，无需轻言“Python完了”，那既不现实也不专业。
对于核心后端服务，Go的优势被放大
尤其是对依赖AI生成代码的创业团队而言，Go的简单性直接转化为AI更高的生产率和更少的引导摩擦。这是效率问题，而非情怀。
Rust仍有其定位，但不普适
Armin提到Rust适合“Rust形状的问题”，如二进制处理、数据库、负载均衡器、高性能Python扩展等。但其编译速度和所有权模型在快速迭代场景中仍会带来摩擦，无需神化任何语言。
AI代码生成质量已成为正式选型指标
这一点最值得技术负责人警觉。如果你的“无限实习生军团”在某种语言中的效率能持续高出30%，这并非一次性收益，而是会随着时间产生复利效应。节省的引导成本、避免的风格分裂、减少的返工，累积起来便是巨大的组织效率差距。这已从“编码偏好”升级为组织效率问题。
更大的图景：语言选型标准已变
Armin的观点有趣之处在于，他并非在传教。他没有贬低Python，也没有鼓吹Go无敌。他仍在写Python，也计划通过PyO3引入Rust，前端照样用TypeScript。
他的核心观点其实很克制：重点不是Go是不是‘最好’的语言，而是选语言的标准已经发生了根本变化。
在非AI时代，我们主要优化：
而在AI时代，我们不得不越来越多地优化：
- AI能否轻松理解
- 能否稳定生成符合预期的代码
- 能否快速验证和迭代
- 能否减少不必要的弯路
Go的设计初衷并非“对LLM友好”，但其哲学——简单、显式、低抽象——阴差阳错地使其成为了当前最适合与AI协作的语言之一。这颇具讽刺意味，也极具启发性：那些曾被嘲笑“太土”、“不够聪明”的设计，在AI时代反而成了高级的工程友好性。
最后
AI革命不仅是模型能力的问题，更是一个生态能否让代码生成变得可靠的问题。而所有工程师都知道，可靠性才是将产品成功送上线的最终保障。
编码这件事，正从“谁写得更炫酷”转向“谁能被人和机器共同稳定地维护”。从这个角度看，Go的“胜利”，未必源于它比Python更强大，更像是它更早地拥抱了一个朴素而残酷的真相：真正大规模可用的系统，往往不是建立在聪明的“魔法”之上，而是建立在足够直接、足够透明的规则之上。
而对此，AI比人类更加敏感。这场由开发者社区领袖的实践所引发的讨论，也值得每一位技术决策者在云栈社区这样的平台上深入思考和交流。
发表于 昨天 03:48
|
查看: 20|
回复: 0
