企業導入生成式 AI 時，最常見的起點是「先做一個聊天機器人」。員工輸入問題，AI 產生回答，畫面上有一個熟悉的對話框，看起來就像完成了一個 AI 產品。

但真正開始使用後，幾乎每個團隊都會遇到同樣的問題：

公司真正需要的，並不是一個比較會聊天的搜尋框，而是一套能可靠完成工作的系統。

這兩者看起來很相似，背後的設計思維卻完全不同。聊天機器人的核心是產生文字，而企業 AI 工作系統的核心，是找到資料、理解定義、執行操作、驗證結果，最後才整理成回答。

從一個真實的工作問題開始

想像一位同事在下午三點問你：

「今年哪一類需求工單最多？主要來自哪些市場？相關專案目前進度如何？」

這看起來只是一個簡單的問題，但真正要回答它，通常需要完成一連串工作。

首先，你必須打開 Google Sheets，找到正確的需求工單資料表，確認分析期間、篩選條件與欄位內容。接著，你可能還要前往 Confluence 或內部 Wiki，確認「需求工單分類」的正式定義，避免自己與提問者使用不同的統計標準。

確認定義後，才能開始依照分類彙整工單數量、計算市場分布與各類別占比。接著，你還需要前往 Trello 或 Jira，確認相關專案目前的狀態、負責人、截止日期與可能的阻塞原因。

最後，才是把數字、背景與進度整理成一份能夠支持決策的摘要。

整個流程可以整理成五個步驟：

1. 找到正確的資料表
2. 確認欄位與分類定義
3. 執行統計與比較
4. 查詢專案進度
5. 整理成可使用的結論

因此，真正的工作不是「產生一段文字」，而是一連串找資料、理解定義、計算、查核與整理的動作。

聊天型 AI 或許可以協助最後一步，但前面的四個步驟，又該由誰完成？

聊天機器人與企業 AI 工作夥伴的差別

聊天機器人通常接受文字輸入，再根據大型語言模型的訓練知識產生回答。它擅長通用知識問答、文案撰寫、摘要、翻譯與腦力激盪，但如果沒有額外連接企業系統，它通常不知道公司的即時資料，也無法確認內部的欄位定義、專案進度與業務規則。

企業 AI 工作夥伴則不只是產生文字。它必須知道公司的資料存放在哪裡、不同問題應該使用哪些工具、如何取得最新資料，以及如何查核分析結果。當它找不到答案時，也必須誠實說明限制，而不是自行補上一個看似合理的答案。

兩者最大的差別，並不是模型夠不夠聰明，而是 AI 是否連接了真實資料、企業工具與工作流程。

一個很聰明但沒有連接企業資料的 AI，就像一位完全不熟悉公司的新同事。

他可能可以提供很好的通用建議，卻無法告訴你昨天的會議紀錄存放在哪裡、公司如何定義需求工單，以及目前有哪些專案已經延遲。

企業知識工作的五個步驟

Data Machi 的核心設計目標，是讓 AI 能完整走過一段知識工作流程，而不是只停留在最後的「輸出文字」。

1. 找到正確的資料來源

系統首先要判斷回答問題需要使用哪一種資料來源。答案可能存在 Google Sheets、Confluence、Trello、PDF 文件、資料庫、API 或其他內部知識庫中。

不同問題可能需要不同工具，有些複合問題甚至需要同時查詢多個來源。

2. 理解問題與資料定義

找到資料後，AI 還必須理解資料代表的意義。例如，欄位代表什麼、工單分類邏輯為何、「完成」與「進行中」如何定義，以及統計範圍是否包含取消或重複的工單。

如果沒有先釐清定義，即使計算本身沒有錯，也可能回答了錯誤的問題。

3. 選擇適合的分析方法

不同問題需要不同的分析方式。有些問題只需要件數統計，有些需要占比、年度比較、趨勢分析、分群比較或異常偵測。

企業 AI 不應該只是把原始資料重新排列，而是要根據問題選擇合適的分析方法。

4. 執行查詢與工具操作

接著，系統必須真的呼叫工具並取得結果，而不是依靠模型的記憶或印象回答。

例如，它可能需要讀取 Google Sheets、查詢資料庫、搜尋 Confluence 文件、取得 Trello 卡片狀態，或使用 Python 執行統計分析。

