标签 Git 下的文章

Go项目该拥抱Monorepo吗?Google经验、etcd模式及白盒交付场景下的深度剖析

本文永久链接 – https://tonybai.com/2025/06/06/go-monorepo

大家好,我是Tony Bai。

在Go语言的生态系统中,我们绝大多数时候接触到的项目都是遵循“一个代码仓库(Repo),一个Go模块(Module)”的模式。这种清晰、独立的组织方式,在很多场景下都运作良好。然而,当我们放眼业界,特别是观察像Google这样的技术巨头,或者深入研究etcd这类成功的开源项目时,会发现另一种代码组织策略——Monorepo(单一代码仓库)——也在扮演着越来越重要的角色。

与此同时,Go语言的依赖管理从早期的GOPATH模式(其设计深受Google内部Monorepo实践的影响)演进到如今的Go Modules,我们不禁要问:在现代Go工程实践中,尤其是面对日益复杂的项目协作和特殊的交付需求(如国内甲方普遍要求的“白盒交付”),传统的Single Repo模式是否依然是唯一的最佳选择?Go项目是否也应该,或者在何种情况下,考虑拥抱Monorepo?

这篇文章,就让我们一起深入探讨Go与Monorepo的“前世今生”,解读不同形态的Go Monorepo实践(包括etcd模式),借鉴Google的经验,剖析其在现代软件工程,特别是白盒交付场景下的价值,并探讨相关的最佳实践与挑战。

Go Monorepo的形态解读:不仅仅是“大仓库”

首先,我们需要明确什么是Monorepo。它并不仅仅是简单地把所有代码都堆放在一个巨大的Git仓库里。一个真正意义上的Monorepo,通常还伴随着统一的构建系统、版本控制策略、代码共享机制以及与之配套的工具链支持,旨在促进大规模代码库的协同开发和管理。

在Go的世界里,Monorepo可以呈现出几种不同的形态:

形态1:单一仓库,单一主模块

这是我们最熟悉的一种“大型Go项目”组织方式。整个代码仓库的根目录下有一个go.mod文件,定义了一个主模块。项目内部通过Go的包(package)机制来组织不同的功能或子系统。

  • 优点: 依赖管理相对简单直接,所有代码共享同一套依赖版本。
  • 缺点: 对于逻辑上可以独立部署或版本化的多个应用/服务,这种方式可能会导致不必要的耦合。一个服务的变更可能需要整个大模块重新构建和测试,灵活性稍差。

形态2:单一仓库,多Go模块 —— 以etcd为例

这种形态更接近我们通常理解的“Go Monorepo”。etcd-io/etcd项目就是一个很好的例子。它的代码仓库顶层有一个go.mod文件,定义了etcd项目的主模块。但更值得关注的是,在其众多的子目录中(例如 client/v3, server/etcdserver/api, raft/raftpb 等),也包含了各自独立的go.mod文件,这些子目录本身也构成了独立的Go模块。

etcd为何采用这种模式?

  • 独立的版本演进与发布: 像client/v3这样的客户端库,其API稳定性和版本发布节奏可能与etcd服务器本身不同。将其作为独立模块,可以独立打版本标签(如client/v3.5.0),方便外部项目精确依赖特定版本的客户端。
  • 清晰的API边界与可引用性: 子模块化使得每个组件的公共API更加明确。外部项目可以直接go get etcd仓库中的某个子模块,而无需引入整个庞大的etcd主项目。
  • 更细粒度的依赖管理: 每个子模块只声明自己真正需要的依赖,避免了将所有依赖都集中在顶层go.mod中。

那么,一个Repo下有多个Go Module是Monorepo的一种形式吗? 答案是肯定的。这是一种更结构化、更显式地声明了内部模块边界和依赖关系的Monorepo形式(即便规模较小,内部的模块不多)。它们之间通常通过go.mod中的replace指令(尤其是在本地开发或特定构建场景)或Go 1.18引入的go.work工作区模式来协同工作。比如下面etcd/etcdutl这个子目录下的go.mod就是一个典型的使用replace指令的例子:

module go.etcd.io/etcd/etcdutl/v3

go 1.24

toolchain go1.24.3

replace (
    go.etcd.io/etcd/api/v3 => ../api
    go.etcd.io/etcd/client/pkg/v3 => ../client/pkg
    go.etcd.io/etcd/client/v3 => ../client/v3
    go.etcd.io/etcd/pkg/v3 => ../pkg
    go.etcd.io/etcd/server/v3 => ../server
)

