AI 原生公司的資料基礎：知識庫、流程資料與模型回饋怎麼設計

AI 知識庫不是把文件丟進雲端硬碟，而是把公司知識、流程紀錄與人工修正整理成 AI 能查、能引用、能更新的資料基礎。中小企業不必一開始做大型數據平台，但要先支撐客服、業務、內容、行政等高頻流程，讓 AI 輸出更接近公司真正做法。

AI 知識庫不是資料夾，重點是讓 AI 找得到、用得對、回得去

很多公司開始做企業 AI 導入時，會把 SOP、產品簡報、FAQ、合約範本丟進 Google Drive 或 Notion，期待 AI 自然懂公司。但 AI 知識庫的重點不是「有放資料」，而是資料能否被正確找到、引用到對的情境，並在錯誤後回到資料系統修正。

更實際的定義是：AI 知識庫是給 AI 使用的公司記憶系統，包含 SOP、客服問答、產品資料、報價規則、內容規範、專案紀錄、品牌語氣與審稿標準。

這也是AI 原生公司和一般 AI 工具使用的差別：不是每個人各自問 ChatGPT，而是讓公司重要知識能被流程穩定取用。Microsoft WorkLab 也提醒，每個企業都有大量資料資產，但常因資料分散、藏在不同系統、資訊過載而難以使用。Microsoft WorkLab：AI-native startups

我們是如何分類公司內部資料？知識資料、流程資料、回饋資料

企業資料 AI 最容易失焦，是因為所有資料都被叫做「資料」。AI 真正要用的資料，可以先分成三類：知識資料、流程資料、回饋資料。

知識資料：SOP、FAQ、產品頁、合約、報價規則、品牌手冊。AI 用來回答問題、產生草稿、引用標準答案。需要版本控管，敏感程度通常是中到高，負責人多半是部門主管或知識 owner。
流程資料：CRM、CMS、表單、任務紀錄、工具呼叫 log。AI 用來判斷下一步、追蹤任務、稽核流程。需要版本控管，敏感程度高，負責人應是流程 owner。
回饋資料：審稿意見、客服修正、主管改稿、客戶反應。AI 用來改善知識庫、prompt、流程與審核規則。敏感程度要依內容判斷，負責人通常是審核者與流程 owner。

知識資料是 AI 回答與產出時要引用的標準答案，例如產品規格、服務流程、FAQ、品牌語氣、教育訓練文件。IBM Think 2026 的資料基礎回顧指出，企業從 AI 實驗走向 AI transformation 時，資料標準不只是能存取，而是要即時串流、補上 context，並確保資料可信；資料品質會影響每一次 AI 判斷。IBM Think 2026：AI-ready data foundation

流程資料則是 AI Agent 做事時留下的任務軌跡。誰觸發任務、讀了哪些 CRM、CMS、表單資料、呼叫哪些工具、產出哪版草稿、誰審核、結果如何，都應該留下來。IBM Think 2026 發表的 AI operating model 把 agents、data、automation 與 hybrid systems 視為彼此配合的企業系統；這也是 AI-native workflow 不能只看自動化步驟，還要看資料紀錄的原因。IBM Think 2026：AI operating model

回饋資料是讓下一次輸出變好的修正紀錄。客服把 AI 回覆改掉、業務主管調整話術、編輯刪掉不符合品牌的段落，如果都留在個人 LINE、口頭提醒或各部門自己亂接工具，AI 永遠學不到，也容易形成 Shadow AI 工具混亂。真正可累積的做法，是把修正原因回寫到知識庫或流程 log，並搭配 AI Agent 工作流治理設定審核與稽核欄位。

AI 知識庫怎麼建？把文件整理出可以用的知識結構

AI 知識庫的實作重點，不是把所有文件搬到同一個平台，而是把常用資料整理成「AI 查得到、看得懂、知道能不能用」的知識單元。每個知識單元都應該能回答一個明確問題，例如「客服遇到退款爭議怎麼回覆」、「業務報價前要確認哪些條件」、「文章初稿不能使用哪些品牌禁語」。

比較容易落地的做法，是從一條高頻流程開始整理：

盤點資料來源：列出 SOP、FAQ、產品頁、客服紀錄、CRM 欄位、表單、Notion、Google Docs 等來源，不急著一次全部搬完。
按用途分類：把資料分成客服、業務、內容、行政、內部訓練等用途，避免 AI 在錯誤流程引用錯誤資料。
清理重複與過期內容：刪除舊版報價、過期規則、互相衝突的 FAQ，保留目前仍有效的版本。
拆成知識單元：一段處理一個問題，避免整份 PDF 或簡報直接丟給 AI，導致答案抓不到重點。
補上 metadata：至少標註標題、來源、版本、適用情境、更新日期、負責人、敏感程度。
設定權限與審核規則：不是每個 AI 流程都能讀合約、報價、客戶個資；高風險輸出也要有人確認。
建立更新責任：知識庫不是建完就好，資料 owner 要知道什麼時候需要更新、誰能核准新版內容。

