在 Claude Cowork 桌面端运行 career-ops：免终端的 AI 求职管线实战指南

career-ops 本质上是为 AI 编码 CLI（Claude Code、Codex、OpenCode 等）设计的一套"可运行在任意 Agent 工作区中的求职工作流"。本文讲解如何在不改动任何系统文件的前提下，把它完整搬进 Anthropic 的桌面协作界面 Claude Cowork——用自然语言指令驱动职位评估、门户扫描与 tracker 登记，全程无需手敲终端命令。读完你将掌握 Cowork 场景下的目录挂载原理、依赖预装要点、启动检查的正确打开方式，以及哪些环节必须回到本机 shell 执行。

为什么 Cowork 是"更友好的那扇门"

career-ops 的官方定位是 AI-powered、CLI-agnostic 的求职自动化系统：求职门户扫描、职位评估、CV 定制、申请跟踪都在本地进行。它对宿主环境的要求很低——只需满足 AGENTS.md 中定义的约定：Agent 读取根目录的指令文件，按需执行 *.mjs 脚本，并尊重 modes/*.md 中定义的各环节提示词。因此，凡是能"读取工作目录文件并调用本地 shell"的 Agent 界面都可以作为宿主。

Claude Cowork 正是这样的界面：它把 career-ops 文件夹挂载进自己的协作会话，让用户在图形化桌面端"看得到每次文件变更"，却不需要面对命令行。根据 docs/COWORK.md 的说明，这一方案是第一方验证过的（2026 年 7 月）：完整的闭环——从一份 PDF CV 的 onboarding、门户配置、对一个真实 Greenhouse 职位的完整 A–G 评估，再到通过 merge-tracker.mjs 完成规范 tracker 登记——全部在 Cowork 内部端到端跑通。附加收益是：Cowork 会把 onboarding 步骤渲染为原生可点击选项与进度清单，交互体验比纯文本终端友好得多。

工作原理：没有斜杠命令，只有对话

career-ops 之所以能在 Cowork 中"零改动运行"，核心原因是它的宿主抽象层设计：

• 指令文件同一套：CLI 场景读取 CLAUDE.md → AGENTS.md → modes/，Cowork 场景读取的完全相同。仓库中 CLAUDE.md 整个文件只有一行 @AGENTS.md 引用，所有真正约定都收敛在 AGENTS.md 一处；CODEX.md、OPENCODE.md、KIMI.md 等则是同一套规则在不同 CLI 下的入口桩。
• 没有斜杠命令（no slash commands）：你不需要记忆 /scan、/evaluate 之类的命令。直接说"evaluate this job posting"、"scan my portals"、"update my tracker"，Claude 会根据自然语言自行路由到 modes/ 下对应的模式文件执行。
• 文件变更全程可见：每次写入（报告、CV、tracker 行）都会实时出现在 Cowork 侧边栏。这正好强化了系统最核心的纪律——任何内容发出之前，你都要先亲自过目（human-in-the-loop）。README 中同样强调 career-ops 从不替你提交申请，永远由你拍板。

从源码结构看，这套"按模式分发任务"的约定在 docs/ARCHITECTURE.md 中有完整对应：单个职位走 auto-pipeline（评估 → 报告 → PDF → tracker），门户扫描走 pipeline/URL inbox，批量则交给 batch-runner.sh 的多 worker。Cowork 只是换了一个触发这些流程的"人机界面"，数据契约与落盘位置不变。

快速上手：五步在 Cowork 里跑通第一轮

第 1 步（唯一一次终端操作）：克隆并预装依赖

必须在打开文件夹之前完成。 Cowork 的本地 shell 没有 npm 网络访问能力，装依赖要趁早：

git clone <career-ops-仓库地址> ~/career-ops
cd ~/career-ops && npm install

这一步是后续所有验证流程的基础：无论是 doctor.mjs 的启动检查，还是 merge-tracker.mjs、verify-pipeline.mjs 等脚本，都依赖 node_modules 中安装好的依赖（如 js-yaml、dotenv）。

第 2 步：安装 Cowork 并挂载目录

安装 Claude Cowork 后，在 Colaborar / Collaborate（协作） 模式下，把 ~/career-ops 文件夹添加为工作目录。

第 3 步：用"锚定句式"触发 onboarding

Cowork 自带的通用初始化流程可能截胡"set me up"这类模糊请求，所以要说得足够明确、把执行路径锁死：

"This folder contains career-ops. Read AGENTS.md, run its startup check (node doctor.mjs --json) and walk me through career-ops onboarding based on its output."

这句话做了三件事：要求先读 AGENTS.md（让 Agent 加载数据契约与模式体系）、强制执行启动自检、并让 Agent 以检查结果为依据引导 onboarding，而不是套用 Cowork 的通用引导。

关于 doctor.mjs --json 的更多细节：从 doctor.mjs 的源码看，它是 career-ops 的"设置体检"入口，--json 输出机器可读的 onboarding 状态。脚本还支持一系列实用 flag：

Flag	作用
node doctor.mjs	运行完整设置诊断，打印 pass/fail 检查清单
node doctor.mjs --json	输出机器可读的 onboarding 状态（Cowork 引导推荐用这个）
node doctor.mjs --strict	额外对 portals.yml 中的每个入口做在线可达性探测（联网、可选）
node doctor.mjs --target <path>	诊断另一个 career-ops checkout
node doctor.mjs --cli <name>	单独检查某个 CLI 的集成（claude、codex、opencode、antigravity、grok、qwen、kimi、copilot、gemini）
node doctor.mjs --help	显示用法

默认不带 --strict 的诊断全程离线、速度很快，适合作为每次会话的开场自检。另外值得留意的是 modes/_shared.md 中规定的 Data Root 解析顺序（环境变量 CAREER_OPS_ROOT/CAREER_OPS_DATA_DIR → 仓库根 .career-ops-data 标记文件 → 仓库根默认值），这套规则在 Cowork 里同样生效，决定了你的 cv.md、tracker、reports/ 到底落在哪里。

第 4 步：交出自己的 CV

交付方式不限：可以粘贴文本，也可以直接指给 Agent 一份现有 PDF——Agent 会自己读取文件内容并转换成 cv.md。注意这里的能力边界：PDF 解析是 Agent 自身的通用能力，不是 career-ops 脚本，因此无需依赖任何专用解析器。转换完成后的 cv.md 即进入 AGENTS.md 定义的 Primary / user-authored 信任层级，成为后续所有求职内容的事实来源。

第 5 步：评估第一个职位

把职位 URL 或 JD 原文粘贴进对话即可。从这里开始，README 中描述的一切照常生效——同样的模式（modes/）、同样的文件布局、同样的数据契约（详见 DATA_CONTRACT.md）：Agent 会完成职位分类（archetype）、A–G 七段评估（角色总结、CV 匹配、级别策略、薪资调研、CV 个性化方案、面试准备、职位真实性甄别）、1–5 分综合评分，并产出报告与 tracker 记录。

哪些环节能在 Cowork 内跑、哪些必须回本机

Cowork 的文件桥（file bridge）与 Linux 沙箱对 career-ops 各环节的支持并不均等，官方验证结果如下表：

环节	在 Cowork 中的表现
评估、tracker、报告、全部模式	✅ 原生可用——Agent 直接编辑挂载目录
零 token 门户扫描（scan.mjs，走 API）	✅ 可在 Cowork 的 Linux 沙箱内运行（有 node）
合并/校验脚本（merge-tracker.mjs、verify-pipeline.mjs 等）	✅ 沙箱
PDF 生成（generate-pdf.mjs）与浏览器驱动检查（Playwright）	⚠️ Playwright 的 Chromium 装在你本机、不在沙箱里——需要时通过本地 shell 执行；或在 Cowork 里先生成 HTML，再自行打印为 PDF

也就是说，Playwright 这条限制是与 CLI 体验唯一真正的差异。沙箱内为什么能跑 scan.mjs？从架构上看，scan.mjs 走的是 Greenhouse/Ashby/Lever 等 ATS 的公开 API 做零 LLM 成本抓取，只依赖 node 与网络（该脚本与沙箱同一运行环境即可满足）；而 generate-pdf.mjs 依赖 Playwright 驱动 Chromium 渲染 templates/cv-template.html（Space Grotesk + DM Sans 字体的 ATS 优化排版），浏览器二进制在桌面本机而非沙箱内，所以必须绕过 Cowork 的文件桥直接回 shell。

两条来自实测的注意事项

官方在验证中额外确认了两个容易踩坑的细节：

1. 务必先在终端 npm install 再开始。Cowork 的本地 shell 无法访问 npm registry，错过了这一步，任何依赖脚本都会在沙箱内失败。
2. 残留的 reports/.reserve-* 哨兵文件无害。Cowork 的文件桥不能删除文件，因此一次运行结束后可能残留这类报告编号占位文件。代码层面有兜底：在 reserve-report-num.mjs 中，MAX_SENTINEL_AGE_MS 被设为 4 * 60 * 60 * 1000（即 4 小时），gcStaleReportReservations() 会遍历 reports/ 目录，清除超过老化阈值且其 owner 进程已不存活的过期哨兵——注意它还会先检查哨兵记录的所有者 PID 是否仍存活，避免误删正在进行的预留。

延伸阅读：在仓库中继续深挖

• README.md：完整功能清单与使用哲学（含 A–H 评估块、Block G 甄别、human-in-the-loop 原则）
• AGENTS.md：数据契约、Source-of-Truth 边界、更新检查约定——Agent 每次会话的"宪法"
• modes/：全部工作流模式，_shared.md 为系统级共享上下文，用户个性化写入 _profile.md 与 _custom.md
• docs/ARCHITECTURE.md：评估流程、批量处理、数据流与流水线完整性脚本的全景图
• doctor.mjs：启动自检脚本（含全部 flag 与诊断项）
• docs/SETUP.md：常规 CLI 场景的完整安装指引，可与本文的 Cowork 流程对照

作者还提到，社区先行者（woolly-earth 的独立深入指南与更早的 career-ops-plugin 适配）率先证明了这一界面的价值，本文所在的官方文档页正是在其验证之上成文的；需要更长篇幅、含完整定制案例（如多轨高级求职的自定义模式）的读者可直接检索该社区指南。