---
name: recruit-grill
description: >
  逐岗梳理真实岗位需求：先读已有资料，把可独立回答的问题成批提出，给出建议供用户确认，形成可执行的初筛标准，
  产出对外 JD、对内寻源笔记（目标公司/命脉技能/排除信号/搜索词）、CONTEXT.md 硬规则与术语表更新。
  当用户说"新开一个岗位"、"梳理 XX 岗的要求"、"帮我写 JD"，或寻源数据显示现有标准跑偏需要重梳理时使用。
---

# recruit-grill —— 逐岗梳理真实岗位需求

把用人需求从「我要一个厉害的 XX」梳理成**可执行的初筛标准**。一次只梳理一个岗位，用尽量少的往返把关键取舍定清楚。

网页开工（默认）：确认用户招聘工作区后，按 [`../recruit-board/references/hosts.md`](../recruit-board/references/hosts.md) 统一接入；脚本可用时为 `grill` 先 start、保存 run id 并进入真实步骤，尽早确认服务并打开或复用网页，同时交付本轮链接。步骤、降级和记录命令遵循 [`共享进度协议`](../recruit-board/references/progress.md)；访谈等待用户回答时在 interview 记 `wait`，恢复后记 `step`，不把未确认标准当作已完成。

按 [`跨轮事项与重点`](../recruit-board/references/decisions.md) 读取该岗位既有未决问题，复用稳定事项，避免下一轮重新提同一个决定。需要跨轮保留的标准选择登记为岗位事项，不伪造候选人收据；用户答复后记录决定，实际更新 CONTEXT／JD／对内笔记后再记资料同步完成。有价值的已确认结论及时记 `highlight`；新事项与重点用 `context.scope:role` 和已核实的 `role` 明确岗位，`details` 按需保留最多 8 项核实短文本，不将未确认建议写成既成变化；旧格式仍可读。结束 run 前写 `summary`；未确认的标准不能作为事实生效。

## 怎么问

1. **先读再问**。读工作区 `CONTEXT.md`、本岗已有 JD／对内笔记和用户提供的材料。已确认且无冲突的结论直接沿用，只用几行交代已知信息和缺口；旧 JD 与 CONTEXT 冲突时指出差异，沿用现行 CONTEXT，询问是否变更。能查到的事实自己查，不把整理工作交回用户。
2. **按依赖分轮，同轮批量问**。每轮把前提已确定、可独立回答的关键问题一起编号提出，问完等用户回答。岗位目标没定时，先与地点、预算等独立问题同批问；依赖目标的命脉、验证信号等留到目标确定后。只剩一个缺口就问一个，不凑题数；也不把后续追问塞成一张长问卷。
3. **给建议，方便拍板**。每题写清一个取舍、推荐答案和一句依据；让“同意”就能接受建议，用户也可按编号修改。预算、汇报对象等事实没有依据时直接索取，不编答案。用户只答部分，就接受已答内容，只补影响下一步的缺口；“不知道／先跳过”记待定，不反复逼问，未答不能当同意。
4. **只追影响筛人的模糊点**。把“资深／能力强／懂 AI”转成可观察的能力与证据，分清硬要求和加分项。公司通用门槛已有就复用；没有依据的年龄、学历、年限限制不自行补成硬规则。目标公司、搜索词和渠道先由 AI 根据已确认要求拟定，标为待寻源验证的假设，只问用户有无已知禁区或特殊偏好。
5. **够用就收口**。按下方判据检查缺口，不逐题走完题库，也不每轮重述整份画像。用户要求少问或先出稿时，立即用已知内容出草稿，集中标出待定项；关键标准仍缺时保留“待梳理”，不宣布可用于正式初筛。

提问用简短编号，例如：

> **Q1｜行业经验需要卡死吗？** 建议不卡行业，要求能用具体项目证明已确认的命脉能力；行业经验作加分项。
>
> **Q2｜需要提交案例吗？** 建议提供一份去敏后的项目案例，便于核验实际贡献。
>
> 可按编号回答；同意建议可直接说“都同意”，也可只写要改的项，其余明确说“同意”或“待定”。

需要补问时查 [`问题参考`](references/question-bank.md)，只选与当前缺口有关的题。

## 什么时候问完

能说明岗位要解决的问题与核心交付物，明确适用的硬门槛、可放宽项、命脉及验证方式、排除信号（可明确无额外项），就汇成一份简短标准供用户整批确认。未改变的既有结论和用户已明确拍板的项不重复审批，只确认新增建议、冲突与未决取舍；全部已确认时直接落盘。

非阻塞的目标公司、搜索词、渠道假设不拖住收口，写进对内笔记待首轮验证。未决标准记入 CONTEXT「待定决策清单」，不能混入生效硬规则；术语确认含义后再更新「术语表」。

## 产出（AI 整理，每岗四件）

标准已确认且四件产物落盘，才算梳理完成；只出草稿时明确尚缺什么，不把岗位改成“在招”。

1. **对外 JD** `01-jd/<role>.md`（可以直接发给候选人/挂平台的版本）。结构：

   ```
   # 岗位名
   > 背景一句话（为什么招）
   ## 一、招聘 spec（设计依据，内部对齐用，发布时可裁掉）
   | 维度 | 结论 |  ← 定位/核心存在意义/汇报线/学历年限/地点/薪资带宽
   ## 二、岗位详情
   | 汇报对象 | 工作地点 | 薪资 |
   > 💡 关于这个岗位（人话版描述）
   ### 岗位职责
   ### 任职要求（硬性）
   ### 加分项
   > 📌 作品集/代码/案例要求（如适用）
   ```

   ⚠️ 对外 JD 里**不写**商业敏感信息和寻源策略。

2. **对内笔记** `01-jd/_internal/<role>.md`——套 `_shared/templates/jd-internal.md`：
   硬约束一句话锚定、命脉技能与验证方式、目标公司锚点、参考简历信号、排除信号、空的关键词迭代表。
   写完提醒用户：**这份不外发**。

3. **CONTEXT.md 更新**：
   - 「初筛硬规则」：本次访谈确认的通用硬门槛（年龄线/学历线/地点坐班/错位处理）。已有内容冲突时向用户确认后更新，并在「已对齐决策」记一条带日期的变更。
   - 「在招岗位与优先级」：标准已确认且产物齐备后，本岗状态从"待梳理"改为"在招"，补优先级和文件链接。
   - 「术语表」：本次新沉淀的术语。

4. **初始搜索关键词**：根据已确认标准拟首轮搜索词，写进对内笔记关键词迭代表的 R1 行，注明“待验证”（日期留空，首轮寻源后回填效果）。

## 什么时候重新 grill

- 寻了几轮源发现标准明显不对（全是错的人/池子里根本没这种人）→ 带着台账数据重新走一遍硬门槛和命脉部分；
- 用人经理改需求 → 增量更新，改动记进「已对齐决策」。