目錄
2026年8月r/Notion 出現一個很值得看的產品需求：希望 Notion 能提供一個直接放進頁面裡的 AI 搜尋元件，讓工作區搜尋不必每次都從全域入口重新開始。這類需求其實不是第一次出現，過去就有人希望官方提供能嵌在頁面裡的 Search Bar；到了 Notion AI 已經能回答工作區問題、跨 Connected Apps 找資料之後，需求自然又往前走了一步：如果 Enterprise Search 已經可以限定特定 Page、Teamspace 或 Source，能不能乾脆把這個範圍固定在專案頁裡，讓搜尋入口跟著工作情境一起留下來？
同一天，r/Notion 還有人抱怨生成式 AI 至今仍缺少穩定的長期知識層，包括建立好的知識無法自然持續使用、Private Knowledge 很難完整接入、Context 每次都得重新整理，以及先前聊過的內容過一陣子又得重新找。相同內容也被發帖者貼到 r/ChatGPT，因此比較準確的描述是一名使用者把同一組問題帶到不同 AI 社群討論，而不是兩名 Notion 使用者各自提出相同案例。把這些討論放在一起看，真正碰到的其實不是「模型記性夠不夠好」，而是 Context 到底由誰管理；對生產力工具來說，AI 不一定需要永久記住所有事情，只要每次開始工作時都能知道這個問題應該查哪一批資料，很多所謂的「記憶問題」其實都可以先從 Retrieval 這一層解決。
Notion Enterprise Search現在已經能做到什麼？
搜尋範圍其實已經可以縮到特定Page或Teamspace
Notion 的 Enterprise Search 目前提供給 Business 與 Enterprise 方案，主要入口位於 Home，可以搜尋 Notion Workspace、已連接的 Slack、Google Drive、Microsoft Teams、Jira 等來源，也能加入 Web Search；當答案使用 Workspace 或 Connected Apps 裡的資料時，Notion 會附上來源，方便回到原始內容確認。現在也不是只能一次搜尋整個 Workspace，使用者可以加入特定 Page 或 Person 作為 Context，也能指定 Page、Teamspace 與 Person，還可以從 Sources 裡只留下 Workspace、特定 Connected App，或把工作區範圍進一步縮到某個 Page 或 Teamspace。
模型方面，目前 Enterprise Search 可以在 OpenAI 的 GPT、Anthropic 的 Claude 與 Google 的 Gemini 之間切換，不過不同模型可以使用的資料來源不一定完全相同，因此不能只看模型名稱就假設搜尋能力一致。這也代表社群真正缺的不是「限縮搜尋範圍」這項能力，而是把已經設定好的搜尋範圍直接保存成某一頁的固定操作介面；現在每次進 Enterprise Search，仍然需要重新指定 Context 或 Scope，如果一個專案長期都只需要查 Project Brief、Decision Log、Meeting Notes 與相關文件，自然會希望這組設定能直接留在專案首頁。
Notion其實已經有AI Block，只是它還不是互動式搜尋框
AI Block已經可以放進頁面，也能指定Context
討論「可嵌入式 AI 搜尋」時，很容易漏掉 Notion 現在其實已經有 /AI Block。AI Block 可以直接插入 Page，不只可以處理目前頁面的內容，建立時也能設定 Prompt、指定 Workspace 或 Connected Apps 裡的 Context 與 Search Sources，完成設定後按下 Generate，就會依照目前資料產生結果，後續需要更新時再重新 Generate。
例如專案首頁可以放一個 AI Block，固定要求系統根據需求文件、Decision Log 與 Meeting Notes 整理目前尚未確認的決策、進度風險與下一步；如果每個專案都有類似需求，也能把 AI Block 放進 Database Template，讓新建立的 Project Page 自動帶著相同的 Prompt 與 Context 設計。這已經很接近「AI 跟著頁面走」，但和社群真正想要的東西還是有差，因為 AI Block 比較像「固定問題＋固定資料來源＋手動重新生成結果」，並不是一個能讓每位瀏覽者直接在頁面裡輸入不同問題、繼續追問，而且搜尋 Scope 已經事先設定好的 Enterprise Search Widget。
換句話說，Notion 現在其實已經完成這個需求的一半：固定 Context 做得到，缺的是一個可以在既定 Context 裡自由提問的 Query Interface。
為什麼「搜尋範圍跟著頁面走」會比每次從全域開始更方便？
Scope會影響Retrieval品質，但不是越小越好
在 Retrieval-Augmented Generation 的架構裡，回答品質不只受模型能力影響，前面的 Retrieval 找回哪些資料同樣重要。假設一個公司 Workspace 已經累積五年的 Project Pages，同一個專案名稱也曾重複使用，直接從全部資料裡問「這個專案的交付日是哪一天」，確實可能把舊版規格、歷史專案或名稱相近的文件一起帶進候選資料；如果搜尋入口本來就在目前專案頁上，而且預設 Context 已經指向正確的 Project，這類不相關內容被拉進來的機率自然比較低。
但這不代表搜尋範圍越小，答案一定越準。真正的答案有時可能存在公司共用政策、另一個 Teamspace，甚至某次 Slack 決議裡，如果 Scope 鎖得太窄，反而會把需要的證據一起排除。比較合理的理解是把 Scope 當成 Intent 的一部分：問「這個客戶上次確認了什麼」時，客戶頁面就是很自然的起點；但如果問的是「公司目前統一的報價政策」，就不該只查單一專案。
所以頁面型 AI Search 真正的價值，不是把搜尋永遠縮到最小，而是讓最常用的 Context 可以預先設定，不必每一次提問前都重新告訴系統現在正在處理哪一件事。
「永久記憶」不一定只能靠模型記住，也可以靠Knowledge Layer處理
Storage、Retrieval與Memory其實是三個不同問題
8 月 20 日那則討論把不少問題混在一起，包括 AI 缺少 Permanent Storage、無法自然接上 Private Knowledge、記得之後又忘記、不同聊天之間沒有完整的 Cross-chat Memory，以及每次建立 Context、保存 Chat、重新找回資料都很麻煩。這些使用感受很容易理解，但從系統設計來看，其實混合了 Storage、Retrieval 與 Memory 三件不同的事情。
Storage 解決的是資料到底有沒有被保存，Retrieval 解決的是需要時能不能重新找到正確資料，Memory 才是模型會不會跨對話保留過去的互動與偏好。Notion 比較有優勢的其實是前兩層，Page、Database、Files 與 Connected Apps 本來就是 Knowledge Storage，Enterprise Search 負責 Retrieval，模型則是在最上層讀取被找到的 Context 再組成回答。這種架構不需要要求模型「永遠記得去年那次會議」，只需要去年那次會議仍然存在，而且今天需要時能被正確找回。
一個可以固定在專案頁上的 AI Search Widget，真正改善的也是這一層：不是替模型新增永久記憶，而是把 Retrieval 的入口留在工作發生的位置。
權限確實是嵌入式AI搜尋需要處理的問題，但不能直接拿來解釋Notion為什麼還沒做
Enterprise Search本來就會依目前查詢者的權限過濾
如果一個 AI Search Block 是由能看到 A、B、C 三份文件的人建立，但另一名瀏覽者只能看到 B，確實會產生一個很實際的設計問題：搜尋結果到底要依建立者還是瀏覽者的權限產生？不過，這個問題不能直接被拿來推論成「Notion 就是因為權限太複雜，所以還沒有做 Embedded Search」。
現有 Enterprise Search 已經具備 Permission-aware Retrieval，搜尋結果會依目前查詢者在 Notion 與 Connected Apps 裡的 Access Rights 過濾，使用者原本沒有權限查看的內容，不會因為進入 Enterprise Search 就突然變成可見。如果未來真的推出互動式 Page Search Widget，比較合理的做法也是每一次 Query 都按照目前 Viewer 的權限重新執行，同一個 Widget 對不同使用者提供不同內容，本來就是權限型搜尋很正常的結果。
比較需要留意的是現有 AI Block。AI Block 生成後的文字本身已經成為 Page Content，如果建立者利用自己可以存取的敏感資料產生一段摘要，再把這張 Page 分享給原本沒有那些來源權限的人，分享出去的是已經生成完成的文字，不會因為底層文件權限不同就自動消失。因此，在公司環境使用固定 AI Block 時，生成內容還是要當成一般頁面內容檢查，不能認為來源文件有 Permission，產生後的文字就會自動繼承相同限制。
成本可能影響產品設計，但嵌入頁面不代表每次打開都會重新跑AI
另一個很容易出現的推論，是如果五十個專案頁都放 AI Search Widget，每次有人打開頁面就會產生一次模型呼叫，成本自然會變得很高。但這不是 Embedded Search 必然的設計方式，搜尋框完全可以等使用者真的輸入問題後才開始執行，就和現在 Enterprise Search 一樣。
現有 AI Block 也已經證明這件事，它不是每次打開 Page 就自動重新運算，而是使用者按下 Generate 才更新。因此，「嵌入頁面＝每次 Page Load 都燒一次 AI 額度」不能當成既定條件；未來若真的推出互動式 Search Block，Cache、Usage Allowance、Concurrency 與不同 Viewer 的 Query History 當然都可能需要另外設計，但 Notion 沒有公開表示這些因素就是功能目前缺席的原因，文章不需要替官方先補答案。
工作區越大，AI搜尋就一定越差嗎？
問題通常不是資料多，而是哪一份才是Current與Authoritative不清楚
同週 r/Notion 有幾篇關於「系統越建越多」的討論，可以拿來補充這個問題，但不能直接推成「頁面越多，AI 一定越不準」。其中一名使用 Notion 六年的使用者表示，Writing、Tasks、Inventories、Finances 幾乎全部留在 Notion，也曾經很享受不停建立新 Structures，但後來開始重新思考自己與 Notion 的使用方式；不過，那篇討論同時牽涉 Privacy、Local-first 與對 Generative AI 產品方向的疑慮，不能單純整理成「系統建太大所以不好用」。
另一則 Habit Tracker 貼文則更單純，發帖者花了一個週末建立 Tracker，只使用 11 天就不再打開，但留言裡也有人表示自己的 Tracker 已經持續使用兩年甚至五年，因此不能拿一個人的放棄經驗證明 Habit Tracking 天生無法維持。比較合理的結論是，結構能不能長期留下來，依然取決於實際需求和維護成本。
這件事和 AI Search 的關聯，也不需要寫成「資料越多就是越多雜訊」。大型 Knowledge Base 完全可以很好用，真正麻煩的是同一件事情同時存在很多版本，卻沒有清楚的 Status、Owner、Date 或 Source of Truth；這時不論是人還是 Retrieval System，都比較難判斷哪一份才是目前應該採用的資訊。
小型Notion資料庫為什麼常常比較容易理解？
共同點不是越小越好，而是用途很容易說清楚
本週有一名大一新生分享，原本使用 Excel 收集 TikTok Creator Accounts 做小型研究，搬進 Notion 後發現資訊比較容易整理與回頭尋找；留言也提醒，Database 當然可以做得非常複雜，但沒必要在需求出現以前先把所有功能都蓋好。車輛保養 Tracker 則是另一個範圍很清楚的例子，作者依照社群回饋增加「距離上次 Tire Rotation 已經行駛多少里程」等欄位，整套系統仍然圍繞 Service Log、Insurance、Warranty、Fuel、Reminders 與 TCO 等車輛管理需求，沒有一路膨脹成管理所有生活事項的 Dashboard。
另一名使用者則把 Notion 用來整理家人的癌症治療資訊，包括 Appointment、Medical Reports、Treatment Progress 與準備詢問醫師的問題，也提到自己以前曾經陷入把 Notion 做得過度複雜的狀態，這一次反而因為需求很明確，才更清楚哪些資料真的需要留下。這些案例比較適合支持的不是「Database 一定要小」，而是每一套 Database 最好能很快說清楚正在處理什麼問題；用途越明確，不論之後是人自己找資料，還是告訴 AI 應該查哪裡，都比較容易。
現在沒有互動式AI搜尋Widget，可以先怎麼做？
臨時問題直接用Enterprise Search縮小Scope
如果只是臨時想問「這個專案最後確認的交付日是哪一天」，最直接的方式還是使用 Enterprise Search，把 Scope 指向目前 Project Page 或 Teamspace 再開始 Query。Notion 現在已經支援這種搜尋粒度，不需要每一次都查完整 Workspace、全部 Connected Apps 與 Web，而且這也比只在 Prompt 裡寫「請只看 Project A」更清楚，因為 Scope 本身就是 Search Interface 的一部分。
固定會問的問題可以直接做成AI Block
如果問題每週幾乎都一樣，例如整理專案目前尚未解決的 Decisions、找出沒有 Owner 的 Action Items，或整理客戶最近幾次 Meeting 的結論，現在其實已經不用等新的 Search Widget。可以直接在 Project Template 裡加入 AI Block，把 Context 指向需要的 Pages 或 Connected Sources，再把 Prompt 寫好，需要更新時按一次 Generate 即可，這比另外維護一頁 Prompt 清單更接近真正的 Embedded AI，因為 Prompt、Context 與 Output 都留在工作發生的同一張頁面。
專案主頁建立明確的Context入口，不用把全部資料搬到同一頁
可以在 Project Page 固定一個 Project Context 區塊，把目前有效的 Brief、Decision Log、Deliverables、Meeting Notes 與主要 Database Views 放在一起，目的不是重新複製所有資料，而是明確標示這個 Project 現在應該參考哪些來源。這樣不只方便 AI，人自己也比較容易找到真正的 Source of Truth，而且 Enterprise Search 或 AI Block 都能直接從這一頁開始建立 Context。
舊資料先標狀態，不需要為了AI按多久沒打開就大量刪除
三個月沒開過，不代表資料已經失效。Decision Records、法律文件、研究資料與歷史專案平常可能很少打開，但真正需要時仍然有價值，因此按照「最近有沒有使用」大量刪除，並不是改善 AI Search 的通用方法。
比較安全的做法是建立 Current、Archived、Superseded 等狀態，舊版本明確標示由哪一份新文件取代，需要時再搬進 Archive，同時把 Page Title 寫得清楚，讓人和 AI 都能從名稱知道這份資料在處理什麼。對 Retrieval 來說，「這是哪一份文件、目前還有效嗎、哪一份才是正式版本」通常比單純把 Workspace 清到只剩很少頁更重要。
可嵌入式AI搜尋真正缺的，是一個可以保存Scope的自由Query入口
現在的 Notion 其實已經有三塊拼圖：Enterprise Search 可以搜尋 Workspace、Connected Apps 與 Web，也能把 Scope 縮到特定 Page 或 Teamspace；AI Block 可以直接住在 Page 裡，保存 Prompt、指定 Context，再按 Generate 更新；Notion Agent 則能在 Workspace Context 裡進一步建立與修改內容。
真正還沒出現在官方產品文件裡的，是把前兩者直接合在一起：一個可以嵌進 Project Page、Scope 已經預先設定好，但每個使用者仍能自由輸入不同問題、繼續追問的 Enterprise Search Block。這也是為什麼社群的要求雖然看起來只是在問「能不能多一個搜尋框」，實際上很合理，因為需求不是再增加一個模型，也不是再多放一個 Ask AI 按鈕，而是希望 Context 能和頁面一起保存，不必每一次提問前都重新指定現在正在處理哪一件事。
在官方真的推出這種元件以前，固定問題可以先交給 AI Block，臨時問題繼續用 Enterprise Search，工作區本身則先把 Current、Archived、Owner、Date 與 Source of Truth 標清楚。模型會不會永遠記得半年前聊過什麼，很難控制；但今天這個問題應該去哪幾份資料找答案，至少可以先把範圍設定好。
常見FAQ
目前沒有看到官方提供一個完整等同 Enterprise Search、可以直接嵌入 Page，並讓每位使用者在固定 Scope 裡自由輸入不同問題的搜尋元件。不過 Notion 已經有 AI Block，可以直接放在頁面裡，預先設定 Prompt、Context 與 Search Sources，再由使用者按 Generate 更新結果，因此「頁面裡完全沒有情境化 AI」並不準確，真正缺的是自由提問的互動式搜尋介面。
AI Block 比較適合固定問題，例如每次都整理專案風險、待確認決策或會議摘要，可以事先寫好 Prompt 與 Context，之後重新 Generate；Enterprise Search 則適合臨時提問，使用者每一次都可以輸入不同問題，再依需求調整 Scope。簡單來說，AI Block 比較像固定模板，Enterprise Search 比較像自由搜尋。
可以。Enterprise Search 現在已經可以加入特定 Page、Person 或 Teamspace 作為 Context，也能調整 Sources，把搜尋範圍縮到特定 Workspace 區域或 Connected App，所以「限定範圍」本身並不是目前缺少的功能，社群真正希望的是能把這套 Scope 固定在某一張 Page 上，不需要每次重新設定。
不一定。縮小 Scope 可以減少不相關文件進入 Retrieval 的機率，例如避免把三年前同名專案的資料一起抓進來，但如果真正需要的資訊存在公司政策、其他 Teamspace 或 Slack 裡，範圍縮得太小反而會漏掉證據。比較好的做法是讓 Scope 符合問題本身，而不是單純追求越小越好。
不一定。資料量大本身不是問題，真正容易造成混亂的是同一件事情存在很多版本，卻沒有標示哪一份仍然有效，也沒有清楚的 Owner、Date、Status 或 Source of Truth。大型 Knowledge Base 一樣可以很好搜尋，只要文件狀態與版本關係清楚，Retrieval 反而可以利用更完整的歷史資料。
不建議只依「多久沒打開」決定刪除。歷史決策、研究資料、合約或舊專案可能平常很少使用，但需要時仍然很重要。比較好的方式是將舊內容標成 Archived 或 Superseded，並清楚指出目前有效版本，讓人和 AI 都知道哪些資料只是歷史紀錄、哪些才是現在應該採用的內容。