机器人比赛

第一部分：香港科技大学ENTERPRIZE战队

我认为大学机器人社团很难形成统一的文化和价值观，因为人员流动的，基本上技术骨干和管理骨干会因为毕业/个人学业分配不断流动，导致社团很难形成统一的价值和体系。在这中间只有口口相传的技术信仰和故事会暂时分别维持一些技术和文化传承。总的来说，ENTERPRIZE（在我加入时）自然形成了如下几个特点：

1. 现代的技术路线（软件方面）。

得益于有几个有软件工程和计算机语言基础的前辈，ENTERPRIZE很早的就采取了“现代化”的软件工程结构。比如使用Git/GitHub进行开发管理，使用静态工具（clang-tidy，clang-format）规范化开发，选择性的使用“现代”C++特性（使用OOP，template，generic，不使用动态内存分配，RTTI，exception，不实用标准库）。回过头来看这些选择非常理智正确，一方面用语言的expressiveness简化了开发难度，另一方面也规避了C++中很多不确定的部分。我也是在读到比如Bare Metal C++和NASA的Programming Guidelines之后，结合实践中的经验和部分承担了管理队伍代码管理的职责后，才慢慢理解其中很多看似简朴的道理，即我们不断在高效，简洁，可扩展性上取舍，动态的在拓展代码库功能的同时，努力维护代码规范和设计模式抑制熵增。

另一个方面，ENTERPRIZE经历的多轮技术经验流失（RM队伍中称之为断代），即因为队伍核心成员流失加上长时间不参加补赛，参赛成员需要重新发现/踩坑。一体两面的结果是目前为止，ENTERPRIZE软件方面也没有积累所谓的“技术债”，新的模式积极拥抱，老的屎山积极推翻。

2. 技术第一

ENTERPRIZE的团队组成大多数（>90%）来自于理工科院系，最多的应该是计算机工程，综合系统设计，以及机械工程。这样的理工科聚集团队很容易形成一个典型的文化：所有人的兴趣点在于钻研最高水平的技术，容易忽视不太sexy的事情，比如组织人员管理和宣传。从参加比赛性价比来说，RoboMaster比赛对于在香港的同学不算高。主要好处在于：

学校比较支持，对于参加机器人相关科研/project可以提供很好的实际上手全栈经验。
队伍“传承”还行，学长学姐有不少在香港学界大组或香港业界大厂。
如果在珠三角创业或者参加创业公司属于技术栈契合，同时学校也有鼓励创业的相关机会。

主要坏处在于：

时间成本很高，基本上会消耗课业外（或课业中）所有时间。
如果想出国留学或者想回内地找工作，属于不太有帮助的经历（在2026年具身热潮这中稍微好一点点）。

回顾来看，ENTERPRIZE 这种"技术第一、其他靠边"的文化是一把双刃剑。一方面，它让队员能够在几乎没有官僚摩擦的环境中快速迭代、深入技术细节，这种氛围对刚入门嵌入式或机器人系统的学生来说极其珍贵——你可以在一个真实的大赛场景里，从零搭建一套完整的机器人软硬件系统，踩遍所有该踩的坑。另一方面，这种文化的代价也很明显：队伍的战斗力高度依赖个别核心成员的个人能力和投入，一旦这些人毕业或精力转移，积累的经验很难沉淀为可复用的方法论。技术可以推翻重来，但组织能力和参赛经验的"断代"却是一次次重复上演。

某种意义上，ENTERPRIZE 给我的最大收获反而不是具体的技术技能，而是对"什么样的团队能持续做出好东西"这个问题有了切身体感——这个问题我在之后的经历中一直在反复验证和修正。

3. 有文化，无制度

