Meta 最新研究:AI-native 芯片设计,真正稀缺的能力是什么?我有三点不同看法

芯片人看AI · 论文精读约9000字 / 阅读约22分钟

一篇 Meta、纽约大学和斯坦福合写的论文，讲 AI 原生时代芯片工程师还需要哪些基本功。前半部分我把论文核心内容原样搬给你（含 14 张原文截图），后半部分是我的看法——有三处我和论文的观点不完全一致，都标了出来。

写在前面

这是一篇论文解读，也是一篇读后感。

论文来自 Meta、纽约大学和斯坦福，2026 年 9 月挂在 arXiv 上，题目直译过来是《学术界 × 产业界：AI 原生时代芯片设计基本功的作用》。Meta 的团队在第一线用 AI 做芯片，他们讲「模型越来越会写 RTL 之后，真正稀缺的能力是什么」，比纯学术视角更值得听。

前半部分是论文的完整解读，我原样搬过来，内容不做修改——它讲的问题值得每个芯片工程师认真读一遍。后半部分是我的观点。有三处我和论文的看法不完全一致，我用专门的标注框标了出来，你看到橙色框就是分歧点。

报告重点：论文的五个核心判断

论文的核心判断是：AI 越深入芯片设计，工程师越需要掌握设计原理、表达设计意图、检验结果并解释取舍。这些基本功决定了任务怎样交给 AI，以及 AI 产生的结果能否进入工程流程。

一、实现加速会把瓶颈推向规格、验证和协作。

生成 RTL 的速度提高以后，需求是否完整、修改是否满足系统约束、上下游是否接受结果，将更直接地影响交付周期。

二、隐性经验需要转化为带条件的知识。

一条约束、一项豁免或一个优化方法，只有同时保留理由、适用范围和检查方法，才有条件被其他工程师和 Agent 复用。

三、检查工具决定反馈是否有工程意义。

仿真、形式验证、STA 和物理检查各自回答不同问题；正确选择检查对象、假设和输入，比得到一个 PASS 标志更重要。

四、快速探索需要与交付基线建立联系。

商业 EDA、开源工具和代理模型可以承担不同阶段的工作。工具之间的 correlation 决定快速评估能用于哪些判断。

五、人才培养和科研交付都要面向实际使用。

学生需要解释和纠正 AI 结果；研究成果需要同时提供方法、实现、运行条件和评价方式，让后续使用者能够接着工作。

全文可以沿着这条关系理解：把经验表达出来，把候选结果检查清楚，再把经过检验的方法交给下一位使用者。

一、实现速度提高以后，工程瓶颈会移到哪里

一次时序优化可以很好地说明这个问题。Agent 发现关键路径过长，在数据通路中增加一级寄存器，重新运行工具后，setup slack 改善了。接下来的问题却属于系统设计：接口是否允许增加一个周期，valid 与 data 是否仍然对齐，背压是否改变，复位后的首笔事务能否正确完成。只有这些条件也满足，局部改动才有机会被接受。

芯片工程里有大量这样的决定。执行一次修改与判断修改是否合理，依赖不同层次的能力。随着候选实现更容易获得，后者会占据更大的工作比重。这正是论文讨论基本功的出发点：把人的职责放到整个设计和交付过程里理解。

1.1 图 5 展示的是代码任务能力的变化

论文用 CVDP 的代码生成和代码理解成绩说明模型能力正在变化。两张子图观察的是不同任务，纵轴都是已解决问题的比例，横轴是结果发布日期。原图采用的是截至 2026 年 8 月的成绩快照。

从左图可以看到，代码生成结果大致落在 17% 至 40% 的区间；右图的代码理解结果大致落在 57% 至 82%。这两个范围只是对原图点位的粗读。生成一个满足题目要求的实现，与理解一段既有代码，所需能力和失败方式并不相同。

作者据此预期，RTL 代码生成会逐步成为更普遍、获取成本更低的能力，工程师的工作也将更多转向任务组织和结果判断。图中比较了不同模型的提交结果，原图脚注还说明，部分提交并未由 Si2 直接运行或验证。因此，评价具体模型时，需要连同任务集、上下文、工具和预算一起看；图中的成功比例不能直接替换成真实项目的交付成功率。

