Notion 在中國用於團隊協作的可行性分析

前言

過去幾年我不曾過多提及 Notion 在團隊協作方面的應用，原因無他，就是權限管理可分配的層級太少，特別是當涉及到資料庫的多人協作，權限要麼過度開放要麼過度封閉，沒有中間地帶，使得很多場景根本無法用 Notion 來協作。

但好消息是，Notion 在最近一年持續補齊了權限體系的關鍵能力，引入了更細緻、更靈活的權限管控功能。再加上 Notion 幾乎是最強的知識庫 Agent 能力，兩個因素加在一起讓我開始認真思考：

所以我花了幾天時間把所有的 Notion 協作場景測試了個遍，終於寫出這麼一篇文章，如果你正好在研究這個需求，應該能給你一些幫助。

下面是這篇文章會覆蓋的重點：

• Notion 的帳號體系
• 頁面共享規則
• 資料庫權限規則
• 成員與團隊協作空間
• 實際協作體驗
• 什麼樣的團隊適合 Notion

Notion 的帳號體系

首先我們需要對 Notion 的帳號體系建立一個整體的框架。

一個信箱可以註冊一個 Notion 帳號，然後一個帳號可以建立多個工作空間（Workspace）

每個工作空間都是一個功能完整的、資料互相獨立的 Notion 筆記庫。如果你用過 Obsidian，那麼 Notion 的工作空間約等於 Obsidian 的倉庫（Vault）。

預設情況下，你既是這個空間的管理員，也是這個空間的成員（Member），如果你的 Notion 從始至終只有你一個人用，也不涉及到任何分享或協作，那麼這篇文章到此結束，後面的內容都不需要再看了。

但如果你需要把 Notion 裡的某個頁面分享給其他人，那麼就需要開始涉及「乍一看有點複雜，但搞懂之後其實很簡單」的 Notion 權限體系，讓我們先從最小的權限單位「頁面」開始講起。

頁面發佈與共享

Notion 的每個頁面都可以選擇共享或者發佈

• 發佈：任何擁有頁面連結的人都可以存取
• 共享：只有被邀請的人才能存取頁面

當使用者被邀請共享，他就成為了這個頁面的訪客（Guest），然後你可以為他分配四種不同的頁面權限，分別是：可以檢視、可以評論、可以編輯、全部權限；前三個比較好理解，第四個「全部權限」意味著你的訪客可以繼續邀請其他人加入這個頁面。

因此如果你不希望這個頁面被擴散存取範圍，給他「可以編輯」就夠了。

如果你要分享的只有一個單一的頁面，則情況就很容易處理，但當你的頁面開始有層級結構，也就是父頁面下巢狀了子頁面，那權限行為就會稍微複雜一點點。

父子頁面權限

基礎規則

子頁面會預設繼承父頁面的權限，也就是說如果你把父頁面分享給了某人，這個人自動就能存取父頁面下的所有子頁面。

但你也可以進入子頁面，然後給這個子頁面單獨授予不同的權限。比如父頁面你只給了「可以檢視」的權限，你可以在子頁面裡單獨給這個人「可以編輯」的權限，或者把這個子頁面的存取權限關掉。

切斷權限繼承

一旦你在子頁面上設定了比父頁面更低一級的權限，比如父頁面是更高一級的「可以編輯」，然後你為子頁面設定了僅「可以檢視」，那麼父子頁面之間的權限繼承鏈就會被切斷。

也就是說，即便這個時候你重新給父頁面授予「全部權限」，子頁面的「權限」也不會有變化，因為這個鏈條已經被切斷了。這個時候你需要單獨去那個子頁面上點擊「恢復設定」，才能讓這個使用者擁有和父頁面相同的權限。

上述邏輯在資料庫中同樣適用，不過「資料庫」會比「頁面」這一單位再進一步複雜一點。

資料庫分享協作

基礎規則

資料庫中的每個條目本質上就是一個頁面，權限繼承的邏輯與前面講的父子頁面完全一致：共享整個資料庫，使用者能看到庫中所有頁面；只共享其中某個頁面，使用者就只能看到那一個。

同樣的，如果你在某個頁面上手動取消了使用者的權限，即使之後重新對整個資料庫授予「全部權限」，那個頁面的權限也不會自動恢復，這與前面提到的「權限斷鏈」效果一致。

