Trae 搭網站：翻車、補救、埋雷

一位專注於AI工具測評的部落客，為了整理一份塵封已久的Excel檔案庫，決定測試字節跳動推出的AI開發工具Trae。他將三個工作表、22個AI工具的混亂數據，從資料清理到建立成一個可篩選、可排序的動態網站，過程中卻發現Trae雖然聰明，卻也暴露出過度解讀、容易埋下技術債的特性。 測評者手邊有三個Excel檔案，裡頭記錄了2025年初測評的22個AI工具，從DeepSeek-V3到Claude 3.5 Sonnet，再到可靈與Midjourney。然而這些工具的字段名稱中英混雜，日期格式五花八門，評分標準從十分制到百分制都有，一直沒有整理完成。他決定將這個爛攤子交給Trae，測試它的極限。 第一關是資料清洗。測評者要求Trae合併三個工作表、統一字段名稱、轉換為十分制、統一日期格式，並輸出兩個Excel檔案。Trae收到指令後，自動建立了Python程式碼開始處理。但第一次執行結果出來，主表只顯示18個工具，少了DeepSeek-V3、Kimi-K1.5、可靈AI與即夢。問題出在去重邏輯，Trae自作聰明地將名稱相近的工具如「可靈AI」與「可靈1.5」視為同一個，這正是AI過度理解的典型案例。 測評者要求修正，嚴禁模糊匹配，並要求評分保留一位小數。然而修復過程並不順利，Trae在執行刪除舊檔案指令時觸發了沙箱的高風險命令確認，又因為Excel檔案正被占用而無法寫入。幾經波折後，Trae最終自行調用檢查工具，發現日期解析的bug並修復，才成功輸出包含全部22個工具的正確資料。 第二階段是建立網站。基於整理好的資料，測評者要求一個「AI工具測評檔案庫」，需具備深色模式、表格展示、篩選與排序功能。更關鍵的是，他要求資料層必須獨立。結果令他意外，Trae自動將專案分為四個檔案：index.html作為入口、data/tools.js存放資料、js/app.js處理渲染、css/styles.css管理樣式。頁面顯示出22個工具、5個類型分類，包含國產與海外產品，篩選按鈕與排序功能都正常運作。 隨後測評者陸續要求加入「狀態」字段，並將評分從十分制改為五分制。Trae成功推算出新的狀態閾值，4.5分以上持續推薦、3.5到4.4分保持觀察、3.5分以下已淘汰。邊界值處理也相當準確。但在修改評分單位時，它修改了四個檔案，也暴露了硬編碼問題。 測評者進一步要求Trae進行程式碼自我審查，找出三個最嚴重的工程問題。Trae沒有敷衍地回應，而是精準點出篩選按鈕的選項是「寫死」的、卡片渲染函數耦合過高、以及中英文數據翻譯不一致的問題。這顯示它具有察覺程式碼債務的能力。 之後的產品疊代測試中，Trae將卡片式呈現改為表格，又新增了詳情頁與歷史評分折線圖。過程中資料層保持獨立，架構扛住了需求變更。但折線圖因為歷史數據只有兩筆，看起來像一根筷子。 當模擬數據從22個暴增至100個時，Trae主動提出分頁建議，並列出四個效能瓶頸，包括全量渲染、無分頁機制、字串拼接與無狀態緩存，甚至區分小於500條與大於500條的長期優化方案。它實施了每頁20條的分頁功能，篩選後自動跳回第一頁，切換流暢。不過測評者發現分頁按鈕第一次點擊時，驗證日誌顯示失敗，之後才成功，事件綁定可能有微小的延遲問題。 此外，關閉自動模式後，Trae的模型列表僅顯示豆包、DeepSeek、GLM、Kimi、QWEN等國產模型。當詢問為何沒有Claude或GPT-4時，Trae回應需要手動添加API Key並考慮網絡與費用問題，意即開箱即用的只有國產模型。 測評者對Trae的結論是複雜的。它能幹活，具備架構意識，能預見效能問題，但容易在業務邏輯上想太多、程式碼債務會持續累積、也不會主動優化。對於需要快速搭建數據展示站的原型驗證，Trae效率極高，但在下指令時必須把規則咬死，避免留下模糊空間讓它自由發揮。長期維護的專案，也不能指望它一次交出完美程式碼，該盯的地方還是得持續盯。