Newbie Training

新進成員培訓與入門

車隊基本工作守則(全隊適用)

  1. 進入工廠不可穿著拖鞋(即使是雨天),盡量穿著長褲。
  2. 所用工具、耗材(螺絲、螺帽)、化學用品,用完後都需歸位。
  3. 工廠內所有設備在離開前須確認設備處於關閉狀態。
  4. 從車上拆下的零部件必須歸位置架子上或詢問該組組長應收納於何處。
  5. 不可在工廠內追逐。
  6. 使用砂輪機、車床等具有旋轉功能之設備或工具盡量不要穿戴手套。避免機器捲入導致受傷。
  7. 工作結束或要離開前必須將該工作區域清潔完畢(恢復至為加工前的狀態)。
  8. 不可干擾正在進行施工作業之人員。

車隊請假流程指引

車隊請假流程指引 修改中

1. 請假對象

• 請假範圍:適用於車隊內所有成員因學業、健康、個人因素等需要請假的情況。 • 請假期限:提前 1 天提出申請,緊急狀況需在事發後 24 小時內補交請假申請。

2. 請假平台與工具

使用工具 • Google 表單:提交請假申請。 • 表單連結:點擊這裡提交請假表單 • HackMD 平台:查看請假規範與相關公告。 • 通知方式:請假通知會透過 Email 或 Line 群組確認是否核准。

3. 請假流程

標準流程 1. 填寫 Google 表單 • 必填項目包括: • 姓名、班級、學號。 • 請假日期與時間段。 • 請假原因(簡單描述)。 • 提交後,請耐心等待審核。 2. 通知老師或負責人 • 表單提交後系統自動通知相關負責人。 • 若表單通知未到位,請主動聯繫負責老師或車隊管理員。 3. 查看核准結果 • 通知核准結果將以以下方式告知: • Email:核准結果將寄至你的學校郵箱。 • Line 群組:若臨時請假,請主動補交。 4. 請假記錄 • 請假記錄將存檔於 Google Sheets,請務必確認填寫無誤。

4. 緊急請假流程

  1. 聯繫車隊管理員 • 請直接透過 Line 群組或電話聯繫管理員。 • 說明請假原因與時間。
  2. 補交表單 • 緊急狀況解決後,需補交 Google 表單作為正式記錄。

5. 注意事項

• 請尊重車隊紀律,誠實填報請假原因。

6. 常見問題

Q1:可以代填請假表單嗎? A:不可以,請假表單僅限本人填寫。

Q2:提交表單後可以修改嗎? A:表單提交後不可修改,若有誤,請聯繫管理員撤回並重新提交。

Q3:未提交表單的情況下缺席會怎樣? A:未按流程提交請假申請視為無故缺席,將按紀律規定處理。

相關問題聯繫人

車隊管理員:
姓名:林源深
電話:0905-449-109

Markdown 語法快速教學

零、什麼是 Markdown&為什麼要使用它

