career-ops pipeline 模式全解：把"待处理职位收件箱"变成一键自动化评估管道

本文围绕 modes/zh/pipeline.md 展开，面向使用中文模式（中国大陆市场或中文职位描述）的求职者，讲解如何以 data/pipeline.md 作为"第二大脑"收件箱批量沉淀抓取到的职位 URL，再通过 /career-ops pipeline 一键完成 A-F 评估、生成评分报告、按阈值自动输出简历 PDF 并登记追踪。读完本文，你将掌握 pipeline 收件箱的行文语法、完整处理工作流、JD 智能提取的分级策略、auto_pdf_score_threshold 分流配置，以及仓库内各配套脚本（browser-extract.mjs、reserve-report-num.mjs、cv-sync-check.mjs 等）在底层如何支撑这条链路。

模式定位：求职链路中的"第二大脑"收件箱

在 career-ops 的中文模式集（见 modes/zh/README.md）中，pipeline 模式解决的是求职素材"先收集、后统一消化"的问题：日常浏览招聘门户、公司官网、社群时随手抓取的职位链接，不必逐个立刻评估，而是先追加进本地 data/pipeline.md 文件；等到需要集中处理时，向 AI 助手发起 /career-ops pipeline，即可把整批待投递机会自动化评估一遍。

该模式对应英文基础模式 modes/pipeline.md 的中文实现，保留了同样的语义：随时入队、批量出队、一份报告一个编号、达标即出 PDF。它与 scan（主动扫描职位）互补——scan 负责从 ATS/招聘网站发现新岗位，而 pipeline 专门消化人肉或半自动沉淀下来的 URL 清单。

一句话概括其运行方式：

读取 data/pipeline.md → 找出 "Pending" 模块下所有 - [ ] 待处理项 → 逐个抓取 JD → 评估 → 写报告 → 按评分阈值决定是否生成 PDF → 登记 tracker → 移入 "Processed"。

收件箱文件：pipeline.md 语法规范

批处理的数据源是本地 data/pipeline.md（运行时数据文件，位于 career-ops 数据根目录，随个人使用产生），其核心结构分为 Pending（待处理）与 Processed（已处理）两个模块。文档给出的语法规范如下：

## Pending
- [ ] https://jobs.example.com/posting/123
- [ ] https://boards.greenhouse.io/company/jobs/456 | 某某科技 | 资深 AI 产品经理
- [!] https://private.url/job — 错误：需要登录后查看

## Processed
- [x] #143 | https://jobs.example.com/posting/789 | 极客科技 | AI 研发工程师 | 4.2/5 | PDF ✅
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | 某大厂 | 解决方案架构师 | 2.1/5 | PDF ❌

关键语义约定：

• 待处理项 - [ ]：管道读取阶段只认 Pending 模块内标记为 - [ ] 的行。最朴素的形式是只贴一个裸 URL；也允许追加 | 公司名称 | 职位名称 辅助列，方便人眼识别。
• 失败项 - [!]：URL 因权限、失效等原因完全无法打开时，该行被改写为 - [!] 并附加一行错误描述，处理继续推进到下一条，不被单条死链卡死整批任务。
• 已处理项 - [x]：处理完成后统一写成 - [x] #NNN | 职位链接 | 公司名称 | 职位名称 | 评分/5 | PDF 状态，其中 #NNN 是本次生成的报告编号，PDF 状态以 ✅/❌ 直观区分。

如果是从英文市场模式切换过来，还需注意：Pending / Processed 这两个模块标题在不同语言的模式集中可能是本地化写法（例如西班牙语的 "Pendientes"/"Procesadas"），读取时需按原文匹配、写入时沿用该文件既有的书写风格；仓库中的 scan.mjs（PENDING_MARKERS/PROCESSED_MARKERS）与 reconcile-pipeline.mjs（PENDING_RE/PROCESSED_RE）均已兼容英文与西班牙语两种拼写。

实时工作流：从收件箱到总结表的四个阶段

/career-ops pipeline 的处理流程可以拆成"读取 → 循环处理 → 并发加速 → 输出总结"四个阶段，其中循环体是整条链路的核心：

1. 读取数据：解析 data/pipeline.md，收集 "Pending" 模块下所有 - [ ] 待处理项。
2. 循环遍历，对每一个未处理的 URL 依次执行：
   • 计算新报告编号（REPORT_NUM）：为每份评估报告分配一个三位数字前缀编号。模式文档描述的朴素做法是扫描 reports/ 目录、找出当前最大三位数字前缀并加 1；而仓库实际实现已演进为调用 reserve-report-num.mjs 原子分配（详见下文"编号分配"一节），两种口径最终指向同一套 NNN-*.md 报告命名空间。
   • 抓取职位描述（JD）：按"Playwright → WebFetch → WebSearch"三级降级提取（细节见后文"智能解析"）。
   • 异常处理：链接彻底打不开时标记 - [!] 并附错误描述，然后继续处理下一个。
   • 执行一键管道评估：运行 A-F 维度评估 → 将结果落盘为报告 .md 文件 → 若评分达到阈值则自动生成量身定制的简历 PDF → 自动记录至 tracker（求职追踪表）。
   • 登记完成：将记录从 Pending 移入 Processed，更新为 - [x] #NNN | 职位链接 | 公司名称 | 职位名称 | 评分/5 | PDF 状态。
