本文永久链接 – https://tonybai.com/2025/06/03/provocation-about-ai-assisted-programming

大家好，我是Tony Bai。

最近，fly.io 博客上该公司开发者 Thomas Ptacek 的一篇题为《My AI Skeptic Friends Are All Nuts》的文章，在开发者社区掀起了不小的波澜，一度登顶HN。Ptacek 以一位自称“严肃开发者”（从C语言到Go、Rust均有涉猎）的口吻，向那些对 AI 辅助编程持怀疑态度的“聪明朋友们”发出了略带“挑衅”的宣言：“即使 LLM 今天停止所有进展，它仍然是我职业生涯中发生的第二重要的事情” 。

这篇文章的观点之鲜明、论证之犀利，让我印象深刻。恰逢 前期Google I/O 2025 大会再次展示了 Gemini 等 AI 模型在编码领域的惊人进展，我们不禁要问：AI 编码工具，究竟是能极大提升生产力的“真香”利器，还是又一轮被过度炒作的“智商税”？作为开发者，特别是 Gopher，我们又该如何看待和应对这场正在发生的变革？

在这篇文章中，我就和大家一起来看看 Thomas Ptacek 对AI辅助编程演进的犀利观点以及他的反思。看看你是否认同他的想法。

误区澄清：现代 AI 辅助编程早已不是“复制粘贴”

Ptacek 在文章开篇就点出了一个关键问题：很多人对 AI 辅助编程的印象，还停留在半年前甚至两年前的水平。他写道：“如果你在6个月前（或者，天哪，两年前用Copilot的时候）尝试使用LLM编码并失败了，那么你并没有在做大多数严肃的LLM辅助编码者正在做的事情”。

那么，现在“严肃的LLM辅助编码者”在做什么呢？Ptacek 强调，他们使用的是 Agent (智能体)。这些 AI Agent 不再仅仅是根据提示生成代码片段让你复制粘贴，它们能够：

• 自主地在你的代码库中进行探索。
• 直接创建和修改文件。
• 运行各种工具， 如编译器、测试框架、linter、formatter 等。
• 与 Git 等版本控制系统交互。
• 根据编译和测试结果进行迭代和修正。
• 通过 MCP 或类似机制调用你设置的任意工具。

Ptacek强调：如果你对 AI 编码的印象还停留在 ChatGPT 网页上简单问答然后手动复制代码，那么你可能真的低估了当前 AI Agent 所能达到的自动化和智能化水平。

AI Agent 如何提升编码效率？Ptacek 的“积极案例”

Ptacek 认为，LLM（通过 Agent）能够极大地提升编码效率，主要体现在以下几个方面：

1. 处理“乏味代码”： LLM 可以编写你需要编写的大部分乏味代码。而大多数项目中的大多数代码都是乏味的。这能让开发者从重复性的工作中解放出来，更快地进入“调整代码并立即看到效果更好”的“黄金时刻 (golden moment)”，获得即时反馈的“多巴胺冲击”。

2. 克服项目启动的“惯性”： 面对一个新项目，繁琐的初始设置、依赖管理、基础架构搭建等往往令人望而却步。LLM Agent 可以被指示去“搞定这些破事，直接将你带到“事情几乎可以工作”的阶段。

3. 自动化“苦差事”： 那些你不想做但又必须做的“脏活累活”，比如大规模的单元测试重构，完全可以交给 AI Agent 在虚拟机里折腾几个小时，然后带着一个 PR 回来。这反而会“逼迫”你去做“真正的工作 (real work)”。

回应常见的质疑：Ptacek 的“辩护”

Ptacek 在文章中也针对开发者对 AI 编码的常见质疑进行了犀利的回击，这些回应也为我们思考 Go 语言在 AI 时代的定位提供了新的视角。

• 关于代码质量与审查责任——“你根本不知道它写的是什么！”

Ptacek强调，开发者始终对合并到 main 分支的代码负责，无论是否使用 LLM。 LLM 生成的代码是“可知的”，你需要阅读它，甚至花时间将其调整为你自己的风格。如果连 LLM 生成的“乏味、重复”的代码都难以理解和消化，那可能是开发人员的“技能问题”。

