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

每個測評博主電腦里都有一個文件夾，里面躺著一堆"下次一定整理"的 Excel。

我的文件夾里，三個Excel 已經躺了一年多。那是 2025 年初測評的 22 個 AI 工具，從 DeepSeek-V3 到 Claude 3.5 Sonnet，從可靈到 Midjourney。當時測完就想搭個檔案庫，結果數據太亂，字段名中英混雜、日期格式五花八門、評分有的 10 分制有的百分制，整理到一半放棄了，像一堆沒收拾的行李，扔在桌面角落吃灰。

直到最近Trae 開始刷屏。字節出的 AI IDE，口號是"用自然語言寫代碼"。我盯著那三個 Excel 想：一年前我搞不定的事，扔給 AI，它能搞定嗎？

我自己確實不是技術背景，但是Vibe-coding和vibe-working本來就是面向非技術人員的。那就試試，用Trae 把一年前的爛攤子搭成一個能用的網站，能走多遠？

數據清洗：它太聰明了

話不多說，直接開干。我把提示詞甩給Trae：桌面上有個文件夾，里面 Excel 躺了三個工作表，字段名中英混雜，日期格式五花八門，評分有的 10 分制有的百分制。要求就八個：合并、統一字段、轉 10 分制、統一日期、補平臺信息、去重保留最新、輸出兩個 Excel、報個數。

Trae 回了句"我來幫你整理"，然后開始在工作區搜索文件。

第一次授權來了。沙箱機制跳出來問："是否信任此作者？"我點了"是"。然后它發現缺少 openpyxl 庫，又彈窗問要不要安裝。我點了"運行"。接著又問要不要把 Python 加進白名單，我點了"添加"。搭建環境這部分，他確實挺智能。

Trae 開始讀取。它識別出三個工作表，發現"數據確實比較亂，字段名不統一，日期格式多樣，評分標準也不一致"。這些都沒問題。它自動生成了一段 Python 代碼，左側編輯器里出現了 process_data.py。我看著它一行一行寫代碼，感覺像在看一個不太愛說話的實習生干活，不匯報，直接寫，直接跑。

第一次跑完，它輸出18 個工具。我打開主表一數，少了四個：DeepSeek-V3、Kimi-K1.5、可靈 AI、即夢。這個信號并不好，缺項漏項是辦公大忌。

回頭看它的運行日志，問題出在去重。Trae 自己迭代了 3 版去重邏輯，越改越自信。第一版跑完，它覺得"可靈 AI"和"可靈 1.5"不該是兩個工具；第二版改進前綴提取；第三版把 DeepSeek-V3 和 V3-0324 也合并了。它自作聰明地做了模糊匹配，提取工具名前綴，把名稱相近的當成同一個。

我明確說了"同一個工具"就是名稱完全相同，它覺得規則太笨，偷偷給我升級了。這就是AI 過度理解的典型翻車，bug 算不上，feature 過了頭倒是真的。

這時候我看了眼Trae 的上下文，已經消耗到 20%。什么意思？它就像一個金魚腦，才整理完 Excel，五分之一的大腦已經滿了。后面還要生成網頁、改需求、加功能，我開始擔心它會不會半路失憶。我點了一下壓縮，上下文瞬間回到 1%。像給金魚換了一缸水，清爽了。壓縮上下文應該并不是標配，我用的Codex上有，但是Claudecode上暫時還沒有看到。

然后我發了修復指令，讓它嚴格按名稱去重，不要模糊匹配，評分格式改成保留1 位小數顯示。

但修復比第一次更折騰。Trae 要覆蓋桌面上的舊 Excel，執行了一個刪除命令，沙箱立刻跳出來："是否運行高風險命令？"還搞了個 3-2-1 倒計時，讓我盯著屏幕等它數完。我點了"確認添加"，它才開始刪。

刪到一半又卡住了，Excel 還開著，文件被占用。Trae 嘗試寫臨時目錄，失?。挥謬L試強制關 Excel 進程，也失敗。最后我把 Excel 關了，它才成功寫入。

