CTO到底該不該寫程式?
CTO到底該不該寫程式?

醫療社群丁香園的 CTO 馮大輝離職了,炸出了科技產業裡的一個大問題:CTO到底應不應該寫程式?

具體來說,CTO在公司裡是幹嘛的?他/她到底寫不寫程式?該不該做程式審查(code review),親力親為給工程師做出榜樣?還是把握一下大方向、設計架構、管管工程師,提供一些培訓?抑或應該把行銷長以及「吐槽老東家」長的職位一併兼了?

在中國,大大小小的工程師們就這個問題已經吵成一團;那我們不妨去看看矽谷。帶著這些問題,我們問了一圈矽谷大小科技公司的 CTO、VP Engineering、技術合夥人,以及其他各種高階技術管理職稱上的朋友。


## 矽谷 CTO 寫不寫程式? 

我們發現在矽谷,技術類公司比純網路產品公司多得多。大部分 CTO 不但會寫程式,程式也是他們日常最重要的工作內容。

Movidius 是一家研發低功耗視覺處理晶片的矽谷科技公司,現在已經擴張到了400多人的規模。 Movidius的 CTO David Moloney 在愛爾蘭都柏林工作,他負責管理一支超過 120 人的技術團隊,因此也設有一個 「CTO 小組」,每天花 10-15 分鐘聽取小組成員的報告並作出指示。他常用的溝通工具是 Slack。

儘管如此,David 仍然很享受親力親為的工作風格,也是公司的技術迭代的主要功臣。他告訴我們,他的日常工作主要包括設計演算法、寫專利聲明以及幫助解決成員提出的技術問題。

我們按照專案和任務分成小組工作,我本人經常寫 Octave(Matlab)、C/C++ 來開發演算法,日常使用 GCC 和 Visual Studio(兩種編程工具)。我們使用 GitHub 來管理所有的程式。

除此之外,David 還會親自撰寫很多的專利聲明,而非將其交給下屬以及其他法律顧問。

David Meloney

David Meloney

其實不只David,採訪中我們發現,在矽谷,捲起袖子上陣寫程式對於 CTO/技術合夥人/高階技術管理人員來說簡直是家常便飯,幾乎不分公司技術團隊人數多寡。

一家由機器人 SLAM(定位、識別和行動技術)公司的共同創辦人匿名接受了採訪。他告訴我,因為是技術公司沒有設立 CTO 的職位,自己和另外一個創辦人每天大約有 8 個小時在寫程式,剩下 4 個小時做管理和溝通工作。

寫程式是每天工作主要部分,語言包括 Python、Java、C++、C 等。

這家公司的技術團隊目前有 8 個人,一半在開發演算法,另外一半做開放系統。

看完小公司,讓我們看看大公司是怎麼搞的。一位前微軟員工告訴我們,「印像很深的是在微軟,一個高階總監管理多於 300 個技術人員,還在堅持對核心部件進行 code review,時不時自己寫程式,程式質量還很不錯。」

微軟現在不設 CTO 職位,每個主要業務單獨設立部門,由資深的技術負責人擔任SVP——這些大多擁有十年以上的微軟工作經驗。

Oculus VR 是世界上最知名的VR 技術公司之一,在被Facebook 收購後成長迅速,員工總數從去年的數百人成長到今年的逾千人,其中技術人員比例很高,但該公司的大神級CTO John Carmack 仍是一副不寫程式不舒服的樣子。他討厭管理,由其討厭開會,曾經在 Twitter 上說

沒有什麼比「取消:(某會議)」的郵件標題讓我笑得更開心了。

j-carmack-twitter

一位知情者告訴我,Carmack 超級不喜歡別人打擾他。他早年用過一些很奇怪的工具來提高自己的工作效率,比如工作的時候開始用CD 機放音樂,但凡有任何中斷(上廁所、收發郵件、被人闖進辦公室)就暫停,然後記錄一天下來暫停了多少次。著名遊戲開發者Richard Garriott曾這樣評價John Carmack在程式上的水平和造詣:

這個人啊,他的大腦分成兩個部分,一塊存儲Oculus的所有程式,另一塊存儲他創立的那個火箭公司的所有技術——而且跟內存一樣,他隨時能調取出任何一家公司、下屬專案裡面的任何一個程式細節。他真是讓我很沒自信……

