本轮拆到第五期，部署、CI、编排、监控这几条自动化赛道都各横评过一轮了，再比一次「谁家件更强」只会重复自己。所以这期不下场比件，往生态下面再挖一层：件是「会干活的」，但「什么时候干活」这件事，几乎没有一件写在自己的 SKILL.md 里。真正的自动化不装在技能目录里，而装在 settings.json 的钩子上、定时器的循环里、后台任务的队列中。本期以本机装机清单为样本（清单口径沿用此前盘点的四百余件全量名录），配合 Claude Code 官方文档的机制说明，把「让一件活自动跑起来」的四个点火通道逐个拆开：事件挂钩、定时值守、后台长任务、权限自润滑。五个在册样本逐件打分，文末给可直接复制的配置命令。
需要说明口径：本期内置四件直接引用其自带描述原文，两件第三方在册样本仅做命名与定位层面的分析，未逐行核对其正文，凡属推断处均已标注。
Skill 的触发机制在官方规范里只有两条路：用户点名（斜杠命令或自然语言），或者模型读完 description 字段自行决定要不要用。这在本系列此前的触发工程专文里拆过，不展开。问题在于，这两条路都要求「有人先开口」——你要么打字，要么提出一个足够接近 description 的请求。
而用户嘴里的「自动化」从来不是这个意思。用户说的自动化是：「以后每次写完文件都帮我查一遍编码」「每天早上把新星榜跑一遍」「CI 红了直接去修，别等我」。这三句话有一个共同点：主语不是用户。执行时机被交给了系统事件、时钟和后台队列。SKILL.md 的 description 字段在这三种场景里全部失效——它只能影响「模型要不要选这个件」，影响不了「这个件根本没有被叫到的机会」。
这就是点火层存在的问题：它不在技能市场里上架，不占技能目录的名额，但缺了它，再强的件也只是个「随叫随到的钟点工」，而不是「自动化」。
flowchart TD
U["用户"] --> Q{"活怎么派"}
Q -->|"开口点名"| C1["手动件"]
Q -->|"描述自燃"| C2["触发件"]
Q -->|"立个规矩"| C3["hook哨兵"]
Q -->|"上闹钟"| C4["定时值守"]
Q -->|"甩后台"| C5["长任务件"]
C3 --> S["settings.json"]
S --> E["工具事件"]
E --> C3
C4 --> K["循环触发"]
K --> C4
C5 --> N["完成通知"]
N --> U
| 样本 | 通道 | 功能完整度 | 设计质量 | 实战效果 | 上手难度 | 社区活跃度* | 加权分 |
|---|---|---|---|---|---|---|---|
| loop | 定时 | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★ | 4.15 |
| update-config | 挂钩 | ★★★★ | ★★★★★ | ★★★★ | ★★★ | ★★★★ | 4.10 |
| fewer-permission-prompts | 自润滑 | ★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★ | 4.00 |
| gh-fix-ci（顺带提及） | 事件响应 | ★★★★ | ★★★ | ★★★★ | ★★★★ | ★★★ | 3.60 |
| long-running-agent | 后台 | ★★★★ | ★★★★ | ★★★ | ★★★ | ★★ | 3.35 |
| encoding-check | 挂钩 | ★★★ | ★★★★ | ★★★ | ★★★★ | ★★ | 3.25 |
*口径说明：本期未采集第三方榜单数据，社区活跃度一栏以「装机在册状态与官方背书程度」作定性档（内置件记高，清单在册但来源分散的记低），不等价于 Star 数。权重沿用系列标准：功能 25%、设计 25%、实战 20%、上手 15%、社区 15%。
update-config（内置，评分 4.10）
这个件的价值全在它自带的一段描述里。它的说明书写着大意如下的一条判断：「从现在起，每次 X 就做 Y」这类自动行为，必须靠在 settings.json 里配置 hooks 来实现——执行这些的是运行时外壳，不是模型，所以靠记忆、靠用户偏好文件都做不到。
这段话是整个点火层的地基。它承认了一个此前很多人没想明白的事实：模型的记忆系统装不下自动化。你在对话里说「以后每次改完代码都跑一下测试」，模型会点头、会记住这次会话里的承诺，但下次新会话开始，这份承诺就蒸发了。唯一能把规矩刻进运行时的位置是 settings.json 的 hooks 段——PostToolUse 挂在工具调用之后，PreToolUse 挂在之前，Stop 挂在回合结束。update-config 这个件干的活，就是把用户的自然语言规矩翻译成这份 JSON。
亮点：它是「元自动化」——别的件自动化你的任务，它自动化「给 Claude 立规矩」这件事本身。短板：上手门槛是四件里最高的，用户得理解 matcher、事件类型、命令注入这几个概念才能看懂配置结果；而且 hooks 跑的是 shell 命令，写错路径或权限会造成静默失败，排障成本不低。
loop（内置，评分 4.15，本期综合第一）
描述原文给出了明确的用法形态：/loop 5m /foo，即「按固定间隔循环执行一条提示词或斜杠命令」，裸跑时默认 10 分钟档。它的设计里有几个值得单独指出的细节：间隔语法直接复用 cron 的五段式思路但简化成了 5m、1h 这种后缀写法；默认档不设整点——这规避了所有用户挤在同一分钟触发造成的负载尖峰；循环任务默认只活在当前会话，显式要求「持久化」才落盘。这三个细节分别对应可靠性、公平性和安全兜底，属于把工程经验压进了默认值里。
它和通道一的本质区别：hooks 是事件驱动，没有事件就永远沉默；loop 是时间驱动，到点必跑，适合「新星榜每天盯一次」「CI 状态每半小时查一轮」这类没有明确触发信号、但需要持续看护的活。短板也在这里：时间驱动意味着无论有没有值得跑的事，它都会烧一轮上下文——高频间隔下成本不友好，官方描述里对「该等多久」给了一大段选择指引，恰恰说明这个通道最大的坑是节奏失控。
long-running-agent（清单在册，评分 3.35；仅做定位分析，正文未逐行核对）
这类件解决的是点火层的第三个空白：有些活不是「等事件」也不是「等时钟」，而是「跑得比对话慢」。批量重构、全仓扫描、连续跑半小时的测试，如果发生在对话线程里，用户只能干等。后台通道的做法是把任务甩进队列，对话线程立刻空出来，任务完成后以通知形式把人拉回来。
需要坦率说明：本件在装机清单中在册，但其 SKILL.md 正文本期未核对，以下是基于生态结构的推断——此类件的通用形态是封装「任务派发、进度查询、结果回收」三段接口，真正的并发能力来自运行时原生支持的后台任务机制，件本身更像一套使用纪律的说明书。基于这个保留，它的实战效果分只给了三星：通道价值确定，但具体件的完成度存疑。如果你要装它，建议先看一眼正文里有没有讲清楚「任务挂了怎么知道」——这是所有后台件的生死线。
fewer-permission-prompts（内置，评分 4.00）
四件里最不起眼、设计却最聪明的一个。描述写的是：扫描你的会话记录，找出常用的只读 Bash 和 MCP 工具调用，然后按优先级写进项目 settings.json 的允许清单。翻译一下：它把「权限弹窗」这个自动化流水线上最大的摩擦源，本身变成了一条自动化流水线。
它的聪明之处在于闭环的选点。点火层的前三个通道都在解决「什么时候开始干活」，这个件解决的是「干活途中会不会被拦下来」——一个后台值守任务跑得再准时，每五分钟弹一次权限确认，自动化就退化成了半自动。它选的原料是会话记录（历史行为是最真实的意图证据），选的落点是允许清单（一次性修复、永久生效），选的边界是只读调用（把误放行的风险压到最低）。功能分只给三星是因为它管不了写操作的白名单，那是刻意的保守；设计分给满，因为它找到了整条流水线上性价比最高的一颗螺丝。
清单里还有一批「消费端」样本：gh-fix-ci（红灯响应）、gh-address-comments（评论响应，此前 PR 门轴专文拆过，不重复）、encoding-check（写后校验）、sentry（线上错误流接入）。它们共同的特征是名字里自带触发条件——名字即事件源。这类件本身不含点火机制，必须挂在通道一的钩子上才有自动性：encoding-check 不配 PostToolUse 钩子，就只是个可以手动叫的检查件。这也是本期最想传达的判断：很多被当作「自动化技能」上架的件，其实是「可被自动化的件」——自动性在你这端的 settings.json 里，不在它的包里。
内置三件（loop、update-config、fewer-permission-prompts）随 Claude Code 分发，免安装：
# 定时通道：20分钟一轮盯任务，裸跑默认10分钟档
/loop 20m /你要循环的命令或任务描述
# 挂钩通道：自然语言立规矩，由 update-config 翻译成配置
# 对话里直接说：「以后每次写完或编辑文件，先检查编码」
# 自润滑通道：一句化触发扫描
# 对话里直接说：「把我的常用只读命令加进权限白名单」
挂钩通道的落点配置（update-config 生成的就是这类结构）：
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{ "type": "command", "command": "你的校验命令" }
]
}
]
}
}
清单在册的第三方件，先用注册表定位来源再装，避免装错同名件：
npx skills find long-running-agent
npx skills find encoding-check
# 确认来源仓库后
npx skills add 来源仓库/件名
开箱即用榜：loop ＞ fewer-permission-prompts ＞ update-config ＞ encoding-check ＞ long-running-agent（后两者需定位来源，前两件一句话就能跑）
设计含金量榜：fewer-permission-prompts ≈ update-config ＞ loop ＞ encoding-check ＞ long-running-agent（自润滑件把闭环选点做成了范本，元自动化件把「记忆装不下规矩」写成了判决书）
省时间预期榜：loop ＞ long-running-agent ＞ update-config ＞ encoding-check ＞ fewer-permission-prompts（时间通道解放的是「每天都要想起来去跑」的心智负担，收益最直接）
新手第一件推荐：loop。零配置、单命令、可随时停，是体会「点火层」存在的最低成本入口；玩明白再碰 settings.json。
五期拆下来，自动化赛道的图景逐渐完整：市场上有替你部署的件、修 CI 的件、盯监控的件，但把它们串成「不用叫的系统」的，从来不是任何一件商品，而是四条点火通道——钩子刻规矩，闹钟管节奏，后台扛时长，白名单拆路障。下期回到新星首发赛道，看看这批点火件本身会不会成为被卷的下一条供给线。
npx skills find/add 命令的来源[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。