Terry Yao's Blog

[tools] Work 目錄結構：專案組織邏輯

閱讀時間約 8 分鐘

cover

為什麼需要統一的目錄結構？

當你同時管理生產專案、學習原型、開發工具和歷史遺留程式碼時，如果沒有一套清楚的組織邏輯，很快就會陷入「找不到東西」的困境。~/work/ 是我所有開發相關程式碼的根目錄，每個子目錄都有明確的定位和生命週期。

這篇文章記錄我目前的目錄結構設計，以及背後的思考邏輯。

目錄總覽

~/work/
├── legacy/            # 已歸檔的舊專案
├── platform-infra/    # 跨專案共用的基礎設施程式碼
├── prd/               # 正式上線的生產專案
│   ├── blog-source/       # 原始 Hexo 部落格原始碼
│   ├── quartz-blog/       # 目前使用的 Quartz 靜態網站部落格
│   └── terryyaowork.github.io/  # GitHub Pages 部署 repo
├── proto/             # 原型 / 學習實驗專案
│   ├── app/               # Mobile / App 原型
│   ├── b2e/               # 後端原型（Node.js、Python 等）
│   ├── f2e/               # 前端原型（React、Vue 等）
│   ├── git/               # Git 工作流實驗
│   ├── infra/             # 基礎設施原型（Docker、K8s 設定）
│   └── shared/            # 跨原型共用的函式庫 / 工具
├── rustdesk/          # RustDesk 遠端桌面（自架）
├── studio/            # Studio 相關專案
└── tools/             # 開發者工具
    ├── openclaw/          # OpenClaw - AI Agent 框架 + Discord Bot
    └── rustdesk/          # RustDesk 工具設定

Mermaid 階層圖

graph TD
    WORK["~/work/"] --> LEGACY["legacy/"]
    WORK --> PLATFORM["platform-infra/"]
    WORK --> PRD["prd/"]
    WORK --> PROTO["proto/"]
    WORK --> RUSTDESK["rustdesk/"]
    WORK --> STUDIO["studio/"]
    WORK --> TOOLS["tools/"]

    PRD --> BLOG_SRC["blog-source/"]
    PRD --> QUARTZ["quartz-blog/"]
    PRD --> GHPAGES["terryyaowork.github.io/"]

    PROTO --> APP["app/"]
    PROTO --> B2E["b2e/"]
    PROTO --> F2E["f2e/"]
    PROTO --> GIT["git/"]
    PROTO --> INFRA["infra/"]
    PROTO --> SHARED["shared/"]

    TOOLS --> OPENCLAW["openclaw/"]
    TOOLS --> RUSTDESK_T["rustdesk/"]

    style WORK fill:#2d333b,stroke:#539bf5,color:#adbac7
    style PRD fill:#1a4731,stroke:#3fb950,color:#adbac7
    style PROTO fill:#341a00,stroke:#d29922,color:#adbac7
    style TOOLS fill:#2a1a4e,stroke:#a371f7,color:#adbac7
    style LEGACY fill:#3d1f1f,stroke:#f47067,color:#adbac7

各目錄的定位與邏輯

prd/（Production）— 正在服務使用者的程式碼

prd/ 裡面放的是已經部署、正在運作的專案。這些 repo 通常有 CI/CD pipeline，任何 push 都可能觸發自動部署。

專案說明
blog-source/早期使用 Hexo 建置的部落格原始碼，目前已遷移
quartz-blog/現行的部落格，基於 Quartz 靜態網站產生器
terryyaowork.github.io/GitHub Pages 部署 repo，對外呈現的網站

原則：prd/ 的數量應該盡量精簡。如果一個專案不再被使用者存取，就該移到 legacy/。

proto/（Prototypes）— 學習與實驗的沙盒

proto/ 是我花最多時間的地方。每個子目錄按照技術領域分類：

  • f2e/：前端實驗（React、Vue、CSS 技巧、bundler 比較）
  • b2e/：後端實驗（Express API、Python 腳本、資料庫操作）
  • app/：Mobile 或跨平台 App 原型
  • infra/：基礎設施實驗（Docker compose、K8s manifest、Nginx 設定）
  • git/：Git 進階操作實驗（rebase 策略、hook 設定、monorepo 結構）
  • shared/：多個原型共用的程式碼（utility functions、共用型別定義）

原則：每個 proto 都是獨立的、可拋棄的實驗。不需要完美，重點是快速驗證想法。驗證完的結論會整理成部落格文章。

tools/ — 提升開發效率的工具

tools/ 放的是我自己日常使用的開發工具：

  • openclaw/：OpenClaw AI Agent 框架，整合了 Discord Bot、瀏覽器自動化、MCP Server 等功能。這是目前最活躍的工具專案。
  • rustdesk/：RustDesk 遠端桌面的工具設定檔。

原則：tools/ 裡的東西是為了讓自己工作更順暢，不一定會對外發布，但使用頻率很高。

legacy/ — 歸檔但保留參考價值

不再維護的舊專案。不刪除的原因是偶爾需要回頭查某個實作方式或設計決策。

原則：不會有新的 commit。如果某天需要重新啟用，會 fork 一份到 proto/ 或 prd/ 重新開始。

platform-infra/ — 跨專案的共用基礎設施

放的是多個專案共同依賴的基礎設施程式碼，例如共用的部署腳本、環境設定模板等。

Proto 到 Blog 的知識產出流程

這套目錄結構最重要的設計意圖之一，就是建立從實作到知識的轉化路徑：

graph LR
    A["proto/ 動手實驗"] --> B["遇到問題 / 學到模式"]
    B --> C["整理筆記與結論"]
    C --> D["prd/quartz-blog/ 撰寫文章"]
    D --> E["發布到 GitHub Pages"]

    style A fill:#341a00,stroke:#d29922,color:#adbac7
    style D fill:#1a4731,stroke:#3fb950,color:#adbac7
    style E fill:#0d2137,stroke:#539bf5,color:#adbac7

實際例子：

這個流程的好處是：

  1. 實作驅動：不是為了寫文章而寫，而是真的遇到問題、解決問題後的紀錄
  2. 可重現：每篇文章背後都有對應的 proto 程式碼可以跑
  3. 持續累積：proto 越多，能寫的主題就越多

命名慣例

規則範例說明
全小寫 + 連字號blog-source/避免跨平台路徑問題
縮寫需一致f2e/、b2e/front-to-end、back-to-end
proto 內按領域分proto/infra/不按語言分，按用途分
prd 內按專案名prd/quartz-blog/一個 repo 一個資料夾

小結

目錄結構不是一開始就設計好的，而是隨著專案數量增長逐步演化出來的。核心思路就三點：

  1. 依生命週期分層：正式上線（prd）、實驗中（proto）、已退休（legacy）
  2. 依用途分類：工具（tools）、基礎設施（platform-infra）、學習（proto）
  3. 建立知識產出路徑：proto 的實驗成果，透過 blog 轉化為可分享的知識

如果你也在管理多個專案，建議花半小時整理一下自己的目錄結構。一套好的組織方式，能省下未來大量「這個 repo 放哪裡了」的時間。

延伸閱讀

關係圖譜

反向連結

  • 工具與自動化

    這個區塊記錄各種開發工具的配置與使用經驗。 文章列表 ClawdBot 配置指南 Work 目錄結構：專案組織邏輯 知識...