我的 OpenClaw 工程化：3 個 Agent 跑通 100% Web 項目開發交付閉環
整理版優先睇
一條消息、一頓飯、一個完整落地頁上線：我用3個Agent跑通100% Web交付閉環
呢篇文章係作者分享佢用OpenClaw嘅3個Agent（Main Claw、Winnie、Amy）完成一個真實Web產品落地頁嘅經驗。作者係一個技術人，之前已經寫過關於OpenClaw養蝦記嘅文章，今次用一個具體項目——Voice Real-time Translation嘅產品頁（vrt.junxinzhang.com）——去驗證佢嘅自動化閉環。作者想解決嘅問題係：代碼寫完唔等於交付完成，域名、HTTPS、統計系統等「最後一公里」往往被忽略。整體結論係：將交付鏈路工程化，用Agent接力完成開發、驗證、上線，甚至回滾，係可行而且高效嘅。
作者嘅經驗係：佢只係發咗一條消息畀Main Claw，Winnie嘅3個SubAgent（Dev、QA、Release）就接力完成咗22次commit、一次回滾、DNS配置、HTTPS證書同三套統計系統埋點。Amy之後仲幫佢寫咗覆盤文章。呢件事證明咗Agent可以成為團隊基礎設施，而回滾唔係失敗，係工程化嘅硬證明。
文章仲提供咗5條可複用嘅方法：先拆角色、先做最小閉環、將域名同證書納入發佈清單、所有動作可追蹤、人只做高價值判斷。作者強調，Agent負責重複執行，人負責定目標同判斷。
- 結論：一條消息觸發，3個SubAgent接力，一頓飯時間完成從代碼到線上產品頁嘅全鏈路交付，包括回滾。
- 方法：將Web交付拆成開發、驗證、上線三個獨立SubAgent，每個專注單一上下文，避免窗口過載。
- 差異：傳統做法忽略域名、HTTPS、統計等「最後一公里」；作者將基礎設施納入Agent職責，確保用戶真正可用。
- 啟發：回滾係工程化嘅硬證明，唔係失敗；原子化commit同清晰基線令回滾快速可靠。
- 可行動點：團隊可以先拆角色、跑通最小閉環、將域名同證書加入發佈清單、用git log做黑匣子、將重複步驟交畀Agent。
Voice Real-time Translation 落地頁
文章提及嘅實際項目線上地址
GitHub Pages 自定義域名配置指南
GitHub Pages 自定義域名配置指南
Cloudflare DNS 文檔
Cloudflare DNS 文檔
OpenClaw 官方文檔
OpenClaw 官方文檔
內容片段
3ce44c2 feat: initial VRT landing page92015c8 feat: add local assets (screenshots)63cd6e0 feat: add local assets (installer DMG)b148bb3 feat: switch installer and screenshots to repo-hosted assets977be32 feat: switch demo video embed to bilibili點解「寫到代碼」唔等於「交得到貨」？
好多技術文章（包括作者以前寫嘅）都有一個隱含假設：代碼寫完等於交付完成。但現實係，一個落地頁由「本地跑得到」到「用戶用得到」，中間仲有域名、HTTPS、統計系統等一堆步驟，每一步都容易出錯。
單獨睇唔難，加埋靠人工記憶，遲早漏一個
作者嘅目標唔係做一個靚仔頁面，而係將成條交付鏈路工程化——用Agent將每個環節串起，變成可重複嘅流水線。
項目全貌：一個真實落地頁，唔係Demo
項目係Voice Real-time Translation嘅產品落地頁，一個macOS實時語音翻譯器嘅官方展示頁面。作者刻意用「零框架」技術棧：純HTML5、CSS3、Vanilla JavaScript，冇React、Vue、npm。原因係落地頁「發佈後極少變更」，零框架等於零構建步驟、零依賴升級風險。
最好嘅技術選型，係令問題最少嘅選型
頁面有9個區塊，覆蓋完整轉化路徑：Header、Hero、價值區、場景區、功能區、截圖區、FAQ區、CTA區、Footer。作者參考咗大量SaaS落地頁嘅轉化漏斗邏輯：先吸引，再說服，最後轉化。
- 線上地址：https://vrt.junxinzhang.com
- 代碼倉庫：github.com/junxinzhang/vrt-landing-page
- 託管平台：GitHub Pages，DNS用Cloudflare（CNAME），HTTPS由GitHub Pages自動簽發（Let's Encrypt，到期2026-05-28）
- 統計系統：百度統計 + Umami + Google Analytics（GA4），三套交叉驗證
Winnie嘅3個SubAgent接力賽：點解係接力，唔係一口氣？
Web交付係一條嚴格有序嘅鏈路：代碼未寫完唔可以驗證，驗證唔過唔可以上線，上線失敗要可以回滾。作者將Winnie拆成3個SubAgent，每個擁有獨立上下文窗口同專注範圍。
- 1 SubAgent 1：開發階段（Winnie · Dev）——編寫HTML/CSS/JS，SEO配置，git commit。一日內產出22次commit，消息前綴統一用feat:/fix:/docs:/revert:。
- 2 SubAgent 2：驗證階段（Winnie · QA）——執行10項檢查：文案、資源可達、腳本存在、構建狀態、響應式。Agent唔會跳過步驟，結果確定性高。
- 3 SubAgent 3：上線階段（Winnie · Release）——推送主分支、觸發構建、域名校驗、HTTPS校驗、回滾預案。最重要嘅能力係「推唔上去或推錯咗點算」。
22次Commit背後嘅故事：翻車與回滾先係重頭戲
項目一共22次commit，全部喺同一日發生。關鍵里程碑包括初始頁面搭建、視覺打磨、同埋一次翻車後嘅回滾。
工程化嘅第一課：將所有關鍵資源納入版本控制範圍，唔依賴任何外部不可控連結
一次視覺改版後，頁面喺移動端出現佈局錯位。傳統流程可能會疊patch，越改越亂。但上線Agent做咗一件正確嘅事：定位到確認穩定嘅基線commit（977be32），一鍵回退核心文件，強制推送重建，逐項驗收。幾分鐘內恢復穩定版本，然後喺穩定基線上繼續增量迭代。
- 1 原子化提交：每次commit只做一件事，出問題時可以精準回退到某一次變更。
- 2 commit消息規範：feat:/fix:/docs:/revert:前綴，3秒鐘理解提交內容。
域名與證書：交付嘅「最後一公里」
用戶判斷網站上線嘅標準係瀏覽器輸入地址見到HTTPS小鎖，唔係GitHub Pages構建成功。作者將域名同證書都納入Agent職責。
DNS配置用Cloudflare DNS Only（灰雲），唔用代理模式，因為GitHub Pages需要直接解析到佢嘅IP先正確簽發HTTPS證書
CNAME文件必須喺倉庫根目錄，內容只有一行：vrt.junxinzhang.com。否則每次推送新代碼後，GitHub Pages會自動清除自定義域名設置。
只做代碼自動化而唔做發佈基礎設施自動化，交付鏈路就係斷嘅
三套統計系統：發佈唔係終點，係循環起點
頁面上線後，作者同時接入三套獨立統計系統：百度統計（國內SEO）、Umami（自託管隱私友好）、GA4（海外標準）。每套都有盲區，三套交叉驗證先接近真實全景。
發佈唔係項目嘅終點，係數據驅動迭代嘅起點
統計數據迴流後可以回答：用戶喺邊個區塊停留最耐？下載按鈕點擊率？移動端比例？渠道來源？呢啲資訊推動下一輪迭代。
今天中午吃飯前，我掏出手機給 Main Claw 發了一條消息：
"參考 meterinfoapp-landing-page 的結構，幫我落地 Voice Real-time Translation 的產品頁。截圖先空着，域名用 vrt.junxinzhang.com。你分配給 Winnie 和 Amy 一些活，一起完成。"
然後我放下手機，去吃飯了。
吃完飯回來，收到了Main Claw的回覆說已經完成了，讓我直接打開瀏覽器，輸入 https://vrt.junxinzhang.com——頁面秒開，HTTPS 小鎖亮着，下載按鈕指向 DMG 安裝包，B 站演示視頻自動加載，百度統計、Umami、Google Analytics 三套埋點全部在線。
我愣了幾秒。
從我發出那條消息，到眼前這個完整可用的線上產品頁，中間我沒有碰過一行代碼、沒有登錄過一次 GitHub、沒有打開過 Cloudflare 的控制枱。
域名是 Agent 配的。證書是 Agent 觸發的。統計代碼是 Agent 埋的。甚至後來那次"改版翻車後的緊急回滾"，也是 Agent 在 3 分鐘內完成的。
一句話結論：一條消息發給 Main Claw，Winnie 寫代碼、跑驗證、做上線，Amy 寫覆盤——一頓飯的功夫，從代碼到線上產品頁，全鏈路交付完成。
如果你只有 30 秒，先看這 3 句：
1. 我把 Voice Real-time Translation 的落地頁項目交給 Winnie，由它的 3 個 SubAgent 接力完成：Dev 寫代碼、QA 跑檢查、Release 做發佈——三段接力，一隻蝦搞定。 2. 線上已經真實可用： https://vrt.junxinzhang.com，DNS 在 Cloudflare，HTTPS 證書由 GitHub Pages 自動託管，三套統計系統同時在線。3. 最關鍵的不是"自動化很快"，而是這次經歷了一次完整回滾——回滾本身，才是工程化最硬的證明。
一、為什麼"能寫代碼"不等於"能交付"
這件事的起因很簡單。
昨天我剛寫完《我的 OpenClaw 養蝦記：3 個 Agent 跑通 100% 自動化閉環》，很多人的反饋集中在一個問題：
"Agent 能寫代碼我信了，但你說的 100% 自動化，是不是隻做到了代碼層面？部署呢？域名呢？HTTPS 呢？用戶真的能打開嗎？"
這個問題問到了要害。
說實話，很多技術文章（包括我自己以前寫的）都有一個隱含假設：代碼寫完 = 交付完成。但現實裏，一個落地頁從"本地能跑"到"用戶能用"，中間還有一段很長的路：
這張表裏的每一項，都是我或者我身邊的工程師踩過的坑。而且它們有一個共同特點：單獨看都不難，但加在一起靠人工記憶，遲早漏一個。
所以這次我的目標不是"做一個漂亮頁面"，而是把整條交付鏈路工程化——用 Agent 把每個環節串起來，讓"從代碼到用戶可訪問"變成一條可重複的流水線。
二、項目全貌：一個真實的落地頁，不是 Demo
先說清楚這次做的是什麼。
項目是 Voice Real-time Translation 的產品落地頁——就是我在[前一篇文章]裏介紹的那個 macOS 實時語音翻譯器的官方展示頁面。
為什麼要做落地頁？因為那篇文章發出去之後，不少人問我"在哪下載"、"有沒有產品介紹頁"。一個好產品沒有落地頁，就像一家好餐廳沒有門面——別人想進來都找不到入口。
2.1 技術棧：刻意做了"零框架"
你沒看錯——沒有 React，沒有 Vue，沒有 Next.js，甚至沒有 npm。
這不是因為我不會用框架，而是一個刻意的工程決策：落地頁是一個"發佈後極少變更"的產物，用零框架意味着零構建步驟、零依賴升級風險、零 Node 版本兼容問題。GitHub Pages 直接託管 HTML，推上去就生效。
最好的技術選型，是讓問題最少的選型。
2.2 頁面結構：9 個區塊覆蓋完整轉化路徑
這套結構不是拍腦袋出來的，而是參考了大量 SaaS 落地頁的轉化漏斗邏輯：先吸引 → 再說服 → 最後轉化。
2.3 線上地址與基礎設施
https://vrt.junxinzhang.com | |
github.com/junxinzhang/vrt-landing-page | |
為什麼用三套統計？因為百度統計覆蓋國內搜索引擎生態、Umami 是自託管的隱私友好方案、GA4 是海外流量的行業標準。三套交叉驗證，確保不漏數據。
三、Winnie 的 3 個 SubAgent 接力賽：為什麼是"接力"，而不是"一口氣"
在[昨天的養蝦文章]裏，我介紹了 Winnie（編碼蝦）和 Amy（文案蝦）的按能力分工模式。這次的 Web 交付場景不太一樣——落地頁從代碼到上線是純技術活，所以 技術鏈路由 Winnie 一隻蝦通過 3 個 SubAgent 接力完成。Amy？別急，它在最後會登場。
換句話說，技術交付這一段不是"兩個人各幹各的"，而是"同一個人換了三頂帽子，按階段依次戴上"。
為什麼這麼設計？因為 Web 交付是一條嚴格有序的鏈路：代碼沒寫完不能驗證，驗證沒過不能上線，上線失敗要能回滾到上一步的穩定狀態。把三個階段拆成三個 SubAgent，每個 SubAgent 擁有獨立的上下文窗口和專注範圍，比讓一個 Agent 一口氣扛到底要穩定得多。
3.1 SubAgent 1：開發階段（Winnie · Dev）——寫代碼
Winnie 的開發階段表現非常穩定。它一天內產出了 22 次 commit，覆蓋了從初始頁面搭建（feat: initial VRT landing page）到資源本地化（feat: switch installer and screenshots to repo-hosted assets）、視頻嵌入（feat: switch demo video embed to bilibili）、視覺優化（feat: refine VRT landing page visual polish）的完整開發週期。
值得一提的是，commit message 風格非常規範——統一使用 feat: / fix: / docs: / revert: 前綴，每條消息都能讓你 3 秒鐘內理解這次提交幹了什麼。這不是偶然，而是我在 Agent 的 system prompt 裏明確要求的。
3.2 SubAgent 2：驗證階段（Winnie · QA）——跑檢查
驗證 SubAgent 的價值在於它不跳步驟。
人類做測試最容易犯的錯就是"這個肯定沒問題，跳過"——然後恰恰是那個被跳過的環節翻車。Agent 不會。你給它 10 項檢查清單，它會一項不落地全部跑完，並且每次結果都是確定性的。
3.3 SubAgent 3：上線階段（Winnie · Release）——做發佈
vrt.junxinzhang.com 解析正確 | |
上線 SubAgent 最重要的能力不是"推上去"，而是"推不上去或推錯了怎麼辦"。這正是接下來我要重點講的。
3.4 為什麼拆成 3 個 SubAgent，而不是讓 Winnie 一口氣幹完
我早之前確實試過讓 Winnie 一個 session 從頭做到尾。結果是：
• 上下文窗口被撐滿：代碼上下文 + 部署配置 + DNS 知識 + 證書流程，一個窗口裝不下 • 出錯難歸因：頁面打不開了——是代碼問題、構建問題、DNS 問題還是證書問題？一個 session 裏乾的活，你問它自己它也說不清 • 無法並行優化：只有拆開，你才能單獨優化某一段的效率
Elvis 在他的 Agent Swarm 方法論裏提過一個核心觀點：上下文窗口是零和的。這句話在 Web 交付場景裏體現得淋漓盡致——開發上下文和運維上下文天然互斥，硬塞在一個窗口裏，兩頭都做不好。拆成 3 個 SubAgent，本質上是給 Winnie 的同一種能力在不同階段分配了獨立的上下文空間。
四、22 次 Commit 背後的故事：完整覆盤
別人寫工程化文章，喜歡畫架構圖。我更想給你看 git log——因為 commit 記錄不會說謊。
這個項目一共 22 次 commit，全部發生在同一天。這不是"趕工"，而是 Agent 驅動的高密度迭代的自然結果。以下是關鍵里程碑：
第一階段：從 0 到 1（commit 1-5）
3ce44c2 feat: initial VRT landing page
92015c8 feat: add local assets (screenshots)
63cd6e0 feat: add local assets (installer DMG)
b148bb3 feat: switch installer and screenshots to repo-hosted assets
977be32 feat: switch demo video embed to bilibili這 5 次 commit 完成了頁面的初始搭建：HTML 骨架、CSS 樣式系統、JS 交互邏輯、產品截圖、DMG 下載包、B 站演示視頻嵌入。
值得注意的是第 4 次 commit（b148bb3）——把截圖和安裝包從外部連結遷移到了倉庫內託管。為什麼？因為外部連結有一個致命問題：你控制不了它的可用性。Google Drive 連結隨時可能因分享設置變化而 404，而倉庫內的資源只要 repo 在就在。
工程化的第一課：把所有關鍵資源都納入版本控制範圍，不依賴任何外部不可控連結。
第二階段：視覺打磨（commit 6-10）
1a843fc docs: embed bilibili preview in README
703ffe9 docs: update README with latest screenshots
7388a0d feat: refine VRT landing page visual polish (index.html)
404afa8 feat: refine VRT landing page visual polish (css/style.css)
3d7434c feat: refine VRT landing page visual polish (js/main.js)這個階段 Winnie 對頁面做了一輪系統性的視覺優化——HTML 結構調整、CSS 細節打磨、JS 交互增強。三個文件分三次 commit，每次只改一個關注點。這不是強迫症，而是 原子化提交 的實踐：每次 commit 只做一件事，出問題時可以精準回退到某一次變更，而不是"回退了樣式順便把功能也丟了"。
第三階段：翻車與回滾（commit 11-14）——這才是重頭戲
e8dfd05 fix: update favicon tab icon and FAQ Q1 client-only note
2007f35 feat: update contact CTA section with localized contact actions
06914a3 feat: add Baidu, Umami, and GA analytics scripts
2bb57b6 revert: rollback landing page UI to 977be32 baseline注意最後一行：revert。
事情是這樣的：在一輪視覺改版後，頁面效果不符合預期——某些樣式改動影響了佈局穩定性，在移動端出現了意料之外的錯位。
如果是傳統手工流程，接下來大概率是這樣的：
1. "先別急，我調調看" 2. 疊了 3 個 patch，每個 patch 修了舊問題又引入新問題 3. 反覆修改 2 小時後，誰也說不清當前版本到底改了哪些 4. 最後被迫凌晨重做
而這次，上線 Agent 做了一件很"無聊"但極其正確的事：
1. 定位到上一個確認穩定的基線 commit（ 977be32）2. 一鍵回退核心文件到該版本 3. 強制推送並觸發 GitHub Pages 重建 4. 逐項驗收線上內容
幾分鐘內恢復到穩定版本，然後在穩定基線上繼續增量迭代。
第四階段：在穩定基線上增量推進（commit 15-22）
f53423d feat: localize contact CTA section
06914a3 feat: add Baidu, Umami, and GA analytics scripts
11e314a feat: add Baidu, Umami and GA analytics (final)回滾之後，Winnie 不是從零重做，而是在 977be32 這個穩定基線上，一個功能一個功能地疊加——先做 CTA 本地化，再做統計埋點，每次加一層，驗一層，確認沒問題再加下一層。
這就是"回滾"真正的價值：它不是失敗的標誌，而是質量控制的工具。
五、域名與證書：交付的"最後一公里"
很多技術文章寫到"代碼部署完成"就結束了。但如果你問一個真正的用戶："你怎麼知道一個網站上線了？"
答案不是"GitHub Pages 構建成功"。答案是：我在瀏覽器裏輸入地址，頁面打開了，地址欄有 HTTPS 小鎖。
這就是為什麼我把域名和證書也納入了 Agent 的職責範圍。
5.1 DNS 配置：Cloudflare CNAME
為什麼用"DNS Only"而不是 Cloudflare 的代理模式（橙雲）？因為 GitHub Pages 需要直接解析到它的 IP 才能正確簽發 HTTPS 證書。開了 Cloudflare 代理會導致證書籤發鏈路斷裂——這是一個極其隱蔽的坑，我見過不少人在這裏卡幾小時。
5.2 HTTPS 證書：GitHub Pages 自動簽發
GitHub Pages 的 HTTPS 證書籤發是自動的，但有一個前提：你的 CNAME 文件和 DNS 配置必須完全一致。如果 CNAME 文件寫的是 vrt.junxinzhang.com，但 DNS 解析的目標不是 junxinzhang.github.io，證書就籤不下來。
上線 Agent 在這一步的工作是：推送包含 CNAME 文件的代碼 → 等待 Pages 檢測到自定義域名 → 確認證書狀態變為 Approved → 驗證 HTTPS 可訪問性。
用戶訪問的是域名和 HTTPS，不是你的 localhost。只做代碼自動化而不做發佈基礎設施自動化，交付鏈路就是斷的。
5.3 一個被忽視的細節：CNAME 文件必須在倉庫裏
很多人會在 GitHub Pages 的設置界面手動填自定義域名，然後忘了在倉庫根目錄放 CNAME 文件。這會導致一個鬼畜的現象：每次推送新代碼後，GitHub Pages 會自動清除你的自定義域名設置——因為構建過程會以倉庫內容為準。
解法很簡單：確保 CNAME 文件在倉庫裏，內容就一行：vrt.junxinzhang.com。但就這麼一個小文件，能讓多少人半夜爬起來排查"為什麼域名又失效了"。
六、三套統計系統：發佈不是終點，而是循環起點
頁面上線了，然後呢？
很多人的回答是"等用戶來"。但更工程化的回答是：看數據，然後迭代。
這次我在落地頁裏同時接入了三套獨立統計系統：
ca2efa...49406 | |||
df2642...69e38 | |||
G-2Y9RHGQ0TG |
為什麼要三套？不嫌多嗎？
不嫌。因為每套統計都有自己的盲區：百度統計看不到海外流量，GA 在國內被牆的地區數據會缺失，Umami 雖然全覆蓋但報表功能相對基礎。三套交叉驗證，才能接近真實的全景數據。
更重要的是，統計數據迴流到下一輪迭代時，能回答這些關鍵問題：
• 用戶在哪個區塊停留最久？→ 說明這塊內容有吸引力 • 下載按鈕的點擊率是多少？→ CTA 文案是否需要優化 • 移動端和桌面端的比例？→ 響應式優化的優先級 • 用戶從哪個渠道來？→ 推廣策略的依據
發佈不是項目的終點，是數據驅動迭代的起點。
七、普通團隊可以直接複用的 5 條方法
這次工程化實踐之後，我提煉了 5 條不依賴 OpenClaw、任何團隊都能用的方法：
1）先拆角色，再談自動化
別上來就讓"一個人從頭做到尾"或者"一個 Agent 全包"。
開發、驗證、上線是三種完全不同的能力和心智模型。開發關注"怎麼實現"，驗證關注"實現得對不對"，上線關注"用戶能不能用"。三者混在一起，出了問題你連在哪一段出的都說不清。
2）先做最小可驗證閉環
不要一開始就追求"完美的自動化流水線"。先把最簡單的閉環跑通：
改一行代碼 → 推上去 → 線上能看到變化
這個閉環一旦跑通，你就有了信心和基礎去疊加更多能力（驗證、統計、回滾……）。
3）把域名和證書納入發佈清單
代碼部署成功 ≠ 用戶可用。域名解析 + HTTPS 生效 才是"交付完成"的標誌。每次發佈前至少確認這兩項。
4）所有關鍵動作都可追蹤
每次變更都應該有 commit，commit 都應該有清晰的 message，每個發佈節點都應該能追溯到對應的 commit hash。出問題的時候，git log 就是你的黑匣子。
5）人只做高價值判斷
Agent 負責重複執行（寫代碼、跑檢查、推部署、配 DNS）。人負責兩件事：定目標 和 做判斷（這個改版好不好？要不要回滾？數據說明什麼？）。
如果你發現自己在反覆做某個手工步驟，那就是一個信號：這個步驟應該交給 Agent。
八、下一步路線圖
這次的實踐驗證了"3個 SubAgent 接力"在單個 Web 項目上的可行性。接下來我會繼續推進：
1. 發佈前自動檢查清單：把驗證 Agent 的檢查項標準化為 YAML 配置，新項目直接複用 2. Staging 環境：正式上線前先跑一輪灰度預覽，減少"推上去才發現問題" 3. 統計數據迴流：把 GA/Umami 的數據自動彙總，生成每週迭代建議 4. 模板化複用：為其他 Web 項目（博客、文檔站、產品頁）複製同樣的 3 Agent 交付流程 5. 沉澱為 SOP：把整套流程寫成"個人可複用的 Agent Team 標準操作程序"
寫在最後：Amy 說，該她了
落地頁上線、數據迴流、方法論沉澱——技術鏈路到這裏就跑通了。
然後我在 Main Claw 裏敲了一句話：
"好了，本次項目的經驗和教訓，交給 Amy 幫我寫一下今天的筆記。"
是的，你現在看到的這篇文章，底稿來自 Amy。
Winnie 跑完了從代碼到上線的全鏈路，Amy 接過 Winnie 留下的 commit 記錄、回滾日誌、部署配置，把一整天的工程實踐濃縮成了你正在閲讀的這些文字。我在她的草稿上做了潤色和事實校驗，但骨架和敍事線是她搭的。
這件事讓我意識到一個更深層的變化：
Winnie 和 Amy 已經不只是"各幹各的"了——它們開始形成流水線式的協作：一個創造事實，一個把事實變成敍事。
回過頭來看，這次最讓我有感觸的不是"22 次 commit 好快"，也不是"落地頁一頓飯的功夫就上線了"，而是那次回滾——以及 Amy 在文章裏把回滾寫成了"工程化最硬的證明"。
傳統觀念裏，回滾是一件丟人的事——"你搞砸了才需要回滾"。但在工程化視角下，回滾是一種能力：它說明你的版本控制是健全的、你的基線是可追溯的、你的恢復路徑是明確的。 Amy 比我自己更早想清楚了這一點，並且把它放在了文章最顯眼的位置。
這次我對"100% Web 開發交付"的定義也更清晰了：
• 人定義目標 • Winnie 完成技術執行 • 系統保證可控 • 出錯時可回滾 • Amy 把經驗變成內容 • 數據能驅動下一輪
當你把交付鏈路工程化，Agent 就不再是玩具，而是團隊基礎設施。當兩隻蝦學會接力，一個人就真的變成了一個團隊。
對了，這篇文章的主角——那個被 Claw 們一頓飯功夫推上線的落地頁——就在這裏：vrt.junxinzhang.com。如果你也有跨語言會議的痛點，歡迎試用 Voice Real-time Translation，也歡迎在落地頁底部聯繫我聊聊你的真實場景。
部署利器：
相關閲讀
OpenClaw 系列
• 我的 OpenClaw 養蝦記：3 個 Agent 跑通 100% 自動化閉環 • Mac Mini 被 AI 圈搶光了，真的值得買嗎？我的 OpenClaw 實測體驗 • OpenClaw 嚐鮮報告：這款爆火的 AI 工具，現在能用嗎？
AI 工程系列
• Teams 只有字幕沒有翻譯？我在 macOS 做了一個實時語音翻譯器 • 從 GLM-5、MiniMax 到"紅包大戰"：開工第一天你必須看懂的 AI Coding 新秩序 • AI 訂閲收緊潮：從 Anthropic 到 Google、GLM，免費午餐真的結束了
參考資料（官網/官方）
1. OpenClaw 官方文檔
https://docs.openclaw.ai/2. GitHub Pages 官方文檔
https://docs.github.com/en/pages3. GitHub Pages 自定義域名配置指南
https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site4. Cloudflare DNS 文檔
https://developers.cloudflare.com/dns/5. Let's Encrypt 證書說明（GitHub Pages 使用）
https://letsencrypt.org/6. Google Analytics gtag.js 集成文檔
https://developers.google.com/analytics/devguides/collection/gtagjs7. Umami 自託管分析平台文檔
https://umami.is/docs8. 百度統計官方文檔
https://tongji.baidu.com/