企业官网建设流程全解析

我一直在做电源相关的硬件设计，这两年深度用大模型辅助设计之后，发现一个很尴尬的问题：模型给出的方案，听起来头头是道，但落到具体元器件参数、环路补偿、热计算上，经常一本正经地编数据。有一回我让模型推荐一颗60V输入的Buck控制器，它直接给我造了个型号，封装、引脚、限流值全都对得上，唯独这个型号的芯片根本不存在。后来我围绕Deepseek Harness搭了一套电源硬件设计agent，核心目标就一个——防幻觉。这篇文章把我实际搭建过程中验证过的架构、机制和踩坑记录完整写出来，希望能给正在做AI辅助硬件设计的同行一些参考。

1. 电源硬件设计场景里，AI幻觉是怎么一步步坑人的

1.1 幻觉不是“乱说”，而是“自信地编造”：先看清三种典型表现

做硬件设计和做文案不一样，文案写错一个典故无伤大雅，电源设计里一个参数错了，板子打样回来就是冒烟、炸机、烧负载。我实际用LLM辅助设计时，遇到过的坑基本可以归成三类。

第一类是器件编造。模型会非常自然地编出不存在的元器件型号，或者把两个相似型号的参数拼接在一起。比如让它推荐“输入48V、输出12V/10A、支持同步整流的Buck方案”，它会给一个看似合理的型号，我第一眼看不出问题，去原厂官网一搜，查无此物。这种幻觉最难防，因为型号命名规则本身就容易被模型“学会”，它完全可以推演出一个符合命名规范但实际不存在的型号。

第二类是数值计算错误。LLM本质上是token预测模型，不是计算器。让它计算“输入12V、输出3.3V、负载2A、开关频率500kHz下的电感纹波电流”，它能给出公式，但代入数值的时候偶尔会把数量级算错。更隐蔽的是，它会“记住”一个典型值然后生搬硬套，不看具体条件。计算这类东西，必须外挂真正的计算程序，不能让模型自己心算。

第三类是约束遗忘。电源设计里约束条件非常多：输入电压范围、输出纹波、效率目标、温升上限、EMC要求、封装尺寸、成本上限。模型在回答前几个问题时往往能记住约束，但对话拉长、上下文变多之后，它会逐渐“忘掉”早期给的条件，最后给出的方案可能在某个边界条件上完全不可用。比如我明确说过“高度不能超过5mm”，它后面推荐了一颗高度10mm的电解电容。

这三类幻觉的共同点是：模型输出的置信度非常高，结构非常完整，甚至推理过程看起来都对，但结论是不可信的。这才是硬件场景下AI辅助设计的最大风险——不是它不会答，而是它“不会让你看出它哪里不会”。

1.2 为什么普通RAG和三两句提示词根本压不住硬件幻觉

很多团队处理LLM幻觉的第一反应是上RAG（检索增强生成），把规格书、设计手册切块灌进向量库，让模型回答前先检索。这个思路在知识问答场景很好用，但在电源硬件设计场景，我实际测下来效果有限，原因有三点。

第一，规格书是参数密集型的表格化文本，切块之后语义碎片化严重。一段关于“绝对最大额定值”的表格被切进向量库，检索出来之后模型能读到表，但你没法保证它引用了正确的列。更麻烦的是，规格书里大量数据是图表曲线，比如“效率vs负载电流”曲线、“环路增益vs频率”曲线，这些是PDF里的图片，文本切块根本检索不到。

第二，大多数幻觉问题不是“不知道”，而是“算不对”和“记不全”。你问它“TPS5430的开关频率是多少”，它检索到规格书确实能答对；但你说“帮我用TPS5430设计一个12V转5V/2A的电源”，它需要在约束下做计算、做选型权衡、做热校核，这已经不是检索能解决的问题了。RAG只能解决“知识有没有”，解决不了“计算对不对”和“约束守没守”。

第三，硬件设计的错误成本太高。软件场景模型输出一段有bug的代码，跑一下测试就暴露了；硬件场景一个错误参数流到原理图，需要打样、焊接、上电测试才能暴露，一轮迭代就是一周时间和几百块板费。所以防幻觉不能靠“概率上大多数时候对”，要的是“每一个关键输出都有据可查、可复核”。