John Carmack

John Carmack

  

## 矽谷 CTO 怎麼看待不寫程式這件事? 

那家機器人技術公司的共同創辦人向我表示,如果技術人員不多,比方說10-50 名的話,CTO 不寫程式是一件挺不可思議的事,「與一般技術人員不同,他們只負責一小部分,我們需要了解系統的每一部分。」

但是在那些擁有50名以上技術人員的中型甚至大型公司裡,情況會根據公司而變化。

一個普遍的觀點是,CTO 應該根據公司需要轉變職能,甚至偶爾身兼多職。 Peloton Technology 的首席網路架構師Tony Li 認為,當公司需要擴張,那麼CTO得設計好系統架構;如果公司需要一個技術傳教者(比如在融資、招人或公關的時候),那麼CTO 也得是一個好的演講者……

當然,如果公司還是需要好工程師,那 CTO 照樣還得寫程式。總而言之,CTO 應該捲起袖子上陣的心態還是被大部分創立於21世紀的美國科技公司所接受。

Movidius 的 David Moloney 1985 年開始工作,曾在多家半導體業界知名公司擔任工程師、主任設計師、技術總監等職位。他認為CTO的確不用寫程式就可以管理,有什麼事情交給團隊成員也行——儘管他強調那不是他的風格。

如果我這樣做了,會感覺很不舒服。我認為作為CTO,首先應該是一個技術問題上的破冰者。

集客式行銷公司 HubSpot 總部位於馬薩諸塞州,已於早年上市,現在員工人數也超過了500人。其 CTO Dharmesh Shah 2014 年曾經回答過「CTO 應不應該寫程式」的問題。 他認為 CTO 應該寫程式,就像銷售 VP 得去銷售一樣。

Dharmesh Shah

Dharmesh Shah

除非那種已經很龐大的公司,在新創公司裡,每個人都要親力親為。我從來不相信純粹的管理職位。

## 不寫程式的 CTO 就失職了嗎? 

或者:寫程式應該成為 CTO 的核心競爭力嗎?

這才是見仁見智的地方。大多數採訪對像都會告訴我,他們認為 CTO 不寫程式可以理解。比如有些經驗豐富,任職於大公司的 CTO,確實應該花更多精力把握大方向,設計架構、分配工作、優化整體性能、確保系統的穩定和安全。具體的執行和實現,由部屬來完成。

比如,有些大的公司不設 CTO 而是設工程副總裁 VP Engineering,但也能見到 VP Engineering 轉職 CTO(比如 Facebook),或者兩個職位共存的情況。曾在多家公司擔任 CTO 的 Vijay Venkatesh 認為,VP Engineering 更多負責現有產品,而 CTO 擔負的是設計未來專案,讓它與現有產品在技術上能夠更好融合的責任。

在這樣的公司裡,CTO 應該有著比普通工程師更全面的技能和更大局觀的視野。 不可否認的是,CTO的程式能力越強大,越能跑好把公司規劃、業務需求透過技術落實的這個流程。程式能力是應該是讓CTO 龐大的技能樹更好地生根發芽的養分,而不是樹根本身。

CTO 應該會寫程式嗎?應該。寫程式是核心工作內容嗎?不應該是。用程式寫得好不好評價 CTO 合適嗎?不合適。

 ——這不是採訪對象們說的,是我總結的。


事實上,無論在矽谷還是中國,不少小型新創公司的早期技術員工都面臨這樣的狀況:行動端和web開發都得懂,平時還得維護自己的郵件/日曆系統,公司斷網了又要負責檢修和給營運商打電話,拉條電話線都得親自出馬。這哪裡是技術長,分明就是首席全棧苦力嘛。

而當公司發展起來之後,中美的情況卻發生了變化。

矽谷這些 CTO(除了 Carmack 大神),要不是一人扛起整個公司的技術運轉,就是在投入巨大精力親力親為。他們會這麼做的原因,也在最一開始提到過:技術對於這些公司的重要性,比技術對於中國大部分新創公司的重要性,都高得多;而CTO們需要考慮的技術之外的因素,也少得多。

