---

🔥 个人主页：铁皮哥（欢迎关注）
📌 作者简介：28届校招生，后端开发/Agent 方向在学
📚 学习内容：Java、Python、计算机视觉、大语言模型、Agent开发
📝 专栏内容：从零开始的Claude Code零代码生活（持续更新中）
✨不只背八股，更想搞懂为什么这样设计

---

前言

本文是系列文章【从零开始的Claude Code零代码生活】的第三篇，使用谷歌推出的 Vibe Design 工具 Stitch 进行 UI 的设计，并接入 Stitch MCP 到 Claude Code 实现 UI 到前端页面的落地实现。
这篇文章会使用之前第二篇生成的文档进行 UI 原型的设计与落地，没看过前两篇的朋友建议先去看一看前两篇，点开专栏就能看到~
从零开始的Claude Code零代码生活（持续更新中）

一、先把 UI 需求文档变成 Stitch 设计草案

上一篇已经生成了 joblens-ui-requirement.md。

这份文档里把 JobLens 第一版页面的风格、模块、交互、空状态、错误状态都整理出来了。

目前文档里主要包含这些页面：

首页 / 工作台
Kanban 投递看板页
岗位列表页
岗位详情抽屉 / 弹窗
快速录入弹窗

如果直接从开发角度看，这些页面已经够详细了。
但如果要交给 Stitch 生成 UI，还需要再处理一步。

因为 joblens-ui-requirement.md 更像是一份产品页面需求文档，里面有很多功能说明和交互细节；而 Stitch 更适合接收一段视觉导向更明确的 UI Prompt。

所以这一篇的第一步，需要先把页面需求文档转换成 Stitch 更容易理解的设计描述。

整个流程大概是这样：

joblens-ui-requirement.md
        ↓
提炼页面目标和核心区域
        ↓
整理成英文 UI Prompt
        ↓
交给 Stitch 生成页面原型
        ↓
再交给 Claude Code 还原成前端代码

这一章不会把所有页面都完整展开。

因为如果每个页面都从 0 到 1 写一遍，文章会变得很长，而且重复内容很多。
这里我只拿两个最关键的页面做示范：

首页 / 工作台
快速录入弹窗

这两个页面刚好代表了 JobLens 的两个核心场景：

打开系统，快速了解求职进度
发现岗位，快速录入并保存下来

剩下的 Kanban 投递看板页、岗位列表页、岗位详情抽屉，都可以按照同样的方法继续生成。

---

1.1 先确定全局设计风格

在生成具体页面之前，先要把 JobLens 的整体视觉风格固定下来。

这一步很重要。

我们也让 Claude Code 帮我们完成 UI Prompt 的确定，这里可以开一个新的上下文窗口，避免过多的 token 消耗。

/clear 可以用于开启一个新的 Claude Code 上下文窗口
/resume 可以用于查看过去的上下文对话窗口
如果一直用一个窗口对话，上下文会被越塞越多，那么每次发送给大模型的话也就越长，所以也会消耗更多的 token。我们依托文档进行开发其实也有这一点好处，无论在任何上下文的情况下，即使是空的上下文，模型也能依靠我们的文档快速了解下一步的任务和当前进度。

找到之前第二篇文章生成的joblens-ui-requirement.md，让 Claude Code 去读这份文档，并基于项目内容生成 Stitch 需要的 Prompt。

这里用的提示词如下：

请先基于 ./docs/joblens-ui-requirement.md，生成一段适合 Stitch 使用的全局 UI 风格 Prompt。

要求：

1. 必须来自当前 JobLens 页面需求文档；
2. 不要加入文档之外的复杂设计风格；
3. 强调 JobLens 是“校招投递工作台”；
4. 明确说明不要设计成传统后台管理系统；
5. 包含颜色、卡片、布局、状态色、提醒色、信息密度等要求；
6. 使用中文输出；
7. 这段 Prompt 后续会作为所有页面设计的统一前缀。

Claude Code 会根据文档生成类似这样的全局 UI Prompt：

设计 JobLens 的高保真首页 / 工作台页面。

JobLens 是一个面向大学生、校招生、实习求职者的校招投递进度管理工作台，用来帮助用户记录岗位、管理投递进度、跟进重要事项。

这是用户打开应用后的第一个页面。页面需要让用户快速了解当前求职进度，发现需要立即处理的事项，并且能够快速录入新的岗位机会。

整体页面应该像一个个人求职进度指挥台，而不是传统后台管理系统，也不要像企业内部管理后台。

整体风格要求：
- 清爽、专业、现代、有激励感
- 使用白色或浅灰色背景
- 使用深靛蓝或专业蓝作为主色
- 使用卡片式布局，模块之间留出足够间距
- 卡片可以使用圆角、轻微阴影、柔和分割线和现代 UI 细节
- 信息密度适中
- 视觉层级清晰
- 首页不要使用密集表格

