企业官网建设流程全解析

电源硬件设计大概是LLM应用里最考验“防幻觉”能力的领域之一。一颗电容选错，效率、纹波、环路稳定性可能全线崩盘；一个不存在的MOSFET型号被写进BOM，产线直接停摆。我最近在做一个面向电源硬件设计的agent智能体架构，基于Deepseek Harness搭了一套可控流程，核心目标很明确：让模型保持推理和对话能力，但在器件型号、计算公式、物理规律这些“不能错”的地方必须说谎即被抓。这篇文章会把整个架构拆给你看，包括防幻觉机制的设计思路、Agent的完整工作流，以及我在实测中踩过的五个真实的坑。适合正在做LLM应用落地、或者在硬件设计领域试水AI工具的开发者参考。

1. 电源设计场景里，大模型幻觉为什么比代码错误更隐蔽

1.1 电源设计的容错空间极窄

先说一个反直觉的结论：在代码生成场景里，模型写错一个函数名，编译器能立刻告诉你；在电源设计场景里，模型推荐错一个电容的耐压值，编译器、仿真器都不存在——错误会被PCB实物放大成过热、啸叫、效率不达标，甚至烧板。你在对话框里问一句“3.3V/2A的Buck怎么设计”，模型可能给你一个看起来完全正确的方案：开关频率500kHz、电感6.8µH、输出电容22µF。参数都对，但这只说明“均值意义上的正确”，不代表这些型号在当前库存、温度、纹波要求下真的够用。

真正的电源设计要考虑的变量远比对话里能聊到的多：输入电压是固定还是宽范围，纹波目标是20mV还是50mV，环境温度是25°C还是85°C，PCB面积是受限还是要做成邮票孔模块，EMI标准是哪一级。这些约束缺一个，答案就可能从“可用”变成“无法打样”。而通用对话式工具给不出约束感，它更擅长给一个四平八稳的“标准答案”，但这个标准答案恰恰是最危险的——因为它看起来太正常了，容易让人放松警惕。

1.2 幻觉高发区：器件型号、公式与物理规律

我在实际测试中把Deepseek模型的错误输出做了分类，三类幻觉占比最高。

第一类是器件型号幻觉。模型会生成看起来像真正的型号，比如“TPS54360”“AO4407A”这种风格，但这些型号的封装、耐压、导通电阻与它描述的参数经常对不上。更麻烦的是，它还能记住一部分真实型号，却把这些型号的极限参数记错，比如把某颗LDO的最大输入电压从40V记成60V。这类幻觉在对话里几乎无法察觉，因为型号字符串是真实存在的，只有逐个核对数据手册才能发现偏差。

第二类是公式幻觉。稳压环路补偿的公式稍微复杂一点，模型就容易把零点位置写错，或者把极点当零点处理；在计算穿越频率时，又常常把增益带宽积和单位增益频率混为一谈。更隐蔽的是单位错误，一个公式里只要µF和nF混用，数值就差了1000倍，而公式本身看起来依然正确。

第三类是物理规律幻觉。模型会建议“用100µF陶瓷电容做输出滤波”，但不提示陶瓷电容在大直流偏置下容量可能掉到标称值的30%；它会建议低压差LDO的压差设置0.5V，却不考虑大电流下压差会随负载增加而抬升。这类错误不是查一个器件参数就能发现的，它需要对电源工作原理有真正的物理直觉。

1.3 通用对话式方案为何不能直接上生产

直接拿通用对话界面做电源设计，等于让一个博学但没拿过烙铁的人直接签原理图。问题不在模型智商，而在它的运行机制：语言模型本质上是一个“预测下一个词”的机器，它擅长的是生成“看起来合理的序列”，而不是“保证绝对真实的序列”。所以防幻觉的唯一办法，不是在提示词里加一句“请确保正确”，而是在架构层面让每一个关键结论都能被外部证据验证。

这也是我这个项目把Harness编排层作为核心的原因。模型负责提出方案，编排层负责验证和执行，两层之间不能有模糊地带。任何没有被工具验证过的数字，都只能作为“候选值”，不能进入最终设计文档。

2. Deepseek Harness在架构里的真实角色：编排层而不是“多了一个模型”

2.1 我对Harness的理解：给大模型套上可约束的执行轨道

