<!-- title: 红灯自愈：CI值守六件横评 -->

# 红灯自愈：CI值守六件横评

## 概述

上一轮「部署四件横评」看的是云门——Vercel、Netlify 那类一键上云的口子。但多数真实项目不上 PaaS：代码推到 GitHub，Actions 跑流水线，最后落到一台自家 VPS。这一期顺着出货的路往前走，把云门之后的工位补齐：**谁来写流水线、红灯亮了谁来修、评审意见谁来清、线上报错谁来盯、跨天的长班谁来值**。本期拆解七件（六件主评加一件彩蛋），全部基于本机装机原文逐行细读。核心发现有二：其一，这一层的件不卷功能卷「刹车」，设计最好的 SKILL.md 都在防模型自作主张、防凭据泄漏、防状态丢失；其二，件正在跨工具流动——有一件的身体里明显住着别家 harness 的路径。

## 评测对比表

| Skill | 定位 | 功能完整度 25% | 设计质量 25% | 实战效果 20% | 上手难度 15% | 社区活跃度* 15% | 加权总分 |
|---|---|---|---|---|---|---|---|
| gh-fix-ci | 修红灯 | ★★★★ | ★★★★★ | ★★★★ | ★★★★ | ★★★ | **4.1** |
| github-actions-skill | 写管线 | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★ | **4.0** |
| long-running-agent | 值长班 | ★★★★ | ★★★★★ | ★★★★ | ★★★ | ★★★ | **4.0** |
| skill-sync-github | 备份自身 | ★★★★★ | ★★★★ | ★★★★★ | ★★★★ | ★ | **4.0** |
| sentry | 盯线上 | ★★★★ | ★★★★★ | ★★★ | ★★★ | ★★★★ | **3.9** |
| planning-with-files | 记台本 | ★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★ | **3.9** |
| gh-address-comments | 清评审 | ★★★ | ★★★ | ★★★ | ★★★★ | ★★★ | **3.2** |

*注：本期素材全部来自本机装机原文，未做联网数值核验，「社区活跃度」按生态常见度与文本成熟度估评，仅供参考。

## 第一站 写管线：github-actions-skill

名字叫 github-actions-skill，其实不碰 CI 的 test/build 段，只管最后一公里：把 GitHub Actions 连到自家 VPS 上。它的设计是标准的问答式向导——**每次只问一个问题**，从 VPS 地址、SSH 用户名、部署路径一路问到部署方式（命令执行还是 rsync），可选项全部给默认值（端口默认 22、分支默认 main）。收集完用表格让用户逐项确认，然后一口气吐出四样东西：ed25519 密钥生成命令、`ssh-copy-id` 上服务器命令、GitHub Secrets 配置清单、可直接落盘的 `deploy.yml`。

亮点是把最容易翻车的三件事——密钥、Secrets、部署脚本——全部拆成清单交给用户点头，模板用的是 `appleboy/ssh-action@v1.0.3` 这类 pinned 版本，不给模型自由发挥的空间。短板也清楚：纯提示词件，无校验脚本，SSH 通不通要用户自己跑测试命令；rsync 模板里 `ssh-keyscan` 直接信任首次指纹（TOFU），安全洁癖者会皱眉。和上一期的云门四件正好互补：那四件管 PaaS，这件管你自己的裸机。

```bash
# 纯提示词件，装完即用，无需任何依赖
npx skills find github actions deploy
npx skills add <owner/repo>@<skill-name> -g -y
```

## 第二站 修红灯：gh-fix-ci

全场唯一的端到端流程件：认证检查 → 定位 PR → 拉失败 check → 抠 Actions 日志 → 摘要失败片段 → 出修复计划 → **用户批准后才动手** → 修完建议复跑 `gh pr checks` 确认。它自带一个 `inspect_pr_checks.py`，这是整份 SKILL.md 最值钱的部分。

它的三个防翻车细节值得所有件作者抄：

1. **防 gh 字段漂移**。gh CLI 的 JSON 输出字段会随版本变动，脚本注释明写「handles gh field drift and job-log fallbacks」，手动兜底路径还加了一句「If a field is rejected, rerun with the available fields reported by gh」——字段被拒就用实际返回的字段重跑，不硬编码假设。
2. **天生可被自动化调用**。脚本「Exits non-zero when failures remain」——失败没清零就非零退出，外层脚本、CI、定时任务都能拿它当探针。
3. **边界纪律写死**。非 GitHub Actions 的 check（比如 Buildkite）只标记为 external 报告 URL，原话是「Do not attempt Buildkite or other providers; keep the workflow lean」——不越界，不装懂。

短板：强绑定 gh CLI 与 Python 环境，monorepo 多工作流场景没有专门策略。

