Trae Solo現在就想干一件事：把AI Coding做成白盒

作者 ｜ 董道力
作者 ｜ 王兆洋

今天提到AI Coding，外界的一個最大的感受是同質化。不停有AI Coding，尤其是大廠的AI Coding發布，但似乎很難第一時間區分出來它們彼此的不同。

這也難怪，畢竟AI 編程這個賽道本身，就是從一場“借用大模型api”的實驗開始熱起來的。大家一開始只要能接上幾家頭部模型，在編輯器里塞個聊天框、做一下自動補全，就敢喊自己是新一代 AI IDE。

直到Claude開始斷供。

一個共識越來越清晰：如果核心能力握在別人手里，產品形態再花哨，也是建立在別人商業安排上的空中樓閣。開發者真正需要的，不只是“能不能調用某個聰明模型”，而是當上游風向變了，自己的工作流還能不能穩定運轉。

在這個背景下，對AI Coding極度重視的字節在Trae這個產品上的思路和做法就非常值得關注。

在模型方面，Trae希望盡量減少對單一上游的絕對依賴，字節在最近發布的豆包編程模型能起到一定作用。

而最近終于正式發布的Trae Solo，則在產品方面給出了答案：字節特點的產品思路如何體現在今天的AI產品上、字節這個同時在建造自己模型上下游生態的公司想要做一個什么樣的coding產品，都在Solo身上初步體現出來。

簡單說，Trae Solo最大的一個特點，就是用盡可能透明的設計，來讓AI Coding這個“黑盒”產品變得白盒化。

這涉及到兩方面的工作和目的。一是產品方面，Trae以近乎瘋狂的節奏保持著版本更新，其中許多工作投入到了實現白盒化的產品細節設計中。另一方面，這背后也能觀察到字節在今天AI Coding領域的競爭策略。

我們首先來看看它產品上做了什么。

想要理解它在產品上的思考和動作，拿它做一個任務是最好的方式。過程里可以看到它如何做到盡可能的透明來嘗試建立“信任”。

Solo 模式有兩條很直觀的路線：solo builder 負責從零把項目骨架搭起來，solo coder 則站在現有代碼庫上持續迭代和打磨。前者解決“先把東西做出來”，后者解決“做出來之后還能一直演進”。理想用法是先用 builder 快速拉起一個可用的 MVP，再交給 coder 按照產品節奏一點點升級、補全、重構。

接下來，我們就用一個項目來跑一遍，看看 Trae solo 這一套到底怎么運轉。

為了幫助程序員系統化地記錄和可視化自己的，寫代碼內容、投入時間和情緒狀態，從數據中看清自己的學習節奏與工作狀態，從而做出更聰明的調整和規劃。我們開發一個“個人記錄項目”。

promtps：開發一個「記錄每天寫代碼的內容、時長和情緒的個人儀表盤」，基于 Next.js。

在頁面上，Trae solo 模式應該是比較早采用了區別于其它 IDE 的三欄模式，最左側是任務列表，中間是 solo 的工作臺，集中了 agent 對話、計劃、終端命令、文件改動等所有過程信息，右側則給網頁和文件預覽留出一整塊空間。看起來都是很工程化的設計，但正是把這些東西串在一塊兒，才讓復雜度盡量待在系統里，而不是全壓在人的腦子上。

接受到 promtps 后，solo builder 的第一反應不是急著寫代碼，而是先把需求拆成一份非常干凈的開發清單，從“搭項目”到“寫測試”“寫部署文檔”，一共 10 個待辦項，并明確寫上當前進度是 0/10 已完成。這一步本身就很像一個靠譜實習生在和你確認：“我先按這 10 步來，你看 OK 嗎？”

接著它開始自動動手，先用一條命令把 programming-dashboard 項目腳手架跑起來，接下來安裝需要的路徑。隨后，它會去搭建數據層，構建“代碼”“時間”“情感”三個項目重要的數據，并寫好對應的類型。最后，等待基礎結果搭完，solo 開始補建業務板塊，表單、各種組件、響應布局等。和其它 no-code 工具相比，它沒有停留在能跑就行，而是進行了測試，并且制作的項目文檔。

其實上面那些流程，其它 IDE 也有，但 Trae solo 模式通過顏色、icon、隱藏步驟等操作，讓流程更加清晰。

此外，更重要的是，solo 模式有一些看似零碎的小設計，都在努力的做一件事情：把 AI 開發盡可能白盒化，讓開發者知道 AI 此刻在干什么，為什么這么干，接下來準備怎么干。

正如開頭所說，現實中很多項目，開發者不需要完全把項目交給一個“黑箱 Agent”，而是站在一個更像“技術負責人”的位置上，和 AI 一起推進項目。

