前言
我們每天從網路擷取、學習各式各樣的內容──看 YouTube 學習相機設定、查除濕機原理、比較舒肥機哪台最好、追蹤 iOS 的新功能，或規劃日本自助行。問題是，多數影片與文章往往在沒有被紀錄的情況下，大多都是看過就忘，亦或是 30 分鐘的影片看完常常抓不到重點。
要解決這個問題可以透過 AI 摘要工具、主動筆記法和分段觀看策略來改善。先前曾分享過的文章 《透過 ChatGPT 進行 YouTube 影片分析與總結》能夠快速取得影片的文字稿、或是《使用 Faster Whisper 取得任何影片或音訊的原始字幕》能夠將純影片的內容轉換為文字稿。
後續交給大型語言模型（large language model，LLM），如 OpenAI ChatGPT、Google Gemini、Anthropic Claude 等工具做摘要、分類與重組；最後把結果儲存在 Notion 供應個人閱讀或私人分享。
當然直接轉成單頁網站（single-page site）可上線的網頁。本篇文章將說明如何進行一套完整的自動化工作流程，涵蓋運用 AI 進行內容統整、產生網頁原始碼，並最終藉由 GitHub Actions 實現網站的自動化部署。此流程能使不具備深厚程式設計背景的使用者得以獨立建置與發布網頁內容。並且快速進行網路文章的分享。
運用 LLM 進行內容統整或產生可靠性的內容
目前市場上上有許多 AI 工具可以協助內容統整與產生，如 ChatGPT、Gemini 等。這些工具支援多元化的輸入來源，包括：
- 完整文章內容
- YouTube 影片字幕
- PDF 文件檔案
- 網路搜尋統整結果
以我常用的搜尋統整結果為例子：
1. Perplexity
- 整合多個網頁來源進行綜合分析。
- 適合需要多角度資訊統整的研究需求。
- 提供來源引用與連結，便於回溯與驗證。
2. Gemini Deep Research
- 自動化網路資訊瀏覽與分析。
- 快速產生綜合性研究報告（數分鐘內完成）。
- 專門處理複雜的研究任務。
使用 LLM 產生符合設計規範的網頁
在取得有效內容後，下一階段是將其轉化為網頁。同樣地，我們可以透過向 LLM 下達具體的設計與技術指令來產生 HTML 程式碼。
以下是目前我常用的提示詞（Prompt）：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| 請以資深前端 UI/UX 設計師之專業角度，對以下採用 TailwindCSS 框架的 HTML 程式碼進行全面性美化。
🎨 視覺設計優化
色彩搭配：採用藍色系為主色調，並融合紫色與青色的漸層效果。
卡片設計：為各章節設計具備玻璃擬態效果與柔和陰影的卡片樣式。
✨ 互動體驗提升
關鍵字互動：為關鍵字添加 hover 效果、背景色變化及細微動畫。
進場動畫：設定各章節依序淡入，以增強視覺層次感。
📱 響應式設計優化
行動裝置體驗：針對行動裝置的瀏覽體驗進行優化，確保在小螢幕上的可讀性與操作便利性。
🔧 技術層面改進
TailwindCSS 實踐：最大化利用原生類別，以減少自定義 CSS 的需求。
效能優化：採用 `transform` 與 `opacity` 屬性執行動畫，以提升渲染效能。
|
我們想要做任何調整，都可以透過 LLM 進行上述提示詞內容的再微調，最終，可以產出不僅美觀且兼具效能與互動性的 index.html 檔案。
使用 GitHub Pages 部署靜態 HTML 網站
GitHub Pages 是一個非常方便的功能，可以讓我們直接從 GitHub 倉庫（Repository）託管靜態網站。這份教學將引導您如何將一個簡單的 HTML 檔案部署上線。
前置準備
在開始之前，請確保您已經：
- 擁有一個 GitHub 帳號。
- 在您的電腦上安裝了 Git。
- 對 Git 的基本操作有初步了解，例如
clone, add, commit, push。
若對 Git 不熟悉，可以參考以下文章：
上傳網頁
首先，在 GitHub 上建立一個新的公開倉庫，例如 single-page-conclusion。
假設我們有一個名為 Git 常見指令統整.html 的檔案。使用 Git 指令將本地的專案提交至專門的分支 gh-pages，並將該分支推送上去。
我們就可以在網址上 https://<您的使用者名稱>.github.io/<您的倉庫名稱>/Git 常見指令統整.html 看到該網頁內容。
使用 GitHub Actions 實現自動化部署
我們可能有些腳本或設定不希望公開，因此會先將原始碼存放在私人倉庫，再透過 Workflow 將最終產出的網頁檔案部署到公開倉庫。GitHub Actions 正是實現此自動化流程的關鍵，它能夠在我們提交程式碼至私有倉庫後，自動執行預設指令，將最終的網頁檔案發佈到公開的倉庫。
為了清楚說明，我們假設有以下兩個 GitHub 倉庫：
- 私人倉庫 (Private Repository):
single-page-conclusion-deploy- 存放所有原始碼、腳本 (
.sh) 與提示詞 (.txt)，這是我們主要的工作區。
- 公開倉庫 (Public Repository):
single-page-conclusion- 僅用於存放最終產生的靜態 HTML 檔案，並啟用 GitHub Pages 功能來發佈網站。
建立與使用個人存取權杖
要讓私有倉庫的 Actions 有權限自動推送到公開倉庫，我們必須建立一把「金鑰」來進行安全的認證。最常見的做法是使用個人存取權杖（personal access token，PAT）。
產生 PAT
您可以前往 GitHub 的 Personal Access Tokens 頁面，點擊 Generate new token，並選擇 Generate new token (classic) 來產生新的金鑰。
設定 Token Scope
在 Select scopes 中，務必勾選 repo、workflow 的所有權限。這將允許金鑰對您的倉庫進行讀取、寫入等操作。
儲存金鑰為 Secret
產生金鑰後，請立即複製它。它會是一長串以 ghp_ 開頭的字元，例如：
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
新增 Secret 至私人倉庫
前往私人倉庫 (single-page-conclusion-deploy)，進入 Settings > Secrets and variables > Actions，點擊 New repository secret。將金鑰命名為 GH_TOKEN 並貼上內容。
完成設定後，我們的 Workflow 就能透過 ${{ secrets.GH_TOKEN }} 安全地讀取這個金鑰，進而取得推送到公開倉庫的權限。
撰寫 Workflow 部署腳本
以我個人的目錄架構為例，以下檔案皆在我的私人倉庫中管理：
./提示詞.txt./update_rss.sh./update.sh./gh-pages/*.html
其中，前三項是我個人使用的腳本與資料，而真正需要部署上線的，只有 ./gh-pages/ 目錄下的靜態網頁檔案。
為了實現自動化部署，我們只需在專案根目錄下建立 ./.github/workflows/deploy.yml 檔案，並在其中貼上以下內容。需要注意的是腳本中的 <USER>/<PUBLIC_REPO_NAME> 替換成您自己的 GitHub 使用者名稱與公開倉庫的名稱。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
| # .github/workflows/deploy.yml
# name: 為此工作流程設定一個在 GitHub Actions 介面上顯示的名稱。
name: Deploy HTML to single-page-conclusion
# on: 定義觸發此工作流程的事件。
on:
# push: 當有 Git push 事件發生時觸發。
push:
# branches: 指定只有推送到特定分支時才會觸發。
branches:
# 當私有倉庫的 'main' 分支有任何更新推送時，此工作流程就會啟動。
- main
# jobs: 工作流程由一或多個「工作（Job）」組成，它們可以並行或依序執行。
jobs:
deploy:
# 指定此工作在最新的 Ubuntu 系統上運行
runs-on: ubuntu-latest
# steps: 「工作」是由一系列依序執行的「步驟（Step）」所組成。
steps:
# 步驟一：簽出（Checkout）私有倉庫的程式碼
- name: Checkout private repo
# uses: 使用 GitHub Marketplace 中預先寫好的 Action。
# actions/checkout@v3: 這是官方提供的 Action，功能是將觸發此流程的倉庫程式碼下載到 Runner 中。
uses: actions/checkout@v3
# with: 為使用的 Action 傳入特定參數。
with:
# fetch-depth: 0: 拉取完整的 Git 歷史紀錄。這在需要基於 Git 歷史進行操作時很有用。
fetch-depth: 0
# 步驟二：設定 Git 提交者資訊
- name: Setup Git
# run: 直接在 Runner 的 shell 環境中執行指令。
run: |
git config --global user.name "github-actions[bot]"
git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com"
# 步驟三：執行腳本以產生 README.md
- name: Generate README.md
run: |
chmod +x update.sh
./update.sh
# 步驟四：複製（Clone）公開的目標倉庫
- name: Clone public repo (single-page-conclusion)
run: |
# 透過金鑰，把公開倉庫複製到本地中的 public-repo 目錄。
# 這個金鑰需要預先在私有倉庫的 Settings > Secrets 中設定。
git clone --depth 1 https://x-access-token:${{ secrets.GH_TOKEN }}@github.com/<USER>/<PUBLIC_REPO_NAME>.git public-repo
# 進入剛剛 clone 下來的 'public-repo' 資料夾。
cd public-repo
# 以下指令確保不論遠端分支是否存在，都能順利切換，避免因分支不存在而導致 workflow 失敗。
# || true: 如果前面的指令失敗（例如遠端沒有 main 分支），則回傳成功狀態，讓 workflow 繼續執行。
git fetch origin main || true
git fetch origin gh-pages || true
# 嘗試切換到 main 分支，如果不存在，就建立一個新的 main 分支。
git checkout main || git checkout -b main
# 步驟五：同步檔案至公開倉庫的 main 分支（主要更新 README）
- name: Sync files to public repo main
run: |
cd public-repo
# 將上一步驟在私有倉庫根目錄產生的 README.md 複製到公開倉庫的資料夾中。
cp ../README.md .
# 將 README.md 加入 Git 的暫存區。
git add README.md
# 提交變更。如果沒有任何變更（檔案內容和上次一樣），commit 會失敗。
git commit -m "Update README.md" || echo "No changes"
# 將 commit 推送到公開倉庫的 main 分支。
git push origin main
# 步驟六：同步網站內容至公開倉庫的 gh-pages 分支（部署網站）
- name: Sync files to public repo gh-pages
run: |
cd public-repo
# 切換到 gh-pages 分支，這是 GitHub Pages 用來發布網站的預設分支。如果不存在則建立。
git checkout gh-pages || git checkout -b gh-pages
# --- 清理舊檔案 ---
# 為了確保部署的內容是最新的，先刪除上次部署的檔案。
# 這可以避免舊的、已在來源中刪除的檔案殘留在線上。
find . -maxdepth 1 -name '*.html' -delete
rm -f README.md
# --- 複製新檔案 ---
# 將私有倉庫中 'gh-pages' 資料夾內的所有新檔案複製過來。
# 這些是網站的實際內容。
cp ../gh-pages/*.html .
cp ../README.md .
# --- 提交與推送 ---
# 將所有新增、修改、刪除的檔案加入 Git 暫存區。
git add .
# 提交所有變更。
git commit -m "Update content, RSS feed and posts data" || echo "No changes"
# 強制推送（force push）到 gh-pages 分支。
# --force: 使用強制推送確保遠端分支的內容與此次部署完全一致，覆蓋掉舊的歷史紀錄。
# 這在自動化部署 gh-pages 這類分支時是常見且安全的做法。
git push origin gh-pages --force
|
儲存後提交、推送到伺服器上後，每當我們將更新推送到私有倉庫的 main 分支時，GitHub Actions 就會自動執行上述步驟（更新 README.md 並部署最新的靜態網頁）。基於同樣的邏輯，也可以輕易擴充此流程，例如加入自動產生 rss.xml 的步驟。
這個方法讓我們既能保有原始碼與腳本的隱私，又能確保部署到公開倉庫的內容是乾淨、可用於發佈的狀態。
結論
本文完整介紹了一套從內容統整到網站自動發布的工作流程。透過結合 LLM 的內容處理能力與 GitHub Actions 的自動化部署功能，把繁瑣的發佈流程簡化為一次 git push。
此方法的核心優勢在於，私人倉庫中可以保有原始資料或是原始碼，僅將最終的靜態網頁部署至公開倉庫。
相較於將筆記儲存在私人空間，將知識轉化為精美的獨立網頁，不僅能鞏固自己的理解，更能透過分享讓其價值極大化，使其變得易於取用且深具影響力。
目前也將我看到的文章，統整後輸出於《Wells 單頁結論》，有興趣的也可以進行自由閱讀。
我覺得做得不錯的有以下幾篇文章可以參考，互動式的方式能夠更快更容易理解其背後的精隨：
- 機率悖論的共同核心
- AI 溝通術：從提示詞到上下文工程
- 過擬合：為什麼完美的解釋反而毫無用處？
- Netflix 自由與責任文化指南
- DJI Osmo 360 vs Insta360 X5
參考文獻
- Introducing Perplexity Deep Research
- Gemini Deep Research
- Creating a GitHub Pages site
- GitHub Pages limits
- Using custom workflows with GitHub Pages
