台灣半導體產業被稱為「護國神山」，吸引不少理工科學生投入。但對許多大學生來說，一個常見疑問是：「半導體工程師需要會寫程式嗎？」答案其實沒有那麼單純。因為在半導體產業中，不同職位的工程師工作內容差異極大，對程式能力的要求也不一樣。記者黃仁杰／綜合報導

台灣半導體產業被稱為「護國神山」，吸引不少理工科學生投入。但對許多大學生來說，一個常見疑問是：「半導體工程師需要會寫程式嗎？」答案其實沒有那麼單純。因為在半導體產業中，不同職位的工程師工作內容差異極大，對程式能力的要求也不一樣。

[caption id="attachment_209353" align="aligncenter" width="1536"] 在半導體產業中，不同職位的工程師工作內容差異極大，對程式能力的要求也不一樣。（圖／AI生成）[/caption]

大致來說，半導體工程師可分為三大類型，包含製造端工程師、設計工程師，以及測試與產品工程師。不同職位需要的技能組合差異明顯，也代表不同的職涯發展方向。

更多科技工作請上科技專區：https://techplus.1111.com.tw/

製造端工程師 程式能力非必要

在晶圓廠工作的工程師，多數屬於製造端，例如製程工程師（Process Engineer）或設備工程師（Equipment Engineer）。這類職位的核心任務，是維持產線穩定運作、提升晶圓良率，以及調整製程參數。

例如製程工程師需要分析不同製程步驟的變化，例如蝕刻、沉積或光刻條件，找出影響晶片品質的關鍵因素；設備工程師則需要負責機台維護、故障排除與設備效率提升。

在這類工作中，程式能力通常不是必要條件。但隨著智慧製造與數據分析逐漸導入，不少工程師仍會使用 Python、MATLAB或Excel VBA 進行資料分析與自動化處理，以提高產線效率。

因此，對想進入晶圓廠的學生而言，扎實的電機、電子、材料或化工背景通常比程式能力更重要。

IC設計工程師 程式能力是基本門檻

若是半導體產業中偏向設計端的職位，例如IC設計工程師或EDA工程師，情況就完全不同。

IC設計工程師的工作，是將晶片功能轉換為電路架構，再透過設計工具完成晶片設計與驗證。這類工程師通常需要使用硬體描述語言（HDL），例如Verilog或VHDL，來描述電路邏輯。

此外，在設計與驗證流程中，也常會使用Python、C++或Perl等程式語言進行模擬、測試與自動化工具開發。因此，對IC設計工程師來說，程式能力幾乎是基本門檻之一。

也因為技術門檻較高，IC設計相關職位通常集中在電機、電子與資訊工程等科系學生。

測試與產品工程師 硬體與數據分析雙棲

另一類常見職位是測試工程師（Test Engineer）與產品工程師（Product Engineer）。這類工程師主要負責晶片量產後的測試、品質管理與產品良率分析。

例如測試工程師需要設計測試流程，確認晶片是否符合規格；產品工程師則會分析量產數據，找出製程問題並協助改善良率。

在這類職位中，程式能力雖然不是像IC設計那樣的硬性要求，但具備資料分析與簡單程式能力仍然相當加分。許多工程師會利用Python或資料分析工具處理大量測試數據。

整體而言，半導體工程師最核心的能力仍然是工程基礎與問題解決能力，但隨著AI與智慧製造導入產線，具備基本的程式與數據分析能力，已逐漸成為半導體人才的重要競爭力。

這篇文章 半導體工程師一定要會寫程式？三種工程師能力大不同 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

AI程式輔助工具被廣泛視為提升軟體開發效率的利器，但最新研究卻顯示，AI實際上可能讓開發者效率變慢。由非營利研究機構「模型評估與威脅研究組織（METR）」進行的一項隨機對照實驗發現，使用AI輔助程式撰寫的開發者，實際工作時間反而增加了19%，與原先預期大相逕庭，而這些資深工程師仍誤以為效率提高了。記者李琦瑋／編譯

AI程式輔助工具被廣泛視為提升軟體開發效率的利器，但最新研究卻顯示，AI實際上可能讓開發者效率變慢。由非營利研究機構「模型評估與威脅研究組織（METR）」進行的一項隨機對照實驗發現，使用AI輔助程式撰寫的開發者，實際工作時間反而增加了19%，與原先預期大相逕庭，而這些資深工程師仍誤以為效率提高了。

[caption id="attachment_71945" align="alignnone" width="1200"] 研究顯示，AI輔助寫程式反而拖慢進度19%，但資深工程師仍誤以為變快了。（圖／123RF）[/caption]

