使用 Okou 建立工作流程指示

你不需要從空白頁開始撰寫工作流程指示。先和你的代理程式一起完成一項真實任務。等結果有用之後，再請代理程式把你們共同開發出的方法整理成可重複使用的工作流程。

由智能體產生第一版草稿。你的角色是檢視它的假設，並判斷工作流程在哪些地方需要更清楚的限制，讓其他隊友也能得到可靠的結果。

在 My Okou 中，個人指示（Instructions）承載每位成員的偏好；工作區工作流程承載可重複的程序與團隊標準。私人工作流程屬於目前使用者，公開工作流程則在工作區內共享。執行時會使用執行成員自己的個人指示（Instructions）、記憶、帳戶與權限。在 Legacy Agents 中，工作流程仍然附加於單一代理程式。請參閱 Instructions and experience modes。

從一次成功執行開始

在智能體已經看過這項任務、來源素材、你的回饋以及可接受結果之後，建立工作流程會更容易。

1. 給智能體一個真實任務，以及它實際需要的輸入。
2. 檢視結果，並修正缺少的脈絡、薄弱的推理或錯誤的格式。
3. 當結果夠好時，請智能體萃取可重複的方法。
4. 讓智能體起草工作流程名稱、描述、指示，以及它建議的任何參考檔案。
5. 在正式公開工作流程之前，先一起檢視草稿。

你可以這樣問：

把我們剛剛做的事情整理成一個團隊可重複使用的工作流程。請起草名稱、描述和指示。把可重複的方法和只適用於這個案例的細節分開。在我們定稿之前，先列出我需要檢視的假設與限制。

這讓智能體負責起草，也讓你負責決定哪些部分必須被控制。

指示是放置限制的常見位置

工作流程指示會隨著工作流程一起流轉，並在每次執行時套用。這使它成為定義限制的最常見位置之一，例如必要輸入、核准來源、輸出格式、品質標準，以及需要確認的動作。

但它不是唯一的控制層：

不要把指示文字當成存取控制的替代品。如果某項動作在技術上必須被限制，請同時使用實際的連接器授權與已命名權限，以及清楚的指示。

檢視智能體的第一版草稿

你不需要重寫每一句話。把檢視重點放在對團隊重要的決策上。

什麼時候應該使用它？

• 哪種請求或情境應該選用此工作流程？
• 什麼情況下智能體不應使用它？
• 描述是否已足夠具體，能與相似的工作流程區分開來？

需要哪些輸入？

• 隊友在工作開始前必須提供什麼？
• 哪些缺少的輸入應該讓智能體提出問題？
• 哪些細節屬於每次執行，而不是永久性的指示？

哪些來源與規則優先？

• 哪一個是記錄系統？
• 哪個附加檔案包含已核准的評分準則或範本？
• 如果兩個來源衝突，哪一個優先？
• 智能體應該如何標示它無法驗證的事實？

輸出應該長什麼樣子？

• 需要哪些區段或欄位？
• 什麼程度的細節才有用？
• 輸出是否需要引用、連結或信心標籤？
• 如果提供了目的地，結果應該送到哪裡？

智能體必須在哪裡停下？

• 哪些動作需要確認？
• 智能體應該建立草稿，而不是送出或發布嗎？
• 哪些資料不應出現在公開的工作流程或共享結果中？

這些就是值得明確寫出的限制。讓智能體負責措辭，然後確認這些措辭反映了你的決定。

一個適合一起檢視的結構

智能體可以使用以下結構作為第一版草稿。把它當作檢視框架，而不是你必須自己填寫的表單：

# Goal
State the single outcome this workflow must produce.

# Use this workflow when
Describe when to use it and any important exclusions.

# Required inputs
- List the information needed for a reliable result.
- Explain what to do when an input is missing.

# Sources and tools
- Name authoritative systems, documents, or attached files.
- Explain which source wins if information conflicts.
- Define how to handle facts that cannot be verified.

# Procedure
1. Verify the inputs and scope.
2. Gather the required evidence.
3. Apply the team's rules or rubric.
4. Produce the deliverable.
5. Check it against the quality bar.

# Output
Define the required sections, fields, format, and destination.

# Quality bar
- State what must be accurate, cited, complete, or consistent.
- Define what counts as done.

# Approval boundaries
- List actions that require confirmation.
- Specify when to create a draft instead of taking the final action.

簡單的工作流程可能只需要少數幾個區段。高風險的工作流程可能需要更明確的來源、驗證與核准規則。請智能體把指示寫得盡可能簡短，但不要隱藏團隊所依賴的任何決策。

範例：共同建立潛在客戶資格判定工作流程

假設你請智能體研究一個進站潛在客戶並草擬回覆。在執行過程中，你更正了公司規模，說明 CRM 是記錄系統，套用團隊的 ICP 評分準則，並要求電子郵件更精簡。

在結果獲得核准後，請智能體把這段對話轉成工作流程。智能體會起草程序。接著你加入那些應該延續到這個潛在客戶之外的限制：

• 在進行公開研究之前先檢查 CRM；
• 使用附加的 ICP 評分準則來評分；
• 為公司規模、所在地與目前職位引用來源；
• 將未驗證但必要的事實標記為 Unknown；
• 回傳 Account summary、Evidence、ICP score、Risks、Recommended next step 與 Reply draft；
• 建立電子郵件草稿，且未經確認絕不送出。

現在智能體可以把這些決定納入指示中。你不需要規定每一步研究流程。你需要讓團隊的來源、輸出契約與核准邊界變得明確無歧義。

用平實語言給出限制回饋

你可以透過告訴智能體哪些地方必須改變，來收緊草稿：

• 「如果 CRM 記錄缺失，請在開始前先要求提供。」
• 「當公司名稱衝突時，請把 CRM 視為記錄系統。」
• 「簡報中的每一項事實主張都需要來源連結。」
• 「把回覆控制在 150 字以內，但要根據進站訊息調整語氣。」
• 「把電子郵件建立為草稿。絕不要自動送出。」
• 「這個工作流程不應套用於既有商機。」

請智能體更新工作流程，並摘要說明每一項變更對應了哪個限制。這樣更容易找出被誤解或放在錯誤區段的規則。

把對的內容留在指示之外

有些資訊不應變成永久性的工作流程文字：

• 客戶名稱、一次性截止時間與特定案例的目的地，應該放在執行請求中；
• 密碼、權杖與私人憑證不應放在指示或附加檔案中；
• 排程與事件應屬於 自動化；
• 技術存取邊界應屬於連接器授權與已命名權限；
• 只適用於單一結果的個人回饋可以留在那個聊天中。

指示應承載可重複使用的方法與行為限制，而不是工作的每一個周邊細節。

一起測試並精煉

請用至少兩個真實情境執行工作流程，最好再找第二位隊友一起測試。每次執行後，詢問：

• 工作流程是否在正確的任務上啟動？
• 它是否請求了所需的輸入？
• 它是否遵循了預定的來源優先順序？
• 輸出是否一致，但又不會過於僵化？
• 它是否在要求的核准邊界處停止？
• 這個問題是否可重複，還是只適用於這個案例？

請智能體修訂指示，以補上可重複出現的缺口。把一次性的修正留在執行中。當這個方法對原始建立者以外的人也有效時，請 與你的團隊共享工作流程。