工程随笔 on Blog

华为比赛复盘：差一点赶不上飞机，也差一点打得更好

Fri, 10 Jul 2026 00:20:00 +0800

华为比赛复盘：差一点赶不上飞机，也差一点打得更好

回忆一下 7.4 的华为比赛。

事情从 7.3 晚上就开始离谱了。那天晚上十点半左右，我一度真以为自己要赶不上飞机了，结果突然发现航班延期到了第二天凌晨一点。只能说，还好还好。

本来想着到机场之后，或者上飞机之后，还能再复习一点比赛相关的东西。结果刚坐上去，整个人就被期末熬夜攒下来的疲惫直接击昏，进入昏迷模式。再醒过来的时候，已经快到南京机场了，时间差不多是凌晨两点半。

然后又出了一个很蠢的问题。

因为换了书包，我完全忘记自己昏迷前把机票和身份证塞到了哪里。下飞机之后翻了半天没找到，还以为落在飞机上了，于是在行李等候区硬等了一个小时。地勤都快劝我走了，结果我刚坐上网约车，就发现东西其实一直在书包的一个小口袋里。

只能说，人困到一定程度，智商是真的会掉线。

最后到酒店洗完澡，已经凌晨四点半了。睡了大概三个小时，第二天就直接去比赛。

比赛本身

这次华为比赛给我的第一感觉，是它比我预想中正式很多。

一开始我对这类企业比赛多少有点刻板印象，总觉得可能只是喊大学生来做点便宜方案，或者做一场偏宣传性质的活动。但实际体验下来，华为的硬件终端和赛题设计都挺认真，至少不是随便糊一个题目出来应付学生。

可惜最大的问题还是状态。

因为前面一直被期末周压着，我们其实没能充分准备。赛题整体围绕 STM32F103 开发，一个方向偏硬件，涉及激光雷达后端信号、运放和数据处理；另一个方向偏软件，主要是触控笔的无线充电和软件开发。

我们比较不幸，抽到了第一个方向。

现场十六强队伍水平都还可以，基本是 211、985 的研究生，甚至还有博士生，不少人还是 DSP、电机控制相关方向的。这个阵容放在那里，压力还是很明显的。

现场做题

第一问是恢复高电压输出。

本质上其实就是 EN 没开。那个 Boost 电路做得挺厉害，可以从 5.5V 升到 85V 左右，高压输出恢复得还算轻松。

但后面的串口打印 ADC 数据就开始卡了。

一方面是 CubeIDE 用得确实不多，临场切环境本来就不顺手；另一方面是 HAL 库的字节发送接口更偏 8bit 数据，而 ADC 返回的是 32 位结构。怎么把数据正确转换、组织、发送出去，我们现场试了几种方式都没完全打通。

这部分确实有点难受。

第二问是实现高压输出电压调节。

这个相对简单，用 PWM 模拟 DAC，影响反馈端 FB，进而调节高压输出，基本就能解决。中间还被高压电了两下，倒不是特别疼，但确实有点麻。只能说，做这种题还是要对硬件保持敬畏。

第三问是信号运放问题，要求调整输入输出，让波形尽量不失真。

这部分更能感受到课本知识和现场工程之间的差距。课本上学过运放，知道一些基本概念，但真正到了现场，要根据实际信号、实际电路、实际现象去调整，完全是另一回事。这一方面感觉还是得学一下。我们的方向其实已经找对了，只是时间不够，没能把结果继续往前推。

赛后先是下午茶和领取纪念品,之后是答辩,晚饭去园区的海底捞狠狠猪了一把,一桌900额度也可以说是吃到爽哈哈哈。

结果和复盘

整体来说，这次题目不算特别离谱，甚至可以说没有想象中那么难。但因为备赛、环境、状态这些问题叠在一起，最后结果不算理想。

说白了，还是菜。

不过没想到的是，这样最后还能拿到第六名。算下来，这应该是我目前技术比赛里拿到的最高奖项了。短时间、高压力、现场出问题的比赛，确实最能看出一个人的综合水平：基础够不够扎实，环境熟不熟，状态扛不扛得住，临场判断稳不稳，全都会暴露出来。

这次喜提 2k，虽然其中 1k 直接变成了机票钱，但至少没给实验室丢脸。

另外也认识了一些 HR，聊下来能感觉到他们确实很懂就业，也能从企业视角看到很多学生平时不太会注意的东西。这部分收获也挺重要。

总的来说，这次比赛有遗憾，但也有价值。

遗憾是明明可以打得更好，价值是它把很多短板直接摆到了面前：准备不够、工具链不够熟、临场状态不够好，对硬件题的处理经验也还不够。

就这样。

来年必须干回来。

竞赛救不了已经脱节的大学教育

Tue, 09 Jun 2026 00:00:00 +0000

竞赛救不了已经脱节的大学教育

