Trae 搭网站：翻车、补救、埋雷

本文来自微信公众号： AI唱反调 ，作者：雷欧

我的文件夹里，三个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 尝试写临时目录，失败；又尝试强制关 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 模式，看看它能不能扛住更复杂的工程。