你每天有多少时间是真正花在想清楚要做什么上面的大部分时间其实都在处理各种中间层的事情写 Tcl/python脚本、整理 timing report……这些东西不是不重要但它们只是通往目标的路本身不是目标。那些年我们浪费在格式上的时间举个很具体的例子。你要分析一份 STA 报告找出所有 slack 为负的路径按照 endpoint 分组再统计每个 clock domain 里最差的 10 条。以前怎么做打开 terminal写 Perl 或者 Python调试半天跑出来发现格式不对再改。前前后后一两个小时没了。现在怎么做直接跟大模型说我有一份 Synopsys PT 的 timing report帮我写个脚本找出所有 violated paths按 clock domain 分组输出前 10 条最差的路径含 startpoint 和 endpoint。几秒钟脚本出来了。可能还要微调但核心框架就在那里。工程师的精力从怎么写脚本转移到我到底要分析什么。这个转移看起来只是工具层面的变化但背后触动的东西要深得多。从 How 到 What这是一次真正的工作重心转移以前我们做的那些工作哪些是真正在创造价值的芯片工程里创造价值的核心在于判断力——判断这个设计方案对不对这个时序约束合不合理这个 floorplan 选择会不会留下隐患。这些判断需要对系统的深度理解需要经验的积累需要对 spec 本身的把握。而写脚本、整理格式、重复性的文档工作只是让这些判断落地的工具。大模型让这些工具的获取成本大幅下降。于是工程师可以把更多精力放在想清楚要做什么上而不是怎么做出来。这个转变从 How 到 What从实现到定义其实是工程师职业价值的一次重新定位。繁文缛节消失之后剩下的是什么有人可能会觉得那些重复性工作没了工程师岂不是没事干了这个担心是真实的。那些繁文缛节消失之后暴露出来的是以前被掩盖的更难的问题。一个 timing closure 的根本挑战从来都不是脚本写得不够快是对关键路径的判断、对约束合理性的理解、对设计本身的掌控。这些东西大模型现在做不了短期内也做不了。现阶段这件事对芯片工程师意味着什么不用过度焦虑但也不应该无动于衷。如果以前你的核心价值主要体现在写脚本快那的确需要认真想一想了。如果你的价值在于深度理解芯片设计的某个环节能准确判断问题出在哪、能给出别人想不到的解决方案这种能力在大模型的时代只会更值钱因为你现在可以用大模型帮你快速实现验证你的想法效率会成倍提升。说到底大模型不是在替代谁是在重新分配工程师的注意力资源。