而在中國,CTO 卻往往沒有辦法這麼去做了。中國科技圈太崇拜靠營運、靠打仗和修建城池獲得成功的神話。微信、淘寶、微博,哪一個不是這樣成功的呢?相比之前,技術的重要性太低,太不被外界重視。技術不會決定生死,產品做得差不多就行,靠推廣甚至靠搏眼球才能成功。這也是為什麼在矽谷,新創公司的CTO 們往往捲起袖子寫程式,而在中國這樣的環境裡,一名合格甚至優秀的新創公司CTO 卻得去考慮程式以外其他很多事,他們的價值,也就不能僅僅用程式來衡量。

所以,對於一個沒有技術缺陷、擅長營運、具備網紅人格,還為其帶來了巨大的影響力的 CTO,卻用單純用「寫不寫程式」來評價功過,並不太合適。特別是當我聽說,整件事情幕後真相的討論點已經從「匿名指責CTO不寫程式」過渡到「團隊拒不兌現 CTO 期權」的時候,我就更明白了:

指責CTO 不寫程式不過是一盆潑出去用來轉移視線的髒水,背後藏的,卻是希望藉著「程式之爭」來達到其否定CTO 價值、繼而撕毀契約目的的厚臉皮和小算盤。

本文授權轉載自:PingWest

往下滑看下一篇文章
AI NAS 何時才值得部署?QNAP 拆解地端 AI 的成本、算力與資料門檻
AI NAS 何時才值得部署?QNAP 拆解地端 AI 的成本、算力與資料門檻

當資料不能離開企業,運算就得靠近:AI 先改寫儲存架構

AI 帶來的第一個變化,不只是運算能力提高,而是企業必須重新決定資料放在哪裡。

儲存架構大致分為雲端與地端兩塊,QNAP 身為資料安全的守護者,長期發展的是地端網路儲存設備(NAS),並擴展至 25GbE、100GbE 高速網路交換器產品線,提供完整的儲存與高速網路基礎架構。威聯通科技(QNAP)總經理劉文義解釋,當資料因合規要求或敏感度不能上雲,就必須留在靠近使用者與應用的地方;運算需求一旦增加,承接資料的裝置也自然被推向地端 AI。

不能上雲的名單比想像中長。醫療業持有大量醫療個資,金融與保險業受到合規與法規限制,部分大學院校與設計公司也不希望資料被雲端存取。對這些組織而言,問題並不是雲端好不好用,而是一開始就沒有把核心資料全面上雲的選項。

qnap2.jpg
威聯通科技(QNAP)總經理暨威強電集團(IEI)董事長 劉文義
圖/ 數位時代

真正讓更多企業回頭計算的,則是長期成本。劉文義指出,資料上傳雲端可能免費,下載卻會按流量收費;當企業把一年、兩年、三年的費用加總回推,可能會發現,購買一台同等容量的 NAS,還能使用 7-10 年。資料規模愈大、存取愈頻繁,總持有成本的差距就愈值得評估。

這並不代表雲端與地端只能二選一。雲端仍適合模型訓練、程式開發與波動大的工作負載;地端則較適合高頻存取、對延遲敏感,或不能離開企業邊界的資料。企業真正要回答的,是每一類資料與任務應該放在哪裡。

依 QNAP 觀察,客戶過去關心的是需要幾 TB、幾 PB,或備份速度有多快;現在更常問的是,機器裡的資料要如何被 AI 活用。QNAP 也從 2021 年起,把公司發展定調在 AI 與高速網路的融合,試圖讓 NAS 從資料保存的位置,進一步成為資料被調用的位置。

當資料量持續擴大,搜尋與管理方式也會跟著改變。「在 NAS 裡放入 AI Agent 會越來越不可或缺。」劉文義舉例,當照片累積到 10 萬、20 萬張,要找出其中幾張特定畫面,已不可能只靠人工翻找。此時,能理解內容、接受自然語言指令的 AI 工具,會從加分功能逐漸變成必要條件。

從資料治理到地端推論:AI NAS 如何進入企業工作流?

AI NAS 不是「多了 AI 功能的 NAS」,而是 NAS 在企業工作流裡換了位置。
依 QNAP 觀察,目前客戶大致分布在一條導入光譜上。人數最多的一群,仍在把資料集中、分類、清理與建立權限。這一步看似與 AI 無關,卻決定後續系統能不能找到正確資料、辨識版本,並把答案交給有權限的人。

