---

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

---

前言

本文是系列文章【从零开始的Claude Code零代码生活】的第二篇，面向零基础用户，从一个想法开始，用 Claude Code 拆出完整项目文档。
这个系列肯定不会断更，大概会保持周更的进度，感兴趣的朋友们可以点个关注，也欢迎私信或评论区咨询问题。
最终成品足以在大学生学科竞赛里拿到不错的奖项了，本科期间A类竞赛的国奖省奖我都拿过不少，相信我的眼光，大家都可以追更学习一下，代码最后也会开源出来。

最近小米发了不少 token，经实测，小米的新模型效果还不错，所以后面的系列文章我都会用 Claude Code 接入 MIMo 进行开发（有羊毛不薅是xxx！）。
申请 token 的流程我也写了一篇文章，可以参考看看： 【炉边闲谈】(接入 Claude Code) 小米 MiMo 百万亿 Token 免费申请流程

一、为什么不能一上来就让 Claude Code 写代码？

做项目之前先别老急着指挥 AI 去写前端、写后端、设计数据库等。

我要求你帮我完成一个帮助用户查看求职信息的系统，要求前后端分离，前端美丽大方、后端逻辑严谨。

用上面这段话能设计出好系统，那我觉得真可以宣布程序员彻底失业了。
最大的问题在于，这个 Prompt 里几乎所有关键点都是模糊的：

• 项目到底解决什么问题没想清楚
• 用户是谁没想清楚
• 第一版做多大没想清楚
• 页面应该展示什么没想清楚
• 接口和数据结构后面不断返工
• 写着写着就变成半成品

我们要成为维新派，写出严谨完备的 Prompt，不要想到啥就写啥。

如果你以前 Vibe Coding 给出的就是上面那种提示词，那我“惩罚”你去看一下我以前写的另一篇涉及大模型原理的文章，或许你会有更多收获，文章讲的不深奥，零基础的小白也能看懂：
【后端/agent开发】(含面试经历/图解)开发者为什么要了解Tool Calling，而不是只会Prompt？

之前提出的那些问题如果不提前想清楚，后面就会出现一种很常见的情况：Claude Code 确实在不断生成代码，但项目推进顺序是乱的。

一会儿让它写页面，一会儿让它改数据库，一会儿又补接口，最后项目看起来功能很多，但主流程可能根本没跑通。

1.1 我以前踩过的伪需求的坑

做产品嘛，肯定不能自己一拍脑门，想到个产品就去做，就好比我早期这篇文章其实想带着去做一个周报生成器，用户只需要输入都干了什么，并选定或上传周报格式模板，就能生成一份周报。

我当时觉得这个想法还挺合理：
写周报肯定需要叙事逻辑吧？那用户只要离散地输入自己做了什么，剩下的组织语言、调整格式、生成成稿都交给系统。

但是！经过我与多个 AI 讨论，并咨询了一些已经工作了的朋友，发现这根本就是伪！需！求！

朋友问：那你这个周报生成器有啥用啊？还是得我输入干了什么事，那它的作用是啥，也不能帮我省事啊。
我说：写周报肯定得有叙事逻辑吧！你用了我这个产品，就不需要自己去搞叙事逻辑了，你只需要“离散”地输入你都干了什么。
朋友 1：我们是表单提交，就根据各个小项填几个字就行了，不用叙事。
朋友 2：我们虽然是交文档，但是OKR也不需要叙事逻辑，主要是数据。

也就是说，我以为用户痛的是“不会组织周报语言”，但真实情况是，很多人根本不需要这种能力。

这就是典型的伪需求风险：

开发者觉得有用，用户不一定觉得有用。

所以这次做 JobLens 之前，我不想再自己拍脑门决定项目方向。第一步先让 Claude Code 从产品视角挑刺。

二、Prompt 1 ：判断需求是否是伪需求

这一步我没有让 Claude Code 写代码，也没有让它设计页面。

我只问它一件事：

JobLens 这个项目到底值不值得做？

这里我刻意让 Claude Code 从产品视角来判断，而不是从技术视角来判断。因为一个项目如果需求站不住，技术方案再漂亮也没有意义。

我给 Claude Code 的 Prompt 是这样的：

我想做一个小项目，项目名暂定 JobLens。

项目定位：
JobLens 是一个面向校招生的岗位追踪与投递进度管理看板。它帮助用户把分散在牛客、Boss 直聘、实习僧、企业官网、公众号、微信群、飞书表格、学校就业网等地方的岗位信息整理到一个统一看板里，并记录每个岗位的投递状态、截止时间、面试安排和下一步动作。