状态颜色要求：
- 待投递：灰色
- 已投递：蓝色
- 笔试：橙色
- 面试：紫色
- Offer：绿色
- 已结束：浅灰色
- 即将截止：红色或橙红色
- 待跟进：黄色或琥珀色

页面布局：

一、顶部统计区域

在页面顶部设计一行 4 到 6 个统计卡片。

统计卡片包括：
- 总岗位数
- 待投递
- 已投递
- 笔试 + 面试
- Offer
- 即将截止

每个统计卡片需要展示一个醒目的大数字、清晰的标签，以及一个与状态颜色匹配的小型视觉强调元素。

“即将截止”卡片需要比其他卡片更加醒目，可以使用红色或橙色高亮、轻微发光效果，或者强调边框来提示紧急性。

每个统计卡片都应该看起来可以点击，用于跳转到对应筛选条件下的岗位列表。

二、快速录入入口

在统计区域下方放置一个非常醒目的快速录入区域。

这是首页最重要、最显眼的操作入口。

可以将它设计成以下形式之一：
- 一个宽大的输入框式区域，支持用户粘贴 JD 文本或岗位链接
- 或者一个大型主操作卡片 / 按钮，用于新增岗位

该区域需要传达这样的文案含义：

“粘贴 JD 文本或岗位链接，快速录入岗位。”

需要包含一个明显的主操作按钮，例如：

“解析”
或
“新增岗位”

快速录入区域应该让用户感觉录入岗位很快、很轻量，比手动维护 Excel 表格更方便。

三、主要提醒区域

在快速录入区域下方，设计一个响应式卡片网格，用来展示重要的求职提醒事项。

需要包含以下模块：

A. 即将截止

设计一个“即将截止”提醒卡片，用于展示 3 天内截止的岗位。

每条岗位信息展示：
- 公司名
- 岗位名称
- 截止紧急程度，例如“明天截止”“2 天后截止”“3 天后截止”

使用红色或橙红色强调紧急感。

当没有即将截止的岗位时，显示友好的空状态文案：

“暂无即将截止的岗位，继续保持！”

B. 待跟进

设计一个“待跟进”提醒卡片，用于展示超过 7 天没有更新进展的岗位。

每条岗位信息展示：
- 公司名
- 岗位名称
- 当前投递状态，使用彩色状态标签展示
- 上次更新时间，例如“投递于 10 天前”

使用黄色或琥珀色作为提示强调。

当没有待跟进事项时，显示：

“暂无待跟进事项。”

C. 近期安排

设计一个“近期安排”卡片，用于展示未来 3 天内的笔试和面试安排。

每条安排展示：
- 公司名
- 岗位名称
- 日期和时间
- 类型标签：笔试或面试

笔试使用橙色标签，面试使用紫色标签。

当没有近期安排时，显示：

“近期暂无笔试 / 面试安排。”

D. 最近更新岗位

设计一个“最近更新岗位”列表，展示最近修改过的 5 到 10 个岗位。

每一行展示：
- 公司名
- 岗位名称
- 当前投递状态标签
- 相对更新时间，例如“3 小时前”“昨天”

当没有岗位时，显示：

“还没有录入任何岗位。”

四、首次使用空状态

当系统中没有任何岗位数据时，页面仍然应该看起来完整、友好、有引导感。

在首次使用状态下：
- 顶部统计卡片仍然保留，所有数字显示为 0
- 快速录入区域成为页面视觉主角
- 添加一个友好的插画或图标，例如剪贴板、火箭、清单
- 显示引导文案：

“还没有录入任何岗位，粘贴一段 JD 文本开始吧！”

- 各个提醒卡片不要消失，而是展示对应的友好空状态文案

五、加载状态

设计轻量级加载状态：
- 统计卡片使用骨架屏占位
- 提醒卡片中展示骨架列表项
- 页面整体结构保持可见
- 不要使用全屏 loading 或全屏转圈

六、错误状态

如果某个模块加载失败，在该模块内部展示行内重试提示：

“加载失败，点击重试。”

不要使用全局错误横幅、弹窗提示或整页错误页面。

交互预期：
- 点击统计卡片，跳转到对应状态筛选后的岗位列表
- 点击快速录入区域，打开快速录入弹窗
- 点击任意岗位条目，打开岗位详情抽屉或弹窗
- 鼠标悬停在可交互卡片上时，卡片可以轻微提升阴影或增强视觉强调

最终页面应该看起来精致、实用，并且适合作为一个真实的学生求职效率工具。

整体感觉应该是：清晰、有条理、有推进感，能够帮助用户持续推进自己的校招投递进度。

这段 Prompt 后面可以反复复用。

每次生成具体页面时，先贴这段全局风格，再追加当前页面的结构要求。
这样 Stitch 生成出来的页面会更统一，不会每一页都像不同项目。

---

1.2 让 Stitch 生成首页 / 工作台的页面原型

