2026 Perplexity Comet 自動化卡在登入頁？開發者復現指南

你看到 Perplexity Comet 停在登入頁，或登入後沒有繼續操作。最快的排查方式是先確認畫面是否要求你授權或接手，再用非敏感測試帳號檢查登入狀態、頁面載入與關鍵互動；停住不等於網站不相容，先記下停點和瀏覽器提示，才有足夠線索分類。

適合需要重現 AI 瀏覽器登入態異常的前端工程師與 QA 工程師。
如果你負責產品驗收，也可以用這套流程釐清哪些敏感步驟必須交由使用者確認。

提醒：不要把真實密碼、驗證碼或可重用的登入憑證放進任務指令、截圖和測試紀錄。遇到驗證碼時，驗證的是使用者接手後的流程，不是嘗試讓代理繞過它。

最後更新於 2026 年 10 月 1 日；功能與權限說明核對自官方 Comet 使用說明及Comet 助手的使用者控制說明。本文未取得本站指定的真實 Mac 環境與脫敏復測紀錄，因此不提供本站實測結果，也不推定特定網站的支援範圍。

先建立公開頁面的對照基線

別一開始就從登入流程找原因。先選一個不需帳號的公開頁面，請助手讀取可見內容，再導向一般連結；這能幫你判斷任務描述、頁面讀取和普通導覽是否已經有問題。若公開頁面也停住，登入態就不是目前唯一值得追查的因素。

每次復測都固定記下瀏覽器版本、頁面 URL、任務指令、實際停點，以及畫面上是否出現要求授權、登入或使用者接手的提示。保留這份基線，之後只改動一個條件，否則即使結果不同，也很難確認原因來自帳號狀態、頁面變化還是指令調整。

Perplexity Comet 為甚麼停在網站登入頁？

先讀畫面提示，再判斷它是要求使用者登入或授權，還是工作流程真的沒有往下走。官方對助手的說明強調使用者仍可控制瀏覽器工作流程；因此，遇到接管提示時，應先按預期流程由測試者操作，再觀察助手能否在登入完成後續接，而不是立刻將停點定義為故障。官方控制說明可以作為產品行為的參考，但不能證明某個網站的登入流程必然受支援。

使用瀏覽器登入態測試時，將結果分成有效會話、已過期會話和未登入狀態，分開復測並記下每次的重新導向與提示。一次只更改一項條件，例如保持任務指令不變，只切換會話狀態；若同時換帳號、改指令又開新分頁，便無法得知是哪項變化影響結果。

測試帳號應只具備完成驗收所需的最低權限，個人資料使用虛構內容；若需要查看 Cookie 或相關瀏覽器資料，只記錄狀態變化和必要的脫敏資訊，不複製憑證。會話管理的安全指引提醒，工作階段識別資料必須受到保護；認證測試也應將登入狀態、錯誤處理和使用者提示一併納入，而非只看能否進入頁面。OWASP 工作階段管理指引與認證安全指引可供你設計這些檢查。

用測試帳號驗證登入後流程

先建立專用測試帳號，再將「登入完成」和「登入後任務」分成兩段驗收。由測試者親自完成需要輸入憑證的步驟，接著觀察助手是否看得到預期頁面、是否遇到新的授權提示，以及任務是否停在特定導覽或表單步驟。

若使用測試框架預先載入登入狀態，請將認證狀態檔當作敏感資料管理，不要提交到程式碼儲存庫或附在一般缺陷單中；相關瀏覽器測試文件也特別提醒，這類狀態可能包含足以冒用帳號的 Cookie 和標頭。登入狀態測試文件可協助你規劃隔離方式，但它不等於 Comet 的登入能力保證。

遇到登入驗證碼時，怎樣安全測試？

驗證碼出現時，記下它出現的頁面、觸發條件，以及助手有沒有明確要求使用者接手。不要把繞過驗證碼當成測試目標，也不要用真實帳號反覆觸發驗證，以免把風險控制誤判成頁面故障。