目标用户：
主要是正在找工作的用户，尤其是找实习/秋招的学生。

真实痛点：
1. 岗位信息来源太分散，经常收藏了很多链接但后面找不到。
2. 投递进度容易乱，不知道哪些岗位已投、哪些还没投、哪些正在笔试或面试。
3. 很多岗位有截止时间，容易错过。
4. 用户需要按城市、岗位方向、技术栈、公司类型、投递状态进行筛选。
5. 很多人最后只能用 Excel / Notion / 备忘录手动维护，但状态流转、截止提醒和统计不直观。

技术栈考虑：
Python + FastAPI + Mysql + React。
后续用 Stitch MCP 设计前端页面，用 Claude Code 辅助生成项目文档和代码。

请你从产品视角判断这个项目是不是伪需求。

请从以下角度分析：
1. 目标用户是否明确
2. 使用场景是否真实
3. 痛点是否足够具体
4. 现有方案有哪些，比如 Excel、Notion、飞书表格，它们的不足是什么
5. 是否适合个人快速开发

请最后给出结论：
- 这个项目是否值得做
- 如果要让项目更有亮点，应该加什么小功能

那么 Claude Code 也是给出了自己的判断，证实了这个需求可行：

● JobLens 产品可行性分析

  1. 目标用户是否明确

  明确，但有细分风险。

  校招/实习群体确实是高密度、高痛点用户群。但这个群体有两个特点：
  - 生命周期极短：秋招集中 8-11 月，春招 2-4 月，一个人真正重度使用可能就 2-3 个月
  - 获客渠道窄：集中在牛客、小红书、微信群，传播链路短

  这意味着用户获取成本不低，且用户留存天然差（找到工作就卸载）。

  2. 使用场景是否真实

  真实。 收藏链接 → 忘了在哪投的 → 错过 deadline → 面试安排记混，这个链条我判断大多数校招学生都经历过。场景是真实的。

  3. 痛点是否足够具体

  痛点具体，但"痛感"因人而异。 你列的 5 个痛点都是真实的，但有一个关键问题：有多少人愿意为这个痛点多维护一个工具？

  大多数人的解法是：忍着。用 Excel 记一下公司名和状态就够了。只有投递量特别大（50+）的人才会觉得"管理不过来"。

  4. 现有方案对比

  ┌────────────────┬──────────────────┬──────────────────────────────────┐
  │      方案      │       优点       │               不足               │
  ├────────────────┼──────────────────┼──────────────────────────────────┤
  │ Excel/备忘录   │ 零门槛，随时可用 │ 没有状态流转、没有提醒、没有统计 │
  ├────────────────┼──────────────────┼──────────────────────────────────┤
  │ Notion 模板    │ 好看，可筛选     │ 需要学 Notion，手机端体验一般    │
  ├────────────────┼──────────────────┼──────────────────────────────────┤
  │ 飞书多维表格   │ 强筛选、自动化   │ 需要飞书账号，偏企业场景         │
  ├────────────────┼──────────────────┼──────────────────────────────────┤
  │ 牛客/Offershow │ 有 offer 数据    │ 聚焦晒 offer，不是投递管理       │
  └────────────────┴──────────────────┴──────────────────────────────────┘

  核心差距： 现有方案都没有解决"从链接一键录入岗位信息"这个问题。用户还是手动填。如果你能解决这个，就有差异化。

  5. 是否适合个人快速开发

  前端部分适合，后端数据采集是硬骨头。 纯 CRUD + 看板 UI 一个人能搞。但如果要接入牛客/Boss
  直聘/企业官网的数据，反爬和接口变动会消耗大量精力。

  ---
  结论

  值得做，但需要调整定位，避免做成"又一个手动录入的表格工具"。

  如果只是把 Excel 搬到网页上，没有壁垒。核心差异化应该在 降低录入成本 和 提供主动提醒 上。

  建议加的小功能（按投入产出比排序）

  1. 链接智能解析（最关键）：用户粘贴一个岗位链接（牛客/Boss/企业官网），自动提取公司名、岗位名、城市、截止时间。不需要
  爬虫，用户粘贴 URL 后调用 LLM 解析页面内容即可。这是最大的差异化点。
  2. 微信/飞书消息转发录入：提供一个小程序或 bot，用户把招聘消息转发过来，自动解析成岗位卡片。
  3. Deadline 倒计时 + 浏览器通知：临近截止的岗位高亮提醒，比 Excel 强的地方。
  4. 投递时间线视图：不是简单的表格，而是按时间轴展示投递历程，一眼看到"这家公司笔试是下周"。
  5. 阶段转化率统计：投了多少家 → 笔试多少 → 面试多少 → offer 多少，给用户正反馈（也缓解焦虑）。

  ---
  一句话总结： 痛点真实，但壁垒不在"看板"本身，而在"自动录入"。把链接解析做好，这个项目就从"能用"变成"好用"。建议先做一个最小版本，只支持粘贴链接 + 看板管理，验证用户是否真的会用。