ENTERPRIZE 几乎没有成文的研发流程。代码怎么写、分支怎么管、需求怎么定、测试怎么做，全靠口口相传和个人自觉。这种状态在一个十来人的小团队里勉强能跑——大家低头不见抬头见，出了问题直接吼一嗓子就解决了。但它的隐性成本很高：新人上手完全依赖学长学姐的面授，一旦中间断了一届，下一届就得从零摸索；同一个坑可能在不同赛季被不同的人反复踩，因为没有人把经验固化成流程。同时一个组织结构也很难scaleup，基本上一个组长管理7-8人小团队，大组长管理4-5个小组长，也就是说一个队伍从管理工具上基本被限制在50有效人员以内。

更深层的问题在于，这种"没有流程"的状态被潜移默化地合理化了——在"技术第一"的文化里，写文档、定规范、画流程图、报账这些事天然被视为不够酷、不够硬核的"杂活"。技术能力强的队员不屑做，想做的人又未必有足够的语境和权威去推动。

第二部分：重生之

反过来思考，如果想要在港科组建一个比赛结果为导向的战队，what could have done differently？

有哪些相关方？

要想理清究竟该怎么做，第一个方面是要搞清楚有哪些利益相关方。

比赛组织者DJI

DJI出钱举办比赛，我观察到具体有下面两个利益考量：

创始人 Frank Wang 自己本身是 RoboCon 出身，也许有一些从比赛到实业的情怀。
RM 能固定产出“高性价比”的工程人才，同时通过比赛宣传公司价值观，引导相关技术路线。

但是同时，比赛组织者和参赛队伍的目标并不完全一致。对 DJI 来说，赛事需要足够好看、足够有传播性、足够能筛选人才；对学校战队来说，真正的问题是如何在有限预算、有限场地、有限学生时间里，把一个高度复杂的工程项目稳定地跑完。这两者有交集，但不是同一个问题。

学校和学院

学校的诉求相对更分散。一方面，机器人比赛是很好的本科生实践平台，也很适合用来对外展示“学生动手能力强”“学校支持创新创业”之类的形象。另一方面，学校并不会天然理解一支 RM 队伍为什么需要长期场地、采购流程、报账支持、危险品管理、宣传资源和稳定的技术传承。对于学校行政系统来说，比赛往往只是很多学生项目中的一个；对于队伍来说，它却几乎是一个小型工程公司。

所以如果要重来，战队不能只把学校当作“要钱的对象”，而应该把学校当作一个需要持续沟通的合作方。什么东西能换来学校支持？可展示的成果、清晰的安全边界、稳定的预算规划、对本科教学或招生宣传有帮助的产出。这些听起来很功利，但如果不把这些讲清楚，队伍就会长期停留在“几个学生凭热情硬撑”的状态。

队员

队员的诉求也不是单一的。有人想学技术，有人想打比赛，有人想做简历，有人只是喜欢机械和电控，有人可能只是被朋友拉进来。一个比赛结果导向的战队不能假设所有人都有同样的目标，也不能只靠“热爱”维持投入。热爱很重要，但热爱不是管理制度。

更现实的做法应该是把队员分层：核心研发、稳定执行、短期参与、宣传行政，各自有不同的任务、权限和预期回报。核心研发需要足够高的技术自由度，也要承担文档、评审和带人的责任；稳定执行成员需要明确任务边界和可完成的工作包；短期参与者则应该被安排在低耦合、可快速反馈的任务里。这样听起来不浪漫，但比把所有人都丢进同一个大群里，然后期待大家自然成长要靠谱很多。

如果目标是赢，应该先承认什么？

第一件事是承认 RoboMaster 不是一个纯技术比赛。它是技术、组织、资源、时间管理、供应链、学校支持、赛规理解和临场执行的混合体。单点技术强当然有用，但不足以稳定转化成比赛成绩。

第二件事是承认学生队伍天然不稳定。毕业、实习、交换、期末、情绪波动都会打断节奏，所以制度不是为了限制人，而是为了在这些不可避免的波动里保住最低战斗力。一个好的制度应该让新人能接住前人的工作，让普通成员也能稳定贡献，让核心成员离开时队伍不至于直接失忆。

