企业官网建设流程全解析

简介：一套FLL（FIRST Lego League）竞赛队伍的完整工程日志PDF，面向参赛队员、指导教练及对乐高机器人工程设计感兴趣的初学者，系统记录了从机器人主体搭建到5个策略物研发的全过程。包内仅含1个PDF文档，约742KB，阅读轻便，可快速了解任务驱动的机械结构设计与传感器应用思路。已有89人学习浏览。日志重点呈现双大型电机驱动、双中型电机辅助、三颜色传感器定位的机器人方案，并逐一拆解策略物1～5号的实现逻辑，如橡皮筋机关、可伸缩装置、窗帘式收集机构、连杆控制机构及绞盘送料机构等，同时涵盖巡线、定位、齿轮传动等关键技术的实战运用。结尾的设计反思与团队协作经验，也能为备赛队伍优化资源管理、减少浪费提供有益参考。

1. 把 FLL 工程日志当成产品文档来写，你就能赢在细节上

FLL 工程日志不是赛后补写的回忆录，而是评委在五分钟内判断一支队伍是否真正理解工程流程的核心依据。很多队伍把精力全砸在机器结构和程序调试上，日志却停留在“今天搭了底座”“明天改传感器”的流水账层面，最终在工程答辩环节被一句“你们为什么选这个方案”问住。反过来，那些拿到高分甚至冠军的队伍，日志里通常能看到一条清晰的问题定义、方案对比、失败记录、参数演进的线索，评委顺着日志就能还原整个赛季的决策过程。这篇博客不讲怎么搭乐高，也不讲怎么调 EV3 或 SPIKE，就讲怎么把工程日志从“记录做了什么”升级成“证明你会做工程”。适用于教练、队员，也适用于任何想把项目过程文档做扎实的技术从业者——FLL 的工程日志本质就是一份带约束条件的产品研发文档。

2. 工程日志的结构化设计：先定信息架构，再谈记录习惯

2.1 为什么大多数日志写得像“流水账”？因为缺少模板约束

FLL 工程日志最常见的问题不是写得少，而是写得散。队员每次活动后随手记几笔，有的写在纸上，有的打在手机备忘录里，到赛季末期想整理成册时，发现时间线对不上、数据找不到、当时的决策理由早就忘了。这种情况的根源在于：日志没有在赛季开始前就定义好“每一篇必须包含什么”。

我一般会在第一次团队会议上就下发一份结构化模板，要求每次活动记录必须包含五个固定区块：目标（这次要解决什么问题）、操作（实际做了什么）、数据（测得的数值或观察到的现象）、分析（数据说明了什么）、下一步（基于分析打算怎么调整）。这五个区块不是随意定的，它们对应着工程日志评审标准里最看重的“迭代闭环”——能看出队伍不是在瞎试，而是在用数据驱动设计变更。

模板的载体不一定要复杂，A4 纸打印的表格就能用，但我更推荐用 Markdown 维护一份电子版，理由后面章节会展开。关键是让每个队员都形成条件反射：写日志不是写日记，是写“工程事件记录”，每一条记录都要能回答“为什么做、做成什么样、接下来怎么办”。

2.2 日志的时间线结构：按里程碑归档，而不是按日期堆叠

按日期顺序记录是最自然的做法，但也是最难检索的。赛季中期你往往需要回答“我们什么时候第一次发现巡线抖动的问题”，如果日志按日期排，你得一页页翻；如果按里程碑归档，每个阶段自然聚合，这个问题就变成“去巡线稳定性专题里找第一条失败记录”。

具体做法是把赛季分成五个里程碑：方案研究与选型、结构原型搭建、程序核心逻辑开发、整机联调与迭代、赛前状态冻结。每个里程碑下再按日期记录进展，同时维护一个“关键决策表”，把最重要的三次左右方案变更单独抽出，记录变更前后的对比数据。这个设计的好处是双重的：对内，队员能快速定位历史记录；对外，评委能看到队伍有清晰的项目管理意识。

关键决策表的字段我建议这样设计：决策日期、原方案描述、触发变更的问题现象、新方案描述、对比验证数据、决策人。这个表格是工程日志里分值密度最高的部分，值得花时间打磨。

2.3 日志颗粒度控制：区分“事实记录”和“解释记录”

另一个常见误区是事无巨细全都写。今天拧了几个螺丝、插了几根线，这类操作细节对工程评判没有价值。真正有用的是两类信息：可量化的数据（马达功率、传感器阈值、运行秒数、失败次数），以及可追溯的理由（为什么把颜色传感器的反射光阈值从 45 调到 52）。前者是“事实记录”，后者是“解释记录”，两者相辅相成，缺一不可。

在模板里我会专门加一个“参数变更记录”子区块，每次调整任何数值参数，必须写三行内容：改动前数值、改动后数值、改动原因。哪怕改完发现没用，这条记录也比不写有价值得多——它证明了队伍在系统性地排除变量，这正是工程思维的核心。注意，这里的“参数”不限于程序里的传感器阈值，也包括结构尺寸（比如机械臂抬起高度）、配重位置、轮胎类型等硬件层面的变量。

