为什么需要 Linear MCP
项目管理的痛点：
PR 合并了 → 测试发现 bug → 你要手动建工单
1. 切到 Linear
2. 新建 issue
3. 填标题/描述/标签/负责人/优先级
4. 关联 PR
5. 切到 Slack 通知
→ 5 步，3 分钟，还容易漏填
Linear MCP：
你：PR #123 合并后出了 bug，建工单
AI：
1. 读 PR 内容（GitHub MCP）
2. 读 bug 描述
3. 在 Linear 建 issue
4. 标题/描述/标签自动填
5. 负责人 = PR 作者
6. 关联 PR
7. Slack 通知（Slack MCP）
→ 1 步，0 切换
Linear MCP 把项目工单从"手动登记"变成 AI 主动驱动。
核心能力
| 工具 | 说明 |
|---|---|
| 创建任务 | 建 issue/task/bug |
| 更新任务 | 改状态/优先级/负责人 |
| 查询任务 | 按 ID/状态/标签查 |
| 列出任务 | 查 Sprint 内全部 |
| 评论 | 给 issue 加评论 |
| 分配 | 设负责人 |
| 关联 | 关联 PR/文档 |
| 搜索 | 全库关键词搜 |
安装与配置
Step 1：创建 Linear API Key
- 访问 Linear → Settings → API
- 生成 Personal API Key（
lin_api_xxx）
Step 2：各客户端配置
Claude Desktop
{
"mcpServers": {
"linear": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-linear"],
"env": {
"LINEAR_API_KEY": "lin_api_xxxxxxxxxxxx"
}
}
}
}
Cursor / VS Code Continue
{
"mcpServers": {
"linear": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-linear"],
"env": {
"LINEAR_API_KEY": "lin_api_xxxxxxxxxxxx"
}
}
}
}
Step 3：验证
列出当前 Sprint 的所有任务
AI 返回任务清单，确认配置成功。
五个实战场景
场景 1：PR 自动转工单
配合 GitHub MCP：
你：PR #123 合并了，把改动建 3 个测试任务
AI：
1. 读 PR（GitHub MCP）
2. 识别改动点：
- 改了支付模块
- 改了退款逻辑
- 改了订单状态机
3. 在 Linear 建 3 个测试任务
4. 标题：[测试] 支付模块 xxx
5. 描述：含 PR 链接 + 改动摘要
6. 负责人 = QA 团队
7. 优先级 = Medium
8. 标签 = testing, post-merge
场景 2：Bug 自动入库
配合 Sentry/日志：
你：生产环境报错，日志在 errors.log，建 bug 工单
[报错日志...]
AI：
1. 分析日志，定位错误
2. 读相关代码（Filesystem MCP）
3. 在 Linear 建 bug 工单
4. 标题：[Bug] 支付回调超时
5. 描述：错误堆栈 + 复现路径 + 影响范围
6. 优先级 = Urgent（影响支付）
7. 负责人 = 支付模块 owner
8. 标签 = bug, payment, P0
场景 3：周报自动生成
你：生成本周项目周报
AI：
1. 查本周已完成任务（status=Done, week=this）
2. 查本周新建任务
3. 查延期任务
4. 汇总：
- 完成 15 个（含 3 个 P0）
- 新建 12 个
- 延期 2 个
5. 存到 Notion（Notion MCP）
6. Slack 发摘要（Slack MCP）
场景 4：延期预警
你：查哪些任务可能延期
AI：
1. 查 due_date < 今天 + 3天 且 status != Done
2. 读每个的进度（评论/子任务）
3. 判断：
- 进度 < 70% → 高风险延期
- 70-90% → 中风险
4. 输出预警表
5. 给高风险任务负责人发 Slack
场景 5：Sprint 规划
你：下个 Sprint 选哪些任务
AI：
1. 查 Backlog 所有未排期任务
2. 按优先级排序
3. 估算每个的复杂度（读描述判断）
4. 按团队容量（10 人 × 5 天 = 50 人天）选
5. 输出建议：
- P0 全选（8 个，预估 20 人天）
- P1 选 15 个（预估 25 人天）
- 留 5 人天 buffer
6. 创建 Sprint，批量排期
权限管控要点
1. 只读优先
日常查询用只读 API Key
写操作用独立 Key + 二次确认
Linear API Key 权限：
- Read：只读
- Read + Write：读写（高风险）
2. 团队隔离
✗ 给 MCP 全团队访问权 → 可能误改其他团队任务
✓ 用 Team 级 API Key，限制到本团队
3. 敏感任务隔离
✗ 安全/合规工单也授权 → AI 可能输出敏感信息
✓ 敏感工单单独项目，不给 MCP 授权
4. 写操作 system prompt 规则
你连的是生产 Linear。规则：
1. 创建任务前确认标题与所属项目
2. 不删除已有任务（改状态为 Canceled）
3. 改负责人前提示用户
4. 大批量操作（>5 个）需用户确认
5. 改优先级前确认（防止 AI 把所有任务设成 Urgent）
注意事项
1. API 限流
Linear API 限速约 1500 请求/小时。批量操作加 sleep：
import time
for task in tasks:
linear.create_task(task)
time.sleep(2.5) # 避免限流
2. 状态机复杂
Linear 任务有状态机：
Backlog → Todo → In Progress → In Review → Done
→ Canceled
AI 改状态要按流转，不能跳级（如 Backlog 直接到 Done）。
3. 自定义属性
Linear 支持自定义属性，AI 操作时要匹配：
优先级：Urgent/High/Medium/Low
类型：Bug/Task/Feature
标签：团队自定义
4. 关联局限
Linear 关联 PR 需 PR 在 GitHub 侧也配 Linear 集成
→ 单向关联可能不完整
→ 配 GitHub MCP 双向确认
5. Webhook 触发
Linear 状态变更可触发 Webhook
→ MCP 客户端订阅 Webhook 实现实时响应
→ 但 MCP 是请求-响应模式，Webhook 要单独处理
与其他 MCP 的协作
| 组合 | 场景 |
|---|---|
| Linear + GitHub | PR 自动转工单 |
| Linear + Slack | 任务变更通知团队 |
| Linear + Notion | 周报存档知识库 |
| Linear + Filesystem | 读日志建 bug 工单 |
与 Notion MCP 的区别
| 维度 | Linear MCP | Notion MCP |
|---|---|---|
| 定位 | 项目工单 | 知识库 |
| 结构 | 工单/状态机/Sprint | 数据库/页面 |
| 流程 | 强（状态流转） | 弱 |
| 协作 | 任务分配 | 文档协作 |
| 适合 | 开发任务跟踪 | 知识沉淀 |
协作三件套
Linear MCP（任务） → 谁做什么
Slack MCP（沟通） → 进展同步
Notion MCP（知识） → 做完存档
三者覆盖了项目协作全流程。
小结
Linear MCP 把项目工单从"被动登记"变成 AI 主动驱动。
记住一个原则：只读 Key 日常用，写操作用独立 Key + 二次确认。配合 GitHub MCP（PR 转工单）、Slack MCP（变更通知）、Notion MCP（周报存档），协作三件套集齐——任务、沟通、知识全打通。