Flask、Jinja2、Click, 这三个名字撑起了 Python Web 生态的半壁江山, 它们的作者 Armin Ronacher 在 2025 年年中写了一篇工作手册, 里面给后端新项目的建议是: 用 Go。一个人推荐对自己阵营不利的东西, 这种证词的分量, 任何 Go 布道者都拿不到。这篇文章当天冲上 Hacker News 首页, 两百多条评论里吵得最凶的就是这一段。
文章表面是一份杂烩式的配置清单: 放开权限让 agent 不被打断地干活, 用容器隔离兜住风险; 常用操作全部做成一条命令的傻瓜工具, 响应要快, 输出少而准, 报错要让一个没有全局记忆的读者看得懂; 代码风格上选"能干活的最笨方案", 长而具体的函数名, 平铺直叙的 SQL, 权限检查就地可见。但底层只有一个思想: 技术选型从此多了一个正式维度, 机器程序员在这套栈上的犯错率和迭代速度。他叫它 agent 友好度。语言之争吵了几十年, 裁判一直是人的生产力和审美, 这是头一回有人系统地把"另一位程序员是台机器"摆上桌面。
Go 赢在哪里呢。测试快且有缓存, 语言简单少惊喜, 生态稳定不折腾, 上下文传递全是显式的。Python 输在 fixture 注入、async 迷宫、解释器启动慢, agent 在这些隐式魔法上反复跌倒。这个结论的边界要自己把牢: 他的证据全部来自本人的项目类型, 中小型服务端和命令行工具, 反对者指出模型训练数据里 Python 和 TypeScript 最多, agent 在上面表现同样出色。语言的权重, 后来社区大致的共识是低于项目结构和工具链质量。
全文最大胆的一步是给 DRY 翻案。不要重复造轮子这条铁律, 成本前提是写代码很贵; agent 把写代码的边际成本压到近零, 依赖的成本 (供应链风险、升级负担) 却一分没降, 所以天平应该向"生成代码"倾斜。这是一次典型的参数变了就重推结论的推理, 我喜欢这个思路, 但他只算了半本账: 依赖库有社区审计、漏洞通报、补丁分发, agent 生成的私有轮子什么都没有, 有漏洞就静默躺在项目里永不更新。我的取舍是分场景, 几百行能写完的小工具可以生成然后纳入自己的测试; 密码学、解析器这类高危轮子, 继续用成熟依赖。
比起任何具体建议, 这篇文章最值钱的是一个复利判断: 工具链速度在 agent 的循环里被反复乘上去, 把测试从四十秒压到四秒, 对生产力的提升可能大于把模型换贵一档。他自己就只用便宜的模型干活。这句话对省钱和提效同时成立, 是我读完之后第一个想去执行的动作。
The dumbest possible thing that will work. (能干活的最笨方案。)
出自 Armin Ronacher, Agentic Coding Recommendations
还有一个细节让这篇手册比同类内容可信: 他在开头就声明这些建议会快速过时, 结尾主动把速朽的和长寿的分开, 工具名会换, 四条原则会留, 简单、稳定、可观测、可并行。一个半月后他又发了一篇文章公开盘点哪些做法失效了。事后看, 快测试、清晰报错、环境隔离、并行工作区, 这些主张后来成了各家工具的官方最佳实践, 他预言的"过时"只应验在工具名上。
我的收尾判断: 这篇文章可以当一份体检表用。拿自己的项目过一遍, 测试一轮要多久, 报错能不能独立看懂, 有多少隐式魔法, 每一项都是效率的直接乘数。机器站在了显式、简单、少魔法这一边, 而这套审美本来就该赢, agent 只是替它提供了新论据。
原文: Agentic Coding Recommendations, 作者 Armin Ronacher, 发布于 2025-06