一台RTX 4060，8GB显存，被改造成了一条简历处理流水线。开发者Florian Jean-Baptiste Dit Doudoute在HackAVP 2026挑战赛中做出CV Forge，把一份简历变成结构化、可被其他服务直接调用的数据。 这个项目的需求和数据来自OPT-NC，创新框架和挑战赛由Station N提供，教学陪伴来自新喀里多尼亚大学IAE，他所在的公司BARRAU BUSINESS SYSTEME则让他一路积累到能独立搭出这套方案。 CV Forge的目标很直接：提取、解释、校验、标准化简历里的信息，让HackAVP生态里的其他模块拿去就能用。 简历不是数据库 人读一份简历几乎是瞬间的事：姓名、经历、学历、技能、联系方式，一眼扫过去就分好了类。机器面对的是另一回事。 简历可能是一栏或两栏排版，可能极度图形化，可能整页是图片，可能从Word或Canva导出，每份文档的组织方式都不一样。问题因此变成两层：先把内容从文档里抽出来，再在不编造信息的前提下理解这些内容。 他的判断很明确：一次糟糕的提取，不会因为后面送进了大模型就变得正确。 把AI留在自己电脑里 简历里全是个人信息：身份、联系方式、学历和职业经历。他选择把方案跑在个人电脑上，OCR和模型都在本地执行，文档不发给云端AI接口。 他也把话说清楚了：本地部署不等于自动安全，也不等于自动符合GDPR。访问权限、文件、日志都要保护，留存规则要另行定义。换来的是对环境的掌控，以及不用按请求次数付费，可以放开手做实验。 硬件上他没有追求跑最大的模型，而是挑了一套匹配需求的方案——识别并结构化简历数据。用他的话说，挑战不在于拥有最大的GPU，而在于把手头这块用好。 流水线拆成四块 整条处理链被切成职责单一的模块： n8n工作流接收待处理的简历； OCR/提取服务从文档中取出信息； 提取内容交给本地运行的Qwen（通过Ollama调用）分析； 结果按预期结构归一化，由Pydantic校验类型、结构和部分业务规则； 档案转换为JSON Resume，供HackAVP其他服务消费，也可作为转成Europass格式的起点。 为什么不把一切都交给模型？因为模型不能100%信任。OCR负责提取，Qwen负责解释，Pydantic负责校验结构，转换器负责产出交换格式。只要接口保持兼容，任何一个组件都能被替换，不必重写整条链。 4060对5080：不是比谁卡大 负责CV Generator的同事用的是RTX 5080，16GB显存，机器能装下更大的模型，具体取决于量化和显存需求，这对文档生成和更复杂的理解任务可能有价值。 他的显卡则逼着他选轻量Qwen加专门化处理。更大的模型在某些任务上确实可能表现更好、错误更少，但这不是自动发生的——得用同样的文档、同样的标准去验证。更强的卡不会魔法般地消除幻觉。 如果明天换GPU，架构可以往上长：显存更多，就能试更大的模型，处理链保持不变，只需调整配置、验证性能、重测精度。分离组件的原则不变。 别再打补丁了 开发过程中他试过用加n8n节点、加条件、加提示词指令的方式修错误。结果是工作流越来越像一座煤气厂。用他的比喻，不能逼一台打印机去放视频，该升级组件就升级组件。 有个具体例子：某些简历上，流水线能找回工作经历、学历技能和联系方式，却偶尔找不到候选人的姓名。他的教训是，先判断错误出在OCR、模型还是校验环节，再决定加不加修正。 十个补丁也变不出一个更强的模型。干净、可演进的架构，胜过一堆修正的堆积。 44秒，以及一个清醒的提醒 用Qwen跑出来的结果他认为是令人鼓舞的，在简历上可见错误很少。但AI始终可能幻觉，所以他盯四个点： 结构：JSON经Pydantic校验合规； 准确：信息忠于原始简历； 完整：关键数据都取回来了； 性能：一次测试约44秒。 他特意强调：JSON合法，不代表信息准确。 真正的产出不是PDF HackAVP给他最大的收获是互操作性——让多个独立应用围绕同一个目标通信。CV Forge把简历转成JSON Resume这个标准化格式，其他团队可以直接使用：CV Matching做候选人与岗位的匹配，CV Generator生成求职材料，Europass对接欧洲标准。 他还做了字段到Europass数据模型的对应工作，覆盖身份、经历、学历、语言和技能。这是数据结构层面的兼容工作，不是官方Europass认证，导出结果的全面验证仍待推进。 互操作性不只是成功发一次HTTP请求，而是让分别设计的系统共享同一条信息、且含义不变。这也是架构问题：如果他明天换GPU、换Qwen模型或换OCR服务，只要守住输出契约，其他团队就不该被迫改自己的应用。 下一步他想做的事很具体：建一套带预期结果的测试简历集；把OCR错误、归一化错误和业务异常分开度