AO2 FIELD GUIDE · N016 · GEO／AEO 與 AI 搜尋
服務範圍說明先交代交付、輸入資料與適用前提，再列需評估及排除項目。附服務條件表與詢問分流表，讓網站與 AI 回答保留能力邊界。
「提供完整解決方案」很難幫助採購判斷適不適合。有效的服務頁應讓讀者知道企業負責哪一段、需要客戶準備什麼、哪些條件仍需確認，以及無法承諾哪些結果；這也是降低 AI 轉述誤解的資料基礎。
服務範圍說明：從可驗收交付開始
先把服務名稱改寫成客戶能核對的交付。例如「建置企業知識庫」還不夠具體，需說明是否包含來源盤點、資料整理、權限規劃、內容發布或系統串接。不同合作案可以有不同組合，但公開頁面應列出基本範圍和需另行評估的部分，避免讀者將所有可能工作都理解為標準包含。
每項交付至少對應輸入資料、執行角色與驗收方式。若需要客戶提供核准規格，網站就應說明資料不足時如何處理；若需要第三方平台權限，也要交代由誰提供及誰維護。這些條件放在同一段工作說明附近，比把所有限制塞到頁尾更能幫助讀者判斷。
| 欄位 | 應寫清楚 | 驗收問題 |
|---|---|---|
| 交付 | 文件、系統或具體工作 | 客戶拿到什麼 |
| 前提 | 資料、權限與協作窗口 | 開始前缺什麼 |
| 包含 | 標準工作與責任 | 誰執行到哪一步 |
| 需評估 | 環境與依賴條件 | 如何確認可行 |
| 排除 | 未承接工作及替代窗口 | 客戶是否可能誤解 |
把「可以做」拆成已有能力與尚需確認
有工具經驗、做過相似任務與已確認能完成本案，是不同程度的資訊。服務頁可以說明現有方法與合作流程，但應避免用相似產業經驗推導所有系統皆可整合。涉及既有資料品質、介面限制或客戶現場環境的項目，列出評估所需資料，讓未知有可執行的確認步驟。
假想 IoT 路燈專案：企業負責控制器資料接入與網站展示，現場佈線、電力施工及既有平台授權由其他角色處理。公開頁應畫清這些接口，說明需要哪些協作窗口。若把整個生態系統都寫成自身交付，後續詢問會帶入錯誤期待，AI 摘要也可能放大這種模糊性。
條件要能觸發分流，而非只寫「視情況而定」
對每個需評估項目，補上影響判斷的條件和下一步。例如舊資料只有掃描 PDF，先安排抽樣檢查；需要跨系統回寫，先確認接口與測試環境；規格版本衝突，先找產品責任人裁決。頁面不必公開所有技術細節，但應讓客戶知道為何需要補資料，以及補到什麼程度能繼續。
| 詢問條件 | 先收集資料 | 下一步 |
|---|---|---|
| 規格未核准 | 版本、負責人與待確認欄位 | 先完成資料確認 |
| 需要舊系統整合 | 平台、接口及測試條件 | 安排技術評估 |
| 涉及專業主張 | 適用市場、文件與審核角色 | 由合適角色確認 |
| 要求固定商業結果 | 目標、現況與可控制工作 | 重訂交付與觀察範圍 |
生技製藥合作情境尤其需要區分內容整理、專業審核與正式核准。可以描述由適當角色確認資料的流程，不能因合作夥伴的產業背景，就將企業包裝成擁有未經證實的資格。涉及產品用途或專業結論時，保留核准角色與來源，不讓行銷文字代替正式判斷。
使用限制應貼近主張與證據
若服務成果取決於客戶配合、系統條件或第三方審核，就在介紹該成果時說清楚。避免前面保證特定成效，後面才以小字撤回。可以承諾明確工作、文件與驗收步驟；搜尋排名、AI 引用或每個案子的商業效果，則應依實際可控制範圍表達，不以理想情境作普遍保證。
Google 的 實用內容指引重視內容能否幫助既定讀者完成目標。本文將其轉為服務條件與分流工作表，是 AO2 的編輯方法，不是平台保證會引用某種寫法。清楚表達能改善資訊理解，但不能控制外部 AI 每次如何摘要。
用業務與 AI 常見問法驗收範圍
準備一組會踩到邊界的問題，例如「資料很亂也包含整理嗎」「有舊系統就一定接得上嗎」「是否包含持續維護」。請未參與撰稿的人只讀頁面回答，再指出依據。若答案仍只能說「應該可以」，表示前提與責任不夠清楚，需補說明或改成明確的評估入口。
同一份核准範圍應連到業務簡報、FAQ、表單與 AI 知識。改版時標記生效日期，查找舊版簡報與過時回答。驗收要檢查實際輸出是否保留排除條件，不能只確認檔案已更新。對尚未確認的詢問，讓系統回覆需要補哪些資料，比產生一個完整但越界的答案更有用。
常見問題
列出限制會不會讓客戶卻步？
清楚的限制應幫助客戶判定適配性，而不是堆一串拒絕。可將範圍分成可直接提供、需取得資料後評估，以及不在服務內，並為需評估項列出必要文件與下一步。例如資料串接需先確認接口與權限，才能估算；若不支援，說明可採的人工交接方式。回查實際詢問是否更容易補齊資料，而非只以表單數量衡量這段說明的價值。
所有服務都要列固定價格嗎？
不需要，但不能只寫「歡迎洽詢」而沒有估算依據。對可標準化交付可說明包含項目與排除項；客製服務則列出影響範圍的變數，例如產品線、來源整理、語言、審查輪次與串接需求。提供需求準備清單，說明估算前需看哪些資料。若使用示意方案，清楚標示並非正式報價，避免讓讀者將一個不適用的數字當成合作承諾。
清楚寫好就能避免 AI 說錯嗎？
不能保證，但能改善可回查的公開依據。先讓服務頁、FAQ、公司介紹及合作條件使用一致說法，將容易誤解的能力寫出適用範圍。發現 AI 說錯時，保存平台、日期、提問與完整答案，核對是否引用過期頁面，再修正來源並按平台提供的方式回饋。後續以相同條件觀察，分開記錄內容已修正與外部回答是否改變，不能把兩者當成同一件事。
白話總結：把服務寫成一份看得懂的工作範圍
裝修報價只寫「全套處理」，雙方很容易想像不同內容。服務頁也要說明包含什麼、哪些需看現況，以及哪些由其他人負責。
- 先列實際交付：把服務名稱拆成工作、文件與驗收結果。
- 再把邊界說明白：區分可直接提供、補資料後評估與不包含項目，列出必要條件。
- 最後用常見追問測試：請不熟悉服務的人判斷能不能做、缺什麼，以及應找誰確認。
完成時，客戶能帶著正確資料來討論，業務也不需要靠口頭補上一長串但書。
來源與方法範圍
查核日期：2026 年 10 月 22 日。官方資料僅支持文中對應的平台或方法說明；工作表、決策步驟與核對方式為 AO2 編輯整理。產業情境依文中標示作假想示例，不作客戶實績、產品資格或效果背書。
