2026 年 3 月，我們全面更新了 moonshot.ai 的平台體驗。這次更新看似簡單：全新的色彩配置、更緊湊的字體排版，以及更新後的動態效果；實際上，它牽動了整個網站的共用元件、設計 token、路由與互動層。
我們使用由 Kimi K2.5 驅動的 Kimi Code CLI 作為 AI 程式設計 agent，協助完成這次重建。這個專案成了一次實戰檢驗：終端機型 agent 如何融入真實的正式環境工作流程，而不是只在示範環境中運作。本文將分享我們的使用方式，以及一路上的心得。
這次更新真正要解決的事
moonshot.ai 這次更新，並不是要從零開始重新設計品牌。大部分設計工作早已在 Figma 中完成；真正的挑戰，是把這些更新一致地套用到既有程式碼庫。
這意味著我們得追蹤共用 token、更新元件、檢查互動行為，並確保分析與無障礙功能不受影響。許多變更單看都很小，卻橫跨了網站的多個層次。
這類工作難的不是演算法複雜度，而是範圍與一致性。挑戰在於知道一次變更會影響哪些地方，並確保沒有遺漏。為此，我們透過 Model Context Protocol (MCP) 連接 Figma，讓設計規格與實作更容易對齊，協助 agent 理解結構並減少人工判讀。
基本規則：讓 agent 真正派上用場
第一步不是撰寫提示詞，而是建立脈絡。我們使用 /init 指令產生 AGENTS.md 檔案，接著花了約一小時加以調整。文件中記錄了這次更新的範圍、不可變更的內容、專案結構，以及建置流程的運作方式。我們也新增了一份規則檔，涵蓋命名慣例、間距與對比需求。
這樣的設定減少了後續反覆說明的需要，也讓 Kimi Code CLI 的工作流程更加一致。若缺少專案脈絡，AI 程式設計 agent 通常會產出合理但泛用的結果；有了脈絡後，它的表現就更接近一位已經熟悉程式碼庫的隊友。
我們實際上怎麼使用它
本節說明 Kimi Code CLI 在這次更新中的實際用法，涵蓋相依關係追蹤、設計對齊、行為研究、效能檢查與整合風險審查。重點不在自動化，而是在大規模重構中降低不確定性。
理解變更會影響哪些地方
在動手編輯前，我們會請 Kimi Code CLI 中的 agent 讀取目標區域，並列出還有哪些地方依賴它。一次單一變更——例如按鈕顏色——可能會影響 hero 區塊、下載區塊、hover 狀態與共用 token；共用元件、動態時序與分析 hook 還可能進一步擴大影響範圍。先取得相依清單，能減少後續意外，也讓修改更可預期。
讓程式碼對齊設計規格
接著，我們逐段將元件與設計規格比對：hero、導覽、產品區塊、下載 CTA 與頁尾。agent 會透過比對樣式與設計 token、版面配置值，產出屬性層級的變更清單。這個流程更像結構化的設計系統自動化，而不是人工目視檢查。 多數差異都很小，例如間距、圓角或字重；但偶爾也會浮現較大的不一致，像是原本應該共用變體的元件，隨著時間逐漸分歧。最後得到的是一份具體的修改清單，而不是憑視覺猜測。
研究新的互動行為
這次更新導入了程式碼庫過去未實作的新 UI 行為：自訂游標、由執行階段驅動的 hero、hover 時播放的插圖卡片，以及捲動觸發的進場效果。
針對每項功能，我們把文件與 repository 狀態一起載入，將 Kimi Code CLI 作為具備脈絡的環境使用。這也是 Kimi K2.5 發揮作用的地方：更長的 context 讓我們更容易在同一處同時推理實作與參考資料。
問題都很實際：
hover 動畫在離開時應該播放完畢，還是取消？
游標狀態是否應與 hero canvas 互動？
多個層疊區塊重疊時，哪些地方會出問題？
大型 context window 讓 Kimi Code 工作流程更連貫，設計意圖與程式碼可以留在同一個 session 中。
檢查體積與效能
這次更新導入了新字體、更多動態效果與額外素材，因而增加了頁面體積。我們使用 agent 調整既有的字體子集化 script 並驗證輸出；之後它也協助解讀 Lighthouse 報告，讓我們能及早找出退化。目標不是到最後才一次最佳化所有內容，而是在變更仍然很小時，就能決定哪些保留、哪些刪除。
合併前追蹤整合風險
多個互動層——進場動畫、游標、hero canvas——雖然位於不同元件，卻共用排序與指標行為，因此某一層的變更仍可能影響其他層。我們也必須考量跨瀏覽器與跨 OS 差異，因為 CSS 與渲染行為不一定總是相同。 在合併成批變更前，我們會把 diff 餵給 Kimi Code CLI，請它追蹤哪些互動可能受到影響，接著在瀏覽器中檢查這些路徑，並在不同環境中做一次輕量檢視。
MCP 整合與 Skills
Model Context Protocol (MCP) 讓 Kimi Code CLI 能直接連接到含有專案資料的外部系統。我們使用 mcp Figma，直接從 Figma 擷取設計 token、版面資料與字體排版，減少設計與程式碼之間的人工轉譯；同時也連接內部工具，在不切換脈絡的情況下呈現任務、規格與邊界案例。
加入伺服器只需要一行指令：
這個模式可套用到整個 MCP 生態系。若需要靈感，你可以將 agent 連接到：
Figma — 官方 MCP，可從畫布取得設計脈絡、變數與版面資料
Atlassian Cloud — 透過 Atlassian 的遠端 MCP 進入點（與 Rovo 一併記錄）存取 Confluence 頁面與 Jira 工作項目
資料庫、CMS API — 供應商或社群提供的 MCP 伺服器；登錄目錄按類別列出數百種選項
你的技術堆疊可能不同——可能是私有文件 API、內部設計 token 服務，或資料倉儲。但概念相同：把 agent 連接到已經存放相關資料的系統。若想了解設定檔、伺服器定義，以及在 Kimi Code CLI 中串接 MCP 的其他方式，請參閱平台指南。
程式碼審查 Skill
我們也為程式碼審查撰寫了一個 Skill。它是一份規則檔，告訴 Kimi Code CLI 如何端到端評估 merge request：讀取 diff、追蹤受影響的檔案與元件、檢查設計系統違規（原始色彩 literal、間距未對齊網格、缺少無障礙 fallback）、依區域評估風險，並產生結構化報告。
報告採用固定格式：
意圖與範圍摘要
依嚴重程度分組的發現（阻擋合併的重大問題、建議改善項目、輕微一致性建議）
每項發現皆包含：diff 中的證據、影響評估，以及具體行動項目
Skill 也會標記可能需要快速透過瀏覽器或裝置驗證的潛在風險——也就是 agent 不確定，但驗證成本很低的情況。
實務上，moonshot.ai 視覺更新期間的每個 PR，在完成審查前都會經過這道結構化檢查。輸出一律包含意圖回顧、依嚴重程度排序的發現、證據與修正建議。
這有助於減少後期反覆修改，並提升 Kimi Code 工作流程的一致性；它也能浮現諸如共用常數旁的硬編碼 URL、需要對齊的分析欄位，以及行動裝置互動邊界案例等問題。
出乎我們意料的事
重構期間，幾個一開始並不明顯的模式逐漸浮現。
從規格到程式碼，比我們預期更快
當 Figma MCP 與 Kimi Code CLI 位於同一個 thread 中時，尺寸與設計 token 會以結構化輸入進來，而不是靠人工轉錄。結果是每個區段的迭代迴圈更短——屬性層級的變更與修正通常一次就能完成，不必在工具之間來回切換。
研究型提示詞帶來的回報超出預期
這次更新高度仰賴長時間、以文件驅動的檢查：把執行階段文件、參考實作與 repository 並排審視。事實證明，讓這些材料與程式碼留在同一個 session 中，往往和實際修改本身一樣有價值。
審查 Skill 把零散不一致整理成清單
結構化報告浮現了前面提到的同類問題——共用常數旁的硬編碼 URL、需要對齊的分析欄位，以及行動裝置互動邊界案例。多數問題單看都很小，但彙整成一次檢查後就更容易處理。
長 thread 重新接續的成本很低
像 kimi --continue 和 /compact 這類指令，讓跨多日的工作不需要每天早上重新建立 context。這減少了重複撰寫提示詞，也讓同一套 Kimi Code 工作流程能穩定推進。
若想進一步了解如何恢復 session、在 session 之間切換，以及使用 /compact 與相關指令管理 context，請參閱 Kimi Code CLI session 指南。
重建 moonshot.ai 得到的經驗
如果要再次進行類似的 moonshot.ai 視覺更新，有幾件事我們會採取不同做法。
先建立脈絡，而不是先寫程式碼
一開始花一小時記錄範圍、限制與慣例，比後續任何提示詞都更省時間。事先建立這些內容，能讓 Kimi Code CLI 這類工具在整個工作流程中表現得更一致。
及早連接真實來源
就我們而言，那是 Figma；在其他專案中，可能是 CMS、內部 API 或設計系統。關鍵是確保系統使用真實資料，而不是推測式假設，尤其是在前端重構情境中使用 AI 程式設計 agent 時更是如此。
讓設計與任務脈絡維持在同一個迴圈
把 token、規格與實作帶入共享脈絡，減少了來回溝通，也讓迭代週期更穩定。這正是包含 Figma MCP 與 Kimi Code CLI 的工作流程特別有效之處：它們能在同一個連續迴圈中，讓設計意圖與程式碼變更保持一致。
如果你不想寫程式碼：Kimi Websites
以上描述的是以開發者為中心的工作流程——終端機、diff 與 context 檔案。不過，當速度比框架層級的控制更重要時，也可以不使用這套技術堆疊，達成同樣的成果：一個精緻且具響應式設計的網站。
Kimi Websites 採用相同的 Kimi K2.5 模型，但透過視覺化、無程式碼介面運作。你可以用自然語言描述需求，透過對話調整各個區段，並一鍵發布。它也能以既有截圖作為輸入，重建版面結構。
對於正在製作 landing page 原型的創辦人，或需要在緊迫時程內推出活動網站的行銷人員而言，這比直接使用傳統前端技術堆疊更快。
結論
Kimi Code CLI 與 Kimi K2.5 在專案中最有幫助的地方，是那些廣度比複雜度更重要的部分。視覺更新很少是在解決艱深問題；更多時候，是大量細微變更必須在整個系統中保持一致。這對人來說耗時費力，卻相當適合能跨檔案追蹤與比對的 agent。
決策仍由我們做出；每項變更也都由我們審查，並驗證最終結果。agent 負責重複性的追蹤、比對與初步審查工作。實務上，這樣的分工證明是一種將 AI 程式設計 agent 納入正式環境工作流程的可行方式。對於跨檔案重構、設計到程式碼的驗證，以及大規模一致性工作，這套做法確實有用。