TRAE 2025：从探索到信赖的转折年

共计 4086 个字符，预计需要花费 11 分钟才能阅读完成。

大家好，我是二哥。

2025 年对我而言，标志着人工智能从“好奇”阶段迈向了“依赖”阶段。

这一年我深刻感受到，AI 已不仅仅是用来“提问”，它开始切实融入我的工作流程。无论是编写代码、修改代码、理解遗留系统、拆解需求还是制定方案，AI 逐渐成为我技术上的长期伙伴。

早在之前，我就购买了国际版 TRADE 的年度 Pro 会员，并且每天的使用频率都很高。

当然，TRADE 的中国版也在同时使用。我所说的“同步”，不仅仅是安装两个版本试水，而是真正融入了我的日常工作流程。

在不同的网络环境、模型体系和实际开发场景中，我都会主动将问题交给 TRADE，对比其给出的结果，再选择我喜欢的风格。

国际版主要使用 Gemini 模型，它在处理代码相关问题时，更加深入，契合我的需求；而中国版则更像是一个高频、随手可得的技术助手。

无论是快速理解旧代码、确认设计合理性，还是在编写过程中停下来，让 AI 帮助我补充基础框架和校验思路，它都能够无缝融入我的开发节奏，不会打断我，反而更加默契。

还有一个非常重要的原因：省钱，哈哈。

在这样的背景下，我第一次完整地使用 TRADE 度过了一整年。第一次看到 TRADE 2025 用户年终报告时，我的内心不禁受到触动。

年终报告往往容易变得流于形式，但当我看到自己在 TRADE 中国版的使用数据时，突然明白了一件事情：

我在潜移默化中，已将 TRADE 视为知识获取的主要来源 。过去我阅读书籍，现在我在“阅读”TRADE，分析它编写的代码，研究它对代码的注释，探讨它对问题的思考方式，以及它帮助我提升工程能力的方式。

使用的高峰时段、关注的问题种类、是生成还是推理，这些数据其实比“你今年写了多少行代码”更具真实性。

大家也可以将自己的年度报告分享至 TRADE Friends 群，互相比拼，看看谁的成就最多，😄

线下活动也欢迎大家积极参与，我上次参加郑州的线下活动，收获颇丰。

如果仅从功能层面来看，AI IDE 和插件大家都有。但 TRADE 之所以让我频繁使用，归根结底是因为：

它并没有试图替我“做决定”，而是一直在帮助我“加速判断”。

从需求理解、代码生成，到重构时的对比分析，它更像是一个随叫随到、但又不抢你键盘和鼠标的技术同事。

在 2025 年，TRADE 的迭代速度非常迅速。

从最初的插件形式，到如今的 IDE，我明显感受到它的产品方向更偏向工程方面。它并不是为了展示 Demo 或模型能力，而是持续围绕一个问题打磨——如何真正融入开发者的日常工作中。

问答、补全、生成、理解代码，这些功能单独看并不新鲜。但当它们有意识地结合在一起时，恰好覆盖了开发过程中最消耗精力、却又容易被忽视的部分。

正因为如此，我才会在真实项目中，把 TRADE 视为一个默认的“工程加速器”。

我使用它完成的任务具体而日常：拆解复杂业务逻辑、快速理解旧项目、生成基础代码框架、在重构前对比多种方案的优缺点等。

SOLO 模式在 11 月上线中国版后，我立刻去体验。左侧是新增的多任务窗口，中间是对话流，右边是工具面板。

对话流在交互上也进行了优化：智能摘要、对话流折叠，以及任务列表的智能拆解和完成情况标记，让 AI 执行过程一目了然；你可以通过点击跳转按钮便捷地回溯对话流。

SOLO 最吸引我的地方，不在于它能生成多少代码，而在于它在动手之前，迫使你把事情理清楚。

在 Plan 模式下，每次使用 @SOLO Coder，看到的第一步总是清晰的开发计划，而非直接的代码。

它将需求拆分为几个阶段，明确每一步要做什么、依赖什么、可能会遇到的困难，提前展示在面前。

更为关键的是，这份计划不是强制执行的。

你可以选择否定，可以让它重做，也可以针对某一部分进行不断细化。当你点击“执行”的那一刻，代码已成为次要问题，因为最复杂的判断已经提前完成。

在实际执行阶段，SOLO 的表现同样相当克制。

所有代码变动都会通过 DiffView 明确展示，你能清晰看到它改动的地方、为何要改动这些地方、以及这次修改与上一次的区别。

