iccnewer-CSDN博客

原创金字塔原理：教你做一个技术强会表达的芯片工程师（7000字）

"这个时序违例的原因，我看了一下，slack是-0.3ns，路径经过了三级寄存器，第一级是在时钟域crossing那里，然后这条路径的fanout比较大，synthesis的时候没有加buffer，另外hold time那边也有一些问题，然后综合策略可能也需要调一下，还有工艺角的选择……明明自己把模块调试好了，报告也写了，但汇报完之后，领导的反应是"所以你的结论是什么"——这句话说出来，很刺耳，但确实是很多人会遇到的真实场景。技术能力够，执行力够，但表达出来的东西，别人没接住。听完这段话，你记住了什么？

2026-05-28 18:13:36 355

原创跟AI说话这件事，芯片工程师可能一直做错了

你招来一个新同事，第一天就扔给他一个模糊的任务，然后期待他交出完美方案——现实里不会有人这么干。输入含糊，输出也含糊，然后得出结论"AI不行"。既然当它是人，就得用对待人的标准去审核它的输出。Agent生成的RTL代码，逻辑结构可能完全正确，但它不知道你的设计有多路时钟、某个寄存器有写保护需求。AI辅助流程的审核机制，和传统的人工审核流程差异很大，但这个环节不能省。流程上对Agent的输出保持必要的核查，这是工程师现在就该建立起来的习惯。但"视Agent为人"有另一层意思，很多人忽略了。

2026-05-28 07:08:00 284

原创对公司而言，大部分人都是“常数“，不是变量

写寄存器，写状态机，跑仿真，看波形，改bug，再跑。这个循环，三年五年下来，你会越来越熟练，也越来越——可替代。大多数工程师不缺执行能力，缺的是在标准流程之外还愿意多想一步的习惯。这三板斧，每个人都会。真正稀缺的，是在工具告诉你"timing met"的时候，能自己判断出"这个方案量产后会出问题"的人。这个领域正在变得越来越需要能独立判断的工程师，客观需求和大多数人的成长路径，恰好是反着走的。进大厂第一件事：学工具，学规范，学"这里一直是这么做的"。大公司要的是可预测的输出，可以稳定复现的流程。

2026-05-27 07:05:00 317

原创芯片流片失败，绝大部分不是技术问题，是管理问题！

代码审查走过场，测试覆盖率数字好看但没什么意义，性能问题留到后期再说——这套操作流程，在很多团队里几乎是默认设置。芯片开发的质量问题，从来都不缺解决方案，缺的是把这些方案认真执行下去的耐心和纪律。质量保证如果要真正起作用，必须嵌入在开发流程的每一个环节里：设计阶段有lint检查，编码阶段有代码规范，提交阶段有代码审查，集成阶段有回归测试。芯片开发里的性能优化，经常出现一种模式：工程师凭经验判断"这里应该有问题"，然后花大量时间在那个地方做优化，最后发现真正的瓶颈在别处。这种思路的问题在于，

2026-05-26 12:30:30 250

原创芯片架构设计能力，才是卡住大多数工程师的真正瓶颈

多读成熟开源IP的设计，比如AXI Interconnect、RISC-V核的流水线实现，不是看功能，而是看它怎么组织状态、怎么处理边界条件、怎么在灵活性和复杂度之间取得平衡。很多做了五六年数字芯片的工程师，RTL写得很溜，仿真跑得很熟练，但一旦被要求独立设计一个模块架构，就开始犯难了。——优先级固定死了，高优先级主机一旦持续请求，低优先级主机就会被完全饿死，到后期很难改。芯片项目的周期很长，一个SoC从立项到流片，少则一两年，多则三四年。在这么长的周期里，早期架构决策的质量，直接决定了后期迭代的代价。

2026-05-26 07:30:58 248

原创华为韬(τ)定律：后端(土木)老哥要辛苦了？

