从 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 里的复现路径。