📘 TTR Wiki 撰寫指南

一、架構原則 
 本 Wiki 應採用以下結構設計： 
 
 書架（Shelf） ：依「部門」分類 
 書本（Book） ：依「實際工作項目」命名 
 章節（Chapter / Page） ：記錄「執行細節與知識」 
 
 此設計目的在於： 
 
 明確對應責任歸屬（誰負責） 
 保持文件可擴展性 
 避免知識分散與重複 
 
 
 二、書架命名規範（部門） 
 書架名稱應符合： 
 
 使用車隊各「部門」命名 
 避免模糊或過於抽象名稱 
 保持長期穩定（不要頻繁更動） 
 
 
 三、書本命名規範（工作項目） 
 書本應對應「一個具體任務或系統」，命名需具備： 
 
 可辨識性（看到名稱就知道在做什麼） 
 可擴展性（未來可以新增內容） 
 避免過大或過小範圍 
 
 ✅ 正確範例 
 
 電池管理系統(BMS) 
 懸吊系統 
 車身人因工程 
 數據分析 
 STM32 嵌入式系統 
 車隊運營 
 專案管理 
 
 ❌ 錯誤範例 
 
 STM cube IDE 教學 (範圍過小) 
 電路（範圍過大） 
 雜項（不可用） 
 
 
 四、章節撰寫標準（最重要） 
 每個書本內頁應遵循「工程文件結構」： 
 建議基本結構 
 # 1. Overview（概述）
- 目的
- 功能
- 系統位置

# 2. System Architecture（系統架構）
- 架構圖
- 模組說明

# 3. Design（設計）
- 設計理念
- 選型原因

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

# 5. Testing（測試）
- 測試方法
- 測試結果

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

# 7. Reference（參考資料）
 
 
 五、撰寫原則 
 1️⃣ 可交接性（最重要） 
 文件應讓「新成員能直接接手工作」 
 
 2️⃣ 工程導向（避免流水帳） 
 ❌ 不要寫： 
 
 今天做了什麼 
 
 ✅ 應該寫： 
 
 為什麼這樣設計 
 遇到什麼問題 
 如何解決 
 
 
 3️⃣ 一致性 
 
 標題格式統一（使用 Markdown） 
 命名規則一致 
 單位（V / A / mm）統一 
 
 
 4️⃣ 可搜尋性 
 
 使用關鍵字（如 CAN、BMS、PID） 
 避免模糊描述 
 
 
 六、版本與維護 
 
 每次重要修改需更新內容 
 避免刪除舊資料（可標註 deprecated） 
 Debug 與 Failure Case 必須保留 
 
 
 七、禁止事項 
 
 ❌ 不可建立「雜項」、「其他」類型書本 
 ❌ 不可僅貼程式碼無說明 
 ❌ 不可只放圖片無解釋 
 ❌ 不可寫無法理解的個人筆記 
 
 
 八、目標 
 本 Wiki 的最終目標為： 
 
 建立車隊的「工程知識資產系統」，使技術能被累積、傳承與複製。