5月25日，何庭波在2026国际电路与系统研讨会上正式发布"韬(τ)定律"。这是中国第一次在全球半导体领域提出产业级别的指导原则。消息出来后，行业反应很分裂——有人觉得是真正的方向转变，有人觉得是被制裁逼出来的说辞。

2026-05-25 12:50:36 297

原创芯片工程师认真聊聊“一人公司“和副业（7000字）

他们能说出自己在做什么项目，能描述自己负责的模块，但说不清楚自己做的这些事情在整个产品链里的重量，以及如果换一个人来做，差距会在哪里。更关键的区别，往往在于工作方式。芯片工程师刚入职的时候，会有一个很自然的冲动：想在项目里把所有东西都做好，把流程搭得很完善，把代码写得很规范，把文档做得很详细。放到全职工作里来理解，这句话的意思是：你在做的每一件事，要能说清楚它对谁产生了什么价值，而不是单纯因为"这是我的职责"才去做。普通员工的思维是：老板/leader布置了什么任务，完成就好，质量不要太差，不要出错。

2026-05-25 07:34:54 324

原创 Token经济学正在重构芯片工程师的生存逻辑（万字长文深度拆解“token“这个计量单位的对于芯片工程师的意义）

用户看到的是一个确定的结果，但芯片实际处理的是一个复杂的推理树。这直接改变了架构设计的优先级。以前大家拼命堆MAC阵列、拼命提频率，现在得开始认真考虑片上存储的带宽利用率、数据复用的效率、动态功耗管理的精细度。同样的芯片、同样的功耗、同样的Token数量，价值差了一万倍。Token经济学正在以一种隐蔽但致命的方式，重新定义什么样的芯片架构有价值、什么样的优化方向值得投入、什么样的工程师能在未来十年里不被淘汰。芯片工程师优化出来的性能提升，没有转化成客户的成本下降,而是转化成了客户对更复杂任务的消耗能力。

2026-05-24 12:29:37 262

原创 AI给组内同事的脚本能力价值打了1折！

当一个芯片工程师能自己写RTL、自己搭验证框架、自己做脚本自动化、自己部署一个内部工具，对整个系统的理解会发生质变。不需要背API，不需要从零翻文档，AI负责补全、解释和调试，工程师负责方向和判断。以前一个做了七八年前端设计的工程师，遇到一个简单的VCD波形解析需求，第一反应可能是是找工具组的人或者脚本能力强的人帮忙。AI工具成熟，Vibe Coding的生态完整，芯片工程师拓展技术栈的门槛是历史最低点。一个RTL工程师想分析仿真跑出来的VCD文件，以前可能要花半天查文档，或者等工具组的人有空。

2026-05-24 07:36:22 267

原创 AI翻译准确率99.9%，专业翻译岗位反而增加了——这说明了什么

这时候的决策不只是技术问题——需要知道这条路径在哪个功能场景下被使用、修改设计对其他模块的影响、后端团队当前的排期能不能支撑一轮重新布线、客户那边的时间节点能否允许一次小迭代。这种感知能力，是在大量真实项目里磨出来的，不是靠读规格书积累的。：客户真正在意的是什么，需求背后隐藏的约束是什么，一个看起来合理的方案在实际落地时会卡在哪里。文学翻译里，一句话的语气、节奏、言外之意，是作者风格的一部分，翻译的是整个感受，不是字句。，是对方确实抓住了他的问题，给出了明确的结论，甚至在他很烦躁的时候，感知到了那种烦躁。

2026-05-23 07:35:59 336

原创领导看的是山顶，工程师盯着的是脚下的路

他们一只眼看领导定的方向，一只眼看团队的实际状态。他们知道那个山顶很难，但不能说太难，因为项目要立项。他们也知道团队有顾虑，但不能太顺着团队，因为方向是上面定的。高层开完战略会，兴冲冲说，我们要冲那个方向，前景好，机会大。技术负责人跟着点头，回去拆解路线图。普通工程师拿到任务，低头开始干活。他们关心的是市场位置、融资逻辑、对外讲的故事够不够有力。那座山够不够高、够不够显眼，比能不能爬上去更重要。表面上看，三层都在动。但每一层真正在意的东西，其实差得很远。站在那个高度，必须往远处看。