我自己试过在提示词里写“请确保你的回答经过计算验证”、“不要编造器件型号”，效果非常有限。模型不会因为你说“不要编”就不编，它只会更隐蔽地编。真正有效的做法，是把设计流程拆开，让模型只做它擅长的部分（语义理解、方案生成、参数传递），把计算、检索、规则校验这些“确定性工作”全部用工具接管——这就是我搭这套agent的核心思路。

2. Deepseek Harness在agent架构里的真实位置：不是外壳，是控制面

2.1 从“裸调模型”到“harness化agent”，中间差了一个“控制面”

最早我写AI辅助硬件设计的脚本，就是“裸调模型”——把设计需求拼进prompt，调用API拿输出，解析文本，人肉眼判断。这种方式的优点是没有中间层，缺点是所有可靠性都压在模型身上，幻觉没有任何拦截机制。

后来社区里逐渐流行“Agent Harness”这个概念。我理解Harness的定位，类比一下：它就像汽车里的方向盘和刹车系统，而不只是车身外壳。外壳只负责把发动机（模型）包起来，方向盘和刹车负责让驾驶员（开发者和规则）在行车过程中随时干预方向。一个harness化的agent，核心是给模型套了一个“可编程的执行控制面”，让开发者可以规定模型在什么条件下调用什么工具、工具返回什么结果、模型在什么情况下必须放弃自己的“主观判断”而接受工具结果。

我为什么用Deepseek Harness这个词，而不是笼统说“agent框架”？因为在我接触的社区实践里，harness和一般agent框架有几个明显区别：它更强调策略的可编程性，把“模型该做什么、工具该做什么、什么情况下听谁的”这些规则显式区分开。这很对我的胃口——做硬件的人本来就习惯“程序负责确定性计算，人负责判断”，harness恰好把AI系统也掰成了这个思路。

2.2 Harness的三层结构：模型能力圈、工具注册表、执行策略

我实际搭建时，把Deepseek Harness理解成三层结构。

第一层是模型能力圈。明确告诉harness：当前使用的模型（Deepseek系列，我后面会讲为什么选它）擅长做什么、不擅长做什么。比如擅长理解自然语言设计需求、擅长生成拓扑方案描述、擅长解释设计选项的取舍逻辑；不擅长数值计算、不擅长记住最新元器件型号、不擅长判断一个器件是否停产能。

第二层是工具注册表。把电源设计过程中需要用到的确定性能力全部封装成工具，注册进harness。我第一批注册的工具包括：符号化数值计算器（用表达式计算代替心算）、元器件数据库查询接口（只在本地数据库里检索，数据库里没有的型号直接判“不存在”）、规格书向量检索引擎（检索到的内容必须带来源标记）、设计规则检查器（输入约束和参数，输出是否违反规则的结论）、仿真结果解析接口（解析LTspice等工具的输出文件提取关键指标）。每个工具都有明确的输入输出schema，harness负责把模型的输出转化为符合schema的调用。

第三层是执行策略。这一层定义“在什么条件下必须调用什么工具”。比如：只要模型输出中包含“纹波电流”“电感值”“反馈电阻”这些计算类参数，harness强制要求先交给计算器执行；只要模型输出中提到了一个元器件型号，harness强制要求先查询本地数据库，查不到的就标记为“未验证型号”；只要最终方案生成，harness必须跑一遍设计规则检查，全部通过才能输出。

这三层合起来，就是一个完整的控制面。模型只负责“语义”那部分，控制面负责“事实”那部分。很多人搭agent容易犯的错是只想“增强模型的能力”，给模型挂一堆工具让它自己挑；而harness的思路反过来——告诉模型哪些事你绝对不能直接回答，必须先交给工具。对防幻觉来说，后一种思路要可靠得多。

2.3 底座模型为什么选Deepseek：内网部署、成本与文本能力的平衡

选择Deepseek作为底座，我综合考虑了三个点，这些也是在社区里反复讨论最多的话题。

首先是内网部署的可行性。硬件设计涉及很多未公开的项目信息，我不能把完整设计需求丢给外部服务，需要在内网服务器上自托管模型推理。Deepseek的权重开放、显存需求相对可控，在单机多卡环境下可以跑起来跑得动，这在工业设计场景几乎是刚需。