• 关于“幻觉 (hallucination)”问题——“它会编造不存在的API！”

Ptacek 认为，对于编程而言，Agent 通过工具链（linting、编译、运行测试）形成的闭环反馈，已经（或多或少地）解决了“幻觉”问题。“如果它们的LLM编造了一个新的函数签名，Agent会看到错误。它们将其反馈给LLM，LLM会说‘哦，是的，我完全是编造的’，然后重试”。这里不能不提到** Go 语言的快速编译特性，使得这种“试错-反馈-修正”的闭环能够非常高效地运转。同时，Go 强大的标准库和清晰的 API 设计，是否也能减少 LLM“编造”API 的概率，或者使其更容易被工具链检测出来。

• 关于“代码像初级开发者写的”——“质量太差！”

Ptacek 回应：“一个实习生一个月要花20美元吗？因为 Cursor.ai 就是这个价钱”。他认为，高级开发者的职责之一就是让能力稍逊的编码者（无论是人类还是“智能体”）变得高效。使用好 Agent 本身就是一项技能和一项涉及提示、索引和（尤其是）工具链的工程项目。 LLM 只有在你允许的情况下才会产生劣质代码。

• 关于“不擅长特定语言 (如 Rust)”——“它写不了我的 Rust！”

Ptacek 认为这更多是语言生态和工具链成熟度的问题，而非 LLM 能力的根本缺陷。他特别指出：“我主要用 Go 工作……Go 恰到好处的类型安全、广泛的标准库以及推崇（通常是重复性）惯用法的文化。LLM 在生成 Go 代码方面表现出色。” 想必很多Go开发者也有着与Ptacek相同的感受，这是 Go 语言在 AI 辅助编程时代的一个显著优势！ Go 的简洁性、明确性、强大的标准库覆盖、以及社区对代码规范和惯用法的重视（例如 Effective Go），使得 Go 代码的模式相对统一和可预测，这为 LLM 的学习和生成提供了极大的便利。

对“手工艺精神”与“平庸代码”的再思考

Ptacek 对软件开发中的“手工艺精神”和对“平庸代码”的过度排斥也提出了批判。

• 他认为：专业软件开发者的工作是用代码为人们解决实际问题。在日常工作中，我们不是工匠。过度追求代码的“优雅”而忽视实际产出，可能是“自我安慰的yak-shaving（指做无关紧要的琐事）”。

• 对于“平庸代码”，他认为：开发者都喜欢对代码自吹自擂。他们担心LLM降低了质量的“天花板”。也许吧。但它们也提高了“地板”。LLM 生成的“平庸但彻底”的代码，可能比人类开发者“抖机灵”但引入缺陷的代码更有价值。

这也引发我们思考：在追求卓越工程的同时，我们是否也应该更务实地看待不同场景下对代码质量的不同要求？LLM 是否能帮助我们更高效地处理那些“允许平庸”但又耗时耗力的部分，从而让我们能将精力投入到真正需要人类智慧和创造力的核心工作中？

Go 开发者如何拥抱 AI Agent 的时代？

Ptacek 的文章，无论你是否完全认同其所有观点，都为我们描绘了一个 AI Agent 深度参与软件开发的未来图景。作为 Gopher，我们应该如何应对？

1. 更新认知，拥抱变化： 首先要认识到，现代 AI 辅助编程已经远超简单的代码补全。应该主动去了解和体验基于 Agent 的编码工具。
2. 学习与 AI Agent 高效协作： 掌握提示工程技巧，学会如何清晰地向 Agent表达需求、提供上下文、引导其生成和修改代码。
3. 发挥 Go 语言的优势： 利用 Go 的简洁性、强大的标准库、快速的编译和测试工具链，为 AI Agent 构建高效的开发和反馈环境。思考如何让 Go 代码对 AI 更“友好”。
4. 提升自身的核心价值： 将精力更多地投入到 AI 难以替代的领域：复杂系统设计、架构决策、需求理解与抽象、创新思维、以及对 Go 底层原理和并发模型的深刻理解。
5. 参与构建 Go 的 AI Agent 生态： Go 语言本身非常适合构建 CLI 工具和后端服务。我们是否可以利用 Go 来创建更强大的、针对 Go 开发的 Agent 辅助工具或平台？

