本文永久链接 – https://tonybai.com/2026/03/29/stop-mindless-ai-coding-we-are-heading-to-a-dead-end

大家好，我是Tony Bai。

过去的一年，大概是所有程序员肾上腺素飙升最快的一年。

从早期的 Copilot、Cursor到如今的Claude Code、Codex，再到各种号称能“全自动开发”的 Agent Swarm（智能体集群）。只要在周末花上几个小时，敲几句 Prompt，你就能把以前想做却没时间做的 Side Project 全部干出来。

甚至，连微软 CEO Satya Nadella 都在四处宣扬“微软现在有多少代码是 AI 写的”。仿佛在一夜之间，“一个人就是一家公司”、“一天撸完一个 SaaS 平台”成了技术圈的标配。

但在这场速度的狂欢中，你有没有感觉到一丝不对劲？

最近，国外资深开发者 Mario Zechner 写了一篇极其辛辣的文章《Thoughts on slowing the f**k down》。他毫不客气地戳破了这层“繁荣”的窗户纸：

当我们把 AI 智能体（Agent）全面引入生产代码库后，我们并没有迎来软件工程的乌托邦，反而正在以惊人的速度，制造着前所未有的“屎山”和灾难。

今天，我想结合他的反思，以及我最近在使用 AI 原生开发时的一些切身痛点，给大家浇一盆冷水。在被大模型彻底“惯坏”之前，我们必须看清，过度依赖 Agent 正在如何毁掉我们的系统，甚至我们的职业生涯。

100% AI 生成，等于 100% 的不可控

很多公司和独立开发者喜欢标榜：“我的产品 100% 是由 AI 写的。”

他们以为这是高科技的证明，但在行家眼里，这简直是灾难的代名词。

那些号称“完全脱手、让 Agent 自己去写”的代码库，往往充斥着你能想象到的最糟糕的垃圾：

高达几个 G 的内存泄漏、莫名其妙的 UI 闪烁、完全没有一致性的设计模式，以及一碰就碎的核心逻辑。

为什么会这样？难道现在的 AI 不够聪明吗？

原因在于：Agent 是“没有痛感”的，而人类有。

在传统的手工编码时代，人类程序员是一个天然的“物理瓶颈”。你一天最多只能写 500 行高质量代码。如果你在这个过程中犯了错（比如引入了某个不良的抽象，或者写了一个极其恶心的嵌套），你会立刻感到“痛苦”。

为了避免这种痛苦，你会花时间去重构，去梳理架构，或者因为被 Reviewer 骂了一顿而痛改前非。

痛苦，逼着人类去学习和进化，逼着系统保持在一个“可维护”的边界内。

但 Agent 呢？它是一台没有感情的打字机。

它可以在几分钟内拉出两万行代码。如果其中包含了一个微小的设计缺陷，它不会感到痛苦。相反，它会在你看不见的地方，将这个缺陷以成百上千倍的速度“复利式地放大（Compound）”。

等你回过神来，想要在这个 100% 由 AI 生成的系统上加一个新功能时，你会绝望地发现：你连它长什么样都不知道，而且它已经烂到连 AI 自己都改不动了。

为什么 AI 连自己写的屎山都修不好？

有人可能会说：“既然 AI 能写屎山，那我再派一个高级 Agent 去重构这堆屎山不就行了？”

这就是当下最可怕的“平替思维”陷阱。

现实是：当代码的复杂度和体积膨胀到一定程度后，AI 的“召回率（Recall）”会呈现断崖式下跌。

这不仅仅是上下文窗口大小（Context Window）的问题。在拥有百万行代码的迷宫中，Agent 根本不知道该去哪里找相关的依赖，不知道哪些旧代码可以复用。它只能基于极其局部的视野（Local View）去做决策。

这就导致了极度荒谬的现象：Agent 在重构时，不仅找不到病根，反而会发明出更多为了抽象而抽象的垃圾代码，让屎山开出更加绚丽的“奇葩”。

人类制造企业级的屎山，需要几十个程序员耗费好几年的时间来堆砌；

而你，只需要带上 2 个 AI Agent，几个星期就能搞出一个连上帝都看不懂的废墟。

当你发现连号称 100% 覆盖率的 AI 测试用例都在撒谎时，除了手动去点产品、祈祷它别崩溃，你已经失去了对系统的任何掌控力。

我们该如何与 Agent 共生？

难道我们要砸烂电脑，退回到手敲汇编的时代吗？当然不是。

Agent 就像古希腊神话中的海妖塞壬（Sirens），用极速的快感诱惑着你。我们必须在它摧毁我们的工程纪律之前，重新夺回主动权。

真正的顶级开发者，绝不会对 AI 说：“嘿，帮我把这个系统全干了。”

他们与 Agent 的协作，遵循着极其严苛的边界：

1. 坚决把控“系统的整体结构”

