跳到主要內容

蘋果與中國:iPhone供應鏈的秘密武器與地緣博弈

當我們手中的iPhone響起,我們可能不曾想過,這小小的裝置背後,隱藏著一個由技術、野心、政治以及極度相互依賴所交織而成的全球網絡。這個故事遠不止於一條簡單的生產線,它揭示了蘋果如何與中國製造深度捆綁,並在其中面臨前所未有的挑戰。

一個令人驚訝的數據是,僅僅蘋果一家公司,就在中國創造了約500萬個工作崗位,這比整個中國為美國創造的所有就業機會加起來還要多。這個數字不僅令人咋舌,更凸顯了蘋果與中國之間那份錯綜複雜的關係。

危機轉機:蘋果的全球化之路


故事的起點要回溯到上世紀90年代末,當時的蘋果正瀕臨破產邊緣。在賈伯斯回歸後,他面臨的首要任務不是創新,而是生存。當時「什麼都自己做」的生產模式成本過高、反應太慢,已經完全行不通。因此,蘋果做出的第一個重大決定,就是砍掉自家工廠,全面外包生產。

就在這個關鍵時刻,一個關鍵人物出場了:鴻海富士康的郭台銘。在所有台灣同業都避之不及、認為蘋果是個要求嚴苛、態度傲慢,且眼看就要倒閉的公司時,郭台銘卻看到了別人沒看到的東西。他認為,如果能滿足蘋果極致的要求,那麼就能滿足世界上任何人的要求。

郭台銘的豪賭:從瀕臨破產到偏執要求


蘋果對完美的追求達到了近乎偏執的程度。書中提到一個經典例子:早期的第一代iMac,那台彩色半透明的電腦,其機身背面有一條塑膠注塑工藝留下的極其細微的結合線,肉眼幾乎看不見,需要用放大鏡才能辨識。然而,賈伯斯卻無法接受,他要求富士康一遍又一遍地修改模具,直到這條線徹底消失。富士康的工程容差甚至是以「微米」來計算的(一根頭髮的直徑約70微米)。這種要求在當時的製造業簡直是天方夜譚,完全顛覆了行業標準。

那麼,為何富士康會願意為了一條看不見的線,反覆折騰,承受如此巨大的成本和壓力呢?

「蘋果壓榨術」與知識轉移的真相


這背後的秘密,被稱為「蘋果壓榨術」(Apple Squeeze)。其交易的重點根本不是金錢。書籍揭示,供應商真正想要的是「知識」。蘋果會將他們最頂尖的工程師派駐到工廠,手把手地教導如何進行自動化生產、優化流程、管理供應鏈。這項無形的資產,才是供應商們願意忍受壓榨的真正回報。業界甚至將其稱為「硬體界的長春藤聯盟」。

中國的「秘密武器」:規模與速度


正是這種獨特的合作模式,最終將中國變成了蘋果的「秘密武器」。許多人誤以為關鍵是廉價勞動力,但這早已不是故事的核心,因為東南亞地區有更便宜的勞動力。中國真正的優勢是「規模和速度」。郭台銘就是一個完美的中間人,他既懂蘋果需要什麼,也懂中國地方政府想要什麼。他能在短時間內,將一片空地變成一座能容納30萬工人的微型城市,這樣的效率和執行力是當時世界上任何其他地方都無法想像的。

成功的兩面性:脆弱的全球網絡


蘋果與富士康建立了一個近乎完美的共生關係:蘋果提供知識和標準,中國則提供無與倫比的規模和速度。這個組合聽起來堅不可摧,然而,任何事物一旦做到極致,是否也意味著它變得極其脆弱?這個系統的阿基里斯之踵,正是它太過成功,也太過依賴單一的一方。權力天秤開始慢慢傾斜。

權力天秤的傾斜:本土競爭與地緣政治


蘋果傾囊相授給富士康的技術和管理經驗,並沒有被鎖在富士康的工廠裡。它像蒲公英的種子一樣散播出去。許多本土企業,如立訊精密、歌爾股份等,透過更低的利潤,甚至不惜虧損來搶訂單,慢慢蠶食富士康的份額。數據顯示,到2021年,蘋果公佈的前200大供應商名單中,來自中國大陸和香港的企業數量,歷史上第一次超過了台灣。

這不僅僅是商業競爭,更讓蘋果頭疼的是,它發現自己成了一個地緣政治的棋子。為了保住巨大的中國市場,它必須做出許多妥協,例如按照要求下架數千個在其他國家不會下架的應用程式,並同意將中國用戶的數據存儲在由中國公司營運的境內伺服器上。這對於一家以「自由和隱私」為品牌核心的公司來說,無疑是一個非常尷尬的局面。

