集成篇

目录¶

• 12. 将 Skill 融入开发流程
  • 12.1 本地开发：Makefile 驱动的质量门禁
  • 12.2 CI 流程：Skill 驱动的自动化门禁
  • 12.3 代码审查：AI 驱动的 PR Review
  • 12.4 完整的质量管线
  • 12.5 团队落地策略：渐进式推广与阻力处理
• 13. Skill 与其他 Claude Code 特性的关系
  • 13.1 特性对比
  • 13.2 选择决策树
  • 13.3 组合使用模式
  • 13.4 一句话总结
• 14. AI 编程助手定制能力横向对比
  • 14.1 主流工具定制能力对比
  • 14.2 AI 代码审查工具对比
  • 14.3 趋势判断

12. 将 Skill 融入开发流程¶

Skill 的真正价值不是孤立使用，而是串联到开发流程的关键节点，形成质量管线。

12.1 本地开发：Makefile 驱动的质量门禁¶

go-makefile-writer skill 帮我们为 Go 项目生成标准化的 Makefile。核心理念：开发者在 push 之前就应该能捕获 CI 会发现的所有问题。

以 issue2md 项目为例，Makefile 中的 ci 目标直接镜像 CI 流程：

ci: fmt-check ci-core  ## Local/CI required gate parity checks

ci-core: cover-check lint build-all  ## Run coverage gate, lint, build

本地执行 make ci 和 CI 执行 make ci COVER_MIN=80 是同一条命令——这就是 go-ci-workflow skill 所说的 "Local Parity"（本地一致性）。

12.2 CI 流程：Skill 驱动的自动化门禁¶

CI workflow 是 Makefile 目标的薄封装层。以下以 issue2md 项目为例（需根据自己的项目适配工具版本和目标名称）：

# .github/workflows/ci.yml（示例，需适配）
jobs:
  ci:
    steps:
       - name: Install golangci-lint
        run: go install github.com/golangci/golangci-lint/v2/cmd/golangci-lint@v2.6.2
       - name: Run CI gate
        run: make ci COVER_MIN=80

  docker-build:
    steps:
       - name: Build image
        run: make docker-build

每个 CI job 委托给一个 Makefile 目标。开发者在本地跑 make ci，CI 也跑 make ci——流程完全一致。

这次 CI 正是由 §8.1 中 git-commit skill 的提交触发的——从本地门禁到 CI 全绿，整条链路由 skill 驱动。

12.3 代码审查：AI 驱动的 PR Review¶

go-code-reviewer skill 可以集成到 CI 中，对每个 PR 自动执行代码审查。以下以 tcg-ucs 项目为例（需根据自己的项目适配 skill 路径、prompt 内容和工具权限）：

# .github/workflows/claude-code-review.yml（示例，需适配）
name: Claude Code Review
on:
  pull_request:
    branches: [master, main]
    types: [opened, synchronize]

jobs:
  review:
    steps:
       - uses: anthropics/claude-code-action@v1.0.3
        with:
          prompt: |
            Read .claude/skills/go-code-reviewer/SKILL.md,
            get the PR diff via `gh pr diff`,
            select review mode (Lite/Standard/Strict),
            execute the full review workflow,
            post findings as PR comments.

工作流 YAML 只做编排，所有审查逻辑都在 skill 中。更新审查标准只需更新 skill 文件，无需修改 CI 配置。

12.4 完整的质量管线¶

把上述环节串联起来，形成从编码到合并的完整质量管线：

编码
  ↓
make fmt / make lint（本地质量检查，go-makefile-writer 生成）
  ↓
git commit（git-commit skill：安全扫描 + 质量门禁 + 规范化 message）
  ↓
git push
  ↓
create PR（create-pr skill：8 道门禁 + 结构化 PR body）
  ↓
CI 触发
  ├── make ci（格式 + 测试 + lint + 覆盖率 + 构建）
  ├── make docker-build（容器镜像验证）
  ├── Claude Code Review（go-code-reviewer skill：自动代码审查）
  └── govulncheck（依赖漏洞扫描）
  ↓
人工审查 + 合并

每个环节都有对应的 skill 提供保障，且本地和 CI 保持一致。

