上周使用 TRAE 的时候，系统弹出一个提示框，嗷嚎，TRAE SOLO 居然上线了独立的客户端，桌面版和 Web 都发布了，目前是 beta 版本，限时免费体验。
SOLO 提供两种模式，可以在右上角切换，一个专注于 Coding，另一个是 MTC 模式（More Than Coding）：作为一种对话式 AI Agent，可以做文档创建、数据分析、报告生成、制作 PPT、竞品调研。
简单来说，SOLO 被拆出来之后，放弃了 IDE 的模式，编码层面类似 Claude Code 和 Codex，MTC 模式则是类似龙虾的 Agent，这个野心不小啊。
后续我看了一场 TRAE 的直播，TRAE 团队分享了构建 SOLO 的过程，真的是有一些干货在的。
SOLO 这个产品有 100 万行代码，共 9000 多次提交，93% 的 AI 代码贡献度……可以说，SOLO 自己开发出了 SOLO：他们用自己做的 AI 编程产品，完成了这个产品本身的绝大部分开发工作。
"吃自己的狗粮（Dogfooding）在科技行业不算新鲜事。微软用 Windows 开发 Windows，Google 用 Chrome 承载自己的搜索能力。不过，用 AI 产品开发 AI 产品这件事的味道有点不一样了：它更像是让一个正在学走路的孩子，同时承担给自己造个摇篮的任务。能行吗？
1
我在之前的文章里写过，过去两年 AI 编程工具的演化路径非常明确，AI 从一个智能补全代码工具逐步走向完整开发一个功能模块的 Coding Agent，这个变化的奇点出现在 2025 年。
TRAE 团队的一位架构师回忆，2025 年他们对 AI 的预期还是能写写模板代码就不错了，到了后面，认知开始被自己的产品打脸。一位深度用户的使用报告显示，全年由 TRAE Agent 生成了近 30 万行代码，而智能补全（Tab）仅触发了 12 次。
12 次。这意味着整个工作流的重心已经彻底翻转了。
TRAE 团队在 2025 年全年发布了 100 多个版本，平均每 3 天一个。这种迭代速度本身就要求开发范式必须跟上节奏。传统的开发流程“产品经理写需求 → 几个工程师分模块开发 → 联调 → 测试 → 上线”，在 3 天一个版本的节奏下根本行不通。于是，他们探索了一条新路。
2
第一个核心实践叫“Spec-Driven”。
传统开发中，一个复杂功能通常需要多人分模块协作。需求拆解之后，前端、后端、基础设施各领一块，最后再联调。这个模式运转了几十年，前提是：人是第一生产力，写代码的人越多、越快，产出就越高。当 AI 成为代码的主要产出者之后，瓶颈就不再是写代码的手速，而是对需求的理解和方案的设计。
Spec-Driven 的做法是：一个功能由一名工程师全权负责。这名工程师不再亲自写大量代码，而是和 SOLO 协作，先输出一份完整的技术方案文档（Spec），明确架构设计、数据流、模块边界和关键实现路径。审查确认后，AI 按照 Spec 设计和编写代码。
这里有一个关键的思维转换。过去行业里流行 Vibe Coding 是给 AI 一个模糊的指令，看它能理解到什么程度。这在做 Demo 或者原型验证时效率非常高，一旦进入有复杂业务逻辑和多模块耦合的生产级项目，Vibe Coding 就会失控。AI 的理解偏差会在每一层调用中被放大，最终导致大规模返工。
Spec-Driven 本质上是通过某种方式把需求跟 AI 讲清楚。这就像管理一个能力强但缺乏上下文的新员工——你不需要教他怎么写代码，但你必须把“为什么这样设计、边界在哪里、可能遇到哪些坑”说清楚。
这就是一人成军，但对人的要求比较高，需要把 Spec 写好，然后带着 SOLO 在更短时间内完成功能。
第二个实践更有意思，叫“Skill 沉淀”，其实就是给 AI 加装记忆系统
做过软件开发的人都知道，一个项目最宝贵的资产除了代码就是存在于资深工程师脑子里的隐性知识——为什么这个模块要这样设计、两个服务之间有什么样的耦合关系、线上出过什么诡异的 Bug 以及当时是怎么排查的等等。这些知识很少被文档化，通常是口口相传。很容易流失。
TRAE 团队做的事情是：把这些隐性知识封装成 AI 可读、可执行的 Skill。
第一类是架构事实——项目的核心数据流、模块间的约束关系、历史设计决策的取舍逻辑。
第二类是问题排查路径——常见错误的分析思路、日志该看哪些字段、环境配置的注意事项。
这些 Skill 是给 AI 看的，是 AI 在执行任务时可以直接调用的结构化上下文。AI 变成了一个熟悉团队所有知识沉淀的老员工。经验不再依赖于人，而在于 Skill。
同时，Skill 还是知识库，一个新加入团队的工程师，也可以通过问答的方式查阅和使用 Skill 快速理解项目的核心脉络，而不需要找资深同事一对一答疑，团队的知识从个人资产变成组织资产。
第三个实践解决的是测试问题。
AI 写代码的速度提升了 5 到 10 倍，但人工测试的速度没变。这就有点尴尬了，代码产出飞快，但验收环节成了瓶颈。尤其是 UI 和交互层面的问题——某个按钮点击时状态不对，某个动画在特定设备上卡顿、一个边界条件下的弹窗文案有错别字——这些靠逻辑层面的自动化测试是没法覆盖的。
为此 TRAE 团队引入了 Chrome MCP（Browser Use）能力来解决这个问题。简单说，就是让 AI 能够像真人一样操作浏览器——打开页面、点击按钮、输入内容、检查元素，完成 UI 层面的回归测试。
这意味着 AI 能够看见自己产出的结果，完成从编码到验收的闭环。当出现问题时，AI 可以自主复现 Bug、查看页面表现、分析日志，像一个真人 QA 那样进行端到端的排查。
这三个实践——Spec-Driven、Skill 沉淀、自动化验收——构成了一个完整的循环：人负责定义做什么和为什么这样做（Spec），AI 的执行力通过积累的知识持续增强（Skill），产出的质量通过自动化手段验收。
3
任何流程和范式的变革都会带来新的挑战，TRAE 团队面临的真实挑战包括：
第一，个人速度不等于组织速度。AI 代码贡献率提升到 93%，整体交付周期确实变短了，但并没有同比例缩短。因为工程师节省出来的时间是碎片化的，不能直接转化为更多需求的承接。研发流程上下游角色的效能提升速率不一致，木桶效应依然存在。
第二，多人协同下的障碍。一个真实的例子：A 同事开发了一个页面，B 同事在做另一个需求时不小心改坏了 A 的页面。这类问题在需求文档里很难被精确定义，在自动化测试中也很难被完全覆盖。
第三，对代码的掌控感下降。当 93%的代码由 AI 生成时，工程师对代码库的理解不可避免地变得模糊。在项目中后期联调阶段，面对一个 Bug，工程师可能需要花更多时间去搞清楚 AI 当初是怎么写的、为什么这样写，bug fix 的难度有可能增加。
对此，TRAE 团队的判断是，AI 仍处于量变积累阶段，还没突破质变。93%的数字确实很漂亮，但真正的质变——组织效能的系统性提升——仍然需要整条研发链路的各个角色、各个环节同步完成 AI 化改造。
4
SOLO 的自我进化实验其实揭示了一个正在发生的行业趋势：AI 编程正从“产品能力”演变为基础设施能力。
两年前，“AI 能帮我们写点代码”还是一个惊喜，现在，AI 写代码已经是标配了，用户要的是一个能理解项目上下文、能在长周期任务中保持一致性、能在凌晨三点自动完成部署后回归测试的“数字同事”。
这个演进方向有两个维度。
纵向上，AI 的使用人群沿着研发链条上下延伸——从需求分析、设计交互、研发编码、质量保障，到发布部署、线上运维，不再只是程序员在用 Agent，整条链路上的角色都在从中受益。
横向上，每个角色使用 AI 的场景在拓宽——程序员不只是用 Agent 写代码，还用它做技术调研、写设计文档、整理会议纪要，甚至整理本地文件和知识库。SOLO 独立端同时提供 Code 模式和 MTC 模式，是对这个趋势的产品化回应。
5
TRAE 团队不仅仅是推出了一个新工具，更有价值的是这一整套方法论和**实践。
对企业管理者来说，我们需要重新考虑这么几件事：
人力结构上，工程师的价值不再体现在写代码的产出量，而在于架构设计、复杂逻辑判断和方案决策的能力。
知识管理上，Skill 化的思路值得借鉴——把团队中少数资深工程师脑海里的经验，转化为 AI 可执行的结构化知识，这比写 Wiki 有用得多。
研发度量上，代码行数、提交次数这些传统指标正在失去意义，取而代之的应该是方案质量、验收通过率和端到端交付时长。
人做设计和决策，AI 做执行。人负责积累可复用的知识，AI 负责把知识转化为一致的行动。人负责定义“好”的标准，AI 负责在这个标准下大规模交付。
这就是 SOLO 和 SOLO 的构建过程，给我们带来的启示。