TechJob on 施星宇

科技巨頭在創新與可靠間的觀察

Sun, 16 Aug 2026 00:40:00 +0800

過去待過 Microsoft 和 Meta 這兩間公司，觀察到這兩間公司有一個有趣的差異，也就是一間公司到底是希望大家覺得它是一間「可靠」、「值得信任」的公司，還是希望大家認為是一間很「有創新能力」、永遠在嘗試新東西的公司

當然，這兩件事情並不是互斥的，一間公司可以同時很可靠，也可以同時很創新，應該幾乎所有科技公司都會希望兩個都有，但我是這樣覺得，當一間公司的規模越來越大之後，這兩件事情其實存在某種程度的 Trade-off，也就是說，當你越想讓整個組織保持快速改變的能力，相對來說就一定會增加一些不確定性，而當你越希望自己的產品、方向和承諾都是穩定而且可以預測的，很多時候就不可能像一間新創公司一樣，想到什麼事情就立刻去做，而我待過的兩間公司，Microsoft 和 Meta 在這件事情上，我覺得剛好是兩個蠻不一樣的例子

當「可靠」本身就是產品的一部分

如果要形容我在 Microsoft 感受到的公司文化，我感覺它是一間相對比較保守的科技公司，我先說我講的保守並不是說 Microsoft 不做新的東西，事實上從 Azure、AI 到各種開發工具，它當然還是持續有很多新的產品和技術，只是相較於很多消費型網路公司，我覺得 Microsoft 做事情的邏輯，會很明顯把安全性、穩定性、相容性，以及長期的可靠度放在比較高的位置，而這其實跟 Microsoft 現在的商業模式有很大的關係，以前很多人對 Microsoft 的印象可能還是 Windows 和 Office，但是今天 Microsoft 很大一部分的業務已經建立在企業客戶上，包括 Azure、Microsoft 365、各種資安方案，許多政府機關和大型企業的基礎設施，本身就建立在 Microsoft 的產品上，而當你的客戶是這些公司的時候，大家對你的期待其實會跟一般消費型產品非常不一樣，舉一個比較簡單的例子，如果今天我做的是一個手機應用程式，我把某個功能拿掉或者重新設計，使用者可能覺得很難用，也可能上網抱怨，但是最多就是換一個應用程式，可是如果今天是一間銀行已經有幾百套內部系統建立在你的平台上，或者一間公司已經把整個基礎設施搬到你的雲端上，那這時候你突然改變一個 API、停止支援一個功能，甚至只是一個原本沒有預期到的破壞性變更，對客戶來說都可能是一件非常大的事情

對這些企業來說，他們買的其實不只是產品本身的功能，而是某種程度上的承諾，也就是我今天選擇你的產品之後，我相信三年後、五年後，甚至十年後，你不會突然告訴我這個東西不能用了，即使技術一直在變，你也會提供足夠的向下相容性、遷移方案，或者長期的支援，讓我不用每隔幾年就重新把整套系統做一次，這也讓我以前在 Microsoft 工作的時候，常常會感受到公司非常在意信任這件事情，有時候從工程師的角度來看，確實會覺得很多事情做得很慢，一個功能可能要經過很多審查，有些東西明明技術上早就可以換掉了，但是因為還有客戶正在使用，所以還是要繼續支援，甚至有些看起來很簡單的改動，最後牽涉到的安全性、法規遵循、相容性問題可能比實際寫程式碼還多

以前我會覺得這是一種大公司的官僚流程，但反過來看，這些官僚流程有一部分其實就是可靠度的成本，因為當很多公司願意把自己的業務建立在你的產品上，他們願意相信的並不是 Microsoft 每一年都一定會做出最酷的新功能，而是它是一間相對不會亂來的公司，對 Microsoft 來說，「可以被信任」本身其實就是產品價值的一部分

相容性的另一面，是不斷累積的複雜度

