企业官网建设流程全解析

1. 项目缘起与整体设计思路

把 AI 助手塞进一块工业开发板，这件事听起来像是极客的玩具，但真正动手之后你会发现，它背后牵扯的东西远比想象中多。我手头这块睿擎派（一款面向工业场景的嵌入式开发板，典型配置为四核 ARM 处理器、2GB 内存、16GB 板载存储，带双网口和宽温设计），原本的定位是跑数据采集、协议转换、边缘计算这类任务，跟“AI 助手”四个字八竿子打不着。但工业现场有个很现实的需求：设备调试和故障排查时，工程师往往要翻手册、查寄存器、对协议，手忙脚乱。如果能在开发板本地跑一个能对话、能查资料、能解释报错的 AI 助手，哪怕只是轻量级的，现场效率会完全不一样。

这个项目要解决的核心问题就三个：第一，在资源受限的工业开发板上把大语言模型跑起来；第二，让这个助手能对接开发板自身的硬件状态和日志；第三，整套东西要稳定、可开机自启、不依赖外部网络。我给它起的代号叫“小龙虾”（NullClaw），取的是“小、硬、能扛”的意思——工业现场环境恶劣，这东西得像小龙虾一样皮实。

为什么选睿擎派而不是树莓派或者别的消费级板子？原因很直接：工业现场对温度范围、供电稳定性、长期运行可靠性有硬要求。消费级板子零下十度可能就罢工了，睿擎派标称工作温度覆盖零下四十度到八十五度，电源输入支持宽压，这些是能真正塞进机柜的前提。当然代价也明显：它的 GPU 算力远不如消费级旗舰板，NPU 算力大概在 1TOPS 级别（不同批次有差异），这意味着我们不能指望跑什么大模型，必须走量化、裁剪、分层的路线。

整体设计思路我反复推翻了三次。第一版想的是直接跑一个 7B 参数的模型，量化到 4bit，结果实测内存直接爆掉，推理速度慢到没法用。第二版退而求其次，用规则引擎加小模型做意图识别，但对话体验太僵硬，工程师问一句“这个寄存器为什么读不到”它只会回预设答案。第三版才定下来现在这套架构：本地小模型负责对话和意图理解，外挂一个结构化的知识库和工具调用层，硬件状态通过系统接口实时注入上下文。说白了，模型不需要什么都懂，它只需要懂怎么调用工具、怎么组织语言，真正的“知识”放在本地文档和脚本里。

这个思路的关键在于把“智能”和“知识”拆开。模型负责理解你在问什么、决定去查什么、把查到的结果用人话讲出来；知识库负责存手册、寄存器表、常见故障码；工具层负责实际去读传感器、查日志、执行诊断命令。这样做的好处是，模型可以很小，但能力边界可以很宽——你加一个新工具，助手就多一项技能，不用重新训练模型。

适合谁来参考这篇内容？如果你是有嵌入式 Linux 基础、想在自己板子上跑 AI 应用的开发者，这篇能给你一套完整的落地路径。如果你只是好奇“开发板上跑 AI”是怎么回事，里面的选型逻辑和踩坑记录也能让你少走弯路。我不假设你精通模型量化，但假设你会用 SSH、会看系统日志、能看懂基本的 Python 和 Shell 脚本。

2. 核心细节解析与实操要点

2.1 模型选型：为什么是 0.5B 而不是 1.5B 或 3B

模型选型是整个项目里最纠结的一步。我前后试了四个量级的模型：0.5B、1.5B、3B 和一个 7B 的量化版本。结论很明确：在睿擎派这个级别的板子上，0.5B 是甜点，1.5B 是上限，3B 以上基本不可用。

先看内存占用。一个模型加载到内存里，除了权重本身，还有 KV Cache、中间激活值、运行时开销。以 0.5B 模型为例，FP16 权重约 1GB，INT8 量化后约 500MB，INT4 量化后约 250MB。睿擎派 2GB 内存，系统本身占 300-400MB，留给模型的空间大概 1.2-1.5GB。0.5B INT4 跑起来峰值内存约 600MB，留有余量；1.5B INT4 峰值约 1.1GB，勉强能跑但一遇到长上下文就危险；3B INT4 峰值直接冲到 1.8GB 以上，系统开始频繁 swap，推理延迟从秒级跳到十几秒。

