最近这半年，如果你在知乎、B站搜“Keil”，会看到一种奇特的对撞。一边是《告别Keil！手把手教你用VSCode搞STM32开发》《告别Keil！STM32 HAL库+CMake+VSCode开发指南》这样的帖子一篇接一篇。知乎知乎
B站上“如何把keil工程移植到vscode”的教程能跑到上千播放。哔哩哔哩今年8月，还有UP主干脆把自己“VSCode+Claude Code写代码、Keil管编译交付”的AI开发环境全套公开。哔哩哔哩另一边，知乎那个133赞、20条评论的问题——“为什么这么难用的Keil仍没有被淘汰？”——最高赞的回答开头第一句就是：Keil不会被淘汰，这是生态问题。知乎
两边说的都是实话。这篇内容想帮你把这件事拆明白：喊“告别”的人和留守的人，到底谁在什么处境？你要不要动，动的成本是多少。
Keil被嫌弃的，从来不是能不能干活
先说清楚大家到底在骂什么。Keil uVision5被吐槽最狠的是编辑器体验：界面“二十年如一日”，代码补全约等于没有，跳转定义经常失灵，中文编码动不动乱码。一个高赞回答形容得很直白：敲完一段，编译，报错，回去改，再编译，“没有补全，没有跳转，没有实时检查”。知乎在今年6月一篇对比AI编程工具写嵌入式代码的文章里，作者干脆把文章标题写成了“Keil太丑不想用”。知乎
但注意，骂点高度集中在“写代码”这一个环节。没有人说Keil编译不稳定、调试不好用。恰恰相反，一个做商业产品开发的工程师在知乎的说法是：商业应用大部分都是Keil，AC6编译器“稳如老狗”，GCC开高优化太激进，时序敏感的代码时不时就会发生错误。知乎这个反差是理解整件事的钥匙：Keil的问题在编辑器，价值在工具链。
那为什么两年了还没人真搬走？
四个生态锁，一个比一个硬：
芯片厂商的示例工程默认就是Keil格式。 国产MCU尤其如此，官方BSP、例程清一色.uvprojx，换工具链等于自己重搭一遍脚手架。
调试器和下载算法绑得死。 ST-LINK、J-Link在Keil里是开箱即用，换环境要重新配OpenOCD、pyOCD或者厂商工具。
历史项目积累。 公司里跑了好几年的项目，没人愿意为了编辑器体验去动构建系统。
Arm编译器在量产代码里的口碑。 就是前面那句“AC6稳如老狗”。
而且Keil也没躺平：2026年MDK5这条线还在更新，5.42、5.43相继推出，安装教程全网都在追新版。知乎当然新版也有新坑——比如有人记录5.39配AC6在STM32U5上出现位域操作异常，最后靠加编译选项解决。知乎5.43又有人遇到调试时System Viewer窗口空白。哔哩哔哩但至少说明这条产品线还活着，不是停更状态。
关键认知：主流玩法不是“告别”，是“离婚不离家”
这是我想给的最重要的一个判断。把全网帖子摊开看，真正做得成、做得久的人，绝大多数没有卸载Keil，而是把“写代码”和“编译调试”拆开了。那个133赞回答的作者把话说得最透——写代码和编译调试本来就是两件事，分开处理就好。知乎他自己还写了个叫k2c的小工具，一行命令把Keil工程文件转成Clangd能识别的配置，在VSCode里白嫖补全、跳转和实时检查，Keil工程一个字不用改。
目前社区里跑得通的路线，大致四条：
路线A：Keil守编译调试，现代编辑器只接管写代码。 典型配置是VSCode+Clangd（配k2c这类工具），或者直接在VSCode/国产AI IDE里装Keil Assistant插件——这个免费插件下载量已经超过41万次，装完工程树下面直接出现编译、下载按钮，不用切回Keil。知乎成本最低，零侵入，工程、编译、烧录一切照旧。适合所有犹豫的人先走这一步。
路线B：AI混合工作流。 在路线A基础上再叠一层AI。B站有UP主把分工拆成四层：VSCode+Claude Code负责写代码，CubeMX生成工程骨架，Keil管编译交付，Git管版本。哔哩哔哩也有人用CubeIDE+VSCode联动，顺带把Claude Code接进去。知乎今年国产AI IDE（Qoder、Trae、CodeBuddy）卷得很凶，实测三款都能装上Keil Assistant，其中CodeBuddy存在编译下载图标渲染异常的兼容问题。知乎适合想立刻吃到AI编码红利、但不敢动构建链的人。
路线C：彻底迁移开源工具链。 CMake+GCC+OpenOCD，或者STM32CubeIDE+VSCode。这条路方向上确实有官方背书——有用户实测ST最新的CubeMX 2，发现它生成的只有CMake工程，判断“将来CMake+GCC+VSCode是主打方向”。知乎但现阶段坑很具体：一位真上手把项目搬到CubeIDE的开发者，列了七条罪状——调试加载比MDK慢一倍多、文件路径太长直接编译失败、工程换目录就打不开、F9打不了断点——最后原话是“我还是退回MDK+Source insight+CUBMX这个模式吧”。知乎只建议纯STM32的新项目尝试，老项目慎入。
路线D：Keil Studio（MDK v6）。 Arm官方押注的新方向，基于VSCode内核、跨平台、有免费社区版。但社区评价是“期望有点落空”：官方原说2023年底正式推出，结果端出来的仍是VSCode插件（Keil Studio pack），功能成熟度和生态厚度都还在追赶中。哔哩哔哩适合关注而不是现在All in。
迁移的真实成本，比你想的高
如果看完还是想动，先把这三笔账算清楚：
时间账： 重建构建系统（CMake/Makefile）、适配下载算法、重学调试配置，熟手也要一到两周；中途踩坑参考上面那位CubeIDE老哥的七条清单。知乎
风险账： 编译器行为差异是最隐蔽的。AC5/AC6/GCC对位域、对齐、内联的处理不完全一致，代码体积和时序都可能变。5.39那个位域bug就是例子——同一份工程，5.36正常、5.39异常。知乎换编译器等于把这个风险放大到全工程。
不可逆账： 从Keil迁出去容易，迁回难。CMake工程里的配置习惯、脚本依赖，用久了就回不去.uvprojx了。
另外提醒一句：从5.37版本开始，Keil不再默认安装AC5编译器，老工程打开报错得单独补装。知乎如果你的项目还依赖AC5，升级Keil版本前先确认这一点，别被安装教程里“一键搞定”的说法带偏。
对号入座：你到底该不该动
学生党、电赛/毕设人群： 别在比赛周期里折腾工具链。Keil+官方例程是最短路径，真想改善体验，装个Keil Assistant就是极限操作。
工业控制、商业产品工程师： 留。你的优先级是AC6的编译稳定性和项目继承，迁移成本是按回归测试的工时算的，编辑器难受就加一层VSCode，别动地基。
想提效的AI尝鲜者： 走路线B。先装Keil Assistant+AI IDE，写代码体验立刻换代，构建链一个字不碰，这是目前社区验证最多、回退成本最低的组合。
纯STM32、新项目、无历史包袱： 可以试路线C，但给自己留一条回退路线，第一个项目别上太复杂的工程结构。
等等党： 盯三个信号——CubeMX 2什么时候把CMake生成铺到更多系列、MDK5的版本更新是不是只剩修bug不再上新特性、Keil Studio商业版什么时候补齐uVision的核心调试能力。知乎这三个信号齐了，才是真正的迁移窗口。
一句话收尾：“告别Keil”喊得响，但社区用脚投票的结果从来不是卸载，而是给这个老伙计配了个新搭档。写代码的地方可以随便换，编译调试的地基，等官方自己把新路修好再搬，不迟。