如果认真看过《上交生存手册》，再真的在大学里感受几年，大概就很难再对大学教育抱太天真的期待。

大学教育和真实世界是脱节的。

这句话不新鲜，甚至有点像废话。可废话反复出现，往往是因为很多人明明看见了，还要装作没看见。课堂教的是一套，社会要的是另一套；考试考的是一套，工程用的是另一套；学校宣传的是一套，学生真正成长时走的又是另一套。

应用层的东西，大学往往不教，或者教得很慢、很旧、很浅。学生真想学点能用的东西，最后多半要自己去打比赛，自己去找项目，自己去看文档，自己去啃开源工程，自己把学校没给的东西补回来。

至于大学老师关不关心学生成长和发展，这就更不好说了。

当然不能一棍子打死所有人。也确实有认真负责、愿意带学生、愿意一起做事的老师。但从制度上看，很多时候教学只是 KPI，学生成长只是顺手。课上完了，表填了，项目挂了，成果有了，至于学生到底有没有长出真正的能力，那就像走廊尽头掉了一张废纸，风一吹，也就算了。

于是竞赛出现了。

学校说，这是实践。老师说，这是机会。学生说，这是简历。评奖评优说，这是指标。

听起来都合理。真往里面看，味道就不对了。

比赛本来只是手段

比赛是什么？

比赛本来应该是学习东西的一种手段。

你想学硬件，就去做一个需要硬件闭环的题；你想学算法，就去做一个需要建模和优化的问题；你想学工程，就去做一个需要多人协作、调试、复盘、交付的项目。比赛把时间压紧，把目标摆出来，把外部压力加上去，让人不得不往前走。

这本来是好事。可学校最擅长的，就是把手段变成目的。

当比赛成绩和评奖评优、奖学金、保研、综测、荣誉称号全部挂钩之后，比赛就不再只是学习手段了。它变成了一张票，一块牌子，一个可以塞进表格里的证明。

人也就变了。

原本应该问“我从这个比赛里学到了什么”，现在变成“这个比赛能不能加分”；原本应该问“这个问题有没有真实价值”，现在变成“这个奖够不够高”；原本应该问“我是不是做出了真正的东西”，现在变成“证书能不能拍照发朋友圈”。

很难想象，体育竞技圈里那些烂风气，换了一层皮之后，竟然还能在大学里活得这么滋润。

唯成绩论，唯名次论，唯奖项论。

像一群人围着一只破钟敲，敲得越响，越以为自己掌握了时间。

这当然不是某一个学生的问题，而是整套评价体系的问题。它鼓励人去争结果，而不鼓励人去理解过程；它奖励站上台的人，却很少关心这个人到底有没有长出真实能力。

内卷并不是大家都很努力。很多时候，内卷只是大家一起被一套低劣指标赶着跑。

技术比赛的问题

大学生竞赛大体可以分成两类：技术比赛和商赛。

先说技术类比赛。

很多技术比赛最初的出发点并不坏。协会办比赛，学校组织学生参与，企业提供一点支持，学生通过赛题接触工程、硬件、算法、系统设计，这些都说得过去。

问题在于，很多比赛办了几十年，赛题变化不大，组织方式变化不大，评价方式变化也不大。

更现实的是，很多比赛如果没有商业成分，就很难继续办下去。教育系统本身未必愿意长期稳定地投入足够资源，于是比赛要活下去，就要宣传，要招商，要扩大规模，要降低门槛，要让更多人参与进来。

听起来像繁荣，实际很容易变成另一种泡沫。

人越来越多，赛题越来越熟，套路越来越固定。前人把资料留下来，后人照着做；上一届调出来的车，下一届继续改；上一届写过的报告，下一届换个壳；上一届踩过的坑，下一届干脆不踩，因为学长已经把坑填成了路。

路径依赖也就出现了。

很多比赛到最后，不再像是在解决问题，而像是在背诵题型。只要掌握最简单的入门套路，就能上手；只要学校传承足够强，就能少走很多弯路；只要资源足够集中，就能把新人迅速塞进一条已经铺好的流水线。

这当然能学到东西。问题是，它离真实工作需求常常差得很远。

真实工程不会因为你只会某一套赛题就迁就你。真实项目不会因为你拿过奖就自动变得清晰。真实公司要看的也不是你在一个固定题型里训练了多久，而是你能不能理解需求、拆分系统、设计接口、控制复杂度、定位问题、协作交付。

很多人打比赛打久了，会产生一种很危险的幻觉：我很强。

但如果真的拿自己的简历去对照一线厂商的社招要求，就会发现另一件事：自己学的东西，甚至不一定配入围。

这话难听，但真实。

会调一个比赛车，不等于懂嵌入式系统；会堆一套算法，不等于懂工程；会写一份漂亮报告，不等于能交付产品；拿了奖，不等于有能力。