中間一群開始建置私有的檢索增強生成(RAG)知識庫。RAG 並不是重新訓練一個模型,而是在模型回答前,先從企業的 SOP、合約、法規或技術文件中取回相關內容,再產生附有來源依據的答案。QNAP 以 Qsirch 的語意搜尋能力協助建構這類應用,協助企業建立私有知識庫;而走在最前面的少數企業,則已經嘗試地端推論與 AI Agent。

模型的選擇權,QNAP 刻意留給客戶。知識庫背後採用哪一個模型,可由企業依需求決定,不綁定單一 AI 供應商。QNAP 也以 QuAgent AI 助理與模型情境協定(MCP)相關能力,讓管理者透過自然語言查詢狀態、調整設定,並讓 NAS 成為 AI Agent 可調用的資料節點。

不過,劉文義沒有把這條路說得太容易。他坦言,目前 NAS 硬體的 AI 運算能力仍有限。一般企業期待的應用,可能需要約 300 到 800 TOPS,甚至 1,000 TOPS,因此多數方案會以 NVIDIA 顯示卡補足算力;一張卡約需新台幣 10 萬至 12 萬元,一張算不完,就得配置 2 張或 4 張。

「整體成本可能是過去單獨一台 NAS 的 5 倍到 10 倍,並不是大部分中小企業都能接受。」除了硬體,使用者還需要 AI 應用的 Know-how、程式背景與開發資源,這些都是落地成本。

QNAP 則是透過算力分級讓各規模與需求的企業都可以有適合的解決方案。在 Computex 2026 搶先亮相的 QNAP AI NAS 中,一類是採用含有 iGPU 與專屬 NPU 的處理器平台,以一百多 TOPS 的範圍,可順暢使用 AI 應用程式;另一類機種則可安裝 1 張或 2 張 NVIDIA 顯示卡,處理更大的運算量。

同時 QNAP 也在軟體端也持續開發,目標是讓 NAS 裡的資料更有效率地被 AI 工具調用,讓資料成為有價值的知識。

從規格走到現場:能源公司如何導入私有 LLM?

本地 AI 實際落地部署會是什麼模樣?劉文義舉了一家約 50 多人的能源公司為例。這家公司原本想用 NAS 搭配雲端 AI 建置內部資料庫,但很快遇到兩個瓶頸:一是員工查詢時明顯出現卡頓;二是專利、技術與合約都高度敏感,高層不願上傳至公有雲,擔心機密資料會有外洩的疑慮。

後來,該公司導入 QNAP AI NAS 的旗艦機種 QAI-h1290FX,搭配顯示卡與全快閃 SSD,在地端部署私有大型語言模型,把數十年來封存的靜態檔案交給 AI 調用,進行跨檔案摘要與精準搜尋。員工因此省下翻找合約與報告的時間,核心機密也能留在企業內部。

這個案例說明,若任務範圍明確,有些應用不必動用雲端大型模型,地端運算量就可能足以支應。

但不同企業的資料量、查詢方式與模型大小不同,導入前仍需要概念驗證(POC)與技術人員評估。

而且,資料留在地端並不等於自動安全。企業仍要處理帳號權限、網路隔離、備份復原、漏洞修補與日常維運。地端的價值,是讓資料邊界與控制權回到企業手上;相對地,安全責任也會更直接地回到企業。

哪些企業現在該做,哪些再等?先看重複性與三個條件

能不能導入地端 AI,不只由產業標籤決定,也要看工作是否重複,以及場景能不能被清楚定義。劉文義觀察,第一批走進來的,除了受法規限制的醫療、金融與保險業,也包括利用地端 AI 加速資料處理的科技業,以及會計、律師等有大量重複文書工作的專業服務業,因為效益較容易被看見。

工廠也是可預期的場景。一條生產線可能有 10 台、20 台機器,每台處理與儲存資料的 Protocol 都不同,需要相對應的儲存裝置;生產過程累積的影像與紀錄可能要保存 3 年到 5 年。當企業要跨設備調用這些資料,AI Agent 與地端資料節點就有發揮空間。

「重複性資料處理越多,或重複性動作越多的產業,越容易透過導入 AI 提高工作效率。」反過來說,較傳統、人力密集,或仍高度依賴人工判斷的製造業,短期內未必能快速導入地端 AI。

