Golang - Tony Bai

标签 Golang 下的文章

还在当“上下文搬运工”？我写了一门课，帮你重塑AI开发工作流

十一月 20, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/11/20/ai-native-dev-workflow

大家好，我是Tony Bai。

最近半年，我发现我的开发日常，正被一种新的“工作流摩擦”所困扰。

我猜，你可能也感同身受。

我们在一块屏幕上沉浸于IDE中的Go代码，在另一块屏幕上，则像一个勤奋的“学生”，不断向AI大模型提问。我们从代码库中精心挑选上下文，复制，切换窗口，粘贴，然后带着AI给出的答案，再复制，切换，粘贴回来。

我们成了AI时代的“上下文搬运工”和“提示词调优师”。

IDE插件的出现，让AI离我们更近了一步，它像一个“副驾驶”，能为我们提供实时的建议。但它依然无法真正地“动手”——它不能为你运行一次测试，不能帮你执行一次git commit，更无法理解你那套复杂的Makefile里到底藏着什么玄机。

我们拥抱了AI，却发现自己陷入了一个新的“效率怪圈”。我们与AI的协作，始终是割裂的、被动的、充满摩擦的。

我一直在思考，这真的是AI时代软件开发的终极形态吗？一定有更好的方式。一定有一种方法，能让AI不再是一个外部的“辅助工具”，而是成为我们开发流程中一个原生的、可指挥的、能动手干活的“核心成员”。

正是为了系统性地解决这个问题，并把我过去大半年时间的思考、踩坑、实践与沉淀分享出来，我与极客时间合作，倾力打造了一门全新的专栏——《AI原生开发工作流实战：重塑新一代软件工程范式》。

为什么要写这个专栏？

因为我相信，软件开发的范式，正在经历一场深刻的革命。

我们正从“人机协作”的1.0时代，迈向“AI原生”的2.0时代。在这场变革中，开发者的核心价值，将不再仅仅是“写出代码”，而是“设计出能让AI写出高质量代码的工作流”。

而承载这场革命的最佳载体，正是以Claude Code为代表的新一代命令行AI智能体（Command-line Coding Agent）。它们让AI的能力，以前所未有的深度，“活”进了我们最熟悉的开发环境——终端里。

但是，拥有强大的工具，和懂得如何驾驭它，是两回事。

下面是一个AI-开发者集成成熟度模型，你看看你处在哪一层？

我看到的太多开发者，依然在用L1、L2的思维模式，去使用一个为L3、L4工作流设计的强大智能体。这就像开着一辆F1赛车去买菜，不仅没发挥出它的全部性能，还觉得它“不好开”。

这个专栏的目标，就是为你提供那本缺失的“F1赛车驾驶手册”。它不是一本简单的工具说明书，而是一套完整的AI原生开发方法论。我将带你一起，从“第一性原理”出发，重新思考和构建我们在AI时代的软件工程实践。

在这个专栏里，我为你设计了怎样的学习路径？

为了让你能系统性地完成这次思维和技能的升维，我将专栏精心设计为四个层层递进的模块，它就像一张清晰的“升级打怪地图”：

模块一：概念篇 · 建立AI原生世界观
在这一模块，我们将首先统一认知。你将深入理解什么是“规范驱动开发（Spec-Driven Development）”，这一AI原生开发的核心引擎。我们还会一起扫描整个命令行AI Agent的生态，并最终明确，我们为什么选择Claude Code作为核心的实战载体，以及如何通过接入国产大模型（如智普AI）来解决国内开发者的成本与可用性问题。
模块二：基础篇 · 掌握与AI伙伴协作的通用语言
我们将从零开始，手把手带你掌握与AI Agent协作的核心交互模型。你将精通上下文的艺术（CLAUDE.md, agents.md, constitution.md），学会如何为AI注入“长期记忆”和项目“宪法”。你还将掌握强大的自定义指令（Slash Commands），开始将你自己的工作流封装为AI可以执行的命令。学完此模块，你将能为任何项目快速定制一套AI‘说明书’，让它秒懂你的代码库。
模块三：进阶篇 · 将Agent锻造成你的专属神器
这是专栏的“硬核”部分。我们将进入AI Agent的“引擎室”，为你揭示其所有高级特性的工作原理和实战技巧。从安全基石（权限、沙箱、快照回滚），到能力扩展矩阵（Hooks, Skills, Sub-agents, MCP），再到自动化接口（Headless模式），你将学会如何将一个通用AI，彻底“魔改”成一个懂你项目、听你指挥的“专属神器”。学完此模块，你将拥有‘魔改’AI Agent的能力，让它从‘通用模型’变成你的‘专属战友’。
模块四：实战篇 · 在真实项目中重塑工程实践
这是整个专栏的“毕业大戏”。我们将把前面所有学到的理论和技巧，全部应用到一个从零到一的Go项目构建中。在通过顶层设计建立好你的AI驾驶舱后，你将亲历一个功能，是如何在AI原生工作流的加持下，被一步步地设计（spec.md）、规划（plan.md, tasks.md）、编码（TDD）、审查、交付（CI/CD），乃至最终维护与重构的。这将是你把知识转化为能力的最佳演练场。