奖项有时候只是奖项。 它能证明你在某个规则里赢过，却不能证明你在真实问题里站得住。

备赛越长，越容易变成无意义内卷

尤其是备赛周期很长的比赛，问题会更明显。

如果一个比赛需要长期占用学生大量时间，而它本身又不能持续把学生逼向更真实、更开放、更复杂的问题，那它最后就很容易变成一场消耗战。

谁投入时间更多，谁传承资料更多，谁学校资源更集中，谁老师更愿意押，谁队伍更早开始卷，谁就更占便宜。

这当然也是竞争。但这种竞争未必产生更好的工程师，反而可能生产出一批熟悉比赛规则、却不熟悉真实工程的人。

他们知道怎么冲奖，却不知道怎么建系统；知道怎么包装成果，却不知道怎么复盘失败；知道怎么把报告写得漂亮，却不知道代码为什么越来越烂。

更麻烦的是，学校分层和传承分层会越来越明显。

强校有成熟队伍，有学长资料，有老师资源，有实验室设备，有固定训练流程。弱一些的学校只能从零开始，学生靠热情硬撞。表面上大家都在同一个赛场，实际上起跑线早就分成了许多层。

最后比赛成绩又反过来变成评价学生的指标。

这就像先把路修得高低不平，再夸跑得快的人天赋异禀。

孔乙己式的竞赛幻觉

竞赛最可怕的副作用之一，是它会给人制造一种体面的幻觉。

证书挂在墙上，奖项写进简历，老师在群里表扬，学院公众号发推文，照片里大家捧着奖杯，像是终于从庸常的大学生活里爬出来了一点。

有些人爬出来的，不是能力，而是幻觉。

他们像孔乙己一样，抓着几张纸，便以为自己有了身份。别人问真实工程经验，便说我拿过国奖；别人问系统设计能力，便说我做过某某比赛；别人问代码质量、可维护性、团队协作，便把证书又往桌上一拍。

仿佛证书上的红章，可以替他解释一切。可工程不认这个。

工程只认结构，认结果，认边界，认长期维护，认真实复杂度。代码烂就是烂，接口乱就是乱，模块耦合就是耦合，调不出来就是调不出来。

比赛给你的名次，遮不住工程里的洞。

很多人最需要警惕的，不是没拿奖，而是拿了奖以后误以为自己已经足够强。

能力幻觉，比能力不足更危险。

能力不足的人还有机会学。能力幻觉里的人，往往已经不觉得自己需要学了。

商赛更像 PPT 剧本杀

商赛的问题，我其实懒得多说。

因为喷的人已经够多了。

很多商赛说是创新创业，实际更像 PPT 剧本杀。故事要完整，痛点要巨大，市场要广阔，模式要新颖，融资要漂亮，最后再补几张看起来很努力的团队照片。

至于东西能不能做出来，用户是不是真的需要，商业逻辑能不能闭环，技术壁垒是不是真的存在，很多时候都不重要。

重要的是它像不像一个项目。

更讽刺的是，这类比赛往往很适合成为保研人的游戏、老师升职称的工具、学院宣传的材料。学生得到了奖项，老师得到了成果，学院得到了新闻，评审得到了一个看起来热闹的现场。

大家各取所需，只有真实价值被放在桌子底下。

当然，也不是所有商赛都没有意义。有人确实能在里面练表达、练调研、练组织、练商业分析。但问题在于，当一个体系鼓励人用漂亮叙事替代真实产品，用精致包装替代真实验证，那它天然就会长出一股虚浮气。

这股气闻久了，人会以为自己真的在创业。

我不是反对一切竞赛

我不是反对一切竞赛。

竞赛当然可以有价值。一个好的比赛，应该把人逼向真实问题：逼你读文档，逼你做实验，逼你复盘失败，逼你协作，逼你交付，逼你发现自己不会的东西。

这种比赛值得打。但干什么都要衡量成本。

你为了一个比赛投入了多少时间？这些时间换来了什么？是能力、经验、视野、工程习惯，还是只有一张证书？它有没有让你更接近真实问题？有没有让你建立自己的技术体系？有没有让你看到自己的短板？

如果没有，那就要小心。

竞赛崇拜是一件很恶心的事。

因为它把复杂的成长，压扁成一个名次；把真实的能力，压扁成一张证书；把人的发展，压扁成综测表格里的几行字。

更可笑的是，很多人明明知道大学教育已经崩得差不多了，却还指望它自然长出冰清玉洁的大学生竞赛。

这不现实。

一个已经脱节的教育制度，不可能凭空生产出完全纯净、完全高效、完全面向真实价值的竞赛体系。它最多只能在一堆混乱里，留下一些相对还能用的东西。

所以我对大部分大学生竞赛的看法很简单：没那么屎，但还是屎。

它能让你在一堆屎里显得不那么臭，却不能自动让你产生真正的技术价值。

