Re: [討論] 是不是不要再往數位IC設計擠了？

看板Tech_Job作者 (菜B08)時間12小時前 (2026/07/05 13:47), 4小時前編輯推噓12(13推 1噓 44→)
留言58則, 21人參與, 3小時前最新討論串2/4 (看更多)
※ 引述 《teddy98 (泰迪!走吧!)》 之銘言： : 　 : 據傳MTK跟SYNPS已經開始合作 : 　 : 開啟了滅絕數位IC工程師的計畫了 : 　 : 　 : Vibe Coding + Agentic Engineering : 　 : MTK已經成立AI部門（agent engineer）了 : 　 : 從專案到投片量產，客戶交期可望大幅縮短 : 　 : 　 : RTL Design --> Testing / Verification --> Defining Timing Constraint (有自動化 : 的tcl) : 　 : --> Logic Synthesis（合成工具讀入 RTL 與 Constraint，轉成 Gate-level Netlist） : --> APR --> ECO : 　 : 全部都可以由Agent Engineer完成 : 　 : 　 : 　 : 所以，真的 : 　 : 不要再往"數位IC"這條路擠了吧？ : 　 : 　 : 以後的人力需求會大幅縮減， : 　 : 因為AI比人做得更好，更快，更準確。 : 　 : AI能做，沒有理由請人來做。 : 　 : 　 : 　 : 數位IC已經注定被賜死了 : 　 : 　 : 但類比IC還沒，相信未來也不會，因為類比的電路架構跟程式和算法，比較沒有關係， : 　 : 要被AI完全替代，還有難度。 : 　 : 　 : 大家不要再往數位IC擠了，未來的招聘需求，會減少很多。 : 　 : 至於，該如何因應？只能拭目以待 : 　 本人最近剛畢業進數位設計工作 入職時有跟主管討論到這類的事 我覺得他說的很有道理，跟大家分享一下 他說軟體工程師跟數位設計雖然都算是coding的工作 但IC設計的容錯率比純軟低很多 軟體有bug就修一修更新一版 最慘還能recover到能動時候 看現在windows整天推一堆有bugs的更新就知道 對公司影響其實不大 但IC設計不是這樣 tapeout一次成本超級高 基本上沒有任何容錯空間 所以就算現在能讓AI寫RTL、寫flow 還是會需要人類去驗證，跑signoff 不然出包誰要背鍋？ 更何況數位設計中後端還有一堆跟coding無關的事 像physical design 因此頂多人力從前端寫RTL移向驗證signoff 但要像軟體那樣血洗應該是很難 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 49.215.101.168 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Tech_Job/M.1783230451.A.A2F.html
推
07/05 13:53, 12小時前 , 1F
其實即便是軟體業，現在也是要資深工程
07/05 13:53, 1F
→
07/05 13:53, 12小時前 , 2F
師去 verify AI 產出的結果吧
07/05 13:53, 2F
推
07/05 13:57, 12小時前 , 3F
那代表只需要資深的
07/05 13:57, 3F
就我現在看起來，反而是資深工程師都把前段RTL缺卡死，signoff相關的雜事都給菜鳥做。 這部分說不定是公司已經在為未來布局了 ※ 編輯: jason90814 (49.215.101.168 臺灣), 07/05/2026 13:59:53
推
07/05 14:02, 12小時前 , 4F
那也是eda tool的問題 工作看tool跑的結果
07/05 14:02, 4F
→
07/05 14:02, 12小時前 , 5F
就只是雜事
07/05 14:02, 5F
但就是這些雜事 1.AI目前做不到 2.機會成本太高不敢讓AI做 3.驗證還在隨著製程提升一 直在變複雜
推
07/05 14:03, 12小時前 , 6F
軟體業要看維護的專案性質，如果是server
07/05 14:03, 6F
→
07/05 14:04, 12小時前 , 7F
的話改動影響到production也影響很大
07/05 14:04, 7F
※ 編輯: jason90814 (49.215.101.168 臺灣), 07/05/2026 14:08:54 ※ 編輯: jason90814 (49.215.101.168 臺灣), 07/05/2026 14:11:07
推
07/05 14:18, 12小時前 , 8F
有沒有可能 未來錯誤也降低了
07/05 14:18, 8F
噓
07/05 14:25, 11小時前 , 9F
誰跟你說coding 跟physical design 無
07/05 14:25, 9F
→
07/05 14:25, 11小時前 , 10F
關的
07/05 14:25, 10F
我現在就在做PD喔，我想表達的意思比較像是，這不能單靠coding就搞定 軟體的code是直接丟下去跑結果，但PD的code是用來串flow餵給工具，因此還是要知道tool 怎麼操作，跑完要開tool看，很多錯誤也不是改code就好，要用手下去修 因此軟體在語言模型變強時就受到影響了，但PD大概要等很強的Agent出來才會受影響
→
07/05 14:26, 11小時前 , 11F
Ics剛畢業的也沒這麼口木
07/05 14:26, 11F
推
07/05 14:27, 11小時前 , 12F
我看到的是，AI完成三四種coding，讓人
07/05 14:27, 12F
→
07/05 14:27, 11小時前 , 13F
去選適合速度或面積需求的。
07/05 14:27, 13F
推
07/05 14:34, 11小時前 , 14F
出包和客戶開會難道叫AI去，研發工程師不
07/05 14:34, 14F
→
07/05 14:34, 11小時前 , 15F
可能消失
07/05 14:34, 15F
※ 編輯: jason90814 (49.215.101.168 臺灣), 07/05/2026 14:42:32
→
07/05 14:44, 11小時前 , 16F
我現在也做PD 寫了一堆tcl來串tool
07/05 14:44, 16F
→
07/05 14:45, 11小時前 , 17F
如果沒給skill/mcp，ai寫的東西就是屎
07/05 14:45, 17F
→
07/05 14:46, 11小時前 , 18F
signoff倒是應該可以取代 尤其是有
07/05 14:46, 18F
→
07/05 14:46, 11小時前 , 19F
internal tool的公司
07/05 14:46, 19F
推
07/05 15:15, 11小時前 , 20F
雜事只要卡到會攸關成敗 基本上就不是雜
07/05 15:15, 20F
→
07/05 15:15, 11小時前 , 21F
事了
07/05 15:15, 21F
→
07/05 15:17, 11小時前 , 22F
AI能不能取代一項工作或是技能 還是在於
07/05 15:17, 22F
→
07/05 15:17, 11小時前 , 23F
他出包時嚴重程度會不會影響到這個案子
07/05 15:17, 23F
→
07/05 15:17, 11小時前 , 24F
不會才有機會取代
07/05 15:17, 24F
→
07/05 15:42, 10小時前 , 25F
自己覺得AI會當輔助工具而不是取代
07/05 15:42, 25F
→
07/05 15:48, 10小時前 , 26F
不是完全不需要人 只是不再需要 那麼多人
07/05 15:48, 26F
→
07/05 15:49, 10小時前 , 27F
扛責任還是要靠人 所以未來需要的就只有
07/05 15:49, 27F
→
07/05 15:49, 10小時前 , 28F
那位可以扛責任的人
07/05 15:49, 28F
→
07/05 16:33, 9小時前 , 29F
資深的還是要 亦即你不可能完全淘汰
07/05 16:33, 29F
→
07/05 16:34, 9小時前 , 30F
公司不會傻到叫老師傅回家 只會適應
07/05 16:34, 30F
推
07/05 17:18, 9小時前 , 31F
都一樣是coding，都一樣不能犯錯
07/05 17:18, 31F
→
07/05 17:18, 9小時前 , 32F
都很快會被全面取代
07/05 17:18, 32F
→
07/05 18:55, 7小時前 , 33F
這什麼奇怪的觀點，這樣嵌入式的程式開
07/05 18:55, 33F
→
07/05 18:55, 7小時前 , 34F
發不是一樣問題。一堆也都出場燒死不能
07/05 18:55, 34F
→
07/05 18:55, 7小時前 , 35F
更新，壞了會死人，還有跟硬體介接搞得
07/05 18:55, 35F
→
07/05 18:55, 7小時前 , 36F
半死。現在也是都Agentic coding啊。問
07/05 18:55, 36F
→
07/05 18:55, 7小時前 , 37F
題是有沒有辦法Check，不是難不難。有
07/05 18:55, 37F
→
07/05 18:55, 7小時前 , 38F
辦法 Check 的情況下，既使半桶水，每
07/05 18:55, 38F
→
07/05 18:55, 7小時前 , 39F
天100萬上下一樣卷死碼農ˉ。
07/05 18:55, 39F
推
07/05 19:48, 6小時前 , 40F
任何事情 都可以被ai取代@_@
07/05 19:48, 40F
推
07/05 20:37, 5小時前 , 41F
我覺得AI的目的是加速開發而不是取
07/05 20:37, 41F
→
07/05 20:37, 5小時前 , 42F
代 幻想AI完全取代某個職位只有真
07/05 20:37, 42F
→
07/05 20:37, 5小時前 , 43F
的分工很細緻的大公司可能發生
07/05 20:37, 43F
→
07/05 20:37, 5小時前 , 44F
但這也不代表公司就不缺人 而是分工
07/05 20:37, 44F
→
07/05 20:37, 5小時前 , 45F
的生態出現變化而已
07/05 20:37, 45F
→
07/05 20:52, 5小時前 , 46F
正常工程師是不至於被取代，低階碼農派
07/05 20:52, 46F
→
07/05 20:52, 5小時前 , 47F
遣SOP生化機器人是真的等著被取代，跟
07/05 20:52, 47F
→
07/05 20:52, 5小時前 , 48F
你講話還會有情緒，不如跟AI講話
07/05 20:52, 48F
→
07/05 21:14, 5小時前 , 49F
你問問那位主管 他們家的FW是否不用幫IC設
07/05 21:14, 49F
→
07/05 21:14, 5小時前 , 50F
計錯誤擦屁股
07/05 21:14, 50F
會需要FW就是因為數位設計出錯的成本很高啊，所以要有個成本比較低的補法 如果你覺得FW很累，那更凸顯數位設計需要有人把關的重要性 ※ 編輯: jason90814 (49.216.132.246 臺灣), 07/05/2026 21:30:54
推
07/05 22:01, 4小時前 , 51F
沒有人說到重點，要讓AI完全接管digit
07/05 22:01, 51F
→
07/05 22:01, 4小時前 , 52F
al ic, 重點是文件描述的完整性與精確
07/05 22:01, 52F
→
07/05 22:01, 4小時前 , 53F
性。這樣才能有完整的設計和驗證promp
07/05 22:01, 53F
→
07/05 22:01, 4小時前 , 54F
t。這才是最難的地方
07/05 22:01, 54F
→
07/05 22:11, 4小時前 , 55F
等代工廠standard cell全面模組化 是否
07/05 22:11, 55F
→
07/05 22:11, 4小時前 , 56F
還要人頭扛責任就很難說 先進代工廠也
07/05 22:11, 56F
→
07/05 22:11, 4小時前 , 57F
很怕設計廠設計導致低良率
07/05 22:11, 57F
推
07/05 23:03, 3小時前 , 58F
通常tape out之後就是fw去補洞了
07/05 23:03, 58F
‣ 更多 jason90814 的文章
文章代碼(AID): #1gIU_pel (Tech_Job)
‣ 更多 jason90814 的文章
文章代碼(AID): #1gIU_pel (Tech_Job)