gilgameshcc SKILL · 判断闸门式投递闭环
把本文件与
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/<batch>.md 里岗位实际出现的渠道顺序处理，不额外排序 |
一句话说清"先看哪个渠道"就够 |
| 打招呼语素材（01-resume 输出，或你自己给） | 可选 | 用 templates/打招呼语骨架.md 的通用模板起步，每次 review 卡都会提醒这会增加文本同质化被识别的风险 |
几句能体现身份定位的话 |
pacing.json 的实际取值 |
可选 | 用模板里的 默认建议值 / 纯占位待校准 起步，同样会在 review 卡里持续标注"这是未经你校准的默认值" |
至少把「你能接受的单日上限」这一项换成你自己的数字 |
⛔ 这一段的四条禁止（对 agent）
- 不许在判断闸门缺失时静默用一套默认值直接开始跑——必须显式说明、必须用户知情同意
- 不许把"缺打招呼语素材"当成可以直接编一套人设话术的理由——通用模板起步可以，编造经历不行
- 不许把
pacing.json的占位值当成"已校准、可以放心用"的数字对待——每次用到都要提醒来源等级 - 不许一次只问一个问题挤牙膏——判断闸门缺什么，一次列全
流程
步骤 0 · 并发锁检查
读 apply-lock.json（schema 见 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/<batch>.md 里的候选岗位。每条先过：
- 硬性排除条件（一票否决，见
03-company-analysis/jd-triage的判定顺序）→ 命中即跳过，记原因 - 必要条件——原文证伪则跳过；原文未提及则挂"待确认"，不因为未提及就默认跳过或默认通过
- 定级结果——读
triage/里已有的级别；没有定级结果的条目本轮不处理，标"待定级"
步骤 3 · 去重
按平台的"已联系"状态判断跳过——这类平台特定的判定逻辑属于 adapters/，本文件只定义去重发生在这一步，不定义具体怎么读那个状态。
⛔ 去重优先于一切：宁可漏投一条不确定是否已联系过的，也不重复投递——重复投递对 HR 是骚扰，对平台是异常信号，比漏投严重。
步骤 4 · 定制打招呼语
用 01-resume 的素材（或 templates/打招呼语骨架.md 的通用模板，见「开跑前」）+ 该条 JD 的具体内容生成。
⛔ 禁止留占位符发送。 具体观察句必须引用这条 JD 的真实内容，不许出现"我注意到贵司在 [填写具体业务]"这类没有替换的模板残留。
步骤 5 · 发送前文本比对
发送前把即将提交的文本和生成的文本逐字比对一遍——输入框随机丢字是已知的平台交互缺陷，不比对会带着丢字的文本发出去。
⛔ 核实本身不构成放慢节奏或提前收尾的理由——这是正常步骤的成本，不是可以跳过换速度的地方。
步骤 6 · 发送后核对一次
确认发送成功即可，不重复截图同一件事。失败不重试第二次——见 GOVERNANCE.md §3 执行边界三问。
步骤 7 · 立即登记台账
每发一条立即登记 ledger.md，不批量补登。记渠道 / 用的哪一版材料 / 定级级别——这三栏事后补不回来（同 00-workspace 台账纪律）。这几栏在 ledger.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 的字段生成 runs/<date>-review.md。这是"每天只 review 一次就够"能成立的唯一原因——它把本轮全部判断压成可审计的一页，不是让人翻日志。
低产归因是硬性字段：实际发出数明显低于轮目标，且不是因为熔断/候选池枯竭/会话上限时，必须写明真实原因，不许含糊带过（比如"今天大部分岗位卡在待确认"就是一个合格的归因，"投得少一些"不是）。
⭐ 长周期批量任务的收尾判断：必须走独立核验
如果本轮扫描目标是"扫完某几个渠道 × 某几个关键词的全部组合"这类可枚举、有明确覆盖范围的任务（不是简单的"今天投够 N 条就收工"），执行 agent 不能自己判断"够了、可以收尾了"。
具体做法见 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/<platform>/，让下次直接回到 L1。没沉淀 = 下次还得再试一遍 = 等于没走通
L3 · 实在不行，才回报人
- 触发条件：L2 也走不通 / 命中风控与同意类信号（验证码、异地登录提醒、异常操作提示）/ 需要只有用户本人才能决定的事（是否接受一套临时判断闸门、要不要为某个探路方向放宽阈值）
- 回报必须含：症状 + 已经试过什么 + 建议你做什么
- ⛔ 命中风控信号时，回报是唯一动作——不重试、不换方式绕过、不用"再试最后一次"这种理由继续。这条优先级高于本轮任何数量目标
变更日志
v0.1.0（首发）
- 确立 fail closed：判断闸门缺失时拒绝运行，是本模块与效率派投递工具的分界线
- 判断闸门式投递闭环九步流程：并发锁 → 现读台账 → 渠道执行+硬门槛 → 去重 → 定制 → 发送前比对 → 发送后核对 → 登记 → 收尾解锁 → 生成 review 卡
- ⭐ 新增「长周期批量任务的收尾判断必须走独立核验」——架构设计文档 §6.5 在 SKILL 正文的落点，具体机制见
GOVERNANCE.md§6 - 三段式区块（开跑前 / 来源标注 / 不对劲的时候）+ 三级自救阶梯，L2 写动作在定位不可靠时"跳过继续"而非"停下等人"