若你是網站開發者，應使用驗證服務提供的測試方式檢查自家整合，並確認測試環境和正式環境分開；不要把測試憑證拿來判定第三方瀏覽器能否通過正式驗證。驗證碼服務的自動化測試說明說明了測試用途的限制，而非同步載入文件則可協助你檢查驗證元件載入時機。對 QA 而言，合格的結果是能安全交還使用者、再確認後續流程，而不是代理自動完成驗證。

動態頁面無法操作時，從失敗步驟回查

SPA、延遲載入內容和彈窗都可能讓頁面狀態在任務執行期間改變。請具體記下任務在哪一步停止：目標元素尚未出現、出現後被遮擋、按下後畫面沒有更新，還是操作需要使用者先觸發。用脫敏截圖或前端事件紀錄確認當時的畫面，不要只留下「不能操作」這種無法重現的描述。

遇到新分頁或多標籤情況時，也要分別記錄目前頁面和目標頁面的 URL、登入狀態及切換時機。若相同任務在公開頁面可行、登入後頁面才停住，回頭檢查重新導向與授權提示；若不同會話狀態都在同一個動態互動失敗，則更值得檢查元素是否可見、頁面是否仍在載入，或流程是否設計了必須由人觸發的操作。

敏感步驟要驗收暫停與撤銷

提交表單、修改個人資料等操作，不應只以自動化是否完成作為驗收標準。先確認代理在需要確認的步驟能否停下並交還控制，再由測試者核對內容、決定是否提交，最後檢查是否有清晰的復原或撤銷路徑。

經驗做法：把「使用者是否看懂即將發生的變更」納入驗收紀錄。即使流程能自動走到提交頁，如果確認資訊不清楚或撤銷方式不可用，仍不能視為安全完成。

依條件決定下一步

• 若公開頁面讀取和一般導覽也失敗，先重現相同任務並檢查指令、頁面載入和瀏覽器提示；暫時不要把問題定性為登入故障。
• 若公開頁面正常，而登入頁要求登入、授權或人工接手，使用專用測試帳號完成該步驟，再比較登入前後的頁面狀態。
• 若只有過期或未登入狀態失敗，檢查重新導向、會話更新和新分頁行為；不要在紀錄中保存可重用的憑證。
• 若不同會話都停在同一個動態元素，回查元素是否出現、是否被遮擋，以及是否需要使用者先觸發；留下截圖或脫敏紀錄。
• 若流程涉及不可逆的提交或資料修改，就要求使用者確認並驗證撤銷路徑；無法安全交還控制時，回退到人工操作。

把每次復測寫成可重現的缺陷單

復測紀錄至少要能讓另一位測試者重做相同情境。可使用以下欄位，不必附上密碼、完整 Cookie 或其他認證資料：

• 環境：瀏覽器版本、作業系統、是否使用新分頁。
• 頁面前置條件：公開或登入後頁面、帳號狀態、是否有彈窗或延遲載入。
• 任務指令：原始文字及必要的前置操作。
• 停點與提示：最後成功步驟、實際停留頁面、畫面上的使用者提示。
• 證據：脫敏截圖或不含憑證的事件紀錄。
• 分類：權限要求、使用者接管、會話狀態、頁面狀態，或網站互動缺陷。

對同一流程重做時，每次只改一項條件；若結果不一致，先補齊前置狀態，再判斷是否屬於可重現缺陷。你也可以先查看遠端 Mac 網頁測試環境的使用方式，並透過支援中心確認環境與交付問題應如何處理。

如果你目前用個人電腦或共用測試機，常見限制是登入狀態容易互相污染、測試前置條件難以固定，以及截圖或紀錄可能混入真實資料；但若工作長期高負載，或必須直接連接實體周邊，購買自用 Mac 可能更合適。若你需要的是短期、隔離且可重複的瀏覽器測試環境，可評估租用 Mac，按專案建立專用測試流程；這能讓復測與日常使用分開，但仍不會替你繞過驗證碼或取代使用者確認。了解 ZavCloud Mac 租用方案後，再判斷是否適合你的測試週期與操作需求。