第三件事是承认“赢比赛”和“做有意思的技术”有时候是冲突的。比赛需要的是在规则、时间和资源约束下做最可靠的选择，而不是每个模块都追求最漂亮的方案。

最小可行的制度

如果重新设计队伍，我觉得不需要一开始就搞很复杂的流程。学生社团不是公司，流程太重会把热情磨掉，但至少需要几条最小制度。

1. 招新

招新不应该只是“找更多人”。很多队伍招新时默认人越多越好，但机器人比赛里，人多不一定等于产出多。没有任务拆分、培训路径和负责人，招来的人越多，沟通成本越高，核心成员反而越累。

我觉得招新应该分成几层。第一层是兴趣筛选，让大家知道 RM 到底是不是自己想象中的“机器人比赛”：它有很酷的部分，也有大量调车、焊线、画板、拧螺丝、报账、等快递和熬夜排查问题。第二层是基础训练，不应该一上来就丢进大项目，而是用几个小任务建立共同语言，比如 CAN 通信、PID、简单机构装配、Git workflow、基本电路调试。第三层才是进入真实模块，让新人在一个有限范围内承担责任。

这里最重要的是反馈周期。新人如果连续一个月不知道自己做的东西有没有意义，很快就会流失。反过来，一个很小但可运行的任务，比如让一个电机按指定速度稳定转起来，或者让一块板子正确读取传感器数据，反而能让人快速建立参与感。队伍真正需要的不是一开始就能独当一面的天才，而是能被系统性培养、逐步接住复杂任务的人。

2. SOP，文档，和流程

SOP 听起来很行政，但对于学生战队来说，它本质上是降低记忆负担。很多事情不应该每年都重新发明，比如新电脑怎么配环境，电池怎么管理，赛前检查清单有哪些，采购要提前多久走流程，代码合并前要跑什么检查，真车测试前谁有权把车架起来。这些东西如果只存在于某几个人脑子里，队伍就会被这些人的时间表绑架。

文档也不需要写得像公司内部规范。一个能活下来的文档系统应该足够轻：能说明背景、当前做法、常见坑、负责人和最后更新时间就够了。重要的是文档要和实际工作绑定，而不是赛季结束之后为了总结而补写。比如每次做完一次重要测试，就顺手记录测试条件、现象、结论和下一步；每次做出一个关键技术决策，就记录为什么选这个方案，为什么没有选另一个方案。

流程的目标也不是制造审批，而是明确责任边界。什么时候可以直接改？什么时候必须 review？什么时候必须通知机械、电控、视觉其他组？什么时候需要停止测试？如果这些边界不清楚，队伍就会在两种状态之间来回摆动：平时过度自由，出事后过度紧张。好的流程应该让大多数常规事情自动运行，让真正危险或高成本的事情被提前拦住。

3. 迭代

RoboMaster 的系统复杂度很容易诱导一种错觉：只要把所有模块都做到足够好，最后自然会变成一台强车。但真实情况通常相反，很多问题只有整车联调时才暴露，而整车联调又总是最稀缺的资源。所以迭代不能等到所有东西都“差不多做好了”才开始，应该从赛季早期就建立可运行的最小系统。

一个结果导向的迭代节奏，应该尽早得到一台能动、能通信、能安全停下来的车。它一开始可以很丑，功能可以很少，但必须能被反复测试。之后每次增加功能，都应该尽量保持主链路可用。比如先保证底盘和遥控稳定，再接入云台；先保证发射机构机械可靠，再追求射频和弹道一致性；先保证视觉模块能输出可解释的数据，再讨论策略层怎么优化。

迭代还需要明确的止损点。学生项目很容易因为一个技术方案已经投入太多时间而继续硬撑，但比赛不会因为你努力过就降低难度。一个方案如果连续几轮都无法稳定复现，就应该降级、替换，或者先做保守版本。保守版本不是失败，它是给队伍留下继续调试和参赛的余地。

可能的队伍结构