接下来开始处理第一个示例页面：首页 / 工作台。

首页是 JobLens 的第一屏，根据页面需求文档，它需要承担这些任务：

展示求职全局状态；
突出快速录入入口；
提醒即将截止的岗位；
提醒长期未跟进的岗位；
展示近期笔试 / 面试安排；
展示最近更新的岗位。

这部分不需要自己重新总结，继续让 Claude Code 从文档里提炼。

输入：

请阅读 ./docs/joblens-ui-requirement.md 中的「页面风格要求」和「4.1 首页 / 工作台」。

请基于文档内容，为 Stitch 生成一段中文 UI Prompt，用于设计 JobLens 首页 / 工作台。

要求：
1. 严格遵循文档中的页面目标、核心区域、交互、空状态、加载状态和错误状态；
2. 页面必须是中文界面；
3. 重点突出“校招投递工作台”定位，不要设计成传统后台；
4. 保留统计卡片、快速录入、即将截止、待跟进、近期安排、最近更新岗位；
5. 输出可直接复制到 Stitch 的 Prompt，不要解释。

Claude Code 生成后，可以得到一段完整的首页 Prompt。

示例输出大概是这样：

设计 JobLens 的高保真首页 / 工作台页面。

JobLens 是一个面向大学生的校招投递进度追踪工作台，用来帮助用户记录岗位、管理投递状态，并持续推进求职进程。

这是用户打开应用后看到的第一个页面。页面需要让用户快速了解当前求职进度，发现需要立即处理的事项，并且能够方便地快速录入新的岗位机会。

整个页面应该更像一个个人求职进度指挥台，而不是传统后台管理系统，也不要像企业内部办公后台。

整体风格要求：
- 清爽、专业、现代，并且有一定激励感
- 使用白色或浅灰色背景
- 使用深靛蓝或专业蓝作为主色调
- 使用卡片式布局，模块之间留出充足间距
- 卡片可使用圆角、轻微阴影、柔和分割线和现代化 UI 细节
- 信息密度适中
- 视觉层级清晰
- 本页面不要出现密集的大表格

投递状态颜色要求保持统一：
- 待投递：灰色
- 已投递：蓝色
- 笔试：橙色
- 面试：紫色
- Offer：绿色
- 已结束：浅灰色
- 即将截止：红色或橙红色
- 待跟进：黄色或琥珀色

页面布局如下：

1. 顶部统计区域

在页面顶部设计一行 4 到 6 个统计卡片。

统计卡片包括：
- 总岗位数
- 待投递
- 已投递
- 笔试 + 面试
- Offer
- 即将截止

每个卡片都需要展示一个醒目的大数字、清晰的标签，以及一个与对应状态颜色一致的小型视觉强调元素。

“即将截止”卡片需要比其他卡片更醒目，可以使用红色或橙色高亮、轻微发光效果，或者强化边框来体现紧急感。

每个统计卡片都应该看起来可以点击，并且能够让人联想到点击后会跳转到对应筛选条件下的岗位列表。

2. 快速录入入口

在统计区域下方放置一个非常醒目的快速录入区域。

这是整个页面最吸引注意力的核心操作入口。

可以将它设计成以下两种形式之一：
- 一个宽大的输入框式区域，支持用户粘贴 JD 文本或岗位链接
- 或者一个大型主操作卡片 / 按钮，用于新增岗位

需要传达这样的文案含义：

“粘贴 JD 文本或岗位链接，快速录入岗位。”

需要包含一个明确、醒目的主操作按钮，例如：

“解析”
或
“新增岗位”

快速录入区域应该让用户感觉录入岗位是快速、轻量的，并且比手动维护电子表格更方便。

3. 主要提醒区域

在快速录入区域下方，设计一个响应式卡片网格，用来展示重要的求职提醒信息。

需要包含以下几个模块：

A. 即将截止

设计一个“即将截止”提醒卡片，用于展示 3 天内即将截止的岗位。

每条信息展示：
- 公司名
- 岗位名称
- 截止紧急提示，例如“明天截止”“2 天后截止”“3 天后截止”

使用红色或橙红色来增强紧迫感。

当没有即将截止岗位时，显示友好的空状态文案：

“暂无即将截止的岗位，继续保持！”

B. 待跟进

设计一个“待跟进”提醒卡片，用于展示超过 7 天没有更新进展的岗位。

每条信息展示：
- 公司名
- 岗位名称
- 当前投递状态，使用彩色状态标签展示
- 上次更新时间，例如“投递于 10 天前”

使用黄色或琥珀色作为提示强调色。

当没有待跟进事项时，显示：

“暂无待跟进事项。”

C. 近期安排

设计一个“近期安排”卡片，用于展示未来 3 天内的笔试和面试安排。

每条安排展示：
- 公司名
- 岗位名称
- 日期和时间
- 类型标签：笔试 或 面试

笔试使用橙色标签，面试使用紫色标签。

