本文永久链接 – https://tonybai.com/2026/06/06/geohot-slams-ai-agents-as-the-most-expensive-software-disaster

大家好，我是Tony Bai。

在 AI 辅助编程疯狂席卷全球的今天，几乎每个开发者的双眼都被“效率翻倍”、“一键生成应用”的狂热口号晃得睁不开眼。大厂管理层在积极推进“全员 AI 编码”，创业者在吹嘘“氛围编码（Vibe Coding）”。

然而，就在这个全民狂欢的时刻，科技界最著名的叛逆天才、传奇黑客 George Hotz（网名 Geohot） 站了出来。他曾在 17 岁时成为全球首位解锁 iPhone 的人，随后又单枪匹马破解了 PS3，并创办了自动驾驶独角兽 Comma.ai。

最近，Geohot 在他的个人博客上发表了一篇名为《The Eternal Sloptember（永恒的垃圾九月）》的文章。在这篇文章里，他用极其冰冷且辛辣的笔触写道：

“我在这里立个 flag：在软件开发中引入 AI Agent，将是行业历史上代价最昂贵的错误之一。因为 Agent 根本不会写程序，而人们需要花越来越长的时间才能意识到这一点。”

这篇文章迅速引爆了开发者社区。在 Reddit 的 r/webdev 板块上，该话题斩获了数千个高赞，引发了无数一线架构师和开发者的强烈共鸣。

为什么这位顶级黑客会把 AI Agent 视为软件工程的毒瘤？他口中的“永恒垃圾九月”究竟隐藏着怎样可怕的行业真相？

典故溯源：什么是“永恒的垃圾九月”？

要理解 Geohot 的愤怒，我们首先需要理解他借用的一个历史梗——“永恒九月（Eternal September）”。

在互联网早期的 Usenet 时代，每年九月，都会有大批大学新生接入网络。这群新手由于不懂网络礼仪（Netiquette），会短暂地破坏原有技术社区的纯粹与优雅。但过去，老用户们只需花费一个月时间，就能将这些新生“同化”。

直到 1993 年 9 月，美国在线（AOL）向其数百万普通用户全面开放了 Usenet。新手的涌入再也没有停止过，原有社区的精致文化被彻底、永久地稀释了。从那以后，老网民将这个悲剧称为“永恒九月”。

Geohot 认为，现在的软件工程正在经历一场由 AI Agent 带来的“永恒垃圾九月（The Eternal Sloptember）”：

大模型（LLM）本质上是“高度复杂的统计模型，旨在模仿人类编程的分布”。它们吐出来的代码，在语法和格式上看起来天衣无缝，但在底层逻辑和系统架构上，往往是坏的、错的。最致命的是，这种“错”被包装得越来越隐蔽，越来越难以被察觉。

无数根本不具备底层系统思维的“调参手”，正在用 AI 疯狂向世界的开源社区和企业代码库里倾倒垃圾代码（Slop）。

“老虎机”效应：Geohot 历时半年的亲身实验

和那些只会纸上谈兵的评论家不同，Geohot 亲自用 AI 进行了长达 6 个月的深度开发实验。

他尝试用 AI Agent 编写他的深度学习框架 tinygrad 的部分代码，甚至尝试用 AI 逆向工程一块 USB 到 PCIe 的芯片。

他的实验结论可以用两个词来概括：极其失望。

“AI 确实非常擅长快速搭建一个原型（Prototype），”Geohot 承认。但当你试图去打磨它、消灭最后 5% 的边缘 Bug、让其达到工业级标准时，AI 就会变成一台“老虎机（Slot Machine）”：

[输入 Prompt] ───> 摇下老虎机摇杆 ───> [输出 buggy 代码 A]
                                             │ (发现错误，重新 Prompt)
                                             ▼
[输入修正 Prompt] ───> 再次摇下摇杆 ───> [输出稍微不同的 buggy 代码 B]

你一次次地拉下摇杆（修改 Prompt），AI 一次次给你吐出看似不同、实则依然带有微妙缺陷的代码。你感觉自己只差临门一脚，但你永远无法真正跨过那条代表“完美交付”的终点线。

“这种试错和盲目摸索（类似Ralph loop），比我自己从第一性原理出发去手写，要慢得多。”Geohot 坦言，“这完全达不到我工作过的任何一家公司的基本技术门槛。”

相比之下，他发现一个古老的自动漏洞挖掘工具 AFL（American Fuzzy Lop，模糊测试工具） 找出的代码漏洞都比大模型多。因为 AFL 是纯粹确定性的，它没有人类社交焦虑，更没有被 AI 公司的“心理战（Psyops）”所污染。

