# 无人值守：把人从回路里拿掉的出厂六件横评 ## 概述 ## 一、欠账与纠偏：为什么是这六件 三处存档共同指向这批样本。其一，09-03 第 3 轮拆出厂开发效率四件套（code-review/simplify/verify/run）时，文末点名 review、security-review、gh-fix-ci、gh-address-comments、sentry、loop 等「名字在册、描述未随清单给出，留待后续轮次」；同文给 loop 打了 3.45 的过渡分，理由是它是「把前面所有件变成值守流程的胶水」。其二，09-03 第 5 轮拆部署四单兵时明确记下「gh-fix-ci 被标为留待后续 CI 专题，本期不越界」。其三，同一期文末的全景 mindmap 把「触发与修复」标注为已拆——这个标注其实过于乐观：gh-fix-ci 只是名字被反复路过，正文从未被拆过。本期纠偏。 ## 二、评测总表 权重按本系列标准（功能 25% / 设计 25% / 实战 20% / 上手 15% / 社区 15%）。带※者为黑箱估分：仅有名称在册，评分依据名字契约、同族形态与生态位推断。 | 维度 | update-config | fewer-permission-prompts | loop | gh-fix-ci※ | gh-address-comments※ | long-running-agent※ | |------|------|------|------|------|------|------| | 功能完整度 (25%) | ★★★★★ | ★★★★ | ★★★ | ★★★★ | ★★★ | ★★★★ | | 设计质量 (25%) | ★★★★★ | ★★★★★ | ★★★★ | ★★★ | ★★★ | ★★★★ | | 实战效果 (20%) | ★★★★ | ★★★★ | ★★★★ | ★★★★ | ★★★ | ★★★ | | 上手难度 (15%) | ★★★★ | ★★★★★ | ★★★★★ | ★★★★ | ★★★★ | ★★★ | | 社区活跃度 (15%) | ★★★★ | ★★★★ | ★★★★ | ★★★★ | ★★★ | ★★★ | | **加权综合** | **4.50** | **4.40** | **3.90** | **3.75※** | **3.15※** | **3.50※** | ## 三、逐件拆解：按去人化链路排序 ### 1. update-config：把「以后每次都 X」写进 settings.json 六件里描述最丰满的一件。它的触发词设计值得逐句读：用户说「from now on when X」「each time X」「whenever X」「before/after X」这类**承诺未来行为**的话时触发——因为这些事 Claude 自己做不到。描述里有一句罕见的元认知声明：这类自动化行为需要 hooks 配置在 settings.json 里，「the harness executes these, not Claude, so memory/preferences cannot fulfill them」（由 harness 执行，记忆和偏好无法兑现）。这是在出厂描述里直接教模型认识自己的能力边界——**把「我记住了」和「系统会执行」划清界限**，堵住了 Agent 最常见的一种幻觉式承诺。它的管辖范围三分：权限（allow 类请求）、环境变量（「set X=Y」）、hook 排障，外加一切 settings.json/settings.local.json 的改动。在去人化链路里它是地基：没有它，后面五件的每一次运行都会被权限弹窗打断。 ### 2. fewer-permission-prompts：读你自己的历史，给自己发通行证 描述一句话：「Scan your transcripts for common read-only Bash and MCP tool calls, then add a prioritized allowlist to project .claude/settings.json」。三个设计点都写在这一句里。**输入是 transcripts**——它不问你想要什么权限，而是翻你自己的使用记录找证据，这是出厂件里罕见的「自反思型」技能：以 Agent 自身行为为输入；**只收 read-only**——写操作永远不进白名单，安全边界刻在描述里；**prioritized**——白名单不是平铺清单而是带优先级的结构，写入位置锁定项目级 `.claude/settings.json` 而非全局，天然做了爆炸半径控制。它和 update-config 是同一条授权线上的两代设计：前者是应答式（你说它配），后者是巡逻式（它扫历史主动提案）。社区对照件 backpass 用「梯度下降训 AGENTS.md」的隐喻做类似的事，但出厂版的哲学更保守也更可信——**不改模型行为，只改放行清单**。 ### 3. loop：把一次性指令变成值守岗 描述原文「Run a prompt or slash command on a recurring interval (e.g. /loop 5m /foo, defaults to 10m in dynamic mode)」。上一期给它 3.45 的过渡分，本期升到 3.90，理由要说清：往期按**单件价值**评它（定时器天花板低），本期按**链路价值**评——去人化流水线里，「人触发」是比「人批准」更高频的环节，loop 把 `/code-review` 这类一次性指令变成每 30 分钟一班的巡逻岗。设计上有三个克制点：默认间隔设在 10 分钟这一保守值而非激进轮询；动态模式下复用同一条 prompt 保证任务不漂移；触发时机绑定 REPL 空闲态，避免和手头任务抢跑。短板也明确：周期性唤醒意味着每轮都是一次上下文加载，间隔设太密就是烧 token 的定时炸弹——它把「什么时候跑」交给你，把「跑太多」的风险也交给你。 ### 4. gh-fix-ci：红灯自愈，动词锁定职责※ 黑箱件，但名字本身是一份契约。CI 自动化这个赛道上，名字普遍起得很大（CI copilot、CI agent），而它叫 **fix**-ci——动词锁定单一职责：不管写 CI（那是 github-actions-skill 的地盘，06-30 存档明确过两者「一个管写对、一个管修好」的分工）、不管看板、不管告警，只管红灯变绿。从同族形态推断（※）：它的调用入口大概率是 CI 失败场景本身（failed run 的上下文里触发），执行路径大概率复用 gh 的 run log 读取 + 本地复现 + 提交修复的闭环——与部署四单兵「确定性下沉到脚本」的路数相反，CI 修复没法全脚本化，因为每场红灯的病因都不同，这恰恰是提示词层该干的活。它在链路上的位置：部署四单兵管「推上去」，它管「挂了拉回来」。风险点：自愈类件的爆炸半径天然大于白名单类——修 CI 的最快路径有时是改测试，这类越权修复有没有闸门，描述未在册，无法验证，装机前建议先在小仓库试（※）。 ### 5. gh-address-comments：替你答辩的边界与风险※ 黑箱件，六件里星数最低的一件，但它的生态位值得单独说。PR 评论是「人在回路」里最琐碎的环节：审查者的问题要逐条回应、改完要标记 resolved、催合并要礼貌地拖。名字用 **address** 而非 reply 是个措辞信号（※推断）：reply 只覆盖回帖，address 涵盖「回应-修复-关闭」全套动作，意味着它的目标不是替你说话，而是把评论线程清零。它是六件里唯一**对外发声**的件——update-config 改的是本地文件，gh-fix-ci 提交的是代码，而它以你的身份在公共场合发言。这决定了它的风险等级天然最高：语气失当是品牌事故，误答技术问题是专业事故。所以本期只给 3.15（※黑箱估分），且建议的使用姿势是草稿模式——让它拟好答辩稿、人过目后再发。无人值守不等于无人负责，这件是全链路里最不该全托管的一件。 ### 6. long-running-agent：长任务的最后一环※ ## 四、去人化链路模型 六件各拆掉一个「人在回路」环节，拼起来是一条完整的无人值守流水线： ```mermaid flowchart LR A[人批准权限] -->|update-config 声明式配置| A1[settings.json 兑现] B[人反复放行] -->|fewer-permission-prompts 扫描历史| B1[只读白名单自动提案] C[人手动触发] -->|loop 定时复用指令| C1[空闲态自动开工] D[人盯 CI 红灯] -->|gh-fix-ci 动词锁定| D1[自愈提交修复] E[人逐条答辩] -->|gh-address-comments 清零线程| E1[草稿建议人终审] F[人守长任务] -->|long-running-agent 托管接续| F1[完成后回报] A1 --> C1 --> D1 --> E1 B1 -.放行提速.-> C1 D1 -.修复后可自动重部署.-> F1 ``` 生态分类一张图： ```mermaid mindmap root((出厂自动化六件)) 授权线 update-config 声明式 fewer-permission-prompts 自反思式 调度线 loop 周期触发 long-running-agent 长任务托管 修复与答辩线 gh-fix-ci 红灯自愈 gh-address-comments 评论清零 ``` ## 五、可抄的四个设计模式 给想写自己第一个 Skill 的读者，这六件贡献了四种可复用写法。**P1 反模式排除**：update-config 在描述里写明「memory/preferences cannot fulfill them」，主动堵住错误路由——好的触发词不仅说清何时触发，还说清别的件为什么做不到。**P2 安全边界前置**：fewer-permission-prompts 把「只收 read-only」写进一句话描述的第一行，边界不是脚注是门面。**P3 动词命名单一职责**：gh-fix-ci 不叫 gh-ci、不叫 ci-agent，fix 一个动词把职权范围钉死，名字即合约——黑箱件靠这个也能让用户预期精准。**P4 以自身为输入**：fewer-permission-prompts 扫描 transcripts 的设计证明 Skill 的输入不必是外部数据，Agent 自己的历史就是最个性化的语料——社区件 backpass 用「梯度下降」的隐喻包装的正是同一个洞察，但出厂版不用隐喻，直接说扫描什么、写到哪里去。 ## 六、安装与使用 六件全部随 Claude Code 本体内置，**零安装**，升级 harness 即得。调用形态： ```bash # loop：slash 命令直接调（描述原文示例） /loop 5m /foo # 组合示意（效果未实测，仅示意链路）：每 30 分钟巡逻一次审查 /loop 30m /code-review # update-config / fewer-permission-prompts / gh-fix-ci / gh-address-comments # 自然语言触发（触发场景均出自出厂描述或名字契约）： # "whenever tests pass, notify the channel" → update-config（hook 类） # "set DEBUG=true" → update-config（环境变量类） # "scan my transcripts and build an allowlist" → fewer-permission-prompts # "fix the failing CI" → gh-fix-ci※ # "address the review comments on PR #42" → gh-address-comments※ ``` ## 七、分维度排行榜 - **按开箱即用**：fewer-permission-prompts ＞ loop ＞ update-config ＞ gh-fix-ci※ ＞ gh-address-comments※ ＞ long-running-agent※ - **按设计质量**：update-config ＞ fewer-permission-prompts ＞ loop ＞ long-running-agent※ ＞ gh-fix-ci※ = gh-address-comments※ - **按链路不可替代性**：update-config ＞ gh-fix-ci※ ＞ loop ＞ fewer-permission-prompts ＞ long-running-agent※ ＞ gh-address-comments※ - **按风险收益比（综合价值除以托管风险）**：fewer-permission-prompts ＞ update-config ＞ loop ＞ gh-fix-ci※ ＞ long-running-agent※ ＞ gh-address-comments※ - **本期金榜**：🥇 update-config（4.50，元认知写进触发词的地基件）· 🥈 fewer-permission-prompts（4.40，自反思型设计范本）· 🥉 loop（3.90，链路价值的胶水件） ## 八、无人值守的三道闸 最后说清风险边界，三个建议按顺序执行。**第一道闸，先建白名单再谈自动化**：fewer-permission-prompts 的只读边界是整条链路里最硬的安全设计，任何人在开 loop 和 gh-fix-ci 之前都应该先跑它——放行清单越准，无人值守时的打断和越权越少。**第二道闸，修复类件限仓试运行**：gh-fix-ci 的描述未在册（※），闸门设计不明，先在无生产数据的小仓库验证它对「改测试凑绿灯」这类捷径的抵抗能力。**第三道闸，对外发声永远留人**：gh-address-comments 是唯一以用户身份对外发言的件，草稿终审模式应该是默认姿势。无人值守的正确读法不是「没人」，而是**人从六个高频环节退到一处终审席**——这六件的真正产品哲学，是让人的位置从回路里挪到回路上。 ## 参考来源 > [!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 等场景全覆盖。