过去一段时间,行业里已经出现了不少“AI做芯片”“智能体进EDA”的案例。但坦白讲,很多内容看上去热闹,真正能说明问题的并不多。要么停留在生成几段RTL,要么只是做了一个问答助手,要么是把几个脚本重新包了一层AI外壳。它们当然有价值,但距离“真正进入芯片研发流程”还差一截。
最近,我们自己做了一次更完整的尝试:通过智能体,把一个从 Spec 到 GDS 的芯片项目在两个小时内跑通了。这里的“跑通”,不是只生成一点设计代码,也不是只做流程讲解,而是让系统真正完成了从自然语言设计描述,到仿真、综合、布局布线、产物生成、结果展示的完整闭环。

先把边界讲清楚:这还不是一个已经流片、已经量产验证的项目,它现在依然是 Demo 阶段。但它已经足够说明一件很关键的事:芯片研发这件事,已经不再只是“AI可以聊一聊、写一写”的场景,而开始进入“AI能实际接手流程性工作”的阶段。
而我们真正想借这次实践说清楚的,也不是“AI会写脚本了”,而是:智能体,正在成为芯片研发流程里最值得重做的一层能力。
真正拖慢工程师的,很多时候不是设计难,而是流程太碎
━━━━━━━━━━━━
如果真正和芯片设计工程师聊,你会发现他们最痛苦的地方,往往并不只是设计本身复杂,而是有太多时间被耗在那些重复、机械、但又不得不做的工作上。
每次跑一个EDA flow,从RTL到GDS,背后几乎都要重复同一套动作:写配置、调参数、盯日志、找产物、做截图、做汇报。流程本身并不“高级”,但一旦流程长、工具多、环节复杂,这些工作就会不断侵蚀工程师的有效时间。更麻烦的是,一旦某个环节失败,很多动作还要再来一遍。

这也是今天芯片研发流程里一个长期存在、却常常被低估的问题:最贵的人力,往往花了大量时间在非创造性工作上。
工程师真正应该集中精力的,是架构思考、设计优化、约束取舍、风险判断,而不是在终端、日志、配置文件和结果目录之间反复横跳。所以从行业角度看,智能体切入芯片研发,价值并不只是“替人跑个任务”,而是把高频、低创造性、强上下文依赖的流程劳动接过去,让工程师重新把时间拿回来。
这次做出来的,不是聊天机器人,而是一个会把流程干完的智能体
━━━━━━━━━━━━
我们这次验证的核心能力,其实可以概括为一句话:把自然语言的设计描述,真正变成完整的EDA流程结果。
用户给出的输入,不需要是复杂配置,也不需要先按某个固定格式手工整理成工程文件,只需要是一段设计意图清晰的 Spec。比如:设计一个 2-request fixed-priority arbiter,使用单时钟和低有效复位,req0 优先级高于 req1,输出寄存。对于工程师来说,这是一种非常自然的表达方式,但传统流程离真正可运行的工程还隔着很多手工步骤。
而在这次智能体流程里,它会继续把这段描述往下推进:先理解设计意图,再提取结构化信息,随后生成配置、组织验证、调用工具、收集结果,并最终输出包括 GDS、DEF、ODB、PPA报告、日志和预览图在内的一整套产物。

这里真正重要的,不是“工具被调起来了”,而是“理解需求—调用工具—读取结果—继续迭代”这条链条被串起来了。这意味着智能体不再只是站在工程流程外面帮你解释问题,而是开始走进流程本身,成为执行链路的一部分。
这也是我们觉得这次实践有意义的地方:不是做了一个会说话的EDA助手,而是做了一个能把事情往下推进的流程型智能体。
真正拉开差距的,不是第一次跑通,而是失败之后还能继续干
━━━━━━━━━━━━
任何做过EDA的人都知道,一次就跑通不是常态,跑挂才是常态。所以一个系统是否有价值,关键不在于它能不能顺利演示一次,而在于流程失败之后,它还能不能继续把事情做下去。
这次我们把自动诊断和自动迭代也做进去了。比如 utilization 超过阈值,系统会判断是否需要增大DIE_AREA;如果 testbench 失败,会提示检查时序和断言;如果是环境或 Docker TTY 类问题,会自动切换执行方式。然后再根据诊断结果重新调整参数,继续发起下一轮执行。
这件事听上去像“自动调参”,但背后真正验证的是另一层能力:智能体已经开始具备持续感知工程上下文的能力。它不只是执行一次命令,而是在一个不断变化的项目状态里工作——知道上一次为什么失败,知道这一次改了什么,知道当前结果相比基线是进步还是退步,也知道不同优化动作之间可能会互相牵制。
而这恰恰是很多通用大模型最容易失真的地方。它们当然可以解释一个问题、总结一段日志,但一旦进入多轮次、强状态、强工具链依赖的工程流程,就很容易从“会说”退化成“说得像懂,但接不住后续执行”。
为什么芯片研发,会是智能体最有机会跑出来的高价值场景?
━━━━━━━━━━━━
不是所有行业都适合智能体先落地,也不是所有流程都值得被智能体改造。但芯片研发很特殊,它天然具备几个非常适合智能体深入的条件。
第一,它是一个典型的多工具链协同的复杂流程。从设计描述到仿真、综合、布局布线、DRC/LVS、PPA分析,每一步都依赖专业工具,每一步又都和上下游结果紧密耦合。这意味着芯片研发不是一个单点问答问题,而是一条天然适合智能体编排和协同的长链路任务。
第二,它有大量高频、重复、标准化但又不能完全脚本化的动作。配置会反复写,参数会反复调,报错会反复查,结果会反复收。这些工作单看并不构成技术壁垒,但它们数量多、频率高、上下文密集,传统自动化很难彻底覆盖,恰恰是智能体最有价值的切入点。
第三,芯片研发的效率提升会被明显放大。因为这是一个高成本、长周期、强协同的行业,哪怕只是帮工程师少花几个小时在重复劳动上,最终释放出来的也是更高价值的人才资源和更快的项目推进节奏。

