做前端的時(shí)間一長你會(huì)發(fā)現(xiàn)最煩人的往往不是寫業(yè)務(wù)代碼而是反復(fù)去“點(diǎn)”同一個(gè)后臺(tái)頁面。尤其是控制臺(tái)類的管理系統(tǒng)菜單嵌套、權(quán)限點(diǎn)多、表單校驗(yàn)奇奇怪怪每次發(fā)版前我都要手動(dòng)把核心流程點(diǎn)一遍點(diǎn)得人只想寫個(gè)機(jī)器人替我上班。后來我把這套前端測試直接寫成了一個(gè) Skill在 AI 編程助手里掛一個(gè)自定義技能包然后我只需要輸入一句話比如“從登錄開始把所有用戶管理的增刪改查流程全部走一遍”AI 就會(huì)自己打開控制臺(tái)順著操作路徑點(diǎn)擊、輸入、校驗(yàn)、截圖把整個(gè)控制臺(tái)點(diǎn)完最后給我一份帶證據(jù)鏈的測試報(bào)告。這篇就聊聊我是怎么把這個(gè) Skill 做出來的包括 Skill 和普通 Prompt 的區(qū)別、控制臺(tái)測試的核心建模思路、落地步驟以及我實(shí)測中踩過的幾個(gè)坑。1. 控制臺(tái)這類頁面的測試為什么這么折磨人1.1 控制臺(tái)頁面的特性狀態(tài)多、鏈路長、權(quán)限雜控制臺(tái)和普通官網(wǎng)頁面完全是兩種生物。官網(wǎng)頁面基本是“展示型”打開就能看交互最多到表單提交?？刂婆_(tái)則是“操作型”每個(gè)頁面背后都是一串狀態(tài)列表篩選、彈窗新建、編輯保存、批量刪除、權(quán)限校驗(yàn)、操作日志每一步都依賴前一步的結(jié)果。最典型的就是用戶管理你要測“新建用戶”就得先準(zhǔn)備角色、分配權(quán)限、再填賬號信息測“編輯用戶”又得先有一條已存在的用戶數(shù)據(jù)測“刪除用戶”還要考慮當(dāng)前用戶是不是管理員、被刪用戶是否被其他業(yè)務(wù)引用。這些操作串起來是一條很長的鏈路任何一個(gè)環(huán)節(jié)的數(shù)據(jù)缺失、權(quán)限不足、接口異常都會(huì)導(dǎo)致后面全部跑不動(dòng)。更麻煩的是權(quán)限矩陣。同一個(gè)控制臺(tái)超級管理員看到的菜單和普通操作員看到的完全不同。有些按鈕只有特定角色才顯示有些接口只有特定 IP 段才允許訪問。手工測試還能憑“經(jīng)驗(yàn)”繞過去自動(dòng)化腳本一旦寫錯(cuò)判定條件就會(huì)在權(quán)限邊界上反復(fù)橫跳最后測出來的結(jié)果根本不能說明問題。1.2 傳統(tǒng)自動(dòng)化測試的“三個(gè)斷層”我最早也試過用 Playwright、Cypress 這類工具寫 E2E 腳本。剛開始覺得挺美好真正維護(hù)起來才發(fā)現(xiàn)有三個(gè)斷層第一個(gè)斷層是選擇器不穩(wěn)定。從開發(fā)者工具里復(fù)制出來的 CSS 路徑頁面改一次版就崩一次?？刂婆_(tái)又是動(dòng)態(tài)組件重災(zāi)區(qū)表格行會(huì)復(fù)用、彈窗會(huì)重渲染、按鈕 ID 經(jīng)常帶一串隨機(jī)數(shù)。你花一下午寫好的幾十個(gè) selector可能因?yàn)榍岸思恿艘粋€(gè) loading 狀態(tài)就全部失效。第二個(gè)斷層是數(shù)據(jù)狀態(tài)不可控。測試腳本跑在最理想的數(shù)據(jù)假設(shè)上環(huán)境里恰好有一條叫“test_user”的數(shù)據(jù)、恰好沒有臟數(shù)據(jù)擋住彈窗。但實(shí)際上控制臺(tái)測試環(huán)境往往是共用的你上一條用例產(chǎn)生的數(shù)據(jù)可能就污染了下一條用例的判定。要解決就得做數(shù)據(jù)初始化、接口 Mock、數(shù)據(jù)庫清理工作量比寫腳本本身還大。第三個(gè)斷層是斷言成本高。前端頁面大多是異步渲染你點(diǎn)完保存到底什么時(shí)候該斷言“成功提示”sleep 3 秒太蠢等待某個(gè)接口返回又需要額外封裝。更別說控制臺(tái)里有大量表格、圖表、狀態(tài)流轉(zhuǎn)斷言邏輯寫得稍微粗一點(diǎn)就會(huì)出現(xiàn)“測試全綠但功能實(shí)際上已經(jīng)壞了”的假陽性。這三個(gè)斷層疊加起來最終的結(jié)果就是自動(dòng)化測試腳本變成了團(tuán)隊(duì)里的“擺設(shè)”平時(shí)不敢跑發(fā)版前才跑一次跑掛了也沒人愿意去修。這不是工具的問題而是我們一直在用“固定路徑腳本”去對抗“高度動(dòng)態(tài)頁面”路徑一斷整個(gè)測試就塌了。2. Skill 與傳統(tǒng) Prompt/腳本的根本區(qū)別2.1 Skill 是一套“可復(fù)用的任務(wù)能力包”很多朋友一聽到“把前端測試寫成 Skill”第一反應(yīng)是這不就是寫一個(gè)Prompt嗎讓 AI 去點(diǎn)擊頁面然后我再補(bǔ)一句“小心點(diǎn)別點(diǎn)錯(cuò)了”就行了。但真正的 Skill 不是一句話而是一整套結(jié)構(gòu)化的技能包。你可以把它理解成給實(shí)習(xí)生一本工作手冊而不是在口頭交代任務(wù)。手冊里寫清楚了這個(gè)崗位負(fù)責(zé)什么、有哪些操作規(guī)范、遇到異常怎么處理、哪些事情絕對禁止。而 Prompt 只是你臨時(shí)說的一句“幫我去把用戶管理測一下”AI 可能理解成“用接口測”也可能理解成“用瀏覽器測”完全看運(yùn)氣。我用的這套 Skill 目錄大概長這樣skill-frontend-console-test/ ├── SKILL.md ├── commands/ │ ├── login.md │ ├── navigate.md │ └── assert.md ├── pages/ │ ├── login.md │ ├── user-list.md │ └── role-manage.md ├── workflows/ │ └── smoke-test.md └── examples/ └── user-crud.mdSKILL.md 是入口文件定義了技能的名稱、用途、觸發(fā)條件、操作邊界commands 里是 AI 可以使用的原子動(dòng)作比如登錄、跳轉(zhuǎn)、斷言pages 里是控制臺(tái)每個(gè)頁面的關(guān)鍵元素和可用操作workflows 里是常用業(yè)務(wù)流程的串聯(lián)方式examples 里放幾個(gè)經(jīng)典的執(zhí)行樣例。當(dāng) AI 加載這個(gè) Skill 時(shí)它看到的不是散落的指令而是一個(gè)“完整的工作環(huán)境”。它知道自己在測試控制臺(tái)知道每個(gè)頁面長什么樣知道每個(gè)流程應(yīng)該按什么順序走知道哪些按鈕危險(xiǎn)不能隨便點(diǎn)。這才叫把前端測試寫成了 Skill而不是寫了個(gè)花哨的提示詞。2.2 為什么一句話能驅(qū)動(dòng)它為什么我只需要輸入“從登錄開始把用戶管理流程走一遍”AI 就能自動(dòng)跑完整條鏈路因?yàn)樗x完 Skill 之后已經(jīng)把這句話拆成了“登錄→進(jìn)入用戶管理→新建→編輯→刪除→退出登錄”這樣的任務(wù)列表然后從 pages 和 workflows 里找到了每一步對應(yīng)的操作描述再調(diào)用 commands 里的原語去實(shí)際執(zhí)行。這本質(zhì)上是一個(gè)“意圖識別 路徑規(guī)劃 原語執(zhí)行”的過程。用戶的一句話是意圖Skill 里的 workflows 是路徑commands 和 pages 是執(zhí)行細(xì)節(jié)。沒有 Skill 的時(shí)候AI 只能靠猜有了 SkillAI 是在“照章辦事”。所以“一句話點(diǎn)完整個(gè)控制臺(tái)”并不是魔法而是我把原本需要在測試文檔里寫幾千字的操作步驟提前結(jié)構(gòu)化地塞進(jìn)了 Skill。AI 只是那個(gè)替我照著文檔執(zhí)行的人。2.3 和傳統(tǒng) E2E 腳本的本質(zhì)區(qū)別為了說清楚這件事我列了一個(gè)對比表格你可以直觀感受一下差異對比維度傳統(tǒng) E2E 腳本Skill 化的 AI 測試執(zhí)行方式固定代碼路徑一步不能錯(cuò)意圖驅(qū)動(dòng)AI 自動(dòng)規(guī)劃路徑頁面變更手動(dòng)改 selector 和流程代碼改 pages/workflows 里的語義描述異常處理腳本遇到異常就退出AI 能讀頁面、截圖、自糾錯(cuò)斷言策略硬編碼的 expect結(jié)合頁面狀態(tài)機(jī)和預(yù)期反饋動(dòng)態(tài)校驗(yàn)維護(hù)成本每次需求變更都要改代碼主要是補(bǔ)充語義描述和示例可解釋性失敗日志是堆棧輸出帶截圖的完整操作理由傳統(tǒng)腳本像是在鐵軌上跑火車鐵軌鋪到哪火車就只能跑到哪。軌道一斷火車就趴窩。Skill 化的 AI 測試更像一個(gè)會(huì)看地圖的司機(jī)你告訴他目的地他自己找路、自己避坑、自己確認(rèn)有沒有到。我不否認(rèn)傳統(tǒng) E2E 的價(jià)值但面對控制臺(tái)這種高動(dòng)態(tài)、多狀態(tài)、長鏈路的場景傳統(tǒng)腳本的維護(hù)成本實(shí)在太高了。Skill 的思路不是徹底取代腳本而是把“怎么寫腳本”這個(gè)問題變成了“怎么描述頁面和流程”而 AI 最擅長的恰恰就是理解描述。3. 把前端測試裝進(jìn) Skill 的核心設(shè)計(jì)3.1 先給控制臺(tái)畫一張“操作地圖”做 Skill 之前我做的第一件事不是寫代碼而是把控制臺(tái)的每個(gè)頁面都梳理成一張“操作地圖”。這張地圖不需要精確到 CSS 選擇器但必須把語義信息寫清楚這個(gè)頁面有哪些功能按鈕、每個(gè)按鈕點(diǎn)了之后預(yù)期出現(xiàn)什么反饋、當(dāng)前頁面從哪里可以跳轉(zhuǎn)到哪里。我以用戶管理模塊為例建了這樣一張表頁面可用動(dòng)作關(guān)鍵元素預(yù)期反饋登錄頁輸入賬號密碼、點(diǎn)擊登錄用戶名輸入框、密碼輸入框、登錄按鈕跳轉(zhuǎn)首頁右上角出現(xiàn)用戶頭像用戶列表搜索、新建、行內(nèi)編輯、刪除搜索框、新建用戶按鈕、表格行、操作列列表刷新、彈窗打開、出現(xiàn)操作成功提示新建用戶彈窗填寫表單、保存、取消姓名輸入框、手機(jī)號輸入框、角色下拉框、保存按鈕彈窗關(guān)閉列表出現(xiàn)新用戶接口調(diào)用成功角色管理創(chuàng)建角色、分配權(quán)限角色名稱輸入框、權(quán)限樹、保存按鈕角色列表更新權(quán)限勾選被保存我把這些信息寫進(jìn) pages 目錄下的對應(yīng)文件里。注意我沒有用“#user-list .edit-btn”這種選擇器而是寫“用戶列表行右側(cè)的編輯按鈕”。因?yàn)?AI 在處理這種語義描述時(shí)會(huì)比處理一串隨機(jī)生成的 class 名穩(wěn)定得多。這算是整份 Skill 能跑通的一個(gè)關(guān)鍵設(shè)計(jì)原則用人的語言描述頁面而不是用機(jī)器的語言。3.2 把自然語言指令翻譯成可執(zhí)行動(dòng)作有了操作地圖接下來要定義一層“可執(zhí)行動(dòng)作原語”。這層原語相當(dāng)于 AI 的手和腳每個(gè)動(dòng)作都要有明確的輸入、輸出和失敗條件。我在 Skill 的 commands 目錄里定義了一組基礎(chǔ)動(dòng)作open(url)打開目標(biāo)環(huán)境地址login(user, password)執(zhí)行登錄流程navigate(頁面描述)通過菜單或路由跳轉(zhuǎn)到指定頁面click(元素描述)點(diǎn)擊頁面上某個(gè)語義元素fill(元素描述, 值)在輸入框填入內(nèi)容wait_until(狀態(tài)描述)等待某個(gè)預(yù)期狀態(tài)出現(xiàn)比如“表格加載完成”assert_visible(元素描述)斷言某個(gè)元素可見assert_text(元素描述, 預(yù)期文本)斷言某個(gè)元素包含預(yù)期文本screenshot(名稱)給當(dāng)前狀態(tài)截圖留證當(dāng) AI 接到“測試新建用戶功能”這個(gè)指令時(shí)它會(huì)根據(jù) workflows 文件里的定義生成類似下面這樣的動(dòng)作序列navigate(用戶管理) wait_until(用戶列表已加載) click(新建用戶按鈕) wait_until(新建用戶彈窗已打開) fill(姓名輸入框, test_user_01) fill(手機(jī)號輸入框, 13800138000) click(保存按鈕) assert_visible(操作成功提示) screenshot(新建用戶完成)這些動(dòng)作看起來很像傳統(tǒng)測試腳本但區(qū)別在于每一個(gè)動(dòng)作里的“元素描述”都是語義化的。AI 會(huì)在執(zhí)行時(shí)自己去頁面上尋找匹配的按鈕、輸入框、彈窗而不是依賴一個(gè)寫死的 selector。所以哪怕前端微調(diào)了布局只要文案和層級沒有大變這個(gè)序列大概率還是能跑通。3.3 測試斷言與 UI 狀態(tài)機(jī)的結(jié)合控制臺(tái)測試最容易忽略的一點(diǎn)是頁面是有狀態(tài)的斷言必須跟著狀態(tài)走。我用了一個(gè)很樸素的狀態(tài)機(jī)思路每個(gè)頁面定義“前置狀態(tài)”和“后置狀態(tài)”。點(diǎn)擊“保存”之前表單處于“可編輯狀態(tài)”點(diǎn)擊保存之后預(yù)期狀態(tài)應(yīng)該是“彈窗關(guān)閉、列表刷新、出現(xiàn)成功提示”。AI 每執(zhí)行完一個(gè)動(dòng)作都要用wait_until和assert_visible去校驗(yàn)狀態(tài)是否如期遷移。如果狀態(tài)沒有遷移比如點(diǎn)擊保存后彈窗沒關(guān)、列表沒刷新AI 就要啟動(dòng)“自我修正”流程先截圖、讀取當(dāng)前頁面文本、對比預(yù)期再?zèng)Q定是重試一次還是調(diào)整操作。這一步是整個(gè) Skill 里最重要的設(shè)計(jì)。因?yàn)闆]有斷言的“點(diǎn)完”只是走馬觀花只有把狀態(tài)校驗(yàn)也包進(jìn)去測試才算真正有說服力。4. 從零到一落地這個(gè) Skill 的關(guān)鍵步驟4.1 搭建 Skill 骨架定義邊界和授權(quán)任何 AI 編程助手里的 Skill第一步都是把目錄結(jié)構(gòu)和入口文件搭起來。別急著寫 pages 和 workflows先把“這個(gè)技能能干什么、不能干什么”說清楚。我在 SKILL.md 開頭寫了這樣一段元信息--- name: frontend-console-test description: 用于Web控制臺(tái)的前端自動(dòng)化測試根據(jù)自然語言指令執(zhí)行點(diǎn)擊流程并輸出報(bào)告 allowed_operations: [open, navigate, click, fill, wait_until, assert, screenshot] forbidden_operations: [delete_without_confirm, export_without_confirm] ---這段信息的作用是給 AI 一個(gè)“行為紅線”?？刂婆_(tái)里有很多高危操作刪除數(shù)據(jù)、批量導(dǎo)出、修改權(quán)限這些動(dòng)作一旦誤觸代價(jià)非常大。所以我明確告訴 AI刪除和導(dǎo)出這類操作如果沒有在指令里顯式說明并且經(jīng)過我的二次確認(rèn)一律禁止執(zhí)行。各家 AI 助手的 Skill 格式可能會(huì)有一點(diǎn)差別但核心思想是通用的你給出的邊界越清楚AI 就越不會(huì)自作主張。很多人在這個(gè)環(huán)節(jié)偷懶結(jié)果后面 AI “發(fā)揮想象力”點(diǎn)了一堆不該點(diǎn)的按鈕這不是 AI 的錯(cuò)是你沒教好。4.2 在真實(shí)控制臺(tái)上跑通第一個(gè)用例骨架搭好之后我沒有急著寫全量頁面而是先挑最簡單的“登錄→進(jìn)入用戶管理→退出”跑通。這個(gè)過程其實(shí)是一場“調(diào)教”我打開真實(shí)控制臺(tái)讓 AI 開始執(zhí)行。我輸入“登錄測試賬號進(jìn)入用戶管理截圖當(dāng)前頁面”。然后盯著 AI 的行為序列看注意它是不是先打開了地址、再填賬號密碼、點(diǎn)擊登錄、等待跳轉(zhuǎn)最后才截圖。如果 AI 點(diǎn)了錯(cuò)誤的按鈕或者跳過了等待步驟我不會(huì)直接說“重新來一次”而是回到 pages 文件里修正對應(yīng)的語義描述。比如它總是找不到“登錄按鈕”我就把元素描述改得更具體一點(diǎn)“登錄按鈕是頁面右下角藍(lán)色的圓角按鈕”。重復(fù)幾輪之后AI 的行為會(huì)越來越穩(wěn)定這就是讓 Skill 真正學(xué)會(huì)“你的控制臺(tái)長什么樣”的過程。4.3 從單條指令擴(kuò)展到全控制臺(tái)巡檢第一個(gè)用例跑通后后面的擴(kuò)展其實(shí)就是復(fù)制粘貼加調(diào)整。我把日常手工測試的高頻流程全部寫成了 workflows用戶管理、角色權(quán)限、訂單審批、數(shù)據(jù)導(dǎo)入、配置發(fā)布每個(gè)流程鏈都包括前置條件、操作步驟、預(yù)期結(jié)果和后置清理。然后我再定義了一個(gè)復(fù)合任務(wù)叫“全控制臺(tái)巡檢”依次執(zhí)行所有 workflows每個(gè)流程結(jié)束都截圖并記錄結(jié)果。這樣我每天早上只需要對 AI 說一句“執(zhí)行全控制臺(tái)巡檢”它就會(huì)自己跑完所有核心鏈路再輸出一份 Markdown 報(bào)告里面包含每個(gè)流程的通過/失敗狀態(tài)、關(guān)鍵操作截圖、失敗原因分析。實(shí)測下來一次巡檢大概能覆蓋我平時(shí)手動(dòng)測試 40 分鐘的內(nèi)容AI 最快五分鐘內(nèi)就能跑完。當(dāng)然個(gè)別流程因?yàn)閿?shù)據(jù)準(zhǔn)備原因偶爾會(huì)失敗但 AI 會(huì)把失敗原因?qū)懙妹髅靼装孜抑恍枰磮?bào)告決定是修腳本還是修數(shù)據(jù)。5. 跑通之后我踩過的那些坑5.1 選擇器不是唯一解語義、角色、坐標(biāo)最開始我犯了一個(gè)非常經(jīng)典的錯(cuò)誤為了讓 AI 定位準(zhǔn)確我在 pages 里塞了大量 CSS 選擇器。結(jié)果頁面一改版選擇器失效AI 直接抓瞎。后來我改成“語義定位優(yōu)先”優(yōu)先用頁面上可見的按鈕文字、菜單名稱、表單 label 來定位。比如“點(diǎn)擊用戶列表右側(cè)操作列的編輯按鈕”而不是“點(diǎn)擊 #edit-3”。你會(huì)發(fā)現(xiàn) AI 對這種描述的理解能力遠(yuǎn)超預(yù)期因?yàn)樗谔幚頃r(shí)不只是讀 DOM還會(huì)結(jié)合可訪問性樹和視覺信息。如果元素沒有清晰的文字標(biāo)簽?zāi)蔷徒o它加一個(gè)語義別名。比如“保存按鈕”可能頁面上有多個(gè)我會(huì)寫成“新建用戶彈窗右下角的保存按鈕”。用坐標(biāo)定位是最不得已的方案我?guī)缀醪挥靡驗(yàn)榭刂婆_(tái)是響應(yīng)式布局坐標(biāo)在不同視口下完全不一樣。5.2 AI 操作過快導(dǎo)致狀態(tài)不同步第二個(gè)坑是 AI 的手速太快了。它剛點(diǎn)完“進(jìn)入用戶管理”下一秒就要去點(diǎn)“新建用戶按鈕”但這時(shí)候表格還在加載按鈕還沒渲染出來結(jié)果就撲了個(gè)空。解決方案不是加 sleep而是在 Skill 里強(qiáng)制約定每個(gè)動(dòng)作執(zhí)行完之后必須先wait_until等預(yù)期狀態(tài)出現(xiàn)再執(zhí)行下一步。等什么等接口返回后頁面出現(xiàn)的確定信號比如“用戶列表已加載”或“彈窗已打開”。這個(gè)約定看起來讓流程變慢了但換來的是整體成功率的大幅提升。我還給 AI 加了“單步確認(rèn)”模式。最開始調(diào)試 Skill 時(shí)每一步都會(huì)輸出當(dāng)前操作和當(dāng)前頁面狀態(tài)方便我看它有沒有按預(yù)期走。跑穩(wěn)定之后再關(guān)掉確認(rèn)讓它自動(dòng)連續(xù)執(zhí)行。5.3 斷言失敗時(shí)讓 AI 自己“糾錯(cuò)”第一版 Skill 遇到斷言失敗就直接停。后來我加了一個(gè)“自糾錯(cuò)循環(huán)”斷言失敗之后AI 先截圖并讀取當(dāng)前頁面文本把“預(yù)期”和“實(shí)際”做一個(gè)對比然后分兩種情況處理。如果是頁面元素描述過時(shí)了它就去更新 pages 里的語義描述然后重新執(zhí)行這一步。比如我寫過“保存成功提示”但前端后來改成了“操作成功”斷言失敗后 AI 發(fā)現(xiàn)文案變了會(huì)把這個(gè)文案更新為兩種都可接受并在最終報(bào)告里標(biāo)注“頁面文案發(fā)生變更”。如果是真正的功能 BugAI 會(huì)把這個(gè)失敗原樣記錄到報(bào)告里標(biāo)紅不會(huì)擅自修改斷言去“掩蓋問題”。這個(gè)機(jī)制非常關(guān)鍵因?yàn)樗谋举|(zhì)是讓測試腳本自己進(jìn)化而不是每次前端一改版就需要人工去維護(hù)斷言。5.4 權(quán)限與安全邊界是必須提前設(shè)好的我剛做完 Skill 的時(shí)候很興奮有一次讓 AI“把控制臺(tái)所有按鈕點(diǎn)一遍”結(jié)果它真的差點(diǎn)去執(zhí)行一個(gè)生產(chǎn)環(huán)境的數(shù)據(jù)清理任務(wù)。雖然我的 Skill 前綴帶了forbidden_operations但那次我用的指令是“所有按鈕”繞過了具體限制。這件事之后我把安全邏輯做了兩層加固第一層Skill 只允許在指定測試域名下工作非測試環(huán)境直接拒絕執(zhí)行第二層凡是涉及刪除、導(dǎo)出、修改權(quán)限這類高危動(dòng)作AI 必須先暫停并問我“是否確認(rèn)執(zhí)行”我不確認(rèn)就不動(dòng)。永遠(yuǎn)不要假設(shè) AI 有“常識”。在 Skill 里把邊界寫到足夠死才是負(fù)責(zé)任的用法?？刂婆_(tái)測試的終極目標(biāo)不是讓 AI 替我亂點(diǎn)而是讓 AI 在一個(gè)受控的范圍內(nèi)幫我做重復(fù)勞動(dòng)。6. 這個(gè) Skill 帶來的延伸價(jià)值和個(gè)人體會(huì)做完這個(gè) Skill 之后我發(fā)現(xiàn)它最大的收獲其實(shí)不是“省了幾個(gè)小時(shí)手點(diǎn)”而是讓我重新理解了前端測試這件事。以前寫測試用例最后沉淀下來的是幾百行代碼和一群沒人看的文檔?，F(xiàn)在這些知識全部變成 Skill 里的語義描述和 workflow每次頁面改版我更新 pages 文件的過程本質(zhì)上就是在整理“當(dāng)前控制臺(tái)到底長什么樣”。這份活文檔對團(tuán)隊(duì)新人也特別友好新同學(xué)想了解控制臺(tái)的核心流程不用再看幾十頁 case直接讓 AI 跑一遍巡檢再看報(bào)告就能理解七七八八。另外AI 在點(diǎn)擊過程中還會(huì)“順便”發(fā)現(xiàn)一些可訪問性問題。比如某個(gè)按鈕沒有可訪問性標(biāo)簽AI 定位時(shí)會(huì)猶豫很久某個(gè)頁面打開后焦點(diǎn)沒有落在預(yù)期位置AI 會(huì)把它記成一條體驗(yàn)問題。這些都是以前寫自動(dòng)化測試腳本時(shí)根本不會(huì)留意到的細(xì)節(jié)但恰恰是控制臺(tái)這類后臺(tái)系統(tǒng)日常最容易忽略的質(zhì)量問題。如果讓我重新做一次我會(huì)更早放棄“寫死腳本”的執(zhí)念直接從語義描述和狀態(tài)機(jī)入手。給 AI 一本好的工作手冊比教它一萬句臨場指令管用得多。而且別指望第一天就能“一句話點(diǎn)完全部”先把最高頻的一條流程做到百分百穩(wěn)定再一點(diǎn)點(diǎn)把整個(gè)控制臺(tái)裝進(jìn) Skill 里。這個(gè)不斷沉淀的過程才是這類 AI 測試方案真正值得投入的地方。