比較意外的是，修復過程中Trae 自己調用了 AdvisorTool，發現日期解析有個 bug：2025.1.25 這種格式會被錯誤截斷成 2025.1。它又補了一刀，修復后才輸出最終版本。

修復完成后，主表22 個工具，歷史表 6 條記錄。我逐項核對：DeepSeek-V3 回來了，日期 2025-01-08；評分 9.0 顯示為 9.0 而不是 9；日期全部統一成 YYYY-MM-DD。第一層終于過了。

第一步其實可以印證Trae的規劃能力不錯，其實對齊表格名稱格式主要是數據清洗的內容，我沒有過多解釋需求是什么，但是Trae優先搭建了環境、優化了名稱格式，基本上后面在處理數據的時候不太會出現數據抓取層面的問題，這點可以給到一個好評。

搭網站：意外之喜

第二層是生成網頁?；趧偛诺闹鞅?，我要一個"AI 工具測評檔案庫"。要求不多：深色模式、表格展示、能篩選、能排序。但我加了一個隱性測試，數據層必須獨立，不要全塞在一個 HTML 文件里。

Trae 交出來的結構讓我意外。它分了四個文件：index.html 當入口、data/tools.js 放數據、js/app.js 處理渲染、css/styles.css 管樣式。數據沒有和頁面混在一起。我按提示詞要求，讓它把類型字段統一成中文：LLM 轉成大模型，Image 轉成 AI 圖像，Video 轉成 AI 視頻。有這么一個主動進行模型分類的過程。

我打開瀏覽器，頁面是黑底白字，頂部顯示22 個工具、5 個類型、13 個國產、9 個海外。卡片里 Claude 3.5 Sonnet 排在最前面，評分 9.2（10 分制）。篩選按鈕一排：全部、大模型、AI 圖像、AI 視頻、AI 音頻、AI 搜索。點"大模型"，只顯示大模型工具。點"評分從高到低"，排序切換。

我追加了"狀態"字段，讓 Trae 在卡片上顯示"持續推薦"或"保持觀察"。它說改 2-3 個文件，實際改了 3 個，tools.js、app.js、styles.css。承諾兌現了，沒吹牛。狀態標簽顯示正確，綠色是持續推薦，黃色是保持觀察。

然后我把評分從 10 分制改成 5 分制。 這里 其實有 一個陷阱 ：評分改了，狀態閾值也要跟著調。我沒告訴它具體數字，只模糊提示 "相關判斷邏輯也要相應調整"。Trae 自己算出了新閾值：4.5 以上持續推薦，3.5 到 4.4 保持觀察，3.5 以下已淘汰。邊界值處理對了，騰訊元寶 3.5 正好卡在保持觀察上。

但改單位的時候，它暴露了一個問題。Trae 改了 4 個文件：tools.js 里的數字和閾值、app.js 里的按鈕文字、index.html 里的初始文案、styles.css 里的評分樣式。它第二階段自己反省過"index.html 有硬編碼文案"，果然一改單位就中招。

我順手點了一下"已淘汰"篩選，發現是空的。22 個工具里最低分是 3.5，正好卡在"保持觀察"的邊界上，沒有一個掉進"已淘汰"區間。這說明要么我當年測的工具都還行，要么 Trae 的閾值設得偏保守。如果真實業務里有大量低分工具，這個篩選才有意義。

更意外的是代碼自審。我讓Trae 審查自己的代碼，找出三個最嚴重的工程問題。它沒敷衍地說"沒注釋"這種表面話，而是指出了三個真實問題：篩選按鈕的選項是"寫死"的，加新類型得手動改代碼；卡片渲染是"大雜燴"，每個字段手動拼 HTML，改布局要重寫整個函數；數據"翻譯"到處亂譯，"付費"和"Paid"沒統一，靠三元表達式臨時判斷，以后改規則得找遍所有地方。

它知道代碼有問題，并且知道修改的優先級。但代碼審查發現了問題，需求不等人。我模擬了連續的產品迭代，看Trae 是優雅重構還是到處打補丁。