同样的变化也会影响 HLS 和硬件 DSL 的价值定位。作者提出，当规格到 RTL 的生成能力提升后，应重新评估这些语言所提供的生产率收益。工程上还要同时考虑类型约束、领域表达、编译优化和验证方法：即使手写 RTL 的工作量下降，这些机制仍可能减少规格歧义或限制不合法结构。

1.2 局部十倍加速，为什么只得到约一点六六倍整体加速

原文表 1 引用了一项软件开发者工时研究，表中样本为 5,928 人。编码、修复、测试、代码审查和文档五类工作合计占 44%。作者用这组比例说明：当其中一部分工作加速后，剩余部分会成为更突出的瓶颈。

假设工作总量不变，只有这 44% 获得十倍加速，剩余时间就是 56% + 44% / 10 = 60.4%，整体加速为 1 / 0.604，约 1.66 倍。按同一个假设计算，可以得到下表。

这里使用的是软件工时比例和简化计算，作用是解释瓶颈转移。芯片项目的工期还取决于任务依赖、EDA 运行、许可证排队、IP 交付、集成复核和返工，不能从这张表直接取得一个项目加速倍数。

对芯片团队更有用的判断是：AI 加速的步骤，是否位于当前交付的关键路径上。如果代码已经完成，项目仍在等待规格确认，那么继续提高生成速度的收益有限；如果每次修改都需要长时间工具重跑，那么减少无效候选和重复运行可能更有价值。

二、从隐性经验到 Agent 能够使用的知识

实现可以交给别人，判断依据却经常留在原设计者脑中。论文列举的典型知识包括时序例外的理由、特定工艺中的处理经验，以及某项设计取舍在什么条件下可以接受。这些内容既影响新人接手，也决定 Agent 能否获得足够的上下文。

2.1 图 1 的变化发生在知识传递路径上

图左侧画的是专家向新人传授经验、新人再向下一位新人传授的过程。每一次传递都依赖具体的工作接触：是否一起定位过问题，是否见过特殊模式，是否讨论过当时放弃其他方案的原因。设计文件保存了最终结果，却未必保存得出结果的过程。

图中间把知识放入共同载体，让工程师和 AI 工具都能使用。右侧的曲线表达作者的组织判断：显式保存并持续维护知识，有利于减少人员变化带来的经验流失。它是一幅概念示意图，讨论的是积累机制。

以 false path 为例，保存一行约束能够重现当时的工具设置，却不足以支持后续判断。接手者还需要知道路径在哪种模式下不可能被有效激励，是否依赖控制互斥，相关假设由哪个检查支撑，以及设计改变后何时需要重新审查。能够迁移的是附带理由和条件的经验。

按照这个逻辑整理知识，记录对象会从“最终文件”扩展到“设计决定”。下表是对这一观点的工程展开。

这类知识既可以供人阅读，也可以成为 Agent 的输入。其价值不依赖某一种知识库产品；关键是记录能否支撑下一次工程决定。

2.2 图 4 解释了芯片数据为什么难以形成训练与评价循环

原图把软件与硬件样例放在开源生态、学术机构和产业公司三个环境中。硬件数据并非不存在；高价值设计及其运行环境，往往受保密约定、工艺绑定和工具格式限制。设计离开原有环境以后，可能只剩一份 RTL，而缺少解释和评价它的条件。

论文把这种稀缺进一步分成了几个相互关联的问题。首先是设计和规格难以获取；其次是中间过程难以获取，包括错误日志、时序分析、候选修改和评审理由；再往后，给结果打分的环境也可能依赖内部库、专有工具和项目方法学。即使拿到样例，也未必能够运行同样的评价。

这使芯片 AI 面临一个双重困难：模型需要学习工程过程，而组织又必须能够判断模型的行动是否有效。扩大公开 RTL 数据可以改善部分代码任务，但工业 Agent 还需要获得规格、过程和评价之间的对应关系。

对于一项时序优化，只有最终网表，很难知道最初的违例是什么；只有修改脚本，很难知道它破坏了哪些其他指标；只有一份通过报告，又很难知道约束和库是否与目标交付一致。把这些材料关联起来，才有可能复用其中的工程经验。

2.3 图 6 进一步回答：知识留下以后怎样使用

图中左侧是 RTL、验证、物理设计和研究领域的专业知识，中间是 Rules、Skills、Tools、Agents，右侧是不同专业和经验层次的使用者。图 1 关注保存与传递，这张图关注知识怎样进入实际任务。

