本地部署 vs 云端调用AI求职工具的两本隐私账怎么算【免费下载链接】ai-job-searchThe job search that runs on your machine. AI job application framework built on Claude Code: evaluate postings, tailor CVs, write cover letters, prep interviews. Fork it and own it.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-job-search把简历、薪资期望、求职信草稿交给 AI 处理是现代求职者的第一直觉——登录一个网页上传 PDF等模型输出匹配度 85%全程不到五分钟。但当你开始使用ai-job-search这类开源框架时一个反直觉的事实出现了它的 README 第一行写着The job search that runs on your machine项目描述是 Fork it and own it。它把整条求职流水线——职位抓取、匹配评估、简历定制、求职信撰写——搬到了你自己的终端里唯一必须外发的是大模型推理本身。这套本地为主、云端为辅的架构把 AI 求职工具的两本隐私账摊开了本地部署保住了哪些数据云端调用又换来了什么、代价是什么本文基于ai-job-search仓库源码逐条拆解这两本账的明细以及它给出的折中方案与合规底线。一、先把账本摊开数据流长什么样ai-job-search是一个构建在 Claude Code CLI 上的开源求职应用框架采用 Python 与 Bun 双运行时Bun 运行各招聘门户的 TypeScript CLI抓取职位Python 运行薪酬查询与 PDF 校验工具Claude Code 则作为智能体编排整个/setup、/scrape、/apply、/interview工作流。从数据流的角度看这个仓库的隐私设计分为三层个人档案层/setup把姓名、联系方式、教育经历、薪资期望写入 CLAUDE.md 与.claude/skills/job-application-assistant/下的七个技能文件工作产物层/apply生成定制简历与求职信编译为 PDF 归档在documents/applications/company_role/投递状态记录在job_search_tracker.csv外部请求层职位抓取请求发往招聘门户大模型推理请求发往 Anthropic API公司研究发往 WebSearch/WebFetch。三层的隐私含义完全不同。前两层几乎完全留在本机第三层则是云端调用的全部内涵。ai-job-search的隐私账核心就是在第三层无法回避的前提下把前两层的数据主权做到极致。二、本地化部署能保住哪些数据个人档案默认不离开本机连 git 都不进最容易被忽略的一条本地不等于只在本机还包括不进 git。因为 GitHub 不允许把公开仓库的 fork 转为私有而/setup会把个人数据写进被 git 跟踪的文件一旦推送到 fork 就相当于公开。SETUP.md 用了整整两处独立警告README 快速上手处与 SETUP 第 2 节强调这一点并给出了私有仓库 upstream 远程的两分钟方案。真正的数据边界在 .gitignore 里而且写得非常细# Personal data (never commit these) salary_data.json **/job_scraper/seen_jobs.json job_search_tracker.csv documents/cv/** documents/linkedin/** documents/diplomas/** documents/references/** documents/applications/** gmail_sync/ company_research/*.json这个文件覆盖了求职流水线的每一类敏感产物薪酬数据、已投递岗位的归档、Gmail 同步状态邮件 ID 与主题、公司研究缓存个人搜索历史。其中**/job_scraper/seen_jobs.json用了任意深度匹配而非根目录规则原因是 job-scraper 技能以其自身目录为基准解析job_scraper/状态文件实际落在.claude/skills/job-scraper/下——一条根目录规则会静默失效让个人数据漏进提交。这种细节说明保住数据不是一句口号而是被当成工程问题在设计。权限白名单预授权的命令一只手数得过来本地部署的另一个隐私红利是对智能体能力的精确控制。.claude/settings.json 只预批准了三种操作运行仓库内置的六个门户 CLI、运行薪酬查询与 PDF 校验 Python 工具、执行pdftotext。没有Bash(curl:*)没有Bash(python:*)这类通配授权——而 SETUP.md 的排障章节专门提醒旧版本克隆会残留一个更宽泛的settings.local.json说明这个收紧是刻意的演进。更关键的是 tools/security_guards.py 这套 CI 守卫任何 PR 若扩大权限白名单、为门户 CLI 的package.json添加preinstall/install/postinstall等生命周期脚本、或削弱个人数据 gitignore 规则CI 直接失败。注释里写得很直白这些守卫让危险变更变响而不是不可能——改动必须在同一个 diff 里同步更新白名单从而显式可审。这对隐私的意义在于你运行的是别人写好的代码但这份代码的行为边界是被机器强制锁死的而不是靠文档承诺。文档内容永不出机器是一条硬规则本地部署能保住的最大头是求职文档本体。/notion-sync 把这一原则推到了最极端它通过官方 Notion MCP 服务器把流水线视图发布到 Notion但规则第 6 条白纸黑字写着Documents never leave the machine——简历和求职信只同步文件名绝不上传、附加或嵌入文档本身仓库文件始终是唯一事实来源且单向同步、永不回流。/gmail-sync 同理它读 Gmail 邮件分类出面试邀请、offer、拒信等状态信号但任何写操作都必须在用户审批批量提案之后且绝不自动提议hired/offer_declined这类需要真人决策的状态。把这三块拼起来本地化部署保住的账目就清楚了个人档案、求职文档、投递状态、邮件信号、公司研究缓存——全部停留在本机文件系统其中最有价值的文档本体连 git 都不进、连 Notion 都不出。三、云端调用换来的是什么换取的核心能力语义匹配与个性化生成必须诚实面对另一半账ai-job-search的大模型推理本质上是云端调用且这是它一切智能的来源。Claude Code 没有免费层需要 Pro/Max/Team 订阅或按 token 计费的 Anthropic API 额度——README.md 的 Prerequisites 明说了这一点。云端调用换来的第一项能力是语义匹配。社区测评文章反复强调它区别于传统关键词搜索基于文本嵌入模型实现跨表达技能匹配简历写built ML pipelines for customer churn prediction in Python using scikit-learn与 JD 里一句experience with predictive modeling也能对齐而不是靠字面命中。其评估框架在 .claude/skills/job-application-assistant/04-job-evaluation.md 中固化为五维评分——技术技能 30%、经验匹配 25%、行为文化 15%、职业契合 30%外加资格与语言两道硬门槛输出 0-100 的分数与 Strong/Good/Moderate/Weak/Poor 五档判定。第二项是双代理审阅流水线。.claude/commands/apply.md 定义了完整的 drafter-reviewer 工作流起草代理写完简历与求职信后另起一个全新上下文的审阅代理先做公司研究走 30 天 TTL 的缓存company_research/*.json再对草稿做事实接地审计对比三份权威源任何无法证实的指标一律删除最后产出结构化 JSON 编辑建议与叙事建议。这套起草—批判—修订的循环是单次云端提示词给不了的质量。第三项是PDF 验证闭环。.tex编译成 PDF 后Claude 要亲自读取渲染页面把简历压到恰好两页、求职信恰好一页再用pdftotext提取文本层做 ATS 可解析性检查——验证邮件地址以纯文本形式存在、阅读顺序正常、关键词覆盖率如实报告真缺口保持可见绝不塞关键词。这一步步都是云端推理换来的工程精度。代价哪些内容实际上被发往云端云端调用的代价清单比没有免费层要长个人档案文本/setup生成的画像、/apply评估与起草时读取的 profile、简历、求职信草稿都会作为上下文随推理请求发送给 Anthropic。这是框架无法回避的最小外流面——它交换来的是匹配、撰写与审阅能力JD 与职位页抓取到的职位描述属于untrusted input同样进入上下文参与评估公司研究请求审阅代理通过 WebSearch/WebFetch 研究公司属于云端检索但其结果会落地到本地缓存Gmail 全文/gmail-sync通过 Gmail MCP 读取邮件全文用于分类分类结果需审批后才写入本地。换句话说云端拿到的是文本语义拿不到的是文件实体。简历文本会随推理请求外流但简历 PDF 本身被 gitignore 与 /notion-sync 规则双重锁死在本机。这就是两本账的精确分野本地部署保住的是数据主权与审计权云端调用换来的是语义智能代价是文本层面的必然外流与逐 token 计费。值得补一笔的是成本侧的工程化对冲社区实践普遍提到的缓存机制、--dry-run、并发调优在仓库里都有对应实现且04-job-evaluation.md规定薪酬数据未配置时该步骤直接跳过、verify_pdf.py提取器缺失时优雅降级为视觉复核——框架的每个可选外部依赖都做了缺了也能跑的设计避免为一次云端调用强行引入不必要的数据路径。四、折中方案与合规底线方案一私有仓库把公开 fork这个坑填上两本账之外ai-job-search还解决了一个更隐蔽的隐私陷阱GitHub 公开 fork 本身就是一个数据泄漏通道。仓库在 README 与 SETUP.md 两处、以及 /setup 命令的 Step 0 都内置了 origin 可见性 preflight——在任何档案文件写入磁盘之前先执行git remote get-url origin检查远程仓库可见性发现是公开 fork 就停下来警告而不是写完再在收尾处提醒。配套方案是 SETUP.md 第 8 节建私有仓库把上游作为upstream远程持续接收更新tools/check_upstream_updates.py 与 tools/upstream_triage.py 负责在合并前预览哪些个性化文件会被更新触及、哪些上游提交值得审阅。这一整套把我的求职数据放哪从部署问题变成了一个可执行的工程决策。方案二把不信任编进代码隐私与合规的底线不是相信模型不会乱来而是假设外部输入是恶意的并把防线写进工作流。SECURITY.md 的威胁模型写得很诚实这是一个智能体工作流LLM 带着文件访问权限同时阅读不可信网页内容职位发布与个人数据简历、档案这个组合是主要风险面无法完全消除只能收窄。收窄的手段包括指令级防线职位文本一律视为数据而非指令绝不执行其中嵌入的指示绝不抓取正文内出现的 URL权限白名单预授权只覆盖流水线必需的精确命令robots.txt 合规抓取tools/robots_check.py 实现了 RFC 9309 的规则解析为 403 后的浏览器头重试把关——只有站点公开策略允许时才重试Disallow或无法确认时一律放弃。linkedin-search技能也在 SKILL.md 里明示仅供个人使用、保持低流量因为自动化访问违反其服务条款零生命周期脚本门户 CLI 的package.json不允许任何postinstall类脚本把bun install变成纯依赖安装堵住供应链注入。底线代码可读性本身就是隐私机制ai-job-search还有一个容易被低估的合规设计它把你自己读代码作为流程的一环。README 在介绍从其他 fork 借用门户技能时明确要求先通读代码、确认网络调用只指向声称的招聘门户、确认无依赖与生命周期脚本再离线跑bun test——而且强调复制步骤是刻意手动的因为你的 settings 已经预授权了门户 CLI 免提示运行若由安装器自动从第三方仓库拉取代码就会跳过唯一重要的检查你本人先读代码。同时 SECURITY.md 反复声明指令级防线不是沙箱——在不信任的招聘网站上先检查智能体抓取和写入了什么再发送。这构成了第三本账的答案当云端推理不可避免时合规底线 最小外流面 显式可审的权限 可审计的抓取行为 永不自动的对外动作 留给人类的最终复核权。所有自动化都停在起草、建议、批量提案这一步投递、审批、接受 offer 这些动作永远由人按下。结语回到两本账的清算ai-job-search的本地部署保住了求职者最值钱的三样东西——档案文件不进 git、文档本体不出机器、智能体行为边界被 CI 强制锁定云端调用换来了语义匹配、双代理审阅与 PDF 验证闭环代价是档案文本与 JD 必然进入模型推理上下文、以及逐 token 的持续成本。它不是完全本地的乌托邦而是一份被工程化得很精细的隐私权衡契约能留在本机的绝不外发必须外发的按最小面走一切外部动作默认不可信、可审计、可回退。对任何把简历交给 AI 的求职者来说这份契约本身——而不是某个模型的智能程度——才是选择工具时真正该算清的那本账。【免费下载链接】ai-job-searchThe job search that runs on your machine. AI job application framework built on Claude Code: evaluate postings, tailor CVs, write cover letters, prep interviews. Fork it and own it.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-job-search创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/17 18:07:50 · 阅读 1.2k 本地部署 vs 云端调用：AI求职工具的两本隐私账怎么算
本地部署 vs 云端调用AI求职工具的两本隐私账怎么算【免费下载链接】ai-job-searchThe job search that runs on your machine. AI job application framework built on Claude Code: evaluate postings, tailor CVs, write cover letters, prep interviews. Fork it and own it.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-job-search把简历、薪资期望、求职信草稿交给 AI 处理是现代求职者的第一直觉——登录一个网页上传 PDF等模型输出匹配度 85%全程不到五分钟。但当你开始使用ai-job-search这类开源框架时一个反直觉的事实出现了它的 README 第一行写着The job search that runs on your machine项目描述是 Fork it and own it。它把整条求职流水线——职位抓取、匹配评估、简历定制、求职信撰写——搬到了你自己的终端里唯一必须外发的是大模型推理本身。这套本地为主、云端为辅的架构把 AI 求职工具的两本隐私账摊开了本地部署保住了哪些数据云端调用又换来了什么、代价是什么本文基于ai-job-search仓库源码逐条拆解这两本账的明细以及它给出的折中方案与合规底线。一、先把账本摊开数据流长什么样ai-job-search是一个构建在 Claude Code CLI 上的开源求职应用框架采用 Python 与 Bun 双运行时Bun 运行各招聘门户的 TypeScript CLI抓取职位Python 运行薪酬查询与 PDF 校验工具Claude Code 则作为智能体编排整个/setup、/scrape、/apply、/interview工作流。从数据流的角度看这个仓库的隐私设计分为三层个人档案层/setup把姓名、联系方式、教育经历、薪资期望写入 CLAUDE.md 与.claude/skills/job-application-assistant/下的七个技能文件工作产物层/apply生成定制简历与求职信编译为 PDF 归档在documents/applications/company_role/投递状态记录在job_search_tracker.csv外部请求层职位抓取请求发往招聘门户大模型推理请求发往 Anthropic API公司研究发往 WebSearch/WebFetch。三层的隐私含义完全不同。前两层几乎完全留在本机第三层则是云端调用的全部内涵。ai-job-search的隐私账核心就是在第三层无法回避的前提下把前两层的数据主权做到极致。二、本地化部署能保住哪些数据个人档案默认不离开本机连 git 都不进最容易被忽略的一条本地不等于只在本机还包括不进 git。因为 GitHub 不允许把公开仓库的 fork 转为私有而/setup会把个人数据写进被 git 跟踪的文件一旦推送到 fork 就相当于公开。SETUP.md 用了整整两处独立警告README 快速上手处与 SETUP 第 2 节强调这一点并给出了私有仓库 upstream 远程的两分钟方案。真正的数据边界在 .gitignore 里而且写得非常细# Personal data (never commit these) salary_data.json **/job_scraper/seen_jobs.json job_search_tracker.csv documents/cv/** documents/linkedin/** documents/diplomas/** documents/references/** documents/applications/** gmail_sync/ company_research/*.json这个文件覆盖了求职流水线的每一类敏感产物薪酬数据、已投递岗位的归档、Gmail 同步状态邮件 ID 与主题、公司研究缓存个人搜索历史。其中**/job_scraper/seen_jobs.json用了任意深度匹配而非根目录规则原因是 job-scraper 技能以其自身目录为基准解析job_scraper/状态文件实际落在.claude/skills/job-scraper/下——一条根目录规则会静默失效让个人数据漏进提交。这种细节说明保住数据不是一句口号而是被当成工程问题在设计。权限白名单预授权的命令一只手数得过来本地部署的另一个隐私红利是对智能体能力的精确控制。.claude/settings.json 只预批准了三种操作运行仓库内置的六个门户 CLI、运行薪酬查询与 PDF 校验 Python 工具、执行pdftotext。没有Bash(curl:*)没有Bash(python:*)这类通配授权——而 SETUP.md 的排障章节专门提醒旧版本克隆会残留一个更宽泛的settings.local.json说明这个收紧是刻意的演进。更关键的是 tools/security_guards.py 这套 CI 守卫任何 PR 若扩大权限白名单、为门户 CLI 的package.json添加preinstall/install/postinstall等生命周期脚本、或削弱个人数据 gitignore 规则CI 直接失败。注释里写得很直白这些守卫让危险变更变响而不是不可能——改动必须在同一个 diff 里同步更新白名单从而显式可审。这对隐私的意义在于你运行的是别人写好的代码但这份代码的行为边界是被机器强制锁死的而不是靠文档承诺。文档内容永不出机器是一条硬规则本地部署能保住的最大头是求职文档本体。/notion-sync 把这一原则推到了最极端它通过官方 Notion MCP 服务器把流水线视图发布到 Notion但规则第 6 条白纸黑字写着Documents never leave the machine——简历和求职信只同步文件名绝不上传、附加或嵌入文档本身仓库文件始终是唯一事实来源且单向同步、永不回流。/gmail-sync 同理它读 Gmail 邮件分类出面试邀请、offer、拒信等状态信号但任何写操作都必须在用户审批批量提案之后且绝不自动提议hired/offer_declined这类需要真人决策的状态。把这三块拼起来本地化部署保住的账目就清楚了个人档案、求职文档、投递状态、邮件信号、公司研究缓存——全部停留在本机文件系统其中最有价值的文档本体连 git 都不进、连 Notion 都不出。三、云端调用换来的是什么换取的核心能力语义匹配与个性化生成必须诚实面对另一半账ai-job-search的大模型推理本质上是云端调用且这是它一切智能的来源。Claude Code 没有免费层需要 Pro/Max/Team 订阅或按 token 计费的 Anthropic API 额度——README.md 的 Prerequisites 明说了这一点。云端调用换来的第一项能力是语义匹配。社区测评文章反复强调它区别于传统关键词搜索基于文本嵌入模型实现跨表达技能匹配简历写built ML pipelines for customer churn prediction in Python using scikit-learn与 JD 里一句experience with predictive modeling也能对齐而不是靠字面命中。其评估框架在 .claude/skills/job-application-assistant/04-job-evaluation.md 中固化为五维评分——技术技能 30%、经验匹配 25%、行为文化 15%、职业契合 30%外加资格与语言两道硬门槛输出 0-100 的分数与 Strong/Good/Moderate/Weak/Poor 五档判定。第二项是双代理审阅流水线。.claude/commands/apply.md 定义了完整的 drafter-reviewer 工作流起草代理写完简历与求职信后另起一个全新上下文的审阅代理先做公司研究走 30 天 TTL 的缓存company_research/*.json再对草稿做事实接地审计对比三份权威源任何无法证实的指标一律删除最后产出结构化 JSON 编辑建议与叙事建议。这套起草—批判—修订的循环是单次云端提示词给不了的质量。第三项是PDF 验证闭环。.tex编译成 PDF 后Claude 要亲自读取渲染页面把简历压到恰好两页、求职信恰好一页再用pdftotext提取文本层做 ATS 可解析性检查——验证邮件地址以纯文本形式存在、阅读顺序正常、关键词覆盖率如实报告真缺口保持可见绝不塞关键词。这一步步都是云端推理换来的工程精度。代价哪些内容实际上被发往云端云端调用的代价清单比没有免费层要长个人档案文本/setup生成的画像、/apply评估与起草时读取的 profile、简历、求职信草稿都会作为上下文随推理请求发送给 Anthropic。这是框架无法回避的最小外流面——它交换来的是匹配、撰写与审阅能力JD 与职位页抓取到的职位描述属于untrusted input同样进入上下文参与评估公司研究请求审阅代理通过 WebSearch/WebFetch 研究公司属于云端检索但其结果会落地到本地缓存Gmail 全文/gmail-sync通过 Gmail MCP 读取邮件全文用于分类分类结果需审批后才写入本地。换句话说云端拿到的是文本语义拿不到的是文件实体。简历文本会随推理请求外流但简历 PDF 本身被 gitignore 与 /notion-sync 规则双重锁死在本机。这就是两本账的精确分野本地部署保住的是数据主权与审计权云端调用换来的是语义智能代价是文本层面的必然外流与逐 token 计费。值得补一笔的是成本侧的工程化对冲社区实践普遍提到的缓存机制、--dry-run、并发调优在仓库里都有对应实现且04-job-evaluation.md规定薪酬数据未配置时该步骤直接跳过、verify_pdf.py提取器缺失时优雅降级为视觉复核——框架的每个可选外部依赖都做了缺了也能跑的设计避免为一次云端调用强行引入不必要的数据路径。四、折中方案与合规底线方案一私有仓库把公开 fork这个坑填上两本账之外ai-job-search还解决了一个更隐蔽的隐私陷阱GitHub 公开 fork 本身就是一个数据泄漏通道。仓库在 README 与 SETUP.md 两处、以及 /setup 命令的 Step 0 都内置了 origin 可见性 preflight——在任何档案文件写入磁盘之前先执行git remote get-url origin检查远程仓库可见性发现是公开 fork 就停下来警告而不是写完再在收尾处提醒。配套方案是 SETUP.md 第 8 节建私有仓库把上游作为upstream远程持续接收更新tools/check_upstream_updates.py 与 tools/upstream_triage.py 负责在合并前预览哪些个性化文件会被更新触及、哪些上游提交值得审阅。这一整套把我的求职数据放哪从部署问题变成了一个可执行的工程决策。方案二把不信任编进代码隐私与合规的底线不是相信模型不会乱来而是假设外部输入是恶意的并把防线写进工作流。SECURITY.md 的威胁模型写得很诚实这是一个智能体工作流LLM 带着文件访问权限同时阅读不可信网页内容职位发布与个人数据简历、档案这个组合是主要风险面无法完全消除只能收窄。收窄的手段包括指令级防线职位文本一律视为数据而非指令绝不执行其中嵌入的指示绝不抓取正文内出现的 URL权限白名单预授权只覆盖流水线必需的精确命令robots.txt 合规抓取tools/robots_check.py 实现了 RFC 9309 的规则解析为 403 后的浏览器头重试把关——只有站点公开策略允许时才重试Disallow或无法确认时一律放弃。linkedin-search技能也在 SKILL.md 里明示仅供个人使用、保持低流量因为自动化访问违反其服务条款零生命周期脚本门户 CLI 的package.json不允许任何postinstall类脚本把bun install变成纯依赖安装堵住供应链注入。底线代码可读性本身就是隐私机制ai-job-search还有一个容易被低估的合规设计它把你自己读代码作为流程的一环。README 在介绍从其他 fork 借用门户技能时明确要求先通读代码、确认网络调用只指向声称的招聘门户、确认无依赖与生命周期脚本再离线跑bun test——而且强调复制步骤是刻意手动的因为你的 settings 已经预授权了门户 CLI 免提示运行若由安装器自动从第三方仓库拉取代码就会跳过唯一重要的检查你本人先读代码。同时 SECURITY.md 反复声明指令级防线不是沙箱——在不信任的招聘网站上先检查智能体抓取和写入了什么再发送。这构成了第三本账的答案当云端推理不可避免时合规底线 最小外流面 显式可审的权限 可审计的抓取行为 永不自动的对外动作 留给人类的最终复核权。所有自动化都停在起草、建议、批量提案这一步投递、审批、接受 offer 这些动作永远由人按下。结语回到两本账的清算ai-job-search的本地部署保住了求职者最值钱的三样东西——档案文件不进 git、文档本体不出机器、智能体行为边界被 CI 强制锁定云端调用换来了语义匹配、双代理审阅与 PDF 验证闭环代价是档案文本与 JD 必然进入模型推理上下文、以及逐 token 的持续成本。它不是完全本地的乌托邦而是一份被工程化得很精细的隐私权衡契约能留在本机的绝不外发必须外发的按最小面走一切外部动作默认不可信、可审计、可回退。对任何把简历交给 AI 的求职者来说这份契约本身——而不是某个模型的智能程度——才是选择工具时真正该算清的那本账。【免费下载链接】ai-job-searchThe job search that runs on your machine. AI job application framework built on Claude Code: evaluate postings, tailor CVs, write cover letters, prep interviews. Fork it and own it.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-job-search创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考