二十五個資料夾名稱先被排好了：一份測試 Skill 清單，是一套被命名的流程介面

2026 年 9 月 29 日，掘金作者「狂師」發布了一篇名為「AI 測試 Skill 大全，我日常在用的 25 個」的文章。文章本身是技術分享，列出了作者自建、圍繞軟體測試完整流程的二十五個 Agent Skill，從需求拆解一路排到測試報告。但如果把視線從「這些工具好不好用」移開，先看那張清單的長相，會看到另一件被設計出來的東西：一套用命名與階層排出來的流程介面。

先從最小的細節看起。清單以一棵目錄樹呈現，每個 Skill 是一個資料夾，資料夾名是英文小寫加連字號，後面綴著一行中文註解。例如 req-to-user-story 對上「需求轉用戶故事」，api-failure-diagnoser 對上「測試失敗智慧診斷與自動修復」。英文負責機器可讀，中文負責人可讀，兩欄並排，這是很樸素的雙語排版，卻讓整份清單同時能被工程師當程式碼讀、被管理者當功能表讀。

再看命名裡的動詞結構。這二十五個名字幾乎都遵循「前置詞加動作」的格式：generator-、review-、executor-、diagnoser-、report-、scheduler-。動詞被放在前綴的位置，等於把每個工具「做什麼」提前到視覺的第一拍。跟一般 AI 工具站那種把「語音克隆」「影片生成」平鋪在首頁的排法相比，這裡的分類依據是動作類型，而不是功能賣點。同樣是聚合，一個按行銷語言排，一個按工作動詞排，後者讀起來更像一份工序表。

工序感來自數字的分組。作者把二十五個 Skill 分成三組：需求與用例設計六個、接口自動化十個、UI 自動化九個。三組各自能串成一條流程，鏈上每個環節又可獨立使用。對照 api- 與 ui- 兩組的命名，會發現它們幾乎是鏡像的：兩邊都有 testdata、testscript-generator、test-tagger、test-executor、failure-diagnoser、report-generator、pipeline-scheduler。同一套後綴，換個前綴就搬到另一個測試面上重用。這種對稱不是偶然，它是把「測試的通用工序」抽象成命名模板的結果，看到 ui- 開頭，就知道它能對應到哪個 api- 的位置。

這種命名上的節奏，其實就是一種介面設計。使用者不需要打開任何一個 Skill 的說明文件，光掃過清單就能推渷出每個工具在流程裡的位置，以及它上下遊是誰。名稱本身就是導覽。文章也提到這些 Skill 都對應企業團隊實際在用的環節，「不是收藏夾裡的擺設」，這句話反過來看，是命名與真實工序的貼合度決定了清單的可信度。

放在更大的脈絡裡，這篇文章是 Claude Skills 這類 Agent Skill 概念流行後的一個縮影。當工具的單位從「一套軟體」縮小到「一個資料夾、一段說明」，命名與排序就成了最主要的設計面。工具本身看不見，看得見的只剩名字。這跟我們先前觀察過的把四種生成能力排成一個介面的 AI 工具聚合站是同一個命題：當能力被拆得很碎，版面與名稱就是產品。

當然，這份清單也有它誠實的極限。文章只交代了清單結構與各 Skill 的用途描述，至於每個 Skill 的實際產出品質、在團隊裡的使用頻率，僅有作者單方面的說法，沒有可核實的數據。以設計觀察的角度看，這無妨，因為值得看的從來不是功效，而是這種「用一致的前綴、鏡像的後綴、分組的數字」把一段專業工作排成可閱讀清單的做法本身。

一份好的工具清單，讓人掃一眼就知道工作怎麼拆、環節怎麼接。這二十五個連字號名稱做到了這件事，而它用的手段，只是命名的一致與排列的秩序。