香港公司外包泰國工程師：成本與溝通風險評估指南

香港公司外包泰國工程師，實際成本通常是月薪的 1.35 至 1.6 倍（含社保、EOR 費、設備與管理overhead），而非報價單上的數字。最大風險不是時差——港泰只差一小時——而是英文書面溝通密度與規格落差。以下是一套可直接套用的評估框架。

泰國為何進入香港公司的外包短名單

過去五年，香港企業在組建跨境技術團隊時，評估名單從「深圳 + 台灣」擴展到越南、菲律賓、馬來西亞與泰國。泰國之所以被納入，有幾個結構性理由：

時區幾乎重疊。 泰國為 UTC+7，香港為 UTC+8，只差一小時。相比之下，香港與波蘭差七小時、與東歐外包中心的重疊工作時間通常不足三小時。對需要即時處理生產事故（incident）的團隊，這一小時差距在實務上等同同步協作。

人力成本梯度明確。 根據世界銀行（World Bank）的國民所得分類，泰國屬於中高收入經濟體，人均國民所得約在七千美元量級，而香港超過五萬美元。這個差距會反映在工程師薪酬上，但不是線性的——資深後端與 DevOps 人才在曼谷的競價已相當激烈。

產業基礎真實存在。 泰國投資促進委員會（Thailand Board of Investment, BOI）長期以稅務優惠推動數位與軟體產業，曼谷與清邁聚集了一批為日本、澳洲、北歐客戶服務的開發團隊。清邁尤其累積了大量長期遠端協作經驗。

但同一組理由反過來看，也是風險來源。把泰國當成「便宜的人力補給站」來評估，幾乎必然低估總成本。

成本結構拆解：薪資以外的七個項目

多數外包決策的錯誤起點，是拿曼谷工程師的月薪和香港的月薪直接相除，得出一個令人興奮的比例，然後據此做預算。真實的全載成本（fully loaded cost）包含以下項目：

1. 基本月薪。 根據 Michael Page 泰國及 Adecco Thailand 公布的年度薪酬指南，曼谷中階軟體工程師（3–5 年經驗）的月薪區間寬廣，資深 DevOps、資料工程與行動端人才的上緣明顯高於一般後端。務必取區間而非中位數做預算。
2. 社會保險（Social Security Fund）。 泰國社會保障法規定雇主與員工各按薪資 5% 提撥，雇主端設有法定月度上限（泰國社會保障辦公室 SSO 公布）。比例不高，但必須入帳。
3. 第十三個月獎金與年度調薪。 泰國市場慣例普遍發放年終獎金，部分企業為一至兩個月。年度調薪幅度在科技職位上常高於通膨。
4. 公積金（Provident Fund）與醫療保險。 非強制，但在曼谷科技人才市場上已接近標配，不提供會直接影響招聘成功率。
5. 僱主名義服務（EOR）或 BPO 管理費。 若不設立泰國實體，透過 Employer of Record 聘用，市場上常見為每人每月固定費用或薪資百分比。
6. 設備、軟體授權與辦公空間。 一台開發用筆電、JetBrains 或 GitHub Copilot 授權、VPN 與安全工具，按三年攤提仍是每月成本。
7. 香港端的管理 overhead。 這是最常被漏掉的一項：需求撰寫、驗收、Code Review、每週同步會議所佔用的香港資深工程師或 PM 工時。一個五人泰國團隊通常需要香港端 0.3 至 0.5 個 FTE 來維持輸出品質。

把第七項計入後，很多「省 50%」的方案實際落在省 25% 到 35% 之間。這仍然有價值，但決策理由必須從「省錢」轉向「擴充產能與時區覆蓋」，否則第一次預算檢討就會被推翻。

一個可以直接放進試算表的成本模型：

1monthly_cost =
2    base_salary
3  + base_salary * 0.05              # SSO 雇主端（受法定上限約束）
4  + base_salary * (1/12)            # 第十三個月攤提
5  + base_salary * 0.03              # 公積金雇主提撥（市場慣例）
6  + insurance_premium               # 團體醫療
7  + eor_fee                         # 或 entity 維運成本 / headcount
8  + equipment_amortised             # 筆電 + 軟體授權 / 36
9  + hk_overhead_fte * hk_rate       # 香港端管理工時
10
11effective_rate = monthly_cost / productive_hours_per_month

