<!-- title: 修错件横评：从CI红灯到APK逆向 -->

# 修错件横评：从CI红灯到APK逆向

## 本期概述

上一篇《官方下场守门：审改简验四件拆解》拆的是「写完代码之后」的把关件：审、简、验、跑。但开发闭环还有后半段没拆——**出错之后的善后**：CI 红了谁去修、Notebook 烂了谁去补、文件乱码谁去查。本期把这一排「修错件」摆上手术台：深拆本机已装的 `gh-fix-ci`、`notebook-fix`、`encoding-check` 三个件（`SKILL.md` 全文实读），外加看一眼本周新星榜上刚冒头的 `apk-reverse`。核心发现：前三个件共享同一套骨架，像同一个工具箱里出来的「件族」；而三件的工程化程度差出两个量级——一个带脚本、防字段漂移、留了自动化退出码，两个是纯提示词、连 markdown 粗体符号都是断的。

## 评测对比表

评分口径：5 星最好；「上手难度」星越多越容易上手。三个本机件本轮实读了 `SKILL.md` 全文、未实跑修复流程，实战分按设计确定性给保守口径；`apk-reverse` 内部未读，仅凭榜单元数据给分，见斜体注。

| Skill | 功能完整度 25% | 设计质量 25% | 实战效果 20% | 上手难度 15% | 社区活跃度 15% | 加权 |
|---|---|---|---|---|---|---|
| gh-fix-ci | ★★★★★ | ★★★★★ | ★★★★ | ★★★ | ★★★ | 4.2 |
| encoding-check | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★ | 4.0 |
| notebook-fix | ★★★★ | ★★★★ | ★★★ | ★★★★★ | ★★★ | 3.8 |
| apk-reverse* | ★★★ | ★★★ | ★★★ | ★★★ | ★★★★ | 3.2 |

## 逐件拆解

### gh-fix-ci：修错件里的工程化天花板

先说一个只有开膛才能发现的细节：这个件的文件夹叫 `gh-fix-ci`，可 `SKILL.md` 的标题写的是 **"Gh Pr Checks Plan Fix"**——定位、取日志、计划、修复，真名把四段工作流全交代了，文件夹名反而是简化版。这种「门牌与正本不一致」在官方件里不会出现，社区件的手工感由此可见。

它的工程化程度，在本期三件里是断档领先的，证据有四处。

**第一，自带脚本，不靠模型徒手干活。** 它捆了一个 `scripts/inspect_pr_checks.py`，Quick start 第一条就是跑它取失败检查。原文还专门交代：`--json` 出机器可读结果，「Exits non-zero when failures remain so it can be used in automation」——还有失败就非零退出，专为挂进自动化钩子设计。同期的两个小件全靠模型现场发挥，这里已经把确定性下沉到了代码层。

**第二，防御性设计做到了「gh 字段会漂移」这个粒度。** 脚本描述里写着它「handles gh field drift and job-log fallbacks」；工作流里的手动降级链也写得极细：`gh pr checks --json` 若有字段被拒，就「rerun with the available fields reported by gh」；再从 `detailsUrl` 里抠出 run id 去 `gh run view --log`；日志还在跑，就绕去 `gh api` 直接拉 job 日志。GitHub CLI 的 JSON 字段随版本变动是真实痛点，把这个坑写进件的，目前少见。

**第三，越界声明一刀切得干脆。** 第 4 步明确：`detailsUrl` 不是 GitHub Actions 的检查，一律标记 external、只留链接，「Do not attempt Buildkite or other providers; keep the workflow lean」。上一篇拆官方 `/simplify` 时总结过「声明你不管什么」的设计律条，这句是同一哲学在社区件里的回声。

**第四，人在环上的审批门。** 全流程是：验认证 → 定位 PR → 取日志 → 摘失败片段 → 拟计划 → **批准后** 才动手 → 改完建议重跑 `gh pr checks` 复查。开头还留了一句软耦合：「If a plan-oriented skill (for example `create-plan`) is available, use it」——有计划件就借用，没有就地内联。对比 `encoding-check` 里硬编码引用另一个件，这是「探测式借用」对「硬链依赖」的进化。

