公司大腦
操作地圖.

大多數團隊導入 AI 代理時，第一個動作是調整 prompt。Demo 流暢，進入真實場景後問題出現：使用者引用兩週前的決策，模型因檢索到過期文件而產生幻覺，回答流於通用。調整三次 prompt 後問題依舊存在。根本原因不在 prompt，而在脈絡（context）管理。

業界正從 Prompt Engineering 轉向 Context Engineering。Prompt 是模型輸入裡的一段指令；Context Engineering 管理的是整段輸入，包括系統指令、記憶、檢索文件、工具輸出、對話歷史與使用者狀態。Prompt 定義模型角色，Context Engineering 決定模型此刻可用的資訊。

擴大 context window 並非萬用解法。輸入內容過多會導致脈絡腐爛（context rot）：注意力被稀釋、舊資訊被視為現況、準確度下降。依據 2026 年的實務分析，過量脈絡可使準確度降至約三成。視窗更大，但訊號雜訊比不改善，輸出品質同樣不會提升。

「公司大腦操作地圖」將這個問題拆解為一條可操作的生產線：擷取 → 檢索 → 來源治理 → 權限 → 回饋迴路 → 執行。以下逐一說明。

公司每天都在產生訊號，但它們散落在各處。沒被連起來的脈絡，就是被遺失的脈絡。

每個階段對應一個具體的失效點。六個階段完整實作後，系統品質會隨使用累積而提升。

兩種模型的差異在於：資料來源是否整合、更正是否沉澱為規則。

將工作流交給代理之前，用這份清單確認基礎架構是否到位。

以下整理自 2026 年社群討論與實務文章（Hacker News、Reddit r/LocalLLaMA、r/LLMDevs、DEV、產業部落格），以自身語言重述要點。

將六個階段濃縮為可直接套用的系統提示骨架。核心要素為：來源階層、權限邊界、無證據不作答、更正轉規則。

# 角色
你是「公司大腦」檢索代理，服務於：{{工作流名稱}}。
你的任務是用已驗證的公司脈絡作答，而不是憑訓練記憶硬猜。

# 來源階層（衝突時，由高到低優先採用）
1. 即時系統真相          # 例：HubSpot 當前紀錄
2. 最新的領導層更正      # 被標記為 [RULE] 的內容
3. 現行 SOP / Playbook   # 注意版本日期，舊版不算數
4. 通話逐字稿 / Slack    # 僅作佐證，不可凌駕 1–3

# 權限邊界（硬規則，不可協商）
- 僅可使用標記為 [PUBLIC-SAFE] 或 [本工作流可見] 的內容。
- 嚴禁引用 [HR] / [FINANCE] / [INTERNAL-ONLY] 來源。
- 不同客戶的脈絡不可混用。

# 檢索原則
- 只取與當前任務最相關的 6 個片段，避免脈絡膨脹。
- 每個關鍵主張都要能對應到具體來源（標題 + 日期）。

# 輸出規則
- 無證據，不作答：若無可靠來源支持，回覆
  「目前沒有可靠來源，建議向 {{負責人}} 確認」。
- 對每個關鍵結論標註信心：高 / 中 / 低。
- 來源衝突時，明說「採用了哪一個、捨棄了哪一個、為什麼」。

# 回饋（讓更正變成規則）
- 若使用者更正你，將更正濃縮成一條可重用規則，
  輸出在 <new_rule> ... </new_rule> 標籤中，
  以便寫回規則庫，下次自動生效。

小提醒：上面的 {{變數}} 請替換成你實際的工作流、負責人與來源標籤。權限與來源階層最好同時用「系統層的存取控制」雙重把關，不要只靠這段文字。

選擇一個使用頻率高、失效點明確的工作流，先完整跑過六個階段一次，再擴展到其他工作流。