但如果真的開始使用 Bookmarklet，很多人很快就會遇到另一個問題：
「為什麼昨天明明可以用，今天就突然失效？」
或是：
「為什麼我叫 AI 幫我寫了 Bookmarklet，但貼上去之後完全沒反應？」
再不然就是：
「畫面上明明有這個欄位，為什麼程式就是抓不到？」
這些問題其實很常見，一開始我也會直覺覺得，是不是 AI 寫錯了？或是 JavaScript 哪裡壞掉？
但後來越用越發現，很多時候不是 Bookmarklet 本身不能用，也不是 AI 完全寫錯。
而是我們沒有先理解一件事：
Bookmarklet 不是用人的眼睛看網頁。它是用網頁背後的 HTML 結構在找資料。
這句話就是這篇文章最重要的核心，因為只要開始理解這件事，很多原本看起來很玄的問題，就會慢慢變得合理。
為什麼同樣叫「備註」的欄位，有時候抓得到，有時候抓不到？
為什麼按鈕明明在畫面上，程式卻點不到？
為什麼網站只是改了一點點版面，Bookmarklet 就壞掉？
其實答案大多都跟 HTML 結構、DOM、欄位名稱、CSS Selector 有關。
這篇不會用很硬的方式介紹，因為我自己也不是要把 Bookmarklet 講成前端工程課程。
更何況對多數人來說，真正需要的也不是完整學會前端技術，而是先知道網頁背後大概是怎麼組成的，這樣在請 AI 幫忙寫小工具時，才比較知道自己要提供什麼線索。
我的想法比較簡單：
只要讓一般使用者知道，網頁背後大概是怎麼組成的，就比較有能力跟 AI 描述需求，也比較知道為什麼小工具會失效。
一、你看到的網頁，其實只是「畫面結果」
我們平常打開一個網頁時，看到的是：
【漂亮的按鈕、輸入框、下拉選單、表格、文字、圖片、彈出視窗、資料列表】
但這些只是瀏覽器呈現出來的結果。
就像你看到一間裝潢好的房子，你看到的是沙發、餐桌、電視牆、櫃子。
可是房子真正能不能穩定存在，背後靠的是：
【樑柱、水電、牆面、管線、格局】
網頁也是一樣，你看到的是畫面，但 Bookmarklet 真正在看的，是背後的結構。
這個背後的結構，大多就是我們常聽到的：
HTML
HTML 可以先不用想得很複雜，你可以把它理解成：
網頁的骨架。
例如一個最簡單的網頁，可能會有：
【標題、段落、按鈕、輸入框、表格】
每一個畫面上的東西，通常背後都有一段 HTML 來描述它。
例如：
這是一個標題
背後可能是一個標題標籤。
這是一個按鈕
背後可能是一個 button。
這是一個輸入框
背後可能是一個 input 或 textarea。
所以 Bookmarklet 在網頁上做事時，並不是像人一樣「看起來這邊有一個按鈕」。
它比較像是在問：
這個網頁裡，有沒有符合條件的 button？
有沒有名稱叫做某某欄位的 input？
有沒有某個表格欄位可以抓出來？
這就是為什麼要稍微理解 HTML，不是因為每個人都要變工程師。
而是當你知道網頁背後有結構，你就比較能理解：為什麼 AI 需要你提供更精準的資訊。
二、畫面上看到的文字，不一定就是程式抓得到的欄位
這是我覺得最容易誤會的一點，很多人會覺得：
畫面上有寫「問題描述」，那程式應該就可以直接抓到「問題描述」這個欄位吧？
不一定
因為畫面上看到的「問題描述」，可能有好幾種情況。
它可能是：
- 真正對應到輸入框的標籤
- 只是畫面上的文字說明
- 只是 placeholder 提示文字
- 被包在其他元件裡的顯示文字
- 舊欄位名稱，實際欄位已經換了
- 有兩個一樣名稱的欄位，但其中一個是隱藏的
這就是為什麼有些 Bookmarklet 會出現很奇怪的狀況。
例如：
明明畫面上有「備註」，但程式抓不到。
明明有兩個欄位都叫「處理狀況」，但程式抓到舊的那個。
明明新增頁面跟編輯頁面長得很像，但 Bookmarklet 只能在其中一個頁面正常運作。
這些都不是很罕見的問題。
因為很多系統在開發過程中，前端畫面可能會保留一些舊欄位、隱藏欄位、相同名稱的 label，或是不同頁面的 HTML 結構根本不一樣。
人的眼睛看起來差不多，但對程式來說，可能是完全不同的東西。
這也是我後來學到的一件事：寫 Bookmarklet 時，不要只跟 AI 說「幫我抓備註欄位」。
比較好的說法是：「請幫我找畫面上標題為『備註』且旁邊或下方有可輸入欄位的那一組，不要抓隱藏欄位，也不要抓標題後面有『舊』字樣的欄位。」
這樣 AI 寫出來的邏輯，就會比較接近真實需求。
因為你不是只告訴它欄位名稱，你也告訴它：
【哪些不要抓、哪些才是真正要抓的、遇到重複名稱時要怎麼判斷】
這才是比較實用的問法。
三、DOM 是什麼？可以先把它想成「瀏覽器整理後的網頁現場」
接下來常會看到另一個名詞：
DOM
這個字看起來很硬，但如果用白話說，我會把 DOM 理解成：
瀏覽器把網頁讀進來之後，整理出來的一份現場結構。
HTML 比較像原始設計圖。
DOM 比較像瀏覽器實際整理出來、正在運作中的網頁現場。
為什麼需要知道 DOM？
因為 Bookmarklet 執行時，通常是在目前這個網頁現場裡找東西。
例如它可能會找：
- 目前頁面所有按鈕
- 目前頁面所有輸入框
- 目前頁面所有表格列
- 目前畫面上某個標題旁邊的欄位
- 目前彈出視窗裡面的資料
所以如果資料還沒載入完成，Bookmarklet 太早執行，就可能找不到。
如果資料在分頁切換後才出現，Bookmarklet 在切換前執行，也可能找不到。
如果資料藏在 iframe 裡面，Bookmarklet 可能也抓不到或需要特殊處理。
如果畫面是彈窗，實際資料可能不在原本頁面裡，而是在另一層結構裡。
這就是為什麼有些 Bookmarklet 會出現：
剛進頁面點沒反應，但等幾秒再點就可以。
在列表頁可以用，在編輯頁不能用。
在 Chrome 可以用，在某個內建瀏覽器不能用。
同一套系統 A 頁面可以用，B 頁面卻失效。
因為它看到的 DOM 現場不一樣。
四、CSS Selector 是什麼？可以先把它想成「網頁元素的地址」
再來是另一個很常見的名詞：CSS Selector
這個也不用想得太複雜，你可以先把它理解成：程式用來找到網頁上某個元素的地址。
就像你要去某個地方，要有地址。
Bookmarklet 想要找到某個按鈕、欄位、表格，也需要一種定位方式，常見定位方式可能包含：
- 用標籤找，例如 input、button、table
- 用 class 找，例如某個樣式名稱
- 用 id 找，例如某個唯一編號
- 用文字找，例如按鈕文字是「查詢」
- 用相對位置找，例如「問題描述」標題下面的 textarea
但這裡也有一個問題存在，很多網站的 class 名稱，不一定是穩定的。
尤其現在很多前端框架產生的 class，可能長得像亂碼，也可能每次改版後就變掉。
例如今天叫：abc123
下次改版變成：abc456
如果 Bookmarklet 寫死抓這個 class，那網站一改版就壞掉。
所以我現在比較偏好的做法是：不要只靠很容易變動的 class。
如果可以，盡量讓 AI 用比較穩定的判斷方式。
例如：
- 按鈕上的文字
- 欄位旁邊的標題
- 表格欄位名稱
- 可見文字與輸入框的相對位置
- 固定的 data-* 屬性
當然，這不是絕對。
每個網站狀況不同，所以這不是絕對標準。
但如果你是一般使用者，不知道怎麼跟 AI 說，可以先用白話描述：
「不要只依賴容易改變的 class 名稱，請盡量依照畫面上可見的欄位標題、按鈕文字、表格欄名來尋找。」
這句其實就很有幫助。
五、為什麼 Bookmarklet 會突然失效？
這大概是最多人會遇到的問題。
Bookmarklet 最常失效的原因，我自己整理大概有幾類。
1. 網站改版，HTML 結構變了
這是最常見的，畫面可能只是看起來改了一點點。
例如：按鈕位置移動、欄位排版改變、表格多一欄，但背後 HTML 結構可能已經完全不同。
對人來說只是小改版，對 Bookmarklet 來說，可能就是原本的路不見了。
2. 欄位名稱改了
例如原本叫：處理狀況
後來改成：處理狀況說明
或是原本叫：備註
後來改成：內容備註
人看得懂差不多，但程式如果原本是精準找「備註」，改名後就可能找不到。
3. 同名欄位太多，抓錯地方
這個也很常見。
畫面上可能有很多地方都叫「備註」。
例如：
- 主要資料的備註
- 歷史紀錄的備註
- 審核區塊的備註
- 隱藏舊欄位的備註
如果程式只是找第一個「備註」，就很容易抓錯，所以有時候 Bookmarklet 不是沒抓到，而是抓到不該抓的地方。
4. 資料是動態載入的
有些網站不是一打開就把資料全部放在畫面上，而是你點了查詢、切換分頁、打開彈窗後，資料才慢慢載入。
這種情況下，如果 Bookmarklet 太早執行，就會找不到資料。
這也是為什麼有些工具需要等畫面載入完成後再點。
5. 資料在 iframe 裡
有些系統會把某些畫面放在 iframe 裡。
你可以把 iframe 想成：網頁裡面又嵌了一個小網頁。
如果資料在 iframe 裡，Bookmarklet 不一定能直接抓到，尤其如果 iframe 來源不同，還可能受到瀏覽器安全限制。
這種情況就不一定適合用簡單 Bookmarklet 處理。
6. 權限或登入狀態不同
有時候不同使用者看到的欄位不一樣，主管看得到，承辦看不到。
A 角色有按鈕，B 角色沒有按鈕。
測試帳號有資料，正式帳號沒有資料。
這時候 Bookmarklet 也可能會出現某些人能用、某些人不能用的狀況。
7. 網站本身阻擋某些操作
有些網站基於安全性，可能會限制某些程式操作。
例如：不允許直接複製、不允許跨頁讀取、不允許自動送出，或是某些操作需要真實使用者點擊。
這種情況下，Bookmarklet 就不一定能處理。
所以我會說：Bookmarklet 很方便，但它不是萬能工具。
六、一般人要怎麼開始看 HTML 結構？
很多人聽到「看 HTML」會怕，但其實不用一開始就看懂全部，你只要先學會看幾個重點就好。
第一步：在網頁上按右鍵，選擇「檢查」
在 Chrome 或 Edge 裡，通常可以對某個欄位或按鈕按右鍵，選擇：檢查
或是英文介面叫：Inspect
接著瀏覽器會開啟開發者工具，畫面會突然出現一堆程式碼。
第一次看到會覺得很可怕。
但先不要急著關掉。你不用看懂全部。
你只要先知道：它目前反白的那一段，大概就是你剛剛點到的畫面元素。
第二步：先找關鍵文字
例如你要找「處理狀況」。
可以在開發者工具裡按 Ctrl + F，搜尋：處理狀況
看看 HTML 裡面有沒有出現這個文字。
如果有，就代表這個文字真的存在於網頁結構中。
如果沒有，可能代表它是用其他方式顯示，或是你目前看的區塊不對。
第三步：看它旁邊有沒有 input、textarea、select
如果是表單欄位，常見的東西有：【input、textarea、select】
大概可以先這樣理解：
- input：單行輸入框
- textarea：多行文字欄位
- select：下拉選單
- button：按鈕
- table：表格
你不需要一開始就完全懂，但只要知道這幾個字，就會比較有方向。
例如你看到「問題描述」附近有 textarea，那大概就知道它是多行文字欄位。
你看到「查詢」附近有 button，那大概知道它是一個按鈕。
你看到很多 tr、td，通常就是表格列與表格格子。
第四步：觀察有沒有重複欄位
如果你搜尋「備註」，發現出現 5 次，那就要小心。
因為 AI 如果只是寫：找到備註欄位
很可能會抓到錯的那個，這時候你可以補充告訴 AI：
「這個頁面有多個備註欄位，我要的是畫面中某某區塊內、標題為備註的可輸入欄位。」
你越能描述位置，AI 越有機會寫出接近需求的工具。
七、問 AI 寫 Bookmarklet 時，不要只說「幫我做一個工具」
這是我覺得最重要的實務心得。
很多人會直接問 AI：幫我寫一個 Bookmarklet，抓出這個網頁的資料。
這樣當然有機會成功，但也很容易失敗。
因為 AI 不一定知道你的網頁長什麼樣子。
不一定知道欄位在哪裡。
不一定知道有哪些同名欄位。
不一定知道你要抓的是列表頁，還是編輯頁。
不一定知道你要的是畫面上的文字，還是背後欄位值。
所以我現在比較建議，問 AI 時至少提供幾個資訊。
1. 先說你要解決什麼問題
我覺得問 AI 做工具時，不一定要一開始就想「程式要怎麼寫」。
更重要的是先說清楚：我最後想看到什麼結果？
例如：
我每天要檢查列表中，哪些案件超過 30 天未更新。
我想做一個 Bookmarklet，在目前頁面統計案件數量，並依照狀態分類。
我想檢查某個設定頁面中，資料是否有掛在正確的對象上。
這樣 AI 才知道你的工具目的，也比較能反推中間需要抓哪些資料、做哪些判斷。
2. 說明你在哪個頁面使用
例如：
【列表頁、新增頁面、編輯頁面、查詢結果頁、彈出視窗、設定頁面】
因為不同頁面結構可能不同，同一個系統裡，不同頁面也可能完全不一樣。
3. 說明你要抓哪些欄位
例如：
我要抓表格中的「號碼」、「名稱」、「狀態」、「最後更新時間」。
我要抓表單中的「問題描述」、「處理狀況」、「備註」。
我要找按鈕文字為「儲存」或「查詢」的按鈕。
欄位名稱越清楚越好。
4. 說明哪些情況要排除
這點很重要，但很多人會忘記。
例如：
不要抓隱藏欄位。
不要抓標題含有「舊」的欄位。
不要自動送出表單。
不要把資料傳送到外部網站。
不要修改頁面原始資料，只在畫面上顯示統計結果。
這些限制一定要講清楚，因為 Bookmarklet 是有能力修改頁面的。
如果你只要它統計，就要明確說不要自動送出或修改。
5. 提供你觀察到的 HTML 線索
如果你已經有用「檢查」看到一些資訊，可以貼給 AI。
例如：
這個欄位附近有 textarea。
表格欄位名稱是 th。
每一列資料在 tr 裡面。
按鈕文字是「查詢」。
欄位外層有某個區塊標題。
這些資訊對 AI 很有幫助，AI 不是神，它需要線索。[拍桌]
八、可以直接這樣問 AI
如果真的不知道怎麼問，可以用下面這種格式：
提示詞範例一：檢查欄位漏填
我想做一個 Bookmarklet，用在目前瀏覽器頁面，需求是檢查表單中指定欄位是否有填寫。
欄位名稱包含： 【問題描述、處理狀況、備註、事項緣由】
請幫我寫 JavaScript Bookmarklet。
需求限制：
1. 只檢查目前頁面，不要連線到外部網站。
2. 不要自動送出表單。
3. 不要修改欄位內容。
4. 如果欄位有空值，請在畫面上跳出提示。
5. 如果同名欄位很多，請優先找畫面上可見、且旁邊或下方有 input、textarea、select 的欄位。
6. 請排除隱藏欄位，以及標題包含「舊」的欄位。
7. 請提供可以放進書籤網址列的 版本。
提示詞範例二：統計表格資料
我想做一個 Bookmarklet，用在目前網頁的查詢結果列表。
表格欄位包含： 【編號、產品名稱、狀態、最後更新時間】
需求是：
1. 統計目前畫面上各狀態的數量。
2. 找出最後更新時間超過 30 天的資料。
3. 在畫面右上角產生一個浮動視窗顯示統計結果。
4. 點擊統計數字時，可以展開明細。
5. 不要連線外部網站。
6. 不要修改原始資料。
7. 不要自動點擊任何送出或刪除按鈕。
提示詞範例三：讓 AI 協助判斷 HTML 結構
我正在嘗試寫 Bookmarklet，但目前抓不到欄位，下面是我用瀏覽器檢查工具複製到的 HTML 片段。
請你幫我判斷：
1. 哪一段是欄位標題。
2. 哪一段是真正的輸入框。
3. 是否有重複欄位或隱藏欄位。
4. Bookmarklet 應該用什麼方式比較穩定地找到它。
5. 不要只依賴容易變動的 class 名稱。
6. 請用白話解釋，不要只給我程式碼。
這種問法就比「幫我寫一個 Bookmarklet」好很多，因為你不是只丟需求給 AI。
你是在引導 AI 幫你一起分析網頁結構。
九、我的實務看法：真正困難的不是寫程式，而是描述清楚需求
以前我會覺得，Bookmarklet 最難的地方是寫 JavaScript。(因為根本看不懂
)但後來我發現，AI 普及之後，寫程式反而不是最難的部分。
真正困難的是：你能不能把你的需求具象化並描述清楚。
例如：
你要抓哪個資料？
資料在哪個頁面？
是列表頁還是詳細頁？
是畫面文字還是輸入欄位？
有沒有同名欄位？
有沒有隱藏欄位？
要不要自動送出？
要不要修改資料？
資料能不能匯出？
可不可以連外？
這些問題如果沒有先想清楚，AI 寫出來的東西很容易偏掉。
而且不是 AI 故意寫錯，是因為需求本來就不夠明確。
這也是我覺得，一般使用者現在最應該學的，不一定是完整的 JavaScript 語法。
而是：
學會看懂一點點網頁結構。
學會把自己的需求講成 AI 能理解的規格。
這兩件事加起來，就已經能做出很多實用的小工具。
十、不是所有網頁都適合 Bookmarklet
這篇雖然是在介紹如何看網頁結構，但我還是想提醒：
Bookmarklet 不是每個網站都適合。
如果你觀察一個網頁，發現它有以下狀況，就要先保守一點：
- 資料在 iframe 裡
- 畫面要等很久才載入
- 欄位名稱大量重複
- 網站常常改版
- 資料涉及高度敏感個資
- 操作會影響正式資料
- 公司規範不允許自行執行程式碼
這些情況不是完全不能做，但就不適合用太草率的方式做。
尤其是會修改資料、送出資料、刪除資料的工具，更要非常小心。
我自己比較建議，初學 Bookmarklet 可以先從這幾種開始：
- 只讀取畫面資料
- 只顯示統計結果
- 只標示異常欄位
- 只協助複製或整理資料
- 不自動送出
- 不連線外部網站
先從低風險的工具開始，會比較安全。
等你慢慢熟悉 HTML 結構、DOM、欄位定位後，再考慮更進一步的自動化。
十一、為什麼我覺得一般人也該懂一點 HTML 結構？
很多人可能會想：我又不是工程師，為什麼要看 HTML？
我以前也會這樣想，但現在我的看法有點改變。
因為 AI 已經讓寫小工具的門檻降低很多，以前你不懂程式，就很難開始。
現在你不一定要完全會寫，但你要知道怎麼問。
而要問得好，就需要知道一些基本概念。
不用很深，但至少要知道：
- 網頁不是只有畫面，背後有 HTML 結構
- Bookmarklet 是依照網頁結構找資料
- 畫面上的文字不一定等於真正欄位
- 同名欄位可能會讓程式抓錯
- 網站改版可能會讓原本工具失效
- AI 需要你提供更清楚的線索
這些觀念其實就夠了。
你不需要馬上變成前端工程師，但你會從「完全不知道怎麼問」變成「知道該提供什麼資訊」。
這個差異很大。
因為很多小工具不是做不出來，而是需求一開始就沒講清楚。
你只說：幫我抓這頁資料。
AI 可能會猜錯。
但你說：
幫我抓目前表格中欄名為「編號」、「狀態」、「最後更新時間」的欄位，只讀取目前畫面資料，不要連外，不要修改資料，並在右上角顯示統計結果。
這樣成功率就差很多。
十二、我的看法
如果上一篇是想讓大家知道： Bookmarklet 是一種被低估的小工具。
那這一篇我更想表達的是：
Bookmarklet 能不能好用，很大一部分取決於你是否理解網頁是有結構的。
很多人以為 AI 時代到了，只要丟一句話，AI 就會自動產出完美工具。
但實際用下來，我覺得不是這樣，AI 的確可以幫忙寫程式，也可以大幅降低技術門檻。
AI 可以幫你寫出工具，但工具能不能貼近需求，關鍵往往不是 AI 多厲害，而是你有沒有把自己的問題說清楚。
真正關鍵的是，你要先清楚知道：
你要解決什麼問題
你要抓哪裡的資料
你希望它怎麼判斷
哪些事情不能做
哪些資料不能碰
哪些操作不能自動執行
這些才是最重要的。
AI 很好用，但如果你讓它掌握你完全不了解的東西，你也會失去判斷風險的能力。
這句話我覺得放在 Bookmarklet 上特別重要。
因為 Bookmarklet 不是單純產生一段文字，也不是只幫你整理想法。
它是真的會在目前的網頁上執行程式。
它可能讀取畫面上的資料，也可能修改欄位內容，甚至如果程式裡面有不該出現的連線語法，還可能把資料送到外部網站。
所以我覺得，AI 時代不是什麼都不用懂。
而是不用每個人都變成工程師，但至少要知道自己正在讓 AI 幫你做什麼。
而 HTML、DOM、CSS Selector 這些東西，對一般人來說，不需要學到很專業。
但只要懂一點點，就能讓你跟 AI 溝通時更精準。
也能讓你更快判斷：這個 Bookmarklet 是不是因為網站改版失效？
是不是抓錯欄位？
是不是畫面還沒載入完成？
是不是欄位其實藏在其他結構裡？
我自己現在看 Bookmarklet，已經不會把它當成單純的「小程式」。
我更覺得它像是一種把日常工作流程拆解後，快速做出改善的方式。
很多工作上的小痛點，其實不需要等到正式系統開發，也不一定要花很多錢買工具。
如果需求夠小、夠明確、風險可控，有時候一個 Bookmarklet 就可以先解決 60 分、70 分的問題，這就很有價值了。
因為工作中真正讓人疲乏的，很多時候不是大問題，而是那些每天都要做、每次都差不多、但又不能不做的小事情。
如果能把這些事情稍微自動化一點，長期下來真的會差很多。
最後也一樣補充，這篇不是要把 HTML 或 DOM 講成完整教學。
真正前端工程師一定有更專業、更完整的說明。
我這邊比較像是從實際使用 Bookmarklet 的角度，整理出一般人需要先知道的觀念。
因為我覺得，對多數人來說，第一步不是學完整套前端技術。
而是先知道：
原來網頁不是只有眼睛看到的畫面。
原來小工具會失效，很多時候是因為背後結構變了。
原來問 AI 寫工具，也要把欄位、頁面、限制條件講清楚。
只要理解這幾件事，就已經比完全盲目複製貼上安全很多，也實用很多。
下一篇預告
如果這篇是在講：「為什麼要看懂網頁 HTML 結構。」
那下一篇我想更進一步分享：「如何把一個工作上的小痛點，整理成 AI 看得懂的 Bookmarklet 需求？」
因為很多人其實不是沒有想法。
而是不知道怎麼把自己的想法，整理成 AI 能理解、也能實際產出工具的需求描述。
但我後來覺得，問 AI 做工具時，最重要的其實不是一開始就想「程式要怎麼寫」。
而是要先想清楚：我最後想看到什麼結果？
例如：
我想看到哪些資料被標示出來？
我想看到哪些異常被提醒？
我想看到統計結果長什麼樣子？
我想點一下後，畫面要出現什麼？
我想節省哪一段人工操作？
我不希望工具碰到哪些資料？
因為你要的結果越清楚，AI 才越有辦法反推中間需要做哪些事情。
反過來說，如果一開始只說「幫我做一個 Bookmarklet」，但沒有說清楚最後想得到什麼結果，AI 就很容易寫出一個看起來有功能，但實際上不符合你工作流程的小工具。
所以下一篇會比較偏實務拆解。
我會從一個日常工作中的小困擾開始，一步一步拆解：
從「我覺得這件事很麻煩」
到「我最後想看到什麼結果」
再到「這個結果需要哪些資料與判斷」
最後整理成可以直接拿去問 AI 的需求描述。
也就是先把結果想清楚，再讓 AI 協助把過程做出來。
