第 44 號願望：有人要一個會自己砍掉 igsh 的擴充功能

在 Instagram 按「分享並複製連結」，複製到的網址尾巴會多一串 igsh 參數。別人點進那條連結，平台會顯示這是由某個帳號分享的。想送出去的只有那則貼文，帳號卻跟著一起送了。

這段是 AI 願望池 第 44 號願望「網址無痕清理器」問題描述的第一段。願望池是大家把想要的作品丟進去、由人或 AI agent 認領去做的地方。這支願望 2026 年 8 月 28 日上午進池子，許願人是「すーさん。」。

他還寫了第二個痛點：utm_*、fbclid、gclid、spm 這些追蹤碼，把原本乾淨的網址撐得又長又亂。另外附了一句對現成品的評語：像 ClearURLs 那類大多針對歐美主流追蹤碼，Instagram 的 igsh、蝦皮的導購碼、PTT 和 Dcard 的追蹤參數支援速度慢，通常也不讓使用者自己寫規則。

9 月 4 日晚上，我請 agent 從池子裡挑一支有把握做完的，它挑了這一支，用我的 token 認領。我做的是東西交回來自己看對不對、什麼時候可以送審。程式碼、測試、商店素材都是 AI 產的。

池子在這裡：https://yazelin.github.io/wish-pool/。

動工前先查別人做過沒

先確認這東西是不是已經有人做了。

8 月 21 日，願望池 skill（給 agent 看的作業說明）裡「別重造輪子」那一句，被擴寫成動工前的市調步驟。規則要查四個地方：大廠或官方的內建功能、同類 app 與 SaaS、GitHub 上的既有 repo、願望自己引用的資料裡順帶提到的產品。

寫這條的理由也留在 skill 裡，來自第 37 號願望（台語即時字幕）：現成的每一個都做了旁邊那件事，線索整晚在眼前，沒有人回頭問一句是不是已經有人做了。

#44 查的是三個地方：ClearURLs 官方文件裡的相近工具整理、laststance/clean-url、newhouse/url-tracking-stripper。

• ClearURLs 那一圈：追蹤參數規則成熟，外掛生態也大。
• clean-url：本機清理、25 個以上的參數、Popup、右鍵複製都有了，README 的 roadmap 上還掛著自訂規則跟 whitelist。
• url-tracking-stripper：有 history change 選項，清理的做法是重新載入，也會跳過已知的轉址。

三個都在旁邊，但沒有一個同時給到這支願望列的組合：亞洲參數預設、自訂規則（精確、萬用、Regex 三種寫法）、JSON 或純文字的訂閱清單、SPA 不重新載入的 history.replaceState、白名單、右鍵複製，全部收在同一支擴充功能裡。

所以這一版補的是這個組合的落差。要講準一點：這不代表 URL 清理這件事沒有前例。

比較表寫進了 repo 的 docs/wish-44.md，公開貼回池子的認領句也照那張表寫。後面想接手或想比版本的人，不用重查一遍。

交回池子的第一版，狀態是本機載得起來

認領當晚，第一筆 commit 進 repo，20 個檔案、2,171 行，接著把 repo 當 answer 交回池子。

這個行數要配一句狀態才看得準。那時它做到的是：本機用開發人員模式載入得起來，9 支 Node 內建測試會過。docs/wish-44.md 的「尚未承諾的部分」第一條就寫著：尚未上架，目前以開發者模式載入。

未封裝載入時的初始化競速

有一個 bug，測試全過也看不到。

前一晚我問過一句：「我們有拿實際的chrome 驗證過功能嗎」。隔天凌晨那筆 commit 處理的是一個重複的 id（duplicate id）。

在 Google Chrome 151 用開發人員模式載入未封裝擴充（沒打包、直接從資料夾載入）的時候，service worker 的 onStartup 跟初始呼叫會同時去建「複製無痕連結」這個右鍵選單項目。兩邊都是先 removeAll() 再 create()，撞在一起，同一個 id 就被建兩次，chrome://extensions 上顯示錯誤。

改法是一把單一 promise 鎖：建選單的動作還在跑的時候，後來的呼叫接上同一個 promise，跑完再把鎖清掉。

要記的是它現形的條件。這個競速是在「載入未封裝擴充」那條路徑上撞出來的，前一晚那 9 支單元測試全過，從測試裡看不到它。

測試改走使用者那條路：737 行端到端測試

這支測試照使用者的方式載入擴充功能。

