語意檢索與全文搜尋

一句話：這篇說明 semantic_search 跟 search_content 差在哪裡，以及什麼問題該用哪一個。

這解決什麼問題

MCP 找東西的方式不只一種，而它們回答的是不同的問題。

search_content 找你打過的字。你記得寫過「熔字爐」，它就把每一處都列出來，含路徑跟前後文。

semantic_search 找你想講的那件事。問「母親的怨氣是在哪一場浮出來的」，它會回那一場戲——就算「母親」跟「怨氣」這兩個詞在那一段裡一個都沒出現。

寫長篇的人真正想問的問題，大多是後面那一種。你記得有那麼一段，但記不得當時用了哪個詞。

該用哪一個

你想做的事	用
「臨澤港」這三個字出現在哪些檔案	search_content
換掉一個角色的名字之前，先找出所有提到他的地方	search_content
哪一場戲讓兩人的關係開始變質	semantic_search
這本書有沒有哪裡已經解釋過海禁的來由	semantic_search
我改稿之前用的那個比喻，大概是說潮水沖走字	semantic_search
團隊知識庫裡有沒有寫過這種情況怎麼處理	semantic_search

search_content：字面比對

search_content({
  "book_token": "bk_...",
  "query": "熔字爐",
  "file_types": ["md"],
  "limit": 20
})

不分大小寫，回的是命中檔案的路徑加上前後幾句。

在 4.0 的書上，file_types 這個參數比你想的重要。 結構化檔案（.beats、.timeline、.script、.map、.geomap）也會被搜——搜的是它們的原始 JSON。所以查一個像 name 或 title 這種普通詞，命中的可能全是欄位名，不是內容。要只搜散文就明講 file_types: ["md"]。

舊的劇本工作室書反過來：那邊的結構化檔案預設被排除，要一起搜得加 include_structured: true。詳見哪些工具在特定檔案上會不一樣。

semantic_search：按意思找

semantic_search({
  "book_token": "bk_...",
  "query": "沈硯第一次懷疑父親的地方",
  "limit": 10
})

三個參數：書、一句自然語言的問題、要幾筆（預設 10，上限 50）。

回來的每一筆有四樣東西：段落的 §編號、檔案的 token、那一段的文字，以及相似度。§編號是可以引用的定位——AI 可以回你「這件事在第三章 §4」，而不是含糊地說「大概在中間某處」。

索引是怎麼來的

第一次搜尋時，Slima 會把這本書最新一顆 commit 的內容切成段落建索引；之後只補算變動過的部分，沒改的檔案不會重算。所以第一次搜一本大書會比後面幾次慢。

很大又從來沒建過索引的書會轉去背景建。 這時候這一次搜尋會回空的，不是「找不到」而是「還沒建好」。等一下再搜一次就有了。

要花一點點費用

把你的問題轉成向量要算一次，所以 semantic_search 會用掉一點點點數。字面搜尋不會。這個差別小，但它是這兩者唯一的成本差異，值得知道。

三件它做不到的事

• 找精確字串：要找一個確切的詞或標點，用 search_content。
• 找還沒進 commit 的字：索引是從 commit 建的。作者剛在 app 裡打完、還沒落到一顆 commit 的段落，這裡搜不到。
• 讀團隊裡設為機密的技能檔：那些檔案從來不進索引，所以語意檢索不會成為讀到它們的側門。

團隊知識庫特別有用

一本團隊知識庫可能有幾十份規範、決議與前作設定。在那上面，字面搜尋跟語意檢索的差別是「翻」跟「問」的差別：你不必先知道那件事被寫在哪一份檔案、用了什麼標題，直接問「這個世界的貨幣單位我們定過嗎」就好。

相關

• Docs：檔案操作工具
• Docs：筆記與評論工具
• Docs：哪些工具在特定檔案上會不一樣
• Docs：搜尋與取代