另外資料庫還有一個新的權限叫「可以編輯內容」，意思是使用者可以修改資料庫頁面正文的具體內容，但不能修改資料庫本身的結構，比如刪掉屬性、修改檢視、排序、篩選等條件。

因此如果你希望某個協作者能在資料庫裡正常填寫內容，但不想讓對方誤操作了資料庫的基本框架，給他「可以編輯內容」的權限將是比「可以編輯」更安全的選擇。

唯讀 + 可建立

假設你用 Notion 建了一個需求收集庫，希望協作成員都能往裡提交需求。你給了大家「可以編輯」的權限，結果第二天發現有人把別人的需求改了，有人不小心刪掉了好幾頁，還有人把檢視的排序條件調亂了。

你想收回編輯權限，但一旦改成「可檢視」，大家又沒法提交新需求了。

Notion 針對這個場景提供了一個權限組合，也就是只給使用者整個資料庫的**「可檢視」權限**，同時額外允許他在資料庫中建立新頁面。這樣使用者既能看到資料庫裡的所有頁面（但不能編輯），又可以自己新建頁面，且僅擁有自己新建的那個頁面的編輯權限。

不過需要注意的是，上面的「允許建立新頁面」有一個前提就是，使用者必須至少擁有整個資料庫的存取權。如果你沒有把整個資料庫分享給這個使用者，而是只單獨分享了庫中的某幾個頁面，那麼即使你勾選了「允許建立頁面」，這個使用者也是不能在資料庫裡新建頁面的。

那如果你既需要能讓這些使用者建立頁面，又不想讓他們看到整個資料庫，該怎麼辦？

方法一、建立獨立頁面並分享

1. 新建一個頁面，在頁面中放置這個資料庫的鏡像檢視
2. 對資料庫進行過濾，篩選出這個使用者能夠存取的特定頁面
3. 把這個頁面分享給這個使用者

這樣一來使用者既能看到頁面中的資料庫，也能在資料庫中新建頁面，但不能存取他沒有權限的其他資料庫頁面。

方法二、建立表單讓使用者填寫

1. 在資料庫中新建一份表單
2. 分享表單連結給使用者，使用者就可以提交新的內容（建立新的頁面）

更精細的資料庫權限控制

前面講的所有資料庫規則，都是需要你先想好誰該有什麼權限，然後再手動去設定。但 Notion 還提供了一種不同的思路，可以讓權限跟著你的業務邏輯走。

在資料庫中，你也許會給每個頁面分配「負責人」「審閱者」「客戶歸屬」這類人員欄位，這些欄位反映的是你的業務關係，而 Notion 的「頁面級存取權限」可以把這些業務關係直接轉化為權限規則。

誰是建立者，誰就能獲得全部權限；誰被標記為負責人，誰就獲得編輯權限；誰被標記為審閱者，誰就自動獲得評論權限。

當一個專案從員工 A 轉交給員工 B，你只需要在「負責人」欄位裡把 A 換成 B，這個頁面的編輯權限就自動轉移給 B 了。

具體來說你可以這樣做

1. 在資料庫中建立一個「人員」欄位

2. 進入資料庫頁面，然後為「人員」欄位新增對應的負責人

然後在資料庫的共享選單中，找到「頁面級存取權限」，為指定的「人員」屬性建立一條權限規則，例如設為「可以檢視」。規則生效後，只要你在某個頁面的這個「人員」欄位中新增了誰，誰就自動獲得對應的「可以檢視」權限。

到這裡，Notion 在單個頁面和資料庫層面的權限能力基本覆蓋完了，從單頁分享、繼承斷鏈、資料庫權限，到人員欄位自動分配，足以應對大多數內容層面的協作需求。

但上面這些操作，大部分都是在「訪客」身份下完成的。什麼是訪客？當你通過信箱邀請某人檢視或編輯一個頁面時，對方預設就是以訪客（Guest）的身份加入你的工作空間，只能存取你明確分享給他的內容，對工作空間的整體結構毫無感知。

訪客模式在小範圍協作時足夠用，但當團隊開始正式組建，逐頁分享就不夠了，你需要一套更系統的權限管理方案，這時候就輪到「成員」和「團隊協作區」登場了。

團隊協作區

