How to Build a Shared AI Harness for Your Team

Cover Image

原始來源與檔名：2026-08-11T094033+0800-How to Build a Shared AI Harness for Your Team.md

SOURCE | 資訊源評估

NAPKIN | 餐巾紙

餐巾紙公式

團隊 AI 效能 = 模型智力 (Model) × 企業環境 (Harness: 記憶 + 策略 + 工作者)

模型提供基礎的通用推理能力，而企業環境（Harness）提供專屬的業務上下文與規則，兩者結合才能發揮真正的商業價值。

一句話

不要讓員工各自訓練自己的 AI，應建立一個共享的「AI 基礎設施 (Harness)」，讓業務規則、上下文和改進經驗在全團隊中自動流轉與累積。

餐巾紙草圖

┌─────────────────────────────────
│        Shared AI Harness
│ 
│  ┌─ Memory (知識/專案/決策)
│  ├─ Policy (規則/邊界)
│  └─ Worker (可重複的工作流)
│       ▲
│       │ (Sync & Review)
│       ▼
│  Team Members (Claude/Codex...)
└─────────────────────────────────

ROUND 1: SKELETON | 骨架掃描

“這本書在說什麼”

章節骨架

  1. 環境建置: 模型只是引擎，需提供企業運行環境。
  2. 單點驗證: 從單一、高頻、邊界清晰的工作流開始。
  3. 持久記憶: 建立小而穩定的知識入口，按需深入。
  4. 策略編碼: 將企業判斷標準轉化為明確政策。
  5. 封裝工作: 將驗證過的工作流打包成可重用的 Worker。
  6. 根因修正: 在基礎層面修正錯誤，而非僅修改單次 Prompt。
  7. 團隊進化: 審查、同步，讓系統隨團隊使用不斷變聰明。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

論證鏈

┌──────────────────────────────────────────────────────────
│ 【前提】員工各自調教 AI 會導致知識不對稱與重複勞動
│    ▼
│ 【機制】需要一個獨立於模型的「環境層 (Harness)」儲存企業知識與規則
│    ▼
│ 【實踐】透過 HQ 建立資料夾結構 (HQ/companies/policies/workers)
│    ▼
│ 【進化】遇到問題時修改底層的 Knowledge 或 Policy，而非修改個人 Prompt
│    ▼
│ 【結論】團隊的 AI 基礎設施能持續沉澱最佳實踐，越用越聰明
└──────────────────────────────────────────────────────────

關鍵證據

  1. 現狀痛點：有人給 Claude 最新策略，有人叫 Codex 找舊資料，每個人對話框裡的「公司版本」都不同。
  2. 成功範例 (每週情報)：將散落的會議記錄、專案進度，透過一個明確的 weekly-intelligence 工作者，標準化產出供人類審查的報告。
  3. 糾錯模型：如果 AI 遺漏資訊，是因為知識庫沒更新；如果 AI 發布未審查內容，是因為缺乏 Policy 攔截。修正這些底層問題能一勞永逸。

隱形假設與邊界

ROUND 3: SOUL | 靈魂提取

“還能怎麼用”

留白提問 (Guided Reflection)

跨域映射

DEEP READ | 精讀指引 (Must-Read Segments)

[!IMPORTANT] 學習的本質需要「認知阻力」。請親自回到原文閱讀以下核心段落，感受原始論述的阻力，不要只依賴 AI 的總結。

  1. 1. Build the environment around the model
    • 「The model supplies intelligence. The harness supplies the company. (模型提供智力。基礎設施提供企業環境。)」
    • 推薦理由: 這句話是整篇文章的核心靈魂。它清晰地劃分了外部 AI 模型與企業內部資產的邊界，破除了「模型就是一切」的迷思。
  2. 6. Make every correction improve the harness
    • 「The useful question is: which part of the environment allowed this mistake? (有用的問題是：環境的哪個部分允許了這個錯誤發生？)」
    • 推薦理由: 這是一種深度的系統思考模式。將 AI 的錯誤視為系統環境的漏洞，教導讀者如何在正確的層次（知識、路由、技能、策略）進行糾錯，這是讓 AI 系統具備複利效應的關鍵。

STRUCTURE MAP | 全書結構圖

┌───────────────────────────────────────────────────
│ 1. 核心理念: Model (Intelligence) + Harness (Context)
│ 
│ 2. 實踐路徑:
│    ├─ MVP 驗證 (挑選清晰邊界的工作流，如周報)
│    ├─ 企業記憶 (建立結構化資料夾：知識、資源)
│    ├─ 策略編碼 (確立不可違背的 Policy)
│    └─ 封裝工作 (定義明確的 Worker Spec)
│ 
│ 3. 成長飛輪:
│    錯誤發生 ──▶ 診斷根本原因 (Knowledge/Policy/Worker) ──▶ 修正底層環境
│ 
│ 4. 團隊協作:
│    個人改進 ──▶ Review ──▶ Sync to Main ──▶ 提升全團隊起跑點
└───────────────────────────────────────────────────

