使用場景
AI 為你的團隊做什麼，哪些仍由人來確認。
在下面找到你的團隊。每張卡用三行概括一篇部落格上的完整場景：現在的工作怎麼做；業務物件、規則和工具定義好之後，AI 接手什麼；哪些動作仍由人決定——權限與審計由執行環境強制執行，而不是靠提示詞。
- 6 個團隊
- 銷售、客服、財務與採購、人事、法務與合規、專案
- 10 個場景
- 每個都在部落格上有完整文章，八種語言
- 7 個模板
- 其中七個場景有可 fork 的起步應用
每個場景跑起來之前需要什麼： 平台即可需要接現有系統需要先寫清制度
怎麼讀一張卡
三行，每個場景都一樣
卡片刻意寫得短。每張卡背後的完整文章寫明物件、規則和第一版怎麼搭；有模板的場景，模板就是你可以安裝或 fork 的應用。
- 現在：工作卡在哪裡，為什麼一張表單或一個佇列不夠。
- 有了 AI：把工作建模之後，應用能做什麼——讀取、分類、起草、核對、提出建議。
- 由人確認：哪些仍是人的決定，執行環境在它周圍強制執行什麼。
- Agent 以登入使用者身份執行，不超出該使用者的權限；它讀取和改動的記錄都寫入審計日誌，在 Enterprise 版中，介面內 AI 的每一次工具呼叫也會被審計。
銷售
從對話裡更新 CRM
銷售推進發生在會議、郵件和筆記裡。記錄應該跟著這些發生，而不是等銷售事後再填。
AI 銷售助理
需要接現有系統
- 現在
- 銷售在事情辦完之後才去填 CRM 欄位，真正的上下文留在會議、郵件、筆記和跟進承諾里。
- 有了 AI
- 銷售用語音或文字更新進展。AI 整理會議紀要、識別下一步動作、提示商機風險、建議階段變更，併為下一次客戶會議做準備。
- 由人確認
- 每條 CRM 變更建議由銷售本人確認，面向客戶的承諾需要確認。風險規則和審批邊界由主管設定。
客服
在排隊之前讀懂客戶的問題
客服工作充滿語言、判斷和重複決策：適合讓 AI 起草，由人決定發出什麼。
AI 工單中樞
需要接現有系統
- 現在
- 一封長郵件或一段不滿的對話變成一條記錄，然後等人去讀、分類、查資料、回覆和升級。
- 有了 AI
- AI 識別問題型別、緊急程度和客戶情緒，匹配知識庫，起草帶引用的回覆，並按 SLA 給工單排序。
- 由人確認
- 回覆草稿、分派和工單更新由客服確認。退款、補償和合同承諾類回覆可設為須主管審批後才能發出；升級任務只在權限校驗通過後建立。
財務與採購
帶著證據判斷每一筆支出
識別發票是最容易的一步。決定需要政策、預算、歷史記錄，以及一條說得清理由的審批鏈。
AI 報銷稽核
需要接現有系統
- 現在
- OCR 能把欄位填上，但報銷是否合規、是否在預算內、是否與專案相關、有沒有重複，財務仍要人工判斷。
- 有了 AI
- AI 提取票據資訊，核對政策、預算、專案和重複發票，排出今天優先要審的報銷單，並給出每條發現依據的政策條款。
- 由人確認
- AI 只給建議；付款審批走清晰的授權鏈，高風險報銷轉財務複核，複核人的修正會被記錄。
AI 採購風險
需要接現有系統
- 現在
- 供應商風險分散在多個系統裡：資質快到期、交付變慢、報價異常、合同缺口、質量退貨。
- 有了 AI
- 下單之前，AI 核對資質和交付表現，把報價與歷史對比，列出質量和合同問題，並建議替代方案。
- 由人確認
- AI 不替你做採購決定：採購在看到風險說明之後再審批，複核結果迴流到供應商管理。
人事與員工服務
讓員工直接問，再走對的流程
員工不會按系統分類思考。服務中心應該先理解請求，再安全地分派下去。
法務與合規
先標出風險，再由負責人簽字
合同和制度都是密集的文本。AI 可以先讀、先起草發現；責任仍在法務和控制負責人身上。
AI 合同審查
需要先寫清制度
- 現在
- 合同臺賬有人管，審查卻沒有：風險留在附件和批註裡，審批人看到的上下文太少。
- 有了 AI
- AI 提取簽約方、金額、期限和非標準條款，與標準模板對比，把偏離變成風險記錄。
- 由人確認
- 每條發現由法務確認或修改，最終意見歸法務。高風險發現進入審批，已簽署的義務變成跟進任務。
AI 內控檢查
需要接現有系統
- 現在
- 合規團隊要手工把制度條文和散落在 IAM、合同、採購、日誌、流程系統和表格裡的證據對上。
- 有了 AI
- AI 把制度拆成控制項，匹配證據，解釋為什麼某個缺口是高風險，並建議整改任務。
- 由人確認
- 高風險發現和證據要求由責任人確認；整改及其確認都留在審計歷史裡。
專案
在進度更新裡看到延期，而不是等到錯過日期
專案風險很少自己報到。它早在里程碑滑期之前，就以零散的隻言片語出現。
AI 專案管理助手
需要先寫清制度
- 現在
- 風險藏在會議紀要、任務更新、週報、變更請求和資源溝通裡，直到里程碑滑期才被看見。
- 有了 AI
- AI 把紀要關聯到任務和里程碑，識別阻塞、依賴和資源衝突，建立帶建議動作的風險記錄，並回答專案健康度問題。
- 由人確認
- AI 負責發現和解釋；承諾仍由人決定。經理把接受的風險轉成行動計劃；可以設規則讓範圍變更先做影響評估。
跨團隊通用
任何團隊都能複用的兩種模式
它們不屬於某一個團隊：一個內容工作流，一個通用的 Agent 工作臺，同樣守著「建議」與「執行」之間那條線。
AI 內容工作臺
需要接現有系統
- 現在
- AI 也許能讓一篇草稿寫得更快，但選題、素材、評審意見、釋出排期和覆盤仍然散落各處。
- 有了 AI
- AI 把素材聚成選題，寫出帶受眾和論據的簡報，標出缺少支撐的說法，並在釋出後總結表現。
- 由人確認
- 草稿釋出前流轉到品牌、產品、法務或客戶成功評審；評審意見和審批都是結構化記錄。
AI Agent 工作臺
需要先寫清制度
- 現在
- 助手回答了問題，使用者卻還得開啟業務系統去建任務、發起審批、更新記錄、留下審計痕跡。
- 有了 AI
- Agent 把目標變成一份看得見的執行計劃，再呼叫受治理的工具：查詢記錄、建立任務、發起審批、生成報告。
- 由人確認
- 查詢資料前先校驗使用者權限，建立任務前先請求確認，高風險動作停在流程審批節點等人決定，它讀取和改動的記錄都寫入審計日誌。
共同的邊界
AI 可以自己做什麼，什麼要等人確認
| 動作型別 | 場景裡的例子 | 會發生什麼 |
|---|---|---|
| 自動執行 | 摘要、分類、起草、內部提醒、風險提示、報表 | AI 直接完成，結果可見並被記錄 |
| 需要確認 | 建立任務、更新狀態、分派、業務記錄變更 | 使用應用的人確認之後才寫入 |
| 需要審批 | 面向客戶的承諾、資金動作、合同條款、權限變更、資料匯出、審計關閉 | 由審批人決定；未經審批，執行環境不會執行 |
FAQ
常見問題
這些是客戶案例嗎？
不是。每張卡概括部落格上的一篇場景文章：一個團隊的工作如何在 ObjectOS 應用裡建模並受治理。它們都不是某個具名客戶的報告。
必須從模板開始嗎？
不必。其中七個場景有對應模板，可以安裝或 fork；其餘場景從一段對工作的描述開始。兩條路得到的是同一種應用：可以由人審閱的物件、權限、流程和 Agent 工具。
誰來決定 AI 可以自己做什麼？
你的團隊，在應用的定義裡決定：哪些動作自動執行，哪些需要確認，哪些需要審批。執行環境對人和 Agent 同等強制執行這條邊界；Agent 以登入使用者身份執行，沒有特權 AI 身份。
下一步