学完这门课，你将获得什么？

一套前沿的开发方法论： 真正掌握“AI原生开发”与“规范驱动开发”的核心思想，而不仅仅是工具的零散技巧。
一套通用的Coding Agent驾驭技能： 精通上下文注入、自定义工具和技能、自动化编排等核心技巧，无论未来出现什么新的Coding Agent工具，你都能快速上手。
一套可落地的工程实践： 获得AI在需求、设计、TDD、CI/CD、重构等软件工程全流程中的最佳实践和Go语言实战代码。
一次思维模式的升级： 完成从“AI工具使用者”到“AI工作流指挥家”的角色转变，构筑在AI时代的个人核心竞争力。

写在最后：一份“抛砖引玉”的邀请

在策划这门课时，我始终保持着一种敬畏之心。

Claude Code是2025年2月才正式进入大众视野的，至今也不过大半年的时间。整个命令行Coding Agent领域，都还处在一个高速演进、日新月异的“黎明时代”。我们所有人，包括我在内，都还在“摸着石头过河”。

因此，这个专栏的内容会更偏向于基础和入门，我希望通过最详尽的示例，为你直观地展现AI原生工作流的巨大潜力。我为你呈现的，更多是我个人在当前阶段探索出的一种可行的工作流，它未必是放之四海而皆准的“最优解”，更谈不上是“终极银弹”。

我更希望这个专栏，能成为一个“抛砖引玉”的平台。

我把我这块“砖”抛出来，是希望能引出你——每一位身处一线的优秀开发者——那块更宝贵的“玉”。我非常期待你在课程的评论区，分享你的思考、你的工作流、你的“最佳实践”。

我相信，关于AI原生开发的未来，最终的答案，一定不是由我一个人，也不是由任何一个AI公司定义的。它将由我们所有拥抱变革、勇于实践的开发者，共同书写。

让我们一起，成为定义这个新时代开发范式的第一批人。

现在，这门凝结了我大半年心血的课程 《AI原生开发工作流实战》 已经在极客时间正式上线了！

专栏为图文形式，共22讲。我为你准备了早鸟优惠 ¥59（原价 ¥99），仅限首周。

扫描下方二维码，立即订阅

用一两杯咖啡的钱，投资一次面向未来的思维和技能升级。

如果你想先了解更详细的课程内容，可以点击「这里」查看专栏的详细目录。

期待在课程中，与你相遇，共同精进！

如果本文对你有所帮助，请帮忙点赞、推荐和转发！

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

Go 泛型再进化：移除类型参数的循环引用限制

十一月 19, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/11/19/proposal-remove-cycle-restriction-for-type-parameters

大家好，我是Tony Bai。

自 Go 1.18 引入泛型以来，Gopher 们一直在探索其能力的边界。然而，在这片新大陆上，一直存在着一个由语言规范施加的限制，它禁止了一种强大而富有表达力的泛型模式的实现。

这个限制就是：“在一个泛型类型 T 的类型参数列表中，其约束不能直接或间接地引用 T 自身。”

近日，由 Go 核心团队的 Robert Griesemer 亲自发起的一个关联提案（NO.75883），旨在移除这个约束。在经过一系列的编译器修复和深度讨论后，最终被标记为 likely accept。这意味着，Go 语言规范中关于泛型“类型参数循环引用”的这条限制，即将在未来的版本中(最早Go 1.26)被正式移除。

