用 AI 搭一个求职自动化系统：别先做投递机器人

我想做一个 AI 求职自动化系统，但越拆越觉得，第一版不应该是"自动投递机器人"。

这个判断一开始只是直觉。后来我真按这个思路搭了一套东西，跑了大约一个月，几十个岗位从收集一路走到沟通、面试和复盘——回头看，第一版没做成投递机器人是对的。所以这篇文章分三段写：当初我怎么拆这个系统，实际落地成了什么样，以及接下来还想补什么。

系统边界

自动投递听起来最爽：抓职位、改简历、填表、投出去。但这也是最容易把系统做歪的部分。求职不是广告投放，目标不是把简历撒得更远，而是把每次投递变成一次更有根据的选择。真正消耗人的，是重复读 JD、手工对齐经历、保存不同版本材料、忘记跟进和复盘。

所以第一版应该先解决这些。它应该像一个求职 CRM 和材料工作台，而不是一个替我按按钮的投递器。我把它拆成四个层次：

职位收集：保存职位链接、公司、岗位、城市/远程、薪资、发布时间和原始 JD。
职位理解：用 AI 提取硬性要求、隐性偏好、关键词、风险信号和面试可能追问。
材料匹配：根据我的经历库生成匹配说明、简历改写建议和 cover letter 草稿。
流程复盘：记录投递状态、沟通记录、面试反馈、拒信原因和下一步动作。

这里最重要的设计是：AI 只做分析和草稿，不直接替我投递。投递前必须人工确认，因为岗位选择、简历真实性和沟通语气都是长期信誉的一部分。系统最多把"是否值得投、该怎么改、缺什么证据"摆到我面前，不能替我越过这个判断。这一条当初是我的主张，跑了一个月下来，我更确信它是对的。

AI 应该做什么

我希望 AI 负责四类事情。

第一是降噪。一份 JD 里常常混着必要条件、加分项、模板废话和招聘方也没想清楚的愿望清单。AI 可以先把这些拆开，让我快速判断是否值得投入时间。

第二是映射。比如岗位要求"熟悉内容系统、自动化流程、Cloudflare Workers"，系统应该能从我的项目库里找出博客 CMS、发布流程、Worker API 这些证据，而不是让我每次重新回忆。

第三是生成可改的草稿。简历 bullet、项目描述、邮件开头都可以生成，但必须附上引用到的经历来源，避免把没有做过的事情写进去。

第四是提示缺口。如果某个岗位要求我没有明确证据，系统应该直接标出"缺少证据"，而不是编一个看起来顺滑的表达。求职材料宁可保守一点，也不能把模型幻觉写进简历。

不做什么

第一版我不做自动投递，不做绕过招聘平台限制的浏览器脚本，也不做虚假经历生成。它们短期看起来提效，长期会污染数据，甚至让后续复盘失真。

我也不会把所有职位都塞进向量库然后追求一个神秘的"匹配分"。匹配分最多只能当排序提示，不能替代判断。一个岗位是否值得投，往往取决于公司状态、业务方向、招聘动机、岗位稀缺性和我当前阶段的目标。

还有一个边界是数据隐私。简历、项目经历、沟通记录、薪资预期和面试反馈都不应该随便发给不可信的第三方接口。第一版更适合本地存储、最小字段、手动导入，不采集招聘平台账号 Cookie，不保存验证码，不自动登录，也不记录和求职无关的个人信息。

实际落地成了什么样

真动手的时候，我做了一个当初没料到的选择：没有先建数据库，而是把整套系统落在一堆 Markdown 文件上，用一个看板插件把它们组织起来。

当初我想的是数据结构得先定下来，默认要上 SQLite 或某种结构化存储，好让系统能搜索、比较、复盘。但真开始用才发现，求职这件事的瓶颈根本不是查询能力，而是维护阻力——我一天只处理几个到十几个岗位，真正会让系统烂尾的，是"每次录入都嫌麻烦"。纯文本加上 Git，再加上任何 AI 环境都能直接读，这种耐用性比数据库的查询能力重要得多。数据库要我先想清楚 schema、配好读写工具才能开始；Markdown 文件我现在就能敲一行。

看板是状态的唯一事实源

系统的核心是一个 Markdown 看板文件，列从左到右是：收集箱 → 需调研 → 待沟通 → 已投递/已沟通 → 面试（R1/R2/R3）→ offer → 已结束（拒/放弃）→ 归档（长期不跟）。此外还有两列常驻：一列模板库，一列使用规则。

每个岗位在看板上是一行，格式固定：公司 - 岗位 - 薪资 - 渠道/日期 - 优先级判断（A/B/C/D 再加一句理由）- 下一步动作 - 详情卡链接。一眼扫下去，就知道所有在跑的岗位卡在哪、下一步该干什么。

每个岗位再配一张详情卡，就是一个单独的 Markdown 文件，卡里记岗位事实、调研、沟通记录、面试准备和复盘。关键的一点是：详情卡里不写状态字段。一个岗位现在是"待沟通"还是"面试 R2"，只看它在看板的哪一列，卡片里绝不重复写一遍。这就是"看板列是状态的唯一事实源、详情卡只沉淀细节"——当初担心的双写失配（同一个状态存两处、改一处忘了另一处）从根上就没了。