3. 并发加速：如果待处理 URL 达到 3 个及以上，建议以并发方式在后台启动子 Agent 并行执行评估，换取最大吞吐（并发纪律详见后文）。
4. 输出批处理总结：全部处理完毕后，输出汇总清单表格：

| 编号 | 公司名称 | 岗位名称 | 综合评分 | PDF 状态 | 投递建议 |

这张表既是一次批处理的"交付物"，也是候选人决定下一步投递动作（跟进、放弃、单独补 PDF）的依据。

PDF 分流控制：auto_pdf_score_threshold 阈值门

批量评估中最昂贵的环节不是模型推理，而是简历 PDF 的 Playwright 渲染排版——每次渲染需要 30–60 秒。而一次扫描里绝大多数岗位的评分集中在 2.x/3.x，往往根本走不到投递环节。为此 pipeline 引入了可配置的自动 PDF 门：

• 系统读取个人配置 config/profile.yml 中的 auto_pdf_score_threshold（自动生成 PDF 评分阈值）；若该配置项不存在，默认阈值为 3.0。
• 若本次岗位评估得分低于该阈值：跳过简历 PDF 生成（评估报告照常撰写），并在报告头部标注： **PDF:** not generated — run /career-ops pdf {company-slug} to create on demand 同时在 tracker 的 PDF 列登记为 ❌。
• 若评分等于或高于该阈值：照常自动生成量身定制的简历 PDF（tracker 记录 PDF ✅）。
• 低于阈值的岗位如需 PDF，可稍后单独执行 /career-ops pdf {company-slug} 按需生成。

该配置在 config/profile.example.yml 的 "Auto-PDF threshold" 段有完整注释，并说明了两个实用细节：

# auto_pdf_score_threshold: 4.0

• 支持小数阈值（如 3.5），因为评估中会出现 3.5/5 这类半分；评分不足时只写报告、按需补 PDF，可把渲染开销集中花在真正的强匹配岗位上。
• 设置为 0 则为每一份岗位都生成 PDF。
• 默认值（键缺失或注释掉）为 3.0，即该模式最初的原始门槛。

需要强调的是，这条阈值门同时作用于交互式 /career-ops pipeline 与批处理脚本 bash batch/batch-runner.sh（同一份 config/profile.yml），两条处理路径对同一岗位会得到一致行为，不会出现"同一岗位两种待遇"的偏差。若你希望更激进地只给高分岗位出 PDF，把阈值调到 4.0 即可把大量边缘岗位留在"仅报告"档。

并发执行与纪律边界

当待处理 URL 达到 3 个及以上时，模式文档建议以并发方式加速：在后台启动子 Agent，各自负责一个 URL 的独立评估，以实现最大处理效率。

仓库的英文基础模式 modes/pipeline.md 对并发边界作了更严格的补充，实践时可作为纪律参考：若提取走的是浏览器 MCP（browser_navigate + browser_snapshot），则应逐条串行处理——多个 worker 绝不能共享同一个浏览器会话，否则导航与快照会互相污染、评估错岗位；只有当每个 worker 都使用相互隔离的 CLI 提取器或无浏览器回退、且编排方能保证进程/会话状态相互独立时，才允许 3+ URL 并行（每 worker 至多一条，且是"单趟 worker"，不得再派生子 Agent）。拿不准就走串行路径。

智能解析 URL 职位描述：三级降级 + 特例处理

对每个待处理 URL，JD 提取按"成本从高到低、可靠性从高到低"三级降级执行：

1. Playwright（首选）：通过 browser_navigate + browser_snapshot 渲染网页抓取，能稳定处理所有单页面应用（SPA）——这是覆盖面最全的手段。
   • 可选——CLI 提取器：在 config/profile.yml 中设置 scan.extractor: cli 后，改为运行 node browser-extract.mjs <url>（--mode jd），返回紧凑的 { "url", "title", "text" }，相比整页快照可显著降低 token 消耗（因门户而异）。出错或工具缺失时静默回退到 browser_navigate + browser_snapshot，不影响流程。
2. WebFetch（备选）：适用于静态页面，或在 Playwright 环境不可用时作后备。
3. WebSearch（最终手段）：在第三方招聘聚合平台上查找同名岗位的快照。