当没有近期安排时，显示：

“近期暂无笔试 / 面试安排。”

D. 最近更新岗位

设计一个紧凑的“最近更新岗位”列表，展示最近修改过的 5 到 10 个岗位。

每一行展示：
- 公司名
- 岗位名称
- 当前投递状态标签
- 相对更新时间，例如“3 小时前”“昨天”

当没有岗位时，显示：

“还没有录入任何岗位。”

4. 首次使用空状态

当系统中没有任何岗位数据时，页面依然应该保持完整、友好，并具有引导感。

在这种状态下：
- 顶部统计卡片依然保留，所有数字显示为 0
- 快速录入区域成为页面的视觉主角
- 添加一个友好的插画或图标，例如剪贴板、火箭、任务清单
- 显示引导文案：

“还没有录入任何岗位，粘贴一段 JD 文本开始吧！”

- 各个提醒卡片不要消失，而是展示对应的友好空状态文案

5. 加载状态

设计轻量级的加载状态：
- 统计卡片使用骨架屏占位
- 提醒卡片展示骨架列表项
- 页面整体结构保持可见
- 不要使用全屏 loading 或全屏转圈

6. 错误状态

如果某个模块加载失败，在该模块内部展示行内重试提示：

“加载失败，点击重试。”

不要使用全局错误横幅、弹窗提示，或整页错误页面。

交互预期：
- 点击统计卡片，跳转到对应状态筛选后的岗位列表
- 点击快速录入区域，打开快速录入弹窗
- 点击任意岗位条目，打开岗位详情抽屉或弹窗
- 鼠标悬停在可交互卡片上时，卡片可以轻微提升阴影或增强视觉强调

最终页面应该看起来精致、实用，并适合作为一个真实面向学生的求职效率产品首页。

整体感觉应该是：清晰、有条理、有激励感，并且真正帮助用户持续推进自己的校招投递进度。

等待一会生成后，给出了一版页面，可是发现了一些问题，最明显的就是页面是全英的，不急，我们让他继续改：

点击选中对应的页面后，我们输入提示词进行修正

---

1.3 让 Stitch 生成快速录入弹窗的页面原型

第二个示例页面是 快速录入弹窗。

这个弹窗是 JobLens 区别于 Excel 的核心交互。

在真实求职场景里，岗位来源非常杂：

招聘官网
牛客帖子
Boss 直聘
实习僧
公众号
微信群
朋友转发

用户拿到的信息可能是一段 JD 文本，也可能是一个链接，也可能只是零散信息。

所以页面需求文档里把快速录入弹窗拆成了三种模式：

粘贴 JD 文本
粘贴链接
手动填写

继续让 Claude Code 基于文档生成 Prompt。

输入：

请阅读 ./docs/joblens-ui-requirement.md 中的「4.5 快速录入弹窗」。

请基于文档内容，为 Stitch 生成一段中文 UI Prompt，用于设计 JobLens 快速录入弹窗。

要求：
1. 严格遵循文档中的录入模式、表单字段、解析流程、校验、空状态和错误状态；
2. 页面必须是中文界面；
3. 弹窗要轻量、现代，不要像复杂后台表单；
4. 保留“粘贴 JD 文本 / 粘贴链接 / 手动填写”三种模式；
5. 输出可直接复制到 Stitch 的 Prompt，不要解释。

Claude Code 生成的 Prompt 示例：

设计 JobLens 的高保真快速录入弹窗。

JobLens 是一个面向国内大学生、校招生、实习求职者的校招投递进度管理工具。快速录入弹窗用于创建新的岗位记录，是 JobLens 区别于 Excel 表格的核心交互。

用户可以粘贴岗位 JD 文本、粘贴岗位链接，或者手动填写岗位信息。弹窗目标是让用户尽可能快地保存一个岗位机会，同时保留必要的信息校验和失败反馈。

整体设计要求：
- 页面文案全部使用中文；
- 弹窗整体轻量、现代、清爽，不要有压迫感；
- 不要设计成复杂企业后台表单；
- 使用白色背景、圆角容器、轻微阴影；
- 使用深蓝色或靛蓝色作为主色；
- 表单字段清晰、间距舒适；
- 信息分组要简单，不要多级嵌套；
- 整体感觉像一个现代效率工具里的快速创建弹窗；
- 用户应该感觉“10 秒就能录入一个岗位”。

弹窗形态：
- 使用居中弹窗 Modal；
- 弹窗宽度适中，不要太宽；
- 背景使用半透明遮罩；
- 支持点击右上角关闭按钮关闭；
- 支持点击取消按钮关闭；
- 可以表现出按 Esc 或点击遮罩关闭的交互预期。

一、顶部区域

弹窗顶部包含：
- 标题：“快速录入岗位”
- 简短说明：“粘贴 JD 文本或岗位链接，系统将尝试提取岗位信息。”
- 右上角关闭按钮