研究團隊邀請了16位具有多年大型開源專案經驗的資深工程師，進行總計246項任務（如修復bug、開發新功能等），並讓系統隨機指定是否使用AI工具（主要是Cursor Pro和Claude 3.5/3.7 Sonnet）來完成。整體研究於2025年2月至6月間進行。

延伸閱讀：AI新創們搶攻瀏覽器市場 Google Chrome地位不保？

令人訝異的是，參與者事後仍普遍認為AI有助提升效率，估算任務完成時間縮短了20%。但實際上，AI輔助組花費的時間比未使用AI的對照組多出約19%，代表AI工具反而減慢了開發人員的速度。

研究指出5項可能導致效率降低的原因，包括開發者對AI效能過於樂觀；測試對象對原始碼庫高度熟悉，AI難以提供額外幫助；大型程式碼庫（超過100萬行）導致AI推理效率下降；AI建議的接受率低（不到44%），反而花費更多時間審查與修正；AI無法充分理解隱含的專案背景與語境。

此外，AI回應延遲與輸入上下文不足等問題，也可能加劇效率拖慢的現象。

報告中也附上時間分配圖示，顯示開發者使用AI後，實際撰寫程式與查找資料的時間減少，轉而花更多時間在與AI互動、等待AI生成內容與審查其輸出，甚至出現閒置。

雖然研究結果顯示目前AI工具未如預期提升效率，但研究作者也強調，這項實驗為特定時間點、特定工具與高熟悉度情境下的結果，未必適用於所有開發環境。

研究作者最後補充，這並不代表AI工具毫無助益，或未來不會更強，「AI技術仍有很大潛力，特別是在新專案、較小型的程式碼庫，或新手工程師的情境下，可能展現不同的生產力表現。」

資料來源：The Register

這篇文章 AI寫程式幫倒忙？拖慢進度19%、資深工程師仍誤以為變快了 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

幾年前自己剛出社會時覺得當主管很威風，現在倒是覺得當主管很可憐，當一個資深工程師開始兼任 ( Team Lead ) 或是正式轉任 ( Engineering Manager ) 管理職的時候，心中或多或少都會有一個疑問，就是還該不該繼續寫程式？關於這個問題想要將自己的所見所聞透過這篇文章記錄下來，文章會分成兩個部分，上半段談的是想法，下半段提的是做法。

圖文／smalltown

Background

幾年前自己剛出社會時覺得當主管很威風，現在倒是覺得當主管很可憐，當一個資深工程師開始兼任 ( Team Lead ) 或是正式轉任 ( Engineering Manager ) 管理職的時候，心中或多或少都會有一個疑問，就是還該不該繼續寫程式？關於這個問題想要將自己的所見所聞透過這篇文章記錄下來，文章會分成兩個部分，上半段談的是想法，下半段提的是做法。

Engineering Manager Need Coding?

From Team’s Point of View

自己覺得答案是肯定的，畢竟連 Elon Musk 都說過一個不會寫程式的技術主管，就像是騎兵隊長不會騎馬一樣 ( Reference )，身為技術主管必須要決定工作任務的優先順序，與團隊內的成員進行互動，因此要勝任這樣的責任就要對於團隊成員的日常工作有一定程度的了解，如此一來，才能夠知曉在工作任務的進行中可能會遇到什麼樣的問題，提供大概的解決方向與對應的協助。

在剛轉任管理職的頭幾年，或許對這些事情都還十分地熟悉，但是假如沒有堅持繼續寫程式，你將會對於這些技術相關的工作內容越來越生疏，到後來甚至形同陌路，導致無法了解自己帶領的團隊成員在開發什麼與他們遇到什麼樣的障礙，所以無法提供團隊成員實質的幫助；最後開始無法理解目前世界上最新的技術趨勢；慢慢失去對於技術的敏銳度與遠見，無法去評估未來的技術發展來做出對應的技術決定。

From Personal Point of View

在一開始人們仍然會來找你解決技術相關的問題，你依然還存在於名為技術的軌道上 ( Technique Track )，但隨著開始把越來越多的時間投資在增進一些軟性技能上，例如與人溝通，知識的轉移，諮詢…等 。( Management Track )，伴隨而來越來越多的會議，你專注在讓其他人成為更好的工程師，創建更有能力的團隊，並且輸出可靠的成果，漸漸地你在於技術方面的能力就這樣被團隊內的資深工程師給取代掉，最終不再知道工作如何被完成的方式。

