Claude Code 实战大师班 #1 — 用斜线命令·Hook·子代理三步实现工作流自动化

Claude Code 实战大师班 #1 — 用斜线命令·Hook·子代理三步实现工作流自动化

通过斜线命令(.claude/commands/)定义任务，用settings.json Hook连接事件，并委托给子代理(.claude/agents/)执行。本文以真实博客自动化系统为案例，从头到尾详解Claude Code三步自动化工作流构建方式，所有代码均可直接运行，帮你掌握这一高效自动化范式。

你现在读到的这篇文章，很可能是今天早上11点30分自动触发的launchd任务唤醒了Claude Code，执行了/daily-tech-blog斜线命令，再由多个子代理分工完成研究和翻译后生成的。

过去几个月，我一直在亲手构建和运维这套自动化管道。它并不完美——有时会触发超时，有时构建失败，有时只生成了某一种语言的版本就结束了。但如果没有这套系统，每天用4种语言发布文章根本不可能实现。

这个系列记录的就是这一过程中学到的东西。第1篇聚焦最核心的三步：斜线命令、Hook、子代理——从零开始构建的方法。

Step 1：斜线命令 — .claude/commands/ 文件夹就是全部

在Claude Code中创建/commit、/review、/deploy这类命令的方法出奇地简单：只需在.claude/commands/目录下放一个.md文件。

文件名就是命令名：

.claude/
└── commands/
    ├── commit.md          → /commit
    ├── daily-review.md    → /daily-review
    └── publish.md         → /publish

文件内容是自然语言指令。看起来像Markdown，但行为像代码：

# Publish Command

Validate and publish the blog post to production.

## Usage
/publish <slug>

## Workflow
1. Run npm run validate:publishing
2. Run npm run build
3. Run git add and commit with the slug
4. Run git push origin main

Report errors clearly with the step number.

就这些。在Claude Code会话中输入/publish my-post-slug，上面定义的工作流就会执行。Claude将每个步骤解释后转换为工具调用。

第一次看到这个结构时，让我惊讶的是”不需要编程语言”。用文本写下流程，Claude就会按情况自行执行。当然，有时解释结果和意图有偏差——这种不可预测性至今仍是挑战。

编写命令的技巧

与其只写”做什么”，加入”为什么是这个顺序”和”哪些情况下要有不同行为”会精确得多：

# Daily Tech Blog

Research, write, validate, and publish one daily article.

## Context
- Today's date: use `date +%F`
- Blog repo: ~/Documents/workspace/www.jangwook.net
- Content types: how-to (Mon-Wed), news (Thu-Fri), series (Sat-Sun)

## Failure Handling
- If sandbox test fails: switch to Source Review lane
- If build fails 3 times: stop and report
- Never ask the user — this runs unattended

“Never ask the user”这一行是实现自主运行模式的关键。没有它，Claude在遇到不确定情况时就会停下来询问确认。在定时任务中这是致命的。

Step 2：settings.json Hook — 事件驱动的自动化

如果斜线命令定义”做什么”，Hook定义的就是”什么时候自动触发”。

在.claude/settings.json的hooks字段中注册事件-命令对：

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/send-telegram.sh 'Claude已完成任务'"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"[audit] $(date) — 文件写入发生\" >> ~/.claude/audit.log"
          }
        ]
      }
    ]
  }
}

4种Hook类型

类型触发时机常见用途
PreToolUseClaude调用工具的前一刻拦截危险命令、审计日志
PostToolUse工具调用完成后文件保存后执行lint、提交后通知
StopClaude完全停止响应时完成通知、清理工作
SessionStartClaude会话启动时注入时间上下文、环境设置

在我的配置中最有用的是Stop Hook。长时间自动化任务（30分钟〜1小时）完成后，会收到Telegram通知。设置好这个之后，我就彻底摆脱了盯着终端看”结束了没有”的习惯。

permissions配置 — 基于白名单的安全控制

与Hook一起必须配置的是permissions。默认情况下，Claude Code在执行每条Bash命令前都会请求用户审批。在自动化环境中，这个行为会阻断整个管道。

预先注册允许执行的命令，就能跳过审批提示直接执行：

{
  "permissions": {
    "allow": [
      "Bash(git log:*)",
      "Bash(git diff:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git push:*)",
      "Bash(npm run build:*)",
      "Bash(npm run validate:*)"
    ]
  }
}

注意：白名单设置过宽（如Bash(*)）可能导致意外命令执行。只注册实际需要的命令模式才是安全做法。

在实际代码审查管道中应用Hook的详细案例，可以参考用Claude Code Hook构建自动化代码审查系统。

Step 3：子代理委托 — .claude/agents/ 专业化AI

让单个Claude实例同时处理研究 + 写作 + SEO优化 + 翻译 + 构建，会降低每项任务的专注度，也浪费Token上下文。

子代理是为每个角色创建独立Claude实例的概念。在.claude/agents/文件夹中，用带frontmatter的Markdown文件来定义：

---
name: writing-assistant
description: Technical blog post writer. Use when creating multilingual (ko/ja/en/zh) developer content.
tools: Read, Write, WebSearch
---

You are a technical writer specializing in developer-focused content.

Core rules:
- Write for developers who will actually run the code
- Include at least 3 first-person experience references
- Verify technical claims before writing
- Never fabricate benchmarks or logs

frontmatter中的description字段最为关键。编排器Claude在判断”什么时候该用哪个代理”时会参考这个字段。写得含糊，就会调用错误的代理，或者完全被忽略。