// Bad imports are sometimes causing attempts to pull that code.
// This makes the error more explicit.
replace (
    go.etcd.io/etcd => ./FORBIDDEN_DEPENDENCY
    go.etcd.io/etcd/v3 => ./FORBIDDEN_DEPENDENCY
    go.etcd.io/tests/v3 => ./FORBIDDEN_DEPENDENCY
)

require (
    github.com/coreos/go-semver v0.3.1
    github.com/dustin/go-humanize v1.0.1
    github.com/olekukonko/tablewriter v1.0.7
    github.com/spf13/cobra v1.9.1
    github.com/stretchr/testify v1.10.0
    go.etcd.io/bbolt v1.4.0
    go.etcd.io/etcd/api/v3 v3.6.0-alpha.0
    go.etcd.io/etcd/client/pkg/v3 v3.6.0-alpha.0
    go.etcd.io/etcd/client/v3 v3.6.0-alpha.0
    go.etcd.io/etcd/pkg/v3 v3.6.0-alpha.0
    go.etcd.io/etcd/server/v3 v3.6.0-alpha.0
    go.etcd.io/raft/v3 v3.6.0
    go.uber.org/zap v1.27.0
)
//... ...

形态3:Google规模的Monorepo (The Google Way)

Google内部的超大规模Monorepo是业界典范,正如Rachel Potvin和Josh Levenberg在其经典论文《Why Google Stores Billions of Lines of Code in a Single Repository》中所述,这个单一仓库承载了Google绝大多数的软件资产——截至2015年1月,已包含约10亿个文件,900万个源文件,20亿行代码,3500万次提交,总计86TB的数据,被全球95%的Google软件开发者使用。

其核心特点包括:

  • 统一版本控制系统Piper: Google自研的Piper系统,专为支撑如此规模的代码库而设计,提供分布式存储和高效访问。
  • 强大的构建系统Blaze/Bazel: 能够高效地构建和测试这个庞大代码库中的任何目标,并精确管理依赖关系。
  • 单一事实来源 (Single Source of Truth): 所有代码都在一个地方,所有开发者都工作在主干的最新版本(Trunk-Based Development),避免了多版本依赖的困扰(如“菱形依赖问题”)。
  • 原子化变更与大规模重构: 开发者可以进行跨越数千个文件甚至整个代码库的原子化修改和重构,构建系统确保所有受影响的依赖都能同步更新。
  • 广泛的代码共享与可见性: 促进了代码复用和跨团队协作,但也需要工具(如CodeSearch)和机制(如API可见性控制)来管理复杂性。

Go语言的许多设计哲学,如包路径的全局唯一性、internal包的可见性控制、甚至早期的GOPATH模式(它强制所有Go代码在一个统一的src目录下,模拟了Monorepo的开发体验),都在不同程度上受到了Google内部这种开发环境的影响。

Google Monorepo的智慧:版本、分支与依赖管理的启示

虽然我们无法完全复制Google内部的庞大基础设施和自研工具链,但其在超大规模Monorepo管理上积累的经验,依然能为我们带来宝贵的启示:

  1. Trunk-Based Development (主干开发): Google绝大多数开发者工作在主干的最新版本。新功能通过条件标志(feature flags)控制,而非长时间存在的特性分支,这极大地避免了传统多分支开发模式下痛苦的合并过程。发布时,从主干切出发布分支,Bug修复在主干完成后,择优(cherry-pick)到发布分支。
  2. 统一版本与依赖管理: Monorepo的核心优势在于“单一事实来源”。所有内部依赖都是源码级的,不存在不同项目依赖同一内部库不同版本的问题。对于第三方开源依赖,Google有专门的流程进行统一引入、审查和版本管理,确保整个代码库中只有一个版本存在。这从根本上解决了“菱形依赖”等版本冲突问题。
  3. 强大的自动化工具链是基石:
    • 构建系统 (Bazel): 能够进行精确的依赖分析、增量构建和并行测试,是Monorepo高效运作的核心。
    • 代码审查 (Critique): Google文化高度重视代码审查,所有代码提交前都必须经过Review。
    • 静态分析与大规模重构工具 (Tricorder, Rosie): 自动化工具用于代码质量检查、发现潜在问题,并支持跨整个代码库的大规模、安全的自动化重构。
    • 预提交检查与持续集成: 强大的自动化测试基础设施,在代码提交前运行所有受影响的测试,确保主干的健康。