很多人第一次听到“Harness”这个词会困惑，以为是某个新模型。其实Harness在LLM应用圈里，指的是连接模型能力和外部世界的“缰绳”：它管理提示词模板、工具调用、上下文窗口、策略路由和结果校验，相当于给一个自由发挥的大模型装上轨道，让它只能沿着预先设计好的路径走。我的项目里把这个编排层命名为Deepseek Harness，底层模型用Deepseek系列，上层是我自己封装的工作流引擎。核心逻辑只有一句话：模型不再被直接提问，而是被编排层拆解成多个子任务后逐段调用。

这么做的好处是，每次调用模型的上下文都被严格控制。比如在“参数计算”这个子任务里，模型只能看到当前设计目标的参数集合和可调用的工具清单，看不到无关的对话历史。上下文越干净，模型跑题的几率越低，幻觉产生空间也越小。

2.2 整体拓扑：模型、编排层、工具层、知识层四件套

整个架构可以分成四层，我用一个表来说明。

这个分层不是拍脑袋定的。我一开始的做法是把所有功能塞进一个Prompt模板，让Deepseek自己决定调不调工具、查不查资料，结果经常出现“模型说自己查了资料，实际没查”的情况。后来把工具调用从模型手里收回到编排层，模型只能通过编排层暴露的接口去访问外部世界，错误率立刻下来一大截。这个教训我很早就想明白了：自由调用工具的前提是模型能准确判断“什么时候该用什么工具”，而这件事对大模型来说其实很难。与其赌模型的判断力，不如在架构上把选择权收走，最多给它两个选项。

2.3 为什么核心流程采用“模型发起、工具决断、审查兜底”

架构最重要的一个设计原则是权限分离：想出主意的模型不能自己盖章。在Deepseek Harness里，我明确规定了三类角色。

• 设计Agent：负责理解需求、提出设计方案、给出参数计算初值，但它没有最终决定权。
• 工具校验器：所有关键数值必须交给SymPy或单位解析器执行，如果工具算出的结果和模型给出的不一致，以工具结果为准。
• 审查Agent：在每一步输出后对结果做反向质疑，模拟“最挑剔的资深硬件工程师”来审方案。

这套机制本质上是从制度上限制模型的权力。模型可以犯错，但错误会在三个环节中被拦截。这种“发起—执行—审查”的三角形结构，比任何提示词都可靠。注意审查Agent不是设计Agent的“复读机”，它必须独立获取证据，否则就只是同一个大脑在自言自语。关于这一点，后面的踩坑记录里会详细展开。

3. 防幻觉不是叠提示词，而是四层机制协同

3.1 第一层：领域知识库RAG与溯源约束

第一层解决的是“模型不知道但假装知道”的问题。我把电源设计相关的数据手册、应用笔记、企业设计规范全部切片后灌入向量库，并在知识层里规定了一个硬性要求：Deepseek生成设计方案时，凡是涉及器件型号、拓扑特性、参数范围的内容，必须引用知识库里的具体片段ID，否则这条回答会被标记为“低置信度”并退回重写。

这个机制的难点不在RAG本身，而在于“知识库片段的可信度管理”。不同来源的文档对同一个问题可能有冲突：某个老工程师的笔记说“Buck输入电容至少10µF”，某款芯片数据手册的推荐电路只给了2.2µF。这种冲突不应该靠RAG相似度排序悄悄带过，而要通过版本号和文档类型给每条知识做优先级权重。我在实践里给每条片段打了三级标签：规格书为最高可信级别、应用笔记为次高、论坛帖子和内部笔记为最低。模型在综合时如果发现低可信级别知识和高端级别知识冲突，必须显式报告而不是掩盖。

3.2 第二层：计算与真实器件库工具调用

第二层解决的是数值真实性问题。在这一层，我把所有公式都从模型提示词里剥离，放进独立的计算工具。模型的职责是识别参数并传给工具，而不是直接算答案。举一个真实例子：Buck电感计算需要知道开关频率、纹波率、输入输出电压。模型只需要把这些参数填进工具调用接口，工具会返回一个标准电感值，并把峰值电流、纹波占比一并算好。

# 工具返回值示例 { "status": "ok", "unit_system": "SI", "standard_value": 6.8e-6, "peak_current": 2.68, "calc_ripple_ratio": 0.31 }

除了公式，器件选型也必须走真实器件库。我把本地维护的器件库（包含型号、耐压、电流、封装、ESR、热阻、库存状态）做成检索接口，模型的选型结果必须落在这个接口返回的型号集合里。如果模型报出的型号在库里查不到，编排层直接判定“不存在”，不让它进入BOM。这一层把最常见的“凭空捏造型号”问题彻底堵死了。

3.3 第三层：规则引擎对物理常识做硬校验

