要用 AI 建立網站資訊架構，應從人們實際要完成甚麼的證據出發，而非給模型一句空白的網站地圖提示。先凍結內容清單及用戶任務登記表，再讓 AI 提議分組、層級、標籤及備選路徑。把每個提議都當作假設：是否採用，由卡片分類、樹狀測試、任務走查、無障礙審查及負責人共同決定。

通用 AI 工作流程說明如何約束證據並核實輸出。本文將其用於資訊架構（IA），即協助人們找到並理解網站內容的組織、命名及路徑。它不容許 AI 編造用戶需要，也不容許宣稱未經測試的導覽已經成功。

關鍵要點

從研究、搜尋紀錄、客戶支援問題及觀察到的行為中歸納任務。

把任務、內容、頁面、功能、標籤及導覽元件區分開來。

讓 AI 提出多個候選結構，並為每個選擇引用證據。

保留互相衝突的心智模型，而不是把它們平均掉。

以具代表性的參與者及真實任務測試可尋性。

為獲批的 IA 定版本，並保留未解決的證據及例外。

如何用 AI 建立網站資訊架構並以真實任務為本？

有用的項目產出的是決策軌跡，而不只是一張圖。核心產物包括：凍結的內容清單、證據登記表、標準化的任務陳述、候選結構、標籤詞彙表、測試方案及結果、例外紀錄，以及獲批版本的層級結構。

以下概念要分開：

概念	例子	為何重要
用戶任務	更換已過期的付款方式	以用戶的語言描述結果
內容	資格規則及操作說明	完成任務所需的資訊
頁面	帳單設定說明頁	一種可能的承載容器
功能	更新信用卡表格	互動能力，而不是類別
標籤	付款及帳單	必須讓人看得懂的路標
導覽路徑	帳戶 → 付款 → 更新信用卡	一條路線，不能證明任務容易完成

組織架構圖不自動等於 IA；資料庫 schema、產品團隊職責圖或現有網址清單也不是。這些輸入可解釋限制，但結構應支持用戶理解的語言及關係。

以研究證據奠定架構基礎

第 1 步：凍結目標、範圍及內容清單

寫一份項目表頭，記錄網站或欄目、受眾、支援的 locale、業務及用戶目標、研究期間、分析數據期間、內容快照日期、已知技術限制、審批人及排除範圍。註明這項工作屬於診斷、局部改版、遷移還是全新結構。

盤點範圍內每個網址或內容物件，包括標題、用途、負責人、格式、受眾、locale、生命週期狀態、入站連結、經批准的流量或搜尋證據，以及重複或質素備註。探索階段不要刪除看似無人使用的內容，把它標記出來，留待另行管治決定。

在讓 AI 重新組織之前凍結清單。否則新頁面、重新導向或編輯改動會令候選結構無從比較。清單不完整時標出缺口，不要讓模型按一般網站慣例填補。

第 2 步：建立真實用戶任務的證據登記表

GOV.UK 建議團隊先了解用戶需要，而不是假設。［1］把每項研究觀察轉成可追溯的任務紀錄，同時在標準化措辭旁保留原始證據。

有用的證據可包括：有主持的訪談、情境調查、可用性測試、站內搜尋字詞、支援個案、來電原因、意見回饋、失敗的旅程、無障礙研究及觀察到的變通做法。用戶訪談整合流程可協助整理筆記，但只有獲批的研究才可進入登記表。

每項任務記錄：

穩定的任務 ID 及中立的陳述；
受眾及所處情境；
預期結果及證據來源；
按既定尺度量度的頻率、重要性或嚴重程度；
相關的前置任務及後續任務；
locale 或地區差異；
不確定之處、矛盾及研究缺口；以及
研究負責人及審批狀態。

沒有證據時，不要把「推廣高級服務」這類持份者要求變成用戶需要；不要把缺乏上下文的搜尋字詞當作完整任務；也不要讓 AI 編造人物誌、頻率、動機或痛點。

第 3 步：畫樹之前先梳理完整問題

用戶往往在一個更大問題的中途進入網站，之後又轉到別處。GOV.UK 關於梳理用戶完整問題的指引，鼓勵團隊了解用戶在與服務互動之前、期間及之後的各個步驟。［3］記錄依賴及相鄰任務，但不要聲稱網站負責所有環節。

