我們從一開始就是使用 Devin 來建構 Devin。上週，我們將 659 個 Devin 產生的拉取請求（PR）合併到我們自己的程式碼庫中，這個數字比 2025 年表現最好的一週的 154 個大幅成長。
許多人都知道 Devin 是一個網頁應用程式。在內部，我們會視工作起始點而定，在所有介面（網頁、Slack、Linear、CLI、API）中使用它。這篇文章將介紹我們如何充分利用這些工具。
核心體驗
設定是這樣的：我們新增任何希望 Devin 管理的程式碼庫。接著，我們會獲得一個統一的介面，可以使用自然語言在所有儲存庫中工作。
它被設計為對話式介面，所以我們可以用與隊友訊息往來相同的方式與它聊天，無論是透過 Slack、Linear 或 Jira 工單，或是網頁應用程式。在任何頻道中標記 @Devin。如有需要可附上檔案。就像在一般聊天介面中一樣來回溝通。
一個強大的成果是，任何人都能做出貢獻，無論其技術專長或在公司中的角色為何，他們不需要了解或設定 Git 或任何命令列工具就能開始為我們的程式碼庫做出貢獻。
標記 @Devin 並提出請求，我們就會收到一個可以審查和測試的 PR。例如，如果有人發現過時的文件或錯誤，他們只需在 Slack 中傳送一則簡短訊息來修復它，然後繼續處理其他工作。
這消除了快速迭代和優化的摩擦與障礙，並減少了切換工作脈絡的需要。
而且，當工程師看到隊友用 Devin 在他們每天使用的同一個程式碼庫中完成的成果時，他們會產生「噢，真的嗎？Devin 做得到這個？」的頓悟時刻，因此它便自然地傳播開來。
Ask Devin（程式碼庫問答）
一旦將儲存庫新增到 Devin，它就會自動建立索引。Ask Devin 成為通往該程式碼庫的視窗。
我們經常在開始工作階段之前使用它來界定工作範圍。工作流程是：使用 Ask Devin 探索程式碼並釐清目標，然後直接從搜尋介面啟動工作階段。
Devin 從我們的探索中獲得清晰的脈絡，提示也會自動針對我們的任務進行調整。
相同的工作流程也適用於 Jira 或 Linear 整合。在工單上標記 Devin。Devin 會分析任務、搜尋程式碼庫並規劃其方法。它會自動產生高品質的工作階段提示。
自動化程式碼審查
隨著我們使用智慧體推送更多程式碼，瓶頸從撰寫程式碼轉移到審查程式碼。Devin Review 將大型、複雜的 GitHub PR 轉換為直覺化組織的差異比對和精確的解釋。
我們現在每個 PR 都會使用它。
每當 Devin 在 Slack 中發布 PR 時，它都會包含一個 Devin Review 連結，因此只需點擊一下即可查看組織好的差異比對。
讓 Devin Review 實用的原因：
- 自動修正。如果 Devin Review 或 GitHub 機器人標記出錯誤，Devin 會自動修正 PR。Devin 還會處理 CI/lint 問題，直到所有檢查都通過，完成智慧體循環。
- 智慧差異組織。以邏輯方式將變更分組，將相關的編輯放在一起，而不是按字母順序排列。
- 複製和移動偵測。偵測程式碼何時被複製或移動，並乾淨地顯示變更，而不是完整的刪除和插入。
- 錯誤捕手。自動分析 PR 中潛在的問題，並依信心等級標記它們。嚴重錯誤需要立即關注。非嚴重錯誤仍應審查。標記為資訊性註解。
- 程式碼庫感知聊天。詢問有關 PR 的問題，並從程式碼庫的其他部分獲得具有相關背景資訊的答案。
對於任何 GitHub PR 連結，您可以將 github.com 替換為 devinreview.com。
設定自動審查後，Devin 會在 PR 開啟、推送新提交或新增某人為審查者時自動開始審查 PR。
設計系統
設計系統會逐漸偏離。有人硬編碼了一個十六進位值，另一個人建立了一個一次性按鈕，突然間我們就在維護多個真相來源。我們用兩種方式處理這個問題。
首先，任何人都可以在發現違規的當下立即修正。在 Slack 中標記 Devin 並附上螢幕截圖，它就會將元件遷移以符合設計系統。
其次，我們執行每日稽核。每天早上，Devin 會掃描過去 24 小時內合併的 PR，標記硬編碼的顏色、非標準間距以及應該使用共享元件庫的元件。它會為每個違規建立 Linear 工單，並選擇性地自動開啟修正 PR。
這種組合意味著無論是否有人注意到，違規都會被捕捉到。
錯誤分類自動化
當錯誤出現在 Linear 中時，必須有人停下手中的工作進行調查——閱讀工單、搜尋程式碼庫、檢查最近的提交——然後才能進行實際修復。我們自動化整個分類步驟。
我們設定了一個!triage-bug 手冊，捕捉我們工程師實際調查的方式：閱讀報告、搜尋相關程式碼路徑、檢查 git 歷史記錄，然後總結調查結果，包括根本原因和建議的修正方法。當任何人為工單新增Bug 標籤時，自動化就會觸發，無需指派。
像「週五部署後 /contact 出現 500 錯誤」這樣的工單，會變成 Devin 自動找到檔案、在 git log 中發現最近的規則運算式重構，並回傳摘要到 Linear：根本原因、受影響的檔案、建議的修正方法。
我們連接 Datadog MCP，讓 Devin 在調查期間檢查日誌。當工程師接手錯誤時，調查已經完成了。
端到端錯誤除錯
有些錯誤需要的不僅僅是分類。它們需要有人提取日誌、檢查資料庫、追蹤程式碼變更並撰寫修正方案。我們將 Devin 連接到 Datadog，並給予它只讀資料庫存取權限，以便它能執行完整的調查。
當錯誤報告進來時（例如「自週五部署以來，專業版使用者在帳單頁面看到『未定義』」），Devin 會從 Datadog 提取錯誤日誌、查詢唯讀複本來驗證資料狀態、在 git 歷史記錄中追蹤導致問題的服務提交、撰寫包含回歸測試的修正方案，並開啟 PR。
過去需要工程師中斷工作一小時的調查，現在在背景中完成。我們審查的是 PR，而不是日誌。
DANA（資料分析師智慧體）
DANA 是專為查詢資料庫、分析資料和建立視覺化而優化的 Devin 專用版本。
我們用它來詢問資料倉儲、建立儀表板，以及在不讓工程師中斷工作的情況下回答資料問題。它也成為非工程任務的首選，例如過去耗費時間的「點擊一堆按鈕來填寫報告」的工作。
我們可以透過點擊智慧體選擇器下拉選單從網頁應用程式存取 DANA，或是在 Slack 中使用 /dana 或@Devin !dana 後接我們的問題。
我們學會了要具體說明指標、包含時間範圍，並在需要時要求視覺化。
DANA 透過 MCP 連接到我們的資料倉儲——Redshift、PostgreSQL、Snowflake、BigQuery，無論我們運行什麼——並維護自己的資料庫知識，因此在我們提出任何問題之前，它已經了解我們的結構描述。它針對簡潔、以指標為中心的答案進行優化，內建 seaborn 視覺化功能，所以我們能快速獲得圖表和見解，而不必等待工程師切換脈絡到 SQL 用戶端。
我們發現它特別適用於那些過去在某人佇列中停留數天的即興問題。像「為什麼週二的註冊人數下降？」或「按企業版與自助服務區分消耗量」這樣的問題，團隊中的任何人都可以在 Slack 中直接提問，並附上 SQL 以便我們驗證邏輯。
DeepWiki
使用 DeepWiki，Devin 會自動索引所有儲存庫，並產生包含架構圖、來源連結和程式碼庫摘要的維基。Ask Devin 使用維基中的資訊來更好地理解和尋找相關脈絡。
對於公開儲存庫，deepwiki.com 會自動產生架構圖、來源連結和文件，無需任何設定。
我們也維護一個免費的 DeepWiki MCP。
手冊
手冊就像是針對重複性任務的自訂系統提示。如果我們發現在多個工作階段中重複相同的指令，那就是建立手冊的時候。
一旦有人成功使用 Devin，其他人就能複製這種成功。一個好的手冊包括：
- 我們希望 Devin 達成的成果
- 達成目標所需的步驟
- 描述後置條件的規格
- 修正 Devin 預設假設的建議
- 禁止的動作
- 啟動者所需的任何輸入或脈絡
我們使用手冊處理複雜的重複性工作——將資料導入 Redshift、執行資料庫遷移、整合 Stripe、Plaid 和 Modal。
MCP 市集
MCP 使 Devin 能夠使用數百種外部工具和資料來源。我們使用 MCP 來挖掘 Sentry、Datadog 和 Vercel 日誌。連接資料庫 MCP 以便在 Slack 中進行資料分析。從 Notion、Airtable 和 Linear 等工具中提取脈絡。
許多只需點擊一下即可啟用——Vercel、Atlassian、Notion、Sentry、Neon、Asana、Jam 等等。
例如，我們透過在 Slack 中標記 Devin 並使用 Redshift MCP 來繪製所有組織的累積 Linear 整合圖表——這為我們提供了每週細分、關鍵觀察結果和可分享的 Metabase 連結。
工作階段見解
工作階段見解會分析已完成的 Devin 工作階段，並提供可執行的改進建議。
在 Devin 完成任務後，工作階段見解會檢查：
- 問題與挑戰（技術問題、溝通落差、範圍蔓延）
- 包含關鍵里程碑和效率指標的工作階段時間軸
- 行動項目，包括即時改進和流程優化
- 包含增強指示的改進提示建議
我們使用一個工作階段的見解來為下一個工作階段提供資訊。我們可以直接從見解中使用改進後的提示啟動新的工作階段。隨著時間推移，工作階段變得更有效率。
API 存取
Devin 提供完整的 REST API，因此智慧體不需要人類參與即可開始工作。我們將 Devin 連接到現有系統並以程式化方式觸發工作階段：
- Sentry 出現崩潰日誌 → Devin 調查並開啟 PR
- 提交錯誤報告 → Devin 重現、診斷並修補
- 部署失敗 → Devin 分析日誌並建議修正方案
- 要求程式碼審查 → Devin 審查並留下評論
Devin 擅長的領域
Devin 可以承擔大多數工程工作，包括複雜任務。成功與具體程度成正比。範圍明確、標準清晰的任務能獲得最佳成果。
我們一致使用 Devin 的任務：
- 大量迭代改進
- 錯誤修正和邊界情況
- 提高測試覆蓋率
- 調查 CI 失敗
- lint 錯誤和 CVE 修復
- PR 審查
- 維護文件
- 修復靜態分析發現的安全性漏洞
- 程式碼庫問答
複雜任務的技巧
- 大規模挑戰應分解為跨多個工作階段的較小、獨立任務。
- Devin 擅長建立可運作的介面；將它們美化仍然是人類的優勢。
- 行動開發可行，但 Devin 沒有手機可以測試。
- 對於需要大量測試和驗證的任何事項，我們確保有驗證機制。
開始使用
最低設定
- 在app.devin.ai註冊
- 連接您的 GitHub、GitLab 或 Bitbucket
- 新增您的第一個儲存庫
- 從簡單任務開始工作階段
擴展規模 當您熟悉後：
- 新增知識以教導 Devin 您的程式碼庫慣例
- 為重複性任務建立手冊
- 連接 Slack 進行內嵌協作
- 為您的工具啟用 MCP
- 在開始工作階段之前使用 Ask Devin 來界定複雜工作範圍
將 Devin 視為團隊成員。給予它脈絡。教導它您的慣例。讓它處理待辦事項清單，讓您專注於需要資深判斷力的工作。具有清晰脈絡、能自主執行範圍明確任務的 AI 軟體工程師，是力量的倍增器。