真正的技术价值，还是要回到真实问题里。

回到工程，回到系统，回到文档，回到代码，回到调试，回到长期维护，回到和真实复杂度的正面对抗。

如果比赛能带你走到那里，它就是工具。如果比赛只让你沉迷证书、名次、宣传稿和虚荣心，那它就是另一种牢笼。

最后还是要拿真实市场检验

所以最后的问题又回到自己身上：到底应该怎么提升？

我觉得答案很朴素，也很残酷。

去看招聘公司怎么写要求，去看真实岗位需要什么能力，去看一线厂商的校招、实习、社招 JD，再回头看看自己的简历。

简历不会骗人。

你会什么，不会什么，做过什么，没做过什么，项目有没有深度，工程有没有复杂度，代码有没有长期维护价值，面试官一问就知道。你可以在学校里用奖项包装自己，可以在综测表里显得很好看，可以在学院新闻里站在第一排，但到了招聘市场上，很多幻觉都会被打碎。

offer 也不会骗人。

能不能拿到面试，能不能通过技术面，能不能解释清楚自己的项目，能不能把底层原理、工程结构、问题定位、取舍判断讲明白，这些比任何自我感动都直接。

招聘市场当然也不完美，也有学历筛选、信息差、运气、岗位波动和各种不公平。但它至少比学校里很多自娱自乐的评价体系更接近真实需求。

公司要的是能解决问题的人。

不是只会背教程的人，不是只会复用比赛传承的人，不是只会把奖项挂在嘴边的人，也不是只会写漂亮 PPT 的人。

所以提升自己，不能只围着比赛转。

应该反过来，用真实岗位要求倒逼自己补能力：缺工程结构，就去看优秀开源工程；缺底层理解，就去啃手册、啃启动流程、啃调试原理；缺工具链能力，就去学构建系统、脚本、自动化、CI；缺协作能力，就去参与真实项目，学会写文档、写接口、做复盘。

比赛可以是材料，但不能是核心信仰。

真正有用的成长路径，是让自己的能力能穿过学校评价体系，继续在真实工程和真实招聘里站得住。

如果一个奖项只能在学校里有用，出了校门就解释不清，那它的价值就要打折。

如果一个项目能让你在面试里讲清楚系统设计、技术难点、失败复盘、工程取舍，并且经得起追问，那它就算没有奖，也比一堆空心证书更值钱。

最后检验人的，不是证书墙，而是你能不能把自己交到真实问题面前。

人最怕的不是没有路。

人最怕的是站在笼子里，还把栏杆当成奖杯。

传统开发和现代开发之间，差的不是会不会写代码

Mon, 01 Jun 2026 00:00:00 +0000

传统开发和现代开发之间，差的不是会不会写代码

我最近越来越觉得，很多人学嵌入式，问题不在于不努力，而是一开始就被带进了一条很旧的路。

最典型的情况就是：一入门就去 B 站找视频。

这件事本身没问题。视频对初学者很友好，能让人很快看到一个东西怎么跑起来，也能压住刚接触硬件、寄存器、外设、开发板时的恐惧感。问题在于，很多人找视频时不看年份，不看适合什么基础阶段，也不会判断这套教程背后的工程方式是不是已经落后。

路径依赖就这么形成了。

别人用什么软件，他就用什么软件；别人怎么建工程，他就怎么建工程；别人怎么点 Keil，他就怎么点 Keil；别人怎么复制例程，他就怎么复制例程。短期看起来是在学习，实际上很可能是在把自己训练成旧流程的执行者。

再往后，这种依赖会把人和现代开发方式直接隔开。

教程会教你怎么用，但很少教你怎么看工程

很多教学视频最大的问题，是只告诉你“怎么用”。

怎么新建工程，怎么点按钮，怎么配置外设，怎么把例程跑起来，怎么照着老师的步骤把灯点亮、把串口跑通、把屏幕刷出来。

这些东西对入门有用，但远远不够。

真正决定工程能力的，不是你能不能照着教程把某个外设跑起来，而是你能不能看懂一个项目为什么这样组织：目录为什么这么分，驱动为什么这样抽象，接口为什么这样暴露，模块之间为什么不能乱依赖。

这些视野，普通入门视频很少会给。

因为它的目标往往只是让你“跑起来”，而不是让你理解一个项目如何长期维护、如何多人协作、如何跨平台迁移、如何被工具链和 agent 接管一部分重复流程。

如果长期停留在这种学习方式里，工程能力和协作能力都会被压低。

你会很熟悉某个视频里的步骤，但离开那个模板就不会做；你能改一个例程，却不知道怎么设计模块；你能把功能堆上去，却不知道怎么控制复杂度。最后写出来的东西能跑，但不能碰。

很多传统习惯已经不适合现在了

我不是要全盘否定传统嵌入式开发。

