Work

AI Workflow

全栈工作流和prompt调优

JobMatch / Lets Go RSS

Overview

这里整理了两个 AI Workflow 项目:JobMatch 侧重全栈搭建,RSS 工作流侧重信息处理、prompt 调优和交付。

Core signalfrom vibe coding to working systems
Projects2
JobMatch focusFull-stack
RSS focusPrompt tuning
Evidence5 assets

Case dossiers

两个项目,两个重点

Case 01

JobMatch

Full-stack workflow

JobMatch 是一个全栈岗位管理项目:围绕 PRD、数据结构、JD 提取、前端确认和 GitHub 开发规范,展示把需求推进成完整产品流程的方式。

Build process

具体构建流程

  1. 01
    搭建全栈项目底座

    从 GitHub 获取主体框架,先确认前端、后端、存储、部署等完整技术栈,并把它作为项目模板;同时参考 MCP 框架,为后续功能接入预留结构。最终结合当前需求范围,没有将 MCP 功能纳入本次具体构建。

  2. 02
    用 PRD 固化需求边界

    以自建 PRD 文档为模板,结合 create-prd、brainstorming 等 skill,以及 agent 的 Plan Mode,持续沟通产品细节,逐步确定功能目标、用户场景和版本边界,并把结论沉淀到 JobMatch 的 PRD 文档中。

  3. 03
    反复追问未定细节

    PRD 初稿完成后,继续用 brainstorming 对未覆盖的产品细节逐轮提问,每次给出可选方案,再选择最适合当前版本的实现方式。

  4. 04
    沉淀项目 rules

    根据我常用技术栈和项目边界,包括前端 Next.js、后端 FastAPI 等规则,让 Codex 生成本项目专用 rules,确保 AI 在开发时始终理解技术约束、项目边界和不能跑偏的地方。

  5. 05
    根据使用体验持续优化

    在实际试用 JobMatch 的过程中,围绕岗位录入、JD 提取结果、字段校对和页面反馈继续调整细节,让流程更贴近真实求职管理场景。

PRD window

PRD 原文全文

产品需求文档:JobMatch v3.md
下载原文
# JobMatch v3 产品需求文档

**文档状态:** Current-state v3
**最后更新时间:** 2026-03-31
**产品名称:** JobMatch

---

## 一、项目背景和目标

### 1.1 项目背景

JobMatch v3 是一款面向中国大陆实习生和应届生的轻量求职流程管理台。
它解决的问题,不只是“把岗位记录下来”,还包括围绕岗位后续发生的一系列关键流程管理问题,例如:

- 原始 JD 分散,后续回看时难以找回
- 岗位字段没有整理,回看时仍需重新读长文
- 投递、截止、测评、面试、Offer 等信息散落在不同工具中
- 同一个岗位虽然被记录下来,但后续推进节奏没有被统一管理

因此,JobMatch v3 不再只是岗位记录工具,而是一个 **以岗位为中心的轻量流程管理工具**,帮助用户在同一个地方完成岗位收纳、信息整理、流程维护和节奏查看。

### 1.2 产品定位

JobMatch v3 的产品定位是:

**一个面向中国大陆实习生和应届生的轻量求职流程管理台。**

产品的核心特点是:

- 以岗位为中心管理信息
- 支持岗位录入、字段维护、流程节点维护、日历节奏查看和结构化对比
- AI 只用于辅助提取,不用于推荐、排序、决策或自动执行
- 产品以 Web 为主,桌面打包为辅

它不是一个推荐工具、判断工具,也不是一个复杂 CRM 系统。

### 1.3 目标用户

核心目标用户包括:

- 中国大陆的实习生和应届生
- 经常收到以微信信息、截图形式获取JD的用户
- 同时在看多个岗位的求职用户
- 岗位信息和流程信息分散在招聘平台、聊天记录、备忘录和日历工具中的用户
- 希望用比表格更直观、比平台收藏更可持续的方式管理岗位和流程的用户

非目标用户包括:

- 招聘方、猎头、企业协同场景
- 需要自动海投的用户
- 期望系统直接告诉自己“该选哪个岗位”的用户
- 需要公开搜索全市场岗位的用户
- 需要设置自动提醒的用户。