打開 Notion 的側邊欄，你會看到兩個區域，分別是私人區域（Private）和團隊協作區（Teamspace），私人區域顧名思義只有自己能看到，而團隊協作區則可以對其他成員開放。

雖然名字帶著「團隊」，但團隊協作區並不是只有協作才用得上。

你完全可以把它當成頂層資料夾來用，把不同類型的內容和 Private 區隔開。比如你可以為不同的主題建立不同的團隊協作區，側邊欄一眼就能看到結構，不用層層點進去翻。

所以即使你是一個人在用 Notion，團隊協作區作為頂層的內容分區就已經很實用了。而當你確實需要多人協作的時候，它還能在這個基礎上疊加權限管控。

當訪客不夠用時

前面講的頁面共享、資料庫權限都是在解決一個問題，即你怎麼把某些內容開放給別人。訪客機制在小範圍協作裡已經很好用了，尤其適合臨時合作、外部溝通，或者只需要接觸少量內容的場景。

但當協作開始變成一件長期的事，你就會開始思考，這個人要不要進入我的整個工作空間，持續參與這裡的內容生產和組織？到了這一步，訪客身份就不太夠用了，你需要考慮的會是另一個層級，也就是成員（Member）。

邀請成員

在 Notion 中邀請一個人成為成員，有兩個不同的入口

1. 在工作空間的設定中邀請對方成為「工作空間成員」

2. 在某個團隊協作區中直接邀請對方成為該團隊協作區的成員。

不論哪種形式，當你邀請了一個新的成員加入，就需要為這個席位單獨付費。當然邀請的前提是，這個成員需要先擁有一個 Notion 帳號（信箱）。

當他接收到你的成員邀請後，他的帳號下就會出現你的工作空間

他可以點擊進入這個專門用於協作的工作空間，在這個空間下他會擁有獨立的私人區域，每個成員的 Private 筆記都是互相不可見的，在這裡建立的內容只有自己可見。

同時，他也能看到你建立的團隊協作區

不過如上圖所示，有的團隊協作區他預設就加入了，有些團隊協作區則只出現在列表裡，需要請求才可以加入，這是為什麼呢？

回到你的視角，當你建立一個團隊協作區的時候，你可以同時設定它的「可見性」

不同的可見性分別適用於不同的需求和場景：

1. 預設：新成員加入工作空間的那一刻就自動成為這些協作區的成員，不需要任何額外操作。如果你的團隊有一個「全員公告」或「公司知識庫」類型的協作區，設成預設就不用每次有新人入職都手動拉一遍。
2. 開放式：新成員能在側邊欄裡看到它的存在，但需要主動點擊加入。適合那些「不是所有人都需要，但感興趣的人可以自己加」的協作區，比如某個興趣小組或跨部門專案。
3. 封閉式：新成員能看到這個協作區的名字，但點進去會發現需要管理員審批。適合有明確歸屬的部門協作區，比如「設計團隊」或「財務部」，你不希望其他人隨意進出，但也不需要藏著不讓人知道。
4. 私人：沒被邀請的人不會知道它的存在，適合管理層討論、薪酬方案、保密專案這類場景。

所以前面那個新成員看到的現象就可以解釋了，有的協作區他一進來就自動加入了，是因為你設成了「預設」；有的只能看到名字但需要申請，是因為你設成了「開放」或「封閉」；而那些你不想讓他知道的協作區，就可以設定為「私人」。

成員能做什麼

這個成員加入後實際能做什麼，還取決於你給他分配的角色。

假設你給他分配的是「可編輯」權限，他會發現自己可以正常編輯協作區裡的頁面內容，但想把側邊欄裡的某個頁面拖到另一個位置時，發現拖不動；想邀請一個同事進來一起看，發現沒有邀請入口。

這是因為團隊協作區裡的很多能力都是單獨的開關，包括編輯頁面、移動頁面、邀請成員、建立子頁面等等，你可以逐個決定要不要開放給普通成員。

作為協作區的所有者（建立者預設就是所有者），你擁有以上所有能力。所以如果成員發現自己在協作區裡「該有的按鈕沒有」，大概率是你沒有把對應的開關打開。

群組

前面講的所有權限操作，不管是分享頁面、設定資料庫權限、還是管理團隊協作區的成員，都是針對「某個人」來做的。人少的時候沒問題，但當團隊人數多起來之後，你會發現自己在反覆做同樣的事：每次有新人入職，要把同樣的頁面、資料庫、協作區再分享一遍；有人離職，又要一個個去收回。