再看推理速度。我用的是 llama.cpp 的 ARM 优化版本，开启 NEON 指令集加速。实测数据如下：

生成速度 8-12 tok/s 是什么概念？大概就是你问一句话，等一两秒它开始往外蹦字，蹦字速度比你阅读速度稍慢一点。这个体验在工业现场是能接受的——工程师问“三号寄存器当前值是多少”，助手调用工具查一下，然后回答，整个过程三五秒。但如果换成 1.5B，生成速度掉到 3-5 tok/s，一句话要等五六秒才说完，现场用起来就有点着急了。

注意：这里的 tok/s 是纯生成速度，不含工具调用和知识库检索的时间。实际端到端延迟还要加上意图识别、工具执行、结果组织的时间，大概再加 1-2 秒。

那为什么不用更小的模型，比如 0.3B 甚至 0.1B？我试过，0.3B 的模型在意图识别上准确率明显下降，经常把“查寄存器”和“查日志”搞混，而且生成的回答语法错误率升高，有时候会蹦出半截句子。0.5B 是一个平衡点，再小就影响可用性了。

2.2 量化方案：INT4 还是 INT8，以及为什么必须做层间混合量化

量化是让模型塞进小内存的关键。INT8 量化最省心，精度损失小，但内存占用是 INT4 的两倍。对于 0.5B 模型，INT8 约 500MB，INT4 约 250MB，差距 250MB。在 2GB 内存的板子上，这 250MB 很关键——它决定了你能不能同时跑知识库检索和工具调用。

但纯 INT4 量化有个问题：某些层对精度特别敏感，量化后模型会“变傻”。我的做法是混合量化：大部分层用 INT4，但 embedding 层、输出层和中间几个注意力层保持 INT8。具体是哪些层，需要做敏感度分析——简单说就是逐层量化，看哪层量化后困惑度（perplexity）上升最多，那些层就保留高精度。

实操上，我用的是 llama.cpp 的quantize工具，配合一个自定义的层敏感度脚本。脚本逻辑不复杂：加载 FP16 模型，逐层替换为量化版本，在验证集上跑困惑度，记录每层量化后的困惑度变化。变化超过阈值的层标记为“敏感层”，最终量化时对这些层用 INT8。

# 伪代码示意，实际脚本更长 for layer in model.layers: model.quantize_layer(layer, bits=4) ppl = evaluate(model, val_dataset) if ppl - baseline_ppl > threshold: sensitive_layers.append(layer.name) model.restore_layer(layer) # 最终量化 quantize(model, default_bits=4, sensitive_layers=sensitive_layers, sensitive_bits=8)

实测下来，0.5B 模型大约有 15%-20% 的层被标记为敏感层，最终模型大小约 320MB，比纯 INT4 大 70MB，但困惑度比纯 INT4 低了近 30%。这个 trade-off 很值。

实操心得：敏感度分析不用跑全量验证集，抽 200-500 条样本就够了。跑全量太慢，板子上跑一遍要几个小时，没必要。

2.3 知识库设计：为什么不用向量数据库

知识库这块我一开始想上向量数据库，做 RAG（检索增强生成）。但实测发现，在 2GB 内存的板子上跑一个向量数据库（哪怕是轻量级的），内存占用和查询延迟都不可接受。一个 10 万条向量的索引，内存占用至少 200-300MB，查询一次要 100-200ms，再加上模型推理，端到端延迟直接翻倍。

后来我换了个思路：工业场景的知识查询，大部分是精确匹配，不是语义匹配。工程师问“寄存器 0x3F 的默认值是多少”，他要的是精确的寄存器地址，不是语义相近的文档。所以我把知识库做成了结构化键值存储 + 倒排索引，用 SQLite 存，查询走精确匹配和前缀匹配，延迟在 10ms 以内。

具体结构是这样的：一张表存寄存器映射（地址、名称、位域、默认值、描述），一张表存故障码（代码、含义、可能原因、处理建议），一张表存命令手册（命令、参数、示例、注意事项）。查询时，模型输出一个结构化的查询意图（比如{"type": "register", "address": "0x3F"}），工具层去 SQLite 里查，返回结果。

-- 寄存器表结构示意 CREATE TABLE registers ( address TEXT PRIMARY KEY, name TEXT, bitfield TEXT, default_value TEXT, description TEXT ); -- 查询示例 SELECT * FROM registers WHERE address = '0x3F';

