1. 从“画版图”到“写约束”：芯片设计流程正在被重新切分过去两年，我陆续参与过几个把机器学习塞进芯片设计流程的项目，有做布局布线的，有做参数调优的，也有做验证用例生成的。说实话，第一次看到工具自动跑出一版比手工调优还紧凑的布局时，心里是有点发毛的。但做得越多越明白一件事：AI 并没有把工程师从流程里踢出去，它只是把流程重新切了一刀，把原来靠人肉试错的部分拿走了，把定义问题、约束边界、判断结果的部分留了下来。这个标题问的是“护城河还剩什么”，我觉得这个问题本身就问偏了。护城河从来不是某一项具体技能，比如你会写某段脚本、你会调某个工具的参数。护城河是你对“什么问题值得解、什么结果算好、边界在哪里”的判断力。AI 擅长在给定目标下搜索最优解，但它不擅长定义目标本身。芯片设计里最贵的从来不是算力，是定义错方向之后浪费的那几个月流片周期。所以这篇我想聊的不是“AI 会不会取代工程师”这种空对空的话题，而是把芯片设计流程拆开，看看哪些环节已经被 AI 实质性地改变了，哪些环节它暂时还碰不动，以及在这个变化里，一个普通工程师应该把精力往哪里挪。适合正在做数字前端、后端、验证、DFT 的朋友看，也适合刚入行、担心自己学的技能会不会很快过时的新人。我会尽量把原理讲清楚，把能落地的操作和判断标准写出来，而不是只给结论。2. 芯片设计里到底哪些环节在被 AI 实质性地改写2.1 布局布线：从“手工摆楼层”到“目标驱动的搜索”布局布线是 AI 介入最早、也最见效果的环节。传统流程里，一个后端工程师拿到网表之后，要花大量时间做 floorplan，摆 macro、规划电源网络、估拥塞。这个过程高度依赖经验，同一个设计不同的人摆出来，面积和时序能差出一大截。AI 在这里做的事情，本质上是把“摆布”变成一个带约束的优化问题。你给它一个目标函数，比如在满足时序的前提下最小化面积，或者给定面积预算下最大化频率，它就在巨大的解空间里搜索。强化学习在这块用得比较多，因为布局本身是一个序列决策过程：先放哪个、后放哪个、放哪里，每一步都会影响后续可选空间。但这里有个很多人忽略的点：AI 搜索出来的结果，质量高度依赖你给它的约束和目标函数。约束写松了，它给你一个面积很小但时序一塌糊涂的方案；约束写死了，它又找不到可行解。我见过一个项目，团队把时序约束写得过于激进，工具跑了两天两夜，最后吐出来一个根本没法收敛的结果，白白浪费了算力。后来把约束按优先级分层，先保证关键路径，再优化次要路径，结果就正常了。所以这个环节里，工程师的价值从“会摆”变成了“会定义问题”。你得知道哪些路径是真的关键，哪些约束是可以放松的，哪些物理效应在这个工艺节点下必须考虑。这些判断，AI 目前给不了你，因为它不知道这个芯片最终要装在什么产品里、工作环境是什么样。2.2 参数调优：把“老师傅手感”变成可复现的搜索策略参数调优是另一个被 AI 改变得很彻底的环节。不管是模拟电路里的偏置电流、补偿电容，还是数字后端里的各种优化选项，传统做法都是老师傅凭手感试。试出来了，但说不清楚为什么，换个人、换个工艺节点，又得重新试。贝叶斯优化在这块用得很多。它的核心思想是：用一个代理模型去近似真实的代价函数，然后根据当前模型的不确定性来决定下一个采样点。简单说，就是“在探索未知区域和利用已知好区域之间找平衡”。相比网格搜索和随机搜索，贝叶斯优化在样本效率上有明显优势，通常几十次迭代就能找到不错的解，而网格搜索可能要几百上千次。我实际用下来，贝叶斯优化最适合的场景是：单次评估成本高、参数维度在 5 到 20 之间、参数之间有耦合但不算特别强。如果维度再高，代理模型本身就不准了，效果会打折扣。这时候可以考虑降维，或者用遗传算法这类基于种群的搜索策略。但这里有个坑：很多人把参数调优当成一个纯黑盒问题，扔给工具就不管了。实际上，参数之间的物理关系决定了搜索空间的结构。比如某个偏置电流和某个晶体管尺寸之间是有物理关联的，如果你在搜索空间里把它们当成独立维度，工具会浪费大量时间在物理上不合理的组合上。正确的做法是，把已知的物理约束编码进搜索空间，缩小无效区域。这个编码过程，就是工程师的经验在起作用。2.3 验证与测试：用例生成和覆盖率收敛的自动化验证是芯片设计里最耗人力的环节之一。一个中等规模的 SoC，验证用例动辄几千上万条，覆盖率收敛往往要跑几周甚至几个月。AI 在这块的介入主要有两个方向：一是自动生成激励，二是智能选择回归用例。自动生成激励这块，常用的是基于覆盖率反馈的方法。工具会根据当前覆盖率缺口，生成更有可能打到未覆盖区域的激励。这比随机生成效率高很多，因为随机生成大部分时间都在重复覆盖已经覆盖过的区域。智能选择回归用例则是另一个思路。每次代码改动之后，不需要跑全量回归，而是根据改动影响范围，挑选最相关的用例跑。这个思路在软件测试里已经很成熟了，芯片验证里也在逐步应用。我见过一个项目，用这个方法把回归时间从三天压缩到半天，效果很直接。但验证这块有个特殊性：覆盖率数字好看，不代表验证充分。有些 bug 藏在覆盖率已经 100% 的地方，因为覆盖模型本身没建对。AI 可以帮你更快地达到覆盖率目标，但它不能帮你判断“这个覆盖率模型是否合理”。这个判断，还是得靠对设计规格的深入理解。2.4 DFT 与测试：模式生成和诊断的智能化DFT 这块相对小众，但 AI 的介入也很明显。测试模式生成、测试压缩、故障诊断，这些环节都有 AI 的身影。比如测试压缩，传统方法是靠算法做确定性压缩，AI 可以在压缩率和测试时间之间找更好的平衡点。故障诊断这块，AI 的价值在于从大量测试失败数据里找规律。一个芯片测试失败，可能是设计问题、工艺问题、封装问题，也可能是测试程序本身的问题。传统做法是靠人一条条看 log，效率很低。用聚类或者分类模型先做一轮筛选，把明显相似的失败模式归到一起，工程师再重点看那些异常的，效率会高很多。但这个环节里，AI 的输出只能作为参考。因为测试失败的原因往往涉及物理层面的东西，比如某个金属层在特定工艺角下电阻偏大，这种问题 AI 从数据里不一定能直接看出来，需要工程师结合工艺知识去判断。3. 为什么“定义问题”比“解决问题”更难被替代3.1 目标函数写不对，AI 只会更快地跑偏这是我在实际项目里体会最深的一点。AI 是一个极其高效的执行者，但它执行的是你给它的目标。目标写错了，它不会质疑，只会用更快的速度、更大的算力，把你带到一个更离谱的地方。举个芯片设计里的例子。假设你在做一个低功耗设计，目标函数写的是“最小化动态功耗”。AI 可能会给你一个方案：把所有时钟频率降到极低，动态功耗确实下来了，但性能完全不达标。如果你把目标函数改成“在满足性能约束的前提下最小化动态功耗”，结果就完全不同。这个道理听起来简单，但实际操作里，目标函数的写法非常讲究。你得考虑：哪些是硬约束，哪些是软约束；多个目标之间怎么加权；约束是写在目标函数里作为惩罚项，还是作为独立的可行性判断。这些选择，直接决定了 AI 搜索的方向和最终结果的质量。我个人的经验是，写目标函数之前，先问自己三个问题：第一，这个设计最不能妥协的是什么？第二，哪些指标是可以 trade-off 的？第三，如果两个方案在主要指标上打平，我用什么次要指标来区分？把这三个问题想清楚，目标函数基本就成型了。3.2 约束边界来自物理世界，不来自数据AI 模型是从数据里学规律的，但芯片设计里很多约束来自物理世界，数据里不一定有。比如某个工艺节点下，金属线的电迁移限制、晶体管的匹配要求、封装的散热能力，这些是物理规律决定的，不是从历史数据里统计出来的。我见过一个案例，团队用历史项目数据训练了一个模型来预测布局后的时序，模型在训练集上表现很好，但换到一个新工艺节点上就完全不准了。原因很简单：新工艺的器件特性变了，历史数据里的规律不适用了。这时候，工程师对工艺的理解就成了关键。你得知道新工艺和旧工艺在哪些方面有本质差异，这些差异会如何影响时序，然后手动调整模型或者约束。所以 AI 在芯片设计里的一个根本局限是：它只能在它见过的数据分布里工作。一旦超出这个分布，它的输出就不可靠了。而芯片设计恰恰是一个不断面对新工艺、新架构、新场景的领域，分布外的情况非常常见。3.3 结果判断需要系统级视角，AI 只看局部指标AI 优化出来的结果，往往在它被训练的那个指标上表现很好，但放到整个系统里看，可能有问题。比如布局工具优化了线长，但可能增加了某个关键模块的拥塞，导致后续布线失败。或者参数调优工具优化了某个子模块的功耗，但增加了整体电源网络的噪声。这种局部最优和全局最优的冲突，在芯片设计里非常普遍。因为芯片是一个高度耦合的系统，任何一个局部的改动都可能产生连锁反应。AI 目前还很难理解这种系统级的耦合关系，它擅长的是在给定边界内找最优解，不擅长判断这个边界本身是否合理。工程师的价值就在这里：你得有系统级视角，知道各个模块之间怎么相互影响，知道哪些指标是真正重要的，哪些只是中间变量。这种判断力，来自对完整设计流程的理解，来自踩过足够多的坑之后的直觉。4. 工程师的护城河：从“会操作”到“会判断”的迁移路径4.1 把工具当黑盒用的人，最先被替代这句话可能有点刺耳，但我觉得是事实。如果你的工作内容是“打开工具、导入数据、点运行、看报告”，那这部分工作确实很容易被自动化。因为 AI 做这些事情比你快、比你稳定、还不用休息。但如果你能理解工具背后的原理，知道它在什么情况下会失效，知道怎么调整输入来获得更好的输出，那你的价值就不一样了。因为 AI 工具本身也需要人来调、来维护、来判断它的输出是否可信。我自己的做法是，每用一个新工具，都会花时间搞清楚它的核心算法是什么、关键参数控制什么、在什么边界条件下会出问题。比如用贝叶斯优化做参数调优，我会去看它的采集函数是怎么定义的，是偏向探索还是偏向利用，然后根据我的问题特点去调整。这些理解，让我在工具给出不合理结果时，能快速判断是哪里出了问题，而不是盲目地重新跑一遍。4.2 跨层理解：前端懂后端，后端懂前端芯片设计的分工越来越细，前端、后端、验证、DFT、封装，每个环节都有自己的工具和流程。但 AI 的介入正在打破这些边界，因为 AI 优化往往需要跨层的信息。比如布局优化需要知道时序的关键路径，时序分析需要知道物理布局的寄生参数，验证需要知道设计的实际使用场景。在这种情况下，只懂自己那一层的人会越来越被动。因为 AI 工具需要跨层输入，而提供这些输入、判断这些输入是否合理的人，必须是懂多层的人。我认识一个做后端的工程师，他花了很多时间学前端的设计流程和验证方法。一开始大家觉得没必要，但后来他在做布局优化时，能直接和前端工程师讨论时序约束的合理性，能判断哪些路径是真的关键，哪些是约束写得太保守。这种跨层理解，让他在项目里的价值明显高于只懂后端的同事。4.3 数据素养：知道什么数据能用，什么数据是垃圾AI 模型的效果，很大程度上取决于训练数据的质量。芯片设计里，数据来源很多：仿真数据、测试数据、历史项目数据、工艺厂提供的模型数据。这些数据的质量参差不齐，直接用很容易出问题。工程师需要具备的基本数据素养包括：知道数据是怎么产生的、知道数据的适用范围、知道数据里可能有哪些偏差。比如仿真数据，你得知道仿真模型在什么条件下是准的，在什么条件下会偏离实际。测试数据，你得知道测试条件是什么，是否覆盖了所有工作场景。我见过一个团队，用历史项目的功耗数据训练了一个预测模型，结果在新项目上预测偏差很大。后来发现，历史项目的数据是在某个特定工作模式下采集的，而新项目的工作模式完全不同。这就是典型的数据适用范围问题。如果工程师有基本的数据素养，在训练模型之前就会先检查数据的适用范围，而不是等模型出问题再回头找原因。4.4 沟通与翻译：把工程问题翻译成 AI 能理解的形式这一点经常被忽略，但我觉得越来越重要。AI 工具需要明确的输入：目标函数、约束条件、搜索空间。但实际工程问题往往是模糊的、多目标的、有隐含约束的。把工程问题翻译成 AI 能理解的形式，本身就是一个高价值的工作。比如老板说“这个芯片要又小又省电还得快”，这是一个模糊的需求。你需要把它翻译成：面积上限是多少、功耗预算是多少、关键路径的频率目标是多少、哪些指标是硬约束、哪些可以 trade-off。这个翻译过程，需要对设计、对工艺、对产品都有理解。而且这个翻译不是一次性的，AI 跑出结果之后，你可能需要根据结果反过来调整翻译。比如发现面积和功耗无法同时满足，就需要回去和老板沟通，看哪个指标可以放松。这种来回沟通和调整的能力，AI 目前完全不具备。5. 一个具体的例子：用 AI 做布局优化时，工程师到底在做什么5.1 问题定义阶段：把设计意图翻译成约束假设我们要做一个模块的布局优化。第一步不是打开工具，而是理解这个模块的功能和性能要求。它工作在什么频率？有哪些关键接口？有没有特殊的物理约束，比如模拟部分需要远离数字噪声源？这些信息，工具不知道，只有工程师知道。你需要把它们翻译成工具能理解的约束：频率目标、时序路径分组、物理禁区、电源域划分。这个翻译过程，直接决定了后续优化的方向。我通常会先画一张草图，标出必须放在一起的模块、必须分开的模块、对时序最敏感的路径、对噪声最敏感的区域。然后根据这张草图去写约束文件。这张草图不一定要很精确，但必须把关键关系表达清楚。5.2 约束编写阶段：哪些写死，哪些留活口约束编写是最考验经验的地方。写得太死，工具找不到可行解；写得太松，工具给你一个没法用的结果。我的原则是：物理约束写死，性能约束留活口。比如某个模块必须放在芯片的某个角落，这是物理约束，写死。但时序目标可以给一个范围，让工具在范围内搜索。如果工具在范围内找不到解，再逐步放松。另外，约束的优先级要明确。哪些是必须满足的，哪些是尽量满足的。工具在搜索时，会优先满足高优先级的约束。如果所有约束都是同一优先级，工具可能会为了满足一个次要约束而牺牲主要约束。5.3 结果评估阶段：看数字之外的东西工具跑完之后，会给你一堆报告：面积、线长、时序余量、拥塞图。但光看这些数字不够，你得看数字之外的东西。比如时序余量，工具报告说所有路径都满足了，但你要看关键路径的余量分布。如果大部分路径余量很大，只有少数路径余量很小，说明约束可能写得太松了，还有优化空间。如果所有路径余量都很小，说明约束写得太紧，工具已经尽力了。再比如拥塞图，工具报告说拥塞在可接受范围内，但你要看拥塞的分布。如果拥塞集中在某个区域，可能是那个区域的模块摆放不合理，需要手动调整。如果拥塞均匀分布，可能是整体布局密度太高，需要降低利用率。这些判断，需要你对设计有深入理解，知道什么样的结果算好，什么样的结果虽然数字达标但实际有问题。5.4 迭代调整阶段：什么时候该信 AI，什么时候该信自己AI 跑出来的结果，不一定是最优的。有时候工具陷入局部最优，你需要手动干预。有时候工具的结果看起来奇怪，但实际测试下来是好的，你需要相信它。我的经验是：如果工具的结果和我的直觉冲突，先别急着否定，花时间理解它为什么给出这个结果。如果我能理解它的逻辑，并且逻辑是合理的，那就接受。如果我理解不了，或者逻辑明显有问题，那就手动调整。比如有一次，工具把一个关键模块放在了离它的通信伙伴很远的地方，我一开始觉得不合理。但仔细看时序报告，发现这个模块的通信路径不是关键路径，而它占的面积很大，放在边缘反而减少了整体线长。这就是工具看到了我没看到的东西。但也有反例。有一次工具为了优化线长，把一个模拟模块放在了数字模块中间，完全忽略了噪声隔离的要求。这就是约束没写清楚，工具不知道这个物理限制。后来我把噪声隔离写成硬约束，结果就正常了。6. 新人该往哪个方向积累，才不会被工具甩下车6.1 先把一个环节吃透，再横向扩展我见过一些新人，什么工具都想学，什么流程都想碰，结果每个都只懂皮毛。这种“广度优先”的策略，在 AI 时代反而危险，因为皮毛层面的操作最容易被自动化。更稳妥的做法是，先选一个环节，比如时序分析或者布局布线，把它吃透。吃透的标准不是会用工具，而是理解工具背后的原理，知道它在什么情况下会失效，知道怎么调整输入来获得更好的输出。这个过程可能需要一两年，但值得。吃透一个环节之后，再横向扩展。这时候你有了一个参照系，学其他环节会快很多，而且能理解各个环节之间的关联。这种“T 型”能力结构，在 AI 时代更有竞争力。6.2 学会写脚本，但别只满足于写脚本脚本能力是基础，能帮你自动化重复工作。但只会写脚本不够，因为脚本实现的是你已经知道的流程，而 AI 能做的是探索你不知道的流程。比写脚本更重要的是，理解脚本背后的算法和数据结构。比如你写了一个脚本做时序分析，你得知道时序分析的基本算法是什么，关键路径是怎么找的， slack 是怎么算的。这些理解，让你在 AI 工具给出结果时，能判断结果是否合理。另外，学会用 AI 工具本身也是一项技能。不是会用界面就行，而是理解它的输入输出、理解它的适用边界、理解怎么调参。这些技能，需要在实际项目里慢慢积累。6.3 培养“端到端”的视角，别只盯着自己的工位芯片设计是一个长链条，从规格定义到最终产品，中间经过很多环节。只盯着自己工位的人，很难理解自己的工作在整体中的位置，也很难判断什么结果是真正重要的。培养端到端视角的方法有很多：多参加跨部门会议、多和上下游同事聊天、多读项目文档、多了解最终产品的使用场景。这些看起来和具体技术无关，但长期来看，它们决定了你的判断力上限。我自己的体会是，当我开始理解整个芯片从定义到量产的全流程之后，我在做自己那一小块工作时，判断标准完全不一样了。以前我只关心我的模块时序是否满足，现在我会关心这个模块在整个系统里的功耗占比、面积占比、对良率的影响。这种视角，让我在做技术决策时更有依据。6.4 保持对物理世界的理解，别被纯数据思维带偏AI 是数据驱动的，但芯片设计最终要落到物理世界上。器件有物理特性、连线有寄生参数、封装有热阻、系统有噪声。这些物理层面的东西，数据里不一定有，但决定了设计的成败。所以，不管 AI 工具多强大，保持对物理世界的理解都很重要。知道一个晶体管在物理上是怎么工作的、知道一条金属线在物理上有什么限制、知道一个封装在物理上能承受多少功耗。这些理解，让你在 AI 给出违反物理规律的结果时，能第一时间发现。我见过一些新人，过度依赖仿真工具，工具说行就行，工具说不行就不行。但工具本身也是基于模型的，模型有适用范围。超出适用范围，工具的结果就不可信了。这时候，对物理世界的理解就是最后的防线。7. 工具越强，判断力越贵做了这么多年芯片设计，我最大的感受是：工具一直在变强，从手工画版图到自动布局布线，从手工写测试到自动生成激励，每一次工具升级都会淘汰一批只会操作的人，同时让会判断的人更值钱。AI 只是这个趋势的延续，不是颠覆。它把搜索和优化的效率提升了一个数量级，但搜索和优化的目标、约束、边界，还是得人来定。而且因为 AI 跑得更快，定义错方向的代价反而更大了。以前手工试错，试错了还能及时回头；现在 AI 一晚上跑几千个方案，方向错了，浪费的是算力和时间，还有可能错过项目窗口。所以我的建议是：别把精力花在担心 AI 会不会取代你上，把精力花在提升自己的判断力上。判断力来自对原理的理解、对流程的熟悉、对物理世界的认知、对系统级权衡的把握。这些东西，AI 短期内学不会，长期来看也不容易替代，因为它们需要真实世界的反馈和跨领域的整合。最后分享一个我自己的小习惯：每次用 AI 工具跑出一个结果，我都会问自己一句“如果是我手工做，我会怎么做，和这个结果差在哪里”。如果差得不多，说明工具已经学到了我的经验；如果差得很多，说明要么工具没学好，要么我该更新自己的认知了。这个习惯，让我在工具越来越强的同时，自己的判断力也在跟着涨。
1. 从“画版图”到“写约束”：芯片设计流程正在被重新切分过去两年，我陆续参与过几个把机器学习塞进芯片设计流程的项目，有做布局布线的，有做参数调优的，也有做验证用例生成的。说实话，第一次看到工具自动跑出一版比手工调优还紧凑的布局时，心里是有点发毛的。但做得越多越明白一件事：AI 并没有把工程师从流程里踢出去，它只是把流程重新切了一刀，把原来靠人肉试错的部分拿走了，把定义问题、约束边界、判断结果的部分留了下来。这个标题问的是“护城河还剩什么”，我觉得这个问题本身就问偏了。护城河从来不是某一项具体技能，比如你会写某段脚本、你会调某个工具的参数。护城河是你对“什么问题值得解、什么结果算好、边界在哪里”的判断力。AI 擅长在给定目标下搜索最优解，但它不擅长定义目标本身。芯片设计里最贵的从来不是算力，是定义错方向之后浪费的那几个月流片周期。所以这篇我想聊的不是“AI 会不会取代工程师”这种空对空的话题，而是把芯片设计流程拆开，看看哪些环节已经被 AI 实质性地改变了，哪些环节它暂时还碰不动，以及在这个变化里，一个普通工程师应该把精力往哪里挪。适合正在做数字前端、后端、验证、DFT 的朋友看，也适合刚入行、担心自己学的技能会不会很快过时的新人。我会尽量把原理讲清楚，把能落地的操作和判断标准写出来，而不是只给结论。2. 芯片设计里到底哪些环节在被 AI 实质性地改写2.1 布局布线：从“手工摆楼层”到“目标驱动的搜索”布局布线是 AI 介入最早、也最见效果的环节。传统流程里，一个后端工程师拿到网表之后，要花大量时间做 floorplan，摆 macro、规划电源网络、估拥塞。这个过程高度依赖经验，同一个设计不同的人摆出来，面积和时序能差出一大截。AI 在这里做的事情，本质上是把“摆布”变成一个带约束的优化问题。你给它一个目标函数，比如在满足时序的前提下最小化面积，或者给定面积预算下最大化频率，它就在巨大的解空间里搜索。强化学习在这块用得比较多，因为布局本身是一个序列决策过程：先放哪个、后放哪个、放哪里，每一步都会影响后续可选空间。但这里有个很多人忽略的点：AI 搜索出来的结果，质量高度依赖你给它的约束和目标函数。约束写松了，它给你一个面积很小但时序一塌糊涂的方案；约束写死了，它又找不到可行解。我见过一个项目，团队把时序约束写得过于激进，工具跑了两天两夜，最后吐出来一个根本没法收敛的结果，白白浪费了算力。后来把约束按优先级分层，先保证关键路径，再优化次要路径，结果就正常了。所以这个环节里，工程师的价值从“会摆”变成了“会定义问题”。你得知道哪些路径是真的关键，哪些约束是可以放松的，哪些物理效应在这个工艺节点下必须考虑。这些判断，AI 目前给不了你，因为它不知道这个芯片最终要装在什么产品里、工作环境是什么样。2.2 参数调优：把“老师傅手感”变成可复现的搜索策略参数调优是另一个被 AI 改变得很彻底的环节。不管是模拟电路里的偏置电流、补偿电容，还是数字后端里的各种优化选项，传统做法都是老师傅凭手感试。试出来了，但说不清楚为什么，换个人、换个工艺节点，又得重新试。贝叶斯优化在这块用得很多。它的核心思想是：用一个代理模型去近似真实的代价函数，然后根据当前模型的不确定性来决定下一个采样点。简单说，就是“在探索未知区域和利用已知好区域之间找平衡”。相比网格搜索和随机搜索，贝叶斯优化在样本效率上有明显优势，通常几十次迭代就能找到不错的解，而网格搜索可能要几百上千次。我实际用下来，贝叶斯优化最适合的场景是：单次评估成本高、参数维度在 5 到 20 之间、参数之间有耦合但不算特别强。如果维度再高，代理模型本身就不准了，效果会打折扣。这时候可以考虑降维，或者用遗传算法这类基于种群的搜索策略。但这里有个坑：很多人把参数调优当成一个纯黑盒问题，扔给工具就不管了。实际上，参数之间的物理关系决定了搜索空间的结构。比如某个偏置电流和某个晶体管尺寸之间是有物理关联的，如果你在搜索空间里把它们当成独立维度，工具会浪费大量时间在物理上不合理的组合上。正确的做法是，把已知的物理约束编码进搜索空间，缩小无效区域。这个编码过程，就是工程师的经验在起作用。2.3 验证与测试：用例生成和覆盖率收敛的自动化验证是芯片设计里最耗人力的环节之一。一个中等规模的 SoC，验证用例动辄几千上万条，覆盖率收敛往往要跑几周甚至几个月。AI 在这块的介入主要有两个方向：一是自动生成激励，二是智能选择回归用例。自动生成激励这块，常用的是基于覆盖率反馈的方法。工具会根据当前覆盖率缺口，生成更有可能打到未覆盖区域的激励。这比随机生成效率高很多，因为随机生成大部分时间都在重复覆盖已经覆盖过的区域。智能选择回归用例则是另一个思路。每次代码改动之后，不需要跑全量回归，而是根据改动影响范围，挑选最相关的用例跑。这个思路在软件测试里已经很成熟了，芯片验证里也在逐步应用。我见过一个项目，用这个方法把回归时间从三天压缩到半天，效果很直接。但验证这块有个特殊性：覆盖率数字好看，不代表验证充分。有些 bug 藏在覆盖率已经 100% 的地方，因为覆盖模型本身没建对。AI 可以帮你更快地达到覆盖率目标，但它不能帮你判断“这个覆盖率模型是否合理”。这个判断，还是得靠对设计规格的深入理解。2.4 DFT 与测试：模式生成和诊断的智能化DFT 这块相对小众，但 AI 的介入也很明显。测试模式生成、测试压缩、故障诊断，这些环节都有 AI 的身影。比如测试压缩，传统方法是靠算法做确定性压缩，AI 可以在压缩率和测试时间之间找更好的平衡点。故障诊断这块，AI 的价值在于从大量测试失败数据里找规律。一个芯片测试失败，可能是设计问题、工艺问题、封装问题，也可能是测试程序本身的问题。传统做法是靠人一条条看 log，效率很低。用聚类或者分类模型先做一轮筛选，把明显相似的失败模式归到一起，工程师再重点看那些异常的，效率会高很多。但这个环节里，AI 的输出只能作为参考。因为测试失败的原因往往涉及物理层面的东西，比如某个金属层在特定工艺角下电阻偏大，这种问题 AI 从数据里不一定能直接看出来，需要工程师结合工艺知识去判断。3. 为什么“定义问题”比“解决问题”更难被替代3.1 目标函数写不对，AI 只会更快地跑偏这是我在实际项目里体会最深的一点。AI 是一个极其高效的执行者，但它执行的是你给它的目标。目标写错了，它不会质疑，只会用更快的速度、更大的算力，把你带到一个更离谱的地方。举个芯片设计里的例子。假设你在做一个低功耗设计，目标函数写的是“最小化动态功耗”。AI 可能会给你一个方案：把所有时钟频率降到极低，动态功耗确实下来了，但性能完全不达标。如果你把目标函数改成“在满足性能约束的前提下最小化动态功耗”，结果就完全不同。这个道理听起来简单，但实际操作里，目标函数的写法非常讲究。你得考虑：哪些是硬约束，哪些是软约束；多个目标之间怎么加权；约束是写在目标函数里作为惩罚项，还是作为独立的可行性判断。这些选择，直接决定了 AI 搜索的方向和最终结果的质量。我个人的经验是，写目标函数之前，先问自己三个问题：第一，这个设计最不能妥协的是什么？第二，哪些指标是可以 trade-off 的？第三，如果两个方案在主要指标上打平，我用什么次要指标来区分？把这三个问题想清楚，目标函数基本就成型了。3.2 约束边界来自物理世界，不来自数据AI 模型是从数据里学规律的，但芯片设计里很多约束来自物理世界，数据里不一定有。比如某个工艺节点下，金属线的电迁移限制、晶体管的匹配要求、封装的散热能力，这些是物理规律决定的，不是从历史数据里统计出来的。我见过一个案例，团队用历史项目数据训练了一个模型来预测布局后的时序，模型在训练集上表现很好，但换到一个新工艺节点上就完全不准了。原因很简单：新工艺的器件特性变了，历史数据里的规律不适用了。这时候，工程师对工艺的理解就成了关键。你得知道新工艺和旧工艺在哪些方面有本质差异，这些差异会如何影响时序，然后手动调整模型或者约束。所以 AI 在芯片设计里的一个根本局限是：它只能在它见过的数据分布里工作。一旦超出这个分布，它的输出就不可靠了。而芯片设计恰恰是一个不断面对新工艺、新架构、新场景的领域，分布外的情况非常常见。3.3 结果判断需要系统级视角，AI 只看局部指标AI 优化出来的结果，往往在它被训练的那个指标上表现很好，但放到整个系统里看，可能有问题。比如布局工具优化了线长，但可能增加了某个关键模块的拥塞，导致后续布线失败。或者参数调优工具优化了某个子模块的功耗，但增加了整体电源网络的噪声。这种局部最优和全局最优的冲突，在芯片设计里非常普遍。因为芯片是一个高度耦合的系统，任何一个局部的改动都可能产生连锁反应。AI 目前还很难理解这种系统级的耦合关系，它擅长的是在给定边界内找最优解，不擅长判断这个边界本身是否合理。工程师的价值就在这里：你得有系统级视角，知道各个模块之间怎么相互影响，知道哪些指标是真正重要的，哪些只是中间变量。这种判断力，来自对完整设计流程的理解，来自踩过足够多的坑之后的直觉。4. 工程师的护城河：从“会操作”到“会判断”的迁移路径4.1 把工具当黑盒用的人，最先被替代这句话可能有点刺耳，但我觉得是事实。如果你的工作内容是“打开工具、导入数据、点运行、看报告”，那这部分工作确实很容易被自动化。因为 AI 做这些事情比你快、比你稳定、还不用休息。但如果你能理解工具背后的原理，知道它在什么情况下会失效，知道怎么调整输入来获得更好的输出，那你的价值就不一样了。因为 AI 工具本身也需要人来调、来维护、来判断它的输出是否可信。我自己的做法是，每用一个新工具，都会花时间搞清楚它的核心算法是什么、关键参数控制什么、在什么边界条件下会出问题。比如用贝叶斯优化做参数调优，我会去看它的采集函数是怎么定义的，是偏向探索还是偏向利用，然后根据我的问题特点去调整。这些理解，让我在工具给出不合理结果时，能快速判断是哪里出了问题，而不是盲目地重新跑一遍。4.2 跨层理解：前端懂后端，后端懂前端芯片设计的分工越来越细，前端、后端、验证、DFT、封装，每个环节都有自己的工具和流程。但 AI 的介入正在打破这些边界，因为 AI 优化往往需要跨层的信息。比如布局优化需要知道时序的关键路径，时序分析需要知道物理布局的寄生参数，验证需要知道设计的实际使用场景。在这种情况下，只懂自己那一层的人会越来越被动。因为 AI 工具需要跨层输入，而提供这些输入、判断这些输入是否合理的人，必须是懂多层的人。我认识一个做后端的工程师，他花了很多时间学前端的设计流程和验证方法。一开始大家觉得没必要，但后来他在做布局优化时，能直接和前端工程师讨论时序约束的合理性，能判断哪些路径是真的关键，哪些是约束写得太保守。这种跨层理解，让他在项目里的价值明显高于只懂后端的同事。4.3 数据素养：知道什么数据能用，什么数据是垃圾AI 模型的效果，很大程度上取决于训练数据的质量。芯片设计里，数据来源很多：仿真数据、测试数据、历史项目数据、工艺厂提供的模型数据。这些数据的质量参差不齐，直接用很容易出问题。工程师需要具备的基本数据素养包括：知道数据是怎么产生的、知道数据的适用范围、知道数据里可能有哪些偏差。比如仿真数据，你得知道仿真模型在什么条件下是准的，在什么条件下会偏离实际。测试数据，你得知道测试条件是什么，是否覆盖了所有工作场景。我见过一个团队，用历史项目的功耗数据训练了一个预测模型，结果在新项目上预测偏差很大。后来发现，历史项目的数据是在某个特定工作模式下采集的，而新项目的工作模式完全不同。这就是典型的数据适用范围问题。如果工程师有基本的数据素养，在训练模型之前就会先检查数据的适用范围，而不是等模型出问题再回头找原因。4.4 沟通与翻译：把工程问题翻译成 AI 能理解的形式这一点经常被忽略，但我觉得越来越重要。AI 工具需要明确的输入：目标函数、约束条件、搜索空间。但实际工程问题往往是模糊的、多目标的、有隐含约束的。把工程问题翻译成 AI 能理解的形式，本身就是一个高价值的工作。比如老板说“这个芯片要又小又省电还得快”，这是一个模糊的需求。你需要把它翻译成：面积上限是多少、功耗预算是多少、关键路径的频率目标是多少、哪些指标是硬约束、哪些可以 trade-off。这个翻译过程，需要对设计、对工艺、对产品都有理解。而且这个翻译不是一次性的，AI 跑出结果之后，你可能需要根据结果反过来调整翻译。比如发现面积和功耗无法同时满足，就需要回去和老板沟通，看哪个指标可以放松。这种来回沟通和调整的能力，AI 目前完全不具备。5. 一个具体的例子：用 AI 做布局优化时，工程师到底在做什么5.1 问题定义阶段：把设计意图翻译成约束假设我们要做一个模块的布局优化。第一步不是打开工具，而是理解这个模块的功能和性能要求。它工作在什么频率？有哪些关键接口？有没有特殊的物理约束，比如模拟部分需要远离数字噪声源？这些信息，工具不知道，只有工程师知道。你需要把它们翻译成工具能理解的约束：频率目标、时序路径分组、物理禁区、电源域划分。这个翻译过程，直接决定了后续优化的方向。我通常会先画一张草图，标出必须放在一起的模块、必须分开的模块、对时序最敏感的路径、对噪声最敏感的区域。然后根据这张草图去写约束文件。这张草图不一定要很精确，但必须把关键关系表达清楚。5.2 约束编写阶段：哪些写死，哪些留活口约束编写是最考验经验的地方。写得太死，工具找不到可行解；写得太松，工具给你一个没法用的结果。我的原则是：物理约束写死，性能约束留活口。比如某个模块必须放在芯片的某个角落，这是物理约束，写死。但时序目标可以给一个范围，让工具在范围内搜索。如果工具在范围内找不到解，再逐步放松。另外，约束的优先级要明确。哪些是必须满足的，哪些是尽量满足的。工具在搜索时，会优先满足高优先级的约束。如果所有约束都是同一优先级，工具可能会为了满足一个次要约束而牺牲主要约束。5.3 结果评估阶段：看数字之外的东西工具跑完之后，会给你一堆报告：面积、线长、时序余量、拥塞图。但光看这些数字不够，你得看数字之外的东西。比如时序余量，工具报告说所有路径都满足了，但你要看关键路径的余量分布。如果大部分路径余量很大，只有少数路径余量很小，说明约束可能写得太松了，还有优化空间。如果所有路径余量都很小，说明约束写得太紧，工具已经尽力了。再比如拥塞图，工具报告说拥塞在可接受范围内，但你要看拥塞的分布。如果拥塞集中在某个区域，可能是那个区域的模块摆放不合理，需要手动调整。如果拥塞均匀分布，可能是整体布局密度太高，需要降低利用率。这些判断，需要你对设计有深入理解，知道什么样的结果算好，什么样的结果虽然数字达标但实际有问题。5.4 迭代调整阶段：什么时候该信 AI，什么时候该信自己AI 跑出来的结果，不一定是最优的。有时候工具陷入局部最优，你需要手动干预。有时候工具的结果看起来奇怪，但实际测试下来是好的，你需要相信它。我的经验是：如果工具的结果和我的直觉冲突，先别急着否定，花时间理解它为什么给出这个结果。如果我能理解它的逻辑，并且逻辑是合理的，那就接受。如果我理解不了，或者逻辑明显有问题，那就手动调整。比如有一次，工具把一个关键模块放在了离它的通信伙伴很远的地方，我一开始觉得不合理。但仔细看时序报告，发现这个模块的通信路径不是关键路径，而它占的面积很大，放在边缘反而减少了整体线长。这就是工具看到了我没看到的东西。但也有反例。有一次工具为了优化线长，把一个模拟模块放在了数字模块中间，完全忽略了噪声隔离的要求。这就是约束没写清楚，工具不知道这个物理限制。后来我把噪声隔离写成硬约束，结果就正常了。6. 新人该往哪个方向积累，才不会被工具甩下车6.1 先把一个环节吃透，再横向扩展我见过一些新人，什么工具都想学，什么流程都想碰，结果每个都只懂皮毛。这种“广度优先”的策略，在 AI 时代反而危险，因为皮毛层面的操作最容易被自动化。更稳妥的做法是，先选一个环节，比如时序分析或者布局布线，把它吃透。吃透的标准不是会用工具，而是理解工具背后的原理，知道它在什么情况下会失效，知道怎么调整输入来获得更好的输出。这个过程可能需要一两年，但值得。吃透一个环节之后，再横向扩展。这时候你有了一个参照系，学其他环节会快很多，而且能理解各个环节之间的关联。这种“T 型”能力结构，在 AI 时代更有竞争力。6.2 学会写脚本，但别只满足于写脚本脚本能力是基础，能帮你自动化重复工作。但只会写脚本不够，因为脚本实现的是你已经知道的流程，而 AI 能做的是探索你不知道的流程。比写脚本更重要的是，理解脚本背后的算法和数据结构。比如你写了一个脚本做时序分析，你得知道时序分析的基本算法是什么，关键路径是怎么找的， slack 是怎么算的。这些理解，让你在 AI 工具给出结果时，能判断结果是否合理。另外，学会用 AI 工具本身也是一项技能。不是会用界面就行，而是理解它的输入输出、理解它的适用边界、理解怎么调参。这些技能，需要在实际项目里慢慢积累。6.3 培养“端到端”的视角，别只盯着自己的工位芯片设计是一个长链条，从规格定义到最终产品，中间经过很多环节。只盯着自己工位的人，很难理解自己的工作在整体中的位置，也很难判断什么结果是真正重要的。培养端到端视角的方法有很多：多参加跨部门会议、多和上下游同事聊天、多读项目文档、多了解最终产品的使用场景。这些看起来和具体技术无关，但长期来看，它们决定了你的判断力上限。我自己的体会是，当我开始理解整个芯片从定义到量产的全流程之后，我在做自己那一小块工作时，判断标准完全不一样了。以前我只关心我的模块时序是否满足，现在我会关心这个模块在整个系统里的功耗占比、面积占比、对良率的影响。这种视角，让我在做技术决策时更有依据。6.4 保持对物理世界的理解，别被纯数据思维带偏AI 是数据驱动的，但芯片设计最终要落到物理世界上。器件有物理特性、连线有寄生参数、封装有热阻、系统有噪声。这些物理层面的东西，数据里不一定有，但决定了设计的成败。所以，不管 AI 工具多强大，保持对物理世界的理解都很重要。知道一个晶体管在物理上是怎么工作的、知道一条金属线在物理上有什么限制、知道一个封装在物理上能承受多少功耗。这些理解，让你在 AI 给出违反物理规律的结果时，能第一时间发现。我见过一些新人，过度依赖仿真工具，工具说行就行，工具说不行就不行。但工具本身也是基于模型的，模型有适用范围。超出适用范围，工具的结果就不可信了。这时候，对物理世界的理解就是最后的防线。7. 工具越强，判断力越贵做了这么多年芯片设计，我最大的感受是：工具一直在变强，从手工画版图到自动布局布线，从手工写测试到自动生成激励，每一次工具升级都会淘汰一批只会操作的人，同时让会判断的人更值钱。AI 只是这个趋势的延续，不是颠覆。它把搜索和优化的效率提升了一个数量级，但搜索和优化的目标、约束、边界，还是得人来定。而且因为 AI 跑得更快，定义错方向的代价反而更大了。以前手工试错，试错了还能及时回头；现在 AI 一晚上跑几千个方案，方向错了，浪费的是算力和时间，还有可能错过项目窗口。所以我的建议是：别把精力花在担心 AI 会不会取代你上，把精力花在提升自己的判断力上。判断力来自对原理的理解、对流程的熟悉、对物理世界的认知、对系统级权衡的把握。这些东西，AI 短期内学不会，长期来看也不容易替代，因为它们需要真实世界的反馈和跨领域的整合。最后分享一个我自己的小习惯：每次用 AI 工具跑出一个结果，我都会问自己一句“如果是我手工做，我会怎么做，和这个结果差在哪里”。如果差得不多，说明工具已经学到了我的经验；如果差得很多，说明要么工具没学好，要么我该更新自己的认知了。这个习惯，让我在工具越来越强的同时，自己的判断力也在跟着涨。