productive_hours_per_month 才是關鍵變數。扣除泰國法定假日（通常多於香港）、年假、會議與規格返工，實際可交付工時往往落在名目工時的 70% 上下。用名目工時算出來的時薪，沒有決策價值。

三種合作模式的取捨

自由接案者與小型工作室

啟動最快，單價最低，適合定義清晰的一次性交付：一個 Shopify 主題改版、一組 API 串接、一輪效能優化。風險集中在連續性——單一接案者離開，知識即刻歸零。若採用此模式，合約必須明確規範原始碼交付、文件標準與 Git 歷史完整移交。

人力擴充（Staff Augmentation / Dedicated Team）

由泰國或區域性供應商提供全職工程師，向香港端的 PM 匯報。成本可預測，招聘與人事行政由供應商承擔。取捨在於：你買到的是人，不是結果。如果香港端沒有能力寫清楚規格與做技術驗收，產出品質會直接反映管理成熟度。

自設泰國實體

長期成本最低、控制力最強，但要面對《外商經營法》（Foreign Business Act）對外資從事服務業的限制、BOI 申請、泰國稅務局（The Revenue Department）的申報義務，以及常駐的會計與 HR 成本。除非規模達到 15 人以上並預期長期經營，否則行政負擔難以攤平。

實務上，多數香港企業的最優解是混合：核心架構與資料留在香港或新加坡，泰國團隊承接明確邊界的功能模組，初期以 EOR 或 dedicated team 起步，驗證一年後再決定是否設立實體。

溝通風險從何而來

把溝通問題歸因於「英文不好」是過度簡化，而且會導向錯誤的解法。

書面英文密度是真實瓶頸。 根據 EF 英語能力指標（EF English Proficiency Index）歷年報告，泰國長期位於「極低能力」級別，而香港位於中段。但這個國家級數字不適用於曼谷的科技人才圈——在國際團隊工作的泰國工程師，技術英文讀寫通常足夠。真正的落差出現在模糊情境的書面表達：描述一個還沒釐清的 bug、質疑一個不合理的需求、主動提出風險。這些需要的語言能力遠高於寫 commit message。

高情境文化下的「不說不」。 泰國職場文化普遍重視 kreng jai（體諒、不願使對方為難）與階層禮節。實務後果是：當需求不合理、工期不可行、規格有矛盾時，團隊傾向先答應，之後再默默延期。香港管理者若習慣以「有問題再說」作為預設，就會系統性地收到過度樂觀的訊號。

時區不是問題，工作節奏是。 一小時時差可忽略，但泰國的法定假日排程與香港不同（宋干節、佛教節日等連續假期），若 release 排程沒有對齊假期日曆，會在最不該出事的時候缺人。

可以直接部署的六項緩解措施

1. 把同步會議改成非同步書面為主。 每日書面 standup（Slack 或 Linear），每週一次 60 分鐘視訊。減少即時口語壓力，提高資訊留存。
2. 用「回述」取代「明白嗎」。 驗收前要求對方用自己的話寫一段 implementation plan。對方寫不出來，就是沒理解——這比問十次「clear?」有效。
3. 規格以可執行形式交付。 Given/When/Then 驗收條件、API 契約（OpenAPI spec）、Figma 標註，而非散文式需求。
4. 建立「升級不等於失敗」的明示規範。 寫進團隊手冊：卡住超過 4 小時必須提出，提出不計入績效負面評價。
5. 假期日曆雙向同步。 把泰國與香港的法定假日放進同一個 release calendar。
6. 設一位泰方技術聯絡人（tech lead）。 由他承擔對外英文溝通，而非要求每位工程師都達到同一語言門檻。

AI 工具正在改寫成本方程式