其次是成本。硬件设计验证是高频迭代场景，一天可能调用上千次，如果全走外部API，费用是笔不小的开销。自托管后推理成本主要就是电费和硬件折旧，设计团队内部随便跑不心疼，大家才愿意真的把它用到日常流程里，而不是当玩具偶尔玩一次。

第三是文本能力。电源设计辅助涉及大量技术文档理解、拓扑方案对比、设计说明生成，这些恰好是Deepseek文本能力的强项。实际用下来，它对“输入12-36V、输出5V/5A”这类结构的理解很准确，能生成结构清晰的设计说明文档，这对后续把方案同步给结构工程师、PCB工程师很有价值。

不过我也得说句实话：Deepseek不是万能的，它对最新器件的知识覆盖有滞后性，这也是为什么我强调必须用本地数据库和规格书检索来兜底——模型靠不住的地方，正是harness和工具发挥作用的地方。底座模型负责scope发散和语义理解，工具负责事实收敛，两者配合才能做防幻觉的架构。

3. 防幻觉电源设计agent的分层架构：六个子系统如何协同

3.1 从自然语言需求到可验证设计参数，中间要过六个子系统

整体架构我按功能划分为六个子系统，它们之间的关系是串并行混合的：需求解析、知识检索、数值计算并行推进，规则校验最后统一把关。

第一个是需求解析子系统。入口是自然语言的设计需求，比如“输入12V到24V，输出5V，最大负载3A，纹波不超过50mV，高度不超过8mm，成本尽量低”。这一层由模型完成语义解析，输出结构化的设计约束对象，包括输入范围、输出规格、环境约束（温升、高度、成本权重）。为了避免模型漏掉约束，我在提示词里设计了强制模板：必须输出“已识别约束清单”，并列出哪些是硬约束、哪些是软约束。

第二个是知识检索子系统。根据约束和候选拓扑，去检索规格书向量库、设计指南、参考设计文档。检索结果统一带上“来源文档名+页码+原文片段”的引用信息。这一层不直接给出答案，只提供素材。

第三个是数值计算子系统。这是一个符号计算器工具，接收参数公式和数值，返回计算结果。所有电感纹波、环路补偿、热阻计算、效率估算都在这里完成。模型永远不会直接输出计算结果——它只能“提出计算请求”，由计算器返回结果。

第四个是元器件选型子系统。它对接两个数据源：本地元器件数据库（包含已验证型号、参数、封装、货源、价格）和厂商规格书解析结果。选型工具内部实现了多目标约束匹配算法，在数据库里筛选满足约束的候选列表，按价格/交期/性能排序返回Top 5。

第五个是设计规则检查子系统。它把电源设计规则沉淀成可执行的规则引擎。规则包括：输入输出压差是否在控制器最低压差之上、电感饱和电流是否大于峰值电流的1.3倍、反馈电阻分压是否落在参考电压允许范围、MOS管栅极驱动电压是否足够、热阻条件下节点温度是否超限。规则不固化在模型提示词里，全部是代码实现。

第六个是方案生成与溯源子系统。它把前五个系统的输出汇总，生成最终设计说明，每一段结论都标注依据来源（计算记录、数据编号、规格书引用）。如果某个结论没有来源，这一层直接拒绝输出。

这六个子系统协同工作后，模型真正的自由度被大幅压缩：它只在“需求理解”和“方案组织”这两个环节有发挥空间，其余环节全部走确定性工具。这就是“防幻觉”架构的本质——不是提高模型说真话的概率，而是让它没有说假话的机会。

3.2 知识层细节：元器件数据库和规格书向量库怎么建，防“编型号”的关键

“编型号”是硬件场景最典型的幻觉，我在这块投入的精力最多，建了两个库。

第一个是本地元器件数据库。这是一个结构化数据库，表结构包含：型号主键、厂商、类别（电阻/电容/电感/芯片）、关键参数JSON字段、封装、温度等级、货源状态、参考单价、最后验证日期。关键点是“最后验证日期”这个字段——所有型号必须经过人工或厂商渠道确认后写入，未经确认的字段默认置空。查询工具的逻辑很简单：模型请求选型时，工具在数据库里做SQL匹配，返回候选项。如果数据库查不到候选，就如实返回“没有符合约束的已验证型号”，绝不让模型“推测一个试试”。这个逻辑听起来很基础，但恰恰是很多agent实现忽略的——模型一旦发现工具查不到，会试图“帮忙”编一个，必须从harness策略层直接禁止。

