為什麼上下文是 AI 協作的基礎

在使用 AI 時，很多人會先關注模型能力——它是否足夠先進、能否處理複雜任務、回覆是否足夠精準。

但在實際業務中，另一個問題同樣重要：AI 是否取得了足夠清晰、完整、可用的上下文。

因為上下文決定了 AI 當前能參考什麼資訊、基於什麼前提判斷、按照什麼目標輸出；而模型能力只決定 AI 能做什麼，上下文才決定 AI 是否知道現在該怎麼做。

什麼是上下文

上下文就是 AI 在處理當前任務時可以參考的資訊。

在理解上下文之前，可以先簡單了解大型語言模型的工作原理：LLM 並不是像人一樣真正「記住」所有資訊，也不會天生知道使用者在其他地方說過什麼；相反，它在產生回覆時，會根據當前輸入中可見的資訊，判斷接下來最可能、最合適的內容是什麼。

也就是說，模型每一次回覆，都是基於當前可用資訊進行理解與產生；如果某個背景、事實或約束沒有出現在當前上下文中，模型就無法穩定地基於它作出判斷。

因此，上下文可以理解為 AI 當前「看得到、用得上」的資訊範圍。

具體來說，上下文可以包括：

例如，若使用者只說：「幫我分析一下這個客戶需求。」

那麼 AI 很難知道客戶是誰、需求來自哪裡、哪些資訊已經確認、哪些問題還需要追問。

但是，若使用者補充了客戶產業、溝通背景、核心訴求、預算限制、上線時間與前一次會議結論，AI 的分析就會更具體，也更接近真實業務場景。

所以，上下文不是「多寫一點文字」，而是讓 AI 獲得完成任務所需的判斷依據。

上下文為什麼影響 AI 表現

大型語言模型不會天生知道使用者腦中的資訊，也不會自動了解企業內部已確認的結論；它的輸出主要依賴當前可以看到與使用的資訊。

常見的上下文問題及其影響如下：

因此，AI 輸出品質不只取決於模型是否足夠強，也取決於上下文是否清晰、完整、一致。

企業 AI 協作更依賴上下文

個人使用 AI 時，上下文通常影響下一次回覆的品質；但企業使用 AI 時，上下文還會影響協作、流程與決策。

一個業務任務可能來自客戶溝通，需要業務補充背景，產品確認需求，技術判斷可行性，再由 AI 協助整理分析，最後透過工作流程產生報告或觸發後續操作。

如果這些資訊分散在會議紀錄、私訊、文件與不同 AI 對話裡，後續協作就會變得低效，因為：

• 團隊需要反覆說明背景；
• AI 會重複分析已經確認的問題；
• 工作流程可能因缺少關鍵輸入而無法精準執行；
• 後來加入的成員也很難快速理解前面的判斷依據。

所以，企業 AI 協作需要解決的不是「讓 AI 回答問題」，而是「讓 AI、工作流程與團隊成員基於同一份上下文持續推進任務」。

好的上下文至少帶來三類價值：

GoInsight.AI 中的上下文建構

在 GoInsight.AI 中，不同使用場景會採用不同的上下文建構方式：

• 在協作場景中，上下文通常透過 Collaboration Workspace 的同一討論串持續沉澱；
• 在流程執行場景中，上下文則透過 InsightFlow 的節點、變數、知識庫檢索、LLM 與 Agent 等能力被結構化傳遞與使用。

Collaboration Workspace：同一討論串中的共享上下文

Collaboration Workspace 是一個持續協作的工作現場。

使用者可以在同一個對話討論串中，透過 @ 呼叫同事或對話式工作流程；任務背景、使用者補充、同事確認、對話式工作流程回傳的結果，都會沉澱在當前討論串中。

在這個討論串裡，上下文來自不同參與方，各自作用如下：

由於所有資訊都保留在同一個討論串中，後續參與者不需要從零開始理解任務，而是可以基於前面的討論繼續推進。

例如，業務團隊正在討論客戶需求：使用者先輸入客戶背景，同事補充會議回饋，再透過對話式工作流程整理需求或產生分析；所有資訊都保留在同一個討論串中，下一次繼續討論或執行流程時，就可以直接基於已有上下文繼續處理。

這類共享上下文的價值主要在於：

• 減少重複溝通；
• 維持多人協作的連續性；
• 讓對話式工作流程基於已有資訊繼續執行；
• 保留討論、判斷與結果，方便後續接力。