这样做的好处是查询快、内存占用小（SQLite 数据库文件本身才几 MB）、结果精确。坏处是只能查结构化知识，查不了“这个报错一般怎么处理”这种模糊问题。我的折中方案是：结构化查询走 SQLite，模糊问题走一个预置的 FAQ 列表，FAQ 列表用简单的关键词匹配，不走向量检索。

注意：FAQ 列表不要超过 500 条，否则关键词匹配的准确率会下降。超过 500 条就考虑做分类，先分类再匹配。

2.4 工具调用层：怎么让模型“动手”而不是“动嘴”

工具调用是这个项目的灵魂。没有工具调用，助手就是个只会聊天的玩具；有了工具调用，它才能真的去读寄存器、查日志、执行诊断。

实现上，我用的是函数调用（function calling）的简化版。模型输出一个特定格式的 JSON，工具层解析后执行对应函数，把结果返回给模型，模型再组织语言输出。格式定义如下：

{ "tool": "read_register", "params": { "address": "0x3F" } }

工具层维护一个工具注册表，每个工具是一个 Python 函数，带参数校验和超时控制。比如read_register函数会去调用板子的 I2C 接口读寄存器，read_log函数会去 tail 系统日志，run_diagnostic函数会执行一组预定义的诊断命令。

# 工具注册表示意 TOOLS = { "read_register": { "func": read_register, "params": {"address": "str"}, "timeout": 2 }, "read_log": { "func": read_log, "params": {"lines": "int", "filter": "str"}, "timeout": 5 }, "run_diagnostic": { "func": run_diagnostic, "params": {"test_name": "str"}, "timeout": 30 } }

关键点在于超时控制。工业现场最怕的就是一个操作卡死整个系统。每个工具调用都必须设超时，超时后返回错误信息给模型，模型再告诉用户“这个操作超时了，可能是什么原因”。我设的超时是：读寄存器 2 秒，读日志 5 秒，诊断命令 30 秒。超过这些时间，基本可以判定是硬件或系统出问题了。

实操心得：工具函数的异常处理一定要做全。我踩过的坑是，I2C 读失败时抛出的异常没被捕获，直接导致整个助手进程崩溃。后来加了 try-except，所有异常都转成结构化错误信息返回给模型，模型再用人话解释。

3. 实操过程与核心环节实现

3.1 系统环境准备与依赖安装

睿擎派出厂自带的系统是一个精简的 Linux 发行版，内核版本 5.10 左右，带 systemd。第一步是确认系统版本和可用资源。

# 查看系统信息 uname -a cat /etc/os-release free -h df -h

实测下来，出厂系统可用内存约 1.6GB，根分区剩余空间约 8GB。这个空间够放模型和知识库，但不够放完整的开发工具链。所以我的做法是：在 PC 上交叉编译，把编译好的二进制和模型文件传到板子上。板子上只装运行时依赖，不装编译工具。

运行时依赖主要是这几个：libcurl（用于可能的 HTTP 接口，虽然主流程不走网络，但预留）、sqlite3（知识库）、python3（工具层脚本）、libi2c-dev（I2C 读写）。安装命令：

# 在板子上执行 apt update apt install -y libcurl4-openssl-dev sqlite3 python3 python3-pip libi2c-dev pip3 install pyserial smbus2

注意：不同批次的睿擎派系统源可能不一样，如果 apt 装不上，就去官方镜像站找对应的 deb 包手动安装。我遇到过系统源里 sqlite3 版本太老的情况，手动编译了一个新版本。

llama.cpp 的编译在 PC 上做，用交叉编译工具链。编译参数关键的是开启 NEON 和关闭不必要的后端：

# 在 PC 上交叉编译 llama.cpp cmake -B build \ -DCMAKE_C_COMPILER=aarch64-linux-gnu-gcc \ -DCMAKE_CXX_COMPILER=aarch64-linux-gnu-g++ \ -DLLAMA_NEON=ON \ -DLLAMA_CUBLAS=OFF \ -DLLAMA_METAL=OFF \ -DLLAMA_BUILD_TESTS=OFF \ -DLLAMA_BUILD_EXAMPLES=OFF cmake --build build --config Release -j$(nproc)

编译出来的main和quantize两个二进制传到板子上，放在/opt/nullclaw/bin/下。

