令呢套系統運行起來令我自己都要花時間排錯，唔係因為任何單一步驟特別難，而係因為手動路線假設你已有一個乾淨嘅 config file、一個最新嘅 Node 版本，同一個在唔符合前兩者時願意自己修正問題嘅開發者。
按類別揀選工具係一個真正嘅優點，比單一捆綁權限授予更精準。
一旦連接好，就要預期佢會審慎而唔係快速。每次工具呼叫都要等你確認，如果你正密切監察，呢個正正係你想要嘅；如果你唔係，佢就會拖慢你。
如果你正在讀這篇文章，你大概是在嘗試回答一個特定問題：你可唔可以真正信任一個 AI 編碼代理去管理你嘅 Hostinger 實際帳戶，以及如果唔依賴預建擴充功能，要點樣連接一個。
我正正就係測試咗呢件事。Hostinger MCP 係一個整合，讓 Claude Code、Cursor 同 Codex 等 AI 工具透過 Model Context Protocol 連接到 Hostinger 服務。
Hostinger Connector 係進入呢個整合嘅其中一種方式，一個一鍵、基於 OAuth 嘅 VS Code 擴充功能。我喺呢度冇測試 Connector。我測試咗直接喺 hPanel 生成 API token，然後手動將佢接入 Claude Code，呢個就係如果你使用 Claude Code、JetBrains，或者任何冇專用擴充功能嘅客戶端時要走嘅路線。
我建立咗一個叫 LinkSnap 嘅小型短連結應用程式，將佢連接到一個真實嘅 Hostinger 帳戶，並且帶佢走過帳戶讀取、部署目標發現、一次實際部署、一次刻意失敗，以及復原。
我哋嘅 Hostinger Connector review 會涵蓋呢個基於 OAuth 嘅擴充功能點樣實作相同嘅底層協議，以及佢自己獨立得出嘅發現。
以下係我根據 Hostinger MCP 喺幾個關鍵方面嘅表現所作嘅評分，呢啲方面對於你判斷手動設定值唔值得花時間最重要：成本、你實際可用嘅功能、設定有幾麻煩、執行是否正確，以及當你需要支援時支援做得好唔好。
| Parameter | Score | Why This Score |
|---|---|---|
| Prices | 9.7/10 | MCP 本身唔使你額外付費，並且適用於你已經擁有嘅任何 Hostinger 計劃。 |
| Features | 9.3/10 | 手動設定讓你可以逐個啟用工具類別，Websites、Domains and DNS、Subscriptions and Payments、Email Marketing、VPS 同 Ecommerce，每一個都會成為自己獨立嘅連接，而唔係一個捆綁式權限授予。 |
| Setup and Authentication | 7.8/10 | Token 生成得好快，但如果你嘅 config file 已經有內容，你就要自己處理，而我喺真正接觸 hPanel 之前已經遇到過陳舊嘅 Node 版本同殘留嘅全局路徑。 |
| Execution Accuracy | 9.2/10 | 帳戶讀取發現咗兩個已經靜默過期嘅 hosting 訂單，而目標發現則以真實、可核查嘅理由排除咗兩個現有候選，而唔係亂估。 |
| Support | 9.0/10 | Kodee 用四輪對答、約兩分鐘內，準確回答咗一個真實嘅雙向術語問題。 |
| Overall | 9.0/10 | 一種更透明、更加手動嘅方式去將 AI 代理連接到你嘅 Hostinger 帳戶，而部署流程喺我刻意造成失敗之後仍然保護咗一個實際網站。 |
你唔會搵到 Hostinger MCP 嘅定價頁，因為根本冇。佢唔係一個你可以單獨買嘅產品。
如果你啟用手動設定路線，你可以喺打開 AI 客戶端之前就揀好佢可以見到邊啲工具類別，而你啟用嘅每一個類別都會變成設定檔入面一個獨立條目，而唔係一個大而全嘅工具集。
Hostinger 亦有記錄底層 API 嘅預設速率限制：每分鐘 60 個請求、每小時 1,000 個請求，而目前用量會喺回應標頭中返回。
就呢種評論所涵蓋嘅互動式、一次一件事嘅工作而言，我從來都冇接近任何一個上限。如果你打算做更自動化嘅事，例如一個無人監督運行嘅腳本，而唔係一個等待你批准嘅代理，呢個就係你設計時要考慮嘅真實數字。
如果你想判斷自己是否真係可以順利完成手動設定，理解點解呢一節同一般嘅易用性評論完全唔同會有幫助。
Hostinger MCP 本身冇要你建立嘅帳戶、冇註冊表格，亦冇首次登入時可以遊覽嘅儀表板。佢係疊加喺你已經有嘅 Hostinger 帳戶同 hosting 計劃之上。由於冇任何需要註冊嘅嘢，所以唔存在註冊步驟。
喺呢度，「易用性」其實係指連接過程本身， 即係將一個你本來已經可以登入嘅帳戶變成 AI 代理可以看見並採取行動嘅帳戶。呢個就係點解呢部分會直接講生成存取權，而唔係由註冊畫面開始。
手動設定亦唔綁定單一客戶端。Hostinger 列出咗：
我揀咗 Claude Code ，因為佢係喺終端機入面運行，而唔係 IDE 側邊欄，再加上佢冇自己專用嘅 Hostinger 擴充功能，所以手動、基於 token 嘅路線就係唯一進入方式，亦令呢個路線嘅測試最乾淨。
有一個前置條件甚至早於 Hostinger 本身，而呢個條件係視乎你揀咩客戶端而定。Claude Code 本身需要 Node.js 22 或以上版本先可以運行。我自己部機仲係用緊之前一個項目留下嘅舊版本，所以我喺未接觸 hPanel 之前就已經撞到 engine warnings 同壞掉嘅安裝。呢唔係 Hostinger 嘅問題，但如果你嘅開發機唔係已經更新，呢個就係一個真實嘅時間成本。
當 Claude Code 真正運行之後，我轉去 hPanel 嘅 API 頁面，呢個頁面而家係直接圍繞 MCP 建構。
頁面頂部列出六個客戶端，VS Code、Cursor、Devin Desktop、Antigravity、Claude Code 同 Codex，而 VS Code 會有一鍵 Connector 擴充功能，其他每個客戶端，包括 Claude Code，都要走手動路線。
生成 token 本身所需嘅嘢好少：
最後一點如果你重視存取控制就好重要。佢唔係喺 token 上設定。佢係喺前一步設定，即係你揀到底要向 AI 客戶端暴露邊啲工具類別，而我就係去到嗰度。
| Detail | Result |
|---|---|
| Fields required to generate a token | Name and expiration only |
| Scope selection on the token itself | None |
| Token visible again after leaving the page | No, shown once |
| Token table tracks | Name, created date, last used, expiration |
下一步，喺任何 config file 存在之前，hPanel 會叫我揀選呢個連接會暴露邊啲工具類別：
我只啟用了 Websites，因為咁已經足夠應付 LinkSnap 所需嘅一切。你每啟用一個類別，佢就會變成生成出嚟嘅 JSON 入面一個獨立項目，每個都有自己嘅 command 同 package name，但全部都指向同一個 token。呢度就係手動路線真正優於單一捆綁權限畫面嘅地方：你喺 AI 客戶端打開之前就可以決定佢可以接觸嘅內容形狀，而唔係之後先決定。
然後就到咗真正耗我時間嘅部分。hPanel 會提供一段現成嘅 JSON 代碼塊同埋一個檔案路徑，Linux 上係 ~/.claude.json ，並叫你將佢貼上去。
我嘅檔案已經有之前一次設定嘗試留下嘅條目。將新區塊直接貼入而唔合併，結果令我有兩個頂層物件，而 JSON 係唔合法嘅，Claude Code 亦因此無法啟動，直到我親手將檔案改寫成一個物件為止。
當 config file 終於有效之後，最後一步就係令 Claude Code 本身讀取到佢。呢度你需要另一個獨立嘅 Claude 登入，完全同 Hostinger token 分開，因為 Claude Code 係透過 Claude 訂閱或者 API 計費運行。相比起一個只係重用你可能已經登入緊嘅 session 嘅瀏覽器擴充功能，呢個確實多咗一步。
過咗呢步之後，連接喺第一次重新啟動時就順利運作。直接問 Claude Code 佢有咩 Hostinger 工具可用，佢返回咗一份完整、正確分組嘅列表，正好同我啟用嘅嗰個類別一致。
| Check | Result |
|---|---|
| Claude Code login required, separate from Hostinger | Yes |
| Connected on first restart after fixing the config | Yes |
| Tool list returned matched the enabled category | Yes |
| Per-tool-call confirmation required by default | Yes, on every call |
最後一行會形塑你之後嘅整個體驗。Claude Code 每次做工具呼叫，例如列出網站、檢查建置、執行 shell 命令，都會先停低問你係定唔係，除非你開啟自動批准。
我喺整個測試期間都保留逐項批准，去真實了解其成本，而單係一次部署同復原流程就需要我超過十幾次獨立批准。
再提醒你一件事，在你將任何真實工作交畀呢個系統之前要知道：呢度完全冇 sandbox。你批准嘅每一個命令，都會即刻作用喺你嘅實際帳戶同實際 hosting。
中間冇任何模擬環境擋住一次提示同一次真實變更之間，所以一次錯誤批准就係真嘅。
按類別揀選工具係一個真正嘅優點，比單一捆綁權限授予更精準。
一旦連接好，就要預期佢會審慎而唔係快速。每次工具呼叫都要等你確認，如果你正密切監察，呢個正正係你想要嘅；如果你唔係，佢就會拖慢你。
你已經知道 config file 可以連接到系統。你真正想知道嘅，係另一端嗰樣嘢究竟係咪真係做得到實際嘅 hosting 工作，所以我建立咗 LinkSnap，一個細小嘅 Express 應用程式，並將佢帶過完整嘅部署生命週期。
| Test | What I Wanted to Learn |
|---|---|
| Read account data | Does it report your account accurately? |
| Find a deployment target | Does it guess, or does it check first? |
| Deploy LinkSnap | Can it move a real app from local to live? |
| Verify the live app | Does it trust its own success claims? |
| Break the app on purpose | What does the platform do with a bad build? |
| Recover the app | Can it restore a known-good version cleanly? |
LinkSnap 嘅 health endpoint 喺之後成為關鍵，原因係平台可以話建置完成，但你嘅應用程式其實根本未啟動。
獨立查詢一個 live endpoint 係唯一可以驗證呢件事，而唔係只係信一個狀態標籤。
我叫 Claude Code 在冇任何提示之下列出帳戶上每一個網站同所有活躍 hosting 計劃。
呢個帳戶有真實複雜度：一個訂單底下有十七個網站，另一個訂單底下有兩個，而另外兩個網站則屬於已經唔再顯示為活躍嘅訂單。
| Check | Result |
|---|---|
| Total websites listed | 21, matched hPanel exactly |
| Active plans identified | 2, matched hPanel exactly |
| Expired-order sites flagged without being asked | Yes, both correctly identified |
佢唔只係列出我要求嘅嘢。佢察覺到兩個網站屬於喺活躍列表中消失咗嘅訂單，標記佢哋好可能已被停用，而我之後喺 hPanel 入面獨立確認兩者都已過期。
呢個唔止係檢索，係你嘅帳戶被審核，而唔係只係被讀取。
呢個測試最能說明你可唔可以信得過呢樣嘢去處理一個實際帳戶。
我叫佢喺冇提供任何域名提示嘅情況下，判斷我係咪有一個可用於 LinkSnap 嘅 Node.js 網站。
| Step | What Happened | Result |
|---|---|---|
| Checked first existing Node.js site | Found an active deployment already in use | Correctly ruled out |
| Checked second existing Node.js site | Found it tied to an expired order | Correctly ruled out |
| Proposed a new site | Under the correct active order | Accurate |
| Asked before acting | Offered a free subdomain or a custom domain | Passed |
我揀咗免費子域名。佢生成咗 floralwhite-ferret-411142.hostingersite.com 並喺正確嘅訂單底下建立咗網站，而我之後亦喺 hPanel 確認過。
全部都一致。
喺確認好目標之後，我將 LinkSnap 打包成 zip 壓縮檔，然後叫 Claude Code 去部署。
主要部署工具喺第一次嘗試時失敗咗，錯喺上載步驟。
佢冇盲目重試，而係先檢查網站儲存空間係唔係真係可達，排除咗呢個原因，然後轉用另一個方法：要求直接上載 URL、將壓縮檔推送過去，再分開觸發建置。
| Step | Result |
|---|---|
| Primary deploy tool | Failed at upload |
| Storage reachability check | Passed, ruled out as the cause |
| Fallback method | Manual upload URL plus separate build trigger |
| Fallback result | Succeeded |
| Self-verification after “build complete” | Ran its own live request, confirmed HTTP 200 |
| My independent check | Homepage and health endpoint both responded correctly |
部署工具第一次失敗係一個真實弱點，我想講得清楚啲。令佢唔至於成為壞結果嘅，係之後發生嘅事：真實診斷、可用嘅替代方案，同埋唔係淨係信狀態徽章，而係實際做 live 檢查。
如果你問我當出問題時會發生咩事，呢一節就係你真正想睇嘅。
我叫 Claude Code 先備份運作正常嘅 package.json，然後將 start command 改去指向一個根本唔存在嘅檔案。
佢唔可以直接編輯 live app 嘅檔案，因為已部署嘅 Node.js app 並冇提供檔案編輯工具。
佢冇偷偷繞過呢個限制，而係向我解釋咗呢個限制，改為根據我本地檔案操作，顯示出確切嘅單行變更，並且喺任何操作之前都等我確認。
| Test | Result |
|---|---|
| Backup created before changes | Yes |
| Exact change shown before applying | Yes |
| Broken build deployed | Build reported failed |
| Live app during the failed build | Stayed up, serving the working version |
| Live app after an explicit restart | Still serving the working version |
| Restore from backup | Passed |
| Redeploy of clean version | Completed, after one retry |
| Final verification | HTTP 200, healthy response confirmed |
呢個係呢篇評論入面最重要嘅發現。平台冇默默接受一個壞嘅部署。佢拒絕咗壞建置，並喺整個過程中保持我最後一個已知正常版本一直運行，無論係重啟之前定之後。
唯一真誠嘅缺口： 建置日誌只顯示成功安裝依賴，冇顯示實際缺少檔案嘅錯誤，所以如果真係有失敗原因，你仍然要去其他地方搵。
仲有一件細事你都應該知道，喺呢個測試中段，Claude Code 提及咗一個同呢次 session 完全無關嘅舊項目名稱。呢件事冇影響結果，但我覺得有必要提一提，而唔係隱瞞。
最明顯嘅弱點係主要部署工具本身，因為我做咗兩次嘗試都失敗，兩次都要用手動後備方案。
如果你自己設定時卡住，以下就係你向 Hostinger 求助時實際會發生嘅事。
| Channel | Availability | Notes |
|---|---|---|
| Live chat (Kodee, AI) | 24/7 | 運行喺本評論所涵蓋嘅同一個 Model Context Protocol 上，而 Hostinger 文件寫明佢可以執行真實帳戶操作，而唔係只係答問題 |
| Live chat (human) | Escalation from Kodee | 可喺同一個聊天視窗內按要求升級處理 |
| Knowledge Base | Self-service | support.hostinger.com |
我問咗 Kodee 一條有真實雙面答案嘅問題：Hostinger MCP 係咪一個可以單獨購買嘅產品，以及佢同 Hostinger Connector 究竟有咩關係。
你唔可以單靠複製一段文件內容去回答呢個問題，因為呢條問題需要正確區分一個協議同其中一個特定實作。
| Question | Kodee’s Answer | Assessment |
|---|---|---|
| Is MCP the same as Connector | No, MCP is the broader integration, Connector is one recommended OAuth-based setup method | Correct and precisely scoped |
| Is MCP itself purchasable | No, not a separate product or subscription | Correct |
| Where to find the API token | Account, then API or Dev Tools, generate, name it, set expiration, copy immediately | Correct and specific |
| What environment variable to use | Named the token variable directly, noted Connector as the alternative that skips it | Correct |
成個對話，四條問題四個答案，根據時間戳記睇，歷時大約兩分鐘。
我唔需要反駁、改寫，或者升級一次。好多 AI 支援工具只會答到雙重問題入面容易嗰一半，但遇到較難嗰一半就會變得含糊。呢次 Kodee 冇咁做。
Hostinger 嘅知識庫以廣泛分類方式組織：Getting Started、hPanel、AI Builder、Domains、DNS、Files Management、Email、MySQL Databases、Website、VPS、Agency Hosting Plans、Reach、SSL、PHP、Profile Management、Billing、Affiliates and Referrals、Features、cPanel 同 About Hostinger。
入面冇任何一類係專門為 MCP 而設，所以如果你按分類去搵，就唔會咁樣搵到。
不過，如果直接搜尋「MCP」，你就可以搵到。嗰次搜尋返回咗二十個結果，最相關嘅兩篇文章，即 WordPress 專用 MCP 設定同本地 IDE 設定，喺最上面。
排喺下面嘅幾個結果就只係間接相關，多數係其他 AI 代理產品，只係順便提到 MCP。
我直接打開咗同呢篇評論設定相符嘅文章：「How to set up web hosting MCP on Local IDEs。」呢篇文章其實做得相當好：
你要知道嘅一個缺口係，呢篇文章嘅手動教學用 Cursor 做示例，而唔係 Claude Code，即使 Claude Code 係官方列出嘅客戶端之一。
實際上呢點冇拖慢我，因為 hPanel 自己嘅 API 頁面直接生成咗一個 Claude Code 專用嘅檔案路徑同 JSON 區塊，而呢個結果比文章嘅示例更新。
如果你只靠文章本身而又用 Claude Code，你就需要自己將 Cursor 特定步驟作出調整。
唯一真正嘅缺口係旗艦設定文章以 Cursor 作示例，所以如果你用 Claude Code，你會得到準確但唔係專為你而寫嘅指引。
值得。唔係因為設定過程一直都好順利，事實上唔係，但係因為當我將一個 AI 代理賦予一個實際帳戶嘅真實存取權，然後再刻意嘗試破壞一切時，之後發生咗咩事。
帳戶讀取喺冇被要求之下發現咗兩個已經靜默過期嘅 hosting 訂單。目標發現以真實、可核查嘅理由排除咗兩個不適合嘅網站，而唔係亂估。我刻意破壞嘅部署管線拒絕咗一個壞建置，並且喺整個過程中保持你嘅網站運行。
整篇評論入面最令我印象深刻嘅，唔係任何一項功能單獨正確運作，而係佢哋背後共同嘅模式：先檢查，再行動，並且清楚講明自己無法驗證嘅地方。
同一種模式亦出現喺支援裡面，Kodee 針對一條真正雙重性質嘅技術問題，喺約兩分鐘內第一次就答啱咗。
呢唔代表呢係一個已經完成、毫無阻力嘅產品。主要部署工具喺我做嘅兩次嘗試中都失敗咗，兩次都需要用手動後備方案。
如果 config file 本身已經有內容，佢會喺我唔經意下壞掉，直到我親手重寫先至修好。而且喺整個過程中根本冇任何 sandbox，你每一次批准都會即刻作用喺你嘅實際帳戶上，呢點提高咗風險，而正正係同樣嘅謹慎，令結果變得可信。
如果你想要一個 AI 代理先檢查再行動，並且喺撞到限制時老老實實講明，Hostinger MCP 值得你花時間，而且你亦願意接受周邊工具仍然有啲粗糙。
如果你需要一個開箱即用、打磨得好順滑嘅方案，或者如果一個部署工具第一次就失敗係你無法接受而唔係可以繞過嘅粗糙位，咁佢暫時就未必值得你花時間。
| Description | Expert Review |
|---|---|
| 價格實惠的主機託管，具備高效能及簡易管理工具。 | Read Shared Hosting Review |
| 快速且安全的 WordPress 主機，提供一鍵安裝和高級功能。 | Read Wordpress Hosting Review |
| 可擴充的 VPS 主機託管，提供專用資源及 root 存取權限。 | Read VPS Review |
| 快速、靈活的雲端託管，提供卓越的正常運行時間及可擴展資源�... | Read Cloud Hosting Review |
| 在離岸數據中心位置提供安全及私密的主機託管方案。 | Read Offshore Hosting Review |
| 安全可靠的電郵託管服務，具備專業級功能。 | Read Email Hosting Review |
| 為開發人員提供靈活環境的可靠 Python 託管。 | Read Python Hosting Review |
| 高效能 PHP 主機託管，全面支援動態網站及應用程式。 | Read PHP Hosting Review |
| 可靠的 Windows VPS 主機託管，提供完整控制與自訂選項。 | Read Windows VPS Review |
| 為 Node.js 應用程式度身訂造的快速且靈活主機託管，提供最佳效�... | Read Nodejs Hosting Review |
| 為 WooCommerce 商店提供優化主機託管，具備高速和安全整合。 | Read Woocommerce Hosting Review |
| 專用伺服器託管，打造無縫的 Minecraft 遊戲體驗。 | Read Minecraft Server Hosting Review |
| 為數碼代理商及開發人員提供具可擴展性及進階功能的託管方案 | Read Agency Hosting Review |
| 為 Magento 電子商務網站優化的快速、安全主機託管。 | Read Magento Hosting Review |
| 高效能的 Linux 主機託管，確保網站運作穩定及安全。 | Read Linux Hosting Review |
| 強大可靠的 Java 主機託管解決方案，適用於動態網頁應用程式及�... | Read Java Hosting Review |
| 為電子商務網站提供優化主機服務，具備安全、快速及可靠的效�... | Read Ecommerce Hosting Review |
| 可靠的 Django 主機託管，提供高速效能及安全環境。 | Read Django Hosting Review |
| 易於使用的 cPanel 主機託管，具備強勁效能及可靠支援。 | Read Cpanel Hosting Review |
| 為企業提供強大的主機託管服務，具有高速、安全及可擴展性。 | Read Business Hosting Review |
| Easy-to-use website builder with drag-and-drop tools and customizable templates. | Read Website Builder Review |
| Optimized hosting for Joomla sites with one-click installation and reliable performan... | Read Joomla Hosting Review |
| Powerful hosting with full PostgreSQL database support for data-driven applications. | Read PostgreSQL Hosting Review |
| Flexible hosting with MongoDB integration for scalable, modern web applications. | Read MongoDB Hosting Review |
| AI-powered website creation platform for building professional sites in minutes. | Read Horizons Review |
| Reliable hosting for n8n workflow automation with easy setup and management. | Read n8n Hosting Review |
| VPS hosting with Docker support for containerized application deployment and scaling. | Read Docker VPS Review |
| 專用 SMTP 伺服器託管，提供可靠及安全的電郵傳送。 | Read SMTP Server Review |
| 為 Ruby on Rails 網頁應用程式度身打造嘅快速同經過優化嘅主機服�... | Read Ruby on Rails Review |
| 提供豐富功能嘅託管服務，整合 OpenClaw，用於建構同管理夾公仔�... | Read OpenClaw Review |
| 快速可靠嘅託管，配備英國本地伺服器，帶來最佳本地效能。 | Read UK Hosting Review |
| 價格實惠且可靠、設有印度伺服器的主機服務，可實現低延遲存�... | Read India Review |
| Read Singapore Review | |
| Read Australia Review | |
| Read AI Agent Review | |
| Read Paperclip VPS Review | |
| Read Hermes Agent Review | |
| Read Hostinger Connector Review | |
| Read Web Apps Hosting Review | |
| Read Hostinger Reach Review | |
| Read hpanel Review | |
| Read Odoo Review | |
| Read Laravel Review | |
| Read MERN VPS Review | |
| Read Ubuntu Review | |
| Read Drupal Hosting Review | |
| Read Express.js Review | |
| Read React Review | |
| Read Nextjs Review |
Hostinger MCP 係一個整合，讓 AI 編程工具透過 Model Context Protocol 連接到你嘅 Hostinger 服務。佢唔係一個獨立嘅託管產品，而係同你現有嘅帳戶配合使用，唔會取代 hPanel。
唔。Connector 係其中一種設定方法，係透過瀏覽器擴充功能使用 OAuth。你亦可以用 API token 手動設定連線，而呢個就係呢篇評測測試嘅路徑，現時支援包括 Claude Code、Cursor、Devin Desktop、Antigravity 同 Codex 喺內嘅客戶端。
是。MCP 整合本身不另收費。你仍然需要符合資格的 Hostinger hosting、cloud 或 VPS 計劃，才能讓 AI 代理實際執行你想要的任務。
喺我嘅測試入面，一個我故意搞壞嘅 build 被拒絕而唔係部署，呢個係好事。不過，build logs 冇顯示導致失敗嘅具體 runtime error，只係話 dependency 安裝成功。請直接檢查你嘅 live app 或 health endpoint，而唔好只靠 build logs。
係。我喺 Claude Code 入面只用手動設定嘅 API token，冇用 Connector extension，成功部署咗一個 Node.js app，之後又故意將佢破壞。主要嘅部署工具喺我兩次嘗試入面都失敗咗，而且每次都需要手動上載再建置作為後備方案，而兩次都成功咗。
我無直接測試過呢點，因為我嘅 token 設定咗一個月期限，而且一直維持到整個審查完結。呢個其實係一個需要預先規劃嘅真實問題，而唔係我可以透過測試回答嘅；記得設定日曆提醒，喺 token 到期前輪換，因為任何依賴佢嘅任務一旦喺使用期間中途過期，理論上都會失敗。
