
最後更新:2026 年 6 月 9 日
今早你打開專案,主清單裡有 287 個任務。其中大約四十個是你的。另外 247 個屬於那些你在週一早上不太想看到的人。然而,所有任務全都擠在同一個滾動矩形裡,滑鼠滾輪感覺在跟你作對。
這正是大多數 Quire 使用者發現子清單的時刻,並納悶自己為何沒在第一天就試試看。官方說法是「同一個專案的個人化或篩選後檢視畫面」。說真的,子清單就是讓你把一個共用的 300 個任務專案,從一個你只是忍耐著打開的東西,變成你真的會毫不猶豫去開啟的東西。
2020 年介紹子清單的文章聚焦於設計理念。這篇文章恰好相反。六個具體的工作流程、我們在每個場景中實際採用的配置、值得了解的取捨,以及一個我們特別建議跳過的應用場景。以下每個範例都來自我們真實運作的行銷活動發布和 Agile 工作空間,你可以點進去親眼看看結構,不必憑空想像。
子清單是一個已儲存、已命名、可共享的檢視畫面,顯示同一個專案中部分任務的子集,擁有專屬 URL 和獨立的權限設定。 任務本身只存在一份,在主清單中。子清單只是指向它們。在子清單中編輯任務就是編輯原始任務,因為根本沒有副本。
三點讓 Quire 的子清單有別於其他工具中聽起來類似的功能。
完整運作機制請參閱子清單使用指南。這篇文章的其餘部分是如何實際運用它。
行銷活動發布的專案很快就會膨脹。看看我們實際的行銷活動發布工作空間:一旦活動運作起來,主清單就橫跨七個區段(網站、部落格文章、社群媒體內容、社群媒體平台、電子報、網路研討會、翻譯),並有自訂欄位追蹤平台、預算、時薪、KPI 分數。行銷總監需要這整張全貌,但部落格撰稿人並不需要。

我們的設定方式:每個職能或每種審核狀態各一個子清單。初期手動設定,等標籤分類體系穩定後(通常大約第五天)再轉換為篩選式。
設計審核子清單是最清楚的範例。篩選邏輯是 status = Reviewing 加上 tag = design。設計師只看到等待他們過目的任務;隨著工作完成,子清單會自動清空。不需要在七個區段的 33 個任務中翻找那三個需要審核的任務。

