文章庫

不是裝上就行，是裝上以後 AI 每次都能穩定幹活 🔥— — —😩 先說一個真實的困境你是不是也遇到過這種情況——跟 AI 說「幫我寫接口用例」，它生成的字段是編出來的換個會話重新說一遍，輸出風格又變了一套PR 裏的測試代碼，看起來像來自兩家公司寫的問題不在模型，在於你沒有把「什麼叫過關」寫成 AI 能穩定執行的 Skill 📦— — —🤔 Skill 到底是什麼？簡單理解：Skill 是一個文件夾型能力包裏面至少有一份 SKILL.md，分兩段：上半段：元數據（name、description）下半段：操作指令（怎麼幹活）還可以掛 scripts/、references/、assets/ 等配套資源相當於給 AI 一本可以版本化、可以 Code Review 的「專項員工手冊」— — —📌 測試流程裏，哪些事最該寫成 Skill？三類最值得沉澱 👇重複且怕跑偏：用例格式、缺陷字段、斷言層級、P0 迴歸清單脆弱、錯一點就全錯：OpenAPI 轉 pytest 時的導入路徑、禁止臆造字段團隊共識：什麼叫「可測需求」、嚴重級別怎麼定、上線前要看到什麼命令輸出不寫 Skill 的代價是什麼？對話裏口頭講一遍，換人、換會話，模型又回到「全網平均水平」— — —🧠 原理層：你是在給 AI 寫指令，不是寫宣傳稿💡 原則一：上下文是公共資源，必須簡潔系統提示、歷史對話、已安裝的所有 Skill 簡介都在搶同一塊上下文窗口Skill 寫得又長又空 → 真正有用的斷言規範反而擠不進來只寫模型不知道的東西，能用 10 行示例說清的，別用 3 頁背景故事— — —💡 原則二：信息要放對層級（三級加載）textL1 元數據 → name + description，始終在上下文，是「觸發開關」L2 正文 → 觸發後才加載，只放步驟和檢查清單L3 資源 → references/、scripts/，按需讀取執行最常見的翻車 ⚠️把「什麼時候用我」寫在正文裏——正文是觸發後才讀的，那時模型已經決定用不用你了，晚了— — —💡 原則三：脆弱操作要「鎖死」，別靠口頭約束高自由度：幫你拆需求、腦暴場景 → 給方向即可低自由度：報告模板字段、CI 命令、斷言必須是固定形態 → 優先用腳本或模板，而不是「請儘量遵守」測開場景裏低自由度特別多，能腳本化就別全靠「請生成」— — —💡 原則四：「不做什麼」往往比「做什麼」更管用與其寫「請專業全面」，不如列反模式清單：❌ 不要臆造 userId❌ 不要用 sleep 代替穩定等待❌ 不要只斷言 HTTP 200AI 在有邊界的可行域裏遊走，輸出會穩很多— — —🏗️ 結構：Skill 的推薦目錄最小可用形態：textmy-qa-skill/└── SKILL.md變複雜以後：textmy-qa-skill/├── SKILL.md ← 元數據 + 操作指令├── scripts/ ← 執行腳本，不用整文件讀進上下文├── references/ ← 給 AI 讀的細則（錯誤碼、表結構）└── assets/ ← 直接拷貝進產出的模板文件⚠️ 不要在 Skill 裏塞給人看的 README、CHANGELOG——那是人類文檔噪音，還容易和 SKILL.md 不一致— — —🎯 description 怎麼寫才像「開關」？差的寫法（容易永遠不觸發）：textdescription: 測試技能description: 幫助測試太泛，模型不知道用戶哪句話該開你好的寫法：能力 + 典型用戶原話 + 邊界yaml---name: api-regression-hintsdescription: >- 為本倉庫編寫或審查 HTTP/API 自動化用例（pytest + httpx）時使用。當用戶提到接口迴歸、OpenAPI 轉用例、斷言業務錯誤碼、禁止臆造字段、或要求對齊 tests/api 目錄風格時激活。不用於純 UI 選擇器或性能壓測腳本。---核心記住一句話：「何時用」全堆在 description，正文裏別再重複寫一遍— — —🔬 五個最值得單獨做 Skill 的測試場景— — —場景一：需求可測性痛點：PRD 全是形容詞，AI 生成的用例「好看但不可執行」Skill 正文要寫：text## 需求可測化1. 逐條拆出功能點，每條給出可判定真假的預期結果2. 對範圍類需求補充邊界值與非法輸入3. 出現模糊形容詞，改為可量化條件，否則標記「待產品確認」反模式：不接受「體驗流暢」類無法驗證的預期— — —場景二：用例設計痛點：等價類、邊界、狀態遷移每次 AI 自由發揮，深度不一致Skill 要寫：固定 P0/P1 定義（P0 = 主路徑 + 資金相關 + 鑑權）輸出格式固定（列名固定的 Markdown 列表）大段測試方法理論 → 放 references/testing-methods.md，正文只留調用指引— — —場景三：接口自動化（最容易「紙面綠、真跑掛」）痛點：字段胡編、fixture 對不上、只斷言 200Skill 要寫：text禁止：未在 OpenAPI 中出現的字段名斷言順序：HTTP 狀態 → 業務 code → 關鍵字段錯誤用例必須明確期望的錯誤碼，不允許只斷言非 200環境變量從 .env.example 讀取，禁止硬編碼低自由度部分 → scripts/lint_api_test.py 掃「禁止 sleep」「必須有 teardown」— — —場景四：缺陷報告痛點：開發追問「你怎麼復現的」；信息每次不一樣Skill 要寫缺陷模板字段（必填）：text環境 / 版本 / 賬號角色 / 復現步驟 /實際結果 / 預期結果 / 日誌片段 / 是否必現— — —場景五：質量門禁痛點：合碼前沒人跑命令，靠口頭確認Skill 要寫：text收尾前必須執行：pytest tests/ -v --tb=short貼出終端摘要截圖，包含通過數 / 失敗數 / 耗時— — —🚀 落地六步（壓縮版）text1. 收集 3～5 個真實觸發句（同事會怎麼跟 AI 說）2. 規劃哪些進 references、哪些必須腳本、哪些只在正文用清單3. 先把 description 寫準，再建目錄和佔位文件4. 先落 references/ 裏的規則文檔，再寫正文步驟5. 自己用原話測觸發率，驗證開關是否準確6. 跑一週真實任務，把「AI 仍常錯的點」改成反模式，而不是再加千字背景— — —✅ 5 條落地原則，收藏備用🎯 先解決觸發準確率：description 裏寫具體關鍵詞和邊界📂 先做信息分層：大段規範進 references/，正文只保留步驟🔒 先鎖脆弱動作：格式/命名/校驗優先腳本化✂️ 先按流程拆小 Skill：需求→用例→自動化→缺陷→發佈，拆開不要萬能大包🛠️ 先納入工程治理：Skill 跟倉庫走，評審、版本和代碼同標準— — —把 description 當開關、正文當操作手冊、腳本當質檢員測試工程師寫的 Skill，才會從「看着專業」變成「真的省 Review、少返工」💪— — —💬 你們團隊現在 AI 測試卡在哪個環節？評論聊聊 👇 點贊收藏，下期講怎麼把現有測試規範拆成多個小 Skill 🌟

完成