Appearance
29 · Slack / Linear 与 SDK 集成：在别处召唤 Codex，把它嵌进你自己的产品
前面都是在 Codex 里用 Codex。 这一篇讲把 Codex 放到别的地方：Slack、Linear，甚至你自己的程序里。
普通人先别急着写 SDK。 先分清两种层次。
先选零代码召唤，再考虑 SDK
大多数普通人不需要一上来写 SDK。 你可以按这个顺序来：
- 先用 Slack、Linear 这类工具里的提醒和消息。
- 再用现成的插件或连接器。
- 最后才考虑 SDK，把 Codex 接进自己的产品。
先把流程跑通，比先把技术栈想复杂更重要。
第一次练习：只在别处召唤一次
不要第一次就写 SDK。 先选一个你已经在用的工具，比如 Slack 或 Linear。
练习任务可以很小：
text
请总结这个 issue / PR 的核心问题。
只做总结，不修改代码，不关闭 issue，不发送额外通知。
最后列出我需要确认的 3 件事。先验证“能不能在别处叫它干一件小事”。 这一步跑通后，再考虑更深的集成。
01 先分清两个层次：零代码“召唤”，还是写代码“嵌入”
两种方式：
- 零代码召唤：在 Slack、Linear 里 @ Codex。
- 写代码嵌入：用 SDK 把 Codex 接进自己的产品。
小白先从零代码召唤开始。 SDK 属于开发者进阶。
02 在 Slack 里召唤：@Codex 一句话派活
设置：三步接上
一般是：
- 安装或授权。
- 选择工作区和仓库。
- 确认权限。
设置类动作建议你自己点，Codex 只做说明。
用法：@ 它，说需求
比如：
text
@Codex 请检查这个 PR 是否有明显风险，并总结需要我确认的地方。它怎么自己挑环境和仓库
要写清楚仓库和任务。 不要只说“帮我看看”。
Enterprise 数据管控：答复要不要带“干活内容”
团队环境会涉及数据管控。 是否展示细节，要听公司策略。
动手：几分钟在 Slack 里跑通一次
练习建议：只让它总结公开 PR，不要处理私人数据。
03 在 Linear 里召唤：把 issue 直接派给 Codex
设置：三步
- 授权 Linear。
- 连接仓库或项目。
- 确认权限范围。
两种派活姿势
一种是在 issue 里直接指派。 一种是通过评论或命令让 Codex 接手。
自动派单：triage 规则
自动派单适合团队。 个人项目先手动更稳。
还有一条岔路：Linear MCP（给本地 Codex 用）
如果你想在本地 Codex 里读 Linear 数据，可能走 MCP。 这和 Linear 里直接召唤 Codex 是两条路。
04 Codex SDK：写代码把 Codex 嵌进自己的程序
两套语言：TypeScript 和 Python
SDK 适合你有自己的产品或工具。
最小代码长啥样
新手先不要急着写。 先问：
text
请用小白能懂的话解释 Codex SDK 最小程序由哪些部分组成。
不要写复杂工程。SDK 和 codex exec 到底差在哪
简单理解：
codex exec：命令行里跑任务。- SDK：在你自己的程序里调用能力。
05 App Server：做深度集成才轮到它
App Server 更偏深度集成。 普通教程网站当前不需要。
先知道有这个层级就够。
06 动手：5 分钟跑一个最小 SDK 程序
如果后面要做小工具，可以再学。
练习目标应该很小：
- 输入一句话。
- 调用 Codex。
- 输出结果。
- 不接真实业务数据。
07 这几样到底该用哪个：对号入座
| 需求 | 选择 |
|---|---|
| 在团队聊天里派活 | Slack |
| 让 issue 变成任务 | Linear |
| 在本地脚本跑一次 | codex exec |
| 嵌进自己的产品 | SDK |
| 深度平台集成 | App Server |
08 小结
集成不是越深越好。
你当前阶段最适合：
- 先把网站内容做扎实。
- 后面再用 GitHub / Slack / Linear 做协作。
- 真要做产品时，再考虑 SDK。