Claude Code 的反馈里，我觉得最关键的不是“值得做”这三个字，而是它提醒了我一个风险：

如果只是把 Excel 搬到网页上，没有壁垒。核心差异化应该在降低录入成本和提供主动提醒上。

这句话基本决定了 JobLens 后面的方向，JobLens 不能只是一个漂亮的投递表格。
如果它只是让用户手动填公司名、岗位名、城市、状态，那它确实没有比 Excel 强多少。

真正值得做的地方应该是：

用户看到岗位后，能不能更快地把它整理成一张岗位卡片？

所以我把项目重新收敛成两个核心能力：

第一，快速录入岗位。
用户可以手动填写，也可以粘贴岗位 JD 文本，让系统尝试提取公司、岗位、城市、技术栈、截止时间等信息。链接解析第一版不强求完全自动，先保存链接并允许用户补充信息。

第二，投递进度管理。
用户可以把岗位放到看板里，持续管理状态：待投递、已投递、笔试、面试、Offer、已结束。

这样一来，JobLens 就不再只是“网页版 Excel”，而是一个围绕校招投递流程设计的个人工作台。

三、Prompt 2：生成顶层需求设计文档

有了 Prompt 1 的反馈之后，我没有马上让 Claude Code 去设计页面、数据库和 API。

原因很简单：需求还没完全压稳的时候，过早进入页面和接口设计，很容易让项目变成“看起来很完整，但方向不一定对”。

所以我把文档拆成两层。

第一层是顶层需求设计文档，只回答几个问题：

• 这个项目为什么存在？
• 用户到底是谁？
• 用户在什么场景下会用？
• 第一版做什么，不做什么？
• 最大风险是什么？

只有这些问题清楚了，后面再去设计页面、数据和接口才有意义。

所以第二个 Prompt，我明确告诉 Claude Code：

不要写代码，不要设计页面，不要设计数据库字段，不要设计 API。
这一步只做顶层需求设计。

下面这段 Prompt 比较长，但它的结构其实很简单：先限制 Claude Code 不要写代码，再明确这一步只生成什么文档，最后规定哪些内容暂时不要碰。大家如果想复刻，可以直接整段复制。

你刚才对 JobLens 的判断很有帮助。

我接受你的核心建议：如果 JobLens 只是一个手动录入岗位的看板，它很容易变成“网页版 Excel”；真正有差异化的地方应该是降低录入成本，也就是“粘贴岗位链接或岗位 JD 文本后，自动生成岗位卡片”。

现在我不希望你开始写代码，也不希望你设计页面、数据库字段或 API。

我希望你先帮我完成 JobLens 的顶层设计文档，用于项目正式开发前的需求确认。

项目重新定位：

JobLens 是一个面向校招生的岗位追踪与投递进度管理看板。它的核心不是替代招聘平台，也不是自动爬取岗位，而是帮助用户把分散在牛客、Boss 直聘、实习僧、企业官网、公众号、微信群、飞书表格等地方看到的岗位，快速整理成统一的岗位卡片，并持续管理投递进度。

第一版重点突出两个能力：

1. 快速录入岗位  
用户可以通过以下方式添加岗位：
- 手动填写岗位信息；
- 粘贴岗位 JD 文本，让系统尝试解析公司、岗位、城市、技术栈、截止时间等信息；
- 粘贴岗位链接，系统先保存链接并允许用户补充信息，后续再扩展链接解析；
- 后续可以扩展 CSV 导入。

2. 投递进度管理  
用户可以把岗位放到看板中管理状态：
- 待投递
- 已投递
- 笔试
- 面试
- Offer
- 已结束

请你基于以上信息，帮我生成一份顶层需求设计文档。

