企业官网建设流程全解析

现在市面上比较热门的是Cursor为什么我会用kiro,因为公司提供。

对比下两款ai的核心

kiro

核心思想：Spec‑Driven（先定规范，再写代码）。 流程：自然语言需求 → 生成正式需求文档 → 架构设计文档 → 拆解任务清单 → AI 编码、写测试用例，全程可追溯，适合工程化开发

Cursor

核心思想：Vibe Coding（边聊天边写代码）。 直接给指令就修改代码，不需要前置写文档；Composer、Agent 模式一键跨多文件修改、自动执行终端命令、修复 Bug，灵活自由。

核心开发范式：冲刺编写 vs. 规划先行

• Cursor（提示词驱动 / Prompt-Driven）：你给出一个提示词（例如“帮我加一个用户评论功能”），Cursor 会立刻开始预测并在多个文件中直接生成代码。这种方式速度极快，适合快速迭代、日常编码和原型开发。

• Kiro（规范驱动 / Spec-Driven）：同样输入“加一个用户评论功能”，Kiro不会立刻写代码。它会先和你在对话中明确需求，生成一份结构化的规格说明书（Specs），包含用户故事、系统架构、依赖关系和验收标准。在你确认这份“设计图纸”无误后，它才会启动 Agent 按照步骤去写代码。这极大地减少了 AI 在大型项目里因理解偏差而“胡言乱语”的概率。

项目管理与长期维护

• Cursor：针对当前正在编写的代码上下文处理得很好。但当项目变得极其庞大时，AI 很难自动维护整套项目的宏观架构文档。

• Kiro：拥有Agent Steering（智能引导）功能。项目初始化时会自动生成product.md（产品愿景）、structure.md（目录规范）、tech.md（技术栈规范）等引导文件。AI Agent 在做任何修改时都会严格遵守这些规则，确保即使代码量暴增，也不会偏离最初的架构设计。

总体概括

kiro文档摘要

以ide集成为例子

打开kiro 导入项目

打开

agent steering&skills说明

通过 Markdown 文件，引导机制能让 Kiro 持续了解你的工作区。这样一来，Kiro 就无需在每次聊天中解释你的约定，引导文件可以确保 Kiro 始终遵循你已建立的模式、库和标准。

一致的代码生成- 每个组件、API 端点或测试都遵循团队已建立的模式和约定。

减少重复——无需每次对话都解释工作区标准。Kiro 会记住您的偏好。

团队一致性——所有开发人员都遵循相同的标准，无论他们是工作新手还是经验丰富的贡献者。

可扩展的项目知识- 随着代码库的增长而增长的文档，记录项目演进过程中的决策和模式。

添加项目的steering文件

他会自动生成

产品概述（product.md）——定义您产品的用途、目标用户、关键功能和业务目标。这有助于 Kiro 理解技术决策背后的“原因”，并提出符合您产品目标的解决方案。

技术栈（tech.md）——记录您选择的框架、库、开发工具和技术限制。Kiro 在推荐实现方案时，会优先选择您已建立的技术栈。

项目结构（structure.md）——概述文件组织、命名约定、导入模式和架构决策。这确保生成的代码能够无缝集成到您现有的代码库中。

这些基础文件默认包含在每次交互中，构成了 Kiro 对项目理解的基础。

Agents.md

Kiro 支持通过AGENTS.md标准提供转向指令。AGENTS.md 文件采用 Markdown 格式，类似于 Kiro 转向文件；但是，AGENTS.md 文件不支持包含模式，并且始终会被包含。

创建、配置和管理自定义 AI 代理的核心方式，它将你的专属 AI 助手封装在一个可共享、可版本控制的文件中，让 AI 能更专业、更可控地为你服务

总结：agents就是一个其他人的已经写好的标准指令文件，比如steering文件， 拿来直接使用

specs

需求阶段

比如输入一个网页浏览功能，他会输出一个requirements文件

里面就是需求文档的标注， 默认他会有多种需求，和验收标准， 我这边为了简化只保留了一种

修改完成后

点击continue 选择design

他会生成design文件

设计阶段

技术架构和组件设计将被记录下来。

实施阶段

继续点击continue 中的 tasks 生成Tasks文件

