# 系統設計理念 (https://21notion.com/zh-TW/docs/faq/system-design)

import { Accordion, Accordions } from 'fumadocs-ui/components/accordion';
import { Steps, Step } from 'fumadocs-ui/components/steps';
import { Card, Cards } from 'fumadocs-ui/components/card';
import { BlogCTA } from '@/components/blog/blog-cta';

本頁面解釋 FLO.W 模板的核心設計理念，幫助你理解「為什麼這樣設計」，從而更好地使用模板。

<BlogCTA title="📖 FLO.W 設計初衷" description="了解 FLO.W 模板為什麼這樣設計，背後的產品理念和資訊架構哲學。" highlights={[]} buttonText="閱讀設計初衷" href="/flow/design-philosophy" variant="minimal" />

<Cards>
  <Card title="理解何為領域" href="/docs/basic-feature/area" />
</Cards>

## 元資訊架構

<Accordions type="single">
  <Accordion title="為什麼任務和專案的資料庫要分開建立？" id="task-project-database">
    **讀者提問：**
    請問為何不將專案資料庫與任務資料庫合併管理呢？資料庫本身就具有子任務功能，在同一個資料庫中就可以實現嵌套，理論上不需要第二個資料庫。是怕任務資料庫太複雜嗎？還是說有函式或者屬性之類的會與任務衝突？

    **我的回答：**
    這個問題其實也可以這麼問，為什麼【一級領域】和【二級領域】這兩個資料庫不合併在一起？或者當你有「A 和 B 資料庫為什麼不放在一起」的疑問時，都可以參考下面的回答，你也能了解我設計這套模板的一些思路。

    <Steps>
      <Step>
        <h4>
          原因 1: 元資訊
        </h4>

        <p>
          首先 FLO.W 這個系統的建立是以 4 種元資訊為基礎的，理解什麼是「元資訊」是回答這個問題的關鍵。非常推薦你閱讀下面這篇文章，並搜索關鍵詞「有限的元資訊類型」。
        </p>

        <p>
          文章連結： 

          <a href="/blog/notion-7-year-reflection">重新審視 Notion，我的七年心得感悟</a>
        </p>

        <img src="https://pic.eryinote.com/PicGo/202509130133919.png" alt="元資訊示意圖" />

        <p>
          <strong>專案：</strong>
        </p>

        <ul>
          <li>
            是一個目標容器，代表一個需要透過多個步驟才能實現的、有明確開始和結束的成果
          </li>

          <li>
            它的用途是「定義方向」和「衡量進展」，因此它的核心屬性是「進度條」、「專案週期」、「所屬領域」等戰略性欄位
          </li>
        </ul>

        <p>
          <strong>任務：</strong>
        </p>

        <ul>
          <li>
            是一個行動單元，代表一個可以立即著手去做的、具體的的動作
          </li>

          <li>
            它的用途是「驅動執行」。因此它的核心屬性是「下一步做什麼?」、「排期」、「狀態」等執行性欄位
          </li>
        </ul>

        <p>
          不同的資料庫作為不同的資訊容器，透過互相關聯，來定義資訊的類型和流動方向，這一點在上面的文章有詳細介紹，有時間的話建議稍微讀一下，能系統了解本套模板的構建思路。
        </p>
      </Step>

      <Step>
        <h4>
          原因 2: 欄位混淆
        </h4>

        <p>
          基於元資訊的定義，【任務】和【專案】的資料庫必然需要各自獨立，否則欄位就會混在一起，使得每個欄位都需要承載兩套使用邏輯。一個具體的「任務」條目裡，會出現「專案進度條」這種無效欄位；一個「專案」條目裡，又會出現「下一步做什麼?」這種執行欄位。
        </p>

        <p>
          這會讓資料庫變得異常臃腫和混亂，也會增加記錄時的工作量，需要重複翻找才能找到合適的那個欄位。
        </p>
      </Step>

      <Step>
        <h4>
          原因 3: 子任務的視圖並不自由
        </h4>

        <p>
          如果把【任務】作為 sub-item 放在【專案】之下，那麼以我長久以來的實踐經驗來看，未來必然會遇到非常多的【視圖過濾篩選】問題。
        </p>
      </Step>

      <Step>
        <h4>
          原因 4: 函式統計
        </h4>

        <p>
          現在【任務】和【專案】都有各自的函式統計報表，必須分開在不同的資料庫內存放，函式統計才可以良好運行，降低複雜度，也能減少函式統計時的效能開銷。
        </p>

        <p>
          函式統計參考：

          <a href="https://leon21.notion.site/2200e68aa046808aaa86ebd2f45fa07f?v=2200e68aa04680ce9657000c1e713a40&source=copy_link">點我</a>
        </p>
      </Step>
    </Steps>
  </Accordion>

  <Accordion title="沒有專案的任務如何管理" id="task-without-project">
    **問題**：我每天的工作都比較瑣碎，並且都不足以歸類到某一個具體的專案上，但又屬於某一個特定的工作領域，這種情況該怎麼做才能更好地管理這些任務？

    **參考方法**：

    1. 建立一個「六月工作彙總」的專案
    2. 將這個月所有瑣碎任務都關聯到這個專案上
    3. 將這個專案關聯到特定的二級領域
    4. 實現以下層級結構
       * 二級領域 XXX
         * 202506 - 工作彙總
           * 瑣碎任務 1
           * 瑣碎任務 2
  </Accordion>