文档目标：
这份文档用于确认项目方向，不用于直接写代码。
请重点关注产品需求、用户画像、用户流程、MVP 边界和风险控制。
不要输出页面设计、数据库字段、API 设计、技术架构细节、组件设计或代码。

请按以下结构输出并撰写对应文档到./docs目录下： 

# JobLens 顶层需求设计文档

## 1. 项目背景

请说明为什么校招生需要一个岗位追踪与投递进度管理工具。

重点围绕：
- 岗位信息来源分散；
- 投递数量多时进度容易混乱；
- 截止时间、笔试、面试时间容易遗漏；
- Excel、Notion、备忘录虽然能用，但维护成本高、状态流转不直观；
- JobLens 的价值不是“再做一个表格”，而是降低岗位录入成本，并让投递流程更清晰。

## 2. 项目定位

请用一段话定义 JobLens。

要求体现：
- 面向校招生；
- 岗位收集与投递进度管理；
- 支持从岗位 JD 文本或链接快速整理岗位信息；
- 聚焦个人求职流程管理；
- 第一版不做自动爬虫和自动投递。

## 3. 目标用户画像

请不要泛泛地写“所有校招生”。

请至少拆成以下几类用户，并说明他们的痛点、行为习惯和使用 JobLens 的价值：

1. 投递量较大的校招生  
例如预计投递 30 到 100 个岗位的人。

2. 多平台找岗位的学生  
例如同时关注牛客、Boss 直聘、实习僧、企业官网、公众号、微信群、飞书表格的人。

3. 技术方向明确的学生  
例如找后端、Java、Python、AI 应用开发、Agent 开发方向岗位的人。

4. 已经在用 Excel / Notion / 备忘录管理投递进度的人  
他们能维护，但觉得不够直观、不够自动化。

请输出每类用户的：
- 用户特征；
- 主要痛点；
- 当前替代方案；
- JobLens 能提供的价值。

## 4. 核心用户场景

请从真实求职行为出发，描述用户在什么情况下会使用 JobLens。

至少包括：

1. 看到岗位后快速保存  
用户在牛客、Boss、企业官网、微信群或公众号里看到岗位，希望快速保存下来，避免链接丢失。

2. 粘贴 JD 文本生成岗位卡片  
用户复制岗位 JD 文本，希望系统帮忙提取公司、岗位、城市、技术栈、截止时间等关键信息。

3. 投递后更新状态  
用户投递后，把岗位状态从“待投递”改为“已投递”。

4. 收到笔试 / 面试安排后记录进度  
用户收到笔试或面试通知后，记录时间、备注和下一步动作。

5. 每天查看待办和即将截止岗位  
用户打开 JobLens，查看哪些岗位快截止，哪些岗位需要跟进。

6. 求职阶段复盘  
用户想知道自己投了多少岗位，进入了多少笔试和面试，哪些方向反馈更好。

请用场景化语言描述，不要只列功能点。

## 5. 核心用户流程

请设计完整用户流程，但保持在产品层面，不要进入页面和接口设计。

流程可以包括：

1. 用户发现岗位；
2. 用户复制链接或 JD 文本；
3. 用户在 JobLens 中创建岗位记录；
4. 系统尝试解析 JD 文本或保存链接；
5. 用户检查并补充关键信息；
6. 岗位进入“待投递”；
7. 用户完成投递后更新状态；
8. 用户收到笔试 / 面试后继续更新状态；
9. 系统提醒即将截止和待跟进事项；
10. 用户在求职过程中持续复盘。

请说明这个流程中 JobLens 解决了哪些原本需要 Excel / Notion / 备忘录手动完成的事情。

## 6. MVP 范围

请重新定义第一版 MVP。

要求：
第一版重点验证“岗位快速录入 + 投递状态管理”是否有价值。

请分成三类：

### 必须做

请列出第一版必须包含的能力，但不要超过 6 项。

建议包括：
- 手动新增岗位；
- 粘贴 JD 文本并尝试解析岗位关键信息；
- 保存岗位链接；
- 管理投递状态；
- 查看即将截止 / 待跟进岗位；
- 基础统计和复盘。

### 可以做

请列出如果时间允许可以加入的功能。

可以考虑：
- CSV 导入 / 导出；
- 简单搜索和筛选；
- 面试复盘备注；
- 附件或链接记录，例如简历版本、面试复盘文档链接。

### 暂时不做

请明确第一版不做的内容，并说明原因。