知識結構也不一定只能用純文字或 Markdown 表達。Simon Willison 在〈Using Claude Code: The Unreasonable Effectiveness of HTML〉引用 Thariq Shihipar 的觀點：對 Claude 這類 AI 要求 HTML 輸出，有時比 Markdown 更能承載結構、標註、差異說明、互動 artifact 與語意資訊。放回企業知識庫脈絡，這提醒我們：AI 可讀資料不只是「文字有沒有存起來」，也包含標題層級、欄位、狀態、引用來源與審核標記是否清楚，讓 AI 在後續流程中更容易判斷內容怎麼使用。

中小企業可以把這件事想成「整理給 AI 使用的內部手冊」。如果人類新人看不懂、找不到來源、分不清新版舊版，AI 通常也不會穩定。把知識單元整理好，再讓 OpenClaw 或其他 Agent 去查，才比較容易累積可控的工作流。

Demo：同一份知識，AI 讀到的結構差在哪？

Markdown 像筆記，HTML 像可被 AI 讀懂的知識結構

同一段內容，文字意思沒有變；差別在於 HTML 多了標籤、層級與關聯訊號，讓 AI、搜尋引擎與 agent 比較能穩定判斷哪裡是主題、哪裡是說明、哪些項目屬於同一組例子。

Markdown：人類好讀的內容草稿

適合快速寫作、整理想法與協作。

## AI 知識庫怎麼建？

公司不能只是把文件丟進資料夾。
真正可用的 AI 知識庫，要把內容整理成清楚的主題、段落與關聯。

- 公司 SOP
- 客戶常見問題
- 銷售話術
- 專案紀錄

AI 還要自己猜：這段是不是完整主題？
清單和段落的關係，需要靠上下文推測。
內容被截取或轉換時，語意比較容易變模糊。

HTML：AI 更容易讀懂的知識結構

用標籤把主題、段落、清單與關聯標出來。

<section aria-labelledby="kb">
  <h2 id="kb">AI 知識庫怎麼建？</h2>
  <p>公司不能只是把文件丟進資料夾。真正可用的 AI 知識庫，要整理出主題、段落與關聯。</p>
  <ul>
    <li>公司 SOP</li>
    <li>客戶常見問題</li>
    <li>銷售話術</li>
    <li>專案紀錄</li>
  </ul>
</section>

<section> 告訴 AI：這是一個完整主題區塊。
<h2>、<p>、<ul> 分別標出標題、說明、例子。
aria-labelledby 讓區塊與標題關係更明確。

重點不是把資料堆得更多，而是把內容整理成 AI 能穩定讀懂、引用、重組的結構。

RAG 企業導入前，要先把資料整理成 AI 能引用的格式

RAG 可以用一句話理解：讓 AI 先查公司資料，再回答問題或產出內容。就像訓練客服新人時，會先給他 SOP、產品資料、客戶紀錄與禁用說法。RAG 只是方法，資料品質才是根本。

IBM Think 2026 的資料基礎回顧指出，AI-ready data 不只要能被存取，還要補上 context、維持可信，並能支撐即時使用。IBM Think 2026：AI-ready data foundation 所以導入 RAG 以前，不要急著討論向量資料庫、embedding 或 chunk 大小，而是先把文件整理成 AI 可以引用的最小單位。

一份可用的知識資料，至少要有：

標題與適用情境：回答什麼問題、用在哪種流程。
來源與版本：來自哪份文件、何時更新、是否仍有效。
權限與審核：哪些流程可讀，哪些輸出必須人工確認。

對中小企業來說，就是不要把 PDF、簡報、Notion、Google Docs、客服紀錄整包亂丟給 AI；先拆段落、標來源、確認版本，再讓 AI 流程讀取。

RAG 不是第一步，向量資料庫要等需求清楚再上

很多企業一聽到 AI 知識庫，就以為一定要先買向量資料庫。實務上，如果資料量還小、查詢情境單純、資料多半是固定 FAQ 或 SOP，用整理好的文件、表格、權限規則與人工審核，就能先驗證 AI 是否真的幫得上忙。

比較適合評估 RAG 或向量資料庫的情況，是公司已經遇到這些問題：