对我们的启示:

  • “单一事实来源”的价值: 即使不采用Google规模的Monorepo,在团队或组织内部,尽可能统一核心共享库的版本,减少不必要的依赖分歧,是非常有益的。
  • 自动化的力量: 投入自动化测试、CI/CD、代码质量检查和依赖管理工具,是管理任何规模代码库(尤其是Monorepo)的必要投资。
  • 主干开发与特性标志: 对于需要快速迭代和持续集成的项目,主干开发结合特性标志,可能比复杂的多分支策略更敏捷。
  • 对依赖的审慎态度: Google对第三方依赖的严格管控值得借鉴。任何外部依赖的引入都应经过评估。

企业级Go Monorepo的最佳实践:从理念到落地

当我们的组织或项目发展到一定阶段,特别是当多个Go服务/库之间存在紧密耦合、需要频繁协同变更,或者希望统一工程标准时,Monorepo可能成为一个有吸引力的选项。

以下是一些在企业环境中实施Go Monorepo的最佳实践:

  1. 明确采用Monorepo的驱动力与目标: 是为了代码共享?原子化重构?统一CI/CD?还是像我们接下来要讨论的“白盒交付”需求?清晰的目标有助于后续的设计决策。

  2. 项目布局与模块划分的艺术:

    • 清晰的顶层目录结构: 例如,使用cmd/存放所有应用入口,pkg/存放可在Monorepo内部跨项目共享的库,services/或components/用于组织逻辑上独立的服务或组件(每个服务/组件可以是一个独立的Go模块),internal/用于存放整个仓库共享但不对外暴露的内部实现。
    • 推荐策略:为每个可独立部署的服务或可独立发布的库建立自己的go.mod文件。 这提供了明确的依赖边界和独立的版本控制能力。
    • 使用go.work提升本地开发体验: 在Monorepo根目录创建go.work文件,将所有相关的Go模块加入工作区,简化本地开发时的模块间引用和构建测试。
  3. 依赖管理的黄金法则:

    • 服务级go.mod中的replace指令: 对于Monorepo内部模块之间的依赖,务必在依赖方的go.mod中使用replace指令将其指向本地文件系统路径。这是确保模块在Monorepo内部能正确解析和构建的关键,尤其是在没有go.work的CI环境或交付给客户时。
      // In my-org/monorepo/services/service-api/go.mod
      module my-org/monorepo/services/service-api
      go 1.xx
      require (
      my-org/monorepo/pkg/common-utils v0.1.0 // 依赖内部共享库
      )
      replace my-org/monorepo/pkg/common-utils => ../../pkg/common-utils // 指向本地
    • 谨慎管理第三方依赖: 定期使用go list -m all、go mod graph分析依赖树,使用go mod tidy清理,关注go.sum的完整性。使用govulncheck进行漏洞扫描。
  4. 版本控制与发布的规范:

    • 为每个独立发布的服务/库打上带路径前缀的Git Tag: 例如,为services/appA模块的v1.2.3版本打上services/appA/v1.2.3的Tag。这样,外部可以通过go get my-org/monorepo/services/appA@services/appA/v1.2.3来精确获取。
    • 维护清晰的Changelog: 无论是整个Monorepo的(如果适用),还是每个独立发布单元的,都需要有详细的变更记录。
  5. 分支策略的适配:

    • 可以考虑简化的Gitflow(主分支、开发分支、特性分支、发布分支、修复分支)或更轻量的GitHub Flow / GitLab Flow。关键是确保主分支(如main或master)始终保持可发布或接近可发布的状态。
    • 特性开发在独立分支进行,通过Merge Request / Pull Request进行代码审查后合入主开发分支。
  6. CI/CD的智能化与效率:

    • 按需构建与测试: CI/CD流水线应能识别出每次提交所影响的模块/服务,仅对受影响的部分进行构建和测试,避免不必要的全量操作。
    • 并行化: 利用Monorepo的结构,并行执行多个独立模块/服务的构建和测试任务。
    • 统一构建环境: 使用Docker等技术确保CI/CD环境与开发环境的一致性。

Go Monorepo与白盒交付:相得益彰的“黄金搭档”

现在,让我们回到一个非常具体的、尤其在国内甲方项目中常见的需求——白盒交付。白盒交付通常意味着乙方需要将项目的完整源码(包括所有依赖的内部库)、构建脚本、详细文档等一并提供给甲方,并确保甲方能在其环境中独立、可复现地构建出与乙方交付版本完全一致的二进制产物,同时甲方也可能需要在此基础上进行二次开发或长期维护。