InsightFlow：讓上下文在流程中被使用

如果說 Collaboration Workspace 關注的是協作中的上下文連續，那麼 InsightFlow 更關注流程執行中的上下文組織與傳遞。

在 InsightFlow 中，真正需要基於上下文進行理解、產生或推理的，通常是 LLM 節點和 Agent 節點：

• LLM 節點會基於提示詞、輸入變數、知識庫檢索結果與記憶產生內容。
• Agent 節點會基於指令、Query、工具資訊、工具回傳結果與記憶進行推理與操作。

而變數、知識庫檢索節點、HTTP 請求節點和工具呼叫節點，更多是在為 LLM 或 Agent 提供上下文材料。

例如：

• 變數用於在節點之間儲存與傳遞資訊。
• 知識庫檢索節點把相關文件片段帶入流程，供 LLM 或 Agent 使用。
• HTTP 請求節點可以從外部系統取得資料，作為後續判斷依據。
• 工具呼叫結果可以繼續傳遞給 LLM 或 Agent，協助其產生下一步結果。
• 記憶可以讓對話式工作流程在多輪處理中保持上下文連續。

這些配置的本質，都是在回答同一個問題：當前 LLM 或 Agent 節點應該基於哪些資訊繼續處理任務？

因此，InsightFlow 中的上下文建構，不是簡單地把所有資訊都塞給 AI，而是透過流程編排，把合適的資訊在合適的步驟提供給 LLM 或 Agent。

可以簡單理解為：

• Workspace 讓上下文在協作中連續。
• InsightFlow 讓上下文在流程中被組織、傳遞和使用。

前者解決的是使用者、同事與對話式工作流程如何圍繞同一個任務持續協作；後者解決的是複雜任務中，LLM 或 Agent 如何在不同步驟獲得所需資訊，並繼續產生、判斷或執行。

上下文不是越多越好

強調上下文重要，並不意味著要把所有資訊都交給 AI。

好的上下文應該是相關、清晰、即時、可使用的。

• 如果一次性提供大量無關材料，AI 反而更難判斷重點；
• 如果把舊結論與新結論混在一起，AI 可能基於錯誤前提繼續產生；
• 如果一個任務裡同時包含太多目標，AI 也容易在不同要求之間搖擺。

因此，建構上下文時更重要的是：

• 把關鍵事實放進當前討論串；
• 把已確認結論沉澱下來；
• 把過時或無關資訊排除出去；
• 讓不同步驟使用各自需要的資訊；
• 對複雜任務進行拆分，讓每一步都有明確輸入與輸出。

這不是單純的提示詞技巧，而是讓 AI 協作更穩定的基礎。

為什麼需要 Say It for Me

即使有協作討論串、知識庫檢索、LLM 節點和 Agent 節點，實際業務中仍然會出現一個問題：許多關鍵上下文來自系統之外。

例如客戶會議中確認的需求、團隊討論後的判斷、外部資料中的結論、其他系統查詢到的資料，或是使用者自己已經整理好的答案——這些資訊可能很重要，也可能已被確認，但如果它們沒有進入當前討論串，後續同事、對話式工作流程或使用者自訂的 Agent 就無法基於它繼續協作。

換句話說：資訊存在，不代表 AI 可以使用；只有資訊進入當前上下文，AI 才能基於它工作。

Say It for Me 是 Collaboration Workspace 中用於補充這類上下文的一個預設功能。

它不是用來替使用者產生答案，而是幫助使用者把已經準備好、已經確認過的回覆，以「問題 + 回答」的形式寫入當前協作討論串。

1. 使用者可以在 Collaboration Workspace 的輸入欄位中輸入 @，在可呼叫對象中選擇 Say It for Me。
2. 選擇後，使用者先提出一個問題，再在跳出的表單中填寫已經準備好的回覆。
3. 送出後，這組問答會出現在當前討論串中，成為後續協作可以繼續引用的上下文。

例如，業務團隊已經在線下會議中確認了客戶的核心需求，但這段資訊還沒有進入當前協作討論串。

使用者可以透過 Say It for Me 寫入：

送出後，這組「問題 + 回答」就會成為當前討論串中的上下文。

後續無論是讓團隊成員繼續補充方案，還是執行需求整理類型的對話式工作流程，或者呼叫使用者自訂的 Agent，都可以基於這條已確認資訊繼續推進。

這讓協作從「重新說明背景」變成「基於已確認事實繼續工作」。