2025 至 2026 年間，最大的變化不是人力單價，而是每位工程師的產出倍數。根據 Stack Overflow 2024 Developer Survey，約四分之三的受訪開發者表示正在使用或計劃使用 AI 開發工具。這對跨境團隊有兩個直接影響：

語言門檻下降。 LLM 作為書面草稿工具，大幅降低了「用英文描述一個模糊問題」的成本。泰方工程師用泰文寫出問題描述、由模型整理為結構化英文 issue，再人工校對，比強迫他直接寫英文更快也更準確。這不是取代語言能力，是降低表達摩擦。

規格與測試的生成成本下降。 香港端可以用 LLM 把口語需求轉為 Given/When/Then 驗收條件草稿，再由人工修正。規格品質提升，返工率下降，而返工正是跨境團隊最大的隱性成本。

但要誠實面對取捨：AI 輔助會放大 Code Review 的負擔。生成程式碼看起來合理但邏輯錯誤的比例不低，若泰方團隊資歷偏淺又缺乏香港端的嚴格 Review，技術債累積速度會快於傳統模式。導入 AI 工具的同時，必須同步強化 CI 閘門：

1# .github/workflows/pr-gate.yml（節錄）
2name: pr-gate
3on: [pull_request]
4jobs:
5  checks:
6    runs-on: ubuntu-latest
7    steps:
8      - uses: actions/checkout@v4
9      - run: npm ci
10      - run: npm run lint
11      - run: npm run test -- --coverage
12      - name: Coverage threshold
13        run: npx nyc check-coverage --lines 80
14      - name: Block large PRs
15        run: |
16          CHANGED=$(git diff --stat origin/main | tail -1 | awk '{print $4}')
17          if [ "${CHANGED:-0}" -gt 600 ]; then
18            echo "PR too large for meaningful review"; exit 1;
19          fi

限制 PR 大小這條規則，在跨境、跨語言團隊中的價值高於任何溝通培訓——它強迫把工作拆成可被審查的單位。

法規與資料合規的盲點

泰國《個人資料保護法》（PDPA）自 2022 年 6 月全面生效，由個人資料保護委員會（PDPC Thailand）執行，架構上參照 GDPR，包含資料主體權利、處理合法基礎與跨境傳輸規範。香港方面，《個人資料（私隱）條例》由個人資料私隱專員公署（PCPD）執行，其中關於跨境轉移的第 33 條至今未生效，但 PCPD 已發出跨境轉移指引，實務上仍應依指引處理。

對外包安排的具體意涵：

• 若泰國團隊會接觸香港用戶的個人資料（客服工單、訂單資料、會員資料庫），必須簽署資料處理協議，明確定義處理目的、保存期限與次級處理者。
• 若客戶涵蓋歐盟或英國使用者，GDPR 的處理者義務同樣穿透到泰國供應商。
• 技術層面的最小化處理比法律文件更有效：生產資料不下行到開發環境、以合成資料或遮罩資料做測試、所有存取走 VPN 與具稽核紀錄的堡壘機。

另一個常被忽略的是常設機構（Permanent Establishment）風險。若香港公司在泰國沒有實體，卻長期指揮一群實質上為其全職工作的人員，泰國稅務局可能認定構成常設機構並課徵企業所得稅。EOR 安排可降低但不完全消除此風險，規模擴大前應取得當地稅務意見。

泰國與其他亞太交付據點的定位

泰國

適合：與香港時區幾乎同步、需要穩定長期團隊、產品面向東南亞市場（泰文在地化能力）。注意：英文書面密度、資深人才競價、外資服務業限制。

越南

工程師供給量大、理工教育基礎紮實，適合大規模人力擴充與後端/行動端開發。流動率在熱門技術棧上偏高，需要更強的知識文件化紀律。

菲律賓

英文溝通優勢最明顯，適合需要大量客戶互動、QA、技術支援與營運流程的角色。時區與香港零時差，但深度工程人才池相對較淺。

台灣

中文溝通零摩擦、工程品質穩定、與香港同時區，適合需要高頻規格協作的產品工程與資料團隊。成本梯度不如東南亞明顯。

新加坡 / 澳洲

