Linear AI 完整教學：當執行長說「議題追蹤已死」，這套工具實際怎麼用

2026 年 3 月，Linear 的執行長丟出一句話：議題追蹤已死。

這種話當然有行銷成分。但如果你看它接下來一整年做的東西——Agent 能用 Claude Code 與 Codex 寫程式、Code Intelligence 讓 AI 讀你的程式庫、Linear Diffs 把 code review 搬進來——你會發現它確實在拆掉某個東西。

拆掉的不是議題追蹤，是「人在系統之間搬東西」這件事。

它到底改了什麼

過去一個功能從想法到上線，路徑大概長這樣：Slack 討論 → 有人手動開 ticket → 工程師讀 ticket → 去 GitHub 開分支 → 寫 code → 開 PR → 在 GitHub review → 回 Linear 改狀態。

每一個箭頭都是一次人工搬運，而每一次搬運都會掉東西——上下文掉了、決策理由掉了、為什麼這樣做的原因掉了。

Linear 2026 年做的事，是把這些箭頭一個一個換成 Agent。

步驟一：先認識 Agent 的基本用法

Linear Agent 可以在網頁、行動或桌面應用裡使用，也能當作外掛在 Slack、Teams 與 Zendesk 裡運作。

它有一個聊天介面。官方給的使用範例很能說明定位：「根據這裡的討論建立議題，並指派給我。」

這句話的意義是——你在 Slack 討論完一個 bug，不用切到 Linear 手動開單，直接叫 Agent 把剛才的討論整理成議題。上下文不會掉，因為它讀的就是原始討論。

實際操作建議：一開始不要什麼都叫它做。先固定用它做兩件事，練到穩了再擴大。我建議從「把討論轉成議題」與「幫我摘要這個專案目前的狀態」開始，這兩件事錯了也不會有什麼損失。

步驟二：把重複的流程存成 Skills

Skills 是把工作流程存起來供未來重複使用，用來自動化常見任務。Automations 則是在議題建立時自動觸發的流程。

注意：這兩項需要 Business 或 Enterprise 方案。如果你在較低階方案，這一段可以先跳過，但它其實是 Agent 從「好玩」變成「有用」的分水嶺。

實務上值得存成 Skill 的東西：

Bug 分流：收到 bug 議題時，自動判斷嚴重程度、指派給對應的負責人、加上標籤、如果是 P0 就同時發 Slack 通知。

規格檢查：新功能議題建立時，自動檢查有沒有寫驗收條件、有沒有指定設計稿、有沒有標記相關的 API 變更。缺哪一項就回覆提醒。

發版整理：把某個週期內完成的議題整理成 release note 草稿。

第二項我特別推薦。台灣團隊的 ticket 品質普遍不穩，尤其是 PM 趕著開單的時候，常常只寫一句「這個要修一下」。用 Automation 在建立當下就擋下來，比事後追問有效得多。

步驟三：開啟 Code Intelligence，讓 Agent 知道你的產品怎麼運作

這是 2026 年 5 月推出的能力。Code Intelligence 給 Linear Agent 受控的程式庫存取權，讓它能推理產品如何運作，而不只是看議題、專案與文件裡寫了什麼。

差別在哪？舉個實際例子。議題寫「登入後首頁載入太慢」。

沒有 Code Intelligence 的 AI 只能根據這句話猜，通常會給你一堆「可以考慮加快取」的通用建議。

有 Code Intelligence 的 Agent 可以去看首頁實際跑了哪些查詢、哪一支 API 被呼叫了幾次、有沒有 N+1 的問題。它的回答會是「這裡連續呼叫了三次使用者權限查詢」而不是「建議優化效能」。

導入前務必確認幾件事：存取範圍怎麼設定、涵不涵蓋私有 repo、公司的原始碼政策允不允許。如果你在金融、醫療這類受監理的產業，這一步一定要先過資安與法遵，不要工程師自己開了才說。

步驟四：讓 Agent 實際寫程式

Linear Agent 可以透過 Claude Code 與 Codex 寫程式，讓你在 Linear 裡完成分流、規劃、審查與出貨。更進一步的是，Agent 能自行設定環境、執行並測試程式碼之後才回報結果——目的是減少交接次數、提供更完整的變更。

「先跑過測試再回報」這件事比聽起來重要。早期的 AI 寫程式工具會很自信地給你一段完全跑不起來的程式碼，你要自己發現。會自己跑一遍的代理，至少過濾掉了最明顯的錯誤。

實務上的用法建議：