2026-05-22 18:37:54 334

原创中国芯片,缺的就是一个DeepSeek时刻

市场越做越窄,技术越搞越封闭,最后困住的是自己。它们的标准成了行业标准,它们的生态成了必选项,全世界想不依赖都不行。一个中国AI公司,开源模型一发布,全球开发者疯狂下载,各大科技媒体争相报道。让全世界的手机厂商、汽车厂商、AI公司都抢着用中国芯片,让中国的技术标准成为国际标准,这才是该追求的目标。当全球开发者都在用DeepSeek的模型,当它的技术路线成为行业参考标准,这才是真正的产业制高点。当中国芯片真正在全球市场上站稳脚跟,当全世界都离不开中国的技术和标准,那才是真正的产业安全。

2026-05-22 12:31:13 138

原创 AI犯了错没人追责，工程师犯了错丢饭碗？

公司如果不建立一套真正奖励负责任工程师的机制，最终会发现，AI能做的那些表层工作越来越多，但没有人真正在守那道最关键的质量防线。一个DFT覆盖率分析的疏漏，一个功耗域划分的错误，可能直接导致几百万的流片费用打水漂。但同样的错误，如果是工程师写的，那就是"不认真"、"能力问题"。假设一个工程师在做一个FIFO模块的设计，发现了一个潜在的跨时钟域问题，主动花了两天时间去分析、验证、修复。这是一个系统性的问题，不是某个人的问题。出了问题，AI不背锅，但流片的钱是真实的，时间窗口是真实的，市场机会也是真实的。

2026-05-21 18:16:37 230

原创忙碌”幻觉：你以为在推进项目，其实只是在逃避

时序收敛没过、功耗超了、验证卡住了——每一个问题都是真实的，每一项任务都是紧迫的。但有时候停下来想想，这些忙碌背后，到底有多少是真正在解决问题，有多少只是在用”我还在干活”这件事本身，来麻醉自己？做前端设计的时候，有一种很常见的状态：RTL代码改了一遍又一遍，综合跑了十几次，每次都在微调timing constraint，但核心的架构问题从来没动过。于是就一直在改constraint。

2026-05-21 11:41:44 331

原创验证工程师，你有没有被领导一句话问懵过？

正确的讨论方式是先把这四种情况摆出来，然后逐一确认：哪些是主路径，哪些是异常路径，哪些在当前设计里根本不会出现。但如果把完备性分解的结构直接拉成一张表，每一行是一个子场景，每一列是：覆盖方式、case名、当前状态、负责人——讨论的时候对着表来，哪个格子是空的，一眼就看出来。表格的结构会逼着你把每个格子都填一个态度：覆盖、不覆盖、或者暂不评估——三者必选其一，不能留空不表态。，按维度列出所有子场景，每个子场景标注覆盖状态，哪些✅哪些还在进行，那领导看一眼就知道思路有没有漏洞。这两种表达，给人的感觉完全不同。

2026-05-21 07:04:00 228

原创只有被坑过才能真正懂，那AI行么？

人类学走路，不是先读一本《步行指南》，而是摔了无数跤之后，身体自己记住了平衡感。芯片工程师的成长路径，其实也差不多。AI可以在几秒内读完所有公开的验证方法论，生成符合格式的UVM测试代码。但它缺少的是"出过错之后的那种感觉"。不是因为算力不够，而是因为这种能力本身就不是靠规则积累起来的。芯片行业有个现象：看过很多架构文档的人，和真正设计过一颗芯片的人，思维方式完全不同。前者倾向于用框架套问题，后者更容易发现框架本身的盲区。当然，理论基础不能忽视，没有基础知识连门都进不了。这句话放在芯片研发里，也不过时。