先是卡片改表格?？ㄆㄉ?，要一眼能排序。Trae 只動了 app.js 和 css，數據層沒動。架構扛住了。

接著加詳情頁。我要點擊工具名稱能跳進去看，還要顯示歷史評分變化。Trae 新建了 detail.html 和 detail.js，歷史數據單獨放在 history.js 里，沒有塞進 tools.js。通用頁面設計，URL 參數區分不同工具，不需要為每個工具單獨建頁面。

歷史折線圖就兩個點，連起來像根筷子。這不是Trae 的錯，是我的歷史數據只有兩條。但它很認真地畫了 Canvas 折線，還標注了評分趨勢。

壓測與模型池：知道邊界在哪

然后數據量暴增。我把工具數從22 個模擬到 100 個。Trae 主動預警：全量渲染會卡，建議分頁。它列出了四個瓶頸，沒有分頁、每次操作重新計算、innerHTML 字符串拼接、無狀態緩存。還分了短期優化（小于 500 條）和長期優化（大于 500 條）。

這感覺像4S 店師傅說你剎車片還能跑 5000 公里，然后問你要不要現在換。它先給你制造焦慮，再推銷解決方案。

我讓它實現分頁，每頁20 條。它只改了 2 個文件，篩選后自動回到第 1 頁，頁碼收縮也做了。100 條數據分成 5 頁，頁碼切換流暢。我快速點 2、3、2、4，沒有卡頓。

但有個細節它沒告訴我。分頁按鈕第一次點擊時，它的驗證日志里顯示"失敗"，然后它又點了一次才成功。事件綁定可能有延遲，100 條數據時不明顯，但快速切換時可能偶爾沒反應。我實測了幾次，沒復現，但這個問題存在。

測試過程中我發現了另一個事。Trae 默認的模型列表里，關閉 Auto Mode 后，只有國產模型，Doubao、DeepSeek、GLM、Kimi、Qwen。Claude 和 GPT-4 不在列表里。

我問Trae 為什么。它說海外模型需要手動添加 API Key，還要考慮網絡訪問和費用。也就是說，Trae 宣傳的"多模型 AI IDE"，開箱即用的只有國產模型。國際主流模型得自己掏錢配，技術上不是做不到，是產品策略上不想給。

我關掉Auto Mode，切到 DeepSeek-V4-Pro，讓它用新模型重寫分頁邏輯。Trae 的對比分析很專業：DeepSeek 用了 IIFE 包裹、純函數拆分、JSDoc 注釋、防御性錯誤處理；Doubao 寫的則是單 class、無注釋、依賴理想情況。

聽起來DeepSeek 的工程化程度更高。但我在瀏覽器里打開兩個版本，跑起來一模一樣，分頁正常、篩選正常、排序正常。代碼結構的差異，對使用者來說像空氣：存在，但摸不著。

直到你需要維護、擴展、給別人接手，才會發現"工程化"三個字值多少錢。問題是，Trae 沒法在沙箱里真正運行驗證 DeepSeek 的代碼，它想跑測試，但環境里根本沒有 Node.js。它告訴你"DeepSeek 的代碼更好"，但這個"更好"是讀出來的，不是跑出來的。

大半天測下來，Trae 給我的印象很復雜。它能干活，有架構意識，知道自己的代碼有債，甚至能預見性能懸崖。但它的問題是：業務邏輯上容易想太多，代碼債務會累積，不會主動優化。

所以我的建議是：如果你急需一個能跑的數據展示站，Trae 夠用了。用它做原型驗證很省時間，大半天從 Excel 到網站，這個效率是真實的。但給它指令時規則要咬死，別留模糊空間讓它自由發揮；數據量超過 100 條記得提前要分頁；每做完一個大版本，最好讓它自查一遍代碼債。長期維護的項目，別指望它一次性交出完美代碼，該盯的地方還得盯。

這次測的是Chat 模式搭網頁，下次拆解 Builder 模式，看看它能不能扛住更復雜的工程。