历时 3 个月，我从 0 上线了一个证据约束型 AI 求职助手：简喵
项目名：简喵 在线体验地址：jianmiao.yanxai.com 个人技术博客：yanxai.com GitHub仓库Readme: RyanCoreAI/AIResume
简喵不是泛简历生成器，而是一个证据约束型 AI 求职助手，围绕真实简历和目标 JD，帮助用户完成简历编辑、目标岗位分析、岗位竞争力诊断、投递文案生成和 PDF 导出。
桌面端截图：
移动端截图：
1.为什么做这个项目
这得从我第一次写简历开始，我自己用Office、WPS试过效果不太好，也用过网上的免费写简历产品，当时花了不少时间找个好模板填写我的简历然后最后一步导出的时候居然提示我要充钱，我换过其它的简历产品，结果不是付费就是导出的时候加上了水印，当时就给我气炸了。说好的免费简历，我花了这么多时间选择模板填写简历结果卡在我导出的时候说要付费，这不是付费的问题是严重伤害了用户的信任。当时我就在想要是我有能力做出来一个免费的简历产品给自己用和身边的朋友用就好了，这就埋下了一个种子，在我现在有能力后终于实现第一次写简历那时候一直想做却没有能力做的事。我自己明确知道什么事情最伤害用户信任，我是在为像以前一样被伤害过用户信任和无数个我而付费，是为爱发电的项目，如果我的项目能帮助到哪怕只有一两个人，这也是我做这个项目的意义。
其次是项目层面，我最开始只是想做一个“不在最后一步卡 PDF 导出”的简历工具，但是我发现做了一个泛泛的简历生成器和PDF导出那也没有价值，市面上到处都是。我发现大多数人真正困难的地方是不是没有经历，而是不知道怎么把已有经历翻译成岗位语言。又还有就是现在大多数的简历工具是一个简历评分器等或者直接帮用户“润色”成看起来很强的表达，但用户不一定知道这句话有没有依据，甚至用户在面试的时候被面试官问穿，这是个很严重的问题。 简喵想解决的不是“把简历写得更夸张”，而是帮助用户分清楚：
- 哪些内容可以直接写；
- 哪些内容需要补证据；
- 哪些 JD 要求暂时不能硬写；
- 哪些表达可以保守降级；
- 最终投递前应该怎么整理。 这也是我把它叫做 证据约束型 AI 求职助手 的原因。
相关竞品也已经很强，而简喵解决的问题就是：从真实经历到目标岗位之间，缺一个证据约束的整理过程。
2.简喵的目标岗位分析和岗位竞争力诊断有什么用？
我现在拿一份示例简历进行项目真实验证：
岗位填写：AI应用开发 （JD粘贴见文章末尾部分）
目标岗位分析结果如下：
目标岗位分析结果只有59分评分，结果显示这份简历缺少Agent 工作流 / RAG / Embedding / 向量检索等相关的证据，然后防幻觉 / 证据链能力未在简历中显性表达， 可以主打LLM API / Prompt / JSONMySQL / Redis权限安全。 应该重写表达：Docker / Nginx / 云部署Java / Spring Boot / REST APIToken 消耗统计防幻觉 / 证据链 / AI 质量控制。 需要补真实项目 / 补口径：Agent 工作流RAG / Embedding / 向量检索。 不能直接硬写：Agent 工作流RAG / Embedding / 向量检索。 当前简历已有 AI 工程化相邻证据，但还没把证据约束、风险降级、质量控制写成主线。 优先改写项目表达，突出结构化输出校验、证据约束和风险降级。 还给出了7天补强计划：
- 第 1 天：选一个小型知识库场景，整理 5-10 篇 Markdown / PDF 文档。
- 第 2-3 天：实现文档解析、文本切分和 Embedding 入库，优先用 pgvector / Milvus 其中一种。
- 第 4-5 天：完成相似度检索、召回排序、上下文拼接和引用来源展示。
- 第 6 天：补充防幻觉边界，包括无证据拒答、引用缺失提示和日志记录。
- 第 7 天：整理 README、架构图和可演示截图，再决定是否写入简历。
- 本周优先补 RAG；Agent 工作流作为下一阶段补强，不建议同周同时做，避免 Demo 过散。
这么看59分也算合理.....
岗位竞争力诊断结果：
这里看到一个点它提出了一个风险点就是简历写了将单次模型评分成本控制在约 ¥0.012 - ¥0.02，有面试追问风险：你这个成本是怎么算出来的？ 说明这是基于模型单价和典型评分请求长度估算的单次成本区间，不是营收指标；没有完整口径时不保留具体金额。数字越具体，越容易被追问 token 单价、输入输出长度、缓存命中和估算公式。其次，这份诊断还根据简历的项目提出了面试追问的风险点。
3.投递文案是什么？PDF导出真实能用吗？
先看一下投递文案的质量：
这里有一个很重要的点就是它确实真实依据岗位要求和现有的简历证据给出一个尽可能表达符合岗位要求的投递文案，不会编造不存在的事实。这个投递文案可以当作一个参考，真实投递还得微调不能盲目复制。
再来从WPS Office看看PDF导出的质量：
4.分享链接是什么？有什么用？
分享链接就是将这份编辑好的简历用短链接的形式发送出去可以让别人预览你的简历，支持微信、QQ等多平台发送，可以手动设置密码和过期时间，现在我当场设置一个短链接有效期30天（8月1日过期）： https://jianmiao.yanxai.com/s/97d7411c687d4351bbf2
点击短链接效果：
这里的PDF导出是浏览器导出,效果不好不建议在这个页面导出正式PDF
分享链接还可以统计链接的数据：
5.AI调用怎么计算？执行时遇到网络问题会不会直接扣除体验次数？
在我的AI额度这个位置有记录历史的AI调用历史，如果AI任中断没有完整生成会退回点数，只有任务完成才会扣除响应的点数，点数的意义是为了保护AI接口防烂刷。
除以上功能外还有其它投递跟进、项目复盘、offer对比等功能不再展示，可以点击项目链接真实体验。
6.如何注册登录？支持Github登录吗？
用邮箱注册登录即可，注册成功过后你会收到邮件：
或者使用Github进行登录
7.简喵为什么强调“证据约束”
因为 AI 简历产品有一个很大的风险： 生成得越流畅，越容易让用户误以为它是对的。 尤其是求职场景，AI 很容易把 JD 要求包装成用户经历。 这会带来两个问题。 第一，用户投出去的简历可能失真。 第二，面试官一追问就穿。
所以简喵在设计上坚持几个规则：
- JD 是岗位要求，不是候选人事实；
- 简历是候选人事实来源；
- 没有证据的内容只能标为缺口或建议；
- AI 可以帮你组织表达，但不能替你编经历；
- 投递前必须由用户确认。 这也是我觉得简喵和普通“AI 优化简历”最大的区别。
8.这个项目做了什么防护？我的简历信息是否会泄露？
简喵当前的安全设计核心是：用户简历默认私有、账号内隔离；富文本和 AI 输出进入系统前后都做净化；分享和 PDF 使用受控 token；AI 调用、PDF 渲染、文件上传这些高风险链路都有边界控制。
（1）简历富文本XSS攻击防护
| 层级 | 防护 |
|---|---|
| 前端 | 使用 DOMPurify 净化富文本 |
| 后端 | 使用 ResumeContentSanitizer 再次净化 |
| 落库前 | 草稿、版本、分享快照、AI 改写内容都会经过服务端 sanitizer |
| 渲染前 | 简历模板、预览页、分享页只渲染净化后的 HTML |
| 浏览器侧 | CSP 限制脚本来源，禁止 object/frame 等危险能力 |
(2) 越权访问防护
| 资源 | 防护方式 |
|---|---|
| 简历 | 按 userId + resumeId 查询 |
| 简历版本 | 校验版本所属简历，简历所属当前用户 |
| 岗位会话 | 校验 session 属于当前用户 |
| 体检结果 | 绑定用户、简历版本、岗位会话 |
| PDF 任务 | 校验 task / version / user 关系 |
| 分享撤销 | 只有创建者可以撤销 |
| 投递/面试/Offer | 按当前用户隔离 |
（3）登录态 / CORS / CSRF / Cookie防护
| 项目 | 当前设计 |
|---|---|
| 登录态 | JWT 放 HttpOnly Cookie |
| 防 JS 窃取 | AccessToken / RefreshToken 设置 HttpOnly |
| HTTPS | 生产要求 Secure Cookie |
| CSRF | 双提交 token，XSRF-TOKEN 可被前端读取但不承载登录态 |
| CORS | 生产只应允许正式域名 |
| Nginx | API no-store，减少缓存用户接口响应风险 |
（4）头像上传防护
| 防护 | 说明 |
|---|---|
| 大小限制 | 头像限制 500KB |
| magic bytes | 不只信任 Content-Type |
| 重新编码 | 服务端重新编码为 JPG，去掉潜在脚本/EXIF |
| 随机文件名 | 使用 UUID，不使用用户原始文件名 |
| 独立路径 | 只暴露 /files/avatars/** |
| 不接收 SVG | SVG 这类可执行载荷应拒绝 |
（5）文件导入防护
| 防护 | 说明 |
|---|---|
| 文件大小限制 | 限制 5MB |
| 类型检查 | PDF / DOC / DOCX / TXT |
| magic bytes | 检查真实文件头 |
| DOCX 解压检查 | 防 zip slip |
| 可疑条目过滤 | 避免路径穿越和异常文件结构 |
（6）PDF导出、Puppeteer防护
| 防护 | 说明 |
|---|---|
| 不允许用户提交任意 URL | URL 由后端构造 |
| host 白名单 | Puppeteer 只访问允许的 host |
| 阻断危险协议 | 阻断 file、ws、ftp 等 |
| 阻断 metadata IP | 阻断 169.254.169.254 等 |
| 容器隔离 | Puppeteer 独立服务 |
| 任务校验 | PDF task 与用户/版本绑定 |
（7）分享链接防护
| 防护 | 说明 |
|---|---|
| 长随机 token | 后端真实 token 足够长 |
| 短链接只是展示 | 前端展示短 token，后端仍可保留长 token |
| 密码分享 | 可选密码保护 |
| 访问限流 | token + IP 限制 |
| 撤销分享 | 创建者可以撤销 |
| 快照净化 | 分享内容创建前经过 sanitizer |
| no-store | 密码分享不应被缓存 |
（8）AI调用防护
| 防护 | 说明 |
|---|---|
| 功能限流 | 额度、每日/月度限制 |
| 任务队列 | 避免重复创建相同 AI 任务 |
| 输出校验 | JSON 修复、schema、fallback |
| 证据边界 | JD 是岗位要求，不是候选人事实 |
| AI 输出净化 | 进入简历/页面/PDF 前走 sanitizer |
| 缓存隔离 | cache key 应包含 user/session/version/scenario |
| 审计日志 | 记录 trace、状态、失败原因 |
| 部分脱敏 | 对手机号、邮箱等敏感字段做处理 |
（9）Nginx / 浏览器侧防护
| 防护 | 说明 |
|---|---|
| CSP | 限制脚本、对象、frame、连接域名 |
| HSTS | 强制 HTTPS |
| X-Frame-Options | 防点击劫持 |
| API no-store | 防止用户接口被代理缓存 |
| assets 长缓存 | 只缓存静态构建产物 |
| connect-src 白名单 | 只允许必要 API/AI 域名 |
（10）简历自动保存防护
| 场景 | 是否会被其他普通用户看到 | 是否会离开你自己的服务器 | 说明 |
|---|---|---|---|
| 保存草稿/版本 | 默认不会 | 不会，除非备份/运维访问 | 存在数据库和服务器信任边界 |
| 简历预览 | 默认不会 | 不会 | 登录态内访问 |
| PDF 导出 | 默认不会 | 不会发第三方，但会进入 Puppeteer 内部服务 | PDF 文件需要清理和权限控制 |
| AI 诊断/体检/投递文案 | 默认不会公开 | 提交前过滤敏感字段仅必要字段进入AI调用链路 | 隐私说明已中明示 |
| 分享链接 | 持链者可看 | 不一定 | 用户主动分享，风险来自链接转发 |
| 头像 | 头像 URL 可公开访问 | 不一定 | 不应上传敏感图片 |
| GitHub 登录 | 不会公开简历 | 会走 GitHub OAuth | 用于登录身份，不等于公开简历 |
说明： 简喵默认不会公开你的简历。你的简历草稿、版本、岗位诊断、体检结果和 PDF 导出记录均绑定当前账号访问。 为了防止脚本注入，系统会在前端和后端同时净化简历富文本内容；为了防止越权访问，核心资源接口会校验当前用户与简历、版本、岗位会话、导出任务之间的归属关系。 当使用目标岗位分析、岗位竞争力诊断或岗位投递文案功能时，系统会将完成该功能所需的简历片段和 JD 内容发送给模型服务进行处理。AI 结果只作为建议，不代表录用概率，也不会自动替你写入无证据经历。 当主动创建分享链接时，持有链接的人可以访问对应分享快照。请不要在分享版本中保留不希望公开的信息。头像会作为公开头像资源展示，请不要上传身份证、证件照、银行卡截图等敏感图片。 简喵会对上传、分享、AI 调用、PDF 导出等高风险入口进行限流、校验、日志审计和错误兜底，但任何线上系统都不存在绝对零风险。建议不要在简历中填写非求职必要的敏感信息。
9.PDF导出并发怎么处理？服务器能承受压力吗
（1）异步 PDF 队列
用户点“导出 PDF”后，后端不是同步卡住请求直接渲染，而是创建一个 pdf_export 异步任务。
流程是：
▼text复制代码用户点击导出 → 后端校验用户是否拥有这份简历和版本 → 创建 pdf_export 任务 → 写入数据库 async_tasks → 推入 Redis 队列 → 后台 worker 取任务 → 调 Puppeteer 服务生成 PDF → 保存 PDF 文件 → 前端轮询任务状态并下载
（2）用户/IP 限流
PDF 导出入口有多层限流，防止一个用户或一个 IP 疯狂点导出。
▼text复制代码防止一个账号连续狂点 防止同一设备/同一出口刷接口 防止短时间批量消耗资源 防止免费用户长期滥用
（3）Puppeteer 白名单隔离
PDF 导出最危险的地方不是“生成 PDF”，而是“让一个无头浏览器访问 URL”。如果不限制，攻击者可能尝试让 Puppeteer 访问：
▼text复制代码云服务器 metadata 地址 内网服务 本地文件 file:// Redis/MySQL 内网地址 任意外部 URL 恶意 HTML 页面
当前项目做了两层白名单。
第一层在后端 PuppeteerClient：
后端只允许自己构造的预览 URL，要求满足：
▼text复制代码必须和 app.base-url 或 pdf-preview-base-url 同源 路径必须以 /preview/ 开头 必须带 token 必须带 versionId
也就是说，用户不能提交一个任意 URL 让服务器帮他转 PDF。
第二层在 puppeteer-service：
Node 服务也会检查：
▼text复制代码只允许 http/https 拒绝 metadata IP，例如 169.254.169.254、100.100.100.200 host 必须在 ALLOWED_HOSTS localhost 端口必须在允许列表 非白名单资源请求会被 request interception 拦截
部署上还有容器隔离：
▼text复制代码Puppeteer 不暴露公网端口 Docker Compose ports: [] read_only: true /tmp 使用 tmpfs 容器资源有限制
所以它不是“浏览器随便打开网页”，而是“只能打开内部预览页，并且页面里的外链资源也受控”。
（4）失败兜底
PDF 生成链路很复杂，可能失败的点很多：
▼text复制代码预览 token 过期 versionId 不存在 Puppeteer 无法访问 preview URL 页面分页溢出 Chromium 超时 服务器内存/CPU 繁忙 队列已满 生成结果不是有效 PDF
第一层：任务状态兜底。 前端不会假装成功，而是轮询 如果任务成功，再下载 如果任务还在 pending/processing，下载接口不会直接返回坏文件，而是返回等待状态。
第二层：PDF 内容校验。
后端拿到 Puppeteer 返回结果后，会检查 PDF 文件头是否是 %PDF。如果不是有效 PDF，直接判定失败，不会把坏文件给用户下载。
第三层：错误归因。 前端会把错误分成几类：
▼text复制代码RATE_LIMITED：导出过于频繁 SERVICE_BUSY：导出队列已满 GENERATE_FAILED：生成失败 TIMEOUT：导出超时 NETWORK：服务不可用
这比统一显示“服务器异常”要好，用户至少知道是频繁、排队、超时还是生成失败。
第四层：浏览器导出兜底。
服务端 PDF 失败时，产品上应该保留浏览器打印/导出路径。代码里 PdfExportHandler 明确是 maxRetry = 0，设计意图是“失败快速返回，由前端使用浏览器打印兜底”。因为 Puppeteer 挂了不代表用户完全不能导出。
10、技术选型与边界
▼text复制代码前端：Vue 3 + TypeScript + Vite 后端：Spring Boot 数据库：MySQL + Flyway 缓存 / 限流 / 任务状态：Redis PDF 导出：Puppeteer 部署：Docker Compose + 阿里云 ECS + Cloudflare AI：DeepSeek / 智谱等模型 provider
AI 应用里最容易忽略的不是 Prompt，而是边界。 很多人做 AI 应用时，第一反应是调 Prompt。 Prompt 当然重要，但上线后更重要的是：
- 输出能不能解析；
- 解析失败怎么办；
- 生成内容能不能直接进入数据库；
- 能不能被展示为 HTML；
- 会不会被 Prompt Injection 诱导；
- 会不会把用户输入当系统指令；
- 会不会把 JD 要求写成用户事实；
- 会不会产生用户无法识别的幻觉。
所以简喵里我做了几层限制：
- Prompt 里明确区分“简历事实”和“JD 要求”；
- 输出要求结构化；
- JSON 解析失败要兜底；
- AI 输出不能直接作为 HTML 渲染；
- 投递文案必须清理 Markdown、重复问候和异常空行；
- 没有证据的 JD 要求只能进入“缺口”或“建议”。
11、上线过程中踩过的坑
1. PDF 预览两页，导出变一页
这是最影响信任的问题之一。 用户看到预览是两页，但导出 PDF 后变成一页，或者第二页内容被挤掉，体验会非常差。 最后我把原则定为：
▼text复制代码编辑器预览页数 = 独立预览页页数 = PDF 导出前确认页数 = 最终 PDF 页数
移动端只允许视觉缩放，不应该影响分页计算。
2. 移动端比想象中难
桌面端简历编辑器可以左右分栏。 移动端不行。 用户在手机上需要：
- 看简历；
- 改模块；
- 调顺序；
- 保存版本；
- 做 AI 分析；
- 导出 PDF。 如果把桌面端按钮硬塞到移动端，只会变成一团乱。 后来我把移动端改成：
▼text复制代码底部：模块 / 预览 / 编辑 顶部：保存 / 版本 / AI 功能 / GitHub / 预览 / 导出 模块：半屏抽屉 编辑：半屏 + 上拉全屏书写
这个过程改了很多轮。
3. 任务状态比按钮状态复杂
AI 任务不是点击按钮马上返回。 它可能处于：
- 创建中；
- 排队中；
- 执行中；
- 成功；
- 失败；
- 超时；
- 退款；
- 已有相同任务。 一开始只做前端 loading 很容易出错。 后来必须以后端任务状态为准，前端只是展示。
4. Docker Compose 上线不是一句命令
上线时也遇到过：
- 后端冷启动时间长；
- health check 先失败后恢复；
- MySQL 初始化和 Flyway 状态不一致；
- Cloudflare 代理下真实 IP 获取；
- HTTPS 和 Cookie 配置；
- CORS / CSRF 本地端口不一致；
- 服务器和本地代码分支不一致。
这类问题没有捷径，只能看日志、看容器状态、看真实请求。
12、为什么我没有一上来做 RAG / Agent / 向量库
很多 AI 项目喜欢一开始就上 RAG、Agent、向量数据库。 但简喵当前阶段不需要。 因为当前核心输入只有两类：
▼text复制代码一份简历 一个目标 JD
它们的数据规模很小。 真正难点不是检索，而是：
- 证据边界；
- 输出结构；
- 失败兜底；
- 用户路径；
- PDF 交付；
- 移动端体验；
- AI 成本控制。
如果现在引入 RAG / Agent / 向量库，更多是技术自嗨，不一定能提升用户价值。 我更愿意先把一个岗位准备链路做扎实。
13、和现有产品相比，简喵的差异在哪里
我不认为简喵现在能在模板、ATS、生态上打过成熟产品。 简喵目前唯一值得打的差异点是： 证据约束。 也就是：
▼text复制代码不是帮你把 JD 要求都写进简历， 而是告诉你哪些能写、哪些需要证据、哪些不能写。
这个差异很小，但我认为它真实。
简喵的现有问题
- 模板数量还不够；
- 非技术岗位的示例还需要补；
- AI 结果质量还要继续调；
- 移动端编辑体验仍然可以优化；
- PDF 导出还需要更多边界测试；
- GitHub 登录、分享、反馈入口等还需要打磨；
- 隐私边界会继续在现有边界进行优化
我不想把它包装成“已经完美解决求职问题”的产品。 但它已经能完成完整链路：
▼text复制代码注册 / 登录 创建简历 编辑简历 保存版本 粘贴 JD 目标岗位分析 岗位竞争力诊断 生成投递文案 导出 PDF 分享链接
这对我来说，是第一阶段最重要的事情。
14.域名绑定和监控
用CloudflareDNS进行服务器端口绑定对应主域名下的子域名，同时开启代理云
部署到Cloudflare域名jianmiao.yanxai.com进行页面资源访问请求的监控
后续会记录服务器上线和域名绑定的过程和经验分享
15、后续计划
接下来我会优先做这些：
1. 补行业模板
尤其是非技术岗位：
- 运营；
- 行政；
- 机械；
- 财务；
- 人事；
- 销售；
- 新媒体；
- 教育；
- 产品助理。 很多用户并不是技术岗。后续需要补充
2. 优化岗位分析质量
尤其是低证据、弱匹配场景。 不能只显示一堆空结果。 就算用户简历很弱，也应该给出可执行建议：
- 哪些经历还能挖；
- 哪些表达要保守；
- 哪些内容需要补；
- 先改哪一段最划算。
3. 强化投递文案
投递文案要更像人写的，不要像技术清单。 不同场景应该有不同语气：
- Boss 开聊要短；
- 官网备注要稳；
- 邮件正文要完整；
- 内推文案要自然。
4. 面试追问
这部分我很想继续做。 因为如果简历里写了某个项目，面试官大概率会追问：
- 你具体负责什么；
- 为什么这么设计；
- 遇到什么问题；
- 怎么验证效果；
- 如果重做会怎么改。
这和“证据约束”是一条线。 简历不是写完就结束，面试追问才是验证真实性的地方。
5. 更明确的隐私说明
简历数据很敏感。 后续需要把数据存储、AI 调用、分享链接、删除机制写得更清楚。
16、最后
做这个项目最大的感受是： 真正难的不是接入 AI，而是让 AI 在一个真实产品里可靠、克制、可解释地工作。
调用模型 API 很简单。 难的是：
- 不让它乱写；
- 不让它污染行业；
- 不让它把 JD 当事实；
- 不让它输出不可解析内容；
- 不让它给用户制造面试风险；
- 不让它在失败时把产品体验拖垮。 简喵现在还很早期，但它已经上线了。 如果你正在找实习、校招、社招，或者只是想整理一份更清楚的简历，可以试试看： jianmiao.yanxai.com
如果你需要某个行业模板，或者发现某个岗位分析不准，也欢迎反馈给我。 我会继续迭代。 为爱发电。 绝不伤害用户信任，PDF 导出不会卡在最后一步。
后续我会写技术复盘文章包括 架构设计 技术选型 AI完整功能链路 功能防护 上线前打包部署 服务器选择和上线 移动端适配 域名绑定 进行一个详细的技术复盘。
测试的JD粘贴如下：
▼text复制代码# AI 应用开发工程师（Java / LLM / RAG / Agent 方向） ## 岗位描述 我们正在建设面向企业知识管理、智能问答、内容生成、流程自动化和智能决策辅助的 AI 应用平台。你将参与大模型应用的后端研发、RAG 检索增强、Prompt 工程、结构化输出校验、Agent 工作流编排、AI 任务调度与效果评估等核心模块建设，推动大模型能力在真实业务场景中的稳定落地。 该岗位更关注 AI 应用工程化能力，而不是单纯调用模型接口。我们希望你既具备扎实的 Java 后端开发能力，也能理解大模型应用中的上下文构建、证据检索、防幻觉、成本控制、响应稳定性和用户体验闭环。 ## 岗位职责 1. 参与 AI 应用平台的后端研发，包括用户、项目、知识库、AI 任务、历史记录、权限控制、文件解析、结果管理等核心模块。 2. 基于 Java / Spring Boot 构建稳定的业务接口，负责接口设计、数据建模、异常处理、日志追踪、权限校验和性能优化。 3. 接入 OpenAI、Claude、DeepSeek、通义千问等大模型 API，完成模型调用封装、Prompt 模板管理、超时控制、失败重试、模型降级和调用成本统计。 4. 参与 RAG 检索增强系统建设，包括文档解析、文本切分、向量化、Embedding 存储、相似度检索、召回排序、上下文拼接和答案引用。 5. 设计和优化 Prompt 工作流，使模型输出更符合业务目标，包括结构化 JSON 输出、结果校验、字段补全、风险提示和多轮追问。 6. 参与 Agent 工作流能力建设，包括任务拆解、工具调用、状态流转、执行日志、人工确认节点和异常回退机制。 7. 参与 AI 输出质量控制，降低幻觉风险，避免模型编造事实、夸大用户能力、生成不可验证内容或输出不符合业务边界的结果。 8. 与产品、前端和算法同学协作，将 AI 能力封装为可复用的业务功能，例如智能简历优化、岗位匹配分析、智能问答、知识库助手、面试准备、报告生成等。 9. 建设 AI 调用可观测能力，包括请求日志、TraceId、Token 消耗、响应时间、错误分类、模型命中率、用户反馈和质量评估指标。 10. 参与系统上线、接口联调、测试用例编写、灰度发布和线上问题排查，保障 AI 应用在真实用户场景下稳定运行。 ## 任职要求 1. 计算机、软件工程、人工智能、信息管理等相关专业本科及以上学历，接受优秀应届生、实习生或初级开发者。 2. 熟悉 Java 语言和 Spring Boot 开发，理解 Controller、Service、Repository/Mapper、DTO、异常处理、参数校验等常见后端分层设计。 3. 熟悉 MySQL、Redis 等常用中间件，能够完成基本的数据表设计、索引设计、缓存设计和常见查询优化。 4. 熟悉 RESTful API 设计，理解前后端分离开发流程，能够与 Vue / React 等前端框架进行接口联调。 5. 了解大模型 API 的基本使用方式，熟悉 Prompt 编写、上下文组织、结构化输出、模型响应解析和异常处理。 6. 了解 RAG 基本流程，包括文档解析、文本切片、Embedding、向量检索、召回排序和上下文增强。 7. 具备较强的问题拆解能力，能够将一个 AI 产品需求拆解为后端接口、数据结构、AI 调用链路和异常处理流程。 8. 有良好的工程意识，重视代码可读性、测试覆盖、日志可追踪性、边界条件处理和线上稳定性。 9. 对 AI 应用落地有持续兴趣，愿意主动研究 LLM、Agent、RAG、Prompt Engineering、防幻觉、AI 评估等方向。 ## 加分项 1. 有完整 AI 应用项目经验，例如智能简历优化、AI 面试、知识库问答、AI 客服、文档问答、Agent 自动化工具、AI 写作助手等。 2. 熟悉 LangChain、LlamaIndex、Spring AI、Dify、Coze、Flowise、n8n 等任一 AI 应用开发框架或平台。 3. 有向量数据库使用经验，例如 Milvus、Pinecone、Weaviate、Qdrant、pgvector、Elasticsearch 向量检索等。 4. 熟悉大模型输出校验、防幻觉、证据链、引用溯源、Claim Verification、结构化输出验证等工程实践。 5. 有 AI 成本控制、Token 统计、模型降级、多模型路由、流式响应、异步任务队列等实践经验。 6. 熟悉 Docker、Linux、Nginx、CI/CD、云服务器部署，有独立上线项目经验。 7. 有 GitHub 项目、技术博客、开源贡献、真实用户使用反馈或完整产品 Demo 者优先。 ## 技术栈 后端：Java、Spring Boot、MyBatis / JPA、Spring Security 数据库：MySQL、Redis AI 能力：LLM API、Prompt Engineering、RAG、Embedding、Agent Workflow 工程化：Docker、Linux、Nginx、GitHub Actions、日志追踪、接口测试 前端协作：Vue / React、RESTful API、SSE / WebSocket 可观测：TraceId、调用日志、Token 消耗、错误分类、用户反馈 ## 你将参与的项目方向 1. 企业知识库问答系统 2. AI 简历优化与岗位匹配系统 3. 智能客服与自动化问答系统 4. AI 面试准备与候选人能力分析 5. 文档解析、摘要生成与报告生成系统 6. Agent 工具调用与业务流程自动化平台 ## 我们希望你具备的特质 1. 不满足于“能调通模型”，而是关注 AI 输出是否可靠、可解释、可追踪、可复用。 2. 能从真实业务流程出发设计 AI 功能，而不是堆砌模型能力。 3. 对工程质量有要求，愿意写测试、补日志、处理异常、优化用户体验。 4. 能持续学习新技术，并把新技术转化为稳定可用的产品能力。
我是Ryan，一个专注于可信AI应用工程的开发者，研究如何让AI生成从“外观”走向“有证据、可追溯、可验证”。