3.2 模型转换与量化实操

模型转换分三步：下载原始模型、转成 GGUF 格式、量化。

原始模型我选的是一个 0.5B 参数的中文对话模型（具体名称不说了，避免广告嫌疑，大家找同量级的即可）。下载后先用 llama.cpp 的convert.py转成 GGUF FP16：

python3 convert.py --input-model ./original_model --output-model ./model_fp16.gguf --outtype f16

然后做敏感度分析，确定哪些层保留 INT8。这一步在 PC 上做，板子上跑太慢。分析脚本输出一个敏感层列表，格式是层索引的 JSON 数组。

最后量化：

./quantize ./model_fp16.gguf ./model_q4_k_m.gguf q4_k_m --sensitive-layers sensitive_layers.json

q4_k_m是 llama.cpp 的一种混合量化策略，对大部分层用 4bit，对敏感层用更高精度。实测下来，0.5B 模型量化后约 320MB，加载到内存峰值约 600MB。

实操心得：量化后的模型一定要在板子上实测一遍，PC 上跑得好不代表板子上没问题。我遇到过一次 PC 上困惑度正常，板子上加载后输出乱码，原因是板子的 NEON 指令集版本和编译时假设的不一致。后来重新编译，指定了正确的-march参数才解决。

3.3 知识库构建与数据导入

知识库的数据来源是开发板的手册、寄存器表和常见故障码。我把这些资料整理成 CSV，然后用 Python 脚本导入 SQLite。

import sqlite3 import csv conn = sqlite3.connect('/opt/nullclaw/db/knowledge.db') c = conn.cursor() # 建表 c.execute('''CREATE TABLE IF NOT EXISTS registers (address TEXT PRIMARY KEY, name TEXT, bitfield TEXT, default_value TEXT, description TEXT)''') # 导入寄存器数据 with open('registers.csv', 'r', encoding='utf-8') as f: reader = csv.DictReader(f) for row in reader: c.execute('INSERT OR REPLACE INTO registers VALUES (?,?,?,?,?)', (row['address'], row['name'], row['bitfield'], row['default_value'], row['description'])) conn.commit() conn.close()

故障码表和命令手册表类似处理。导入后数据库文件约 3-5MB，查询延迟在 10ms 以内。

注意：CSV 里的地址格式要统一，有的手册写0x3F，有的写3F，有的写63（十进制）。导入前一定要做格式归一化，否则查询时匹配不上。我在这上面浪费了半天时间。

3.4 工具层脚本编写与调试

工具层是一个 Python 脚本，负责解析模型输出的 JSON、调用对应函数、返回结果。核心逻辑如下：

import json import subprocess import smbus2 def read_register(address): try: bus = smbus2.SMBus(1) addr = int(address, 16) value = bus.read_byte_data(0x48, addr) # 假设设备地址 0x48 return {"status": "ok", "value": hex(value)} except Exception as e: return {"status": "error", "message": str(e)} def read_log(lines=50, filter_str=""): try: cmd = f"journalctl -n {lines} --no-pager" if filter_str: cmd += f" | grep {filter_str}" result = subprocess.run(cmd, shell=True, capture_output=True, text=True, timeout=5) return {"status": "ok", "content": result.stdout} except subprocess.TimeoutExpired: return {"status": "error", "message": "log read timeout"} except Exception as e: return {"status": "error", "message": str(e)} def dispatch(tool_json): tool = tool_json.get("tool") params = tool_json.get("params", {}) if tool == "read_register": return read_register(params.get("address")) elif tool == "read_log": return read_log(params.get("lines", 50), params.get("filter", "")) else: return {"status": "error", "message": f"unknown tool: {tool}"}

调试时，我写了一个简单的测试脚本，模拟模型输出各种 JSON，看工具层能不能正确执行。测试用例包括：正常读寄存器、读不存在的寄存器、读日志超时、未知工具名等。

实操心得：工具函数的返回值一定要结构化，不要返回纯字符串。结构化返回值方便模型理解，也方便后续做错误处理和日志记录。我一开始返回纯字符串，模型经常误解返回内容，后来改成 JSON 就稳定多了。

3.5 系统集成与开机自启

所有组件准备好后，用 systemd 做服务管理。创建两个服务：一个跑模型推理服务（llama.cpp 的 server 模式），一个跑工具层和对话管理。