文件量明顯變大：人工很難靠資料夾或關鍵字搜尋找到正確段落。
查詢頻率高：客服、業務、內容或行政每天都在問類似問題，手動查資料太慢。
權限變複雜：不同部門、客戶等級、專案狀態能看的資料不同，不能讓 AI 全部混在一起讀。
更新頻率高：產品規則、價格、活動、政策常變，AI 回答必須能追到最新版本。
準確率要求高：涉及對外承諾、金額、合約條款、客戶個資，答案必須附來源並保留審核紀錄。

向量資料庫能幫 AI 從大量文字中找相近內容，但它不會自動解決資料過期、權限混亂、來源不明或人工審核缺失。IBM Think 2026 的資料基礎回顧也提醒，AI 若缺少可信 context 與治理，可能放大企業內既有的資料 fragmentation。IBM Think 2026：AI-ready data foundation 只要涉及敏感資料、對外承諾、金額、合約條款或客戶個資，就需要權限控管、引用來源與 AI Agent 安全設計。

CRM、CMS、客服與工作流紀錄，是中小企業最容易被浪費的資料

中小企業不一定有資料湖，但通常已有很多可用資料，只是分散在 CRM、CMS、客服系統、表單、Google Sheet、LINE 對話與任務管理工具裡。Microsoft WorkLab 提到，AI 可以協助整理 hidden、disparate sources 或 information overload 中原本難以使用的資料。Microsoft WorkLab：AI-native startups

CRM 資料的價值，不只是讓 AI 生成罐頭訊息。詢問來源、產業、過去互動、報價版本、成交或流失原因，都能幫助 AI 判斷客戶狀態，產生下一步建議。同樣是詢問方案，新客戶和已談過報價的客戶，AI 應讀到不同脈絡。

CMS 與內容資料能變成品牌聲音與 SEO 工作流的知識庫。已發布文章、品牌用語、FAQ、案例、內鏈規則、審稿意見，都能支撐內容初稿、改稿與內鏈建議。Microsoft 提到，有 AI-native 廣告公司把超過 two decades 的 advertising effectiveness research 放進平台，讓創意人員日常使用。Microsoft WorkLab：AI-native startups

客服紀錄不是成本中心，而是產品與服務改善資料。常見問題、抱怨分類、退貨理由、客戶用語，可以回饋到知識庫、產品頁、銷售話術與 FAQ。Microsoft 的醫療新創案例提到，AI 分析最多 200 個健康因素；相較之下，標準電子病歷通常只包含約 10% 真正相關資料。Microsoft WorkLab：AI-native startups

工作流 log 則是 AI-native data architecture 的骨架。每次 n8n 自動化流程設計或 n8n AI 內容產製工作流都應留下任務 ID、輸入、輸出、工具呼叫、審核人與結果。IBM Think 2026 的 AI operating model 強調，企業 AI 要把 agents、data 與 automation 串進可治理的系統。IBM Think 2026：AI operating model 沒有 log，就無法知道 AI 哪裡做得好、哪裡需要人介入。

模型回饋要制度化，不能只靠同事覺得 AI 不好用

很多公司導入 AI 後，最常聽到「AI 不好用」「它不懂我們公司」。這些感覺不一定錯，但如果沒有變成可追蹤的回饋資料，就不會改善。模型回饋的核心，是把人工修正、審核意見、客戶反應變成下一次 AI 可查詢、流程可調整的資料。

例如客服回覆被改哪一句、文章草稿哪個段落不符合品牌、業務建議被主管改成哪個版本，都應該留下修正原因。IBM Think 2026 的資料基礎回顧指出，企業要把資料變成可行動的 intelligence，不能只停在資料可取得。IBM Think 2026：AI-ready data foundation

回饋欄位不能一開始設計太重，否則員工不會填。比較適合起步的欄位範本如下：

任務 ID / 任務類型：例如客服回覆、業務跟進、文章草稿、會議摘要、資料分類。
AI 原始輸出：保留 AI 當時產出的版本，方便回頭判斷錯在哪裡。
人工修改後版本：記錄最後採用的內容，不只留下「改過」兩個字。
修改原因：例如資料錯誤、語氣不符、缺少來源、權限不該讀、客戶情境判斷錯。
引用來源：AI 當時引用哪份 SOP、FAQ、CRM 欄位或知識庫段落。
風險等級：一般內容、需主管確認、涉及個資、涉及金額或合約承諾。
回寫動作：要更新知識庫、SOP、prompt、權限規則，還是只記錄為個案。
審核人與處理狀態：誰確認、是否已回寫、是否需要追蹤下一版結果。