第三层是规则引擎，专门拦截那些“数值对但物理上荒谬”的结果。RAG和器件库能拦型号问题，但拦不住设计参数本身违反物理规律——比如模型给一个耐压100V的Boost拓扑选了60V的MOSFET，或者在1A负载下选了一个热阻高达200°C/W的LDO。这类错误靠查库很难发现，因为器件库里有这个型号，参数也真实存在，只是组合不合理。

我的做法是把电源设计中的硬性物理规则写成可执行的校验函数。规则引擎的每条rule都带触发条件和拒绝理由，比如：

• 开关管电压应力不得低于输入电压与尖峰余量之和；
• 电感饱和电流必须大于最大峰值电流的1.2倍；
• 输出电容数量必须满足纹波电压和瞬态响应双重要求；
• 反馈环路补偿的穿越频率必须小于开关频率的1/10。

如果模型给出的参数不满足这些规则，编排层会拒绝该方案并要求设计Agent重新给参数，同时把违规原因写进调试日志。这个日志非常有用，我后来根据日志反向优化了很多Prompt模板，发现许多“模型想当然”的设计都被规则拦截在摇篮里。

3.4 第四层：审查Agent与自洽性复算

第四层是针对“整份方案的自洽性”做审查。前三层都是在单个点上拦截，但幻觉有时会以“组合错误”的方式出现：电感值、电容值、环路参数单看都对，组合起来却在负载阶跃下振荡。我为此加了一个审查Agent，单独调用同一个Deepseek模型，用另一套指令去质疑设计Agent的产出。它被要求“假设前一份方案是同行提交的，你要挑出所有毛病”，并且必须输出三类结论：明确的错误、可疑但需要人工确认的地方、没有问题的部分。

除了人工思路的交叉审查，我还会让结果走一次“自洽性复算”：把设计Agent产出的参数重新喂给计算工具，复算纹波、效率、环路相位裕度，看看这些指标是否在目标范围内。如果复算结果和设计Agent声称的指标对不上，说明过程中有信息遗失或偷换概念，必须回退。这两个动作叠加之后，方案的最终通过率明显提高，尤其是那种“单个参数都对、组合起来却不对”的复合错误，被复算机制抓住了不少。

4. 从“需求一句话”到“原理图草图”，Agent的完整工作流

4.1 需求解析阶段：把模糊指标转成结构化参数

实际做智能体工作流，最容易被忽略的是第一步。用户说“我要做一个12V转5V、2A的电源，纹波尽量小”，这句话里有大量隐藏信息需要澄清：输入电压范围是12V固定还是9~18V？纹波“小”是指多少mV？效率有没有要求？成本敏感还是尺寸敏感？如果直接拿这句话去生成方案，后面每一步都会建立在沙子上。

所以在Deepseek Harness里，需求解析是一个独立的Agent子任务。它会输出一份JSON结构化参数，包含输入电压范围、输出电压、最大负载电流、纹波目标、效率目标、环境温度、PCB面积约束、EMI要求等字段。

{ "vin_min": 9.0, "vin_max": 18.0, "vout": 5.0, "iout_max": 2.0, "ripple_target_mv": 20.0, "efficiency_target_pct": 88.0, "ambient_temp_c": 60.0, "pcb_area_mm2": 400.0, "emi_requirement": "CISPR25_Class3" }

对缺失的字段，它不会瞎猜，而是通过编排层生成追问问题列表，让用户逐项确认。只有当关键指标全部明确，工作流才会继续往下走。这一步我吃过亏：最初为了端到端省事，跳过了澄清环节，结果各个阶段的数据一路错下去，最后报告生成出来，用户说“我意思是宽电压输入，你按固定输入算了”。从此以后，需求解析成了硬性前置关卡。

4.2 拓扑选型与器件初筛

参数解析完成后，第二步是拓扑选型。这一步我把规则引擎放到了前面：根据输入输出电压关系自动排除不可能拓扑——输入低于输出就不能用Buck，输入总是高于输出就不能用Boost，输入输出范围重叠才考虑Buck-Boost或SEPIC。规则跑完之后，Deepseek模型再做风格化推荐，并结合成本、复杂度、EMI特性给出三套候选方案。

器件初筛是在拓扑确定后进行的。系统会先从器件库拉出满足电压、电流、封装、温度范围的候选集合，按导通电阻或静态电流排序，再让模型结合成本和供货情况给出推荐。这里有个细节：器件库的查询条件里，电压、电流范围本身就是过滤条件，模型无法推荐超出范围的型号，这是物理约束在源头生效。也就是说，模型即使想犯错，也没有可犯错的素材。

