我先把丑话说在前面这篇不是劝人转行的鸡血文是我自己踩完坑之后的一份复盘。我在一家通信设备公司做了三年多软件测试写过接口自动化脚本、跑过性能压测、维护过一堆回归用例结果业务线调整我成了那个多余的人。空窗整整一年简历投出去大部分石沉大海偶尔有面试聊到一半对方就发现我对硬件、对底层几乎一无所知。后来我把方向从纯软件测试挪到嵌入式机器人芯片测试用15天集中补课才把面试这条路重新打通。这15天我啃的东西其实就五块C语言和硬件基础、ROS2、物联网通信、单片机开发再加上芯片测试本身的流程和嵌入式AI部署。听起来挺唬人但拆开看每天的任务量并不夸张关键是顺序不能乱乱了就会像我第一次那样装完ROS2发现连C指针都写不利索纯属浪费时间。下面我把每天干什么、装过哪些环境、写过哪些脚本、面试被问到什么、哪些弯路完全没必要走全都摊开讲。你要是测试岗出身想往硬件和机器人方向挪或者还在学校里想搞明白这条路到底要学什么这篇应该能帮你省下至少半个月。1. 15天转型路线怎么排先搞清楚目标岗位到底考什么1.1 把嵌入式机器人芯片测试拆成可练的技能块这个岗位名字很长其实它是一组技能的交集不是一个单一技能。我当时的做法是去招聘网站上把相关岗位的描述抓下来大概看了四十多条把高频词做了个词频统计。出现的顺序大致是这样的C语言基础、Linux常用命令、单片机/嵌入式开发、通信协议UART/I2C/SPI/CAN、ROS2、自动化测试框架、Python脚本、芯片测试流程、AI模型部署。统计完我心里就有底了软件测试的那部分能力用例设计、缺陷跟踪、自动化框架搭建、日志分析我是现成的缺的是右边那一半硬件和系统层的东西。所以15天不该平均用力而应该把时间压在我最缺、且面试一定问的几块上。我最后定下来的权重是这样分配的C与硬件基础占3天ROS2占4天单片机与物联网占3天芯片测试流程占3天AI部署和简历面试占2天。这个分配不是拍脑袋逻辑是——C和硬件是地基没它后面全白搭ROS2是机器人测试岗的门票必须能说出所以然单片机和物联网是证明你真的碰过硬件而不是纸上谈兵芯片测试流程是岗位的核心业务面试官一定会问AI部署是加分项能让你从一群候选人里冒出来。提示不要先学ROS2。我第一轮就是这么干的装完Jazzy、跑通talker/listener自我感觉良好结果面试官问你怎么用C写一个发布者、内存怎么管理的当场哑火。1.2 15天时间表与每天的产出物光有计划没用必须有产出物否则学完就忘。我给自己定的规矩是每天结束前必须往GitHub上推一次代码或者一份笔记哪怕只有几十行。天数主线任务当天必须交出的产出物第1天C语言速过指针、结构体、内存布局手写一个环形缓冲区并跑通第2天Linux命令、进程线程、文件IO一个能抓串口日志并落盘的Python脚本第3天通信协议原理UART/I2C/SPI/CAN用逻辑分析仪或示波器抓一次UART波形第4天ROS2安装与核心概念跑通官方demo能解释节点与话题第5天ROS2通信机制与QoS一个自定义消息包能收发第6天ROS2测试工具链用launch_testing写一条自动化用例第7天TF2、URDF、rviz2用rviz2显示一个自己写的URDF第8天单片机最小系统与烧录点亮LED并串口打印第9天中断、定时器、ADC做一个电压采集并通过串口上传第10天物联网链路MQTT数据上报到本地broker并能订阅第11天芯片测试基础CP/FT/SLT一份测试流程梳理笔记第12天边界扫描、JTAG/SWD、OpenOCD用OpenOCD真的连上一次目标板第13天嵌入式AI部署量化与推理把一个小模型跑在开发板上第14天简历重写与项目包装简历改到第二版第15天模拟面试与查漏补缺三份不同岗位的面试问题清单这张表看着密其实每天有效学习时间也就六到八小时。真正让我效率翻倍的是产出物这一列——你只要想着今天必须交东西就不会陷在再看一个教程的循环里。1.3 为什么先补C和硬件而不是先补框架软件测试出身的人有个通病习惯从框架和工具入手因为上手快、反馈明显。但嵌入式这套东西不一样工具是长的在语言和硬件之上的。举个最直白的例子ROS2里一个订阅回调为什么会丢消息答案往往不在ROS2本身而在你的回调执行时间太长、队列深度不够或者QoS配置不匹配。这些都是C层面的问题。再比如面试官问你怎么测一个CAN报文你如果说用工具抓包看看那是初级答案如果说先看波特率与采样点是否匹配、再看ID过滤和掩码配置、最后做总线负载压测和错误帧注入那才是他们想听的。这些判断全部来自对硬件和协议的理解跟你会不会用某个软件没关系。所以我把前三天全部押在C和硬件上宁可ROS2晚一天开始。回头看这三天是我整个15天里性价比最高的。2. 环境搭建把工具链和编辑器磨顺手能省一半时间2.1 开发环境清单与选型逻辑环境这块我踩的坑最多单独拎出来讲一节。核心思路是开发环境要能同时搞定写上位机脚本和调嵌入式代码两件事别装两套。我的主力组合是VSCode加一套插件配合命令行工具。VSCode的好处是既能写Python脚本做自动化又能通过插件连远程Linux、开串口终端、管理PlatformIO工程一个窗口全包。CLion我也装过代码重构和索引确实更强但配置嵌入式调试链路OpenOCD GDB CMake比较折腾15天的时间预算下我没必要为了重构功能去啃它。VSCode里我实际常用的是这几个C/C做代码跳转和补全clangd作为补充比C/C扩展的索引快一些Python写测试脚本CMake Tools跑构建ROS做话题和节点可视化PlatformIO IDE管单片机工程Serial Monitor看串口日志GitLens看提交历史。注意C/C扩展和clangd同时开容易打架出现跳转跳错地方的情况。我的做法是二选一做ROS2和Linux应用时用clangd做单片机裸机开发时切回C/C扩展。远程开发这块我用的是Remote-SSH连一台Ubuntu机器。理由很实在ROS2在Windows上跑坑太多虽然新版有支持但社区资料还是Linux为主遇到问题搜到的答案也基本都是Linux的。所以干脆一开始就建一个干净的Ubuntu环境把精力留给真正的知识点。2.2 ROS2安装与验证版本选择比安装步骤更重要ROS2的安装本身不难难的是选版本。我的建议是先确认你的Ubuntu版本再对号入座。操作系统版本推荐ROS2发行版理由Ubuntu 24.04Jazzy官方长期支持与24.04绑定Ubuntu 22.04Humble生态最成熟第三方包最多Ubuntu 20.04Foxy已停止维护不建议新项目使用我当时用的是Ubuntu 24.04配Jazzy。安装流程大致是配置软件源、更新索引、安装desktop版本、配置环境变量。装完之后最关键的验证不是能不能打开rviz2而是能不能跑通最基本的通信。# 终端1 source /opt/ros/jazzy/setup.bash ros2 run demo_nodes_cpp talker # 终端2 source /opt/ros/jazzy/setup.bash ros2 topic list ros2 topic echo /chatter ros2 topic hz /chatterros2 topic hz这条命令我强烈建议每个测试岗的人都练熟。它输出的是实际消息频率而发布端标称的是理论频率。这两个数一对比就能看出丢包、阻塞、序列化耗时这一类问题。我面试时就被问到怎么判断话题通信有没有性能问题我答的就是先看hz再看延迟配合QoS配置检查。验证完demo还要检查环境变量有没有写进shell配置文件。如果是临时source新开一个终端就失效很多人第二天回来发现昨天还好好的今天怎么找不到命令了就是这个原因。source /opt/ros/jazzy/setup.bash echo source /opt/ros/jazzy/setup.bash ~/.bashrc2.3 嵌入式工具链交叉编译、OpenOCD与串口调试ROS2装完接下来要面对的是另一套完全不同的工具链。嵌入式这边核心就三件事编译、烧录、调试。编译用交叉编译器比如针对ARM Cortex-M的arm-none-eabi-gcc。这个工具链的原理是你的电脑是x86架构目标板是ARM架构指令集不同所以要用专门的编译器生成目标板能识别的机器码。理解这一点很重要因为面试时经常考为什么不能直接用gcc编译嵌入式程序。烧录和调试靠OpenOCD配合调试器常见的ST-Link、J-Link。OpenOCD的作用是把上位机的调试命令翻译成JTAG或SWD协议时序打到芯片的调试接口上。openocd -f interface/stlink.cfg -f target/stm32f1x.cfg这条命令跑起来后OpenOCD会在本地开一个GDB Server端口然后你在另一个终端用GDB连上去就能单步、打断点、看寄存器。这一套流程第一次配可能要花一小时配通之后就是肌肉记忆。串口调试我用Python的pyserial写了个小工具功能很朴素打开串口、按行读取、带时间戳落盘、支持关键字高亮。这个工具后来在面试时成了我的谈资——我把它当成测试工程师思维的证据不是被动地看日志而是主动做工具提高效率。import serial, datetime ser serial.Serial(/dev/ttyUSB0, 115200, timeout1) with open(uart.log, a, encodingutf-8) as f: while True: line ser.readline().decode(utf-8, errorsignore).strip() if line: ts datetime.datetime.now().strftime(%H:%M:%S.%f)[:-3] f.write(f[{ts}] {line}\n) f.flush()提示串口权限问题几乎人人必踩。Linux下普通用户默认没有/dev/ttyUSB*的读写权限报错是Permission denied。把用户加入dialout组并重新登录就能解决别用sudo硬跑那样生成的文件权限会乱七八糟。3. ROS2核心机制机器人测试岗问得最多的那一块3.1 节点、话题、服务、动作四件套的测试视角ROS2的资料很多但大部分是教你怎么开发不是教你怎么测。我按测试的思路把它重新梳理了一遍这四件套要这么理解节点是运行单元一个进程可以有多个节点。测试关注的是节点的生命周期启动是否正常、异常退出时有没有留下僵尸进程、资源占用有没有泄漏。话题是单向的异步数据流。测试关注的是频率、延迟、丢包、消息顺序、QoS匹配。命令上主要靠ros2 topic hz、ros2 topic delay、ros2 topic info -v这三条。服务是同步的请求响应。测试关注的是超时处理、并发调用、服务端崩溃时客户端是否卡死。动作是可以中途反馈、可以取消的长任务。测试关注的是取消后资源是否释放、反馈频率是否稳定、目标被抢占时的行为。这四种通信方式对应四种完全不同的故障模式这也是为什么ROS2的测试不能简单套用传统接口测试的思路。传统接口测试大部分是同步请求响应你只要关心HTTP状态码和响应体ROS2里最麻烦的恰恰是异步话题和长任务动作。3.2 DDS与QoS消息传递机制里最容易翻车的地方这是我认为ROS2最值得深挖的一块也是面试区分度最高的地方。ROS2底层用的是DDS做消息传输QoS服务质量配置决定了通信双方的匹配规则。核心的几个维度是可靠性reliable还是best_effort、持久性volatile还是transient_local、历史深度keep_last还是keep_all、深度多少、以及时限deadline。最典型的坑是发布端用reliable订阅端用best_effort这两个是能匹配的反过来发布端best_effort、订阅端reliable就匹配不上——订阅端收不到任何消息而且不会报错ros2 topic list里还能看到这个话题特别隐蔽。# 查看话题的QoS详情重点看Reliability那一行 ros2 topic info -v /chatter # 手动指定QoS来echo排查是不是QoS不匹配 ros2 topic echo /chatter --qos-reliability best_effort我用这个思路排查过一次传感器数据收不到的问题节点都在跑、话题列表里也有就是没数据。最后发现是订阅端配置了reliable而驱动节点是best_effort。改配置后立刻通了。这件事让我明白ROS2调试不能只看有没有还得看匹不匹配。QoS还有一个容易忽略的点是队列深度。深度太小处理不及时就会丢消息深度太大内存占用上去而且延迟会累积。我的经验值是高频传感器数据比如IMU、图像用小深度加best_effort控制指令用深度稍大的reliable。这个没有标准答案得根据实际吞吐量算。比如一个100Hz的话题回调处理耗时20毫秒那深度至少得留2到3才能扛住偶发的处理抖动。3.3 launch_testing与ros2 bag把测试自动化真正跑起来软件测试出身的人最关心的就是怎么自动化。ROS2这块主要有两个抓手。第一个是launch_testing。它把测试代码和launch文件绑在一起先起节点再跑断言最后清理进程。最小结构是这样import unittest import launch_testing from launch import LaunchDescription from launch_ros.actions import Node def generate_test_description(): return LaunchDescription([ Node(packagedemo_nodes_cpp, executabletalker, nametalker) ]), {talker: None} class TestTalker(unittest.TestCase): def test_talker_runs(self, talker): self.assertTrue(talker is not None) launch_testing.post_shutdown_test() class TestShutdown(unittest.TestCase): def test_exit_code(self, proc_info): launch_testing.asserts.assertExitCodes(proc_info)跑起来用launch_test test_talker.launch.py这个模式的价值在于它天然覆盖了启动-运行-关闭完整生命周期比单纯的单元测试更贴近真实场景。我后来把大部分回归用例都改成了这个结构。第二个是ros2 bag也就是数据录制回放。ros2 bag record -a -o my_bag ros2 bag info my_bag ros2 bag play my_bag --rate 0.5bag的用法里有个技巧特别有用--rate参数可以调速回放。用它做0.5倍速回放能复现那些只在低速时出现的时序问题用2倍速回放能做压力测试。这比真人反复操作高效得多。注意录制时用-a会把所有话题全录下来包括大体积的图像话题几分钟就能把硬盘撑爆。生产环境的做法是先ros2 topic list筛出需要的话题再逐个指定录制。另外bag文件格式在不同发行版之间有兼容性问题跨版本回放前先确认一下。3.4 TF2、URDF与rviz2空间数据的校验方法机器人测试和普通软件测试最大的区别就是多了空间这个维度。一个机械臂的关节角度对不对光看数值是看不出来的得看坐标系变换的结果。URDF是描述机器人结构的文件定义了连杆和关节。TF2负责管理这些坐标系之间的变换关系。rviz2是可视化工具把TF2算出来的结果画出来。对测试岗来说重点是验证三件事坐标系树结构是否完整有没有断链、变换是否连续有没有跳变、时间戳是否同步有没有过期数据。# 把TF树导出成PDF一眼看出结构对不对 ros2 run tf2_tools view_frames # 实时查询两个坐标系之间的变换 ros2 run tf2_ros tf2_echo base_link camera_linkview_frames生成的PDF是我见过最直观的排查工具。有一次我遇到rviz2里模型乱飞用这个命令一看发现有两个节点都在发布同一个坐标系互相覆盖树结构里出现了重复节点。这种问题靠看日志根本发现不了。时间戳问题是另一个高频坑。TF2默认只保留一小段时间的变换数据如果你的两个话题发布频率差太多或者有个节点处理特别慢就会出现找不到某个时刻的变换的报错。解决思路是检查各节点的时间源是否统一都用系统时间或者都用仿真时间必要时把缓存时间调长。4. 物联网与单片机证明你真的碰过硬件4.1 单片机选型51、STC、STM32、ESP32先学哪个这个问题我被问过很多次。我的答案是想快速建立信心从51或者STC开始想直接对接岗位需求从STM32开始想做物联网项目ESP32最省事。平台优势适合场景主要短板51单片机资料最丰富结构最简单理解寄存器、中断、定时器资源少很难做复杂项目STC单片机与51兼容支持在线升级工业小控制板、成本敏感场景生态不如STM32STM32生态成熟HAL库完善岗位需求最大外设齐全上手门槛略高ESP32内置WiFi和蓝牙物联网、无线数据采集实时性和功耗不如专用MCU我实际走的路是先用51把GPIO、定时器、中断、串口这几件事搞明白因为它的寄存器操作最直白你能清楚看到写某个地址就是配置某个功能。然后转到STM32用HAL库快速搭项目。最后用ESP32做物联网联调。这个顺序的好处是理解层层递进。直接从ESP32开始的人往往能用Arduino框架点灯但说不清底层发生了什么面试一深挖就露馅。4.2 串口与固件升级最容易埋在细节里的坑串口是所有嵌入式项目绕不开的东西也是测试岗最该练熟的部分。参数就四个波特率、数据位、停止位、校验位。看起来简单实际问题很多。第一个坑是波特率误差。串口收发双方各自用本地时钟分频产生波特率如果时钟源精度不够累积误差会超过容忍范围表现为偶发的乱码。判断方法很简单乱码是不是随机的、是不是在长报文时更容易出现。如果是先怀疑波特率误差再怀疑线材和干扰。第二个坑是电平标准。TTL电平和RS232电平不兼容直接对接可能烧接口。这个必须靠查手册确认别凭经验。第三个坑是升级流程。以串口升级为例芯片通常需要先进入bootloader模式一般靠特定引脚电平或者特定命令触发再按协议分包下发固件最后校验并跳转到应用区。测试的重点在于升级中断怎么办、固件校验失败怎么办、升级后旧配置是否保留。这几个场景恰恰是软件测试出身的人最擅长设计的——等价类、边界值、异常流程全都用得上。提示做固件升级测试时一定要准备一个变砖恢复方案。我在测试时故意在写入过程中断电结果芯片进了bootloader死循环。好在芯片本身有内置的启动模式用跳线强制进下载模式才救回来。这一步必须提前演练别等真出事。4.3 物联网链路从采集到上报的完整验证物联网项目的结构其实很固定传感器采集、主控处理、通信模块上传、云平台或本地broker接收、应用端展示。测试要覆盖每一段的边界。我搭的一个最小验证环境是这样的ESP32接一个温湿度传感器采集后通过MQTT上报到本地broker再用一个Python脚本订阅并落库。用本地broker而不是云平台是因为本地环境可控、延迟低、不用考虑网络波动适合先验证逻辑正确性。MQTT这块有几个测试要点值得记下来。一是连接保活机制如果客户端异常断开broker多久能感知到二是QoS等级0是至多一次、1是至少一次、2是恰好一次等级越高开销越大很多消息重复的问题根源就是选了等级1三是遗嘱消息客户端异常掉线时broker能不能发布预设消息这对可靠性验证很关键。# 本地broker发一条测试消息 mosquitto_pub -h 127.0.0.1 -t sensor/temp -m {value: 26.3} # 订阅并观察 mosquitto_sub -h 127.0.0.1 -t sensor/# -vPython侧用paho-mqtt订阅处理逻辑里我特意加了断线重连和消息去重。去重这件事看着多余但在QoS等级1下重复消息是常态不是异常。这个认知转变对我挺重要——软件测试里我们习惯把重复当缺陷物联网里得先看协议约定。5. 芯片测试与AI部署真正的岗位落脚点5.1 芯片测试的基本范式与你在其中的位置前面都是铺垫这一块才是岗位的核心业务。芯片测试大致分几个阶段晶圆测试CP在晶圆还没切割时进行用探针台接触每个芯片的焊盘快速筛掉明显失效的die目的是省下后续封装成本。成品测试FT在封装完成后进行覆盖更全面的功能和参数。系统级测试SLT把芯片放到接近真实应用的环境里跑验证系统级行为。此外还有老化测试在高温高压下持续运行一段时间筛出早期失效品。测试的内容又分功能测试和参数测试。功能测试验证逻辑对不对参数测试验证电气指标合不合格比如电压阈值、漏电流、时序余量。测试向量、扫描链、边界扫描这些概念都是为了提高测试覆盖率、降低逃逸率。作为测试工程师你的日常工作大概是这样根据芯片规格书设计测试用例、配置测试设备、分析测试数据、定位失效原因、和设计团队一起复现问题。软件测试的很多方法论在这里能直接迁移比如等价类划分、边界值分析、失效模式分析。但有一件事必须重新学怎么读数据手册和时序图。这是硬件测试的基本功读不懂手册连测试条件都定义不了。5.2 嵌入式AI部署从模型到板子的最后一公里AI这块我是当加分项来学的但后来发现它其实是趋势。机器人芯片测试里越来越多涉及模型在芯片上跑得对不对这类问题。部署的核心难点不在模型本身而在量化。训练出来的模型通常是浮点的芯片上跑的一般是定点或int8的这个转换过程会引入误差。验证的重点就是量化后的精度下降了多少、有没有超出可接受范围、哪些层的量化误差最大。主流的推理框架有几个方向TFLite Micro适合资源受限的MCUCMSIS-NN是针对ARM内核优化的算子库ONNX Runtime和NCNN更多用在稍强的边缘设备上。我实际练手的是把一个图像分类的小模型量化后跑在开发板上记录推理耗时和精度变化。这里有个经验值得分享量化校准集的选择比量化算法本身更重要。如果你用一批和实际场景分布不一致的数据去校准量化后的模型在真实数据上会掉得很惨。这个道理和测试用例的覆盖度是一样的——样本选错了后面全白费。再往上走一层是具身智能数据集的质量问题。机器人要学动作需要大量带标注的轨迹数据标注一致性、时序对齐、多模态同步、长尾场景覆盖这些都是数据质量的关键维度。这类数据集的评价方法和传统数据集不太一样因为它的输入是多模态的、时序的单看准确率是不够的。5.3 从软件测试思维迁移到硬件测试思维我最大的体会是软件测试和硬件测试的思维方式有重叠但有个关键差异。软件测试里复现一个问题是相对容易的环境可以完全重建。硬件测试里这次不复现是常态因为温度、电压、器件个体差异都在变。所以硬件测试更强调统计和边界不是问能不能复现而是问在什么条件下会失效、失效率是多少。这个思维转变体现在很多细节上。比如软件测试里我们习惯把日志等级调细硬件测试里则更依赖仪器示波器看波形、逻辑分析仪看时序、电源看电流曲线。有时候一个偶发问题最后是靠看电流波形的一个毛刺定位的。另一个差异是成本意识。软件里跑一次全量回归可能就几小时机器时间硬件里跑一次全温测试是实打实的设备和时间成本。所以硬件测试用例的设计更讲究优先级和抽样策略不可能穷举。这一点在面试里也是加分项——你如果能说出我会先做失效模式分析把高风险项排在前面面试官会觉得你懂行。6. 常见问题与排查技巧实录6.1 环境类问题速查表环境问题占了新手期的绝大部分时间我整理了一份自己实际遇到的清单。现象常见原因排查动作新终端里找不到ros2命令环境变量只在当前shell生效检查shell配置文件里有没有source那一行串口打不开、提示权限不足用户不在dialout组加入组后重新登录交叉编译报找不到头文件工具链路径或sysroot配置错误检查编译器前缀和包含路径烧录时连不上目标板调试器驱动或接线问题先确认调试器能被识别再查SWD接线rviz2打开是黑屏没有配置显示或话题无数据检查显示环境变量和话题列表节点启动后立刻退出依赖缺失或参数未传看退出码和完整日志这份表我建议对着自己的环境过一遍很多玄学问题其实都是这几类。6.2 通信与硬件类问题排查思路通信问题的排查我总结了一个固定套路先确认物理层再确认协议层最后看应用层。物理层就是接线、电平、供电。听起来最low但实际故障占比最高。我遇到过好几次怎么调都不通最后发现是杜邦线接触不良。协议层看波特率、时序、地址配置。这一层要用仪器示波器看波形、逻辑分析仪看时序别靠猜。应用层看数据内容、缓存、处理逻辑。到了这一层软件测试的经验就能派上用场了抓日志、加断点、做对比。还有一个通用技巧二分法定位。把链路从中间切开看前半段有没有问题快速缩小范围。这个和软件调试里注释掉一半代码是一个思路。注意硬件调试千万别带电插拔尤其是电源和电机这类大电流器件。我见过有人热插拔烧了一块板子白干两天。养成断电操作的习惯。6.3 简历和面试层面的几个实在建议最后说点非技术的。我那一年空窗期不是白过的简历改了很多版面试也复盘了很多次。简历上最忌讳的是把软件测试的经历写成负责XX模块测试。要往硬件和系统靠就要重新组织语言。比如负责接口自动化可以改成搭建自动化测试框架覆盖XX个用例并将方法迁移到嵌入式固件回归测试。哪怕当时没做过你在15天里练的那些项目也完全可以写成个人项目经历。面试里最高频的几个问题我也记下来了ROS2的通信方式有哪几种、QoS是干什么的、怎么测一个嵌入式系统的稳定性、串口通信可能有哪些问题、芯片测试的流程是怎样的。这几个问题如果你能答得有细节、有例子基本就稳了。还有一点面试官很看重你为什么要转。我当时说的是软件测试做了几年之后我发现很多问题的根因在下层我想往下走一层把问题看透。这个回答是真实的也是他们愿意听的。别编故事编的故事经不起追问。最后分享一个小技巧也是我实打实受益的把15天里做的所有产出物整理成一个仓库README里写清楚每个项目解决了什么问题、用了什么工具、遇到什么坑。面试时直接给链接比嘴上说一百句都管用。我拿到offer的那家公司技术负责人就是在面试前看了我的仓库才决定加面一轮的。这个习惯我现在还保持每做一个新项目就往里加慢慢就成了自己最硬的底气。