主要是因為這篇剛好可以接著前兩篇往下看：
第一篇聊的是 Bookmarklet 是什麼。
第二篇聊的是 為什麼要稍微看懂一點網頁 HTML 結構。
如果說第一篇是在認識工具，第二篇是在理解網頁背後的結構。
那這一篇，我想更進一步聊一件我覺得更實際的事情：
「如何把一個網頁上的工作小痛點，整理成 AI 看得懂的 Bookmarklet 需求？」
至於最後一篇收尾文，就請大家再耐心等候一下
也先說明一下，這幾篇 Bookmarklet 分享，定位比較像是我自己的使用心得與效率工具思維整理。
不是專業前端教學，也不是要把 Bookmarklet 講成什麼一定要學會的技術。
所以這篇裡提到的範例，也只是提供大家一個思考方向，不是要大家看完後，馬上照著做出一個一模一樣的工具。
我比較想分享的是：
在 AI 工具越來越普及的現在，一般人可以怎麼觀察自己的工作流程，找出那些重複、瑣碎、但很耗時間的網頁操作，並思考有沒有機會用小工具簡化。
所以這篇的重點不是「教大家寫程式」。
而是：先學會把問題講清楚。
因為每個人的工作內容、操作流程、常用網站、困擾點都不一樣。
有些人每天要確認表單有沒有漏填。
有些人每天要看待處理清單。
有些人每週要整理狀態分布。
有些人每個月要統計某些資料數量。
每個人真正卡住的地方都不一樣。
所以在真的開始做工具之前，我反而會建議先不要急。
可以先用一個禮拜觀察看看：自己每天或每週，到底有哪些事情是在網頁上反覆操作、反覆確認，並且一直消耗時間。
例如：
每次都要人工檢查。
每次都要一筆一筆數。
每次都要複製貼上。
每次都怕漏掉資料。
每次都要花時間確認狀態。
每次都要把畫面上的資料再整理一次。
這些才是我們真正要找的東西。
因為我們要追求的不是「為了做工具而做工具」。
而是：真的能節省時間、降低重複操作、減少出錯機率，這樣的小工具才有價值。
如果一個工具做出來之後，反而需要花更多時間維護、檢查、調整，那就不一定值得做。
所以這一篇想分享的，其實不是某一個固定範例。
而是一種思考方式：先觀察痛點 → 再確認想要的結果 → 最後才讓 AI 協助把過程做出來。
一、我以前也會直接問 AI：幫我寫一個工具
一開始接觸 AI 寫小工具時，我也很直覺。
看到一個每天都要處理的網頁，就會想：這個應該可以自動化吧？
然後就很直接地問 AI：幫我寫一個 Bookmarklet。
幫我統計這個網頁。
幫我抓這頁資料。
幫我做一個自動化工具。
看起來很合理，對吧？
但實際用下來才發現，這樣問常常會出問題。
AI 可能真的寫出一段程式，也可能看起來很厲害。
甚至執行後也真的跳出一些結果。
可是用起來就是怪怪的。
不是少抓資料，就是抓錯欄位。
不是顯示的結果不符合需求，就是工具做了一些我其實不需要它做的事情。
後來我才慢慢發現，不一定是 AI 完全寫錯。
而是我一開始就沒有把需求講清楚。
我只跟 AI 說： 幫我做一個工具。
但我沒有說清楚：
我要解決什麼問題？
我最後想看到什麼結果？
我要統計哪些資料？
哪些資料不該碰？
哪些事情不能自動做？
結果要怎麼呈現才方便我判斷？
這些才是真正重要的地方。
所以我現在比較不會一開始就問 AI：「幫我寫程式。」
我會先問自己：我最後到底想看到什麼結果？
因為結果越清楚，AI 才越有辦法反推中間需要做哪些事情。
如果連自己想要的結果都還不清楚，那 AI 寫得再快，也很容易變成：
看起來有功能，但其實不好用。
二、真正值得做的，通常是工作中那些每天都在消耗時間與注意力的事情
我覺得 Bookmarklet 最適合的情境，不是那種很大型、很正式、很複雜的系統需求。
也不是要拿來取代完整產品。
它比較適合處理一種很尷尬的狀況：人工做很煩，但正式開發又太小題大作。
例如工作上常見的情境：
- 每天都要檢查某些欄位有沒有漏填
- 每天都要看待處理清單有多少筆
- 每天都要確認哪些資料已經逾期
- 每週都要統計不同狀態各有幾筆
- 每次開會前都要整理畫面上的數字
- 每次都要從網頁複製資料到其他地方
- 每次都要找出哪些項目需要優先處理
這些事情不一定難，但它們很消耗精神。
因為它通常不是做一次就結束。
今天要看。
明天也要看。
下週還是要看。
而且越是重複的事情，越容易因為疲乏而漏掉。
這也是我覺得 Bookmarklet 有價值的地方。
它不是要幫你取代判斷，而是先幫你把畫面上的資料整理成比較容易判斷的狀態。
例如：
原本你要一筆一筆看，它幫你先統計數量。
原本你要自己找異常，它幫你先標示出來。
原本你要人工複製整理，它幫你先產生可複製的文字。
這樣你省下來的，不只是時間。
還有那些反覆確認、怕漏掉、一直重看的精神消耗。
三、用一個工作情境來拆：待處理清單與異常狀態統計
這邊我用一個比較常見、但不綁定特定產業的工作情境來舉例。
很多人的工作其實都會遇到類似畫面：
一個列表有很多筆資料。
每一筆都有狀態、日期、負責人、類型、備註或處理進度。
它可能是：
- 待處理事項清單
- 線上表單填寫紀錄
- 專案任務列表
- 系統申請紀錄
- 異常項目追蹤表
- 內部流程進度清單
這些頁面本身不一定複雜，但每天看、每天確認、每天統計，就會變得很疲乏。(我自己就是如此)
假設你每天早上打開一個待處理清單，畫面上有 50 筆資料。
你要先看目前總共有幾筆待處理。
再看哪些已經處理中。
再看哪些已完成。
再看哪些很久沒有更新。
再看哪些欄位沒有填完整。
最後心裡還要大概整理出：今天哪些東西要優先注意？
如果是人工做，就是從第一筆開始看。
看完一筆，心裡記一下。
再看下一筆。
看到一半可能有人找你。
回來又忘記剛剛看到哪裡。
最後只好重新看一次。
這種事情很常見。
而且它很討厭的地方是：它不是什麼高難度工作。
但它會一直消耗你的時間和注意力。
這時候 Bookmarklet 可以做的，不是幫你自動處理資料，也不是幫你亂按送出。
更不是幫你取代專業判斷。
而是很單純地：只讀取目前畫面上的列表，幫你整理出一個統計結果。
例如點一下書籤後，畫面右上角出現一個小視窗：
- 目前畫面資料：48 筆
- 待處理：16 筆
- 處理中：20 筆
- 已完成：12 筆
- 超過 7 天未更新：5 筆
- 欄位缺漏：3 筆
然後再把「超過 7 天未更新」或「欄位缺漏」的項目，用淡色標示出來。
這樣你就不用每次都從頭看到尾，也不用每次都人工數數量。
更重要的是，它可以降低漏看的機率。
這才是我覺得 Bookmarklet 比較有價值的地方，不是拿來炫技。
也不是為了做工具而做工具，而是它真的可以幫你節省某些每天重複發生的檢查時間。
但注意，這裡的重點不是「叫 AI 寫程式」。
而是你已經先想清楚：我最後想看到的是一個能協助判斷優先順序的統計結果。
這樣 AI 才知道它要做的不是亂抓資料，而是協助你把原本需要人工檢查的內容，整理成更容易判斷的資訊。
四、把需求拆成五個問題，AI 才比較聽得懂
我自己現在會用一個很簡單的方式整理需求。
不是一開始就想程式，而是先問自己五個問題。
1. 我最後想看到什麼結果？
這是最重要的。
例如：
我想看到一個浮動視窗，顯示目前頁面的狀態統計。
我想看到哪些項目被標示出來。
我想看到可以複製的統計文字。
我想看到目前畫面有多少筆資料。
我想看到哪些資料可能需要再確認。
這一步是結果，不要一開始就想程式。
先想結果。
2. 這個結果需要哪些資料？
例如工作待處理清單統計可能需要：
- 資料建立日期
- 最後更新時間
- 目前狀態
- 項目類型
- 負責人或處理人員
- 是否有必填欄位缺漏
但不一定需要：
- 完整個人資料
- 聯絡方式
- 身分證字號
- 地址
- 帳號密碼
- 與統計無關的敏感內容
這一點很重要，因為不是畫面上所有資料都應該被讀取。
你要先想清楚：哪些資料是完成統計必要的，哪些資料不該碰。
3. 我要用什麼規則判斷？
例如：
- 狀態等於「待處理」就歸類為待處理
- 狀態等於「處理中」就歸類為處理中
- 最後更新時間距離今天超過 7 天，且狀態仍不是已完成，就列入需要確認
- 指定欄位是空白，就列入欄位缺漏
- 只統計目前畫面上看得到的資料
這些就是規則。
很多人問 AI 時會忘記講規則，但規則才是工具好不好用的關鍵。
因為同樣是「異常」，每個人的定義可能不同。
有人覺得 3 天沒更新就要注意。
有人覺得 7 天才算。
有人只想看未完成。
有人想看全部。
所以不能只說：幫我找異常。
而是要說：什麼情況才叫異常。
4. 結果要怎麼顯示？
Bookmarklet 的結果不一定只能跳 alert，有時候可以設計得更好用。
例如：
- 在右上角顯示浮動統計視窗
- 把異常資料用顏色標示
- 產生一段可以複製的文字
- 產生簡單表格
- 提供「複製結果」按鈕
- 提供「關閉視窗」按鈕
這個也要先說，因為如果你沒說，AI 可能會用最簡單的 alert 跳出結果。
但 alert 很快就不夠用，資料一多，閱讀性會很差。
所以我現在會直接告訴 AI：請用浮動視窗顯示統計結果，不要只用 alert。
5. 哪些事情不能做？
這個是安全邊界，一定要講。
例如：
- 不要自動送出表單
- 不要刪除任何資料
- 不要修改原始頁面資料
- 不要自動點擊確認、送出、取消、刪除按鈕
- 不要連線到外部網站
- 不要讀取帳號密碼或不必要的敏感資料
- 只處理目前頁面看得到的資料
這些限制越清楚越好，因為 Bookmarklet 本質上就是 JavaScript。
它可以做的事情很多，所以你要先劃清楚界線。
AI 很好用，但如果你讓它掌握你完全不了解的東西，你也會失去判斷風險的能力。
尤其是會在網頁上執行的工具，更不能完全不看內容就直接使用。
五、把模糊想法變成 AI 看得懂的需求
假設一開始你的想法只是：我覺得每天檢查待處理清單很麻煩。
這句話很真實，但 AI 不知道你到底麻煩在哪裡。
所以可以一步一步拆。
第一版：模糊想法
我覺得每天檢查待處理清單很麻煩。
第二版：說出痛點
我每天打開列表後，都要人工確認哪些項目還沒處理、哪些狀態停留太久、哪些欄位沒有填完整，最後還要自己整理目前大概有多少筆需要注意。
第三版：說出想要的結果
我希望點一下 Bookmarklet 後，可以在畫面右上角看到目前清單的狀態統計，並且把逾期未更新或欄位缺漏的資料標示出來。
第四版：說出需要資料與判斷規則
需要讀取目前頁面看得到的建立日期、最後更新時間、目前狀態、項目類型與必填欄位狀態。
如果最後更新時間距離今天超過 7 天，且狀態仍不是已完成，就列入需要確認。
如果指定欄位是空白，也列入欄位缺漏。
第五版：說出安全限制
不要自動送出表單。
不要修改任何欄位內容。
不要刪除資料。
不要點擊任何確認、送出、取消、刪除按鈕。
不要連線外部網站。
只讀取目前頁面看得到的資料。
你看，這樣整理後，需求就清楚很多。
而且 AI 也比較有機會寫出真正符合你需求的 Bookmarklet。
這個過程其實就是把腦中的模糊想法，整理成 AI 看得懂的規格。
我覺得這才是 AI 時代很重要的能力。
不是每個人都要會寫程式，而是要能把自己的問題說清楚。
六、可以直接這樣問 AI
下面我會把剛剛的例子整理成一段可以直接問 AI 的需求。
這裡先提醒，這只是示範格式。
實際使用時，還是要依照你自己的網頁畫面、欄位名稱、網站規範調整。
也不代表每個網站都適合這樣做。
如果網站本身有明確禁止自動化操作，或資料涉及高度敏感內容，就不建議使用。
提示詞範例：待處理清單統計 Bookmarklet
我想做一個 Bookmarklet，用在我目前瀏覽器打開的工作待處理清單頁面。
目的不是自動送出、修改或刪除資料，而是協助我統計目前畫面上的資料狀態。
我最後想看到的結果是：
1. 在畫面右上角產生一個浮動視窗。
2. 顯示目前頁面資料總筆數。
3. 依照狀態統計數量，例如：待處理、處理中、已完成、暫緩。
4. 找出最後更新時間距離今天超過 7 天，但狀態仍不是已完成的資料。
5. 找出指定欄位空白或缺漏的資料。
6. 將需要確認的資料在畫面上用淡色標示。
7. 提供一個「複製統計結果」按鈕，可以把統計內容複製成純文字。
需要讀取的資料包含：
建立日期、最後更新時間、目前狀態、項目類型、指定必填欄位是否有內容。
安全限制：
1. 只讀取目前頁面看得到的資料。
2. 不要自動點擊任何送出、確認、刪除、取消、儲存按鈕。
3. 不要修改任何欄位內容。
4. 不要連線到外部網站。
5. 不要讀取帳號密碼、完整個人資料或其他與統計無關的敏感內容。
6. 如果找不到表格或欄位，請顯示友善提示，不要直接報錯。
給 AI 的補充說明：
1. 請協助產生成可以放進書籤網址列使用的 Bookmarklet 版本。
2. 請盡量依照畫面上的欄位名稱、按鈕文字、表格標題來找資料，不要只依賴容易變動的 class 名稱。
3. 請先用白話說明這段工具會做什麼，再提供內容。
4. 請特別說明這個工具是否會連線到外部網站。
5. 如果有任何可能修改資料、自動送出或讀取不必要資料的地方，請主動提醒我。
這樣問，成功率通常會比「幫我寫一個 Bookmarklet」高很多。
因為你已經把結果、資料、規則、呈現方式、安全限制都講清楚了。
AI 比較像是在協助你把這些條件轉成程式，而不是自己亂猜你要什麼。
七、除了待處理清單，還有哪些工作網頁可以這樣想？
待處理清單只是其中一個例子，其實很多工作網頁，都可以用同樣方式思考。
1. 表單填寫頁
你可能想確認：
- 哪些必填欄位還沒填
- 哪些欄位格式可能不一致
- 哪些地方常常被漏掉
- 送出前是否可以先提醒
這種情境的重點不是自動送出，而是協助檢查，降低漏填機率。
2. 任務列表頁
你可能想知道：
- 目前待處理幾件
- 處理中幾件
- 已完成幾件
- 哪些任務停留太久
- 哪些類型最近比較多
如果網站本身沒有提供統計，Bookmarklet 就可能幫你做一個簡單補強。
3. 異常追蹤頁
你可能想知道：
- 不同異常類型各有幾筆
- 哪些異常已經超過指定天數
- 哪些項目尚未更新
- 哪些狀態需要優先確認
這種頁面很適合做「畫面上的快速統計」，但也要注意，不要讀取不必要的敏感內容。
4. 申請紀錄頁
你可能想知道：
- 待審核幾件
- 已通過幾件
- 退回幾件
- 哪些申請卡在某個狀態太久
如果每天都要人工確認，時間久了其實很耗神。
5. 文件或資料清單頁
你可能想知道：
- 哪些文件未分類
- 哪些資料沒有更新日期
- 哪些項目缺附件
- 哪些項目超過一段時間沒有維護
這類情境也很適合用來思考：能不能先做一個只讀取、只統計、只標示的輔助工具。
重點不是哪一種網站一定可以做，而是你可以用同一個思考方式去判斷：
我想看到什麼結果？這個結果需要哪些資料？哪些事情不能做？
這三件事想清楚，就已經成功一半了。
八、不要一開始就追求完美，先做 60 分的小工具
很多人一開始想做工具，很容易想得太大。
例如：
我希望它可以自動整理全部資料。
我希望它可以跨頁統計。
我希望它可以自動匯出 Excel。
我希望它可以記錄歷史資料。
我希望它可以自動提醒我。
這些不是不能做，但一開始就想太多，很容易做不出來，也更容易有風險。
我會比較建議，第一次做 Bookmarklet 時，先把需求縮小。
例如：
只統計目前畫面。
只顯示結果。
只標示異常。
只複製文字。
不要自動送出。
不要連線外部網站。
這樣比較容易成功，也比較容易確認有沒有問題。
工具不用一開始就 100 分。
如果它能先幫你省下 5 分鐘，減少一點人工檢查，其實就已經有價值了。
之後真的常用，再慢慢優化。
這也是我覺得 Bookmarklet 最適合的定位：
不是一開始就做成大系統，而是先做一個小而明確的效率工具。
九、AI 產生後，不要急著直接使用
當 AI 幫你產生 Bookmarklet 後，不代表就可以馬上貼到書籤裡執行。
尤其 Bookmarklet 是會在目前網頁上執行的小工具。
所以我覺得至少要先停一下，確認幾件事：
- 它是不是只做我原本要它做的事情？
- 它有沒有可能讀取不必要的資料？
- 它有沒有可能把資料送到外部網站？
- 它有沒有自動送出、刪除、確認或修改內容？
- 它產生的結果，有沒有先跟人工檢查結果比對過？
這一段我先點到為止，因為這其實又是另一個很重要的主題。
下一篇我會用比較白話的方式，整理自己在使用 AI 產生的小工具前，會先注意哪些地方。
不是要大家看懂完整程式。
而是至少知道：執行前要先確認它是不是只做你原本想讓它做的事。
十、我的看法
使用 Bookmarklet 一段時間後，我越來越覺得：真正重要的不是「我會不會寫 JavaScript」。
而是：我能不能把自己的需求說清楚。
AI 可以幫忙寫程式。
但它不能替你決定什麼結果才是你真正需要的。
它也不會自動知道哪些資料對你來說很敏感。
更不會知道哪些操作在你的情境下絕對不能碰。
所以我覺得，AI 時代反而更需要一種能力：
先定義結果，再讓 AI 協助完成過程。
這跟過去學程式的邏輯有點不同。
以前可能是先學語法，再慢慢想可以做什麼。
但現在對一般使用者來說，更實際的方式可能是：
先找到自己的痛點。
再描述自己想看到的結果。
接著整理需要哪些資料。
再補上判斷規則與安全限制。
最後才請 AI 協助產生工具。
這樣做出來的東西，才比較容易真的解決問題。
而不是只做出一段看起來很厲害，但實際上用不到的程式。
我自己會把 Bookmarklet 看成一種「把小痛點快速變成小工具」的方法。
它不一定完美，也不一定適合所有網站。
更不適合拿來處理高風險或高敏感資料。
但如果需求夠小、結果夠明確、風險也能控制。
它確實可以幫我們省下很多重複操作的時間。
而這也是我覺得 AI + Bookmarklet 很有趣的地方。
AI 不是單純幫你變出工具。
而是當你能把問題描述清楚時，它可以幫你把原本模糊的想法，變成一個真的可以試用的小工具。
最後一樣補充，這篇不是要鼓勵大家到處亂執行 Bookmarklet。
也不是要大家把所有網頁都拿來自動化。
我的想法反而是：越方便的工具，越要清楚知道自己在做什麼。
尤其是 AI 現在可以很快產生程式碼，更不能因為方便就完全不檢查。
所以剛開始時，先從低風險、只讀取、只統計、只顯示結果的小工具開始。
慢慢理解自己的需求，也慢慢理解工具的邊界。
回到這幾篇文章的初衷，我其實不是想把 Bookmarklet 講成什麼很厲害、一定要學會的技術。
而是覺得，在 AI 時代，很多原本需要一點程式能力才做得到的小工具，現在一般使用者也有機會開始接觸。
但前提是：你要先知道自己想解決什麼問題，也要知道工具的邊界在哪裡。
這樣才比較能真正用得安心，也用得長久。
下一篇預告
如果這一篇是在講：「如何把想法整理成 AI 看得懂的 Bookmarklet 需求。」
那下一篇我想用一篇作為這個系列的小收尾：「AI 幫你寫出 Bookmarklet 後，真的可以直接用嗎？」
因為 Bookmarklet 雖然方便，但它畢竟是在目前網頁上執行的小工具。
我覺得一般使用者不一定需要看懂完整程式，也不需要把自己變成工程師。
但至少可以先養成幾個基本觀念：
它是不是只做我原本要它做的事？
它有沒有可能讀取不必要的資料？
它有沒有可能把資料送出去？
它有沒有自動送出、刪除、確認或修改內容？
它產生的結果，有沒有先跟人工檢查比對過？
下一篇不會是很硬的程式教學。
而是想用比較白話的方式，整理我自己在使用 AI 產生 Bookmarklet 時，會先注意的幾個地方。
也算是替這幾篇 Bookmarklet 分享做一個收尾。