这几类载体各有作用。规则表达必须满足的条件；技能组织一类任务的步骤和适用范围；工具完成计算、转换或检查；Agent 根据任务状态选择下一步行动。它们组合起来，才可能使一个原本不熟悉该领域的人完成部分工作。

作者把这种能力增强称为 superintelligence。在本节语境中，它指个人通过外部专业知识和工具扩展能力。例如，不熟悉某种向量架构的人，可以借助相关知识提出优化，再利用工具评价结果。其工程价值首先体现在减少进入陌生领域的成本、提高问题表达质量，以及扩大能够尝试的方案范围。

对照已有 EDA 和 IP 的发展路径，这个观点并不突兀。综合、布局布线和协议 IP 已经把大量专业知识封装在工具与模块中。原文 §2.7 主张在这些已有积累上继续建立 AI 能力。因而，把一项经验封装成可调用方法时，已有工具、接口和检查结果都应成为它的一部分。

三、候选结果怎样获得工程可信度

知识能够被调用，只解决了任务如何开始。Agent 运行以后还会产生代码、脚本、约束和解释，工程师需要判断这些产物满足了什么条件。论文在 §3.4 把芯片工程已有的精确检查手段视为一项优势：这些反馈可以用于筛选候选、定位失败，并指导下一次修改。

3.1 图 2 强调的是复核所需的知识

图上半部分把问题交给模型后直接接受结果，下半部分加入了人对基本知识的掌握，使人能够检验结果。两条路径都使用 AI，差异在于使用者是否仍然具备理解和判错的能力。

论文将这种把部分任务交给外部工具的行为称为认知卸载。适当卸载可以让人处理更大的问题；如果连判断依据也一并放弃，使用者就可能无法识别错误方案。工程师不需要重做工具内部的全部计算，但需要知道工具回答了哪个问题、采用了哪些条件，以及结果与产品要求是什么关系。

这一点在验证中尤其具体。同一份含糊需求可以使 DUT 和 testbench 共享同一个错误解释。两者在仿真中相互吻合，说明的是它们之间的一致性；能否满足产品要求，还取决于需求解释和检查器是否正确。验证的独立性来自规格、模型、性质和复核依据，不能只按生成了多少文件或调用了多少个 Agent 来判断。

3.2 确定的工具结果，仍然依赖正确的检查条件

把工具接入 Agent 后，工程师的一项核心工作，是把“怎样判断结果可以接受”写清楚。

检查器覆盖的性质、使用的模型和输入条件，决定了反馈的含义。

原文把等价检查、形式验证、STA、DRC 等列为可供 Agent 使用的反馈。在具体工程中，它们的检查对象不同，需要分别解释。

例如，形式工具中的 assume 限定被探索的情况，assert 表达需要检查的性质。如果把真实可能发生的行为排除在假设之外，证明结果就只对更小的环境成立；关键性质没有写入时，工具也不会自动补充产品要求。

STA 的结果同样依赖输入条件。若 Agent 通过放宽约束或错误增加例外来消除违例，报告可能改善，电路实际能力却没有相应变化。

因此，一个时序优化任务需要同时固定比较条件和允许的修改范围。对网表或 RTL 的修改，可以进入相应的功能及实现检查；对设计约束的修改，则需要先判断它是否仍表达原来的需求。把这两类动作混成同一个“降低违例数”目标，会使优化方向偏离产品要求。

这也是论文观点值得继续展开的地方：已有 EDA 检查能够提供反馈，而反馈是否适合用作优化目标，仍然是一项设计工作。正确性条件、性能目标和资源预算应分别表达，避免一个总分掩盖了不可接受的功能变化。

3.3 图 7 说明了为什么错误发现时机如此重要

图中列出的设计成本估计依次约为 7nm 的 2.49 亿美元、5nm 的 4.49 亿美元、3nm 的 5.81 亿美元和 2nm 的 7.25 亿美元。这些数字来自论文引用的外部估计，描述的是复杂芯片的设计成本背景。

高投入使检查前置具有直接的经济意义。一份错误候选刚生成时，处理成本可能很小；当它进入集成、长时间工具运行和后期交付后，再回退就会牵动更多工作。因此，自动化任务的收益需要同时考虑候选生成速度、检查成本和后续返工。