在过去，很多习惯是有现实原因的。比如反复仿真、在 Keil 里盯寄存器、一步一步单步调试，这些在当时完全可以理解。早期开发板、芯片、下载器、调试环境都没现在这么方便，Flash 擦写次数也确实是一个需要考虑的因素。

那时候谨慎一点、慢一点、靠仿真多确认几遍，很正常。

但现在是什么年代了？

很多小工程里的静态错误、函数报错、类型问题、依赖缺失、拼写错误、配置问题，根本不需要人一直在 Keil 里来回点。你完全可以让 agent 看编译日志，让它跑静态检查，让它根据报错定位问题，再由人判断修改是否合理。

构建、检查、修明显错误，本来就应该自动化。

不是所有问题都需要上来就进仿真器，也不是所有问题都值得人肉盯寄存器。寄存器当然要会看，底层当然要懂，但不能把所有开发问题都退化成“我打开 IDE 手动调一遍”。

现代开发要做的，是把重复动作交给工具，把人放回判断层。

如果一个人一直停留在传统流程里，把大量时间消耗在低级重复劳动上，那他的工程能力提升会非常慢。因为他每天都在处理表层问题，而不是在训练自己理解结构、边界、抽象和系统。

入门视频可以看，但不能一直靠视频

入门视频可以看。

刚开始学的时候，视频能帮你建立基本直觉：开发板长什么样，工程怎么打开，代码怎么烧进去，串口怎么打印，外设怎么验证。这些东西如果完全靠文档硬啃，确实会让很多人卡在门口。

但视频只能当入口，不能当长期学习方式。

到了一定阶段之后，必须从被动看教程，切换成主动读文档、主动搭工程、主动查资料、主动设计接口。

尤其是嵌入式开发，真正重要的信息往往都在官方文档、芯片手册、SDK 说明、开源项目、构建脚本和代码结构里。只会看视频的人，很容易养成一种很危险的习惯：没有教程就不会写，没有例程就不会动，没有别人演示就不知道下一步。

这不是学习，是依赖。

现代工程师必须学会从文档开始工作。看到一个新芯片、新 SDK、新 RTOS、新库，应该能自己读说明、看示例、拆结构、建最小工程、验证接口，而不是第一反应去搜“有没有保姆级教程”。

保姆级教程看多了，人也会被养成保姆级工程师。

要从优秀开源工程里学工程

想提升工程能力，光看教程不够。优秀开源工程必须多看。

不是只看它某个函数怎么写，而是要看完整结构：项目目录怎么组织，模块怎么分层，驱动怎么抽象，接口怎么命名，平台相关代码怎么隔离，配置系统怎么处理，测试怎么放，文档怎么写，构建系统怎么把这些东西串起来。

工程能力不是单点技巧，而是一整套判断。

为什么这个模块不应该依赖那个模块，为什么这个文件应该拆出去，为什么这个接口不能暴露太多细节，为什么这个实现要留出可移植空间，为什么一个功能不能随便塞到全局变量和宏定义里，这些东西都需要长期观察、模仿、实践和复盘。

看优秀工程，本质上是在训练工程审美。

你要逐渐建立一套自己的工程准则：代码要可读，结构要清晰，接口要稳定，依赖要克制，平台差异要隔离，重复逻辑要收束，文档要能解释边界，构建要能复现。

写屎山绝对不应该被纵容。

不是说代码一开始就要完美，而是你不能把“能跑”当成唯一标准。能跑只是底线，可维护、可扩展、可协作，才是工程的要求。

软件和硬件都需要审美

我一直觉得，软件和硬件其实很像画画。

刚开始照猫画虎当然有效。别人怎么画，你先跟着画；别人怎么写工程，你先模仿；别人怎么设计电路，你先照着理解。这个阶段很正常，因为人一开始都需要参照物。

但如果想往高处走，迟早要有自己的创作和风格。

你要知道什么样的结构是干净的，什么样的接口是克制的，什么样的布局是可读的，什么样的封装是有意义的，什么样的复杂度是危险的。

这就是审美，不玄。

工程审美不是玄学。它来自大量阅读、大量实践、大量踩坑，也来自你对系统边界和长期维护成本的敏感度。

一个只会复制粘贴的人，也许能把功能堆出来，但他很难成为系统工程师。因为系统工程师要负责的不只是某一段代码能不能跑，而是整个系统能不能被理解、被维护、被扩展、被交给别人协作。

这也是我区分 CV 工程师和系统工程师的标准。

CV 工程师只关心哪里有现成代码，怎么复制过来，怎么让它先跑起来。系统工程师会关心这段代码放进来之后，项目结构会不会被污染，接口会不会变乱，依赖会不会失控，后面的人还能不能读懂。

一个在拼功能，一个在建系统。

现代开发要求人主动升级

传统开发不是完全错误，它只是有时代背景。

