招聘方友好功能：先调研招聘方真实行为，再决定做什么

目标

站主原话：

我想要设计一点功能，能方便 hr 用？你觉得有啥功能？方便他们统计或者收集信息，什么的，主要是我不了解，你去调研一下。

需求是真实的，但「方便 HR 收集信息」这句话里藏着一个会踩坑的歧义，所以没有直接动手，先调研。

关键 prompt（原文摘录）

你用 agent 去做 …… 主要是我不了解，你去调研一下

落地阶段的拍板很干脆：

都做一下

结果

先用一个 6-agent 工作流并行调研了五个角度（招聘方真实行为 / 帮 HR 省事的功能 / 留资与分析的隐私合规 / 中国招聘语境 / 对话式 AI 初筛趋势）→ 综合成带优先级 + 隐私注释的功能清单。几条调研事实直接决定了设计：

• 简历初筛眼动实测 7.4 秒、审作品集 80% 用时不到 3 分钟——所以做了常驻首屏、爬虫可读的「招聘速览」事实条（岗位/学历/base/到岗），不让硬条件被埋进发布会叙事里。
• 嵌 live 作品集链接的候选人正向初筛响应少 37%（点外链=打断扫描）——这个站本身就是那个外链，更要第一屏自证。
• 29% 的作品集偷跑第三方分析，对安全意识强的工程团队是减分项——于是把「零追踪」做成展品（/privacy + 页脚徽章），而不是去加分析。

落地的六个功能，全部贴合零数据库 / 诚实调性：

1. 首屏「招聘速览」事实条（静态、content 驱动）。
2. AI 分身的建议问题改成 HR 初筛漏斗：介绍 → 到岗 → 远程 → 差异化 → 挑个项目讲踩坑 → 联系。
3. 一键复制：邮箱 / 候选人摘要纯文本块（直接粘进 ATS 或微信转发同事）。
4. 聊天对话导出为 Markdown 纪要（纯客户端，带候选人摘要头）。
5. .vcf 电子名片 + 站点二维码（构建期一次性生成的静态产物，零运行时依赖；名片只放公开字段，不含手机号）。
6. 零追踪隐私页：用人话讲清「唯一发出去的是你主动问 AI 分身的内容、会推给站主以便回复，且不反查你是谁」，一次性满足 PIPL 告知义务。

踩坑与纠正

最该记的不是技术坑，是一个差点做错的产品决策。 「方便 HR 收集信息」最自然的实现是「我来收集 HR 的信息」——访客分析、IP 反查公司、记录谁来过。调研明确这条在 PIPL/GDPR 下要单独同意，且和本站「诚实 / 隐私克制」的人设正面冲突，对工程团队还是减分项。所以方向被纠正成：帮 HR 把候选人信息一键带走（下载 / 复制 / 名片 / 导出），以及只升级既有的飞书「你问了什么」推送，绝不滑向「记录你是谁」。把「不追踪」本身做成卖点，比偷偷追踪高级。

客户端 JS 白名单第四类。 「一键复制」必须用 Clipboard API，碰了「客户端 JS 只允许聊天岛+导航高亮+发布会引擎」的铁律。按纪律没有偷偷加，而是把 copy-button.tsx 显式写进 CLAUDE.md 白名单并在此论证：招聘方实用、纯本地、不追踪。对话导出复用聊天岛既有客户端边界，不算新增。

二维码的零依赖取舍。 不想为一个二维码引 npm 包或运行时外部服务，最终一次性生成 PNG 提交进 public/——既不破「不加依赖」，也不在构建期引入会失败的外部调用（这是从 OG 图那次构建期 Google Fonts 取字体的经验回退一步：能离线一次性产出的静态资产，就别放进构建期网络依赖）。

用时与备注

约 1.5 小时。调研那 10 分钟是关键——它把一个「听起来要做追踪」的需求，纠正成了一批既帮招聘方又守住隐私底线的功能。方向由站主拍板（「都做一下」），调研结论与隐私红线判断、实现与验证由 AI 完成。