所以从这个角度看,智能体进入芯片研发,并不是一个为了追热点而寻找落脚点的故事,反而更像是这个行业迟早会发生的一次能力重组。
但为什么“通用大模型 + 几个工具”这条路,很难真正走深?
━━━━━━━━━━━━
看到这里,很多人会自然问一句:既然现在通用模型已经这么强了,为什么还需要专门谈半导体行业模型、芯片研发智能体,甚至私有化部署和运维能力?
因为到了工程落地层面,问题已经不是“模型知道不知道几个术语”,而是它能不能在一个高度专业、强约束、重流程、重安全的环境里稳定工作。而这背后,至少有三道门槛。
第一道门槛,是领域知识必须足够深,而且要是结构化的深。芯片研发不是普通文本任务。timing violation、utilization、setup/hold、工艺约束、综合策略、版图收敛,这些概念之间不是并列关系,而是一个高度耦合的知识网络。模型如果只是“知道这些词”,很容易回答得头头是道,但给不出真正可执行的动作。
第二道门槛,是工程项目需要的不是聊天式上下文,而是项目状态管理能力。一次 run 用了什么配置,改过哪些参数,失败原因是什么,下一轮相比上一轮是优化了还是退步了,这些都不是普通对话记忆能解决的问题,而是一个持续追踪项目状态的系统能力。
第三道门槛,是芯片研发本质上是一个工具链原生任务。模型不仅要会回答,还要知道什么时候调用哪个工具,如何组织输入,如何理解复杂日志,如何根据结果安排下一步动作,最后再把零散产物重新整理成工程师能消费的结果。如果没有这层原生集成,很多“Agent + 工具”的方案最终都会停留在外挂层,难以进入真正的生产流程。
也就是说,芯片研发场景里真正需要的,从来不是一个“更会说话”的模型,而是一套模型、智能体、工具链、状态系统和安全部署能力一起成立的综合方案。
真正能落到企业里的,不只是一个Agent,而是一整套可交付能力
━━━━━━━━━━━━
这也是为什么,我们在做这次实践时,关注点并不只是“Demo能不能跑通”,而是它背后对应的能力栈能不能继续往企业环境里延伸。
企业真正关心的问题,其实很直接:你这个东西能不能进我现有研发环境?能不能管权限?能不能做数据隔离?能不能适配我的算力和网络条件?出了问题谁来运维?长期怎么升级?这些问题不解决,再漂亮的 Demo 也进不了真正的业务现场。
所以今天行业比拼的,已经不只是模型推理能力,而是模型底座 + 智能体落地 + 私有化部署 + 持续运维的综合交付能力。尤其在半导体行业,研发数据天然敏感,流程环境复杂,企业对内网部署、权限控制和可审计性要求都非常高,安全落地能力不是加分项,而是入场券。
从这个角度看,这次“从 Spec 到 GDS”的打通,更像是验证了一个方向:真正有价值的,不是做出一个会演示的智能体,而是做出一套企业敢接、敢用、能长期跑的智能体系统。
这也是为什么,行业最终会越来越看重那些既懂半导体语境、又懂模型能力、还能把智能体安全部署到客户现场并持续运维的团队。
像这次项目里体现出来的很多能力,本质上也正是我们一直在持续打磨的方向:一方面,用更懂半导体研发语境的行业模型去承接复杂任务;另一方面,把智能体方案真正做成可部署、可集成、可维护的企业级能力。也正因为如此,我们会持续投入像智语芯这样的半导体行业大模型底座,以及围绕它展开的智能体落地、私有化部署与运维能力建设——不是为了把AI包装得更热闹,而是为了让企业在真实研发场景里真正用得起来、跑得下去。
写在最后
━━━━━━━━━━━━
这次项目没有流片,所以我们不会把它讲成一个已经跑到终局的故事。但它已经足够说明:智能体开始进入芯片研发的核心流程,这件事是真的发生了。
它也许现在还只是一个 Demo,但它已经不是那种停留在外围辅助层的 Demo,而是一个真正把需求理解、工具调用、流程执行、失败诊断、结果整理串起来的工程样本。它所验证的,不只是“AI能不能写脚本”,而是芯片研发这件事,正在出现一套新的效率基础设施。
从Spec到 GDS,两小时跑通的,不只是一个项目。更像是一个信号:芯片研发,正在进入智能体时代。
)