做一个嵌入式领域的 agent 有搞头吗？

yono

看到坛友们发的 AI 使用相关的帖子越来越多，好像 AI 的应用在嵌入式领域也有所普及，起码我们智慧的广大坛友都用起来了。


痛点

大家发了很多 AI 不好用，AI 在某些地方好愚蠢的帖子。

这是 AI 不可避免的痛点，坛友们用的通常都是通用型 AI 产品，他在公共领域的知识和技能其实是很强的，比如精通命令行指令、精通代码的编写、精通客服话术。
但是细分到具体应用，比如嵌入式领域应该怎么做，你的行业产品应该怎么做，他没有“可信信源”，所有信息来自他训练集中良莠不齐的网上消息。

一个典型案例是坛主大佬关于 CRC 校验计算的问题。据我实践过程中的观察，GitHub copilot、Claude Code、豆包等等一众 AI agent，实际上都不能百分百做好“描述模糊的 CRC 校验”这档子事。
正确的姿势是，把16进制写成一个文件，不要作为上下文发给 AI，直接说“我有一个以 01 F7 87....存储的 test.txt文件，现在，我需要以多项式 xxx xxx 对他做CRC计算，请帮我制作一个 py 脚本/一行即可出结果的命令行。、
其一是大量的 16 进制数据发送给他，只会占据他的上下文，影响正确决策；其二是不能简单说 CRC16/CRC32 CRC细分类太多、他其实分不清到底应该用什么算法。

现在的编程专用型产品，比如 GPT CodeX，只是互联网行业的编程特别强。哪怕我觉得 CodeX 已经是嵌入式训练集最强、最会写嵌入式代码的了，但是他的训练集还是不够多，而且缺乏你使用的芯片的详细信息。

怎么解决

我原以为各个芯片厂商应该一直在着手推进，毕竟去年年初就有了 MCP 这种”可信信源“解决方案，但是居然直到现在都没看到风声。

最近有尝试构建自己的 agent，当在本地有 md 格式或源码的优先信源时，他基于你给出的信息做总结和行动，符合你的预期的可能性大大提高。

所以可以把各个厂商的大部分芯片型号的手册都转成 md 格式，再把他们的初始软件包包含 Example 都丢到置信知识库里。也可以丢一些 RTOS/传感器 之类的手册和源码进去。

这样子后续再问这个 agent ，岂不是很爽？

问题
如果是产品化，将涉及大量的侵权问题、版权争议，我大概率没力气搞。
所有人通用的话，耗工时以月计算。

折中方案

我参考的项目是 CodePothunter/lingque: A self-awared agent(s) assistents with very compact core, natively connected to Lark (feishu).

如果认可我这个思路，你也可以自己搞一些自己用的可信信源部署。只是自用的话应该没什么问题。

搞不好的话，也可以邮件联系请我帮忙。

刘心武

手册都转成 md 格式，这个操作，大佬有没有什么脚本或者软件是成熟的？之前找过一些转换方法，甚至尝试直接让 AI 来执行都非常不满意。

yono

刘心武 发表于 2026-6-18 13:38
手册都转成 md 格式，这个操作，大佬有没有什么脚本或者软件是成熟的？之前找过一些转换方法，甚至尝试直接 ...

这就是巨大难点呀呀呀。没办法，什么工具都不能完美转换，最终都要手动调整。

这也是我说“所有人通用的话，耗工时以月计算”里的耗工时，都在人工校对上。

要是有工具的话，爬一下+脚本转换根本不需要工时。
个人用最多十来个手册，markitdown 然后校对一下，一个小时内就够搭起来了。

fxyc87

刘心武 发表于 2026-6-18 13:38
手册都转成 md 格式，这个操作，大佬有没有什么脚本或者软件是成熟的？之前找过一些转换方法，甚至尝试直接 ...

我就是这样的啊，丢给它pdf，让他转换成skill技能。

eric2013

非常有搞头，就是工作量奇大无比。

有时候官方自己的文档，一个文档一个参数，最经典的就是这种错误，AI自己都蒙圈

确诊了，STM32H7 SPI的CubeMX，参考手册，数据手册给出最大时钟都不一样，已经完全凌乱了
https://forum.anfulai.cn/forum.p ... d=103038&fromuid=58
(出处: 硬汉嵌入式论坛)

yono

eric2013 发表于 2026-6-18 15:40
非常有搞头，就是工作量奇大无比。

有时候官方自己的文档，一个文档一个手册，最经典的就是这种错误，AI ...

这一定程度也是自建 agent 的优势吧，现在的 agent 基本不会说出”这个事情我拿不准，这个事情我做不到“。
不利于商业化运营。

像这种多个信源给出的答案不一致，他可能都不告诉你有多个答案，自己随机就选一个回答你了。

自建的 agent 就可以设定“多个信源的结果冲突时，直言不确定结论，将多个信息来源给用户判断”。

eric2013

yono 发表于 2026-6-18 16:02
这一定程度也是自建 agent 的优势吧，现在的 agent 基本不会说出”这个事情我拿不准，这个事情我做不到“ ...

还有一点，让AI记录手册在官方的原始地址可能更好点，可以定期更新勘误。特别是Github上的，我发现特别方便

刘心武

eric2013 发表于 2026-6-18 16:15
还有一点，让AI记录手册在官方的原始地址可能更好点，可以定期更新勘误。特别是Github上的，我发现特 ...

这个比较困难吧，有的下载资料需要登录账号，如果它账号密码信息，不就要给 AI 泄露不少自己的信息吗？

yono

经过3个小时的简单二开，已经可以做到优先基于本地知识库辅助项目开发了。
而不是单纯的问答对话。

比较难做，我自用也不打算实现的是
1. IDE 集成，这是相当麻烦
2. 多种模式而不是直接接替写入，现在只能通过 git compare 检查它到底改了啥

自用来说够了，只辅助驱动开发，后续应用层依然由 claude 进行。

yono

经过3个小时的简单二开，已经可以做到优先基于本地知识库辅助项目开发了。
而不是单纯的问答对话。

比较难做，我自用也不打算实现的是
1. IDE 集成，这是相当麻烦
2. 多种模式而不是直接接替写入，现在只能通过 git compare 检查它到底改了啥

自用来说够了，只辅助驱动开发，后续应用层依然由 claude 进行。

yono

还是做不到很好的 PDF 解析，工具调用会失败(也可能是我忘记装python库了)

SOUL 的编写还是要调一调。

yono

eric2013 发表于 2026-6-18 16:15
还有一点，让AI记录手册在官方的原始地址可能更好点，可以定期更新勘误。特别是Github上的，我发现特 ...

如果是 HAL 库和 Firmware Package 当然可以，但是还是那个问题，手册都是 PDF 格式，做不到完美解析的。等待全世界都使用 markdown！