小结：保持开放，主动实践，与 AI 共舞

AI 编码工具究竟是“真香”还是“智商税”？或许答案因人而异，也因我们如何使用它而异。但 Thomas Ptacek 的“挑衅”至少提醒我们，不能用静止的眼光看待飞速发展的技术。

AI 辅助编程的浪潮已然到来。对于我们 Gopher 而言，Go 语言的特性使其在这波浪潮中具有独特的优势。与其固守过去的经验和偏见，不如保持开放的心态，主动去实践和探索，让 AI Agent 成为我们提升自身能力、加速项目交付、并最终能专注于更有创造性工作的强大伙伴。

毕竟，正如 Ptacek 所说，当他那些“聪明的怀疑论朋友们”最终接受并开始使用这些工具时，他们将会让编码 Agent 比今天强大得多。

而我们，又怎能置身事外呢？

聊一聊，也帮个忙：

• 你目前在工作中使用 AI 辅助编程工具（如 Copilot, Cursor.ai, Gemini Code Assist，Trae等）的体验如何？它在哪些方面帮助了你，又有哪些不足？
• Ptacek 文章中对 AI 编码的哪个观点让你印象最深刻？你同意还是反对？为什么？
• 你认为 Go 语言在 AI 辅助编程时代，还有哪些可以进一步优化的方向，以更好地与 LLM Agent 结合？

欢迎在评论区留下你的思考和经验。如果你觉得这篇文章提供了一个值得探讨的视角，也请转发给你身边的开发者朋友们，一起参与这场关于 AI 与编程未来的讨论！

想与我进行更深入的 Go 语言、AI 赋能开发与技术趋势交流吗？ 欢迎加入我的“Go & AI 精进营”知识星球。

我们星球见！

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

本文永久链接 – https://tonybai.com/2025/05/29/xiter-declined

大家好，我是Tony Bai。

随着 Go 1.22 中 range over func 实验性特性的引入，以及在 Go 1.23 中该特性的最终落地（#61405），Go 社区对迭代器（Iterators）的讨论达到了新的高度。在这一背景下，一项旨在提供标准迭代器适配器（Adapters）的提案 x/exp/xiter (Issue #61898) 应运而生，曾被寄予厚望，期望能为 Go 开发者带来一套便捷、统一的迭代器操作工具集。然而，经过社区的广泛讨论和官方团队的审慎评估，该提案最终被标记为“婉拒并撤回 (declined as retracted)”。本文将对 x/exp/xiter 提案的核心内容做个简单解读，说说社区围绕它的主要争论点，以及最终导致其搁浅的关键因素，并简单谈谈这一决策对 Go 语言生态的潜在影响与启示。

x/exp/xiter：构想与核心功能

x/exp/xiter 提案由 Russ Cox (rsc) 发起，旨在 golang.org/x/exp/xiter 包中定义一系列迭代器适配器。这些适配器主要服务于 Go 1.23 中引入的 range over func 特性，提供诸如数据转换 (Map)、过滤 (Filter)、聚合 (Reduce)、连接 (Concat)、并行处理 (Zip) 等常用功能。

其核心目标是：

• 提供标准化的迭代器操作工具： 帮助开发者以更声明式的方式处理序列数据。
• 探索迭代器在 Go 中的惯用法： 将其置于 x/exp 目录下，意在收集社区反馈，探讨这些适配器如何融入现有的 Go 代码风格，以及是否最终适合进入标准库 iter 包。

提案中包含了一系列具体的函数定义，例如：

• Concat / Concat2: 连接多个序列。
• Filter / Filter2: 根据条件过滤序列元素。
• Map / Map2: 对序列中的每个元素应用一个函数。
• Reduce / Reduce2: 将序列中的元素聚合成单个值。
• Zip / Zip2: 并行迭代两个序列。
• Limit / Limit2: 限制序列的长度。
• Equal / Equal2 (及 EqualFunc 版本): 比较两个序列是否相等。
• Merge / Merge2 (及 MergeFunc 版本): 合并两个有序序列。