12.5 团队落地策略：渐进式推广与阻力处理¶

Skill 的技术集成只是一半，另一半是团队接受度。工具再好，若推广方式引发阻力，最终也会被束之高阁。以下是经过验证的渐进式推广路径，核心思路是"先证明价值，再固化为流程"。

第一阶段：个人试点（1-2 周）

由 1-2 名对 AI 工具熟悉的成员先在日常工作中使用 skill，收集真实的正面案例和问题反馈。这个阶段的目标不是推广，而是积累说服团队的证据——没有真实案例，任何宣讲都是空洞的。

第二阶段：可选启用（2-4 周）

将 skill 提交到项目的 .claude/skills/ 目录，但不强制使用。在团队会议上用第一阶段的真实案例（如"Skill 拦截了一次密钥泄漏"）展示价值。关键原则：用证据说服，不用行政命令强推。强制推广往往引发逆反心理，反而阻碍采用。

第三阶段：CI 门禁集成

当团队大多数成员已经在自愿使用 skill 后，再将其集成到 CI 流程中作为质量门禁。此时团队对 skill 的行为已有预期，CI 集成不会产生意外摩擦。过早集成到 CI 是常见错误——在团队尚未建立信任之前就设置强制门禁，只会让 skill 成为"令人烦躁的障碍"。

常见阻力与应对

渐进式推广的本质是把"工具采用"当成一个需要管理预期、积累信任、降低摩擦的工程问题——和写好 skill 本身同等重要。

13. Skill 与其他 Claude Code 特性的关系¶

Claude Code 提供了多种扩展机制，各有其适用场景。理解它们的区别是正确使用的前提。

13.1 特性对比¶

13.2 选择决策树¶

这个知识/流程需要在每次会话中生效吗？
├── 是 → 它短于 200 行吗？
│   ├── 是 → 放在 CLAUDE.md
│   └── 否 → 拆分到 .claude/rules/ 或抽取为 skill
├── 否 → 它需要用户主动触发吗？
│   ├── 是 → 它有副作用吗？
│   │   ├── 是 → Skill + disable-model-invocation: true
│   │   └── 否 → Skill（默认）
│   └── 否 → 它是确定性逻辑（如格式化、lint）吗？
│       ├── 是 → Hook（零 AI 上下文成本）
│       └── 否 → 它需要连接外部服务吗？
│           ├── 是 → MCP server
│           └── 否 → Skill + user-invocable: false（后台知识）

13.3 组合使用模式¶

这些特性不是互斥的，最佳实践是组合使用：

13.4 一句话总结¶

CLAUDE.md 是"始终生效的背景知识"，Skill 是"按需加载的专业能力"，Hook 是"零成本的确定性保障"，MCP 是"连接外部世界的桥梁"，Sub-agent 是"隔离执行的并行agent"。

把对的知识放在对的位置，既保证了 AI 在关键时刻拥有必要的上下文，又避免了无关信息对上下文窗口的浪费。

14. AI 编程助手定制能力横向对比¶

Skill 并非唯一的 AI 编程助手定制机制。了解市场上其他工具的定制能力，有助于理解 skill 的设计理念和独特优势。

14.1 主流工具定制能力对比¶

14.2 AI 代码审查工具对比¶

在 CI 集成的代码审查领域，也有多种选择：

Copilot 和 CodeRabbit 胜在开箱即用和规模；Claude Code + Skill 胜在定制深度和领域适配。对于有特定领域审查需求（如 Go 并发安全、资源生命周期管理）的团队，后者的投入产出比更高。

14.3 趋势判断¶

AI 代码审查已经从"新鲜事物"变成"基础设施"——Copilot Code Review 覆盖了 GitHub 20% 以上的代码审查量。但在定制化深度上，行业仍处于早期：

• 大多数团队：直接使用 Copilot 或 CodeRabbit 的默认配置，不做深度定制
• 进阶团队：通过配置文件传递项目级规范（如 .github/copilot-instructions.md）
• 前沿实践：用自定义 skill 构建完整的领域审查体系（门禁、反例、版本感知、降级策略）

从"能用 AI"到"用好 AI"，中间隔着的正是本文讨论的这些设计模式和工程实践。