產品設計與原型驗證
決定 WebpageToPDF 的產品方向、首版範圍和 PDF 轉換方案。
這篇從市場調查開始，逐步決定產品範圍，再透過技術原型驗證實作方案。
市場調查
開發產品不能只憑一個模糊的想法就開始寫程式碼。至少要先弄清楚：誰會使用、在什麼情況下使用，以及現有產品還有哪些問題沒有解決。
從網域也能看出來，這次要做的是一款網頁轉 PDF 工具：使用者輸入網頁網址，由伺服器端完成轉換，再提供 PDF 檔案下載。
我先查看「webpage to pdf」這個關鍵字的搜尋結果。這個詞有一定搜尋量，但並不好經營。排在前三名的都是經營多年的大型網站，反向連結多，網域權重也高。新網站短期內幾乎沒有機會與它們競爭前三名，能先進入前十名就已經不錯了。
前十名包括 Reddit 貼文、兩款 Chrome 擴充功能、一款應用程式，以及三個線上轉換工具。這表示使用者搜尋「webpage to pdf」時，找的不一定只是線上工具，也可能更想使用瀏覽器擴充功能或桌面應用程式。
webtopdf
我分別試用了幾個排名靠前的產品。Webtopdf 提供的選項最豐富，整體使用體驗也不錯。
它的轉換結果基本上可用，而且似乎會主動處理 Cookie 同意彈出視窗之類的干擾元素。不過，產生的結果偶爾會變成行動裝置版面：
上圖右側的選單，預設不會出現在桌面版頁面中。可能是轉換時頁面尚未載入完成，剛好擷取到中間狀態。此外，部分頁面也會出現排版錯亂。
ilovepdf
iLovePDF 提供的轉換選項也相當完整。它有個實用功能：轉換前可以預覽目前頁面的效果。這個預覽比較像瀏覽器截圖，使用者只能查看，無法直接編輯頁面。
從轉換結果來看，iLovePDF 對原始網頁做的額外處理較少，基本上會依原樣產生 PDF，Cookie 同意彈出視窗等無關元素也可能一併保留。
web2pdfconvert
Web2pdfconvert 是這幾個產品中最讓我意外的一個。頁面簡潔，選項卻不少，還支援將檔案存到第三方雲端硬碟。更重要的是，它產生 PDF 的效果最穩定，也是這次測試中表現最好的。
它比較像 ConvertAPI 的線上展示頁面，頁尾也註明轉換功能由 ConvertAPI 提供。如果自行開發的效果不理想，直接在伺服器端串接它確實方便。不過商業授權不便宜，長期使用會明顯提高每次轉換的成本。
我也試了幾個排名較後面的產品，整體效果差異很大。比較後，可以得到三個有用的結論：
- 匯出的 PDF 幾乎都能選取文字，表示主流產品並不是先將網頁擷取成圖片，再放進 PDF。我最初考慮過這種做法，但它會失去文字選取、複製和搜尋能力，不適合作為主要實作方式。
- 很少有產品主打批次轉換，這可能是值得進一步驗證的方向。
- 紙張大小、橫向或直向、背景和邊界，已是常見功能，單靠增加這些選項很難做出差異。相較之下，轉換前的預覽，以及對結果的調整，更有機會改善實際體驗。
從商業角度看，網頁轉 PDF 並不是特別理想的方向。排名靠前的網站都已經營多年，網域歷史長、反向連結多、權重高，轉換效果也不錯，很難超越。更麻煩的是，這個關鍵字的範圍很窄，搜尋量並不大：
即使排到第一名，能取得的流量也有限。目前排名第一的網站，網域已有約 20 年歷史，每月瀏覽量也只有約 40 萬。
也就是說，這個方向既難做，流量上限又不高，不能期待它賺多少錢。不過，我做這個專案原本就不是為了獲利，而是想完整示範如何用 Saavo 開發並上線一款實際產品。網域已經買了，那就繼續，只是不要抱太高的期待。
我也將相關關鍵字匯出，交給 AI 分析了一次。它的判斷偏樂觀，我個人持保留態度。這些關鍵字的平均 DR 大約是 40～55，新網站上線後很難快速看到成效。
產品設計
實際的市場調查一定比上面更詳細、完整，這裡就不再展開。市場調查決定了是否要做這個產品，以及大致方向。如果市場競爭充分，而競爭對手的網站無論功能或設計都比你做得好，開發這個產品可能就沒有太大意義。
你需要考慮如何在競爭對手中脫穎而出。除了功能突破與完善，設計創新和使用者體驗的改善也很重要。這些網站無論經營時間或使用者基礎，可能都比你高出好幾個數量級，短期內很難在排名上超越，甚至可能連前十名都進不去。即使你的功能更強、設計更美觀、使用體驗更好，仍需要時間累積使用者和品牌影響力，這無法避免。
市場調查時就應考慮這些問題。如果功能還不如對手，或與它們差不多，基本上就可以放棄了。只有做得更好，才有機會在市場取得一席之地，也才值得進一步考慮產品設計。
產品設計的核心，其實就是決定產品要做什麼、如何實作，以及第一版應做到什麼程度。
在目前的 Google 搜尋結果中，Web2pdfconvert 的使用體驗明顯優於 Webtopdf，排名卻比較後面。原因肯定不只一個，但頁面內容多寡應該也有影響。Web2pdfconvert 的頁面太精簡，文字很少，搜尋引擎不容易判斷它提供哪些功能。Webtopdf 的介紹較完整，看起來也更專業，我的網站接下來可以參考這個方向設計。
網站初期只做一個首頁。上半部直接放轉換工具，讓使用者開啟就能使用。下半部再介紹產品功能、使用情境和常見問題，補足 SEO 需要的文字內容。配色盡量簡單，避免蓋過工具本身。版面則參考 ahrefs 的免費工具頁面。
搜尋結果中有兩款 Chrome 擴充功能，也表示部分使用者希望瀏覽網頁時就能順手轉換。日後可以考慮開發擴充功能，除了方便使用，也能替網站帶來流量。不過第一版先不做，避免一開始就把範圍拉得太大。
功能差異化方面，我更想從互動體驗著手。基本選項必須齊全，但真正值得投入的是即時預覽：調整紙張、方向或邊界後，使用者能立即看到大致效果，不必等檔案產生後再反覆重試。
再往後，還可以嘗試兩個方向。第一是加入 AI 對話，讓使用者以自然語言隱藏網頁元素、修改內容或調整版面。第二是支援批次轉換，滿足現有產品較少照顧到的需求。這兩項都需要先驗證，尤其要繼續研究批次轉換相關關鍵字，不能只因為競爭產品沒做，就認定一定有機會。
想法可以很多，但第一版必須控制範圍。WebpageToPDF 最核心的任務只有一個：使用者輸入公開網頁網址，選擇紙張和版面，再產生並下載 PDF。
第一版只完成這條完整流程：
輸入網址 → 設定 PDF → 提交工作 → 等待轉換 → 下載檔案首版只支援公開的 HTTP/HTTPS 網頁，以及 A4/Letter、橫向或直向、列印背景和邊界等基本選項。已登入的使用者可以查看自己的轉換記錄。
需要 Cookie 的私人頁面、Chrome 擴充功能、批次轉換、API、團隊空間、AI 調整和網頁編輯器，暫時都不做，先把最核心的功能做好。Chrome 擴充功能仍值得列入後續規劃，因為它能讀取使用者已登入的頁面，解決伺服器端無法存取會員內容的問題，但這不屬於首版範圍。
產品設計階段，可以和 AI 討論，請它提出幾款設計原型。這一步只產出設計稿，目標是確定核心 UI、互動流程和功能清單。不過這並非固定規則，我個人習慣在產品設計和技術原型探索之間反覆調整。
任何階段的劃分都不是一成不變的。有了新想法或改善方案時，都可以回到前面的階段調整。透過持續迭代，才能找到最適合自己的產品。你也可以在產品設計階段就決定所有功能，再直接進入技術原型探索，取決於個人習慣和偏好。
產品設計時，AI 幫我產生了幾個版本的 UI 設計稿。經過幾次調整，最後選定下圖的版本：
技術原型探索
正式實作產品前，我習慣先探索技術方案，避免開發時走冤枉路。網頁轉 PDF 的技術不複雜，常見做法有兩種：
-
將網頁截圖轉成 PDF
先擷取網頁畫面，再將圖片放入 PDF。優點是實作簡單，效果也不錯。缺點是失去文字選取、複製和搜尋能力，不適合作為主要實作方式。
-
直接透過瀏覽器產生 PDF
本質上就是用瀏覽器開啟目標網頁，再執行
page.pdf()，由瀏覽器自動產生 PDF 檔案。優點是效果最好，缺點是網頁結構各式各樣，直接轉成 PDF 可能出現版面或呈現問題。
網頁轉 PDF 的主要難點，不在最後產生 PDF，而在前面的網頁排版與呈現。PDF 對應傳統印刷品，網頁則天生採用流動式版面，兩者的排版方式差異很大。好的產品應事先處理網頁，例如隱藏首頁的同意彈出視窗、側邊選單或頁尾版權資訊。
不同網頁很難有統一的處理方式，因此我準備研究如何讓使用者決定要輸出哪部分內容，最好還能有良好的互動性。這也是我目前想與同類產品做出差異的主要方向。
一開始，我考慮兩個創新方向。第一是引入 AI，讓使用者透過對話決定輸出內容，例如輸入「請隱藏首頁的同意彈出視窗」「請隱藏側邊選單」「請隱藏頁尾版權資訊」。第二則是實作真正的遠端即時瀏覽器，讓使用者看到即時畫面，透過滑鼠互動，達到類似在本機進行 Web 偵錯的效果。
構想很好，但實際效果不理想。第一個方向，我試做了幾個原型，功能上可行，卻發現效益不大、成本不低。使用者真正需要的，未必是對話互動，而是當網頁出現廣告、彈出視窗或浮動視窗等干擾元素時，能自動隱藏，或替他們完成必要操作。大多數功能不需要 AI。並不是 AI 做不到，而是準確率不高、成本也不低，建立明確的規則庫可能更合理。
遠端即時瀏覽器方面，我發現確實已有不少產品，多數效果不錯，但那不是我想做的。我需要的是將網頁轉成 PDF，而不是讓使用者遠端偵錯網頁。Cloudflare 的 Browser Run 其實能實現類似功能，我做了一些原型測試，效果不理想，操作很卡，成本也不低，並不是很合理的方案。
不過，我最後仍改造了第二個方案，不直接使用遠端瀏覽器，而是以截圖實現即時預覽。對網頁轉 PDF 來說，這種方式更簡潔方便、成本更低，實作也不複雜。
經過原型驗證，我調整了最初的首版範圍：將 Visual Editor 納入首版，但仍不做 AI 調整、批次轉換和 API。截圖方式也保留下來，作為優先還原網頁外觀的快速模式。如果需要選取、複製或搜尋文字，則使用瀏覽器匯出方式。後續教學都以調整後的範圍為準，產品聚焦於三種核心模式：
- Quick Convert：以截圖快速產生 PDF。優點是外觀最接近原始網頁，缺點是 PDF 中的文字無法選取、複製或搜尋。
- Custom：採用傳統的瀏覽器匯出 PDF 方式，使用者可自行選擇紙張、方向、背景和邊界。優點是能選取、複製和搜尋文字，缺點是 PDF 的外觀可能與原始網頁不同。
- Visual Editor：以 Custom 模式為基礎的進階版本，保留其功能，並提供額外互動方式。使用者能隱藏指定網頁元素，或修改某些元素節點的預設樣式，讓匯出結果更有彈性，也更容易控制。
以上是我在實際開發與探索時的一些想法，並未詳細展開產品程式碼。不同產品的實作方式差異很大，而本系列主要介紹如何使用 Saavo 範本完成實際產品，個別業務程式碼不是重點。
尤其有了 AI 之後，技術原型探索就像是替 AI 準備的試驗場。你可以先讓 AI 自行實作產品功能，等原型通過驗收，再拆分程式碼，逐步移植到 Saavo 範本中。移植過程最好由人工把關。
一方面能趁機釐清整個產品邏輯，另一方面也能持續調整 AI 產生的程式碼。即使程式碼不夠好、邏輯較混亂，只要將修改範圍控制在單一函式或檔案內，日後發現問題仍容易定位與重構。重點是責任邊界要清楚。
本篇檢查
完成本篇後，應清楚了解三種轉換模式和各自的適用情境，並準備好要移植的原型。