只有真正取得最新資料，回答才可能隨著企業狀況更新。

5. 整理成能支持決策的結論

最後，系統需要將不同來源的資訊整合成容易理解的內容。一份可信賴的回答通常不只包含核心發現與數字，也應說明資料來源、使用定義、分析限制與下一步建議。

企業 AI 的回答不只要看起來合理，還要讓使用者知道結果從哪裡來，以及接下來能採取什麼行動。

評估一套企業 AI 系統時，可以先問一個問題：

當企業資料更新時，答案會跟著更新嗎？

如果答案是「不會，因為系統只能使用 Prompt 裡提供的內容」，那它仍然停留在聊天機器人的層次。

初學者可以怎麼理解？

聊天機器人像是一位很會說話的新同事。他讀過很多書、表達流暢，回答問題時也充滿自信，但他不知道公司的資料放在哪裡，也不確定自己說出的數字是否正確。

企業 AI 工作夥伴則像是一位熟悉公司系統、知道如何查資料，而且在交付前會檢查結果的同事。

他不一定比前者更聰明，但他知道哪些事情需要查證、應該使用哪個系統、什麼時候不能靠猜測回答，以及結果交付前需要做哪些確認。

因此，企業真正需要的並不是一個更會說話的模型，而是一套能夠可靠執行工作的系統。

Data Machi 如何處理不同問題？

在 Data Machi 中，使用者只需要使用自然語言描述需求。系統會先判斷問題屬於哪一種類型，再選擇對應的工具與處理方式。

數據分析

當問題涉及數字、統計、比較或趨勢時，系統會使用 Google Sheets 或其他結構化資料工具。它可能需要查詢工單數量、計算分類占比、比較不同市場，或整理年度趨勢。

文件知識

當問題涉及規則、定義、背景資訊或內部流程時，系統會查詢 Confluence、PDF 或其他知識庫。例如確認欄位定義、查找作業規範、整理會議紀錄，或比較不同版本的文件。

專案進度

當問題涉及任務狀態、負責人、截止日期或阻塞原因時，系統會連接 Trello、Jira 或其他專案管理工具。

複合問題

有些問題無法只透過單一工具完成，例如：

「今年需求最多的工單分類是什麼？相關專案目前完成了多少？」

這個問題可能需要先從 Google Sheets 統計需求工單，再從 Confluence 查詢分類定義，接著從 Trello 取得專案狀態，最後才將三個來源整合成一份摘要。

在這種情況下，Data Machi 會由 Coordinator 判斷需要使用哪些工具、工具的執行順序，以及如何整合結果。

這是整套系統從「聊天介面」走向「企業知識工作流」的第一步。

踩坑筆記：為什麼只靠 Prompt 不夠？

早期開發企業 AI 時，最常見的做法之一，是把所有規則都塞進一段很長的 System Prompt。

例如，要求模型先查詢資料、不可以捏造答案、回答前必須確認來源、工具失敗時要重新嘗試，以及高風險操作前必須詢問使用者。

這些要求看起來很完整，但問題在於：

Prompt 只能告訴模型「應該怎麼做」，卻無法保證這些步驟真的被執行。

Prompt 比較像是提供給模型的員工手冊。它可以描述期待的行為，但不能真正控制每一個執行步驟。

只靠 Prompt，通常無法保證模型一定會呼叫工具、使用正確工具、按照正確順序執行多個步驟，也不能保證工具失敗時會自動重試，或高風險操作一定會經過人工確認。

真正的企業工作流程需要程式層面的控制，例如：

• 狀態管理
• 條件分支
• 工具路由
• 錯誤處理
• 重試機制
• 人工審核
• 執行紀錄

這些能力無法只靠一段 Prompt 穩定完成。後續文章會進一步介紹，如何透過 Tool Use、Agent 與 LangGraph，逐步補上這些能力。

本日重點

今天只需要記住一件事：

企業 AI 的價值，不在於回答得像不像人，而在於它能不能可靠地完成一段工作。

聊天機器人主要解決「如何產生回答」，但企業 AI 工作系統還必須解決如何找到正確資料、理解企業定義、選擇適合工具、執行與驗證結果，以及產生可以支持決策的結論。

下一篇，我們會進一步拆解「知識工作」到底由哪些環節組成，以及為什麼理解這個流程，是設計企業 AI 系統的第一步。