同样的道理还延伸到派生视图：我想要表格和一个能在浏览器里打开的页面，于是有个脚本把看板派生成这两样东西。派生出来的文件禁止手改，因为它们只是看板的投影，要改就改源头，不然又回到双写失配的老问题。

配套的常驻文件

光有看板还不够，真正让它跑得久的是几个常驻文件：

一个决策规则文件，写死方向、offer 底线和沟通话术规则，省得每个岗位来都重新跟自己（或 AI）争论一遍。
一份 PROFILE，记我的背景和能力边界，AI 分析岗位时拿它当基准。
STATUS / TODO / LOG 三件套，专门为"多个 AI 环境轮流干活"设计：每次 AI 开工前先读，干完更新 STATUS、往 LOG 里追加一条。
一个 prompts 目录，放启动任务和生成交接包的固定提示词。
模板库那一列，放成文的话术（首次沟通、约面、追问团队、跟进、冷处理）、简历轻定制规则和面试复盘模板。

AI 接进来的方式很简单：我把一个岗位丢给它，它默认先分析这个机会，再去更新看板和对应的详情卡；之后的沟通、面试、被拒都更新同一张卡，不重复建卡。有一条规则我看得很重——AI 对话本身不能当长期事实源。对话会滚走、会丢，任何值得留下的事实都必须落盘到文件里。看板和卡片才是记忆，聊天窗口只是临时工作台。

隐私落成了红线清单

原来"隐私默认收紧"那条设想，落地时写成了一份明确的红线：不记录身份证、验证码、账号密码、薪资流水、招聘私聊原文、登录态截图。聊天截图只在本地蒸馏出事实后把结论写进卡片，截图本身不进 Git。想法变成清单之后，执行时就不用每次现场判断了。

如果规模再大一档

跑了大约一个月，几十个岗位走过完整的状态流转，包括面试和复盘，这套纯文本的东西完全扛得住。当初那套结构化设想我没删，先留着——如果哪天岗位量大到 Markdown 手工维护不动，再考虑把它升级成这样的表：

job: id / company / title / source_url / jd_summary / requirements / risks / status
profile_asset: id / type(project|work|education|achievement) / title / evidence / keywords
application: job_id / resume_version / cover_letter / human_notes / confirmed_by_human / next_action

但那是"规模逼到那一步"才值得做的事。现阶段，维护阻力最低的方案就是最好的方案。

接下来想补什么

排在最前面的是一个我还没实施、大概会等找到工作之后再做的想法：把"入库-分析"这一步从桌面搬进随手可用的聊天入口。现在录入一个岗位，我得回到看板那套桌面工作流里。我想要的是——发现一个岗位，直接把链接或者其他材料丢进某个即时聊天工具里对接的 AI 助手，它基于我的背景档案和决策规则自动分析，回我一句"值不值得投、该问什么、用哪版简历"。等于把系统入口做到手机上随手能用，晚点再回桌面把结论归档。

其余几条更琐碎，都是奔着现有系统的具体维护痛点去的：

给详情卡加一层 frontmatter。现在卡片基本是散文，统计只能靠人数。如果每张卡顶上补几个结构化字段（渠道、优先级、状态时间戳），就能让脚本自动派生看板行和一些基本统计，而不是我手抄。
渠道与漏斗转化复盘。跑了几十个岗位之后，我其实说不清哪个渠道更值当、从收集到沟通到面试各漏了多少。有了结构化字段，就能算一算转化，把精力往回报高的渠道挪。
断链检查脚本。看板行和详情卡靠链接互指，纯手动维护迟早会出现卡片没链、链接指向不存在的文件。写个跑一遍就报告断链的脚本，能省掉"点进去发现打不开"的糟心。
跟进提醒。最容易漏的就是"待沟通"里躺了很久没动的岗位。我想让系统能把"待沟通超过 N 天"或者"面试后 N 天没跟进"的卡自动顶出来，而不是靠我的记性。
复盘回流成证据库。每次面试复盘其实攒了不少"这段经历这样讲更好"的素材，现在它们埋在各张卡里。如果能把这些回流进 PROFILE 或一个简历证据库，下次改简历就有现成的、被面试验证过的说法可用。

关键原则

这几条当初是我的主张，现在跑了一个月，算是有了点实践背书：

判断不外包：投不投、怎么写、是否接受机会，最后都由人决定。
证据可追溯：每段生成文本都应该能追到真实经历。
隐私默认收紧：能本地处理就本地处理，能少存就少存，不把账号凭证和无关个人信息放进系统。
复盘优先于规模：宁可少投一些，也要知道每次为什么投、结果为什么好或不好。

求职自动化的价值，不是让系统替我显得更忙，而是让我更清楚地看见自己和岗位之间的距离。这一个月下来，最大的体会其实很朴素：让这套东西一直有人用下去，比让它看起来先进重要得多。