How to Build a Shared AI Harness for Your Team (Architectural Deep Dive)

前言/背景

隨著 AI 工具（如 Claude, Codex）在企業中的普及，團隊常面臨「AI 孤島」現象：每個成員都在自己的對話框中獨立調教 AI，導致上下文碎片化、經驗無法傳承、產出標準不一。本文提出了一種名為「共享 AI 基礎設施 (Shared AI Harness)」的架構思維，旨在於底層大語言模型之上，建立一層專屬於企業的知識、策略與工作流抽象層，確保整個團隊能基於統一的上下文與規則來運用 AI，並透過持續的反饋迴圈讓該基礎設施不斷進化。

章節詳細總結

1. Build the environment around the model (圍繞模型建立環境)

模型本身只具備推理、寫作與呼叫工具的能力，它缺乏對特定公司運作方式的理解。一個有效的 Harness 必須結構化地回答五個問題：

  1. AI 知道什麼？
  2. 如何找到相關上下文？
  3. 必須遵循哪些規則？
  4. 能執行哪些可重複的工作？
  5. 每次執行如何改進下一次？

架構洞察在於：不要依賴超長的單次 System Prompt，而是建立持久化、可檢索的環境。「The model supplies intelligence. The harness supplies the company.（模型提供智力。基礎設施提供企業環境。）」相同的模型在不同公司表現各異，根本原因在於其掛載的工作環境不同。

2. Prove the harness on one real workflow (在單一真實工作流上驗證)

避免一開始就試圖將全公司數據導入系統，這會導致高昂的整合成本卻缺乏價值驗證 (MVP)。應選擇具備以下四個屬性的任務作為起點：高頻率、邊界清晰、依賴公司上下文、人類能快速判斷結果（例如：每週情報摘要）。

在實作 weekly-intelligence 前，必須先定義合約 (Contract)：

3. Give the AI durable company memory (賦予 AI 持久的企業記憶)

作者建議透過特定的資料夾與檔案結構來管理知識，並透過工具（如 HQ）掛載至 AI 工具中。初始的目錄結構範例如下：

架構決策 (Architectural Reasoning)：不要將整個公司的數據塞進每個 Prompt 中。Harness 的作用是提供一個「地圖」，讓 AI Agent 有一個小而穩定的入口，並根據任務按需檢索 (Retrieve on demand) 更深層的知識。這解決了 Context Window 限制並降低了運算成本。

4. Turn company judgment into policy (將企業判斷轉化為策略)

Knowledge 告訴 AI 發生了什麼，而 Policy (策略) 告訴 AI 公司期望如何處理工作。例如在 weekly-intelligence.md 中定義：

  1. 每一項事實主張都必須有來源支持。
  2. 揭露矛盾的證據，不要默默地自行解決。
  3. 標記遺漏、過時或不確定的資訊。
  4. 絕不包含機密或跨租戶 (cross-company) 上下文。
  5. 在發布前必須停下來等待人類批准。

控制機制分為三層級：

  1. Instruction (指令)：對話中的偏好。
  2. Policy (策略)：跨 Session 的持久規則。
  3. Hook (鉤子/機械攔截)：在動作邊界強制阻擋 (例如 API 發布前的強檢查)。

5. Package the workflow as a shared worker (將工作流封裝為共享 Worker)

將驗證過的 SOP 打包成可重複使用的元件 (Worker)。不要建立過於泛用的「全能分析師」，而是建立輸入/輸出明確的 Worker。 Worker Specification 包含：

6. Make every correction improve the harness (讓每次修正都改進基礎設施)

這是整個系統產生複利效應的關鍵。當 AI 產出不如預期時，不應只是在對話框中重寫 Prompt，而應將問題追溯到 Harness 的正確分層並進行修復：

核心思維是：尋找「是環境中的哪一部分允許了這個錯誤發生？」並從源頭修正。

7. Make the harness smarter every time the team uses it (讓系統隨團隊使用越來越聰明)

透過同步機制 (如 hq-sync)，團隊成員可以將自己驗證過的技能、Policy 或 Worker 同步到主線 (Main)，讓下一個使用者直接繼承這些改進，這將單人遊戲變成了「AI 多人連線遊戲」。 流程為：Memory → Context → Policy → Worker → Review → Team default。 注意：共享學習提高了風險，糟糕的指令會影響所有人，因此必須將 Main 視為生產環境 (Production)，嚴格執行 Review，並透過 audit 機制檢查安全性與上下文效率。

總結與結論