測試工程師怎麼寫出「真能用的」AI Skill？
整理版優先睇
不是裝上就行，是裝上以後 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 🌟
不是裝上就行，是裝上以後 AI 每次都能穩定幹活 🔥— — —😩 先說一個真實的困境你是不是也遇到過這種情況——跟 AI 說「幫我寫接口用例」，它生成的字段是編出來的換個會話重新說一遍，輸出風格又變了一套PR 裏的測試代碼，看起來像來自兩家公司寫的 問題不在模型，在於你沒有把「什麼叫過關」寫成 AI 能穩定執行的 Skill 📦— — —🤔 Skill 到底是什麼？
簡單理解：Skill 是一個文件夾型能力包裏面至少有一份 SKILL.md，分兩段：上半段：元數據（name、description）下半段：操作指令（怎麼幹活）還可以掛 scripts/、references/、assets/ 等配套資源相當於給 AI 一本可以版本化、可以 Code Review 的「專項員工手冊」— — —📌 測試流程裏，哪些事最該寫成 Skill？
三類最值得沉澱 👇重複且怕跑偏：用例格式、缺陷字段、斷言層級、P0 迴歸清單脆弱、錯一點就全錯：OpenAPI 轉 pytest 時的導入路徑、禁止臆造字段團隊共識：什麼叫「可測需求」、嚴重級別怎麼定、上線前要看到什麼命令輸出不寫 Skill 的代價是什麼？對話裏口頭講一遍，換人、換會話，模型又回到「全網平均水平」— — —🧠 原理層：你是在給 AI 寫指令，不是寫宣傳稿💡 原則一：上下文是公共資源，必須簡潔系統提示、歷史對話、已安裝的所有 Skill 簡介都在搶同一塊…
- 測試工程師怎麼寫出「真能用的」AI Skill？
- 測試工程師怎麼寫出「真能用的」AI Skill？｜重點 2
- 測試工程師怎麼寫出「真能用的」AI Skill？｜重點 3
- 測試工程師怎麼寫出「真能用的」AI Skill？｜重點 4
- 測試工程師怎麼寫出「真能用的」AI Skill？｜重點 5
可記低 Skill
不是裝上就行，是裝上以後 AI 每次都能穩定幹活 🔥— — —😩 先說一個真實的困境你是不是也遇到過這種情況——跟 AI 說「幫我寫接口用例」，它生成的字段是編出來的換個會話重新說一遍，輸出風格又變了一套PR 裏的測試代碼，看起來像來自…
內容結構
textmy-qa-skill/├──
SKILL.md ← 元數據 + 操作指令├── scripts/ ← 執行腳本，不用整文件讀進上下文├── references/ ← 給 AI 讀的細則（錯誤碼、表結構）└── assets/ ← 直接拷貝進產出的模板文件整理版
不是裝上就行，是裝上以後 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 🌟
😩 先講一個真實嘅困境
你係咪都遇過呢種情況——
同 AI 講「幫我寫接口用例」，佢生成嘅字段係作出來嘅
轉個對話重新講一次，輸出風格又變咗另一套
PR 入面嘅測試代碼，睇起嚟似係兩間公司寫嘅
問題唔喺模型，係在於你冇將「咩叫過關」寫成 AI 可以穩定執行嘅 Skill 📦
🤔 Skill 究竟係咩？
簡單理解：Skill 係一個文件夾型能力包
裏面至少有一份 SKILL.md，分兩段：
- 上半段：元數據（name、description）
- 下半段：操作指令（點樣做嘢）
仲可以掛 scripts/、references/、assets/ 等配套資源
📌 測試流程裏面，邊啲嘢最應該寫成 Skill？
三類最值得沉澱 👇
- 重複同埋怕走樣：用例格式、缺陷字段、斷言層級、P0 迴歸清單
- 脆弱、錯少少就全錯：OpenAPI 轉 pytest 時嘅導入路徑、禁止亂作字段
- 團隊共識：咩叫「可測需求」、嚴重級別點樣定、上線前要見到咩命令輸出
唔寫 Skill 嘅代價係咩？
🧠 原理層：你係喺度俾 AI 寫指令，唔係寫宣傳稿
💡 原則一：上下文係公共資源，一定要簡潔
系統提示、歷史對話、已安裝嘅所有 Skill 簡介都喺度爭同一塊上下文窗口
Skill 寫得又長又空 → 真正有用嘅斷言規範反而逼唔到入去
淨係寫模型唔知嘅嘢，用得着 10 行示例講清楚嘅，就唔好用 3 頁背景故事
💡 原則二：資訊要放啱層級（三級加載）
textL1 元數據 → name + description，始終在上下文，是「觸發開關」L2 正文 → 觸發後才加載，只放步驟和檢查清單L3 資源 → references/、scripts/，按需讀取執行最常見嘅出事 ⚠️
將「幾時用我」寫喺正文裏面——正文係觸發之後先讀嘅，嗰時模型已經決定用唔用你，晚了
💡 原則三：脆弱操作要「鎖死」，唔好靠口頭約束
- 高自由度：幫你拆需求、腦暴場景 → 俾方向就得
- 低自由度：報告模板字段、CI 命令、斷言一定要固定形態 → 優先使用腳本或者模板，唔好靠「請儘量遵守」
測開場景入面低自由度特別多，可以腳本化就唔好全靠「請生成」
💡 原則四：「唔做啲咩」好多時比「做啲咩」更有效
與其寫「請專業全面」，不如列反模式清單：
- ❌ 唔好亂作
userId - ❌ 唔好用
sleep代替穩定等待 - ❌ 唔好剩係斷言 HTTP 200
AI 喺有邊界嘅可行域入面行，輸出會穩定好多
🏗️ 結構：Skill 嘅推薦目錄
最細可用形態：
textmy-qa-skill/└── SKILL.md變複雜之後：
textmy-qa-skill/├── SKILL.md ← 元數據 + 操作指令├── scripts/ ← 執行腳本，不用整文件讀進上下文├── references/ ← 給 AI 讀的細則（錯誤碼、表結構）└── assets/ ← 直接拷貝進產出的模板文件🎯 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 對唔上、淨係斷言 200
Skill 要寫：
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 同倉庫一齊走，評審、版本同代碼同一標準
😩 先說一個真實的困境
你是不是也遇到過這種情況——
跟 AI 說「幫我寫接口用例」，它生成的字段是編出來的
換個會話重新說一遍，輸出風格又變了一套
PR 裏的測試代碼，看起來像來自兩家公司寫的
問題不在模型，在於你沒有把「什麼叫過關」寫成 AI 能穩定執行的 Skill 📦
🤔 Skill 到底是什麼？
簡單理解：Skill 是一個文件夾型能力包
裏面至少有一份 SKILL.md，分兩段：
- 上半段：元數據（name、description）
- 下半段：操作指令（怎麼幹活）
還可以掛 scripts/、references/、assets/ 等配套資源
📌 測試流程裏，哪些事最該寫成 Skill？
三類最值得沉澱 👇
- 重複且怕跑偏：用例格式、缺陷字段、斷言層級、P0 迴歸清單
- 脆弱、錯一點就全錯：OpenAPI 轉 pytest 時的導入路徑、禁止臆造字段
- 團隊共識：什麼叫「可測需求」、嚴重級別怎麼定、上線前要看到什麼命令輸出
不寫 Skill 的代價是什麼？
🧠 原理層：你是在給 AI 寫指令，不是寫宣傳稿
💡 原則一：上下文是公共資源，必須簡潔
系統提示、歷史對話、已安裝的所有 Skill 簡介都在搶同一塊上下文窗口
Skill 寫得又長又空 → 真正有用的斷言規範反而擠不進來
只寫模型不知道的東西，能用 10 行示例說清的，別用 3 頁背景故事
💡 原則二：信息要放對層級（三級加載）
textL1 元數據 → name + description，始終在上下文，是「觸發開關」L2 正文 → 觸發後才加載，只放步驟和檢查清單L3 資源 → references/、scripts/，按需讀取執行最常見的翻車 ⚠️
把「什麼時候用我」寫在正文裏——正文是觸發後才讀的，那時模型已經決定用不用你了，晚了
💡 原則三：脆弱操作要「鎖死」，別靠口頭約束
- 高自由度：幫你拆需求、腦暴場景 → 給方向即可
- 低自由度：報告模板字段、CI 命令、斷言必須是固定形態 → 優先用腳本或模板，而不是「請儘量遵守」
測開場景裏低自由度特別多，能腳本化就別全靠「請生成」
💡 原則四：「不做什麼」往往比「做什麼」更管用
與其寫「請專業全面」，不如列反模式清單：
- ❌ 不要臆造
userId - ❌ 不要用
sleep代替穩定等待 - ❌ 不要只斷言 HTTP 200
AI 在有邊界的可行域裏遊走，輸出會穩很多
🏗️ 結構：Skill 的推薦目錄
最小可用形態：
textmy-qa-skill/└── SKILL.md變複雜以後：
textmy-qa-skill/├── SKILL.md ← 元數據 + 操作指令├── scripts/ ← 執行腳本，不用整文件讀進上下文├── references/ ← 給 AI 讀的細則（錯誤碼、表結構）└── assets/ ← 直接拷貝進產出的模板文件🎯 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 對不上、只斷言 200
Skill 要寫：
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 跟倉庫走，評審、版本和代碼同標準