在上一期中，我们的简历筛选 app 完成了基础的职位信息查看，新建，编辑和简历上传功能。

接下来在本期中，我们将利用 Cursor 继续完成大模型简历分析的功能。

我的需求是实现一个简历筛选评分的应用，用网页实现就可以。

主要目标是解决 HR 筛选简历时，可以根据岗位的职责要求，从多份简历中选择出匹配度最高的简历。

我的需求很明确，里面除了基本的应用功能外，判断简历匹配度的部分，还需要调用其他大模型API 才能实现，所以这个应用如果做出来了，也算是一个 AI 大模型应用。

打开我们的 Cursor ，经过上一期的多种操作，我们发现了 Cursor 开发项目的时候，你有时候得用 Chat 去提问，有时候得用Composer ,但是如果是那种一个问题可能针对多种文件进行修改的情况， Composer 的效果明显会好很多，Chat 容易遗漏部分代码功能。

所以本期的简历筛选，我们就尽量去使用 Composer 来完成。

首先还是用 Cursor 打开我们的项目文件。

然后 ctrl + I 打开 Composer 。

现在我们的要求是，在简历管理的列表中，需要增加一个操作是简历分析，该操作需要调用Grok API 来对简历内容和当前的职位详情进行分析匹配，从而判断该简历的得分是多少。

该操作会更新多个文件，其中最关键的是后端 python 中调用 grok api 的部分，他给的代码是下面这样。

并且 Cursor 也特别提到了， Grok API 这里很可能用的不对，要你实际替换用法。

为什么会不对呢？是因为这里大模型本身没有联网，所以很可能训练的代码里面不不知道 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 订阅。