论文还指出，AI 可能产生不符合工程师熟悉模式的结构。过去依赖经验辨认常见拓扑的做法，在这种情况下会遇到困难。解释设计时，需要回到功能性质、结构影响和测量结果：它怎样满足要求，改变了什么代价，后续人员怎样维护。

四、AI、固定程序与工程直觉怎样配合

把每一步都交给模型，会持续引入推理开销和运行波动。论文 §4.2 提出的区分很实用：AI 可以参与开发工具，也可以成为工具每次运行时的一部分。选择哪种形式，应从任务本身出发。

4.1 图 8 区分开发阶段与运行阶段的 AI

左侧先借助 AI 编写程序，再由程序执行设计任务；右侧把模型放进运行过程，让它根据输入和反馈持续选择行动。两种方式可以组合，但需要承担不同的成本和调试责任。

以时序报告为例，格式稳定后，提取起终点、计算数值变化、按路径分组，都可以用固定程序完成。面对多个指标同时异常、需要提出原因假设时，模型才可能提供额外的分析价值。这样分配任务，也使数值计算与解释可以分别检查。

4.2 原文表 2 的重点是迁移已有工程判断

芯片工程师已经习惯对运行时间、PPA 和资源使用形成直觉：哪些分析很快，哪些流程需要排队；增加寄存器可能改善哪些路径，又会增加哪些代价；共享逻辑能够节省资源，却可能改变吞吐或控制复杂度。作者主张把这些判断延伸到 AI 工作流，在原有芯片工程经验上建立新能力。

例如，让 Agent 降低功耗时，需要说明允许采用哪些技术、使用哪组活动数据、时序和面积有什么限制，以及功能怎样保持。让 Agent 优化性能时，需要同时说明频率、延迟和吞吐的关系。任务中的这些条件，来自对电路和系统的理解。

资源判断也扩大了范围。模型 token、计算节点、EDA 许可证、工具运行和人工复核都可能消耗预算。一个较低成本的模型若频繁触发无效的完整重跑，总任务成本仍可能较高；一个高预算模型若只在少数困难步骤使用，也可能减少返工。需要比较的是完成有效任务的总成本。

对长时间运行的 EDA 作业，这还包括等待和调度。增加 Agent 的并发数可以增加候选和提交，但不能增加已有许可证池的容量。当工具已经满负荷运行时，更多提交可能只增加排队。

4.3 图 9 把持续实验与识别技术突破连接起来

图中的阶跃表示一种可能情形：许多工具和组件分别成熟后，通过组合使过去难以完成的任务变得可行。一个流程可能长期卡在获取中间状态、理解报错或恢复会话上；这些连接补齐以后，端到端能力才会表现出来。

作者因此强调持续实验，同时强调需要理解原来的难题在哪里。判断一种方法是否取得进展，应观察它在什么任务、预算和完成条件下跨过了原有瓶颈。一次成功演示、通过一个局部检查、完成完整流程和交付可集成结果，分别对应不同的能力范围。

这将基本功与技术选择联系起来。理解时序收敛、混合信号协同或工艺变化中的困难，才能判断一个新系统解决了哪一部分问题；理解已有算法和工具，才能发现哪些工作可以直接复用。

五、商业 EDA、开源工具与代理模型怎样分工

芯片 Agent 的可扩展性受到工具运行时间和许可证数量的直接影响。论文 §5.1 预期，快速探索与最终检查会使用不同层次的工具。这个观点的工程价值，在于把候选数量、评价成本和最终交付联系起来。

读这张图时，要分别看两个维度。横轴比较商业许可约束和开源工具的使用条件；纵轴比较较高精度评价和较快近似评价。许可证决定可获得性和并发约束，模型精度决定结果能支持哪些判断，两者并不是同一个问题。

原文用 cycle accurate model 标示较高精度一端，主要表达精度与速度的取舍。实际的 STA、LVS 和其他 signoff 检查具有不同的计算对象，不能都按周期精确仿真理解。选择工具时应直接看所需模型、检查项目、工艺支持和交付要求。

对已有商业交付要求的项目，可以由认可的 EDA 流程建立交付基线，再把开源工具和代理模型接入适合的探索环节。

快速结果能承担什么决定，取决于它与基线在相应任务上的对应关系。

5.1 correlation 需要围绕实际决定建立

如果快速模型只用于把候选排序，最重要的是能否保留值得深算的方案；如果用于预测某个硬性阈值，阈值附近的错误分类会更重要；如果要比较 PPA 的小幅改进，还需要关注误差是否已经大于改进本身。一个整体误差指标很难同时回答这些问题。