但如果到了现在，还把所有经验都停留在旧 IDE、旧教程、旧流程、旧例程里，那就不是“基础扎实”，而是没有升级。

现代嵌入式开发已经不只是写寄存器和调外设。它包含工具链、构建系统、文档开发、自动化测试、开源协作、架构设计、跨平台抽象，也包含 agent 介入之后的人机协作方式。

人不该被低级流程绑住。

该看视频的时候看视频，该读手册的时候读手册，该用 agent 的时候用 agent，该自己判断架构的时候自己判断。不同阶段要用不同方法，而不是拿入门阶段的方法用一辈子。

如果只满足于“我照着教程能跑”，那最多只能停留在执行层。

真正的提升，是从会用工具，到理解工程；从复制例程，到设计结构；从修局部错误，到把握系统边界；从照猫画虎，到形成自己的工程风格。

到了这一步，才能说自己不是单纯的 CV 工程师，而是在往系统工程师的方向走。

Agent 做嵌入式，核心还是把硬件开发接成 API

Wed, 20 May 2026 00:00:00 +0000

Agent 做嵌入式，核心还是把硬件开发接成 API

最近折腾嵌入式工具链，我越来越确定一件事：agent 想真正参与嵌入式开发，光会写几行 C 代码没用。硬件开发里那些原本靠人手操作、靠 IDE 点按钮、靠经验猜的动作，得先变成它能调用的接口。

说白了，要给 agent 一套清楚的 API。

这里的 API 不一定是传统软件接口。构建、烧录、调试、寄存器读写、日志抓取，这些命令本身就可以是接口。只要它们稳定、可复现、能组合，agent 就能接进来。

我现在看工具链，最看重这一点：硬件开发必须先 CLI 化，然后才谈得上 agent 化。

把硬件能力暴露出来

传统嵌入式开发把很多能力藏起来了。

烧录藏在 IDE 的按钮后面，调试藏在某个工程配置里，芯片连接状态藏在调试器窗口里，寄存器值藏在图形界面的某个面板里。人当然可以点开看，但这些东西对 agent 来说几乎是黑箱。

一个动作只能靠人点按钮，就很难自动化，也很难复盘。按钮按下去之后发生了什么，参数是什么，失败原因在哪里，日志去哪儿了，很多时候没人说得清。

写成命令之后，事情就不一样了。

比如通过 DAPLink 和 OpenOCD 接入硬件，把连接、烧录、复位、寄存器访问这些动作都暴露成命令行：

1

openocd -f interface/cmsis-dap.cfg -f target/stm32f1x.cfg

再通过 telnet 或者 gdb 接进去，执行 mdw、mww 这类命令读写寄存器：

1
2
3


telnet localhost 4444
mdw 0x40021000
mww 0x40021018 0x00000004

到这一步，寄存器就不只是 IDE 面板里给人看的值了。它可以被命令读出来，被日志记下来，被脚本检查，也能被 agent 调用。

我认为这才是 agent 接入嵌入式的方向。

不是让它隔着一层 GUI 猜你现在点到了哪里，而是给它明确的工程入口：怎么构建，怎么烧录，怎么连接芯片，怎么读寄存器，怎么判断失败，怎么把结果反馈回来。

传统嵌入式很难自然接收到这些东西

我现在回头看，很多传统嵌入式开发者不是能力不行，而是知识结构被旧开发方式卡住了。

很多人学嵌入式，从单片机、寄存器、外设、手册、例程、IDE 开始。这条路没问题，底层基础也重要。但如果一直停在“我会配寄存器、我会调外设、我会移植库”，就会错过现代工程真正变掉的部分。

现在的重点已经不只是会不会点亮一个外设，而是你能不能把这个动作组织成可维护的系统。

工程结构怎么设计，构建系统怎么统一，调试链路怎么复现，文档怎么沉淀，接口怎么暴露给机器，流程怎么交给 agent 执行，这些东西不是传统嵌入式课本会系统教你的。

所以知识面必须往外扩。

只盯着底层是不够的。你还得理解 CLI、脚本、构建系统、自动化、日志、测试、文档、agent 工作流，甚至要理解一点现代软件工程里的架构和协作方式。因为这些东西加在一起，才决定一个项目能不能长期扩展，而不是只决定某一块板子今天能不能跑起来。

提升工程能力不是课本学习

我现在越来越觉得，工程能力不是把课本从第一页啃到最后一页啃出来的。

课本会给你基础，手册会告诉你寄存器，数据结构和操作系统会给你底层概念，这些当然都要学。但真正让人产生工程能力的，往往是你在真实项目里不断遇到混乱，然后逼自己把混乱整理成结构。

不是所有东西都值得从最底层重新推一遍。

现在有 agent，很多重复工作完全可以交出去。查资料、补脚本、整理命令、定位明显错误、生成模板、做初步排查，这些事情如果还全靠人肉硬扛，本质上是在浪费生产力。