在 PaiFlow 项目中，我已经不止一次将相对完整的任务直接交给 SOLO，例如 docker-compose.yml 这种一旦错误就会影响整个开发环境的配置。

这是一个非常复杂的微服务和多语言工作流实战项目，类似于 coze 或者 dify。

我给它的提示词其实非常简单，只描述了目标和约束条件。但 SOLO 会自动补全上下文，规划服务编排顺序，考虑依赖启动关系，甚至将最终给同事的操作说明一并生成。

我现在希望在 docker/PaiFlow 目录下新建一个 docker-compose.yaml 文件，将 console 下的 backend、frontend 以及 core-workflow-java 打包在一起，前置环境包括 MySQL、MinIO、Redis，使用的 JDK 为 21，并且我需要一份完整的教程，告诉同事们按照什么样的顺序进行打包并通过 Docker 运行。

如果不想自己动手验证，还可以让 TRADE 亲自为我们进行验证，若发现问题，它也会主动思考解决方案。

验证通过后，它会给出链接让我们直接点击体验。这种完整闭环的能力，显然超越了传统“AI 辅助写代码”的范畴。

还有一个常被忽视但对长期项目极为重要的点：SOLO 的上下文管理。

它会明确告知你当前上下文的使用情况，必要时进行自动压缩，确保关键信息不丢失。

同时，你也可以手动控制上下文，确保复杂任务在对话变长的情况下不会“失忆”。

这一点实际上反映了对真实工程场景的深刻理解——业务不是简单的一问一答，而是一个不断推进的过程。

这是我最频繁且依赖 TRADE 的一个场景。接手老项目，最令人困扰的从来不是代码量，而是上下文的缺失。

这里的写法为何如此？
这个字段是哪个版本引入的？
这个分支是为了解决什么问题？

过去我只能依赖翻阅文档、询问他人或查看提交记录，而现在我会直接让 TRADE 参与进来，基于代码结构和调用链，帮助我推测设计意图。

在这一点上，TRADE 表现得无可挑剔，是我在所有 IDE 中体验最好的，没有之一。

探索 TRADE 的强大功能与未来潜力

例如，当我询问它：“ES 是如何存储数据的？”TRADE 会全面分析源代码，并提炼出对我最有帮助的信息。

它能够清晰地说明索引的结构。

{
  "mappings": {
    "properties": {"chunk_id": { "type": "keyword"},
      "chunk_content": {
        "type": "text",
        "analyzer": "ik_smart"
      },
      "chunk_vector": {
        "type": "dense_vector",
        "dims": 1024,
        "index": true,
        "similarity": "cosine"
      },
      "source_file_name": {"type": "keyword"},
      "source_file_md5": {"type": "keyword"},
      "user_id": {"type": "keyword"},
      "org_tag": {"type": "keyword"},
      "is_public": {"type": "boolean"},
      "created_at": {"type": "date"}
    }
  }
}

每个字段的具体用途如下：

chunk_content：这是关键词搜索（BM25）的基础数据，当用户进行关键词查询时，ES 能够准确地处理中文分词并进行匹配。
chunk_vector：保存由 Embedding 模型生成的向量，与 chunk_content 相对应。维度 2048 必须与所选 Embedding 模型的输出维度完美匹配。
user_id、org_tag 及 is_public 为权限和归属相关字段，用于标记此知识块归属的用户、组织，以及是否公开。

这些信息对于理解项目至关重要。

从行业的角度来看，人工智能开发工具正处于一个重要的转折点。2025 年将是一个显著的里程碑：

AI 不再仅仅是“能否实现”，而是“是否能够持久融入工程体系”。

能够带来真正价值的工具，必定是减少工程中的摩擦，而不是增加新的学习负担。

为何我对 TRADE 未来的发展充满信心？

因为它选择了一条虽然缓慢但正确的发展道路。

没有急于追求花哨的功能，也没有急着讲述故事，而是踏踏实实围绕开发者，专注于提升“好用”的体验：上下文管理、可控执行、Diff 透明、任务可追踪等，确保工程节奏不被打断。

在当前市场环境下，这种专注显得尤为珍贵。

从模型迭代的节奏来看，TRADE 显然是在为长期使用做好准备。

国际版内置模型不断更新，保持在前沿水平，支持 GPT-5.2、Gemini-3-pro 等，且上下文窗口扩展至 272k，这在本质上为复杂工程任务留出了足够的空间，而不是仅仅服务于一次性问答。