例如，在一组微架构候选中，代理模型可能足以帮助筛选面积明显偏大的方案；到了几个接近的候选之间，它的误差就可能影响排序。此时将少量候选送入详细实现，比要求同一个近似模型同时承担探索和最终验收更合理。

5.2 交付结果沿认可的检查路径确认

工具层次之间需要传递配置和结果，避免同名指标被直接比较。前端估算面积与物理实现面积、不同 corner 的 slack、不同活动数据下的功耗，各自带有条件。只有条件对齐，快速评价与生产评价之间的差异才有解释价值。

工具组合的收益来自减少不必要的昂贵运行，同时保留交付所需的检查。对芯片 Agent 而言，能够更快提出候选只是前半段能力；能够把少量有价值的候选送到正确的工具和检查路径，才把探索效率连接到了工程交付。

六、工具接口与 Agent 分工决定知识能否组合

工具可以运行，并不意味着一个陌生调用者就能正确使用它。EDA 姆的默认行为、适用版本、运行状态和结果含义，长期依靠手册与工程师经验共同解释。论文 §5.2 把这种解释工作看作工具厂商在 AI 原生时代需要承担的一部分。

6.1 图 11：工具厂商应交付可直接使用的知识

左侧由工程师读手册、手工调用工具；中间由客户把手册整理成模型上下文和技能；右侧则由厂商整理并验证这些材料，再供不同客户使用。作者关注的是一项重复成本：每个客户都重新解释同一套工具语义，既耗时，也容易产生不一致。

将手册切分后接入检索，可以帮助找到相关内容；要形成可调用能力，还需要表达命令的输入要求、参数含义、副作用、异常行为和版本差异。知道一条命令存在，还需要进一步理解何时能够调用它，以及怎样使用返回结果。

以长时间运行的 EDA 作业为例，提交成功只说明调度系统接受了请求。工具是否正常启动、是否完成目标分析、是否得到满足条件的结果，是后续不同状态。接口如果把这些状态混成一个成功标志，Agent 就可能在结果尚未形成时继续向下游传递结论。

MCP 等机制提供调用入口；具体的工具语义仍由工具和工作流定义。这使厂商维护的技能、样例和检查方法具有实际价值：它们可以减少客户反复解释同一个工具的成本，也让升级后的变化有明确来源。

6.2 任务划分应对应可检查的产物

原文 §5.3 建议将复杂芯片任务分解，使每一步更容易描述、执行和验证。这样既能降低单次上下文负担，也能针对任务选择模型、程序和工具。

例如，一次修改可以依次形成需求说明、候选实现、运行配置、检查结果和修改解释。它们之间存在明确依赖：没有确定需求，就难以判断候选；输入版本改变后，旧检查也不能继续代表新产物。任务划分应使这些依赖能够被观察和检查。

6.3 图 12：不同组织交换的是带条件的结果

图左侧的学术机构、EDA 厂商、设计公司和开源组织各自提供能力，需要维护多个适配关系；右侧通过共同接口交换能力。若 n 个参与方都直接两两对接，无向连接数可达 n(n-1)/2，共同规范有机会减少重复适配。

实际难点还包括结果语义。两个系统都返回 PASS，可能一个完成了 lint，另一个完成了指定模式的 CDC 检查；两个系统都返回 coverage，也可能分别指代码、功能或性质覆盖。字段相同，结论覆盖的内容仍可能不同。

论文因此强调，把已完成检查的保证、证明以及失败信息传给下游。这个观点可以具体落实为几类交接内容：检查针对哪个设计版本，采用什么配置，覆盖哪些范围，存在什么豁免，结果及日志在哪里。下游据此判断哪些结果能够复用，哪些输入变化要求重新检查。

证据能够随产物一起传递，复用才不会退化为重新相信一段文字。

七、基本功训练需要对应新的工程责任

到这里，论文对人才培养的要求已经变得具体：能够表达任务，理解约束，选择执行手段，解释检查结果，并把决定交接给其他人。这些能力同时依赖底层知识和系统视角。

图中浅蓝色对应产业实践，浅黄色对应教学投入。左边表示既有培养与工作内容的关系；右边表示 AI 进入后，各层次工作可能发生不均匀变化。条形与箭头是示意，重点在于培养结构需要随责任变化调整。