4.3 参数计算与验证器回写

器件初筛确定后，进入参数计算环节。这一环节是全流程最核心的部分，我强烈建议把“计算”彻底从模型生成中剥离。Deepseek只负责把设计目标、拓扑、器件型号、输入条件装配成一条工具调用请求，实际计算由SymPy和数值计算库完成。举例来说，Buck输出电感的计算会返回标准电感选型值和峰值电流值；输出电容的计算会返回满足纹波需求的电容容值和耐压建议；环路补偿计算会返回RC网络参数。工具随后把结果回写到编排层的状态对象中，所有后续流程只能使用工具回写的结果，不能再使用模型对话里的数字。

这个“回写”设计可以防住一类很隐蔽的幻觉：模型在中间步骤说出的数字和最终报告里的数字不一致。只要最终报告一律从状态对象取数，这类不一致就不可能发生。我见过太多对话式工具出现“前面说电感6.8µH，后面表格里却写成10µH”的情况，根本原因就是文本里的数字没有被结构化地同步。

4.4 输出物与人工复核界面

最后一步是生成输出物。我目前的输出物分为三种：一份面向工程师的设计说明文档，包含拓扑选择理由、器件选型表、关键参数计算过程；一份BOM清单，带物料编号、厂商建议、封装和价格估算；一份原理图草图，用SVG生成，标注关键网络和元件位号。

需要特别说明的是，这套系统绝不是一个完全自动化的替代方案。我的定位是“可交互的设计副驾”，所以最后一定要留一个人工复核窗口。审核界面上每条关键结论旁边都带一个“证据来源”按钮，点开可以看到这条结论引自哪份数据手册、哪条应用笔记、哪一个计算工具。人工确认后再导出正式设计。这一步既是防住了最后一道幻觉余漏，也让工程师逐步建立对系统的信任。毕竟，再好的防幻觉机制也不可能做到100%，人工复核不是流程的负担，而是可信度的压舱石。

5. 实测踩坑：五个真实翻车记录与修复过程

5.1 翻车一：模型“记得”的ESR值不可信

最典型的翻车发生在我刚把电容ESR查询接口接进来之前。当时模型给了一颗1200µF固态电容的选型建议，并声称该型号ESR只有12mΩ，我根据这个值估算的输出纹波是15mV，非常漂亮。但后来手工查了官方手册，实际ESR标称是35mΩ，纹波实际是43mV，整个结论全部推翻。根因很简单：模型不是数据库，它“记得”的是训练语料里出现过的高频信息，而高频信息未必和当前这颗料相关。

修复方法：从那一刻起，所有ESR、耐压、额定电流、热阻这些参数一律通过器件库检索接口实时获取。凡是接口返回不了的，就返回一个“该参数未知”，也不允许模型用自己的记忆补全。这条规则看起来简单，但执行成本很高，因为要持续对抗模型“顺手补齐缺省数据”的倾向。每次发现模型又在“记忆补全”，我都会把它当成一次bug来处理，而不是当作文本润色。

5.2 翻车二：知识库文档版本冲突导致自相矛盾

第二个坑出现在知识库上线后的第二周。某款电源控制芯片有两代版本，一代的反馈补偿推荐电路用了比较大的电容，二代的推荐值缩小了一个数量级。RAG检索时，两个版本的应用笔记都被召回，Deepseek在生成方案时直接综合了两个版本的参数，给出一个中间值，结果既不适用于一代也不适用于二代，逻辑上是自相矛盾。

修复方法：给知识库每条片段增加“适用器件版本”字段，检索时把器件版本作为硬过滤条件而不是相似度排序的一个权重。此外增加了冲突检测规则：如果同一设计目标命中了多条知识且版本不同，禁止自动综合，必须在报告里列出冲突并转人工。从此以后，这类矛盾从“悄悄发生”变成了“显式暴露”，在人工复核时反而成了系统可信度的一部分。后来我甚至主动在知识库里埋了几组不同版本的测试数据，用来验证冲突检测是否真的在正常工作。

5.3 翻车三：公式对、单位错，看似无害但会炸

第三个坑属于单位解析问题。某个环路补偿推导中，模型给出了零点频率公式1/(2πRC)，代入的C值看起来是0.1，单位却写的是“uF”而实际电容是“nF”。数字完全一样，公式也对，但单位差1000倍，最终补偿网络完全失效。这种问题最阴险：对话里根本看不出错，除非你从头到尾做一次单位核算。