标题下方放置三个 Tab，用于切换录入模式：

1. 粘贴 JD 文本
2. 粘贴链接
3. 手动填写

默认选中“粘贴 JD 文本”。

Tab 横向排列，当前选中项使用主蓝色下划线或高亮背景。切换 Tab 时，已经填写的内容不要被清空。

二、模式一：粘贴 JD 文本

这是默认模式，也是最核心的录入方式。

页面从上到下包含：

1. JD 文本输入区

设计一个醒目的多行文本输入框。

占位文案：

“粘贴岗位 JD 文本，例如：某公司 Java 后端开发工程师，负责……”

输入框高度适中，适合粘贴一段较长 JD。输入框使用浅灰边框，聚焦时边框变为主蓝色。

输入框附近放置一个明显的主按钮：

“解析 JD”

按钮使用主蓝色填充。

2. 解析状态反馈

需要体现以下状态：

- 正在解析：按钮进入 loading 状态，文案变为“正在解析……”
- 解析成功：下方表单字段被自动预填充
- 部分解析成功：显示黄色提示：“部分信息未能识别，请手动补充。”
- 解析失败：显示红色提示：“解析失败，请手动填写。”但不要阻塞用户继续填写

3. 解析结果 / 信息确认区

在 JD 输入区下方设计一个“岗位信息确认”区域。

解析前，这个区域可以以弱化状态展示，让用户知道解析后会在这里确认信息。

解析后，这个区域展示可编辑表单字段，用户可以修改解析结果。

该区域不要做得太复杂，重点展示最核心字段：

- 公司名，必填
- 岗位名，必填
- 城市
- 岗位方向
- 技术栈
- 来源平台
- 岗位链接
- 截止时间
- 备注

三、模式二：粘贴链接

该模式用于用户只有岗位链接的情况。

页面从上到下包含：

1. 链接输入框

占位文案：

“粘贴岗位链接，例如：https://……”

输入框下方显示轻量说明：

“当前版本仅保存链接，不自动解析页面内容。”

说明文字使用浅灰色，可以配一个信息图标。

2. 岗位信息表单

链接输入框下方展示与手动填写模式一致的表单。

表单默认为空，用户手动填写关键信息。

四、模式三：手动填写

该模式直接展示完整表单。

表单字段包括：

第一组：基础信息
- 公司名，必填
- 岗位名，必填

第二组：岗位属性
- 城市
- 岗位方向
- 技术栈
- 来源平台

第三组：补充信息
- 岗位链接
- 截止时间
- 备注

表单布局要求：
- 公司名和岗位名可以使用双列布局；
- 城市和岗位方向可以使用双列布局；
- 技术栈和来源平台可以使用双列布局；
- 岗位链接、截止时间、备注可以单列展示；
- 备注使用多行文本框；
- 表单不要过长，不要有复杂分组边框；
- 标签放在输入框上方，便于阅读。

字段说明：
- 城市：支持输入或下拉选择；
- 岗位方向：支持输入或下拉选择，例如后端、前端、AI 应用开发、数据分析、产品、运营等；
- 技术栈：文本输入，提示“如 Java、Spring Boot、MySQL”；
- 来源平台：下拉选择，选项包括牛客、Boss 直聘、实习僧、企业官网、公众号、微信群、其他；
- 岗位链接：URL 输入框；
- 截止时间：日期选择器；
- 备注：多行输入框，提示“补充说明，如内推信息、面试准备要点等”。

五、必填字段校验

公司名和岗位名为必填字段。

视觉要求：
- 标签旁显示红色星号；
- 点击保存时进行校验；
- 校验失败时，对应输入框边框变为红色；
- 输入框下方显示红色提示文字，例如“请输入公司名”“请输入岗位名”；
- 用户开始输入后，错误提示可以消失。

六、底部操作栏

弹窗底部固定显示操作按钮：

左侧或次要位置：
“取消”

右侧或主要位置：
“保存岗位”

在 JD 文本模式中，如果已经解析出内容，主按钮也可以显示为：

“保存岗位”

按钮状态：
- 保存中：按钮进入 loading 状态，文案为“保存中……”，并禁用重复点击；
- 保存成功：弹窗关闭；
- 保存失败：弹窗不关闭，在弹窗顶部或底部显示红色提示：“保存失败，请重试。”，并保留所有已填写内容。

七、整体交互预期

- 默认进入“粘贴 JD 文本”模式；
- 用户可以在三个 Tab 之间切换；
- 切换 Tab 时已填写内容保留；
- JD 解析失败不阻塞用户手动填写；
- 保存失败不清空表单；
- 弹窗关闭前不需要复杂二次确认；
- 整体流程要让用户感觉录入岗位很轻松。

最终效果应该是一个中文、高保真、轻量、专业的快速录入弹窗。

它应该让用户一眼明白：
“我可以把 JD 或链接粘贴进来，系统帮我提取信息，我检查一下就能保存岗位。”