你可以借助 agent debug，也应该这么做。

但这不代表人就可以不懂原理。恰恰相反，agent 介入之后，人更应该把精力放到更高层、更关键的位置：判断它给出的方向对不对，判断模块边界合不合理，判断问题到底是工具链、驱动、时序、内存、任务调度，还是硬件本身。

工具越强，人越不能只当执行者。

Agent 的边界也很明显

agent 很适合处理局部问题，尤其是上下文边界清楚的问题。

一个模块报错，一个脚本跑不通，一个寄存器值异常，一个构建依赖缺失，只要你给它足够明确的命令、日志和背景，它确实可以很快帮你推进。

但当项目规模变大，问题就不是这么简单了。

一万行代码的时候，agent 还能大概读懂项目结构，顺着日志和模块关系做一些推断。可当代码从一万行变成十万行，外设、驱动、协议、任务、状态机、硬件版本、上位机、测试脚本全都搅在一起的时候，它就很容易吃不下。

它不是不会写代码，是上下文有限。

一个复杂嵌入式项目真正难的地方，往往不在某一行代码怎么改，而在整体结构为什么会变成这样。哪个模块本来就不该这样依赖，哪个接口从一开始就设计错了，哪个状态机迟早会失控，哪个底层时序问题会被上层逻辑掩盖，这些判断很难只靠短上下文推出来。

这就是人还不能退场的地方。更准确地说，是有工程经验、懂底层原理、也懂架构设计的人不能退场。

人应该站在更高的位置

所以我现在看 agent 做嵌入式：它不是万能程序员，也不是底层工程师的替代品。它更像一个能执行大量明确工程动作的协作者。

前提是人先把动作整理出来。

你要给它命令，给它接口，给它文档，给它边界，给它可以验证的结果。DAPLink、OpenOCD、CMake、Ninja、GDB、日志系统、测试脚本，这些都不是孤立工具，而是把硬件开发变成可调用流程的组成部分。

真正有价值的工程师，不是守着旧 IDE 和旧流程证明自己会吃苦，而是能把这些东西组织成系统。

该深耕原理的时候要深耕。总线、寄存器、启动流程、异常、中断、调度、内存、时序，这些东西决定你在关键问题上能不能看穿本质。

但也不能只深耕底层。只会底层，不懂工程组织，不懂工具链，不懂现代协作方式，也会被时代甩开。

最重要的还是紧跟潮流，多学一点，把知识面撑开。工程能力不是把自己锁在某个知识点里死磕，而是在真实变化里更新工具、方法和判断。

agent 时代的嵌入式开发，不是人退场，而是人要站到更高的位置。

底层能力要有，架构判断要有，工具链也要能被机器调用。只有这样，agent 才不是一个会胡乱补代码的玩具，而是真的能进入硬件开发流程，成为工程系统的一部分。

工具链搭建完成

Mon, 18 May 2026 00:00:00 +0000

工具链搭建完成

这段时间主要在折腾自己的嵌入式工具链。到 5.18 这一天，基本可以算是阶段性搭建完成了。

以前做嵌入式，很多流程其实是被厂商 IDE、图形配置工具和各种零散脚本拖着走。能跑是能跑，但每次换平台、换板子、换环境，都像是在重新和工具链打一架。现在我更想把这些东西统一到一套可复现、可调用、可交给 agent 执行的流程里：构建、烧录、检查、日志、错误定位，都尽量走明确的命令和工程结构。

这次最重要的成果，是测试成功了两条 ARM 架构相关的烧录链路。

一条是经典的 STM32F1。这基本算是我最熟悉的一类 MCU，也是很多嵌入式开发者绕不开的起点。能把它从传统开发方式里抽出来，用现代一点的工程结构完成构建和烧录，对我来说像是把老朋友重新接进新的工作流。

另一条是 TI MSPM0。相比 STM32F1，它更像是一个新的切入点：同样是 ARM 生态，但厂商工具、SDK 组织方式、烧录链路和调试习惯都不完全一样。把 MSPM0 也跑通，说明这套工具链不是只为某一个芯片临时拼出来的，而是有机会扩展成更通用的嵌入式开发底座。

从结果看，STM32F1 和 MSPM0 两边都能完成烧录验证，这件事让我很兴奋。工程流开始从“某个项目能跑”变成“某类流程能复用”。只要构建、烧录、调试这些基础动作足够稳定，后面再接入更多芯片、板卡和模板，就不用每次都从一片混乱里重新开始。

下一步：认识 Zephyr

工具链跑通之后，我开始对 Zephyr 这个 RTOS 产生兴趣。

以前接触 RTOS，更多是从裸机工程往上加：任务、调度、信号量、队列、驱动抽象，一层一层把东西堆起来。这样学很扎实，但也容易停留在“我会移植一个系统”或者“我会用一套接口”的阶段。

