chozzc/Lujie-Careerkit
1
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

【S3W3 交叉评测】录阶 CareerKit #3

New issue
Closed
opened 2026-08-06 11:00:29 +08:00 by Jyoti · 1 comment
Jyoti commented 2026-08-06 11:00:29 +08:00
Copy link

交叉评测意见

1. 项目理解

我理解“录阶 CareerKit”是一套面向实习、校招和社会招聘场景的 AI 求职工作台。项目不是只生成一份简历，而是将简历编辑与版本管理、JD 匹配、求职材料生成、投递进度跟踪、面试准备、模拟面试和复盘整合为一条连续工作流。

除 Web 应用外，项目还将简历优化、面试准备、模拟面试和求职沟通等能力封装为 4 个 Agent Skills，可供 Codex、Claude Code 等工具复用。仓库采用 Next.js、React、Prisma 和 SQLite，并提供在线预览与 Docker 本地部署方式。

2. 项目亮点

2.1 产品流程比较完整

项目已经从单点的“AI 简历生成器”扩展为较完整的求职管理工具。简历版本可以与目标岗位、投递记录和面试记录关联，生成的面试准备材料还支持 Word 和 PDF 导出，结果能够继续进入真实求职流程，而不是停留在一次对话中。

2.2 AI 修改边界落实到了代码中

src/lib/ai-service.ts 中对模型输出进行了结构化校验，并明确限制模型不得新增原简历不存在的学校、公司、项目、技能、数字和成果。JD、用户补充内容和简历文本也被明确作为分析材料处理，不能作为可执行指令。

src/lib/resume-review.ts 又进一步生成修改前后差异，支持用户逐条查看和采纳，而不是直接覆盖原简历。这种“AI 提建议、用户做最终决定”的设计，比一次性重写整份简历更可靠。

2.3 工程完整度较高

仓库不仅有页面代码，还包含 Prisma 数据模型、数据库迁移、文件解析、简历导出、面试材料导出、状态管理和大量 Vitest 测试文件，并提供 Dockerfile、docker-compose、双语 README、开源许可证和第三方声明。

在线 Demo 也可以直接访问，控制中心内已有简历、投递阶段和待跟进任务等示例数据，便于快速理解项目方向。

3. 当前存在的问题

3.1 比赛评审材料比较分散

项目功能很多，但仓库目前主要依靠一份较长的 README 展示。根目录暂未看到独立的项目 Specs、功能验收清单、测试结果、Demo 案例或架构说明。

评委需要自己从 README、源码、在线 Demo 和多个模块中判断“哪些功能已经完成、如何验证、对应哪段代码”，会增加理解成本。项目实际完成度可能高于评委短时间内能够看到的完成度。

3.2 AI 核心能力不方便无密钥评测

在线 Demo 可以直接查看示例数据和非 AI 功能，但 JD 匹配、AI 简历优化、模拟面试与 AI 复盘需要评委自行配置兼容模型的 API Key。

这会导致部分评委只能看到功能入口和说明，无法快速验证最核心的 AI 流程。当前 README 有配置步骤，但缺少一条无需准备环境、可在较短时间内完成的评审路径。

3.3 核心业务文件体积较大

src/lib/repository.ts 已超过 1200 行，承担简历、岗位、投递、面试、设置和示例数据等多个领域的持久化逻辑；src/lib/ai-service.ts 也包含多类 AI 任务。

当前功能可以运行，但随着后续继续增加求职场景，较集中的文件结构会提高修改冲突、回归测试和问题定位的成本。

4. 下一步建议

建议一：增加“评委 60 秒体验入口”

建议在 README 最前面增加一段简短的评审路径，例如：

  1. 打开在线 Demo；
  2. 查看示例简历；
  3. 进入 JD 匹配；
  4. 查看一份预生成的匹配结果；
  5. 进入模拟面试与复盘；
  6. 查看投递流程和导出材料。

对于必须使用 API Key 的步骤，可以提供录屏、截图或预生成结果，保证评委在不配置模型的情况下也能确认完整流程。

建议二：逐步拆分核心服务

可以将 repository.ts 按领域拆分为：

  • resume-repository.ts
  • job-repository.ts
  • application-repository.ts
  • interview-repository.ts
  • settings-repository.ts

将不同 AI 场景拆分为独立 service，并保留统一的模型调用、结构校验和错误处理层。这样更利于后续增加功能和定位问题。

5. 综合评价

这是一个完成度较高、产品方向明确的求职类 AI 项目，不是简单的页面原型或提示词包装。尤其值得肯定的是，它将简历版本、岗位、投递和面试材料组织成了持续可积累的数据结构，并且对 AI 编造事实和直接覆盖用户内容设置了明确边界。

项目目前最需要补充的并不是更多功能，而是让已有成果更容易被验证：通过清晰的 Specs、评审路径、Demo 案例、测试记录和模块对应关系，让评委能够在较短时间内确认项目确实实现了完整闭环。

