软件工程 - Tony Bai

标签软件工程下的文章

AI 时代如何真正掌握一门新技术？这份非主流学习指南建议永久收藏

六月 4, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/06/04/master-new-tech-in-ai-era-counter-intuitive-learning-guide

大家好，我是Tony Bai。

最近，在开发者社区 Reddit 的 Golang（Go语言）板块上，一个求助帖引发了跨越语言和技术栈的集体共鸣。

发帖人是一位刚入行两年的新人，他的帖子大意是：

“我很迷茫。在这个AI时代，大家似乎都在用大模型疯狂地构建项目、飞速向前。如果我按照传统方式，看书、查文档、一行行敲代码，就会觉得自己慢得像个古董，正在被时代抛弃。

但当我向AI要答案时，我又觉得我根本不是在编程，我只是个在中间倒腾提示词的传话筒。看着那些跑起来的代码，我感到无比空虚——我感觉自己像个骗子，我根本没有真正掌握它。在AI时代，我到底该怎么学习？”

这个帖子之所以能得到成百条回复，是因为它戳破了当下几乎所有技术学习者的隐秘焦虑：当AI 能秒出代码、秒给方案时，我们该如何建立属于自己的、不可替代的技术壁垒？

如果你的学习方式依然停留在“遇到问题 -> 丢给AI -> 复制粘贴 -> 跑通收工”的循环中，那么你正在主动将自己推向被AI淘汰的边缘。

在这篇文章中，我们将结合这场技术社区的讨论，为你拆解一套在AI时代真正掌握一门新技术（我们以崇尚极简的Go语言为例）的“非主流”学习指南。

为什么“AI代写”是一粒甜美的毒药？

在Reddit的讨论区中，一位资深开发者留下了这样一句警示：

“Remember, lines produced are lines spent; not achieved.”（记住，生产出来的代码行数，是你的负债，而不是你的成就。）

在非AI时代，写代码的行数代表着你的思考与劳动；但在AI时代，生成一万行代码可能只需要几十秒钟。很多人因此陷入了“效率幻觉”，看着屏幕上飞速滚动的代码，误以为自己的能力也随之暴涨。

这是一种极度危险的认知幻觉。

1. 认知深度的“折叠”

编程不仅仅是输出语法，更核心的是在脑海中建立逻辑模型。当你遇到一个并发瓶颈或内存泄漏问题时，你为了排查它而去翻看源码、对比不同的垃圾回收机制、调整参数——这整个“痛苦挣扎”的过程，正是你大脑神经元建立连接、内化技术底层逻辑的唯一途径。

如果你直接问AI“怎么解决”，AI会直接把改好的代码喂给你。你跳过了挣扎，也就跳过了认知。你的技术肌肉不仅没有得到锻炼，反而开始萎缩。

2. 丧失对复杂系统的控制力

用AI拼凑出来的项目，在初期确实能跑得很快。但因为你没有亲手参与底层架构的微调，随着项目规模扩大，各个模块之间的耦合、并发冲突、边界条件会像雪崩一样爆发。由于你缺乏对这些代码的“微观掌控力”，一旦AI也无法给出正确答案时，你将面对满屏报错束手无策。

Senior与Junior的AI使用界限

在技术团队中，你会发现一个有趣的现象：资深工程师（Senior）用AI效率翻倍，而初学者（Junior）用AI却越来越平庸。

这背后的本质差异在于：你是否拥有“代码品味（Code Smell）”和“系统直觉”。

资深工程师的模式：【主导与审查】

高级开发人员对系统架构、设计模式、性能瓶颈有着深刻的肉体记忆。当他们使用AI时，他们把AI当作一个速度极快的“草稿撰写员”。AI给出的方案，Senior一眼就能看出哪里有潜在的内存泄漏，哪里不符合并发安全。他们是在评审（Review） AI，始终掌握着主导权。

初学者的模式：【盲从与执行】

初学者由于没有建立起完整的技术品味，无法分辨AI给出的方案到底是优雅的还是埋了雷的（即AI生成的“Slop/代码垃圾”）。初学者往往选择无条件信任，甚至连变量名、异常处理都直接套用。

一位大厂技术面试官在贴子中坦言：

“在最近的面试中，我看到了初级候选人理解能力的全面崩溃（collapse of comprehension）。他们能用AI在10天内做出一套复杂的分布式系统，但当我问及其中一个数据一致性问题是如何在Go中保证的，或者让他们手写一个简单的通道（channel）协作时，他们彻底哑口无言。”

