加一個功能、修一個 bug，通常都走同一條路：開編輯器、找到檔案、改完、跑測試。對於整天待在終端機裡的人來說，這條路中間有一道彆扭的接縫。跟助手的對話在一個視窗，程式在另一個視窗，在兩者之間切換所耗掉的注意力，比兩件事本身都多。

Aider 把對話搬進終端機。進到專案目錄、啟動工具，然後像跟同事講話一樣描述你要什麼：給這個函式加上參數檢查、把這三個類別裡的共同邏輯抽出來。它讀程式、改檔案、跑測試，把活做完，而編輯器從頭到尾沒有出現。數萬人追蹤、數百萬次安裝，說明那道接縫確實值得拆掉。

每次改動都提交，後悔只要一條命令

很多人一用就上癮的設計很簡單：它對程式庫做的每一次修改，都會連同一段寫好的說明提交進版本控制。改之前長什麼樣、改之後長什麼樣，兩者都躺在歷史裡。於是你永遠有一條乾淨的退路。改壞了，平常用的工具直接顯示差異、還原回去，不必爭論「它到底動了哪些檔案」。

作者把這個原則貫穿整個專案，這也是它在開發者社群裡口碑這麼好的一大原因。而這其實是一條很小的紀律，卻改變了工作的心理：把任務交給代理，不再像下注，而像開一個分支。

先畫一張地圖，再動手

面對大型程式庫，工具會先用語法解析器把整個儲存庫解析一遍，產生一份地圖：有哪些檔案、哪些類別、哪些函式，彼此怎麼呼叫。它不把全部原始碼塞給模型，而是先讓模型看到專案的骨架，再由模型精確挑出需要改的檔案。

這才讓大型專案從理論變成可行。另一種模式把「想」與「做」拆開：由更強的模型規劃改動，再由更快的模型照著執行。需要判斷的地方講品質，不需要的地方講速度，成本則與任務難度成比例。

任何模型，一百多種語言

不偏愛任何廠商。商業模型可以接，跑在自己機器上的本機模型也可以接，後者情況下程式根本不離開機器。維護者自己推薦的組合裡，有些是照性價比挑的，而不是照名氣挑的——這種立場本該常見，實際上卻很少。

語言覆蓋超過一百種，從常見的腳本與系統語言，到用在網站後端與舊企業系統上的那些。檢查與測試也在同一個迴圈裡：工具自己跑 linter 與測試，發現問題先修好再把工作交回來。你甚至可以把需求講出來讓它寫成程式——聽起來像噱頭，直到你用第三次。

用它自己造出來的

真正說服懷疑者的細節是：這個專案是用自舉的方式開發的。作者用這個工具寫了它自己大約百分之八十八的程式，歷史裡有三千多次提交帶著共同作者的身分指向它。一個敢這樣大量用在自己身上的工具，提出的品質論證是任何基準都比不上的，而任何懷疑的人都可以自己去翻歷史。

專案以寬鬆授權完全開源，本身不收費；你只為實際呼叫的模型付費。它也能處理「模型只存在於瀏覽器視窗裡」的情況，把那種安排原本需要的複製貼上一併省掉。

適合誰

本來就住在終端機裡、覺得切到編輯器很煩的開發者會得到最多，但它的吸引力其實更廣。Aider真正提供的是一種工作方式：每個實驗都有紀錄，每個錯誤都能還原，而模型是儲存庫裡的一個參與者，不是旁邊的一個聊天視窗。換個位置這麼小的一件事，差別卻大得意外。