第二个是规格书向量库。我先把常用电源芯片、MOS管、电感厂商的规格书PDF转成结构化文本，再做分块和向量化。分块策略试过几种，最终用的是“按章节语义切块+保留下文表格为Markdown”的方案。特别注意：规格书里的绝对值表格（Absolute Maximum Ratings）、推荐工作条件表（Recommended Operating Conditions）必须作为独立块保留，不能被切碎。向量检索时，模型返回的引用要能定位到具体文档和原始块文本，方便工程师复核。

这两个库解决的核心问题是：把“模型记住了什么”替换成“系统检索到什么”。模型可以继续“记得”一个型号，但它提出型号后，harness会立刻触发数据库查询，查不到就直接拦截，并替换成数据库真实存在的候选。用设计术语说，这是把“开环输出”变成了“闭环反馈”。

3.3 计算层细节：符号计算工具怎么设计，数量级不再出错

数值计算工具我实现得很谨慎，经历了一个从“让模型直接调用代码”到“符号表达式结构化传递”的演进。

一开始我给的方案是：模型输出Python代码，工具执行代码返回结果。这个方法可行，但有一个隐患——模型写代码时偶尔会写出逻辑错误代码，比如把除法写成乘法，工具执行了但结果依旧错。后来我改成符号表达式方案：工具定义了一批标准计算函数，包括电感计算（calc_inductor）、纹波计算（calc_ripple_current）、反馈分压计算（calc_feedback_divider）、热阻计算（calc_junction_temp）、功率损耗估算（calc_power_loss）。模型的任务不是写代码，而是调用这些函数并传入参数。

以Buck电感计算为例，工具函数内部固定实现公式：

def calc_inductor_ripple(Vin, Vout, fsw, L): # D = Vout / Vin D = Vout / Vin # delta_I_L = (Vin - Vout) * D / (fsw * L) di = (Vin - Vout) * D / (fsw * L) return di

模型只需要明确告诉harness“这个方案用了L=10uH的功率电感”，harness就会把它转换成一个计算请求，把L=10uH, Vin=24, Vout=5, fsw=500k传给计算工具，返回值被填充回方案里。整个链路中模型没有“算数”的机会，它只负责“选公式对应场景”。这个模式上线后，数值数量级的错误几乎归零了——因为公式的实现是固定且经过单测验证的，模型想错都不给它机会。

3.4 规则约束层细节：一组触发示例（压差、电感饱和、热校核）

设计规则检查子系统的价值不在于规则多复杂，而在于规则“必须被执行”。我在harness策略里设定了触发器：方案生成后，自动提取关键参数集，送入规则引擎检查。下面是我最早跑通的几条规则，每条都是实际设计场景里翻过车的。

压差检查：非同步Buck控制器的最大占空比有限制，输入接近输出时压差不足可能无法稳定调节。规则引擎根据控制器的最小压差参数（从数据库读取），判断设计输入范围内的所有极端点是否满足。如果某个边界点不满足，返回“违反规则R-102：最小压差不足”。

电感饱和检查：根据计算的峰值电流（考虑纹波），检查所选电感的饱和电流是否大于峰值电流的1.3倍。规则引擎调用数据库里的电感饱和电流参数，和计算层返回的峰值电流做比较，不满足直接弹出具名报告。

热校核：根据MOS管的Rds_on、开关损耗估算、热阻和最高环境温度，计算结温。超过规格书最大结温就直接报“违反规则R-203：结温超限”。

反馈电阻精度检查：反馈分压电阻的E系列取值是否满足输出电压精度要求，实际取标准阻值后的输出电压偏移是否在允许偏差内。

这些规则全部以代码实现，不依赖模型判断。每次输出方案前，harness强制跑一遍规则引擎，把“检查记录”写入方案的附录。这相当于给模型套了一层“带硬约束的编译器”，幻觉在输出前就会被拦截。

4. 三道防幻觉闸门与负样本回流：让模型“不敢编、编了也能被抓住”

4.1 第一道闸门：工具优先策略，模型只做意图理解和参数传递

第一道闸门是把模型和工具之间沟通方式设计成“强制工具优先”。之前我直接让模型自由发挥，“可以用工具也可以自己回答”，结果模型为了省事经常跳过工具直接编。后来改成harness策略：凡是涉及型号确认、数值计算、规则校验的操作，模型一律不允许自行直接输出，必须先发起工具调用。