这就是盲目依赖AI代写的代价：你以为你开挂了，其实你只是把自己的大脑外包了。

非主流学习指南（以Go语言为例）

那么，在AI时代，正确的学习姿势到底是什么？这套“非主流”路径建议你打印出来，贴在电脑旁。

第一步：开启“Cold Turkey（冷火鸡）”阶段，强制肌肉记忆

在学习一门新技术（如Go语言）的前几个月，请狠心关掉你IDE里的所有AI辅助插件（如Copilot、Cursor的Tab补全）。

Go语言的设计哲学是 “Clear is better than clever”。它的语法极其克制，没有复杂的语法糖。这使它成为最适合用古法一行行敲击来建立肌肉记忆的语言。

亲手去写每一个 if err != nil 的错误处理；
亲手去体验指针传递与值传递的区别；
亲手写一个基础的 for range 循环。

在这个阶段，痛苦是你的朋友。那些因为拼写错误、类型不匹配导致的编译失败，正是你建立语言直觉的养料。

第二步：系统化输入优先（先建立拼图框，再填充碎片）

AI最擅长提供零散的代码片段，但它无法为你提供系统的知识框架。因此，必须坚持阅读经典。

官方 Spec 优先：去读Go的官方文档《Effective Go》，去理解为什么官方不推荐使用过于复杂的技巧，而是强调代码的可读性。
经典图书不可替代：通读一本如《The Go Programming Language》这样的硬核著作，或《Go语言第一课》这样的系统化的专栏。书本/专栏能够提供一条由浅入深、逻辑连贯的学习脉络，这是AI那碎片化的回答永远无法提供的。

第三步：将AI角色重塑为“苏格拉底私人导师”

这是整套指南中最关键的改变：禁止让AI帮你写代码，强制让AI教你思考。

每次遇到难题，不要问 “帮我用Go写一个高并发的爬虫”，而是使用以下苏格拉底提问提示词（Prompt Template）：

苏格拉底学习 Prompt 模板：

“我现在正在学习Go语言的 [并发控制/通道/接口] 概念。在解决 [具体问题] 时，我卡住了。请你扮演一位资深的、注重启发式教学的导师。

在接下来的对话中，请严格遵守以下规则：
1. 绝对不要直接给我写出最终的代码答案。
2. 请指出我思路中可能存在的盲区或不合理的设计。
3. 用反问、类比或拆分步骤的方式，一步步引导我自己写出正确的代码。
4. 如果我的代码运行出错，请帮我分析报错信息背后的底层逻辑，而不是直接给出修改后的代码。

我的初步代码/想法如下：[贴出你的尝试]”

通过这种方式，AI从一个“抢你饭碗的枪手”，变成了一个“24小时无条件陪伴、温和且博学的私人教授”。

第四步：构建“双向反馈回路”

自己先写：哪怕写得再烂，也要自己先用最基础的方式把功能实现。
让AI Review：功能跑通后，把代码发给AI：“这是我自己实现的Go并发下载器。请站在资深Go开发者的角度，帮我挑挑刺。这里有没有通道泄露的风险？有没有更地道的写法（Idiomatic Go）？”
对比重构：理解AI给出的优化建议，然后关掉AI的窗口，自己手动在编辑器里把优化后的代码重写一遍。

小结：在无限代码的时代，做掌握源头的人

在这个时代，最不缺的就是代码。随着大模型代码生成能力的指数级演进，写代码的成本正在无限趋近于零。

但正因如此，能够看懂代码、评估系统风险、做出架构决策的人，其价值正在成倍增长。

平庸的开发者：只学会了如何向AI索要现成的螺丝钉，一旦系统倒塌，他们不知道哪颗螺丝出了问题。
顶级的开发者：借助AI导师，以极快的速度弄懂了整个系统的构造原理，他们亲手组装，对每一个接口、每一次并发、每一处内存分配都了如指掌。

在AI时代，学习技术不是为了和AI比拼速度，而是为了借由AI的博学，更快、更深地抵达技术的本质。

关掉你的IDE/Copilot自动补全，打开一本经典的Go语言书，准备好你的键盘。

属于你的深水区探索，才刚刚开始。

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

为了便于你随时温习，我将这套“AI时代非主流学习法”整理成了4条核心原则，建议截图保存：