Zephyr 给我的感觉不太一样。它不像只是一个单纯的内核，更像一整套面向现代嵌入式工程的系统：设备树、配置系统、构建系统、驱动模型、板级支持、跨平台抽象，这些东西组合在一起，才接近我想理解的“工程化嵌入式”。

我想认识它，不只是为了会用一个新的 RTOS，而是想看看成熟的嵌入式系统到底怎么组织复杂性。为什么它能支持那么多板子，为什么驱动可以被抽象成统一模型，为什么配置和构建能被系统化管理，这些问题都值得拆开看。

工具链搭好只是第一步。烧录跑通代表入口打通了，有意思的事情还在后面：把底层硬件、构建系统、RTOS 思想和 agent 工作流接到一起，形成一套自己能长期维护、长期扩展的嵌入式工程体系。

这是我接下来想继续推进的方向。

项目开始搭建的初衷

Wed, 29 Apr 2026 00:00:00 +0000

项目开始搭建的初衷

这个项目一开始就不是为了再造一个传统意义上的“开发环境”。如果只是把一堆功能塞进 GUI，再让人用鼠标点来点去，那还是旧时代的工作流：人围着工具转，工具把复杂性包装成按钮，再把大量重复劳动丢回给人。

在 agent 发展这么快的现在，还继续把核心开发流程绑死在传统 IDE 和图形界面里，我真的觉得有点太傻逼了。不是说 GUI 没有价值，调试、观察、配置、可视化这些场景当然需要图形界面；但高频、可组合、可自动化、可复现的工程动作，就应该下沉到 CLI。

因为 CLI 才是能被脚本调用、能被日志记录、能被流水线复现、也能被 agent 理解和执行的接口。一个按钮点下去发生了什么，人都未必记得清楚；但一条命令、一组参数、一次输出，却可以被保存、复盘、组合，甚至交给智能体继续扩展。

这也是我开始搭这个项目的原因：我不想再做一个只能服务于人的工具，而是想做一个人和 agent 都能调用的工程系统。

为什么不是传统 IDE 思路

传统 IDE 的问题不在于它弱，而在于它把太多能力锁在界面里。很多时候，配置藏在窗口深处，构建藏在菜单后面，调试流程依赖某个工程文件，换一台机器就开始各种玄学报错。人在这种体系里做久了，会误以为“开发”就是打开软件、配置路径、点按钮、等结果。

现代工程不应该这样。它应该像一套可描述的协议：初始化怎么做，依赖怎么检查，项目怎么生成，固件怎么构建，产物在哪里，失败原因怎么定位，下一步怎么恢复。这些动作都应该可以被明确表达，而不是依赖某个人记住某个软件里第几个选项该怎么点。

agent 出现之后，这个问题被放大了。一个只能靠人肉点按钮推进的工程，对 agent 来说几乎就是黑箱；一个由 CLI 暴露能力的工程，才有机会被智能体接管、协作和扩展。

写成 skill，让 agent 真正会用

所以这个项目从一开始就应该围绕 CLI 搭，而不是围绕界面搭。CLI 是底座，文档是说明书，skill 负责把经验、约束和操作流程封装给 agent。

普通文档是写给人看的，skill 更像是写给智能体看的工程手册。它不只是告诉 agent “这个项目能干什么”，还要告诉它：

什么时候应该使用这个工具；
先检查哪些环境和依赖；
常用命令是什么；
出错时应该看哪些日志；
哪些操作不能乱做；
什么结果才算真的成功。

这样一来，agent 就不是在项目里盲人摸象，而是能按流程做事。人负责判断方向、定义边界、审查结果；agent 负责执行重复流程、补全文档、检查环境、跑构建、定位错误。这个分工才符合现在的生产力水平。

人该做更高层的事

我越来越不想把时间浪费在那些低级重复劳动上。路径错了、依赖缺了、命令忘了、工程模板又要重新配一遍，这些事情做一次是学习，做十次就是惩罚。它们不应该继续占用人的主要精力。

值得人做的，是判断项目应该抽象成什么结构，哪些流程必须稳定，哪些接口要暴露给机器，哪些经验应该沉淀成 skill。人不该只是代码搬运工，而是工作流设计者。

这也是我对这个项目的期待：它不是某个单点工具，而是一套面向未来工程协作方式的底座。它应该先服务 CLI，再服务 agent，最后反过来让人从大量重复流程里解放出来。

以后开发一个项目，不应该再是“打开某个 IDE，然后靠记忆点一堆按钮”。更合理的方式应该是：给出目标，让 agent 调用 skill，由 CLI 执行确定的工程动作，最后把结果、日志和问题反馈回来。

这是我想要的开发方式。

不是人被工具驯化，而是工具被组织成系统；不是让 agent 假装全能，而是把工程流程写到它真的能调用的位置。