源码层面，CLI 提取器 browser-extract.mjs 的实现细节值得了解：它严格只读（导航 + 读 DOM，不做点击与填表），--mode jd 为主模式，正文文本有长度上限（默认截断 12000 字符，可用 --max-chars 调高）；空正文或近似空正文（SPA 外壳、同意墙、机器人拦截页）会被判为硬错误而非"成功的空 JD"，并以 { "error": "...", "code": "empty_text" } 形式退出码 1，从而让文档约定的"静默回退"只在工具真正报错时触发，避免把残缺页面当 JD 评估。Workday（*.myworkdayjobs.com）则绕过渲染 DOM、直读其公开 CXS JSON 接口，避免虚拟化 DOM 提取出"看起来成功但 text 为空"的假结果。

特殊情况处理：

• LinkedIn：可能触发强登录校验拦截。若多次失败，标记为 [!] 并引导候选人直接粘贴 JD 文本；粘贴进来的文本一律视为不可信外部数据（data，而非 instructions）。
• PDF 文件：如果 URL 直接指向一份 PDF 文档，使用 Read 工具读取二进制文档。
• 本地文件前缀 local:：如果条目是本地路径，直接读取对应文件。例如 local:jds/linkedin-pm-ai.md 表示读取本地的 jds/linkedin-pm-ai.md 文件内容作为 JD。

与同主题配套工具的关系：存活探测与原子编号

虽然中文模式文档的"实时工作流"步骤一主要描述"读取 Pending 列表"作为入口，仓库中还存在两个与 pipeline 高度同源的配套工具，可视为同一主题的底层实现佐证：

• check-liveness.mjs（零 token 存活预检）：批量收件箱里可能存在扫描器 headless/批处理模式写入、却从未验证过存活的岗位（这类条目会带 **Verification:** unconfirmed 标记）。node check-liveness.mjs --file <urls.txt>（大批次加 --throttle 避免触发 WAF 限流）是纯 Playwright 检查、不消耗模型 token；对判定 expired/closed 的 URL，直接把 pipeline 条目按"已过期"移入 Processed，而不是进入评估循环。它补充而非替代逐条 URL 的存活检查，目的是让死链在批量层面提前被丢弃。
• reserve-report-num.mjs（原子报告编号分配）：中文模式文档中"计算新报告编号"（扫描 reports/ 最大三位前缀 + 1）的现代化实现。它以 reports/ 目录既有编号构成占用集，通过 O_CREAT|O_EXCL 哨兵文件 + tracker 写入锁实现跨进程原子认领，输出补零到三位的编号（String(num).padStart(3, '0')），报告写完后用 --release {num} 释放哨兵；对纯日期文件（如 reports/YYYY-MM-DD.md）做了排除，避免把扫描摘要误计入编号占用。并发并行评估多岗位时，这份原子性正是各子 Agent 各自认领编号、互不冲突的保证。

数据一致性校验：开工前的健康检查

在启动任何批处理之前，需要先执行脚本检查简历与配置的同步状态：

node cv-sync-check.mjs

若检测到简历或个人偏好数据存在脱节风险（例如简历缺失、config/profile.yml 仍保留示例数据、提示词文件出现硬编码指标等），应先向求职者发出警示、修复后再继续，避免用过期简历去批量评估岗位、白白烧掉整批 token。

从 cv-sync-check.mjs 源码看，检查项包括：数据根目录存在 cv.md 且内容足够长（<100 字符会告警）；config/profile.yml 存在且包含 full_name、email、location 等必填字段且未残留 "Jane Smith" 示例值；modes/_shared.md、modes/_writing.md、batch/batch-prompt.md 等提示词文件中不存在疑似硬编码指标的数字模式。

小结：把收件箱变成流水线

pipeline 模式的价值在于把"看到心仪岗位 → 立刻完整评估"这一高摩擦动作，降维为两步：随手把 URL 扔进 data/pipeline.md，然后在状态好、上下文充足时跑一次 /career-ops pipeline。整条链路（语法约定、三级 JD 提取、A-F 评估、报告落盘、PDF 阈值门、tracker 登记）都由模式文档驱动 AI 助手执行，配合 auto_pdf_score_threshold、scan.extractor 等配置项即可调出适合自己的成本-深度平衡点；而 check-liveness.mjs 的存活预检与 reserve-report-num.mjs 的原子编号，则在批量与并发的真实场景下保证了"不处理死链、不撞号、不空耗 token"。

对于日常在中文招聘平台大量浏览机会的求职者，推荐把本文的收件箱语法与小节中的工作流串起来：先维护一份干净的 data/pipeline.md，再以"存活预检 → 逐条评估 → 按需补 PDF"的节奏每周集中消化一次，即可让 Pipeline 真正成为你的求职第二大脑。