tools字段只列出该代理实际需要的工具。没有Write权限的研究代理就不会意外修改文件。这是同时实现角色专业化和权限限制的方法。

这个博客目前运行着19个代理：

  • writing-assistant — 4种语言文章写作
  • seo-optimizer — 元标签、内链优化
  • web-researcher — 趋势研究和事实核查
  • content-recommender — 生成relatedPosts
  • image-generator — 撰写英雄图片简报

关于将代理组织成团队的更复杂模式，可以参考Claude Code代理团队完整指南。

三步整合：实际自动化管道

比起理论，直接看运行中的管道更直观。这个博客每日自动化的流程如下：

macOS launchd (每天11:30)
    ↓
daily-tech-blog.sh
    ↓
claude --dangerously-skip-permissions "/daily-tech-blog"
    ↓
/daily-tech-blog 斜线命令执行
    ├── 趋势研究（子代理：web-researcher）
    ├── 沙盒测试（mktemp）
    ├── 4语言文章写作（子代理：writing-assistant）
    ├── npm run validate:publishing
    ├── npm run build
    └── git push origin main
    ↓
Stop Hook → send-telegram.sh → Telegram通知

最关键的文件是daily-tech-blog.sh。调用Claude的核心部分：

run_with_timeout "$MAX_TIMEOUT" claude --dangerously-skip-permissions \
  "/daily-tech-blog" \
  < /dev/null >> "$LOG_FILE" 2>&1 || CLAUDE_EC=$?

--dangerously-skip-permissions跳过所有权限提示。如名字所示，这是危险的。只有在白名单定义完善的状态下才能使用，个人自动化项目之外不建议使用。

< /dev/null关闭stdin，防止Claude无限等待交互式输入。在cron任务中这是必须的。

实际执行日志长这样：

daily-tech-blog实际执行日志截图

launchd plist的配置也值得参考：

<key>StartCalendarInterval</key>
<dict>
    <key>Hour</key>
    <integer>11</integer>
    <key>Minute</key>
    <integer>30</integer>
</dict>
<key>StandardOutPath</key>
<string>/Users/jangwook/logs/launchd-daily-tech-blog.log</string>

将日志重定向到文件，在调试”为什么今天的文章没有发布”时帮助极大。

实际入门 — 5分钟最小配置

为刚开始尝试三步走的人整理了最简工作示例，可以直接应用到现有项目。

1. 创建文件夹结构

mkdir -p .claude/commands .claude/agents

2. 第一个斜线命令 (.claude/commands/review.md)

# Review Command

Review recent changes before committing.

## Steps
1. Run git diff --staged to see staged changes
2. Check for: hardcoded secrets, console.log, TODO comments
3. Suggest improvements or approve with "LGTM"

For detailed security analysis, delegate to @checker agent.

3. 完成通知Hook配置 (.claude/settings.json)

{
  "permissions": {
    "allow": ["Bash(git:*)", "Bash(npm:*)"]
  },
  "hooks": {
    "Stop": [{
      "hooks": [{
        "type": "command",
        "command": "say 'Claude已完成任务'"
      }]
    }]
  }
}

4. 第一个代理定义 (.claude/agents/checker.md)

---
name: checker
description: Code quality reviewer. Use when checking files for issues before commit.
tools: Read, Grep
---

Review the provided files for syntax errors, obvious bugs, and security issues.
Rate: SAFE / CAUTION / CRITICAL

这4个文件是最小工作单元。有了这些，/review就能分析暂存的变更，工作完成后收到语音通知，需要详细检查时委托给checker代理。

诚实的评价 — 哪些地方不好用

运行这套系统三个月后，我遇到了一些现实的限制。

成本问题：每天自动生成4种语言、2500字以上的文章，月度API费用累积得比预期快。我靠Anthropic Max订阅勉强控制，但不接受这个成本就无法维持这个规模的自动化。

超时处理：构建慢或子代理链条太长，就会触发60分钟超时。文章只生成到一半就中断。如果没有超时检测后的清理逻辑，仓库状态会变得混乱。

代理质量的非确定性：同一个命令执行两次，结果可能不同。文章质量、内链位置、relatedPosts选择——每天都不一样。这是LLM的特性，无法消除，只能通过QA循环（validate:publishing、astro check、build）来保证最低质量标准。

说实话，把这套系统称为”生产就绪”还为时过早。按我的标准，它是”对个人自动化来说足够稳定的水平”。在团队规模使用，需要更健壮地设计错误恢复、状态管理和审计日志。

如果需要系统性地分析代理工作流的框架，Claude Code代理工作流5种模式是很好的参考。

下一篇：#2 MCP服务器集成

第1篇涵盖了在.claude/文件夹内完结的自动化。

第2篇更进一步——从头构建MCP服务器，将Claude Code连接到外部工具。读取Notion数据库、发送Slack消息、查询PostgreSQL——这些外部系统集成都可以通过一条斜线命令完成。

如果已经尝试过MCP服务器构建，MCP服务器从零构建实践指南是很好的预备阅读材料。

本文中的.claude/目录结构和Shell脚本示例均直接取自jangwook.net博客自动化系统的实际运行版本。

阅读其他语言版本

这篇文章有帮助吗？

您的支持能帮助我创作更好的内容。请我喝杯咖啡吧。

关于作者

jw

Kim Jangwook

AI/LLM专业全栈开发者

凭借10年以上的Web开发经验，构建AI代理系统、LLM应用程序和自动化解决方案。分享Claude Code、MCP和RAG系统的实践经验。

GitHub LinkedIn X (Twitter) 查看简介

相关文章

返回博客列表