工作流自动化这条线，前面几轮已经拆过大半个地图：部署四方言做过二审，CI 从救火拆到无人值守，编排与监控六件过过堂，跨宿主协作和回滚缝隙也都有专文。但把这条流水线从头走到尾，会发现真正没人拆的是件与件之间的接缝——一个任务怎么被定时唤起、怎么并联铺开、干完了谁来验收、验收过了谁来质检、最后规矩沉淀到哪。本轮换掉「找新架上架」的思路，改为对一台真实工作机上实际在役的八个内置件做装机横评：调度层的 loop、并联层的 deep-research、验收层的 verify 与 run、质检层的 code-review 与 simplify、规矩层的 update-config 与 fewer-permission-prompts，外加一件只闻其名的观察名单成员 long-running-agent。所有引用文本均来自本机技能注册时的描述原文，未抓取远端仓库，因此本文不出现任何 Star 数与下载量——这也是一次把评测维度强行「去热度化」的实验。
先交代选题排除法。部署层四件（Vercel、Netlify、Cloudflare、Render 方言对接）上月已做过二审；CI 层的救火与无人值守、PR 评审流水线、发版记档各有一篇；编排监控六件、跨宿主三台引擎、回滚缝五件也都交过卷。再把榜单翻一遍，剩下的空位不在「又一组新件」，而在一个更朴素的问题上：这些件装好了，谁把它们串起来？
串接的答案不在市场里，而在每一台 Claude Code 的出厂配置里。本机技能注册清单里，真正承担「从触发到收尾」职能的是八个名字，按流水线位置分五层：
flowchart TD
A["调度层 loop"] -->|定时唤醒| B["并联层 deep-research"]
A -->|定时点名| F["验收层 verify"]
B -->|报告落地| F
F -->|应用能跑| C["质检层 code-review"]
C -->|bug清零| D["简化件 simplify"]
D -->|结论沉淀| E["规矩层 update-config"]
E -->|高频放行| G["清单件 fewer-permission-prompts"]
这张图就是本轮的评测对象。下面逐层过堂。
| 件 | 功能完整度 25% | 设计质量 25% | 实战效果 20% | 上手难度 15% | 服役状态 15% | 综合 |
|---|---|---|---|---|---|---|
| deep-research | ★★★★★ | ★★★★★ | ★★★★ | ★★★★ | 内置·常驻 | ★★★★★ |
| loop | ★★★★ | ★★★★★ | ★★★★ | ★★★★★ | 内置·常驻 | ★★★★★ |
| update-config | ★★★★ | ★★★★★ | ★★★★ | ★★★ | 内置·常驻 | ★★★★☆ |
| code-review | ★★★★ | ★★★★★ | ★★★★ | ★★★★★ | 内置·常驻 | ★★★★☆ |
| verify | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | 内置·常驻 | ★★★★ |
| simplify | ★★★ | ★★★★ | ★★★ | ★★★★★ | 内置·常驻 | ★★★☆ |
| run | ★★★ | ★★★★ | ★★★ | ★★★★★ | 内置·常驻 | ★★★☆ |
| fewer-permission-prompts | ★★★ | ★★★★ | ★★★ | ★★★★ | 内置·按需 | ★★★☆ |
两点口径说明。其一，「实战效果」的判分依据是这八件在本机的真实服役痕迹（被调用的频率与兜底的场合），不是社区口碑转述。其二，「社区活跃度」维度在本轮整体缺席：由于抓取通道受限，远端 Star 与 Issue 数据一律没有，改用「服役状态」替代——内置常驻表示随时可唤起，按需表示用到才加载。这是本文与往轮最大的方法论差异，也是最诚实的一种处理。
注册描述原文：
Run a prompt or slash command on a recurring schedule (/loop 5m /foo, defaults to 10m). For an autonomous /loop (no user prompt)…
逐句拆。第一句有半句是语法：/loop 5m /foo——调度对象不是脚本，而是提示词或斜杠命令。这是整个设计里最值钱的一个决定：它意味着你已经装好的任何一件（评测、部署、周报）都自动获得定时触发能力，不用为调度单独适配。市场上很多自动化件走的是另一条路：自带 cron 解析器、自带任务队列，结果每件都要学一遍自己的调度方言。loop 把调度做成公共层，方言问题根本不出现。
第二处细节是「defaults to 10m」。默认十分钟一班的保守节奏，暴露了作者对这类工具翻车方式的理解：定时任务的默认值一旦太激进（比如默认每分钟），新手第一次试用就会把 API 配额打穿，然后永远卸载。十分钟是一个「先跑起来、再加压」的教化节奏。
第三处是自治分支：不带用户提示词的 /loop 会进入自治模式，由调度器自己决定下一轮做什么。这让它从「闹钟」升格成「值班员」——但也埋了最需要警惕的一颗雷：自治循环没有人类输入校准，跑偏不会有人喊停。实战建议只有一条：自治模式只用于有明确产出物的场景（轮询某个状态、盯某个进度），产出「判断」而非「文件」的循环务必挂人类提示词。
使用命令：
# 最简形态：每5分钟跑一次已有斜杠命令
/loop 5m /code-review
# 中文任务提示词同样合法
/loop 15m 检查 docs/ 下新增文件并汇总成三行周报
# 自治模式（慎用，只盯明确产出物）
/loop
八件里设计密度最高的一件。注册描述原文：
Deep research harness — fan-out web searches, fetch sources, adversarially verify claims, synthesize a cited report.
短短一行，五个动词把一条完整流水线的五个工位全部点名：fan-out（并联散开）、fetch（落地取原文）、verify（对抗核查）、synthesize（合成）、cite（带引用）。拆两个最见功力的地方。
第一是 fan-out 的「散开-收拢」结构。 它不是「多搜几次」，而是把一个研究问题拆成多个独立搜索角度同时铺开，每个角度各自取原文、各自得出中间结论，最后才收拢合成。这正是多 Agent 协作的最小可用单元：不需要用户理解任何编排概念，一句「帮我深度研究 X」就触发了整套并联。市场上不少编排件要求用户先画好 DAG、定义好节点再开跑，把流水线图纸摊在了用户脸上；deep-research 把图纸藏在一句自然语言后面，这是两种设计哲学的分水岭。
第二是 adversarially verify 这个短语。 「对抗式核查」意味着每个关键结论都要经过一个立场相反的核查者试图推翻，推翻不掉才算幸存。这直接回应了 AI 研究最大的痛点——一本正经的幻觉。把「反幻觉」写进流程而不是写进免责声明，是这一件区别于普通「搜索总结器」的本质特征。
还有一个容易被略过的门槛设计：触发前先问清。描述里明确要求，若问题不够具体，先用两三个澄清问题收窄范围，再带上下文开跑。先查户口，再开工——这一句放在触发器里，比放在文档里有效十倍，因为用户永远不读文档，但模型一定读描述。
flowchart TD
Q["问题进门槛"] -->|不够具体| C["先发2-3个澄清问题"]
C --> Q
Q -->|足够具体| F["多角度并联搜索"]
F --> G["逐路取原文"]
G --> V["对抗核查每个结论"]
V --> S["带引用合成报告"]
短板也直说：它只产出「带引用的报告」，不产出可执行动作。研究完的下一步（建文件、发通知、改配置）得由别的件接手——这正是接缝层存在的意义，它在等一个调度器把它串进班车。
verify 的注册描述原文：
Verify that a code change actually does what it's supposed to by running the app and observing behavior.
拆开看，这句定义里藏着对「验收」一词的完整态度：运行应用 + 观察行为，而不是读 diff。读 diff 验收的是「代码看起来对」，跑起来验收的是「事情真的发生了」。描述还点名了三个触发场景：被要求验证一个 PR、确认一个修复真的生效、push 之前手动过一遍。三个场景共用同一个哲学——交付前的最后一道闸，宁可用最笨的方式（真跑一遍）。
run 是它的前置工位，描述原文：
Launch and drive this project's app to see a change working… first looks for a project skill that already covers launching; otherwise falls back to patterns per project type (CLI, server, TUI, Electron, browser-driven).
两处设计值得点名。一是「先找项目自带技能，再按项目类型兜底」——这是一个尊重生态的接缝写法：如果仓库里已经有人写了启动方式，就复用；没有才按 CLI、server、TUI、Electron、浏览器五类常见形态套模板。二是它把「应用类型」显式列成清单，等于告诉模型：不知道怎么启动时，从这五个格子开始猜，不要凭空编命令。
两件套合起来的短板是 verify 依赖环境：测试环境起不来的项目，验收闸门等于虚设。它不会替你修环境，描述里也没有承诺这一点——边界划得很干净。
code-review 原文关键段：
Review the current diff for correctness bugs and reuse/simplification/efficiency cleanups… Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree.
三个设计点。范围锁死在「当前 diff」——不翻旧账，审查成本与改动量成正比，这是审查类工具能不能被高频使用的关键。目标分两类：正确性 bug 和复用/简化/效率类清理，且明确「低中档位只报少而准的高置信发现」——把查全率与查准率的权衡做成档位开关，交给用户按场合选，而不是替用户做主。两个出口：--comment 把发现贴成 PR 内联评论，--fix 直接改工作区。发现与动作分离，人类保留决定权。
simplify 是它的分工搭档，原文里有一句罕见的「负面声明」：
…then apply the fixes. Does not hunt for bugs; use /code-review for that.
「不抓 bug，抓 bug 请找隔壁」——把自己不做什么直接写进门牌。这在设计上极聪明：两个件最怕的就是用户分不清边界、随便调一个然后抱怨漏报。simplify 还多了一项「altitude cleanups」（抽象层级修正），即代码不是写错了，而是写矮了——该抽函数的没抽、该上移的逻辑留在了原地。这类问题普通 lint 抓不到，是质检流水线上真正的增量工位。
两件合用的顺序固定：先 /code-review 清 bug，再 /simplify 做清理。反着跑会被 simplify 改动过的代码打乱 diff，让审查对象漂移。
八件里最被低估的一件。注册描述原文：
Automated behaviors (“from now on when X”, “each time X”, “whenever X”…) require hooks configured in settings.json - the harness executes these, not Claude, so memory/preferences cannot fulfill them.
这一段值得逐句抄进任何一本提示词工程教材。它解决的是一个真问题：用户说「以后每次改完代码都跑一下测试」，这句话如果被记进记忆或偏好文件，永远只会被「想起」，不会被「执行」——因为记忆没有执行权。update-config 的描述把这条边界写得斩钉截铁：自动化行为必须落成 settings.json 里的 hooks，由 harness 执行，而不是由模型记得。
更细的是它对触发语句式的枚举：「从今往后当 X」「每次 X」「无论何时 X」——把自然语言里的承诺句式直接映射到 hook 配置。用户不需要知道 hooks 的 JSON 结构，说人话即可；翻译工作由这件完成。描述还顺手做了减法：能用 /config 命令解决的，就不建议动文件。
配套的 fewer-permission-prompts 干的是另一件烦人事：扫描本机的真实使用记录（transcripts），把高频出现的只读 Bash 和 MCP 调用挖出来，生成带优先级的放行清单写进项目级 .claude/settings.json。它的聪明在于数据来源——不从文档出发，从你自己的历史行为出发。每个人高频只读操作都不一样，照抄别人的放行清单没有意义，抄自己的才有。
规矩层这一对的共同短板：都是「写配置」的件，写错了配置影响面比普通件大。hooks 配错可能导致每次操作都弹确认或静默失败，上手难度因此是八件里最高的，建议改完 settings 后立刻用一个小任务实测一遍。
本机清单里还有一个与调度层强相关的名字：long-running-agent。诚实声明：它的注册描述未在本轮可用材料中展开，无法引用原文，也正因此不参与本轮评分——按本文开头的口径，没有原文的件不硬拆。它被列入观察名单的理由只有一个：从命名看，它与 loop 构成「定时短跑 vs 常驻长跑」的互补位，若下一轮抓取通道恢复，值得单独开一篇做首拆。这里只留一个悬念：如果长跑件的描述里也有一句类似「Does not hunt for bugs」式的负面声明，那将是本文「负面声明设计」论点的第二个证据。
设计教科书榜（学写 SKILL.md 必抄）： 1. update-config——「记忆无执行权」的边界宣言，一句话救一个幻觉 2. deep-research——五个动词讲完一条流水线，对抗核查写进流程 3. simplify——「Does not hunt for bugs」式负面声明，边界即卖点
开箱即用榜（零配置上岗）：
1. code-review——有 diff 就能跑，--comment/--fix 两个出口
2. verify——push 前一道闸，跑起来才算数
3. loop——一句话上岗的定时器
提效上限榜（用对了改变工作方式）： 1. deep-research——把数小时的多源交叉验证压成一次触发 2. loop——把一次性对话升格成值班制度 3. fewer-permission-prompts——从自己的历史里挖出专属放行清单
新手第一件：loop。语法一个斜杠加一个间隔，五分钟理解调度层是什么；理解了调度层，接缝层其余七件就都有了串起来的绳子。
从这八件的描述原文里，能提炼出三条可迁移的写法模式。其一，动词链开场：deep-research 用 fan-out → fetch → verify → synthesize → cite 五个动词把机制全部说完，没有一个形容词——描述里的动词密度就是信息密度。其二，负面声明：simplify 的「不抓 bug」、code-review 的「低档位只报高置信」，都是在描述里主动交代自己不做什么，防误用比防不用更重要。其三，执行权归属写清楚：update-config 点破「harness 执行，不是 Claude 记得」——任何涉及自动化的件，都应该在描述里写明动作由谁执行、什么时候执行，否则用户以为设置了自动化，实际只是让模型多了段回忆。
[!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 等场景全覆盖。