Tony Bai - 一个程序员的心路历程

悄悄用 Go 重写 AI 基础设施：NVIDIA 的 GPU 云平台为何选择 Go？

五月 26, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/05/26/why-nvidia-chose-go-to-rewrite-their-ai-infrastructure

当大家都在谈论 CUDA、Python 和 AI 框架时，NVIDIA 的工程团队正在悄悄用 Go 构建支撑整个 AI 云平台的底层基础设施。从 GPU 函数平台 NVCF，到 AI 集群运行时 AICR，再到已经有 1.8k Star 的分布式存储 AIStore，Go 语言已经成为 NVIDIA 内部 AI 基础设施的核心技术栈。这不是偶然，而是一个精心设计的技术选型。

大家好，我是Tony Bai。

2026 年 4 月，NVIDIA 悄悄开源了一个 repo：github.com/nvidia/nvcf。

没有大张旗鼓的发布会，没有 Jensen Huang 的皮夹克登场。但如果你打开这个 repo 看一眼语言构成，数字会让你一惊：

Go 占比 88.5%。

这不是一个小工具，这是驱动 build.nvidia.com、NVIDIA DGX Cloud 推理服务和全球 GPU 云合作伙伴（CoreWeave、Oracle Cloud 等）整个控制平面的核心平台。

然后你再看 AICR（AI Cluster Runtime）：Go 51.1%。

再看 AIStore（面向 AI 的分布式存储）：Go 75.2%，1.8k Star，10,219 次 commit，是一个有深度的系统级项目。

NVIDIA 在用 Go 构建 AI 时代的基础设施。而且这个趋势正在加速。

NVCF：GPU 云函数平台的全面开源

它是什么

NVCF 全称 NVIDIA Cloud Functions，是一个用于部署、管理和运行 GPU 加速工作负载的平台。你可以把它理解为”GPU 版的 AWS Lambda”——但更贴近生产级 AI 推理场景的设计。

你注册一个 Docker 容器或 Helm Chart，指定 GPU 类型，NVCF 负责处理一切：路由、队列、自动扩缩容、多租户隔离。GPU 云合作商在自己的 Kubernetes 集群上运行 NVIDIA Cluster Agent（NVCA），算力接入 NVCF 控制平面。

2026 年 4 月，NVIDIA 以 Apache 2.0 协议开源了整个平台的完整代码，包括控制平面、调用平面、计算平面、CLI、Helm Charts 和数据库迁移脚本——全部在一个 monorepo 里。之前的 NVIDIA/nvidia-cloud-functions 和 NVIDIA/nvcf-go 两个 repo 已归档，这个新 repo 是唯一的真相来源。

三平面架构：Go 是粘合剂

NVCF 的整体架构围绕三个独立可扩展的平面展开，通过 NATS JetStream 连接。

控制平面（Control Plane）

运行在专用 Kubernetes 集群上，负责函数生命周期管理、自动扩缩容决策和密钥管理。核心服务：

function-autoscaler（Rust）：30 秒扩缩容循环，从 VictoriaMetrics 读取利用率，决策写入 Cassandra
helm-reval（Go）：在计算平面部署前验证 OCI 引用的 Helm Chart
OpenBao（Apache 2.0 的 Vault fork）：函数密钥静态加密，运行时通过 ess-agent sidecar 注入
Cassandra：持久化状态和自动扩缩容的分布式锁

调用平面（Invocation Plane）

所有请求的必经之路，Go 在这里是绝对主角：

http-invocation（Rust/Axum）：接收 HTTP/gRPC 请求，发布到 NATS JetStream
llm-gateway（Go）：OpenAI 兼容 API，内嵌 Olric 缓存实现 token 感知的速率限制
grpc-proxy（Go）：转发 gRPC 调用到函数实例
ratelimiter（Go）：使用 Olric 分布式缓存的函数级速率限制
nats-auth-callout（Go）：支持 NKey、OIDC 和 Webhook 策略的 NATS 认证