```bash
# 前置：gh 已认证（repo + workflow scopes）
gh auth login && gh auth status
# 安装
npx skills find gh fix ci
npx skills add <owner/repo>@<skill-name> -g -y
```

## 第三站 清评审：gh-address-comments

只有三步的极简件：`fetch_comments.py` 拉全部评论和评审线程 → 编号加摘要，问用户要修哪几条 → 动手改。它的精髓在第二步：**评审意见不是每条都该听**，这个件把否决权明确留给人，模型只负责把每条意见「修起来要干什么」讲清楚。

短板是失败路径几乎没设计：拉取脚本挂了没有 fallback，认证过期只有一句「prompt the user to re-authenticate」。另有一个隐藏门槛——它假设你在沙盒环境里跑 gh，SKILL.md 里明说被沙盒拦截就要以提权方式重跑 `gh auth status`，这在默认沙盒化的 harness 里是必要交代，对新 手不算友好。建议和 gh-fix-ci 当兄弟件一起装：一个修红灯，一个清评审，覆盖 PR 生命周期的两大琐事。

```bash
npx skills find pr review comments
npx skills add <owner/repo>@<skill-name> -g -y
```

## 第四站 盯线上：sentry

全场安全设计最讲究的一件。开篇就立了三条铁律：token 只要读权限（`project:read`、`event:read`）；「Never ask the user to paste the full token in chat」——引导用户自己在系统里设环境变量，绝不让他把 token 贴进对话；输出强制 PII 脱敏，「Do not print raw stack traces」。

执行层同样克制：所有 API 调用走自带的 `sentry_api.py`（自带分页和一次瞬时错误重试），四个 GET 端点写死在 SKILL.md 里，并且明令「Always call the Sentry API (no heuristics, no caching)」——不许模型猜，只许问 API，杜绝凭训练记忆编造 issue 状态这类事故。

最有意思的细节藏在环境变量里：`export CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"`，默认技能目录写的是 `~/.codex/skills`。这是一件从 Codex 生态漂流过来的件——SKILL.md 这个格式正在变成跨 harness 的通用载体，写法本身已经工具无关。短板：只读，看得见摸不着，报错处置要靠别的件接力；上手要先去网页建 token，多一道门槛。

```bash
# 前置：在 sentry.io/settings/account/api/auth-tokens/ 建只读 token
export SENTRY_AUTH_TOKEN=...   # 只读 scopes
# 安装
npx skills find sentry
npx skills add <owner/repo>@<skill-name> -g -y
```

## 第五站 值长班：long-running-agent

解决一个要命的问题：上下文窗口会死，活儿不能死。它的答案是两班制。**初始化员**只上第一班，留下三样遗产：`init.sh`（一键拉起环境）、`feature_list.json`（全部需求的通过/失败清单）、`claude-progress.txt`（逐班日志），外加首次 git 提交。**编码员**每班按七步开机自检：pwd → 读进度 → 读清单 → 看 git log → 跑 init.sh → 跑冒烟测试 → 挑一个失败的 feature 开工。

最狠的设计是清单格式选择。SKILL.md 原话：「Use JSON format to prevent inappropriate edits」——模型改 Markdown 会手痒，改 JSON 至少要守 schema；测试描述不许动一个字，只许翻 `passes` 布尔位，而且「Mark as passing ONLY after end-to-end verification」。它还附了一张常见翻车表：「一次性梭哈整个项目」「看到半成品就宣布完工」「留下坏状态就下班」，每条配了对应解法。

短板：仪式感偏重，小活儿用它属于杀鸡用牛刀；端到端验证依赖浏览器自动化（文中点名 Puppeteer MCP），没配就执行不到位。

```bash
npx skills find long running agent
npx skills add <owner/repo>@<skill-name> -g -y
```

## 第六站 记台本：planning-with-files

开篇自报家门：「Work like Manus: Use persistent markdown files as your working memory on disk.」——把工作记忆落到磁盘三个文件里：`task_plan.md`（阶段与勾选）、`notes.md`（调研发现）、`deliverable.md`（成品）。每完成一个阶段就回去打勾，每个大动作前重读一遍计划。

它的价值在两条反直觉纪律。一是 **Read Before Decide**：模型最大的毛病是目标说过就忘，重读计划文件是把目标刷回注意力窗口的土办法，但管用。二是 **Store, Don't Stuff**：大产出写文件、上下文只留路径，直接对治上下文膨胀。反模式表里甚至点名「别拿 TodoWrite 当持久化」——这句话本身就是生态化石，暴露了它的出身年代。

亮点是零依赖零配置，纯 Markdown 工作法，任何 harness 都能跑；上手门槛全场最低。短板：它管的是任务内的连续性，不管跨天跨任务的状态——所以它和 long-running-agent 是互补件不是竞品：一个管注意力，一个管交接班。同一个长任务里俩一起开，效果最好。