團隊的技能持續進步，但你的技能保持不變，雖然你在管理方面學到很多新東西，但周圍的人不再認為你具有創造力，你無法再提供技術相關的建議，最後甚至需要依靠別人告訴你，你的團隊成員表現的如何；走到這一步時，你已經無法為團隊提供專業的技術建議，你變成管理流程中的一個小環節，試想你的工作只是拉表格，開會…等事務，你不知道完成工作的具體方式，結果就是變成一個取代性相對高的員工。

How Much Code Should A Engineering Manager Write?

技術團隊最重要的就是產出良好品質的程式，一個沒有技術能力的技術主管可能會無法很順利地帶領團隊完成此目標，而當技術主管變成管理流程的環節時，你的重要性會降低，取代性變高；那麼一個技術主管該花多少時間來寫程式呢？有文章提出來至少該花 30% 的時間 ( Reference )，不過其實這不是個好問題，所以當然 30% 也不會是一個好的答案。

Where Should A Engineering Manager Write Code?

重點要擺在一個技術主管要為了什麼樣的理由去寫程式？！而不是要寫多少程式，因為寫程式代表的並不是 100% 的時間都是在敲鍵盤輸入程式語言，大約只有 10～20% 的時間是真的在敲鍵盤輸入程式語言，另外 80~90% 的時間會花在設計，溝通，測試和閱讀…等方面上，因此一個技術主管要參與寫程式這件事情時，有不少種方式可以達成。

Practices

所以技術主管應該要怎麼讓自己在擔任管理職時，還是可以擁有相當的技術能力呢？！底下列出一些具體的作法供大家參考：

?‍? 確保自我程式技能

絕對不能跟一般工程師一樣花大量的時間在主要功能的開發上面，但還是要確保自己技術水平保持在能夠熟知目前狀況與了解團隊遭遇的挑戰；講白話一點就是寫一些不會影響專案進行的程式，但卻又讓自己維持寫程式的手感。

• 開發讓自己團隊日常工作更輕鬆的工具
• Review 團隊成員發的 Pull Request （不能是主要 Reviewer）
• 利用 POC 來探索即將迎來工作的可行性
• 幫忙清理技術債
• 修復一些小 Bug
• 在工作外貢獻於開源專案

?‍? 協助增加團隊產出

不要因為覺得自己來寫會比較快，就讓自己重拾資深工程師的角色，而是要讓團隊跟線上服務一樣是可以橫向擴展與具備高可用；因為一個人的輸出總是有其極限所在，當什麼事情都只能由某個特定人士才能完成的話，導致整個團隊過度依賴一個人，此人會成為團隊輸出的瓶頸，同時你也沒有善盡管理團隊的職責，讓團隊發揮應有的生產力，所以當發現團隊成員間有知識或是能力上的落差時，可以花時間去做以下的事情。

• 撰寫技術文件
• Pair Programming
• 內部技術分享（一次性分享或是讀書會）

?‍? 要不要擔任技術主管？

假如覺得自己不寫程式是在浪費才能，對公司是重大的損失，那就請不要當主管，畢竟管理也是一個專業的全職工作，不是可以讓你當成副業的，雖然是因為你的技術讓你成為主管，但主管這個角色有其不同的責任與工作需要你去完成，假如你還是習慣當一個獨立貢獻者，其實你是在毒害自己的團隊與整個組織！為什麼會這樣說呢？

• 因為你正在剝奪別人學習和成長的機會
• 帶領好一個團隊其實能夠對組織產生更大的影響
• 因為主管的角色，導致團隊成員不敢直接批評你所撰寫出來的程式碼
• 不像你需要分心身兼二職的人，能夠寫出比你更好的程式
• 要是你擔任技術主管的薪水比工程師來得高，其實你領到比你的貢獻還要多的薪水，因為你讓公司花更多的錢聘請你來做其他人就可以完成的工作

Conclusion

總而言之，就算擔任技術主管也不應該放棄寫程式這件事情，它仍然是你工作的一部分，只是你需要換一個方式來寫程式，你需要因為不同的原因去做它，並且確保自己在寫的程式不會阻擋到專案的進行。

其實一個主管可以帶來的影響力在於整個團隊的產出，而不在於你自己個人的貢獻上，雖然管理不是一件容易的事，但既然你擔任著這個角色，就要負責去做好它，而不是利用寫程式來做逃避，擁有寫程式的手感只是主管工作的一部份而不是全部。

這篇文章 沒技術系列 — 軟體工程師主管要寫程式嗎？ 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。