適合交給 Agent 的：明確定義的 bug 修復、有既有模式可循的重複性功能（例如「照著現有的 A 頁面做一個 B 頁面」）、測試補寫、相依套件升級。

不適合的：架構決策、涉及多個服務的變更、效能敏感的核心路徑、任何你自己也還沒想清楚的東西。

最後一項是重點。AI 寫程式最大的風險不是它寫錯，是它會非常有效率地把一個沒想清楚的需求實作出來——然後你要花更多時間拆掉。

步驟五：用 Linear Diffs 做 code review

Linear Diffs 把 code review 帶進 Linear，讓你從議題直接審閱變更、與 Agent 迭代修改，並把所有 review 同步回 GitHub。

它不取代 GitHub，GitHub 仍然是程式碼的真實來源。它做的是把入口搬到你原本就在的地方，省掉切換視窗與重新建立上下文的成本。

「與 Agent 迭代修改」這個流程是新的：你在 review 裡指出問題，Agent 直接改，你再看。這比傳統的「留 comment → 等作者有空 → 改 → 再 review」快得多，前提是你要願意把 review 的標準講清楚。

注意事項：三個容易踩的坑

第一，議題品質變成瓶頸。 以前寫得爛的 ticket 是同事私下抱怨，現在是 AI 照著爛描述做出爛東西，而且做得很快。導入 Agent 之前，先把「怎麼寫一張好議題」講清楚，這件事的投報率遠高於任何工具設定。

第二，方案限制要先看。 Skills 與 Automations 需要 Business 或 Enterprise 方案。小團隊如果只是想試 Agent 的對話能力，不用急著升級；但如果你的目標是自動化，要先把成本算進去。

第三，review 不能省。 Agent 會跑測試不代表它的變更是對的——測試只證明它沒壞掉現有行為，不證明它做了對的事。合併前的人工 review 沒有任何可以省略的理由。

台灣團隊的實務建議

台灣的軟體團隊有一個很普遍的結構問題：人少、事雜、一個人身兼三種角色。工程師同時是 PM、是 QA、有時還要做客服。

這種結構下，Linear Agent 的價值其實比大公司更高——因為省下的不是某個專職角色的時間，是那個什麼都要做的人的注意力。他不用再為了開一張單切到另一個系統，也不用為了回答「這個功能做完了嗎」去翻三個地方。

但也有兩個現實限制。一是預算：Business 方案對台灣小團隊不是小數目，導入前要算清楚省下的時間值不值得。二是原始碼政策：不少台灣公司是接外商或大廠的案子，合約裡對原始碼的處理有嚴格限制，Code Intelligence 這種功能可能直接違約，一定要先確認。

如果你的團隊還在用 Notion AI 或試算表管專案，我的建議是先不要急著跳。工具換過去很快，但「議題要怎麼寫」這件事沒解決，換到哪裡都一樣。搭配 Cursor 或 GitHub Copilot 這類編輯器內的 AI 工具，加上 Linear 的議題側自動化，是目前比較完整的組合。

想看更多開發流程的自動化做法，可以參考 任務指南；需要現成的提示詞可以到 提示詞範本 找。

TheAI學院 評語

「議題追蹤已死」這句話當然誇張了，議題追蹤沒死，它只是不再需要人當搬運工。Linear 這一年做的事其實很聚焦：把上下文留在原地，讓 AI 在上下文旁邊工作，而不是要人把上下文複製過去。

我認為真正值得注意的是 Code Intelligence。當 AI 能讀懂產品怎麼運作，它給的建議才會從「通用最佳實踐」變成「你這個專案的具體問題」。這是所有 AI 開發工具接下來的主戰場。

評語：AI 讓寫程式變快之後，瓶頸就往上游移動——現在最貴的不是實作，是把需求想清楚。一張爛議題以前浪費一個人半天，現在能讓 AI 在半小時內產出一堆要重寫的程式碼。

給台灣讀者的具體建議：先別急著買 Business 方案。這個月挑五張你們團隊最典型的議題，拿去問 Agent「你看得懂要做什麼嗎」。如果它看不懂，那你們該解決的是寫作規範不是工具預算。等到議題品質穩定了，再談自動化，投報率會完全不同。

資料來源

• Linear Changelog：Code Intelligence（2026-05-14）
• Linear 官方更新頁 Now
• Linear adopts agentic AI as CEO declares issue tracking dead（The Register，2026-03-26）

依公開資訊整理、以官方說明為準。方案內容與功能可能調整，實際以 Linear 官方公告為準。