</Accordions>

## 領域設計

<Accordions type="single">
  <Accordion title="暫時沒有領域歸屬的筆記怎麼記" id="unassigned-notes">
    **問題**

    經常遇到一些筆記它暫時不屬於任何當前已建立的領域，但是又有留存的必要，為了它單獨建立一個領域不值得，但不建立領域又少了一個分類的維度，怎麼辦？

    **回答**

    我在 FLO.W 系統的領域模組裡，留存了一個「無領域筆記」視圖，篩選出了所有「沒有設定一級或二級領域」的筆記。這樣一來你就可以集中查看那些沒有設定領域的筆記，看看它們是否存在哪些共性，如果有的話，或許就可以為這些筆記建立一個「一級」或者「二級」領域了。
    ![FLO.W 領域專精導航，展示領域相關的各項視圖和功能模組](https://pic.eryinote.com/PicGo/202509130216987.png)
    因此如果你覺得這個模組有必要顯示出來的話，可以直接在導航列上 @ 這個頁面。（方法參考 @導航列影片完整解讀 ）
  </Accordion>

  <Accordion title="為什麼領域不能無限制分級擴張" id="area-limit">
    **問題**
    模板裡的領域有一級二級，如何建立三級四級呢

    **回答**
    本模板在「領域」模組中採用「一級」與「二級」的雙層結構，是經過審慎設計的。其目的是在「宏觀戰略」與「具體行動」之間建立最清晰、最高效的連接。在考慮增加更多層級前，理解其設計初衷至關重要。
    首先你需要先閱讀 [理解何為領域](/docs/basic-feature/area) 這篇文章，然後再往下閱讀。

    限制地增加三級、四級領域，容易導致管理結構臃腫、決策負擔加重，並可能讓資訊固化在某個角落，違背了資訊流動的核心理念。當需要比二級領域更精細的分類時，不推薦直接建立新的資料庫層級，而是建議根據其本質，選擇以下兩種更符合系統邏輯的路徑。

    <Accordions type="single">
      <Accordion title="路徑一：若它是一個「有始有終的目標」，請將其轉化為「專案 (Project)」" id="turn-to-project">
        當一個想法的本質是「為了完成某件具體的事」時，它更適合作為專案進行管理。

        * **場景示例**：
          在一級領域「職業發展」和二級領域「資料分析能力」下，想要開始學習 Python。此時不應建立三級領域「Python學習」。
        * **推薦操作**：
          在 `Project｜專案管理` 資料庫中，建立一個名為「學習 - Python 基礎入門」的新專案，並將其關聯到二級領域「資料分析能力」。
        * **核心優勢**：
          專案天然具備目標和時限，能驅動具體任務的拆解和執行，形成行動閉環。專案完成後歸檔，能保持領域結構的長期清爽與戰略性。
      </Accordion>

      <Accordion title="路徑二：若它是一個「需長期積累的知識主題」，請將其轉化為「專題筆記 」" id="turn-to-subject">
        當一個想法的本質是「長期持續的方向」時，它更適合作為專案進行管理。

        當一個想法的本質是「需要對某個特定知識領域進行深度梳理」時，它更適合作為知識網路的核心節點。

        * **場景示例**：
          在一級領域「個人心智成長」下，對「斯多葛主義哲學」產生了深厚興趣，並希望系統整理。
        * **推薦操作**：
          1. 在 `筆記管理` 資料庫中，建立一篇名為「專題：斯多葛主義哲學研究」的筆記。
          2. 將這篇筆記關聯到一級領域「個人心智成長」。
          3. 所有關於此主題的更細分的筆記（如讀書筆記、個人思考等），都透過「父/子級」關係連結到這篇「專題筆記」上。
        * **核心優勢**：
          以筆記為核心構建知識網路，比建立僵化的層級更靈活、更輕便。專題筆記頁面本身就成為該主題的思考中心與索引目錄。
      </Accordion>

      <Accordion title="決策路徑總覽" id="strategy">
        \| --- | --- | --- |
        \| 一個**有明確目標、能在一段時間內完成**的事情 | 將其定義為一個 **`專案 (Project)`** | 用 **行動** 來定義目標 |
        \| 一個**需要長期學習和積累**的知識主題 | 將其建立為一篇 **`專題筆記 (Topic Note)`** | 用 **知識** 來組織知識 |
      </Accordion>
    </Accordions>
  </Accordion>

  <Accordion title="為什麼原則是筆記而非領域" id="principle-note">
    **社群讀者提問**

    > 我有一些需要長期踐行的個人原則，想為它建立一個專案來不斷完善。我感覺它應該屬於【個人成長】這個一級領域之下，但又覺得它像一個二級領域。我該如何安放它，才能構建出【`個人成長 -> 踐行原則 -> 完善原則的專案 -> 具體任務`】 這樣的層級呢？

    **我的回答**

    **一、【領域】是房間，【筆記】是書**

    在開始操作前，我們首先要建立一個認知

    * **【領域 Area】是「房間」**：它代表你人生的一個長期責任區，是一個你需要持續打理和投入的空間，比如書房（個人成長）、廚房（健康管理）。它是結構，是容器。
    * **【筆記 Note】是「書」或「工具」**：它代表具體的知識、資訊、方法論、參考資料。你的「個人原則」就是一本需要被反覆閱讀和修訂的「人生指導手冊」。它是內容，是實體。

    讀者問題的核心困惑，就在於**試圖將一本「書」，當成一個「房間」來對待**。

    **二、錯誤的做法：用層級硬塞**

    如果我們遵循傳統資料夾的層級思維，就會像提問者那樣，試圖構建一個看似合理的層級鏈條：

    * 一級領域：個人成長 (房間)
      * 二級領域：踐行原則 (試圖把書當成一個小房間)
        * 專案：完善個人原則
          * 任務...

    這個結構的問題在於，【踐行原則】本身並不具備【領域】的特性——它沒有獨立的、需要長期投入的目標，它本身就是一份需要被參考的「內容」。強行把它設為二級領域，會讓你的領域結構變得既有房間，又有書，造成混亂。

    **三、FLO.W 的解決方案**

    <Steps>
      <Step title="為「原則」正名，將它歸入【筆記】">
        「踐行原則」是高度濃縮的智慧結晶，是指導你行動的SOP，這正是【筆記】資料庫存在的意義。

        1. 進入 `筆記管理` 資料庫
        2. 建立一個新的筆記，標題可以是「我的個人踐行原則」
        3. 在這篇筆記的頁面內部，詳細寫下你的每一條原則
        4. 將這篇筆記關聯到【一級領域】的「個人成長」

        現在，你的「書」已經放進了正確的「房間」。
      </Step>

      <Step title="用「關聯」連接【專案】與【筆記】">
        現在，你可以為「完善原則」這個目標建立一個專案，並讓它和你剛剛建立的原則筆記產生聯動。

        1. 進入 `專案管理` 資料庫
        2. 建立一個新專案，例如：「Q4 個人原則覆盤與迭代」
        3. 將這個專案關聯到【二級領域】的「個人心智模型建設」（或者其他你自定義的二級領域）下
        4. **最關鍵的一步**：在這個專案的「關聯筆記」屬性中，找到並關聯上你那篇名為「我的個人踐行原則」的筆記

        這樣一來，我們就構建了一個全新的、更強大的結構：

        * **一級領域：** 個人成長
          * **二級領域：** 個人心智模型建設
            * **專案：** Q4 個人原則覆盤與迭代
              * **關聯的筆記** **【我的個人踐行原則】**
              * **任務：** 1. 覆盤上季度原則執行情況...

        【原則】這篇筆記不再是層級鏈條中僵化的一環，而是像一個外掛的知識 U 盤，靈活地插入到了需要它的專案中。
      </Step>
    </Steps>

    **這種做法的好處是：**

    * **結構清晰**：你的【領域】結構永遠只存放責任區，保持著戰略高度的純粹性
    * **高度靈活**：同一篇「原則」筆記，未來還可以被「年度規劃專案」、「人際關係覆盤專案」等多個不同的專案所關聯複用，真正實現知識的流動

    當你遇到一個新概念，不確定該如何安放時，可以問自己一個問題：它是一個我需要長期負責的「地方」，還是一個我需要參考或行動的「東西」？

    * 如果是「地方」，它應該是一個領域
    * 如果是「東西」，它很可能是一篇【筆記】或一個【專案】
  </Accordion>
</Accordions>

***

**想深入了解？** 閱讀 [FLO.W 設計初衷](/flow/design-philosophy) 或 [重新審視 Notion，我的七年心得感悟](/blog/notion-7-year-reflection)。