
我们如何用 AI 原生工作流重构简历筛选
我们并行运行 125 个 AI 智能体,依据统一的评分标准筛选 115 位候选人,仅花费 $65 就生成了一份经过排名、给出理由且完全可审计的入围名单。
本文记录的是一个小实验:我们把 Notion 招聘数据库接入 Claude Code,运行了一套动态工作流,并行调度 100 多个 AI 智能体去阅读简历、按统一的评分标准给候选人打分,并相互交叉核验彼此的判断——最终产出一份可以立即据以行动的排名候选名单。
整件事花了 $65,在大约 13 分钟内跑完了 115 位候选人。但比成本更有意思的,是它暴露出的一系列方法论问题——什么时候该动用一支智能体队伍而非单个智能体、如何防止 AI 评分虚高,以及把"优秀"编码成机器真正能执行的东西到底意味着什么。
1. 什么是动态工作流
我们先从概念讲起,因为后面的一切都建立在它之上。
如今大多数 AI 用法遵循的是一问一答的模式:发一条消息、得到一个回答、再迭代。这对一次性任务很好用,但当你需要对 115 个对象做同一件事时就会很别扭——你要么复制粘贴 115 次,要么让单个会话依次处理它们,而这个过程会越往后越慢、越往后越嘈杂。
**动态工作流是另一种范式:用代码来编排一支 AI 智能体队伍。**它的核心特征是:
- **确定性的控制流 + AI 的判断,二者分离。**循环、调度、聚合、配额执行由代码负责(可复现、可审计);主观判断(这份简历够不够强?)则交给 AI 智能体。
- **扇出并行。**单个
parallel(...)调用就能同时启动数十甚至上百个相互独立的智能体,每个智能体处理自己的那一份,互不污染。 - **多阶段流水线。**一个阶段的输出喂给下一个阶段。阶段之间的过滤、排序、去重由代码完成。
- **结构化输出。**每个智能体返回符合 schema 的 JSON,而不是自由格式的聊天文本,因此下游代码可以直接消费。
打个比方:单个会话就像请一位专家咨询一下午。而动态工作流就像组建一个 125 人的评审团,给每位成员发一份评分标准和一份候选人材料,让所有评审并行进行,对靠前的结果做交叉核验,再聚合成一份排名清单——而组建、调度、聚合的逻辑都内嵌在脚本里。
简历筛选天然契合这种范式:高量级、统一标准、主观判断、公平性要求。
更深入的技术介绍见:A harness for every task: dynamic workflows in Claude Code
2. 招聘工作流:目标与设计
问题
我们有一个具体的痛点:有一百多位候选人卡在 Notion 招聘数据库的"初筛"状态里,靠人工根本没法在不标准漂移的情况下处理完——你审到第 80 份简历时所用的尺子,几乎从来不会和审第 5 份时一样。
我想验证的是一个很具体的想法:我们能不能把"AI 智能体时代里优秀长什么样"抽象成一份机器可执行、人类可读的评分标准,然后让全部 115 位候选人在同一套校准下跑一遍?
目标明确不是让 AI 来做录用决定。目标是:
- 把 115 位候选人压缩成一份有排名、有论据的候选名单,让人的注意力投向真正值得关注的人。
- 让标准透明且可迭代——如果结果不对,你改的是一个 Markdown 文件,而不是代码或直觉。
三个关键设计决策
决策 1:标准与代码彻底分离
评估标准放在独立的 Markdown 文件里(criteria/),不嵌进工作流代码。任何人——包括非技术的同事——都可以通过编辑这些文件来改变筛选行为:
criteria/
├── 00-philosophy.md 总体理念:我们到底在招什么样的人 + "抬高标准"规则
├── 01-pedigree.md 扎实的学术 / 早期基础 (权重 20%)
├── 02-ai-agent-fluency.md AI 原生能力 (权重 35%)
├── 03-grit-problem-solving.md 解决问题与克服困难 (权重 30%)
├── 04-talent-lens.md 顶尖人才信号 (权重 15%)
└── scoring.md 评分公式 + 等级分段 + 5% 配额规则这四个维度就是我们的**"AI 智能体时代优秀标准 v0.1"**。每个维度背后的考量是:
- **AI 原生能力权重最高(35%)。**在 2026 年,一个人是否把 Claude Code 这类智能体工具真正当作工作方式的核心组成部分,是一道重要的生产力分水岭。我们专门对堆砌关键词的行为扣分——只列出"Claude Code"却拿不出可验证的项目证据,会被当作弱信号。
- **解决问题的硬证据(30%)。**我们寻找的是"伤疤组织":从零独立做出来的东西、克服真实障碍的叙述——而不是教程级别的照搬复刻。
- **扎实的基础(20%)。**学术背景作为原始潜力的代理指标——它是一个信号,而非硬性要求。名校学历配上平庸的产出会被扣分;没有名校光环、但有真实落地成果的自学型实干者则会被加分。
- **顶尖人才信号(15%)。**这个维度是刻意主观的。提示词会问:像 Anthropic 这样的团队,或者像 Musk 这样的创始人,会不会立刻想要主动联系这个人?它捕捉的是另外三个维度抓不到的那种主动性、品味和速度。
决策 2:把"抬高标准"编码成硬约束,而不是口号
scoring.md 里有一条硬规则:进入最高档(S)的候选人必须 ≤ 全体池子的 5%。所有打分完成后,代码会施加一个全局上限:即便很多候选人在技术上落在 S 区间,也只允许排名前 5% 通过。这直接对抗一个已知的失败模式——AI 打分天生宽松。没有硬约束,它会把池子里一半的人都评为"优秀"。
决策 3:加入对抗式复审,揪出虚高的分数
光打分还不够。单个打分智能体可能被听起来很唬人的关键词带着走——"发表在顶级期刊""自己造了个框架"。所以排名靠前的候选人要再过一轮:由一支**"魔鬼代言人"智能体组成的评审团,它们明确的任务就是为"这个人配得上顶级评级"唱反调**,并在证据不足以支撑的地方把分数往下压。
工作流
准备 📋 Notion 招聘数据库 —— Notion CLI 拉取 → 每位候选人生成一份结构化数据文件
AI阶段 1:打分(115 个智能体并行)
- 阅读 6 个标准 MD 文件 + 该候选人的数据文件
- 主动访问 GitHub / 作品集链接以核验证据
- 输出结构化 JSON:4 维度分数 + 理由 + 亮点 + 风险标记
Code确定性综合
- 计算加权总分
- 全局排名排序,计算 5% 配额名额
- 选出排名靠前的候选人进入对抗式复审队列
AI阶段 2:对抗式复审(智能体并行)
- "魔鬼代言人"人设复审每位头部候选人
- 为顶级评级唱反调
- 在证据不足处把分数往下压
Code确定性裁决
- 用校准后的分数重新排序
- 执行 5% 硬上限
- 给出最终等级分段:S / A / B / C / D
输出:排名报告 结构化 Markdown,含每位候选人的分数、理由和对抗式复审裁决
**蓝色阶段(打分 / 复审)是 AI。灰色阶段(综合 / 裁决)是代码。**这种切分是刻意的:凡是涉及数学的——加权、排序、配额执行——都交给代码以保证可复现;凡是需要判断的——这个人够不够强?——都交给 AI。
3. 我们看到了什么:结果与洞察
下文所有候选人均已匿名。我们描述的是工作的类型,而非姓名或可识别细节。
我们跑了什么
| 指标 | 数值 |
|---|---|
| 候选人 | 115(Agent Researcher / Agent Engineer / Growth 岗位) |
| 智能体总数 | 125(115 个打分 + 10 个对抗式复审) |
| 运行时长 | ~13 分钟(并发上限 ~14,分 8 波完成) |
分布
| 等级 | 数量 |
|---|---|
| S — 卓越 | 0 |
| A — 强 | 0 |
| B — 合格 | 6 |
| C — 一般 | 26 |
| D — 不推荐 | 83 |
5% 配额(5 个名额)完全没用上——挡住任何人的不是配额,而是绝对分数门槛。没有人靠自己越过 A 档的底线。至于为什么这其实是个有用的信号,下文再说。
排名头部长什么样(已匿名)
无一例外,排名最高的候选人都是那些真正动手做过智能体的人——而不是那些只是听说过 AI 的人:
- **第 1 名:**一位研究生,从零搭出了一个 Claude-Code 风格的多智能体工作台——包括智能体主循环、工具调用解析、上下文压缩、子智能体派生和安全闸门。全是可验证的代码,而非文字描述。
- **第 2 名:**另一位研究生,部署了一套真实、可公开访问的多智能体系统(垂直领域应用),上面还叠加了学术产出。
- 再往下:有人用 Go 从零写了一个智能体编排引擎;有人通过研究 Claude Code 的架构做出了一个轻量级编码智能体;有人在七天里用本地 LLM、全程借助 AI 工具独立做出了一款游戏。
他们的共同点是:他们的强信号几乎从不出现在简历正文里——而是藏在 GitHub 仓库和作品集里。这正是为什么每个打分智能体都被要求主动访问链接、核验证据,而不是只读简历文字。
三个洞察
洞察 1:对抗式复审确实揪出了虚高的分数
最清楚的例子是排名前两位的候选人。打分阶段之后,两人的加权总分都在 82 分左右——足以挤进 A 档并蹭到 S 门槛。经过对抗式复审,两人都落到了 75 分左右,理由非常具体:
"搭出了一个可验证的多智能体工作台——AI 原生能力是硬信号。但项目大约只有 3 周大、单人贡献、0 star、无测试。从概念上看是一次重新实现,而非原创的问题解决。除了学历那一行,几乎没有其它支撑证据:是一个扎实的高潜候选人,但谈不上卓越。"
"一个货真价实、可验证的 AI 原生实干者。但所声称的顶级期刊发表只出现在招聘方的备注里,没有可独立验证的来源。核心系统后端是私有的,无法确认其个人贡献。用未经核实的学术资历去够顶级档,属于关键词驱动的分数虚高。"
这正是设计要达到的效果:**它没有否定这些候选人——而是把分数拉回到证据真正能支撑的水平。**单个打分智能体可能会上头;而一支专门负责反驳的独立智能体队伍能可靠地把这种虚高挤掉。
洞察 2:S:0 / A:0 不是 bug,而是一面镜子
第一反应是去问:是不是标准定错了?但诚实地看一看这个池子:
- 很大一部分候选人简历极其稀薄——关键维度(AI 经验、可验证的成果)干脆缺失。
- 许多申请 Agent Engineer 岗位的人完全没有使用智能体工具的证据,也没有 GitHub 链接。
- 池子里甚至还混进了招聘方的商务邮箱和 LinkedIn 系统通知——它们被正确地识别为无关并打了 0 分,这顺带暴露出我们的招聘数据库该清理了。
换句话说,**一份严格的评分标准干净利落地把信号从噪声里分了出来。**真正的实干者(头部 6 位)和"全面而有成就的通才"(中间档)最终落在了明显不同的位置。这正是重点所在——宁可漏掉几个,也不要把所有人都捧高。
这也带出一个值得讨论的开放问题:对那些 GitHub 记录很强、但尚无职业履历的学生候选人来说,当前的 A 档门槛(78 分)是不是太苛刻了?有意思的是,对抗式复审的智能体自己也把前两名形容为"高潜候选人"——但加权分数还是把他们留在了 B 档。**要不要为高潜的早期职业候选人放宽这个门槛,是一个判断题,最好等我们看到 B 组的实际面试质量后再来定夺。**好消息是:这个改动只是某个 Markdown 文件里的一个数字。无需改代码。
洞察 3:"标准即代码"让分歧变得富有成效
关于招聘标准的讨论通常停留在模糊层面——"我们想要有冲劲的人""能自己把事情搞定的人"。因为这份评分标准是带着权重和锚定示例写下来的,讨论立刻变得具体:"AI 能力该占 35% 还是 40%?""一个没有名校学历的异类实干者到底能加多少分?""配额该是 5% 还是 8%?"——**每一处分歧都对应着 Markdown 文件里某一具体行,可以被修改、被版本管理、被辩论。**标准于是成了一项你持续维护的资产,而不是每次开会都要重复一遍的共识。
4. 成本与 ROI
精确花费
我们用的是 Claude Opus 4.8(最高档)。按 token 类别的精确拆分:
| 类别 | Tokens | 单价 / M | 小计 |
|---|---|---|---|
| 输入(缓存未命中) | 2,306,691 | $5.00 | $11.53 |
| 缓存写入 | 6,536,462 | $6.25 | $40.85 |
| 缓存读取 | 12,806,404 | $0.50 | $6.40 |
| 输出 | 248,312 | $25.00 | $6.21 |
| 合计 | ~$65 |
折算下来大约是每位候选人 $0.57。
一个反直觉的发现:缓存写入才是最大头
很自然的假设是:既然 115 个智能体都在读同样的那 6 个标准文件,提示词缓存应该帮上大忙。但它并没有,至少不是你以为的那种方式。
提示词缓存依赖于精确的前缀匹配,而每个智能体会话都是独立的。125 个智能体意味着 125 个独立会话——每个会话的任务描述都不同(不同的候选人数据)——所以智能体 A 写入的缓存无法被智能体 B 命中。缓存确实能在每个智能体自身的多轮执行里帮上忙(读标准 → 访问 GitHub → 访问作品集 → 输出,每一轮都会重新读取前面的内容)。
这揭示了一个架构上的权衡:扇出并行会成倍放大缓存写入的成本(每个智能体都构建自己的缓存),但换来的是相互隔离、互不污染的判断,并消除了串行处理时上下文的二次方累积。对于判断质量敏感的任务来说,这笔权衡是划算的。
怎么看待 ROI
直接和人工审阅比一比:一位招聘负责人认真读一份简历、查一下 GitHub、再写点笔记——保守估计每位候选人 5 到 10 分钟。115 位下来就是 10 到 19 小时的专注工作,而且标准会一路漂移。
这套工作流交付了:
| 项目 | 表现 |
|---|---|
| 成本 | 每位候选人 $0.57,约 13 分钟产出完整排名 |
| 深度 | 每位候选人的四维度分数、书面理由、风险标记和对抗式复审裁决 |
| 一致性 | 第 1 位候选人和第 115 位候选人按完全相同的评分标准评估 |
| 可审计性 | 每一个名次都有完整的推理链 |
但更重要的 ROI 在于注意力:它把人的关注从 83 位明显不合适的候选人那里抽走,转向头部那 6 位真正的实干者。这正是初筛能做的最高价值的事。
还能更便宜吗?
能,但大概没必要。如果这变成一项高频、大量级的操作(每天数百位候选人),实用的优化方向会是:
- 打分阶段用 Sonnet,只在对抗式复审用 Opus——很可能在质量几乎不损失的情况下削减 70% 到 80% 的成本。
- 或者先用更便宜的模型做一遍粗筛,再用 Opus 对头部档做详细评估。
但招聘本身低频、高风险、难以撤销。花 $65 跑完整条流水线,同时拥有完整的可审计性和可迭代的标准,结论很清楚:用最好的模型。不要拿判断质量去换那点边际成本的节省。
更大的图景
这个实验真正让人兴奋的地方,并不是"AI 能筛简历"——那并不是个新想法。而是动态工作流这一范式——用代码编排一支 AI 智能体队伍——第一次让某些类别的工作变得可结构化、可复现、可迭代。
招聘只是一个切入点。同样的范式——标准即可读文件 + 扇出并行评估 + 对抗式复审 + 确定性聚合——可以迁移到任何需要做出一致、大量级主观判断的领域:内容审核、代码评审、用户反馈分诊、竞品分析、尽职调查。
这份评分标准还是 v0.1,并不完美。但它如今已是一项可版本管理、可辩论、可改进的资产——而不再是一份藏在某人脑子里的隐性约定。比起任何单一的结果,正是这种转变,才是这个实验真正关乎的东西。

