從 Slack 派發編碼任務
說明如何從 Slack thread 啟動 Codex cloud task，並把結果帶回執行緒或 Codex cloud 審查。
當一個 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 里的复现路径。