不過，相容性做得好也不代表產品就一定比較好用，當舊的功能不能隨便拿掉，舊的操作方式需要繼續支援，新的需求又不斷加進來時，產品就很容易變成一層一層往上疊，每一次增加的東西都有它當時合理的背景，但是過了幾年之後，使用者看到的可能就是更多選項、更多入口，以及好幾種看起來很像、實際上又不完全一樣的做法，我自己觀察到 Power BI 對就是個明顯的例子，它的功能很多也需要照顧不同時期、不同使用情境和不同企業客戶的需求，但整個介面和概念也容易變得複雜，有些東西之所以還留在那裡不一定是因為它仍然是今天最好的設計，而可能只是因為已經有人依賴它，不可以直接拿掉

所以 Microsoft 這種做法的代價，很多時候不是功能突然消失，而是歷史包袱會慢慢累積，它讓使用者比較能相信原本的東西明天還會存在，卻也可能讓整個產品變得疊床架屋，需要花更多時間理解

即使已經是一間大公司，還是希望自己可以 Move Fast

相比之下，我到 Meta 之後感受到的是一個蠻不一樣的文化，Meta 今天當然已經不是一間新創公司了，它已經是一間有非常多員工、產品也影響全球數十億使用者的大型公司，但是很有趣的是，它內部到現在還是非常努力想要維持一種新創公司的精神，其中最明顯的當然就是大家都知道的 Move Fast，我以前在外面看到這個口號的時候，會覺得它可能就只是公司文化宣傳的一部分，但真的進到公司之後，會發現它其實會反映在很多做事情的方法上，例如公司如果覺得一個方向很重要，組織和資源可以很快速地往那邊移動，一個專案可以很快開始，方向也可能很快改變，而如果後來發現這件事情不值得繼續做，也可以很快把資源重新移到其他地方，這種文化的好處其實非常明顯，就是一間公司不會因為自己已經變得很大，就完全失去改變方向的能力，因為科技產業本來就是一個變化非常快的產業，如果今天一間公司所有事情都希望等到百分之百確定才去做，那很多時候等你確定的時候，市場可能早就已經往下一個方向走了

我覺得 Facebook 後來改名成 Meta 就是一個非常典型的例子，不論現在回頭看元宇宙這個方向是不是完全正確，光是從一間大型企業做決策的角度來看，這其實是一件蠻驚人的事情，Facebook 這個名字已經累積了非常大的品牌價值，但當上面認為下一個運算平台可能會往另一個方向發展時，它真的可以直接把整間公司的名稱改掉，然後投入非常大量的人力和資源去做 VR、AR 和相關技術，這種事情如果放在一間更傳統的大公司，可能光是討論要不要做就要非常久，更不用說真的把整間公司的方向往那邊移動，所以我覺得 Meta 特別之處就是它即使已經是一間非常大的公司，還是很努力不要讓自己變成一間「因為已經成功，所以什麼事情都不敢改」的公司，但這樣的文化其實也一定會有它另外一面的代價

快速改變的另一面，是不斷重新適應

如果說 Microsoft 的難用有一部分來自歷史包袱，那 Meta 則是另一種程度的難用，不是舊的東西留下太多而是東西變得太快，有些今天還能使用、也已經熟悉的功能可能過一陣子就不見了或者被移到另外一個地方，內部的工具、介面和流程也可能持續調整，每一次改變單獨來看都有讓系統變得更好、更一致，或者更符合新方向的理由，但對實際使用的人來說還是需要不斷重新適應，這種做法可以減少長期累積的包袱，讓團隊有機會直接換掉不再適合的設計，可是它同時也降低了可預測性，使用者不一定要理解十年前留下來的所有選項，卻要接受自己今天學會的東西，明天不一定還能照同樣的方法使用

所以從易用性的角度來看，Microsoft 和 Meta 並不是一個好用一個難用，而是兩種不同的成本，一種是為了相容而累積的複雜度，另一種是為了快速迭代而產生的不穩定性

對公司來說是快速改變，對合作的人來說可能是不確定性

