作者jason90814 (菜B08)
看板Tech_Job
标题Re: [讨论] 是不是不要再往数位IC设计挤了？
时间Sun Jul 5 13:47:29 2026
※ 引述 《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://webptt.com/cn.aspx?n=bbs/Tech_Job/M.1783230451.A.A2F.html
1F：推 VincentWu: 其实即便是软体业，现在也是要资深工程220.134.106.95 07/05 13:53
2F：→ VincentWu: 师去 verify AI 产出的结果吧220.134.106.95 07/05 13:53
3F：推 jack529: 那代表只需要资深的1.132.29.63 07/05 13:57
就我现在看起来，反而是资深工程师都把前段RTL缺卡死，signoff相关的杂事都给菜鸟做。
这部分说不定是公司已经在为未来布局了
※ 编辑: jason90814 (49.215.101.168 台湾), 07/05/2026 13:59:53
4F：推 dakkk: 那也是eda tool的问题 工作看tool跑的结果123.192.156.133 07/05 14:02
5F：→ dakkk: 就只是杂事123.192.156.133 07/05 14:02
但就是这些杂事 1.AI目前做不到 2.机会成本太高不敢让AI做 3.验证还在随着制程提升一
直在变复杂
6F：推 sarsman: 软体业要看维护的专案性质，如果是server123.194.171.137 07/05 14:03
7F：→ sarsman: 的话改动影响到production也影响很大123.194.171.137 07/05 14:04
※ 编辑: jason90814 (49.215.101.168 台湾), 07/05/2026 14:08:54
※ 编辑: jason90814 (49.215.101.168 台湾), 07/05/2026 14:11:07
8F：推 botnet: 有没有可能 未来错误也降低了42.73.44.21 07/05 14:18
9F：嘘 brightest: 谁跟你说coding 跟physical design 无1.161.170.218 07/05 14:25
10F：→ brightest: 关的1.161.170.218 07/05 14:25
我现在就在做PD喔，我想表达的意思比较像是，这不能单靠coding就搞定
软体的code是直接丢下去跑结果，但PD的code是用来串flow喂给工具，因此还是要知道tool
怎麽操作，跑完要开tool看，很多错误也不是改code就好，要用手下去修
因此软体在语言模型变强时就受到影响了，但PD大概要等很强的Agent出来才会受影响
11F：→ brightest: Ics刚毕业的也没这麽口木1.161.170.218 07/05 14:26
12F：推 rogergon: 我看到的是，AI完成三四种coding，让人111.71.96.221 07/05 14:27
13F：→ rogergon: 去选适合速度或面积需求的。111.71.96.221 07/05 14:27
14F：推 katzlee: 出包和客户开会难道叫AI去，研发工程师不36.227.6.155 07/05 14:34
15F：→ katzlee: 可能消失 36.227.6.155 07/05 14:34
※ 编辑: jason90814 (49.215.101.168 台湾), 07/05/2026 14:42:32
16F：→ tomsawyer: 我现在也做PD 写了一堆tcl来串tool 36.239.169.219 07/05 14:44
17F：→ tomsawyer: 如果没给skill/mcp，ai写的东西就是屎 36.239.169.219 07/05 14:45
18F：→ tomsawyer: signoff倒是应该可以取代 尤其是有36.239.169.219 07/05 14:46
19F：→ tomsawyer: internal tool的公司 36.239.169.219 07/05 14:46
20F：推 bunjie: 杂事只要卡到会攸关成败 基本上就不是杂 182.155.197.16 07/05 15:15
21F：→ bunjie: 事了 182.155.197.16 07/05 15:15
22F：→ bunjie: AI能不能取代一项工作或是技能 还是在於 182.155.197.16 07/05 15:17
23F：→ bunjie: 他出包时严重程度会不会影响到这个案子 182.155.197.16 07/05 15:17
24F：→ bunjie: 不会才有机会取代 182.155.197.16 07/05 15:17
25F：→ hidog: 自己觉得AI会当辅助工具而不是取代111.241.133.246 07/05 15:42
26F：→ francej: 不是完全不需要人 只是不再需要 那麽多人 36.230.165.161 07/05 15:48
27F：→ francej: 扛责任还是要靠人 所以未来需要的就只有36.230.165.161 07/05 15:49
28F：→ francej: 那位可以扛责任的人 36.230.165.161 07/05 15:49
29F：→ mooto: 资深的还是要 亦即你不可能完全淘汰220.129.139.152 07/05 16:33
30F：→ mooto: 公司不会傻到叫老师傅回家 只会适应220.129.139.152 07/05 16:34
31F：推 stillboy: 都一样是coding，都一样不能犯错 123.192.90.30 07/05 17:18
32F：→ stillboy: 都很快会被全面取代 123.192.90.30 07/05 17:18
33F：→ sonicyang: 这什麽奇怪的观点，这样嵌入式的程式开 133.159.152.53 07/05 18:55
34F：→ sonicyang: 发不是一样问题。一堆也都出场烧死不能 133.159.152.53 07/05 18:55
35F：→ sonicyang: 更新，坏了会死人，还有跟硬体介接搞得 133.159.152.53 07/05 18:55
36F：→ sonicyang: 半死。现在也是都Agentic coding啊。问 133.159.152.53 07/05 18:55
37F：→ sonicyang: 题是有没有办法Check，不是难不难。有 133.159.152.53 07/05 18:55
38F：→ sonicyang: 办法 Check 的情况下，既使半桶水，每133.159.152.53 07/05 18:55
39F：→ sonicyang: 天100万上下一样卷死码农ˉ。133.159.152.53 07/05 18:55
40F：推 tom830001: 任何事情 都可以被ai取代@_@118.232.63.183 07/05 19:48
41F：推 gotofumihisa: 我觉得AI的目的是加速开发而不是取 101.10.56.56 07/05 20:37
42F：→ gotofumihisa: 代 幻想AI完全取代某个职位只有真 101.10.56.56 07/05 20:37
43F：→ gotofumihisa: 的分工很细致的大公司可能发生 101.10.56.56 07/05 20:37
44F：→ gotofumihisa: 但这也不代表公司就不缺人 而是分工 101.10.56.56 07/05 20:37
45F：→ gotofumihisa: 的生态出现变化而已 101.10.56.56 07/05 20:37
46F：→ sonicyang: 正常工程师是不至於被取代，低阶码农派 130.62.95.177 07/05 20:52
47F：→ sonicyang: 遣SOP生化机器人是真的等着被取代，跟 130.62.95.177 07/05 20:52
48F：→ sonicyang: 你讲话还会有情绪，不如跟AI讲话 130.62.95.177 07/05 20:52
49F：→ kshieh: 你问问那位主管 他们家的FW是否不用帮IC设 61.230.2.56 07/05 21:14
50F：→ kshieh: 计错误擦屁股 61.230.2.56 07/05 21:14
会需要FW就是因为数位设计出错的成本很高啊，所以要有个成本比较低的补法
如果你觉得FW很累，那更凸显数位设计需要有人把关的重要性
※ 编辑: jason90814 (49.216.132.246 台湾), 07/05/2026 21:30:54
51F：推 kentelva: 没有人说到重点，要让AI完全接管digit 36.226.197.144 07/05 22:01
52F：→ kentelva: al ic, 重点是文件描述的完整性与精确 36.226.197.144 07/05 22:01
53F：→ kentelva: 性。这样才能有完整的设计和验证promp 36.226.197.144 07/05 22:01
54F：→ kentelva: t。这才是最难的地方 36.226.197.144 07/05 22:01
55F：→ VicLien: 等代工厂standard cell全面模组化 是否 122.121.141.23 07/05 22:11
56F：→ VicLien: 还要人头扛责任就很难说 先进代工厂也 122.121.141.23 07/05 22:11
57F：→ VicLien: 很怕设计厂设计导致低良率 122.121.141.23 07/05 22:11
58F：推 marsonele: 通常tape out之後就是fw去补洞了 1.169.248.197 07/05 23:03
59F：推 givgi456: 51楼专业 61.230.56.138 07/06 07:23
60F：推 dakkk: 的确 不然怎会一堆work around 39.14.0.90 07/06 08:04
61F：推 Samurai: 所以现在就是找tool商直接合作，从源头 1.171.3.104 07/06 08:16
62F：→ Samurai: 开始搞规则模组化，不是你想的自己瞎弄 1.171.3.104 07/06 08:16
63F：推 Samurai: 而且还有DV把关，感觉DV会最先受到冲击 1.171.3.104 07/06 08:21
64F：推 zaq851017: 那是你以现在AI能力看吧，我自己认 49.214.3.34 07/06 10:51
65F：→ zaq851017: 为三五年後不管硬体还是软体工程师 49.214.3.34 07/06 10:51
66F：→ zaq851017: 都是AI的天下吧 49.214.3.34 07/06 10:51
67F：推 nikolas: 有没有一种可能，你现在看到很多杂事要 101.10.10.71 07/06 11:39
68F：→ nikolas: 做，其实就是因为人类搞出来的，因为公 101.10.10.71 07/06 11:39
69F：→ nikolas: 司没有人愿意花时间去优化架构，都是一 101.10.10.71 07/06 11:39
70F：→ nikolas: 堆老旧习惯层层堆叠出来的狗屎，所以搞 101.10.10.71 07/06 11:39
71F：→ nikolas: 得很复杂需要工程师。之後AI介入，直接 101.10.10.71 07/06 11:39
72F：→ nikolas: 重新优化架构优化流程，可能真的需要1/1 101.10.10.71 07/06 11:39
73F：→ nikolas: 0的人力就可以了 101.10.10.71 07/06 11:39
74F：推 bunjie: 如果可以 那GG一堆工程师应该也能裁了 223.141.130.76 07/06 14:45
75F：推 a37805: 容错低（x)错了双手一摊叫sw扛（o)114.137.185.119 07/06 18:43
76F：推 frozen: 工程师就是负责背锅的 XD 42.79.69.170 07/06 19:01
77F：→ bmiss: 叫AI做事，也要描述的清清楚楚。不然根本灾 39.15.33.230 07/06 19:07
78F：→ bmiss: 难 39.15.33.230 07/06 19:07
79F：→ Ratio0306: PD不是只有用tool，这些tool本身也是co 114.137.195.94 07/06 20:27
80F：→ Ratio0306: ding出来的，coding这些tool也是PD的一 114.137.195.94 07/06 20:27
81F：→ Ratio0306: 环 114.137.195.94 07/06 20:27
82F：→ tomsawyer: coding这些tool就是eda vendor的事情 49.214.2.134 07/06 22:41
83F：→ tomsawyer: 了 49.214.2.134 07/06 22:41
84F：→ j0618204: 加速开发就是不需要那麽多人...114.137.175.142 07/07 05:50
85F：推 senjyu: APR的agent还要好长一段路 61.230.3.186 07/07 11:37
86F：推 garfield100: 工程师负责背锅 42.73.177.9 07/07 19:44
87F：→ garfield100: AI不背锅的啦 42.73.177.9 07/07 19:44
88F：→ garfield100: 不是容错低 只是推给别人背锅 42.73.177.9 07/07 19:45
89F：→ shangclock: 错了还不是两手一摊找软解、ECO、改cu 42.72.127.70 07/08 13:11
90F：→ shangclock: t然後下颗IC记得修，讲的好像都不能出 42.72.127.70 07/08 13:11
91F：→ shangclock: 错,有出错就天崩地裂一样 42.72.127.70 07/08 13:11
92F：推 gsy2i7y14: 感谢分享 114.137.28.145 07/10 13:25
93F：推 acgotaku: 基本上容错空间越小的任务 越适合交给AI 59.115.66.22 07/10 19:02
94F：→ acgotaku: 你用出包找谁背的角度就很奇怪, 因为 AI 59.115.66.22 07/10 19:03
95F：→ acgotaku: 越来越不犯错 59.115.66.22 07/10 19:04
96F：→ acgotaku: 目前各大公司最新的模型, 你如果觉得他 59.115.66.22 07/10 19:09
97F：→ acgotaku: 会犯错, 请记住绝对 99.9% 是使用者问题 59.115.66.22 07/10 19:10
98F：推 blastillocal: 其实只是人类犯错有人可以卸责，AI 119.234.24.75 07/18 17:13
99F：→ blastillocal: 则不行 119.234.24.75 07/18 17:13
100F：推 GTRNO1: 1年前全世界顶尖公司的SWE打死不相信自己 49.217.121.244 07/22 11:09
101F：→ GTRNO1: 的工作岗位会被LLM给裁掉 现在换HWE在找 49.217.121.244 07/22 11:09
102F：→ GTRNO1: 藉口了 哈哈哈 49.217.121.244 07/22 11:09