# /etc/systemd/system/nullclaw-model.service [Unit] Description=NullClaw Model Server After=network.target [Service] Type=simple ExecStart=/opt/nullclaw/bin/llama-server -m /opt/nullclaw/models/model_q4_k_m.gguf -c 2048 -t 4 --host 127.0.0.1 --port 8080 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

# /etc/systemd/system/nullclaw-agent.service [Unit] Description=NullClaw Agent After=nullclaw-model.service Requires=nullclaw-model.service [Service] Type=simple ExecStart=/usr/bin/python3 /opt/nullclaw/agent/main.py Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

启用服务：

systemctl daemon-reload systemctl enable nullclaw-model nullclaw-agent systemctl start nullclaw-model nullclaw-agent

注意：模型服务的-c 2048是上下文长度，设太大内存扛不住，设太小对话记不住上下文。2048 是实测下来的平衡点，大概能记住 10-15 轮对话。如果内存有富余，可以调到 4096，但 0.5B 模型本身能力有限，上下文太长反而容易跑偏。

4. 常见问题与排查技巧实录

4.1 模型加载失败或推理崩溃

这是最常见的问题，表现是服务启动后立即退出，或者推理到一半进程消失。排查思路按以下顺序：

第一，看内存。free -h看可用内存，如果低于 500MB，基本就是内存不够。解决方法是换更小的量化版本，或者减少上下文长度。

第二，看模型文件完整性。md5sum对比 PC 上和板子上的模型文件，传输过程中可能损坏。我遇到过一次 scp 传输大文件时中断，文件大小对但内容损坏，模型加载时报奇怪的错误。

第三，看 NEON 支持。cat /proc/cpuinfo | grep neon，如果没有输出，说明 CPU 不支持 NEON，需要换编译参数。睿擎派一般支持，但不同批次可能有差异。

第四，看系统日志。journalctl -u nullclaw-model -n 100，里面会有具体的错误信息。

4.2 工具调用超时或返回错误

工具调用超时通常有两个原因：硬件响应慢，或者工具函数本身有 bug。

硬件响应慢的情况，比如 I2C 读寄存器，如果设备没接好或者地址不对，smbus2会一直等直到超时。我的做法是在工具函数里设一个较短的超时（2 秒），超时后返回错误，不要让整个助手卡住。

工具函数 bug 的情况，最常见的是参数类型不对。模型输出的 JSON 里，地址可能是字符串"0x3F"，也可能是数字63，工具函数要能处理两种格式。我写了一个参数归一化函数，把所有输入统一转成字符串再处理。

实操心得：工具函数的日志一定要打全。每次调用记录输入参数、执行时间、返回结果。出问题时看日志一目了然。我一开始没打日志，排查一个问题花了两个小时，后来加了日志，同样的问题五分钟就定位了。

4.3 对话质量差或答非所问

0.5B 模型的能力有限，对话质量差是预期内的。但通过一些技巧可以明显改善：

第一，系统提示词要写死。把助手的角色、能力边界、输出格式都在系统提示词里定义清楚。比如“你是一个工业开发板助手，只能回答与开发板相关的问题，不知道就说不知道，不要编造”。

第二，few-shot 示例要精炼。在提示词里放 3-5 个典型问答示例，让模型模仿格式。示例不要太多，否则占用上下文。

第三，输出后处理。模型输出后，用正则表达式提取关键信息，去掉多余的客套话。比如模型输出“好的，我来帮您查询一下寄存器 0x3F 的值，根据查询结果，当前值是 0x12”，后处理成“寄存器 0x3F 当前值：0x12”。

第四，限制回答长度。在推理参数里设max_tokens，防止模型长篇大论。我设的是 256，够用了。

4.4 系统长期运行稳定性问题

工业现场要求 7x24 运行，稳定性是硬指标。我跑了连续 72 小时的稳定性测试，发现两个问题：

一是内存泄漏。Python 工具层脚本跑久了内存会缓慢增长，原因是某些异常处理路径没有释放资源。解决方法是加一个定时重启机制，每天凌晨重启一次 agent 服务。虽然不够优雅，但实用。

二是日志占满磁盘。journalctl默认不限制日志大小，跑几天就把分区占满了。解决方法是配置日志轮转：

# /etc/systemd/journald.conf SystemMaxUse=100M SystemMaxFileSize=10M MaxRetentionSec=7day