计算平面（Compute Plane）

每个 GPU 集群运行一个 NVCA（NVIDIA Cluster Agent）Operator。NVCA 将集群注册到控制平面，消费 NATS 消息，管理 Pod 生命周期。

一次请求的完整生命周期

从调用方的 POST /v2/nvcf/pexec/functions/{id} 开始，到响应返回，完整链路如下：

http-invocation 检查速率限制（via ratelimiter gRPC）
请求发布到 NATS stream: Create.NVCA..{clusterID}..*
NVCA queue manager 消费消息
创建 ICMSRequest Kubernetes CR（通过 NATS sequence 去重）
MiniService controller 协调：创建 Pod 或应用 Helm Chart
函数 Pod 通过 WorkerService gRPC 回连：ConnectOnce
响应返回调用方
完成时：Terminate.NVCA.{clusterID} 触发 Pod 删除和 GC

Scale-to-Zero 的关键设计：NATS 作为持久化请求缓冲区

NVCF 解决的最有趣的工程问题，是 GPU 工作负载的 Scale-to-Zero。

传统方案（如 Knative）在 Scale-up 期间请求会面临超时压力或重试。对于加载大型模型可能需要数十秒乃至数分钟的 GPU 推理来说，这个问题会非常严重。

NVCF 的解法是把 NATS JetStream 当做一个持久化请求缓冲区：

自动扩缩容器将期望实例数降为 0，没有 Pod 运行
新请求到达，发布到 NATS JetStream，消息被持久化
自动扩缩容器检测到队列深度 > 0，将期望实例数提升到 1+
NVCA 收到创建消息，启动 Pod
Pod 通过 WorkerService gRPC 连接，拉取缓冲的消息
响应通过一直保持打开状态的 http-invocation 连接返回

请求永远不会被丢弃。 调用方在冷启动时等待更长时间，但请求一定会完成。这是 NATS 持久化消息的直接价值。

AICR：AI 集群运行时，Go 写的”集群配方书”

为什么需要 AICR

搭建一个 GPU 加速的 Kubernetes 集群是出了名的难。内核版本、驱动、容器运行时、Operator、Kubernetes 版本——任何一个环节的细微差异都可能导致难以诊断的问题，而且极难复现。

这些知识以前只存在于 NVIDIA 内部的验证流水线和运维手册里。AICR 把这些知识公开了。

项目地址：github.com/NVIDIA/aicr

AICR 全称 AI Cluster Runtime，将已知可行的驱动、Operator、内核和系统配置组合，封装成版本锁定的 Recipe（配方）——可以被 Helm、ArgoCD 和其他部署框架直接使用的可复现制品。

核心概念：Recipe 系统

一个 Recipe 是针对特定环境的版本锁定配置。你描述你的目标（云厂商、GPU 型号、操作系统、工作负载意图），Recipe 引擎将其与一个经过验证的 Overlay 库进行匹配——从基础默认值到云厂商、加速器、操作系统、工作负载特定调优，自底向上分层组合。

每个 AICR Recipe 具备三个特性：

Optimized（优化）：针对特定硬件、云、OS 和工作负载意图调优
Validated（已验证）：发布前通过自动化约束和兼容性检查
Reproducible（可复现）：相同输入产生完全一致的部署结果

CLI 展示：五分钟上手

# 安装 CLI（Go 编译的单一二进制）
curl -sfL https://raw.githubusercontent.com/NVIDIA/aicr/main/install | bash -s --

# 采集集群当前状态快照
aicr snapshot --output snapshot.yaml

# 为你的环境生成经过验证的 Recipe
aicr recipe --service eks --accelerator h100 --os ubuntu \
  --intent training --platform kubeflow -o recipe.yaml

# 对比 Recipe 与集群实际状态，找出差异
aicr validate --recipe recipe.yaml --snapshot snapshot.yaml

# 渲染为部署就绪的 Helm Charts
aicr bundle --recipe recipe.yaml -o ./bundles

