历时 3 个月，我从 0 上线了一个证据约束型 AI 求职助手：简喵

项目名简喵在线体验地址简喵个人技术博客技术博客GitHub仓库Readme: AIResume部署上线及域名绑定全流程上线AI应用生产级护栏限流、日志、降级、缓存、审计、成本简喵不是泛简历生成器而是一个证据约束型 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、架构图和可演示截图再决定是否写入简历。本周优先补 RAGAgent 工作流作为下一阶段补强不建议同周同时做避免 Demo 过散。这么看59分也算合理…岗位竞争力诊断结果这里看到一个点它提出了一个风险点就是简历写了将单次模型评分成本控制在约 ¥0.012 - ¥0.02有面试追问风险你这个成本是怎么算出来的 说明这是基于模型单价和典型评分请求长度估算的单次成本区间不是营收指标没有完整口径时不保留具体金额。数字越具体越容易被追问 token 单价、输入输出长度、缓存命中和估算公式。其次这份诊断还根据简历的项目提出了面试追问的风险点。3.投递文案是什么PDF导出真实能用吗先看一下投递文案的质量这里有一个很重要的点就是它确实真实依据岗位要求和现有的简历证据给出一个尽可能表达符合岗位要求的投递文案不会编造不存在的事实。这个投递文案可以当作一个参考真实投递还得微调不能盲目复制。再来从WPS Office看看PDF导出的质量4.分享链接是什么有什么用分享链接就是将这份编辑好的简历用短链接的形式发送出去可以让别人预览你的简历支持微信、QQ等多平台发送可以手动设置密码和过期时间现在我当场设置一个短链接有效期30天8月1日过期分享短链接点击短链接效果这里的PDF导出是浏览器导出,效果不好不建议在这个页面导出正式PDF分享链接还可以统计链接的数据5.AI调用怎么计算执行时遇到网络问题会不会直接扣除体验次数在我的AI额度这个位置有记录历史的AI调用历史如果AI任中断没有完整生成会退回点数只有任务完成才会扣除响应的点数点数的意义是为了保护AI接口防烂刷。除以上功能外还有其它投递跟进、项目复盘、offer对比等功能不再展示可以点击项目链接真实体验。6.如何注册登录支持Github登录吗用邮箱注册登录即可注册成功过后你会收到邮件或者使用Github进行登录7.简喵为什么强调“证据约束”因为 AI 简历产品有一个很大的风险生成得越流畅越容易让用户误以为它是对的。尤其是求职场景AI 很容易把 JD 要求包装成用户经历。这会带来两个问题。第一用户投出去的简历可能失真。第二面试官一追问就穿。所以简喵在设计上坚持几个规则JD 是岗位要求不是候选人事实简历是候选人事实来源没有证据的内容只能标为缺口或建议AI 可以帮你组织表达但不能替你编经历投递前必须由用户确认。这也是我觉得简喵和普通“AI 优化简历”最大的区别。8.这个项目做了什么防护我的简历信息是否会泄露简喵当前的安全设计核心是用户简历默认私有、账号内隔离富文本和 AI 输出进入系统前后都做净化分享和 PDF 使用受控 tokenAI 调用、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 设置 HttpOnlyHTTPS生产要求 Secure CookieCSRF双提交 tokenXSRF-TOKEN可被前端读取但不承载登录态CORS生产只应允许正式域名NginxAPI no-store减少缓存用户接口响应风险4头像上传防护防护说明大小限制头像限制 500KBmagic bytes不只信任 Content-Type重新编码服务端重新编码为 JPG去掉潜在脚本/EXIF随机文件名使用 UUID不使用用户原始文件名独立路径只暴露/files/avatars/**不接收 SVGSVG 这类可执行载荷应拒绝5文件导入防护防护说明文件大小限制限制 5MB类型检查PDF / DOC / DOCX / TXTmagic bytes检查真实文件头DOCX 解压检查防 zip slip可疑条目过滤避免路径穿越和异常文件结构6PDF导出、Puppeteer防护防护说明不允许用户提交任意 URLURL 由后端构造host 白名单Puppeteer 只访问允许的 host阻断危险协议阻断 file、ws、ftp 等阻断 metadata IP阻断169.254.169.254等容器隔离Puppeteer 独立服务任务校验PDF task 与用户/版本绑定7分享链接防护防护说明长随机 token后端真实 token 足够长短链接只是展示前端展示短 token后端仍可保留长 token密码分享可选密码保护访问限流token IP 限制撤销分享创建者可以撤销快照净化分享内容创建前经过 sanitizerno-store密码分享不应被缓存8AI调用防护防护说明功能限流额度、每日/月度限制任务队列避免重复创建相同 AI 任务输出校验JSON 修复、schema、fallback证据边界JD 是岗位要求不是候选人事实AI 输出净化进入简历/页面/PDF 前走 sanitizer缓存隔离cache key 应包含 user/session/version/scenario审计日志记录 trace、状态、失败原因部分脱敏对手机号、邮箱等敏感字段做处理9Nginx / 浏览器侧防护防护说明CSP限制脚本、对象、frame、连接域名HSTS强制 HTTPSX-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异步任务。流程是用户点击导出 → 后端校验用户是否拥有这份简历和版本 → 创建 pdf_export 任务 → 写入数据库 async_tasks → 推入 Redis 队列 → 后台 worker 取任务 → 调 Puppeteer 服务生成 PDF → 保存 PDF 文件 → 前端轮询任务状态并下载2用户/IP 限流PDF 导出入口有多层限流防止一个用户或一个 IP 疯狂点导出。防止一个账号连续狂点 防止同一设备/同一出口刷接口 防止短时间批量消耗资源 防止免费用户长期滥用3Puppeteer 白名单隔离PDF 导出最危险的地方不是“生成 PDF”而是“让一个无头浏览器访问 URL”。如果不限制攻击者可能尝试让 Puppeteer 访问云服务器 metadata 地址 内网服务 本地文件 file:// Redis/MySQL 内网地址 任意外部 URL 恶意 HTML 页面当前项目做了两层白名单。第一层在后端PuppeteerClient后端只允许自己构造的预览 URL要求满足必须和 app.base-url 或 pdf-preview-base-url 同源 路径必须以 /preview/ 开头 必须带 token 必须带 versionId也就是说用户不能提交一个任意 URL 让服务器帮他转 PDF。第二层在puppeteer-serviceNode 服务也会检查只允许 http/https 拒绝 metadata IP例如 169.254.169.254、100.100.100.200 host 必须在 ALLOWED_HOSTS localhost 端口必须在允许列表 非白名单资源请求会被 request interception 拦截部署上还有容器隔离Puppeteer 不暴露公网端口 Docker Compose ports: [] read_only: true /tmp 使用 tmpfs 容器资源有限制所以它不是“浏览器随便打开网页”而是“只能打开内部预览页并且页面里的外链资源也受控”。4失败兜底PDF 生成链路很复杂可能失败的点很多预览 token 过期 versionId 不存在 Puppeteer 无法访问 preview URL 页面分页溢出 Chromium 超时 服务器内存/CPU 繁忙 队列已满 生成结果不是有效 PDF第一层任务状态兜底。前端不会假装成功而是轮询如果任务成功再下载如果任务还在 pending/processing下载接口不会直接返回坏文件而是返回等待状态。第二层PDF 内容校验。后端拿到 Puppeteer 返回结果后会检查 PDF 文件头是否是%PDF。如果不是有效 PDF直接判定失败不会把坏文件给用户下载。第三层错误归因。前端会把错误分成几类RATE_LIMITED导出过于频繁 SERVICE_BUSY导出队列已满 GENERATE_FAILED生成失败 TIMEOUT导出超时 NETWORK服务不可用这比统一显示“服务器异常”要好用户至少知道是频繁、排队、超时还是生成失败。第四层浏览器导出兜底。服务端 PDF 失败时产品上应该保留浏览器打印/导出路径。代码里PdfExportHandler明确是maxRetry 0设计意图是“失败快速返回由前端使用浏览器打印兜底”。因为 Puppeteer 挂了不代表用户完全不能导出。10、技术选型与边界前端Vue 3 TypeScript Vite 后端Spring Boot 数据库MySQL Flyway 缓存 / 限流 / 任务状态Redis PDF 导出Puppeteer 部署Docker Compose 阿里云 ECS Cloudflare AIDeepSeek / 智谱等模型 providerAI 应用里最容易忽略的不是 Prompt而是边界。很多人做 AI 应用时第一反应是调 Prompt。Prompt 当然重要但上线后更重要的是输出能不能解析解析失败怎么办生成内容能不能直接进入数据库能不能被展示为 HTML会不会被 Prompt Injection 诱导会不会把用户输入当系统指令会不会把 JD 要求写成用户事实会不会产生用户无法识别的幻觉。所以简喵里我做了几层限制Prompt 里明确区分“简历事实”和“JD 要求”输出要求结构化JSON 解析失败要兜底AI 输出不能直接作为 HTML 渲染投递文案必须清理 Markdown、重复问候和异常空行没有证据的 JD 要求只能进入“缺口”或“建议”。11、上线过程中踩过的坑1. PDF 预览两页导出变一页这是最影响信任的问题之一。用户看到预览是两页但导出 PDF 后变成一页或者第二页内容被挤掉体验会非常差。最后我把原则定为编辑器预览页数 独立预览页页数 PDF 导出前确认页数 最终 PDF 页数移动端只允许视觉缩放不应该影响分页计算。2. 移动端比想象中难桌面端简历编辑器可以左右分栏。移动端不行。用户在手机上需要看简历改模块调顺序保存版本做 AI 分析导出 PDF。如果把桌面端按钮硬塞到移动端只会变成一团乱。后来我把移动端改成底部模块 / 预览 / 编辑 顶部保存 / 版本 / AI 功能 / GitHub / 预览 / 导出 模块半屏抽屉 编辑半屏 上拉全屏书写这个过程改了很多轮。3. 任务状态比按钮状态复杂AI 任务不是点击按钮马上返回。它可能处于创建中排队中执行中成功失败超时退款已有相同任务。一开始只做前端 loading 很容易出错。后来必须以后端任务状态为准前端只是展示。4. Docker Compose 上线不是一句命令上线时也遇到过后端冷启动时间长health check 先失败后恢复MySQL 初始化和 Flyway 状态不一致Cloudflare 代理下真实 IP 获取HTTPS 和 Cookie 配置CORS / CSRF 本地端口不一致服务器和本地代码分支不一致。这类问题没有捷径只能看日志、看容器状态、看真实请求。12、为什么我没有一上来做 RAG / Agent / 向量库很多 AI 项目喜欢一开始就上 RAG、Agent、向量数据库。但简喵当前阶段不需要。因为当前核心输入只有两类一份简历 一个目标 JD它们的数据规模很小。真正难点不是检索而是证据边界输出结构失败兜底用户路径PDF 交付移动端体验AI 成本控制。如果现在引入 RAG / Agent / 向量库更多是技术自嗨不一定能提升用户价值。我更愿意先把一个岗位准备链路做扎实。13、和现有产品相比简喵的差异在哪里我不认为简喵现在能在模板、ATS、生态上打过成熟产品。简喵目前唯一值得打的差异点是证据约束。也就是不是帮你把 JD 要求都写进简历 而是告诉你哪些能写、哪些需要证据、哪些不能写。这个差异很小但我认为它真实。简喵的现有问题模板数量还不够非技术岗位的示例还需要补AI 结果质量还要继续调移动端编辑体验仍然可以优化PDF 导出还需要更多边界测试GitHub 登录、分享、反馈入口等还需要打磨隐私边界会继续在现有边界进行优化我不想把它包装成“已经完美解决求职问题”的产品。但它已经能完成完整链路注册 / 登录 创建简历 编辑简历 保存版本 粘贴 JD 目标岗位分析 岗位竞争力诊断 生成投递文案 导出 PDF 分享链接这对我来说是第一阶段最重要的事情。14.域名绑定和监控用CloudflareDNS进行服务器端口绑定对应主域名下的子域名同时开启代理云部署到Cloudflare域名jianmiao.yanxai.com进行页面资源访问请求的监控后续会记录服务器上线和域名绑定的过程和经验分享15、后续计划接下来我会优先做这些1. 补行业模板尤其是非技术岗位运营行政机械财务人事销售新媒体教育产品助理。很多用户并不是技术岗。后续需要补充2. 优化岗位分析质量尤其是低证据、弱匹配场景。不能只显示一堆空结果。就算用户简历很弱也应该给出可执行建议哪些经历还能挖哪些表达要保守哪些内容需要补先改哪一段最划算。3. 强化投递文案投递文案要更像人写的不要像技术清单。不同场景应该有不同语气Boss 开聊要短官网备注要稳邮件正文要完整内推文案要自然。4. 面试追问这部分我很想继续做。因为如果简历里写了某个项目面试官大概率会追问你具体负责什么为什么这么设计遇到什么问题怎么验证效果如果重做会怎么改。这和“证据约束”是一条线。简历不是写完就结束面试追问才是验证真实性的地方。5. 更明确的隐私说明简历数据很敏感。后续需要把数据存储、AI 调用、分享链接、删除机制写得更清楚。16、最后做这个项目最大的感受是真正难的不是接入 AI而是让 AI 在一个真实产品里可靠、克制、可解释地工作。调用模型 API 很简单。难的是不让它乱写不让它污染行业不让它把 JD 当事实不让它输出不可解析内容不让它给用户制造面试风险不让它在失败时把产品体验拖垮。简喵现在还很早期但它已经上线了。如果你正在找实习、校招、社招或者只是想整理一份更清楚的简历可以试试看在线体验如果你需要某个行业模板或者发现某个岗位分析不准也欢迎反馈给我。我会继续迭代。为爱发电。绝不伤害用户信任PDF 导出不会卡在最后一步。后续我会写技术复盘文章包括架构设计技术选型AI完整功能链路功能防护上线前打包部署服务器选择和上线移动端适配域名绑定进行一个详细的技术复盘。测试的JD粘贴如下# 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生成从“外观”走向“有证据、可追溯、可验证”。