群組就可以用來解決這個問題，你可以把多個成員放進一個群組，然後用群組為單位來分配權限。新人入職時，把他加進對應的群組，他就自動獲得這個群組已有的所有權限；離職時，把他移出群組，權限就自動收回。

建立群組

在「Notion 系統設定 - 人員 - 群組」中可以建立和管理群組，比如你可以按部門建群組：「設計團隊」「開發團隊」「營運團隊」，也可以按角色建：「管理層」「實習生」等等。

如何使用

群組建立好之後，幾乎所有你能分配權限給「某個人」的地方，都可以換成分配給「某個群組」。

之前講頁面共享時，我們都是填信箱邀請某個人，但如果你有一份文件需要讓整個設計團隊都能看到，直接把「設計團隊」群組加進去就行了，之後設計團隊新來了人，只要把他加進群組，他就自動能看到這份文件。

資料庫的共享選單裡，同樣可以把群組作為權限對象。比如你想讓「營運團隊」對某個資料庫只能檢視不能編輯，直接給這個群組設定「可檢視」權限就行，不用一個個人去設定。

前面講到的團隊協作區也可以把群組加為成員。比如你建立了一個「技術部」協作區，直接把「技術部」群組拉進來，群組裡所有人就自動成為這個協作區的成員。

並且你還可以在頁面的評論或者段落的評論中，用 @ 的方式來呼叫整個部門，或者將通知傳送給特定的群組，這樣就不用一個個地 @ 了

實際協作體驗

花了大量篇幅終於講完了所有重要的權限設定，如果不搞懂這些，什麼流程都搭不起來。不過真正決定一個團隊願不願意留在 Notion 的，可能還是實際的協作體驗更重要。

所以接下來我會快速介紹一下，如果你選擇用 Notion 來協作能獲得什麼樣的效果。

即時協同編輯

Notion 支援多人即時編輯同一個頁面，不會出現內容覆蓋或衝突的問題，每個人的編輯會即時同步到所有人的螢幕上，不需要手動重新整理。你能即時看到其他人的游標位置和正在輸入的內容，頁面右上角會顯示當前正在檢視或編輯這個頁面的成員頭像。

另外 Notion 也有完整的頁面編輯歷史，你可以檢視任意時間點的頁面快照，也可以把頁面恢復到之前的某個版本。免費版可保留 7 天的編輯歷史，Plus 版 30 天，商業版 90 天，企業版則不限時間。

非同步評論溝通

Notion 的協作溝通主要靠評論系統，分為兩種形式：

• 頁面評論：在頁面頂部的討論區發起，
• 行內評論：選中頁面中的某段文字，直接在旁邊新增評論

兩種評論都支援 @ 提及特定成員或群組，被 @ 的人會在通知中心和信箱收到提醒。

對於圍繞文件展開的非同步協作，這套機制是夠用的。評論天然掛在內容旁邊，上下文不會丟失，比在微信群裡討論一個文件細節要高效得多。特別是當你需要對一份方案做多輪修改時，每一輪的回饋意見都能定位到具體段落，不會出現「你說的是哪一段？」這種溝通損耗。

編輯建議

除了評論之外，Notion 還有一個功能叫編輯建議（Suggested Edits）的功能，擁有「可以評論」及以上權限的人，可以直接在頁面上建議增加、修改或刪除內容。

建議的改動會以「藍色增加」與「灰色刪減」的方式標記在頁面中，段落旁邊還會出現一個小卡片，頁面所有者（或擁有編輯權限的人）可以逐條接受或拒絕這些建議，也可以在卡片裡回覆討論。

封存頁面

團隊用 Notion 時間久了，工作區裡一定會累積大量過時的頁面，比如去年的專案計畫、已經結束的活動方案、不再維護的文件。這些頁面刪掉可惜，留著又會干擾搜尋結果和 AI 回答的準確性。

Notion 在今年 3 月上線了**封存（Archive）**功能來解決這個問題。

你可以把過時的頁面標記為封存狀態，封存後頁面頂部會出現一條橫幅，顯示是誰在什麼時候封存的。封存頁面預設不會出現在搜尋結果、側邊欄和資料庫檢視中，但你隨時可以通過篩選條件把它們調出來檢視。