客戶旅程地圖可展示次序及交接，而 IA 描述的是分組及可尋性。不要把旅程階段直接轉成導覽的頂層。「發現、決定、購買、使用」或許是有用的分析框架，對想補領遺失信用卡的人卻是糟糕的標籤。

亦要把任務陳述與實作需求分開。用戶故事及驗收準則描述產品行為，並不自動決定頁面邊界或選單層級。

第 4 步：讓 AI 提出多個候選分組，而不是一個答案

提供凍結的任務登記表、獲批的清單欄位、限制及輸出 schema。從研究摘錄中刪去個人資料，並在提示中使用任務 ID。一條有邊界的指示可以是：

只使用所提供的任務及內容紀錄，提出三種替代分組。
每個分組及標籤都引用支持的任務 ID。保留互相衝突的
模式，把缺乏支持的放置標為未解決。不要新增用戶、
需要、頁面、功能、研究發現或成功結論。回傳層級、
交叉連結、備選標籤及需要研究人員解答的問題。

候選方案之間要有實質差異，例如任務導向、物件導向及生命週期導向。要求模型解釋取捨，並指出需要多個入口的項目。拒絕虛構的證據、沒有引用的放置、重複的 ID、遺漏的清單項目，以及超出議定深度的層級。

NIST 的生成式 AI 概況強調全生命週期的風險管理及評估。［4］在這裏即是記錄輸入及模型設定、驗證輸出 schema、以真人測試提議，並在推出後監察獲批結構。

如何測試、審批並維護結構？

第 5 步：與領域負責人審查層級及標籤

在用戶測試之前審查候選結構。除非研究顯示用戶明白並會尋找內部部門名稱，否則刪去。檢查同級項目概念上是否並列、標籤有否重疊、有沒有類別淪為「雜物抽屜」。

GOV.UK 的服務範圍指引，是圍繞用戶想達成的目標、而非現有組織邊界來規劃服務。［2］應用這項原則時，別假裝每個網站都是政府服務：以用戶的說法界定任務及其邊界，再另行記錄組織限制。

為每個擬議標籤維護一份小型詞彙表，包含定義、納入及排除的內容、測試過的備選說法、各 locale 的措辭及負責人。標籤橫跨多種語言時，本地化術語表流程很有用。直譯可能合併本應區分的概念或製造新的含糊，因此須按 locale 分別批准標籤。

第 6 步：進行卡片分類並保留分歧

卡片分類有助研究參與者如何為具代表性的項目分組，以及如何為這些組別命名。開放式分類用於發現模式，封閉式分類用於評估既定類別，兩類問題都重要時可採用混合式。卡片取自真實任務及內容，避免會洩露預期答案的內部術語。

記錄招募準則、參與者背景、任務材料、主持規則、完成數據、組別標籤、項目移動、評語及無障礙配套安排。移除身份識別後 AI 可總結模式，但研究人員應檢查原始結果及離群值。

不要把所有參與者壓縮成一個「平均用戶」。新客戶與資深管理員可能有不同的心智模型。有爭議的卡片可能代表有多條合理路徑、標籤含糊、任務屬複合性質，或招募對象有差異。把這些假設留待下一輪測試。

第 7 步：用真實任務做樹狀測試

樹狀測試去掉頁面設計，只問參與者在純文字層級中會往哪裏找。撰寫描述目標、但不重複目標標籤的情境。進行研究之前，先界定正確目的地及可接受的備選路徑。

量度完成率、直接程度、首次選擇、回頭次數，有需要時計算用時，並收集質性解釋。按任務及相關受眾拆分結果，而不是依賴單一整體分數。高平均值可能掩蓋一個幾乎人人都找不到的關鍵任務。

當搜尋器、深層連結、帳戶主頁或說明連結是常見入口時，要測試多個入口點。主選單只是其中一條存取途徑。不要因參與者反覆猜測後終於找到答案，就宣稱層級有效。

第 8 步：走查內容、無障礙及邊界情況

以真實內容檢查擬議的樹實作後是否站得住腳。為每項優先任務，由可能的入口走到結果，檢查頁面用途、標題層級、連結文字、麵包屑、搜尋字詞、重新導向及下一步操作。

審查鍵盤及螢幕閱讀器導覽，但不要把無障礙簡化為一個選單元件。清晰的標籤、可預期的結構、描述性標題、多條路徑及持續維護的頁面關係，都有助辨明方向。研究中要納入有相關無障礙需要的人。