### 1.4 产品目标

JobMatch v3 的目标,是让用户把它当作自己的 **轻量求职流程台持续使用**,而不是只在第一次记录岗位时打开一次。

它优先解决五件事:

1. 让用户能快速把岗位存进系统
2. 让原始 JD 在有来源时被长期保留
3. 让当前岗位字段始终可编辑、可修正
4. 让每条岗位都可以继续维护关键流程节点
5. 让用户能按月看到截止、测评、面试和结果节奏。

---

## 二、功能详细说明

### 2.1 功能列表

JobMatch v3 当前核心功能包括:

1. 统一岗位创建
2. JD 粘贴录入
3. 纯手动创建
4. AI 辅助固定字段提取
5. 当前岗位记录管理
6. 原始 JD 快照保留
7. 流程节点与流程摘要
8. 月历视图
9. 搜索、筛选、归档和删除
10. 结构化对比
11. 轻量重复提醒

---

### 2.2 详细功能描述

#### 功能 1:统一岗位创建

产品通过统一新建页拥有两种正式录入方式:

- JD 粘贴录入
- 纯手动创建

两种路径都可以生成正式岗位记录。
其中,纯手动创建不是提取失败后的替代方案,而是一条正式、一等的录入路径。

---

#### 功能 2:JD 粘贴录入

用户在任意渠道看到岗位 JD 后,可将原始 JD 粘贴到统一新建页中,并手动触发字段提取。
系统会基于 JD 返回固定字段草稿,只补当前空白字段(用户如果之前手动填充过内容,系统不会覆盖而是保留信息);随后由用户核对、修改并保存岗位。

主要价值:

- 降低岗位录入成本
- 保留原始岗位依据
- 让用户快速形成结构化岗位信息。

---

#### 功能 3:纯手动创建

当用户没有完整 JD,但仍希望先记录岗位时,可通过纯手动方式创建岗位。
用户直接填写核心字段后即可保存岗位,系统生成正式岗位记录。后续如果拿到了原始 JD,还可以继续补充。

这保证了:

- 资料不完整时也能记录岗位
- 岗位管理不会因为缺少 JD 而中断。

---

#### 功能 4:AI 辅助固定字段提取

字段提取由后端统一管理,可以通过真实 LLM 或启发式 fallback 完成。
提取结果只作为可编辑草稿,不是系统真相。

当前固定字段包括:

- job_title:岗位名称
- company_name:公司名称
- normalized_city:归一化城市
- full_location_text:完整地点文本
- salary_text:薪资原文
- arrival_time:到岗时间
- application_method_text:投递方式原文
- resume_naming_convention:简历命名方式
- job_description_excerpt:职位描述原文片段
- job_requirements_excerpt:职位要求原文片段
- other_content_excerpt:其他内容

设计原则:

- 提取失败不阻断保存
- 只补空白字段,不自动覆盖已有内容
- 原文片段尽量保留结构,不总结、不改写。

---

#### 功能 5:当前岗位记录管理

用户日常搜索、筛选、查看、编辑和对比的核心对象,是当前岗位记录(CurrentJobRecord)。

规则包括:

- 所有字段都允许用户修改
- 用户修改后的值是当前生效记录
- 搜索、筛选、对比和详情展示主要基于这层记录
- 编辑当前记录时,不能覆盖原始 JD 快照

这一层代表系统中“用户当前认可的正式信息”。

---

#### 功能 6:原始 JD 快照保留

当岗位通过 JD 粘贴录入时,系统会保留一份 JD 快照(JDSnapshot)作为原始依据。

当前版本规则:

- 后台长期保留快照
- 前台详情页当前只展示最新一份快照
- 新快照不会自动覆盖当前岗位字段
- 纯手动创建的岗位可以暂时没有快照

该功能的主要价值在于保留原始依据,方便后续回看、核对和追溯。

---

#### 功能 7:流程节点与流程摘要

每条岗位都可以维护正式的流程节点(WorkflowEvent),例如:

- planned_apply(计划投递)
- application_deadline(投递截止)
- applied(已投递)
- assessment(测评)
- interview(面试)
- offer
- rejected(未通过)
- closed(关闭)

系统会基于这些节点,自动推导流程摘要,包括:

