Codex Linear 集成：把 issue 转成可执行的代码任务

适用场景

这篇手册适合使用 Linear 管理需求和 bug 的团队。Linear 集成能把 issue 转成 Codex 任务，但 issue 本身必须足够清晰。

OpenAI 官方 Use Codex in Linear 页面介绍了 Linear 集成。具体连接方式和权限以当前官方页面为准。

步骤 1：让 issue 具备可执行信息

好的 Linear issue 应包含：

• 问题或目标。
• 当前行为。
• 预期行为。
• 影响范围。
• 相关页面或文件。
• 验收标准。
• 验证方式。

示例：

目标：手册详情页左侧目录需要按文档学习顺序展示。
范围：src/components/manual-sidebar.tsx。
验收：App、CLI、IDE、配置、Cloud、故障排查按固定顺序分组。
验证：运行 lint 和 next build。

步骤 2：把任务拆到合适大小

Codex 更适合处理边界清楚的 issue。

适合：

• 一个明确 bug。
• 一篇文档。
• 一个小功能。
• 一组相关测试。

不适合：

• “重做整个后台”。
• “优化全部体验”。
• “把网站做得更高级”。

如果 issue 太大，先拆成多个子任务。

步骤 3：控制 Linear 权限

授权时要确认：

• Codex 能读哪些 workspace 或 team。
• 是否能评论 issue。
• 是否能改状态。
• 是否能创建任务。
• 是否能访问关联仓库。

建议先让 Codex 评论和创建 PR，不要一开始就自动改变关键状态。

步骤 4：让 Codex 在结果里回填验证信息

可以要求 Codex 在 issue 或 PR 中说明：

• 修改了哪些文件。
• 解决了什么问题。
• 跑了哪些验证。
• 没跑哪些验证以及原因。
• 是否还有风险。

这样团队成员能快速判断是否可以 review。

步骤 5：敏感 issue 要更谨慎

以下 issue 不适合直接交给默认集成：

• 安全漏洞。
• 客户数据。
• 内部权限策略。
• 生产事故。
• 未公开产品计划。

这类任务应先确认访问权限和信息脱敏策略。

常见错误

不要把很大的 epic 直接交给 Codex。

不要省略验收标准。没有验收，Codex 很难判断完成。

不要让 Codex 自动关闭你还没 review 的 issue。

不要把敏感数据写进 issue 正文。

小结

Codex Linear 集成的效果取决于 issue 质量。把目标、范围、验收和验证写清楚，控制权限，并让结果回到 PR 和 review 流程，才能稳定落地。