实现方式是在提示词层面做“能力边界声明”，同时harness在解析层做强制拦截。比如模型输出中出现“此方案使用XX电感10uH”这样的句子，harness的正则和数据流解析器会识别“10uH”是待计算参数，自动触发计算工具；识别“XX电感”是元器件，自动触发数据库查询。如果模型没触发，harness直接拒绝该条输出，并返回“参数未验证”的错误信息要求模型重新走工具流程。

这套设计带来的好处很实际：模型渐渐学会了“先请求工具，再组织回答”，因为它发现只有走工具流程的输出才会被harness接受。这相当于用行为约束重塑了模型的工作习惯，比在prompt里哀求“请谨慎作答”有效得多。

4.2 第二道闸门：答案溯源与引用强制，每条结论都要有“出处页码”

第二道闸门是溯源强制。方案说明里不允许出现无源陈述。具体要求是：每个设计结论后面必须附带来源标识，来源可以是三类——计算记录（来自数值计算子系统的日志）、规格书引用（来自向量检索的文档ID和页码）、数据库记录（来自元器件库的主键）。

比如最终方案里写：“选择芯龙半导体XL4015作为降压控制器，原因是输入电压范围8-36V满足设计需求，最大输出电流5A满足3A负载裕量。”这句话里“8-36V”和“5A”必须各带一个数据库引用，harness检查到引用缺失会在方案输出前打回。这个机制一开始让方案生成变得有点“啰嗦”，但工程师拿到方案做复核时感受完全不一样——每条信息都能按图索骥，审核效率大幅提升。

实际落地时，我给harness增加了一个“溯源检查器”，它会扫描模型生成的文本，识别“参数断言”语句，然后检查参数是否在工具调用日志里出现过。如果参数在日志里找不到来源，就返回“未知来源参数清单”，要求模型重新生成。这套机制有效拦截了“模型自己知道的一些说法”——那些不知道从哪里冒出来的“常识”，没有出处就直接不给过。

4.3 第三道闸门：数值一致性校验

第三道闸门是最硬的一道：对关键参数做数学一致性校验。什么意思呢？就是不管模型怎么描述，也不管工具怎么计算，我再用独立的数学关系式验一遍。举个例子：

方案里说“输出5V/3A，纹波要求50mV，我选了L=22uH，Fsw=500kHz”。一致性校验器会根据Buck公式独立算一遍在一定占空比下电感电流纹波是多少，进而初步推断输出纹波的电容分量是否可能满足50mV。如果数学上根本不成立，不管模型的推理过程多“流畅”，直接判定“数值不一致”，方案打回。

这个校验器的价值在于：它不信任模型的话，也不完全信任工具的输出，而是用第三方的数学关系做交叉验证。相当于给整个回路加了一颗“裁判”，防止模型在语义层把参数“翻译”错。实际操作中，我遇到过好几次模型正确调用了计算工具，但在最终方案文本里却写了一个与计算结果不一致的数字（可能是复制错误、上下文污染），一致性校验把这类问题全部拦下来了。这是我认为防幻觉架构里最值得投入的部分。

4.4 反向机制：每次设计失败的负样本如何回流到规则库

防幻觉不止是“拦截”，还需要“记忆”。我把每次失败的案例沉淀成负样本，回流到规则引擎和提示词策略里，形成闭环。

具体做法：当一次设计被规则引擎打回或者被工程师在审核中发现问题时，系统自动生成一条“失败案例记录”，字段包括：失败原因类型（编型号/算错/约束疏忽/来源缺失）、触发场景、模型当时的输出片段、harness拦截的环节、人工复核结论。这些记录按周汇总，人工审视后提炼成新的规则或提示词约束。

比如早期出现过一次“反馈分压电阻选用了非标准E系列值”的问题，后来就沉淀成一条规则：所有电阻值必须从E24系列中选取，规则引擎增加check_series_value校验。又比如“源引用”机制的引入，就是因为多次发现模型会突然冒出一句没有任何来源支撑的经验值——失败案例一多，溯源检查器就上线了。

这个“失败回流”机制是我觉得很多AI项目做得不够的地方：大多数agent系统上线后就放养，出了问题改prompt，但结果朝令夕改越改越乱。负样本回流让系统具备“每次失败都是升级规则的机会”的自我迭代能力，规则库越用越完善，幻觉存活的空间越来越小。