自下而上的训练帮助工程师理解器件、电路、逻辑和实现约束怎样影响系统。自上而下的训练则要求从目标出发，分解规格、接口、资源和验收条件。论文主张重新平衡两者，使学生能够承担规格表达和验证组织，同时保留识别底层错误所需的知识。

7.1 能定义任务，也要能识别错误

“基础学到什么程度”应与承担的判断联系起来。评估一个复位方案，需要理解状态、时钟和释放条件；评估流水线调整，需要理解延迟、吞吐、协议和时序；判断一份功耗结果，需要理解其工作负载和活动条件。只有看见可能失效的方式，规格和检查才容易完整。

这也是作者坚持实践训练的原因。教材通常把条件整理得比较清楚，真实工作还包含工具环境、非理想输入、缺失上下文和跨团队依赖。亲手定位过一次失败，能够帮助学习者建立对异常的识别能力。

7.2 原文的考核建议落在“解释与验证”上

原文 §6.2 给出了一种评分安排的例子：允许 AI 参与的作业和实验占 10% 至 20%，受监考且不能使用设备的考试占 80% 至 90%。作者用它说明怎样调整学习激励，使基础掌握与 AI 实践同时得到评价。

更直接的例子是 INT8 MAC。学生可以借助 AI 生成 Verilog，但要解释位宽、符号扩展、累加范围、溢出处理和结构取舍。两个 8 位有符号数的乘积通常使用 16 位表示，累加器还要根据累加项数和溢出策略确定范围。代码能够编译，并没有回答这些设计问题。

7.3 原文表 3 连接了传统课程与 Agent 工程

这里尤其值得重视软件工程和随机过程。芯片 Agent 本身是软件系统，需要版本管理、模块化和回归；其内部又包含非确定性的模型行为，需要用重复实验、运行记录和受约束的执行方式来理解波动。

八、科研成果如何从可阅读走向可复用

论文最后把前述知识、工具和验证问题带入科研。研究者同样需要搭建流程、解释实验、保存经验，并使后来者能够复现和继续使用成果。

8.1 AI 可以压缩研究基础工程的搭建时间

芯片研究常常先要完成工具接入、模块集成、验证和物理实现，之后才具备检验研究假设的条件。作者将这些支撑工作称为 research scaffolding。AI 可以辅助生成脚本、整理运行配置和组织实验，使研究者更早进入需要检验的问题。

8.2 重新研究旧问题，要先判断原来的瓶颈是否改变

原文指出，部分方向曾受限于过高的工程投入、复杂搜索，或一个人难以覆盖的多学科知识。AI 可能改变这些条件，使它们值得重新评估。文章举出大型系统、体系结构基准、编译器，以及异步电路、替代存储、随机计算和受模拟启发的电路等例子。

判断的起点仍是原问题。例如，一个方向如果主要卡在实现工具链投入，自动化可能降低试验门槛；如果主要受器件特性、制造约束或不可忽略的通信代价限制，生成实现更快并不会自动改变这些条件。

8.3 图 13：研究成果同时服务于人和 Agent

上半部分先形成研究结果和论文，再由工程师阅读、重现并适配到产业流程。图中将人工重现标为劳动密集且容易损失知识的阶段。下半部分把研究成果整理为上下文、技能和工具，供后续工作流组合使用。

这张图把“能读懂”与“能接着做”之间的距离画了出来。人需要理解问题、方法和证据；Agent 要运行方法，还需要输入条件、可执行入口、运行步骤和反馈。两种需求可以通过同一套研究材料共同满足。

科研交付的扩展方向，是让论文中的方法带着运行条件和评价方式进入下一项工作。

论文负责说明研究贡献，可执行材料帮助贡献被复现、组合和继续改进。

8.4 强化学习的机会来自连续决策与延迟反馈

并非所有自动重试都构成 RL。固定模型在推理时反复读日志、提出修改，可以是一种搜索过程；策略是否依据奖励更新，决定了它与训练方法的关系。

九、论文的结论：基本功延伸到了工作流和交付物中

从全文回看，作者讨论的基本功包含两部分：一部分是电路、体系结构、验证和实现中的领域知识；另一部分是表达问题、检验假设、组织实验、解释结果和协作交付的能力。AI 将更多执行任务自动化以后，这两部分知识会更频繁地出现在任务的入口和结果的出口。