bundles/ 目录包含按组件分类的 Helm Chart，每个组件附带 values 文件、checksum 和 README。你可以用 helm install 部署，提交到 GitOps 仓库，或使用内置的 ArgoCD 部署器。

安全供应链：SLSA Level 3

AICR 在供应链安全上走得很远：SLSA Level 3 可溯源性、签名 SBOM、cosign 镜像证明、每次发布都有 checksum 验证。这已经是不少大型企业对内部工具的要求，NVIDIA 在开源项目里直接做到了。

技术栈细节

代码以 Go 为主（51.1%），使用 golangci 做 lint，goreleaser 做发布，ko 做容器镜像构建。项目已经发布了 54 个版本，活跃度很高。目前支持 Amazon EKS、GKE 和 Kind（自管理），GPU 覆盖 H100 和 GB200，工作负载支持 Kubeflow 训练和 Dynamo 推理。

AIStore：完全用 Go 写的 AI 分布式存储

如果说 NVCF 和 AICR 还是相对新鲜的项目，那 AIStore 则是一个已经经受了时间考验的系统级工程——1.8k Star，240 个 Fork，10,219 次 commit，46 位贡献者。

项目地址：github.com/NVIDIA/aistore

核心定位

AIStore（AIS）是一个专为 AI 应用构建的轻量分布式存储栈。它是一个弹性集群，可以在运行时扩缩容，支持从单台 Linux 机器到任意规模的裸机集群的任意部署方式。

AIS 的核心差异点：它能原生操作集群内数据和远程数据，而不是把远程数据当成缓存。这对 AI 训练工作负载来说是关键区别——你不需要先把 S3 数据拉下来再训练，AIS 可以透明地处理数据层。

技术亮点一览

多云后端支持：无缝访问 AWS S3、GCS、Azure、OCI，支持跨账号、跨 endpoint 的同名 bucket 共存。
线性扩展性：官方博客和 KubeCon 演讲中展示了跨任意数量集群节点的均衡 I/O 分布和线性扩展能力。
ETL Offload：在数据附近执行 I/O 密集型数据转换，可以内联（作为每次读请求的一部分实时处理）或离线（批量处理，结果写入目标 bucket）。
Get-Batch：单次调用检索多个对象或归档文件。专为 ML/AI 流水线设计，一次操作获取整个训练批次，按用户指定的顺序组装成 TAR（或其他序列化格式）。这个功能甚至有配套的 arxiv 论文（2602.22434）。
负载感知节流：基于多维度负载向量（CPU、内存、磁盘、文件描述符、goroutine）的动态请求节流，保护 AIS 集群在压力下的稳定性。
30+ 批处理操作：包括 archive、blob-download、copy-bucket、dsort、etl-bucket、lru-eviction、rebalance、rechunk 等，全部可以通过 CLI 启动、监控和控制。

为什么用 Go

AIStore 75.2% 的代码是 Go，其 Go API 直接被 CLI 和 benchmarking 工具使用。选择 Go 的逻辑很清晰：

系统级性能：Go 的 goroutine 模型天然适合高并发 I/O 密集型工作负载，而分布式存储正是这种场景
单一二进制发布：CLI 工具和服务端都能编译成静态链接的单一二进制，部署极其简单
生态成熟：Kubernetes operator、gRPC、NATS、Prometheus——这些基础设施领域的核心库在 Go 生态中都有成熟实现
代码可维护性：相比 C++，Go 在保持接近底层性能的同时大幅降低了复杂系统的维护成本

为什么是 Go？NVIDIA 的技术选型逻辑

把这三个项目放在一起看，NVIDIA 选择 Go 的逻辑变得清晰：

AI 基础设施的特殊需求

AI 基础设施不同于传统 Web 服务。它需要处理：

GPU 资源的精细调度和隔离
大规模并发请求的队列管理
跨多集群的协调
模型文件的海量 I/O
长时间运行的异步任务

