跨仓库开发太累了？用这个 Claude Skill 给你的 AI Bot 当指挥官

拾遗·Skill精选官 内容创作者 2026-09-27 864 阅读

你的团队有多少个微服务？5个？10个？20个？

跨仓库功能开发是什么体验——在 Notion 里记依赖关系，在 Slack 里追进度，在各个 GitLab 里反复横跳。人肉当中间件，信息永远不对称。

Smithy Orchestrator 就是来解决这个问题的。

这是一个 Claude Code Skill，专门给「跨多仓库工作」的团队用。它不是一个写代码的 AI，而是一个指挥官 AI——你告诉它要做什么，它来规划、拆解、分配、监督所有仓库的工作。

它怎么工作的？

流程是计划门控（Plan-gated）的，每一步都要你确认：

  1. 你下达任务 → 它分析所有涉及的仓库，生成跨仓库的计划
  2. 你审批计划 → 它才创建 GitLab Issues 并分配给 Smithy Bot
  3. Bot 写代码 → 它开 Draft MR，但不是「写完了」，只是「计划被批准了可以开始写」
  4. 你来审 MR → 最终合并是你手动做的
任务输入 → 跨仓库规划 → 你确认 → 创建 Issue → Bot 实现 → Draft MR → 你审核 → 合并

关键是：Bot 看不到其他仓库，只能看到自己被分配的那个。所以你的计划必须写得足够清楚——API 形状、消息队列名称、配置 key，一个都不能少。

适合谁用？

  • 多仓库微服务团队，功能改动涉及 3+ 个仓库
  • CI/CD 流程长，人工协调成本高
  • 有独立的 Smithy Bot 在跑（这是给 Bot 用的编排层，不是给人类直接用的）

如果你只有一个仓库，这个 Skill 帮不上忙。

安装

这个 Skill 附在 smithy-ai/smithy-ai 仓库里：

# 先装 smithy-ai 的完整环境（参考其 README）
# 然后把 orchestrator skill link 进去
git clone https://github.com/smithy-ai/smithy-ai.git
cd smithy-ai
# 按照仓库文档配置 glab 和 repos.yml
# Skill 在 .claude/skills/smithy-orchestrator/

需要先配置 repos.yml，告诉它你的 GitLab Host 和各仓库信息。没有这个配置文件它会停下来提示你配置。

核心感受

这类工具最难的不是「能不能用」，而是「团队是否愿意改流程」。如果你的团队已经在用 GitLab Issues 做任务跟踪，Smithy Orchestrator 可以把人肉协调那层砍掉——它把「规划→分配→审核」的链路自动化了，但最终决定权还在人手里。

GitHub：https://github.com/smithy-ai/smithy-ai

GitHub: https://github.com/smithy-ai/smithy-ai

评论区

0 条评论

登录后可评论。

拾遗·Skill精选官 864 阅读