封存和刪除的區別在於，封存只是被搜尋結果隱藏了，頁面本身完好無損，所有連結和引用依然有效，需要的時候一鍵取消封存就能恢復。如果你封存一個父頁面，它下面的所有子頁面也會自動跟著封存。

對於團隊來說，定期封存過時內容可以顯著提升搜尋效率和 AI 回答的品質，因為 AI 在檢索工作區內容時會自動跳過封存頁面，減少被過時資訊誤導的機率。

AI 語音會議

Notion 在 2025 年推出了 AI 語音筆記功能，可以在會議中自動錄音並生成轉錄文字。

會議結束後，AI 會在幾秒內整理出一份結構化的摘要，包括討論要點、行動項目和後續待辦，直接儲存為一個 Notion 頁面。2026 年初這個功能又擴展到了行動端，意味著你不帶電腦參加會議也能用手機錄製語音並轉譯了。

這樣一來，每次會議結束後，AI 就會自動將全文進行轉錄，並提取結構化的重要資訊，團隊成員可以隨時回顧，也可以直接從摘要中提取行動項目分配給對應的負責人。

Agent 協作

Notion 目前的 Agent 能力已經不只是「幫你寫幾句話」的水平了，我為此寫了一系列的長文，如果你感興趣的話可以閱讀以下兩篇文章：

• Notion Agent 的基礎入門
• Notion Custom Agent 7 個實踐

在團隊場景下，Agent 是真的可以節省大量的工作時間，舉幾個具體的例子：

• 有人提需求，自動分類並分配給對應負責人
• 有人寫文件，自動生成摘要供其他成員檢索
• 任務狀態變更，自動通知下游協作者接手
• 客戶來信，自動建專案並拆任務給團隊成員
• 定時彙總多庫進度，推送簡報給管理者
• 會前自動備好上下文，參會人直接進入討論
• 串聯自動化流水線，銜接不同角色的工作
• 基於知識庫自動應答客戶，替新人兜底

這些能力的核心價值在於，它把很多「人人都知道該做，但沒人願意花時間做」的整理工作自動化了。對於五到十人的小團隊來說，可能省下來的就是每天至少一個小時的瑣碎操作。

不過需要說明的是，這些自動化能力目前還需要一定的配置門檻。你需要懂得如何設計資料庫結構、編寫 Agent 指令、設定觸發條件，因此不是開箱即用的。所以它更適合團隊裡有人願意花時間深入研究 Notion 的情況。

總體評價

這次測試下來，我最大的感受是 Notion 在協作權限這件事上，終於跨過了「只是能用」的階段。從單頁面分享、資料庫的「可編輯內容」與「唯讀 + 可建立」組合，再到基於人員欄位的頁面級自動權限分配，整套邏輯已經可以覆蓋一個中小團隊的絕大多數協作場景了。

當一個工具在這種基礎設施層面做到了這個程度，你自然會對它的上限更有信心，也更願意花時間去探索其他的可能性。

當然權限只是協作的地基，真正決定團隊願不願意留在 Notion 的，是日常協作體驗能不能跟上。目前來看，文件協同編輯、評論系統、編輯建議這些能力已經足夠支撐非同步協作，AI Agent 還能在此基礎上接管大量重複性工作。但即時通訊的缺失意味著 Notion 還沒法成為團隊協作的唯一入口，它更適合作為知識和流程的中樞，而不是溝通的中樞。

畢竟就算是 Notion 官方，他們也需要搭配 Slack 一起使用呢。

中國團隊如何選擇

與國內主流工具的差異

如果你在考慮 Notion，大概率也在同時考慮飛書或者釘釘。這幾個工具各有側重，但因為我個人並不完全了解其他幾款工具，因此只能從我能看到的關鍵差異點去進行對比。

1. 軟體生態環境

Notion 顯然是一款面向「外國人」的產品，因此能夠與之聯動的軟體生態並不包含國產軟體，但也正因為這個原因，如果你的工作與 Figma、Github、Linear 或者是谷歌生態更為緊密，那麼 Notion 與這些工具的聯動將能獲得最好的效果。