主动戒断，重建肌肉记忆：在学习一门新技术（如Go语言）的前期，强制关闭所有AI代码自动补全。像前AI时代的程序员一样，亲手敲下每一行代码、解决每一次报错。
系统输入，构建认知地图：拒绝用碎片化的AI回答代替系统学习。坚持阅读官方规范（Spec）和经典书籍，先在脑海中画出技术拼图的“边框”。
重塑定位，将AI降级为导师：严禁向AI要直接的代码答案。使用“苏格拉底式提示词”，引导AI指出你的逻辑漏洞、解释底层原理、启发你独立思考。
闭环反馈，完成深度重构：永远坚持“自己先写 -> AI审查 -> 闭环重构”的三步法。在对比与亲手重写中，真正内化代码的“好坏品味”。

今日开放讨论

学习的本质是思维的碰撞，面对汹涌而来的AI浪潮，我想听听你的真实想法：

你目前在学习或工作时，对AI（如GitHub Copilot, Cursor, Claude Code等）的依赖程度有多高？
在日常开发中，你是否也曾经历过“代码虽然跑通了，但感觉自己像个骗子”的空虚瞬间？你是如何克服这种技术焦虑的？
除了文中提到的“苏格拉底提问法”，你在用AI辅助学习时，还有哪些秘而不宣的“神级提示词”或实用技巧？

欢迎在评论区留下你的深度思考。

如果这篇内容对你有启发，欢迎点赞、转发、收藏，你的支持是我持续输出硬核思考的最大动力。

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

img{512x368}

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

再见样板代码！Go 官方新提案：函数一键转接口

六月 2, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/06/02/no-more-boilerplate-go-proposal-function-to-interface-conversion

大家好，我是Tony Bai。

在 Go 语言日常开发中，有一个设计几乎人人写过，但写多了又让人觉得极其繁琐、甚至有些“脱裤子放屁”的样板代码。

假设你需要一个只读数据的 io.Reader，但它的行为非常简单（比如只是为了在测试里模拟数据），你通常需要这样写：

type ReaderFunc func(p []byte) (n int, err error)

func (f ReaderFunc) Read(p []byte) (n int, err error) {
    return f(p)
}

紧接着，在代码中通过 io.Reader(ReaderFunc(myFunc)) 进行双重套娃调用。

这种设计被称为 “适配器型定义”（如标准库中的 http.HandlerFunc）。虽然它工作得很好，但如果每个包都需要针对自己的单方法接口（Single-method Interface）定义一遍这种暖场代码，整个项目就会充斥着大量无意义的样板代码（Boilerplate）。

为了终结这个痛点，Go 语言的积极贡献者 Merovius 提交了一项提案——Issue #47487：允许将函数显式转换为单方法接口。

目前，该提案已被列为Active状态，并有了原型实现（CL 572835）。它不仅能让 Go 代码的清爽度提升一个量级，更是对 Go 语言底层类型系统的一次精妙微调。

痛点拷问：为什么我们讨厌“套娃”代码？

在复杂的微服务或系统级开发中，我们经常需要临时“包装”一些行为。比如，你想设计一个 io.Writer，用来统计实际写入了多少个字节：

// 传统写法：你需要定义一个专门的结构体
type countingWriter struct {
    w io.Writer
    n int64
}

func (w *countingWriter) Write(p []byte) (n int, err error) {
    n, err = w.w.Write(p)
    w.n += int64(n)
    return n, err
}

func main() {
    cw := &countingWriter{w: os.Stdout}
    // 写入数据到 cw
    fmt.Println(cw.n, "bytes written")
}

为了实现一个简单的计数逻辑，你被迫写了十多行结构体和方法定义。更糟糕的是，这破坏了内聚性——countingWriter 往往只用一次，却污染了整个包的命名空间。

现在，看看新提案下，利用闭包（Closure）和函数转接口后的极致美学：

func main() {
    var N int64
    // 核心：直接把匿名函数转换为 io.Writer 接口！
    cw := io.Writer(func(p []byte) (n int, err error) {
        n, err = os.Stdout.Write(p)
        N += int64(n)
        return n, err
    })
    // 写入数据到 cw
    fmt.Println(N, "bytes written")
}

对比极其鲜明：代码行数缩减了一半，状态逻辑（N）被完美锁死在当前函数作用域内，没有任何多余的结构体命名，逻辑高内聚。

方案博弈：为什么是显式“类型转换”，而不是“自动赋值”？

其实，社区早在几年前就提过更激进的提案（#21670）：允许将函数直接、隐式地赋值给匹配的单方法接口（Assignability）。

但是，该提案很快遭到了 Go 核心团队的否决，原因在于隐式赋值的二义性与安全隐患。

最经典的例子：