比如在 Agent 對話框可以輕松添加多種內容，用戶可以將網頁元素添加到對話框，實現指哪里改哪里。用戶不再需要用“把背景色調成紅色”“把 xx 字體改大一號”這種自然語言描述。

同樣是調試，瀏覽器中的控制臺會記錄很多“隱藏”報錯，在 Trae 中也支持一鍵添加到對話框。也避免開發者需要不斷復制控制臺中的內容交給 Agent。

除了用戶可以清晰容易的指出要修改的位置之外，Trae 也能清晰的告訴用戶它在做什么。

在“修改代碼頁面”可以看到文件修改整體情況，AI 改了哪些文件。落到具體的文件中，則是顯示典型的左右對照 diff，修改的地方用綠色高亮標出來，被刪掉的舊標題和樣式用紅色標出。

對開發者來說，這種視圖特別像“AI 自動幫你寫好 PR”：你不用滿項目去翻，也不用猜它到底改了哪幾處，只要掃一眼修改列表和對應 diff，就能判斷這次迭代有沒有越界、風格是不是統一、有沒有誤傷別的模塊。

AI 寫的代碼，不再是一坨黑箱，而是一組可以隨時復查、隨時回滾的具體改動。

此外，上下文幾乎決定了 AI 能做到哪一步。Trae 專門加了一個「手動壓縮上下文」的開關：

當你感覺當前這輪任務 AI 已經理解得差不多、回答也比較穩定時，就可以主動點一下“壓縮”。系統會把之前那些冗余的對話、日志和文件片段收攏成更精簡的摘要，把寶貴的上下文空間騰出來給后續任務。

關鍵是，這個壓縮過程可見。Trae 會把壓縮前后的對比直接攤在你面前：原來哪些文件、哪幾段對話在上下文里；壓縮后保留了哪些核心信息、舍棄了哪些細枝末節，都有清單。你一眼就能看懂“它刪了什么、留了什么”，而不是突然發現 AI 變笨了，卻不知道是因為上下文被系統偷偷清掉了。

整個項目的雛形制作完成了，接下來就調用 solo coder 模式進行完善以及增加功能。

Solo coder 還有一個很好用的 plan 功能，相當于在真正開工之前，先把 AI 的方案攤開給你看。

AI 不會一上來就亂改文件，而是先生成一份計劃：它是怎么理解你的需求的，準備朝哪個方向改，如果不滿意，你可以在它動手前就打斷、調整，而不是等它把一堆文件洗了一遍，最后才發現方向不對、白浪費了一堆 tokens。

比如我上傳一張圖片后，讓 solo coder 參考并修改項目 ui 風格。Trae coder 會寫一個詳細的改進說明，迭代目標是什么，將會改動哪些文件，第一步做什么第二步做什么。

我們可以對比一下網頁修改前后的設計風格，先不討論是不是美觀，但基本上都遵循了事先的計劃，比如“藍紫漸變、組建統一”等。

如果把這次體驗收個尾，我會這樣看待 Trae 的 solo 體系：solo builder 讓人有勇氣“先把東西做出來”，solo coder 則幫你在不推倒重來的前提下，持續把產品打磨到能用、好用、愿意長期維護。

這體現了Trae 理解的開發者的心理：大家并不是想找一個會自作主張的替代者，而是想要一個說得清楚、改得明白、出事能追責的搭檔。于是它把 AI 編程拆成一套可監督的過程。顏色和圖標讓任務流可讀，上下文壓縮讓信息邊界透明，修改頁面用 diff 告訴你每一處改動的位置，而 plan 則把“先對齊再執行”落實到每個步驟。

這些看似分散的小設計，其實都在朝同一個方向靠攏：讓人類保留決策權，讓 AI 承擔體力活。同時，盡可能透明，不丟掉必要的掌控權。

從 Claude 斷供那天開始，AI IDE 這條線其實就被迫進入了下一個階段：光靠著堆模型智商的紅利期會越來越短，接下來必須找到別的突破路徑。

今天來看，Trae找的路之一就是要把工程細節、協作方式、人機邊界一件件打磨清楚。在上面這個任務的過程里，這些各種各樣的產品功能和細節設計就是這個思路的產物，這些功能不一定都是會延續下來得到用戶肯定的設計，但這種迭代速度至少在今天有一個非常重要的作用——就是讓它和同質化的AI Coding產品們區分出來。

這個策略現在看來越來越清楚，通過不斷的強化讓這種“白盒”的特點成為“賣點”，進而獲得盡可能廣泛的潛在用戶，最終快速跑到一個規模化的重要節點，從而復刻字節一切成功產品的網絡效應。

這也無疑是一個實現起來充滿挑戰的策略，今天正式全量上線后，接下來幾個月的產品高強度更新和用戶量的增長情況，對于Trae Solo將會更加至關重要。