在入口，工程师需要说明设计意图、运行条件、允许修改的范围和评价目标。在执行过程中，工具和检查器把这些要求转化为反馈。在出口，工程师需要解释改动、确认相应检查，并使下游理解结果适用于哪些条件。

论文最有持续价值的联系，是把个人基本功与组织能力连接了起来。经验被记录为带条件的方法，判断被落实为检查，工具通过接口组合，研究成果带着运行材料交付。这样，一位工程师的理解才有机会在离开本人之后继续被使用。

对芯片团队而言，AI 原生能力可以落实为三件事：任务能够说明白，结果能够检查清楚，经过检验的方法能够继续复用。

模型提供了执行和探索的新手段，芯片工程积累决定这些手段怎样作用于实际设计。

论文部分到这里。原文：arXiv:2609.09344v1，Vincent T. Lee 等 8 位作者，来自 Meta、纽约大学和斯坦福大学。下面是我的部分。

十、我的观点：先说我们一致的地方

先说结论：我也是一直认可基本功的，这篇论文的核心判断我完全认同。尤其是「隐性经验要转成带条件的知识」「检查工具决定反馈的工程意义」这两条，和我这几年做 AI 辅助芯片设计的体感完全一致——我的公众号写过的大部分内容，本质上就是在做论文图 1 那件事：把脑子里的经验写成 Agent 能用的东西。

我的三点不同看法，分歧不在「基本功重不重要」——这点没有分歧——而在节奏和重心：论文把基本功放在一个相对恒定的位置上，我认为 AI 对 EDA 的渗透比论文暗示的更快，基本功的内容和用法会跟着变。另外我们站的位置不一样：论文作者是 Meta、NYU、斯坦福的视角，看到的是开源生态和学术研究能触达的部分；我在产业一线，看到的是商业 EDA、流片成本和组织现实。视角不同，对节奏的判断就不同。

另外有一块论文讲得轻、但我认为很重的东西——流片成本、组织问题、国内现状——我也补在后面。

分歧一：EDA 被攻破只是时间问题，论文的谨慎我保留意见

论文的通篇语气是「AI 需要人来驾驭，基本功决定成败」，图 4 讲芯片数据稀缺，图 10 讲商业 EDA 的许可证约束，整体是谨慎乐观。先把这两张图放回来，方便你对照我的说法。

说得更直白一点：论文说的「基本功」，我理解为人对工具的调用和经验判断。短期内，AI Native 芯片设计确实更多依赖人的经验、人的工作路谱（做过什么、踩过什么坑）、以及 AI 对既有工具的调用能力。但长期看，当工程实践数据循环建立起来，天平会向 AI 倾斜。论文把「人的基本功」放在了一个相对恒定的位置上，我认为它是移动的。

分歧二：论文的「superintelligence」是个人能力，我更关心组织能力

论文讲能力增强的原图是图 6，我放在这里。

这也是我为什么在公司内部一直在推的东西，不只是工具选型——是流程和分工的重构。

分歧三：对商业 EDA 的地位，我比论文更现实

论文讲工具分层的原图是图 10，放在这里对照。

论文没细讲、但我认为关键的两件事

十一、最后

这篇论文值得读，不是因为它给了答案，而是它把问题问对了：AI 原生时代，芯片工程师的基本功不是变不重要了，而是换了位置——从「执行」挪到「定义、检查、交接」。

再强调一次：我是认可基本功的，一直是。我和论文的分歧只在节奏——论文认为基本功是恒定的锚，我认为它是移动的地板，EDA 被攻破只是时间问题，基本功的内容会随着 AI 渗透不断更新。但在「怎么干」上我们没有分歧：把经验变成带条件的知识，把检查当作工程底线，把交付做成可复用的资产。

短期靠人的经验弥补 AI 的工程实践缺口，靠 EDA 工具做客观独立的第三方裁判；长期，把人从执行里解放出来，去做定义问题、组织证据、判断边界、承担责任的事。

论文在参考文献里说了一句（大意）：芯片工程的积累决定 AI 手段怎样作用于实际设计。这句我完全同意，也是我整个公众号的立足点。

*免责声明：本文由作者芯片人原创。文章内容系作者个人观点，路科验证转载仅为了分享与讨论，不代表路科验证对该观点的赞同或支持，如果有任何异议，欢迎联系路科验证。