值得注意的是，许多函数都提供了针对 iter.Seq[V]（单值序列）和 iter.Seq2[K, V]（键值对序列）的两个版本，这导致了 API 数量上的成倍增加。

以下是一个简单的设想用法示例：

package main

import (
    "fmt"
    "iter"
    // 假设 xiter 包已存在且包含提案中的函数
    // "golang.org/x/exp/xiter"
)

// 假设的 Filter 函数
func Filter[V any](f func(V) bool, seq iter.Seq[V]) iter.Seq[V] {
    return func(yield func(V) bool) {
        for v := range seq {
            if f(v) && !yield(v) {
                return
            }
        }
    }
}

// 假设的 Map 函数
func Map[In, Out any](f func(In) Out, seq iter.Seq[In]) iter.Seq[Out] {
    return func(yield func(Out) bool) {
        for in := range seq {
            if !yield(f(in)) {
                return
            }
        }
    }
}

func main() {
    numbers := func(yield func(int) bool) {
        for i := 1; i <= 5; i++ {
            if !yield(i) {
                return
            }
        }
    }

    // 设想：筛选偶数，然后平方
    evenSquares := Map(
        func(n int) int { return n * n },
        Filter(
            func(n int) bool { return n%2 == 0 },
            numbers,
        ),
    )

    for sq := range evenSquares {
        fmt.Println(sq) // 预期输出: 4, 16
    }
}

社区热议：挑战与权衡

x/exp/xiter 提案引发了社区成员的广泛讨论，焦点集中在 API 设计、易用性、与 Go 语言既有哲学的契合度等多个方面。

API 设计与易用性

• 链式调用 vs. 嵌套函数调用: 一些开发者指出，与 Java Streams 或 C# LINQ 那样的流畅链式调用（seq.Map(…).Filter(…)）相比，Go 中基于顶层函数的嵌套调用（Filter(Map(seq, …))）在可读性和编写顺序上存在不足。然而，实现链式调用需要泛型方法，而 Russ Cox指出泛型方法在 Go 中面临巨大的实现挑战（动态代码生成、性能问题、接口检查复杂性等），因此短期内不太可能实现。
• 函数参数顺序: 关于 Filter, Map, Reduce 等函数中，回调函数 f 与序列 seq 的参数顺序，社区存在不同看法。
  • benhoyt认为回调函数应置于末尾，以符合 Go 标准库中如 sort.Slice 等多数函数的习惯，便于使用内联函数字面量。
  • aarzilli 和 Russ Cox 则倾向于将回调函数置于首位（如 Map(f, seq)），理由是这更利于函数组合时的阅读顺序（从内到外或从后往前阅读），并且与 Lisp, Python, Haskell 等语言的类似库保持一致。Russ Cox 最终在提案更新中将 Reduce 的函数参数也移至首位。
• 匿名函数冗余: DeedleFake等人指出，在没有更简洁的匿名函数语法（如 #21498 提案）的情况下，使用这些适配器时，匿名函数的类型签名显得冗余和笨拙，降低了代码的简洁性。

Seq vs. Seq2 的双重性

提案中大量函数针对 iter.Seq[V] 和 iter.Seq2[K, V] 提供了两个版本（例如 Map 和 Map2），这直接导致了 API 接口数量的翻倍。虽然 Russ Cox 认为这只是“重复而非复杂性”，因为学习了 Foo 形式后，Foo2 形式只是一个简单的规则，但仍有社区成员担忧这会使包显得臃肿，影响开发者体验，并随着未来可能增加更多适配器而使问题恶化。

Zip 的语义之争

提案中的 Zip 函数设计为当一个序列耗尽后，仍会继续迭代另一个序列，并在 Zipped 结构体中通过 Ok1/Ok2 标志位标示元素是否存在。这与 Python 等语言中 zip 在最短序列结束时即停止的行为不同，更类似于 zip_longest。社区开发者就此展开讨论，认为应提供传统意义上的 Zip（返回 Seq2[V1, V2] 并在短序列结束时停止）和行为类似 zip_longest 的版本（如 ZipAll 或将提案中的 Zip 重命名为 ZipLongest）。

