聊方案和算参数在电源设计里完全是两码事。我见过不少团队兴致勃勃把大语言模型接进硬件设计流程让对话式 AI 帮忙选拓扑、聊方案思路前期什么都顺真到让 Assistant 算一个反激变压器的匝数比或者环路补偿参数时就开始翻车——要么公式形态用错要么把连续模式下的方程直接套到了断续模式里要么压根不管输入电压范围和占空比边界。问题根源不是模型不够“聪明”而是它背后缺一套面向严谨计算的“权威知识库”。电源硬件设计 Agent 要真正跑起来第一步要解决的不是 Agent 本身而是给它的计算动作提供一套分好层、带边界、有来源、可裁决的知识底座。这是一篇写给同行看的“前提工程”笔记重点在“三层权威”知识库怎么搭、每层管什么、Agent 调用时怎么让人敢信它的计算结果。1. 为什么“严谨计算”是电源硬件设计 Agent 的第一道坎1.1 对话式模型聊方案可以算参数不行对话式模型强在“生成”弱在“精确计算”这是由推理方式决定的。你问它“反激电源的优缺点”它可以给你列十条你问它“输入 90V 到 265V 交流、输出 12V 3ACCM 模式下反射电压取 80V求匝比 n”它可能给你一个看起来合理但经不起推敲的答案。因为在电源设计里同一组物理量在不同工作模式下对应完全不同的方程漏掉一个前提条件计算路径就完全不同了。举个很典型的例子反激变换器匝比 (n) 和反射电压 (V_{OR}) 的关系式 (V_{OR} n \times (V_{out} V_f)) 本身很简单但什么时候成立、怎么决定 (V_{OR}) 的取值区间背后绑定了一连串边界原边开关管的耐压裕量、最大占空比限制、输入电压最低点的反射电压能否保证副边导通时间足够。模型如果只记住了公式却不知道这些前置规则给出来的“计算结果”就只是一串数字没有任何可用的工程意义。电源设计不是“差不多先生”能干的活每个数值都会落到实物上算错了板子就摆在那里等着冒烟。1.2 参数级联一步错导致的“看起来合理但全链路污染”更麻烦的是电源硬件设计里的参数是一条长链根本不允许中间环节有幻觉。你算电感量要先知道开关频率、纹波率、伏秒积电感量定了再算磁芯选型、匝数、气隙匝数变了占空比在极限工况下的实际值也会变占空比变了环路补偿的穿越频率设计基准也跟着动。磁性元件的损耗计算还会反过来影响热设计和效率估算。任何一个环节在“没有根据”的情况下输错一个数下游全部跟着污染而且污染很隐蔽——因为结果量级还是正常的电流还是几安培电压还是几十伏看起来像模像样实际上已经彻底偏离了正确设计点。这种“看起来合理但全链路污染”比直接报错更可怕。直接报错还能让人检查给出一个看似严谨的错误结果会让人浪费大量时间去查板子。所以我一直强调Agent 做电源计算时不能有“概率性发挥”的空间它必须每一步都建立在“带来源、带边界、带审核状态”的知识单元上。这正是严谨计算和日常问答的本质区别。1.3 面向严谨计算的知识库和通用问答库的评价标准完全不同这里我把两类知识库的差异列一下方便大家理解为什么不能拿着通用问答知识库的办法直接做电源设计维度通用智能问答知识库面向严谨计算的知识库核心评价指标相关性、内容丰富度、表达流畅数值正确性、边界覆盖度、证据可追溯性错误容忍度较低语义偏离可接受极高单点错误可导致全链路失效知识组织单元段落、文档、摘录可计算的规则、参数化模板、带来源的常量更新驱动文档新增、新内容补充数据手册更新、实测异常、失效案例回流使用方式检索后生成答案检索后按模板实例化并执行计算流程从这张表可以看得很清楚严谨计算的知识库必须是一个“可执行对象系统”而不是“文本集合”。通用知识库回答错了最多说一句“抱歉我理解得不对”电源计算 Agent 答错了那就是一次真实的电源失效案例。这也是我在整个构建工作中最优先考虑的问题知识库的权威性不是宣传词而是计算安全的第一道防线。2. 三层权威的分工理论管物理标准管边界经验管例外2.1 理论权威物理与数学的绝对约束理论权威层是地基负责“在理想条件下系统应该呈现什么行为”。它包含基本电路定律、开关变换器的稳态和动态方程、磁性元件基础理论、环路控制理论这类普适性极强、变化极慢的知识。这一层的特点是不会因为某个新器件发布而改变也不会因为某个项目的特殊经验而推翻它们是整个计算体系里的“公理”。在知识库设计里理论层不应该是整篇整篇的教材文档而应该被拆成一条一条“带严苛适用边界的计算规则”。例如“电感伏秒平衡”“变压器安匝平衡”“电容电荷平衡”这些听起来是基本原理但在不同拓扑、不同工作模式下的表达形式完全不同必须细化到能被程序判断的状态。理论权威层的建设质量决定了 Agent 的“方向感”方向错了再好的器件选型都白搭。2.2 标准权威器件行为与安全边界的工程约束标准权威层负责把理论计算结果拉回到“工程可接受范围”。器件数据手册里的绝对最大额定值、推荐工作条件、热阻曲线、开关特性参数以及行业多年沉淀下来的降额惯例都属于这一层。理论层会告诉你“这管子理论上能过 10A 平均电流”但标准层会告诉你“在 125 摄氏度壳温下安全工作区里允许的电流只有 7A再算上开关损耗和短路尖峰实际推荐值只有 5A”。这一层的特点是有明确来源、带版本、会随时间更新。数据手册不是永恒的真理某器件厂商某一年修订了安全工作区曲线就是一次显著的知识库变更事件。标准权威层的价值就是把“器件的数据边界”做成机器可读的安全护栏Agent 在给方案之前必须先撞一遍这堵墙。2.3 经验权威实测与失效案例的证据约束经验权威层是我觉得最容易做歪、但做成了价值最大的一层。它记录的是“在真实项目中某做法在实际运行中出现过什么异常”包括失效现象、根因分析、复现条件、量化规避措施。这一层补充的是理论层和标准层覆盖不到的“真实世界的脏细节”。举个例子理论上某 MOSFET 的电压应力只要在额定值以内就不会失效但实际项目里发现在某个开关频率和 PCB 布局下关断尖峰整定比理论估算高出一倍原因是寄生电感与结电容的耦合效应在数据手册里并不会体现。这种经验如果不沉淀进知识库Agent 下次设计同样的拓扑还是会踩同一个坑。经验权威层的本质是“证据”不是“印象”每一条最好能量化成“在什么条件、什么现象、多大概率、怎么规避”。2.4 一套驾驶逻辑三层之间的优先级关系和相互校正拿开车来类比这三层的关系理论层像物理定律任何一辆车都必须遵守它限定了“车在这条弯道上理论能承受的极限速度”标准层像交通法规规定的不是物理极限而是“安全行驶速度上限”不同地区法规版本还不一样经验层像事故案例库告诉你“这个路段即使限速 60下雨天也容易打滑老司机通常只开 40”。Agent 在执行计算时也应该遵循这套逻辑先用理论层选出正确的方程再用标准层完成安全边界校核最后用经验层验证是否有已知的例外情形。三层不是并列关系而是递进关系。缺少理论层Agent 连方向都会错缺少标准层Agent 会一直游走在爆炸临界点缺少经验层Agent 会在从未见过文档记录的真实工况面前表现得过度乐观。反过来说经验层发现理论和现实的系统性偏差时要能反向推动理论层去检查公式假设是否成立或者推动标准层去关注设备手册参数是否被误用。在三层互相校正的闭环里知识库才会越来越可信。3. 理论权威层的精细化建模让公式自带适用边界和来源3.1 公式权力清单给每条公式建立“身份档案”做知识库的第一步不是收集公式而是给公式建立“身份档案”。我得知道每条公式是经过什么样的验证路径进入知识库的是教科书标准推导、论文推导、还是用仿真工具验证过适用拓扑是什么适用工作模式是 CCM、DCM还是两者兼顾使用频率范围的限制是什么这些元信息要跟着公式一起存而不是放在文档某个角落。我给这个档案机制起了个内部叫法叫“公式权力清单”核心思想是“不是所有写在纸上的公式都有资格被 Agent 直接调用”。被废弃的旧公式也要有记录标注废弃原因和替代公式 ID否则时间久了自己都搞不清楚为什么某个版本的计算路径改了。没有权力清单的公式库和一本没人校对的习题集没有区别你无法保证里面每道题的答案都是正确的。3.2 假设条件显式化理想公式和真实场景的差距这是我踩过最深的一个坑也是最想让各位注意的点。大量电源公式的推导都埋了隐形假设——比如“变压器是理想的漏感为零”“电感电流纹波很小可以近似为线性变化”“开关管压降忽略不计”。这些假设在教科书里省去是为了推导简洁但到了 Agent 手里就成了定时炸弹。所以理论层的每条公式必须显式列出它的假设条件清单并且区分哪些假设在什么参数范围内可以放宽哪些假设一旦不成立就得换另一条公式。还是拿反激变换器举例“伏秒平衡”公式在 CCM 下成立的前提是稳态且电感电流连续如果工作模式判定错了直接用伏秒平衡去算 DCM 工况下的占空比得到的结果就是错的。把假设条件做成机器可判定的字段Agent 才能在自己运行到某一步时主动检查“当前场景是否满足前置条件”不满足就拒绝计算并提示需要人工介入。这不是为了限制 Agent 的自由度而是给它加一道“不犯低级错误”的保险。3.3 参数依赖图谱先知道“算什么需要先知道什么”理论层建设过程中很容易忽视的另一个点是参数的“计算顺序”。电源设计里很多参数量看似并列实际上存在严格的依赖关系只有知道了开关频率才能确定伏秒积只有知道伏秒积和期望的纹波率才能算出临界电感只有知道电感量、匝数和磁芯截面积才能逼近磁通密度摆幅。如果知识库里只有“公式清单”而没有“参数依赖顺序”Agent 在推理时就会不知道该先去获取哪个未知量或者更糟糕它会从一个没有被任何来源支撑的假设值开始往下算整个计算链从一开始就是悬空的。我建议为每个子领域建立一张参数依赖图谁由谁决定、谁需要查手册、谁需要经验预设、谁必须由用户输入。真正严谨的 Agent遇到每一个“未知量”都应该先判断这个量的来源等级而不是默默假设一个。3.4 知识条目的参数化模板让公式可以被 Agent 直接执行理论层的知识单位最终要落成一个可以被程序实例化的模板。我给每条核心规则设计的结构大概长这样{ knowledge_id: FLYBACK_TURNS_RATIO_001, layer: theory, domain: flyback_ccm, assumptions: [工作在CCM且环路稳定, 忽略漏感对电压尖峰的影响, 副边二极管导通压降近似取典型值], input_params: { VOR: {unit: V, source_level: user_or_spec}, VOUT: {unit: V, source_level: user_or_spec}, VF: {unit: V, source_level: datasheet_or_estimation} }, output_params: { n: {unit: 1, description: 原副边匝比} }, formula_template: n (VOR VF) / (VOUT VF), source: derived_from_volt_second_balance, review_status: approved_v1, validated_cases: [case_flyback_5V_3A_001, case_flyback_12V_2A_003] }这样做的好处是知识条目本身不是一段“文字说明”而是一个“可执行对象”。Agent 检索到它之后能自动解析输入参数、检查假设条件、执行公式模板、输出带来源 ID 的计算结果。只要知识库源头是可靠的整个链路就在可控范围内如果哪一环数据不可靠这个结构也能明确告诉使用者到底哪个环节出了问题方便回溯。4. 标准权威层的知识化数据手册语义抽取与降额边界入库4.1 数据手册不是文档是带版本来源的边界数据集很多团队做知识库都是把数据手册 PDF 直接丢进向量库让模型“翻资料”。这个思路对严谨计算来说完全不够。数据手册里的一个数值只有同时绑定了“器件型号、厂商、手册版本号、页码或曲线标识、适用测试条件”这些元信息才有资格被 Agent 引用。否则模型检索到的可能是一份过时手册里的旧参数或者误用了某型号同系列不同子型号的差异数据。标准权威层的信息抽取至少有四类关键内容必须做结构化绝对最大额定值、推荐工作条件、典型特性曲线、热阻与封装参数。前两类直接给安全边界后两类影响实际寿命评估和热设计。更重要的是要保留“手册版本号”这个字段因为器件厂商修订手册时如果改了安全工作区曲线或降额曲线值旧版本的知识条目必须被标记为“过期”。没有版本控制的数据手册库还不如没有——它会给出看起来权威、实际却过期的错误约束。4.2 降额规则的入库方式安全系数从哪来到哪去降额是电源设计里最常见也是最容易被 AI 忽略的工程动作。理论计算出的电压应力可能刚好落在器件最大额定值的 90% 附近理论上能用但行业通行的可靠性设计规范会要求再留出足够的裕量。比如半导体器件的电压降额按一定比例、电解电容的纹波电流降额按一定比例具体比例取决于产品应用等级。知识库里保存降额规则时不能只存一个数字还要存“规则来源、适用产品等级、适用条件”。同样是降额消费类电源和长期满负荷运行的高可靠电源降额系数完全不同。Agent 在做器件选型时应该先用理论层算出电气应力再用标准层的降额规则把应力放大到“可接受的设计目标”最后拿这个放大后的值和器件手册的绝对最大额定值比较。这一步一旦做错要么选了过裕量的器件导致成本飞涨要么踩在红线边缘导致长期可靠性隐患。4.3 非理想效应修正让计算贴近芯片真实行为数据手册给出来的参数都是在特定测试条件下测出来的典型值实际电路里到处是“非理想修正”。最典型的有三类开关管的导通电阻随结温升高而变大电容的 ESR 随温度变化且受频率影响磁性元件的损耗并不是固定值更依赖磁通摆幅和频率。理论层算的是“理想器件在理想条件下的行为”标准层必须补充“真实器件在边界条件下的行为”。我的做法是把这些非理想效应修正也做成知识条目每个条目标注“修正对象、修正公式或修正曲线、适用温度/频率范围、原始参数来源”。Agent 在完成理想计算之后强制走一遍非理想修正流程把温度变化、频率特性、寄生参数带来的偏差修正回来。这个步骤在常规教程里经常被跳过但恰是“理论结果”和“实测结果”拉开差距的最大来源。4.4 理论层和标准层冲突时谁说了算知识库一定要提前定义冲突仲裁原则否则 Agent 在计算中遇到“理论可行、手册不允许”的情况就会开始和稀泥。我的原则很明确标准层对“安全性”的判定优先于理论层对“可用性”的判定。意思是理论公式算出电流应力 8A器件手册安全工作区只支持 6A那就不用再争论 8A 理论是不是被低估了直接判为不可行继续寻找替代方案。但这不代表理论层可以被随意碾压。冲突发生时知识库应该记录一条“冲突证据”包括冲突双方的知识条目 ID、冲突参数的具体数值、仲裁结果、以及是否开启了人工复核。后续如果经验层中有大量类似拓扑在相似工况下实际通过了测试经验层可以反向“推翻”标准层的过度悲观估计但这必须走人工确认流程。仲裁机制不是为了消灭冲突而是为了把每一次冲突变成知识库进化的线索。5. 经验权威层的建设用失效案例给计算兜底5.1 失效案例的结构化模板从现象到可复用规则经验层最容易做成一堆“故事”这是最大的浪费。失效案例要能够被 Agent 使用必须以结构化模板入库设备上线时的异常表现、烧毁或损坏的器件、失效时刻的电气/热/波形特征、根因分析结论、复现条件、修复动作、以及最终沉淀出来的可复用规则。我见过一个很有代表性的案例某辅助电源在开机瞬间连续损坏同步整流管理论计算和器件手册校核都通过了但实物一上电就烧。后来定位到根因是输出电容的 ESR 过大在二次侧产生了一个超出预期的电压尖峰叠加到同步整流管的漏源电压上突破了安全工作区。这个案例如果只作为“一篇故障报告”躺在文件夹里Agent 永远不会知道但当它被结构化成“故障现象 根因 规避规则”的知识条目后下一次设计类似拓扑、选用类似输出电容参数时Agent 就会自动预警并调用修正公式。这才是经验权威层的真实价值。5.2 实测数据回流把“我们在某次测试中发现”变成量化证据知识库里不能只有书本和数据手册还要有真实项目里积累下来的实测数据它们是典型的稀缺权威证据。一套 60W 反激方案的环路增益实测波特图、一台老化的温升记录、一批板子输出纹波噪声的统计分布——这些数据代表了真实世界的“地回答”。它们比任何理论估算都更接近实际尤其是那些理论模型还没有完全解释清楚的现象。做这套工作时我建议把每个实测数据条目都标注采集来源、板卡版本、测试条件、样本数量。只有样本量足够大或者异常复现次数足够多的现象才有资格沉淀为“概率性规律”入库孤立的个例只能作为“潜在风险提示”不能作为设计规则直接使用。5.3 用概率语言描述经验不给 Agent 模糊指令经验层的知识描述方式要特别注意这是新手团队最不会做的一点。不要写“这种方案在开机时容易颤振”而要写“在 A 条件、B 负载、C 开关频率组合下出现 D 现象的比例为 X%规避动作 E 可以将频率降到 Y%”。Agent 读到前一种描述只会输出一句充满不确定性的废话读到后一种描述才能真正参与计算决策。概率化语言让经验层知识具有“可计算性”。Agent 在标准层校核完之后会根据经验层的概率规则判断当前设计方案是否有已知的高风险隐患并在输出报告中标注风险等级和规避建议。这样既保留了经验的参考价值又不会因为一句没有量化依据的“经验上不行”而把合理的方案一票否决。5.4 经验层反向驱动理论层和标准层的更新经验层的真正价值不只是“兜底”还在于“纠偏”。当多个项目都出现“理论计算损耗比实测损耗显著偏低”的情况就该停下来查查是不是理论层的某个假设在现实场景下从来不成立。我就遇到过类似的问题某类磁性元件实测损耗普遍比经典计算值高不少最后追查发现是气隙附近的边缘磁通损耗被经典公式忽略了尤其是在气隙大、工作频率高的场景下非常明显。这类系统性偏差发现之后经验层不能只“记住”差异而要反向推动理论层新增一条“边缘磁通损耗修正项”的计算规则或者推动标准层更新对这个磁芯材质损耗特性的参考曲线。经验层、标准层、理论层互相驱动知识库才会越用越准而不是越用越臃肿。6. Agent 调用知识库时的机制设计分层检索、冲突仲裁、证据链留痕6.1 知识单元是“可计算对象”而不是“可引用文字”所有知识条目入库时都要遵循同一个原则Agent 拿到的不是一段可引用文字而是一个可计算对象。我在前面给的 JSON 示例已经体现了一部分这里再强调一下知识单元必须包含参数表、公式模板、适用条件、来源 ID、审核状态、版本号。Agent 的职责不是“看懂这一段话然后自己推理”而是“对齐知识单元的参数表执行公式模板输出带来源的计算结果”。这个原则直接改变了 Agent 的行为模式。它不再是“一个懂电源的大模型”而是一个“能调用权威知识单元的计算调度器”。模型的理解能力仍然有用但主要用于解析需求场景、生成设计计划、汇总报告文案真正敏感的计算步骤全部走知识单元执行。6.2 一次典型计算的调用顺序场景解析、公式实例化、边界校核、经验修正拿反激变压器设计来走一遍流程。第一步场景解析Agent 根据输入规格和工作模式判定条件确定当前设计落在 CCM 还是 DCM 域这是最基础的前提判定。第二步公式实例化从理论层调出对应工作模式的匝比公式、伏秒积公式和临界电感公式把用户输入参数一一对应填充。第三步边界校核用标准层的数据手册边界和降额规则核对每一步计算的中间结果比如开关管电压应力是否在降额后的安全范围内、磁芯磁通密度是否接近饱和拐点。第四步经验修正在经验层检索同类拓扑、同类功率段是否有关键失效案例或经验修正系数若有则按概率规则对计算结果做修正或输出风险提示。这四步走完Agent 才真正“做完了一次电源计算”。每一步的输出都带着完整的证据链任何一步出问题都能定位到具体知识条目而不是扔出一句“系统认为不可行”。6.3 置信度与证据链每个输出数值都必须能回答“为什么”电源设计 Agent 的每一个输出数值都应该能回答“这个数是怎么来的”。我把证据链分成三个层次公式来源哪条理论规则、哪个版本、参数来源用户输入、数据手册某版本、实测回流、还是默认假设、边界校核记录通过了哪些安全边界检查。任何一个参数的来源如果只能靠默认假设该数值就必须标注为“低置信度”并且要求人工介入确认。比如计算开关管电压应力时如果输入参数里的漏感尖峰只能靠经验默认值Agent 就要在报告中显著标注“此区间为估算值建议以实测波形为准”。这个机制在人类工程师之间其实就是“负责任地标注假设”但到了 Agent 身上需要把它变成硬性规则。没有证据链的数值无论是人算还是机器算都不该出现在最终方案里。6.4 版本演进与存量方案重算知识库和代码库一样必须有版本管理。理论层变化最慢标准的更新主要来自数据手册修订经验层则随每个项目持续增长。这里有一个容易被忽略的动作每当数据手册修订触发标准层知识条目变化时系统中所有“在存状态”的设计方案都要被标记为“需要重算校核”。举个例子某器件厂商修订了一款常用功率开关管的安全工作区曲线降低了高频区的允许电流知识库更新后那些还在设计流程里的高端开关频率方案就应该自动触发重算。如果不做这一步Agent 可能拿着旧版本的安全边界给新项目做选择结果就是“知识库更新了设计方案却还在用旧规则”。版本演进的自动化能力从侧面决定了 Agent 是否真的有长期使用价值这是自动化系统区别于一次性计算工具的分水岭。7. 落地路线与第一批翻车教训先做磁性元件小闭环再谈高度自动化7.1 为什么建议从磁性元件损耗计算这个小闭环起步很多团队一上来就想做“全拓扑自动设计”输入规格直接输出完整原理图这个目标听起来很激动人心实际落地时复杂度高得吓人拓扑选择、器件选型、环路设计、热设计、PCB 布局建议、EMC 预判任何一环知识库不够硬都会让整个系统崩掉。我更推荐优先选择“磁性元件选型与损耗估算”作为第一个闭环。原因是它的边界足够清晰输入参数明确输入电压范围、输出电压/电流、开关频率、磁芯材质和尺寸范围、输出可量化匝数、气隙、磁通密度摆幅、损耗值、温升预估、验证手段直接绕一个变压器、上电子负载、测温升和效率就能得到反馈。这个闭环一旦打通Agent 的整套调用机制、证据链机制、冲突仲裁机制就都被真实跑了一遍后续扩展到环路设计和热设计时才不会手忙脚乱。7.2 验证指标可复现率、偏差分布、方案误杀率知识库建成什么样才算合格我建议用三个指标来衡量。第一个是“计算可复现率”同一输入多次运行输出结果和证据链完全一致的比例。如果 Agent 计算过程中存在随机性、检索排序波动可复现率会很难看而这在严谨计算里是不可接受的。第二个是“实测偏差分布”拿一批历史项目的实测数据去回放看看 Agent 计算的关键参数和实测值的偏差中位数、分布离散度以及异常点比例。第三个是“方案误杀率”把一批历史上验证过可用、能正常工作的设计案例输入给 Agent看它有多少比例会把这些可行方案判为不可行误杀率要压到足够低才谈得上自动化。这三个指标合在一起就是“知识库是否值得信任”的量化答案。别急着上自动化先把这套验证流程跑完再谈“高度自动化”这三个字。7.3 第一批项目里反复踩的五个坑第一批实施过程中有几个坑我几乎是每个项目都能看到有人踩一遍。坑一是知识粒度太粗。整个公式集当作一条知识塞进向量库Agent 检索时“好像找到了又好像没找到”最后计算过程变得完全无法追踪。解决办法很简单知识粒度要细到“一条知识一个公式或一条规则”。坑二是只放知识不放边界条件。公式本身搬进来了适用场景和假设条件却留在外面这会把 Agent 变成一个“公式复读机”你说什么它用什么完全不判断场景。坑三是经验层未经量化清洗就入库。把个例当规律把一次偶发的测试异常当成普遍风险导致 Agent 在大量原本合理的设计前过于保守误杀率飙升。坑四是三层冲突时不仲裁。理论层和标准层打架时Agent 自己猜一个结果既没有仲裁规则也没有人工复核动作输出一个“看起来两边都照顾到了”的模棱两可结果这种结果最害人。坑五是把模型本身当计算器。让 LLM 的推理能力直接参与数值运算而不是让模型负责调用知识单元执行计算结果就是所有小数值都带上了模型的“猜测性”这完全违背了严谨计算的初衷。7.4 知识库的持续维护节奏以及我的一点经验收尾知识库不是一次建完就结束的工程。我建议每个设计项目结束之后都做一次“案例回填”把在设计过程中发现的公式边界问题、器件手册更新、实测偏差、失效案例全部补进来。团队每周花一点时间过一遍新案例有针对性地质疑某条知识单元的适用条件这种维护节奏运行一个月后知识库的准确度会看到明显提升比一次性投入几个月然后放任不管效果好得多。根据我个人的体会先花两三个月把一个“磁性元件小闭环”的权威知识库做扎实远比一开始就把盘子铺开要划算。自动化程度高不高不取决于 Agent 本身的多才多艺而取决于知识库里每条规则、每个参数、每个边界条件靠不靠谱。所谓“三层权威”本质上是在为计算可信度做三道防线理论层保证方向正确标准层保证不越红线经验层保证贴近现实。最后再分享一个实用的检验方法拿一条老项目的输入规格把 Agent 输出的设计和当年实物的实测记录做逐一对比打分这是验证这套知识库成色最快、也最不留情面的办法。