这次微小的语法调整，将为 Go 社区解锁一种被称为“奇异递归模板模式” (Curiously Recurring Template Pattern, CRTP) 的强大能力，并对我们如何设计类型安全的泛型 API 产生深远影响。

在这篇文章中，我们将深入探讨这一重要变化，剖析其背后的技术原理、核心应用场景等。

被束缚的表达力——这条限制是什么？

让我们从一个 Griesemer 提出的、看似合理的代码开始，它在当前版本(比如Go 1.25.4)的 Go 中是非法的：

// 目标：定义一个“可比较”的元素接口
// E 应该是一个实现了 Element[E] 接口的类型
type Element[E Element[E]] interface {
    Less(other E) bool
}

// 编译器报错：invalid recursive type: Element refers to itself
// (无效的递归类型)

这段代码的意图非常清晰：我们想定义一个 Element 接口，它有一个 Less 方法，该方法接收的参数 other，其类型 E 必须和实现这个接口的类型是同一个类型。这是一种“自引用”或“递归”的类型约束。

例如，如果我们有一个 Int 类型：

type Int int

// 我们希望 Less 的参数是 Int，而不是其他实现了 Element 接口的类型
func (i Int) Less(other Int) bool {
    return i < other
}

Element[E Element[E]] 这种约束，正是为了在编译期强制执行这种“同类型比较”的保证。

然而，由于 Go 1.18 规范中的明确限制，这种优雅的、类型安全的表达方式，在过去几年中一直是一条死路。

为何需要它？—— CRTP 模式的威力

社区的讨论为我们揭示了这种“循环类型约束”的几个核心应用场景。它们都与 C++ 中的 CRTP(Curiously Recurring Template Pattern) 模式异曲同工。

Robert Griesemer 在提案中给出了一个经典的例子：如何用泛型来模拟一个数学上的“环”(Ring)。

// 未来将合法的代码
type Ring[T Ring[T]] interface {
    Zero() T
    One() T
    Add(y T) T
    Mul(y T) T
}

Ring[T Ring[T]] 这个约束，确保了 Add 和 Mul 等方法的参数和返回值，永远是实现该接口的具体类型 T，而不是某个其他也实现了 Ring 接口的无关类型。它在编译期就锁定了操作的类型闭环。

Prometheus 的开发者 Bryan Boreham 在 GopherCon 2023 的演讲中，也遇到了同样的问题。在实现一个通用的 K-路归并树时，他希望定义一个通用的 Value 接口，让放入树的元素自带类型安全的 Less 方法，而不是依赖外部传入的闭包。这不仅能让 API 更简洁，更重要的是，直接的方法调用比闭包调用更容易被编译器内联，从而带来显著的性能提升。

从“不可能”到“可能”——幕后的编译器修复

这个看似简单的语法限制，为何在 Go 1.18 中被加入，又为何现在可以被移除了？

答案隐藏在编译器的类型检查和循环检测机制中。在早期，Go 的类型检查器为了防止无限递归（例如 type T T），采用了一套相对保守的循环检测算法。当它遇到 type T[P T[P]] 这种通过类型参数列表形成的“循环依赖”时，会直接将其误判为非法的无限递归。

在 NO.68162 issue的修复中，Go 团队改进了类型检查器的算法。新的算法能够更智能地区分有害的无限递归（如 type T *T）和无害的、可以在实例化时“展开”的泛型递归约束。

深度剖析——Griesemer 的“两步实例化”解释

在 #75883 提案的讨论中，一个极其深刻的问题被提出：type T[P T[P]] int 这样的定义，是否会导致无法解决的循环？Robert Griesemer 对此给出了一个权威的、清晰的解释，揭示了 Go 泛型实例化的核心机制。

他指出，Go 的泛型实例化，严格遵循两个步骤：

第一步：类型替换 (Substitution)
编译器首先会简单地、机械地将调用方提供的类型实参 (type argument)（例如 int），替换掉泛型定义中的类型形参 (type parameter)（例如 P）。
```
// 原始定义
type T[P T[P]] int

// 假设我们尝试实例化 T[int]
// 第一步替换后，我们得到一个临时的、假想的定义：
type T[int T[int]] int
```
第二步：约束校验 (Verification)
在替换完成后，编译器才会去检查：被替换的类型实参 (int)，是否满足它所对应的类型形参的约束 (T[int])？

