Kiro做UI设计：用规格补齐页面状态

Kiro 做 UI 设计，可以先用 Spec 写清“谁能操作、页面何时变化、完成后去哪里”，再通过 Pixso MCP 读取组件，生成对应的可编辑界面。以团队申请开通项目空间为例，先把可申请、处理中、已开通三个阶段说明白，再让 AI 补齐画板，比只要求“做一个好看的开通页”更容易得到完整流程。

Kiro 负责梳理要求和安排任务，Pixso 承载图层、组件与视觉结果。设计师确定信息优先级、权限边界和每一步的主操作，再由 AI 将这些决定落实到画布上。这样需要审阅的是具体界面和行为，而不是一段“体验友好”的抽象描述。

开通流程首先要回答：用户现在能做什么

设想一个企业内部应用：员工为“移动门户改版”项目申请协作空间，填写用途、所属部门和负责人；申请提交后由指定人员处理，空间就绪后才能进入。三种页面的主操作分别是“提交申请”“查看进度”“进入空间”，不应从头到尾都保留同一个“立即开通”。

这个任务容易遗漏的不是按钮样式，而是阶段之间的关系。提交申请不代表已经通过审批，通过审批也不一定意味着资源已准备好。如果页面提前显示“开通成功”，用户点击进去却看到错误页，视觉再精致也无法弥补流程断裂。

权限是另一条维度：有的人可以申请，有的人只能看申请记录。它不应被混成第四个业务阶段。没有申请权限时，可以在申请页保留产品说明和必要信息，将表单区域改为只读说明，并提供已确定的申请权限途径；不能让用户填完后，才在提交时发现自己没有资格。

Spec与UI设计稿分别放什么

Kiro 的 Feature Specs 可以从需求出发，再形成技术方案与实施任务。其中 design.md 中的 design 指技术设计，不能把它当成视觉设计稿。文字说明了流程，还需要在 Pixso 里落实字段位置、信息层级和状态变化。

这三类内容的分工很清楚：

• 需求条目：谁可以提交、何时视为处理中、什么条件下才能进入空间。
• 技术方案与任务：申请怎样保存、进度从哪里读取、权限怎样判断，以及失败如何恢复。
• Pixso 设计稿：各阶段展示哪些信息、哪里显示进度、按钮如何变化、只读区域如何表达。

在 Kiro 中为这个功能创建 Spec，可以先给出下面的要求，避免 AI 自动补进一整套没有约定的采购或管理流程：

整理“团队申请开通项目空间”的需求与验收条件。
申请包含项目名称、用途、所属部门和负责人。
三个主阶段为可申请、处理中、已开通。

处理中需要区分等待审批和空间准备，但使用同一个进度页承载。
提交后保留申请内容；只有空间就绪且用户有访问权限时，才能进入空间。
申请权限和访问权限分别判断，不能因为可以申请就默认拥有管理员权限。

先列出尚未明确的业务问题，再形成需求条目。
不要自行增加付费套餐、合同签署、自动邀请成员和数据迁移。

接着把“及时反馈”“智能开通”改成可判断的条件。下面这组条目可以直接作为设计依据：

R1：只有具备申请权限的用户可以编辑并提交申请。
R2：提交成功后显示申请编号与已提交内容，不立即显示空间已开通。
R3：处理中显示当前环节；审批通过但空间未就绪时，不能进入空间。
R4：只有空间就绪且当前用户有访问权限时，显示可用的“进入空间”操作。
R5：无论处于哪个阶段，项目名称和负责人都保持一致。
R6：保留填写内容；只有确认申请未提交成功，才提供重试。超时或结果未知时，先查询申请状态，不直接重复提交。

还需要与团队确定几个真正影响界面的选择：申请能否撤回、处理过程中能否修改负责人、被退回后是否允许重新提交。如果这些行为未确定，就先不画“撤回”“催办”“转交”等按钮；按钮一旦出现在设计稿里，往往会被当成已经承诺的功能。

连接Pixso，先读已有组件与目标画板

在 Kiro 打开项目，从命令面板搜索 MCP，选择工作区 MCP 配置；也可以直接维护 .kiro/settings/mcp.json。按 Kiro MCP 配置文档，工作区配置只对当前项目生效，同名配置优先于用户级设置。添加：

{
  "mcpServers": {
    "pixso": {
      "url": "https://pixso.cn/mcp"
    }
  }
}

保存后按浏览器提示完成 OAuth 授权，再确认 Kiro 能列出 Pixso 工具。公网服务地址为 https://pixso.cn/mcp，私有化环境使用企业自己的服务地址。远程连接不要求一直开着 Pixso 客户端；详细步骤可查看 Pixso 远程 MCP 开发者指南。

在 Pixso 中准备放置申请流程的页面，右键目标容器，复制图层链接。带 item-id 的链接用于定位具体容器，文件分享链接或页面链接不能替代它。Pixso MCP 需要全功能席位或研发席位；读取需要目标文件的查看权限，改稿还需要编辑权限。

读取我提供的项目空间申请容器链接，先不要修改文件。
识别页面已有的字段、按钮、步骤指示和结果提示区域。
读取当前文件里可复用的输入框、按钮、状态标签、文字样式和颜色变量。
说明哪些可以复用，哪些需要补充；不要展开其他业务页面。
特别检查“状态标签”和“可点击按钮”是否被混为同一种组件。

查看它返回的对象是否符合画面：状态标签用于告诉用户现在到哪一步，按钮用于触发动作；“处理中”标签不应被当成可点击操作。组件外观相似，也不代表它们关联了同一个源组件，需要结合读取到的结构判断。

用同一份申请串起三个阶段

