Claude Code 第 12 篇 告别手动合并与部署：用 Claude Code Skill 打造自动化工作流（TaoToken 统一 Key 配置版）

1. 从一次被拒绝的 push 说起如果你每天都在做同一套动作开发分支写完push 到远程切到 uat合并开发分支push uat再切回来最后去 Jenkins 点一下部署——那这套流程本身就该被自动化。Claude Code 的 Skill 机制正好能把这条链路固化成一个可复用的指令而 TaoToken 的统一 Key 配置能让 Skill 里调用的模型通道和脚本执行都走同一个入口不用在多个配置文件之间来回改。这篇聚焦的是落地从settings.json骨架到 CC Switch 配置再到一个完整的ta-merge-to-uat-and-deploySkill最后用一次真实提交验证从合并到部署的自动化链路。适合已经在用 Claude Code、手上有 Jenkins 部署任务、并且希望把重复操作交给 Skill 执行的开发者。读完之后你应该能在本地跑通一条从git push到 Jenkins 触发部署的完整流程并且知道每一步出错时该查哪里。核心检索词先摆出来Claude Code Skill 是什么、能做什么、适合谁。Skill 本质是一个带SKILL.md的目录里面写清楚触发条件和执行步骤Claude Code 在匹配到任务时会自动加载并执行适合所有需要把多步骤操作固化成一致流程的人尤其是合并、部署、代码审查这类重复度高的场景。2. TaoToken 前置统一 Key 与 API 通道在写 Skill 之前先把模型通道统一掉。TaoToken 的作用是提供一个统一的 Key 和 API 入口让 Claude Code 以及 Skill 里调用的脚本都走同一个通道避免每个项目、每个工具各配一套 Key。官网入口在这里https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。API 地址是 https://taotoken.net/api 注意这个地址不带 UTM 参数配置时直接填这个。你需要先拿到 API Key。进入控制台创建https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 然后在 API Keys 页面生成一个 Keyhttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。生成后复制保存后面配置里要用。如果你还没决定用哪个模型可以先在模型对话页面试一下https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 。长期做编码和 Agent 任务的话Coding Plan 更合适https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。注意API Key 只生成时可见一次复制后妥善保存。不要把它写进会提交到 Git 的文件里。3. 可复制配置settings.json 骨架与 CC SwitchClaude Code 的配置分两层全局~/.claude/settings.json和项目级.claude/settings.json。Skill 相关的配置建议放项目级这样不同项目可以有不同的 Skill 集合。先看全局配置骨架重点是模型通道指向 TaoToken{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoTokenKey }, model: claude-sonnet-4-20250514 }项目级.claude/settings.json里加上 Skill 目录和权限配置{ skills: { directory: .claude/skills }, permissions: { allow: [ Bash(git *), Bash(curl *) ] } }permissions.allow这一项很关键。Skill 执行时会调用git和curl如果不提前放行Claude Code 会在每次执行前弹确认自动化就断了。把git *和curl *加进白名单Skill 才能连续跑完。CC Switch 配置方面如果你用 CC Switch 管理多个 Claude Code 配置在它的配置里把ANTHROPIC_BASE_URL指向https://taotoken.net/apiKey 填 TaoToken 生成的 Key。这样切换配置时模型通道和 Skill 执行环境保持一致。提示ANTHROPIC_BASE_URL末尾不要加斜杠直接写https://taotoken.net/api即可。4. 编写 ta-merge-to-uat-and-deploy SkillSkill 的核心是SKILL.md。在项目根目录创建.claude/skills/ta-merge-to-uat-and-deploy/SKILL.md内容如下--- name: ta-merge-to-uat-and-deploy description: Use when a development branch must be pushed to origin, merged into the uat branch, deployed, and pushed back safely, especially when the first push is rejected because the remote dev branch moved ahead or when uat must be refreshed from origin before merging. --- # TA Merge to UAT and Deploy ## Overview Use the remote branch state as the source of truth. First make the development branch publishable, then bring local uat up to date from origin, merge the development branch into it, push uat, switch back to the development branch, determine affected services from changed files, trigger deploy for each service. ## Workflow bash git status --short git branch --show-current # 1) Publish the development branch first git push origin dev-branch # If the push is rejected because origin has newer commits: git fetch origin git merge origin/dev-branch git push origin dev-branch # 2) Update the deployment branch and merge into it git switch uat git fetch origin git merge origin/uat git merge dev-branch # 3) Publish the deployment branch git push origin uat # 4) Return to the development branch git switch dev-branch # 5) Determine affected services from changed module directories git diff --name-only HEAD~1 | grep -oE ta-module/[^/] | sort -u # 6) Deploy each affected service curl --location http://192.168.2.136:8080/job/ta-uat-build-deploy/buildWithParameters?tokenuat_build_deploy_tokencause%E8%BF%9C%E7%A8%8B%E8%B0%83%E7%94%A8 \ --header Authorization: Basic base64 \ --form serviceservice-nameService mappingta-module/ta-core/→ta-coreta-module/ta-gateway/→ta-gatewayta-module/ta-system/→ta-systemta-api/ta-api-common/→ deploy all 4 servicesta-common/→ deploy all 4 servicesCommon mistakesMerging intouatbefore the development branch is safely pushed.Skippingfetchbefore updatinguat.Reversing the merge direction.Using force push to get around a rejected push.这个 Skill 的关键点在于先 push 开发分支再切 uat 合并最后根据改动文件判断要部署哪些服务。description 字段写得具体一些Claude Code 才能在你提到“合并到 uat 并部署”时自动匹配到这个 Skill。 ## 5. 验证请求一次完整的自动化链路 配置和 Skill 都就位后跑一次完整验证。假设当前在 feature-a 分支有代码改动已提交。 第一步确认工作区干净 bash git status --short git branch --show-current输出应该是空的git status和feature-a。第二步在 Claude Code 里输入/ta-merge-to-uat-and-deployClaude Code 会加载 Skill按步骤执行。你会看到它依次执行git push origin feature-a、git switch uat、git fetch origin、git merge origin/uat、git merge feature-a、git push origin uat、git switch feature-a。如果git push origin feature-a被拒绝说明远程有新的提交。Skill 会自动执行git fetch origin和git merge origin/feature-a再重新 push。这一步是很多人手动操作时容易漏掉的。第三步观察 Jenkins 触发。Skill 会根据git diff --name-only HEAD~1的结果判断改动模块。比如改动了ta-module/ta-core/和ta-module/ta-gateway/它会分别调用两次 curlcurl --location http://192.168.2.136:8080/job/ta-uat-build-deploy/buildWithParameters?tokenuat_build_deploy_tokencause%E8%BF%9C%E7%A8%8B%E8%B0%83%E7%94%A8 \ --header Authorization: Basic base64 \ --form serviceta-core curl --location http://192.168.2.136:8080/job/ta-uat-build-deploy/buildWithParameters?tokenuat_build_deploy_tokencause%E8%BF%9C%E7%A8%8B%E8%B0%83%E7%94%A8 \ --header Authorization: Basic base64 \ --form serviceta-gatewayJenkins 收到请求后开始构建你可以在 Jenkins 控制台看到构建记录cause字段显示“远程调用”说明是 Skill 触发的。验证成功的标志本地分支回到feature-auat 分支已更新并推送Jenkins 对应服务的构建任务已启动。6. 本篇常见错排查push 被拒绝后直接 force push。这是最常见的错误。远程开发分支有新提交时正确做法是git fetch origin然后git merge origin/dev-branch合并后再 push。force push 会覆盖别人的提交Skill 里明确禁止了这种做法。切到 uat 后忘记 fetch。本地 uat 可能落后于远程直接 merge 开发分支会导致后续 push 被拒绝。Skill 的步骤里git fetch origin和git merge origin/uat是连着的不要跳过。合并方向搞反。是把开发分支合并到 uat不是把 uat 合并到开发分支。方向反了会把 uat 的提交带到开发分支污染开发历史。Jenkins 认证失败。Authorization: Basic后面的 base64 是用户名:API_Token的编码结果。如果 Jenkins 返回 403检查这个 base64 是否正确以及 API Token 是否还有效。可以在 Jenkins 用户设置里重新生成 Token。服务映射判断错误。如果改动了ta-api/ta-api-common/或ta-common/需要部署全部四个服务。Skill 的 service mapping 里写清楚了对应关系执行前可以先用git diff --name-only HEAD~1确认改动范围。Skill 没有被触发。检查.claude/settings.json里的skills.directory是否指向.claude/skills以及SKILL.md的description是否包含足够的触发关键词。如果自动匹配不生效可以直接用/ta-merge-to-uat-and-deploy手动调用。权限确认打断自动化。如果每次执行 git 或 curl 都弹确认检查permissions.allow里是否加了Bash(git *)和Bash(curl *)。没有这两项Skill 无法连续执行。排障和接入相关的配置统一在 API Keys 页面管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。接入文档在这里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。如果你用的是 Claude Code 的 Anthropic 兼容通道参考https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaude-code-anthropicutm_campaignrewrite 。7. 把 Skill 用起来Skill 写完之后真正省时间的地方在于它的一致性。每次合并部署的步骤完全一样不会因为手快漏掉 fetch也不会因为切分支顺序错了导致 push 被拒。我试过在三个项目里复用同一个 Skill 结构只需要改 service mapping 和 Jenkins URL其他部分直接复制。一个实用技巧把SKILL.md里的description写得稍微“啰嗦”一点把常见的触发场景都列进去比如“push 被拒绝”“需要刷新 uat”“部署多个服务”。Claude Code 匹配 Skill 时看的就是这段描述写得越具体自动触发越准。另一个技巧Jenkins 的cause参数可以用 URL 编码的中文比如%E8%BF%9C%E7%A8%8B%E8%B0%83%E7%94%A8对应“远程调用”。这样在 Jenkins 构建历史里一眼就能看出是 Skill 触发的而不是手动点的。最后Skill 不是一次写完就固定的。每次遇到新的边界情况比如某个模块的映射关系变了或者 Jenkins 接口加了新参数就回来更新SKILL.md。它本质上是一份可执行的文档维护成本比记在脑子里低得多。