什么是系统的整体结构？那是你的核心架构设计、API 的边界、数据库的实体关系，以及整个系统跑起来时的“手感”。

这些东西，必须由你亲手来写，或者通过 Pair Programming（结对编程）一行一行地推敲。

只有亲手写过，感受到那份“摩擦力”，你才能在脑海中建立起对系统的上帝视角。这是目前任何 SOTA（最先进）大模型都无法替代的品味与经验。

2. 让 AI 去干“不用动脑子”的脏活

Agent 最适合的场景，是那些不需要全局视野的局部任务：写一段正则、爬个数据、写几条枯燥的单元测试，或者是写一个就算坏了也不影响公司赚钱的内部临时脚本。

把时间花在“决定做什么”和“决定不做什么”上。学会对需求说“不”，本身就是最高级的特性。

3. 强制减速

这是最反直觉，也是最重要的一条建议。

不要为了追求那虚荣的“代码生成量”而沾沾自喜。给自己设定一个限制：每天 AI 生成的代码量，绝对不能超过你“能够深入 Review 和理解”的极限。

你必须确保，如果明天所有的 AI 公司突然破产，你依然能从容地接管这个系统，因为它的每一根骨架，都在你的掌控之中。

小结：只有人类，才能兜住底线

在过去的一年里，我们把太多的权力让渡给了机器，以至于我们忘记了软件工程的本质。

在这个鼓吹“快、更快、再快一点”的癫狂时代，慢下来，反而成了最稀缺的竞争力。

你的代码可能不再是纯手工敲出来的了，但你的架构品味、你的工程纪律、你在出 Bug 时能一针见血找到根源的敏锐直觉，才是你在这个时代安身立命的根本。

一切自动化，最终都需要人类的纪律（Discipline）与主体性（Agency）来兜底。

机器可以写代码，但只有人类，才能为系统注入灵魂。

资料链接：https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down

今日互动探讨：

在日常开发中，你有没有遇到过被 AI 生成的“看似完美、实则藏雷”的代码坑得很惨的经历？你是怎么发现并解决的？

在 AI 编程的浪潮中，你觉得人类程序员最不可被替代的核心能力是什么？

欢迎在评论区分享你的血泪史与思考！

还在为“复制粘贴喂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/03/27/function-type-inference-should-work-in-all-assignment-contexts

大家好，我是Tony Bai。

在这个大模型（AI）写代码如喝水一般简单的时代，你有没有遇到过一种极其憋屈的场景：

你让 Claude Code 或者 Codex 帮你写了一段 Go 语言代码，逻辑清晰，结构优雅，连它自己都觉得这波操作满分。但当你满怀期待地按下 go run 时，Go 编译器却无情地丢给你一个红色报错：

cannot use generic function g without instantiation
（不能在未实例化的情况下使用泛型函数 g）

AI 沉默了，它不明白自己错在哪；如果你是个习惯了 Rust 那种“地表最强类型推断”的开发者，你可能会当场流下心酸的眼泪—— 在 Rust 里闭着眼睛都能推断出来的泛型参数，怎么到了 Go 里，它就突然变成了“残疾”？

如果你曾经被这个“诡异”的泛型报错折磨过，甚至因此怀疑过自己的智商，不要怪 AI 不懂 Go 语言。

因为就在最近，连“Go 语言之父之一” 的 Robert Griesemer 都亲自在官方 GitHub 上提了一个 Issue，承认这个语法限制不仅反直觉，甚至一度被认为是一个编译器 Bug！Griesemer 本人随即在 Issue 中自我更正，明确这需要语言规范(spec)层面的修改，而不只是修编译器。

今天，我们就来扒开这个在 Go 官方仓库引发热议的 Issue #77245，看看这个即将改变Go工程师日常编码的“底层规范级修补”，到底是怎么回事。

“薛定谔”式的类型推断

自从 Go 1.18 引入泛型以来，“不够聪明”的类型推断（Type Inference）就一直被开发者诟病。直到 Go 1.21 发布，官方宣称大幅增强了这部分能力：只要在赋值上下文中，目标类型是明确的，Go 就可以帮你自动推断出泛型函数的参数类型，不需要你手动写 g[int] 了。

这听起来很美好，对吧？

但现实是极其骨感的。我们来看看 Robert Griesemer 亲自给出的这个“薛定谔式的推断”的例子：

type S struct{ f func(int) }

func g[T any](T) {} // 这是一个简单的泛型函数

func _(s S) {
    s.f = g          // ✅ 没问题！Go 编译器智商在线，完美推断出 T 是 int

    s = S{f: g}      // ❌ 报错：不能在没有实例化的情况下使用泛型函数 g

    s = S{f: g[int]} // ✅ 没问题！必须手动写死 g[int]
}

看懂这个坑在哪里了吗？

当你写 s.f = g 的时候，编译器智商在线，它知道 s.f 需要一个 func(int)，所以它机智地把泛型函数 g 实例化成了 g[int]。

