大模型人工智能驱动的芯片物理验证标准平台实战复盘

如果你负责过一颗芯片流片前的物理验证，一定对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/low，suggestion必须给可执行的修改方向，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”的时候，其他人的接受度就自然上来了。

问题速查表

6. 影响范围、应用场景与后续扩展

6.1 对验证工程师和项目流程的改变

平台上线后最直观的影响，是验证工程师的工作重心发生了转移。过去他们把大量时间花在逐条翻阅报告、分辨同类pattern上，现在这部分工作被模型分类和预过滤替代。人的精力被释放出来，聚焦到真正复杂、真正高风险的违规处理上。

项目流程也变得更有秩序。平台为每条violation建立了完整生命周期，谁、在什么时间、基于什么依据做了处理，全部记录在案。项目经理可以随时按风险等级、处理状态、责任归属查看当前验证进度，而不是在几份零散的Excel和聊天记录里拼凑信息。

6.2 对标准和审计的意义

“标准系统平台”这个定位，在量产项目里会带来一个额外价值：审查可回溯性。芯片流片前，质量团队会检查物理验证是否充分、waive是否合理。以前这个检查过程靠人工翻报告，效率低，而且每个人翻的重点还不一样。现在系统里每条结论都带规则引用、知识库依据和操作记录，审计可以按流程抽查，也可以全量检查waive率偏高的规则类型，揪出那些可能被过度放行的隐患。

从更宏观的角度看，这类平台本质上是把“老师傅的经验”变成了“组织结构化的资产”。人的经验会随离职流失，但沉淀在标准系统里的判断逻辑、标注数据、知识库文档不会。这是我做这个项目过程中越来越确信的一点。

6.3 从物理验证向更大范围扩展

现在平台聚焦在物理验证环节，但整套技术栈具有很强的外溢性。逻辑验证环节的仿真日志分析、覆盖率报告解释，本质上是同一个问题：非结构化文本、海量记录、需要领域经验来判断什么值得关注。时序分析报告后的violation筛选、跨电压域的约束冲突排查，也是这样。只要接入层能解析数据、知识层能组织文档、模型层能做分类解释，这套架构就能平移过去。

从工艺迁移的角度看，新工艺节点上线时，需要重新适配大量规则。平台的历史知识库如果能做好分层，老节点的waive记录就能作为新节点的参考基线，加速新节点验证经验的积累。我甚至觉得，这东西再往前走一步，能变成整个设计团队的“规则知识底座”，不只服务于验证，还能辅助设计阶段提前规避问题。

6.4 给我自己留下的一个很实在的结论

我曾以为这个项目的核心难点在大模型调优，但做完之后回头看，真正的难点是把一个模糊的“AI提升验证效率”想法，翻译成具体的数据结构、规则引擎、人机协作流程和验收指标体系。大模型只是冰山露出水面的那一角，水面下是大量枯燥的解析、标注、版本管理、知识库建设，以及和一线工程师不断对话、迭代的过程。

小步快跑是这一整套东西落地的最靠谱路径。挑一个具体工艺库、一类高频规则、一条完整链路，把它跑通、跑稳、跑出可量化的效率提升，再去复制到更多场景。先让一小批专家看见收益，让种子用户帮助完善流程，比任何顶层设计都有效。

结尾

在这个项目里，我最深的一个体会是：大模型在严肃工业场景里，真正值钱的能力不是“生成”，而是“结构化地理解并辅助决策”。当它把几万条物理验证违规记录压缩成一张带风险排序、带证据链、带可执行建议的清单时，它解决的不是某个人的效率问题，而是整个验证团队的工作方式问题。

如果你也想在类似的AI辅助平台里做点什么，我的建议很朴素：先把一个痛点做穿，把数据标准化、知识结构化、人机分工边界这三件事想清楚，然后再谈模型选型和微调。模型会过时，工具会迭代，但一套能让人和AI高效协作的标准系统，会持续产生复利。至少在我做的物理验证场景里，这是最值钱的东西。