如果这些交付证据得到补强，同时逐步拆分较集中的业务代码，项目的比赛展示效果、可信度和后续维护能力都会明显提升。

评测范围：公开仓库源码、README、在线 Demo、核心 AI 与简历审核逻辑、Prisma 数据结构、测试文件和 Docker 配置。
评测限制：本次未在本地启动项目，也未使用真实 API Key 调用模型，因此不对全部测试实际通过情况和模型输出效果作确定性判断。

## 交叉评测意见 ### 1. 项目理解 我理解“录阶 CareerKit”是一套面向实习、校招和社会招聘场景的 AI 求职工作台。项目不是只生成一份简历，而是将简历编辑与版本管理、JD 匹配、求职材料生成、投递进度跟踪、面试准备、模拟面试和复盘整合为一条连续工作流。 除 Web 应用外，项目还将简历优化、面试准备、模拟面试和求职沟通等能力封装为 4 个 Agent Skills，可供 Codex、Claude Code 等工具复用。仓库采用 Next.js、React、Prisma 和 SQLite，并提供在线预览与 Docker 本地部署方式。 ### 2. 项目亮点 #### 2.1 产品流程比较完整 项目已经从单点的“AI 简历生成器”扩展为较完整的求职管理工具。简历版本可以与目标岗位、投递记录和面试记录关联，生成的面试准备材料还支持 Word 和 PDF 导出，结果能够继续进入真实求职流程，而不是停留在一次对话中。 #### 2.2 AI 修改边界落实到了代码中 `src/lib/ai-service.ts` 中对模型输出进行了结构化校验，并明确限制模型不得新增原简历不存在的学校、公司、项目、技能、数字和成果。JD、用户补充内容和简历文本也被明确作为分析材料处理，不能作为可执行指令。 `src/lib/resume-review.ts` 又进一步生成修改前后差异，支持用户逐条查看和采纳，而不是直接覆盖原简历。这种“AI 提建议、用户做最终决定”的设计，比一次性重写整份简历更可靠。 #### 2.3 工程完整度较高 仓库不仅有页面代码，还包含 Prisma 数据模型、数据库迁移、文件解析、简历导出、面试材料导出、状态管理和大量 Vitest 测试文件，并提供 Dockerfile、docker-compose、双语 README、开源许可证和第三方声明。 在线 Demo 也可以直接访问，控制中心内已有简历、投递阶段和待跟进任务等示例数据，便于快速理解项目方向。 ### 3. 当前存在的问题 #### 3.1 比赛评审材料比较分散 项目功能很多，但仓库目前主要依靠一份较长的 README 展示。根目录暂未看到独立的项目 Specs、功能验收清单、测试结果、Demo 案例或架构说明。 评委需要自己从 README、源码、在线 Demo 和多个模块中判断“哪些功能已经完成、如何验证、对应哪段代码”，会增加理解成本。项目实际完成度可能高于评委短时间内能够看到的完成度。 #### 3.2 AI 核心能力不方便无密钥评测 在线 Demo 可以直接查看示例数据和非 AI 功能，但 JD 匹配、AI 简历优化、模拟面试与 AI 复盘需要评委自行配置兼容模型的 API Key。 这会导致部分评委只能看到功能入口和说明，无法快速验证最核心的 AI 流程。当前 README 有配置步骤，但缺少一条无需准备环境、可在较短时间内完成的评审路径。 #### 3.3 核心业务文件体积较大 `src/lib/repository.ts` 已超过 1200 行，承担简历、岗位、投递、面试、设置和示例数据等多个领域的持久化逻辑；`src/lib/ai-service.ts` 也包含多类 AI 任务。 当前功能可以运行，但随着后续继续增加求职场景，较集中的文件结构会提高修改冲突、回归测试和问题定位的成本。 ### 4. 下一步建议 #### 建议一：增加“评委 60 秒体验入口” 建议在 README 最前面增加一段简短的评审路径，例如： 1. 打开在线 Demo； 2. 查看示例简历； 3. 进入 JD 匹配； 4. 查看一份预生成的匹配结果； 5. 进入模拟面试与复盘； 6. 查看投递流程和导出材料。 对于必须使用 API Key 的步骤，可以提供录屏、截图或预生成结果，保证评委在不配置模型的情况下也能确认完整流程。 #### 建议二：逐步拆分核心服务 可以将 `repository.ts` 按领域拆分为： * `resume-repository.ts` * `job-repository.ts` * `application-repository.ts` * `interview-repository.ts` * `settings-repository.ts` 将不同 AI 场景拆分为独立 service，并保留统一的模型调用、结构校验和错误处理层。这样更利于后续增加功能和定位问题。 ### 5. 综合评价 这是一个完成度较高、产品方向明确的求职类 AI 项目，不是简单的页面原型或提示词包装。尤其值得肯定的是，它将简历版本、岗位、投递和面试材料组织成了持续可积累的数据结构，并且对 AI 编造事实和直接覆盖用户内容设置了明确边界。 项目目前最需要补充的并不是更多功能，而是让已有成果更容易被验证：通过清晰的 Specs、评审路径、Demo 案例、测试记录和模块对应关系，让评委能够在较短时间内确认项目确实实现了完整闭环。 如果这些交付证据得到补强，同时逐步拆分较集中的业务代码，项目的比赛展示效果、可信度和后续维护能力都会明显提升。 > 评测范围：公开仓库源码、README、在线 Demo、核心 AI 与简历审核逻辑、Prisma 数据结构、测试文件和 Docker 配置。 > 评测限制：本次未在本地启动项目，也未使用真实 API Key 调用模型，因此不对全部测试实际通过情况和模型输出效果作确定性判断。
chozzc commented 2026-08-07 00:21:23 +08:00
Owner
Copy link

