传统开发和现代开发之间，差的不是会不会写代码
我最近越来越觉得，很多人学嵌入式，问题不在于不努力，而是一开始就被带进了一条很旧的路。
最典型的情况就是：一入门就去 B 站找视频。
这件事本身没问题。视频对初学者很友好，能让人很快看到一个东西怎么跑起来，也能压住刚接触硬件、寄存器、外设、开发板时的恐惧感。问题在于，很多人找视频时不看年份，不看适合什么基础阶段，也不会判断这套教程背后的工程方式是不是已经落后。
路径依赖就这么形成了。
别人用什么软件，他就用什么软件；别人怎么建工程，他就怎么建工程；别人怎么点 Keil，他就怎么点 Keil；别人怎么复制例程，他就怎么复制例程。短期看起来是在学习，实际上很可能是在把自己训练成旧流程的执行者。
再往后，这种依赖会把人和现代开发方式直接隔开。
教程会教你怎么用，但很少教你怎么看工程
很多教学视频最大的问题，是只告诉你“怎么用”。
怎么新建工程，怎么点按钮，怎么配置外设，怎么把例程跑起来，怎么照着老师的步骤把灯点亮、把串口跑通、把屏幕刷出来。
这些东西对入门有用，但远远不够。
真正决定工程能力的，不是你能不能照着教程把某个外设跑起来，而是你能不能看懂一个项目为什么这样组织：目录为什么这么分，驱动为什么这样抽象，接口为什么这样暴露，模块之间为什么不能乱依赖。
这些视野，普通入门视频很少会给。
因为它的目标往往只是让你“跑起来”，而不是让你理解一个项目如何长期维护、如何多人协作、如何跨平台迁移、如何被工具链和 agent 接管一部分重复流程。
如果长期停留在这种学习方式里，工程能力和协作能力都会被压低。
你会很熟悉某个视频里的步骤，但离开那个模板就不会做；你能改一个例程，却不知道怎么设计模块；你能把功能堆上去，却不知道怎么控制复杂度。最后写出来的东西能跑，但不能碰。
很多传统习惯已经不适合现在了
我不是要全盘否定传统嵌入式开发。
在过去，很多习惯是有现实原因的。比如反复仿真、在 Keil 里盯寄存器、一步一步单步调试，这些在当时完全可以理解。早期开发板、芯片、下载器、调试环境都没现在这么方便，Flash 擦写次数也确实是一个需要考虑的因素。
那时候谨慎一点、慢一点、靠仿真多确认几遍，很正常。
但现在是什么年代了？
很多小工程里的静态错误、函数报错、类型问题、依赖缺失、拼写错误、配置问题，根本不需要人一直在 Keil 里来回点。你完全可以让 agent 看编译日志，让它跑静态检查，让它根据报错定位问题，再由人判断修改是否合理。
构建、检查、修明显错误，本来就应该自动化。
不是所有问题都需要上来就进仿真器，也不是所有问题都值得人肉盯寄存器。寄存器当然要会看，底层当然要懂，但不能把所有开发问题都退化成“我打开 IDE 手动调一遍”。
现代开发要做的，是把重复动作交给工具，把人放回判断层。
如果一个人一直停留在传统流程里，把大量时间消耗在低级重复劳动上，那他的工程能力提升会非常慢。因为他每天都在处理表层问题，而不是在训练自己理解结构、边界、抽象和系统。
入门视频可以看，但不能一直靠视频
入门视频可以看。
刚开始学的时候，视频能帮你建立基本直觉：开发板长什么样，工程怎么打开，代码怎么烧进去，串口怎么打印，外设怎么验证。这些东西如果完全靠文档硬啃，确实会让很多人卡在门口。
但视频只能当入口，不能当长期学习方式。
到了一定阶段之后，必须从被动看教程，切换成主动读文档、主动搭工程、主动查资料、主动设计接口。
尤其是嵌入式开发，真正重要的信息往往都在官方文档、芯片手册、SDK 说明、开源项目、构建脚本和代码结构里。只会看视频的人，很容易养成一种很危险的习惯：没有教程就不会写，没有例程就不会动，没有别人演示就不知道下一步。
这不是学习，是依赖。
现代工程师必须学会从文档开始工作。看到一个新芯片、新 SDK、新 RTOS、新库，应该能自己读说明、看示例、拆结构、建最小工程、验证接口，而不是第一反应去搜“有没有保姆级教程”。
保姆级教程看多了，人也会被养成保姆级工程师。
要从优秀开源工程里学工程
想提升工程能力，光看教程不够。优秀开源工程必须多看。
不是只看它某个函数怎么写，而是要看完整结构：项目目录怎么组织，模块怎么分层，驱动怎么抽象，接口怎么命名，平台相关代码怎么隔离，配置系统怎么处理，测试怎么放，文档怎么写，构建系统怎么把这些东西串起来。
工程能力不是单点技巧，而是一整套判断。
为什么这个模块不应该依赖那个模块，为什么这个文件应该拆出去，为什么这个接口不能暴露太多细节，为什么这个实现要留出可移植空间，为什么一个功能不能随便塞到全局变量和宏定义里，这些东西都需要长期观察、模仿、实践和复盘。
看优秀工程，本质上是在训练工程审美。
你要逐渐建立一套自己的工程准则：代码要可读，结构要清晰，接口要稳定，依赖要克制，平台差异要隔离，重复逻辑要收束，文档要能解释边界，构建要能复现。
写屎山绝对不应该被纵容。
不是说代码一开始就要完美，而是你不能把“能跑”当成唯一标准。能跑只是底线，可维护、可扩展、可协作，才是工程的要求。
软件和硬件都需要审美
我一直觉得，软件和硬件其实很像画画。
刚开始照猫画虎当然有效。别人怎么画，你先跟着画；别人怎么写工程，你先模仿；别人怎么设计电路，你先照着理解。这个阶段很正常，因为人一开始都需要参照物。
但如果想往高处走，迟早要有自己的创作和风格。
你要知道什么样的结构是干净的，什么样的接口是克制的，什么样的布局是可读的，什么样的封装是有意义的，什么样的复杂度是危险的。
这就是审美，不玄。
工程审美不是玄学。它来自大量阅读、大量实践、大量踩坑，也来自你对系统边界和长期维护成本的敏感度。
一个只会复制粘贴的人，也许能把功能堆出来，但他很难成为系统工程师。因为系统工程师要负责的不只是某一段代码能不能跑，而是整个系统能不能被理解、被维护、被扩展、被交给别人协作。
这也是我区分 CV 工程师和系统工程师的标准。
CV 工程师只关心哪里有现成代码，怎么复制过来，怎么让它先跑起来。系统工程师会关心这段代码放进来之后，项目结构会不会被污染，接口会不会变乱，依赖会不会失控，后面的人还能不能读懂。
一个在拼功能，一个在建系统。
现代开发要求人主动升级
传统开发不是完全错误，它只是有时代背景。
但如果到了现在，还把所有经验都停留在旧 IDE、旧教程、旧流程、旧例程里，那就不是“基础扎实”，而是没有升级。
现代嵌入式开发已经不只是写寄存器和调外设。它包含工具链、构建系统、文档开发、自动化测试、开源协作、架构设计、跨平台抽象，也包含 agent 介入之后的人机协作方式。
人不该被低级流程绑住。
该看视频的时候看视频，该读手册的时候读手册，该用 agent 的时候用 agent，该自己判断架构的时候自己判断。不同阶段要用不同方法，而不是拿入门阶段的方法用一辈子。
如果只满足于“我照着教程能跑”，那最多只能停留在执行层。
真正的提升，是从会用工具，到理解工程；从复制例程，到设计结构；从修局部错误，到把握系统边界；从照猫画虎，到形成自己的工程风格。
到了这一步，才能说自己不是单纯的 CV 工程师，而是在往系统工程师的方向走。