因为 AI 大模型的出现，软件行业的开发范式经过了几轮迭代，我们嵌入式的研发样式也在进行迭代，只是比互联网慢半拍。
1. 传统开发
传统开发是过去几十年的标准范式，瀑布或敏捷，需求 → 设计 → 编码 → 测试 → 上线，每个节点由不同角色承担：项目经理、产品经理、SE、测试工程师。这个阶段的编程就是现在说的古法编程。
除了航空航天、轨道交通这类有强合规要求的领域，还在坚持古法的公司应该不多了。还有没有还在坚持古法的公司？
2. AI 辅助开发
AI 辅助开发是大部分公司正在经历的阶段：把大模型插进传统流程的各个环节提效。产品经理用它写需求文档，工程师用它出设计、写代码、写单元测试，测试工程师用它生成用例和自动化脚本。
这就是我们常说的 +AI。人仍是主体，人守每个关卡，AI 只做明确模块和重复劳动。
今年（2026年），coding的各主流模型的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大模型作为系统核心引擎来构建。行业有一个简单判断标准：移除 AI 能力，整个产品就无法提供核心价值，直接失效。
相关资料：
阿里的《AI Native 研发范式实践手册》：https://g.alistatic.com/s/v/ainativeinfra/ai-native-handbook/0.0.1/ai-native-handbook.pdf Anthropic：https://claude.com/resources/articles/the-ai-native-sdlc-playbook、https://academy.claude.com/courses/ai-native-sdlc-playbook3.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 做确定性护栏。
方向是一样的：先修地基，再谈编排方是谁。
热门跟贴