标准库的边界与 Go 的哲学

• “Go 风格”与“过度抽象”: 一些开发者对引入这类高度函数式的适配器表示担忧，认为它们可能与 Go 语言简洁、直接、偏向过程式循环的既有风格不符，可能导致“过度抽象”。Russ Cox 也承认存在这类担忧，并指出提案的初衷是补充而非取代传统的 for 循环。
• x/exp 的定位: Russ Cox强调，x/exp 仓库并非随意尝试新事物的试验场，而是存放那些被认为是标准库潜在候选者的地方，因为即使是 x/exp 中的包，也需要长期支持。
• DSL (领域特定语言) 的可能性: 有开发者提出了借鉴 jq 或 C# LINQ 的思路，通过 DSL 来解决迭代器链式操作的易用性问题。但 Russ Cox 认为这不符合 Go 当前的目标，且可能带来性能和复杂性问题。

最终的抉择：为何搁置？

在 Go 1.23 发布一段时间后，经过充分的讨论和实践反馈，Russ Cox 和 Austin Clements 代表提案审查小组，宣布将此提案标记为“婉拒并撤回 (declined as retracted)”。

主要原因可以归纳为：

1. 缺乏广泛共识与“过度抽象”的担忧: 官方团队认为，对于将这些适配器加入标准库并鼓励其广泛使用，社区并未形成足够强的共识。许多情况下，直接使用 for 循环可能更为清晰和符合 Go 的惯用法，而这些适配器可能导致“过度抽象”。
2. 实际使用体验与语法限制: 许多开发者在实际使用迭代器后发现，由于当前 Go 语言匿名函数语法的冗余以及缺乏流畅的链式调用机制，这些适配器的使用体验并不理想，甚至不如手写循环或自定义辅助函数来得直接。
3. 为第三方库发展留出空间: 官方认为，与其在标准库中提供一套可能不完美或引发争议的工具集，不如将这部分探索和创新留给社区和第三方库。撤回官方提案可以为第三方迭代器工具库的涌现和发展创造更有利的环境。
4. 迭代器特性尚年轻: Go 中的迭代器特性相对较新，社区和官方都需要更多时间来积累使用经验，观察哪些模式和辅助函数真正被广泛需要和接受。未来可能会基于更充分的数据和实践，提出更具针对性的小型提案。

展望与启示

x/exp/xiter 提案的搁浅，并不意味着 Go 语言在迭代器支持上的停滞。相反，它反映了 Go 团队在语言发展上一贯的审慎和务实态度。

对 Go 开发者而言，这意味着：

• range over func 依然强大: Go 1.23 提供的原生迭代器机制是核心，开发者可以充分利用它来构建高效、灵活的数据处理逻辑。
• 自定义与第三方库是当前主流: 对于迭代器的转换、过滤、聚合等操作，目前主要依赖开发者自行编写辅助函数，或选用社区中涌现的第三方迭代器工具库（如 deedles.dev/xiter, github.com/bobg/seqs, github.com/jub0bs/iterutil 等在讨论中被提及的个人项目）。
• 关注语言本身的演进: 诸如更简洁的匿名函数语法 (#21498) 等相关语言特性的提案，如果未来能被接受，可能会极大地改善函数式编程风格在 Go 中的体验，并可能为官方再次考虑标准化迭代器工具铺平道路。
• Go 的哲学不变: 清晰、简洁、可读性以及避免不必要的复杂性，仍然是 Go 语言设计的核心考量。任何新特性或库的引入，都将在此框架下被严格审视。

x/exp/xiter 的讨论过程本身就是一次宝贵的社区实践，它汇集了众多 Go 开发者的智慧与经验，即便提案未被接纳，其间的深入思考和论证也为 Go 语言迭代器生态的未来发展指明了方向，并留下了丰富的参考。我们期待看到 Go 社区在迭代器领域持续探索，涌现出更多符合 Go 风格且能切实解决开发者痛点的优秀工具与实践。

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