聊方案和算参数，在电源设计里完全是两码事。我见过不少团队兴致勃勃把大语言模型接进硬件设计流程，让对话式 AI 帮忙选拓扑、聊方案思路，前期什么都顺，真到让 Assistant 算一个反激变压器的匝数比或者环路补偿参数时，就开始翻车——要么公式形态用错，要么把连续模式下的方程直接套到了断续模式里，要么压根不管输入电压范围和占空比边界。问题根源不是模型不够“聪明”，而是它背后缺一套面向严谨计算的“权威知识库”。电源硬件设计 Agent 要真正跑起来，第一步要解决的不是 Agent 本身，而是给它的计算动作提供一套分好层、带边界、有来源、可裁决的知识底座。这是一篇写给同行看的“前提工程”笔记，重点在“三层权威”知识库怎么搭、每层管什么、Agent 调用时怎么让人敢信它的计算结果。

1. 为什么“严谨计算”是电源硬件设计 Agent 的第一道坎

1.1 对话式模型聊方案可以，算参数不行

对话式模型强在“生成”，弱在“精确计算”，这是由推理方式决定的。你问它“反激电源的优缺点”，它可以给你列十条；你问它“输入 90V 到 265V 交流、输出 12V 3A，CCM 模式下反射电压取 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 输出的设计和当年实物的实测记录做逐一对比打分，这是验证这套知识库成色最快、也最不留情面的办法。