我根据当前仓库源码、README 和线上版实际行为逐项核对了这份评测。

关于评审材料分散、缺少独立 Specs、测试结果和 Demo 案例的问题成立。项目功能已经比较完整，但评委需要在 README、源码、在线 Demo 和多个模块之间自行寻找验证路径，确实增加了理解成本。

关于无 API Key 时无法完整体验 AI 流程的问题也成立。在线版可以直接查看示例数据、简历编辑、投递流程和部分导出能力，但 JD 匹配、简历优化、模拟面试和 AI 复盘仍需要配置可用的模型服务。因此，提供预生成结果、录屏或一条无需配置环境的评审路径，会比单纯增加功能更有帮助。

关于 repository.ts 和 ai-service.ts 集中度较高的问题，我认为这是维护性风险，而不是当前功能缺陷。当前集中式仓储边界有利于本地单用户版本保持一致性，但随着领域继续增加，后续可以按简历、岗位、投递、面试和设置逐步拆分。这个重构不应为了比赛临时大范围进行，以免引入回归问题。

当前版本已经具备以下实现：

  • AI 输出经过结构化数据校验；
  • 提示词明确限制新增不存在的经历、技能、数字和成果；
  • 简历优化支持原文与建议对照；
  • 用户可以逐条接受、拒绝或编辑修改；
  • 原简历不会被直接覆盖；
  • AI 输入会移除联系方式和内部编辑元数据；
  • 项目包含测试文件和 Docker 部署配置。

我在本地重新运行了测试和 lint，目前均通过，但这些结果还没有通过 CI 状态或 README 评审清单公开展示。

因此，本轮最有价值的改进不是继续增加模块，而是降低评委验证已有能力的成本。后续会优先考虑：

  1. 在 README 顶部增加“评委 60 秒体验路径”；
  2. 提供不依赖 API Key 的预生成 AI 案例；
  3. 增加 Specs、功能验收清单和测试结果说明；
  4. 逐步补充核心 AI 流程与 Agent Skills 的映射；
  5. 在功能稳定后再按领域拆分集中式仓储逻辑。
我根据当前仓库源码、README 和线上版实际行为逐项核对了这份评测。 关于评审材料分散、缺少独立 Specs、测试结果和 Demo 案例的问题成立。项目功能已经比较完整，但评委需要在 README、源码、在线 Demo 和多个模块之间自行寻找验证路径，确实增加了理解成本。 关于无 API Key 时无法完整体验 AI 流程的问题也成立。在线版可以直接查看示例数据、简历编辑、投递流程和部分导出能力，但 JD 匹配、简历优化、模拟面试和 AI 复盘仍需要配置可用的模型服务。因此，提供预生成结果、录屏或一条无需配置环境的评审路径，会比单纯增加功能更有帮助。 关于 repository.ts 和 ai-service.ts 集中度较高的问题，我认为这是维护性风险，而不是当前功能缺陷。当前集中式仓储边界有利于本地单用户版本保持一致性，但随着领域继续增加，后续可以按简历、岗位、投递、面试和设置逐步拆分。这个重构不应为了比赛临时大范围进行，以免引入回归问题。 当前版本已经具备以下实现： - AI 输出经过结构化数据校验； - 提示词明确限制新增不存在的经历、技能、数字和成果； - 简历优化支持原文与建议对照； - 用户可以逐条接受、拒绝或编辑修改； - 原简历不会被直接覆盖； - AI 输入会移除联系方式和内部编辑元数据； - 项目包含测试文件和 Docker 部署配置。 我在本地重新运行了测试和 lint，目前均通过，但这些结果还没有通过 CI 状态或 README 评审清单公开展示。 因此，本轮最有价值的改进不是继续增加模块，而是降低评委验证已有能力的成本。后续会优先考虑： 1. 在 README 顶部增加“评委 60 秒体验路径”； 2. 提供不依赖 API Key 的预生成 AI 案例； 3. 增加 Specs、功能验收清单和测试结果说明； 4. 逐步补充核心 AI 流程与 Agent Skills 的映射； 5. 在功能稳定后再按领域拆分集中式仓储逻辑。
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
chozzc/Lujie-Careerkit#3
No description provided.