最近在集中找工作。投了几家之后我意识到一件事：找工作其实特别像一个项目。它有明确的目标，拿到一份合适的 offer；有一堆并行推进的任务，同时跟好几家公司；还有大量能反复用的资产，简历、项目经历、面试话术。可大多数人处理它的方式是散装的，想到哪做到哪，每投一家都从头来一遍。
我是个 Java 后端，干这行有些年头了。某天我想，既然它这么像一个项目，为什么不真把它当个项目来管？我用 Claude Code 建了个求职仓库，把该沉淀的资产、该固化的流程、该跟踪的进度都放进去，又写了几个 skill 把最重复的环节自动化掉。这篇记一下这个“求职项目”是怎么搭起来的。
找工作为什么值得当个项目做
先说为什么值得这么较真。有几年经验的人，找工作真正难的往往不是没东西讲，是另外几件事，而它们恰好都是一个“失控的项目”会有的症状。
一是细节记不清。简历上写的项目是两三年前做的，当时调的参数、踩的坑、最后性能提升多少，现在只记得大概。面试官一追问具体类名、数字，就卡壳，或者随口说错。这其实是项目资产没沉淀好。
二是话术不稳定。自我介绍这周讲一版下周讲一版，状态好的时候滔滔不绝，状态差的时候磕磕巴巴。同样一个项目，上家面的时候讲得精彩，下家就漏了重点。这是流程没固化。
三是容易吹过头。准备得越充分，越容易把简历上的东西讲得比实际做的还厉害。比如简历写了“自研流程引擎”，面试时被人往 Activiti 的内部实现里带，你其实没用它的引擎、也不熟，硬答就会穿帮。这是缺少风险预案。穿帮一次，整场面试的信任就塌了。
这三件事有个共同点：都该靠项目机制兜住，别指望临场发挥。资产沉淀好，流程固化下来，风险提前标出去，问题就解决了一大半。这个仓库要做的，就是给求职这件事搭一个能跑起来的项目骨架。
先把项目的资产库建起来
整个仓库就是一堆 Markdown 文件，按求职的流程分了八个目录，每个目录对应一类项目资产。
| 目录 | 装什么 |
|---|---|
简历/ |
详细版和精简版两份，文件名带日期 |
工作经历/ |
每段经历的素材，前司那十几个项目的代码库索引也在这 |
项目亮点/ |
把项目整理成能讲的亮点，STAR 结构，按价值排序 |
面试题库/ |
按主题分的复习题，JVM、MySQL、并发、分布式、场景题等十来个分类 |
自我介绍/ |
按面试轮次的逐字稿，HR 面、一面、二面各一份 |
面试经验/ |
投递进展看板，按状态分子目录：期望岗位、待面试、等结果、未通过、已放弃 |
学习计划/ |
系统补课用的教材，按阶段组织 |
求职日记/ |
每天投了谁、做了什么 |
八个目录是资产库的主体，但整个仓库摊开看，还不止这些：
旁边还挂着进度管理、三个 skill 组成的工具链，以及 CLAUDE.md 和 README.md 这两份项目约定。光有目录不算项目，关键在资产怎么流动、被反复用。下面这张图讲的是数据怎么跑的：
flowchart LR
subgraph 资产库[资产：整理一次，反复用]
R[简历]
E[工作经历]
H[项目亮点]
Q[面试题库]
end
subgraph 工具链[三条自动化流水线]
S1[interview-prep]
S2[interview-highlight-doc]
S3[textbook-stage-gen]
end
subgraph 交付物[每次面试的产出]
O1[面试经验/某公司]
O2[自我介绍逐字稿]
O3[阶段教材]
end
R --> S1
H --> S1
Q --> S1
S1 --> O1
O1 --> O2
E --> S2
S2 --> H
S3 --> O3
O3 -.补课后回流.-> Q
底层的资产（简历、经历、亮点、题库）整理一次，反复给上面的工具链用。三个 skill 各管一段，产出到对应的地方。其中 interview-prep 最常用，下面挨个说。
除了资产，这个项目还有两样专门管“进度”的东西。仓库根的 README.md 里有一张面试记录表，每投一家公司加一行，在“感兴趣→已投→面试→已发 offer”几个阶段打勾。这就是项目的看板，一眼能看清现在有多少家卡在哪个阶段、哪些石沉大海了。求职日记/ 则是每天一篇，记当天投了谁、推进了什么、踩了什么坑，相当于这个项目的每日站会加复盘。有这两样，求职就不会变成一团糊涂账。
三条自动化流水线（三个 skill）
skill 是 Claude Code 的一个机制，可以理解成一段固化下来的工作流指令。我写了三个，分别接在求职项目最重复的三个环节上。
interview-prep：投一家公司，出一整套面试包
这是用得最多的一个。输入是“公司名 + 岗位 JD”，JD 可以是文字，也可以直接丢一张招聘页截图，它会先 OCR 提取。真正费功夫、也最该费功夫的，是它在出材料之前先做的三件功课。
一是公司调查。不是扫一眼官网那种看，是联网挖一遍：公司做什么业务、规模多大、融到哪一轮、最近有什么动向、技术团队什么风格。这些背景决定后面所有话术的底色——去创业公司讲稳健、去大厂讲从零到一，完全是两套讲法。
二是JD 解读。JD 表面写的和实际要的人经常不是一回事。它会拆开看：哪些是真硬指标，哪些是凑数的加分项；从一堆要求里反推这个团队大概在做什么业务、缺什么样的角色。JD 读懂了，准备才有方向。
三是岗位分析。把 JD 跟我仓库里的简历和项目亮点逐条对一遍——哪里对口，正好是该拎出来重点讲的；哪里是缺口，提前想好话术，别等现场被问到才慌。决定讲哪个亮点，光看 JD 字面还不够，skill 还会去翻公司最近的新闻，推断这家具体在做什么业务、这个岗位招进去大概干什么活，再综合这些挑出最对路的那几个。
它有个设计我觉得挺聪明，按是否已经约到面试分两条路走。
- 还没约面，只是看看、调研一下：在期望岗位底下记一条，把公司背景、JD 原文、“为什么选你们公司”的口语稿、针对这家定制的三面逐字稿和预测问答收在一起。
- 已经约到面试了：单独给这家公司开一个目录，把上场要用的东西成套放进去——公司速览和核心雷区、开口念的自我介绍逐字稿、把面试往有利方向引的话术、按轮次分类的高频题，再配几张临场前扫一眼的脑图速览卡。
我特别看重的是它对**“不编造”的执着**。逐字稿和答案里凡是涉及我经历的部分，只能从仓库里已有的项目亮点和简历里取，查不到的字段就老老实实标注“查不到，以工商登记为准”，绝不凑数。这一点我下面单独讲。
说到逐字稿，得补一句用法，免得误会。它是用来模拟真实面试场景的，不是让你上场照着背。真到现场，面试官追的点经常不在 JD 写的那几条里，得靠当场听、当场想，随机应变。稿子真正的作用，是把能预料到的部分先想透、练熟，好腾出脑子去接那些预料不到的。
它也有个明显的短板：说不清一家公司整体的技术架构。单看一个工程的代码，撑死了只能看清这一个服务，公司层面那些服务怎么拆、怎么交互、数据怎么流，它拼不出来。我打算后面补一下这块——先靠 AI 主动问询的方式一步步把公司的技术架构盘出来，攒成一份整体架构文档，再拿它去对具体项目，找出更适配、面试时更有得聊的点。
interview-highlight-doc：把代码读成能讲的亮点
这个 skill 解决的是开头说的第一个痛点：细节记不清，还容易吹过头。
它的输入是一个 Java 服务的源码目录，输出是一份 亮点-<服务名>.md。流程是先读代码，把真实类名、方法、行号摸清楚，再整理成能用 STAR 结构讲出来的亮点文档。
为什么找亮点这事要交给 AI，不自己来？因为有个反直觉的现象：自己写的代码，反而最看不出哪儿是亮点。
天天对着那堆逻辑，你太清楚每一行是怎么熬出来的，反而觉得全是苦活累活，分不清哪块是真复杂、哪块其实稀松平常。不识庐山真面目，只缘身在此山中，看自己的代码大概就是这种状态。AI 换了个视角，它是头一回读这段代码的旁观者，没有“这功能是我通宵写出来的所以觉得理所当然”这层感情滤镜。它扫到一段多阶段调度、一把细粒度的分布式锁、一个历史回溯重算，会客观地判断“这块有点东西”，然后提醒你这地方面试时值得拎出来讲。
效率也差出一截。十几万行的服务，我自己一行行翻亮点得花上好几天，AI 几分钟通读一遍，还能按复杂度排个序，直接点出哪几处逻辑最硬。当局者迷，旁观者清，把找亮点这件事交给一个清醒的旁观者，比自己闷头找靠谱得多。
核心就一条硬规矩：以代码为准，简历说的不算。
它会做一种很关键的核实动作。比如简历上声称这个服务用了缓存，它会去 grep @Cacheable、JetCache 这些注解，确认代码里真有；声称某段逻辑是并行执行的，它会去看那段代码是不是被注释掉了、是不是真在跑。简历、文档里的口径都可能过时或者夸大，代码不会撒谎。发现口径对不上，就在文档里点出来、校正掉。
还有一条反直觉的约束：严格锁死三个亮点，不许多写。一开始我也想多塞几个显得厉害，后来发现写五到八个反而每个都讲不透、还显得在凑数。聚焦三个最硬的，按架构深度、业务复杂度、并发一致性这个顺序排，每个都经得起追问，反而更显功力。
每写完一个亮点，它还会自己跑一遍自检：链接是不是死链、口径有没有讲穿（比如 Activiti 那个雷区）、STAR 段落有没有 AI 味、该配流程图的长链路配了没有。
textbook-stage-gen：批量补课，系统重建知识体系
这个 skill 跟具体某次面试关系没那么直接，但它管的是另一件大事，该补的课得系统地补。
我的 学习计划/ 下有一套按阶段组织的教材，讲企业级 Java 加 AI 应用开发。一个阶段少则两三课，多则八九课。这个 skill 的工作就是按阶段把一整批课文批量生成出来。
它有意思的地方在于怎么处理“并行生成”的通病。如果让 AI 一课一课单独写，每课单看都挺自洽，拼到一起却对不上：同一个概念在两课里重复讲、前后课的异常体系不兼容、重试层数在两课里乘起来爆炸、注入方式这课这样那课那样。它用四步解决：
- 并行生成，每课派一个子任务，同时跑。
- 整阶段审查，派一个子任务通读所有课，专门查跨课的重复、断层、目的没收口。
- 并行修复，每个文件派一个子任务，按审查报告精确改。
- grep 验证，用命令行客观验证破折号数量、个人词残留、交叉引用链接是不是真的存在，不靠 AI 自报。
第四步里有个我踩过的大坑值得提一句：macOS 的 grep 默认是 BSD 版，不认 \| 这种交替写法，必须加 -E 才行。不加的话搜出来“一个都没有”，看着像“已清除”，其实是假阴性，根本没搜到。这种检查清单被固化进了这个 skill，后面生成新阶段就不用再踩一遍。
给这个项目立几条规矩
光有 skill 不够，真正让这个项目跑得稳的是几条立好的规矩，我写进了仓库的 CLAUDE.md，每次跑 skill 它都会先读。
先说事实基准。CLAUDE.md 里记着所有不能踩的雷。比如我前司做过一个自研流程引擎，口径要严格说成“用了 Activiti 的 BPMN 工具层做流程图建模和 XML 转换校验，但没用它的引擎，执行层是自研的”。原因也要备好：Activiti 引擎是为人工审批流设计的，重度依赖数据库、部署重，我的场景却是系统自动执行、要零数据库依赖的内存调度，所以不合适。这种边界一旦在 CLAUDE.md 里钉死，所有 skill 产出的材料口径就一致了，不会这次这么说、下次那么说。
再说不编造这条底线。公司查不到的注册资本、我没做过的行业系统，一律诚实标注。JD 要求但我没做过的技术，话术是“技术栈接得住、需要补”，别装做过。宁可面试时少讲一个亮点，也不讲一个经不起追问的假亮点。讲穿一次，整场面试的信任就没了。
最后是去 AI 味。所有要开口念的稿子，写完都过一遍 humanizer-zh 这个 skill。它会抓一类典型的 AI 写作痕迹：满篇破折号、机械的序号、否定式排比、虚词堆砌（赋能、抓手、闭环、彰显这些）。面试官看简历看多了，一眼就能分辨哪句是人话、哪句是 AI 编的。把这些痕迹洗掉，稿子才像真人在说话。
怎么启动你自己的求职项目
这套东西不用原样照搬，我觉得可以分几层看。
最基础的一层，就是一个 git 仓库加一份 CLAUDE.md。哪怕不用 Claude Code，你也值得把简历、项目亮点、自我介绍、题库按目录理清楚，再写一份文档记下自己的雷区。光是这一步，就能让求职从临场发挥变成有据可查，算是把项目的资产库立起来了。
往上一层，是把最重复的动作固化成 skill。如果你也用 Claude Code，可以照着 interview-prep 的思路写一个：固定输入是公司加 JD，固定输出是公司调研加逐字稿。真正的难点是想清楚“每次投一家公司我到底重复做了哪些动作”，代码倒是其次。想清楚之后，把这些动作的顺序和质量标准写死就行。
再往上，是 interview-highlight-doc 和 textbook-stage-gen 这种更重的 skill。前者要有自己项目的源码可以喂给它读，后者适合有明确学习目标、要系统补一大块知识的时候才用得上。没有对应场景，就别先建。
还有一点想强调：这套仓库真正值钱的地方，是让准备工作的质量稳定下来，那几个 skill 倒在其次。每投一家公司，我拿到的是同一套结构、同一个口径、同一份事实基准支撑出来的材料。状态再差，底线也在那。对一个正在求职、本来就焦虑的人来说，这种稳定性比什么都重要。
小结
把找工作当个项目来做，本质是用项目管理的思路，给一件高度重复、强依赖个人记忆、又容易翻车的事兜住底。
- 先把资产库建起来，八个目录各管一类。
- 三条自动化流水线：
interview-prep出面试包，interview-highlight-doc把代码读成亮点，textbook-stage-gen系统补课。 - 一张记录表当看板，一篇日记当站会和复盘，几条规矩当质量门禁。
找工作这件事不确定性本来就多，面试能不能过有太多我控制不了的因素。但手里的资产有多厚、上场前准备得有多扎实，是可以靠把它当个项目做，牢牢抓在手里的。