- 当前进度
- 下一节点
- 是否已过截止

这一步的意义,是让用户不仅能记录岗位,还能持续管理这条岗位后续发生的关键事件。

---

#### 功能 8:月历视图

系统提供按月查看的 CalendarMonth 视图,用于查看当前活跃岗位的关键流程节点。

当前规则:

- 默认聚焦未归档岗位
- 按月份查看截止、测评、面试和结果
- 支持从月历继续打开岗位详情
- 适合帮助用户理解“这个月要处理什么”

月历视图的核心价值,是让用户在时间维度上管理岗位节奏,而不只是停留在静态记录层。

---

#### 功能 9:搜索、筛选、归档和删除

主列表围绕已保存岗位工作,支持:

- 对当前字段搜索
- 对原始 JD 全文搜索
- 按城市筛选
- 按公司名称筛选
- 按归档状态筛选
- 归档岗位
- 删除岗位

其中:

- 归档用于保持主列表整洁
- 删除用于移除不再需要的岗位。

---

#### 功能 10:结构化对比

系统支持对已保存岗位进行结构化对比。
该功能属于支持能力,而不是主产品承诺本身。

当前规则:

- 只能选择已保存岗位
- 一次最少 2 个、最多 4 个岗位
- 用户自己选择对比字段
- 系统只展示字段,不输出自动结论、推荐或排序

该能力主要帮助用户在多个已保存岗位之间进行自主比较。

---

#### 功能 11:轻量重复提醒

系统在创建岗位时提供轻量重复提醒,但不自动合并岗位。

当前逻辑优先参考:

- 岗位名称
- 公司名称
- 归一化城市

如果没有可靠唯一标识,系统只做提醒,不做强制合并。

---

### 2.3 优先级排序

#### Must have(必须有):核心功能,满足基本需求

- 统一岗位创建
- JD 粘贴录入
- 纯手动创建
- AI 辅助固定字段提取
- 当前岗位字段编辑
- 原始 JD 快照保留
- 流程节点新增、修改、删除
- 进度、下一节点和是否过截止摘要
- 月历视图
- 搜索、筛选、归档和删除
- 轻量重复提醒

#### Should have(应该有):增强体验,提升转化

- 列表、详情、月历之间的一致性优化
- 快照历史展示优化
- 对比页阅读效率优化
- 字段提取失败后的引导体验优化
- 流程节点维护交互优化

#### Could have(可以有):锦上添花,非必需

- 更清楚地暴露快照历史
- 用户主动触发的更多输入来源补强
- 桌面端交付体验持续优化
- 结构化对比页进一步增强

#### Won’t have(暂不考虑)

- 自动推荐最优岗位
- 自动岗位排名
- 自动联系 HR
- 自动投递
- 自动持续抓取平台岗位
- 黑盒式职业建议
- 能力差距分析
- 复杂 CRM、团队协作、自动编排型重系统。

---

## 三、产品边界说明

JobMatch v3 的核心定位是:

**以岗位为中心的轻量流程管理工具,而不是判断工具、推荐工具或自动执行工具。**

因此,它明确不负责:

- 自动推荐更好的岗位
- 自动给岗位打分或排名
- 自动联系 HR 或自动投递
- 自动持续抓取全市场岗位
- 职业路线建议
- 能力差距分析
- 黑盒式决策

产品虽然支持记录 `已投递 / 面试 / Offer / 未通过 / 关闭` 等流程节点,但这并不意味着要演变成一个复杂招聘 CRM。
其首要目标仍然是:轻、可控、手动优先。

---

## 四、关键结果(KR)

**核心目标:** 证明用户愿意把 JobMatch 当作轻量求职流程台持续使用。

- 用户可以在 3 分钟内通过 JD 粘贴录入或纯手动创建保存一条岗位
- 100% 的已保存岗位都必须保留一份有效依据:原始 JD 快照,或纯手动创建时的核心三字段
- 100% 的字段提取失败场景都不能阻断保存
- 对已维护流程节点的岗位,列表、详情和日历展示的当前进度 / 下一节点 / 是否过截止必须保持一致
- 用户可以在 30 秒内通过搜索、筛选或日历找到之前保存的岗位或本月关键节点
- 用户可以从主列表选择 2-4 个已保存岗位并完成一次无推荐、无自动结论的结构化对比。