同一間公司這特性從內部和外部去看，感受會完全不一樣，例如從 Meta 自己的角度來看，如果一個方向不對可以快速調整方向，這絕對是一個優點，因為代表公司的資源不會一直浪費在一個已經知道沒有機會的專案上，但是如果你今天是間正在跟 Meta 合作的廠商，而且你已經投入了一批人力在共同開發某個東西，那你最在意的事會是：「你們明年還會不會繼續做這件事？」，所以就是對公司本身而言，改變的能力是一種彈性，但是對依賴這間公司的人來說，改變有時候就是一種風險，這點其實不只是在公司合作上，對員工、開發者，甚至投資人來說都是一樣的

今天一間公司很願意嘗試新的東西，對裡面的工程師來說可能代表有很多新技術、新產品可以搞，但也可能代表組織和專案可以很容易改變，甚至哪天突然就被公司砍掉了，而一家公司願意投入大量資源去嘗試一個還不知道會不會成功的市場，從創新的角度來看當然很好，但從投資人的角度來看，問題可能就會是這些資源什麼時候能夠轉換成營收，所以這並不是單純「哪一種公司文化比較好」的問題，而是不同的人在意的東西本來就不一樣，而你到底比較相信哪個

創新和可靠度其實有一點一體兩面

創新和可靠度這兩個看起來都是非常正面的詞，其實在某些情況下有一點一體兩面，創新的本質本來就代表你要去做一些以前沒有做過的事情，而只要是一件以前沒有做過的事情就一定會包含某種程度的不確定性，你不知道市場會不會接受，不知道技術最後能不能成功，也不知道現在投入的資源最後有沒有辦法產生回報，如果一間公司完全不能接受這些不確定性，那它當然很難做出真正很新的東西，因為所有討論最後都會變成：「有沒有過去成功的案例？有沒有資料可以證明一定會成功？」但問題是，如果真的已經有足夠的資料可以證明一件事情一定會成功，那很多時候它可能也已經不算是一件多創新的事情了

反之，可靠度很大一部分的價值，其實就是降低不確定性，一個企業為什麼願意簽長期合約，為什麼願意把基礎設施搬到你的平台上，本質就是因為它相信未來的結果在某種程度上是可以預測的，從這個角度來看 Microsoft 和 Meta 的差異，不是哪間公司比較厲害，而是兩間公司在不同的地方做了不同的取捨，Microsoft 因為有大量企業客戶，所以它需要讓客戶相信：「你今天把重要的東西交給我，未來我不會突然改變規則」，而 Meta 很大一部分的業務還是消費市場，它面對的競爭則是：「下一個平台出現的時候，我是不是還跟得上？」這兩個問題本身就造就出非常不一樣的公司文化

介在兩者中間的公司

如果要再加入另外一家公司，我自己會覺得 Google 是一個蠻有趣的案例，因為它某種程度上好像剛好介在 Microsoft 和 Meta 中間，以前的 Google 給人的印象其實是一間非常創新的公司，而且有很多東西都是先把技術做出來再看看可以拿它來做什麼，它有很強的工程文化，也做過非常多實驗性的產品，這一點我覺得比較接近 Meta，但 Google 這幾年也慢慢開始進入更多企業市場，包括 Google Cloud、Google Workspace，這些東西的客戶跟一般搜尋引擎或 YouTube 的一般使用者是非常不一樣的，如果今天一間公司真的把自己的基礎設施搬到 Google Cloud，它當然也會開始問跟 Azure 客戶一樣的問題，這個服務五年之後還在不在，API 會不會改，你們會不會哪天覺得這個產品不值得繼續做，就把它關掉

而我覺得這也是為什麼當一間科技公司越來越大、企業業務越來越重要的時候，它很多做事情的方法可能就會慢慢往 Microsoft 那一側移動，這不一定代表公司失去了創新能力，而是當越來越多人開始依賴你的產品之後你能夠隨意改變的空間本來就會變小，這也是一間新創公司變成大型企業之後不太能避免的事情

大公司為什麼最後都會變慢

