7 月 19 日，微博上一位 AI 开发者晒了一件“让他破防的小事”：他只给了一句指令——做一个每天帮他练 15 分钟日语 N2 题的小工具，项目管理用 Linear——然后就看着 Agent 自己创建了一堆 ticket，再一个个分配给 subagent 去开发、发 PR、review、comment。微博他自己都感慨：明知道这已经是行业跑了好几个月的实践，亲眼看到还是觉得时代变了。
如果你还停留在“Linear 是个长得好看的 Jira 替代品”，那 2026 年这个夏天的变化值得认真看一眼：这款项目管理工具，正在变成 coding Agent 的“打卡机”。
发生了什么：CEO 亲自宣布“Issue tracking 已死”
2026 年 3 月 24 日，Linear CEO Karri Saarinen 发了一封标题只有四个字的公开信：「Issue tracking is dead.」。知乎他的论点不复杂：传统 issue tracking 是为“人类交接”模型设计的——PM 写需求、建 ticket，工程师接手，系统靠优先级、Sprint、状态流转来弥合中间的缝隙。可一旦 AI Agent 变成执行主体，整条交接链就多余了：Agent 不需要等 Sprint 排期，它需要的是上下文。
信里给了三个数字：75% 的 Linear 企业客户已经装了 coding Agent，Agent 工作量三个月涨了 5 倍，25% 的新 Issue 是 Agent 自动建的。知乎
现在打开 Linear，迎接你的不再是看板，而是「Ask Linear…」聊天入口。
同一周发布的三样东西：Linear Agent（产品内置聊天，Cmd/Ctrl+J 唤起，能用自然语言建 Issue、整理 Backlog、总结项目进展）、Skills（可复用工作流）、Automations（Issue 进入 Triage 时自动触发 Agent 处理）。官方演示的 Linear Agent 有三个典型用法：识别紧急任务、总结错过的更新、从视频里自动创建 Issue。
到 7 月底，官方功能清单里又多了 Code Intelligence、Coding Sessions 和 Loops，能整理需求、生成项目更新、读取授权代码库，也能调用 Claude Code 或 Codex 完成改动，重复任务按计划自动跑。小红书
同一时间，模型厂商也在下注。3 月 4 日，OpenAI 低调开源了 Symphony，它能把任务看板变成全自动研发流水线，从问题监控到代码提交形成闭环。知乎
也就是说，工具厂商和模型厂商押的是同一件事：看板变成 Agent 的任务队列。
先别急着欢呼，三盆冷水
第一盆，CEO 自己承认天花板。4 月份 Karri 又写了一篇长文给 AI 叙事降温：几乎没有人私下承认 Agent 写了 100% 的代码，工程师通常同时只能管两三个 Agent。知乎
Linear 自家的云端 coding Agent 每月修复超过 1000 个 issue，听着唬人，注意全是小修复。最大的收益是带宽——以前太小、太烦、不值得花时间的事现在有人干了，但真正困难的问题依然困难。知乎
第二盆，AI 在你最不懂的领域看起来最惊艳。Karri 的原话很扎心：在你不熟悉的领域，你看不出输出的毛病，所以觉得它像魔法。他把这叫作大规模版的“格尔曼失忆症”加“达克效应”。知乎所以外行刷屏的“AI 全自动开发”爽文，建议对折观看。
第三盆最实际：团队自己没理顺，Agent 只会更快地制造混乱。有拆解笔记直接点破：如果团队没有清晰的 Issue 责任和状态规则，Agent 只会更快制造混乱。小红书Hacker News 上对这次转型的反应也冷得多，有评论直言：我一直觉得 Linear 是一家审慎、克制的公司，这个突然的声明让我感觉他们内部在经历某种存在危机。知乎Linear 赌的是“上下文垄断”——你的 Roadmap、Issue、代码都在我这儿，所以我更有资格当 Agent 中枢。这个赌局还没开牌。
现在能上手的三条路，各适合不同的人
路线一：MCP + Claude Code，适合个人开发者。早在 3 月就有玩家实测，Linear 可以直接把 issue 发给 codex、cursor、claude code 这些编码工具。微博现在更成熟的玩法是：在 Claude Code 里接入 Linear MCP，把需求交给它拆子任务、标依赖，审核通过后批量建进 Linear 按序执行，独立子任务还能用 git worktree 并行。核心原则就八个字：先规划再执行，先拆解再编码——把大需求直接整个丢给 AI，往往上下文溢出、修改范围失控。知乎成本方面，Linear 免费档或 Basic 档就够，主要支出是模型订阅。独立开发、副业项目，这条路最稳。
路线二：Linear 内置 Agent + Automations，适合 5-20 人团队。团队本来就在用 Linear 的话，直接开内置 Agent：用自然语言整理需求、生成项目更新、读授权的代码库。Automations 更有意思，注意门槛：只给 Business 档及以上，也就是此前改价后 16 美元/月那档。官方演示的一条自动化——「当 Label 包含 Bug 时，自动搜索客户反馈并挂载上下文」——已经运行了 116 次，全程无人值守。知乎
路线三：Symphony + Codex，适合有 infra 能力、敢折腾的团队。一个 WORKFLOW.md 文件配置全部规则：轮询哪个看板、最多并发几个 Agent、沙箱级别、PR 策略。用一句话概括就是：团队管理“工作”，而不是监督“Agent”——把任务放进 Linear 看板，Symphony 自动派发到独立 workspace 里跑完、提 PR，全程无需人工盯着。知乎
但要提醒一句：OpenAI 官方给 Symphony 的定位是“低层次的工程预览版”，主要供受信环境测试，别上来就接生产仓库放羊。知乎
要不要上车？先过三道检查
这两个月，“循环工程”成了微博上的热门话题，连开发 Claude Code 的核心成员都说自己不再写提示词、转而构建循环了。微博热度会退，但“看板变 Agent 任务队列”这个趋势大概率不会退回——连 Linear 自己的数据都摆在那：25% 的 Issue 已经是 Agent 建的。不过上车之前，先过三道检查：
仓库的 Issue 规则清楚吗？状态、责任人、review 规范，缺哪个补哪个，Agent 放大的是混乱。
成本承受力如何？Linear 按席位收费，Agent 不占席位，但 coding Agent 的模型用量另算。Karri 有句话说得直白：如果潜力就是收入，那这些资本开支早就变成利润了。
从一个非核心项目开始。并发上限设两三个，跑一周，自己数 PR 再决定扩不扩。
几个值得持续盯的信号：Linear 的 MCP 支持进度、Code Intelligence 的开放节奏、Symphony 什么时候结束预览。工具永远是被用它的人重新定义的——Linear 真要变成 AI 的打卡机，咱们普通玩家要做的，是先找一个小项目把回路跑一遍。这位“新员工”是留用还是辞退，你试一周说了算。