Markdown(MD) 是一種輕量級標記語言,由 John Gruber 提出,透過簡單的符號(如 #*- 等)即可在純文字中描述文件結構,並可轉換為 HTML、PDF 等格式。

使用 Markdown 的主要原因在於其高效率與可讀性:開發者或使用者不需要撰寫複雜的 HTML,即可快速建立格式清晰的文件;同時,Markdown 本身即具備良好的可讀性,即使未經轉換也能直接理解內容。此外,Markdown 為純文字格式,特別適合版本控制(如 Git),並廣泛應用於 GitHub、Notion 等平台,成為技術文件、筆記與專案說明的主流工具。

Markdown 提供了一種簡單、快速且跨平台的文件撰寫方式,能大幅提升文件整理與溝通效率。

一、標題(Headings)

使用 # 表示標題層級(1~6)

# H1 標題
## H2 標題
### H3 標題
#### H4 標題
##### H5 標題
###### H6 標題

二、清單(Lists)

無序清單

- 項目 A
- 項目 B
    - 子項目 B1
        - 子項目 B1-1

或使用 *

* 項目 A
* 項目 B

有序清單

1. 第一點
2. 第二點
    1. 子項目
        1. 更深一層

三、換行(Line Break)

方法一(建議)

在行尾加兩個空格

這是一行  
這是下一行

方法二

使用 HTML:

<br />

四、文字樣式(Emphasis)

效果 語法 範例
粗體 **文字** 粗體
斜體 *文字* 斜體
粗斜體 ***文字*** 粗斜體
刪除線 ~~文字~~ 刪除

五、顏色(HTML 語法)

Markdown 原生不支援顏色,需要用 HTML:

這是一坨灰色的字
用車床時戴手套可能變成這個顏色
消化不良的時候大概就是這個顏色
TTR藍的色號"62c5e2"要背,考試會考
這是神聖乖乖的顏色

<font color="#96999A">灰色</font>
<font color="#ff0000">紅色</font>
<font color="#62c5e2">藍色</font>

超連結

[Google](https://www.google.com)

👉 顯示: Google


圖片

![圖片說明](圖片網址)
![Markdown Logo](https://markdown-here.com/img/icon256.png)

七、程式碼(Code)

行內程式碼

使用 `git commit`

👉 使用 git commit


程式碼區塊

```python
def hello():
    print("Hello Markdown")

---

## 八、引用與分隔線

### 引用(Quote)

```markdown
> 這是一段引用

👉

這是一段引用


分隔線

---

九、表格(Tables)

| 項目 | 價格 | 備註 |
| :--- | :---: | ---: |
| 蘋果 | 30 | 左對齊 |
| 香蕉 | 20 | 置中 |
| 西瓜 | 100 | 右對齊 |

對齊說明

語法 對齊
:--- 左對齊
:---: 置中
---: 右對齊

十、重點整理(口訣)


延伸資源


📘 TTR Wiki 撰寫指南

一、架構原則

本 Wiki 應採用以下結構設計:

此設計目的在於:


二、書架命名規範(部門)

書架名稱應符合:


三、書本命名規範(工作項目)

書本應對應「一個具體任務或系統」,命名需具備:

✅ 正確範例

❌ 錯誤範例


四、章節撰寫標準(最重要)

每個書本內頁應遵循「工程文件結構」:

建議基本結構

# 1. Overview(概述)
- 目的
- 功能
- 系統位置

# 2. System Architecture(系統架構)
- 架構圖
- 模組說明

# 3. Design(設計)
- 設計理念
- 選型原因

# 4. Implementation(實作)
- 程式 / 電路 / 機構
- 關鍵參數

# 5. Testing(測試)
- 測試方法
- 測試結果

# 6. Debug / Issue(問題紀錄)
- 遇到的問題
- 解法

# 7. Reference(參考資料)

五、撰寫原則

1️⃣ 可交接性(最重要)

文件應讓「新成員能直接接手工作」


2️⃣ 工程導向(避免流水帳)

❌ 不要寫:

✅ 應該寫:


3️⃣ 一致性


4️⃣ 可搜尋性


六、版本與維護


七、禁止事項


八、目標

本 Wiki 的最終目標為:

建立車隊的「工程知識資產系統」,使技術能被累積、傳承與複製。

2026 新進隊員核心知識庫

本章節紀錄了新進成員必須掌握的 FSAE 核心知識,包含規則、技術與實務操作。

2026 新進隊員核心知識庫

第一章:FSAE 賽事精神與車隊文化指南

1.1 這不只是一場比賽,是一次工程創業

歡迎加入車隊!首先要建立一個觀念:Formula SAE (FSAE) 的核心不是造一輛最快的車,而是在一年的時間內,模擬經營一家高科技工程公司。SAE International 創立它的初衷,是希望培養出能「解決真實世界問題」的工程師。

我們追求的三大核心能力

  1. 技術的深度 (Engineering Excellence): 車子快只是結果。我們更看重你是否能解釋「為什麼」這樣設計能讓車變快,以及背後清晰的數據支持。
  2. 務實的商業頭腦 (Business Acumen): 賽車是個燒錢的運動。你必須學會如何在有限的資源下做取捨,並向評審(模擬的投資人)證明你的方案是值得投資的。
  3. 刻在骨子裡的安全意識 (Safety-First Culture): 在賽車場上,任何一個小疏忽都可能造成無法挽回的後果。這也是為什麼規則手冊如此嚴苛,因為它背後是無數前人累積的經驗與教訓。

1.2 車隊,就像一個緊密的作戰單位

每個組別都有其專業,但真正的挑戰在於「協作」。

1.3 給新進隊員的幾點心法

參考與延伸閱讀

2026 新進隊員核心知識庫

第二章:2026 技術規則深度導讀:底盤結構與安全性

2.1 SES:與評審溝通的共同語言

在動手畫第一張設計圖前,請先打開 SES (Structural Equivalency Spreadsheet)。它不是一份讓你打勾的表格,而是你與評審之間關於「安全」的合約。

讀懂管材規範 (F.3.2)

2.2 2026 年安全規則的「弦外之音」

2.3 駕駛艙:不只是座位,更是「逃生艙」

2.4 「防火牆」:隔絕水、火、電

參考與延伸閱讀

2026 新進隊員核心知識庫

第三章:車載電子系統基礎:CAN-Bus 通訊與感測器整合

3.1 CAN-Bus:車輛的語言

想像一下,如果車上每個感測器都需要一對獨立的線連到主控,那線束將會多麼臃腫與沉重。CAN-Bus (Controller Area Network) 就是為了解決這個問題而生的。

核心物理層知識

3.2 感測器:車輛的五感

3.3 2026 電氣安全:高壓電如猛虎

3.4 實用技巧:CAN DBC 檔案

DBC (Data Base CAN) 檔案是解碼 CAN 訊息的「字典」。學會定義和使用 DBC 檔案,能讓你用 MoTeC i2 或其他分析軟體時事半功倍。

參考與延伸閱讀

2026 新進隊員核心知識庫

第四章:賽車製造工藝與實驗室安全作業規範

4.1 安全,是回家的唯一道路

實驗室的安全守則不是為了限制你,而是為了保護你。

4.2 製造的藝術:從圖紙到現實

TIG 焊接的細節

碳纖維的鋪陳之舞

4.3 品質是檢測出來的

參考與延伸閱讀

2026 新進隊員核心知識庫

第五章:靜態項目攻略:技術設計評審 (DR) 與成本報告 (CR)

5.1 設計評審 (DR):這是一場工程辯論

你要面對的,是一群有著幾十年業界經驗的老鳥。他們一眼就能看出你的設計是經過深思熟慮,還是僅僅停留在「能跑就好」的階段。

如何準備一場無懈可擊的 DR

5.2 成本報告 (CR):不只是「報價單」

成本報告的精髓在於展現你的「成本意識」。

5.3 商業簡報 (BPP):賣的不是車,是「夢想」

參考與延伸閱讀