所以現在回頭看，我覺得所謂的「大公司病」可能也不完全只是因為公司的人變多了，或者管理階層變得比較官僚，而是一間公司成功之後需要負責任的對象也變多了，新創公司最怕的是沒有改變，如果今天產品沒有人用，最合理的做法可能就是明天直接改方向，因為反正原本的東西也沒有什麼人依賴，但是當今天有幾億、幾十億個使用者，有企業客戶、有開發者、有合作夥伴，甚至有政府機關都建立在你的產品上時，一次產品方向的改變影響的就不只是你自己的公司

所以很多大型企業後來會開始出現更多流程、審查、法規遵循、資安要求，我覺得其中當然還是會有一些沒有必要的官僚流程，但是也不能說這些東西全部都沒有意義，有一些其實只是因為你犯錯的成本已經跟以前不一樣了

最困難的可能是，長大之後還能不能同時保留兩件事情

所以不單純是「Microsoft 比較保守，所以 Meta 比較創新」這麼簡單的方式去看這兩間公司，我反而覺得比較有趣的問題是，一間公司在成長的過程中，到底要怎麼同時保留創新和可靠度，如果一家公司太偏向可靠度，所有事情都必須先證明沒有風險，那它很有可能會慢慢變成一間穩定，但是很難再創造新東西的公司，可是如果一家公司所有事情都只追求快速行動，方向一直改，那不論是客戶、合作夥伴還是員工，長期下來也可能不知道自己到底能不能信任今天的方向，所以真正難的但是關鍵的，是要分清楚哪些事情是可以快速試錯的，哪些事情則是一旦承諾之後就不應該隨便改變，一個新的產品方向可以快速實驗，但是已經提供給客戶的 API 可能不能說改就改，內部專案可以快速停止，但如果合作夥伴已經在上面投入很多資源，那對外的承諾就需要另外考慮

如果真的能把這個界線切清楚，那一間大型科技公司或許才有機會在變得越來越可靠的同時，還是保留原本改變自己的能力，而我覺得這可能也是 Microsoft、Meta、Google 這些已經非常成功的大型科技公司，接下來都會一直面對的一個問題：當一間公司已經大到很多人開始依賴它之後，它還能不能在讓別人信任自己的同時，繼續保有冒險和改變的能力？

我覺得這件事情，會比單純比較哪一間公司「比較創新」還要有趣呢

Product、Program、Project Manager比較

Mon, 05 May 2025 14:52:00 +0800

前言

PM大概是科技業中最容易讓人搞不懂的職稱之一，Product Manager叫PM、Project Manager也叫PM，後來又冒出一個Program Manager還是叫PM，三個職稱看起來差不多，實際工作卻可能差了十萬八千里。更麻煩的是每間公司對PM的定義都不太一樣，有些公司的Product Manager做的其實很像Project Manager，也有些職缺乾脆只寫一個「PM」，等進去面試後才發現工作內容跟想像中完全不同。

我以前也很直覺地認為Product、Program與Project是從策略一路排到執行，Program Manager大概就是一次管理很多Project、職級也比較高的人，然而自己實際做過Technical Program Manager（TPM）後，才發現事情沒有這麼簡單。這三種角色並不是一條由上到下的指揮鏈，比較像是站在不同角度處理同一件事情，而在公司規模不大或分工沒有那麼細的地方，更常是一個人把三份工作全部包走。

因此這篇並不是要給三種PM下一個放諸四海皆準的定義，畢竟這種定義大概也不存在，而是希望用比較接近實際工作的方式，解釋三者通常在意什麼、每天都在處理哪些問題，以及新人看職缺時到底該看哪裡。

Product Manager｜產品經理

Product Manager最重要的問題是：「這個東西到底該不該做？」

假設一間影音平台想推出家庭訂閱方案，Product Manager不能只是收到老闆一句「Netflix有家庭方案，我們也來做一個」，接著就把需求丟給工程師。他得先弄清楚究竟是哪一群使用者有這個需求、他們現在遇到什麼問題、願意付多少錢，以及這個方案對公司的生意是不是真的有幫助。要是辛苦做了半年，結果沒人想用，就算準時上線、程式也沒有Bug，仍舊很難說是一個成功的產品。

