> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pubrio.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 人员 + 公司筛选器
> 在一次 /people/search 调用中同时使用人员级和公司级筛选器 — 与 /companies/search 共用同一筛选引擎。
`POST /people/search` 现在接受 `POST /companies/search` 支持的所有公司筛选器。无需先查公司、收集 ID,再喂给第二次人员查询 — 一次请求覆盖两层。
## 一个请求体,两类参数
`/people/search` 请求体在概念上分成两类筛选器。它们在 JSON 中处于同一层级,可以自由组合。
针对*人员*属性的筛选:
| 参数 | 说明 |
| ---------------------- | ----------------------------------------------- |
| `people_titles` | 职位(自由文本或 slug) |
| `management_levels` | `founder`、`c_suite`、`vp`、`director`、`manager` 等 |
| `departments` | `master_engineering`、`master_sales` 等 |
| `department_functions` | 子部门 / 职能 slug |
| `people_locations` | 人员所在国家代码 |
| `people_groups` | 已保存的群组 ID |
| `peoples` | 指定的 `people_search_id` |
| `linkedin_urls` | 人员 LinkedIn URL |
| `social_media` | 各社交网络的账号 |
针对人员所在*公司*的筛选 — 与 `/companies/search` 同名,只有少数位置类键带 `company_` 前缀:
| 参数 | 说明 |
| --------------------------- | ---------------------------------- |
| `technologies` | 公司使用的技术 slug ID |
| `categories` | 类目 slug ID |
| `verticals` | 垂直 slug ID |
| `vertical_categories` | 垂直类目 slug ID |
| `vertical_sub_categories` | 垂直子类目 slug ID |
| `keywords` | 与公司描述匹配的自由文本关键词 |
| `founded_dates` | 成立年份区间,例:`[2015, 2023]` |
| `employees` | 员工区间,例:`[[100, 500], [501, 1000]]` |
| `revenues` | 收入区间(美元) |
| `company_locations` | 公司总部所在国家代码 |
| `company_exclude_locations` | 要排除的国家代码 |
| `company_places` | 要包含的城市 / 地区名 |
| `company_exclude_places` | 要排除的城市 / 地区名 |
| `companies` | 指定的 `domain_search_id` |
| `domains` | 指定的公司域名 |
| `company_linkedin_urls` | 公司 LinkedIn URL |
`company_` 前缀只在位置/地点类筛选上出现,因为裸名 `places` / `locations` 已被*人员*的地址字段占用。其他键都使用裸名(`technologies`,而不是 `company_technologies`)。
***
## 四步构建一个查询
具体是哪些人?职位、级别、部门、国家。这层放在请求体的**顶层** — 精度通常由公司条件承担。
他们必须任职于哪些公司?行业、规模、成立年份、总部国家、技术栈。把这些归到一个 **`company_filters: {...}`** 对象里,这样每个键属于哪一层一目了然。
任何需要精度的多值筛选器(例:"*同时*使用这些技术"),在 `company_filters` *内部* 的 `filter_conditions` 中加一条记录。默认是 OR。
`POST /people/search`。两种风格都接受,但 `company_filters: {...}` 更易读,也与 [Monitor](/cn/developer-guides/introduction) 的载荷结构一致。
### 完整示例
需求:位于美国、成立于 2015 至 2023 年、员工 100-5000、*同时*使用 Kubernetes 和 Docker、但总部不在旧金山的中型公司中的工程副总裁或 CTO。
```bash cURL theme={null}
curl -X POST https://api.pubrio.com/people/search \
-H "Content-Type: application/json" \
-H "pubrio-api-key: YOUR_API_KEY" \
-d '{
"people_titles": ["VP of Engineering", "CTO"],
"company_filters": {
"company_locations": ["US"],
"company_exclude_places": ["San Francisco"],
"founded_dates": [2010, 2024],
"employees": [[100, 500], [501, 1000], [1001, 5000]],
"technologies": ["Kubernetes", "Docker"],
"is_enable_similarity_search": true
},
"per_page": 25,
"page": 1
}'
```
```python Python theme={null}
import requests
response = requests.post(
"https://api.pubrio.com/people/search",
headers={
"Content-Type": "application/json",
"pubrio-api-key": "YOUR_API_KEY",
},
json={
"people_titles": ["VP of Engineering", "CTO"],
"company_filters": {
"company_locations": ["US"],
"company_exclude_places": ["San Francisco"],
"founded_dates": [2010, 2024],
"employees": [[100, 500], [501, 1000], [1001, 5000]],
"technologies": ["Kubernetes", "Docker"],
"is_enable_similarity_search": True,
},
"per_page": 25,
"page": 1,
},
)
print(response.json())
```
```javascript Node.js theme={null}
const response = await fetch("https://api.pubrio.com/people/search", {
method: "POST",
headers: {
"Content-Type": "application/json",
"pubrio-api-key": "YOUR_API_KEY",
},
body: JSON.stringify({
people_titles: ["VP of Engineering", "CTO"],
company_filters: {
company_locations: ["US"],
company_exclude_places: ["San Francisco"],
founded_dates: [2010, 2024],
employees: [[100, 500], [501, 1000], [1001, 5000]],
technologies: ["Kubernetes", "Docker"],
is_enable_similarity_search: true,
},
per_page: 25,
page: 1,
}),
});
console.log(await response.json());
```
***
## 键重映射参考
`/people/search` 把公司筛选器交给共享引擎时,位置/地点类键会被改写为裸名。引擎和 `filter_conditions[].key` 实际看到的是裸名:
| 你发送的字段(人员 API 名) | 引擎看到的字段(公司 API 名) |
| ----------------------------------------------------------------------------------------------------------------------------------------- | ------------------- |
| `company_locations` | `locations` |
| `company_exclude_locations` | `exclude_locations` |
| `company_places` | `places` |
| `company_exclude_places` | `exclude_places` |
| `technologies`、`verticals`、`vertical_categories`、`vertical_sub_categories`、`categories`、`keywords`、`founded_dates`、`employees`、`revenues` | 原样透传 |
这就是为什么公司级位置在 `filter_conditions[].key` 中要用裸名:
```json theme={null}
{
"company_places": ["New York", "Boston"],
"filter_conditions": [
{ "key": "places", "operator": "and" }
]
}
```
`{ "key": "company_places", "operator": "and" }` 会被静默忽略 — 引擎不识别带前缀的名称。在 `filter_conditions` 中始终引用引擎名。
***
## 幕后的连接
只要添加*任何*公司级筛选器,人员到公司的连接就会从 `LEFT JOIN` 切换为 `INNER JOIN`。即便人员匹配所有人员级筛选,只要其归属公司无法识别,也会被排除。
如果你一加上 `company_locations` 或 `technologies` 结果就掉到零,请检查你的数据集中是否真的存在该批人员对应的公司。引擎在此宁可正确也不召回 — 它绝不会为了满足筛选而臆造公司。
响应中也能看到这一连接行为:一旦应用了任何公司筛选器,每条返回的人员都会带有完整的 `company` 对象。
***
## 常见模式
用固定的公司列表(`companies` 或 `domains`)做目标,再叠加人员级筛选,在每家公司里找到合适的购买者。
```json theme={null}
{
"people_titles": ["VP Marketing", "CMO"],
"management_levels": ["vp", "c_suite"],
"company_filters": {
"companies": ["67c4696b-…", "f1e2d3c4-…", "0a9b8c7d-…"]
}
}
```
描述公司的形态,而不是具体账户。用区间和垂直 — 引擎会返回符合的人员。
```json theme={null}
{
"people_titles": ["Head of Engineering"],
"company_filters": {
"verticals": [12, 47],
"company_locations": ["US", "CA"],
"founded_dates": [2015, 2023],
"employees": [[51, 200], [201, 500]],
"filter_conditions": [
{ "key": "verticals", "operator": "and" }
]
}
}
```
在使用特定技术栈的公司中找到购买者。`technologies` 上的 AND 是典型覆盖。
```json theme={null}
{
"people_titles": ["RevOps", "Sales Operations"],
"departments": ["master_sales"],
"company_filters": {
"technologies": [114, 287, 452],
"filter_conditions": [
{ "key": "technologies", "operator": "and" }
]
}
}
```
找到使用竞品产品(某项技术)但未使用你产品(通过 `categories` 排除或独立筛选轮次)的公司中的决策者。
```json theme={null}
{
"people_titles": ["VP Sales"],
"management_levels": ["vp"],
"company_filters": {
"technologies": [287]
}
}
```
再用 `technologies: [114]`(你的产品的 tag ID)重跑,在客户端做差集。
***
## 后续步骤
完整参考 — 每个键、每个默认值,可复制的 AND/OR 配方。
统一筛选引擎背后的心智模型。
`/people/search` 的完整请求/响应结构。
`/companies/search` 的完整请求/响应结构。