最近一段时间，我一直在思考一个问题：
在一家以嵌入式、C++和设备研发为主的公司里，一个长期从事 Java、Python、大模型、Agent 和后端系统开发的人，真正能够创造什么价值？
这个问题看起来很容易回答。
可以做 AI Coding，可以接入大模型，可以做 RAG，可以开发 Agent，也可以搭建 MCP 服务。
但如果只是把这些技术一个个堆起来，我认为意义并不大。
真正值得思考的是：
AI 技术如何进入原有的研发体系，并最终成为嵌入式研发的一部分？
这也是我越来越清晰的一个定位：
我并不需要成为最优秀的 C++ 工程师，也不需要让 C++ 工程师转型成为 AI 工程师。
我更希望成为连接两者的人。
一边是 AI、大模型、Agent、Java、Python、云平台和自动化工具链；
另一边是 C++、Linux、ARM、雷达、传感器、通信协议和真实设备。
而真正有价值的事情，恰恰发生在这两边之间。
一、AI进入企业之后，真正改变的可能不是“写代码”
过去两年，大模型最容易被看到的能力，是写代码。
给它一段需求，它可以生成代码。
给它一个报错，它可以分析原因。
给它一个函数，它可以解释代码。
这些能力已经非常有价值。
但是如果把视野放到企业研发体系中，就会发现：
写代码只是研发流程中的一个环节。
一个嵌入式产品真正从需求走向交付，需要经历：
需求分析、方案设计、协议设计、代码开发、编译构建、单元测试、集成测试、设备联调、日志分析、问题定位、版本发布以及后续维护。
其中大量工作，并不是“写代码”。
例如：
“这个雷达协议里的字段是什么意思？”
“这个设备为什么突然断开？”
“昨天测试环境出现的异常和哪次代码提交有关？”
“这个协议字段修改以后，哪些地方需要同步修改？”
“这个崩溃日志可能来自哪个模块？”
“这个版本和上一个版本相比，修改了哪些通信逻辑？”
“测试环境里某个设备为什么一直没有数据？”
这些问题，本质上都是研发知识、工程数据和工具能力之间的连接问题。
而这恰恰是 AI 可以开始发挥作用的地方。
二、真正值得建设的，不是一个“AI助手”，而是一套AI研发能力
如果仅仅给公司每个人安装一个 AI Coding 工具，我认为这只是第一步。
因为这种方式下，AI仍然是一个独立存在的工具。
工程师打开编辑器，问 AI 一个问题。
问完之后，继续自己工作。
AI 和公司的代码仓库、CI/CD、测试系统、日志系统、设备系统之间仍然是割裂的。
但如果进一步思考：
如果 AI 可以直接访问 Git？
它可以分析提交记录。
如果 AI 可以访问 CI/CD？
它可以查看构建结果。
如果 AI 可以访问测试系统？
它可以分析测试失败原因。
如果 AI 可以访问日志系统？
它可以定位异常。
如果 AI 可以访问设备？
它甚至可以进一步分析设备状态、通信数据和运行日志。
这时候，AI的角色就开始发生变化。
它不再只是：
“帮我写一段代码。”
而可能变成：
“帮我分析这个问题。”
然后 AI 自己完成：
读取问题描述
↓
分析相关代码
↓
查询 Git 提交记录
↓
查看构建结果
↓
查询测试记录
↓
分析设备日志
↓
定位可能原因
↓
生成修改建议
↓
执行测试
↓
输出分析结果
这时候，AI才真正进入了研发流程。
所以我越来越认为：
企业真正需要的不是一个更聪明的聊天机器人，而是一套能够进入研发流程的 AI 工程系统。
三、为什么我认为“AI + Embedded”是一个值得长期投入的方向
大模型的世界和嵌入式的世界，其实存在一个非常有意思的互补关系。
大模型擅长处理：
- 自然语言
- 代码
- 文档
- 知识
- 复杂任务分解
- 信息检索
- 工具调用
- 多步骤任务规划
而嵌入式系统擅长处理：
- 设备
- 硬件
- 实时数据
- 通信协议
- Linux
- ARM
- C/C++
- 传感器
- 雷达
- 电机
- 控制系统
一个在“信息世界”。
一个在“物理世界”。
如果两者结合起来，AI就不再只是回答问题。
它可以开始理解设备。
甚至参与设备研发和运行维护。
这其实是一个非常重要的变化。
过去的软件系统，大多数运行在服务器和电脑里。
而嵌入式系统最终连接的是现实世界。
因此：
AI一旦进入嵌入式研发，其价值不只是提高代码生成效率，而是有机会让 AI 从“理解软件”进一步走向“理解设备”。
这也是我认为 AI + Embedded 值得长期关注的原因。
四、但这并不意味着C++工程师需要转型成为AI工程师
这是我特别想强调的一点。
技术发展过程中，一个很容易出现的误区是：
看到 AI 很重要，就认为所有工程师都应该学习 AI。
我并不认同这种方式。
一个优秀的 C++ 工程师，他多年积累的设备经验、系统经验、协议经验和工程经验，本身就是非常重要的能力。
例如：
一个雷达协议为什么这样设计？
一个设备为什么需要这样的状态机？
为什么某个通信机制不能简单修改？
某个异常到底属于软件问题、通信问题还是设备问题？
这些问题并不是学会几个大模型 API 就可以解决的。
它需要长期的行业经验。
所以 AI 的进入，并不是为了取代这些能力。
恰恰相反：
AI需要建立在这些专业能力之上。
我更愿意把未来的研发团队理解成一种互补关系。
C++ 工程师继续发挥他们最擅长的事情：
设备、系统、协议、性能、稳定性以及工程实现。
而 AI 工程能力则负责另一部分：
大模型、Agent、知识库、自动化、工具连接、数据分析以及研发流程自动化。
两者结合起来，才可能形成新的研发方式。
五、我真正想做的，是成为两个技术世界之间的“连接层”
如果把公司的技术体系画成一张图，我认为自己所在的位置并不是某一个具体技术栈。
而是在中间。
上面是：
大模型
Agent
RAG
MCP
Python
Java
微服务
自动化
云平台
下面是：
C++
Linux
ARM
嵌入式
雷达
传感器
通信协议
真实设备
中间需要一个连接层。
这个连接层需要解决的问题是：
如何让上面的 AI 能力真正理解下面的设备世界。
例如：
AI 不应该只是知道“TCP是什么”。
它应该能够理解公司的 TCP 通信协议。
AI 不应该只是知道“日志是什么”。
它应该能够理解某一种设备的日志结构。
AI 不应该只是会生成 C++。
它应该能够理解公司的代码结构、协议定义和工程规范。
AI 不应该只是回答：
“这个设备为什么没有数据？”
而应该能够进一步：
查询设备状态 → 查看通信日志 → 分析协议 → 检查服务 → 给出定位结果。
这时候，AI 才真正和企业业务、研发环境发生关系。
六、RAG解决的是“企业知道什么”，Agent解决的是“企业能做什么”
在这个过程中，我认为还有一个很重要的认识。
很多企业做 AI，第一反应都是知识库。
把公司的文档、规范、产品资料全部放进去，然后做一个企业知识问答系统。
这当然有价值。
但知识和能力是两个不同的问题。
例如：
企业知识库告诉 AI：
某型号雷达的通信协议是什么。
而能力系统则应该让 AI：
查询这个雷达当前状态。
知识库告诉 AI：
某个错误码代表什么。
工具系统则应该让 AI：
查询最近出现这个错误码的设备。
知识库告诉 AI：
代码提交规范是什么。
工具系统则应该让 AI：
查询某次提交并进行检查。
所以我越来越倾向于把企业 AI 系统拆成几个不同的部分：
企业知识库
↓
企业“知道什么”
能力知识库 / 工具体系
↓
企业“能够做什么”
Agent Memory
↓
Agent“记得什么”
Agent
↓
决定“现在应该做什么”
MCP
↓
让 Agent 真正连接外部能力
这几个部分不能混在一起。
知识负责提供信息。
工具负责提供能力。
Memory负责保留上下文。
Agent负责组织这些能力完成任务。
这才逐渐形成一个完整的执行体系。
七、从“AI Coding”走向“AI研发Agent”
如果沿着这个方向继续发展，我认为企业 AI 的演进可能会经历三个阶段。
第一阶段：AI工具
最容易开始。
例如：
- AI Coding
- 代码补全
- 代码解释
- 文档生成
- 日志分析
- 技术问答
这个阶段解决的是：
让工程师更高效。
第二阶段：AI Agent
接下来，AI开始拥有工具。
例如：
Git
CI/CD
测试平台
日志平台
数据库
知识库
项目管理
设备管理
这时候工程师给 AI 的不再只是一个问题，而可能是一个任务：
“帮我分析这个设备最近频繁断线的问题。”
Agent开始自己拆解任务。
任务
↓
规划
↓
查询知识
↓
查询设备
↓
查询日志
↓
分析代码
↓
形成结论
这个阶段解决的是：
让AI开始参与研发流程。
八、第三阶段：AI + Embedded
再往前一步，AI开始真正连接设备。
这可能是更值得关注的方向。
例如：
工程师
↓
AI Agent
↓
MCP / Tool
↓
设备平台
↓
雷达 / 传感器 / 控制器
这时候 AI 不再只面对软件。
它开始面对真实设备。
例如：
“检查一下这台雷达最近的通信状态。”
Agent可以：
查询设备
↓
读取状态
↓
查看心跳
↓
查询通信日志
↓
分析异常
↓
输出诊断结果
如果未来进一步增加权限控制和人工确认机制，甚至可以进入：
查询
↓
分析
↓
生成操作方案
↓
人工确认
↓
执行设备操作
↓
验证结果
这时候，AI真正开始从软件世界走向物理世界。
九、这也意味着“Agent”的真正价值不是聊天
我过去对 Agent 的理解，也经历过一个变化。
最开始容易把 Agent 理解成：
一个比普通聊天机器人更聪明的 AI。
后来越来越发现，这个理解太浅。
真正的 Agent，更接近：
能够围绕目标组织任务、调用工具、处理结果并持续推进任务的执行主体。
所以一个成熟的 Agent 系统，至少应该考虑：
用户目标
↓
任务理解
↓
任务树
↓
规划树
↓
Agent执行
↓
工具 / MCP
↓
业务系统 / 设备
↓
执行结果
↓
任务状态
↓
审计与追踪
这也是为什么我越来越重视：
任务、规划、工具、Memory和审计。
因为只有这些东西逐渐形成体系，Agent才不再只是一个“会调用工具的聊天窗口”。
十、未来真正有价值的可能不是“谁拥有最强模型”
模型当然重要。
但对于企业而言，模型只是整个系统中的一个组成部分。
假设未来模型能力越来越接近，那么企业之间真正拉开差距的可能是：
谁拥有更完整的企业知识
谁拥有更丰富的工具体系
谁拥有更好的任务模型
谁能够连接更多业务系统
谁能够连接真实设备
谁拥有更完整的执行数据
谁能够建立可靠的权限和审计体系
也就是说：
模型能力可能越来越成为基础设施，而企业自己的“能力体系”和“执行体系”才会逐渐变得重要。
这也是为什么我现在越来越关注 MCP、Agent、任务树、规划树、Memory以及执行审计。
这些东西表面上看起来是不同技术。
实际上，它们共同解决的是一个问题：
如何让 AI 从“理解信息”走向“执行任务”。
十一、这也是我对自己职业定位的一次重新认识
过去如果让我介绍自己，我可能会说：
Java后端 + Python + AI。
现在我觉得这个描述已经不够准确。
因为技术栈本身不是最终价值。
真正重要的是：
我能够把不同技术体系连接起来。
我可以理解 Java 后端和微服务。
也可以做 Python 和 AI。
能够理解大模型、Agent、RAG和MCP。
同时又长期接触嵌入式产品、雷达、通信协议和设备系统。
这些能力单独看，并没有什么特别。
但把它们放在一起，就形成了一个比较明确的位置：
AI + Embedded 的连接者。
这可能就是我未来更值得投入的方向。
十二、最终目标不是“让公司所有人都学AI”
如果让我设计一条公司的 AI 技术演进路线，我不会从：
“大家开始学习大模型。”
开始。
而会从真实问题开始。
例如：
“能不能让 AI 帮我们分析一次 C++ 崩溃？”
然后：
“能不能让 AI 自动查询 Git 和日志？”
再进一步：
“能不能让 AI 自动执行测试？”
最后：
“能不能让 AI 在权限和人工确认机制下，直接连接设备？”
技术就是这样一点一点进入企业的。
不是为了 AI 而 AI。
而是因为原来的研发流程存在真实的问题，所以 AI 有了进入的理由。
十三、我认为真正值得建设的是一条新的研发链路
最终，我希望看到的不是一个孤立的 AI 工具，而是这样的体系：
AI研发层
┌───────────────────────────────────┐
│ LLM │ Agent │ RAG │ Memory │ MCP │
└───────────────────────────────────┘
↓
AI工程平台
┌───────────────────────────────────┐
│ Coding │ Knowledge │ Agent │ Data │
└───────────────────────────────────┘
↓
工具层
┌───────────────────────────────────┐
│ Git │ CI/CD │ Test │ Log │ DB │ Device │
└───────────────────────────────────┘
↓
嵌入式研发体系
┌───────────────────────────────────┐
│ C++ │ Linux │ ARM │ Radar │ Sensor │
│ TCP │ UDP │ CAN │ MQTT │ Hardware │
└───────────────────────────────────┘
↓
真实设备
这条链路真正打通以后，AI才不再是研发团队旁边的一个工具。
它会逐渐成为研发体系中的一个组成部分。
结语：未来真正稀缺的，是“连接能力”
技术发展到今天，单纯掌握某一种语言、某一个框架、某一个模型，价值仍然存在。
但技术边界正在越来越模糊。
AI正在进入软件开发。
软件正在进入设备。
设备产生的数据又重新进入 AI。
未来真正重要的能力，可能越来越不是：
“我会什么技术？”
而是：
“我能把哪些技术连接起来，并解决什么问题？”
对于嵌入式公司而言，C++工程师依然重要。
对于 AI 而言，大模型依然重要。
对于企业而言，业务知识依然重要。
而真正值得建设的，是它们之间的连接。
让 C++ 连接设备，让 Java 连接业务，让 Python 连接 AI，让 MCP 连接工具，让 Agent 连接任务，最终让 AI 连接真实的研发和设备世界。
这可能就是我理解的：
AI + Embedded。
也可能是我下一阶段真正想做的事情。
不是替代谁。
而是让原本彼此分离的技术世界，开始真正协同工作。基于此，我生成一副个人价值图。
AI介入开发之后 大多数程序员已经变成了AI+人工回车确认的机械工作状态，所以思考是有必要的，不思考未来就止步于此了。