3. 从空白页到第一版：用 Markdown 模板搭建可复制的日志体系

3.1 为什么选 Markdown 而不是 Word：版本管理与检索效率

FLL 赛季通常持续八到十二周，一支队伍七八个队员，如果每人用 Word 写各自的片段再汇总，合并格式就够折腾半天。Markdown 的好处是纯文本，人人都能改，合并时不会出现格式冲突。更重要的是，Markdown 天然适配 Git 的版本管理，每一版日志的修改记录都清晰可见，这在评委问“你们怎么管理过程文档”时是实打实的谈资。

另一个实用理由是检索。一份赛季日志最后往往有几十页，PDF 导出后靠目录跳转，但 Markdown 源文件可以随时用 grep 或编辑器全局搜索。比如你想找所有提到“陀螺仪”的记录，一条命令就能列出所有相关段落，这种效率对赛季末期的复盘至关重要。

这里顺手分享一个我自己在用的仓库结构，仅供参考，不必照抄：

fll-engineering-journal/ ├── README.md ├── 00_decision_log.md ├── 01_milestone_research/ │ ├── 2025-03-01_方案对比.md │ └── 2025-03-08_底盘选型.md ├── 02_milestone_prototype/ │ ├── 2025-03-15_底座搭建.md │ └── 2025-03-22_机械臂v1.md ├── 03_milestone_program/ │ ├── 2025-03-29_巡线PID初版.md │ └── 2025-04-05_传感器校准记录.md ├── 04_milestone_integration/ │ ├── 2025-04-12_联调失败记录.md │ └── 2025-04-19_参数调优表.md └── 05_milestone_freeze/ ├── 2025-04-26_赛前状态.md └── 2025-05-01_最终参数备份.md

目录结构的设计逻辑是：里程碑归档 + 日期前缀 + 主题命名。日期前缀保证文件能按时间排序，主题命名保证人眼扫过去就知道内容是什么。顶层单独放一个00_decision_log.md，因为它是整个赛季的索引文件，需要在所有里程碑之上。

3.2 一份可直接改的日志模板：每个区块该写什么

下面这份模板是我给队伍用的基础版，你可以根据自己的项目节奏调整。注意每个区块后都附了“写作提示”，这些提示在赛季初就要和队员对齐，避免各写各的。

# [日期] [本次目标一句话] ## 1. 目标 <!-- 这次活动要解决什么问题？用一句话说清楚，不要写“继续搭建”这种模糊表述。 --> ## 2. 操作记录 <!-- - 做了什么，按顺序列点 - 只写影响设计或程序的决策性操作 - 重复性劳动不用写 --> ## 3. 数据与现象 <!-- - 程序运行结果：测试时间、成功率、失败模式 - 传感器读数：关键阈值、环境条件 - 结构测试：尺寸、重量、卡滞位置 --> ## 4. 分析 <!-- - 数据说明了什么？和预期是否一致？ - 如果不一致，可能的原因是什么？ --> ## 5. 下一步 <!-- - 明确下一次要改什么、测什么 - 尽量写“验证 XX 参数是否影响 YY 表现”这种可证伪的表述 -->

模板里的注释部分在渲染成 PDF 之前要删掉。有些队伍嫌每次打开模板麻烦，我建议直接把这份结构做成一个_template.md文件放在仓库根目录，每次新建记录时复制一份再改名。这样既能保证格式统一，又避免队员从零开始面对空白页时产生“不知道写什么”的畏难情绪。

3.3 用 Git 管理日志的协作细节：分支策略与提交规范

一支队伍用 Git 协作，用不着搞复杂的 Git Flow，但有两个基本规范值得从一开始就建立。第一，每个队员在自己的分支上写当天的记录，经队长或负责文档的同学 review 后再合并到主分支。这个流程不是形式主义，它能保证主分支上的日志永远是可读的、经过确认的版本，而不是七嘴八舌的草稿堆。第二，提交信息按“日期-主题-操作类型”的格式写，例如：

git add 03_milestone_program/2025-04-05_传感器校准记录.md git commit -m "0405-传感器校准-添加反射光阈值对比数据"

提交信息的格式有三个要素：日期便于回溯，主题便于识别，操作类型说明这条提交是新增、修改还是修正。赛季末如果需要给教练或评委展示过程管理能力，提交历史本身就是一份拿得出手的“过程证据”。这里不需要命令行操作经验，图形化工具如 VS Code 的源代码管理面板就完全够用。

4. 日志的核心方法论：问题定义、数据采集与失败记录

4.1 把“这个程序有问题”翻译成可验证的工程问题

FLL 日志最考验功力的地方，是把模糊的抱怨转化为清晰的问题陈述。队员说“巡线不太行”，这句话写进日志等于没写。但如果转化成“在深色地毯区域，颜色传感器的反射光读数波动超过 8，导致巡线程序在弯道处丢失黑线 3 次”，这就是一个可验证的工程问题——别人看到这条记录就能知道变量是什么、标准是什么、失败的表现是什么。

