從手機引導 Bug 修復到驗收：以圖片連結案例為例

在 Tactic Remote 的文章中，螢幕截圖能正常顯示，但點擊用於開啟原始圖片的連結時，卻被重寫成了頁面 URL。在中文文章中，這意味著共用圖片位址被加上了 /zh-CN/ 前綴。圖片本身是存在的，只是連結出錯了。

這是非常適合從手機進行引導的任務規模：有明確的異常症狀、需要審查的變更範圍小，而且您可以親自驗證結果。它同時也揭示了 AI 輔助工作中常見的錯誤：在尚未驗證最初失敗的具體操作之前，就輕易接受了「已修復」的結論。

以下案例源自對本網站的一次真實修復。我們在該修復前後重新執行了實際的 URL 輔助函式（helper）。原先的程式修改與測試都在電腦上完成；下方的訊息是您可以透過 Tactic Remote 傳送的範例，並不是全程透過手機修復問題的對話紀錄。iPhone 螢幕截圖是迴歸檢查中使用的真實圖片資源。程式碼編輯與測試是在已連線的開發電腦上運行，而不是在 iOS 本機端運行。

1. 回報操作、預期結果與影響邊界

說「修復圖片」會留下太多詮釋空間。Agent 可能會替換正常運作的資源、重寫文章，或是修改整個語言路由。更好的開頭訊息應描述單一操作以及必須保持正常運作的部分：

在中文版 iPhone 指南中，螢幕截圖可以正常顯示，但開啟原始圖片時使用了錯誤的位址。請先重現該連結行為。共用圖片應使用既有的 /images/ URL 開啟；文章與文件連結則仍應遵循所選語言。在編輯程式碼之前，找出最小修復方案與迴歸檢查。不要改動文章文字與不相關的內容。

在發送之前，請選擇網站專案並確認對話的目錄與分支。若 Agent 提到了不同的儲存庫，請在它修改任何內容前予以糾正。iPhone 設定指南介紹了連線方式；本案例則是在主機與目標專案均可用之後開始。

本報告中有價值的區別在於：圖片能正常顯示，但連結被修改了。圖片元素載入的是其 src；點擊圖片則是跟隨外層連結的 href。如果只檢查前者，就會忽略後者。

2. 在套用修補程式前索取失敗範例

受影響的資源為：

/images/editorial/mobile-guides/iphone-chat-mode.png

舊版輔助函式將該檔案位址當作站內頁面的位址處理。其輸出為：

這兩個版本都應該原封不動地返回上述原始圖片位址。

英文版同樣受到影響：頁面標準化在末尾加上了斜線。帶有查詢字串（query string）與片段識別碼（fragment）的圖片位址也會遺失這些部分。該共用檔案需要完全跳過頁面在地化邏輯。

我們的本機 HTTP 檢查對未修改的檔案位址返回了 200, image/png。無效的 /zh-CN/images/...png 位址則返回了 404。這些請求是在本機候選版本上進行的；它們並不是歷史線上故障或受影響訪客數量的度量。

從手機發送的實用後續指示如下：

針對一個失敗案例，顯示輸入 URL、實際輸出與預期輸出。包含一個普通文件連結作為對照組。請勿單純為了讓測試通過而修改預期結果。

3. 審查修復範圍

正式版使用的輔助函式原本就不會改寫可下載範例的位址。此次修復將共用圖片加入同一個提早回傳（early return）的判斷中：

- if (href.startsWith('/examples/')) return href
+ if (href.startsWith('/examples/') || href.startsWith('/images/')) return href

頁面連結仍然使用現有的語言路由函式。這是刻意與本網站的兩個共用資源目錄繫結；這並非一條要求所有包含句點的 URL 都應繞過在地化的規則。

要求 Agent 在對話中顯示變更檔案清單與此 diff，然後在應用程式提供的檔案/變更檢視中審查實際修改。將畫面上顯示的分支和路徑與您選取的專案進行對比。如果回覆提議大幅重寫路由邏輯，請詢問為何針對此特定問題必須這麼做。

歷史上的修復是與文章及日期的改進一同提交（commit）的。連結修復本身就是上方那段簡短的條件；整個 commit 並非只有一行變更。在您自己的任務中，接受修補程式之前，請審查整個 diff，並將既有且不相關的工作分開考量。

4. 閱讀測試結果，而不僅是「passed」這個詞

針對此案例，我們在網站的八種語言中，分別檢查了六項預期結果：

這總共代表了 48 項檢查，其記錄結果如下：

這 16 個失敗案例是分布在八種語言中的兩項圖片相關預期。它們並非 16 篇損壞的文章、16 位使用者或 16 個獨立 Bug。通過的對照組至關重要：如果修補程式只是單純停止對所有連結進行在地化，雖然能修好圖片範例，但會破壞文件導覽功能。

下載可執行的重現範例，進行檢查並在您的開發電腦上運行：

node image-link-regression.mjs

它使用 Node 的內建斷言（assertion），在記憶體中執行，不會傳送網路請求或修改檔案。範例保留了修復前後的相關 URL 處理邏輯，並移除了 TypeScript 型別。其結果與另外針對儲存庫實際修訂版本執行檢查的結果相符。這是針對特定問題的重現範例，不能取代專案本身的建置或整合檢查。

透過手機要求 Agent 提供能對應到已審閱變更的證據：

回報確切的命令、目錄、分支或 commit、結束狀態碼以及失敗的斷言。請將已完成的檢查與僅僅建議的檢查分開。如果您在測試後編輯了修補程式，請在該版本上重新運行受影響的檢查。

在網站最初的修復中，儲存庫的 lint、正式版建置與 SEO 檢查也都順利通過。那些更廣泛的檢查涵蓋了不同層面；但它們本身都不能證明一般人確實可以在瀏覽器中開啟原始圖片。

5. 在本機預覽中重複使用者操作

現在回到暴露問題的文章中。確認內嵌圖片仍可載入，開啟原始圖片，確認它是一張圖片而非錯誤頁面，然後返回文章。同時也檢查一般文件連結。以英文和翻譯後的版本重複此操作，然後在狹窄的手機寬度下再次測試。

當預覽在電腦上運行時，請記住在實體 iPhone 上開啟 127.0.0.1 位址是指向手機本身。請使用專案既有的預覽存取路徑從其他裝置進行檢查。將桌面瀏覽器寬度調整為手機寬度可作為版面配置的參考，但並非實體 iPhone 的測試。

6. 在明確的停止點驗收成果

在本案例中，修復後的本機網站通過了檢查，並在本機預覽審查中獲得驗收。該驗收針對的是網站候選版本；它並未發布更新。它也不能證明歷史任務是完全從 iPhone 操作完成的。

對於類似任務，您的最後訊息可以具體明確：

我已在本機預覽中檢查了原始圖片與文件連結。請保留此修補程式及其迴歸檢查。摘要說明剩餘的限制，然後在發布或進行進一步修改前停止。

如果您尚未開啟預覽，請說明還剩下什麼：「輔助函式檢查通過；視覺驗收仍待處理。」Agent 的閒置狀態、全部通過的測試摘要，以及您對可見結果的驗收，解答的是不同的問題。

本案例中可重複使用的是這套流程：描述失敗的操作、保留對照案例、審閱最小且合理的變更、將檢查結果對應到該版本，並在決定下一步之前重做使用者的操作。您可以透過手機做這些決策，而讓開發電腦處理程式碼工作。若對話在此過程中停止回應，請在重新發送相同指示前，先參考連線與傳遞狀態疑難排解指南。