如果按结果导向来设计，队伍结构也许不应该完全按传统机械、电控、软件、视觉来切。专业分组当然必要，但比赛产出是以机器人为单位交付的，所以还需要横向的项目负责人。每台车至少应该有一个 owner，负责追踪它的整体状态：机械完成度、电控风险、软件接口、测试记录、备件情况和赛前 checklist。

这样做的好处是问题不会永远停留在“这是哪个组的问题”。真实系统里很多问题都跨组：电机发热可能是机械阻力、控制参数、驱动设置或操作习惯；通信异常可能是线束、协议、任务调度或电源噪声。如果没有整车 owner，这类问题很容易在组和组之间来回踢。owner 不一定要亲自解决所有问题，但要负责把问题推进到有结论。

同时，队伍还需要把“研发”和“比赛执行”分开看。研发关注长期能力，比赛执行关注当下可靠性。临近比赛时，应该有人有权说：这个功能暂时不上，这个模块只保留保守模式，这个问题赛后再重构。否则队伍很容易在赛前最后一周继续做大改，最后每个模块看起来都更先进，但整车更不稳定。

小结

写到这里，其实我并不是想说 ENTERPRIZE 做得不好。恰恰相反，我能很明显地感觉到队伍正在越来越好。新同学的水平很高，学习速度也很快，很多人在刚加入不久之后就能做出相当完整的东西。和我刚进队时相比，现在大家能接触到的工具、资料、工程习惯和外部环境都好了很多，队伍也在慢慢形成更成熟的技术审美。

但矛盾也在这里：队伍确实在进步，却也仍然在重复踩一些老坑。很多问题不是因为这一届不够努力，也不是因为某个同学能力不够，而是学生战队天然容易失忆。人员流动太快，经验沉淀太慢，很多过去已经付过代价的事情，如果没有被写下来、制度化、变成新人可以继承的东西，就会在几年后换一种形式重新出现。看到新同学一边变强、一边重新撞上相似的问题，其实是一种很复杂的感受：既欣慰，也有点可惜。

对我个人来说，参加 RoboMaster 带来的影响很难只用“学到了技术”概括。它当然让我接触了嵌入式、控制、机械、电控、视觉、项目管理这些具体东西，也让我第一次比较完整地经历了一个复杂工程系统从想法到实物、从能跑到能比赛的过程。但更重要的是，它让我更早地理解了工程和组织之间的关系：一个系统能不能跑起来，不只取决于某段代码、某块板子、某个算法，也取决于一群人能不能沟通、交接、复盘、承担责任。

这段经历里也有很多不成功的部分。有些比赛没有打好，有些方案最后没有用上，有些问题反复出现，有些时间现在回头看也许可以用得更聪明。但正因为它不是一段被包装得很漂亮的经历，反而更真实地塑造了我对工程的理解。它让我知道什么叫临场压力，什么叫系统复杂度，什么叫“差一点就能跑”和“真的能稳定跑”之间的距离。

所以最后还是感谢这段经历。感谢 ENTERPRIZE，感谢一起熬夜调车、写代码、修线、搬东西、吵架又继续干活的人，也感谢那些失败的测试和不太体面的比赛结果。它们没有给我一个完美的故事，但给了我很多之后仍然会反复用到的判断标准。也希望之后的 ENTERPRIZE 能继续变好，不只是做出更强的机器人，也能把每一届人踩过的坑、建立过的经验、形成过的判断，真正留给下一届。

赛场上的比赛会结束，但现实世界里更复杂、更实际的问题还会一直存在。面对这些问题，单纯的热情和聪明都不够，最终仍然需要有人用科学的态度、工程的方法，以及创业实干家的行动力，把问题拆开、验证、推进、落地。这大概也是机器人比赛留给我最重要的价值：它让我相信，真正值得做的事情，不止发生在赛场上，也发生在赛场之外更漫长、更具体的现实里（这几句是ChatGPT写的，感觉总结的很好😂）。

Blog