在这种场景下,如果乙方的原始项目是分散在多个Repo中(特别是还依赖了乙方内部无法直接暴露给甲方的私有库),那么采用为客户定制一个整合的Monorepo进行交付的策略,往往能带来诸多益处:

  1. 解决内部私有库的访问与依赖问题:
    我们可以将乙方原先的内部私有库代码,作为模块完整地复制到交付给客户的这个Monorepo的特定目录下(例如libs/或internal_libs/)。然后,在这个Monorepo内部,所有原先依赖这些私有库的服务模块,在其各自的go.mod文件中通过replace指令,将依赖路径指向Monorepo内部的本地副本。这样,客户在构建时就完全不需要访问乙方原始的、可能无法从客户环境访问的私有库地址了。

  2. 提升可复现构建的成功率:

    • 集中的依赖管理: 所有交付代码及其内部依赖都在一个统一的Monorepo中,通过服务级的go.mod和replace指令明确了版本和本地路径,极大降低了因依赖版本不一致或依赖源不可达导致的构建失败。
    • 统一构建环境易于实现: 针对单一Monorepo提供标准化的构建脚本和Dockerfile(如果使用容器构建),比为多个分散Repo分别提供和维护要简单得多。
    • 结合-trimpath、版本信息注入等技巧,更容易在客户环境中构建出与乙方环境内容一致的二进制文件。
  3. 简化后续的协同维护与Patch交付:

    • 集中的代码基: 即使后续乙方仅以Patch形式向甲方提供Bug修复或功能升级,这些Patch也是针对这个统一Monorepo的特定路径的变更。甲方应用Patch、进行代码审查和版本追溯都更为集中和方便。
    • 清晰的项目布局与版本管理: 在Monorepo内部,通过良好的目录组织和为每个独立服务打上带路径前缀的版本标签,使得甲乙双方对代码结构、版本演进和变更范围都有清晰的认知。
  4. 便于客户搭建统一的CI/CD与生成SBOM:

    • 甲方可以在这个统一的Monorepo基础上,更容易地搭建自己的CI/CD流水线,并实现按需构建。
    • 为Monorepo中的每个独立服务生成其专属的软件物料清单(SBOM)也更为规范和便捷。

可见,对于复杂的、涉及多服务和内部依赖的Go项目白盒交付场景,精心设计的客户侧Monorepo策略,可以显著提升交付的透明度、可控性、可维护性和客户满意度。**

小结

Monorepo并非没有代价。正如Google的论文中所指出的,它对工具链(特别是构建系统)、版本控制实践(如分支管理、Code Review)、以及团队的协作模式都提出了更高的要求。仓库体积的膨胀、潜在的构建时间增加(如果CI/CD优化不当)、以及更细致的权限管理需求,都是采用Monorepo时需要认真评估和应对的挑战。Google为其Monorepo投入了巨大的工程资源来构建和维护支撑系统,这对大多数组织来说是难以复制的。

然而,在特定场景下——例如拥有多个紧密关联的Go服务、希望促进代码共享与原子化重构、或者面临像白盒交付这样的特殊工程需求时——Monorepo展现出的优势,如“单一事实来源”、简化的依赖管理、原子化变更能力等,是难以替代的。

Go语言本身的设计,从早期的GOPATH到如今Go Modules对工作区(go.work)和子目录模块版本标签的支持,都在逐步提升其在Monorepo环境下的开发体验。虽然Go不像Bazel那样提供一个“大一统”的官方Monorepo构建解决方案,但其工具链的灵活性和社区的实践,已经为我们探索和实施Go Monorepo提供了坚实的基础。

最终,Go项目是否应该拥抱Monorepo,并没有一刀切的答案。 它取决于项目的具体需求、团队的规模与成熟度、以及愿意为之投入的工程成本。但毫无疑问,理解Monorepo的理念、借鉴Google等先行者的经验(既要看到其优势,也要理解其巨大投入)、掌握etcd等项目的实践模式,并思考其在如白盒交付等现代工程场景下的应用价值,将极大地拓展我们作为Go开发者的视野,并为我们的技术选型和架构设计提供宝贵的参考。

Go的生态在持续进化,我们对更优代码组织和工程实践的探索也永无止境。


聊聊你的Monorepo实践与困惑

Go语言项目,是坚守传统的“一Repo一Module”,还是拥抱Monorepo的集中管理?你在实践中是如何权衡的?特别是面对etcd这样的多模块仓库,或者类似Google的超大规模Monorepo理念,你有哪些自己的思考和经验?在白盒交付场景下,Monorepo又为你带来了哪些便利或新的挑战?

AI 编码工具“真香”还是“智商税”?一位资深码农的“挑衅”与Go开发者的反思

本文永久链接 – 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 精进营”知识星球

img{512x368}

我们星球见!


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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats