你每天有多少时间是真正花在"想清楚要做什么"上面的？

大部分时间，其实都在处理各种"中间层"的事情：写 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 的根本挑战，从来都不是脚本写得不够快，是对关键路径的判断、对约束合理性的理解、对设计本身的掌控。这些东西，大模型现在做不了，短期内也做不了。

现阶段，这件事对芯片工程师意味着什么

不用过度焦虑，但也不应该无动于衷。

如果以前你的核心价值主要体现在"写脚本快"，那的确需要认真想一想了。

如果你的价值在于深度理解芯片设计的某个环节，能准确判断问题出在哪、能给出别人想不到的解决方案，这种能力在大模型的时代只会更值钱，因为你现在可以用大模型帮你快速实现验证你的想法，效率会成倍提升。

说到底，大模型不是在替代谁，是在重新分配工程师的注意力资源。