Agent on Blog

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

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 才不是一个会胡乱补代码的玩具，而是真的能进入硬件开发流程，成为工程系统的一部分。

项目开始搭建的初衷

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 假装全能，而是把工程流程写到它真的能调用的位置。