---

文章里只演示两个页面就够了。

剩下的页面只要继续让 Claude Code 按同样方式读取文档对应章节，再生成 Stitch Prompt 即可。

二、把 Stitch 原型交给 Claude Code，还原成前端代码

接下来要做的事情，就是把 Stitch 生成的页面交给 Claude Code，让它根据原型还原成前端代码。
数据暂时使用 Mock。
后端接口、数据库和真实保存逻辑放到后面的文章再接。

这一篇只解决一个问题：

如何把 Stitch 生成的 UI 原型，变成一个本地可以运行、结构清晰、后续方便接后端的前端页面。

2.1 先把 Stitch MCP 接入 Claude Code

如果只是用 Stitch 单独生成几张图，那它和项目代码之间还是断开的。

我希望 Claude Code 能直接读取 Stitch 原型信息，再根据当前项目结构生成页面代码。
所以这里需要先把 Stitch MCP 接入 Claude Code。

MCP 可以简单理解成 Claude Code 的“外接工具接口”。
接入以后，Claude Code 不只是能读本地文件，还可以通过 MCP 获取外部工具提供的信息。

现在大家可以还开着 claude code 终端呢，先输入/exit退到原本的 cmd 界面，然后再执行下面命令查看现在都装了哪些 MCP：

claude mcp list

如果还没有 Stitch，就需要添加 Stitch MCP。

打开 Stitch 页面，依次按图中操作点击

然后去创建一个密钥

然后我们能拿到以下信息：

MCP Server URL : https://stitch.googleapis.com/mcp
Header: X-Goog-Api-Key: 你的 API Key

然后在你的终端输入命令：

claude mcp add --transport http stitch https://stitch.googleapis.com/mcp \ 
--header "X-Goog-Api-Key: 你的_STITCH_API_KEY"

即可接入成功。

然后进入 Claude Code 交互模式：

claude

在 Claude Code 里输入：

/mcp

验证已接入 MCP 成功。

---

2.2 让 Claude Code 先读项目文档和 Stitch 原型

接下来让 Claude Code 开始工作。

但还是那句话：不要一上来就让它写代码。

先让它读文档、读原型、给计划。

我输入的是：

请先阅读 docs 目录下的 JobLens 设计文档，包括需求、功能、数据、API、页面需求和实现计划。

然后通过 Stitch MCP 读取：
1. 求职工作台首页原型；
2. 快速录入岗位弹窗原型。

现在不要写代码。请先输出前端实现计划，包括：
- 当前阶段目标；
- 需要实现的页面和组件；
- Mock 数据设计；
- 后续 API 预留点；
- 准备新增或修改的文件列表。

这里特意让 Claude Code 同时阅读了需求、功能、数据、API 和实现计划。

这样它生成代码时不会只看 UI 图，而会知道：

字段从哪里来；
状态有哪些；
哪些接口后面要接；
哪些功能现在不该做；
Mock 数据应该长什么样。

比如数据设计文档里已经定义了岗位核心字段，包括公司名、岗位名、城市、岗位方向、技术栈、来源平台、岗位链接、JD 原文、状态、截止时间、笔试时间、面试时间、下一步动作、备注等。

API 文档里也已经设计好了后续会用到的接口，比如创建岗位 POST /api/jobs、解析 JD 文本 POST /api/jobs/parse-jd、获取顶部统计数据 GET /api/stats/overview、获取即将截止岗位 GET /api/stats/expiring、获取待跟进岗位 GET /api/stats/follow-up。

这些信息都应该反映到前端结构里。

例如 Claude Code 应该能给出类似这样的组件拆分：

src/
├── pages/
│   └── Dashboard/
│       └── DashboardPage.tsx
├── components/
│   └── job/
│       ├── JobSidebar.tsx
│       ├── StatCard.tsx
│       ├── ReminderPanel.tsx
│       ├── JobStatusTag.tsx
│       └── QuickAddJobModal.tsx
├── mock/
│   └── jobMock.ts
├── types/
│   └── job.ts
└── services/
    └── jobService.ts

这里 services/jobService.ts 暂时不一定真的请求后端，但可以先留好方法名。

这样后面从 Mock 切到真实 API 时，不需要把页面大改一遍。

---

2.3 先生成前端类型和 Mock 数据

确认计划没问题后，下一步是先让它把类型和 Mock 数据准备好。

因为只要字段乱了，页面后面一定会乱。

我输入：

请根据 docs/joblens-data-design.md 和 docs/joblens-api-design.md，生成前端 TypeScript 类型和 Mock 数据。

要求：
1. 状态枚举、字段命名与文档保持一致；
2. Mock 数据至少 10 条，覆盖全部岗位状态；
3. 数据要能支撑首页统计、即将截止、待跟进、近期安排、最近更新岗位；
4. 暂时不要写页面组件。

状态枚举要特别注意。

