# 02 Apply > SKILL · 判断闸门式投递闭环 - Skill: `gilgameshcc/02-apply` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add gilgameshcc/02-apply` - Raw SKILL.md: https://api.skillmd.com/api/skills/gilgameshcc/02-apply/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: gilgameshcc (https://skillmd.com/u/gilgameshcc) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/gilgameshcc/02-apply --- # SKILL · 判断闸门式投递闭环 > **把本文件与 [`GOVERNANCE.md`](GOVERNANCE.md) 一起整份交给你的 agent。** 本文件是"怎么跑"，`GOVERNANCE.md` 是"什么时候不该跑/该停"——两份缺一不可，本文件多处直接引用 `GOVERNANCE.md` 的判据，不重复定义。 **这份 skill 干什么**：把已经校准好的判断规则（硬门槛、排除条件、匹配度定级），套进一个可以定时触发、无人值守跑一轮的投递闭环，同时保证它不会退化成无差别大量投递。 **跑完你会拿到**：一批已投递/已跳过的岗位记录 + 一张每日 review 卡（你只需要花几分钟看这一张卡，不用翻日志）。 --- ## ⛔ 第一条规则：fail closed **本模块在没有判断闸门的情况下，拒绝运行。** 「判断闸门」= 至少要有：`positioning.md` 里的硬性排除条件（≥1 条）+ 必要条件（≥1 条）+ 一份定级结果（`triage/` 下至少一批）。三者缺一，本模块的开工响应是： > "我现在没有可以执行的判断闸门——缺〔具体缺哪几项〕。我不会在没有判断的情况下开始投递，那等于把这个模块变成一个无差别投递器，而这正是本模块存在的理由要防止的事。请先补上这几项，或者明确告诉我你愿意接受哪些默认值作为临时闸门（会在每日 review 卡里持续提醒你这是临时状态）。" ⛔ **这不是一条"建议"，是拒绝执行的硬闸门。** 不允许因为用户催促、或者"先跑起来看看效果"这类理由绕过。唯一的例外路径是用户**显式**接受一套临时判断规则并知情同意其风险——即便如此，每一次 review 卡都要重复提醒"当前判断闸门是临时值"，直到被替换成用户自己校准的版本。 --- ## 开跑前 | 要什么 | 必需 / 可选 | 缺了会退化成什么 | ⭐ 最小可接受形态 | |---|---|---|---| | **硬性排除条件（`positioning.md`）** | 必需 | **不运行**（见上「fail closed」） | 至少 1 条能一票否决的条件（薪资底线 / 城市 / 权限红线其中之一） | | **必要条件（`positioning.md`）** | 必需 | 同上 | 至少 1 条 | | **一份定级结果（`triage/`）** | 必需 | 同上 | 哪怕只有几条也行——定级结果的量不影响是否能开工，只影响第一轮能处理多少 | | **渠道优先级** | 可选 | 按 `jobs/.md` 里岗位实际出现的渠道顺序处理，不额外排序 | 一句话说清"先看哪个渠道"就够 | | **打招呼语素材（01-resume 输出，或你自己给）** | 可选 | 用 [`templates/打招呼语骨架.md`](templates/打招呼语骨架.md) 的通用模板起步，**每次 review 卡都会提醒**这会增加文本同质化被识别的风险 | 几句能体现身份定位的话 | | **`pacing.json` 的实际取值** | 可选 | 用模板里的 `默认建议值` / `纯占位待校准` 起步，**同样会在 review 卡里持续标注"这是未经你校准的默认值"** | 至少把「你能接受的单日上限」这一项换成你自己的数字 | ### ⛔ 这一段的四条禁止（对 agent） 1. **不许在判断闸门缺失时静默用一套默认值直接开始跑**——必须显式说明、必须用户知情同意 2. **不许把"缺打招呼语素材"当成可以直接编一套人设话术的理由**——通用模板起步可以，编造经历不行 3. **不许把 `pacing.json` 的占位值当成"已校准、可以放心用"的数字对待**——每次用到都要提醒来源等级 4. **不许一次只问一个问题挤牙膏**——判断闸门缺什么，一次列全 --- ## 流程 ### 步骤 0 · 并发锁检查 读 `apply-lock.json`（schema 见 [`config/lock.schema.json`](config/lock.schema.json)）。 - `status: in_progress` 且 `updated_at` 在合理时间窗内 → **不重复启动**，本轮直接结束，理由写"已有一轮在跑" - `risk_paused: true` → **直接结束，不做任何投递相关操作**，见 `GOVERNANCE.md` §2 熔断 - 否则 → 写 `status: in_progress`，`updated_at` 更新为当前时间，继续 ⭐ **状态判断只信文件，不信会话记忆、不信锁文件里的旧计数。** 定时触发的每一次都是全新会话，"检查任务是否 in_progress"这类依赖会话内状态的判断从未真正生效过——这是本模块继承自个人实践的一条硬纪律，不是理论推测。 ### 步骤 1 · 现读台账，重新数今日真实进度 **不信锁文件里 `confirmed_count` 的旧值，重新读 `ledger.md` 今天的记录数一遍。** 锁文件的计数只是缓存，真相以台账为准——两者不一致时，以台账为准并更新锁文件，而不是反过来。 ### 步骤 2 · 渠道优先级执行 + 硬门槛过滤 按开跑前确认的渠道顺序，逐个渠道读取 `jobs/.md` 里的候选岗位。每条先过： 1. **硬性排除条件**（一票否决，见 `03-company-analysis/jd-triage` 的判定顺序）→ 命中即跳过，记原因 2. **必要条件**——原文证伪则跳过；原文未提及则挂"待确认"，**不因为未提及就默认跳过或默认通过** 3. **定级结果**——读 `triage/` 里已有的级别；没有定级结果的条目本轮不处理，标"待定级" ### 步骤 3 · 去重 按平台的"已联系"状态判断跳过——这类**平台特定**的判定逻辑属于 [`adapters/`](../../adapters/README.md)，本文件只定义去重发生在这一步，不定义具体怎么读那个状态。 ⛔ 去重优先于一切：宁可漏投一条不确定是否已联系过的，也不重复投递——重复投递对 HR 是骚扰，对平台是异常信号，比漏投严重。 ### 步骤 4 · 定制打招呼语 用 01-resume 的素材（或 [`templates/打招呼语骨架.md`](templates/打招呼语骨架.md) 的通用模板，见「开跑前」）+ 该条 JD 的具体内容生成。 ⛔ **禁止留占位符发送。** 具体观察句必须引用这条 JD 的真实内容，不许出现"我注意到贵司在 [填写具体业务]"这类没有替换的模板残留。 ### 步骤 5 · 发送前文本比对 发送前把即将提交的文本和生成的文本逐字比对一遍——输入框随机丢字是已知的平台交互缺陷，不比对会带着丢字的文本发出去。 ⛔ **核实本身不构成放慢节奏或提前收尾的理由**——这是正常步骤的成本，不是可以跳过换速度的地方。 ### 步骤 6 · 发送后核对一次 确认发送成功即可，不重复截图同一件事。**失败不重试第二次**——见 `GOVERNANCE.md` §3 执行边界三问。 ### 步骤 7 · 立即登记台账 每发一条立即登记 `ledger.md`，不批量补登。记渠道 / 用的哪一版材料 / 定级级别——这三栏事后补不回来（同 `00-workspace` 台账纪律）。这几栏在 `ledger.md` 基础字段之外的补充说明，见 [`templates/台账渠道字段补充.md`](templates/台账渠道字段补充.md)。 ### 步骤 8 · 收尾解锁 **不是"轮到收尾"就可以直接停。** 收尾之前必须先过 `GOVERNANCE.md` §1「提前结束白名单」——只有命中四种情况之一才能收尾，命中哪一种要写进 review 卡。**如果本轮属于"长周期批量任务"的收尾判断（见下方⭐），必须先走完 `GOVERNANCE.md` §6 的独立核验，不能自己裁决。** 解锁：`apply-lock.json` 写回 `status: completed`，`updated_at` 更新，`confirmed_count` 写本轮台账重新数出来的真实值。 ### 步骤 9 · 生成每日 review 卡 按 [`templates/每日review卡.md`](templates/每日review卡.md) 的字段生成 `runs/-review.md`。**这是"每天只 review 一次就够"能成立的唯一原因**——它把本轮全部判断压成可审计的一页，不是让人翻日志。 **低产归因是硬性字段**：实际发出数明显低于轮目标，且不是因为熔断/候选池枯竭/会话上限时，**必须写明真实原因，不许含糊带过**（比如"今天大部分岗位卡在待确认"就是一个合格的归因，"投得少一些"不是）。 --- ## ⭐ 长周期批量任务的收尾判断：必须走独立核验 **如果本轮扫描目标是"扫完某几个渠道 × 某几个关键词的全部组合"这类可枚举、有明确覆盖范围的任务**（不是简单的"今天投够 N 条就收工"），**执行 agent 不能自己判断"够了、可以收尾了"。** 具体做法见 [`GOVERNANCE.md` §6](GOVERNANCE.md#6-长周期批量任务的收尾结构化覆盖清单--独立核验)：维护一份结构化覆盖清单文件，收尾前调用一个**独立的、看不到本轮对话历史的子 agent**，只读覆盖清单和台账文件本身，给出"满足/不满足停止条件"的布尔判断——**执行者不能因为"自己觉得已经扫得差不多了、命中率变低了、跑得有点久了"而推翻这个独立判断**。 为什么这条必须写进 SKILL 正文而不只是 GOVERNANCE 的一节：**这正是本模块和"随口喊停的海投脚本"之间最容易被忽视的一条分界线**——判断闸门管的是"该不该投这一条"，独立核验管的是"这一轮该不该算完"，两者都缺一不可，缺了后者，一个判断力很强的 agent 依然可能在长会话里因为疲劳类模式（工作量大/命中率下降/会话变长）而提前收尾，产出一份看起来完整、实际漏了一大块候选池的结果。 --- ## 来源标注 同仓库统一三档（`你给的` / `公开可查` / `我推测的`），本模块额外补一条： **每日 review 卡里所有涉及"是否已跑完/是否满足收尾条件"的判断，必须标注是执行者自己判断的还是独立核验判断的。** 前者标 `执行者自评`，后者标 `独立核验`——两者不能互相替代，混用视为违反 §6。 --- ## 不对劲的时候 | 症状 | 最可能的原因 | 你下一句该说什么 | |---|---|---| | **投递数量很多但回应率异常低** | 判断闸门被绕过了，或打招呼语用的是通用模板未定制 | "把最近 20 条的判断依据和打招呼语原文列出来，我要看是不是有占位符没替换、或者硬门槛形同虚设" | | **agent 每次都说"候选池枯竭"但你手动搜还有很多** | 提前收尾——可能没走独立核验就自己判断收尾了 | "把这轮的结构化覆盖清单给我看，哪几个渠道×关键词组合标了`done`，哪几个是`not_started`；如果没有独立核验记录，重新走一遍再给我结果" | | **熔断触发后过了一会儿又开始投了** | 熔断解除逻辑被绕过，或者判断成了不同类型的"暂停" | "查 `apply-lock.json` 的 `risk_paused` 字段和解除时间戳，熔断解除必须是显式的人工动作，不能是等一等自动恢复" | | **每日 review 卡里"低产归因"栏是空的或者写得很含糊** | agent 把它当成可选字段跳过了 | "低产归因是硬性字段，不是可选项——回去把今天投得少的真实原因写清楚，不接受'投得少一些'这类不构成归因的话" | | **打招呼语里出现了没替换的占位符文字** | 步骤 4/5 的检查没有真正执行 | "停止发送，把发送前文本比对这一步重新做一遍，凡是含 `[` `]` 这类占位符标记的一律不许发出去" | --- ## 三级自救阶梯 ### L1 · 有现成的，直接走 判断闸门齐全、渠道 recipe 命中、节奏参数已由用户校准——按流程执行，不问。已有规则能裁决的业务判断（这条要不要跳过、这条打招呼语够不够定制），自己裁决。 ### L2 · 没现成的，自己走通并沉淀 - **recipe 失效/页面结构变了**：备选候选链 → 一次有界结构探查 → a11y 语义模式。⛔ **写动作（点提交）在定位不可靠时，跳过这一条继续下一条，不是停下等人**——记进 review 卡"要你决策"栏，不中断整轮 - **走通后必须把新的语义线索写回 `adapters//`**，让下次直接回到 L1。没沉淀 = 下次还得再试一遍 = 等于没走通 ### L3 · 实在不行，才回报人 - **触发条件**：L2 也走不通 / 命中风控与同意类信号（验证码、异地登录提醒、异常操作提示）/ 需要只有用户本人才能决定的事（是否接受一套临时判断闸门、要不要为某个探路方向放宽阈值） - **回报必须含**：症状 + 已经试过什么 + 建议你做什么 - ⛔ **命中风控信号时，回报是唯一动作**——不重试、不换方式绕过、不用"再试最后一次"这种理由继续。这条优先级高于本轮任何数量目标 --- ## 变更日志 ### v0.1.0（首发） - 确立 fail closed：判断闸门缺失时拒绝运行，是本模块与效率派投递工具的分界线 - 判断闸门式投递闭环九步流程：并发锁 → 现读台账 → 渠道执行+硬门槛 → 去重 → 定制 → 发送前比对 → 发送后核对 → 登记 → 收尾解锁 → 生成 review 卡 - ⭐ 新增「长周期批量任务的收尾判断必须走独立核验」——架构设计文档 §6.5 在 SKILL 正文的落点，具体机制见 `GOVERNANCE.md` §6 - 三段式区块（开跑前 / 来源标注 / 不对劲的时候）+ 三级自救阶梯，L2 写动作在定位不可靠时"跳过继续"而非"停下等人"