在这个例子中，约束 T[int] 是一个具名非接口类型。根据 Go 的类型规则，只有 T[int] 自身才满足这个约束。而我们传入的 int 显然不是 T[int]。因此，约束校验失败，T[int] 是一次非法的实例化。

这个“两步走”的过程，清晰地证明了这种递归约束并不会导致无限循环，因为类型检查总能在有限的步骤内终止。正是基于这个坚实的理论基础，Go 团队才有信心去移除最初的限制。

一个完整的带有循环引用的类型参数的示例

让我们将 Griesemer 提出的 Ring 示例，扩展为一个完整的、在未来版本的 Go 中将可以运行的程序：

package main

import "fmt"

// 1. 定义一个递归约束的泛型接口
type Ring[T Ring[T]] interface {
    Zero() T
    One() T
    Add(y T) T
    Mul(y T) T
}

// 2. 实现该接口的具体类型
type MyInt int

func (x MyInt) Zero() MyInt       { return 0 }
func (x MyInt) One() MyInt        { return 1 }
func (x MyInt) Add(y MyInt) MyInt { return x + y }
func (x MyInt) Mul(y MyInt) MyInt { return x * y }

// 3. 编写一个操作该泛型接口的通用算法
// scale computes x + y*s
func scale[R Ring[R]](x, y, s R) R {
    return x.Add(y.Mul(s))
}

func main() {
    var a, b, c MyInt = 2, 3, 5
    // 4. 调用通用算法，编译器会检查 MyInt 是否满足 Ring[MyInt] 约束
    result := scale(a, b, c)
    fmt.Printf("scale(2, 3, 5) = %d\n", result) // 预期输出: scale(2, 3, 5) = 17
}

让我们剖析一下scale 调用时的实例化过程：

main 函数中对 scale(a, b, c) 的调用，完美地展示了“两步实例化”机制是如何工作的：

第一步：类型推断与替换 (Type Inference & Substitution)
- 编译器观察到 scale 函数的调用参数 a, b, c 的类型都是 MyInt。
- 通过类型推断，编译器确定类型实参 (type argument) 就是 MyInt。
- 它将 MyInt 替换掉 scale 函数签名中的类型形参 (type parameter) R。
- 此时，scale 函数的约束被临时实例化为 Ring[MyInt]。
第二步：约束校验 (Verification)
- 现在，编译器需要校验：类型实参 MyInt 是否满足其约束 Ring[MyInt]？
- 要满足 Ring[MyInt]，MyInt 必须实现 Ring[MyInt] 接口中定义的所有方法。让我们来逐一检查：
  - Zero() MyInt：MyInt 实现了 Zero() MyInt。满足。
  - One() MyInt：MyInt 实现了 One() MyInt。满足。
  - Add(y MyInt) MyInt：MyInt 实现了 Add(y MyInt) MyInt。满足。
  - Mul(y MyInt) MyInt：MyInt 实现了 Mul(y MyInt) MyInt。满足。
- 由于 MyInt 完整地实现了 Ring[MyInt] 接口，约束校验通过。
- 编译器确认此次泛型函数调用是合法的，并生成相应的代码。

这个过程与我们在第四章中看到的那个非法的 T[P T[P]] int 示例形成了鲜明对比。在这里，MyInt 是一个接口实现者，它能够满足由其自身参与定义的接口约束，从而构成了一个有效的、有穷的递归。

小结：Go 泛型的一次重要进化

移除泛型类型参数的循环引用限制，对于 Go 语言而言，远不止是修复了一个编译器 bug 或减少了一条规则。

对开发者而言：它解锁了一种全新的、更强大、更类型安全的泛型编程模式。我们将能够构建出表达力更强、性能更高、API 更简洁的通用库和数据结构。
对语言本身而言：这是 Go 泛型走向成熟的一次重要进化。它表明 Go 团队正在持续地、审慎地打磨泛型这一新特性，使其在保持 Go 哲学的基础上，逐步释放其全部潜能。

不过，CRTP 模式对于不熟悉的开发者来说，也确实存在一定的认知门槛。

目前，该cl已经合并到主线，大家可以在go playground的go dev branch版本下体验。

资料链接：https://github.com/golang/go/issues/75883

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？