大厂病灶：为什么非技术管理层会成为“垃圾代码”的帮凶？

既然 AI Agent 开发如此低效，为什么现在各大巨头依然在疯狂推进？

Geohot 揭示了企业管理层一个极其荒谬的逻辑漏洞：对“虚假指标”的崇拜。

在大型企业中，管理层通常是非技术出身的。他们无法辨别代码的高级设计与品味，他们只能看懂看得见的指标——比如“开发进度图表”和“代码产出行数（Lines of Code, LOC）”。

“那些底层的、平庸的开发者（Bottom Performers），通过使用 AI，突然产出了 10 倍的代码量。”

管理层看到图表后大喜过望：“看啊！我们的团队多有效率！这个星期我们提交了 100 个 PR！”

但他们不知道，这多出来的 10 倍代码，全部都是无法维护的“工业垃圾（Slop）”。

这造成了极度扭曲的恶性循环：

1. 底层开发者用 AI 疯狂复制粘贴，提交海量垃圾 PR。
2. 由于大企业的反馈循环极慢、极官僚，这些黑盒垃圾代码顺利混入主干分支。
3. 认知负担转嫁：高水平的资深工程师（Top Performers）不得不花费双倍、甚至十倍的精力和认知负载（Cognitive Load），去帮这些 AI 审查代码擦屁股、Debug。

这就是为什么 Geohot 说：“AI Agent 对大企业的伤害，远比对个人或小团队的伤害要深得多。”

终局梦醒：当黑盒代码的“账单”到期

Reddit r/webdev 板块上的大批大厂老兵，用自己身边的真实惨剧，印证了 Geohot 的预言。

一位在 Fortune 100 强企业工作的开发者留言道：

他们的管理层在大会上狂热地宣称“AI 将接管一切开发，以后周五下午直接让 AI 部署 1 万行代码上线”。

“我们这些一线的工程师在下面默默看着。等这波 AI 狂热退去，账单到期，面对一堆无人能懂的‘黑盒代码（Black Boxes）’在半夜 3 点崩溃时，这些管理层会迎来极其残酷的梦醒时刻。”

目前的微服务和企业级软件，本就已经因为复杂的业务需求和拼凑的库而变得极其脆弱。一旦你引入 AI，让它用“在 StackOverflow 上抄来的、似是而非的代码”去填补这些系统的空隙，你实际上是在制造一个“无法被任何人理解、也无法被任何人重构”的终极怪胎。

“没有经验的 junior 开发者加上 AI，就是一场灾难的配方。” 另一位老兵写道。

幸存者法则：别在“AI 妄想症”中自残

面对这场由大厂和 AI 巨头联手制造的“AI 妄想症（AI Psychosis）”，真正的工程师该如何自救？

Geohot 在文章的结尾，给出了一个极具力量、甚至带有一丝英雄主义的生存守则：

“这个时代真正的故事，将是谁能在这场‘AI 妄想症’中保持清醒，不伤害到自己。”

1. 回归第一性原理（First-Principles）：放弃用 AI 盲目试错。当你遇到技术难题时，去读书，去查阅最干净、最硬核的一手的底层文档，搞清楚 CPU、内存和操作系统的底层运行机制。
2. 把 AI 降级为助手，而不是总监：Geohot 并不排斥 AI，但他对 AI 的定位极其清晰——它是一个更聪明的谷歌搜索，是一个帮你写样板代码、帮你写测试基准（Benchmarks）的高效秘书。但系统的架构设计、核心逻辑和最终决策，必须牢牢握在你自己的手里。
3. 拒绝成为平庸的羊群：当周围的人都在用 AI 批量生产垃圾代码并为此沾沾自喜时，保持克制，坚持对完美、优雅和高性能的代码品味的追求。

技术世界正在迎来一场由大量平庸代码构成的泥石流。但泥石流终会退去，那些在风暴中死守底层常识、拒绝交出思考方向盘的真正工程师，将在废墟之上，重建这个世界的数字基石。

资料链接：

• https://www.reddit.com/r/webdev/comments/1tvsfgj/im_calling_it_now_the_adoption_of_ai_agents_into/
• https://geohot.github.io/blog/jekyll/update/2026/05/24/the-eternal-sloptember.html

今日开放讨论：

你同意 Geohot 关于“AI 降低了代码质量，最终会拖垮大企业系统”的悲观论调吗？在你的团队里，是否也出现了“LOC（代码行数）增加，但系统却变得越来越像黑盒”的苗头？