文档里状态枚举已经固定为：

TODO_APPLY
APPLIED
WRITTEN_TEST
INTERVIEW
OFFER
CLOSED

对应中文分别是：

待投递
已投递
笔试
面试
Offer
已结束

这些状态在数据设计、功能设计和 API 设计里都是统一的。

前端最好从一开始就用英文枚举做数据值，用中文做展示。

比如：

export type JobStatus =
  | 'TODO_APPLY'
  | 'APPLIED'
  | 'WRITTEN_TEST'
  | 'INTERVIEW'
  | 'OFFER'
  | 'CLOSED'

export const JOB_STATUS_LABEL: Record<JobStatus, string> = {
  TODO_APPLY: '待投递',
  APPLIED: '已投递',
  WRITTEN_TEST: '笔试',
  INTERVIEW: '面试',
  OFFER: 'Offer',
  CLOSED: '已结束',
}

这样后面接后端接口会很顺。

不要让前端状态写成：

status: '待投递'

这种写法短期看方便，后面联调一定会难受。

---

2.4 根据 Stitch 原型还原首页

类型和 Mock 数据准备好后，再开始生成首页。

我输入：

请根据 Stitch MCP 中的「求职工作台首页」原型实现 React + TypeScript 页面。

要求：
1. 结合 docs/joblens-ui-requirement.md、joblens-feature-design.md、joblens-api-design.md 和 joblens-implementation-plan.md；
2. 当前阶段只使用 Mock 数据，不接真实后端；
3. 首页统计和提醒逻辑尽量从 Mock 数据计算，不要写死；
4. 保留首页的统计卡片、智能录入、即将截止、近期安排、待跟进、最近更新岗位；
5. 点击「新增岗位」和「解析并保存」时打开快速录入弹窗；
6. 完成后说明新增和修改的文件。

这里有一个关键点：
首页统计不要全写死，应该尽量从 Mock 数据里算出来。

比如：

总岗位数 = jobs.length
待投递 = status === TODO_APPLY
已投递 = status === APPLIED
笔试 / 面试 = WRITTEN_TEST + INTERVIEW
Offer = status === OFFER
即将截止 = deadline 在 3 天内 && status === TODO_APPLY

这和后续 API 里的 GET /api/stats/overview 能对应上。统计接口设计里已经包含了 total、todo_apply、applied、written_test、interview、offer、closed、expiring_soon、need_follow_up 等字段。

这样做的好处是，后续只要把 Mock 计算换成接口返回，页面结构不用动。

---

2.5 首页不要只还原 UI，还要预留接口位置

Claude Code 生成首页后，我会继续让它补一个轻量的 service 层。

这一层暂时还是返回 Mock 数据，但方法名先和 API 设计对齐。

输入：

请新增 src/services/jobService.ts，用于封装首页当前需要的数据读取逻辑。

当前阶段仍然返回 Mock 数据，不请求真实后端。

请预留以下方法：

1. getOverviewStats()
   - 对应后续 GET /api/stats/overview

2. getExpiringJobs(days = 3)
   - 对应后续 GET /api/stats/expiring

3. getFollowUpJobs(days = 7)
   - 对应后续 GET /api/stats/follow-up

4. getRecentUpdatedJobs()
   - 当前从 Mock 数据按 updated_at 倒序取最近 5 条

5. getUpcomingSchedules()
   - 当前从 Mock 数据中筛选未来 3 天的 written_exam_time 和 interview_time

要求：

1. 方法返回 Promise，模拟后续接口异步调用；
2. DashboardPage 不直接 import mock 数据；
3. DashboardPage 通过 service 方法获取数据；
4. 保持页面效果不变。

这一步看起来不显眼，但很重要。

如果页面直接到处 import Mock 数据，后面接真实后端会比较麻烦。
现在先加一个 jobService，后续只要把里面的 Mock 实现换成 fetch 或 axios 就可以了。

比如后面可以替换成：

export async function getOverviewStats() {
  return request('/api/stats/overview')
}

这样前端页面不需要关心数据来自 Mock 还是 FastAPI。

---

2.6 生成快速录入弹窗

首页完成后，再生成快速录入弹窗。

这里要结合文档重新确认一下产品逻辑。

顶层需求里说，用户发现岗位后，可以复制 JD 文本或链接，粘贴到 JobLens，系统尝试解析并生成卡片；如果是链接，第一版只保存链接，不解析页面内容。

功能设计里也明确说，快速录入是 JobLens 区别于 Excel 的关键能力：Excel 要逐个填写字段，而 JobLens 是复制 JD、粘贴、系统提取、用户确认、保存。解析不准也没关系，因为解析结果只是预填充，用户始终可以手动修正。

结合我们现在的首页设计，我把弹窗逻辑收敛成两个 Tab：

1. 智能录入
2. 手动填写

这里我没有保留单独的“粘贴链接”Tab。

