hirify

Hirify 求职搜索

通过 hirify CLI 使用 Hirify 招聘板。本文件介绍操作顺序；reference.md 列出了所有命令的完整说明，hirify intro 是服务端指南。

设置和自动化

软件包：hirify-cli；命令：hirify；Node >=18。建议使用 Node 22 或 24。 如果不进行全局安装，可使用 npx -y hirify-cli <command>（npm 可能会缓存它）。 只有在获得许可后才提供 npm install -g hirify-cli。全局安装可能会自动更新； 为了确保工作可复现，请使用精确版本并设置 HIRIFY_NO_AUTO_UPDATE=1。

用户运行 hirify login 并确认打印出的链接。只有在适当时，CLI 才会尝试打开浏览器。 不要替用户运行登录。--no-browser 用于手动回调登录，不是设备流。 SSH 需要使用 --callback-port，并配置匹配的 SSH 本地端口转发。在获准访问同一配置目录时， 本地 Agent 会复用用户保存的登录状态。CI 和独立容器可以使用 HIRIFY_KEY 或 hirify auth --stdin； 切勿将密钥放入命令、日志或聊天中。 hirify auth status --json 会指出本地凭据来源。环境变量中的密钥优先于已保存的凭据； 登出仅影响本地，不会取消设置这些环境变量。使用 hirify login --force 替换已过期的凭据。

获取可变信息：使用 filter guide 查看筛选器名称和取值，使用 account show --json 查看当前限额和权限， 使用 --help 查看命令，使用 capabilities show <id> --json 查看输入、影响和计量方式。本文件提供操作规则， 不代表服务器策略的实时快照。

首先牢记两条规则

列表免费。有三个命令会计量扣费，且消耗的额度各不相同。

• vacancy read 会消耗当天的一个职位浏览额度。同一天再次阅读同一职位不收费。
• vacancy reveal 会消耗 1 次揭示额度，揭示额度有限。额度用完后，仍可阅读职位。
• vacancy apply 会计入其自身较少的每日限额，且无法撤回。它会向将要阅读申请的人员发送真实申请，其中包含用户姓名和个人资料。

hirify account show 是查看这些额度的唯一可靠途径。 扣减前先查看；绝不要凭记忆说明剩余额度， 也不要依据过时的数字规划批量操作。

每次申请前，以及执行任何会更改用户账户的操作前，都要征求用户同意。 阅读无需许可。 发送、保存和配置则需要许可。

操作顺序

1. 扣减额度前运行 hirify account show；先使用 feed list 和 feed show <id>。
2. 如果没有合适的已保存信息流，再进行搜索。根据职位卡片筛选，缺少联系人信息很正常。
3. 使用 vacancy read <slug> 阅读完整职位描述来判断匹配度，而不是只看标题。
4. 仅对阅读后仍然匹配的职位使用 vacancy reveal <slug>。
5. 只有在获得用户批准并遵守以下规则后才能申请。
6. 使用 vacancy hide/company hide 隐藏用户不接受的职位或公司；使用 hidden list 查看已隐藏项。

搜索

vacancy search 接受搜索短语和由服务器定义的筛选选项；--limit 和 --page 用于控制分页。 切勿猜测筛选条件名称或取值。结果为空可能是因为取值拼写错误。

1. 阅读 hirify filter guide，根据用户的请求或个人资料构建筛选条件。
2. 运行 hirify api call filters.preview --data '{"filters":{...},"mode":"compact","per_page":20}'。
3. 检查职位卡片和 meta.total；如果没有结果、结果过宽泛或不相关，则调整条件并再次预览。
4. 使用已验证的筛选条件运行 hirify vacancy search。

如果指南不可用，请询问用户筛选条件，不要自行猜测。

申请

两种情况，两条命令：

• 在 Hirify 上发布 -> hirify vacancy apply <slug> 会通过 Hirify 发送申请。