不是每個修改都要變成新規則。真正值得回寫知識庫的，是重複發生、會影響客戶體驗、涉及風險，或代表公司標準答案已經改變的修正。如果只是單一客戶的特殊情境，可以留在任務紀錄；如果同樣錯誤一直出現，就應該更新 SOP、prompt 或權限設定。

Microsoft WorkLab 提到，AI-native startup 會讓員工成為 AI manager，負責 assign tasks、provide feedback、move forward with decisions。Microsoft WorkLab：AI-native startups 這正是 Human-in-the-Loop 與 AI 原生組織設計的價值：人不是每次從零修改，而是把判斷變成下一次可用的資料。

回饋也要分流。AI 不懂公司規則，就補知識庫；亂查資料，就改權限或引用規則；常犯同錯，就調 prompt 或流程；高風險輸出，就加人工審核。公司從個人使用 AI 進入流程化回饋後，也可用 AI 導入成熟度評估缺的是資料、治理還是工作流設計。

資料基礎的起步順序：先盤點高價值流程，再設知識庫與回饋迴路

資料基礎不是一次把全公司資料整理完，而是先挑一條值得 AI 化的流程。好的起點通常符合三個條件：高重複、高資料、高判斷。像客服分類、詢價回覆、SEO 內容審稿、業務跟進、會議摘要，都比「整理所有公司文件」更容易驗收。

可以用這份 AI 資料盤點 checklist 取代過長表格，讓流程 owner 直接拿去開會討論：

流程名稱：這是哪一條工作流？例如客服分類、詢價回覆、文章審稿或業務跟進。
資料來源：資料來自 CRM、CMS、客服系統、表單、文件，還是人工輸入？
資料格式：內容是文件、表格、API、對話紀錄、圖片，或多種格式混在一起？
更新頻率：資料每天、每週、每月更新，還是靠人工不定期維護？
敏感程度：是否包含個資、報價、合約條款或商業機密？
負責人：誰負責維護資料正確性？誰能核准新版內容？
AI 用途：AI 要用來查詢、分類、寫草稿、給建議、做摘要，還是協助審核？
人工審核：哪些輸出必須經過人確認？哪些情況需要升級給主管？

中小企業不需要一開始把每個階段都做滿；先讓一條流程跑起來，能查資料、能產草稿、有人審、修正能回寫，就已經具備擴大的基礎。

IBM Think 2026 發表的 AI operating model 指向同一個重點：企業 AI 不只是單點工具，而是 agents、data、automation 與 hybrid systems 的系統性設計。IBM Think 2026：AI operating model 所以在評估 AI 導入成本時，不要只看工具月費，也要看資料整理、權限、審核與維護成本。

如果公司已開始使用 ChatGPT、n8n、CRM、CMS 或客服工具，但資料散在各處、AI 回答不穩、審核意見沒有回收，適合先找 AI 自動化顧問盤點第一條可落地的 AI 資料工作流。好事發生數位可以協助整理內部知識庫、流程資料與模型回饋欄位，讓 AI 導入從工具試用走向可累積的工作流資產。

常見問題 FAQ

AI 知識庫一定要用 RAG 或向量資料庫嗎？

不一定。先把常用文件、FAQ、SOP、客戶紀錄整理成 AI 可引用、有來源、有版本的資料，比一開始選向量資料庫更重要。IBM Think 2026 的資料基礎回顧指出，AI-ready data 需要即時、可信且帶有 context；技術可以後補，資料管理習慣要先建立。IBM Think 2026：AI-ready data foundation

公司資料都在 Google Drive、Notion、CRM 裡，可以直接丟給 AI 嗎？

不建議整包丟。比較安全的做法是先分類、標註來源與版本、設定權限，並把敏感資料遮罩或限制使用情境。資料來源越分散，越需要先定義哪一條流程能讀哪些資料，而不是讓 AI 自由翻全公司的文件。

模型回饋是什麼？中小企業真的需要做嗎？

模型回饋就是把人工修正、審核意見、客戶反應變成下一次 AI 可查詢的資料。只要公司把 AI 接進客服、內容、業務或行政流程，就需要基本回饋紀錄。IBM Think 2026 的資料基礎回顧指出，企業要把資料變成可行動的 intelligence，不能只停在資料可取得；修正沒留下來，AI 就難以越用越準。IBM Think 2026：AI-ready data foundation

資料基礎要做到什麼程度，才適合導入 AI Agent？

不用等到資料完美。先挑一條高重複、高資料、高判斷的流程，整理必要資料、設定權限、留下紀錄與審核，再逐步擴大。Microsoft 指出每個企業都有 treasure trove of data，但常因分散、隱藏或資訊過載而難以使用；AI Agent 的第一步，是把資料變得可用。Microsoft WorkLab：AI-native startups