如果你负责过一颗芯片流片前的物理验证一定对Calibre那几十MB的DRC报告不陌生。过去两年我一直在做一件事——把大模型、人工智能技术塞进芯片物理验证流程里最终落成了一个叫“基于大模型人工智能的芯片物理验证标准系统平台软件”的项目。这个项目名字听起来很绕但拆开看就是给芯片流片前的物理验证环节配了一个能读懂规则文件、会看异常报告、还能自动解释验证结果的AI辅助大脑。这篇文章我想把整个项目从业务痛点、系统架构、模型训练、落地部署到踩坑经验完完整整讲一遍。内容比较长但每一条都是真实项目里摸出来的。适合物理验证工程师、后端设计工程师、EDA方向的产品经理以及那些想把大模型真正用进严肃工业场景的朋友。说白了这是一篇“AI for EDA”的实战复盘不是概念科普也不是PPT汇报稿。1. 为什么要把大模型塞进芯片物理验证1.1 物理验证到底是干什么的芯片设计到了后端布线阶段之后在送出去流片之前必须过一道“体检关”这道关就叫物理验证。主要包括DRC设计规则检查、LVS版图与网表一致性检查、ERC电学规则检查、DFM可制造性设计分析。DRC看的是版图几何图形有没有违反工艺厂的尺寸、间距、密度要求LVS看的是画出来的版图跟设计原理图是不是同一张网表ERC看的是有没有电源地短接、悬浮节点这类电学问题。任何一个严重violation漏掉轻则芯片性能不达标重则直接流片失败一批wafer的钱就打水漂了。这个环节的特点很鲜明规则极其密集、工具输出极其庞杂。一个成熟工艺节点的rule deck可能有上万条规则语句很多规则还带条件上下文。工具跑完之后生成的报告动辄几万条记录。物理验证工程师做的工作本质上就是在一堆海量的违规记录里筛选出真正致命的问题同时把那些可以waive的误报、非关键性问题识别出来。这活儿非常依赖经验。1.2 传统工作流里的痛点我做这个项目之前走访过好几个设计团队最深的感受是大家的时间消耗和心智负担都很大。一个中等规模的SoC芯片跑完DRC之后report里可能会有三到五万条violation。工程师要一条条看图层、坐标、违反的规则编号判断是short、open、antenna还是density问题再决定是修还是waive。很多violation是同一类pattern反复出现但位置不同、场景不同审核逻辑又会有些差别。更麻烦的是规则解释的门槛很高。rule deck里那些TCL表达式、布尔条件、变量定义普通工程师看得懂一部分但碰到复杂规则还是要去找负责工艺库的专家问。老工程师脑子里装着大量“这种violation可以waive那种必须修”的判断标准但这些经验没有沉淀成统一的文档也没有结构化的系统。结果就是同一个地区的同一类violation在不同工程师手里可能给出完全不同的处理结论评审口径也很难保持一致。1.3 大模型能补上哪一块缺口大模型真正擅长的是把非结构化的文本、代码、日志、表格理解成有上下文语义的信息。物理验证过程中的rule deck、run log、violation report基本都是非结构化或半结构化数据。传统脚本只能做关键词匹配和正则抽取但理解不了“这个规则在什么条件下生效”“这条violation和那条报告里说的可能是同一个物理缺陷”。大模型可以读原始报告片段结合经纬度坐标、图层名、规则编号、邻近图形信息给出分类结果、风险等级、修改建议甚至能解释规则本身为什么这么定。放在整个验证流程里它起的作用不是替代签核工具而是把“人肉理解报告”这一步自动化、标准化、可追溯化。这也正是我当时立项时的核心判断签核工具不能也不该被AI取代但签核报告到人脑之间的这一大段“理解鸿沟”非常适合用大模型来填。2. 平台整体架构与设计思路2.1 贯穿始终的四个设计原则这个大模型物理验证平台在设计之初我给自己定了四个死原则。第一不替代签核工具。DRC、LVS、ERC的裁决权永远属于Calibre、Pegasus、Guardian这类成熟工具。AI只做后处理、前置分析和解释不做最终的“合法/非法”判断。这个原则保证了平台再怎么出错都不会让芯片带病流片。第二全部数据标准化。不管上游是什么工具、什么版本、什么格式进入平台之后都要被解析成统一的数据模型。违规记录有统一字段事件状态有统一定义AI输出有统一JSON结构。只有标准化之后规则引擎、统计报表、审计追踪才做得了。第三AI结论必须可追溯。模型给出的每条判断都得能追溯到原始报告片段、命中的规则编号、引用的知识库文档。不能是“模型凭感觉说这是个高风险”而要能让工程师点开引用就复查。第四知识要持续沉淀。平台跑得越久标注数据、复核记录、专家反馈都会变成新的知识资产。这样越往后系统越聪明换人也不会换掉判断口径。2.2 分层架构与模块拆解整个平台我按六层来拆接入层负责对接EDA工具流。常见的方式是在PR或physical verification流程结束后用TCL脚本把DRC报告、LVS报告、run log、rule deck的元信息一起导出推送到平台的数据接口。接入层要解决的问题是兼容不同的工具版本还要处理文件格式差异。解析层将所有原始文件统一成标准Schema。比如一条DRC violation统一解析为规则ID、图层、坐标、违规矩形区域、相关net、测量值、限制值、严重级别、原始文本片段。解析层是整个平台的地基这里做不扎实后面模型再好也没用。智能分析层是平台的大脑。它由大模型推理服务、领域微调模型、RAG知识库、实体识别模块组成。输入是解析后的标准化数据和原始文本片段输出是违规分类、风险评分、解释说明、修改建议、规则关联。审核流转层处理人机协作。模型生成的结论进入待审队列工程师可以接受、修改或拒绝。审核动作会形成反馈数据回流到标注集。这个层还负责状态管理比如新建、已提交、复核中、已解决、已waive。知识层集中管理规则手册、历史waive记录、专家评审意见、工艺文档。这些内容经过切块、向量化之后为RAG检索提供数据。知识层的核心是版本管理因为工艺规则会随节点迭代而更新。展示层提供Web界面和API。工程师在网页上可以浏览分类后的violation列表点开一条就能看到大模型的解释、关联的规则原文、知识库引用来源还可以一键跳转到版图工具的对应坐标。API则开放给内部流程系统做对接。2.3 为什么不是“端到端全自动签核”经常会有人问既然大模型都上了能不能让它直接判断哪些违规需要修甚至自动修版图我的回答是现阶段千万不要这么干。物理验证的标准系统和一般互联网推荐系统不一样准确性要求是绝对级的。一个严重violation漏掉后果不是推荐错了广告而是芯片直接fail或者可靠性出问题。大模型存在幻觉存在上下文遗漏它在理解复杂布尔规则时也可能做不到百分百准确。把最后的裁决权完全交给AI风险完全不可控。还有个原因是信任问题。验证工程师本来对AI输出就抱有怀疑态度如果系统给出结论却没有解释、没有来源、不允许人工干预那第一批使用者试用三次之后就不会再打开了。相反把AI定位成“一个极其勤奋的初筛助理”模型给出建议工程师做最终决定人机一起配合接受度会高很多。我们在项目里反复强调AI输出的是“参考意见”不是“裁决结果”。2.4 “标准”二字具体指什么标题里的“标准系统平台”在很多汇报里会被当成一个空洞的形容词。但对我来说标准是有明确落点的。第一是数据格式标准。无论今天接入的是Calibre还是Pegasus无论rule deck是TSMC还是SMIC还是自家内部的规则集进入平台后都转成同一套JSON Schema。下游的统计报表、机器学习模型、审计系统都只认这套标准格式。第二是处理流程标准。一条violation从模型产出到人工复核再到最终关闭每一步的状态、责任人、时间戳、修改记录都完整保留。这个流程不随个人的工作习惯改变不会出现“这个人喜欢随手标记error那个人喜欢全部打完再复核”的混乱状态。第三是知识沉淀标准。专家每做一次waive都要求选择原因分类比如“非关键区域”“与器件性能无关”“后续工艺步骤可修正”等。这些原因分类本身就是标准化的知识标签喂给模型时就变成高质量的监督数据。3. 关键技术实现从数据到模型的工程细节3.1 上游工具接入与原始数据解析物理验证工具的输出本质上是一堆ascii文件和日志。Calibre生成的flat report里每隔几行就是一条违规记录里面包含坐标点集、规则名、测量值、限制值。但问题在于不同版本的工具输出格式经常有不兼容的小改动同一个字段有时是十六进制坐标有时是十进制层名的命名规范也不统一。我当时的做法是先采集了半年内的真实报告文件做格式普查然后专门写了一个基于语法解析器genie的适配层而不是用正则硬匹配。正则表达式看着省事但报告格式一旦变化就会无声无息地解析失败非常危险。解析层里每一类文件对应一个parser类parser失败时要把原始文件名、行号、异常类型记录下来并自动告警而不是静默跳过。解析结果落到标准Schema后我会保留一份原始文本片段因为后续大模型推理需要结合原始文本理解上下文。这一步是最不性感、最累、但回报最高的工作。没有干净的结构化数据后面所有算法都跑不起来。我给团队定的要求是宁可解析慢一点也不要漏数据、错数据。3.2 基座模型选择与领域微调大模型技术栈这部分选型其实跟在通用场景里选模型差不太多但有工业场景的特殊要求。我首选开源底座模型一个是可控性一个是数据安全。物理验证的版图信息和规则文档很多都是公司内部资产不能随随便便传到外部API。所以平台从一开始就定了本地化部署路线所有推理全部走内部服务。模型规模上我测试过7B、13B、70B三档最终主力线上用的是13B量级。物理验证任务里上下文很长一条完整违规描述可能有好几千字符。7B模型在复杂归因上有点吃力经常答不到点上。70B效果好但显存开销大单卡没法玩至少需要四卡A100级别的配置成本和运维压力都上去了。13B配合量化、vLLM部署单卡A10勉强能跑A100就很顺畅性价比最合适。微调方案用了LoRA。专门构造了三类训练样本DRC违规解释、LVS不一致归因、报告语义分类。每类样本都要求模型输出固定格式的JSON。训练数据一部分来自历史人工标注一部分是让专家写种子示例再通过模型批量生成候选答案人工筛选。混入少量通用指令数据防灾难性遗忘。微调之后的效果明显比直接拿通用模型加Prompt要稳定尤其是输出格式的规范性提升特别大JSON解析失败率从百分之二十几降到了百分之三以内。3.3 RAG知识库和结构化实体抽取大模型有个硬伤它对你没见过的文档、新出的规则、公司内部的历史判决记录是不知道的。物理验证领域又恰恰是这种“长尾知识特别多”的场景。所以我同时做了RAG知识库把foundry规则手册、公司历史waive记录、专家评审意见、rule deck的相关变量说明全部切块向量化在模型推理前先检索最相关的文档片段作为参考上下文一起送入模型。RAG里面有个关键设计不是直接把可能相关的文档全塞进去因为上下文窗口有限塞太多反而干扰输出。我先做一个结构化实体抽取把违规记录里的层名、坐标、net名、规则ID、数值大小抽出来形成结构化标签。然后用这些标签去向量库里做精确查询把命中的规则原文片段找出来。这样模型看到的不是一堆模糊相关的文档而是与这条违规记录真正高相关的规则上下文。举个例子一条M1 metal spacing违规知识库检索首先命中的是设计规则手册里关于M1最小间距的定义、相关注释、常见异常说明以及内部历史waive记录里“这个区位于dummy fill区域waive概率高”的类似案例。模型在这些信息的辅助下给出的解释就可信得多。3.4 四个核心提示词模板与输出校验提示词设计上我不搞那种长篇大论的系统提示词而是针对不同任务各写一套极简模板再配上严格的输出校验器。DRC违规解释模板的输入是规则ID、图层、测量值、限制值、原始报告片段、知识库检索文本。输出要求是JSON包含risk_level、violation_type、explanation、suggestion、references。risk_level分high/mid/lowsuggestion必须给可执行的修改方向references必须列出引用的规则ID和知识库文档编号。LVS不一致归因模板输入是不一致net列表、器件类型、报告中的连接关系异常描述。输出要求是JSON包含likely_cause、affected_nets、impact_assessment、further_check_list。这个任务比DRC更难因为LVS不一致经常是层次化设计里的子模块抽象问题单看报告很难定位所以我会让模型输出“需要进一步检查的清单”而不是让它瞎猜。报告摘要模板用于把上万条violation压成三百字的简报输出包含总量、分类占比、高风险条目topN、建议优先处理项。变更影响评估模板在rule deck更新时使用输入是新旧规则的部分描述输出是对当前违规记录集的影响分析。每个模板后面都挂了一个校验器核心逻辑是先解析JSON解析失败就重试一次再失败就把答案丢弃并进入人工队列成功解析后还要检查risk_level是否在枚举值范围内references是否能在知识库索引里找到对应文档。通过了这套校验模型输出才会进入Web界面展示。这个流程帮我挡住了大量“模型自己脑补出来但实际上找不到来源”的问题。4. 从0到1的落地实操与效果评估4.1 最小可用版本应该先做哪一块很多团队做这类平台容易一上来就铺大摊子DRC、LVS、ERC全部覆盖模型、知识库、UI、API一次性全做完。我的经验恰恰相反第一版只做一件事DRC报告的分类和解释而且只针对一个工艺库覆盖高频出现的Top 20规则。这看起来很小但足够把整条链路打通。当时的场景是这样的一个28nm项目一次完整验证跑出来大约五千条DRC记录。在平台接入前一位资深工程师要把这五千条从头到尾人工过一遍耗时大概两天。平台第一版上线后模型自动把五千条分成了五类标出了其中一百二十条高风险项。工程师只需要优先看那一百二十条其他条目主要是重复性pattern可以用批量waive流程处理。最终人工复核量降到了三百条左右处理时间从两天缩到了半天。我为什么强调这个场景可以被当作示范工程因为它看得见、摸得着、效果立竿见影。团队看到真实时间节省后续才愿意继续投入资源做更多工艺节点和LVS板块。反过来如果一上来就喊“全面提升验证效率”但没有任何一个可对照的具体数字项目很快就会被质疑成“玩具”。4.2 可量化的验收指标与回归集平台不能靠“感觉准”来验收必须定义指标。我用了四个准确率指模型对violation分类和风险等级的判断与专家复核结论一致的比例。这个指标在标注集上跑要求达到百分之九十以上。误报率指模型标成高风险但实际专家确认不需要特殊处理的比例。这个指标要压到百分之三以下因为误报太多会消耗工程师的信任。人工复核减少比例指平台处理后需要工程师逐条打开细看并给出判断的记录比例。从最初的百分之百往下降目标是从五千条里筛出两百条以内需要人工复核的记录。规则溯源覆盖率指模型输出的解释和建议中能够正确定位到规则原文或知识库文档的占比。低于百分之九十的输出不允许进入审核队列。为了做回归我专门维护了一个金标准标注集里面有一千条经过专家复核的违规记录分布在多个工艺节点、多种工具版本上。每次模型更新、微调迭代、提示词改动都必须先跑一遍回归集。这一步非常关键否则你改完模型可能老问题变好了新问题冒出来甚至把以前正确的判断改错了。4.3 部署形态、资源估算与推理优化部署上我强烈建议把在线问答和批量分析分成两套服务。物理验证报告分析是明显的批处理场景一次消耗几万条violation等个几十秒完全没关系。但是工程师在Web界面里点开一条违规记录想要即时解释时就属于在线交互延迟必须控制在一到两秒以内。批量分析我跑在异步队列里用vLLM做推理开启continuous batching瓶颈主要在多请求并发时的显存吞吐。在线问答则单独部署一个较小的量化模型实例或者用同一服务做优先级队列避免批量任务把在线请求挤爆。模型都做了4bit量化A10卡跑13B模型足够用。显存紧张的话可以把长上下文场景下的最大输入长度做一个限制超长报告用滑动窗口切片处理而不是无脑扩上下文。还有一点容易忽略结果缓存。同一个工号、同一个工艺库、同一条violation记录很多时候会被多次查看。我把模型输出按照规则ID加内容摘要做缓存命中缓存就直接读结果不用重新推理。实际运行下来在线接口的缓存命中率能做到百分之三十左右资源压力小不少。4.4 嵌入现有验证流程的几种方式平台做得再好如果不嵌入工程师的真实工作流就没人用。我做了三个对接点。第一个对接点是TCL脚本触发。在后端验证流程里跑完DRC之后追加一段TCL把report文件自动推送到平台验证结束就能在网页上看到分析结果不需要额外人工上传。第二个对接点是版图工具集成。工程师在Web界面里看到一条高风险violation时可以直接点击“在版图中定位”平台通过API把坐标和层名发送给版图工具自动打开对应位置。这个动作省掉了工程师手抄坐标再回去找位置的步骤体验提升非常明显。第三个对接点是问题和需求管理系统。模型的输出可以一键生成任务单关联到责任工程师名下。任务单里附上violation坐标、风险等级、AI建议、引用来源让下游修改版图的人不用再来回翻报告。5. 实践中的常见问题与排查技巧实录5.1 模型幻觉什么时候最容易出现大模型幻觉在这个领域是绕不开的。我踩得最多的一类坑是模型为了解释一条violation会自己“编”一条和rule deck不一致的原理出来。尤其当知识库检索没有命中相关文档时模型容易一本正经地胡说。后来我加了“未命中规则原文就明确回答不知道”的机制同时在Prompt里强制要求如果检索片段里找不到对应规则就输出insufficient_context不许猜。这里的关键不是骂模型笨而是要给它一条“安全退出路径”。另一类幻觉出现在LVS归因上。LVS报告本身信息不完整模型经常会脑补出“可能是DNW层接反”“可能是M1 float”这类具体结论。实际上没有看版图细节根本无法确定根因。后来我把输出结构改了要求模型先给可能原因列表再给“排除这些原因的验证步骤”而不是直接给唯一结论。经过这一改模型回答的专业性和可信度都提升了一个量级。5.2 标注数据不足怎么撑过冷启动冷启动阶段标注数据永远不够。我建议分三步走先让专家写五十到一百条小样本种子数据覆盖高频规则用种子数据微调一个初版模型初版模型的输出经过专家修正后再进入标注集。这个过程就是典型的主动学习不需要一口气搞几千条标注只要种子集把规则类型覆盖全模型很快就能在一个工艺库里达到可用水平。另外一个技巧是用规则ID做弱监督信号。rule deck里很多规则自带类别信息比如spacing、width、enclosure这类关键字。可以直接用这些关键字给违规记录打初版标签再让专家筛选修正。虽然标签噪声高但作为预分类的起点是够用的。5.3 工具版本变化导致解析器失效这个问题最隐蔽也最让人头疼。EDA工具升级后报告里的字段顺序、坐标符号、错误码名称都可能发生变化。我的解决方案是对解析器做schema漂移检测每次解析时统计关键字段的缺失率如果某类字段缺失率突然超过阈值就自动发出告警并冻结该批次数据的自动流转。宁可让流程停下来也不能让模型读着残缺数据给出错误结论。同时所有解析器都做了版本登记。报告文件头里通常会带工具名称和版本号平台按版本号建立解析规则映射。某个新版本工具的格式没解析过系统会自动标记“未验证版本”由人来确认格式变化再更新解析器。这个流程保证了解析器的每一次变更都是有依据的而不是事后补救。5.4 并发使用时的性能和成本问题工程师团队同时跑项目的时候并发量不小。在线推理服务曾因为批量任务和在线请求共用一个队列出现过一次明显的卡顿工程师点开一条记录要等十秒钟才出结果体验极差。后来我把服务拆开在线队列优先级最高任务级批量推理放到低优先级队列并且限制了单用户的最大并发请求数。延迟从十秒降到了两点五秒以内。GPU成本也是需要控制的。模型量化后单次推理成本不高但架不住量大。我做了两层控制一是缓存策略二是输出长度限制。解释文本控制在三百个token以内不搞长篇大论。实验结果显示回答质量没有明显下降但显存吞吐压力小了不少。5.5 工程师不愿意用怎么办再好的系统如果一线工程师不信任、不想改变习惯最终就是摆设。我做过几件有意推动采纳的事情。在Web界面里增加置信度展示模块模型对每条输出都给出一个置信度评分低置信度结果直接要求人工复核。工程师看到模型“有自知之明”信任感会显著提升。还有一个小设计所有AI解释后面都带“认可”和“不认可”按钮。工程师每点一次都在为模型攒反馈数据。每周我会看一次反馈数据把工程师认为“不认可”的回答挑出来更新到知识库和微调数据集里。三个月下来界面上的被认可率从最初的百分之六十几提升到了百分之八十五以上。最关键的还是上线初期的“种子用户”策略。我拉了几位资深验证工程师先让他们试用、挑问题、提需求。他们发现问题、问题被修复、问题转化成了新需求这种参与感比任何宣传材料都有用。等这批种子用户在自己的团队里分享“平台帮我少看了一千条violation”的时候其他人的接受度就自然上来了。问题速查表现象原因排查方法解决建议模型输出与规则原文矛盾检索未命中或上下文不够查看输出references是否包含知识库文档增加检索命中率增加“证据不足就拒绝回答”机制JSON解析失败率突然升高提示词改动或微调后格式漂移检查最近一次模型迭代增加格式校验回归失败后自动转人工某批次报告解析为空EDA工具版本升级检查文件头版本号与解析器映射启用schema漂移检测冻结数据并人工确认在线接口延迟增高批量任务抢占资源查看并发队列状态拆分在线/批量服务设置队列优先级工程师反馈解释“说了等于没说”输出过于笼统抽查输出质量优化知识库检索增加更多具体案例不同人对同类violation处理结论不一致知识沉淀不足统计waive原因分布建立标准waive原因枚举回流知识库6. 影响范围、应用场景与后续扩展6.1 对验证工程师和项目流程的改变平台上线后最直观的影响是验证工程师的工作重心发生了转移。过去他们把大量时间花在逐条翻阅报告、分辨同类pattern上现在这部分工作被模型分类和预过滤替代。人的精力被释放出来聚焦到真正复杂、真正高风险的违规处理上。项目流程也变得更有秩序。平台为每条violation建立了完整生命周期谁、在什么时间、基于什么依据做了处理全部记录在案。项目经理可以随时按风险等级、处理状态、责任归属查看当前验证进度而不是在几份零散的Excel和聊天记录里拼凑信息。6.2 对标准和审计的意义“标准系统平台”这个定位在量产项目里会带来一个额外价值审查可回溯性。芯片流片前质量团队会检查物理验证是否充分、waive是否合理。以前这个检查过程靠人工翻报告效率低而且每个人翻的重点还不一样。现在系统里每条结论都带规则引用、知识库依据和操作记录审计可以按流程抽查也可以全量检查waive率偏高的规则类型揪出那些可能被过度放行的隐患。从更宏观的角度看这类平台本质上是把“老师傅的经验”变成了“组织结构化的资产”。人的经验会随离职流失但沉淀在标准系统里的判断逻辑、标注数据、知识库文档不会。这是我做这个项目过程中越来越确信的一点。6.3 从物理验证向更大范围扩展现在平台聚焦在物理验证环节但整套技术栈具有很强的外溢性。逻辑验证环节的仿真日志分析、覆盖率报告解释本质上是同一个问题非结构化文本、海量记录、需要领域经验来判断什么值得关注。时序分析报告后的violation筛选、跨电压域的约束冲突排查也是这样。只要接入层能解析数据、知识层能组织文档、模型层能做分类解释这套架构就能平移过去。从工艺迁移的角度看新工艺节点上线时需要重新适配大量规则。平台的历史知识库如果能做好分层老节点的waive记录就能作为新节点的参考基线加速新节点验证经验的积累。我甚至觉得这东西再往前走一步能变成整个设计团队的“规则知识底座”不只服务于验证还能辅助设计阶段提前规避问题。6.4 给我自己留下的一个很实在的结论我曾以为这个项目的核心难点在大模型调优但做完之后回头看真正的难点是把一个模糊的“AI提升验证效率”想法翻译成具体的数据结构、规则引擎、人机协作流程和验收指标体系。大模型只是冰山露出水面的那一角水面下是大量枯燥的解析、标注、版本管理、知识库建设以及和一线工程师不断对话、迭代的过程。小步快跑是这一整套东西落地的最靠谱路径。挑一个具体工艺库、一类高频规则、一条完整链路把它跑通、跑稳、跑出可量化的效率提升再去复制到更多场景。先让一小批专家看见收益让种子用户帮助完善流程比任何顶层设计都有效。结尾在这个项目里我最深的一个体会是大模型在严肃工业场景里真正值钱的能力不是“生成”而是“结构化地理解并辅助决策”。当它把几万条物理验证违规记录压缩成一张带风险排序、带证据链、带可执行建议的清单时它解决的不是某个人的效率问题而是整个验证团队的工作方式问题。如果你也想在类似的AI辅助平台里做点什么我的建议很朴素先把一个痛点做穿把数据标准化、知识结构化、人机分工边界这三件事想清楚然后再谈模型选型和微调。模型会过时工具会迭代但一套能让人和AI高效协作的标准系统会持续产生复利。至少在我做的物理验证场景里这是最值钱的东西。