2026-05-20 11:45:00 359

原创 AI工具大概率会加剧芯片行业的“强者越强“效应，而不会拉平差距（6000字）

但一个刚入行、对setup/hold violation还没建立直觉的工程师，用同一个工具，很可能照单全收，结果跑出来的结果一塌糊涂，还不知道哪里出了问题。工具是工具，能力是能力，两者的关系很清楚。入行一两年的数字芯片工程师，大概率都有过这种感受：用了Copilot或者ChatGPT之后，感觉效率蹭蹭往上涨，以前要查半天文档的东西，现在几秒钟就能得到答案。如果你的目标是长期在这个行业站稳脚跟，光会用工具是不够的，基础能力才是放大效应的前提。AI放大的是你已有的能力，你的基础越扎实，放大效应越明显。

2026-05-20 06:35:32 321

原创普通工程师堆起来的人海战术，作用其实很有限

但现实是,前端架构如果有根本性缺陷,后面的人再多也是在错误的方向上狂奔。当然,也不是说普通工程师就不重要。执行层面的工作量确实需要人手。但如果指望靠堆人数来弥补核心能力的欠缺,那基本上是在做梦。架构设计能力、关键IP的积累、底层算法的创新——这些东西不是靠加班加点就能搞出来的。所以啊,与其盲目扩张团队规模,不如想清楚:自己手里到底有没有那几张关键的牌?就是你招10个普通工程师,也顶不上一个顶尖架构师的价值。这就像盖房子,地基没打好,你请再多工人来砌砖也没用。这些东西,钱能解决一部分问题,但解决不了全部。

2026-05-19 16:40:47 234

原创做芯片的人，为什么容易看不起管理岗？

技术工作的成果是可见的：代码在那里，仿真结果在那里，时序报告在那里。就是觉得做管理的人，每天开会、汇报、做PPT，不干实事。懂技术的时候还好，一旦脱离一线时间久了，讲话开始飘，方向开始虚，还喜欢对具体的技术问题指手画脚。开会、汇报、PPT，这些是信息传递的形式，不是管理的本质。只是这个准确性，不再体现在他自己能不能写出那段约束脚本，而是体现在他能不能听懂两个工程师的争论，判断出谁的方案风险更低。技术问题的答案通常是确定的，对就是对，错就是错。管理问题没有标准答案，只有在当时的约束条件下，相对更合理的判断。

2026-05-19 11:46:13 287

原创 AI时代，芯片工程师最该读的一本书，不是技术手册

这本书不厚，逻辑也不复杂。但它能帮人重新审理自己的思维习惯，这一点比读十本工具手册都值钱。芯片行业正在经历一个明显的范式转移。在这个阶段，思维方式的迭代速度，会决定一个工程师的天花板在哪里。推荐读一读，读完你会发现，很多以前觉得复杂的问题，其实没那么复杂。

2026-05-19 07:12:00 225

原创 AI调试陷入自证怪圈？你的验证工程正在悄悄失控

比如你的某个interface信号时序有问题，AI除了修时序，顺手给你加了一堆assertion，加了几个cover point，还在driver里加了条件判断。把波形、log、DUT结构、期望行为这些东西在脑子里过一遍，形成自己的判断，再去用AI验证思路——这个顺序对了，AI才是工具。训练数据里见过太多"加个判断防止出错"的写法，所以在不确定的时候，它的默认动作就是加东西、包一层、多一个检查。这个过程，表面上是在调试，实际上AI在做的是不断重新解释失败现象，用新的理由覆盖旧的理由。""建议再检查一下……

2026-05-18 18:09:55 285

原创芯片从需求到流片，写代码其实是最简单的那一步