依 QNAP 提供的資料,企業也可用「高頻、大量、敏感」三個條件做第一輪判斷:資料是否被頻繁調用?規模是否大到雲端傳輸與長期費用開始變得明顯?內容是否涉及個資、法規、智慧財產或商業機密?三個條件愈集中,地端部署愈值得評估;三者都不成立時,使用雲端 API 往往更簡單,也可能更划算。

可以先等的企業,大致也有三種。第一,資料仍分散、版本混亂、權限不清,急著上 AI 只會把混亂放大,先完成集中與治理,效率就可能先提升。第二,找不到一個具體且反覆發生的業務痛點,只因為「別人都在做」而採購,設備很可能變成昂貴的展示品。第三,使用量仍小、需求偶發,現階段雲端的彈性反而更有優勢。

因此,POC 不應只驗證「模型答不答得出來」,還要回答三個問題:資料由誰負責,誰可以存取?導入後能節省多少查找時間、傳輸成本或人工作業?正式上線後,誰負責資料、模型與資安維運?只有當效益與責任都能被量化,才適合從展示走向正式部署。

企業願意把部分資料留在自己的機房,動力最終仍回到資料主權。QNAP 的主要市場分布在歐洲、美洲與亞太,其中歐洲占比將近一半,而歐洲也正是全球推動資料主權的最大動力。

QNAP 的產品已取得 ISO 27001、ISO 27017 與 ISO 27018 等多項認證,並滿足 GDPR、HIPAA 等資料保護與法規遵循需求;累積至今,已售出約數百萬台裝置,協助企業打造智慧、安全的儲存方案。

至於普及時間點,劉文義提出一個明確的價格與效能交會點:地端應用若要順暢運作,運算量可能至少要達到 300 至 600 TOPS,甚至 800 TOPS,同時價格要落在新台幣 5 萬至 8 萬元。目前符合這些條件的硬體方案仍很有限。

qnap3.png
「AI NAS 不是多了 AI 功能,而是改寫了資料在工作流的位置。」威聯通科技總經理劉文義坦言,地端算力成本高昂,QNAP 透過「算力分級」與開放模型架構,助企業逐步建構私有 RAG 知識庫與 AI 團隊。
圖/ 數位時代

「預測約兩、三年後,應該很快會看到符合一般大眾期待、具備合理 CP 值的產品。那個時間點,就會是 AI 落地最蓬勃發展的時候。」在此之前,企業真正能先做的,不是搶著買最大的模型或最昂貴的顯示卡,而是把資料治理、使用權限與高價值場景準備好。

QNAP 以「資料煉油廠」比喻自己的角色:原油再多,沒有整理、提煉與配送的過程,也無法成為可用的能源。這個定位也點出地端 AI 的競賽條件——不是誰先買到算力,而是誰的資料先準備好被調用。模型會持續更換,但企業自己的資料層則會長期存在。

AI NAS 不是把模型塞進儲存設備,而是在資料必須留在企業內時,讓搜尋、推論與管理靠近資料的地端節點。

QNAP World Tour 2026 台北場將於 2026 年 9 月 18 日(五)舉行,現場將聚焦 AI 應用、儲存備份、網通產品、資安與監控,並安排 Live Demo,適合 IT 管理者、系統整合商與企業決策者參加。

活動地點:新板希爾頓酒店|如意 AB 廳

活動時間:09:20–16:00

地址:新北市板橋區民權路 88 號 2F

立即報名:https://bnex.tw/9f7my4

2026 QNAP 台灣企業資安韌性大調查,填問券抽好禮,倒數計時:https://www.surveycake.com/s/q4abw

登入數位時代會員

開啟專屬自己的主題內容,

每日推播重點文章

閱讀會員專屬文章

請先登入數位時代會員

看更多獨享內容

請先登入數位時代會員

開啟收藏文章功能,

請先登入數位時代會員

開啟訂閱文章分類功能,

請先登入數位時代會員

我還不是會員, 註冊去!
追蹤我們
台達電全解讀
© 2026 Business Next Media Corp. All Rights Reserved. 本網站內容未經允許,不得轉載。
106 台北市大安區光復南路102號9樓