為了回答這些問題，Product Manager可能會訪談使用者、看產品數據、研究競品，跟設計師討論操作流程，再找工程、法務、行銷與客服確認各種限制。由於想做的東西通常永遠比工程資源多，他還得決定第一版要先做什麼、哪些需求可以晚一點、哪些看起來很酷但其實先不要浪費時間。

而且產品上線並不是下班的時候，反而只是另一個階段的開始。多少人真的開通家庭方案、有多少人用過一次就不再使用、訂閱收入有沒有增加、客服又收到了什麼奇怪的抱怨，這些都會影響下一步的產品方向，因此Product Manager通常會關注使用率、轉換率、留存率、營收或使用者滿意度等結果。

Product Manager經常被稱為「產品的CEO」，這句話聽起來很威風，但老實說也很容易誤導新人。多數Product Manager並不是任何人的主管，沒有辦法命令工程師一定要做什麼，也不能無視成本與技術限制亂開支票；他真正需要的能力，是在資料永遠不完整的情況下做出還算合理的判斷，再想辦法說服一群不歸他管的人一起把產品做出來。

Project Manager｜專案經理

如果公司已經決定家庭訂閱方案非做不可，Project Manager接下來關心的就是：「要怎麼在有限的時間與資源內把它做完？」

一個看似簡單的功能，背後可能牽涉會員系統、付款、App、網站、客服工具、法務條款與行銷素材，其中只要一個環節慢下來，上線時間就可能整個往後延。Project Manager需要把事情拆成可以執行的任務，找出負責人與前後依賴關係，排出Milestone，再持續確認專案是不是還走在原本的計畫上。

當然，現實中的計畫幾乎沒有照表操課這回事，工程師可能突然發現原本的設計做不出來、法務審核比預期多了兩週、老闆在上線前又多塞了三個需求，甚至原本答應支援的人直接被別的專案搶走。Project Manager的價值就是在這些事情真的把專案炸掉以前先看見風險，把影響攤開來讓大家知道，再協調出可以接受的做法。

所以Project Manager確實會排時程、追進度與開會，但如果只把這個角色理解成每天問「好了沒」的人就太可惜了。好的Project Manager會讓每個人知道現在的目標、決策與責任是什麼，問題出現時也知道該找誰處理；催進度只是表面，減少意外與混亂才是這份工作的核心。

Project Manager通常會在意專案能不能準時完成、預算是否超支、需求範圍有沒有失控，以及最後交付的品質是否符合標準。不過這些結果也不是他一個人能控制的，專案管理做得再好，碰到需求每天改三次或資源根本不足的組織，一樣只能努力不要讓場面變得太難看。

Program Manager｜計畫經理

Program Manager應該是三者中最難只用一句中文解釋的角色，因為Program究竟有多大、包含什麼，在不同公司中的差異非常大。

回到家庭訂閱的例子，如果公司的真正目標是「拓展全球付費會員」，那麼家庭方案可能只是其中一小塊，整個Program還包含新的付款系統、跨國定價、家長控制、隱私與法規、客服流程和上市行銷，而這些工作分散在不同國家與團隊，各自又有自己的目標與時程。Program Manager要處理的就是這些工作之間沒有人單獨負責、但不處理又一定會出事的空隙。

例如付款系統什麼時候可以支援新的方案？各國法規不同，要不要分批上線？兩個團隊同時需要同一批工程資源時，哪一邊應該先做？一個團隊延遲會影響到多少下游工作？這些問題通常不是多開幾場進度會議就會自己消失，Program Manager得先建立大家共同理解的目標與Roadmap，再整理跨團隊的Dependency、風險與決策，必要時把Trade-off帶到更高的層級解掉。

因此Program Manager不一定是一次管很多Project Manager的人，更不代表他必然比Project Manager高一階。Program描述的是問題的範圍與複雜度，而不是組織圖上的上下關係。有些Program是一項有明確終點的大型產品上市，有些則是雲端遷移、隱私合規、開發流程或營運效率這種持續多年的能力建設，兩者都可能由Program Manager負責。