短板也直白：依赖 `gh` 认证（`repo` + `workflow` 两个 scope）、依赖网络、只认 GitHub Actions。CI 跑在别处的，它直接不接。

### encoding-check：把「报告长什么样」写死的模板件

触发方式是斜杠命令加 glob：`/encoding-check **/*.md`。它管五件事：编码类型（UTF-8、GBK、ASCII）、BOM 检测、中文兼容性、emoji 等特殊 Unicode 字符、CRLF 与 LF 换行符。

它最值得抄的设计是**把输出格式逐字写死**。`SKILL.md` 里给了一张完整的 ASCII 表格模板：文件名、编码、BOM、CJK、状态五列，状态只用 ✓、⚠、✗ 三档，表尾强制跟 Summary 汇总（几个 OK、几个待转换、几个需人工），再跟 Recommendations 逐条给建议——「Convert doc2.md from GBK to UTF-8」。模型照着模板填空，输出就不会每次一个花样。这是纯提示词件能拿到的最高确定性手段。

安全姿态也齐：自动转换前先问 y/n，转完留 `.bak` 备份。甚至附了一节 Windows PowerShell 版本命令，还单列「预防建议」教人从源头写对：Python 里 `encoding='utf-8'`、编辑器默认 UTF-8。修错件顺手带教案，这是它比 `notebook-fix` 多出的一层。

最能暴露出身的是「集成工作流」一节：流程图里明确写着第 3 步接 `/pptx-test sample.md` 单页测试、第 4 步才批量处理——它原本是内容生产流水线上的预处理守门员，不是通用开发工具。顺带一提，这份 `SKILL.md` 的列表项粗体符号全是断的（`** 文件编码类型**`，星号和字之间垫了空格），手工写作、渲染前没检查的痕迹，和它的流水线出身互相印证。

### notebook-fix：管着「代码住错房间」这种 notebook 特有病

同一套骨架的第三件：`/notebook-fix **/*.ipynb`，五类病 ——— `malformed_imports`（导入语句语法错）、`code_in_markdown`（代码住进了 markdown 单元格）、`json_encoding`、`syntax_errors`、`cell_formatting`。其中 `code_in_markdown` 是 notebook 特有的病：代码贴进错了类型的单元格里，肉眼难察、一跑就废，把它单列成检查项说明作者真踩过坑。示例报告里的病句也造得逼真：`` `from langchain impor xxx` ``——少一个字母 t 的真实世界 imports。

执行流程六步：扫描、逐文件体检（JSON 有效性、导入、单元格类型、Python 语法）、报告、问 y/n、**备份后修复、复验文件可正常加载**。最后一步「验证修复后可加载」是个容易被忽略的好设计——修完不等于修对，加载得动才算数。边界也交代了：「严重损坏的文件需要手动处理」「建议先在副本上测试」。短板在纯提示词：改写代码的活，模型发挥空间大、稳定性就打折，这也是它实战分低于 `encoding-check` 的原因——查编码是机械活，改代码是手艺活。

### apk-reverse：榜单新星，内部待验

## 修错件的公共骨架

三个深拆件去掉领域差异，剩同一副骨头：

```mermaid
flowchart TD
    A["斜杠命令触发"] --> B["glob 扫描目标"]
    B --> C["逐文件体检"]
    C --> D["汇总问题清单"]
    D --> E["y/n 确认门"]
    E -->|"同意"| F["备份原文件"]
    F --> G["执行修复"]
    G --> H["复验可加载"]
    E -->|"拒绝"| I["只留报告不动手"]
```

三件共享同一套触发语法、同一种 ✓⚠✗ 视觉语言、同一个 y/n 门、同一种 `.bak` 备份习惯——几乎可以断定出自同一个工具箱；是否同一作者，本机元数据未见署名，不作断言。这副骨架的设计哲学只有一句话：**修错件的第一美德是不信任自己的修复**。所以报告先行、动手要批、改前备份、改后复验，四道门一道不少。代价是交互式的 y/n 门在无人值守场景会卡住——`gh-fix-ci` 用「退出码非零」绕开了这个死结，同一族里两代设计的分野就在这一处。

