AI學習與應用體會系列文章06:由零建立網站
建立網站唔係叫 AI 一次過生成幾頁，而係將定位、資料、資訊架構、程式、測試、部署同營運連成一個可重複流程。Agent 可以大幅擴大一個人嘅執行力，但產品方向、權限同發布責任仍然要由人掌握。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
上一篇講到，強積金呢類低頻、高風險工作，最合理嘅做法往往係由機器準備、人負責提交。建立網站就唔同：資料整理、程式修改、測試、格式轉換同部署檢查都會反覆出現，而且大部分工作容易驗證、可以回退，自動化回報通常更高。
為咗真正熟習 AI Agent，筆者揀咗一個同「衣食住行」有關嘅生活題材，由零開始建立一個網站，作為考下自己運用AI 能力嘅功課。
最初筆者以為主要挑戰係寫 Frontend 同 Backend；做落先發現，程式只係其中一部分。真正困難係將一個模糊念頭，逐步變成清楚定位、可靠資料、可用頁面同可以長期維護嘅系統。
真正起點唔係程式碼，而係網站要解決乜
一句「幫我整個生活資訊網站」對人同 Agent 都太含糊。AI 可以即刻生成一個首頁，但如果未定義使用者、場景同內容邊界，做得愈快，只會更快累積錯誤假設。
筆者先整理一頁簡短嘅 project brief，將項目限制成幾個可以核對嘅問題：
1｜服務對象：邊類人會使用網站？佢哋喺咩情況下需要資料？使用手機定電腦較多？
2｜核心任務：使用者進入網站之後，最重要係搜尋、比較、查路線、睇詳情，定係完成另一個明確動作？
3｜內容邊界：第一個版本必須有乜，暫時唔做乜，避免 Agent 見到任何相關功能都自行加落去。
4｜可信標準：資料由邊度取得、幾耐更新一次、邊啲內容需要人工核對，過期或者矛盾時點處理？
5｜成功標準：唔係只問網站有冇上線，而係核心頁面能否完成任務、資料是否準確、速度是否可接受，同埋日後可唔可以維護。
呢張 brief 亦係所有 Agent 嘅共同邊界。之後無論係研究、設計定寫程式，每一項建議都要回答：佢解決緊邊個使用者問題？屬於第一個版本定日後版本？用咩方式驗收？
| Agent 最有價值嘅第一步，唔係立即寫程式，而係將「我想整個網站」拆成一連串有輸入、有輸出、有驗收標準嘅決定。 |
研究同類網站，但唔係叫 AI 抄一個返嚟
定位初步清楚之後，筆者叫 Agent 研究同類網站。多個 sub-agents 可以平行查看唔同服務，整理頁面種類、導覽方式、資料密度、搜尋流程、更新頻率同常見問題，速度比逐個網站手動記錄快得多。
但研究結果唔應該只係一句「呢個網站設計得幾好」。筆者要求用固定格式交付，並為每個重要觀察保存來源同檢視日期：
對象與任務：對方主要服務邊類使用者，最突出嘅使用場景係乜。
頁面與路徑：由首頁到分類、清單、詳情同完成任務，需要經過幾多步。
資料與更新：頁面展示邊啲欄位、資料來自邊度、過期內容有冇清楚標示。
優點與缺口：邊啲做法值得參考，邊啲問題仍然未解決，自己嘅網站可以點樣改善。
同類網站研究提供嘅係證據同選項，唔係設計答案。Agent 好容易將最常見嘅做法當成最佳做法，亦可能將幾個網站拼成一個功能過多嘅方案。最後仍然要由我根據目標使用者、維護成本同第一版範圍作取捨。
資訊架構先係網站骨架，首頁顏色反而係後一步
有咗定位同研究之後，筆者叫AI先畫 sitemap 同 user flow，再開始做畫面。網站通常唔只得首頁，仲可能有分類頁、清單頁、詳情頁、搜尋結果、方法說明、資料來源、常見問題同聯絡頁。呢啲頁面之間點樣連接，會直接影響使用者搵唔搵到資料。
筆者先揀兩至三條最重要嘅路徑，例如「由地區搵資料」、「由分類比較選項」同「由搜尋直接去詳情」。每條路徑都要有清楚入口、足夠篩選、可理解嘅頁面名稱，同埋去到詳情後下一步可以做乜。
同時要定義分類法同頁面模板。地區、類別、標籤、服務狀態如果一開始冇統一規則，Agent 之後每次加內容都可能創造新名稱，最後出現「中環」、「中西區」同「Hong Kong Central」被當成三個地方嘅情況。
所以，資訊架構唔只係一張選單圖，而係一份內容契約：一類資料有咩欄位、可以屬於邊啲分類、會出現喺邊類頁面，以及使用者點樣由一頁去到下一頁。
設計數據庫之前，要先講清楚「一筆資料代表乜」
生活資訊往往同時涉及名稱、地點、時間、價格、交通、聯絡方式、來源同更新日期。如果只將 Agent 搜集到嘅文字直接塞入頁面，第一版可能睇落完整，但之後好難查重、更新或者知道邊句資料從何而來。
筆者定義最核心嘅資料實體，再為每一筆資料保存幾類欄位：
穩定身份：使用內部代號或者唯一識別碼，唔好因為顯示名稱改動就變成另一筆資料。
結構內容：名稱、分類、地區、地址、時間、狀態同其他可以搜尋或篩選嘅欄位分開保存。
來源紀錄：保存來源名稱、原始連結、取得日期同最後核對日期，方便追查同更新。
發布狀態：將原始、待核對、已批准、已發布同已下架分開，避免未審內容直接出街。
版本與變更：重要修改要知道由邊個流程產生、改咗乜，同埋必要時可唔可以回復上一版。
當數據模型清楚，Frontend、搜尋、SEO 同內容更新先有共同基礎。Agent 遇到缺失資料時亦唔應自行作假填滿；較可靠嘅做法係保留空值、標示待核對，或者將記錄送入人工審核清單。
Frontend、Backend 同 Database 唔係三份互不相干嘅功課
Frontend 負責使用者見到同操作嘅部分；Backend 負責讀寫資料、驗證規則、權限同業務流程；Database 保存網站嘅狀態。三者之間需要一份清楚契約，例如每個 API 接收乜、回傳乜、欄位類型係乜、錯誤時點樣表示。
筆者唔會叫 Agent 一次過分別完成整個前台、後台同數據庫，再到最後先嘗試接駁。較穩陣嘅方法係先做一條 vertical slice：由一筆測試資料開始，經 Backend 讀取，喺 Frontend 顯示成一個可用詳情頁，再經管理流程修改，最後部署到測試環境。
當呢條最短路徑真正行得通，先逐步加入清單、搜尋、篩選、更多內容類型同管理功能。咁樣每一輪都有可見成果，亦容易知道錯誤出喺資料、介面、程式定部署，而唔係面對幾十個同時未完成嘅模組。
一個主要 Agent 點樣協調多個 sub-agents
較大型任務入面，筆者會用一個高能力(i.e. 貴)主要 Agent 負責維持 project brief、架構決定、待辦清單、依賴關係同驗收標準，再將界線清楚嘅工作分配俾唔同 sub-agents。
研究 Agent：整理同類網站、資料來源同使用者問題，交付有證據嘅研究摘要。
資料 Agent：抽取、清理、去重同驗證資料，輸出符合 schema 嘅記錄同例外清單。
Backend Agent：建立數據模型、API、權限規則同管理流程，並附測試。
Frontend Agent：按照已批准 wireframe 同 API 契約建立頁面、互動同響應式版面。
測試與審核 Agent：執行測試、檢查回歸、挑戰假設，同埋列出未通過項目，而唔係只負責讚成。
sub-agent 之間最好唔係靠無限對話交接，而係靠具體 artifacts：研究表、schema、程式修改、測試報告、畫面截圖、來源清單同決策紀錄。每份交付都要有輸入範圍、完成定義同未解決問題，主要 Agent 先可以知道下一步係合併、退回定重新規劃。
模型亦唔需要一律用最昂貴版本。架構取捨、複雜除錯同最終審核可以交俾推理能力較強嘅模型；資料格式化、重複轉換同大批量初步分類，就用速度較快、成本較低嘅模型。模型選擇本身都係工作流程設計。
一次過生成全站，通常只適合示範
AI 可以喺短時間內生成一個睇落完整嘅網站，呢種能力好適合做概念展示。但真正項目需要考慮資料更新、錯誤狀態、手機版、權限、測試、日誌、備份同日後修改。畫面出到嚟，唔等於系統已經完成。
筆者將工作拆成細小版本，每次只處理一個清楚範圍，保存版本紀錄，通過驗收先合併。每項功能至少要有以下幾類標準：
功能：正常情況下完成預定任務，輸入同輸出符合規格。
資料：欄位完整性、類型、來源同更新日期通過驗證，異常資料唔會靜靜流入公開頁面。
例外：空結果、網絡失敗、重複提交、權限不足同外部服務失效都有清楚處理。
介面：手機同桌面可用，文字層級、鍵盤操作、圖片替代文字同基本可讀性有檢查。
部署：測試環境通過、設定齊全、有回退方法，公開後亦可以確認真正版本同健康狀態。
呢個做法未必有「一句 prompt 整好全站」咁吸引，但每次改動都比較細、可理解同可回復。Agent 出錯時，我要處理嘅係一個有限問題，而唔係重新猜測成個網站點解壞咗。
AI 寫到程式，唔代表程式可以直接上線
大型語言模型產生程式同文章一樣，都可能出現局部合理、整體有漏洞嘅結果。佢可以引用不存在嘅函式、忽略邊界情況、誤解資料類型，或者修正一個錯誤時破壞另一個功能。
因此，筆者將可以客觀驗證嘅部分交俾固定工具：formatter 同 lint 檢查格式；unit tests 驗證小功能；integration tests 驗證 API 同數據庫；end-to-end tests 模擬使用者完成核心路徑；資料檢查則驗證 schema、重複項目、空值同來源。
測試 Agent 可以協助找反例同補測試，但唔應該由同一個 Agent 自己定要求、自己寫程式、再自己宣布通過。驗收標準最好喺開工前寫低，重要功能亦要有獨立審核同少量人工實測，避免所有角色共享同一個錯誤假設。
AI 輸出可以每次有少少不同，固定測試就係將呢種不確定性鎖喺可接受範圍。可以由程式驗證嘅，唔好只靠睇落順眼；未能驗證嘅，就要明確標示風險同由人判斷。
部署唔係最後撳一下 Publish
網站喺自己電腦運作，同公開俾其他人使用係兩回事。筆者將 local、staging 同 production 分開：本地用嚟開發，staging 用真實流程測試，production 先係正式環境。設定、數據同權限亦唔應該混埋。
API keys、數據庫密碼同部署憑證要放喺受控秘密管理或環境變數，唔好寫入程式碼、prompt、一般日誌或者 Agent 長期記憶。Agent 只應取得完成當前工作所需嘅最低權限，而且讀取、修改、發布同管理帳單最好分開。
筆者透過 API 將 Cloudflare 等服務連接到 Agent，用自然語言要求佢檢查 DNS、快取、部署或者其他設定。不過，涉及網域轉移、權限提升、付款、刪除資源同保安設定時，仍然要先產生變更計劃同差異，再由人確認。
正式上線亦要有日誌、健康檢查、備份同 rollback。Agent 報告「部署成功」只代表命令完成；真正完成係公開網址可用、核心頁面讀到正確資料、舊版本可以回復，而且異常時有人收到通知。
SEO 同 GEO 唔應該等網站完成先補做
搜尋同內容發現能力由資訊架構開始。每頁要有清楚目的、穩定網址、準確標題、合理 heading 層級、內部連結、圖片替代文字、來源同更新日期；頁面速度同手機體驗亦會影響使用者係咪願意繼續睇。
筆者喺項目入面將 GEO 理解為：除咗方便傳統搜尋引擎索引，亦令生成式搜尋同 AI 助手較容易理解內容、分辨實體、找到原始依據同引用正確段落。做法唔係重複堆關鍵字，而係用清楚定義、結構化欄位、可追查來源同一致頁面模板減少歧義。
AI 最容易做嘅係大量生成頁面，但數量唔等於價值。冇新資料、內容重複、來源不明或者長期唔更新嘅頁面，只會增加維護負擔。發布規則應該先問一頁有冇獨立用途、證據夠唔夠、同現有內容有咩分別，再決定係咪建立。
小結
完成呢個項目之後，筆者更明白點解一個人配合 AI Agent，今日已經可以做出以前需要幾個角色合作先完成嘅原型。研究、資料、程式、測試、內容同部署之間嘅等待時間大幅縮短，夜晚亦可以由 Agent 執行檢查，第二朝再交結果俾筆者。
但人唔係因此變得冇用，而係由逐項執行，轉為同時擔任產品負責人、編輯、驗收者同權限管理者。筆者要決定服務邊個、相信邊啲資料、接受咩風險、邊個版本可以公開，以及出問題時由邊個負責。
AI 可以放大好流程，亦可以放大錯方向。如果定位一開始就錯、資料來源唔可靠或者驗收標準太鬆，多個 Agent 只會更快製造更多程式同內容。所以，一個人加 AI 唔係自動等於一隊成熟團隊；資訊保安、法律責任、品牌、專業設計同複雜工程，仍然需要相應專業。
建立嘅唔只係一個網站
網站上線只係其中一個結果。更有價值嘅係背後形成咗一套可以重複使用嘅生產系統：project brief、研究格式、資料 schema、Agent 角色、驗收標準、測試、部署流程、權限邊界同決策紀錄。下一個項目唔需要再由空白開始。
當網站骨架、數據同發布流程穩定之後，下一個問題就唔再係「點樣整到出嚟」，而係「點樣持續有用」。文字、圖片、影片、社交媒體、使用者查詢同網站數據，全部可以連成另一個循環；但同樣需要來源、品牌規則、人工審核同停止條件。
下一篇會由網站內容開始，講 Agent 點樣協助製作同發布，再由客戶查詢、搜尋同使用者行為找出缺口，逐步建立一個會根據真實回饋改善嘅營運系統。
下一篇
由內容生產到客戶回饋：建立自我改善嘅網站循環
下一篇會講 Agent 點樣根據資料同寫作規則產生文字、圖片同影片，安排社交媒體內容，同時從電郵、搜尋同使用者行為收集回饋；再透過分析、A/B 測試同人工審核，將一次性網站變成可以持續更新同改善嘅營運系統。