從 Slack 派發編碼任務

📖 本篇術語速查表

英文 / 縮寫	中文	一句話解釋
Slack 派發	dispatch	在 Slack 裡把編碼任務交給 Codex。
任務邊界	task scope	適合從 Slack 派的任務範圍。
許可權範圍	who can	誰能從 Slack 觸發任務。

不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你規劃從 Slack 派發編碼任務給 Codex（適合什麼、誰能派、怎麼寫）。

你是 Codex Slack 派發規劃顧問，幫我規劃從 Slack 把合適的編碼任務安全地派給 Codex。

【角色】
你知道哪些編碼任務適合從 Slack 派、誰能觸發、Slack 裡任務怎麼寫清、不適合的任務該引去哪。

【輸入】
- 我想從 Slack 派的任務型別：___
- 團隊誰能觸發：___
- 任務會改程式碼還是隻查 / 只讀：___
- 安全 / 許可權要求：___

【工作流程】
1. 區分適合和不適合從 Slack 派的任務
2. 定誰能觸發、許可權邊界
3. 給 Slack 裡寫清任務的方式
4. 複雜任務引導到合適入口

【輸出規範】
▌一、適合 / 不適合從 Slack 派的任務
▌二、觸發許可權邊界
▌三、Slack 任務寫法
▌四、複雜任務的引導

【硬約束】
- 限定誰能觸發，高風險操作不向全員開放
- 複雜任務別塞一句訊息，引去合適入口
- 頻道敏感資訊不外洩
- 改程式碼的派發限定範圍 + 審查
- 不確定的機制標註需查官方文件

當一個 Slack thread 已經有足夠上下文，可以直接讓 @Codex 從執行緒裡啟動 cloud task。任務會繫結到正確 repo 和 environment，完成後你可以回到 Slack thread 或 Codex cloud 裡 review 結果。

官方頁面：https://developers.openai.com/codex/use-cases/slack-coding-tasks

Slack coding tasks

從 Slack thread 啟動 scoped cloud task。

Slack integration

安裝、連線 repo 和設定 Slack 入口。

Cloud environments

讓 Slack 任務繫結正確 repo 和執行環境。

適合什麼任務

場景	Codex 應該做什麼
async handoff 從 Slack thread 開始	用 thread context 啟動 scoped cloud task
需要 quick issue triage、bug fix、scoped implementation	避免切換工具，把任務直接從 Slack 交給 Codex
大型 codebase 裡任務範圍明確	prompt 裡點出相關 files/folders 和目標 environment

推薦執行環境：cloud。

相關官方說明：

Use Codex in Slack：https://developers.openai.com/codex/integrations/slack
Codex cloud environments：https://developers.openai.com/codex/cloud/environments

起始提示詞

在 Slack thread 裡 mention：

@Codex 請分析這個 thread 中提到的問題，並在 <name of your environment> 中實現修復。

關鍵是寫明 environment。否則 Codex 可能不知道應該在哪個 repo / cloud environment 裡開任務。

任務 brief 模板

Slack thread 往往噪音很多。真正派發給 Codex 的 message 最好用短 brief 收口：

@Codex 請基於本 thread 做一個 scoped cloud task。

Environment:
- <codex cloud environment name>

Repo / area:
- <repo name>
- <相關 folder / service / package>

Goal:
- <要修的問題或要實現的小功能>

Constraints:
- 不做 unrelated refactor
- 保持現有測試和介面行為
- 如果 thread 資訊不足，先在 task 裡列出缺口，不要猜測業務規則

Validation:
- 跑 <test / lint / build / manual check>
- 完成後給出 diff summary 和 remaining risk

這個模板比直接說“修一下上面的問題”穩定。它把 Slack 討論壓成 Codex cloud 能執行的環境、範圍、目標和驗證。

使用步驟

安裝 Slack app，連線正確 repositories 和 environments，並把 @Codex 加入 channel。
線上程裡 mention @Codex，寫清 request、constraints 和期望 outcome。
開啟 task link，review 結果。
如果還需要下一輪，繼續在 Slack thread 裡 follow up。

適合從 Slack 派發的任務

優先選擇能在一輪 cloud task 裡完成的事情：

任務型別	Slack 裡要補的關鍵資訊
bug triage	錯誤截圖、復現路徑、環境名、期望行為
小修復	相關資料夾、不要碰的模組、驗證命令
issue 轉程式碼	issue 連結、驗收標準、已有討論結論
文件更新	目標頁面、事實來源、是否需要構建
PR follow-up	PR 連結、review comment、允許改動範圍

不適合從 Slack 直接派發的是大方向產品討論、跨系統重構、缺少 owner 的需求、需要生產許可權的操作。Slack 是入口，不是需求治理系統。上下文不完整時，先讓 Codex 做分析報告，再由人決定是否進入實現。

實用建議

如果 thread 自己沒有足夠 context 或 suggested fix，在 prompt 裡補充 guidance。
用 project 或 environment name 明確 repo/environment mapping。
scope 要足夠窄，讓 Codex 不需要第二輪 planning loop 也能完成。
大型 codebase 裡，直接指出相關 files 或 folders。

Slack 入口適合啟動清晰的小任務，不適合把模糊產品討論直接變成大改動。

Review 結果

Codex 完成後，不要只看 Slack 摘要。商業專案裡至少檢查四件事：

task link 裡實際改了哪些檔案。
是否跑了 brief 裡指定的驗證命令。
是否有剩餘風險、失敗測試或無法確認的資訊。
follow-up 應該繼續在 Slack thread 裡追問，還是轉到 Codex cloud / GitHub PR 裡審查。

如果結果範圍跑偏，下一條 message 應該收窄，而不是繼續追加新需求：

@Codex 只保留這次 bug fix。不要繼續實現新功能。請撤回 unrelated changes，並只驗證原 thread 裡的復現路徑。