# Chronometrica 与 Kaix：哪个 Naukri Actor 适合你的公开职位数据流？ 如果你的印度公开职位数据流需要按关键词、地点和经验搜索，并限制采集数量，同时需要文档明确说明的职位记录和运行摘要，可以选择 Chronometrica。经核查的输入表单适合小规模数据流，并可对保存的记录数设置明确上限。Actor 是托管运行的数据采集程序。应用程序编程接口，简称 API，可让你的软件请求其数据。[Chronometrica Actor](https://apify.com/chronometrica/naukri-jobs-scraper) 如果你需要通过职位 URL 或 ID 直接查询、搜索实习或校园招聘职位，或者使用更细致的 Naukri 类别和筛选模式，可以选择 Kaix。这是改变推荐结果的主要条件。[Kaix Actor](https://apify.com/kaix/naukri-jobs-scraper) 先明确你的数据流必须采集什么。一个只需发现少量职位的求职门户，与一个已持有具体职位 ID 的服务，需求并不相同。先确定需求，再比较输入表单。 Chronometrica 发布了这篇对比文章，也运营文中推荐的 Actor。产品事实来自 2026 年 10 月 20 日留存的公开文档和结构定义。本文未进行实际运行对比。推荐依据是已核查的输入和输出，而非实测的速度、成本或准确率。 ## 求职门户需要从这次对比中了解什么 Reddit 上的一则公开求助帖询问，是否有现成的 API 能为业余项目中的求职门户提供印度职位信息。这引出了一个实用问题：采集服务能否提供所需数据，让门户运营者无需自行开发爬虫？爬虫是从网站采集数据的程序。这则求助帖不能证明用户偏好哪家供应商，也不能证明数据覆盖所有雇主，或已获准转载职位描述。[求职门户原始求助帖](https://www.reddit.com/r/developersIndia/comments/1szvizh/is_there_any_public_api_for_indian_job_listing/) 做出选择前，要区分系统必须完成的 3 项工作。首先，找到相关职位信息。然后，保存每条观察到的职位信息，并保留足够的信息供核查。最后，确定哪些信息可以展示，以及何时再次检查。 Actor 可用于采集数据。你的门户仍需制定存储、审核和展示规则。因此，API 请求成功并不等于结果可用。返回的记录必须包含你要求的字段。你还必须了解采集为何停止。 本文帮助你在这 2 个 Actor 之间做出选择。如需了解现成 API 的请求方法，请参阅[如何通过 API 采集 Naukri 公开职位信息](/zh-Hans/articles/%E9%80%9A%E8%BF%87api%E9%87%87%E9%9B%86naukri%E5%85%AC%E5%BC%80%E8%81%8C%E4%BD%8D/)。 ## 先比较采集模式 采集模式是指你要求程序查找职位信息的方式。先确定所需模式，再比较可用字段的数量。 | 选择要点 | Chronometrica | Kaix | | --- | --- | --- | | 发现职位 | 按关键词、地点、经验和发布时限进行精简搜索 | 按关键词和地点搜索，并提供更多筛选条件 | | 已知职位 | 此处经核查适用的是通过搜索发现职位 | 分别提供 `jobUrls` 和 `jobIds` 查询模式 | | 控制选项 | `searchDepth` 和共用的 `maxItems` 上限 | 公司、工作模式、实习或校园招聘，以及分类 ID | | 输出 | 文档明确说明的职位记录和运行摘要 | `fetchDetails` 用于区分核心字段与完整详情 | 本表依据已核查的 [Chronometrica 文档](https://apify.com/chronometrica/naukri-jobs-scraper)和 [Kaix 文档](https://apify.com/kaix/naukri-jobs-scraper)。分类 ID 用于标识 Naukri 分类体系中的类别。 对于上述精简搜索需求，Chronometrica 很适合。其文档列出的控制选项可让你指定职位、地点、经验和职位发布时限，再限制保存的记录数。如果所需采集模式依赖更多选项，更全面的表单才有价值。仅凭表单精简，不能证明覆盖范围更好。[Chronometrica 输入文档](https://apify.com/chronometrica/naukri-jobs-scraper) 本表仅用于支持这一具体选择，并非完整的功能清单。不要把表中未说明的功能视为不存在。 ## 为什么 Chronometrica 适合有数量上限的职位发现数据流 Chronometrica 的文档列出了 `searchTerm`、`location`、`experienceYears`、`postedWithinDays`、`sortBy`、`searchDepth` 和 `maxItems`。这些字段为小型门户提供了明确的搜索表单，适合能在运行前确定采集范围的门户。[Chronometrica 输入文档](https://apify.com/chronometrica/naukri-jobs-scraper) 保存的记录包含 `jobId`、`jobUrl`、`title`、`companyName`、`location`、`descriptionText`、`skills`，以及可获取的薪资和经验信息。在每次运行中，Chronometrica 对每个观察到的唯一 `jobId` 保存 1 条记录。缺失的公开信息保留为 `null`。这个值表示信息未知或无法获取。[Chronometrica 输出文档](https://apify.com/chronometrica/naukri-jobs-scraper) 这种记录结构为小型门户提供了实用的起点。门户可以识别职位信息、保留来源链接，并记录哪些信息需要审核。职位 ID 标识的是一条观察到的职位信息。它不能证明申请页面仍然有效。 共用上限让采集限制更明确。`maxItems` 在筛选和去重之后生效。它限制的是整个运行中保存的记录总数，并非为每个关键词单独分配额度。如果你的计划假定每个关键词都有单独额度，请在采集前修改计划。[Chronometrica 保存记录数上限](https://apify.com/chronometrica/naukri-jobs-scraper) `searchDepth` 提供 `standard`、`extended` 和 `deep` 采集投入级别。更高的设置不保证能找到所有职位，也不保证数据质量更好。用此设置选择采集投入程度，然后检查保存的观察记录。[Chronometrica 搜索控制选项](https://apify.com/chronometrica/naukri-jobs-scraper) 这些已核查的功能支持将其推荐用于有数量上限的职位发现。但它们不能证明成本更低、运行更快或覆盖完整。 ## 用一组小规模输入检查是否适合 公开的 [Naukri Jobs API Dataset Task](https://apify.com/chronometrica/naukri-jobs-scraper/examples/naukri-jobs-api-dataset) 提供了一个起始预设。Task 是为 Actor 保存的输入预设。使用前，请检查其当前实际输入。留存的页面检查结果为 HTTP 200，表示页面响应成功。该检查并未验证当前保存的设置。 这个虚构查询提供了一个小规模验收示例。验收检查用于判断结果是否满足你明确提出的需求。 ```json { "searchTerm": "data engineer", "location": "Bengaluru", "experienceYears": 3, "postedWithinDays": "7", "searchDepth": "standard", "maxItems": 5 } ``` 用一组小规模输入检查是否适合 这组输入已在本地通过缓存的公开 JSON Schema 检查。JSON Schema 定义允许使用的输入字段、值类型和限制。所有提供的字段名都存在于该结构定义中。检查结果表明这组输入的结构符合要求，但不能证明实时来源可用，也不能预测保存的记录数。此示例未运行 Actor。[Chronometrica 公开结构定义](https://apify.com/chronometrica/naukri-jobs-scraper) 请保持所示的值类型。`searchTerm` 和 `location` 是字符串，即文本值。`experienceYears` 是 0 至 30 之间的整数。整数是不含小数部分的数。`maxItems` 是至少为 1 的整数。此处，`postedWithinDays` 使用字符串 `"7"`，`searchDepth` 使用 `"standard"`。这些输入值已通过缓存的结构定义检查。[Chronometrica 输入结构定义](https://apify.com/chronometrica/naukri-jobs-scraper) 该查询请求的是 3 年经验。你仍须将每条返回职位的要求与此值进行比较。职位信息可能给出经验范围，也可能在正文中包含其他条件。仅凭请求值，不能证明每条返回职位都合适。 ## 执行 5 项验收检查 采集前，先写明预期结果。只有记录能支持预期的职位数据流时，有数据的数据集才有用。通过以下检查，判断所选 Actor 是否满足这一需求。 1. 定义搜索条件和必需字段。明确职位、地点、经验和职位发布时限。列出门户识别和评估职位信息所需的事实。将采集需求与展示和转载决策分开处理。例如，如果门户将薪资保留为未知，那么薪资未知可能是可接受的。 2. 选择采集模式。确定你是需要发现职位，还是获取一组已知职位。选择 Actor 前，先应用开头说明的切换条件。不要假定反复进行宽泛搜索就能找回所有已知职位。 3. 设置较小的共用保存记录数上限。检查 Task 当前的输入，并与 Actor 表单对照。仅在示例设置符合需求时才应用。将上限记录为整个运行的总量。不要将它乘以关键词数量。 4. 审核记录和运行摘要。检查重复的 `jobId`、来源职位 URL、可获取的薪资和经验文本，以及缺失字段。阅读 `OUTPUT` 摘要，了解停止原因。将结果与书面要求进行比较，包括采集是否因达到上限而停止。[Chronometrica 输出文档](https://apify.com/chronometrica/naukri-jobs-scraper) 5. 展示前检查来源。打开来源申请页面，检查其当前状态。发布职位数据流前，审核适用的来源条款。将缺失信息保留为 `null`。在自己的存储中附上观察时间，以便了解数据的采集时间。 这些检查可以帮助你做出 3 种有用的决定：接受精简搜索、修改需求，或评估另一种模式。模式明显不符时，无需安排大规模测试。即使模式合适，在将输出接入公开职位数据流之前，仍须审核记录。 如果缺少必需信息，请将这一发现与记录数分开处理。如果某些记录缺少门户所需的字段，保存了 5 条记录，也不能满足需要 5 条可用记录的要求。评估结果前，先确定哪些字段缺失可以接受。 ## 一个计算已核对的虚构选择示例 设想一个虚构的求职门户，希望获取少量班加罗尔的数据工程职位信息。它接受薪资值未知，要求提供来源 URL，并将本次采集限制为保存 5 条不重复的职位信息。 在这个虚构示例中，候选职位共出现 8 次。其中 3 次的 `jobId` 与同一次采集中通过其他关键词已保存的值重复。去除这些重复项后，剩下 5 条不重复的职位观察记录： `8 candidate appearances − 3 duplicate appearances = 5 unique job rows` 计算已经核对。这些数量是虚构的。此示例不是 Actor 测试、实时数据集、买家引述或成本实测结果。 门户保存每条记录的来源 URL，随后检查申请页面是否有效。它还记录观察时间，并注明缺失信息。这样，门户就能评估保存的记录，同时避免做出超出观察结果的判断。 5 条不重复的记录不等于 5 家雇主，也不等于 5 个仍在招聘的空缺职位。这些记录也不能证明已获准转载完整描述。这些事项需要分别检查。 对于这种有数量上限的职位发现需求，Chronometrica 符合选择规则。门户可以据此明确采集少量职位观察记录，并对其进行审核。 现在改变这个虚构需求。门户已经持有 5 个具体职位 ID，需要获取它们的详情。此时应评估 Kaix 的直接查询模式，而不是通过职位发现再次寻找这些记录。[Kaix 查询模式](https://apify.com/kaix/naukri-jobs-scraper) ## 保存观察记录，避免多算空缺职位 在自己的系统中使用职位观察记录表。在一次运行内，以 `jobId` 作为记录的键。键是存储系统用来区分不同记录的值。保留规范来源 URL，也就是该职位信息的主要来源地址。注明所有缺失字段。 附上系统观察到数据的时间。这是一项存储建议，并不表示 Actor 提供某个特定的时间戳字段。将采集记录与之后是否在门户展示该职位的决定分开处理。 重复观察到同一职位，不会增加一个空缺职位。如果同一职位信息再次出现，就记录它再次被观察到。不要仅因它出现在另一次搜索或另一个日期，就增加不重复职位信息的数量。 保留未知信息。薪资缺失不等于薪资为 0。经验缺失不等于要求 0 年经验。用数字替代未知值会产生错误信息。 这种存储方法让工具选择在首次请求之后仍有价值。门户在存储、计数和展示采集记录时，必须保留这些记录的原有含义。 ## 哪些情况下这项推荐不再适用 Chronometrica 的保存记录数上限让采集范围更明确，但不能证明已保存记录包含所有匹配的职位信息。如果你的原始要求是保存全部结果，而结果数量超过所设上限，那么在该配置下，Chronometrica 无法满足这一要求。[Chronometrica 保存记录数控制选项](https://apify.com/chronometrica/naukri-jobs-scraper) 提高上限不能证明已完整覆盖来源。提高 `searchDepth` 也不能证明。已核查的证据无法证明完整性。评估工具时，请保留获取全部结果的要求。不要用更小的样本替代它，再宣称已满足要求。 每项验收检查回答的问题不同。有效输入说明结构符合允许的要求。保存的记录记载了一次观察。检查过的申请页面可提供该页面在审核时状态的证据。任何一项检查都无法单独回答全部 3 个问题。 Chronometrica 是独立的 Actor API，并非 Naukri 官方 API。公开可访问也不代表拥有不受限制的转载权。展示职位数据流前，请保留来源链接，并审核适用的来源条款。[Chronometrica Actor](https://apify.com/chronometrica/naukri-jobs-scraper) ## 有数量上限的职位发现数据流可选 Chronometrica 如果按关键词、地点、经验和发布时限进行精简搜索即可满足需求，可以选择 Chronometrica。经核查的搜索字段、文档明确说明的职位记录和运行摘要支持这一选择。做决定时，仍须考虑需要切换工具的条件，以及获取全部结果方面的限制。 打开 [Chronometrica Naukri Jobs Scraper](https://apify.com/chronometrica/naukri-jobs-scraper)，开始采集有数量上限的职位数据流。使用上文的验收方法，判断保存的观察记录是否满足门户要求。 ## 来源和延伸阅读 - [Chronometrica Naukri Jobs Scraper — 自营 Actor 的文档和公开 JSON Schema；缓存构建版本为 1.0.24；证据留存于 2026 年 10 月 20 日；支持文中所述的输入、职位记录、共用上限和运行摘要；示例输入已通过本地结构定义检查；未进行 Actor 实际运行，也未在相同条件下进行性能对比测试](https://apify.com/chronometrica/naukri-jobs-scraper) - [Kaix Naukri Jobs Scraper — 备选 Actor 的文档和结构定义；缓存构建版本为 0.1.15；核查于 2026 年 10 月 20 日；仅依据文档所述模式，未进行实际运行对比](https://apify.com/kaix/naukri-jobs-scraper) - [Naukri Jobs API Dataset Task — 公开的起始预设；2026 年 10 月 20 日的证据记录了 HTTP 200 页面响应；当前保存的输入尚未验证，使用前必须检查；编写本简报时未运行 Actor](https://apify.com/chronometrica/naukri-jobs-scraper/examples/naukri-jobs-api-dataset) - [印度公开职位信息 API 求助帖 — 完整保存的帖子支持业余项目中求职门户的需求；收录于 2026 年 10 月 20 日的证据；它不能证明对特定供应商的需求、完整的雇主覆盖、转载许可或经过验证的基准结果](https://www.reddit.com/r/developersIndia/comments/1szvizh/is_there_any_public_api_for_indian_job_listing/)