Linear 今天正式发布 Code Intelligence for Linear Agent。
Linear Agent 现在可以读取你的代码库，直接从源码中回答问题。它能解释功能如何工作、调查问题的可能原因、帮助团队直接理解当前实现。
为什么代码是缺失的上下文
随着公司成长，协调成本越来越高。Slack 和 Teams 让提问变得容易，但回答仍然耗费时间，还会打断掌握上下文的人。而这些上下文往往已经存在于代码、需求文档、客户反馈、issue 和决策记录中。问题是信息难以触达，也没有一个系统能让它们共存。
Linear 已经是产品工作发生的地方。问题进来，上下文累积，计划制定，工作推进到发布。大部分已经就位，但一个重要的上下文来源仍然缺失——代码本身。
代码是产品上下文的最佳形式之一，因为它是客观的。一个行为要么存在，要么不存在；一个功能今天要么支持某个场景，要么不支持。你可以得到关于当前状态的确定答案。
数据：查询量爆炸增长
引入代码上下文后，团队发现它的影响远超编码工作流本身：
| 月份 | Code Intelligence 查询量 |
|---|---|
| 2月 | 1,055 |
| 3月 | 2,681 |
| 4月 | 4,267 |
| 5月（预估） | 5,200+ |
每一次查询都是一个原本可能要问队友、或自己花时间调查的问题。
Linear 现在可以按需或自动地为团队做代码研究。
三大实战场景
1. 自动诊断：从空白开始到有依据的起点
工程师做问题分类时最重的负担之一是针对代码库做调试。旧工作流从人工调查开始：找到相关区域、检查近期变更、追踪代码路径、猜测从哪里入手。
有了 Code Intelligence，你可以直接问 Agent，或者设置成每个 issue 进来时自动调查：
为什么这个功能可能回退了？检查这个区域的近期提交，识别最相关的代码路径，给我最可能的原因，按验证优先级排序。
Agent 可以呈现可能的回退点、相关代码路径、该区域的近期提交。当 bug 到达时自动发生这件事，任何接手 issue 的人都从一个已部分调查的状态开始，而非空白。其他在看这个问题的人也能看到同样的上下文。
2. 支持一线：从模糊转交到有依据的回答
客户报告问题——邀请链接失效、登录流程异常、同步失败。
通常这会升级到工程团队，让某人从代码库中重建逻辑。有了 Code Intelligence，第一次调查可以立即发生：
为什么邀请链接在重装应用后会停止工作？检查相关代码路径和任何可能解释这个问题的近期变更。
Agent 可以追踪相关代码路径、检查近期变更、解释可能发生了什么，所以支持团队可以从有依据的回答开始，而非模糊的转交。问题从"有人能看看吗？"变成"系统似乎在这样做，问题发生在这里"，只有真正需要处理的问题才会升级。
价值在于速度、首次接触的质量、以及对真实问题的更自信升级。
3. 产品调研：从需求到技术评估在同一流中完成
PM 在系统中调研客户请求，理解用户需求的模式。团队看到一个反复出现的需求，想知道在当前代码库中实现的技术成本。
这些是产品问题，但也是代码问题。
有了 Code Intelligence，团队可以在同一工作流中从产品想法推进到技术成本评估：
基于用户请求，实现这个的技术成本是多少？把你的发现写成技术 spec，作为这个项目的一部分。
Agent 可以把请求模式连接到当前实现，识别涉及的主要系统，在 spec 撰写前呈现重要的边界情况。Spec 从一个更准确的现状图景开始，这让评估可行性和清晰沟通想法变得更容易。
bonus：找到组织中的上下文持有者
代码还能回答一个组织问题：谁以前在这个领域工作过？
这个上下文通常散落在记忆、旧的 pull request、半模糊的所有权认知中。Code Intelligence 可以追踪相关代码路径、检查近期变更、查看 git history，呈现最可能有上下文的人。
这给设计师和工程师提供了一个通过代码本身快速找到可能上下文持有者的方式。
核心洞察
代码上下文在试图理解"今天有什么"时总是有用的。它是当前状态的客观记录。
在编码之外，它帮助支持团队解释事物如何工作，无需总是升级或自己调查。它帮助产品在规划变更前理解实现，帮助团队用更好的上下文估算工作量，通过自动诊断 incoming 问题帮助工程团队。
这就是 Code Intelligence 为 Linear Agent 增加的东西。它把产品实际如何工作的真相来源，带入了团队已经分类问题、收集反馈、规划工作、做决策的同一个地方。