字节旗下的编程工具Trae海外版终于对外发布了SOLO模式，我周末去参加了线下活动，深度体验了一波。我可以很负责任的说，Trae背后的研发团队算是把vibe coding玩明白了。
Trae群友线下活动@长沙
虽然阿里发布了Qoder、腾讯发布了codebuddy，对比起来codebuddy初始化友好，但是在整体生态上Trae跑在前面，开发者体验也更舒服，而Qoder可能还没想明白编程agent对程序员（甚至非程序员）价值的底层逻辑。现场，我们见证了一位小小年纪的孩子，用AI开发了自己的游戏平台的奇迹，也看到产品经理们对使用AI编程工具来实现自己想法的热情。那么，作为新的编程范式，Vibe coding到底意味着什么呢？这篇文章，我会从Trae的SOLO模式的一些特征讲起，深入聊一聊编程Agent和Vibe coding的一些想法。
SOLO带来交互新体验，新的coder agent很亮眼
当把Trae切换为SOLO模式后，整个编辑器的界面发生变化。主体区域变为与Agent的对话区域，而文件目录、代码编辑器变为参考区域。意思很明确，打开SOLO，进入真正的Vibe coding时代。
SOLO模式下，与普通的Vibe coding工具相比，主要多了两个重要的东西：
- 多任务系统
- SOLO Coder Agent
我理解，SOLO Builder和原来我们用的builder智能体区别不大，它的底层逻辑应该是一样的，只不过因为vibe交互形式，它放出了更多的信息，让开发者可以减少对实际代码的关注，而把重心放在对话内容所展现的vibe coding过程的处理上。但是，新增的SOLO Coder这个新的智能体，和Cursor的Agent非常像。对于这个Coder Agent，它的核心亮点在于：
- 它增加了可选的Plan阶段，而且我们可以自己去修改它Plan的文档
- 有一个Todo-list，可掌控当前进度
- 非常细致且友好的消息展示，不再是为了展示消息而把所有对话都展示出来，而真的为了让你理解编程过程而展示对应的过程性内容
- 对研发全流程的深度支持，从编码到构建再到发布，一条龙打通
它现在拥有两个（虽然界面上是3个）Agent，总结起来，Builder Agent适合从0到1，是一个我们过去常见的编程助手；而Coder Agent适合深度开发，是一个独立的工程师（当然还可以配合工具扮演其他角色）。
我和小伙伴有一个共同的感觉，就是Trae的Coder更适合表达为“对标Claude Code，同时拥有Cursor的多任务模式”。而Claude Code是目前最优秀的编程Agent，不仅仅是因为它有最优秀的编码大模型作为后端，更重要的是，它把vibe coding这种编程交互形式，与传统研发流程进行了完美融合，在其运行过程中，我们能感觉它是真的像一个程序员一样在做事。
此外，这次Trae带来的多任务体系，也可以大大提升我们的开发效率。多任务意味着，一个agent在执行的同时，可以再开一个执行进程，多管齐下，更快的完成项目目标。在Cursor的新版本上，我们也看到了多任务的能力。可见这也是一个非常重要的功能。
Vibe coding的终极诀窍
接下来，我想聊一聊，Vibe coding的诀窍。说是诀窍，到不如说是掌握vibe这种交互形式的基本技能。为什么是“基本”技能呢？这是因为我们必须了解一个工具的所有使用方式，或者说掌握其完成目标的原理，才能真正在工作或生活中用它来完成自己的创造，而不是仅仅是把玩一个玩具。那么，我们现在开始吧。
高级的提示词引导
我们有一个让大模型角色扮演的习惯，比如“你是一个具有10年前端开发经验的编程专家……”，通过这样的指令，我们试图让LLM成为一个在前端开发方面无所不能的上帝，可以满足我们的任何需求。然而，事实上并非如此简单。对LLM的提示，也并非越详尽越好，产品经理把自己的产品文档丢进去，试图希望它可以完美输出一套代码给我。这些做法都是有问题的。
那么，到底什么样的提示词才是好的呢？
我们要明白一个最基本的道理，即我们使用LLM的本质，是借助它的预测机制，实现推理。那么，什么样的提示词，有助于使其预测按照我们预想的方向进行推理呢？一句话“有高度相关性的提示词”。
我们在提示词中不仅要明确它的角色，还要为它量身定制任务的各项条件，包括但不限于：
- 角色定位
- 拥有的能力
- 任务的背景
- 任务的目标
- 方法论
- 项目规则
- 具体实施路径
- 验证方法
不仅仅局限于这些，不同的场景下，我们可能还会有更多的条件可供提供。当有了这些之后，我们还要提供能够激发大模型按照特定模式预测的上下文，这些上下文可以起到提供资料、提供参照案例、提供当前状态等引导大模型方向的内容。
这也就是为什么，AI距离我们普通人很远的原因，因为我们很多人，无法拥有足够的耐心，坚持到把提示词写好。因为AI的速度很快，所以我们会把自己写提示词的时间，和AI返回结果的时间做对比，写太多提示词就会觉得自己亏了，于是就草草归咎于大模型很傻。
如果想要获得于自己目标一致的结果，那么形成一套自己的提示词模板，或者借助一些市面上的prompt template生成工具，把自己的需求变为以上所述的提示词模式，或许对你的帮助会非常大。
大模型的灵活搭配
在一个编程工具中，我们并非只能依赖一个大模型。已知目前市面上的大模型，claude 4.5在编程领域遥遥领先，但是在任务理解、计划、工具调用这些方面，则其他模型可能更有性价比。我们看到GPT-5.1 codex有非常优秀的稳定性，输出虽慢但效果稳定的好，得益于它的思考能力强于市面上所有模型。Deepseek-R1的思考能力也不弱，价格却是骨折价。工具调用上GLM-4.5就已经是极致性价比，更何况还出了4.6版本。Grok-code凭借出码速度超快的特点，即使价格不便宜，也照样霸榜编程模型盈利榜首。
将专业的事交给专业的模型去做，得到的结果必然是最高水准。
不懂Agent等于不会Vibe编程
通过对编程领域的深度研究，并且与AI的特征结合起来，开发出既有通用性，又有针对性的Agent，提供给不同场景下的用户用来做Vibe coding，这就是当前所有编程项目在做的事。将这些Agent以看得见或看不见的形式，植入到各种系统或软件中，就有了我们常见的Cursor、Trae。那么，究竟什么样的Agent，才是好的vibe coding智能体呢？
我认为可以从以下几个方面去评测：
- 对研发流程的把握程度，是否可以覆盖完整的研发流程
- 是否无需过多配置，就可以达到90分的开发准度
- 是否能够给出结构严谨的代码目录结构和代码块
- 运行过程中是否需要开发者重度参与
- 运行结果是否可以一次性满足开发需求，而无需“AI善后工程师”
- 过程是否有清晰的反馈，是否对开发者足够透明
- 是否有足够高的自定义权限，例如接入工具、MCP、创建子Agent、提供项目规则等
- 执行过程是否准确遵照计划指示
- 修改是否可回退
- 速度是否很快
- 整个编程过程，开发者是否有大量心智负担
- 操作界面是否友好
满足上面这些点的agent或应用，往往会给我们非常舒服的开发体验。
构建Agent开发团队
单一Agent完成庞大项目不是一种好的实践，根本原因在于LLM上下文长度过长时，会严重影响其性能。将项目拆分为各个部分、工作环节、输入产出，为项目的阶段、里程碑设立“负责人”，通过搭配不同Agent为一个小团队，最终完成整个项目，是一种理想的vibe coding的工作模式。这个过程非常枯燥，它考验开发者的项目管理能力，要学会安排任务、分配工作、知人善任。
在Claude Code和Trae中，都支持创建自定义的Agent。虽然提前创建Agent是可行的，但是如果不在具体项目背景下去创建，往往陷入非常空洞的通用性描述。我的建议是根据项目的实际情况，在必要的时候不要犹豫，立即去创建subagent，然后更新项目的角色任务表和工作流程文档。
我们对每一个subagent的职责、能力、工具流程有了清晰的定义后，我们就可以像老板管理员工一样，指挥我们自己的开发团队完成当前的项目目标。而把不同的阶段目标、特定开发目标分散开，可以降低主Agent的性能压力。同时，subagent内部也可以多翻调优，以达到更好的编程效果。
完善的项目规则
在所有AI员工之间需要有一个共识，遵循同一套规则来完成处理、构建、生成。这些规则可以包括任何原有项目中的规范，例如：
- 代码规范
- 工作流程
- 模块规范
- 业务数据展示规范
- 版本管理规范
- 项目部署规范
除此之外，还可以将在过去vibe coding中发现的一些有益的规则也总结起来。通过这些规则，约束agent的行为，以获得更好的控制力。
合理的上下文工程
直白的说，上下文工程就是研究应该将哪些信息塞到与LLM的对话历史消息中去。构造（假装存在）历史消息，即我们所说的上下文工程。如何做上下文工程，有很深的学问。由于LLM的上下文长度越长，它的性能越差，执行的时间也越长，所以对上下文进行优化就成了一项重要的工作。目前已知的优化上下文的方法论有：
- 上下文压缩/稀疏化：摘要+关键点提取
- 注意力机制优化：通过算法给上下文中的内容打分，只关注最相关的部分
- 检索增强（RAG）
- In-Context Learning：高质量示例+思维链
- 窗口管理：只保留时间较近的消息，旧内容被剔除
- 分层管理：将上下文分为长期记忆、短期会话、实时触发，采用不同策略管理这些消息
- 功能隔离法：将不同的消息进行分类隔离，根据不同流程或场景，由不同agent进行执行，而每个agent所选的消息类型不同，例如对话agent只把“修改代码是否成功”作为消息，而忽略生成代码过程中的代码细节，而负责生成代码的agent不需要读取详细的任务规划
上下文工程不仅是提高Agent性能的关键，也是准确实现vibe coding目标的关键。当然，这个往往已经被编程软件自己做了，对于我们开发者而言，可以通过观察，来了解哪一家的软件在这方面做得更好，就可以选择使用这家软件。
构建工具、MCP调用流程
将一个工作流程视为一项能力，创建一个子智能体，将实现这项能力的相关工具或MCP Server添加到其中，并为它创建完成工作流的提示词工程和上下文工程，此时，这个子智能体可以按照流程设计，调用工具，实现既定的能力。
MCP作为既定标准协议，可以作为架构底层协议，完成Agent的架构设计。现在，几乎所有的vibe coding工具都支持MCP。通过MCP，可以调用本地软件、程序完成对本地文件的读写和资源操作，也可以将第三方服务封装为MCP Server后使用云端服务能力。此外，Agent与Agent之间也可以基于MCP进行交互，将Subagent作为一种特殊的工具，被其他Agent以通用MCP Server的模式进行调用。如此构建上去，一层一层的合理设计，最终就可以形成我们自己的编程Agent架构。
通过组合工具，按流程调用工具，Agent几乎可以完成编程工作中的绝大部分事，包括但不限于从创意的调研、数据的整理和挖掘、产品的概念设计、原型的创作、POC、UI设计、编程、构建、部署、监控，这些工作通过工具及合理的流程安排，几乎都可以做到。开发者的角色，更像是乐队的指挥。
设计严谨的编程步骤
在编程工作中，先做什么再做什么最后做什么，对于现实中的开发者是很容易的，但是对于AI来说，却异常困难。因此，编程步骤往往都被内置在vibe coding的工具内部，由固定的代码来执行。
当你发起一个编程任务时，工具能否以严谨的步骤完成你的任务，对于产出来说是很重要的。
例如，“对任务进行理解 -> 拆分任务步骤 -> 为每一步建立验证节点 -> 为每个任务分配执行者 -> 开始执行任务 -> 实时反馈 -> 进行验证 -> 完成任务”这是目前非常流行的一种分步逻辑。它的核心理念是将Plan和ReAct两种模式结合起来，提升AI在整个任务中的整体性能（而非只关注某一个细节过程的性能）。
对于我们开发者而言，寻找拥有更严谨编程步骤的vibe coding工具，以及构建自己的这种步骤规范，是提升vibe coding能力的又一体现。
设计优雅的vibe交互体验
优雅永不过时。作为一种新的编程范式，在编程本身的交互体验上，也需要演进。
首先，从typing code（敲代码）的形式，演变为chat builder（文字聊天）的形式。通过文字，我们可以通过 @ 来指挥智能体，通过 # 来引用代码或资源位置，能够像师傅带徒弟一样，一步一步的指挥AI生成新代码或修改老代码。但是，文字输入还不够geek，因为你必须有一个键盘。
接着，从typing-chat形式，演变为talking-chat（说话聊天）的形式。随着全模态模型的成熟，端到端的语言交流已经成为非常容易的事。需要区分talking和speech-input，通过语音转文字的输入本质上并没有改变底层的逻辑，而且会丢失通过 @ # 来进行快速引用的便捷性。而真正的说话聊天，要求AI能够在复杂的上下文中，准确捕获你的意图，并且在无需明确引用的情况下，准确修改或增加文件，这对Agent的设计要求更高。当talking coder成为主流时，产品经理们完成无人开发即可上线产品的梦想，或许就不远了。这让我想起当年老罗那一款让人“下尿”的产品，过于超前。
最后，从单一的IDE界面，演变为全场景的交互形式。当我们想要将看到的物品，作为应用中的元素的时候，我们不得不进行非常复杂的预处理，比如手机拍照或屏幕截图到仿照生图，然后再让AI将其处理为应用中可用的图片格式。但是，当我们带上类似苹果的Vision Pro这样的设备，我们就不再需要一台真正的电脑，它可以锁定我们的目光，对我们眼中所看到的事物进行云端建模和处理；可以锁定我们的手势和动作，结合目光焦点来理解我们的意图；通过说话来与我们进行需求确认，并以更拟人的方式，与我们一同完成编程工作。让我们来看一段想象中的编程方式：
这种充满未来科技感的编程形式，或许就是这一轮vibe coding的终章。
结语
本文从Trae SOLO模式的发布展开，详细阐述了vibe coding的各个环节。作为开发者，我们当然希望通过vibe coding这种形式，提升我们的开发效率，然而如果我们没有理解其运作的原理，用起来就会感到吃力，最后可能也只是看了看热闹，无法转化为自己的生产力。通过本文，我希望朋友们能从我这个经历者的视角，去重新审视一下vibe coding，在什么场合适用，什么场合不适用，都可以做到心里有数。当然，你可能还有一些疑惑，可以在下方留言区留下你的思考，让我们一起探讨。
2025-11-17 1395