至於Technical Program Manager，簡單來說就是處理的Program具有相當程度的技術複雜度，因此除了Program Management能力外，也需要理解系統架構、技術限制與工程團隊的語言。這不代表TPM每天都要下去寫Code，但至少不能在工程師講到API、Database、Latency或System Design時立刻進入放空狀態，不然很難判斷風險，更不用說協助團隊做選擇。關於TPM實際面試會遇到什麼，我之前也寫過一篇Google Technical Program Manager面試經驗。

所以三種PM到底差在哪？

說了這麼多，可以先很粗略地記成下面三句：

Product Manager在意的是「為什麼做、替誰做，以及該做什麼」
Project Manager在意的是「由誰來做、什麼時候做完，以及如何順利交付」
Program Manager在意的是「多個團隊與專案要如何合作，才能達成更大的共同目標」

這個分法雖然不可能涵蓋每間公司的情況，但至少比「Product負責策略、Project負責執行、Program負責管理很多Project」來得接近現實。因為Product Manager一樣需要處理大量執行問題，Project Manager也不可能完全不參與策略，而Program Manager更不是只要把幾張專案進度表疊在一起就算完成工作。

在小型新創公司，一位Product Manager可能從使用者訪談一路做到排時程與追進度，實際上同時兼了Product與Project Manager；到了分工細的大公司，三種角色可能一起出現在同一個Program中，甚至還有Product Operations、Delivery Manager、Engineering Program Manager等更多令人眼花撩亂的名字。台灣的情況又更有趣，軟體公司的PM可能偏產品，系統整合公司的PM可能主要面對客戶交付，硬體公司的PM則可能每天處理供應鏈、試產、認證與量產時程，光看兩個英文字母實在很難知道他到底在幹嘛。

新人該怎麼看PM職缺？

比起研究職稱，最有用的方法還是把Job Description打開來看，而且不要只看那些「善於溝通、積極主動、可以在快速變動的環境工作」之類每間公司都能複製貼上的句子，可以特別找下面幾件事：

這個角色最後要對什麼結果負責，是產品成長、單一專案交付，還是跨部門的整體成果？
平常最常合作的對象是使用者、設計與工程，客戶與供應商，還是公司內的多個團隊？
工作中有多少產品與需求的決策權，又有多少時間是在執行別人已經決定的方案？
公司用什麼方式判斷這個PM做得好，是營收與留存、時程與預算，還是效率、成本與組織能力？
這個職位上一個人一週通常怎麼過？這題在面試中問下去，通常比職稱本身更容易挖出真實的工作內容。

如果你喜歡理解使用者與商業問題，願意在模糊的資訊中做取捨，Product Manager可能比較適合；如果你擅長把一團混亂整理成可以執行的計畫，對細節、風險與時間很敏感，Project Manager可能比較對味；如果你喜歡處理跨團隊的複雜問題，能在沒有直接管理權的情況下推動一群人往前，而且看到一堆Dependency不會先頭痛，那Program Manager也許是可以嘗試的方向。

不過Program Manager，尤其TPM，通常比較需要既有的產業或專案經驗，原因也很直接：如果自己還沒有看過幾個專案是怎麼成功、又是怎麼爆炸的，就很難提早看出一個大型Program究竟會在哪裡出問題。

結語

Product、Project與Program Manager並不是三條完全分開的路，也不是固定的升遷順序。實際工作中大家都會碰到產品判斷、專案執行與跨團隊協調，只是每個角色花費的比例不同，而這個比例還會隨著公司、產業與團隊一直改變。

如果真的只能用一句話總結，我會說Product Manager確認問題值不值得解決，Project Manager想辦法讓解法順利交付，而Program Manager則確保一群彼此牽連的團隊最後真的能產生結果。

所以下次看到PM職缺，先不要急著被職稱騙進去，問清楚每天到底在解決什麼問題比較實在。

科技業台商與外商公司暱稱

Sat, 06 May 2023 14:52:00 +0800

科技業台商與外商公司暱稱

台商

IC設計 (豬屎屋)

