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 工具跑出一个结果，我都会问自己一句“如果是我手工做，我会怎么做，和这个结果差在哪里”。如果差得不多，说明工具已经学到了我的经验；如果差得很多，说明要么工具没学好，要么我该更新自己的认知了。这个习惯，让我在工具越来越强的同时，自己的判断力也在跟着涨。