「內容」子清單的運作方式相同:tag = content、assignee in [撰稿人],自動加入任何符合的新任務。同樣的資料,不同的視角。
關鍵突破在於:行銷總監仍從主清單進行跨職能規劃,每個職能負責人從他們的子清單執行工作。同樣的資料,無需對帳,再也不會在週五下午四點出現「哪個版本的追蹤表才是最新的?」這類 Slack 訊息。
關於這如何融入發布營運模型的完整圖景,請參閱我們關於跨職能專案管理的文章。
大多數工程團隊最終形成的模式是這樣的:主清單是 backlog,每兩週的 Sprint 規劃會產生一個子清單,包含本週期要完成的任務。
我們的 Agile 工作空間就是實際範例。backlog 按功能面向(客戶回饋/User stories、網站、桌面應用程式、Android 應用程式、iOS 應用程式)組織,Story Points 作為自訂欄位。在 Sprint 規劃時,團隊多選已決定的任務,使用右鍵 → 設定子清單 → Sprint 47。這就是我們建立Sprint 47 子清單的方式,你現在就可以打開它:目前裡面有兩個來自客戶回饋的真實 bug 工單(「Emojis cannot show correctly」、「Home button doesn't work」),還留有空間讓其餘的 Sprint 承諾任務陸續加入。

這個模式的篩選式版本使用像 sprint-47 這樣的標籤,以及一個自動加入所有帶此標籤任務的篩選式子清單。前期設定多花一點時間,之後零維護成本。
子清單 URL 貼到團隊的 standup 頻道。接下來兩週,工程團隊從這個子清單工作。子清單的看板檢視模式就成為 Sprint board。產品經理查看主清單進行 backlog 梳理和路線圖討論。工程師查看子清單了解進行中的工作。
還有一個額外收獲:到了 retro 時間,子清單就是那次 Sprint 的紀錄。它精確記錄了範圍內有什麼、交付了什麼、被延後了什麼。不需要截圖 Jira board 貼到 Confluence。子清單 URL 就是那份紀錄。
這是子清單對代理商最有價值的應用,也是大多數代理商不知道可以這樣做的功能。同樣的模式也適用於與外部創意夥伴合作的內部團隊(自由設計師、影片剪輯師、翻譯廠商)。任何你的組織外部需要查看工作進展、卻只應看到其相關部分的對象。
我們的設定方式:每個客戶案件(或每個外部合作夥伴流)一個專案。主清單包含所有工作,包括僅限內部的任務:商業談判、內部 QA、獲利狀況標記。以客戶命名的子清單設定權限為外部團隊,只填入客戶應該看到的交付成果和決策。
你可以在行銷活動發布工作空間中看到外部團隊——客戶檢視子清單的結構。在真實案件中,你會填入涉及客戶的交付成果:審核中的部落格文章、設計素材、網路研討會腳本、翻譯稿件。內部利潤備註、私密 QA 討論、用於計費的範疇變更紀錄?這些保留在主清單中,外部團隊 URL 完全看不到。

客戶得到那個 URL,以外部團隊席位開啟,看到交付成果、截止日期、狀態,以及涉及他們的留言。僅此而已。
對於同時管理 8 到 15 個客戶案件的代理商,這個模式可以取代每週 PDF 報告、平行的 Notion 頁面、充滿截圖的狀態更新郵件,以及當客戶問「你們在做什麼?」時因為無從查看而產生的大量來回溝通。
這個工作流程的更深入版本請參閱我們的代理商專案管理文章。簡短版本:外部團隊子清單讓你不再需要維護一份平行的客戶端追蹤表,因為權限邊界由工具強制執行,而不是靠你自己的自律。
一個管理八位直屬成員和四個活躍專案的組長有個週期性難題:每逢週五,他們需要知道什麼完成了、什麼延誤了、接下來有什麼。從四個主清單中整理這些資訊是一個沒人樂意做、大多數人都會略過的 90 分鐘工作。
我們的設定方式:每個專案各一個篩選式子清單,全部命名為「本週」。我們已在行銷活動發布中建立好範本,你可以查看 URL 結構。你需要設定的篩選條件:
due-date in this week 或 completed in this weekassignee in [直屬成員]這正是篩選式子清單大顯身手的應用場景。週中新建且符合條件的任務會自動出現。完成的任務在週期結束後自動消失。無需任何維護。子清單保持最新狀態,因為它是查詢,不是一份手動整理的清單。
如果你不想每個專案都維護一個子清單,子清單 2.0 更新讓你可以在資料夾、智慧資料夾、組織或「我的任務」層級建立子清單。在包含所有四個專案的資料夾上建立一個「本週」子清單,套用一次篩選,這個 URL 就能從旗下每個專案拉取符合的任務。你只需收藏一個連結,週五的檢視一個分頁就搞定。
如果你的工作流程中有 AI 工具,可以搭配 Quire 的 MCP 整合:讓 Claude 讀取每個「本週」子清單,自動起草週五的團隊摘要。AI 現在有了精確範圍的資料來源,而不是整個 backlog。
當有新成員加入,你為他建立一個專屬子清單(例如「入職——Elizabeth」),只加入適用於她職位的任務。權限設定為指定成員:Elizabeth、她的主管、夥伴、人力資源聯絡人。行銷總監和工程主管完全不需要看到這些。Elizabeth 的主管每天查看。

這比文件檔案多出的功能:截止日期、負責人、留言,以及可見的進度。Elizabeth 不用開口詢問就知道下一步是什麼。她的主管在週五瞥一眼子清單就能看到哪裡卡住了。夥伴在自己的任務到期時會收到通知。當 Elizabeth 完成入職後,子清單被封存,而不是刪除。它成為她入職過程實際情況的紀錄,在設計下一位成員的入職流程前,這份紀錄值得好好閱讀。
如果組織已連接 Quire MCP,從 HR 範本或入職會議逐字稿生成專屬子清單只需要一個提示詞。我們在「5 個 AI 專案管理工作流程」中介紹了這個流程。
個人生產力應用場景。這個不算創新,但卻是大多數使用者最先採用、使用最頻繁的功能。
我們的設定方式:一個私人篩選式子清單,命名為「今天」,條件為 assignee = me、due-date = today OR overdue、status != done。我們已在行銷活動發布中建立好今天子清單範本,你可以查看實際結構。在你自己的使用中,將權限設為「私人」,這樣它就不會出現在任何隊友的分頁列中。

子清單固定在專案分頁列的頂端。一天的第一個動作是打開它,最後一個動作是關閉它。在工作時間內,包括那 247 個不屬於你的任務在內的一切,都從視野中消失。
說實話:「今天」子清單本身並不是一個生產力系統,而是在系統內運作的聚焦工具。如果你沒有關於清單上該放什麼、以及如何決定優先順序的習慣,「今天」子清單很快就會變成另一個被你忽略的清單。我們在關於協調成本的文章中探討了這個模式。
當你開始把子清單當作本來就不應共用同一個專案的團隊之間的隔離工具時,它就變成了錯誤的選擇。
這個模式是這樣的:兩個職能正在推進的工作,有著不同的利害關係人、不同的時程、不同的節奏,以及不同的完成定義。有人決定「讓我們把它放在同一個專案裡,各給一個子清單就好」。六週後,兩個團隊都沒有清晰的全貌,主清單亂成一片,子清單各自偏離。
如果兩個工作切片有真正獨立的所有權,它們就屬於兩個專案,而不是兩個子清單。子清單是共享範疇內的聚焦工具,不是替代真實專案邊界的東西。
誠實的判斷標準:如果兩個子清單永遠不會從放在一起查看中獲益(主清單毫無意義或令人困惑),那你擁有的不是一個有兩個檢視的專案,而是兩個共用標籤的專案。
如果你正在猶豫要拆分專案還是使用子清單,有個判斷準則:你會想閱讀主清單嗎?如果會,用子清單。如果不會,就拆分。
完整指南請參閱 quire.io/guide/create-sublists,但以下是大多數人需要的版本:
L 鍵。在任何任務上右鍵點擊選單可以看到設定子清單,用過兩次後你會發現這比拖曳快多了。
以下幾個模式,區分了真正使用子清單的團隊與試用一週後放棄的團隊。
以工作內容命名子清單,而非以人名命名。 「Sara's Tasks」會過時。「Q3 Brand Refresh」即使在 Sara 休假時仍然有用。描述工作切片的名稱能在人員異動後繼續有效。
盡可能使用篩選式子清單。 手動子清單需要維護。篩選式子清單自我更新。前期多花一點時間思考設定,往後每週都能回收這份投資。
固定你真正使用的,封存其餘的。 一牆的固定子清單本身也會成為一種混亂。對大多數團隊來說,三到五個固定子清單是最佳數量。封存(而非刪除)你不再使用的子清單;任務仍保留在主清單中,而當工作流程需要時你也可以重新啟用子清單。
分享 URL,而非截圖。 子清單 URL 是即時的資料來源。把截圖貼到 Slack 是在創造一份平行的文件,任何人更新任務後它就會立即過期。
不要在子清單內隨意調整主清單的排序。 在子清單內重新排序會同步影響主清單。如果你需要不影響主清單的不同排序,你要的可能是獨立的智慧資料夾,而不是子清單。
子清單是讓超過 50 個任務的共用 Quire 專案對每個人都變得可以接受的機制。關鍵不在於篩選本身,而在於篩選被命名、被儲存、被權限控管,並指向同一個資料來源。以上六個真實工作流程(職能專屬的行銷視圖、Sprint 範圍界定、外部團隊客戶視窗、主管週檢視、新員工入職追蹤,以及個人聚焦清單)涵蓋了子清單最能發揮作用的大多數場景。
錯誤用法是用子清單替代本應存在的專案邊界。正確用法是給共用專案中的每個人提供最小、最相關的視圖。大多數說「主清單難以管理」的團隊,其實的意思是「我還沒有設定子清單」。
子清單是 Quire 中同一個專案的個人化或篩選後檢視畫面。任務只存在於主清單一份,並可出現在你建立的任意數量子清單中。在子清單中編輯任務會同步更新主清單,因為兩者是同一個任務,不是副本。
標籤是任務上的中繼資料。篩選是暫時性的搜尋。獨立專案是獨立的資料集。子清單則是一個已儲存、已命名、具備權限控管的相同資料檢視,並擁有專屬 URL。你同時獲得篩選的聚焦感、專案的持久性,以及外部連結的精細共享能力,而不會複製任何一個任務。
Free 方案每個專案可建立兩個子清單。付費方案會提高此上限。大多數達到上限的團隊使用的是 Free 方案,通常在使用 Quire 幾週後才發現子清單,這往往也是考慮升級的時機。完整方案說明請參閱定價頁面。
可以。建立子清單時,你可以選擇「所有成員」、「管理員」、「指定成員」、「外部團隊」或「私人」。「外部團隊」選項是代理商和顧問公司用來讓客戶以唯讀方式查看其相關工作的功能,同時不會暴露內部任務。
從子清單移除任務只會讓它從該檢視消失,任務仍保留在主清單中。刪除子清單本身不會影響其任務,所有任務仍在主清單中。在子清單內重新排序會同步更新主清單的排列順序。在讓任何人「整理」他們的個人子清單之前,這一點值得先了解清楚。
當工作本質上屬於不同的專案,而非不同的檢視時。如果兩個工作切片有各自的利害關係人、各自的時程,以及各自的完成定義,那就是兩個專案,而不是兩個子清單。子清單是聚焦工具,不是團隊之間的界線。
準備好讓你的團隊獲得最精準、最實用的專案視圖了嗎?
子清單在所有 Quire 方案中皆可使用,包含 Free 方案(每個專案兩個子清單)。以上應用場景各只需五分鐘設定。如果運作一週後效果良好,團隊會主動捍衛它;如果沒有,你也只是花了五分鐘。
立即免費開始使用 quire.io/signup。無需信用卡,完整功能存取,30 天試用。在另一個分頁開啟子清單指南,從「今天」子清單開始嘗試。