我通常要求队员遵循“环境-行为-差异”这个三要素格式来描述问题：环境指明测试条件，行为指观察到什么，差异指实际表现和预期之间差多少。这个格式不仅适用于程序调试，也适用于结构问题（比如“机械臂在满载状态下抬升高度比空载低了 1.5 厘米”），它是一个通用的工程问题描述框架。

更关键的是，问题定义要在日志里形成“问题清单”。我建议在00_decision_log.md里维护一个表格，每遇到一个新问题就增加一行，问题解决后标记关闭。这样到赛季末，评委一眼就能看出队伍处理了多少个问题、每个问题从出现到解决花了多长时间，这是工程能力最直观的呈现。

4.2 数据记录怎么做才有说服力：原始数据与对比实验

工程日志里的数据不是越多越好，而是越“可比较”越好。很多队伍记录了测试成绩，但每次测试的条件都不一样——有时在客厅测、有时在赛场测、有时电池电量不同，这些数据放一起根本没法分析。我建议在赛季第一次测试前就确定固定条件，包括场地表面类型、光照条件、起始位置、电量状态，并把这些条件写进日志模板的“数据与现象”区块。

对比实验是另一种高价值记录。当你要判断“大轮胎和小轮胎哪个更适合走这条路线”时，不要凭感觉选，而是各跑五遍记录成功率。日志里应该留下这样的表格：

这张表本身没有多高深，但它背后体现的是控制变量的实验意识。评委看到这种记录，就不需要你额外解释“我们做了选型对比”——表格自己会说话。还要注意的是，表格里的“备注”列往往比数据本身更能暴露问题，打滑、振荡这类现象描述是后续分析的重要素材。

4.3 失败记录怎么写才有价值：把每一次“翻车”变成设计输入

很多队伍不愿意把失败写进日志，觉得丢人。这完全是误解。FLL 评审的核心导向是“迭代过程”，而不是“一次成功”——后者与其说证明能力，不如说可能暴露了没有真正挑战复杂问题。新队伍第一次就顺顺当当跑完整场比赛，只能说明任务设得不够难。

失败记录的写法有讲究。只写“今天失败了，巡线不稳”毫无价值。要写清楚四点：预期结果、实际结果、排查过程、下一步假设。这四点组成了失败记录的最小闭环，缺一个都会让阅读者无法判断你从失败中得到了什么。

我还会额外要求队员在每次失败后写一条“根因假设”，哪怕这个假设后面被推翻了也没关系。比如“我怀疑是环境光变化导致传感器读数漂移”，这条假设会引导你下一次记录时专门测试环境光条件——于是日志就自然地从失败记录过渡到实验设计。这正是工程日志最有魅力的地方：每一篇都不是孤立的，而是下一篇的输入。

4.4 从日志到答辩：如何让评委 5 分钟内看懂你的工程过程

工程日志的最终归宿是评审现场。评委翻日志的时间很短，如果他想了解你们的工程流程，通常会在答辩时直接翻阅你们提到的页面。这就要求日志必须具备“快速检索”的能力——目录要清晰，关键页面要容易定位，数据表不能藏在某个不起眼的角落。

方法是给每篇日志加状态标签，比如在文件命名里用前缀区分“计划”“进行中”“已验证”等状态。这样在汇总成 PDF 时，可以用书签功能按状态分区，或者用页眉标注当前里程碑名称。还有一种更直观的做法：在仓库根目录的README.md里维护一个总览表，列出每个里程碑下最重要的三篇日志链接和一句话摘要，评委想看细节时能按图索骥。

5. 从日志到现场：用工程日志反向驱动答辩讲稿

工程日志写得好，不只是给评委看的一张纸，它本身就是答辩的最强素材库。我发现很多队伍到了赛季末才开始准备讲稿，回头翻日志时发现能用的话术全在那些“分析”区块里——只是当时没当回事。

具体操作是，赛季结束前两周做一次“日志挖掘”：通读所有记录，把每一次关键决策、每一次失败后的调整、每一组对比数据抽出来，按“背景-行动-结果”的结构重新组织成口头表达。比如日志里写着“颜色传感器阈值从 45 调到 52 后，深色地毯区域丢线次数从 3 次降到 0 次”，到了答辩现场就可以变成：“我们最初发现深色地毯区域存在传感器读数漂移问题，通过记录环境光变化数据定位到阈值裕量不足，将阈值上调到 52 后完成了十次连续测试全部通过。”——评委听到的不只是一个结果，而是一整套思考链条。

另外，现场答辩时评委可能会随意翻开日志某一页提问。如果日志的日期、主题、状态标签都规范整齐，你就能迅速定位到对应内容，从容讲解。反过来，如果日志本身就是一本流水账，翻到哪页都讲不出决策逻辑，场面就会非常尴尬。所以日志的归档规范不是洁癖，而是答辩安全的最后一道防线。

最终提醒一件事：整个赛季的日志要在赛前统一导出为带有书签目录的 PDF，并把源文件打包备份。现场只能用 PDF，而评委大概率会直接用翻页器浏览，一个结构清晰的目录比什么都重要。日志不是做完项目后的副产品，它本身就是工程能力的一部分——你希望评委看到一支什么样的队伍，就把日志写成什么样。

本文还有配套的精品资源，点击获取