欢迎在评论区分享你的一线工程经历，我们一起在这个狂热的时代保持冷峻的思考！

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

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

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

原「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/06/05/stop-writing-go-like-java-avoid-over-architecting

大家好，我是Tony Bai。

前不久，Go 语言社区 Reddit (r/golang) 上爆发了两场激烈的争论。

这两个帖子的主题直击了无数 Go 开发者的灵魂深处：

1. 我们该如何构建一个大型的 Go 模块化单体架构，而不被复杂的“架构设计”淹没？
2. 为什么现在的 Go 项目里，pkg 和 internal 目录被滥用得如此令人发指？

如果你正在维护一个中大型的 Go 后端项目，你大概率经历过这样的绝望时刻：为了加一个极其简单的业务字段，你需要穿透 handler、usecase、domain、repository、adapter 等足足五层抽象结构；你的项目根目录下躺着一个 pkg 文件夹，里面又套着 internal，代码藏在七八级目录深处。

你以为你在写出业界最高标准的“整洁架构（Clean Architecture）”，但实际上，你正在把 Go 语言写成你曾经最讨厌的“臃肿企业级 Java”。

今天，我们就来透过这层过度工程（Over-engineering）的外衣，看看顶级开发者们是如何打破这种“架构伪神话”，用最符合 Go 哲学的极简方式，构建起能支撑千万级流量的大型单体项目的。

被“标准规范”毒害的洋葱病

在一个全新的 Go 项目立项时，很多技术负责人的第一反应就是去 GitHub 搜一个叫做 golang-standards/project-layout 的高赞仓库，然后照猫画虎地建起一堆目录。

紧接着，悲剧就开始了。综合 Reddit 各位资深大佬的吐血经验，以下两大陷阱，几乎踩中了 90% 的业务团队：

陷阱 1：“死去的” pkg 与被滥用的 internal

帖子原作者一针见血地指出：pkg 目录是时代的眼泪，而 internal 正在遭受前所未有的滥用。

在早期的 GOPATH 时代，我们需要一个地方来区分业务代码和第三方包，于是有了 pkg。但在 Go Modules 已经全面普及的今天，你的代码仓库根目录本身就是一个 Module。在 root 下面再嵌套一层 pkg 纯粹是“脱裤子放屁”——它除了让你的 import 路径变长 4 个字符之外，没有任何实际意义。

更致命的是 internal。官方引入 internal 是为了防止库开发者暴露内部 API 给第三方。但是现在的业务开发团队，为了所谓的“代码隔离”，盲目地把整个 App 的所有核心逻辑全塞进 internal，导致项目结构变成了这样：

internal/app/modules/order/usecase/impl/order.go

当你接手这种代码时，你每天有 30% 的时间在 VSCode 里狂按文件树，试图搞清楚自己到底在哪。

陷阱 2：生搬硬套的 DDD 与洋葱架构（Clean Architecture）

一位在电商公司写 Go 的老哥抱怨道：他试图用严格的 DDD（领域驱动设计）和六边形架构来组织他的模块化单体代码。结果是，随着项目增大，维持这种“整洁”变成了噩梦。

每一次新增功能，都要处理无休止的接口绑定（Wiring dependencies）、防止循环引用，以及为了“解耦”而写的大量毫无意义的样板代码（Boilerplate）。“我感觉自己花在维护架构上的时间，甚至超过了实际交付业务功能的时间。”

记住：Go 语言的灵魂是简单直接。强行引入 Java/C# 语境下的沉重分层，就像给一辆轻巧的保时捷跑车装上了坦克的履带。

为什么“扁平化”才是 Go 架构的尽头？

面对这种极度臃肿的代码，我们在 Reddit 的评论区看到了海外老炮们的共识：Opting for a flatter structure typically guides you organically away from overly nested internal. (选择更扁平的结构，通常能自然而然地引导你远离过度嵌套的代码气味)。

在 Go 语言中，优秀的架构并不是靠“目录分层”来体现的，而是靠“领域边界（Domain Boundaries）”和“依赖流向”来体现的。

真相 1：Package 的划分应该基于“业务能力”，而不是“技术层次”

把项目按 controllers/、services/、models/ 划分是典型的反模式（MVC遗毒）。这种结构下，如果你要修改一个关于“订单”的功能，你必须在好几个目录下反复横跳。

真正懂 Go 的做法是：按领域（Domain）划分子包。 一个 order 包里，就应该包含订单的结构体、订单的仓储接口、乃至相关的处理逻辑。所有的东西都在一起，高内聚。