必须包括：
- 不做自动爬虫；
- 不做自动投递；
- 不做登录注册；
- 不做多用户系统；
- 不做复杂 AI 岗位匹配；
- 不做微信 Bot / 飞书 Bot；
- 不做移动端 App；
- 不做实时消息推送。

## 7. 功能优先级原则

请说明 JobLens 第一版做功能时遵循什么原则。

例如：
- 优先解决高频、刚需、低实现风险的问题；
- 优先降低岗位录入成本；
- 优先保证投递状态清晰；
- 不为了炫技加入复杂 AI 能力；
- 不碰反爬严重的数据采集；
- 先做单用户闭环，再考虑扩展。

## 8. 项目风险与规避策略

请从产品和实现角度列出风险。

至少包括：

1. 用户不愿意额外维护一个工具；
2. JD 文本格式不统一，解析可能不稳定；
3. 岗位链接解析受平台限制；
4. 功能膨胀，项目变成复杂求职平台；
5. 手动录入体验不好，用户回到 Excel；
6. 如果过早做爬虫，容易被反爬和平台变化拖垮。

请给出每个风险的规避方式。

## 9. 后续扩展方向

请只列方向，不要展开实现。

可以包括：
- CSV 导入导出；
- QQ / 微信 / 飞书提醒；
- 面试复盘文件管理；
- JD 智能解析增强；
- 根据岗位要求生成准备清单；
- Agent 工作流：自动解析岗位、生成待办、提醒跟进、整理复盘。

注意：这些都不是第一版必须做的，只作为后续演进方向。

## 10. 顶层结论

请总结：

1. 调整后的 JobLens 为什么不是伪需求；
2. 它和普通 Excel / Notion 表格的区别是什么；
3. 为什么第一版 MVP 是可控的；

输出要求：
- 内容要像项目正式开发前的需求设计文档；
- 表达要清晰，但不要过度商业化；
- 不要写代码；
- 不要设计页面；
- 不要设计 API；
- 不要设计数据库字段；
- 不要进入 Stitch MCP；
- 重点完成顶层需求设计。

Claude Code 会在当前路径下生成一个文件 ./docs/joblens-design-doc.md，这就是顶层的需求文档了。

四、Prompt 3：生成下层产品与工程设计文档

顶层需求文档设计完了，下一步还要想清楚：

这个项目应该按什么顺序做？每一步做到什么程度算完成？如果中间跑偏了，怎么检查？

所以还要再让 Claude Code 生成一份更靠近执行层的开发计划。如果这一步不提前想清楚，后面很容易出现一种情况：Claude Code 确实在不断生成代码，但项目推进顺序是乱的。

要在已有需求分析文档的基础上，再设计五份更细粒度的文档：

docs/
├── joblens-design-doc.md              # 顶层需求设计文档，已生成
├── joblens-implementation-plan.md     # 实现计划、阶段任务、验收过程
├── joblens-feature-design.md          # 功能设计
├── joblens-data-design.md             # 数据设计
├── joblens-ui-requirement.md          # 页面需求
└── joblens-api-design.md              # API 设计草案

下面这个 Prompt 更偏工程设计，长度会更长一些，想复刻的话也可以直接复制。向 Claude Code 发送以下提示词，：

