LuluSkill 文章
怎麼檢查 AI 助理幫你做出來的東西
把驗收方式變成一次簡短的測試：該試什麼、怎麼記下失敗、怎麼回報給助理，以及什麼時候該停下來重新規劃。
這是 LuluSkill 自己寫的內容。它不引用、不鏡像、也不摘要任何第三方 Skill，也不推薦任何一個。閱讀它不會建置、發布或執行任何東西：AI 工具會拿你的文字做什麼，要由你自己檢查。
看起來完成的第一版，仍然要通過你的檢查
助理交回第一版的時候，它通常看起來已經完成了：頁面有標題、按鈕有文字，也許還附上一段「全部完成」的說明。但這些都無法告訴你，你寫委託時設想的那個人，能不能完成你設想的那件事。唯一的辦法，是親自試一次。
做這件事不需要看懂程式碼。你檢查的是行為：一個人做了什麼，以及他看到什麼回應。你寫在委託裡的驗收方式，就是這次測試的起點，因為那是你早就決定好、用來判斷成果值不值得保留的那一項測試。
這篇文章會用到的三個詞
白話解釋
- 測試單
- 把驗收方式改寫成有編號的步驟，每一步都寫明你要做什麼、預期會看到什麼。
- 失敗紀錄
- 針對一件不符合預期的事寫下的幾行字：發生在哪裡、你做了什麼、你預期什麼、實際發生了什麼。
- 重新規劃
- 回到委託本身，修改其中的某個決定，而不是針對同一個成果再要求一次修補。
開始測試之前
- 使用虛構的測試資料——編出來的名字和日期——不要用未來使用者的真實資料。
- 測試結束之前，不要改動正在測的版本，這樣每一則紀錄描述的都是同一個東西。
- 先不要分享給真正要用的人。還沒通過檢查的第一版，仍然只是你手上的測試品。
- 如果它要你輸入密碼、付款或真實地址，先停下來，確認委託裡到底有沒有要求過這些。
把驗收方式改寫成一張測試單
驗收方式通常只有一句話，例如「兩位志工用兩支手機報名同一個班次，兩個名字都會出現」。這句話是這次測試的目標，但還不是一位幫手能不問你就照著做的東西。測試單，就是把同一句話展開，變成一個人實際會走的每一步。
寫的時候，要讓一個從沒看過這個專案的人也能照著做。如果幫手卡在測試單上，問題出在測試單，而不是出在助理做出來的東西。
測試單的每一行這樣寫
- 替每一步編號，這樣紀錄上只要寫「第 4 步失敗」，不必把整條路徑重新描述一次。
- 寫出使用者要做什麼，連輸入的內容都寫清楚：「輸入名字『小美』，點第一個星期六」，而不是「報名」。
- 寫出之後應該看到什麼，用能直接拿來和畫面比對的字句：「『小美』出現在第一個星期六底下」。
- 標出哪一步就是驗收方式本身，讓每個人都知道哪一種失敗最要緊。
- 最後加一步，確認成果還在：關掉頁面，重新打開，再看一次。
在測試單最上方寫下
- 正在測哪一個版本、用哪一種裝置——先從使用者實際會用的那一種開始。
- 你要輸入的虛構測試資料，這樣第二輪測試才能用同樣的名字和日期。
- 哪些是「先不做」的，這樣幫手就不會把你刻意沒要求的功能，回報成缺漏。
空白測試單
範例
把這幾行複製到一份筆記裡，填入括號中的內容，再把括號刪掉。第一版通常五個步驟就夠了。
- 版本與裝置：［哪一個版本，以及使用者實際會用的裝置］。先不做：［委託裡的那份清單］。
- 測試資料：［你要輸入的虛構名字、日期與數值，每一輪都用同一組］。
- 第 1 步：［使用者做什麼，連輸入內容都寫清楚］。預期：［應該看到什麼，用能直接和畫面比對的字句］。
- 第 2 步：［一般路徑上的下一個動作］。預期：［看得見的結果］。
- 第 3 步（驗收方式本身）：［委託裡的那句話，改寫成兩個人實際會做的事］。預期：［委託承諾的結果］。
- 第 4 步（犯錯路徑）：［一個錯誤或漏填的輸入］。預期：［一則說明接下來怎麼做的訊息，而且什麼都沒存進去］。
- 第 5 步：［全部關掉再重新打開］。預期：［前面幾步的東西都還在］。
括號本身就是重點：當每一個括號都被填掉，測試單才算完成；還留著括號的測試單，代表有一個問題你會在測試途中用猜的來回答。
該試什麼，又該照什麼順序
順序很重要，因為前面的失敗會把後面的問題蓋住。如果連一般路徑都走不通，去測打錯字之後會怎樣，就沒什麼意義。先完全照著測試單走，通過之後再慢慢往外擴。
一輪測試，依這個順序
- 一般路徑：完全照測試單走，用使用者實際會用的裝置。不要幫忙、不要跳步，也不要繞過任何問題。
- 驗收方式本身，就算安排起來有點麻煩也要做——兩支手機、兩個人、同一個時間點。
- 犯錯路徑：留一個欄位空白、用錯誤的格式輸入日期、把主要按鈕連按兩下。
- 中途打斷：走到一半按「上一頁」、儲存前重新整理、全部關掉之後再重新打開。
- 不該看到的人：用無痕視窗、不登入打開頁面，看看一個陌生人會看到什麼。
- 每一則訊息、委託要求的每一種語言都要看——包括錯誤訊息，因為它們只在出錯時才會出現。
看起來沒問題，但值得再看一眼的地方
- 「已儲存」的訊息。那只是一個說法，不是證明：重新整理頁面，看看東西是不是真的還在。
- 沒拿掉的範例內容：佔位文字、範例名字，以及看起來像真的、其實是編出來的數字。
- 你沒要求的功能。拿它們和「先不做」清單比對；每多一個，就多一樣要檢查、要照顧的東西。
- 任何宣稱會送出訊息或提醒的功能。在放進任何真人的資料之前，先弄清楚它是不是真的會送，又會送給誰。
怎麼記下哪裡失敗
每看到一個失敗，就立刻寫下來。記憶會把細節磨平：一個小時後，「我在第二支手機按下『儲存』之後，名字就不見了」會變成「報名好像怪怪的」，而後面那句話，沒有人能據以處理。
紀錄是描述，不是診斷。如果你猜得到原因，可以寫在最後，並註明是猜測。事實要放在前面，因為就算猜錯了，事實依然成立。
一則失敗紀錄的六行
白話解釋
- 在哪裡
- 測試單上的步驟編號，以及發生在哪一個頁面。
- 我做了什麼
- 確切的動作、輸入內容和裝置：「在第二支手機上輸入『安安』，按下『儲存』」。
- 我預期什麼
- 測試單上的那一行，直接照抄，不要換句話說。
- 實際發生什麼
- 你看到的情況，以及任何訊息的確切字句。照抄，不要摘要。
- 多常發生
- 每次都會、有時候會，還是只有一次。下結論之前再試一次，因為這三種情況需要的修法都不一樣。
- 影響多大
- 卡住關鍵流程、有錯但能繞過，還是只是外觀問題。這決定了你回報的先後順序。
讓紀錄保持有用
- 一則紀錄只寫一個失敗。兩個問題寫在一起，回來時往往只修好了其中一個。
- 不要寫進真實的個人資料。如果某個失敗只有在真實資料下才會出現，就描述那筆資料的樣子，不要照抄。
- 也要記下通過的部分。簡單一句「第 1 到 3 步通過」，下一輪就能讓你看出修正有沒有弄壞原本正常的地方。
檢查過程中常見的六種失誤，以及該怎麼做
一場測試可以失敗，而成果本身沒有任何問題。這種時候，紀錄看起來很有說服力，卻指向錯誤的地方——這比完全沒有紀錄更糟。下面每一列都是測試本身出錯的方式，以及你在發現的當下該怎麼做。
| 失誤 | 你怎麼察覺 | 該改成怎麼做 |
|---|---|---|
| 測試一個還在變動的版本 | 兩則紀錄對同一步的描述不一樣，而你說不出哪一則來自哪一個版本。 | 停下來，寫下你正在測的是哪一版，然後在那一個版本上從第 1 步重新走一次。 |
| 順手幫了它一把 | 某一步通過了，但那是因為你重新整理、重新輸入，或用測試單沒寫的方式等了一下。 | 把那個變通做法寫進紀錄，當成失敗的一部分，並讓那一步算作失敗。 |
| 只寫診斷、不寫描述的紀錄 | 紀錄寫的是你認為的原因，卻完全沒有寫你做了什麼、看到什麼。 | 改寫成先寫四項事實——在哪裡、我做了什麼、我預期什麼、實際發生什麼——再把猜測加在最後，並標明是猜測。 |
| 一則紀錄塞了三個問題 | 這則紀錄很難標成已修正，因為它有一部分還在失敗。 | 在回報之前，把它拆成一則一個問題，並排出先後順序。 |
| 只記下失敗的部分 | 修正之後，你分不出原本通過的步驟是不是還通過。 | 加一行寫出通過的步驟，並在下一輪先檢查它們。 |
| 拿真實資料來測 | 紀錄或成果裡現在含有某個真人的資料。 | 停止測試，把資料換成虛構的值，並改用描述的方式說明那個真實情況。 |
比較
完整走一次：志工報名頁的測試
這個例子延續談寫提示詞那篇文章裡虛構的食物銀行。協調人拿到了報名頁的第一版，找來一位志工、準備兩支手機。這只是示範，不代表任何真實的成果會出現同樣的內容。
測試單
範例
協調人那一句驗收方式，展開成五個步驟。測試資料：虛構的名字「小美」、「阿哲」和「安安」。
- 版本：星期二交回來的那一版。裝置：兩支手機。先不做：密碼、簡訊提醒、服務時數報表。
- 第 1 步：用手機 A 打開頁面。預期：看到接下來四個星期六，每一天都列出班次。
- 第 2 步：輸入「小美」，點第一個星期六的早班。預期：「小美」出現在那個班次底下。
- 第 3 步（驗收方式本身）：手機 A 輸入「阿哲」、手機 B 輸入「安安」，兩邊幾乎同時點同一個下午班。預期：兩支手機上都看得到兩個名字。
- 第 4 步：名字欄位空白時按「儲存」。預期：出現請你填寫名字的訊息，而且什麼都沒有存進去。
- 第 5 步：兩支手機都關掉頁面，再用手機 A 重新打開。預期：小美、阿哲和安安都還在。
只有五步，一位從沒看過這個專案的幫手也能每一步都照著做。第 3 步特別標出來，因為整份委託就是圍繞著這項檢查寫的。
這一輪測試發現了什麼
範例
測試過程中寫下的三則失敗紀錄，最嚴重的排在最前面，再加上一行通過的部分。
- 紀錄 1，第 3 步，卡住關鍵流程：阿哲和安安前後只差一下點了下午班。預期兩個名字都在。兩支手機都只顯示安安，重新整理之後也一樣。試了兩次，兩次都這樣。
- 紀錄 2，第 4 步，有錯但能繞過：名字空白時按「儲存」，班次上多了一筆空白的名字，也沒有出現任何訊息。
- 紀錄 3，不在測試單上、屬於先不做的範圍：每個班次底下多了一顆「傳送提醒」按鈕，按下去會顯示「提醒已送出」。沒有人提供過任何電話號碼，所以不清楚它到底有沒有送出什麼。
- 通過：第 1、2、5 步。頁面在手機上也不需要左右捲動。
雖然紀錄 3 最出人意料，但先回報的是紀錄 1：它就是驗收方式本身，在它通過之前，這個頁面連唯一的任務都還沒達成。紀錄 3 則以「超出範圍、請移除」的方式回報，而不是當成要修好的功能。
怎麼把失敗描述給助理
「不能用，請修好」這種話，等於讓助理自己去猜是哪個部分壞了、怎樣才算正常，而它的猜測可能會動到原本沒問題的地方。有用的回報，幾乎就是把紀錄原封不動地轉過去。
一次只回報一個失敗，從最嚴重的開始。請它在動手之前，先說明可能的原因和打算怎麼改，這樣如果中間有誤會，你可以在它還只是文字的階段就發現。
回報範本
範例
複製這幾行，用一則失敗紀錄填入括號裡的內容，再把括號刪掉。
- 哪一步：［步驟編號，以及這一步是要做什麼］。
- 我做了什麼：［確切的動作、輸入的內容，以及使用的裝置］。
- 我預期：［測試單上的那一行，或它所根據的委託原文］。
- 實際發生：［我看到的情況，訊息請照抄］。發生頻率：［每次／有時／一次］。
- 動手之前：請先告訴我你認為原因是什麼、打算改哪裡。只改這個問題需要改的地方，並告訴我可以怎麼確認它真的修好了。
最後一行最關鍵。它把「請修好」變成一段你隨時可以喊停的簡短對話，而且要的是一個確認修正的方法，而不是一句「已經修好了」。
填好的範本
範例
這一輪測試的紀錄 1，協調人實際送回去的版本。
- 哪一步：測試單第 3 步，兩位志工同時報名同一個班次。這就是我委託裡的驗收方式。
- 我做了什麼：一支手機輸入「阿哲」、另一支輸入「安安」，前後只差一下，都點了第一個星期六的下午班。
- 我預期：兩支手機上，這個班次都有兩個名字，因為委託裡寫明兩個名字都必須出現，任何一個都不能消失。
- 實際發生：兩支手機上都只列出安安，重新整理之後也一樣。我試了兩次，兩次都這樣。
- 在你動手之前，請先告訴我你認為原因是什麼、打算怎麼改。頁面的其他部分請維持原樣，並告訴我可以怎麼確認修好了。
這裡完全不需要技術用語。協調人沒有說名字為什麼消失，只說它消失了、在什麼情況下消失——而這正是任何想找出原因的人最先需要的資訊。
收到回覆之後
- 如果它的說明和你看到的情況對不上，在任何改動之前就說出來。瞄準錯誤原因的修正，可能會帶來新的問題。
- 改動之後，從第 1 步把整張測試單重新走一遍，而不是只測失敗的那一步。一個地方的修正，可能弄壞原本通過的另一步。
- 只有當那一步在使用者實際會用的裝置上通過時，才把紀錄標為已修正——而不是看到一句「已修正」就算數。
什麼時候該停止修補，重新規劃
只要每一輪留下的紀錄都比上一輪少，一次修一個失敗就行得通。一旦紀錄不再減少——同一個失敗又回來，或每修好一個就冒出另一個——再多做幾輪同樣的事，大概也幫助不大。問題往往不在最後一次改動，而在委託裡從來沒有做出的某個決定。
該停下來重新規劃的跡象
- 同一個失敗在修了兩三輪之後，又出現了。
- 每一次修正都弄壞一個原本通過的步驟，所以紀錄的數量不減反增。
- 你寫不出「我預期」那一行，因為委託裡從來沒決定應該發生什麼。
- 失敗都出在你沒要求的功能上，而移除它們又一再弄壞你真正要的功能。
- 成果已經長得遠遠超出那一頁計畫，你也說不出哪一條才是關鍵流程了。
重新規劃，但不必從零開始
- 停止要求修補。保留最新的紀錄，也保留通過最多步驟的那一個版本。
- 拿紀錄對照委託，找出缺漏或不清楚的那個答案——常見的是給誰用、完成的樣子，或先不做什麼。
- 只改寫那一個答案，用白話補上失敗揭露出來的規則——「兩個人可以在同一時間報名同一個班次」——並在測試單上加一步來檢查它。
- 把修改後的委託和測試單一起交出去，並說明要從上一個版本繼續，還是從委託重新開始。
第一版算通過的條件
- 測試單上的每一步都通過，而且是在使用者實際會用的裝置上。
- 連續通過兩次，每次都重新打開頁面。
- 由你以外的人照著測試單走完，過程中你沒有出手幫忙。
- 「先不做」清單上的東西，一樣都沒有偷偷跑進來。
通過，並不代表其他地方都沒有問題。它代表的是：你設想的那個人，已經能完成你寫委託時要它完成的那件事。一路上注意到的其他事情，都放進下一版的清單，並替每一件寫好它自己的驗收方式。
你的下一步
用你自己的想法依序做三件事。每一件都不需要帳號、工具或 Skill。
- 把你的驗收方式改寫成一張大約五個編號步驟的測試單，每一步都寫明要做什麼、預期看到什麼。
- 請一位沒看過這個專案的人用手機照著測試單走，你在旁邊每遇到一個失敗就寫一則紀錄，過程中不要出手幫忙。
- 只用範本回報最嚴重的那一則紀錄，改動之後，再把整張測試單從頭走一遍。