[{"content":"最近在建一條本地 AI 影片生成流水線，硬體是 RTX 3070 Laptop 8GB，完整的技術架構和參數設定記錄在技術文件。\n這篇寫的是建構過程中幾個關鍵決策點——哪些地方 AI 幫了忙，哪些地方它的判斷是錯的，以及怎麼發現。\n第一版：AI 憑空想像的流程 最初直接讓 AI 根據需求建 ComfyUI workflow。它建出來了，影片也能產，但有一個明顯的問題：風格帶著一種舊化感，像是幾年前的 AI 生成特徵。\n原因事後回想很清楚——AI 沒有足夠的資訊。它沒有看過 Sulphur 2 的官方 workflow 定義，只憑訓練資料推斷出一個「合理的流程」。推斷不等於正確，結果就是一個能動、但不在最佳狀態的起點。\n第一個決策：給 AI 官方參考，而不是讓它自己想。\n第二版：引入官方 Workflow，效能卻掉了 重新提示 AI，要它去取得 Sulphur 2 官方 distilled T2V workflow 定義，按照那份結構重新拆成 pass1 + pass2 的兩段式設計。結構正確了，但發現生成效能直線下滑——同樣的段落，時間拉長了好幾倍。\n這裡出現了第一個診斷題：效能問題出在哪？\n效能調整：AI 知道的設定，跟現在的軟體不一樣 排查過程中花了相當多時間在 ComfyUI 的 offload 策略上。AI 給的設定建議是舊版本的理解——當時的 ComfyUI 有多種 offload 模式可以細調。但實際操作下來發現，新版本的行為已經不同，選項基本收斂到「自動」或「關閉自動」兩種，中間的細調空間幾乎消失了。\nA/B 測試了一輪後，最終穩定的方式是 --cache-none。\n邏輯是：多 model 加上多 workflow 的情境下，讓 ComfyUI 做智能 cache 決策，反而容易造成記憶體用量難以預測——RAM 先爆，然後 pagefile 的問題就跟著浮現（這個問題在上一篇有說過）。放棄 cache 的好處，換來的是行為的可預測性。\n這裡的決策不是「找到最優設定」，而是在不確定性高的情況下，選可控而非最優。\nCFG 值：AI 的 Convention 和社群實測的落差 最後一個繞路的地方是 CFG。\nAI 在整個過程中持續提示 CFG 應該設在 3 以上——這在一般的 diffusion model 使用情境下確實是常見範圍，不算錯的建議。但它忽略了一件事：distilled LoRA 的訓練工作點是 CFG=1.0，把 CFG 推高，等於把 guidance 推離訓練分佈。\n結果是 inter-frame 不穩定，具體表現就是 flicker。用 PSNR-Y 量化之後，數字差距非常明顯。\n最終解法是重新提示 AI，要它直接核對官方 workflow 的數值設定，而不是靠它的 convention 推斷。對照結果出來之後，所有設定才完整對齊。\n這裡的教訓是：AI 的 convention 是統計上的常見值，不是針對特定訓練工作點的正確值。 當模型有特殊的訓練前提時，社群的實測數字比 AI 的通則建議更可信。\n幾個可以帶走的判斷點 回頭看這整條建構過程，幾個決策點有類似的形狀：\nAI 沒有足夠資訊時，它會推斷而不是停下來問。 提供官方參考比依賴它推斷更快。 AI 的知識有時間差，新版軟體的行為它不一定知道。 涉及版本敏感的設定，驗證比信任更省時。 AI 的 convention 是從大量案例歸納的。 當你的使用場景有非典型前提（distilled model、特定 LoRA 訓練設定），去核對上游的數值，不要讓 AI 用通則覆蓋。 完整的 pipeline 架構、參數設定、PSNR 量化數字，在技術文件有詳細記錄。\n","permalink":"https://blog.davidhsaiou.com/posts/ai-pipeline-decision-process/","summary":"\u003cp\u003e最近在建一條本地 AI 影片生成流水線，硬體是 RTX 3070 Laptop 8GB，完整的技術架構和參數設定記錄在\u003ca href=\"https://doc.davidhsaiou.com/docs/tech-notes/knowledge-base/ai-shorts/sulphur2-pipeline.html\"\u003e技術文件\u003c/a\u003e。\u003c/p\u003e\n\u003cp\u003e這篇寫的是建構過程中幾個關鍵決策點——哪些地方 AI 幫了忙，哪些地方它的判斷是錯的，以及怎麼發現。\u003c/p\u003e\n\u003ch2 id=\"第一版ai-憑空想像的流程\"\u003e第一版：AI 憑空想像的流程\u003c/h2\u003e\n\u003cp\u003e最初直接讓 AI 根據需求建 ComfyUI workflow。它建出來了，影片也能產，但有一個明顯的問題：風格帶著一種舊化感，像是幾年前的 AI 生成特徵。\u003c/p\u003e\n\u003cp\u003e原因事後回想很清楚——AI 沒有足夠的資訊。它沒有看過 Sulphur 2 的官方 workflow 定義，只憑訓練資料推斷出一個「合理的流程」。推斷不等於正確，結果就是一個能動、但不在最佳狀態的起點。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第一個決策：給 AI 官方參考，而不是讓它自己想。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"第二版引入官方-workflow效能卻掉了\"\u003e第二版：引入官方 Workflow，效能卻掉了\u003c/h2\u003e\n\u003cp\u003e重新提示 AI，要它去取得 Sulphur 2 官方 distilled T2V workflow 定義，按照那份結構重新拆成 pass1 + pass2 的兩段式設計。結構正確了，但發現生成效能直線下滑——同樣的段落，時間拉長了好幾倍。\u003c/p\u003e\n\u003cp\u003e這裡出現了第一個診斷題：效能問題出在哪？\u003c/p\u003e\n\u003ch2 id=\"效能調整ai-知道的設定跟現在的軟體不一樣\"\u003e效能調整：AI 知道的設定，跟現在的軟體不一樣\u003c/h2\u003e\n\u003cp\u003e排查過程中花了相當多時間在 ComfyUI 的 offload 策略上。AI 給的設定建議是舊版本的理解——當時的 ComfyUI 有多種 offload 模式可以細調。但實際操作下來發現，新版本的行為已經不同，選項基本收斂到「自動」或「關閉自動」兩種，中間的細調空間幾乎消失了。\u003c/p\u003e\n\u003cp\u003eA/B 測試了一輪後，最終穩定的方式是 \u003ccode\u003e--cache-none\u003c/code\u003e。\u003c/p\u003e\n\u003cp\u003e邏輯是：多 model 加上多 workflow 的情境下，讓 ComfyUI 做智能 cache 決策，反而容易造成記憶體用量難以預測——RAM 先爆，然後 pagefile 的問題就跟著浮現（這個問題在\u003ca href=\"../t2i-model-selection-8gb-vram/\"\u003e上一篇\u003c/a\u003e有說過）。放棄 cache 的好處，換來的是行為的可預測性。\u003c/p\u003e","title":"用 AI 建本地 AI 影片生成流程——幾個讓我多繞一圈的決策點"},{"content":"最近在建一條本地 AI 影片生成流水線，需要挑一個 T2I 模型做 keyframe 的上游。 硬體限制是 RTX 3070 Laptop，8GB VRAM，不能加卡。\n挑模型的過程裡，順帶整理了一些平時容易混淆的概念，以及讓系統跑穩的幾個關鍵設定。\nFine-tune、LoRA、Distill 是三件不同的事 這三個詞在中文圈常常被混在一起講，但它們根本不是同一個維度：\nFine-tune LoRA Distill 改什麼 畫風 / 內容 畫風 / 內容（同上） 推論速度 訓練範圍 整個模型 只訓練插件權重 訓練速度更快的學生模型 檔案大小 跟 base 一樣大 50–300 MB 跟 base 一樣大 可以疊？ ✗ 一次一個 ✓ 可以同時掛多個 ✗ 換 checkpoint 這三件事可以疊在同一個工作流裡。juggernautXL_v9-lightning.safetensors 這個常見的模型， 本質就是寫實 fine-tune + Lightning distill 的組合；用它的時候還可以再加角色 LoRA + 風格 LoRA。\n弄清楚這個，選模型的時候就不會被名字搞混。\n8GB VRAM 的候選名單 把常見的選項排一遍：\n模型 VRAM 1024² 出圖時間 品質 8GB 可行？ SDXL Lightning（4–8 步） ~7 GB 4–6 s ★★★★☆ ✓ SDXL base + fine-tune（30 步） ~7 GB 15–22 s ★★★★☆ ✓ Flux Schnell GGUF Q4_K_M ~7 GB + offload 15–20 s ★★★★★ ✓ Flux Dev GGUF Q4_K_M ~7 GB + offload 60–90 s ★★★★★ ✓ 但慢 Flux fp16 12 GB+ — ★★★★★ ✗ 12B 的 Flux 為什麼能塞進 8GB？靠 GGUF Q4_K_M 量化——精度損失大約 5–10%， 但 Flux 的 prompt 理解能力幾乎全保留。Q4_K_M 是 4-bit 量化裡品質與速度的甜蜜點， Q4 還是 Flux 級的，不是閹割版。\n搭配 ComfyUI 的 --cache-none 啟動參數以及系統自動 offload，8GB 跑圖片其實非常夠用， 可以達到相當穩定的效果。\n一個反直覺的發現 測試幾輪下來，有一個結果出乎意料：\n寫實 SDXL fine-tune 在單張人像特寫場景，有時候贏 Flux。\nFlux 的「AI 感」比想像中明顯——塑膠皮膚、過度平滑的質感，在人像特寫裡特別容易被注意到。 寫實 SDXL（Juggernaut、RealVisXL 這類）因為是在大量攝影照片上 fine-tune 的，皮膚紋理相對自然。\n但這個優勢邊界其實是流動的，還在測試中。偶爾 SDXL 贏，偶爾 Flux 贏， 取決於場景、構圖、光線方向這些細節。\n最後發現，模型之間的邊界不是最重要的事。真正決定產出品質的，是你對提示詞的熟練度， 以及你對這個模型的反應熟不熟。 同樣一行 prompt，對 SDXL 有效的寫法拿去餵 Flux 未必成立。 換模型，等於重新建立一套使用直覺。\nWindows 環境下的 Pagefile 問題 這個問題卡了我一段時間，值得單獨說。\n在 Windows 上跑 AI 圖片生成，當 VRAM + RAM 都吃滿，系統會把溢出的資料 offload 到 pagefile。 Pagefile 在 SSD 上，速度比 RAM 慢 10–50 倍。一旦生成流進入 pagefile 處理，出圖時間會異常拉長。\n問題在於，Windows 預設的 pagefile 是自動增長模式，理論上系統會按需擴大。 實際上，當模型 offload 量大的時候，我曾經看到 pagefile 自動增長到 6X GB—— 這個大小讓 swap 有機會觸發磁碟 I/O，反而造成不穩定。\n解法：把 pagefile 設成固定大小。\n計算方式：系統 RAM（32 GB）+ 估計需要的 model swap space，取一個保守的固定值（例如 24 GB）。 設定固定大小後，系統不會再無限增長，pagefile 用量變得可預測，出圖速度也恢復穩定。\n設定路徑：進階系統設定 → 效能選項 → 虛擬記憶體 → 取消自動管理 → 手動指定固定大小。\n8GB 不是死路 「8GB VRAM 跑不動現代模型」這個說法在 2024 年前大概是對的。 2025 年後，GGUF Q4_K_M 量化 + distill + 智能 offload，加上 --cache-none 這類記憶體管理參數， 讓這個上限被推高了不少。\n8GB 跑 Flux 12B、跑 SDXL，在設定對了的前提下，現在都是可行的。 要付出的代價是速度，以及對工作流更細緻的理解——哪個步驟在哪一層記憶體裡、會不會打架。\n最終哪個模型更好，測試還在進行。但這些設定讓我可以在穩定的環境下繼續測下去，這才是前提。\n","permalink":"https://blog.davidhsaiou.com/posts/t2i-model-selection-8gb-vram/","summary":"\u003cp\u003e最近在建一條本地 AI 影片生成流水線，需要挑一個 T2I 模型做 keyframe 的上游。\n硬體限制是 RTX 3070 Laptop，8GB VRAM，不能加卡。\u003c/p\u003e\n\u003cp\u003e挑模型的過程裡，順帶整理了一些平時容易混淆的概念，以及讓系統跑穩的幾個關鍵設定。\u003c/p\u003e\n\u003ch2 id=\"fine-tuneloradistill-是三件不同的事\"\u003eFine-tune、LoRA、Distill 是三件不同的事\u003c/h2\u003e\n\u003cp\u003e這三個詞在中文圈常常被混在一起講，但它們根本不是同一個維度：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e\u003c/th\u003e\n          \u003cth\u003eFine-tune\u003c/th\u003e\n          \u003cth\u003eLoRA\u003c/th\u003e\n          \u003cth\u003eDistill\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e改什麼\u003c/td\u003e\n          \u003ctd\u003e畫風 / 內容\u003c/td\u003e\n          \u003ctd\u003e畫風 / 內容（同上）\u003c/td\u003e\n          \u003ctd\u003e推論速度\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e訓練範圍\u003c/td\u003e\n          \u003ctd\u003e整個模型\u003c/td\u003e\n          \u003ctd\u003e只訓練插件權重\u003c/td\u003e\n          \u003ctd\u003e訓練速度更快的學生模型\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e檔案大小\u003c/td\u003e\n          \u003ctd\u003e跟 base 一樣大\u003c/td\u003e\n          \u003ctd\u003e50–300 MB\u003c/td\u003e\n          \u003ctd\u003e跟 base 一樣大\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e可以疊？\u003c/td\u003e\n          \u003ctd\u003e✗ 一次一個\u003c/td\u003e\n          \u003ctd\u003e✓ 可以同時掛多個\u003c/td\u003e\n          \u003ctd\u003e✗ 換 checkpoint\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e這三件事可以疊在同一個工作流裡。\u003ccode\u003ejuggernautXL_v9-lightning.safetensors\u003c/code\u003e 這個常見的模型，\n本質就是寫實 fine-tune + Lightning distill 的組合；用它的時候還可以再加角色 LoRA + 風格 LoRA。\u003c/p\u003e\n\u003cp\u003e弄清楚這個，選模型的時候就不會被名字搞混。\u003c/p\u003e\n\u003ch2 id=\"8gb-vram-的候選名單\"\u003e8GB VRAM 的候選名單\u003c/h2\u003e\n\u003cp\u003e把常見的選項排一遍：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e模型\u003c/th\u003e\n          \u003cth\u003eVRAM\u003c/th\u003e\n          \u003cth\u003e1024² 出圖時間\u003c/th\u003e\n          \u003cth\u003e品質\u003c/th\u003e\n          \u003cth\u003e8GB 可行？\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eSDXL Lightning（4–8 步）\u003c/td\u003e\n          \u003ctd\u003e~7 GB\u003c/td\u003e\n          \u003ctd\u003e4–6 s\u003c/td\u003e\n          \u003ctd\u003e★★★★☆\u003c/td\u003e\n          \u003ctd\u003e✓\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eSDXL base + fine-tune（30 步）\u003c/td\u003e\n          \u003ctd\u003e~7 GB\u003c/td\u003e\n          \u003ctd\u003e15–22 s\u003c/td\u003e\n          \u003ctd\u003e★★★★☆\u003c/td\u003e\n          \u003ctd\u003e✓\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eFlux Schnell GGUF Q4_K_M\u003c/td\u003e\n          \u003ctd\u003e~7 GB + offload\u003c/td\u003e\n          \u003ctd\u003e15–20 s\u003c/td\u003e\n          \u003ctd\u003e★★★★★\u003c/td\u003e\n          \u003ctd\u003e✓\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eFlux Dev GGUF Q4_K_M\u003c/td\u003e\n          \u003ctd\u003e~7 GB + offload\u003c/td\u003e\n          \u003ctd\u003e60–90 s\u003c/td\u003e\n          \u003ctd\u003e★★★★★\u003c/td\u003e\n          \u003ctd\u003e✓ 但慢\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eFlux fp16\u003c/td\u003e\n          \u003ctd\u003e12 GB+\u003c/td\u003e\n          \u003ctd\u003e—\u003c/td\u003e\n          \u003ctd\u003e★★★★★\u003c/td\u003e\n          \u003ctd\u003e✗\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e12B 的 Flux 為什麼能塞進 8GB？靠 GGUF Q4_K_M 量化——精度損失大約 5–10%，\n但 Flux 的 prompt 理解能力幾乎全保留。Q4_K_M 是 4-bit 量化裡品質與速度的甜蜜點，\nQ4 還是 Flux 級的，不是閹割版。\u003c/p\u003e","title":"8GB VRAM 跑得動 12B 模型？本地 AI 圖片生成的模型選擇思路"},{"content":"過去一個月，我把整套個人開發流程改成 agent 驅動。下面是目前的狀態，與一個還沒解完的問題。\nAgent 架構 7 個 orchestrator skills、18 個 agents、23 個 utility skills,透過 MCP 與 Gitea、YouTrack、Kubernetes 整合。\n三層架構：\nPlanning：把模糊需求拆成模組、再拆成 lane-level issue Orchestrator：驅動「issue → 派工 → PR → merge」迴圈,最多 5 輪 Specialist：按技術棧切分（前端、後端、infra、docs、PR review 等）,在獨立 worktree 實作 流程 人類給幾行簡易的功能模組描述,剩下的事 agent 接手:\nplanner 改寫規格 → orchestrator 派工 → designer 出 mockup → coder 實作 → reviewer 跑規格整合檢查 → resolver 處理改動 → merge\n最近一次產出的速度 這個 epic 的目標是 WebRTC 視訊會議的基礎實作——視訊框、對話框、房間管理。\n11 個 issue,從規格到 13 個 PR 全數 merge,總時間 3 小時 28 分鐘,產出 10,224 行 code,平均約 49 行 / 分鐘。\n成品:https://lnkd.in/gYpdhEYD\n速度看起來很快,但成品仍有不少地方需要修正。能做到的,是把骨幹立起來。\n目前的限制 以這個 Meeting 專案為例,我只給了 5 到 10 行的功能簡述,agent 確實把功能做出來了。但在模組之間的銜接、畫面之間的過渡這些「規格沒明寫的部分」,agent 一律自由發揮——而那個發揮的結果,跟我心中真正想要的成品有不小的距離。\n最後我仍然花了 1 到 2 小時手動處理需求變更與 bug 修正,才把這個 PoC 收到一定的完整度。\n問題不在 agent 寫不出 code,而在它沒辦法通靈——那些沒寫進規格的細節,例如對話框顏色跟背景太接近、Blazor 互動性的小問題,agent 抓不到。\n這些東西人類工程師可以邊做邊看,邊看邊改,因為他們知道「看起來應該像什麼」。但 agent 沒有這個過程,只能照規格走。\n另一個層面是 context 與規則的問題。\ncontext 有上限,當塞到滿,前面講過的東西就會被擠掉。每個新 session 起來,agent 也不一定會讀到上次的脈絡——上次怎麼裝某個工具、上次踩過哪個坑、上次選定了哪個方案,都有機會被遺忘。結果就是有時候會失敗、有時候會錯選工具。\n更麻煩的是規則本身。即使你把所有規範用自然語言寫下來,agent 仍然有機會繞過、或選擇性遺忘——它會找到一個聽起來合理的解釋,讓自己跳過某條規則。\n這代表你必須花時間把「環境的隱性知識」寫成顯性文件,並且把重要的規則做成不留商量空間的硬性檢查。否則每一次都會從零開始,變貴、變慢,產出也不穩定。\n下一步 規格寫越清楚,產出越接近預期,這沒例外。但要寫多細才夠?沒答案。寫太少 agent 自由發揮,寫太多人類就把該省的時間花掉了。\n中間有兩條路:讓 agent 遇到沒寫到的就先問再做,或讓 agent 自己 QA 把問題抓出來。但這兩條都會吃更多 token,而且都還需要把更多使用案例寫清楚。\n整套流程怎麼平衡,目前還在嘗試。這一步本身就花了不少時間。\n結論 agent 確實提升了效率,甚至取代了寫程式碼這整個過程。但走到最後,會發現問題還是回到那些工程上的老問題——規格、邊界、規則、溝通。\n怎麼寫一份完整的開發規格?怎麼建構與分派 agent 的職責與邊界?怎麼用自然語言描述一個規則,又不留模糊地帶?角色與角色之間,輸入輸出的規範該怎麼定?\n這些問題本來就是團隊運作要解決的——角色怎麼分、規範怎麼定、訊息怎麼傳。以前靠人的默契還能撐,agent 接手後就撐不住了,因為 agent 不會默契,只會照規則走。\n換句話說,agent 處理掉的只是「實作」這一環,其他的環節反而更需要被明確寫下來。\n工具換了,但工程的本質沒換。\n過去這些議題常常因為時程或成本被犧牲掉——「先動手再說」、「之後再補文件」、「先讓功能跑起來」。AI 出現後,這些被擠到後面的事,反而被拉回了最該被處理的位置。\n","permalink":"https://blog.davidhsaiou.com/posts/software-agentic-development-observations/","summary":"\u003cp\u003e過去一個月，我把整套個人開發流程改成 agent 驅動。下面是目前的狀態，與一個還沒解完的問題。\u003c/p\u003e\n\u003ch2 id=\"agent-架構\"\u003eAgent 架構\u003c/h2\u003e\n\u003cp\u003e7 個 orchestrator skills、18 個 agents、23 個 utility skills,透過 MCP 與 Gitea、YouTrack、Kubernetes 整合。\u003c/p\u003e\n\u003cp\u003e三層架構：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePlanning：把模糊需求拆成模組、再拆成 lane-level issue\u003c/li\u003e\n\u003cli\u003eOrchestrator：驅動「issue → 派工 → PR → merge」迴圈,最多 5 輪\u003c/li\u003e\n\u003cli\u003eSpecialist：按技術棧切分（前端、後端、infra、docs、PR review 等）,在獨立 worktree 實作\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"流程\"\u003e流程\u003c/h2\u003e\n\u003cp\u003e人類給幾行簡易的功能模組描述,剩下的事 agent 接手:\u003c/p\u003e\n\u003cp\u003eplanner 改寫規格 → orchestrator 派工 → designer 出 mockup → coder 實作 → reviewer 跑規格整合檢查 → resolver 處理改動 → merge\u003c/p\u003e\n\u003ch2 id=\"最近一次產出的速度\"\u003e最近一次產出的速度\u003c/h2\u003e\n\u003cp\u003e這個 epic 的目標是 WebRTC 視訊會議的基礎實作——視訊框、對話框、房間管理。\u003c/p\u003e\n\u003cp\u003e11 個 issue,從規格到 13 個 PR 全數 merge,總時間 3 小時 28 分鐘,產出 10,224 行 code,平均約 49 行 / 分鐘。\u003c/p\u003e","title":"Software Agentic Development：一個月實作後的幾個觀察"},{"content":"Hello, this blog is live.\n這個 Blog 以 Hugo + PaperMod 為技術棧， 透過 Gitea Actions CI 自動建置 Docker image，並由 FluxCD GitOps 部署至 K3s 叢集。\n域名：blog.davidhsaiou.com\n","permalink":"https://blog.davidhsaiou.com/posts/hello-world/","summary":"\u003cp\u003eHello, this blog is live.\u003c/p\u003e\n\u003cp\u003e這個 Blog 以 \u003ca href=\"https://gohugo.io/\"\u003eHugo\u003c/a\u003e + \u003ca href=\"https://github.com/adityatelange/hugo-PaperMod\"\u003ePaperMod\u003c/a\u003e 為技術棧，\n透過 Gitea Actions CI 自動建置 Docker image，並由 FluxCD GitOps 部署至 K3s 叢集。\u003c/p\u003e\n\u003cp\u003e域名：\u003ca href=\"https://blog.davidhsaiou.com\"\u003eblog.davidhsaiou.com\u003c/a\u003e\u003c/p\u003e","title":"Hello World"}]