進行結構檢查，找出孤立頁面、循環路徑、同名但意思不同的標籤、只有一個而未加解釋的子項的類別、放在多個上層卻沒有標準歸屬的頁面，以及不再服務任何獲批任務的內容。把這些問題交給人處理，不要讓 AI 暗中「修正」網址或重新導向。

第 9 步：審批架構並定版本

決策紀錄應包括內容清單快照、任務登記表版本、候選結構、研究計劃、參與者準則、結果、選定的層級、標籤詞彙表、交叉連結、被否決的備選方案、未解決的風險、內容負責人的決定及生效日期。

研究團隊負責詮釋用戶證據；內容設計負責標籤及頁面用途；產品及服務負責人批准範圍及取捨；工程團隊確認技術可行性；無障礙專家及參與者驗證相關障礙。模型不能取代這些職責。

推出後，監察站內搜尋的改寫、零結果搜尋、支援查詢、任務完成證據、常見的回頭、失效連結、孤立內容及特定 locale 的問題。內容、受眾、產品或導覽有實質變化時應重新測試，而不只是叫 AI 再產生一張網站地圖。

常見錯誤有哪些？

由「產生網站地圖」開始，而沒有任務證據： 先建立一套可追溯的任務和內容證據。
按部門組織網站： 按用戶的理解分組，職責誰屬另行記錄。
把旅程階段直接轉成導覽： 以旅程表達次序，以 IA 表達分組。
只接受一個 AI 結構： 比較多個替代方案，保留互相衝突的心智模型。
不配合任務情境測試標籤： 使用真實情境及預先界定的目的地。
只優化主選單： 把搜尋、深層連結、交叉連結及情境入口都納入考慮。
把最終找到當作通過： 檢查直接程度、首次選擇、回頭次數及參與者的解釋。

總結

凍結目標、證據期間及完整的內容清單。
從獲批的研究及觀察到的行為中歸納任務陳述。
讓 AI 提出附引用的候選結構、備選方案及未解決的問題。
審查層級及標籤，不把組織架構圖照搬進來。
透過卡片分類、樹狀測試、任務走查及無障礙研究作驗證。
批准並監察有版本的 IA，由人承擔問責。

常見問題

AI 可從現有網址直接建立網站地圖嗎？

它可以提議重組，但網址反映的是現有實作，不一定反映用戶需要。應把凍結的清單與真實任務證據結合，要求引用，並測試得出的結構。

網站層級應有幾層？

沒有通用數字。使用能表達有意義關係、並支持經測試路徑的最淺結構。比起深度，易明的標籤、合理的分組及順利完成任務更重要。

主導覽應依照客戶旅程嗎？

不一定。旅程描述的是次序，而導覽類別協助人們從不同起點找到所需。應測試生命週期式標籤是否符合你的受眾實際尋找資訊的方式。

搜尋可代替資訊架構嗎？

不可以。搜尋依賴內容結構、標題、元數據、詞彙及得到維護的目的地頁面。人們也會瀏覽、經深層連結進入，到達頁面後亦需辨明方向。

卡片分類參與者意見不一怎麼辦？

保留分歧。它可能揭示不同的受眾、多條合理路徑、含糊的卡片或重疊的概念。以後續研究及樹狀測試處理，不要強行製造共識。

AI 可按持份者想法撰寫用戶任務嗎？

AI 可協助改寫有紀錄的假設，但不得把它變成研究證據。清楚標示哪些是假設，並在它們影響架構之前，以具代表性的用戶加以驗證。

如何驗證本地化導覽標籤？

維護獲批的概念及各 locale 的術語，再請以該語言為母語的人在情境中測試標籤。不要依賴直譯，也不要假設一個 locale 的類別邊界可原封不動移植。

何時再次覆核 IA？

在受眾、服務、內容、locale 或平台出現實質變化後，以及證據顯示有可尋性問題時覆核。在正式研究輪次之間持續進行輕量監察。

**免責聲明：**本文提供一般資訊，不能取代用戶研究、無障礙評估、法律審查，或專業的內容及產品判斷。

來源

GOV.UK Service Manual, Start by learning user needs: https://www.gov.uk/service-manual/user-research/start-by-learning-user-needs
GOV.UK Service Manual, Scoping your service: https://www.gov.uk/service-manual/design/scoping-your-service
GOV.UK Service Manual, Map a user's whole problem: https://www.gov.uk/service-manual/design/map-a-users-whole-problem
National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1): https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 6 日。

如何用 AI 建立網站資訊架構（IA）：由任務到測試