這也催生了我們現在經常聽到的「中國+1」戰略,即供應鏈多元化,不能把所有雞蛋都放在一個籃子裡。目前印度正成為這個「+1」的首選。一份報告預測,到2025年第二季度,美國市場進口的iPhone中,印度組裝的比例可能飆升到44%,而中國大陸的份額則可能下降到25%。這是一個巨大的逆轉。

「中國+1」的陷阱:核心仍在中國


然而,「中國+1」戰略並非簡單地將工廠從A地搬到B地。儘管最終的組裝可能會轉移到印度或越南,但那些新工廠裡使用的大部分精密零組件,仍然要從中國運過去。這意味著,整個供應鏈的中心,或者說「大腦」,其實還在中國。這更像是中國的供應鏈網絡上嫁接了幾個海外組裝車間而已,它分散了最終組裝的風險,但並未從根本上擺脫對原有體系的依賴。

矛盾的共存:蘋果供應鏈的兩面性


蘋果官方發佈的供應商責任報告描繪了一個近乎烏托邦的圖景:提供超過2800萬人次的培訓、嚴格的供應商行為準則、推動供應商使用清潔能源、回收材料,甚至幫助員工上大學。這與我們前面提到的超級工廠、被壓榨的利潤和巨大的生產壓力,兩種畫面看似矛盾,卻又同時存在。

這正是蘋果最核心的矛盾,也是它最聰明的地方。這兩種畫面都是真實的,並且互為因果。報告裡的高標準是真的,蘋果確實投入了巨額資金和人力去推行這些標準、去改善勞動條件。但是,這些改善是在「效率的基礎之上」的。正是這種極致的效率,才會催生出對這些補救措施的巨大需求。這就像一個頂級運動員會被世界上最好的醫療和康復團隊護貝,但這恰恰是因為他每天都在進行著遠超常人、對身體有巨大損耗的訓練。蘋果供應鏈也是如此,它是問題的製造者,也是問題的解決者。這不是虛偽,而是一種系統性的一體兩面。高效的生產體系與完善的保障體系,就像兩根相互纏繞的DNA螺旋,共同構成了蘋果的供應鏈。

最終的啟示:一場相互利用的宏大敘事


這個故事的關鍵可能不僅僅是蘋果利用了中國的勞動力和市場,更是「中國允許蘋果這樣做,以便反過來利用蘋果,來實現自己更長遠的戰略目標。」這是一個相互利用,最終實現自身產業升級和技術趕超的宏大敘事。

當我們今天再次拿起手中的iPhone時,可以思考一下,你手中這台設備的「身體」(即它的物理組裝地)可能正在從中國轉移到印度,但它最核心的「大腦」,那塊由台積電製造的晶片,仍然來自那個處在中美關係風暴中心的台灣。當一個全球化產品的「身體」和「大腦」同時被捲入一場地緣政治的角力中,這對我們每一個人又意味著什麼呢?

REF:


留言

這個網誌中的熱門文章

Vibe Coding:為什麼 Junior 更快上手?Senior 要如何追趕?

現象層面(市場觀察) 最近有篇文章討論 junior & senior 開發者在 AI 時代的角色轉變,非常熱門。 身為 Cympack 產品開發團隊 ,我們也一直關注這個議題,在閱讀這篇文章時觀察到一些有趣的現象,對我們來說,這正好反映出 AI 正在改變開發生態,junior 借力 AI 快速成長、senior 則需要在 「架構思維」 與 「多 agent 協作」 中找到新定位,其中有些啟發(insight) 可以跟大家分享。 為什麼 Junior 更容易上手 vibe coding? 心智負擔低 → Junior 沒有太多傳統 code workflow 的框架包袱 敢於嘗鮮 → Gen Z / 年輕工程師天生習慣用 prompt-based 工具、跟 LLM 互動 少「優雅程式設計」的束縛 → 不太糾結「這樣寫會不會不夠優雅」,反而 embrace 快速迭代、快速出成果 反觀 Senior: 熟悉大型系統設計 有豐富的「工程正統流程」知識(架構設計、測試策略、效能優化、設計模式) 對 AI 生成 code 的品質 / 維護性通常比較保留 部分 10+ 年資深工程師,對 prompt engineering 沒那麼熟練,還在觀望 技能面(未來的關鍵能力) Vibe coding 本質上 = prompt engineering + AI co-pilot 管理能力 能力項目 誰目前比較有優勢? Prompt 撰寫 / AI 互動 Junior 較強(熟悉 chat-based 流程) 系統設計 / 架構把關 Senior 較強 AI 生成 code 驗證 / Bug 察覺能力 Senior 較強(能看出潛在問題) 快速疊代 / Hackathon 式開發 Junior 較強 長期維護性 / 穩定性 Senior 較強 總結 Junior 確實更快適應 vibe coding,並且更習慣以 「chat-based coding」 的工作流開發。 Senior 擁有驗證 AI 產物與系統設計的深度能力,但若不主動練習 vibe coding,長期會逐漸落後於新一波開發潮流。 就如同在 GAI 技術年會分享,希望帶給各位的感受, 『與 AI 協...

