AI 编程：Cursor 实现简历筛选 App - 完成大模型简历分析功能

在上一期的开发中，我们已经搭建了一个简历筛选 App 的基础功能：可以查看职位信息、新建职位、编辑信息，并支持上传简历。

到了这一期，我们要借助 Cursor 把大模型简历分析这个核心能力补上。

需求背景

这个应用的目标其实很清晰——做一个网页版的简历筛选评分工具。HR 在筛选简历时，可以根据岗位职责要求，从一堆简历中快速找到匹配度最高的那位候选人。

需求本身不算复杂，但有一个关键点：简历匹配度的判断需要调用外部的大模型 API，才能实现智能分析。所以，这个应用本质上也是一个 AI 大模型应用。

实现简历分析

打开 Cursor，经过上一期的折腾，我们已经摸清楚了一个规律：开发项目时，有些场景适合用 Chat 来提问，有些则更适合用 Composer。尤其是当一个问题涉及多个文件同时修改时，Composer 的效果明显更好——Chat 容易遗漏部分代码的改动。

所以，这一期的简历分析功能，我们尽量用 Composer 来完成。

先打开项目文件，然后 Ctrl + I 启动 Composer。现在核心需求是：在简历管理列表里，增加一个“简历分析”操作。点击后，需要调用 Grok API 来对简历内容和当前职位详情进行匹配分析，最终给出一个评分。

这个操作会涉及多个文件的修改，最关键的是后端 Python 中调用 Grok API 的部分。Cursor 给出的代码大概长下面这样——但它自己也留了个尾巴：提示说 Grok API 的用法很可能不对，需要你实际替换。

为什么不对？因为大模型本身没有联网，它的训练数据里很可能没有 Gel 到 Grok API 的最新用法。这时候可以用 Cursor 的另一项功能——docs，把 Grok API 的官方文档链接喂给它。

这样一来，再提问时就可以 @ 这个文档，让模型基于最新的接口规范来生成代码。

到这里我们一直在用 Composer，但有些错误是跟命令行相关的，这时候 Composer 就不如 Chat 好使了。

解决掉这个命令行错误后，因为数据库结构有变更，还需要执行数据库迁移操作，否则上传简历时会直接报错。问一下 Cursor，它会告诉你迁移步骤。

迁移完成，重新运行应用，简历就能正常上传了。

点击简历旁边的“分析”按钮，进入分析操作。你可以输入自定义的提示词，也可以用系统默认的提示词来做评估。

不过，一开始分析会失败。这时候 Cursor 开始往代码里加日志，帮助定位问题。经过几轮调整，看到了错误原因：Grok-1 这个模型并不存在，Grok 当前可用的模型是 grok-beta。

修正模型名称后，再次运行——还是失败，但这次已经能看到更具体的错误信息。经过较长时间等待，得到一个失败的响应。问题出在响应结果的解析上。Cursor 给出的处理方式是让 AI 通过提示词直接返回 JSON 结构。

调整之后，可以看到 Grok API 已经成功调用了，AI 也返回了内容，只是前端界面没有显示出来。由于这个修复可能涉及多个文件，我们直接把问题描述加到 Composer 里，让它全自动处理。

再次运行，页面上直接提示：简历分析完成。点击查看分析详情，还能看到具体的匹配原因。

效果确实不错。

总结

整期开发下来，一行代码都没手敲，全程都在和 Cursor 对话。如果问一个完全不会代码的人能不能用这套流程把需求做出来——答案是肯定的。但你会发现，虽然不需要懂具体的语法，如果你有开发背景和编程思维，大概知道每个模块是干什么的，那用 Cursor 能省掉大量试错时间。

今天的过程也清晰展示了 Composer 和 Chat 的定位差异：如果修改涉及多个文件，Composer 是最合适的，因为它能自动批量调整；如果是一个特别具体的问题，或者跟命令行操作相关，那么用 Chat 会更直接。

最后，我们看看 Cursor 的 Usage 统计。完成整个项目大概用了 71 次高级模型调用。看来即便是 Pro 订阅，也无法支持一个程序员天天无节制地用高级模型。但如果确实能大幅提升效率，带来的收益远超过 Cursor 本身的订阅费用，那升级到 Business 套餐就是很划算的选择。

END