但是（最气人的但是）！

当你使用结构体字面量 S{f: g} 进行初始化时，编译器却突然“智力下线”了。它死活推断不出 g 需要被实例化为 int，非逼着你极其啰嗦地写上 g[int]！

这种“一半聪明，一半智障”的表现，不仅存在于结构体里。在切片（Slice）、数组、Map，甚至是 Channel 的发送操作中：

type F func(int)
type A [10]F
type S []F
type M map[string]F
type C chan F

func g[T any](T) {}

func _() {
    var a A
    a[0] = g      // ok
    a = A{g}      // error: cannot use generic function g without instantiation
    a = A{g[int]} // ok

    var s S
    s[0] = g      // ok
    s = S{g}      // error: cannot use generic function g without instantiation
    s = S{g[int]} // ok

    var m M
    m["foo"] = g         // ok
    m = M{"foo": g}      // error: cannot use generic function g without instantiation
    m = M{"foo": g[int]} // ok

    var c C
    c <- g      // error: cannot use generic function g without instantiation
    c <- g[int] // ok
}

只要你使用了复合字面量（Composite Literals），这套“残疾”的类型推断就会集体失效。

为什么 Rust 和 AI 看了会沉默？

如果你去问一个 Rust 开发者：“目标结构体的字段类型 f func(int) 明明就摆在那里，Go 编译器为什么会看不见？”

Rust 开发者可能会拍着你的肩膀叹气。在 Rust 强大的类型推断系统面前，这种上下文推导简直是基本操作，根本不需要开发者操心。

而在如今 AI 辅助编程大行其道的时代，这个问题更加被无限放大。

大模型在学习了海量代码后，它的“直觉（Next-token prediction）”告诉它，这里上下文极其明确，根本不需要写死类型参数。于是 AI 开心地生成了 S{f: g}，结果却被 Go 编译器无情打脸。你不得不停止思考，手动去把 AI 生成的代码一行行加上 [int]、[string]……

这根本不是 AI 的幻觉，而是 Go 语言规范（Spec）在当年设计时，由于过于严谨，给自己留下的思维盲区。

在最初的 Go Spec 中，关于泛型函数实例化生效的上下文规定得极其死板（只在某些直接赋值的场景生效）。当时的 Go 团队并没有抽象出一个统一的 “赋值上下文（Assignment Context）” 概念。这导致散落在各个角落的复合字面量操作，全都成了漏网之鱼。

官方的修补：一场牵一发而动全身的“规范手术”

起初，Robert Griesemer 以为这只是个单纯的编译器 Bug，只要改改代码就行了。

但随着讨论的深入，核心成员们（如 Austin Clements）发现，这事儿没那么简单。要从根本上解决这个问题，必须对 Go 语言规范（Spec）动刀子！

在随后的内部评审中，Go 团队做出了一个决策：

他们没有选择“头痛医头，脚痛医脚”地去给结构体、Map、切片分别打补丁。而是选择在 Go 语言最底层的定义——“可赋值性（Assignability）” 上做文章。

他们提出了一个新的 CL ，只要一个表达式符合“可赋值性”的校验（无论是等号赋值、结构体初始化、还是 Channel 发送），Go 编译器就必须启动泛型函数的自动类型推断。

这就好比给整个 Go 语言的类型推断系统，彻底打通了奇经八脉。

小结

到这里，可能有开发者会问：“不就是少写几个 [int] 吗？至于这么大惊小怪吗？”

在几行代码的 Demo 里，这确实不是事。

但在大厂动辄十几万或几十万行的微服务源码中，当我们使用泛型去实现高阶的“工厂模式”、“回调注册”、“依赖注入”时，代码中会充斥着大量的结构体初始化和泛型函数传递。

如果没有统一的类型推断，原本极其优雅的代码，就会变成被各种中括号 [T, K, V] 塞满的“乱码”。

更少的手动类型标记，意味着更低的人类认知负荷（Cognitive Load），以及对 AI 代码生成工具更友好的兼容性。

Go 语言之所以能在一众花里胡哨的新语言中稳坐云原生霸主的交椅，靠的绝不仅是并发，更是这种对“代码清爽度”和“心智负担”极其克制、甚至有些偏执的追求。

好消息是，这个被开发者诟病已久的痛点，已经被 Go 官方提案评审委员会 “正式接受（Accepted）”。

我们极有可能在即将到来的后续版本(比如Go 1.27)中，看到这段啰嗦的泛型代码彻底消失。

资料链接：

• https://github.com/golang/go/issues/77245
• https://go.dev/cl/751312

今日互动探讨：

在日常写 Go 泛型的时候，你还遇到过哪些让你觉得“Go 编译器简直是个智障”的奇葩场景？或者在对比 Rust/TS 时，你觉得 Go 的类型系统最需要补齐哪个短板？

欢迎在评论区疯狂吐槽与分享!

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

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