注意：日志轮转配置改完后要systemctl restart systemd-journald才生效。我改完忘了重启，以为没生效，又折腾了半天。

5. 性能优化与资源占用实测

5.1 推理速度优化：从 5 tok/s 到 12 tok/s

刚部署完的时候，生成速度只有 5 tok/s 左右，体验很差。后来做了几项优化，提升到 8-12 tok/s。

第一，线程数调整。llama.cpp 默认用所有核心，但睿擎派四核里有一个核要跑系统任务，实际用 3 个线程最稳。-t 3比-t 4快，因为减少了线程切换开销。

第二，批处理大小。-b 512是默认值，对于 0.5B 模型可以降到-b 256，减少内存占用和计算量，速度反而略有提升。

第三，KV Cache 量化。llama.cpp 支持 KV Cache 量化，把 KV Cache 从 FP16 降到 INT8，内存占用减半，速度提升约 10%。参数是--cache-type-k q8_0 --cache-type-v q8_0。

第四，关闭不必要的日志。llama.cpp 默认输出大量调试日志，关掉后减少 I/O 开销。--log-disable或者把日志级别调到 error。

优化前后对比：

5.2 内存占用分析与压缩

内存是板子上最紧张的资源。我做了详细的内存占用分析：

2GB 内存，系统占用约 1GB，还剩 1GB 余量。这个余量是必要的，因为推理时会有临时内存分配，峰值可能再涨 200-300MB。

如果内存实在紧张，可以进一步压缩：把模型权重放到 mmap 文件里，按需加载，减少常驻内存。llama.cpp 默认就是 mmap 加载，但可以通过--no-mmap强制全量加载。实测 mmap 模式下常驻内存少 100MB 左右，但首次推理会慢一点。

实操心得：不要追求把内存用到极限。留 20%-30% 的余量，系统才稳定。我试过把内存压到只剩 100MB 余量，结果跑几个小时就 OOM 了。

5.3 启动时间优化

从开机到助手可用，时间越短越好。初始版本启动要 45 秒，优化后降到 20 秒左右。

优化手段：模型服务用--no-warmup跳过预热，首次推理时再加载；工具层脚本延迟初始化，不在启动时加载所有依赖；SQLite 用 WAL 模式，减少启动时的锁等待。

# SQLite WAL 模式 sqlite3 /opt/nullclaw/db/knowledge.db "PRAGMA journal_mode=WAL;"

启动时间分解：

6. 扩展方向与个人体会

这个项目做完之后，我最大的体会是：在资源受限的设备上跑 AI，关键不是模型本身，而是怎么把模型和系统能力结合起来。0.5B 的模型单独拿出来，能力很有限，但它加上工具调用和知识库之后，能解决的实际问题远超预期。

后续可以扩展的方向有几个。一是增加更多工具，比如支持 Modbus 读写、支持 CAN 总线诊断、支持 GPIO 控制。每加一个工具，助手的能力边界就拓宽一块。二是做多板协同，一块板子跑模型，多块板子跑工具层，通过本地网络通信，这样模型可以稍微大一点。三是做语音交互，加一个 USB 麦克风和扬声器，用轻量级语音识别和合成，实现语音对话。语音识别可以用 Vosk 的小模型，合成用 espeak，都是轻量级的。

还有一个方向是模型微调。用开发板相关的问答数据对 0.5B 模型做 LoRA 微调，让模型更懂开发板的术语和场景。LoRA 微调可以在 PC 上做，然后把适配器合并到模型里。不过 0.5B 模型微调效果有限，可能 1.5B 更合适，但 1.5B 在板子上跑又吃力，这是个矛盾。

我个人在实际操作中的体会是，这套方案目前最适合的场景是辅助调试和快速查询，不适合做复杂的推理和决策。工程师问“这个报错什么意思”“寄存器怎么配”“日志里这个关键词出现了几次”，助手能快速回答。但如果你问“这个系统为什么不稳定”，它只能给你一些通用的排查建议，真正的根因分析还是要靠人。

最后分享一个小技巧：助手的系统提示词里加一句“如果不确定，就说不知道，并建议用户查阅手册第 X 章”。这样模型不会瞎编，而且会把用户的注意力引导到正确的资料上。工业场景里，一个说“不知道”的助手比一个胡说八道的助手有价值得多。