項次	公司名稱	Ptt、Dcard暱稱	說明
1	聯發科	發哥、發弟、M、大M、麥當勞、篤行路麥當勞	分紅多的時候就是發哥，少的時候就變發弟，因為被稱為M，員工自嘲為篤行路麥當勞打工仔，去上班謙稱為鏟薯條。叫大M是因為曾經有小M(晨星)
2	聯詠	滷肉、N	聯詠的英文是Novatek音似「滷肉」
3	瑞昱	螃蟹、R、帝王蟹、寄居蟹、海產店	Realtek、Logo就是一隻螃蟹，帝王蟹專指分紅特別多的部門，如果分紅少，鄉民就鄙稱寄居蟹，因為是螃蟹所以也有人稱海產店
4	群聯	全聯、P、請支援收銀	群聯音似全聯
5	慧榮	S
7	奇景	海馬	Himax音似海馬¹
8	達發	客運、發哥子公司	發哥的一家子公司，英文名是Airoha發音似早期的阿羅哈客運
9	瑞鼎	鼎王	取鼎字。由於鼎王麻辣鍋是相較昂貴的餐廳，故這是分紅好的意²
10	矽創	洗窗	取矽創的諧音
11	敦泰	保全	有一家保全公司叫敦泰保全
12	奕力	一粒、粒粒	奕力的諧音。或取粒字，源自《憫農詩》：「誰知盤中飧，粒粒皆辛苦」，為員工自嘲工作辛苦²
13	華邦電	邦邦
14	信驊	股王
15	新唐

品牌廠

項次	公司名稱	Ptt、Dcard暱稱	說明
1	宏達電	紅茶、紅茶店、Hㄒㄈ、阿姨	紅茶店是取諧音，阿姨是指雪紅阿姨
2	華碩	石頭	華碩品質，以卵擊石
3	宏碁
4	微星	小星星、中二龍、微薪、G星	微薪是只薪水給的不多
5	技嘉	雞排店	英文名字是GIGABYTE，GIBYTE發音跟雞排很像²
6	群暉	亞東Google	公司在捷運亞東醫院站附近，跟Google一樣吸引很多軟體頂尖人才

面板廠

項次	公司名稱	Ptt、Dcard暱稱	說明
1	友達	戀人、戀人未滿	取名稱：友達以上，戀人未滿
2	群創	包子	之前與奇美電子合併，因奇美包子而得名

系統廠

項次	公司名稱	Ptt、Dcard暱稱	說明
1	和碩	皮卡	音似其英文名Pegatron
2	廣達	肉鬆、肉鬆店	有一家肉鬆廠叫做廣達香肉鬆
3	緯創	W、大W
4	緯穎	小w、we win	因為是緯創的子公司
5	仁寶	寶寶
6	光寶	點燈	英文名字LITEON，表示light-on²
7	研華
8	華擎	小石頭、妖擎	因為華擎是由華碩分家出來的所以叫小石頭，又專門生產一些奇怪的主機板和產品(妖板)
9	台達店	三角、三角形	Logo是一個三角
10	鴻海	海公公（取海字）、海邊、海底、紅海	取海字。《烏龍派出所》的阿兩常說：「你家住海邊啊！」這句話意指「多管閒事」（因為海邊鎖管(小卷/透抽)很多）。之所以稱鴻海為海邊，是暗指公司管很多²
11	英業達	小英	名字裡有英字
12	啟碁	道士	取諧音，道士會起乩

半導體製造

項次	公司名稱	Ptt、Dcard暱稱	說明
1	台積電	台GG、GG、護國神山、神山、大哥、祖墳冒煙	因為台灣有台積電因此中國不敢隨便打台灣，所以稱之為護國神山。祖墳冒煙是在說能近台積電的人都是有祖先保佑
2	聯電	二哥、U、大碩	因其員工常以該公司為跳板跳槽至台積電，近似研究所補習班「大碩」而謔稱之
3	世界先進	仙境、RO	取先進兩個字的諧音
4	日月光	神教	出自金庸小說《笑傲江湖》的虛構組織日月神教²
5	南亞科	牙科
6	華亞科	滑牙科
7	矽品	三口、三口組	三個口、很多口的那間、三口組 (因最後一個字品，而被鄉民取這些名稱 )
8	力積電	假G、小GG	叫假G是因為名稱跟台積電很容易混淆