```bash
npx skills find planning files
npx skills add <owner/repo>@<skill-name> -g -y
```

## 彩蛋 自产件：skill-sync-github

一件值得单独说的私房菜：把 `~/.claude/skills/` 整个目录同步到私有仓库 allSkills。触发词设计极接地气——「同步skill」「推送skill」「上传skill」「备份skill」都能唤醒；错误处理表连「LF will be replaced by CRLF」这种警告都写了「无害，可忽略」；还附了新电脑一行命令恢复的指南。本期这批 SKILL.md 能在多台机器间保持一致，靠的就是它。社区活跃度给它打了最低的一星——私有件没有社区，但这对它根本不重要，个人自动化件的满分标准是「忘了它的存在，一切照常运转」。

## 本期精读：自动化件怎么给模型踩刹车

把六件的 SKILL.md 放在一起看，「刹车」设计反复出现在四个位置：

- **批准闸门**：gh-fix-ci 的「implement after explicit approval」——计划先过目，批准才动手；
- **权限收窄**：sentry 的只读 scopes 加「Never echo auth tokens」——能看的绝不给能写的；
- **边界声明**：gh-fix-ci 的「Do not attempt Buildkite or other providers」——明确说出「我不管什么」比「我管什么」更防事故；
- **状态防篡改**：long-running-agent 的 JSON 清单加「只许翻 passes 位」——给模型的写权限上了锁。

四根刹车，一根都不能少。回看之前横评里翻车的件，翻车原因几乎都能对号入座：缺哪根，坏哪样。

## 流程图

六件在本机出货流水线上的站位：

```mermaid
flowchart TD
    A["代码改完要出货"] --> B["github-actions-skill"]
    B -->|"问答生成 deploy.yml"| C["Actions 推包上 VPS"]
    C -->|"红灯"| D["gh-fix-ci 拉日志定位"]
    D --> E["出修复补丁"]
    E --> C
    C -->|"绿灯 合入"| F["gh-address-comments 清评审"]
    C -->|"上线之后"| G["sentry 盯线上报错"]
    G -->|"报错聚合成单"| H["值班 Agent 排查"]
    H --> D
```

long-running-agent 的两班交接循环：

```mermaid
flowchart TD
    S1["初始化员 只上首班"] --> S2["写 init.sh"]
    S1 --> S3["立 feature_list.json"]
    S1 --> S4["开进度日志"]
    S1 --> S5["首次提交 git"]
    S5 --> S6["编码员 接班上岗"]
    S6 --> S7["七步开机自检"]
    S7 --> S8["只挑一个 feature"]
    S8 --> S9["端到端实测"]
    S9 -->|"通过"| S10["passes 改 true"]
    S9 -->|"失败"| S11["修复并记进度"]
    S10 --> S12["提交 写台本 收班"]
    S11 --> S12
    S12 --> S6
```

## 推荐排行榜

- **综合第一：gh-fix-ci**。唯一的端到端流程件，脚本兜底、退出码、边界声明三样俱全，生产可直接用。
- **新手友好榜**：github-actions-skill 与 planning-with-files 并列。前者一路问答零决策，后者零依赖纯 Markdown。
- **安全设计榜**：sentry 一骑绝尘。只读 token、PII 脱敏、不回显凭据、禁缓存，四件套齐活。
- **长活搭档榜**：long-running-agent + planning-with-files 组合。一个管交接班，一个管注意力，缺一不可。
- **最冤榜**：gh-address-comments。三步件省 token 又把否决权留给人，可惜失败路径全裸装，配齐刹车能上四分。
- **最被低估**：skill-sync-github。没有社区没有 Star，但整套路由它托底——自动化件的最高荣誉是存在感为零。

## 参考来源

1. 本机装机原文：`~/.claude/skills/` 下 github-actions-skill、gh-fix-ci、gh-address-comments、sentry、long-running-agent、planning-with-files、skill-sync-github 七份 SKILL.md（本文全部引文与功能描述皆出于此）
2. [Sentry Auth Tokens](https://sentry.io/settings/account/api/auth-tokens/) — sentry 件正文中给出的只读 token 创建入口
3. [appleboy/ssh-action](https://github.com/appleboy/ssh-action) — github-actions-skill 生成模板所引用的 SSH Action（pinned @v1.0.3）
4. [skills.sh](https://skills.sh/) — Skills 生态聚合站，`npx skills add` 安装链路的浏览入口
5. [gprshome/allSkills](https://github.com/gprshome/allSkills) — 本机 skills 的同步备份仓库（私有，引自 skill-sync-github 正文）

> [!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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
