# 接缝层八件横评：从触发到验收 ## 概述 工作流自动化这条线，前面几轮已经拆过大半个地图：部署四方言做过二审，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 的出厂配置里。本机技能注册清单里，真正承担「从触发到收尾」职能的是八个名字，按流水线位置分五层： ```mermaid 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 数据一律没有，改用「服役状态」替代——内置常驻表示随时可唤起，按需表示用到才加载。这是本文与往轮最大的方法论差异，也是最诚实的一种处理。 ## 调度层：loop，把对话变成班车 **注册描述原文**： > 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` 会进入自治模式，由调度器自己决定下一轮做什么。这让它从「闹钟」升格成「值班员」——但也埋了最需要警惕的一颗雷：自治循环没有人类输入校准，跑偏不会有人喊停。实战建议只有一条：**自治模式只用于有明确产出物的场景**（轮询某个状态、盯某个进度），产出「判断」而非「文件」的循环务必挂人类提示词。 使用命令： ```bash # 最简形态：每5分钟跑一次已有斜杠命令 /loop 5m /code-review # 中文任务提示词同样合法 /loop 15m 检查 docs/ 下新增文件并汇总成三行周报 # 自治模式（慎用，只盯明确产出物） /loop ``` ## 并联层：deep-research，流水线的发动机样板 八件里设计密度最高的一件。**注册描述原文**： > 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 研究最大的痛点——一本正经的幻觉。把「反幻觉」写进流程而不是写进免责声明，是这一件区别于普通「搜索总结器」的本质特征。 还有一个容易被略过的门槛设计：触发前先问清。描述里明确要求，若问题不够具体，先用两三个澄清问题收窄范围，再带上下文开跑。**先查户口，再开工**——这一句放在触发器里，比放在文档里有效十倍，因为用户永远不读文档，但模型一定读描述。 ```mermaid flowchart TD Q["问题进门槛"] -->|不够具体| C["先发2-3个澄清问题"] C --> Q Q -->|足够具体| F["多角度并联搜索"] F --> G["逐路取原文"] G --> V["对抗核查每个结论"] V --> S["带引用合成报告"] ``` 短板也直说：它只产出「带引用的报告」，不产出可执行动作。研究完的下一步（建文件、发通知、改配置）得由别的件接手——这正是接缝层存在的意义，它在等一个调度器把它串进班车。 ## 验收层：verify 与 run，「跑起来」两件套 **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 与 simplify，分工写进门牌 **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，让审查对象漂移。 ## 规矩层：update-config，把「从今往后」变成机器可执行 八件里最被低估的一件。**注册描述原文**： > 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 本机清单里还有一个与调度层强相关的名字：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 记得」——任何涉及自动化的件，都应该在描述里写明动作由谁执行、什么时候执行，否则用户以为设置了自动化，实际只是让模型多了段回忆。 ## 参考来源 1. 本机 Claude Code 技能注册清单（/skills 实录，2026-09-15 读取）——本文八件名称与全部引用描述的原文出处 2. [anthropics/skills](https://github.com/anthropics/skills) — 官方 Skills 仓库，编辑提供的追踪入口；本轮抓取通道受限，未做远端核对 3. [skillsmp.com](https://skillsmp.com) — 2300+ Skills 可搜索目录，后续补查热度数据时的首选入口 4. [mcpservers.org/agent-skills](https://mcpservers.org/agent-skills) — 官方+社区精选目录，与本文同层级的编排类件可在后续轮次补拆 5. [skills.sh](https://skills.sh) — Skills 生态热门榜，long-running-agent 等观察名单成员的下一站核对入口 > [!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 等场景全覆盖。