我要向你示範，如何把散落在團隊工具與工作流程之間的模型、Agent、技能與自動化，整合成一套協同運作的系統。
現今大多數團隊的狀況截然不同。他們的模型、技能與自動化，散落在不同的工具、私人對話與個人設定之中。
每個人都必須把自己知道的知識和工作方式，教給他們的 AI。他們建立的上下文、修正與工作流程，幾乎無法傳遞給其他人。
一個人把最新策略交代給 Claude；另一個人請 Codex 去翻找舊資料夾；第三個人則憑記憶重建一套實用的工作流程。每一段對話裡，都藏著一個略有不同的公司樣貌。
我們用 HQ 打造了這個共享層。它位於 Claude Code、Codex、Cursor，或你的團隊所選擇的任何開源模型之下，在這些工具之間傳遞公司的上下文與能力。
我們來實際打造一個吧。
我們先從一個每週情報 Worker 開始。它在週一上線時，就已經知道本週發生了哪些變化：哪些決策已經拍板、哪些專案有了進展、哪些風險變得更高，以及團隊接下來承諾要做什麼。
到最後，你的團隊將擁有：
- 一個所有 Agent 都能取得目前公司上下文的單一位置；
- 一套不會因新對話或模型更換而失效的運作規則；
- 一個團隊中任何人都能執行的每週情報 Worker；
- 一套會隨著團隊使用而持續進步的共享技能與自動化；
- 一套複盤與同步迴圈，能把一個人的改進，變成團隊新的起點。
不要一開始就試圖盤點整個公司的所有環節。先在一個可重複的工作流程上驗證這套框架，然後每當團隊發現另一個值得分享的流程時，再逐步擴展。
1. 建立環繞模型的環境
模型可以推理、寫作、呼叫工具。它仍然需要一個能夠說明公司內部工作方式的環境。
一套實用的框架，必須能回答五個問題：
- AI 知道什麼？
- 它如何找到相關的上下文？
- 它必須遵守哪些規則？
- 它能執行哪些可重複的工作？
- 每次執行如何改善下一次執行？
一段很長的系統提示詞，或許能在單一會話中回答其中部分問題。而公司的框架，能讓這些答案變得結構化、持久化，並開放給所有人使用。
知識可以被搜尋；規則不會因為對話結束而失效；工具有明確的邊界；工作會留下產出物。被認可的工作流程會變成可重複使用的資產，而不是隨著對話關閉而消失。
這就是為什麼同一個模型，在兩家公司會給人截然不同的感受。模型或許完全相同，但工作環境截然不同。
模型提供智慧，框架承載公司。
2. 在一個真實工作流程上驗證框架
如果一開始就想把整個公司建模，你很可能會花上好幾週整理上下文，最後卻沒有任何證據證明這套框架真的改善了任何一項工作。
請從一個具備四項特性的工作流程開始：
- 它經常發生；
- 界線明確；
- 依賴公司上下文；
- 人類可以快速判斷結果品質。
每週公司情報簡報就很符合這些條件。
所需的輸入資料其實都已經存在，只是散落在會議紀錄、專案檔案、決策文件，以及人們的腦海裡。產出對整個團隊都有價值，而且創辦人一眼就能看出簡報是否準確。
在建立 Worker 之前，先把契約定義清楚。
輸入
- 過去 7 天的會議
- 目前的專案狀態
- 決策、承諾與待解決的問題
- 風險與受阻的工作
流程
- 擷取相關來源
- 驗證每一項事實陳述
- 揭露矛盾與遺漏的資訊
- 綜整公司層級的變化
輸出
- 已做出的決策
- 各專案進度
- 風險與阻礙
- 下週的承諾事項
- 來源清單
邊界
- 僅限草稿
- 發布前停下，交給人工審閱
如果這個工作流程每次由不同人執行時，做法都會變來變去，那就先維持手動執行。一個流程應該先變得可重複，才有資格成為共享基礎設施。
3. 給 AI 持久化的公司記憶
先從目前的 HQ 引導式設定 開始。安裝 HQ、建立公司工作區，然後在團隊原本就在使用的 AI 工具中，把 HQ 設為目前的工作目錄。
開源快速入門 只需要一行指令：
npx create-hq
現在，只要加入這份每週簡報所需的上下文就好。
先從這個結構開始：
- HQ
- companies
- your-company
- company-brief.md
- knowledge: decisions and playbooks
- sources: meetings
- signals
- people
- projects
- policies: weekly-intelligence.md
- workers: weekly-intelligence
從這個基礎開始，只在真實工作流程有需求時，才逐步加入更深層的知識、技能、自動化，以及公司專屬的 Worker。
公司簡報說明這家公司做什麼、如何獲利，以及當下最重要的事。專案紀錄目前的狀態；決策保存了團隊當初選擇某條路線的原因；成員檔案則讓每個項目的負責人一目了然。
會議情報會捕捉那些從未進入正式文件的承諾、風險、問題與決策。
不要把整個公司都塞進每一次的提示詞裡。HQ 的章程會給 Agent 一張地圖，標明知識、政策、專案與 Worker 分別存放在哪裡。Agent 沿著這張地圖，去擷取完成任務所需的更深層來源。
給 Agent 一個小而穩定的入口，並在需要時才提供更深層的上下文。
如此一來，公司記憶隨時可用，又不會在開始工作前就把上下文視窗消耗殆盡。
4. 把公司的判斷變成政策
知識告訴 Worker 發生了什麼事；政策則告訴它，你的公司希望這項工作如何被處理。
建立 companies/your-company/policies/weekly-intelligence.md：
每週情報政策
- 每一項事實陳述，都要有來源支持。
- 揭露互相矛盾的證據，絕不擅自私下定奪。
- 依照來源原本的緊急程度回報風險。
- 標記缺失、過時或不確定的資訊。
- 絕不包含機密或跨公司上下文。
- 發布前停下，取得人工核准。
第一版政策請保持精簡，讓團隊願意持續維護它。
控制機制分為三個層級：
- 指令：要求 Agent 遵循某種偏好。
- 政策：讓規則在跨會話、跨人之間持續有效。
- Hook 或機制性檢查：在失敗代價高昂時，直接攔截該行為。
「註明來源」可以從政策做起；而「未經核准絕不發送」則值得在行為邊界上強制執行。
不要試圖窮舉所有可能的行為。只需寫下少數幾個無論更換任何模型、成員或專案，都必須維持不變的原則就好。
5. 把工作流程打包成共享 Worker
接下來，把通過驗證的流程變成可重複使用的 HQ Worker。
執行 /newworker，然後交給它一個範圍明確的任務。「什麼都能做的公司分析師」聽起來很有用，但其實難以測試、也容易被誤用。每週情報 Worker 則有清楚的輸入、輸出與停止條件。
Worker 規格：
名稱： weekly-intelligence
目的： 產出一份附有來源、供人工審閱的每週公司簡報。
允許的來源
- 公司簡報
- 過去 7 天的會議
- 目前的專案
- 決策與承諾
流程
- 確認回報期間。
- 擷取允許的來源。
- 提取決策、進度、風險與承諾。
- 對照來源資料驗證每一項陳述。
- 標記矛盾、缺口與過時資訊。
- 依照要求的格式撰寫簡報。
必要輸出
- 執行摘要
- 已做出的決策
- 專案進展
- 風險與阻礙
- 下週承諾事項
- 未解決的問題
- 來源清單
絕不
- 捏造缺失的事實
- 讀取其他公司的上下文
- 洩漏機密
- 發送或發布簡報
完成條件： 每一項陳述都有來源支持、或已標註為不確定，而且草稿已準備好交給人工審閱。
公司的知識提供事實，政策提供判斷，Worker 則提供可重複執行的步驟。
一段提示詞只能產出一份有用的簡報；一個 Worker 則能讓另一位同事在下週五也能使用同一套方法。
6. 讓每一次修正都持續改善框架
不要把第一次成功執行，當作已經完工的基礎設施。
執行 Worker、審閱簡報，然後在正確的層級上診斷每一項修正。
- 事實缺失 → 改善公司知識。
- 上下文錯誤 → 改善路由與資源描述。
- 重複出錯 → 改善 Worker 的技能。
- 行為不安全 → 改善政策或 Hook。
- 成果品質不佳 → 改善輸出契約。
- 資訊過時 → 改善知識養護流程。
如果 Worker 漏掉某個決策，是因為會議內容根本沒有被記錄，那麼重寫提示詞也修不好系統。你該改善的是知識路徑。
如果它老是讓風險被埋在瑣碎的更新事項底下，那就把輸出契約寫得更明確。
如果有人要求它在沒有核准的情況下發布簡報，那就加強政策與行為閘門。
真正有用的問題是：環境的哪一部分，允許了這個錯誤發生？
修好那個層級，然後重新執行同一個案例。這項修正應該要比最初暴露問題的輸出活得更久、持續發揮作用。
這就是人類判斷力產生複利效應的方式。你只需要教系統一次，之後每一次執行都能沿用改善後的行為，而不必在私人對話中重複修正。
7. 讓框架在團隊每次使用時都變得更聰明
當簡報、政策與 Worker 都通過審閱之後，執行 /hq-sync。
這就是 HQ 成為「AI 多人協作」的地方。
業務團隊可以把客戶異議處理變成一個技能；客服團隊可以把升級通報規則寫成明確規範；營運團隊可以改善報表；工程團隊可以加入審查關卡。
每一項貢獻只要通過審閱，就會同步到 Main，成為公司共享框架的一部分。
下一位同事會直接繼承公司已經驗證過的上下文、規則、技能、Worker 與自動化。他們不需要原始對話或提示詞。
他們只要在慣用的 AI 工具中打開 HQ，就能從改進後的版本繼續往下做。
這就是 HQ 的複利迴圈：使用框架、改進某個層級、審閱、同步，然後拉高每個人的起點。
底層模型可以是 Claude、Codex、ChatGPT，或任何開源模型；而在模型之下，公司層會持續累積智慧、變得越來越聰明。
公司之間的隔離原則仍然適用。同步不應該抹平不同租戶之間的界線、繞過權限，或把機密放進共享檔案。一套共享框架，只有在「共享」的界線保持明確時，才能真正運作。
共享學習也提高了風險。一句鬆散的指令，現在可能影響到所有人，所以請把 Main 當作正式環境（production）來對待。
同步之前，先審閱每一項貢獻。保持政策範圍精簡。用真實案例測試 Worker。隨著系統規模成長，請使用 /harness-audit 檢查上下文效率、品質關卡、持久化、搜尋與安全性。
任何改變只要通過審閱，就同步它。接著，挑選下一個可重複的工作流程，再次提升共享基準線。
完整的進展路徑是：
記憶 → 上下文 → 政策 → Worker → 審閱 → 團隊預設
這週就從一個固定會重複出現的工作開始。定義它的輸入、輸出與核准邊界。先手動執行、修正，再把通過驗證的方法，變成團隊可以共享的 Worker。
模型會持續更迭，但貴公司的記憶、規則與最佳工作方式，不應該跟著一起歸零。
如果你想為自己的團隊建立一套共享框架，歡迎試試 HQ。
歡迎追蹤 @VibeMarketer_ 獲取更多內容。感謝你的閱讀 :)