`gh-fix-ci` 的完整工作流则是另一张图：

```mermaid
flowchart TD
    A["gh auth status 验身份"] --> B["定位当前分支 PR"]
    B --> C{"失败检查是否 Actions"}
    C -->|"是"| D["跑自带脚本取日志"]
    C -->|"否"| E["标记外部 只留链接"]
    D --> F["摘出失败片段"]
    F --> G["拟修复计划"]
    G --> H{"用户批准"}
    H -->|"是"| I["动手改并跑测试"]
    H -->|"否"| J["停在计划"]
    I --> K["gh pr checks 复查"]
```

## 与官方件的分工，一句话带过

上一篇拆过的官方 `/verify` 管「跑起来证明改动是对的」，本期的三件管「已经坏掉的东西怎么救回来」：一个面向未然的验证，三个面向已然的修复，同一条开发闭环的两半。加上此前拆过的抓包三件套（网络取证向），「出错善后」这条货架目前已有协议分析、CI 修复、文件修复、编码检查四个格子，移动端逆向这个格子刚被 `apk-reverse` 占上。

## 安装与使用命令

三个本机件的通用装法是把含 `SKILL.md` 的文件夹放进 `~/.claude/skills/`，或经 `/plugin` 走插件市场。触发与脚本用法均出自各件原文：

```bash
# encoding-check / notebook-fix：斜杠命令 + glob，即装即用
/encoding-check **/*.md
/encoding-check ./documents/*.txt
/notebook-fix **/*.ipynb
/notebook-fix single-notebook.ipynb

# gh-fix-ci：前置一步 gh 认证（需 repo + workflow scope）
gh auth login
gh auth status

# 然后可走对话式流程，或直接用自带脚本
python ~/.claude/skills/gh-fix-ci/scripts/inspect_pr_checks.py --repo "." --pr "123"
python ~/.claude/skills/gh-fix-ci/scripts/inspect_pr_checks.py --repo "." --pr "123" --json
python ~/.claude/skills/gh-fix-ci/scripts/inspect_pr_checks.py --repo "." --max-lines 200 --context 40

# apk-reverse：本周新星，装法以其仓库说明为准（本轮未抓取到说明文件）
git clone https://github.com/newliver666/apk-reverse
```

## 推荐排行榜

- **工程化程度第一**：`gh-fix-ci`——自带脚本、防字段漂移、非零退出码，三件里唯一能挂进无人值守流水线的。
- **新手即用第一**：`encoding-check`——零前置、零依赖，报告模板照着读就会，还附预防教案。
- **最谨慎奖**：`notebook-fix`——六步流程里「复验可正常加载」一步，是修错件该有的收尾姿势。
- **设计最值得抄**：`encoding-check` 的写死输出模板——纯提示词件拿到确定性的最便宜手段。
- **榜单观察席**：`apk-reverse`——修错赛道向逆向延伸的信号，待下一轮开膛验证。
- **明确不推荐**：CI 不在 GitHub Actions 的团队硬上 `gh-fix-ci`；严重损坏的 `.ipynb` 指望 `notebook-fix` 起死回生——两件都自己声明了不接。

## 写给 Skill 作者：这一族给出的三条律条

第一，**修错件必须四道门**：报告、确认、备份、复验。少任何一道，都是在用未经信任的输出覆盖用户仅存的原件。第二，**机械的检查下沉为脚本，手艺的判断留在提示词**——同族两个纯提示词件和一个带脚本件放在一排，高下立判；非零退出码这种「为自动化留钩子」的细节，是提示词永远给不了的。第三，**边界声明已成生态共识**：从官方 `/simplify` 的「不抓虫」到 `gh-fix-ci` 的「不碰 Buildkite」，上架越晚的件越会把「我不管什么」写在脸上——你的新件若还没写这句，等于把误触发的大门敞着。

## 参考来源

> [!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)