这些场景对并发模型的要求极高。Go 的 goroutine 和 channel 机制，让工程师可以用清晰的代码表达复杂的并发逻辑，而不需要像 C++ 那样手动管理线程。

云原生生态的”母语”

Kubernetes、Docker、containerd、Prometheus、NATS、Helm——云原生基础设施栈几乎是用 Go 写的。NVIDIA 的三个项目全部深度集成 Kubernetes，深度依赖 Operator 模式、Controller Runtime、Helm Chart。选择 Go 意味着可以直接使用这些生态的核心库，而不是跨语言调用的额外复杂度。

运维友好的单一二进制

aicr、ais CLI 工具都是 Go 编译的单一静态二进制。在需要快速部署到新集群、在 CI/CD 流水线中运行、或者在边缘节点上操作时，这个特性极其实用。

Rust + Go 的互补分工

值得注意的是，NVCF 并不是全 Go。高性能热路径（http-invocation、function-autoscaler）用了 Rust，而控制逻辑、网关、代理、认证——这些需要快速迭代、逻辑清晰的组件——用 Go。

这个分工很有意思：Rust 负责极致性能的关键路径，Go 负责需要快速演化的系统逻辑。两种语言各司其职，而不是用一种语言通吃所有场景。

小结：这意味着什么

对 Go 开发者

NVIDIA 的这几个 repo 是绝佳的真实世界大型 Go 项目参考：

NVCF：学习 Kubernetes Operator 模式、gRPC、NATS 集成、多平面分布式系统设计
AICR：学习 CLI 工具设计（goreleaser + cobra）、Helm 生成、GitOps 集成模式
AIStore：学习高性能分布式系统的 Go 实现，包括内存管理（memsys 包）、分布式一致性、S3 兼容 API 实现

这三个项目都是 Apache 2.0 或 MIT 开源，代码质量高，有完整的测试和文档。

对 AI 平台工程师

NVIDIA 正在开源 AI 基础设施的核心组件。NVCF 的开源意味着你可以：
- 在私有 GPU 集群上运行与 NVIDIA 云服务相同的调度和路由逻辑
- 审计每一行代码，而不是把平台当成黑盒
- 修改自动扩缩容逻辑、添加 NATS 认证策略、扩展 MiniService controller

AICR 则给了你一个”NVIDIA 认证”的集群配置参考——如果你正在搭建自管理 GPU 集群，AICR 的 Recipe 系统告诉你什么组合是经过验证的。

对技术决策者

当 NVIDIA——一家以 CUDA C++ 闻名的公司——在 AI 基础设施层面系统性地选择 Go，这个信号足够强烈。Go 已经不只是”Google 的语言”或者”云原生工具链的语言”，它正在成为 AI 时代基础设施的核心技术栈之一。

资料链接：

https://blog.kubesimplify.com/nvcf-is-now-open-source-inside-nvidia-s-gpu-function-platform
https://github.com/nvidia/nvcf
https://github.com/NVIDIA/aicr NVIDIA AI Cluster Runtime
https://github.com/NVIDIA/aistore AIStore: scalable storage for AI applications

还在为写 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}

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

Shopify 23,000 名工程师背后的 Claude Code 配置方案（你可以直接复刻的完整配置）

五月 24, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/05/24/shopify-claude-code-configuration-for-23000-engineers

大家好，我是Tony Bai。

这篇来自 X (Twitter) 的深度好文剖析了 Shopify 如何通过 Claude Code 实现工程效率的飞跃。文章不仅分享了其 23,000 名工程师背后的核心配置逻辑，还详细介绍了从并行智能体（Agents）到 MCP 工具包，再到“策略优先”的工作流转型。如果你正在思考如何将 AI 真正集成到团队的开发流水线中，这份来自“未来视角”的 AI 原生工程实践手册（AI-first playbook）绝对值得深入研读与复刻。下面是文章译文全文：

Shopify 的 23,000 名工程师正致力于在今年第三季度实现 96% 的代码自动化。

