📘 TTR Wiki 撰寫指南
一、架構原則
本 Wiki 採用以下結構設計：
- 書架（Shelf）：依「部門」分類
- 書本（Book）：依「實際工作項目」命名
- 章節（Chapter / Page）：記錄「執行細節與知識」
此設計目的在於：
- 明確對應責任歸屬（誰負責）
- 保持文件可擴展性
- 避免知識分散與重複
二、書架命名規範（部門）
書架名稱應符合：
- 使用「部門 / 功能」命名
- 避免模糊或過於抽象名稱
- 保持長期穩定（不要頻繁更動）
範例：
三、書本命名規範（工作項目）
書本應對應「一個具體任務或系統」，命名需具備：
- 可辨識性（看到名稱就知道在做什麼）
- 可擴展性（未來可以新增內容）
- 避免過大或過小範圍
✅ 正確範例
- Battery Management System
- STM32 RTOS Development
- Motor Control System
- Suspension Design
- CAN Communication Protocol
❌ 錯誤範例
- STM32（太模糊）
- 電路（範圍過大）
- 雜項（不可用）
四、章節撰寫標準（最重要）
每個書本內頁應遵循「工程文件結構」：
建議基本結構
# 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 的最終目標為：
建立車隊的「工程知識資產系統」，使技術能被累積、傳承與複製。
🎯 補一句（給你用在開頭很加分）
你可以加這段在最前面：
本 Wiki 不僅為文件系統，更是車隊工程能力的累積與傳承基礎。