挫折
每次 Claude Code 完成一項建構，我都有同樣的體驗。程式碼能用。功能在那裡。但我完全不知道到底發生了什麼。
它先讀了哪些檔案？過程中做了什麼決策？總共有幾個步驟？它有沒有嘗試某件事、失敗了、然後再試一次？唯一的辦法就是翻閱長長的聊天記錄。那不是流程。那是考古學。
更大的問題是：跟上次有什麼不同？我昨天跑了同類型的工作流程。今天更快嗎？跳過了某一步嗎？花更多錢了嗎？沒有比較兩次執行的方法，我就是在盲飛。
我真正想要的
我要的東西很具體。AI 完成的那一刻，我想看到：
- 發生了什麼 — 每一步，按順序，附帶時間。
- 改了什麼 — 與上次執行的 diff。什麼變快了、什麼變慢了、什麼壞掉了。
- 誰參與了 — 哪些步驟完全由 AI 自動化，哪些需要人類決策。
而且關鍵是：它必須讓非工程師也能讀懂。我的 PM 應該能看一眼就理解工作流程，不需要讀程式碼。
所以我做了 osop diff
我做的第一個東西不是規格書或標準。而是一個 diff 工具。餵它兩份執行記錄，它一目了然地顯示所有資訊：
$ osop diff monday.osoplog.yaml tuesday.osoplog.yaml Workflow: feature-build Run A: Mon Apr 1 | Run B: Tue Apr 2 Node | Duration | Cost | Status ───────────────────────────────────────────────────────────── plan | 2.1s → 1.8s | $0.02 → $0.01 | same explore_code | 12s → 5.2s | $0.08 → $0.03 | same implement | 45s → 32s | $0.15 → $0.12 | same type_check | 3.2s → 3.1s | — | same human_review | 120s → 60s | — | same ───────────────────────────────────────────────────────────── Total | 182s → 102s | $0.25 → $0.16 | -44% faster
逐步的時間變化。成本變化。狀態變化。新增或移除的節點。哪些步驟需要 AI、哪些需要人類。一個指令、一張表格、完全清晰。
這解決了我個人的問題。但接下來發生了意想不到的事。
其他公司也有同樣的問題
我開始為其他團隊提供諮詢 — 幫他們規劃 SOP、標準化流程、搞清楚 AI 在他們的工作流程中該放在哪裡。每一個團隊都有同樣的挫折，而且更嚴重。
他們的工作流程被困在特定工具裡。一個團隊用 LangChain，另一個用 n8n，第三個把一切都寫在自訂 Python 腳本裡。什麼都不可移植。你無法從一個工具拿出工作流程，交給另一個使用不同工具的團隊，然後期望它直接能用。
即使在同一個團隊內，比較同一流程的兩次執行也很痛苦。每個人都有自己的日誌格式。沒有標準的方式來說：這是我們計畫的、這是實際發生的、這是週二和週三之間的差異。
從個人工具到通用協定
那時我才意識到：diff 工具只有在執行記錄採用標準格式時才有用。而記錄只有在工作流程定義也標準化時才有用。所以我兩個都定義了。
.osop — 一個描述該發生什麼的 YAML 檔案。節點（有哪些步驟）、邊（它們如何連接）、安全性中繼資料（哪些步驟有風險）、人類閘門（哪些步驟需要核准）。
.osoplog — 一個記錄實際發生了什麼的 YAML 檔案。時間戳記、持續時間、工具呼叫、使用的 AI 模型、消耗的 Token、人類決策、錯誤狀態。
兩個檔案。一種格式。任何工具都能讀取。任何工具都能寫入。任何人 — 工程師或非工程師 — 都能 diff 兩份日誌，精確看到什麼改變了。
現在的狀態
OSOP 現在擁有完整的 CLI（9 個指令）、87 個工作流程範例、6 種格式的轉換器（GitHub Actions、Airflow、n8n 等）、視覺化編輯器、MCP 伺服器，以及 18 個 AI 程式平台的整合。
但我每天都在用的功能仍然是 osop diff。它是系統中最簡單的東西，也是解決最初問題的那個：AI 完成的那一刻，我就知道它到底做了什麼。
試試看
如果你使用 AI 程式 Agent，而且曾經想過「到底剛才發生了什麼」，這就是 OSOP 要解決的問題。整個系統是開源的（Apache 2.0）。從 osop init 開始建立工作流程，或直接用兩份執行日誌跳到 osop diff。
使命從第一天起就沒變過：AI 完成的那一刻，你應該確切知道它做了什麼。其他一切都從這裡生長出來。