原因是：
首页的智能录入区域本来就已经支持粘贴 JD 文本或岗位链接。弹窗打开后，不应该再让用户重复粘贴一次。弹窗的核心职责应该是：

展示解析结果
  ↓
让用户检查字段
  ↓
补充缺失信息
  ↓
保存岗位

如果用户一开始没有在首页粘贴内容，或者解析失败，就可以切到“手动填写”。

给 Claude Code 的 Prompt：

请根据 Stitch MCP 中的「快速录入岗位弹窗」原型实现 QuickAddJobModal 组件。

要求：
1. 结合 docs 中的页面需求、功能设计、数据设计和 API 设计；
2. 弹窗只保留「智能录入」和「手动填写」两个 Tab；
3. 表单字段与 JobPosition 保持一致；
4. 公司名和岗位名必填；
5. 当前只做前端交互和 Mock 保存，不请求真实接口，但预留接口位置；
6. 预留 parseJdText 和 createJob 的 service 方法；
7. 保存成功后关闭弹窗，并把新岗位临时追加到首页状态。

这个 Prompt 里最关键的是：

不请求真实接口，但预留接口位置。

因为 API 设计文档里已经有 POST /api/jobs/parse-jd，请求字段是 jd_text，返回公司名、岗位名、城市、岗位方向、技术栈、截止时间和 JD 摘要。

也有 POST /api/jobs 创建岗位接口，必填字段是 company_name 和 job_title。

所以前端弹窗保存的数据结构应该提前和这些接口对齐。

---

2.7 把弹窗接入首页

弹窗组件生成后，还要接回首页。

继续输入：

请把 QuickAddJobModal 接入 DashboardPage。

要求：

1. 点击左侧「新增岗位」按钮，打开 QuickAddJobModal；
2. 点击首页智能录入区域的「解析并保存」按钮，打开 QuickAddJobModal；
3. 首页输入框中的内容作为 originalContent 传给 QuickAddJobModal；
4. 如果首页输入框为空，也允许打开弹窗，但智能录入区域提示用户需要补充信息；
5. 保存成功后关闭弹窗；
6. 保存成功后暂时把新岗位追加到前端本地状态中；
7. 追加后首页统计卡片、最近更新岗位区域同步变化；
8. 不请求真实后端接口；
9. 代码结构保持清晰。

这里我加了一个细节：

保存成功后暂时把新岗位追加到前端本地状态中。

这比只打印控制台更有体验。

虽然还没接数据库，但至少可以看到：

我新增了一个岗位
  ↓
首页总数 +1
  ↓
最近更新岗位出现新记录

这更接近真实产品。

但是当前只是前端本地状态，刷新页面后数据不会保留。真正的数据持久化要等后面接 POST /api/jobs 和 MySQL。

---

2.8 本地运行检查

代码生成完成后，启动前端项目。

如果是 Vite 项目：

cd frontend
npm install
npm run dev

如果是 Create React App：

cd frontend
npm install
npm start

打开浏览器后，先检查首页：

1. 左侧导航是否正常；
2. 顶部搜索是否正常；
3. 统计卡片是否展示；
4. 智能录入区域是否明显；
5. 即将截止是否只展示 3 天内截止的待投递岗位；
6. 待跟进是否只展示超过 7 天无进展的非终态岗位；
7. 近期安排是否展示未来 3 天的笔试 / 面试；
8. 最近更新岗位是否按更新时间排序；
9. 页面是否全中文；
10. 控制台是否有报错。

再检查快速录入弹窗：

1. 点击「新增岗位」能否打开弹窗；
2. 点击「解析并保存」能否打开弹窗；
3. 首页输入内容是否能传入弹窗；
4. 智能录入 Tab 是否默认选中；
5. 手动填写 Tab 是否正常；
6. 公司名为空时是否提示；
7. 岗位名为空时是否提示；
8. 保存成功后弹窗是否关闭；
9. 新岗位是否能临时出现在首页；
10. 刷新后数据丢失是否符合当前 Mock 阶段预期。

这里的“刷新后数据丢失”不是 Bug。

因为这一章还没接后端，当前数据只是前端 Mock。
真正刷新后不丢数据，要等后面实现岗位创建接口和 MySQL 持久化。

写在文后

这篇文章总算把 JobLens 从“文档里的页面需求”，推进到了“能看见、能点击、能继续开发的前端原型”。
而且这个过程中我也应该越来越能感受到一件事，Prompt 不应该替代项目文档，Prompt 只是调度 AI 工作的指令。
前面文档写得越清楚，后面给 Claude Code 的提示词反而可以越短。
因为真正的上下文已经沉淀在项目文档里，而不是每次都靠一大段 Prompt 重新解释一遍。
下一篇就该让页面真正“活起来”了。我会开始进入后端部分，基于前面已经整理好的数据设计和 API 草案，继续完善项目。

期待您的一键三连！如果有什么问题或建议欢迎在评论区交流！