並且作為 Anthropic 前十的 Token 消耗大戶，Notion 對最新 AI 模型的支援（例如 Gemini、Claude、GPT）是最快且最好的，因此如果你的團隊更看重 AI 方面的能力，那麼 Notion 會更比國內的協作工具更有優勢。

2. 協作溝通方式

如果你的團隊習慣了飛書或者企微那種 IM 即時聊天溝通的協作，比如在群聊裡直接分享文件、討論完一鍵轉任務、文件更新自動推送到群裡，那麼 Notion 目前做不到這些，因為它沒有自己官方的即時通訊工具，因此所有溝通都必須發生在 Notion 生態內部，或者像官方一樣搭配第三方的 IM。

如果你的團隊以非同步協作為主，大家習慣按自己的節奏處理工作，這個限制就不太影響。

3. 資料安全

任何雲端產品的資料安全都是個老生常談的問題，即便是飛書、釘釘也無法避嫌，對於 Notion 這樣一款伺服器在境外的工具就更是如此。

只能說我個人的判斷是，對於 Notion 這樣一款正在飛速發展的產品來說，倒閉跑路一說是絕無可能，但任何成熟的團隊都應該都資料安全保持敬畏之心，定期匯出全庫筆記備份才是上策。幸好 Notion 早已支援全庫匯出為 Markdown、PDF 或者是 HTML 格式，也算是個難能可貴的優點了。

短板有多短

在做出選擇之前，還有幾個更重要的問題需要考慮。這種工具的選擇不在於長板有多長，而在於最短的那塊短板你是否能夠接受。

1. 價格不低

Notion 的免費版功能已經非常齊全，但如果想在協作上好用，至少得訂 Plus 版本，每個席位每年 120 美元，如果想再加上 AI 功能，則需要上商業版，每個席位每年 240 美元。

2. 遷移難度

如果你的團隊已經在飛書、釘釘或者其他平臺上跑通了一套成熟的協作流程，遷移到 Notion 的成本會比你預期的高。適應期、培訓、協作中斷這些都需要提前考慮。

而且 Notion 和國內主流工具的使用邏輯差異比較大，如果團隊成員連文件怎麼建、資料庫是什麼都不清楚，前期的學習曲線會比較陡。所以如果你決定要推這件事，最好確保推動者既是團隊裡最懂 Notion 的人，也有足夠的決策權，遇到阻力的時候才推得動。

3. 存取難度

你的團隊需要願意為了用上最好的 AI 和 Agent 能力，去克服網路穩定性和支付便利性方面的一些小障礙，這點就不展開細說了。

什麼樣的團隊適合

選擇 Notion 作為協作工具與知識庫中樞，不能靠拍腦門決定，不能因為膚淺的或者花哨的功能而動心，畢竟個人筆記遷移尚且困難，團隊文件遷移的難度就更加巨大了。

我認為只有符合以下 3 個特徵的團隊才有必要將 Notion 納入考慮。

1. 追求更高工作流上限的團隊

願意花時間去沉澱知識庫、雕琢協作流程，想把 AI Agent 深度融入日常工作，而且團隊成員至少有基礎的 Notion 使用經驗。滿足這些條件，Notion 帶來的回報會非常高。

2. 核心產出是知識密集型工作的團隊

比如內容創作、產品設計、諮詢、研究。日常產出的就是文件、方案、知識庫，Notion 能把這些分散的知識組織起來、關聯起來，讓資訊在團隊內部流動而不是沉沒在各自的資料夾裡。

3. 願意把工作空間當成長期資產去經營的團隊

Notion 的回報是複利式的，資料庫結構、權限規則、Agent 工作流，用的時間越長，累積的資訊越多，效率提升就越明顯。我願意花幾天時間寫這篇文章，說到底是因為我覺得 Notion 對知識工作者來說是真的好用。

它和其他所有文件類、知識庫類的產品都不一樣，它能提供的上限是最高的。目前最前沿的 AI 公司，比如 OpenAI 和 Anthropic，內部都在用 Notion，這也從側面驗證了一點，在知識密度最高的團隊裡，Notion 的協作能力經得起檢驗。

以上就是我這次測試下來的全部感受和建議，每個團隊的情況不同，適合的工具也不同，我能做的就是把我實際測過的東西盡量寫清楚，但肯定還有很多角度和場景無法一一涉及，因此如果你在實際使用中遇到了什麼問題，歡迎在評論區留言，我會持續解答。