同一個凌晨，我問了一句「你可以做e2e嗎」，接著加了一支用真的 Google Chrome 跑的端到端測試 tests/e2e/chrome.e2e.test.mjs。它有 737 行，比 repo 裡任何一個擴充功能檔案都長（擴充功能本體裡最長的 shared/cleaner.js 是 374 行）。

它不用 --load-extension，因為 Chrome 目前對命令列載入有限制。它開一顆乾淨的瀏覽器，進 chrome://extensions、把開發人員模式切開、按「載入未封裝項目」，連檔案選擇器都接了一個測試用的 portal mock（filechooser-portal-mock）。

載進去之後，測初始網址清理、SPA 的 pushState、設定頁的自訂規則與訂閱規則、全域暫停、白名單，還有 Ctrl+Shift+Y 複製到剪貼簿。

商店要的 1280x800 產品截圖，是四個多小時後準備上架那筆 commit 在這支測試裡另外補的函式 captureStoreScreenshot 截的。它讀 STORE_SCREENSHOT_DIR，有設就在測試跑到設定頁時把那一格畫面存成檔，沒有另外排版畫一張。

送審那天並列了三條做不到

9 月 5 日凌晨加了產品介紹頁，上午打包、把圖示尺寸對齊商店規格，11 點 49 分送出 Chrome Web Store 審查。寫這篇的時候排隊還沒有結果。

貼回池子的那則進度紀錄，不只寫做到什麼。同一則裡用「誠實限制」的名義並列了三條：

1. 審查尚未完成。
2. 網址整理發生在頁面載入之後。網站在初始請求裡可能已經收到那串原始 URL，history.replaceState 撤不回來。所以它改善的是分享、複製、網址列曝光這一段，不能拿來當網路層的防追蹤工具。
3. chrome://、edge:// 這類特殊頁面不能注入 content script，這些頁面不會被假裝成已經清理成功。

第二條值得多講一句。願望的期望欄第一項寫的是「即時網址列偵測與無感清理」，字面上做得到，可是做到的範圍比讀起來小一圈。這種落差不寫進公開紀錄，使用者會把它用在錯的地方。

MVP 的邊界也寫在 docs/wish-44.md：手機 App、伺服器代理、AI 分析、短網址展開、全域剪貼簿攔截，全部在邊界外。

還有一條藏在預設值裡：未知參數一律保留。寧可留下幾個沒清到的追蹤碼，也不要把某個網站的登入或 SPA 狀態洗掉。內建規則現在 29 條，其中 6 條綁死網域才生效，蝦皮 4 條、PTT 和 Dcard 各 1 條。

同一則進度紀錄裡也寫了帳單：這一輪全程用 GPT 5.6 Luna Max，20 美元方案的帳號，大約 5% 的週用量。

回頭看，#44 跟願望池的瓶頸

願望池的 NEXT.md 上記著目前最大的瓶頸：8 個還沒成真的願望裡，5 個的規格缺口一項都沒人補。多數願望卡住的地方在規格，不在沒人會寫程式。

#44 被挑中的時候，規格狀態是 refining，規格欄位沒有一項填過，也沒有社群補充。許願人填的是兩個痛點、一段現成品侷限，和六條期望（自訂規則、訂閱清單、白名單這些子項都在裡面）。認領的 agent 照池子的規格收斂協定（agent 一輪一輪把規格補齊的流程）自己提交一輪，規格狀態到 ready、implementation_ready=true 才動工。這個 ready 是 agent 代為整理的，「桌面 Chromium MV3」「哪些功能列入 MVP」都是它的實作決策，提案人沒有確認過。

這支願望的 needs 欄位是空的，池子上的更新紀錄裡，也沒有一則是卡住回頭發問的。

現在能做什麼

寫到這裡是 9 月 5 日，商店那邊在排隊。repo 裡該做的範圍在那之前就做完了，clone 下來用開發人員模式載入就能跑：https://github.com/yazelin/url-no-trace。

工坊那頁列著還在等人接的願望：https://yazelin.github.io/wish-pool/board.html。

後記（2026-09-11）

9 月 11 日上午，池子上多了一則進度：通過審查，上架 Chrome Web Store，商店名稱「無痕清理器｜Clean Trail」：https://chromewebstore.google.com/detail/goahbbfmfjfmlkngodpocghpjofjbolf。願望 #44 的狀態同時轉成成真。

上面那三條做不到，沒有因為上架改變。第二條還算數：網址整理發生在頁面載入之後，它管的是分享跟複製那一段，管不到網路層。