先确定三页共同的信息：项目名称为“移动门户改版”，申请部门为产品部，负责人为陈晨。提交后的申请编号沿后续阶段保留，用于查询同一条申请。不要在“已开通”画面突然换成另一个空间名称，否则评审者无法判断这是流程变化，还是跳到了另一条记录。

可申请页先说明空间用途，再组织表单。部门、负责人等已有默认值应可辨认；哪些可改由业务规则决定。主按钮紧接表单，提交失败的信息也应在这里可见，而不是只在屏幕角落闪过。

处理中页把重点转为当前环节和已提交摘要。可以显示“提交申请 → 等待审批 → 空间准备 → 开通完成”的步骤，但等待审批和空间准备属于同一处理中主画面的不同进度。没有可靠完成时间时，不写“预计一分钟完成”或虚构倒计时。

已开通页把主动作改为进入空间，并展示名称、负责人和当前用户可用的权限。空间已经开通但当前用户没有访问权限时，不应保留一个点击必失败的入口；应说明访问条件及已确定的获取权限方式。

允许在目标页面新增三份画板：空间申请、空间处理中、空间已开通。
保留原画板、原组件及其他页面，不删除已有内容。
三页使用同一个项目名称“移动门户改版”、部门“产品部”和负责人“陈晨”。

申请页：显示必填项与提交按钮。
处理中页：保留申请内容和编号，突出当前处理环节，不显示进入空间按钮。
已开通页：显示空间信息与访问权限，满足访问条件时显示进入空间按钮。

沿用已确认的组件、文字样式和变量。
不要把每个阶段重新设计成一套视觉风格，不新增尚未确定的撤回或催办功能。
完成后返回新增节点并截图，对照R1—R6说明已落实的位置。

新版远程工具支持读取组件、样式和变量，并通过 apply_design 等工具创建或调整设计内容。检查结果时，看新增内容是否仍为可编辑图层，字段和按钮是否保留合理结构，原组件有没有被意外改动。工具范围可查 Pixso MCP 工具与指令。

权限与失败反馈，不要塞进一个“异常页”

阶段说明业务走到哪里，权限说明当前用户能做什么，失败说明哪一次动作没有完成。三者彼此关联，但不是同一件事。把它们全部变成“无权限或发生错误，请重试”，会让用户不知道等待是否有用、换账号是否有用，还是需要改表单。

无申请权限时，页面应在用户开始填写前给出明确说明，保留帮助其理解用途的信息；无访问权限则可能出现在空间已经开通之后，不能因此把空间状态退回“未开通”。界面表达应分别对应这两个事实。

只有确认申请未提交成功时，才显示失败原因和重试操作，同时保留表单内容。请求超时或结果未知时，先查询申请状态；仍无法确认结果，就保持“结果待确认”，不直接重复提交。不要一边显示“申请已收到”，一边又要求用户重新提交。

审批被退回也不等于系统故障。若产品允许修改后再提交，应显示退回原因和可修改项；如果产品不支持重新提交，就不能只为界面完整而凭空补一个按钮。可以让 Kiro 将已确定的差异放在对应画板旁，形成可比较的局部变体：

在申请页旁补充“无申请权限”“确认未提交成功”和“结果待确认”三个局部参考。
无权限：保留用途说明，不出现可编辑表单和提交入口。
确认未提交成功：保留已填内容，显示明确失败原因，并允许重试。
超时或结果未知：保留已填内容，先提供查询申请状态的操作；
只有查明未提交成功才允许重试，不提供直接重复提交的入口。
不要将“空间已开通但无访问权限”改成未开通；
在已开通页补充该权限说明，保留真实的开通状态。
只处理这些局部，不新增业务流程。

沿着同一条申请核对画面

让 Kiro 根据需求编号读回节点，并用 take_screenshot 查看三张画板。check_layout 可以辅助发现布局结构问题，但“审批通过后是否仍需等待空间准备”属于业务逻辑，需要对照规格判断，不能仅看画面对齐就通过。

还要换一组更难的内容：项目名称变长、部门名称占两行、退回原因有三条时，摘要和按钮是否仍然清晰。对这类问题，优先调整容器宽度、换行和信息优先级，不要为了塞进固定高度而把所有文字缩小。

如果 AI 改到了未授权画板，先定位受影响节点，再恢复或修正局部。工具执行失败不代表之前的修改一定已撤销；先读取文件当前内容，再决定重试哪些动作，避免叠加重复画板。

规则变了，只改受影响的部分

设计稿稳定后，可以让 Kiro 按 Spec 的任务继续实现页面，将需求编号关联到代码和测试。设计稿给出视觉与结构，需求条目说明状态变化的条件，两者共同描述这条开通流程。画板不会自动建立审批服务、分配实际权限或创建项目资源，这些行为必须由实现来完成。

如果调用 Pixso 的 design_to_code / D2C+，需要企业版全功能席位或研发席位，且文件位于企业空间。Kiro 读取设计数据后结合仓库编写代码，与直接使用 D2C+ 是不同路径，不能把 MCP 已连接当作后者已经开通。

后续增加“审批通过后需要管理员配置资源”的要求时，先更新处理中阶段的规则，再调整进度文案、相关画板与实现任务。可申请和已开通的共同结构仍然保留，不必重新生成整套页面。长期使用的组件命名和项目规范，可以放在 Kiro Steering 中；本次目标链接、允许修改的范围和具体业务条件，仍需在任务里明确提供。

从一个开通流程开始，把每个阶段的事实、权限和下一步分别说清，再在 Pixso 中形成可编辑的状态画板。之后讨论和修改都有具体对象，设计师也能把精力放在流程是否合理，而不是反复解释“这个按钮为什么现在不能点”。