真相 2：不需要过度设计“防腐层”，直到你真正觉得痛

一些高级开发者指出，他们宁愿花更多的时间去做“事件风暴（EventStorming）”和领域建模，也不愿意去写抽象接口。如果你的 order_repository.go 从第一天起就只有一个 Postgres 实现，且未来三年都不会换数据库，那么你为了“解耦”而提取的一个洋葱接口层，就是纯粹的成本浪费。

大型 Go 项目实用构建指南

抛开那些玄乎其玄的词汇，如果你想构建一个不崩溃的、好维护的大型模块化单体（Modular Monolith），请立刻遵循以下四条“少即是多”的务实法则：

法则 1：干掉 pkg，克制使用 internal

除非你正在写一个准备开源给全世界使用的公共 Library 包，否则你的微服务或单体 Web 应用根本不需要 pkg 目录。

同样，把你的核心代码从深渊般的 internal/app/core/… 中解放出来。把业务包直接平铺在根目录或者按大模块放在一个外层目录即可。让文件树尽可能的“浅”。

法则 2：采用极简的领域扁平结构（Domain-Driven Flattening）

正如评论区大佬给出的终极解法，你的项目结构应该看起来像这样：

cmd/
  server/main.go        // 所有依赖注入和组装都在这里完成（Composition Root）
domain/                 // 或者直接放在根目录
  order/
    order.go            // 领域模型（Entity/Aggregate）
    repository.go       // 接口（依赖倒置，只定义 order 需要什么）
    postgres_repo.go    // 直接在同一个包下实现，或者平铺
  user/
    ...
  catalog/
    ...

不要再建什么 port 和 adapter 文件夹了！order.go 就是你的核心，postgres_repo.go 就是它的具体实现。它们呆在一个包里，简单明了，任何人 grep 搜索一下就能秒懂。

法则 3：让 Consumer 定义接口（Interface Segregation）

很多人为了解耦，喜欢在一个单独的 interface 包里定义全局接口，这又是 Java 思维作祟。

在 Go 里，接口应该是“隐式实现”的。不要在提供者（Provider）端定义接口，要在消费者（Consumer）端定义。

比如 order 包需要发邮件，它不应该去依赖 email 包的接口。它应该在自己的包里定义一个极小的 type Mailer interface { Send(…) }，然后在 main.go 中把真正的 Email 服务注入进去。这就是 Go 解除循环依赖的最强法宝。

法则 4：一切脏活累活，全扔进 main.go

对于单体应用来说，不要试图在每个模块内部做复杂的自动依赖注入（Autowiring）或自启动钩子。

保持每个模块都是极度干净、被动的。然后在你唯一的 cmd/server/main.go 里，显式地初始化数据库、初始化各个模块、然后手动把它们组装（Wire）在一起。是的，这个 main.go 可能会有几百行甚至上千行，但它让你在启动时一目了然，排查问题再也不用像个无头苍蝇一样在迷宫里乱撞了。

小结：回归大道至简

不管是摒弃 pkg，还是剥离 500 层的“整洁架构”，这背后体现的其实是 Go 语言最深刻的哲学：Pragmatism（务实主义）。

技术架构的终极目标，是为了让人读得懂，让业务跑得快，而不是为了满足程序员在代码里“建构精密钟表”的虚荣心。

如果你的代码不能让人在 30 秒内找到修改点，不能让你通过一个简单的 grep 搜索就锁定业务逻辑，那么不管你的架构图画得多么符合六边形、洋葱或者 DDD 规范，它都是一个失败的设计。

所以，立刻打开你的 IDE，试着把你那些嵌套了五六层的文件夹拖出来吧。相信我，当你删掉那一堆废话般的中间层接口时，你会感受到前所未有的舒畅。

资料链接：

• https://www.reddit.com/r/golang/comments/1tftqpj/how_do_you_structure_and_maintain_large_go/
• https://www.reddit.com/r/golang/comments/1tft8ds/pkg_internal_directories_are_way_overused/

今日互动探讨：

在你的 Go 项目里，曾经为了遵循所谓的“规范设计”做过哪些现在看起来极其离谱的过度工程？你现在的项目是扁平结构还是洋葱结构？

欢迎在评论区留言晒出你的代码结构，或者 @出那个每天沉迷于建文件夹的同事。让我们一起探讨，什么是真正的“Go 语言地道之美”！

(如果你觉得这篇实操指南帮到了你，请不要吝啬你的点赞和转发！)

还在为写 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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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