---

## 五、总结

JobMatch v3 的主承诺已经不再只是“岗位收纳”,而是:

**记录岗位 + 管流程节点 + 看时间节奏**

它的核心价值不是替用户做决策,而是把用户已经在做的岗位管理动作,放进一个统一、轻量、可持续维护的闭环中。

从产品演进角度看,JobMatch v3 已经从“轻量岗位记录工具”升级为“轻量求职流程管理台”,更接近真实求职过程中的持续使用场景。

Prototype

Axure 交互原型

打开完整原型

用 Axure 把 JobMatch 的岗位创建、字段提取、流程节点、日历和结构化对比做成了一套可交互原型,实现把需求文档进一步转成页面结构、信息层级和关键交互流程的能力。

Proof points

  • 从岗位存档、JD 提取、字段校对这些真实求职场景出发设计流程。
  • 演示视频展示从输入岗位信息到提取字段、确认校对的完整路径。
  • GitHub README 体现本地安全初始化、功能分支、检查、checkpoint/tag 等工程纪律。

Case 02

Lets Go RSS

Prompt tuning

Lets Go RSS 是一个 AI 前沿信息追踪系统:用 n8n 串起 RSS 抓取、摘要分类、入库和飞书推送,同时用 prompt_tuning 目录把分类与摘要能力拆成可测试、可对比、可迭代的实验。

Build process

具体调优流程

  1. 01
    明确 prompt 调优目标

    先把调优目标拆成三件事:分类要稳定落到六个固定类别,摘要要能说明核心事实和关注角度,输出必须能被 n8n 稳定读取。这样 prompt 调优不是追求“写得更像总结”,而是围绕可交付的结果迭代。

  2. 02
    固定每日真实测试物料

    每天从真实 RSS 信息流中摘取一批测试物料,保留标题、来源、时间、描述和链接,作为后续 prompt 调优的固定输入。每轮改 prompt 都在同一批物料上对比,避免只凭单次输出观感判断效果。

  3. 03
    保存不同版本的提示词

    把每一版提示词单独保存下来,并写清楚这一版主要想解决什么问题。这样后续对比时,可以知道变化来自哪里,也能在效果不稳定时回到上一版。

  4. 04
    合并记录 V1 到 V6 的调试路径

    从生产基线开始逐轮拆问题:V2 处理分类冲突;V3 梳理分类原则和易错规则;V4 强调只依据明确文本分类,并细化 AI产品 vs AI商业化 的边界;V5 强化输出完整性,避免漏条目、错编号或分类名跑偏;V6 将摘要升级为“事实 + 关注角度”的双句结构。

  5. 05
    确定提示词版本更替规则

    每一轮只改一个主要问题,再用同一批物料和上一版结果对比。只有新版本确实解决了当前问题,同时没有破坏分类稳定性、输出完整性和摘要可读性,才把它替换为新的基线;否则只作为实验记录保留,不进入正式工作流。

n8n 工作流画布,展示 RSS 抓取、DeepSeek 摘要分类、Neon 入库和飞书推送节点。
Automation mapRSS n8n 自动化链路

Webhook、RSS 抓取、去重、DeepSeek 摘要分类、Neon 入库与飞书推送串成完整工作流。

飞书多维表格截图,展示 RSS prompt 从 V1 到 V6 验证的测试提示词、测试物料和测试结果记录。
Prompt iterationRSS prompt 调优记录

飞书多维表格记录 V1-V6 / V6 验证,每轮都有测试提示词、测试物料、结果和差异点。

Evidence strip

证据墙

Full-stack flow

JobMatch 产品演示

从岗位文本输入,到 AI 提取字段,再进入人工确认与校对界面。

Engineering workflow

JobMatch GitHub 规范

README 记录本地安全初始化、功能分支、检查和 checkpoint/tag 流程。

Delivery proof

RSS 飞书交付效果

分类汇总后的每日 AI 前沿信息进入飞书群,成为真实可消费的信息产品。

Engineering workflow

Lets Go RSS GitHub 规范

README 记录 RSS 抓取、调试、运行和交付链路的项目说明。