Vibe Coding 協作到自建 Dev Agent?從 Claude / Codex 到 OpenHands

過去一年,越來越多工程師開始 把 AI 真正帶進工作流程 。從一開始用 ChatGPT、Claude 來問語法問題,到後來很多人愛上 Cursor,直接在編輯器裡讓 AI 幫忙改 code、補 test case、甚至自動整理 PR。這樣的開發體驗,已經大大改變了我們寫程式的方式。 更現實的是,在很多企業內部、政府單位、或涉及機密資料的專案裡, 其實根本不能直接用 Cursor 或雲端 LLM 工具。   畢竟這些服務通常會把資料傳到雲端模型做處理,萬一專案裡有未公開的技術、敏感客戶資料,或是受限於法規 (像金融、醫療、政府標案) ,直接用雲端 AI 工具就會踩 紅線 。  因此,許多團隊反而更希望 「自己架一套 Dev Agent」 ,可以在內網執行,資料完全掌握在自己手上,該整合的內部工具、該讀的私有 repo、該串的 CI/CD pipeline,全部客製化、安全可控。 這時候,像 OpenHands 這樣的開源 Dev Agent 框架就特別有價值。它的出發點不是單純的 AI 助手,而是讓你能夠打造出一個真的可以跑在自己環境裡、可以理解整個開發流程的 AI 工程師。從建置到部署,從 CLI 操作到瀏覽器查詢, 從多檔案編輯到自動測試,全部都能自己完成,甚至還能針對不同專案調整專屬的工作流。 對很多開始探索 AI 協作開發的團隊來說,這是一條 從 「AI 幫你寫一段程式」,走向「AI 幫你解決一整個任務」 的進化路徑。而且,還是在可控、可自定義、安全的環境裡完成的。 🧩 主要概述 OpenHands 是由 All‑Hands AI 開發的開源「軟體開發代理人平台」,能模仿人類工程師從建立程式、修改程式碼、執行指令,到瀏覽網頁、呼叫 API……等一整套開發流程 它提供雲端(OpenHands Cloud)與本地 Docker 運行版本,用戶能配置 LLM(如 Claude、OpenAI、Gemini…) 📚 核心特性與怎麼使用 代理人的工具能力 支援代碼編輯、命令行、執行環境、網頁瀏覽、API 呼叫—接近人類開發者完整技能。其中 OpenHands Cloud 版本提供 $50 試用額度讓大家方便使用,又或者如果自己本機有 docker 的話,可以自己Local 版本透過 Docker 自架環境。 ...

Google Gemini 全端 AI Agent 快速入門 - 打造「思考」的 AI 助理

一套從搜尋、反思到輸出的全端 AI 代理人範例,讓你看懂什麼叫 Research Agent 在 AI 工具百家爭鳴的今天,大家都在問一個問題: 「我能不能不只問 AI 答案,而是讓它像一位助理一樣,有流程、有反思、還有出處,真正幫我完成一件事?」 Google 最近釋出了一個相當具有指標意義的開源專案 gemini-fullstack-langgraph-quickstart ,正是為了解這個問題而誕生。 這套系統到底是什麼? 這個範例不是傳統 Chatbot,而是展示一個完整的 AI research agent : 它會根據使用者的提問,自動發想搜尋關鍵字、查資料、整合重點,最後給出答案還附上引用來源。背後的邏輯設計得非常扎實,不只是能跑,更是具備可讀性、可擴展性與可商用性。 它的流程大致如下:  1. 使用者輸入問題(例如:「抖音是否影響台灣選舉?」)  2. Gemini LLM 幫你想出關鍵字(不只是照抄問題)  3. 呼叫 Google Search API 抓資料   4. LangGraph 控制流程 → 判斷資料夠不夠 → 若不足,自動補查  5. 整合最終答案,並產生 citation(來源說明) 你可以想像這就像一位實習助理幫你寫報告, 不只輸出一段內容,而是會 去查、會判斷、會補資料,而且說明「我為什麼這樣說」 。 LangGraph 是什麼角色? LangGraph 就是整個 Agent 背後的控制系統 。 用白話講,它幫你定義 AI 每一步要幹嘛、遇到什麼狀況該走哪條路、要不要反思、要不要再查,甚至可以定義條件邏輯與資料流動。 這就不像寫一個單純的 Chat API,而是比較像「把一個流程圖變成可以跑的程式」。 對工程師來說,它提供了從 prompt 到流程控制的設計彈性;對產品設計來說,它讓 AI 有了 「多步驟任務執行」 的能力。 技術架構與使用方式 這整套系統是 Fullstack 架構,前後端都幫你整好了,技術選型也非常實用:   前端:Vite + React + TailwindCSS + Shadcn UI  後端:FastAPI + LangGraph...