裝潢報價單會寫清楚哪幾面牆要打掉、哪幾扇窗不動、誰申請許可。沒寫的那一面牆，通常就是後來吵架的那一面。GEO 專案也一樣：「想做 GEO」和「這次要觀測台灣繁中的五題服務選擇題、交出證據卡、不含頁面發布」，是兩份完全不同的合約。
這篇給你可以直接寫進範圍文件的東西：七個範圍層、一張交付與不包含的對照表、六種責任角色的邊界、五步處理範圍變動，以及一份填好的範例。
要落成 Day 0 基準，看 GEO baseline workflow；工具怎麼選，看 GEO 工具評估框架。
常見的開場是客戶只說「想讓品牌在 AI 裡更常出現」，沒有說市場、語言、題型、引擎，也沒有說誰負責修改網站。工具可以很快開起來，到了最後一天才發現大家回答的不是同一個問題。把目標、交付和排除項先寫下來，才知道這次專案何時算完成。
Otlex 示範帳戶的總覽畫面，示範範圍文件要核對的範圍與狀態。
先把專案問題寫成一句話
範圍討論的第一步，是把「想做 GEO」改成一個可查證的工作問題。例如：
- 想知道台灣繁體中文題目中，品牌在某一組服務選擇回答裡如何被描述。
- 想核對產品頁的公開事實是否能支持常見比較題。
- 想建立 Day 0 觀測、把證據交給內容團隊，再決定是否需要修改頁面。
- 想比較多個 AI 引擎的回答和引用，但先限定某個主題與市場。
這一句話會往下決定題目、資料、角色和交付。寫成「提高 AI 可見度」的話，範圍就還是空的：觀測、內容、工程和發布四種工作會被打包成一項服務，而它們的責任人、工時和授權全都不同。
Google 官方 AI features 文件指出，AI Mode 和 AI Overviews 建立在一般搜尋的索引和內容處理上，也可能使用查詢展開；頁面是否被索引或顯示不由專案單方面決定。範圍因此要把可控工作和外部搜尋結果分開列出。Google AI features 官方說明
GEO 專案範圍與驗收的七個範圍層
一、研究問題
先定義要查什麼現象，例如品牌描述、產品比較、服務選擇、引用來源或內容缺口。研究問題要連得到題目和判讀。判斷方法：這個問題能不能直接寫成一題 prompt？不能的話，它還是一個目標詞，不是研究問題。
二、市場與語言
列出地區、語言、文字系統、必要的裝置或上下文。台灣繁中和其他市場的題目分開放。題目語境、品牌資料和內容責任都可能不同；混成一組之後，報表上的每個數字都要附一段解釋才看得懂。
三、引擎與觀測條件
列出這次會觀測的 AI 引擎、帳號或公開條件、執行日期和保存方式。用我們的 Otlex 的話，產品支援 ChatGPT、Google AI Overview、Google AI Mode、Gemini、Grok、Perplexity、Claude 七個引擎；這次專案實際涵蓋哪幾個，還是要逐項寫進範圍。
四、題目與意圖
說明題目來源、題目數量的組成方式、意圖分類、版本和責任角色。同一組問題由多個團隊共用時，另外建立 prompt library 的審核和退役規則。一次性研究題目直接丟進長期追蹤集合，半年後那個集合裡會有一批沒人記得為什麼在跑的題目。
五、頁面與內容工作
列出可能被核對的頁面，例如公司介紹、產品頁、服務頁、比較頁或 FAQ。每個頁面寫責任角色、允許的修改類型、需要的品牌或產品核准。內容建議、編輯修改、工程實作和發布分成四格，它們常常由四個人做，卻很容易在範圍裡被寫成一句「更新頁面」。
六、資料與交付
說明會保存哪些回答、引用、日期、執行狀態、人工分類、任務和匯出檔。交付可以是 baseline 包、證據卡、缺口清單、內容規格或交接摘要。每一項寫出「誰用」和「怎麼算完成」；少了這兩欄的交付項目，最後都會變成一個沒有人打開的檔案。
七、責任與排除
寫出誰提供品牌事實、誰核准主張、誰改內容、誰改網站、誰負責正式發布，以及哪些事項不在本次範圍。被列進協作名單，和擁有發布或部署授權，是兩件事。名單上的名字不會自動帶著權限。
把交付和不包含事項列成表
一張範圍表可以讓業務、客戶、內容和工程角色用同一份文字討論：
| 範圍項目 | 本次要交付 | 需要誰提供或核准 | 明確不包含 |
|---|---|---|---|
| 觀測 | 指定市場、語言、題目和引擎的結果 | 題目責任角色、資料責任角色 | 所有市場與所有題目 |
| 證據 | 回答、引用、日期、狀態和限制 | 觀測執行者 | 搜尋系統內部資料 |
| 判讀 | 品牌事實與內容缺口的待辦 | 品牌、產品或內容角色 | 自動批准品牌主張 |
| 內容 | 內容規格、編輯建議或指定頁面修改 | 內容責任角色 | 未核准全站改寫 |
| 網站 | 已授權的技術檢查或工程任務 | 工程責任角色 | 自動部署、重導或 URL 變更 |
| 追蹤 | 約定條件下的後續觀測 | 觀測與分析角色 | 保證提及、引用或排名 |
「不包含」那一欄不是在縮小合作，它是在保護每個角色知道自己要做什麼。真的要增加範圍時，新增一列和責任。「順便處理」這四個字免費開始，最後由某一個沒被問過的人結帳。
Otlex 示範帳戶的行動清單，示範範圍變動時可回查的工作項目。
一份填好的專案範圍卡
下面是一份範例，數量只用來展示寫法，你的專案按實際情況填。
| 欄位 | 範圍 v1 |
|---|---|
| 決策問題 | 確認自家產品在繁中工具選擇題中的描述是否正確 |
| 市場／語言 | 台灣／繁體中文 |
| 題目 | DEMO-S01 至 S05，共 5 題；完整原文另存 v1 |
| 引擎與模式 | ChatGPT 搜尋、Google AI Mode；記錄可見模型，未提供時註明 |
| 目標頁 | 自家產品頁與 FAQ 各 1 頁；由品牌方填入完整 URL |
| 原始證據 | 每次回答、引用 URL、時間／時區、執行狀態與題目版本 |
| 預定交付 | 差異卡、2 頁修改建議、核准後文字草稿、變更清單 |
| 批准人 | 品牌方產品負責人核事實；網站負責人核發布 |
| 排除事項 | 未列入引擎、其他市場、網站改版、代為部署、付費曝光 |
| 結案材料 | 原始檔、建議與草稿版本、逐項確認結果、未解項目 |
中途要求新增 Perplexity 與一頁比較內容，v2 就新增引擎、頁面責任人與交付，並重新確認用量、工時和批准角色。v1 的兩引擎觀測保留原版本，新增引擎單獨建立基準，避免把比較集合變大的差異寫成品牌成長。
| 確認點 | 可交出的證據 | 範例狀態 |
|---|---|---|
| 交付 | 5 題原文、原始檔與 2 頁草稿 | 待執行 |
| 發布 | 已核准版本的公開頁面與上線時間 | 不在代部署範圍 |
| 索引 | 搜尋平台針對 URL 的索引資料 | 網站發布後另查 |
| 推薦／引用 | 同條件觀測結果、有效回答數及變更紀錄 | 待重新觀測 |
買方可將這張卡附在 GEO 廠商比較 的詢價文件；若採購的是傳統搜尋工作，改用 SEO 廠商指南 的技術、內容與分析責任欄位，避免把兩類工作合成一句「網站優化」。
依責任角色安排工作邊界
範圍文件可以用 RACI 類似的思路，但要以團隊真的使用的角色名稱為準：
- 資料或研究角色：定義觀測條件、保存材料、標記執行狀態。
- 品牌或產品角色：確認公司、產品、功能與服務事實。
- 內容角色：判斷頁面是否支持主張、提出修改建議、完成編輯。
- SEO 或網站角色：處理頁面結構、內部連結、可抓取性或其他已核准工作。
- 工程角色：處理網站程式、整合、權限、部署前檢查。
- 發布責任角色：批准正式公開變更並完成獨立發布流程。
一個人可以兼任多個角色，範圍文件仍然寫出兼任關係。它擋的是兩種誤會：客戶以為「服務方會完成所有修改」，以及內容角色被推去批准自己沒有權限核對的產品主張。
Day 0 baseline 可以當範圍的第一個交付，但要把起始觀測與後續內容改動分開。要交給內容團隊，用 GEO client handoff 的證據卡；要設計 dashboard 欄位，看 AI 搜尋監測 dashboard。
遇到範圍變動怎麼處理
範圍變動很常見，重點是保留變動前後的語境。可以按以下五步處理：
步驟一：指出變動來源
記清楚是新增市場、換語言、增加引擎、修改題目、加入頁面、增加角色，還是更改交付。「需求增加」這四個字，兩週後沒有人還原得出當初改了什麼。
步驟二：檢查受影響的資料
判斷變動會不會讓舊結果不能直接比較、讓題目需要重新審核，或讓原本的責任人不再適用。把受影響的基準和報表列出來。
步驟三：更新交付與排除
新增工作時，同時寫出新增的驗收條件、責任角色和不包含事項。若縮小範圍，也要保留被移出的項目和原因。
步驟四：重新確認授權
內容修改、工程變更、正式 URL、重導、部署或外部資料處理都可能需要不同的責任角色。範圍更新不會順便產生授權，這兩件事各自要有人簽名。
步驟五：告訴接收者哪些結果不可直接比較
交接文件或 dashboard 應標示條件改變的日期。新結果獨立呈現。默默接在舊趨勢後面的那一段，日後只有當初做的人看得懂。
要比較工具能力，用 GEO 工具評估框架；要先核對採購交付，用 AI 搜尋監測工具採購清單。這幾篇分別處理能力、採購和範圍，不互相替代。
常見問題
GEO 專案範圍與驗收應該先定市場還是先選工具？
先定研究問題和範圍，再選工具。市場、語言、題目、引擎和證據欄位決定了工具要展示什麼能力；順序反過來的話，範圍會被示範畫面和功能名稱帶著走，最後買到的是介面，不是答案。
範圍要不要列出所有七個 AI 引擎？
專案範圍可以按問題、語言、資料和資源選一部分。Otlex 支援七個引擎，那是產品範圍；這次實際涵蓋哪幾個要列出來，沒涵蓋的寫成排除或後續範圍。兩份清單長度不同是正常的。
GEO 專案範圍與驗收可以直接寫固定完成日期嗎？
已經有核准資源、依賴和工作量證據時，可以給計畫日期。題目審核、品牌事實、內容修改、工程和發布各有各的依賴；先寫完成條件、再回推日期，比先答應一個日期再想辦法可靠。
範圍文件要包含內容改寫全文嗎？
本次交付是研究和內容規格的話，範圍列出頁面、問題、證據和編輯輸出就夠。真的包含全文改寫，再把語氣、來源、核准與發布責任另列；一份範圍同時當研究報告和發布授權，等於讓寫報告的人替發布簽名。
範圍變動後要重新做所有觀測嗎？
看變動影響。如果市場、語言、引擎、題目或條件改變，原本結果可能要分組或另立基準；如果只是補充交付格式，可以保留原觀測並更新文件。由資料責任角色按受影響欄位判斷，並留下理由。
結語
範圍文件的目的，是把研究問題、觀測範圍、內容責任、工程邊界和交付條件寫成所有角色都能核對的文字。先定義可控的工作，再標示外部搜尋結果和不包含的事項，遇到變動時留下前後差異，團隊就能在不誇大承諾的前提下推進。範圍討論可以先看 GEO 服務頁 的公開工作範圍；要討論實際市場、頁面或角色範圍，到聯絡頁提供需求。