上一篇《官方下场守门：审改简验四件拆解》拆的是「写完代码之后」的把关件：审、简、验、跑。但开发闭环还有后半段没拆——出错之后的善后：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，可 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 跑在别处的，它直接不接。
触发方式是斜杠命令加 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 **/*.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 的原因——查编码是机械活，改代码是手艺活。
三个深拆件去掉领域差异，剩同一副骨头：
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 的完整工作流则是另一张图：
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 走插件市场。触发与脚本用法均出自各件原文：
# 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——修错赛道向逆向延伸的信号，待下一轮开膛验证。gh-fix-ci；严重损坏的 .ipynb 指望 notebook-fix 起死回生——两件都自己声明了不接。第一，修错件必须四道门：报告、确认、备份、复验。少任何一道，都是在用未经信任的输出覆盖用户仅存的原件。第二，机械的检查下沉为脚本，手艺的判断留在提示词——同族两个纯提示词件和一个带脚本件放在一排，高下立判；非零退出码这种「为自动化留钩子」的细节，是提示词永远给不了的。第三，边界声明已成生态共识：从官方 /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 等场景全覆盖。