5. 内网部署实录：模型推理、harness运行时与工具链的落地细节

5.1 部署拓扑：三个独立子系统一个也不能少

实际部署时我划了三层：模型推理层、harness运行时层、工具链层。

模型推理层是Deepseek系列的量化权重，跑在内网GPU服务器。我这边用的是两张卡的机器，量化后单并发推理速度可以满足一个五人硬件团队的日常调用。模型推理层暴露一个OpenAI兼容的API接口，harness运行时通过这个接口与模型通信，这样做的好处是将来换其他底座模型时harness不用动大手术。

harness运行时层是个独立服务，负责意图解析、工具调度、策略执行、溯源检查。它和模型推理层走的是两个独立服务，互不依赖。

工具链层更彻底——我把所有工具（数据库查询、符号计算、规则引擎、文档解析）全部封装成独立的本地服务，harness通过HTTP或本地中转调用。工具层与模型层完全隔离，意味着模型永远无法直接访问数据库，它最多能请求harness帮它查一次。所有工具的日志都持久化存储，方便溯源和排查。

这个三层隔离设计我认为是内网部署的关键：模型和工具永远不直接对话，一切请求都经过harness。模型面对的不是真实世界，而是harness为它构造的“受控视图”——这正好是防幻觉的另一道隐性屏障。

部署参数可以参考我整理的下表（实际根据需要调整）：

5.2 插件与skill的离线安装方式

社区里关于“harness插件”、“skill部署到内网服务器”讨论得很多，我实际踩过一轮之后总结出的经验是：先理清概念，再动手装。

我理解的插件是可复用的功能模块（接数据库、接计算器、接文档解析），skill更偏上层的“技能包”，通常是一套提示词策略+配套工具的绑定。在内网服务器上部署，最麻烦的是模型权重下载和依赖拉取，我的做法是先在一台能联网的机器上把权重文件、镜像、依赖包都下载好，打成离线包，用移动存储介质拷到内网服务器上。这一步据我所知是内网环境通用的做法。

装上之后重点在“注册”。插件的注册不只是把代码放进目录，还包括在harness配置中心登记能力描述和参数Schema。我吃过一个亏：插件装好了，但harness不知道这个插件是干什么的，模型也就永远不会调用它。后来我写能力描述时特意写得“功能动词+参数名词”的风格，比如“查询已验证元器件型号，入参是器件类别和电压/电流/封装等必填字段”，效果好了很多。

Skill的部署更讲究一点。我会把一个skill定义成一套“规则+工具绑定+示例对话”的包，装进去之后先跑一轮冒烟测试：给一个简单需求，看harness是不是按预期调度工具。skill部署不成功最常见的症状是模型根本不触发工具调用，这时候要检查的不是skill本身，而是harness策略层是不是把相关工具的优先级放在“模型自主回答”之前了。

5.3 一个完整的设计请求走查：看每一条防幻觉机制如何被触发

为了直观说明这套系统的运转，我完整走一个真实例子的简化版：“设计一个输入12V到24V、输出5V/3A的非同步Buck电源，纹波小于50mV，高度不超过8mm。”

第一步，需求解析。模型输出结构化约束：Vin_min=12V, Vin_max=24V, Vout=5V, Iout=3A, ripple<50mV, height<8mm，并在“已识别约束”清单里标记“高度不超过8mm”为硬约束。

第二步，知识检索与器件数据库查询并行触发。模型提出“使用XL4015”的假设，harness立即查元器件数据库，返回XL4015的验证记录和关键参数；同时规格书向量库检索到XL4015数据手册的推荐电路章节，引用ID和页码被记入溯源日志。

第三步，数值计算。模型基于XL4015参数提出“开关频率180kHz，电感47uH”的假设，harness把这些值提交给计算工具，得到满载下的电感纹波电流、输出电容纹波电压估计。计算结果返回后，harness自动与“50mV”约束比对——如果比不过，直接提示方案不可行。

第四步，规则检查。压差、纹波、电感应力和热校核四条规则全部跑完，规则引擎输出一份“检查记录”，我要求它必须在记录末尾声明：此方案在所有约束边界点均未触发违反规则。出现“违反”时harness禁止输出完整方案，只输出失败原因。