io.Reader 和 io.Writer 的核心方法，其函数签名是完全相同的：

Read(p []byte) (n int, err error)
Write(p []byte) (n int, err error)

如果允许隐式赋值，当你写下 var x = func(p []byte) (int, error) { … } 时，编译器根本无法得知你这个函数到底是一个“读者”还是一个“写者”。

为了守护 Go 语言类型安全、意图清晰的底层哲学，#47487 采取了折中但极度务实的路线：要求必须进行显式类型转换（Convertibility）。

// 必须显式声明你要转换成什么接口
r := io.Reader(myFunc)
w := io.Writer(myFunc)

程序员必须显式、大声地告诉编译器：“我知道这个函数签名的含义，现在我要把它当做 Reader/Writer 来用。” 这完美规避了隐式匹配导致的逻辑混乱。

编译器背后的魔法：如何处理反射与断言？

这是一个看似简单的语法糖，但对 Go 编译器的底层设计提出了巨大的挑战。

在 Go 语言的底层设计中，有一个坚不可摧的铁律：只有被定义（Defined）的类型才能携带方法，未命名类型（如普通的 func 类型）是没有方法集的。

如果我们将一个普通的匿名函数转换为了 io.Reader 接口，当我们对这个接口进行反射（reflect.TypeOf）或类型断言时，底层的动态类型（Dynamic Type）到底是什么？

为了解决这个“Trilemma（三难困境）”，Go 团队在原型 CL 572835 中展示了编译器的底层魔法：在编译期，自动生成虚拟的未导出类型。

当你写下 io.Reader(func…) 时，Go 编译器会在幕后自动为你生成一个类似于 runtime.io_reader.func 或 runtime.autogenerated_xxx 的未导出定义类型。它拥有一个名为 Read 的方法，该方法在调用时会直接执行你传入的函数体。

这种设计的精妙之处在于：

完全向后兼容：不破坏任何既有反射代码的假设。
不破坏语法直觉：由于自动生成的类型是未导出的，用户无法对其进行电击治疗（比如无法直接对这个虚拟类型进行类型断言），从而保证了底层的干净。

官方自曝：标准库里到底有多少无用的“套娃”代码？

在 Issue 的辩论中，Merovius 对 Go 语言的标准库进行了一次扫描，揭露了如果没有这个特性，标准库自己写得有多纠结：

测试代码中的大量复制：在标准库测试中，存在大量为了测试 io.Reader、io.Writer、io.Closer 而定义的临时函数类型。
同名不同命的尴尬：在 net/http 包中，为了支持函数转换，居然定义了两个功能、签名完全一致，但由于在不同测试文件而名称不同的类型——funcWriter 和 writerFunc。
为了便利被迫暴露 API：因为没有原生语言支持，标准库不得不主动暴露出一些公共辅助类型，比如 net/http.HandlerFunc、cmd/go 内部的 ActorFunc、以及 x/mod 的 HashReaderFunc。

如果这项提案落地，标准库中数十个这样“脱裤子放屁”的适配器定义和重复代码，将在瞬间被全部清理干净。

对于第三方库（如各类 mock 框架、测试断言库）来说，这也意味着繁琐的 Fake 实现可以被一键简化为极简的匿名函数传入。

小结：这就是 Go 务实的进化美学

在 Issue #47487 漫长的拉锯战中，我们可以清晰地感受到 Go 团队在面对语言进化时的审慎。

Go 从不轻易引入新的语法，每一次特性的加入，都要经历长达数年、多方视角的拷问与权衡。他们拒绝了不安全的隐式匹配，也拒绝了过于复杂的通用接口字面量，最终停在了一个“用显式类型转换，在编译器内部生成虚拟类型”的务实方案上。

这正是 Go 语言长盛不衰的工程美学：宁可让语言显得有些“无聊”和“保守”，也绝不在运行时的安全性和可预测性上做出半步妥协。

随着 CL 572835 原型的不断完善，我们有望在不久的将来，彻底告别写各种 HandlerFunc 的繁琐日常，让 Go 代码重新回归极致的清爽。

资料链接：

https://github.com/golang/go/issues/47487
https://go.dev/cl/572835

今日互动讨论：

你赞同 Go 官方坚持使用“显式转换（Explicit Conversion）”而不是“隐式自动匹配（Implicit Assignability）”的设计吗？在你的日常项目中，有哪些单方法接口（如 http.Handler 或自定义业务处理器）能被这个新特性瞬间治愈？

欢迎在评论区留下你的硬核见解，我们一起聊聊 Go 语言的演进之道！