这个过程不是线性的，是反复迭代的，而且很多问题的根因在架构层，修复方案要追溯到最开始的设计决策。把这些环节串联起来的，是具体的人，是工程师、PM、测试、客户之间持续的沟通和决策。要回答这个问题，需要有人把系统的使用场景想清楚，跑估算，做权衡。一个芯片项目的起点，通常是某个客户或者产品团队说了一句话，比如："我们需要支持 4K 60fps 的视频编码，延迟控制在 10ms 以内。从一句模糊的产品需求，到最后一颗芯片量产出货，中间每一个关键节点，都需要有人在场，有人理解上下文，有人做出决策，有人承担后果。

2026-05-18 12:26:52 255

原创大模型能帮你查芯片 Bug，但“修“这个动作，必须你来确认

等到最后发现原来是 testbench 的事，设计代码已经被改得面目全非，原本验证过的逻辑被破坏了，新的 bug 反而引进来了。按照工程师指定的排查逻辑，让大模型逐步分析，列出可能的问题点，并明确标注哪些结论有依据、哪些是推测、哪些需要补充信息。一个模块的时序改了，综合结果变了，后端约束可能就不再成立。但一旦涉及跨模块调试、时序收敛问题、或者任何"这个信号为什么不对"的问题，在没有完整上下文之前，不要让它开始"修"。这样，大模型的输出就从"自由联想"变成了"按图索骥"，排查结果的可信度会大幅提升。

2026-05-17 19:10:11 255

原创 AI时代的数字芯片工程师：该怕什么，该学什么，该怎么干（7620字）

但大多数的工程师，其实并没有认真想过：这波AI浪潮，到底在改变什么，会对自己的职业路径造成什么影响，以及现在该怎么做。EDA工具出现之后，不是"原来的工程师用工具画得更快了"，而是能做的设计规模发生了量级跳跃，整个行业的分工方式也随之重组。芯片圈里有一种很普遍的误解，认为AI对芯片研发的影响，就是"EDA工具加了几个智能功能"，或者"以后写RTL可以用AI补全代码"。把时间线拉长来看，AI对芯片研发的影响，跟当年EDA工具的出现，或者云端仿真平台的兴起，有相似的底层逻辑。AI这一轮，走的是类似的路径。

2026-05-17 10:34:43 310

原创芯片行业凭什么用通用大模型？我们需要一个真正懂硬件的 AI

所以行业大模型的路径，大概率不是一个统一的公共模型，更可能是每家公司基于开源基座模型，用自己的内部数据做私有化微调。拿一个很常见的场景来说——你让通用大模型帮你写一段 UVM testbench，它能给你生成一段看起来像样的代码，格式对了，关键字对了，但细节经常是错的。，它能理解跨阶段的依赖关系，能在架构讨论阶段就预判后端实现的风险，能把前辈工程师踩过的坑变成可检索的知识。现在是一个很好的时机，因为基础模型的能力已经到位了，剩下的只是行业有没有意识到这件事的紧迫性。通用大模型处理不了这种层次的复杂性。

2026-05-16 17:19:08 332

原创芯片工程师每天在重复什么？AI时代该换个活法了

如果把AI当成学习工具，看它生成的代码，理解其中的逻辑，反而能加速学习过程。以前50%的时间花在写代码上，30%做验证，20%做优化。现在可能变成20%写代码，40%做验证，40%做优化。时序要收敛，功耗要优化，验证覆盖率要达标，这些硬指标一个都跑不掉。AI时代最重要的能力，可能不是学会使用某个具体工具，而是学会识别哪些工作值得自己做，哪些应该交给工具。芯片开发有个奇怪的现象：明明技术含量很高，但工程师每天干的活里，至少一半是重复劳动。只要最终结果是对的，代码是人写的还是AI生成的，有那么重要吗？

2026-05-16 06:56:43 314

原创一线验证工程师的实战经验-不要把上电复位当成理所当然的事情（9000字）