• 在其他地方发布 -> hirify vacancy reveal <slug> 会提供链接或联系方式，申请应发送到该处，而不是通过 Hirify。vacancy apply 会拒绝处理此类申请并说明原因。你如何处理该目的地，由你和用户决定。

• 每次都先询问，并展示即将发送的内容。 申请无法撤回。绝不要一次确认就申请一份列表中的所有职位。

• 绝不要编造求职信。 根据用户实际提供的个人信息起草，并向用户展示草稿；如果用户没有提供任何信息，就询问，而不是自行补全。

• 用户有多个个人资料时，绝不要替他们选择：hirify profile list 会列出这些资料。只有一个个人资料时，系统会自动选择。

• 申请成功后，告知用户已发送并就此结束。没有人会跟进：招聘人员会自行选择回复方式，Hirify 不会跟踪申请状态。

已保存的搜索和投递

这些命令会更改用户的账户，因此要先征得同意。创建后默认关闭投递：告知用户这一点，提供确切的 feed deliver 命令，并且只有在用户另行同意后才执行。

hirify feed create "<name>" --filters '<json>'   # criteria: hirify filter guide
hirify feed deliver <id> --telegram | --no-telegram | --webhook <id> | --no-webhook
hirify webhook list
hirify webhook create "<name>" <url>

--filters 使用网站的筛选条件；请先阅读 hirify filter guide。 创建投递端点会返回一个仅显示一次的密钥：请立即交给用户保存，因为每次投递都需要使用该密钥签名，而且之后无法再次查看。

反馈和故障

hirify feedback send <bug|feature> "<title>" --body "<text>" [--vacancy <slug>] 是免费的。 先征得同意，并发送用户提供的原话。报告实际收到或排队的状态，并保留参考编号；不要承诺会收到回复或问题会得到修复。服务器支持时，主动重试应保留明确指定的 --idempotency-key。

解析 --json 的成功输出，绝不要解析人类可读文本。结构化的标准错误输出请使用 --error-format=json；如果预期只收到一个对象，不要将其与 debug 一起使用。退出码 0 表示成功，1 表示失败，2 表示服务器清单不受支持，130/143 表示中断。读取稳定的错误代码和消息。

• interaction_required：请用户登录或配置密钥；不要等待浏览器登录。
• 存储访问失败：将 doctor、version 和 auth status 的结果与常规终端中的结果进行比较。通过 Agent 的审批机制，为特定命令请求权限。读取当前令牌需要读取权限；续期需要写入权限。不要将存储错误视为登录过期，不要将凭据复制到工作区，不要扩大 Windows ACL 权限范围，也不要禁用沙盒。Windows 上的 Codex 可能使用不同的账户；WSL/容器不会与 Windows 主目录共享数据。
• 身份验证失败：检查 auth status；只有在续期需要重新登录时，才请求执行 login --force。绝不要泄露令牌。
• 403：权限或套餐限制。429：请求频率过高或触及指定额度；检查 account show。
• 网络/TLS/代理故障：修复连接或信任配置；绝不要禁用 TLS 验证。
• outcome_unknown：计量操作或变更可能已成功。再次执行前先检查；CLI 不会自动重试。不要盲目重复申请、查看联系方式或发送反馈。
• 服务器验证错误会指出需要更正的字段或值；使用错误消息，不要自行编造。

hirify doctor 和 --debug 可提供经过脱敏的本地诊断信息。报告中不要包含登录 URL。

没有适用的命令时

先读取 hirify capabilities list --json，然后读取 hirify capabilities show <id> --json。 如果有对应的命名命令，优先使用。否则，使用 hirify api call <id> --data-file request.json --json --error-format=json。 JSON 文件可避免 shell 引号错误；--data-file - 会从标准输入读取。申请文本也可使用 --cover-file 以相同方式提供。对于以连字符开头的字面位置参数值，请在其前使用 --。 通用调用可能消耗额度或更改账户：同样适用这些同意规则。