先导：kiro与trae solo的整体风格对比
市面常见的AI 驱动 IDE有两个另类：trae和kiro。
字节真的在把用户当作0基础，秉持 “零基础友好” 的理念，致力于实现Vibe coding；而亚马逊出品的 Kiro 直接给出vibe coding模式，结合工程化严谨开发的范式，更受到技术背景产品经理的青睐。
| Kiro vibe coding | Trae Solo builder | Kiro spac coding | Trae Solo coder | |
|---|---|---|---|---|
| 开发风格 | 用户主导 | agent主导 | 用户主导 | agent主导 |
| 文档类型 | / | / | 产品经理--用户故事 | 项目经理 |
| 工作流 | 交互开发 | 全流程管理 | 需求澄清-设计-测试 | 开发计划-执行生成 |
| 模型 | claude | Grok、Gemini、kimi | claude | Gemini、kimi |
| 特色 | 交互追问，有助于梳理、明确需求 | 全流程管理。包含前期交互到后期部署上线，小白友好 | 支持vibe coding转化为spac coding；工作流 明确，保证输出的稳定性一致性 | 近乎实现0代码。 创造力更强，对有创意的非开发者能提供更强大支持 |
| 适用于 | 主观能动性强、探索性，简单项目开发 | idea快速落地验证，产品demo快速实现 | 工程化项目迭代；需求明确的产品开发 | 非精准实现方式，但明确目的项目开发 |
kiro是亚马逊出品的AI 驱动 IDE，界面风格主色调为紫色。ai对话样式为右上角的对话框，支持左右双侧调用，整体布局与传统IDE有一些区别。
kiro在支持模型上优势是支持claude 4.5。新用户注册送500信用值，相当于对话token的折算，不同模型对应credit不同。实践验证可知，一个简单的网站开发使用20-70左右。但想要基于长上下文复杂开发消耗偏大。
ai对话栏里同样支持三个实用功能：通过#引用内容，包括代码、文本等；上传图片交互；集成内容使用率（圆环），当上下文过长时（超过80%），工具会自动总结压缩，通常压缩到20%左右，以此实现对话开发的持续。
不同于其他类型的ai辅助编程IDE，Kiro更偏向于工程化实践和产品开发。分为vibe coding和spec coding两种模式：
- 只有idea的时候建议使用**
Vibe Coding**模式，快速产出可用产品； - 有产品demo时，可以使用**
Spec Coding**模式，聚焦迭代优化和落地。
个人成果展示：My Trae Project
Vibe coding based on kiro
-
初始交互
点击左上角文件夹，新建或打开一个文件。之后输入提示词，开始和Kiro对话。
注意，如果先对话，kiro会让你打开文件夹后继续交流。但打开后文件夹后会是新对话，所以此步注意要先新建/打开文件夹。
对话框中输入提示词，尽可能完善的描述需求。Vibe模式会优先构建可实现思路，通过交互解决不确定性，给出选项帮助用户明确实现路径。
提示词：
你是一个资深软件产品经理。
我现在在设计一个网站。功能是用户输入对应的人，比如说父母，导师等，可以自动生成新年祝福词。
我想和你一起进行交互设计。整体的页面风格我希望整洁，科技感强一些，然后有对应的交互动画，切换丝滑。
但是需要注意的是，我没有太多网站部署的经验和设计经验，我希望你能一步一步来带我做。文件夹已经帮你打开了，开始？
-
开发执行
智能体开发模式时（默认），会弹出命令运行指令，需要用户手动操作。可取消，信任此命令并运行，直接运行：
对于简单命令可直接“trust”，避免重复工作
trust：点击紫框后，点击”打开设置“，添加命令白名单（agent会自动添加）后，即可自动继续运行。
当Kiro显示working状态时会自动推进开发，但部分场景下后台进程**background process会需要用户手动点击继续**（右侧会出现倒三角按钮）：
-
页面生成
通过安装库、依赖，交互，测试后，顺利生成网站：
为快速验证交互流程，初期Demo在代码里会内置固定的祝福词模板。页面的逻辑没问题后，可以专心集成api。
api获取方式：智能体经典范式构建
-
api 调用
直接在对话里告诉kiro你要调用的模型，并生成环境变量.env。等待其创建完成后，填入api即可。
手动或告知kiro把 环境变量 添加到 .gitignore，避免误提交到Git。
-
深度修改
当前生成的demo会比较简陋，一些按钮功能没做出来，我们可通过语言交互把偏重要的修改先做出来，比如：
- 返回按钮；
- 逻辑不自洽的地方。
一种常见的kiro使用方法是：vibe模式生成 MVP 原型-->切换 spac 模式完成后续迭代
因此，上述对应的修改同样可以放到spac模式迭代。但基础的逻辑问题放到vibe模式亦可。
到此为止，我们基于**vibe coding**模式生成的小网站就可以正常使用了。
Spac coding based on kiro
**Spac coding**模式与vibe模式最大的不同在于，Vibe 模式是直觉导向的自由对话式开发，Spec 模式是规范驱动的结构化规划式开发。简单来说：
- Vibe 模式像聊天一样直接下达需求，kiro会即时执行；
- Spec 模式需先明确规范，输入需要更加完善。包括页面有什么，逻辑关系等等。甚至直接把vibe开发的项目包丢进去。随后spac模式会通过结构化文档固化需求、设计和任务，再推进开发。
本节中，我们分别尝试两种方式使用spac模式完成并完善新年祝词小网站。
-
vibe 模式继承开发
（1）模式转换
- 自动转换： 当我们输入词中可能包含（需求文档，新开发，迭代等等），kiro会自动分析我们想要进行规范化开发，从而转向spac模式。此时在页面中点击
Yes即可转换模式。 - 手动转换： 直接在对话页面新建 Spec 模式对话，导入 Vibe 模式开发的项目包，延续开发流程。
提示词：
假设现在你是产品经理。现在帮我生成该网站的需求文档，或者是逻辑文档。我交给其他开发同事去做。
注意：内容不要太多，不要分点，简单描述内容、逻辑关系、设计风格即可
（2）版本迭代
在spac模式下，更新生成新模块需要更结构化的描述才有助于开发。
提示词：
我现在需要开发一个新功能：“主题”功能。
背景：考虑到直接生成祝福词太宽泛，容易被误解为群发，因此需要新增该功能，了解用户背后故事。
示例：为李老师生成祝福词，主题：感谢指导论文，感谢帮我提供找工作的思路。
设计：类似于自定义关系的的文本框，同样为非必填。
生成：最后生成内容交给大模型，关注主题和对象来生成祝福语。
调用你的spac工作流，帮我完成开发工作
该模式下会生成requestments,design,task list工作流对应的核心文档，逐步完成开发。请首先确定需求requestments是否有遗漏或逻辑问题。
（3）设计阶段
需求澄清后，点击move to design phase 转到设计阶段。
设计文档生成后，检查（该文档偏专业一些，建议直接跳过到下一阶段），若无问题点击右下角进到测试阶段。
（4）测试阶段
通常会给出全面测试和必要性测试。根据任务强度自选。
测试可以使用run all tasks（适用于完全测试）,或者kiro对话框交互一个一个来测试。
需要注意的是，测试通常耗时较长，耗费credit较多，过程中新增极多测试文件，报错重测概率高。如若简单任务或不涉及模型调用，建议简单测试即可。
tips： task list 中会实时显示测试进度：完成后用绿色标注，进行中为蓝色，未测试为灰色。
（5）后续优化
完成后打开网站实测：
测试正常后，清除不必要的文件，交给kiro自动解决。
至此，我们的网站开发顺利完成。
-
严谨输入开发
在前文，我们基于vibe模式将我们的简单意图实现为可用demo，之后通过转为spac模式，通过其需求--设计--测试工作流，完成了更新迭代。
除了继承 Vibe 模式成果，Spec 模式也支持直接导入 PRD启动开发。在本节，我们首先使用上一节开发的网站，用kiro生成相应的PRD。随后复制给spac coding直接开发。后续流程同继承式开发。
生成简单、逻辑自洽、不分点的PRD即可。无需过度冗余内容
Kiro Summary
- Vibe 模式优势： 通过对话梳理模糊需求，快速产出 MVP，逐步完成开发。但其测试的缺失会导致报错频繁。
- Spec 模式优势： 通过 “需求 - 设计 - 测试” 三步工作流，输出的内容稳定可靠。但单独使用spac模式会显著把问题复杂化，直接导入 PRD就会部署出功能过度冗余、测试流程繁琐的产品。且前期自动生成过多导致后期修改空间小，更加不可控，对新手友好度低。
综合来看：
- 对于一个不明确或者偏模糊的idea，建议使用vibe模式先澄清需求，产出mvp后转到spac开发迭代。
- 明确的需求可以用spac，但要求使用者明确产品开发的全流程，包括后期部署、性能测试等，从产品经理的角色兼顾项目经理的角色---这点是kiro使用中常见的误区。如果不具备专业知识储备，不在前期多介入交流，后期很可能被agent牵着鼻子走，难修改。
- 对于非专业开发人士，或只想手搓一些可用小玩具的用户来说，无论需求明确与否，vibe模式入手多介入，再转 spac 开发迭代小模块，可能仍是最优解。
Vibe coding based on SOLO Builder
Trae Solo 是字节系 AI 开发工具，0119版本更新后，TRAE国际版SOLO模式下的智能体包含**SOLO Coder**和 SOLO Builder。
二者核心区别在于适用场景、核心能力与协作模式，前者侧重复杂项目 “从 1 到 100” 的迭代重构，后者专注 Web 应用 “从 0 到 1” 的快速搭建，二者互补覆盖全开发流程。
---本质上来说，和kiro是类似的，但ai会主导更多。
开发前，加入一些智能体辅助开发：
[最佳实践 海外版]8 个支持一键导入 TRAE 使用的自定义智能体
| Kiro（Vibe/Spec） | TRAE SOLO（Builder/Coder） | |
|---|---|---|
| 轻量模式 | Vibe：快速对话式编码，无强制文档，适合原型 / 探索 / 小改，自由灵活 | SOLO Builder：自然语言→自动选模型→生成 PRD→出可预览成果，一键部署，面向快速落地 |
| 规范模式 | Spec：先产出 requirements/design/tasks 三文档，结构化规划后编码，适合复杂项目 / 团队协作，可追溯可控 | SOLO Coder：需求分析→任务规划→多智能体编排→迭代重构，适合已有代码迭代 / 架构优化，支持人工介入 |
| 设计理念 | 从 “vibe coding” 到 “viable code”，覆盖创意到工程化全流程 | 从 “0 到 1 快速搭建” 到 “1 到 100 深度开发”，互补覆盖原型到成熟产品 |
| 工具定位 | AI 驱动 IDE，侧重编码环境内的开发协作 | TRAE 平台的智能体，侧重全流程任务闭环与智能体协同 |
| 二者差异 | 流程上： Kiro Spec强制生成三文档（需求 / 设计 / 任务），SOLO Coder：自主编排多智能体分工。 |
-
主页面介绍
相较于kiro，trae的可视化界面布局传统，模块、按钮更完善。对于国内新手开发者而言，无论是CN版还是国际版，中文的使用能够贯彻全流程（对话中英文与否和取决于搭载模型）。而kiro的中文语言设定只在状态栏生效。
界面左侧为任务栏，更像是常见的大模型对话模式，可开启多个任务。智能体布局在中间，表明了其“ai主导”的决心。右上角的实时跟随可以透明化看到trae在编辑哪些文档。
对话框里和kiro类似，开始对话后也会有上下文使用率。有对话优化功能，帮助用户优化提示词对话文本等。
使用同样的提示词，交给builder。在solo模式，默认模型只有Gemini 3和kimi K2。此处使用Gemini 3 pro进行开发。
-
交互生成demo
builder模式也会生成简单的 PRD，相较kiro的工程化文档，更偏向于一个C端产品经理的输出风格：
生成PRD后更多的是返回用户“有了什么”，而不是讨论详细的细节，给出的更像一个汇报。
对于模糊需求的用户会省心，方便偷懒。但没有深入交互的生成，对一些偏严谨细致的需求者会更“累”，需要主动去修改。
-
成果及部署
trae生成网址后会给出预览，并默认vercel部署选项。在应用拓展的便捷性比kiro做的好一些。全程托管对于懒人来说省事很多。而且经过多次生成对比，trae生成页面的风格、颜值确实（可能）要高一些。
为保证对比一致性，添加一些功能：
提示词：
1.新增“编辑”按钮，不只有复制和换一句，允许生成后用户自己编辑。
2.给出一个用户输入选项，让用户自己输入祝福对象。
3.打开api填写页面我来填写。
返回结果：
最终第一版本更新如下。预览页面提供元素选择和更改功能，可以快速进行定向调整。
最后测试能否自动转入solo coder模式，失败 。只能手动转。而且在对话框中直接转模式并不会影响风格。
-
SOLO coder模式 继承 开发
在左侧任务栏新建任务，选择coder模式继续开发。
在开启plan模式之前，输出内容并无差异。主要差异在推理过程。
最后生成如图所示：
功能描述：
产品概述 本项目是一款基于 AI 的智能祝福语生成工具，旨在帮助用户在不同节日和社交场景下，快速创作出得体、个性化且富有文采的祝福内容。核心价值在于解决传统模板千篇一律的痛点，通过多维度的参数配置，让 AI 生成真正符合用户具体情境的专属文案。
核心逻辑与功能 产品的交互逻辑围绕“四维配置”展开，用户依次确定四个关键参数：节日场景（如新年、生日，决定了 AI 的基础人设）、祝福对象（如父母、领导，决定了语气亲疏）、语言风格（如古风、幽默，决定了行文格调）以及具体主题（如“感谢提拔”，用于注入个性化背景）。前端将这些参数动态拼装成结构化的 Prompt 发送给大模型，确保生成内容精准命中用户需求。生成结果通过弹窗形式展示，支持打字机动效以增强交互感，并提供一键复制、二次编辑和重新生成功能，形成了从配置到获取再到优化的完整闭环。
UI 设计风格 界面设计采用极具未来感的赛博朋克与毛玻璃（Glassmorphism）风格。视觉上以深色背景为主基调，搭配半透明的磨砂玻璃卡片容器和高饱和度的霓虹光效（蓝紫色系），营造出高端、科技的氛围。交互层面强调流畅性，弹窗的缩放出现、按钮的微交互以及文字的逐字显现，共同构建了沉浸式的使用体验。
Spac coding based on SOLO coder
Coder 模式是 Trae Solo 的深度开发模式，开启plan功能后，将展现与 Builder 模式的核心差异。
将上一阶段生成的PRD文档复制发给trae。让其自动规划开发：
与kiro类似，plan模式下工具会自动生成项目管理视角的开发计划书，涵盖技术栈选型、开发步骤规划、UI 风格定义等核心内容，区别于 Kiro 的工程化需求文档。点击 执行 进到下一步。
通常在自动执行时，工具会将开发任务拆分，分配给多个 Agent 协同完成。开发过程中，在终端or对话端需要用户操作，但不会提示。
最终生成页面如下所示：
与builder模式不同，coder模式生成网站默认不帮助用户部署，但同样在右上角有部署选项。开发效果也会随着PRD的详细程度变动。
Trae Solo summary
- 总体来说，Solo模式的核心优势在于Agent 强主导性，主导设计、开发的意识，对简单、模糊需求用户很友好。可视化界面与一键部署功能大幅降低开发门槛。
- 而builder模式正如其宣传的 “全链路协同” ，从简单的需求编写到上线部署，核心是帮助用户 “从 0 到 1” 的创意落地。
- 如果是高精准项目，除非用户清楚自己“要什么”，不然builder模式输出的模糊需求文档带来的不确定性，可能会导致后期更新迭代困难。即使有上下文压缩功能，也会由于agent主导的开发思路导致用户需求的忽略。最终变成一个普通的对话agent。
- coder模式在不开启plan时输出风格结果相近与builder，同样的agent主导，对项目拆分规划，自主修bug，多智能体协同开发。开启plan模式后给出的文档不同于kiro的requestments，整体风格更偏向于项目经理的角度，开发技术栈、ui风格、步骤等等，同时此模式下会将任务拆分交给多个agent自主开发，也会导致结果与模型的风格，能力更相关。
常见问题
1.node.js安装
建议在打开kiro前先安装，避免出问题。
2.kiro Operation was aborted by user or system. The agent has seen this error and will try a different approach to write the file if needed.
等会重新生成，或者换个网络。
3.An unexpected error occurred, please retry
直接发送：Continue
4.部署平台
才疏学浅，欢迎各位大佬指导交流经验。