他们同时运行多个 Claude Code 智能体，每个智能体处理代码库的不同部分，而工程师只需进行审查和合并。

Bessemer 发布了他们完整的 AI 优先手册。

以下是他们的确切配置，你可以在 5 分钟内完成复刻。

基础设施层（为什么他们的配置能奏效）

Shopify 没有标准化某一个 AI 工具。他们标准化了底层的架构。

他们构建了一个内部 LLM 代理（Proxy），将每一个 AI 请求路由到同一个网关。无论使用 Claude Code、GitHub Copilot 还是 Cursor，它们都流经相同的基础设施。

Shopify 的 LLM 代理架构：

工程师 -> Claude Code / Copilot / Cursor
          ↓
      LLM 代理 (集中式网关)
          ↓
      OpenAI / Anthropic / Google 模型
          ↓
      使用分析 + 成本控制 + 模型路由

这赋予了他们集中式的成本控制、使用分析，以及在不改变任何工程师工作流的情况下更换模型的能力。

给小团队的启示： 不要只选一个工具就全力投入。先构建基础设施，这样你就可以在保持对成本和数据控制的同时，试验不同的工具。

模式 1：并行智能体，而非单一对话

Shopify 的资深工程师不会把 Claude Code 当作一个简单的“提问-回答”工具。

他们会同时启动多个智能体，在代码库的不同部分工作。

一个智能体负责重构认证模块。另一个负责编写测试。第三个更新文档。工程师负责审查输出，丢弃无效内容，合并有效内容。

bash 示例：

# 终端 1：负责重构认证的智能体
claude -p "refactor src/auth/ to use the new session handler"

# 终端 2：负责编写测试的智能体
claude -p "write integration tests for the payment flow"

# 终端 3：负责更新文档的智能体
claude -p "update API documentation for all changed endpoints"

工程师的工作职责从“写代码”转变为“审查和合并”智能体的输出。Shopify 工程副总裁 Farhan Thawar 将此称为“编排智能系统”。

模式 2：扩展批判循环 (Extended critique loops)

并非每个任务都能受益于并行化。对于复杂的架构决策，Shopify 工程师会让单个智能体运行扩展的批判循环。

智能体生成一个答案，评估它，修改它，并在漫长的推理周期中继续精炼。

他们不接受第一次输出，而是强迫智能体自我辩论。

提示词模式：

“针对 [X] 提出一个架构方案。
然后批判你自己的提议：在规模化(scaling)时会出现什么问题？
根据你的批判进行修改。
再次批判该修订版。
给出最终版本，并附带每个决策的置信度水平。”

这种方式产生的结果比单一提示词好得多，因为 Claude 在你发现错误之前就已经抓住了自己的错误。

模式 3：Shopify AI 工具包 (MCP)

在 2026 年 4 月，Shopify 发布了一个开源的 MCP (Model Context Protocol) 服务器，将 Claude Code 直接连接到 Shopify 的文档、GraphQL API 模式和在线商店操作。

只需一条命令即可安装：

claude mcp add --transport stdio shopify-dev-mcp -- npx -y @shopify/dev

这赋予了 Claude Code 7 种工具：

根据实时模式验证 GraphQL 查询
通过 Shopify CLI 执行商店操作
创建产品、管理元字段（metafields）、修改主题
用自然语言运行批量操作

如果没有这些，Claude 会产生幻觉、臆造 API 字段或组件模式。有了它，Claude 能够处理真实的平台数据。

模式 4：CLAUDE.md 作为团队基础设施

Shopify 不把 CLAUDE.md 视为个人配置，它是提交到 Git 并供 23,000 名工程师共享的团队基础设施。

他们的方案示例：

# CLAUDE.md (Shopify internal pattern)

## Stack
Ruby on Rails, React, GraphQL, MySQL

## Commands
- Dev: dev up && dev server
- Test: dev test [path]
- Lint: dev style
- Type check: bin/srb tc