修复方法：我在编排层加了一个“单位感知的数值解析器”。所有参与计算的参数都必须携带单位，工具内部统一换算到SI制后再执行公式；计算完成后再把结果换算回常规工程单位。解析器还会检查公式两端的量纲是否匹配，比如计算电阻分压时，左边是电压，右边是电流乘电阻，量纲必须一致，不匹配直接中止并报错。这个解析器成了整个防幻觉体系中性价比最高的组件之一，一套代码覆盖了所有公式计算场景。

5.4 翻车四：审查Agent被同一个幻觉带跑

第四个坑最打击人：我让审查Agent去审设计Agent的产出，结果两个Agent用同一个模型，在同一个错误方向上的自信程度完全一致。设计Agent说“某电感饱和电流为3A”，审查Agent没有质疑，反而顺着这个错误点去分析饱和裕量是否够，等于确认了错误前提。交叉审查如果不能独立获取外部证据，就只是同一个大脑在自言自语，这是我在这个项目里最重要的教训之一。

修复方法：审查Agent必须调用独立的工具接口来获取数据，不允许仅凭推理来“认为”某个数值是正确的。我在审查流程里加了硬规则：凡涉及具体数值的参数，审查Agent必须调用器件库检索或计算工具进行复验，如果工具的结果与设计Agent一致才通过，否则强制标记异常。这也是“防幻觉”从提示词层面真正转到了工具层面的一个标志性改动。从那以后，审查Agent的质疑质量提升非常明显，它终于能发现一些真正可疑的地方了。

5.5 翻车五：防幻觉太狠，模型拒绝回答可解问题

最后一个坑来自矫枉过正。在加入过多校验后，模型开始频繁拒绝回答，比如“该参数无法验证，建议人工确认”，连一些完全可以由基础物理知识推出的、已经进入知识库的内容也不肯回答。整个智能体的可用性大打折扣，用户得不到任何输出，比给一个错误答案更让人沮丧。

修复方法：我把防幻觉机制分成“硬拦截”和“软警告”两档。对必须外部证据支持的关键参数，采用硬拦截，拿不到证据就拒绝；对可以由通用知识合理推导的设计建议，采用软警告，允许模型输出但标记置信度，并提示用户需要二次确认。经过这个调整，系统的响应率和准确率达到一个可用的平衡点。这个平衡点的位置肯定不会一劳永逸，但至少给了我一个可以持续调优的旋钮，而不是一个只有0和1的开关。

6. 这套架构的复用边界与后续扩展思路

6.1 迁移信号完整性与热设计Agent的可行性

做完电源设计这个场景，我明显感觉到这套架构不只能用在电源域。信号完整性的阻抗匹配计算、热设计里的散热器选型和温升估算，底层逻辑是相通的：领域知识库 + 公式工具 + 器件库 + 物理规则校验，这正是防幻觉架构最擅长解决的“高精度工程决策”问题。迁移时最需要做的工作有两块：一是把规则引擎的物理规则换成目标领域的规则，二是把器件库替换成目标领域的物料库。工程上大概能用三到四周完成一个垂直Agent的雏形，主要时间花在整理知识库的切片和规则库的沉淀上。

6.2 可以低成本复用的组件清单

复盘这个项目，有几个组件是几乎可以原样复用的，我列一个清单方便大家参考。

这套清单最大的价值在于：防幻觉这件事的技术投入被一次性做进了架构里，后续切换领域时，不需要重新发明轮子。我甚至觉得，单是“单位感知解析器”和“溯源约束模板”这两个组件，就已经值回整个项目的开发成本，因为它们解决的是所有工程类Agent都会遇到的通病。

6.3 离规模化落地还差什么

目前这套架构还有一个短板：端到端流程的人工介入比例还偏高，尤其是需求解析阶段和人工复核阶段。把需求解析做成一个带澄清式多轮对话的专用交互界面，是下一步值得投入的方向；人工复核阶段则可以考虑引入更多客观仿真数据，例如把设计方案自动导出成仿真网表，在真正打样之前先用仿真工具验证环路稳定性。如果这两块补齐，整个系统的自动化率会有明显提升。

最后分享一个最直接的体会：如果让我把整个项目重做一遍，我会在第一天就把单位解析器和器件库接口接上，而不是先花两周调提示词。这两个组件带来的收益，远比任何“让模型更聪明”的优化都大。防幻觉智能体本质上是工程问题，不是模型问题。