Career-Ops 性能问题排查指南：批处理四大坑与避坑方案

dctc_shouhuzhe

career-ops 在 GitHub 已积累超过 36,000 Star，是当前最受关注的 AI 求职开源项目之一。其设计理念清晰：基于 Claude Code 构建完整求职流水线，覆盖职位评估、PDF 简历生成、批量处理全链路。然而，这套系统在生产环境下的性能表现远非演示视频中那般流畅。本文聚焦批处理场景，深入拆解四个真实存在的 P0 级性能问题，并给出可操作的排查与缓解方案。

---

## 一、Windows 下的静默批处理失败

career-ops 官方定位为"全平台"工具，但实际上 Windows 用户面临的兼容性问题最为严重。Issue #539 记录了一名工程师在真实招聘场景中使用 career-ops 批处理时遇到的 4 个 P0 级 bug，最终导致静默批处理失败——进程不报错，但数据全部丢失。

核心问题在于 `batch/` 目录下的 `batch-runner.sh` 是纯 Bash 脚本。在 Windows 原生环境下无法直接执行，需要借助 WSL、Git Bash 或 Cygwyn 等 Unix 兼容层。这意味着：

- 路径解析行为不一致（Windows 反斜杠 vs Unix 正斜杠）
- 行尾符问题（CRLF vs LF）会导致 shell 脚本逻辑错乱
- 部分 Node.js ESM 模块在 Windows 路径下的行为与 Linux/macOS 不同

真实案例：某招聘平台技术团队在 2025 年 Q4 引入 career-ops 进行批量职位调研，初期在 Windows 10 开发机上部署。运行 batch-runner.sh 后进程正常退出，但 `data/applications.md` 始终为空。团队排查两周后发现：Windows Git Bash 默认的路径转换逻辑导致 JDS 目录下的配置文件读取路径全部失效，但脚本返回码仍为 0。最终该团队迁移至 WSL2 环境，问题在 10 分钟内完全解决。

排查方案：Windows 用户应在 WSL2 环境下运行 career-ops，而非依赖 Git Bash 或 Cygwyn。运行前必须执行以下检查：

```bash
bash --version  # 确认 GNU Bash
uname -a        # 确认 WSL2 或 Linux

file batch/batch-runner.sh

node -e "console.log(require('path').sep)"
```

若检测到 CRLF 行尾符，必须转换：

```bash
dos2unix batch/batch-runner.sh

sed -i 's/\r$//' batch/*.sh

Get-Content batch/batch-runner.sh | Set-Content -Path batch/batch-runner.sh -Encoding UTF8
```

预防措施：建议在项目根目录添加 `.gitattributes` 文件强制 Unix 行尾符：

```
* text=auto
*.sh text eol=lf
*.mjs text eol=lf
```

---

## 二、LLM API 调用的串行瓶颈

---

【标签】
Thinkpad, IBM, X1 Carbon, AI开发, Ollama部署, 本地大语言模型, VSCode配置, 华强北, 选购指南

【相关阅读】
- Thinkpad T14 深度评测：商务本的性能极限在哪里
- OpenClaw多模型集成配置指南
- 华强北Thinkpad港版购买防坑指南