去年年底，我们团队在做一个低功耗传感器节点的固件项目。硬件平台早就调通了，软件却卡在一个特别尴尬的地方：老同事调走了，把排查经验和历史坑位也一并带走了；新来的工程师光啃那本六百多页的芯片手册就啃了三天；而我作为项目负责人，光在群里回答“这个寄存器为什么写不进去”“DMA中断为啥一直进”这类问题，一周就回答了不下二十次。
痛定思痛之后，我决定给团队做一个真正的“AI研发中枢”：把芯片手册、历史排查记录、代码规范、测试经验统统喂给知识库，再用开源应用平台Dify把问答、代码审查、日志分析、测试报告生成这些动作串成标准流程。这套系统从搭建到现在跑了三个月，新同事上手时间明显缩短，重复性问题在群里被提问的次数也少了一大半。这篇文章就把从选型、建知识库、设计工作流到踩坑调优的完整过程写下来，给同样想在嵌入式团队里引入AI能力的读者做一个参考。
1. 嵌入式团队的AI需求，和互联网团队完全不一样
1.1 研发知识都散落在哪里：从芯片手册到群聊记录
做嵌入式的人应该都有同感：这个领域的“知识资产”极其分散，而且高度依赖经验。我大致盘点了一下我们团队日常要反复查阅的东西，至少有六类：
- 芯片数据手册与参考手册，少则两百页，多则上千页，寄存器描述、引脚复用表、电气特性、勘误表全是硬信息；
- SDK与驱动源码，厂商提供的例程、我们二次开发的BSP代码，里面藏着大量“只能意会”的写法；
- 内部经验文档，比如某型号ADC采样需要延时、某个外设复位后要等几个时钟周期才能配置，这类内容通常只存在于老员工的注释和邮件里；
- 历史Bug记录与排查报告，散落在缺陷管理系统、本地Markdown、甚至微信聊天记录里；
- 硬件设计注意事项，比如电源纹波对参考电压的影响、高速信号绕线规则，这部分往往和软件问题纠缠在一起；
- 测试用例与量产记录，尤其是低功耗项目的电流测试数据，每次回归都要重新对一遍。
这些知识有一个共同点：大部分是“非结构化”的，而且查起来极费时间。芯片手册是PDF，内部文档是Word或Markdown，聊天记录更是毫无索引可言。新同事遇到问题，第一反应是打开搜索引擎，第二反应是去群里喊人；而老手回答问题，靠的是脑子里那本“错题集”。
所以在引入AI之前，我先把问题定性清楚了：我们需要的不是一个“会聊天的大模型”，而是一个能把这些零散知识统一索引、按需检索、再按照嵌入式研发的逻辑把答案组织起来的系统。这个定位，决定了后面所有的技术选型。
1.2 为什么不是直接调大模型API，而是选Dify
一开始我也考虑过最朴素的方案：让团队每个人都直接去调大模型API，自己写提示词。但试了两周就放弃了。直接调API有几个绕不过去的问题：
- 没有知识库支撑，模型回答芯片寄存器和引脚号基本靠“编”，而嵌入式场景最不能容忍的就是编造；
- 没有工作流概念，日志分析要先提取关键字段、再查表、再给结论，这种多步骤逻辑每次都要在代码里重写；
- 没有统一入口，每个人写的脚本风格各异，今天能用明天就断，维护成本比写功能代码还高；
- 没有权限管理，源码片段、内部测试数据传给第三方接口，合规上心里没底。
Dify这类开源大模型应用开发平台，解决的正是上面这些问题。它把知识库（RAG）、提示词编排、工作流、模型管理、API发布这些能力做成了可视化配置，研发团队不需要从零搭一套AI基础设施。对我们嵌入式团队来说，最看重的是它支持私有化部署，知识资产不用出内网；同时工作流可以编排多步调用，正好匹配“排查问题不是一次问答就能结束”的现实。
1.3 Dify在嵌入式研发流程中的角色定位
用一句话概括：Dify在我们团队里充当的是“AI应用的中控层”，大模型是引擎，知识库是燃料，而Dify负责把两者按业务流程组装成一个个可对外服务的应用。我们的整体架构分三层：
- 底座层：向量数据库存切片后的知识，关系库存应用配置和会话记录；
- 应用层：Dify上创建了手册问答、代码审查、日志分析、测试报告生成等多个独立应用，每个应用有独立的提示词、知识库和模型参数；
- 接口层：通过API把应用接入企业微信群、缺陷系统、CI流水线，工程师在常用工具里直接触发。
这个定位很重要。它意味着我们做的是“平台”，不是“脚本”。后续每新增一个场景，只需要在平台上加一个应用，而不是重新写一套代码。
2. 第一步先把团队知识“喂”给机器：知识库建设的三个关键决策
2.1 哪些文档值得入库，哪些入库反而添乱
知识库不是越大越好，这个道理我们是在被“污染”之后才深刻体会到的。第一批我把能找到的所有资料都导了进去，结果模型回答质量直线下降：问A芯片的UART配置，它答出来的是B芯片的内容，因为两个型号的文档片段在向量空间里太接近，检索排序把不相关的文档也带出来了。
后来我们定了几条入库标准，执行之后效果立竿见影：
- 只入“确定性”文档：芯片参考手册、官方勘误表、经过评审的内部设计文档、已关闭的Bug记录，这些内容事实性强，适合检索；
- 不入“过程性”记录：早期草稿、会议纪要、未验证的讨论记录，这些内容本身就不确定，喂进去只会增加噪声；
- 过期版本单独隔离：同型号芯片的旧版手册、旧SDK例程，要么不入库，要么放到独立的“历史版本”知识库并做标记，避免新旧信息打架；
- 涉密内容坚决过滤：客户定制协议、量产价格、供应链信息，哪怕再有用也不入库。这个底线必须一开始就划清楚。
我建议嵌入式团队在做知识库规划时，先花半天和骨干工程师一起列一份“知识资产清单”，把文档按“事实型/经验型/过程型”分个类，再决定哪些入库、哪些不进。这一步省不掉，因为后续所有应用的质量都取决于知识库的纯净度。
2.2 切分策略：芯片手册的表格和代码段完全是两回事
RAG的检索质量，很大程度取决于文档怎么切分。Dify的知识库提供了分段长度和重叠窗口的设置，但不同内容要用不同策略，这是我在实践里反复调出来的经验。
芯片手册的寄存器描述、引脚复用表这类内容，特征是表格密集、信息高度压缩。如果按照默认的每段500个字符去切，一个寄存器表格很可能会被拦腰截断，表头丢了，下一行数据单独成为一个片段，检索时模型拿到的是残缺信息，根本没法准确回答。我现在的做法是：PDF转成Markdown后，在预处理阶段就按表格块为边界切分，一个完整表格尽量放在同一个分段里，分段长度设置得短一些，比如200到300个字符，重叠窗口设50到100个字符。这样做的目的是保住表格的完整性，宁可一个片段短一点，也不能让关键字段被切断。
代码和文档又不一样。SDK例程、驱动源码更适合按函数切分：一个函数一个片段，函数头的注释正好可以作为检索时的上下文描述。Dify本身不做代码级切分，我是先用脚本按函数边界把代码文件拆好，再作为独立文档导入，这样检索时命中“某个函数”比命中“某一大块代码”要精准得多。
还有一个非常容易被忽略的细节：索引标题和别名。嵌入式领域的同一个概念经常有多个叫法，比如“看门狗”“WDT”“IWDG”其实是同一个东西。我在清洗文档时给每个知识库维护了一个“同义词表”，并且把别名写进文档的标签字段里，大大提高了检索召回率。官方文档里写IWDG，老工程师习惯说看门狗，新同事问“狗咬了”也能被检索到，这种细节非常影响实际体验。
2.3 更新机制：让助手和固件版本同步进化
知识库最怕的是“一次性建设，永久不维护”。我们团队的做法是建立一条轻量的更新流水线：
- 每次芯片厂商发布手册修订版，由硬件工程师审核差异，把变更页替换进知识库；
- 每个已关闭的Bug，由负责人在缺陷系统里勾选“已归档至AI知识库”，系统自动导出新增记录；
- 每个季度做一次“知识体检”，抽查20个高频问题，看助手回答是否还准确，不准就回溯是切片问题、文档过期问题还是提示词问题。
我把知识库的更新节奏和固件版本绑定在一起，固件出v1.2，知识库就同步更新到v1.2对应的手册和SDK文档。这个流程坚持下来之后，助手才没有出现“拿着上代芯片的资料回答本代芯片问题”的尴尬情况。
3. 真正能落地的场景：AI助手在研发流程里干了哪些活
3.1 芯片手册问答助手：从“翻六百页PDF”到“十秒给结论”
这是我们上线的第一个应用，也是团队反馈最好的一个。它解决的需求特别朴素：工程师查寄存器、查引脚复用、查外设配置时，不用再打开PDF手动搜索。
实现逻辑并不复杂：知识库挂载芯片参考手册的寄存器章节和引脚复用章节，提示词里明确要求“回答必须引用手册中的章节或表号，禁止凭经验补充未出现在检索结果中的数据”，温度参数调到0.1以下，保证回答严格忠于资料。
举一个实际例子，工程师提问“I2C1的SCL引脚有哪些复用功能”，助手会先检索引脚复用表相关片段，再组织出类似这样的回答：“根据手册第8章引脚复用表，I2C1_SCL可复用为PB6、PB8，配置为AF4模式；详细寄存器配置见GPIOx_AFRL寄存器的说明。”同时给出引用的表号和章节，工程师可以快速回溯原文核对。
这套方案上线后，最大的变化不是回答有多“聪明”，而是团队不再害怕打开几百页的手册了。以前新工程师连“这个外设时钟在哪打开”都要找半天，现在直接问助手，效率提升非常明显。
3.2 嵌入式代码审查助手：查的不是风格，是资源和时序
第二个场景是代码审查。通用代码审查工具通常关注命名规范、重复代码、语法问题，但嵌入式代码审查有它的特殊性：资源占用、时序约束、中断安全、寄存器操作的正确性。这些才是真正让嵌入式工程师头疼的地方。
我设计的代码审查应用是一个工作流，接收一段代码或一个PR的diff，先做静态分析，再对照团队规范知识库逐项检查，重点集中在：
- 寄存器操作：读-改-写序列是否被中断打断，需不需要临界区保护；
- volatile的使用：硬件寄存器地址、中断中共享的变量是否遗漏volatile；
- 堆栈与内存：大数组是否用了静态分配，递归深度是否可控，是否有动态内存分配在中断里；
- 外设初始化顺序：时钟使能、引脚复用、外设复位、中断配置的执行顺序是否和手册要求一致；
- 延时与阻塞：循环等待标志位的代码有没有超时机制，防止死等。
这个助手起的不是“替代人工评审”的作用，而是“先把明显问题筛掉，让评审专家把时间花在真正的设计讨论上”。我们的数据是，接入代码审查助手之后，PR评审的往返次数减少了大约四成。不过这里我必须强调：模型检查不出硬件时序问题，比如信号竞争、建立保持时间违规，这些仍然需要硬件工程师把关。AI在这里干的是“体力活”，不是“脑力活”。
3.3 串口日志分析助手：把崩溃现场翻译成排查方向
嵌入式调试中最痛苦的场景之一，就是拿着一份串口日志，面对一堆看不懂的十六进制数和寄存器值。我们做过统计，一个HardFault问题的排查，老工程师平均需要半小时，新工程师可能要一整天。
日志分析应用的工作流设计是这样的：
- 输入阶段：工程师把崩溃时的完整日志粘贴进来，或上传日志文件；
- 预处理节点：用脚本提取日志中的关键信息，包括异常类型、触发地址、寄存器快照（PC、LR、R0-R12）、栈回溯；
- 检索阶段：把提取出的故障寄存器和现场信息丢给知识库，检索芯片手册的“异常处理与故障分析”章节、历史Bug库中同类问题记录；
- 生成阶段：模型综合检索结果，输出“可能的原因排序+下一步排查建议”。
举个例子，一次定时器中断里操作数组越界导致的HardFault，助手的分析输出会包含“异常类型为总线错误，PC指向0x08001234，该地址位于Timer_IRQHandler附近；历史Bug库中有三条记录与该场景相关，其中一条的根因是数组越界写入了相邻变量。建议检查定时器回调中数组下标在使用前是否做了边界校验，并对比历史Bug单编号TICKET-1024的修复方案”。
这种“从崩溃现场直接跳到历史Bug记录”的能力，是传统搜索完全给不了的。因为Bug记录根本不会出现在芯片手册里，它只存在于我们自己的知识库中。这也是我为什么坚持要自建知识库而不是纯用通用大模型的原因：通用模型知道芯片手册，但不知道你们项目的历史债务。
3.4 测试报告与缺陷单的自动化辅助
最后一个场景相对轻量，但日常使用频率很高。我们做了一个“测试报告生成助手”和一个“缺陷单分类助手”。
测试报告生成助手挂载了测试用例模板和历史测试数据，工程师只需要填入关键实测数值（比如各低功耗模式的电流、唤醒时间、通信误码率），助手就能按照团队模板生成结构化报告，包括与前一个版本的对比和异常标注。虽然数值还是工程师自己填，但一个原本要写一小时的报告，现在十分钟就能出初稿。
缺陷单分类助手则负责“接客”环节：研发群里突然有人报了个bug，机器人自动把描述喂给助手，助手先判断属于软件问题、硬件问题还是配置问题，再打上模块标签，附上可能的代码位置建议，然后指派给对应的负责人。这个应用看起来技术含量不高，但对团队协作效率的提升非常明显——bug单的品质变高了，处理人的第一反应不再是“这描述根本看不懂”。
4. 从“聊天机器人”升级成“流程引擎”：工作流设计的心得
4.1 把老工程师的排查经验固化成工作流
聊天式问答的天花板在于：模型只会回答你问的问题，不会主动引导你排查。而实际研发中，问题往往不是一次问答能定位的，需要按逻辑一步步走。Dify的工作流功能，正好可以把老工程师脑子里的排查思路固化下来。
举一个我们做的“看门狗复位排查”工作流。看门狗复位是嵌入式项目里出了名难查的问题，因为复位发生时系统已经来不及打印现场了。传统做法是工程师凭经验猜，效率极低。我们在Dify里设计的工作流是这样的：
- 用户先选择复位发生的场景：上电复位、运行中复位、低功耗唤醒复位；
- 根据场景分支提问：最近改了什么代码？是否新增了外设？功耗模式是否切换？
- 引导用户打开特定的调试手段：打开哪个宏开关、在哪个中断里打点、如何用调试器的复位原因寄存器判断复位源；
- 根据用户返回的现场信息，检索知识库中相似的排查案例；
- 输出候选根因和验证方法。
这个工作流的设计重点，是把“老工程师的追问习惯”转化成了条件分支逻辑。用了之后，新工程师遇到看门狗问题，不再是一头雾水地在群里乱问，而是先跑一遍这个流程，把关键信息收集齐，真正需要老员工介入的情况就少了很多。
4.2 模型选择与参数配置的工程经验
Dify允许不同节点调用不同模型，这个灵活性很有用。我在实际配置中摸索出的原则是“便宜模型干粗活，强模型干细活”。
在日志分析工作流里，“提取关键字段”这个节点用的是速度快的轻量模型，因为它只需要做信息抽取，任务简单；而“综合根因分析”这个节点才用更强的模型，因为它需要结合知识库做多层推理。这样搭配的理由非常直接：信息抽取节点会被频繁触发，如果都用最强的模型，接口延迟和成本都扛不住；而根因分析节点调用次数少，但质量要求高，值得用更强的模型。
温度参数也需要按场景调整。事实型问答（寄存器配置、引脚功能）我把温度设为0到0.1，追求稳定复现；报告生成这类需要一定组织语言的场景，温度设到0.3左右，让表述自然一些；只有生成测试总结、发布说明这类文案时我才用到0.5以上。知识库问答类的应用，温度一旦超过0.5，就开始出现“一本正经地添油加醋”，这在嵌入式领域是不能接受的。
关于上下文长度，我也吃过亏。早期把整个会话历史都传给模型，结果长对话之后，模型反而被早期的错误回答带偏。后来我把会话轮次截断到最近六轮，并且在工作流的关键分支节点，只传入当前问题的精炼摘要，不传原始长文本。这个调整让回答稳定性提升不小。
4.3 人机协作边界：什么时候必须叫人
AI助手做久了，团队里会产生一种“它什么都知道”的错觉。我作为负责人，必须明确划出人机协作的边界。我们定了一条硬规则：
- 凡是涉及安全相关的决策，比如电源电路参数计算、电机控制时序、电池保护阈值，助手给出的答案只能作为参考，必须由硬件工程师复核并签字；
- 凡是助手给出“可能”结论的，工作流会自动追加一个节点，生成“验证方法建议”，引导工程师用实测去确认，而不是直接采信；
- 凡是助手检索相似度低于阈值的，返回结果会明确标注“知识库中无直接相关资料，以下内容仅为模型推测”，强制降低误导风险。
这条边界不是技术问题，是管理问题。AI助手的作用是把团队的“平均水平”提上去，而不是把“安全责任”甩给模型。我在给团队培训时反复强调一句话：助手说的话要有出处，没有出处就当它放屁，自己去查手册。
5. 把AI助手部署到团队日常：私有化、API与权限管控
5.1 为什么坚持私有化部署
嵌入式项目的保密等级普遍比互联网应用高，因为源码和硬件设计直接关系到产品竞争力。第一次考虑部署方式时，团队里也有人提议直接用云端版本，方便省事。但评估下来发现了几个硬伤：
- 芯片手册虽然公开，但我们自己写的BSP源码、驱动改动、产品级配置是核心资产，绝不能出内网；
- 历史Bug记录里包含客户项目代号、具体产品缺陷，这些数据一旦外传，后果不是技术问题而是商务问题；
- 缺陷系统、编译服务器都在内网，API调用必须走内网通路，云端部署在链路层面就不通。
所以最终方案是在内网一台服务器上用Dify开源版本做私有化部署。部署本身不复杂，用容器编排跑起来，数据库用内网已有的PostgreSQL实例，向量存储用的是独立的向量数据库容器。这里提醒一句：Dify的配置数据在关系库里，而知识库的向量索引在向量库里，两者都要做好定时备份，否则知识库重建的过程非常痛苦——几百个文档重新切分、重新索引，至少要小半天。
模型这一层，我们选择了一家支持私有化部署的模型服务商，在内网再起一个推理服务。这样做的好处是，从Dify到模型再到知识库，全链路不出内网，安全边界非常干净。如果你团队没有内网推理的条件，至少也要选数据合规方案清晰的模型API供应商，并且签订数据使用协议，底线是不能把日志和代码片段留在第三方缓存里。
5.2 通过API把助手嵌进工程师的日常工具
如果让工程师专门打开一个网页去问AI，使用频率一定高不了。我们做的是把各个应用通过Dify开放的API接口，嵌入到工程师本来就天天在用的工具链路里：
- 群聊机器人：把“手册问答”应用挂到团队群，工程师在群里@机器人就能提问，答案直接回到群里；
- 缺陷系统联动：新Bug单创建时，自动调用“缺陷单分类助手”打标签、写初步分析，并把结果填回Bug单的描述字段；
- CI流水线联动：编译失败时，流水线自动把错误日志发给“编译日志分析应用”，几分钟后把可能的修复建议贴在流水线页面上；
- PR评审流程：代码提交PR时，自动触发“代码审查助手”，把审查意见作为评论发到PR下面。
API接入的设计原则是“应用主动找人，而不是人去找应用”。工程师不需要改变工作习惯，AI助手会出现在他们需要的地方。这部分的开发工作量不大，Dify每个应用生成后都有现成的API文档和SDK，我们的后端同学两天就把四个集成点全部做完了。
5.3 权限控制：谁能问、能问到什么程度
知识沉淀得越多，权限问题就越敏感。量产代码的审查结果、特定客户的Bug记录，不是每个团队成员都应该看到的。我们的做法是按知识库维度做隔离：
- 通用知识库（芯片手册、SDK文档）：全员可问；
- 项目内部知识库（某项目X的Bug记录、设计文档）：仅该项目组成员的应用可关联；
- 敏感知识库（量产数据、客户定制）：只有管理者账号可见，且不开放给任何集成接口。
Dify的权限粒度是按“应用”和“知识库关联关系”来控制的，我们为不同角色创建了不同的应用实例，分别关联不同的知识库。API密钥也严格区分，每个集成点单独一个Key，涉及敏感知识库的Key只发放给负责人。这套机制执行之后，既保证了知识共享的便利性，也没有出现“新人能查到量产客户信息”的越权风险。
6. 实测中的翻车现场：这些坑我已经替你们踩过了
6.1 幻觉最严重的重灾区：寄存器地址和引脚编号
第一个翻车现场来得很快。我们上线手册问答应用后，有工程师提问“某型号MCU的UART4的发送引脚是哪个”，助手一本正经地回答了一个引脚号，结果对着实物一测，完全不对。我排查之后发现，问题出在两个方面：
一是引脚复用表在原始PDF里是一张巨大的表格，转成Markdown后被切成几段，检索命中的片段可能只包含部分引脚，模型看到不完整数据，就“脑补”了缺失的部分；二是提示词里没有加“禁止推测”的硬性约束，模型倾向于把回答补完整，哪怕补的是错的。
修复方案分三层：
- 预处理层：把引脚复用表按“外设+引脚号”拆成独立的结构化条目，比如“UART4_TX: PA0, PD1”，一条一个最小片段，保证检索命中时信息是完整的；
- 提示词层：明确写入“只可引用检索结果中出现的引脚编号和寄存器地址；检索结果中不存在的信息，一律回答'手册中未查询到'”；
- 工作流层：加了一个“检索验证”节点，在返回回答前先比对检索结果与回答中出现的实体，如果回答中有实体没在检索结果里出现，打回重生成。
这个三层防护之后，事实性错误率下降非常明显。实测用20个高频引脚问题做验证，回答准确率从最初的不到七成，提升到了稳定在95%以上。剩下的5%依然存在——所以我一直跟团队强调，凡是引脚号、寄存器地址这类硬信息，答题之后必须回原文核对。
6.2 PDF转换与编码乱码：技术文档的预处理是隐形工作量
做知识库之前，我想象中的工作流程是“上传PDF，自动索引，一切搞定”。现实是，PDF转文本就折磨了我整整一周。
我们用的芯片手册是扫描版加文字层的混合PDF，有些页面文字层是歪的，转出来之后表格完全错位，寄存器名和位域说明串到一起，变成了一堆乱码。更麻烦的是含公式和特殊符号的页面，比如电气特性章节里的µA、Ω、℃这些符号，转出来经常变成“？”或乱码，直接导致检索时命中率断崖式下跌。
这里分享一个惨痛教训：知识库的质量问题，在检索时才会暴露，而检索时已经晚了。我后来给处理流程加了一个质检步骤：每个转出来的文档，抽查关键页面，重点看表格完整性、特殊符号、页眉页脚有没有混入正文。对于表格密集的页面，干脆舍弃自动转换，直接用脚本重建Markdown表格，虽然费时间，但一次建好，后续反复使用都是赚的。
另外，串口日志分析还有一个编码坑。很多嵌入式工程师用串口助手导出日志，默认是GBK编码，直接传给助手会出现乱码。我们在日志分析应用前面加了一个预处理节点，自动检测编码并转成UTF-8，之后再进模型。这个节点成本极低，却解决了几十个“乱码导致分析失败”的问题。
6.3 如何给AI助手定“及格线”：回答质量的评估方法
AI服务上线容易，但“怎么算好用”这个问题，团队里聊过好几轮。我们不能凭感觉说“回答得还行”，必须建立客观的评估标准。我们做的是一套轻量级的评测集方案：
从历史真实问题中挑选了50个高频问题，覆盖寄存器配置、引脚复用、中断配置、功耗模式切换、编译错误、排查案例六大类；然后由骨干工程师逐一写出标准答案，标注出每个答案里的关键信息点，比如寄存器名、地址、引脚号、操作顺序、注意事项；接着把这些问题批量发送给助手，把回答和标准答案做比对，按“关键信息点命中率”打分。
这里我特别说明一下，为什么不用网上常见的那种“端到端评个分”的做法。因为嵌入式问答的关键信息大多是离散的硬信息，一个回答里可能包含五个关键点，错了其中一个就没法用。按“关键信息点命中率”评估，能直观反映“这个助手回答可不可信”。我每周跑一次评测集，命中率低于90%就回溯，看是知识库更新导致的、模型参数导致的，还是提示词漂移导致的。这套流程跑了三个月，助手的评分一直稳定，团队对它的信任度也随之建立起来了。
6.4 让模型学会说“我不知道”：提示词与兜底策略
最后一个严重问题是“过度自信”。通用大模型在训练时被鼓励尽量回答，但嵌入式场景里，瞎说比不说更危险。我见过一次特别吓人的输出：有工程师问“这个传感器上电后多少微秒内可以开始读ID”，知识库里根本没有这个数据，模型却根据“一般经验”编了一个数值，差点导致工程师根据这个错误值去调硬件。
从那之后，我把“承认不知道”作为所有知识类应用提示词里的强制要求，并且从三个层面做了兜底：
- 提示词层面：写明“如果检索知识库中没有明确的答案，请回答'根据现有资料无法确认'，并引导用户提供更多上下文或查阅手册的具体章节”；
- 检索层面：设置相似度阈值，低于阈值直接截断后续生成，返回预设的“未找到相关资料”话术，并列出用户可以去查的文档名称和章节；
- 对话策略层面：引导用户“换个问法”，比如补充芯片具体型号、把外设名称写完整，提高下一次检索的成功率。
这套组合拳下来，助手“瞎编”的概率大幅降低。虽然偶尔会出现“明明知道却不答”的保守情况，但相比于编造错误信息带来的信任崩塌，我宁可让它保守一点。做嵌入式的人应该都理解这个选择：在这个领域，可靠性永远比看起来聪明更重要。
最后再分享一点个人的体会。给嵌入式团队引入AI，不要追求一步到位，先挑一个最高频的场景（比如芯片手册问答）跑起来，让团队先形成“有问题先问AI”的习惯，再逐步叠加代码审查、日志分析和缺陷分类。知识库要像代码一样做版本管理，提示词要像配置项一样有评审记录。AI研发中枢的价值，不在于它一次能回答多复杂的问题，而在于它每天稳定地替团队解决那些重复、琐碎、但又不能出错的查询和检查工作。它不会取代你的硬件评审和实测，但能让你的团队把省下来的时间，花在真正需要人的经验和判断力的地方。
