秋招求职作品集 · 招聘 / AI+HR 方向
龙翔翔
招聘 × AI × 产品
“从真实招聘场景出发，把 HR 问题转化为可运行的 AI 产品。”
3个线上站点
4个产品端
335项插件自动化测试通过
10人团队规模设计
招聘 × AI × 产品
“从真实招聘场景出发，把 HR 问题转化为可运行的 AI 产品。”
ABOUT
“我不是从技术出发做 HR 工具，而是从真实 HR 工作出发，寻找 AI 的应用方式。”
THE REAL SCENE
“我能不能把这个招聘流程真正数字化？”
WHAT I BUILT
HireFlow 不是“一个 App”，而是覆盖招聘全流程的团队工作系统。
HR 的日常工作站：候选人管理、OCR 扫描、跟进提醒、团队看板、离线可用。
手机 + 电脑双端网页，苹果手机也能用，无需安装。
在 BOSS / 猎聘 / Moka 候选人页面一键采集，自动去重后导入云端。
团队总览、招聘漏斗、成员效率、风险提醒、反馈与审计。
ARCHITECTURE
核心设计：一套云端数据，多端协同。云端是唯一事实来源，本地 SQLite 保证离线可用。
CASE STUDY 01 · 浏览器采集插件
HR 每天在 BOSS / 猎聘 浏览几十位候选人，信息靠逐字段复制粘贴，一次几分钟，慢且易错。
“扫描整页文字”会把当前登录 HR 自己的姓名、按钮文字、左侧候选人列表一并抓进来 —— 插件常常把 HR 自己识别成候选人。
真实页面识别准确率仍待人工回归验证（待验证）——自动化测试通过不代表线上 100%。
CASE STUDY 02 · Android APK
面试现场、地铁、展厅、没有信号的地下室 —— HR 的录入需求恰恰发生在这种地方。如果系统必须联网才能用，它就“用不起来”。
首页 · 团队看板
候选人 · 状态
OCR 扫描简历CASE STUDY 03 · 管理员驾驶舱
管理者想了解招聘进度，只能逐个问成员：“这周新增了几个？谁在面试？Offer 发出去了吗？”信息滞后、口径不一。
AI CAPABILITY
招聘流程里哪些能力真正属于 AI，哪些只是规则与 OCR —— 我做了明确分层。
如实说明：AI 兜底 Edge Function 已完成开发，当前默认关闭（AI_ENABLED=false），部署函数并配置密钥后开启 —— 状态：待部署启用（待验证）。
THE HARD PROBLEMS
这三件事决定了 HireFlow 能否在真实场景里“用得住”。
页面同时存在候选人、聊天对象和当前登录 HR 的姓名，整页抓取把“龙翔翔”识别成了候选人。
没有“候选人上下文”，所有文字一视同仁。
必须先定位“HR 当前打开的候选人”，再提取字段。
Resume-First 锁定当前简历 / 实体分类 / 当前用户排除 / 多候选人点选。
自动化 335/335 通过；“江先生”不再被识别成“龙翔翔”。
面试现场、地铁里没有网络，纯云端 App 直接不可用。
所有读写都依赖网络请求。
HR 的核心操作必须本地优先，云端负责同步与统一。
SQLite 即时落盘 → 同步队列 → 网络恢复自动上传 → 失败指数退避重试。
断网可增改查，恢复网络数据不丢、自动同步。
10 人团队、4 个端同时使用，数据不一致或串号就是事故。
多端各自存一份、权限只靠界面隐藏。
云端必须是唯一事实来源，权限必须在数据库层拦住。
organization_id 数据隔离 + Supabase RLS；状态历史与操作日志留痕；最后有效修改覆盖当前值。
成员只能看本团队数据、改自己负责的候选人；管理员看全量；绕过界面也读不到他人数据。
ENGINEERING & DELIVERY
以上数据均来自真实项目（线上站点实测在线、自动化测试实际运行、云端数据库可核验）。未验证环节已在文中标注。
MY ROLE
“AI 辅助开发 ≠ AI 替我完成项目。需求判断、产品决策、架构设计、调试、测试、验证、迭代 —— 每一项我都全程参与并负责。”