AI 大模型 的出现，让软件行业的开发范式经过了好几轮迭代。嵌入式研发的迭代同样在进行，只是节奏比互联网慢半拍。
1. 传统开发
传统开发是过去几十年的标准范式，无论瀑布还是敏捷，都按照需求→设计→编码→测试→上线推进，每个节点由不同角色承担：项目经理、产品经理、SE、测试工程师。这个阶段的编程，说白了就是现在常说的“古法编程”。
除了航空航天、轨道交通这类强合规领域，还在坚持古法的公司应该不多了。你身边还有没有还在坚持古法的公司？
2. AI 辅助开发
AI 辅助开发是多数公司正在经历的阶段：把大模型插进传统流程的各个环节提效。产品经理用它写需求，工程师用它出设计、写代码、写单测，测试工程师则用它生成用例和自动化脚本。
这就是常说的 +AI：人仍是主体，守住每个关卡，AI 只处理明确模块和重复劳动。
到 2026 年，各主流模型的 Coding 能力已经相当强，Coding Benchmark 综合成绩如下：
分数 60 分已经算是顶尖水平。而在两年前的 2024 年，各大模型还仅仅徘徊在 30 分上下：
模型能力越来越强，意味着在 AI 辅助开发阶段，初级工程师和高级工程师的开发效率正在慢慢拉平。能不能产出更易维护的代码，就得看各自的手段了。不过大家现在也不怎么关心维护问题了——代码由 AI 维护，问题也由 AI 分析解决。
于是当下有些公司开始卷工时，比如《嵌入式工程师的评优现状？卷工时？》这篇文章聊到的。我们也不必安于现状，可以多想想突破点，就像《随笔 | 会调 AI 之后，嵌入式工程师还剩什么？》里说的：别总沉浸在 AI 帮我们干了多少活，大家的 AI 都能干。
总的来说，当前的瓶颈早已不是生成代码，而是在环境、验证、上下文、安全、组织协同等方面能否形成闭环。这正是下一个研发范式阶段——AI-Native 研发范式。
3. AI-Native 研发范式
3.1 什么是 AI-Native？
AI-Native 研发范式不同于 AI 辅助开发。它不是在传统软件上加一个 AI 助手，而是从产品构思、架构设计开始，就把大模型作为系统的核心引擎来构建。行业里有一个简单的判断标准：移除 AI 能力后，整个产品无法提供核心价值、直接失效。
相关资料：
3.2 嵌入式切换 AI-Native 研发范式的思考
研发层面的卡点不在编码，而在闭环。
互联网的编译、部署、回归都发生在同一台机器上，agent 能自己构建、自己运行、自己核实。嵌入式要复杂得多：可复现构建、执行环境（板子、外设、时序）、可观测（串口、调试器）、可回滚（烧错变砖），再加上芯片手册等因素。
- 比较容易切换 AI-Native 的场景：嵌入式 Linux 上层软件、平台中间件、工具链与测试基建等。离硬件远、接口有标准，比较容易闭环。
- 比较适合 AI 辅助的场景：裸机控制、实时性、低功耗、安全认证域等。硬件贴得紧，一次失败常常耦合着驱动、时序和外设状态等。
嵌入式里 AI-Native 研发范式的现状，一句话就能概括：离硬件越近，闭环越贵，切换越晚。
3.3 走到 AI-Native，要过四道坎
- 构建可复现：工具链容器化，交叉编译器版本固定。判定：agent 改完代码，构建次次能过。
- 执行可仿真：能搬的全搬进 QEMU 等仿真环境。判定：不接硬件就能跑的测试占比。
- 板级可自动化：脚本化烧写加电源复位、串口日志自动抓取、板卡排队租约。判定：一次 HIL 回归里人工介入几次。
- 判定可机器读：测试输出、覆盖率、日志归一成机器结论；证据不足直接判 UNKNOWN。判定：可信绿灯的自动化率。
如果前两道没有打通，所谓 AI-Native 只是让 agent 写代码、等人验证，本质上仍然是 AI 辅助，而且成本更贵——你得反复跟 AI 拉扯。
成熟度大致分四级：
- L1：人逐步开 AI
- L2：需求、设计、计划落成 git 里的版本化产物，agent 在 CI 里跑仿真
- L3：agent 端到端跑到 HIL，人只在关卡上审
- L4：产品级 AI-Native，与研发流程正交，需要单独评估
阿里那份手册把环境与验证驱动排在五个共性挑战的第一位；Anthropic 的 playbook 同样让每个阶段的产出落成 git 里的版本化文件，用 hook 做确定性护栏。
方向是一致的：先修地基，再谈编排方是谁。这类从编码到闭环的转变，云栈社区 里也有不少开发者在持续讨论。 | 
发表于 6 小时前
|
查看: 10|
回复: 0