第五步，生成方案与溯源。模型基于所有工具返回的数据组织最终输出，溯源检查器扫描全文，确认每个参数都有来源标识，没有来源的参数被剥离或要求重新生成。最终交付的是一份“带引用、带计算记录、带规则检查记录”的完整方案。

这个案例说明，防幻觉不是某一个单点机制，而是一条处处设防的链路。模型只提供“假设”，所有“验证”由工具和规则完成，最后还有一道溯源审计兜底。

6. 实测对比与避坑清单：从三组测试看效果

6.1 三组对照：有的放矢地验证“防幻觉”是否真的有效

我做了三组实测，分别验证器件真伪、参数正确性和约束完整性的提升效果。

第一组是型号真伪测试：问系统“推荐一颗输入电压能到60V的同步Buck控制器，电流能力5A”。裸调模型时，系统会给出一个看起来像模像样的型号；接入harness后，元器件数据库查无此型号或者数据库识别到该型号未经验证时，输出会变成：“数据库中没有符合输入60V且已验证的同步Buck控制器，建议放宽输入限制或提供已验证型号清单。”这个才是硬件工程师真正需要听的话——系统告诉你的不是“有”，而是“真有”。

第二组是参数正确性测试：给一个固定拓扑和参数，要求计算电感纹波电流。裸调模型偶尔算错数量级；harness化后，所有计算都经过符号计算工具，我抽查了20组不同参数组合的计算结果，全部与用计算器人工复核的值一致。这组测试验证的是“工具接管计算”的有效性。

第三组是约束保持测试：在一段长达十轮的设计对话中，持续追问各种替代方案，中间偶尔穿插一句“高度最好控制在8mm以内”。裸调模型在第7轮左右开始忽略高度约束，推荐的方案部分超过8mm；harness化系统因为约束在需求解析时已经结构化为“硬约束”，每一轮回到规则引擎都会重新校验，超高的方案会被直接拦截。这组测试验证了“规则引擎兜底”的价值。

三组测试结果并没有让我意外——因为架构设计的时候就已经预判到了这几类问题，但真正让我满意的是系统的稳定性：连续跑了一天，没出现一次“漏网幻觉”。这背后不是模型变聪明了，而是架构把“犯错的空间”压缩到了几乎没有。

6.2 踩坑与排查：部署和调参阶段的典型问题清单

结合搜索结果里大家反复问的那些问题，我在部署和调参过程中也遇到了不少，挑典型的列个表：

6.3 给团队的三个启动建议：从最小闭环做起

最后给想复刻这套架构的团队三个建议。

第一个建议是不要一开始就追求全流程自动化。我先做的是“设计参数复核”这一个最小闭环：模型输出方案 → 计算工具验算关键参数 → 规则引擎查硬约束 → 溯源检查。跑通这一个闭环，防幻觉的核心价值已经体现出来了，后面再逐步加知识检索、加器件库、加文档生成。一次铺开六个子系统，排查问题会非常痛苦。

第二个建议是把数据资产积累当成第一优先级。元器件数据库和规格书向量库的构建需要持续投入，越早开始越好。每一次设计项目结束，把用到的型号、验证过的参数、踩过的坑都回流到库里，半年后这个库会成为团队最值钱的AI资产。没有数据资产的防幻觉架构只是空壳，模型再聪明没有可信的事实源也白搭。

第三个建议是保留人的复核环节。我对这套系统的定位是“高级辅助”，不是“自动驾驶”。方案虽然经过层层校验，但最终上原理图前一定要有资深工程师审核。系统负责拦截确定性错误，人负责判断经验性取舍，这个边界在部署时就应该写清楚，防止团队对系统产生过度信任。

我个人走完这一趟之后最大的感受是：防幻觉这件事，不管Agent的能力怎么演进，只要落到的领域是“错误代价极高”的硬件设计，就必须把关键环节交给确定性系统去兜底。模型负责发散，工具负责收敛，规则负责审计——把这三件事分开，你的agent离“可信”就不远了。最后再分享一个小细节：给harness写工具能力描述时，不要偷懒抄官方文档，一定结合你自己领域里真实的对话场景去写，写清楚“什么场景触发、参数怎么取、结果返回什么”，模型才真正知道怎么用。这个细节对最终防幻觉效果的影响，远比你想象的大。