显示任务的步骤

最后执行 run all tasks

使用钩子实现工作流程自动化

创建一个hooks 成功后

会出现一个文件 .json文件

mcp

你可以把AI模型想象成一个知识渊博但“与世隔绝”的专家。

• 它的困境：这个专家虽然懂很多，但无法直接查阅你公司最新的数据库，不能操作Jira来帮你创建任务，也无法访问你代码仓库里的私有代码。所以，当你问它具体问题时，它只能基于过时的训练数据给出泛泛而谈的回复。

• MCP的解决方案：MCP就是为这个“专家”配的一个万能助手。这个助手遵循一套标准流程，能帮专家安全地连接到各种外部系统，获取信息或执行操作。

MCP采用了客户端-服务器（Client-Server）架构，主要有三个角色：

• MCP主机 (Host)：这是你正在使用的、需要AI能力的应用程序。比如，Kiro、Claude Desktop、VS Code中的GitHub Copilot等。

• MCP客户端 (Client)：它内置于主机应用内部，负责与MCP服务器进行一对一的通信。

• MCP服务器 (Server)：这是一个轻量级的服务程序，它在MCP主机之外运行，作为“桥梁”连接到特定的数据源或工具。

  • 例如，一个“GitLab MCP服务器”就专门负责与你的GitLab仓库交互。

  • 一个“数据库MCP服务器”就负责连接你的PostgreSQL数据库。

总结:mcp是连接第三方数据源的工具，方便ai去查阅.

skills

它是一套遵循开放Agent Skills标准的、可移植的指令包。通过 Skills，你可以将一系列特定工作流的指引、脚本甚至模板打包起来，教会 Kiro 的 AI 代理（Agent）完成某个特定任务。

Skills 的核心设计是“渐进式披露”（Progressive Disclosure），这让它非常高效：

• 轻量启动：Kiro 启动时，只会加载每个 Skill 的名称和描述，几乎不消耗资源。

• 按需加载：只有当你的任务与某个 Skill 的描述匹配时，Kiro 才会加载其完整的指令，就像调用一个函数一样。

• 精准执行：加载后，AI 就会严格按照 Skill 中的步骤来执行任务。

最后总结

• Steering 文件：Steering (product.md等) 是静态的背景信息，描述项目“是什么”；可以理解为：Steering 是“字典”

• MCP：MCP 是“接口”，让 AI 能直接调用外部工具（如数据库、API）并获得确定性的结果。简单说，MCP 提供“能做什么”。

• Custom Agents：Custom Agents（自定义代理）是“执行者”，你可以为它分配不同的 Skills 和 MCP 工具。Skills 是“技能包”，Agent 是拥有这些技能的“人”。

• Skills:技能包:你可以将一系列特定工作流的指引、脚本甚至模板打包起来，教会 Kiro 的 AI 代理（Agent）完成某个特定任务

代理说明：

内置了5种代理

Default： 最通用的基础模式，一个可以处理各种日常开发任务的“多面手”
Spec：这是 Kiro 最核心的模式，代表了一种“先想清楚，再动手”的严谨工作流

在Spec模式下，你通常还可以选择两种子流程：

• Requirements-first：从需求开始，逐步推进到设计和任务。

• Design-first：如果你已经有了比较清晰的技术思路，可以从设计阶段开始。

Quick Spec（Spec模式的 “快进版”）:它会一次性自动生成需求、设计和任务这三份文档，省去了在阶段之间反复确认的步骤

Bug Fix：一个专门为修复 Bug而设计的专家。它的工作流程非常严谨，会先进行根本原因分析（Root Cause Analysis），然后设计一个“外科手术式”的精准修复方案，最后还会规划防止问题复发的任务

Plan：一个专注于高层次规划和任务分解的代理。它不像Spec那样产出详尽的技术设计文档，而是更侧重于帮你把一个大目标，拆解成一个清晰、可执行的任务列表

Powers

Kiro 的 Powers 功能让您的 AI 代理能够即时访问任何技术领域的专业知识。Powers 将您的工具、工作流程和最佳实践打包成 Kiro 可以按需激活的格式。当您提及相关关键词时，Kiro 会自动加载 Powers 的上下文和工具。