## Architecture
- app/models/ → ActiveRecord models, business logic
- app/controllers/ → thin controllers, delegate to services
- app/services/ → service objects for complex operations
- app/graphql/ → GraphQL types, mutations, resolvers

## Rules
- NEVER bypass Sorbet type checking
- All new code must have type signatures
- Database queries only through established patterns
- IMPORTANT: run dev test after every change

来自会议的核心见解：在 CLAUDE.md 中塞入每一个标准和规范会让性能变差，而非变好。你在每一个环节都要为此付出代价。

模式 5：策略优先的验证

这是 Shopify 的方法与其他团队最不同的地方。

在 2024 年，工程师将 70% 的时间花在执行（写代码）上，30% 花在策略上。

在 2026 年，Shopify 翻转了这个比例。

因为 AI 处理了大部分编码工作，工程师现在将 70% 的时间花在策略上：映射用户流、验证市场需求、选择正确的架构。只有 30% 的时间花在执行上。

工作流对比：

2024 工作流： 策略: 30% → 执行: 70%
2026 工作流 (Shopify)： 策略: 70% → 执行: 30%

AI 编写代码。人类负责决定代码存在的意义。

模式 6：带护栏的安全自主性

Shopify 不会让智能体野蛮生长。他们的Claude Code 护栏设置如下：

json 示例：

{
  "permissions": {
    "allow": [
      "Read", "Glob", "Grep", "LS", "Edit",
      "Bash(dev test *)",
      "Bash(dev style *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git add *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Read(**/.env*)",
      "Bash(git push *)",
      "Bash(dev deploy *)",
      "Bash(bin/rails db:drop *)",
      "Bash(rm -rf *)"
    ],
    "defaultMode": "acceptEdits"
  }
}

智能体可以读取、编写、测试、重构和提交。它们不能推送到远程仓库、部署到生产环境、删除数据库或读取密钥。

人类在任何不可逆的操作中保持参与。

你今天就能复刻的配置

你不需要 23,000 名工程师来使用这些模式。以下是初学者版本：

步骤 1：标准化你的 CLAUDE.md
保持在 60 行以内。包含技术栈、命令、架构和规则。提交到 Git，与团队共享。
步骤 2：设置并行智能体
针对大型任务，在独立的终端运行 2-3 个智能体，每个工作在代码库的不同部分。
步骤 3：安装相关的 MCP 服务器
连接你日常使用的工具栈（GitHub, Slack, 数据库等）。
步骤 4：添加护栏
允许：read, write, test, lint, commit。
拒绝：push, deploy, delete, secrets。
步骤 5：翻转比例
停止将 70% 的时间花在执行上。让智能体写代码。把时间花在决定哪些代码应该存在上。

最重要的数字

Shopify 20% 的生产力提升并非来自编写更多的代码，而是来自探索 10 种方案而非 2 种、更快的原型设计以及捕捉错误。

最能发挥 Claude Code 价值的团队不是那些拥有最强提示词的团队，而是那些构建了基础设施，让智能体能够安全、并行、在真实代码库上工作的团队。

2026 年第三季度实现 90% 的自主编码。 这不是愿景宣言，而是 23,000 名工程师正在努力达成的最后期限。

今日互动探讨：

Shopify 提出的 “70% 策略 + 30% 执行” 模型，预示着程序员的定义正在发生根本性位移：从“写代码的人”变成“编排智能的人”。

面对这种“AI 自动驾驶”式的开发工作流，我想听听你的看法：

你准备好了吗？ 如果明天起 70% 的代码都由 AI 并行完成，你认为自己最核心的“策略价值”会体现在哪里？
最大的担忧是什么？ 是担心代码库变得臃肿无法维护，还是担心初级工程师（Junior）在缺乏“手写代码”锻炼后难以成长？
现状调研： 你现在的日常工作中，写代码的时间占比是多少？你是否尝试过同时开启多个 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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

img{512x368}

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