最近换手机，备忘录实在难以迁移，就尝试从零开始，全流程用 AI 搞了一个小网站：KzNote，用作私人笔记本。算是实践一下AI构建网站的落地链路：从设计到前端到后端全使用AI来做。
这次用到的工具：
- Stitch（设计 AI 网站）：从提示词/参考图生成 UI 设计与页面结构，负责“统一风格 + 明确布局”
- Google AI Studio（在线 AI 前端 IDE）：承接设计上下文，生成/迭代前端代码与 mock 数据，负责“快速得到可运行界面”
- Trae IDE（桌面 IDE）：面向真实工程的编码与改造，用来搭建后端（PHP）并把 mock 替换成真实 API，负责“打通真实数据流”
工具入口：
- Stitch：https://stitch.withgoogle.com/（官方介绍：https://developers.googleblog.com/en/stitch-a-new-way-to-design-uis/）
- Google AI Studio：https://aistudio.google.com/（Build 模式说明：https://ai.google.dev/gemini-api/docs/aistudio-build-mode）
- Trae IDE：https://www.trae.ai/（文档：https://docs.trae.ai/ide/what-is-trae）
下面补一段更细的介绍，方便后续复用这条链路。
Stitch：设计 AI 网站（Prompt → UI → Code）
Stitch 是一个偏“设计侧”的 AI 工具，核心能力是把自然语言描述、草图/截图等视觉参考，快速转成一套高保真的 UI 方案，并且尽可能把“设计系统”一起带出来（颜色、字号层级、间距、组件状态等），以保证多页面的风格一致。
它在链路里的价值可以理解为：先把“风格与布局”定死，再去生成代码，减少后面反复返工。
你可以把它当成这几件事的组合：
- 设计方向生成器：同一需求出多种布局/风格变体，快速对齐方向
- 组件与页面拼装：列表页/详情页/编辑页这种典型信息架构，能很快搭起来
- 设计到开发的桥：支持把结果送去 Figma 做精修，也支持导出前端代码作为初始脚手架
使用小技巧：
- 先生成“Style Guide/设计系统页”，再生成业务页面，整体一致性会更稳定
- 提示词里把间距体系、圆角、阴影、字体层级写清楚，比只写“极简/高级”更可控
- 让它多给几版方案再选（而不是一版生成后不停修），通常效率更高
Google AI Studio：在线 AI 前端 IDE（Prompt → 可运行应用）
Google AI Studio 不只是一个聊天窗口，它更像是一个“在线的 AI 应用构建环境”：你可以在里面调 prompt、选模型、设置系统指令与输出结构；当交互逻辑稳定后，再进入 Build 模式，把想法直接生成成一个可运行的应用雏形（带代码编辑与预览）。
它在链路里的价值是：把 Stitch 产出的设计上下文（页面结构、组件风格、视觉参考）直接接到“可运行代码”，快速得到一个能点、能跑、能演示的前端项目。
在我这次的用法里，它主要干了两件事：
- 生成前端代码：按页面拆组件、补齐交互状态，形成可运行的 UI
- 生成 mock 数据：按界面字段生成 JSON/mock 列表，方便前端先把链路跑通
使用小技巧：
- 先把“输出契约”写清楚：页面路由、接口返回结构、错误码/空态字段，生成会更稳定
- 让它先生成最小闭环（列表 → 详情 → 编辑），跑通后再加功能，返工更少
- mock 数据里主动加入边界值（空列表、超长标题、异常状态），联调时更省时间
Trae IDE：桌面 AI IDE（工程落地与多文件改造）
Trae 是一个面向真实工程的桌面 IDE（偏 VS Code 生态），优势在于它不仅能回答问题、补全代码，还擅长在“真实仓库上下文”里做多文件的生成、替换、重构与联调辅助。
它在链路里的价值是：当你从“可演示的前端”进入“可用的产品”阶段，需要后端、数据库、鉴权、部署等工程化内容时，用桌面 IDE 来做会更顺手，也更接近你平时的开发节奏。
这次我用它主要做了：
- 搭建 PHP 后端项目骨架（目录结构、路由、基础配置）
- 按前端 mock 的字段对齐接口契约，补齐 CRUD 接口
- 把前端从 mock 切换到真实 API（尽量保持返回结构一致，减少前端改动）
使用小技巧：
- 先锁定接口契约与字段命名（id/noteId 这种最容易漂移），再让 AI 批量生成/替换
- 优先实现最小接口集，把“打通链路”当第一目标，后面再优化架构与抽象
整体体验非常顺滑，不过也有“新项目 + 功能简单”的加成：页面不多、业务规则少、数据模型能从零定义，因此 AI 的输出更容易收敛。
适用范围（哪些项目最合适）
这条链路对下面类型的项目尤其友好：
- 新起一个工具类/信息类网站（列表/详情/编辑为主）
- 需求相对明确、交互复杂度中等
- 需要快速做出可演示的原型，并尽快进入真实联调
如果是强约束的业务系统（复杂权限、多角色、多流程、强一致性），依然能用，但建议把“接口契约/领域模型/权限矩阵”作为第一优先级，否则后期返工会很痛。
Step 1：用 Stitch 锁定风格与页面结构
我最满意的是 Stitch 对“风格统一”的把控：只要提示词把设计语言说清楚，它能比较稳定地输出一致的视觉系统。
这是当时的 Stitch 提示词示意：
其实就是自然语言描述，当然，你如果能有更好的提示词结构，那效果会更好，像我这种后端大老粗，根本没有审美，只能大白话描述，让AI自由发挥。
- 设计语言：字体、字号层级、圆角、阴影、间距体系、主色/辅色、背景层级
- 组件规范：按钮/输入框/卡片/列表/对话框的状态（默认、hover、禁用、错误）
- 布局结构：导航、侧边栏、内容区栅格；移动端是否需要底部导航
- 页面清单：列表页、详情页、编辑页、设置页等
- 可实现性约束：优先可复刻、少“炫技动效”，避免生成难以落地的交互
如果页面较多，建议先让 Stitch 出一页“设计系统（Style Guide）”，把颜色、字体、间距、组件状态定下来，再扩展业务页面，一致性会明显提升。
Step 2：导出到 AI Studio 生成前端与 mock
基于 Stitch 的结果，我直接导出到 AI Studio，生成可运行的前端代码与 mock 数据：
这一阶段我主要盯三件事（事实上，我只是点点页面，试试弹窗，有问题让AI直接修复就好了，完成度挺高的。）：
- 结构是否可维护：页面/组件/路由/请求层/状态管理是否分层清晰
- mock 是否贴近真实：字段命名、数据量、空态/异常态/边界值是否覆盖
- 交互是否闭环：加载态、错误态、空态、表单校验、按钮禁用策略是否完整
我的实践策略是“先跑起来再优化”：先保证页面能点、链路能通，再逐步把目录结构、复用组件、类型定义等工程化细节收敛到自己满意的标准。
Step 3：用 Trae 搭建 PHP 后端并替换 mock
当 UI 可跑、交互也像样之后，就进入“把假数据换成真数据”的阶段。我用 Trae 来搭建 PHP 后端项目，核心任务是：
- 对齐前端 mock 的数据结构，抽象出后端模型与接口契约
- 实现最小可用接口集（列表/详情/新增/更新/删除）
- 前端请求从 mock 切到真实 API（尽量保持返回结构一致，减少重构）
这里最关键的是“契约优先”：
- 前端已经基于 mock 固化了字段与结构，后端尽量对齐，避免无意义返工
- 真需要调整时，优先做兼容（新增字段、保留旧字段一段时间）
- 把真实世界的问题尽快暴露出来：分页、排序、错误码、并发更新、数据校验
Trae 搭建后端与替换 mock 的过程截图：
演示效果
PC 演示示例：
移动端演示示例：
文档也交给 AI：让输出变得“工程化”
除了写代码，这次我还把“规范文档”也交给 AI，效果不错。典型场景是生成执行方案类文档（比如 执行方案.md）或需求说明。
我比较认可的一种拆法是：复杂功能不要试图写成一篇巨大的需求文档，而是拆成多份“小而清晰”的说明，每份只描述一个闭环：
- 背景/目标/范围
- 用户故事与交互说明（包含空态、错误态）
- 数据结构与字段说明
- 接口契约（路径、方法、请求/响应示例、错误码）
- 验收标准与回归点
文档拆小之后，AI 不容易跑题，人也更容易评审、迭代和定位变更点。
小结
“Stitch → AI Studio → Trae”这条链路对新项目尤其友好：设计先统一，前端快速落地可运行界面，再把 mock 平滑替换为真实 API，基本能在很短时间内跑通一个可演示、可迭代的产品雏形。后续我会把提示词结构、文档模板和接口契约沉淀成一套自己的启动模板，让下一次从零开始更快进入“可用”阶段。
