Kiro 是什么？
Kiro 是一款由 Amazon Web Services 构建的可下载编码环境，它将 AI 辅助开发带向了这一类别中大多数工具尚未尝试的方向。
大多数 AI 编码工具会让你输入提示并立即返回代码，而Kiro 会先运行一个规划流程： 它读取你的项目上下文，编写需求文档，生成技术设计，将一切拆分为编号任务列表，然后才开始编写代码。
Kiro 可作为 IDE、命令行工具、网页界面（目前仅向付费用户预览开放）以及移动应用（iOS 早期访问）使用，定位于那些希望获得结构化、可维护输出，而不是一周后还得把代码一点点拆解重来的开发者。
Kiro 适合谁？
- 那些曾被 AI 生成代码在第一天后就崩掉而“受伤”的开发者。 Kiro 的规格工作流会强制先规划再实现，因此它编写的代码都能追溯到文档化需求，而不是凭猜测拼凑出来的。
- 正在转向 agentic 工作流的团队。 Kiro 的 Agent Hooks 让你自动化诸如编写测试或生成文档之类的重复任务，只要文件发生符合条件的变化就会自动触发，无需反复提示。
- AWS 生态开发者。 Kiro 构建在 AWS 基础设施之上，在你所在的地理区域内通过 AWS 区域处理数据，并且能自然连接 AWS 服务。如果你的技术栈已经高度依赖 AWS，Kiro 几乎无需额外配置就能融入。
- 想要比自动补全更深入的 VS Code 用户。 Kiro IDE 基于与 VS Code 相同的基础构建。你的键盘快捷键、设置和扩展会在几分钟内随入门流程一起迁移过来。
Kiro 的优缺点
- 规格工作流会先规划再写任何代码
- Agent Hooks 可在文件事件触发时自动执行任务
- VS Code 扩展和设置可顺利导入
- Autopilot 模式可在无需持续请求批准的情况下构建
- Steering 文档为 Kiro 提供项目上下文
- 支持多个前沿模型，包括 Opus 4.8
- MCP 服务器集成可原生连接外部工具
- 需要下载；免费层无法通过浏览器访问
- 50 个免费积分消耗得比预期更快
- 在需求细化阶段曾超时一次
评分拆解
Kiro 的最高分出现在功能与特性方面，其规格驱动工作流、Agent Hooks 和 Autopilot 执行使它领先于本文评测过的其他所有 AI 编码工具。它在可访问性和积分机制上略显不足，这两点在决定是否投入工作流之前都需要认真考虑。
| 功能 | 评分（满分 10） | 评分原因 |
|---|---|---|
| 易用性 | 7.0 | 对任何 VS Code 用户来说都很熟悉；下载要求和开发者专用属性让非技术用户难以使用 |
| 功能与特性 | 9.5 | 规格工作流、Agent Hooks、Autopilot、MCP 集成、Steering 文档：这是评测中最完整的 AI 编码工具功能集 |
| 设计与自定义 | 7.0 | 深色和浅色 IDE 主题；通过规格编辑和 steering 文档可对生成代码结构进行强控制 |
| 性价比 | 6.5 | 免费层的 50 个积分在规划阶段就消耗到了 4.28，还没写一行应用代码 |
| 性能与可靠性 | 7.5 | 规划输出细致且具体；在需求细化阶段确认有一次超时，发生在 7 分 24 秒时 |
| 总体 | 8.2 | Kiro 的规格工作流是迄今为止评测过的 AI 辅助开发中最结构化的方法。这个分数体现了它真实的差异化优势，同时也受到有限免费层和测试中记录到的那次可靠性故障的拖累。 |
Kiro 功能
- 规格驱动工作流：需求、设计、任务、代码
- Agent Hooks 可在文件事件触发时自动执行任务
- Steering 文档为代理提供项目上下文
- Autopilot 模式无需逐步批准即可执行任务
- 支持用于外部工具集成的 MCP 服务器
- 首次启动时可导入 VS Code 配置
- 支持多模型，包括 Claude Opus 4.8
我的真实 Kiro 评测：测试后我发现了什么
大多数 AI 应用构建工具只会落入两类之一：
- 一种是根据描述生成界面的可视化工具
- 另一种是基于聊天、直接根据提示编写代码的工具
Kiro 两者都不属于，这也是为什么评测它需要采用不同的方法。
Kiro 是一个 agentic IDE。你不会拖拽组件到画布上，也不会在 30 秒后看到实时预览。你得到的是一个本地开发环境，它会先规划构建再开始实施，生成需求、设计文档和结构化任务列表，然后代理按步骤逐一执行。
它生成的应用是真正位于你机器上的项目，文件归你所有，使用的是你定义的技术栈。
为了验证这个流程是否真的有效，我在 Kiro 内部从零构建了一个物业管理平台。
提示词涵盖了房东和租客认证、房产与单元管理、租约跟踪、带状态更新的维修请求、Stripe 支付集成、邮件通知，以及带报表功能的房东仪表盘。这与我用来评测 Rork、Figma Make、Uizard 和 Retool 的提示词相同，这使得比较每个工具如何处理真正复杂的场景成为可能，而不是只看一个简单示例。
本次评测要回答的问题很明确：Kiro 的规格优先工作流，是否能产出比直接写代码的工具更结构化、更易维护的结果？
以下是我的发现。
让 Kiro 运行起来：需要下载，而不是打开浏览器标签页
与本次比较中的其他 AI 应用构建工具不同，Kiro 并不是在浏览器中运行。开始使用意味着你需要访问 kiro.dev，点击 Downloads，选择你的操作系统，并在本机安装应用。
我使用的是 Pop OS，一款基于 Debian 的 Linux 发行版，所以我在下拉菜单中选择了 Debian（.deb）包。该网站也为其他 Linux 环境提供 Universal（.tar.gz）包。Windows 和 macOS 安装程序也可以通过同一下载页面获取。
这在实际中意味着：
- 首次会话需要本地安装，而不是浏览器标签页
- 免费层没有仅靠互联网访问的方式（网页界面目前仅向付费计划开放预览）
- 对开发者来说，这不是问题
- 如果你是在和浏览器型构建工具对比 Kiro，请把这部分设置时间算进去
安装过程本身很顺利。没有配置步骤，也不用手动解决依赖，应用在常规包安装后就顺利启动了。
登录发生在浏览器中，而不是应用内部
当 IDE 第一次打开时，它不会要求你在应用窗口内登录，而是会把你重定向到浏览器页面，在那里完成身份验证。
登录界面提供四种选项：
| 登录方式 | 适合谁 |
|---|---|
| 个人开发者和自由职业者 | |
| GitHub | 对于已有账号的开发者来说最自然的选择 |
| AWS Builder ID | 已经身处 AWS 生态中的开发者 |
| Your Organization | 使用 SSO 的企业团队 |
GitHub 选项与目标受众的匹配度很好。大多数开发者已经有 GitHub 账户，可以直接认证，而无需创建新凭据。
注册前有几点值得知道：
- 通过 Google 或 AWS Builder ID（不是 AWS Identity Center）登录，你将获得一张 20 美元的积分，可用于首次升级到付费计划。这是一项一次性福利，值得在选择登录方式前了解。
- 通过“Your Organization”登录会通过企业 SSO 路由，并且是需要集中身份管理的团队的入口。
- 登录即表示你同意 AWS Customer Agreement、Service Terms、Privacy Notice 和 AWS Intellectual Property License。由于 Kiro 是 AWS 产品，你的数据会在你所在地区的 AWS 区域内处理。
入门设置：三个步骤，不到两分钟
登录之后，Kiro 会在打开主 IDE 前运行一个简短的设置流程。步骤如下：
步骤 1：选择主题。 Kiro Dark 或 Kiro Light。两者在确认前都会显示带语法高亮的实时预览。
步骤 2：设置 Shell 集成。 这让你可以通过终端使用 kiro 命令打开任意项目。你也可以跳过，之后再设置。
步骤 3：从 VS Code 导入。 Kiro 会导入你现有的 VS Code 扩展（凡是 Open VSX 可用的都会导入）、设置和键位绑定。扩展会在入门流程继续进行时后台加载，因此不会卡在加载页面。
在这整个过程中，最实用的是 VS Code 导入。如果你已经花了很多年定制 VS Code 环境，那么切换过来并不需要从头开始。我的会话中导入运行得很顺利。
但入门流程没有包含对 Kiro 核心功能的任何介绍。你不会被带着了解 Specs、Agent Hooks 或 Steering Documents 是什么。你会直接来到主界面，然后自行摸索。这对有经验的开发者来说可以接受，但也意味着你第一次使用这个工具的最独特功能时，需要自己主动探索。
IDE 内部：让 Kiro 与众不同的四个面板
Kiro IDE 看起来像 VS Code，因为它就是基于相同基础构建的。文件资源管理器、编辑器标签页、终端、搜索栏和菜单栏的行为都和预期完全一致。
Kiro 与标准 VS Code 安装不同的地方，在于左侧专用面板，其中包含四个在任何 VS Code 扩展中都不存在的部分：
| 面板部分 | 作用 |
|---|---|
| Specs | 创建并管理用于复杂构建的规格文档（需求、设计、任务） |
| Agent Hooks | 设置在文件系统事件触发时自动执行的任务 |
| Agent Steering and Skills | 存储引导文档，塑造代理在所有会话中的行为方式 |
| MCP Servers | 将外部工具和数据源连接到 Kiro 代理 |
IDE 右侧是聊天面板。你在这里与 Kiro 交互，也会在这里实时看到积分消耗。“Est.
Credits Used: 0.1, Elapsed time: 57s” 会在每次代理动作后更新，这意味着你始终知道每个任务的成本。
在聊天输入栏底部，有两个控件决定 Kiro 在每项任务上的行为：
- 模型选择器： 你可以选择 Auto（Kiro 为每个请求挑选最具成本效益的模型），或手动指定 Claude Sonnet 4.6 或 Claude Opus 4.8 等具体模型。
- Autopilot 切换： 开启 Autopilot 后，Kiro 会在每一步中写入并编辑文件，而不会等待你的逐步批准。关闭后，Kiro 会在每条命令前暂停，并要求你 Trust、Reject，或手动 Run 它。
在物业管理平台测试中，我在规划阶段保持 Autopilot 开启，在任务执行期间使用手动批准，以便独立评估每一步。
结论： 对于任何 VS Code 用户来说，IDE 布局在几分钟内就会变得舒适。左侧的四个部分才是 Kiro 价值所在，而在第一次会话前理解它们，会决定你能从工具中获得多少。
Steering 文档：在第一条提示前给 Kiro 上下文
在一个新的 Kiro 项目中，第一件要做的事不是开始构建，而是生成 steering 文档。
我在发送任何提示之前先点击了 Kiro 面板中的“Generate Steering Docs”。Kiro 扫描了空的项目目录，并在 .kiro/steering/ 下创建了三个 markdown 文件：
| 文件 | 内容 |
|---|---|
| product.md | 产品名称、描述、核心领域概念和关键目标 |
| structure.md | 预期的文件夹布局和文件组织规范 |
| tech.md | 预期技术栈、常用命令和编码规范 |
对于一个完全空白的项目，Kiro 推断出了合理的默认值：React with TypeScript、Next.js API routes、PostgreSQL、Prisma、Tailwind CSS，以及基于 JWT 的认证。它把 tech.md 和 structure.md 都标记为占位文件，提示应在真实技术栈通过脚手架确认后再更新。
这很重要，因为后续每一次代理动作都会先读取这些文件，然后才做任何事。等你完成项目脚手架并确认真实技术栈后，更新 tech.md 会让 Kiro 在之后的所有任务中自动遵循这些规范。
你还可以添加自己的 steering 文件，用于 API 设计标准、命名规范、部署规则，或任何你希望代理视为固定条件的内容。
Vibe 模式 vs Spec 模式：决定整个构建流程的选择
当你为一个新构建打开聊天时，Kiro 会在你输入任何内容之前显示两种模式：
Vibe 模式 让你先聊天，再逐步构建。没有规划文档，没有结构化输出。最适合快速实验、早期探索，或需求仍在打磨中的任务。
Spec 模式 会在写入任何代码前先运行规划序列。Kiro 会生成需求、技术设计文档和任务列表。只有在这三者都经过审阅并批准后，它才会开始写代码。最适合可维护性很重要的生产级工作。
我为物业管理平台选择了 Spec 模式。提交提示后，Kiro 在生成任何内容前先问了我两个后续问题：
- “你想先从什么开始？”（Requirements，标记为推荐，或 Technical Design）
- “这是一个新功能还是 bug 修复？”（Build a Feature，推荐，或 Fix a Bug）
这些问题决定了后续一切内容的结构。选择“Requirements”意味着 Kiro 会先写用户故事和验收标准，再触及架构。
这种顺序会生成与先从技术设计出发、再倒推需求完全不同的规划产物。
Spec 工作流：在任何代码之前先有需求、设计和任务列表
这部分正是让 Kiro 值得认真评估的原因。
在选择“Requirements”和“Build a Feature”之后，Kiro 在 .kiro/specs/property-management-platform/ 下创建了 requirements.md 文件。该文档立即出现在编辑器中。我可以一边生成一边阅读。内容包括：
术语表： 12 个领域术语被精确定义，包括 Auth_Service、Property_Service、Lease_Service、Payment_Service、Maintenance_Service、Notification_Service 和 Dashboard_Service，每个术语都映射到一个计划中的具体子系统。
平台描述： 文档中记录了 Landlord 和 Tenant 两种角色，以及确认的技术栈：Next.js、TypeScript、PostgreSQL、Prisma、Tailwind CSS、Stripe 和 Docker。
在生成初始文档后，Kiro 运行了一个自动细化步骤。它解析了全部 12 条需求，为每条需求并行派发细化子代理，并将 requirements.md 更新为每项需求的完整验收标准。面板实时显示：“Refining requirements 12/12.”
在需求完成后，我点击“Continue”，并选择“Generate Design and Tasks”。Kiro 同时生成了 design.md 和 tasks.md。任务拆分是本次会话的亮点：
11 个任务组，43 个子任务，按实现顺序排列：
- 项目脚手架与基础设施
- 认证（JWT、黑名单、中间件、页面）
- 房产与单元管理
- 租客管理
- 租约管理、文档上传和 cron 作业
- 维修请求
- Stripe 支付与 webhook
- 邮件通知
- 房东仪表盘与报表
- 共享 UI 组件与布局
- API 加固（速率限制、CORS、健康检查、环境验证）
每个子任务都包含精确命令、文件路径以及可追溯的需求引用。例如任务 1.1 直接在描述中引用了 Requirements R12（Docker）和 R10（REST API）。规划与执行之间的关联在整个过程中都清晰且可验证。
相比之下，Rork 会跳过整个阶段，直接根据提示生成用户界面。输出质量上的差异是显而易见的：Kiro 的任务列表具体到足以交给人类开发者，让他们明确知道要按什么顺序构建什么内容。
任务执行：Kiro 实际构建了什么
在批准任务列表后，我点击了任务 1.1：“Initialize Next.js 14 project with TypeScript, Tailwind CSS, and ESLint”。
Kiro 将任务状态更新为“进行中”写入 tasks.md，然后把执行委派给它的 spec-task-execution 子代理。该代理首先检查工作区，确认只有 .kiro 规格文件夹，尚未存在 Next.js 项目，然后开始搭建项目脚手架。
在第一次执行循环中，文件树填充了：
- package.json，列出了 Next.js、React 19.2.4、TypeScript 和 Tailwind 依赖
- tsconfig.json、eslint.config.mjs、next.config.ts
- src/ 和 public/ 目录结构
- AGENTS.md 和 CLAUDE.md，由 Kiro 生成，作为项目的代理引导文件
- README.md
值得注意的是 CLAUDE.md 文件：Kiro 是 AWS 产品，但其底层使用的是 Anthropic 的 Claude 模型。CLAUDE.md 文件是 Claude 驱动的代理存储项目专属行为指导的方式。即使在 AWS 基础设施语境下，它的存在也反映了底层模型。
在任务列表顶部，“Run all tasks”按钮可让 Kiro 在启用 Autopilot 的情况下按顺序执行全部 43 个子任务。
我逐个运行任务，以便评估每一步。对于一个真正的项目，如果你对已批准的计划有把握，自动运行全部任务并在每个任务组结束后审查输出，是一种合理且省时的工作流。
Kiro 执行期间生成的每个文件，都是我本地项目目录中的真实文件，从第一秒起就归你所有、可以编辑。这一点很重要，因为它区别于 Figma Make 或 Uizard 这类浏览器型构建工具，在后者中，输出要么只是设计资产，要么是你无法本地掌控的托管应用。
第七分钟的超时：这对可靠性意味着什么
我想直接说明这一点，因为它发生在测试最重要的部分。
在 Kiro 完成全部 12 项需求细化并接受对 requirements.md 的编辑后，代理超时了。聊天面板中的错误消息写道：
“The request timed out. Please try again. (Conversation ID: 29d25548-c3ce-414c-8f57-702124c7fec6). Elapsed time: 7m 24s.”
这发生在需求阶段与设计生成阶段之间。超时前完成的工作已保存，没有任何需求丢失。
在确认错误后，我点击“Continue”并选择“Generate Design and Tasks”。Kiro 无需重复需求步骤就恢复了，干净地生成了两个文档，并在会话余下时间里正常继续。
这里有几点背景值得注意：
- 超时发生在一个复杂提示上，该提示覆盖 12 个不同的需求区域，并启用了并行细化运行。更简单的任务不太可能花这么久。
- Kiro 目前处于预览阶段，在复杂任务边缘的可靠性表现本就是这类工具在该阶段的常见特征。
- 恢复过程很干净。检查点系统保留了所有已完成工作，下一个步骤立即运行。
尽管如此，在这个工具最具特色的功能上运行了七分钟后发生超时，这仍然是一次真实的体验失败。如果你正赶着截止日期，一个会停下来并要求你手动重试的工具，即使恢复很平滑，也依然令人沮丧。
Agent Hooks：无需被要求就会运行的自动化
Agent Hooks 在本文比较过的其他任何 AI 编码工具中都没有出现，它们值得单独关注，因为它们代表了一种不同的 AI 辅助思路。
Hook 是一种在文件系统事件发生时自动运行的任务。你用自然语言描述行为，Kiro 将其转换为事件监听器，从那一刻起，只要触发条件满足，该行为就会在后台运行。不需要执行命令，也不需要提醒去设置。
Hooks 可以做的例子：
- 在文件保存时：为任何尚无测试文件的组件生成基础测试
- 在文件保存时：运行代码清理或格式检查
- 在文件创建时：自动为新函数生成文档
- 在字符串常量更改时：无需手动操作即可更新本地化文件
这个 hook 被存储在 .kiro/hooks/ 中，作为可编辑文件。如果你想调整触发条件或指令，可以直接编辑该文件。配置是透明的，并且可以像项目其他部分一样进行版本控制。
最实用的例子是保存时测试：开发者经常把写测试拖到冲刺最后，而一个在组件保存时悄悄添加基础测试的 hook，可以直接消除这种拖延决策。下一次保存后，测试就会出现在文件树中，无需你做任何操作。
积分消耗：免费层到底能提供什么
积分机制是 Kiro 在你承诺使用工作流前最需要仔细阅读的部分。
免费层提供 50 个积分。一次物业管理平台规格会话消耗如下：仅规划阶段就用了 4.28 个积分，这还包括需求、设计文档和完整的 43 个任务列表，而在那之前还没有写一行应用代码。
按照这个消耗速度：
| 场景 | 免费层可覆盖范围估算 |
|---|---|
| 仅规划会话（不执行代码） | 大约 11 次会话 |
| 规划加部分任务执行 | 3 到 5 次会话 |
| 复杂项目上的完整规格到执行 | 最多 1 个完整项目 |
在注册前需要理解的关键机制：
- 积分不会结转。每个计费月结束时没用完的部分都会消失。
- 所有付费计划默认关闭超额计费。你必须在达到上限之前到 Settings 中启用它，否则 Kiro 会在任务进行中停止工作。
- 模型选择会影响消耗速度。用 Claude Sonnet 4.6 运行同一任务，比使用 Auto 模式贵 1.3 倍。Opus 模型更贵。
- 免费层用户可使用 Claude Sonnet 4.5，以及一组开源权重模型，包括 Qwen3 Coder Next、DeepSeek v3.2 和 MiniMax 2.1。付费用户可解锁 Claude Sonnet 4.6、Claude Opus 4.6 和 Claude Opus 4.8。
- 信用消耗会在每次代理动作后显示在聊天面板中，并每五分钟在订阅仪表盘中更新一次。
实时积分追踪器（每次任务后显示“Est. Credits Used: 0.1, Elapsed time: 57s”）是目前没有任何同类工具提供的透明度功能。你可以准确知道每项任务运行时花了多少，这有助于决定对某个任务使用 Auto 模式还是特定模型。
Kiro 定价与方案
Kiro 采用基于积分的定价模式，共有五个层级，从无需信用卡的固定月度免费额度，到为专业日常使用设计的高容量方案。
所有付费方案都包含高级模型访问权限、启用按量超额的选项，以及完整的 Kiro 功能集，包括 specs、hooks、autopilot 和 CLI 访问。
选择方案前要知道：
- 免费计划提供固定的每月积分额度，无需信用卡。它不会过期，但一个复杂的规格会话就会明显消耗其中一大部分。
- 你第一次从免费升级到任何付费计划时，如果使用 Google 或 AWS Builder ID（不是 AWS Identity Center），你会获得 20 美元积分，可用于抵扣订阅费用。这项福利只适用一次。
- Kiro 按每个日历月的第一天计费。月中升级意味着你需要支付按比例计算的费用，但会立即获得新方案的完整积分上限。
- 所有付费计划都提供按固定每额外积分计费的超额计费选项，但默认关闭。请在达到上限前到 Settings 中启用，否则 Kiro 会在积分用尽时暂停你的工作。
- 未使用的积分不会结转到下个月。
- 每位开发者都需要单独订阅。目前没有共享团队席位选项。团队计费功能标注为即将推出。
- Kiro 的标准政策是不对月中取消提供退款。访问权限会持续到计费周期结束。只有在计费错误的情况下才会酌情考虑退款。
- 只接受信用卡付款。
- GovCloud（US）的价格大约比标准价格高 20%，且该环境下没有免费层。GovCloud 访问需要付费计划和通过 AWS IAM Identity Center 的企业身份验证。
- 网页界面目前处于预览阶段，仅向付费用户开放。无论你是在 IDE、CLI 还是网页中工作，积分消耗速率都相同。
哪个方案适合哪类用户： 免费计划足以完成一次真实评估。对于真实项目上的主动开发，则需要付费计划，以避免在中途耗尽。更高等级的方案适合那些每周运行多次完整规格会话，或同时处理多个复杂项目的开发者。
Kiro 的替代方案
与 Kiro 最直接的竞争者是 Cursor，这是一款同样建立在 VS Code 基础之上的 AI 驱动代码编辑器，面向那些希望 AI 深度集成到开发环境中的开发者。
核心区别在于工作流理念。Cursor 旨在加速你已经在做的事情：你写代码，Cursor 提供辅助。
Kiro 则是先接管规划阶段：代理先定义要构建什么，然后才开始写入任何内容。如果你最头疼的是在 AI 聊天和编辑器之间来回切换带来的低效，Cursor 更直接地解决这个问题。若你更在意 AI 生成代码缺乏结构、难以维护，那么 Kiro 的规格工作流才是更相关的答案。
| 功能 | Kiro | Cursor |
|---|---|---|
| 易用性 | 对 VS Code 用户来说很熟悉；规格工作流增加了学习曲线 | 对 VS Code 用户来说很熟悉；入门摩擦更低 |
| 最适合 | 面向生产项目的结构化、规格驱动构建 | 在现有代码库中进行快速 AI 辅助编辑和代理任务 |
| 后端与数据 | 构建真实的本地项目，完全掌控技术栈 | 编辑和扩展现有项目文件，完全掌控技术栈 |
| 设计灵活性 | 没有可视化构建器；输出真实、归你本地所有的代码 | 没有可视化构建器；输出真实、归你本地所有的代码 |
| 定价模式 | 基于积分；50 个免费积分；所有使用都会从每月积分池中扣除 | 自 2025 年 6 月起改为基于积分；Auto 模式无限制；高级模型选择会从每月积分池中扣除 |
最终结论：Kiro 值得买吗？
Kiro 通过把规划放在编码之前而脱颖而出。它的规格工作流、Steering 文档和任务拆分能产出比直接进入实现的 AI 工具更结构化、可维护性更高的代码库。Agent Hooks 也是一大亮点，它能实现超越单次提示、持续运行的工作流自动化。
代价是学习曲线和价格。免费层对于大型项目来说太有限，而且开发者需要习惯在 IDE 中工作。在测试期间，我还遇到了超时，不过 Kiro 最终恢复了，而且没有丢失进度。
如果你是构建生产软件的开发者，Kiro 是当今最强的 AI 编码工具之一。但如果你想要的是一个简单的无代码应用构建器，那么它并不适合你。