但模拟电路的特性是渐变的、有延迟的、带毛刺的，数字电路却期望信号是干净的0和1。具体做法是加入时钟检测逻辑，检测时钟频率是否达到目标值，或者简单地加一个足够长的延迟，确保时钟有足够时间稳定。仿真器给的电源就是稳定的1.8V，时钟就是完美的方波，复位信号就是干净的边沿。数字逻辑在这种时钟下采样，寄存器可能采到错误的值，状态机可能跳到非法状态，计数器可能从一个随机值开始计数，甚至是亚稳态。不能简单地在仿真开始时就给一个完美的时钟，而是要模拟时钟从无到有、从不稳定到稳定的过程。如果时钟还在抖动，就报错。

2026-05-15 19:48:08 334

原创芯片研发也怕“一句话需求“：从模糊规格到烂尾项目有多远？

架构设计完了，前端说要改接口；前端做完了，后端说时序收不住；流片回来，系统团队说功能对不上。这条链路上的每一次翻工，代价都是真金白银。但很多项目失败，都是败在最开始那几页 spec 写得太随意。数字芯片的研发周期动辄两三年，投入少则几千万，多则过亿。每一个没答清楚的问题，后面都会变成一个返工节点。工程师不熟悉项目规范就开始写 RTL。规范缺失，代码写了也白写。需求模糊，后面全是债。

2026-05-15 12:12:07 346

原创芯片工程师开始互相分享提示词了

从更长的时间维度来看，这些分散在各个社群里的提示词积累，最终会形成行业级别的最佳实践。一个写得好的提示词，背后是工程师对这个任务的清晰拆解：目标是什么、约束是什么、哪些细节AI容易搞错、输出格式要求是什么。对个人工程师来说，现在最务实的做法，就是把用过的、验证有效的提示词记录下来，定期整理，按模块类型分类存好。别人写的提示词，是在他的项目背景、他的工艺节点、他的团队规范下打磨出来的。拿到别人的提示词，先对照自己项目的规范过一遍，把不符合的地方改掉，再存进自己的模板库。别人分享的是经验，自己积累的才是能力。

2026-05-15 07:03:38 308

原创大模型写的 Verilog，为什么总在最关键的地方出错？

心理学里有个词叫"System 1 thinking"，就是那种不假思索、条件反射式的判断。很多人用下来的感受是：简单的活儿它做得还行，但一碰到稍微复杂的逻辑，就开始出岔子。大模型本质上是一个概率机器。给它一个问题，它做的事情是：在训练数据里找到最相似的模式，然后生成概率最高的输出。一个初级工程师犯错，通常也是因为同样的原因——靠直觉写代码，而不是先把问题想清楚。这个过程和人类的直觉很像——快，流畅，但不经过深度推理。它给的是"最可能的答案"，而不是"正确的答案"这是大模型的工作方式决定的。

2026-05-14 18:10:12 325

原创研发本就是“工具“，所以注定会被更好的工具替代？

但判断层依赖的是对系统全局的理解、对历史决策的记忆、对风险的直觉感知，这些目前AI都做不了。这个说法出现在一个关于AI替代的讨论里，听起来很有逻辑：芯片研发的目的是满足需求，本质上是一种工具性工作，既然是工具，就有可能被更高效的工具替代。需求到落地的路很长，AI能走完其中的一段，甚至是相当长的一段，但有些部分它走不了——那些需要理解业务语境、权衡工程约束、跟人对齐需求的部分。芯片研发确实是工具性工作——但造桥也是工具性工作，你不能说造桥这件事会被一个更好的工具完全替代，因为每座桥都要理解它所跨越的那条河。

2026-05-14 11:50:48 229

原创国产AI陪聊，洋AI干活？

这时候需要AI能够理解整个系统的行为，追踪信号在不同时钟域之间的传播，识别出哪个环节的状态机转换出了问题。比如根据寄存器手册自动生成UVM RAL模型，或者把一堆assertion改个命名规范，这些任务就算生成的代码有小毛病，人工扫一眼也能发现。国产模型现在的水平相当于一个刚毕业的应届生，能干活但需要人盯着。那时候国产模型也能把复杂的timing violation分析清楚，给出真正有用的建议。最近大家形成了一个默契：遇到问题先问问国产大模型，它要是答不上来，再切到GPT-5和claude。

