扩展机制：Hooks / Skills / Commands

裸 harness 解决「能干活」，扩展机制解决「按你的规矩干活」。以 Claude Code 为例讲三大机制——原理在各家 harness 中通用。

Hooks：把团队流程焊进运行时

Hook = 在 harness 生命周期的固定事件点上执行你的 shell 命令，可以检查、拦截、改写模型行为。

事件点与用途

事件	时机	典型用途
PreToolUse	工具执行前	拦截危险命令（如禁 git push --force）
PostToolUse	工具执行后	自动 format / lint 改过的文件
UserPromptSubmit	用户提交 prompt 后	注入上下文（当前 ticket 信息）
Stop	模型结束回合时	检查是否真的完成（没过测试就打回去继续）
SessionStart	会话启动	加载环境信息

配置示例（.claude/settings.json）

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "bash .claude/hooks/block-dangerous.sh"
      }]
    }],
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{
        "type": "command",
        "command": "npx prettier --write \"$CLAUDE_TOOL_INPUT_FILE_PATH\" 2>/dev/null || true"
      }]
    }]
  }
}

#!/usr/bin/env bash
# block-dangerous.sh —— 拦截破坏性 git 命令
input=$(cat)   # hook 通过 stdin 收到 JSON（工具名+参数）
if echo "$input" | grep -qE 'push.*--force|reset --hard'; then
  echo '{"decision": "block", "reason": "禁止强推/硬重置，如需请人工操作"}'
  exit 0
fi
exit 0   # 无输出 = 放行

关键设计：hook 的 stdout 是结构化决策（block/approve/注入消息），回注到对话流——相当于用任意语言扩展 harness 的行为，而模型看得懂拦截原因。

Hook 最擅长的事

「每次 X 之后必须 Y」类约束：
  - 改了 ts 文件 → 自动跑 tsc --noEmit
  - 会话结束 → 通知 Slack
  - 提交前 → 检查敏感信息
写一次，模型永远绕不过去（对比：写在 prompt 里的规矩，模型偶尔忘）

Skills：可分发的能力包

Skill = 一个文件夹 + 一个 SKILL.md，把「完成某类任务的操作手册」打包成按需加载的技能。

结构

.claude/skills/deploy/
├── SKILL.md        # 入口：frontmatter(name, description) + 指令正文
└── scripts/
    └── deploy.sh   # 可附带的脚本资源

---
name: deploy
description: 发布本博客到 GitHub Pages。当用户说"发布/部署"时使用
---

# 发布流程
1. 确认侧边栏已注册新文档
2. 执行 bash deploy.sh "<简短 commit message>"
3. 验证输出末尾有 finish!!! 且 push 行显示 forced update
4. 若遇 10054 错误：先 git ls-remote 探活，通了重跑；具体见 troubleshooting.md

Skills 的精髓：渐进式加载

启动时只注入 name + description（一行索引，几乎零成本）
模型判断当前任务匹配 → 才加载 SKILL.md 正文
正文引用的脚本/参考文件 → 用到时才读

三层懒加载 = 「能力库可以无限大，上下文成本恒定」

对比三种「教 AI 做事」的方式： CLAUDE.md（常驻，适合少量铁律）/ Skills（按需，适合大量流程）/ Hook（强制，适合不可违反的约束）。

自定义命令（Slash Commands）

把常用 prompt 存成文件，变成 /命令：

.claude/commands/review.md
---
description: 审查当前分支的改动
---
审查当前 git diff：按正确性→安全→性能排序，
只报告可确认的问题，引用 file:line。

输入 /review  →  文件内容作为 prompt 展开（支持 $ARGUMENTS 占位符）

适合团队沉淀高频操作：/daily-report、/migrate-component、/release-check。

插件：三件套打包分发

Plugin = Skills + Commands + Agents（+ hooks/MCP 配置）打成一个可安装单元，团队内共享：

myteam-plugin/
├── .claude-plugin/plugin.json   # 清单
├── skills/         # 技能
├── commands/       # 命令
├── agents/         # 子代理定义
└── hooks/          # 钩子

安装后团队成员的 harness 直接获得整套定制——把「AI 使用规范」从口头约定变成版本化的工程资产。

扩展机制选型决策树

需要强制执行（模型不许违反）？        → Hook
每次会话都要生效的铁律？               → CLAUDE.md
特定任务的操作手册（偶尔用到）？        → Skill
高频 prompt 模板？                    → Slash Command
需要独立上下文/工具集的专家角色？       → 自定义 Agent
要分发给整个团队？                    → Plugin

实战：把一个团队流程「编译」进 harness

以「发布前检查」为例，看四个机制如何各就各位：

1. CLAUDE.md 写一句：「发布必须走 /release 流程」（认知）
2. Skill release.md 写完整发布手册：构建、验证、回滚（知识）
3. /release 命令一键触发（入口）
4. PreToolUse hook 拦截任何绕过检查脚本的 git push --force（强制）

结果：新人第一天，AI 就按老员工的方式发布。

本篇小结

• Hooks：事件点 + 结构化决策，把硬约束焊进运行时
• Skills：description 索引 + 三层懒加载，能力库无限而上下文恒定
• Commands：prompt 模板化；Plugins：整套定制团队分发
• 四种机制覆盖「认知 / 知识 / 入口 / 强制」四个层面

下一篇：构建你自己的 Harness。