成本最高，但適合放置架構決策、資安治理與面向歐美客戶的商務角色。澳洲團隊能延伸覆蓋到亞太以東的工作時段。

真正有效的配置，通常不是選一個國家，而是按職能分配：架構與資安留在香港或新加坡，核心開發放越南或泰國，營運與支援放菲律賓，中文產品協作放台灣。Branch8 在香港、新加坡、台灣、越南、馬來西亞、印尼、菲律賓與澳洲的交付佈局，就是為了支撐這種按職能分層的結構，而不是單點的人力套利。

一個可操作的評估框架

在簽約前，用以下七個維度各給 1–5 分，加權後比較候選方案：

1. 全載成本比（相對香港自聘，含管理 overhead）— 權重 20%
2. 技術棧契合度（候選團隊在你實際使用的框架上的實戰年資）— 權重 20%
3. 書面英文密度（要求試寫一份 incident report，不是面談口說）— 權重 15%
4. 交付證據（可檢視的 Git 歷史、CI 設定、測試覆蓋率，而非作品集截圖）— 權重 15%
5. 資料合規成熟度（是否有 PDPA/GDPR 處理流程、是否接受安全稽核）— 權重 10%
6. 連續性風險（團隊規模、流動率、是否有 bus factor 為 1 的角色）— 權重 10%
7. 合約與 IP 條款（原始碼歸屬、離場條款、過渡期義務）— 權重 10%

90 天試行設計

不要用整個專案驗證供應商。用一個邊界清晰、有真實業務價值但不在關鍵路徑上的模組：

• 第 1–2 週：環境接入、唯讀程式碼閱讀、交付一份架構理解文件
• 第 3–6 週：第一個功能模組，全程走 PR 流程與 CI 閘門
• 第 7–10 週：第二個模組 + 一次刻意安排的規格變更，觀察對方是否主動提出風險
• 第 11–12 週：回顧會議，檢視返工率、PR 平均 Review 輪數、升級行為頻率

「刻意安排的規格變更」是整個試行中最有診斷價值的一步。團隊默默吸收變更而不提出工期影響，就是未來延期的前兆。

一個實作觀察

在為一家總部設於香港、門市橫跨大中華市場的零售集團重整電商平台時，團隊採用的是多地協作：香港端負責資料模型與金流整合，區域團隊承接前端與中台模組。最有效的單一介入，不是增加會議，而是把所有需求改成 OpenAPI 契約加 Given/When/Then 驗收條件先行——規格寫完才開工。這個做法把「理解落差」從交付後暴露，提前到規格審查階段暴露，成本差異是數量級的。

另一個觀察是：跨境團隊的文件語言應該統一為英文，但討論語言可以多元。強迫所有即時對話使用英文，只會讓資訊停留在少數幾個人身上。

最常見的三種失敗模式

一、把外包當成逃避內部能力缺口的方法。 如果香港端沒有人能做技術驗收，外包只會把問題延後並放大。先補內部的技術領導力，再談外包。

二、用時薪而非交付單位計價。 按小時計費的合約，雙方誘因方向相反。盡可能以 sprint 容量或功能模組計價。

三、沒有離場設計。 合約裡必須寫明：原始碼與基礎設施配置持續同步到客戶控制的 repository、所有第三方帳號由客戶持有、終止後提供至少 30 天過渡支援。沒有這些條款，供應商的議價能力會隨時間單向上升。

如果你正在評估泰國或其他亞太據點的工程團隊配置，Branch8 以香港為總部、在新加坡、台灣、越南、馬來西亞、印尼、菲律賓與澳洲設有交付能力，可協助你完成全載成本試算、供應商技術盡職調查與 90 天試行設計。歡迎聯絡我們討論你的具體情境。

Sources

• EF — English Proficiency Index
• Stack Overflow — Developer Survey
• Thailand Board of Investment
• Personal Data Protection Committee, Thailand (PDPC)
• Office of the Privacy Commissioner for Personal Data, Hong Kong (PCPD)
• Social Security Office, Thailand
• The Revenue Department, Thailand
• World Bank — Open Data
• Michael Page Thailand — Salary Guide