Git Worktrees for AI Development
TL;DR · AI 摘要
Git Worktrees for AI Development - KDnuggets publ: 17-Jul, 2026 - Blog Top Posts About - Topics AI Career Advice Compute...
核心要点
- 主题聚焦:Git Worktrees for AI Development
- 来源:KDnuggets,建议结合原文判断细节。
- AI 分析暂不可用,本条为保底评分与摘要。
AI开发中的Git工作树 - KDnuggets
publ: 2026年7月17日
- 博客热门文章
- 话题 AI 职业建议 计算机视觉 数据工程 数据科学 语言模型 机器学习 MLOps NLP 编程 Python SQL
- 数据集
- 活动
- 资源 快速参考指南 推荐 技术简报
- 广告
订阅简报
#header end
/ad_wrapper
AI开发中的Git工作树
Git工作树是从同一仓库中检出的独立目录。你可以根据需要创建任意数量的工作树,每个工作树位于自己的分支上,所有工作树可以同时共存于文件系统中。
作者:Shittu Olumide,技术内容专家 2026年7月17日发布于 编程
<div class="addthis_native_toolbox"></div>
# 引言
你正在特性分支上运行Claude Code。代理已经工作了二十分钟,它已经阅读了你的代码库,建立了上下文,并开始对认证重写进行实质性进展。这时Slack消息弹出:生产环境崩溃了,有人需要在main分支上进行热修复,而且必须立即处理。
在旧的工作流程中,你需要先暂存更改,切换分支,丢失AI代理构建的所有内容,修复漏洞,推送代码,切换回原分支,然后花费十分钟让代理重新理解之前的工作。如果你同时在同一个目录中运行两个代理,情况会更糟——两个代理同时修改package.json,对相同文件生成编辑,第二个代理会静默覆盖第一个代理的修改。没有警告。没有错误。只有在测试失败时,你才会在一小时后发现莫名其妙的损坏工作。
Git工作树消除了这类问题。这不是新发明——该功能自2015年Git 2.5版本发布以来就已存在——但2025-2026年的AI编码浪潮使其成为基础设施的关键部分。一个.git目录,多个工作目录,每个工作目录位于自己的分支上,彼此互不可见。每个AI代理都有自己的隔离工作区。热修复也有自己的工作区。没有任何冲突。
目前51%的专业开发者每天使用AI工具,但只有17%使用AI代理的开发者表示这些工具提升了团队协作。这两个数字之间的差距不是工具问题,而是基础设施问题。团队在没有底层工作流支持的情况下就采用了AI代理。本指南就是这个工作流层。
到文章结束时,你将了解什么是工作树,如何设置它们,如何在其中并行运行AI代理而不产生混乱,以及如何在整个项目生命周期中维护它们。
# Git工作树的本质
标准的Git仓库只有一个工作目录——存放文件并进行代码编辑的文件夹。要处理不同分支,你需要切换分支,这会将该目录中的所有文件更改为此分支的内容。如果你有未提交的工作,需要先进行暂存。如果AI代理正在执行任务,你需要中断它。
Git工作树打破了这个限制。工作树是从同一仓库中检出的独立目录。你可以根据需要创建任意数量的工作树,每个工作树位于自己的分支上,所有工作树可以同时共存于文件系统中。
my-project/ ← 主工作树 (分支: main)
my-project-feat-auth/ ← 链接工作树 (分支: feat/auth)
my-project-feat-api/ ← 链接工作树 (分支: feat/api)
my-project-hotfix-login/ ← 链接工作树 (分支: hotfix/login)所有四个目录共享同一个 .git 文件夹。它们共享历史记录、对象和提交。但每个目录都有自己的已检出文件、自己的索引以及自己的工作状态。在 my-project-feat-auth/ 目录中编辑文件的代理无法看到或操作 my-project-feat-api/ 中的任何内容。它们是物理上独立的目录,恰好共享同一个 Git 后端。
为什么这种方法比多次克隆更优?工作树(worktree)的朴素替代方案是将仓库克隆两次并在不同的克隆目录中工作。这虽然可行,但存在实际成本:你需在磁盘上复制整个仓库,克隆之间不共享 Git 历史记录,一个克隆中的提交不会立即在另一个克隆中可见,且克隆之间在 Git 层没有协调。使用工作树时,你只需克隆一次。每个额外的工作树仅增加已检出文件的成本,而不是再次复制完整的提交历史。
涵盖管理工作树所需所有操作的七条命令:
| 命令 | 功能 | |------|------| | git worktree add <path> -b <branch> | 在新分支上创建新工作树 | | git worktree add <path> <existing-branch> | 将现有分支检出到新工作树 | | git worktree list | 显示所有活动工作树及其分支和提交哈希 | | git worktree lock <path> | 防止工作树被修剪(在代理运行时有用) | | git worktree unlock <path> | 释放锁 | | git worktree remove <path> | 清洁删除工作树(保留分支) | | git worktree prune | 清理被手动删除的工作树的元数据 |
这就是完整的功能范围。本文其余内容都是基于这七条命令构建的工作流。
# 初始化设置
先决条件:Git 2.5 或更高版本。运行 git --version 检查版本。任何现代系统(macOS、Linux、带 WSL 或 Git Bash 的 Windows)都自带高于 2.5 的版本。
#### // 步骤 1:从干净的仓库开始
当主分支干净时,工作树效果最佳。在创建第一个工作树前,请提交或暂存任何未完成的工作。
# 确认工作树是干净的
git status
# 如果有未提交的修改,提交它们
git add . && git commit -m "checkpoint: work in progress"#### // 步骤 2:创建第一个工作树
# 在 ../myapp-feat-auth 路径下创建新分支 feat/auth 的工作树
# 将 "myapp" 替换为你的项目名,"feat/auth" 替换为你的分支名
git worktree add -b feat/auth ../myapp-feat-auth main
# 验证是否创建成功
git worktree list你应该看到类似以下的输出:
/home/user/myapp abc1234 [main]
/home/user/myapp-feat-auth abc1234 [feat/auth]两个目录都存在,且都包含主分支的相同文件。从此时起,你在 myapp-feat-auth/ 目录中做的任何修改都会保留在 feat/auth 分支,并与 main 完全隔离。
#### // 步骤 3:在新工作树中设置环境
这是大多数教程会跳过的步骤。工作树是一个新的工作目录,它不会自动包含你的 .env 文件、已安装的 node_modules 或 Python 虚拟环境。你需要显式设置这些内容。
cd ../myapp-feat-auth
# 复制被git忽略的环境文件
# .env、.env.local等文件不会被git跟踪 --
# 它们不会自动出现在新的工作树中
cp ../myapp/.env .env
cp ../myapp/.env.local .env.local 2>/dev/null || true
# Node.js项目:安装依赖
# 每个工作树都是独立的工作目录 --
# 父目录的node_modules不会自动继承
npm install
# Python项目:创建并激活虚拟环境
# python -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt#### // 步骤4:验证工作树的隔离性
# 在新工作树内部
git branch
# 应显示:* feat/auth
# 做一个测试修改
echo "// test" >> test-isolation.js
git status
# 仅显示当前工作树的修改
# 切换到主目录并验证未受影响
cd ../myapp
git status
# 状态干净 -- test-isolation.js的修改在此不可见
ls test-isolation.js 2>/dev/null || echo "此处没有 -- 隔离性已确认"至此,你已具备开始工作的所有条件。工作树已就绪。在该目录下打开的任何代理(agent)都仅作用于feat/auth分支。
# 实际案例研究
git worktree用于AI驱动并行开发的最清晰记录案例来自微软全球黑客松2025。
作为工程负责人,Tamir Dresher面临所有AI代理开发者最终都会遇到的问题:功能太多、时间太少,且无法在不频繁切换上下文的情况下同时处理多个任务。创建多个仓库克隆过于繁琐。切换分支会破坏AI代理的上下文。必须有所改变。
解决方案是使用git worktree创建Dresher所描述的虚拟AI开发团队。每个功能都有自己的工作树。每个工作树都有自己的VS Code窗口。每个窗口运行自己的AI代理。Dresher的角色从开发者转变为技术负责人:定义任务范围、审查输出、指导陷入困境的代理,并合并完成的工作。
该设置如下所示:
myapp/ ← 主窗口:协调与审查
myapp-feat-authentication/ ← 代理1:实现OAuth2流程
myapp-feat-api-endpoints/ ← 代理2:构建REST端点
myapp-bugfix-login-crash/ ← 代理3:修复生产环境登录崩溃每个VS Code窗口完全独立。语言服务器、代码检查器和测试运行器按窗口独立运行。代理之间不会互相访问对方文件。当代理1完成工作后,Dresher审查差异,批准后从该分支发起拉取请求(PR)——这与审查人类工程师的PR流程完全相同。
Dresher在黑客松中记录的三个具体优势:
- 无上下文丢失。每个AI代理都完整保留其特定任务的上下文。切换功能只需切换VS Code窗口,而非分支、stash或重启代理。代理对其正在构建内容的理解始终保持完整。
- 不同任务使用不同工具。由于每个窗口独立,Dresher在一个窗口使用Roo进行快速功能开发,在另一个窗口使用Visual Studio配合GitHub Copilot调试复杂问题。跨任务混合使用工具变得轻而易举。
- 清晰的分支管理。如果某个功能需要废弃,关闭窗口并删除工作树仅需10秒。其他代理完全不受影响。
该模式现已在AI编码社区中被记录为最佳实践。
# 使用工作树并行运行AI代理
完整并行工作流的机制分为四个阶段:设置工作树、为每个代理提供上下文、运行代理、定期检查点。
#### // 阶段1:脚本化工作树创建
不要每次手动创建工作树。脚本可以确保每个工作树获得相同的初始设置——环境文件、依赖项安装和干净的起点。
前提条件:Git 2.5+,Bash(macOS/Linux/WSL)
运行方式:将脚本保存为项目根目录下的create-worktree.sh,运行chmod +x create-worktree.sh,然后执行./create-worktree.sh feat/auth-redesign main
#!/usr/bin/env bash
# create-worktree.sh
# 为一个AI代理任务创建独立的工作树
# 用法:./create-worktree.sh
[base-branch]
# 示例:./create-worktree.sh feat/auth-redesign main
set -euo pipefail
BRANCH="${1:?Usage: $0
[base-branch]}"
BASE="${2:-main}"
REPO_ROOT="$(git rev-parse --show-toplevel)"
REPO_NAME="$(basename "$REPO_ROOT")"
# 将分支名中的斜杠替换为连字符用于目录命名
# feat/auth-redesign 变为 feat-auth-redesign
WORKTREE_PATH="${REPO_ROOT}/../${REPO_NAME}-${BRANCH//\//-}"
echo "为分支创建工作树: $BRANCH"
echo "基准分支: $BASE"
echo "工作树路径: $WORKTREE_PATH"
# 获取最新代码使新分支从当前远程状态开始
git fetch origin 2>/dev/null || echo "(无远程仓库--跳过获取)"
# 从基准分支创建新分支的工作树
# 如果 -b 失败则回退到检出现有分支
git worktree add -b "$BRANCH" "$WORKTREE_PATH" "$BASE" 2>/dev/null || \
git worktree add "$WORKTREE_PATH" "$BRANCH"
# 复制未跟踪的环境文件到工作树
# 这些文件被.gitignore忽略,因此不会自动继承
for f in .env .env.local .env.development .env.test; do
if [ -f "$REPO_ROOT/$f" ]; then
cp "$REPO_ROOT/$f" "$WORKTREE_PATH/$f"
echo "已复制 $f"
fi
done
# Node.js: 在新工作目录中安装依赖
if [ -f "$WORKTREE_PATH/package.json" ]; then
echo "安装Node依赖..."
(cd "$WORKTREE_PATH" && npm install --silent 2>/dev/null || \
echo "(跳过npm install--在工作树中手动运行)")
fi
# Python: 提醒开发者设置环境
if [ -f "$WORKTREE_PATH/requirements.txt" ] || [ -f "$WORKTREE_PATH/pyproject.toml" ]; then
echo "检测到Python项目。"
echo "在新工作树中运行:"
echo " python -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt"
fi
echo ""
echo "工作树已准备就绪。在IDE中打开它并启动你的代理:"
echo " cd $WORKTREE_PATH"此脚本的作用:创建工作树,复制被.gitignore忽略的环境文件(最常见的设置失败情况),并在新目录中运行依赖项安装。${BRANCH//\//-}替换将类似feat/auth的分支名转换为文件系统友好的目录名feat-auth。第23行的回退处理远程分支已存在的情况。
#### // 阶段2:设置AGENTS.md上下文文件
为提升代理输出质量,最重要的一件事是为每个代理提供清晰的书面上下文文件。ICSE 2026的同行评审研究证实,将架构文档纳入代理上下文可显著提升功能正确性、架构符合性和代码模块化程度。AGENTS.md文件是您在所有会话中可靠、大规模传递上下文的方式。
在项目根目录创建此文件并提交。每个代理在会话启动时都会读取它。不同工具读取不同文件名——AGENTS.md(OpenAI Codex)、CLAUDE.md(Claude Code)、AGENTS.md(通用)——但内容比文件名更重要。
# AGENTS.md
# AI编码代理的项目上下文
# 提交到仓库根目录
# 每个打开此项目的代理都会首先读取此文件
## 项目概览
Node.js/TypeScript REST API搭配React前端
技术栈:Node 20,Express 5,Prisma ORM,PostgreSQL,React 18,Vite
## 构建与测试命令
npm run dev # 在3000端口启动开发服务器
npm run build # 构建生产版本到dist/
npm run test # 运行所有测试(Vitest)
npm run test:watch # 监听模式
npm run lint # ESLint和Prettier检查
npm run db:migrate # 运行待处理的Prisma迁移
npm run db:seed # 种子开发数据
## 架构
- API路由: src/routes/ 每个资源一个文件
- 业务逻辑: src/services/ 从不在路由处理程序中
- 数据库访问: src/repositories/ 从不直接在服务中调用Prisma
- 共享类型: src/types/index.ts
## 规范
- 所有导出函数需要JSDoc注释
- 提交代码中禁止使用console.log -- 使用src/utils/logger.ts
- 错误处理:从服务中抛出类型化错误,在路由处理程序中捕获
- 分支命名:feat/, fix/, refactor/
## 禁止修改区域 -- 除非明确指示否则不要修改
- src/auth/ (安全团队所有,独立审核流程)
- prisma/migrations/ (仅通过npm run db:migrate修改)
- .env文件 (永不提交,从不配置/外读取)
## 当前工作树任务
任务: [开始代理前填写]
分支: [填写]
验收标准: [填写]底部部分是使此文件按工作树生效的关键。每次创建新工作树时,打开AGENTS.md并在启动代理前填写这三行内容。这能精确限定代理的工作范围,防止其触碰不应修改的区域。
针对Claude Code,原生的-w标志可在一个命令中完成工作树创建和会话启动:
# 创建工作树并在其中启动Claude Code会话
claude --worktree feat/auth-redesign
# 简写形式
claude -w feat/auth-redesign
# 使用tmux窗格实现分屏可见性
claude -w feat/auth-redesign --tmuxclaude --worktree会在名为worktree-feat-auth-redesign的分支上创建.claude/worktrees/feat-auth-redesign/目录,然后在其中启动会话。.worktreeinclude文件(gitignore语法)控制哪些被git忽略的文件会自动复制到新工作树中:
# .worktreeinclude -- 放在仓库根目录
# 创建新工作树时要复制的文件
.env
.env.local
.env.development#### // 阶段3:同时运行多个代理
当需要同时运行三到四个代理时,通过脚本化整个设置流程可节省时间并确保一致性。
如何运行:保存为 parallel-setup.sh,执行 chmod +x parallel-setup.sh,然后运行 ./parallel-setup.sh feat/auth feat/api feat/dashboard
#!/usr/bin/env bash
# parallel-setup.sh
# 用一条命令为 N 个并行 AI 代理创建 N 个工作树
# 用法: ./parallel-setup.sh
...
# 示例: ./parallel-setup.sh feat/auth feat/api feat/dashboard
set -euo pipefail
if [ $# -eq 0 ]; then
echo "用法: $0
..."
echo "示例: $0 feat/auth feat/api feat/dashboard"
exit 1
fi
REPO_ROOT="$(git rev-parse --show-toplevel)"
REPO_NAME="$(basename "$REPO_ROOT")"
MAIN_BRANCH="main"
echo "正在设置 ${#@} 个并行工作树..."
git fetch origin 2>/dev/null || echo "(没有远程仓库 -- 跳过获取)"
for BRANCH in "$@"; do
SAFE="${BRANCH//\//-}"
WT_PATH="${REPO_ROOT}/../${REPO_NAME}-${SAFE}"
if [ -d "$WT_PATH" ]; then
echo "已存在: $WT_PATH (跳过)"
continue
fi
# 从 main 分支创建新分支的工作树
git worktree add -b "$BRANCH" "$WT_PATH" "$MAIN_BRANCH" 2>/dev/null || \
git worktree add "$WT_PATH" "$BRANCH"
# 复制环境文件
for f in .env .env.local; do
[ -f "$REPO_ROOT/$f" ] && cp "$REPO_ROOT/$f" "$WT_PATH/$f"
done
echo "已创建: $WT_PATH (分支: $BRANCH)"
done
echo ""
echo "所有工作树:"
git worktree list
echo ""
echo "在每个路径的独立终端或 IDE 窗口中打开,并启动你的代理。"
echo "记得在每个工作树的 AGENTS.md 中填写任务部分。"此脚本的作用:一条命令即可生成所有包含环境文件的工作树。运行 ./parallel-setup.sh feat/auth feat/api feat/dashboard 会在五秒内创建三个隔离的工作目录。在每个终端标签页中打开它们,填写 AGENTS.md,然后启动代理。
防止工作树偏离主分支
最大的长期失败模式不是创建时的冲突,而是偏离(drift)。一个工作树如果三天没有与主分支同步,累积的差异本身就会成为需要合并的项目。
使用 Claude Code 的生产环境实践者对此有明确共识:完成检查点后,要从主分支拉取并合并更新——这能防止工作树偏离过远,从而避免出现大量难以解决的冲突。建议在每次重要的代理会话结束时同步,而不仅仅是在提交 PR 前。
正确的策略是变基(rebase)而非合并(merge)。变基会将你的分支提交放在最新主分支之上,保持历史线性,使 PR 的差异清晰。
如何运行:保存为 sync-worktree.sh,执行 chmod +x sync-worktree.sh,然后在任意工作树目录中运行 ./sync-worktree.sh
#!/usr/bin/env bash
# sync-worktree.sh
# 将当前工作树分支变基到最新的主分支
# 在检查点运行以防止分支偏离
# 用法(在工作树内部):./sync-worktree.sh [主分支名称]
# 示例:./sync-worktree.sh main
set -euo pipefail
MAIN_BRANCH="${1:-main}"
CURRENT_BRANCH="$(git rev-parse --abbrev-ref HEAD)"
if [ "$CURRENT_BRANCH" = "$MAIN_BRANCH" ]; then
echo "已经在 $MAIN_BRANCH 分支 -- 无需同步。"
exit 0
fi
echo "正在将 '$CURRENT_BRANCH' 同步到 '$MAIN_BRANCH'..."
# 如果存在未提交的工作,拒绝执行 -- 变基需要干净的状态
if ! git diff --quiet || ! git diff --cached --quiet; then
echo "错误:检测到未提交的更改。"
echo "请先提交您的进度:"
echo " git add . && git commit -m 'checkpoint: agent progress'"
exit 1
fi
# 获取最新的远程状态
git fetch origin
# 将此分支变基到最新的主分支
# --autostash 可自动处理轻微的工作树差异
git rebase "origin/$MAIN_BRANCH" --autostash
echo ""
echo "完成。'$CURRENT_BRANCH' 已与 origin/$MAIN_BRANCH 同步。"
echo ""
echo "准备推送时:"
echo " git push --force-with-lease"
echo ""
echo "注意:--force-with-lease 比 --force 更安全。"
echo "如果其他人已推送至该分支,它会拒绝推送。"这做了什么:变基前的未提交更改检查是一项重要的安全措施。在脏工作树上执行变基会产生令人困惑的状态。--autostash 可处理轻微差异。推送时使用 --force-with-lease 比 --force 更安全,因为它会拒绝覆盖您尚未看到的远程工作。
从代理完成到合并的 PR 的完整合并生命周期:
# 在工作树内部,代理完成任务后
# 1. 提交代理的工作
git add .
git commit -m "feat: implement OAuth2 + PKCE auth flow"
# 2. 打开 PR 前与主分支同步
./sync-worktree.sh
# 3. 运行测试以验证同步未导致问题
npm run test
# 4. 推送分支
git push --force-with-lease origin feat/auth-redesign
# 5. 通过 GitHub CLI 或网页界面打开 PR
gh pr create \
--title "feat: OAuth2 + PKCE authentication" \
--body "Implements OAuth2 per docs/auth-spec.md. All tests pass."
# 6. PR 合并后清理
cd ../myapp
./cleanup-worktree.sh feat/auth-redesign# 完整命令参考
所有 git worktree 命令的实际示例。在构建第一个工作流时请保持本节打开。
#### // 创建工作树
# 从主分支创建新分支的工作树
git worktree add -b feat/payments ../myapp-payments main
# 将现有分支检出到新工作树
git worktree add ../myapp-feat-auth feat/auth
# 分离的 HEAD -- 用于在特定提交上重现 bug
git worktree add --detach ../myapp-debug abc1234
# 直接跟踪远程分支
git worktree add ../myapp-hotfix origin/hotfix/login-crash#### // 检查和管理
# 显示所有工作树的路径、提交哈希和分支名称
git worktree list
# 用于脚本的机器可读输出
git worktree list --porcelain
# 锁定工作树以防止被删除
# 在代理程序运行时使用,防止意外清理
git worktree lock ../myapp-feat-auth --reason "agent-running"
# 解除锁定
git worktree unlock ../myapp-feat-auth
# 移动工作树目录(关闭所有打开的编辑器后再执行)
git worktree move ../myapp-feat-auth ../worktrees/auth-redesign#### // 清理
# 清洁地删除工作树——Git 中的分支会被保留
git worktree remove ../myapp-feat-auth
# 即使存在未提交的更改也强制删除
# 仅在确定工作内容可以丢弃时使用
git worktree remove --force ../myapp-feat-auth
# 手动删除工作树后清理元数据
git worktree prune
# 预览将被清理的内容而不会实际执行清理
git worktree prune --dry-run
# 在移动 .git 目录后修复工作树引用
git worktree repair# 常见错误及解决方案
错误信息
原因
解决方法
fatal: 'feat/auth' is already checked out分支被其他工作树使用
使用其他分支,或先删除现有工作树
fatal: <path> already exists目标目录已存在
删除目录或选择其他路径
error: '...' is a main worktree尝试删除主工作树
只有关联的工作树可以被删除
error: worktree has modified files存在未提交的更改
提交更改,或使用
--force丢弃更改
工作树在
执行
rm -rf后仍然存在
元数据未清理
运行
# 结论
Git 工作树并不是高级的 Git 隐秘功能。它们是核心基础设施原语,当 AI 编码代理开始在相同代码库中并行运行时,它们变得不可或缺。
本文中的工作流程并非理论上的。这是 Tamir Dresher 团队在微软全球黑客松上实际使用的流程。这也是目前使用 Claude Code、Cursor 和 Codex 的实践者在 GitHub 和 Medium 上记录的流程。这是代理编码社区达成共识的模式:因为它能以最简单的方式可靠地解决其设计要解决的问题。
设置成本很低。本文中的四个脚本涵盖了完整生命周期——创建、同步和清理——仅需约 120 行 bash 代码。概念模型很简单:一个任务、一个分支、一个工作树、一个代理。回报是你可以并行运行多个代理,而无需花费整个下午去解决两个代理都没有故意制造的冲突。
如果你已经在使用 AI 编码工具但没有使用工作树,请在下一个项目中设置它们。创建工作树的脚本只需 10 秒即可启动。如果你正在围绕 AI 代理构建团队工作流程,AGENTS.md 和并行设置脚本将你从临时会话转移到可重复且可扩展的流程。
模型编写代码。你的工作是创造条件,让它能够干净、并行地完成这项工作,而不会阻碍自身。
Shittu Olumide 是一位软件工程师和技术作家,热衷于利用前沿技术创作引人入胜的叙述,注重细节,擅长简化复杂概念。你也可以在 Twitter 上找到 Shittu。
更多相关内容
- 10 个高级 Git 技巧
- Git for Vibe Coders
- 对话式AI开发中的3个关键挑战及如何避免它们
- 如何使用Docker搭建本地开发环境
- 2024技术趋势:AI突破与开发洞察…
- Python开发必备的30个工具
<hr class="grey-line"><br> <div><h3>我们推荐的5门免费课程</h3><br> </div>
Mailchimp for WordPress v4.13.1 - https://wordpress.org/plugins/mailchimp-for-wp/
/ Mailchimp for WordPress插件
您可以从这里开始编辑。
如果评论已关闭。
<= 上一篇
#content end
<script type="text/javascript">kda_sid_write(kda_sid_n);</script>
最新文章
- Git Worktrees在AI开发中的应用 5个关于智能体AI的免费资源 与Pi编码智能体协作 10个保持AI领域领先的YouTube频道 停用If-Else链:在Python中使用注册模式替代 7个用于本地AI智能体编排的Python框架
热门文章
- 停用If-Else链:在Python中使用注册模式替代
- 5个现实世界的SQL项目构建您的数据作品集
- 10个保持AI领域领先的YouTube频道
- 使用Ollama运行OpenClaw
- 使用Outlines进行结构化语言模型生成
- KDnuggets新闻,2025年1月25日:ChatGPT作为Python编程助手 • Python与机器学习预测足球比赛胜者
- 与Pi编码智能体协作
- 为新手解释微调(预训练模型如何学习新技能)
- 生产环境中减少LLM延迟和推理成本的12种方法
- 机器学习中10个概率概念的简单解释
#content_wrapper end
© 2026
Guiding Tech Media
|
关于
联系我们
广告合作
隐私政策
服务条款
2026年7月17日由Olumide Shittu发布
blank
不,谢谢!
/.main_wrapper
<script defer type="text/javascript" src="https://s7.addthis.com/js/300/addthis_widget.js#pubid=gpsaddthis"></script>
noptimize
/noptimize