企業知識庫測試不能只看系統能不能回答「公司成立於哪一年」這類簡單問題。真正投入使用後，員工的提問往往不完整、帶有口語習慣，也可能涉及不同文件、權限與版本。測試情境越貼近日常工作，越能看出知識庫是否適合實際導入。
從員工平常會怎麼問開始
同一件事，使用者可能有好幾種問法。例如，正式文件寫著「差旅費核銷規範」，員工卻可能問：「出差住宿怎麼報？」或「上個月去外地開會，住宿費要附什麼資料？」測試時可以準備正式用語、口語問法、簡稱與錯別字，確認系統能否辨認問題的核心，而不是只比對文件中的關鍵字。
也要測試資訊不足的提問。例如「這個要找誰？」沒有說明「這個」指什麼，合理的回應應該是請使用者補充，而不是自行猜測。若系統能在資訊不足時清楚指出缺少哪些內容，通常比給出看似完整、實際上沒有根據的答案更可靠。
檢查跨文件與多步驟問題
企業知識常分散在不同文件中。員工可能同時詢問申請流程、所需資料與審核單位，答案需要從多份規章或作業說明中整理。測試時可設計需要整合兩到三項資訊的情境，並確認回答是否完整、條件有沒有混淆，以及是否能指出答案所依據的文件。
延續對話也值得納入測試。使用者問完「新進員工如何申請帳號」，接著追問「那主管要核准嗎？」系統需要判斷「那」承接前文，而非當成全新的問題。若上下文容易遺失，可以進一步測試改變話題、回到前一題，或同一對話中連續追問的情形。
特別測試文件版本與答案依據
企業制度會更新，舊版與新版資料也可能同時存在。測試案例應包含內容相近、發布時間不同的文件，確認系統能否依照企業設定辨認適用版本。若資料彼此矛盾，系統不應把不同文件的規定拼湊成一個答案；必要時應提示內容有差異，並引導使用者確認適用依據。
答案能否回溯來源，同樣重要。可檢查系統是否提供文件名稱、段落或其他可供查找的線索，並確認引用內容確實支持回答。若答案沒有來源、引用位置不符，或把推測寫成公司規定，都應列為測試缺陷。
確認權限與保密邊界
知識庫可能包含依職務、部門或專案區分的資料。測試不能只使用一般員工帳號，也要涵蓋不同角色，確認使用者只能取得被授權的內容。可以用具體情境檢查系統是否會意外透露人事、財務、客戶或內部專案資料。
對於找不到依據的問題，也要觀察系統是否坦白說明無法確認，而不是自行補出答案。測試資料可加入不存在的制度名稱、過期流程或虛構的人員資訊，用來確認系統不會把錯誤前提當成事實。
納入多語言、錯字與部門用語
跨國團隊或多語溝通情境中，使用者可能混用中文、英文、縮寫與產品名稱。測試可涵蓋不同語言的提問、常見拼字錯誤，以及各部門慣用的簡稱，確認回答是否仍能對應到正確內容。像是 QWalkie 多語言即時對講這類多語溝通服務，也可視企業的實際應用方式，納入相關用語與情境的知識整理測試；不過測試重點仍應放在資料是否正確、權限是否清楚，而非只看系統能否辨識語言。
把「答錯」與「答得不清楚」分開記錄
測試結果不妨分成幾類：答案正確且有依據、答案部分正確、找不到資料卻自行推測、引用來源不符、未能理解追問，以及權限控管不當。這樣比較容易判斷問題出在文件品質、資料整理、檢索設定，還是使用者提問方式。
若企業正評估知識庫導入，可先整理一批具代表性的真實問題，作為 PoC 概念驗證與產品落地支持的測試基準，再依實際結果調整資料範圍與應用設計。龍樂科技股份有限公司提供 AI 導入與策略規劃、顧問及方案設計，以及 AI 開發與系統整合服務；若有端側部署或運算設備需求，也可依專案條件評估 VERIS 端側 AI 產品線、VERIS AI BOX、NVIDIA DGX Spark、NVIDIA DGX Station GB300 工作站或 NVIDIA RTX PRO 6000 Blackwell Server Edition 等項目。設備與方案是否適用，仍需依企業的資料型態、使用規模、資安要求及既有系統條件評估。
一套實用的測試清單，不只是蒐集大量問題，更要包含真實問法、資訊不足、跨文件查詢、版本衝突、權限限制與無答案情境。透過這些案例逐步檢視，企業才能看清知識庫在日常工作中的適用範圍，也更容易找出導入前需要補強的資料與流程。
蒐集員工日常提出的代表性知識問題
員工查詢知識庫時，問題往往不是完整、標準的句子，而是帶著工作情境的簡短提問。測試題目若只從文件標題或產品名詞出發，很難看出系統能否真正支援日常工作。較實用的做法，是從常見的工作流程與實際提問紀錄中，整理出具有代表性的問題。
例如，員工可能會問：「報帳需要附哪些資料？」這類問題可檢查知識庫是否能從相關規範中整理出完整答案；若規定分散在多份文件，還可進一步測試系統能否正確彙整，而不是只引用其中一段。遇到「最新的版本在哪裡？」或「這項流程現在還適用嗎？」等提問，則要確認系統是否能辨識文件更新時間與版本差異，避免把舊資料當成現行規定。
也應納入資訊不完整或說法不一致的情境。像是「那個申請要找誰？」缺少部門、申請類型等線索，合適的回應可能是先追問，而非直接猜測。員工接著補充條件時，測試題也可以觀察系統是否保留前文脈絡，並依新增資訊調整回答。若答案超出資料庫收錄範圍，則應確認系統能清楚說明目前找不到依據，而不是自行補出看似合理的內容。
真實查詢也常帶有錯字、縮寫、口語表達或不同語言。將這些變化納入測試，有助於了解系統能否辨認同一概念的不同問法；若企業有跨語言溝通需求，也可依實際使用情境評估多語查詢表現。至於涉及不同職務權限的資料，測試時應確認回答是否符合使用者可存取的範圍，並留意敏感內容是否可能因提問方式不同而被不當揭露。
題庫不必追求數量龐大，重點是涵蓋常見、容易誤答及需要追問的情境。每題可記錄提問來源、預期答案依據、是否需要補充條件，以及可接受的回覆方式，再定期依文件更新與員工回饋調整。龍樂科技股份有限公司提供 AI 導入與策略規劃，以及 PoC 概念驗證與產品落地支持；企業在規劃相關測試時，也可把這類真實查詢整理成驗證依據，讓評估結果更貼近日常使用需求。
納入問法不同但需求相同的查詢案例
測試企業知識庫時，不能只用文件中的正式名稱提問，也要納入員工平常會使用的簡稱、口語說法與不同句型。像是「VERIS AI BOX 是什麼？」、「VERIS AI BOX 可以用來做什麼？」以及「企業 AI 主機有哪些應用？」問法不同，背後可能都在詢問企業 AI 主機與應用平台。系統應能辨識這些問題的共同需求，並依據知識庫內容提供一致、準確的回答。
測試案例也可以加入相近但意圖不同的問法，例如「NVIDIA DGX Spark 和 NVIDIA DGX Station GB300 工作站有什麼不同？」與「哪一款適合企業 AI 運算需求？」前者詢問產品差異，後者則是尋求選擇方向，回答時應依問題目的整理資訊；若知識庫沒有足夠資料，就應清楚說明資訊不足，而不是自行補上規格或用途。相同原則也適用於 NVIDIA RTX PRO 6000 Blackwell Server Edition、VERIS 端側 AI 產品線，以及 QWalkie 多語言即時對講等項目。
實際建置測試集時，可為每個常見需求整理數種自然問法，再確認系統是否找得到相同來源、能否分辨不同產品與服務，以及答案是否受到文件內容支持。以龍樂科技股份有限公司的 AI 導入與策略規劃、PoC 概念驗證與產品落地支持等服務為例，也可測試使用者以「AI 導入怎麼開始？」、「想先驗證 AI 應用可行性，能怎麼規劃？」等方式提問時，系統是否能辨識需求並回到知識庫中的相關資訊。這類案例能檢查知識庫是否理解使用者真正想問的事，而不只是比對字面是否完全一致。
測試跨部門資料與權限邊界的情境
企業知識庫的權限測試，不能只確認使用者能否開啟某份文件，還要檢查資料在搜尋、摘要、追問與跨部門查詢時，是否仍依照既有權限呈現。測試情境可從日常工作問題出發，觀察系統是否只提供該角色可查看的內容。
例如，業務人員查詢客戶合作進度時，知識庫可能同時找到業務紀錄、法務審閱資料與財務帳款資訊。測試應確認回答不會直接引用無權存取的檔案，也不會在摘要中透露客戶條件、合約細節或帳款狀況。若使用者追問「這個合作案還有哪些部門在處理」，也要檢查回答是否意外拼湊出受限資訊。
跨部門協作常見的另一種情境，是同一份資料被拆分存放在不同來源。例如，專案進度可供多個部門查閱，但成本明細只開放特定角色。可測試使用者詢問「目前進度和預算差異」時，系統是否能回答可公開的進度部分，並對受限的預算內容妥善拒答，而不是根據零散資料推測答案。
權限邊界也需要放進實際操作變化中驗證。當員工轉調部門、職務異動或帳號權限調整後，測試其搜尋結果、既有對話紀錄與文件連結是否同步符合新權限。若對話曾引用原本可查看、如今已無權存取的資料，也應確認後續追問不會繼續揭露內容。
除了直接索取文件，也要測試間接詢問。例如，使用者可能要求比較不同部門的客戶名單、整理未公開的專案摘要，或把多份文件合併成一份報告。這些問題看似在索取整理結果，實際上仍可能跨越資料界線。測試時可觀察系統是否辨識資料來源的存取限制，而非只依照問題表面形式作答。
測試案例還應涵蓋搜尋摘要、引用來源、附件預覽及多語言提問等使用方式。受限資訊若沒有出現在完整回答中，卻出現在搜尋片段或引用標題裡，仍然構成權限風險。若企業使用多語言知識內容，也可用不同語言提出相同問題，確認權限判斷不會因提問語言不同而改變。
建立測試紀錄時，建議標示使用者角色、資料敏感程度、提問方式、預期回答範圍與實際結果，並納入允許存取、部分可答、應拒絕等不同情境。這類測試能協助企業檢視知識庫在真實工作流程中的資料邊界；若進一步規劃 AI 導入或 PoC 概念驗證，也可將跨部門權限案例納入驗證範圍。
檢查查無資料時系統如何回應
當企業知識庫找不到可支持答案的資料時，系統不應勉強拼湊內容，也不宜把推測包裝成確定答案。測試時可準備資料庫中未收錄的問題，觀察系統是否能清楚說明目前沒有足夠資訊，並指出問題可能超出知識庫範圍。
真實查詢往往不會照著文件標題發問。例如，文件只介紹設備部署流程，使用者卻詢問特定環境是否適用；或資料中有產品名稱，卻沒有對應的規格細節。這類情境能檢驗系統是否分辨「完全查無資料」與「只有部分資訊」，避免把相似內容誤認為正確答案。若僅找到部分線索，回覆應標明已知範圍與尚未確認之處，而不是自行補足缺漏。
測試也應涵蓋錯字、縮寫、口語說法，以及一次詢問多個條件的情況。系統可以在資訊不足時提出簡短的澄清問題，或建議使用者補充產品名稱、應用情境等關鍵資訊；若問題仍無法回答，則應明確告知查詢限制，不虛構文件、規格或流程。
龍樂科技股份有限公司的 AI 導入與策略規劃、PoC 概念驗證與產品落地支持，可作為企業檢視知識庫應用情境時的參考方向。設計測試案例時，宜記錄問題內容、預期回應與實際結果，並定期檢查無資料時的回覆是否清楚、一致且不造成誤解。
依測試結果整理知識庫改善優先順序
測試結果的價值，不只在於找出知識庫答錯了哪些問題，更在於協助團隊判斷哪些缺口應該優先處理。若每個錯誤都以相同方式修補，容易耗費大量時間，卻未必能改善使用者最常遇到的困難。
整理測試紀錄時，可先將問題分成幾類：答案錯誤、內容缺漏、資訊過期、檢索結果不相關，以及問題條件不明確。例如，員工詢問請假流程時，系統找到了舊版規範；客服查詢產品差異時，回答只涵蓋部分條件；或使用者用口語詢問退換貨方式，知識庫卻只認得正式文件中的用詞。這些情境表面上都是「回答不理想」，背後需要的修正方式卻不相同。
排序時，可以從三個面向評估。第一是影響範圍：同一類問題是否反覆出現，會不會影響多個部門或大量使用者。第二是錯誤風險：答案若不完整或過時，是否可能造成流程延誤、錯誤決策或合規疑慮。第三是修正成本：問題是否能透過補充文件、調整分類或增加問法範例處理，還是需要重新確認資料來源與權責。
實務上，可將「出現頻率高、影響大、答案風險高」的項目列為優先處理。像是涉及內部申請流程、客服承諾內容或作業規範的錯誤，通常比少見且影響有限的查詢更值得先檢視。若問題來自知識內容本身，應確認文件是否完整、版本是否一致，以及內容維護責任是否清楚；若資料正確但系統抓不到，則可檢查標題、段落切分、關鍵詞與常見問法是否貼近使用者實際表達。
測試也應納入跨輪對話與條件變化。同一個問題若因部門、地區、產品版本或使用者身分不同而有不同答案，就要確認知識庫能否辨識這些條件。測試紀錄可保留原始問句、預期答案、實際回答、問題分類、影響程度與修正狀態，後續再用相同問題回測，避免只憑感覺判斷內容是否已改善。
龍樂科技股份有限公司提供 AI 導入與策略規劃，以及 PoC 概念驗證與產品落地支持；企業在規劃知識庫測試時，可將測試結果整理成明確的修正清單，作為評估導入方向與驗證成果的依據。當每次測試都能連結到資料維護、系統檢索或使用情境，知識庫改善就不再只是補幾份文件，而是逐步建立可追蹤、可回測的管理流程。
案例說明
企業知識庫測試的重點，不是確認系統能不能回答「公司成立於哪一年」這類容易查找的問題，而是檢視它面對員工日常真正會提出的疑問時，能否找對資料、說清楚依據，並在資訊不足時明確告知限制。測試情境越貼近實際工作，越容易看出知識庫是否值得導入。
從員工常用的問法開始測試
同一件事在不同部門、不同年資的員工口中，可能有不同說法。測試時可將同一個問題改寫成正式問句、口語問句與簡短關鍵字，例如：「差旅費怎麼申請？」、「出差報帳要走什麼流程？」或「差旅報帳」。觀察系統是否都能找到同一份正確規範，而不是只對文件標題或特定詞彙有反應。
也可加入錯字、縮寫與不完整句子，例如「請假單在哪？」、「特休怎麼算」或「報帳附件」。這類查詢能反映員工在忙碌時的真實輸入習慣；若系統必須依照文件原文逐字提問才答得出來，實際使用時就容易增加搜尋成本。
確認多條件問題是否回答完整
不少工作問題同時包含身分、情境與限制條件。像是「新進員工出差需要準備哪些資料？」就不只是查出差規範，還可能涉及新進人員的作業流程。測試時可檢查答案是否涵蓋問題中的每個條件，並能區分適用對象，而不是把不同文件的內容混在一起。
另一種常見情境是追問。使用者先問「如何申請帳號？」接著問「主管也要核准嗎？」系統應能理解第二句承接前文，而不是把它當成毫無關聯的新問題。可再延伸詢問「如果申請被退回呢？」測試知識庫是否能沿著同一個流程提供一致資訊。
測試文件版本與資訊矛盾
企業資料可能分散在作業手冊、公告、表單說明與內部常見問題中，內容也可能因改版而不同。可設計一組新舊規範並存的測試資料，詢問「目前應依照哪一份流程辦理？」觀察系統是否能辨認文件版本與適用範圍，並指出答案依據。
若兩份文件說法不一致，系統不應自行拼湊出看似完整的答案。較合理的回應方式，是說明目前找到的資料存在差異，列出相關文件名稱或版本資訊，並提醒需要依內部權責確認。這項測試能避免錯誤資訊被包裝成肯定答案。
刻意提出資料不足或不適用的問題
知識庫測試不能只看答對的比例，也要確認系統知不知道何時不該回答。可提問「某項尚未公告的政策何時生效？」或詢問資料庫裡沒有的細節，檢查系統是否清楚表示查無依據，而不是自行推測日期、流程或負責人。
也可使用前提錯誤的問法，例如「按照已取消的舊規定，現在還能申請嗎？」測試系統能否指出前提可能不正確，並引導使用者查閱現行資料。若涉及權限或敏感資訊，還要確認不同使用者是否只會取得符合其權限範圍的內容。
檢查答案是否方便採取行動
有用的答案不只是貼上一大段文件內容，而是能直接回應使用者要做什麼。以「如何申請設備」為例，可檢視回答是否整理出申請步驟、所需資料與對應文件，並讓使用者知道資訊來自哪一份內部資料。若答案附上來源名稱、章節或文件連結，也較方便員工自行核對。
測試時可同時評估正確性、完整性、來源可追溯性與表達清楚度。若答案雖然正確，卻省略重要條件，或引用的來源已經失效，仍可能造成實務上的困擾。
把測試結果轉成改善清單
每次測試都可記錄原始問句、預期答案、系統回覆、引用來源與問題類型，再依結果分類為資料缺漏、文件過期、問法辨識不足、答案不完整或權限設定問題。這樣不必只憑印象調整系統，也能看出哪些問題反覆出現、哪些部門最需要補齊資料。
若企業正規劃 AI 導入與策略規劃，或進行 PoC 概念驗證與產品落地支持，這些真實查詢情境可作為評估依據之一。龍樂科技股份有限公司提供企業 AI 顧問與導入服務，以及 AI 開發與系統整合服務；企業可先整理實際工作問題與內部文件，再據此檢視方案是否符合使用需求。
常見問題Q&A
企業知識庫的測試，不能只確認系統能否找到文件裡的關鍵字。真正重要的是，它面對使用者平常會怎麼問、問得清不清楚，以及資料不足或彼此矛盾時，能不能給出合適回應。以下整理幾種值得納入測試的真實查詢情境。
問：使用者問法和文件用詞不同，系統還找得到答案嗎？
答：測試時可用同一個問題設計不同說法，例如正式用語、口語問法、縮寫，或只輸入部分關鍵字。也可以加入錯別字、同音字等情況，觀察系統能否理解查詢意圖，而不只是比對完全相同的詞句。若結果不一致，應檢查知識內容是否使用了使用者熟悉的名稱，並補上常見別稱或問法。
問：使用者只問一半，或沒有說明想查哪一類資料，系統該怎麼回答？
答：像是只輸入「申請流程」或「設備支援」這類內容，可能對應多種資料。測試應確認系統會不會直接猜測，也要檢查它能否指出資訊不足，並以簡短問題確認使用者要查的對象、情境或文件範圍。若系統自行補上未經資料支持的細節，便需要調整回答規則或知識內容。
問：使用者在對話中補充條件，系統還能接續理解嗎？
答：可先提出一個較廣泛的問題，再逐步補充部門、產品或使用情境，確認系統是否保留前文資訊。例如詢問企業 AI 導入相關內容後，再補充想了解概念驗證階段，測試系統能否把後續問題連回原本主題。也要測試使用者中途改變問題時，系統是否能辨識新舊需求，而不是沿用不相關的脈絡。
問：不同文件對同一件事的說法不一致，系統會選哪一個？
答：測試資料可刻意納入版本不同、更新時間不同，或描述互相矛盾的文件。觀察系統是否能辨認資料來源與版本資訊，並在無法判定時清楚說明目前資料不足，而不是任意拼湊出單一答案。日常維護時，也應標記文件的適用範圍與更新狀態，避免舊資料和新資料同時被當成有效依據。
問：知識庫裡沒有答案時，系統會不會自行編造？
答：這是很重要的測試情境。可以提出超出知識庫範圍的問題，或詢問資料中未列出的規格、價格與服務內容，確認系統是否明確表示找不到依據。以龍樂科技股份有限公司相關資訊為例，若問題涉及產品規格或服務細節，回答應以已提供的資料為準；資料沒有列出的內容，不宜自行補寫。
問：系統的答案能不能讓使用者確認資料來源？
答：可測試系統是否能指出答案來自哪份文件、哪個章節，或提供可供核對的來源資訊。這對政策、操作程序及產品資料尤其重要。若回答只給結論，卻無法回到原始資料查證，使用者較難判斷內容是否適用，也不容易發現知識庫中的錯誤。
問：不同使用者的權限不同，搜尋結果會不會顯示不該看的內容？
答：測試應涵蓋不同角色登入後的查詢結果，確認權限設定不只影響文件瀏覽，也確實涵蓋搜尋摘要、引用內容與對話紀錄。若部分資料僅供特定對象使用，系統不應透過片段摘要或答案內容洩露相關資訊。
問：多語言查詢或中英混合輸入，也需要測試嗎？
答：若企業日常會使用不同語言，便應測試中文、英文及中英混合查詢，也可檢查產品名稱、技術名詞或縮寫是否能正確對應。例如查詢 AI 導入與策略規劃、VERIS AI BOX、NVIDIA DGX Spark 等項目時，應確認不同寫法是否能找到相符資料，並避免把名稱相近的產品混為一談。龍樂科技股份有限公司的 QWalkie 多語言即時對講，也可作為多語情境的相關查詢內容，但答案仍須依知識庫實際收錄資料為準。
問：如何判斷測試結果是否符合實際使用需求？
答：除了確認答案是否正確，也應記錄查詢是否成功、引用來源是否吻合、系統是否適時追問，以及遇到未知問題時能否坦白說明。企業可將匿名化的常見提問整理成測試題庫，定期在文件更新或系統調整後重新測試。若正在規劃 AI 導入與策略，或進行 PoC 概念驗證與產品落地支持，這些真實查詢紀錄也能協助釐清知識庫的涵蓋範圍與後續修正方向。
重點結論
企業知識庫測試的重點，不是確認系統能不能回答資料裡已經寫好的問題，而是看員工用日常說法提問時，能否找到正確內容、交代依據，並在資訊不足時清楚表明限制。測試情境應從實際工作流程出發，涵蓋不同問法、不同資料狀態，以及可能造成誤解的邊界情況。
常見的直接查詢可以作為起點，例如詢問某項內部流程、產品規格或文件存放位置。不過，若題目只採用文件中的正式名稱，測試結果往往過於理想。實際使用者可能會使用縮寫、口語表達、錯別字，或以「上次那份表單」這類不完整描述提問。測試時應確認系統能否理解常見說法；若線索不足，也應追問必要資訊，而不是自行猜測答案。
同一問題換一種問法，仍應得到一致且有根據的回覆。例如，使用者可能問「差旅怎麼報」，也可能問「出差費用要去哪裡申請」。若兩種說法指向同一份制度文件，答案的核心內容與引用依據應保持一致。這類測試能檢查知識庫是否真正理解問題，而非只比對關鍵字。
跨文件與多步驟查詢也值得納入。實務上的問題常需要整合不同資料，例如先確認申請條件，再判斷應採用哪一種流程。測試時要觀察答案是否完整涵蓋各項必要資訊，並能指出資料來源；若不同文件的說法不一致，則應揭露差異，而非擅自合併成單一結論。
資訊不足、文件缺漏與過期內容，是最容易被忽略的情境。可以準備知識庫中沒有答案的問題，觀察系統會不會明確表示查無資料，或說明目前無法確認；也可測試已更新與舊版文件並存時，系統是否採用正確版本。對企業而言，能辨認回答範圍，比看似流暢卻沒有依據的推測更重要。
權限與敏感內容同樣需要測試。不同角色能查看的資料可能不同，測試應確認回覆不會透露使用者無權取得的內容，也不會因為問題措辭不同而繞過資料限制。若知識庫包含內部規範、客戶資料或營運資訊，這項檢查尤其不能只在上線前做一次，而應納入日常維護流程。
多語言與混合語言查詢則反映跨地區或跨部門的使用狀況。員工可能以中文提問，引用英文產品名稱，或在一句話中混用縮寫與專有名詞。測試時可確認系統是否能辨識關鍵詞、保留名稱原意，並以使用者容易理解的方式回答；若翻譯會影響制度或規格的精確性，也應確認答案能回到原始文件核對。
評估結果不宜只看「有沒有回答」。更實用的檢查項目包括答案是否正確、資訊是否完整、引用是否吻合、表達是否清楚，以及遇到未知問題時能否適當拒答。可將常見查詢整理成測試題庫，標記標準答案與依據文件，再由實際使用者定期補充新問題。當企業規劃 AI 導入、顧問及方案設計，或進行 PoC 概念驗證與產品落地支持時，這些真實查詢情境也能協助釐清知識整理、系統整合與驗收的範圍。龍樂科技股份有限公司提供相關 AI 導入與策略規劃，以及 AI 開發與系統整合服務，可作為企業規劃時的服務項目參考。