本栏第 4 轮，按轮次方向做内容创作与办公类横评。盘点装机目录时发现：写作线、转化线、PPT 线、办公数据线的生产件已被前几轮拆了个遍，但有一类件始终没被拉通看过——专挑毛病的件。09-12 的课程线横评里有一句被埋没的观察：「把验收做成独立编制的件，内容类赛道里教育线是先行者，本机注册表里能与之类比的同位件，只有开发域的 code-review、verify、pptx-test 寥寥数件」，并留下一个悬而未解的判断——「质检位自己没人质检，这是全生态验收件的共性盲区」。本文接住这个线头，把散落在本栏四个不同档案里的验收件第一次拉通，提出「质检四型」框架，并回答一个此前无人回答的问题：质检件的 SKILL.md，和生产件的写法有什么本质不同。
口径说明：本轮网络素材通道受限，本文事实与星数全部取自本栏 09-10 至 09-14 的既往拆解档案，均为各档案当日快照数据，非 09-15 更新值；凡档案未记载的细节，本文标注「未核验」而非推测。
先把生态结构摆出来。本栏过去一个月拆过的内容与办公件，按流水线位置分：上游有 content-strategy、content-research-writer、marketing-psychology（09-14「动笔之前」档案）；中游有写作五件、转化四件、代笔四件、去AI味三件；下游有 PPT 六件、办公数据六件、图卡四件、导出件。每一个生产环节都有横评，唯独「成品出来之后、交付出去之前」这一段，验收件散落各档，从未同框。
这不是小事。生产件的横评反复证明了一件事：生成件的出活质量不稳定——PPT 排版溢出、公式算错、稿子带AI腔、CSV 打开是乱码，全是本栏档案里出现过的真实事故描述。生产端越拥挤，验收端的稀缺就越刺眼。09-13 的 PPT 赛道横评给过一句判断：「生成件满地都是，验生成的件这是装机里唯一一个。造与验分离，这是所有成熟工程流水的标志，PPT 赛道也凑齐了」——PPT 赛道凑齐了，那其他赛道呢？
把装机目录翻到底，内容与办公域的验收编制一共点名四件：pptx-test（PPT 交付前质检）、ai-course-development-expert（课程六维评估）、encoding-check（文本编码防御）、notebook-fix（ipynb 修复兜底）。数量少得可怜，但四个件恰好代表了四种不同的质检形态。先上框架图。
flowchart TD
A["生产件产出成品"] --> B{"哪一道质检?"}
B -->|"生成前立规矩"| C["预防型"]
B -->|"交付前挑毛病"| D["检测型"]
B -->|"检出后做兜底"| E["修复型"]
C --> F["sepia: 生成端纪律"]
D --> G["pptx-test 排版验收"]
D --> H["课程件六维评估"]
D --> I["encoding-check 编码防御"]
E --> J["notebook-fix 五类病修复"]
G --> K["可交付成品"]
H --> K
I --> K
J --> K
预防型在生成端拦截（毛病别犯出来），检测型在交付端验收（犯出来的挑出来），修复型在检出后兜底（挑出来的修回去）。开发域还有第四型——复核型（内置的 code-review、verify，09-15「接缝层」档案已拆），本文以内容与办公域为主，复核型作对照位。
沿用本栏五维口径（功能完整度 25%、设计质量 25%、实战效果 20%、上手难度 15%、社区活跃度 15%）。各件星数沿用其档案当日快照：pptx-test 取 09-13、课程质检件取 09-12、encoding-check 取 09-10、notebook-fix 取 09-14，快照日期不同，横向比星数时注意这一点。
| 件 | 型 | 快照 | 功能 | 设计 | 实战 | 上手 | 活跃 | 加权 |
|---|---|---|---|---|---|---|---|---|
| ai-course-development-expert | 检测 | 09-12 | ★★★★★ | ★★★★ | ★★★★ | ★★★ | ★★★ | 4.0 |
| encoding-check | 检测 | 09-10 | ★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★ | 3.6 |
| pptx-test | 检测 | 09-13 | ★★★ | ★★★★ | ★★★ | ★★★★★ | ★★ | 3.4 |
| notebook-fix | 修复 | 09-14 | ★★★ | ★★★ | ★★★ | ★★★★ | ★★ | 3.2 |
| 对照：sepia | 预防 | 09-13 | ★★★★★ | ★★★★★ | ★★★★ | ★★★★ | ★★★★★ | 4.6 |
| 对照：verify（内置） | 复核 | 09-15 | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | 常驻 | 4.0 |
加权分按本栏惯例由门牌承诺与档案实测综合计得。先说结论：质检件的社区活跃度全员低位——没有一个验收件进过任何新星榜，与生产件动辄千星的涨幅形成刺眼对照。用户给「帮我产出」投票的热情，远高于给「帮我挑错」投票。这是生态的钱荒，也是生态的机会。
本栏 09-13 档案给它留过一个独立小节，标题就叫「质检位独立成件，这个信号比这件本身大」。定位：检查生成的 pptx 有没有交付前事故——排版溢出、字体缺失、页序错乱。单文件实现，功能上毫不惊艳，但它占的是一个此前完全空着的工位：PPT 赛道当时已有官方 pptx、pptx-official、pptx-generator、pptx-manipulation 四个生产件同场，验收位只有它一个。
亮点在「造与验分离」的示范意义。09-12 的装机重影审计数过，pptx 工位一度同时坐着六份件，生产端过饱和；pptx-test 的存在等于承认了一件事——代码造件的出活质量不稳定，需要一道独立工序兜底。短板也直白：单文件意味着检查项有限，字体嵌入、动效兼容这类深水区问题未核验其覆盖能力；且它是全场最孤独的件——PPT 交付前查得出毛病，查出的毛病还得你自己回 pptx-manipulation 手工改，检测与修复之间没有联动。
npx skills find pptx-test
npx skills add pptx-test
09-10「办公数据层横评」档案的加权并列第一，评语只有一句：「中文用户装机建议：必装」。定位：检查并修复文本编码问题，典型场景是 GBK 与 UTF-8 互转失败产生的乱码——CSV 打开是乱码、脚本输出变问号、Windows 与 macOS 之间传文件的编码漂移，中文办公环境里发生频率最高的故障没有之一。
它的设计价值在「防御性」三个字：大多数办公件解决「怎么产出」，它解决「产出之前先别烂在手里」。把它做成独立小件而不是塞进表格件里，是对的——编码检查需要在读取任意文件的时机触发，而不只是处理表格时。在装配线上的位置是全链最上游：编码干净，下游 spreadsheet、md2pdf 的活才有意义。短板有二：功能面天然小，装机活跃度信号弱；且「check」是动词式命名，触发完全依赖用户提到乱码、编码、GBK 这类关键词——description 写得不够宽，它会在该出场时沉默。09-07 档案曾以它为样板给出过本机自建骨架（~/.claude/skills/encoding-check/SKILL.md），属本地自建件，市场安装命令未核验，自建路径照抄即可。
四件里加权最高，也是全生态把「验收」做成独立编制的第一件。定位是元教育件——不直接服务学员，而是评估和优化其他教育产品的质量。09-12 档案记载它以六维框架运作：课程定位、内容完整性、结构逻辑性、实践性、评估有效性等，产出评估报告加改进建议。对教育机构用户，它就是课程上线前的质检站。
亮点是稀缺性带来的生态位：图表引擎横评七件、框图引擎六强，上榜件清一色是生成位，验收位只有它。短板则暴露了整个质检赛道的共性困境——第一，需要用户懂教育评估术语，上手三星；第二，验收权威来自框架本身而非外部基准，它说一门课「实践性不足」，你并没有第二个独立验收位可交叉复核。质检位自己没人质检——这句 09-12 档案的判词，至今没有第二件出来打破。
npx skills add ai-course-development-expert
前三件都只管「挑」，这一件管「修」。09-14「新星说明书」档案的记载最细：中文写成，修 ipynb 五类常见病——坏 import、代码误进 markdown 格、JSON 编码、语法错、格式问题。流程里有两个防翻车阀门：修复前自动备份 .bak，修复前先问一句 y/n。它的输出样例直接把终端长相画在说明书里，档案评价为「把汇报格式当规格写，这是家用件里少见的自觉」。
亮点是触发即用的零门槛（/notebook-fix **/*.ipynb）和修复前的双保险设计——先备份、再确认，把「质检员动手修」这件事的风险兜住了。短板：它是私货件（装机目录本地件），不在公开市场，别人装不了，参考价值在写法不在装机；修复范围限 ipynb 五类病，出了清单就无能为力。它和检测型件的正确关系是上下游：pptx-test 查出页序错乱后没人兜底，而 notebook-fix 这类修复件的存在证明「检出之后有得修」是可以在设计里闭环的——只是目前没有一件把检测和修复写进同一个 SKILL.md。
sepia（预防型对照，4.6）：09-13 去AI味档案的在位者，卡在生成端——不挑成品，而是在写作开始前立纪律，让AI腔根本写不出来。10 天星数翻倍、敢写「77+ 宿主」兼容声明，是全表唯一有爆发曲线的件。它证明了预防型比检测型更受市场青睐：用户愿意为「不出问题」付费，胜过为「找出问题」付费。
verify（复核型对照，4.0）：内置件，09-15 接缝层档案已拆。跑起来看结果，用实际运行代替静态检查——开发域的验收思路比内容域领先一个身位：它有「运行」这个客观基准，而内容域的验收只能对照清单和框架。这个差距是内容质检件的下一代机会：给 pptx-test 加一页真实渲染对比，给课程件加一组学员视角试跑。
把四件的档案细节并排放，能提炼出一组与生产件完全相反的写法纪律。生产件教模型「怎么做好」，质检件教模型「怎么判坏」——方向相反，写法也相反：
| 写法维度 | 生产件惯例 | 质检件惯例 |
|---|---|---|
| 正文主体 | 工作流指令、提示词工程 | 检查清单、病灶目录 |
| 「好」的定义 | 形容词（专业、美观、自然） | 可数项（溢出、缺失、错乱） |
| 输出格式 | 交付物本身 | 固定样式的报告 |
| 风险控制 | 无（产坏了重跑） | 阀门（备份、y/n 确认） |
| 失败分支 | 很少写 | 必写（查不出≠没有） |
四条可直接照抄的经验：第一，病灶写成清单。notebook-fix 的五类病、pptx-test 的三类事故，都是有限可数的条目——模型对清单的执行远比对形容词可靠，这与本栏 09-15「语料当引擎」档案的结论（可验收压倒凭感觉）完全同源。第二，动手前装阀门。notebook-fix 的 .bak 备份加 y/n 确认，是四件里唯一把「质检员自己出错」写进流程的设计——质检件改的是别人的成品，破坏力比生产件大，阀门是刚需而不是可选。第三，报告格式当规格写。生产件可以自由发挥交付样式，质检件的产出就是报告本身，报告格式不固定，跨会话、跨机器的验收结果就没法对账。第四，写清「查不出」的边界。encoding-check 的档案短板（触发依赖关键词）反过来说明：质检件必须在正文里写明哪些病不在清单上，否则「没查出来」会被用户误读成「没有病」。
按场景装机：中文办公环境 → encoding-check 必装（09-10 档案原话）；重度 PPT 交付 → pptx-test；课程/教学内容团队 → ai-course-development-expert；常碰 ipynb → notebook-fix 写法自建。
按设计范本：学防翻车 → notebook-fix；学触发词 → encoding-check；学验收框架 → ai-course-development-expert；学工位卡位 → pptx-test。
三条待填的空位，留给想入场的作者：其一，写作线没有检测型件——text-humanizer 是改写不是验收，成稿质检位仍空着；其二，「检测+修复」没人合体——查出一堆毛病再让用户手工返工，是 pptx-test 最大的体验断点；其三，「质检位自己没人质检」至今无解——谁先做出交叉验收的双件结构，谁就补上全生态最大的盲区。
[!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 等场景全覆盖。