軟體、電信、銀行

項次	公司名稱	Ptt、Dcard暱稱	說明
1	中華電信	種花、種花電信、種花點心、小公司（出自徐旭東）	取諧音，加上工作很悠閒
2	台灣大哥大
3	遠傳	大公司	為網友呼應其老闆徐旭東之言論而謔稱之
4	趨勢	亞洲最大純軟
5	國泰	大樹、花椰菜	Logo是一顆大樹，大樹長的很像花椰菜
6	Dcard	豬腳、低卡、低能卡	取諧音、又Dcard上的發文通常太過浮誇很低能故稱低能卡
7	愛卡拉	卡拉雞

外商

IC設計製造

項次	公司名稱	台灣暱稱	對岸暱稱	說明
1	Qualcomm(高通)	Q
2	Marvell(邁威爾)	漫威		Marvell發音跟漫威一樣
3	Nvidia(英偉達)	NV
4	Intel(英特爾)	牙膏廠	牙膏廠、藍廠	core i系列每一代效能都高一點點就像擠牙膏
5	AMD(超微)	推土機廠	推土機廠、紅廠	AM3時代處理器名稱
6	Micron(美光)	光光、發光、人生發光		來自徵才標語「加入美光，人生發光
7	Texas Instruments(德儀)
8	Broadcom(博通)
9	NXP(恩智浦)

品牌與軟體設計

項次	公司名稱	台灣暱稱	對岸暱稱	說明
1	Google(科高)	G	G社、狗家	狗家取字Google的諧音
2	Microsoft(微軟)	M$、MS	巨硬、巨嬰³	M$是指微軟什麼東西都要錢，巨硬來自於微軟字面上的相反
3	Meta(臉書)		臉家、M社	Facebook翻譯為臉書
4	Amazon(亞馬遜)		亞麻、雨林、香蕉廠³	亞馬遜以對員工小氣聞名，公司福利只願意提供香蕉給員工
5	Apple(蘋果)	阿婆	A社、水果家
6	IBM(國際商業機器)	外星科技	大藍	據說真的有從事外星科技
7	Netflix(網飛)		N社、網飛
8	Tiktok(抖音)	父母白養	字節	取自「抖音一響，父母白養」
9	Dropbox		D社、丟盒子
10	Airbnb
11	Salesforce		賣力
12	Orcale(甲骨文)		烏龜殼
13	Sony(索尼)	$ony、大法		相機技術很厲害，就跟魔法一樣
14	Dell(戴爾)	呆鵝
15	騰訊	企鵝		騰訊的Logo是一隻企鵝
16	百度		百毒	中國網友慣稱呼，諧音
17	Uber		黑車
18	Uber Eats	吳柏毅
19	Foodpanda	熊貓
20	Garmin
21	Samsung(三星)	三爽

半導體設備商

項次	公司名稱	台灣暱稱	對岸暱稱	說明
1	ASML(艾斯摩爾)	A4ML	阿斯麥	A4ML是只這家公司給的分紅很少，阿斯麥是中國ASML的翻譯
2	TEL(東京威力科創)
3	ASM(先藝)
4	AMT(應材)
5	KLA(柯磊)
6	LAM(柯林研發)

系統廠

項次	公司名稱	台灣暱稱	對岸暱稱	說明
1	Supermicro(美超微)
2	Lenovo(聯想)

知名企業家

項次	名稱	暱稱	說明
1	郭台銘	果凍
2	Lisa Su(蘇丰姿)	蘇媽
3	Jason Huang(黃仁勳)	老黃、皮衣刀客、AI教父
4	Sundar Pichai	皮柴
5	Elon Musk	鋼鐵人、馬投顧	其言行對加密貨幣很有影響力
6	Sam Altman	奧特曼
7	蔡力行	Rick	聯發科CEO