2026-05-14 07:21:01 347

原创三年前的代码，今天还能扛住多大的锅？

很多人觉得"以后再补"是合理的权衡，有时候确实是，但"以后"需要是真的有计划的，而不是无限期推迟的借口。反过来，如果代码库里充斥着没有解释的魔法数字、功能不清的模块名、缺失的接口文档，AI 生成的新代码很可能把这些问题往下传递，甚至放大。三年前为了赶排期写的那段 RTL 代码，注释只有一句话，测试用例也没补齐，当时想着"以后再补"，结果后来一直没动。AI 可以帮你快速生成代码，但它理解不了当初的设计意图，看不见注释背后的决策过程，也不会自动把技术债务标记出来。，然后看到了你的名字。来看一个具体的例子。

2026-05-13 21:12:58 308

原创 Vibe Coding正在制造大量垃圾RTL

正确的流程应该是：先想清楚架构，画出状态机，定义好接口时序，然后让AI帮忙生成框架代码。生成之后还要仔细review，检查边界条件，补充约束，优化关键路径。看到AI生成的代码能跑，不代表它就是对的。真正决定项目成败的，还是工程师对需求的理解、对架构的把控、对质量的坚持。有种很危险的倾向：因为AI生成代码快，就降低了对代码质量的要求。AI写代码的速度确实快，但最近看到的一些代码，只能说是灾难现场。Vibe Coding的氛围感很足，但代码质量的"粪围感"更浓。工具变快了，垃圾产出的速度也变快了。

2026-05-13 12:09:22 361

原创寄存器验证做到这个程度，基本就不会漏了(7000字)

表面上看，UVM有RAL（Register Abstraction Layer），跑一遍寄存器读写，reset值对上了，读写功能没问题，就觉得验证完了。实际操作上，建议在项目kickoff后，验证工程师和设计工程师一起做一次寄存器表格review，专门对齐这些问题。这件事不用很正式，一个小时的会议就够，但对后续验证质量的影响是决定性的。这篇文章从一个在项目里踩过坑、见过形形色色问题的视角，把寄存器验证怎么做才算完备，讲得尽量清楚、可操作。寄存器表格（spec）本身必须是准确的，才有验证的意义。

2026-05-13 07:25:04 217

原创别急着抛弃 Workflow：强大的 Agent 也有搞不定的场景

给Agent一个函数，它会自己打开文件看代码，理解逻辑，生成覆盖各分支的测试用例，跑测试，看报错，修正，再跑。来看一个具体场景：一个1000万门的SoC在做pre-silicon验证，timing收敛阶段发现某条关键路径在worst-case corner下违例了50ps。确实，当模型足够强、上下文足够长，Agent确实可以跳过很多预设的Workflow步骤，自主规划工具调用顺序、探索工程结构、完成并验证任务。最近有一种声音：模型能力强了，Workflow要被淘汰了，Agent会直接搞定一切。

2026-05-12 12:03:21 234

原创每个工具里塞一个小模型，这个思路值得认真对待

一个工程师用了三年的波形查看器，他有一套固定的"查问题套路"：先看哪几个信号，按什么顺序展开层级，哪些信号的颜色是红色代表异常。不需要多大的模型，一个轻量的本地模型，持续记录用户的操作序列，识别其中的模式，下次遇到相似情景时主动给出建议或者直接预填配置。：小模型和规则系统专注于个人化、场景化的效率提升，是大模型无法覆盖的重要补充，在资源受限的芯片研发环境下尤其务实。在资源有限的情况下，先把每个核心工具的"个人化适配"做好，比堆一个大而全的AI平台更实际，效果也往往更直接。这就是小模型能发挥作用的地方。

2026-05-12 07:39:48 245

空空如也

空空如也