你已经完成了 JobLens 的顶层需求设计文档，并写入了 ./docs/joblens-design-doc.md

  这份文档已经明确了：
  - 项目背景
  - 项目定位
  - 目标用户画像
  - 核心用户场景
  - 核心用户流程
  - MVP 范围
  - 功能优先级原则
  - 项目风险与规避策略
  - 后续扩展方向
  - 顶层结论

  现在请你基于这份顶层需求设计文档，继续生成 JobLens 的下层产品与工程设计文档。

  注意：
  这一步仍然不要直接写业务代码。
  这一步的目标是把顶层需求进一步拆成可以开发、实现和验收的设计文档，为后续编码、页面设计和项目实现做准备。

  请你先读取：

  ./docs/joblens-design-doc.md

  然后在 docs 目录下继续生成以下 5 个文档：

  1. ./docs/joblens-implementation-plan.md
  2. ./docs/joblens-feature-design.md
  3. ./docs/joblens-data-design.md
  4. ./docs/joblens-ui-requirement.md
  5. ./docs/joblens-api-design.md

  文档只服务于 JobLens 项目本身。

  ---

  # 1. joblens-implementation-plan.md：项目实现计划

  请把 JobLens 从 0 到第一版可用拆成若干实现阶段。

  要求：
  - 不要一次性做完所有功能；
  - 每个阶段都要有明确目标；
  - 每个阶段都要有输入、输出、任务和验收过程；
  - 每个阶段都应该能独立验证；
  - 阶段顺序要符合真实项目开发流程；
  - 不要空泛写“完成开发即可”，验收过程要具体。

  ---

  # 2. joblens-feature-design.md：功能设计文档

  请基于 MVP 范围，拆解 JobLens 第一版的功能模块。
  至少要包括岗位管理模块、快速录入模块、投递状态管理模块、提醒模块、搜索和筛选模块、投递统计模块以及 CSV 导入导出模块。
  请注意：
  - 快速录入模块的第一版可以做成“辅助解析”，不要承诺百分百自动准确。如果解析失败，用户仍然可以手动补充。
  - 提醒模块的第一版只做页面内提醒，不做微信、QQ、邮件、短信推送。

  ---

  # 3. joblens-data-design.md：数据设计文档

  请设计 JobLens 第一版的数据结构，但不需要写数据库建表代码。
  至少包含以下实体：

  岗位记录：要区分必填字段、可选字段以及后续扩展字段。

  投递事件 / 状态变化：记录用于记录状态变化和求职过程。请说明它为什么有价值，比如后续可以生成投递时间线和复盘。

  提醒记录：第一版可以不单独建复杂提醒系统，但文档里可以预留设计。

  附件 / 资料链接：用于后续存简历版本、面试复盘文档、笔试准备资料链接。这可以作为后续扩展，不一定第一版实现。

  状态枚举设计：请定义岗位状态枚举，并说明每个状态对应的中文显示。

  
  ---

  # 4. joblens-ui-requirement.md：页面需求文档

  这是后续交给页面设计工具生成页面的基础文档。

  请注意：
  这一步不是让你生成前端代码，也不是写页面生成 Prompt。
  而是把页面需求描述清楚。

  页面风格要求：
  - 不要像普通后台管理系统；
  - 要像一个“校招投递工作台”；
  - 适合后续做成清晰、漂亮、可演示的前端界面；
  - 信息密度适中；
  - 视觉清爽；
  - 有看板感；
  - 有一点求职进度管理的仪式感。
  - 看起来要有高级感，不要太朴素

  请设计第一版页面结构。

  ---

  # 5. joblens-api-design.md：API 设计草案

  请基于功能设计和数据设计，设计第一版 API 草案。
  不需要写代码，只需要给出接口说明。
  ---

  输出要求：

  1. 请先读取 ./docs/joblens-design-doc.md。
  2. 请在 docs 目录下生成上述 5 个 Markdown 文档。
  3. 每个文档内容要清晰、可执行，不要写成空泛产品方案。
  4. 不要直接写业务代码。
  5. 不要生成前端代码。
  6. 不要进入页面设计工具实际绘图。
  7. 不要过度设计，第一版要保持个人项目可实现。
  8. 所有文档只服务于 JobLens 项目开发本身。

五份文档生成完毕：
写到这里其实有个问题：

文档是不是还可以继续拆？

当然可以。

如果继续往下拆，还能拆出测试计划、部署文档、组件设计、交互细节、错误码规范、日志规范等等。

但对于一个个人项目的 MVP 来说，我觉得到这里已经够了。

因为现在这六份文档已经回答了从“为什么做”到“怎么做”的关键问题。继续拆下去，很容易进入另一种误区：

文档写得越来越多，项目却一直没有跑起来。

所以我给自己定了一个边界：文档只要能支撑第一轮开发就够了。

第一轮开发的目标也不应该太大，只需要跑通最小闭环：

创建岗位 → 保存到数据库 → 前端展示 → 修改状态 → 刷新后数据不丢

我们开发项目可以做好准备，但是不能一直准备下去。

写在文后

这篇文章没有写一行业务代码，但我觉得它是整个项目里很关键的一步。
以前我用 AI 写项目时，最容易犯的错误就是：想法刚冒出来，就马上让 AI 搭页面、写接口、建数据库。这样确实很爽，但爽完以后经常发现项目边界没想清楚，功能越写越乱，最后变成一个半成品。
这次我换了一种方式。
先让 Claude Code 判断需求，再让它生成顶层需求文档，最后继续拆成实现计划、功能设计、数据设计、页面需求和 API 草案。
到这里，JobLens 已经从一个“我想做个求职管理工具”的想法，变成了一套可以开始开发的项目文档。
下一篇我会结合 Stitch MCP 和本篇产出的文档，进入前端页面的设计开发。

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