MLOps工程师模拟申请报告

基于Apptronik的Staff MLOps Engineer职位和公开简历生成的MLOps工程师模拟申请示例。查看职位匹配度、经历证据缺口、修改建议和面试问题。

查看点评示例

查看适合你职位的报告。

选择或搜索职位，查看相应的分析与面试问题。

领域

职位

MLOps工程师. 报告示例已更新。

按岗位浏览模拟申请示例

软件开发

云与基础设施

安全

安全工程师

IT支持

数据与AI

产品与项目管理

设计与品牌

营销与增长

内容与媒体

销售与客户支持

经营与战略

财务与会计

人力资源与培训

法务、合规与政策

制造与工程

运营、物流与供应链

环境与安全

建设、建筑与房地产

医疗、卫生与制药

教育与社会工作

酒店、餐饮与零售

维修与技术服务

Staff MLOps Engineer · Apptronik

节选自公开简历与实际职位的分析。申请问题保持未回答。

你的申请会如何被理解？

概括职位与简历中体现的优势和证据缺口。

Apptronik Staff MLOps Engineer

值得申请，先补关键证据

前 74-86%

总结

以下是您向 Apptronik 的 Staff MLOps Engineer 岗位提交的模拟申请分析。简历中最突出的优势是您在 Nkia 将 AI Assistant 的架构、评估和部署串联起来，并在 1500个场景的评估中达到94%准确率。更深入的审阅者希望看到一份真实系统案例，串起数据版本、实验记录、模型审批、部署回滚及您的个人架构决策。

评分、比较排名、面试官与招聘阶段属于AI分析和模拟，并非企业的实际评价或招聘结果。

判断现在是否准备好投递。

查看申请建议及提交前需要完善的内容。

前 74-86%

与相似申请者对比的基准

在由相似申请者、相邻岗位的被录用者、相似角色的在职者构成的对比基准范围内，你处于前 74-86%、高于基准范围的中间水平，这意味着应用交付成果值得招聘方继续阅读，但不能直接视为通过 Apptronik 的 Staff MLOps Engineer 筛选或达到 Staff 要求。你在 Nkia 主导 AI Assistant 的模块化架构、本地部署和评估工具建设，并以 1500 个场景下 94% 的准确率及功能新增耗时缩短 30% 支撑实际价值。申请前应优先重写 Nkia 的职责范围与平台工具条目，明确哪些生命周期环节由你负责、哪些团队实际采用，以及哪些生产决策由你作出；约 4.8 年 ML 工程经历本身不能替代岗位要求的完整 MLOps 平台所有权。

依据

AI Assistant 在 1500 个场景下达到 94% 准确率，加上 제품 매뉴얼 검색시스템 개발 的检索与响应时间指标，使你的成果比只有工具清单的申请更容易核验。这些可量化的应用交付证据支撑了前 74-86%的位置，但指标覆盖的是应用表现，不能扩展解释为机器人平台规模。

申请前要修改的内容

重写 Nkia 的 AI Assistant 首条经历，按架构决策、本人负责范围、本地部署和 1500 个场景下 94% 准确率排列证据。

在 프롬프트 관리 서비스 개발 条目中明确提示词版本管理、评估自动化及实际使用边界，避免将其写成完整模型注册平台。

更可能收到的招聘邮件

简历筛选被拒

基于当前报告信号生成的真实下一步示例。

9:41

●●●●○

🔋

←

📥

⋮

Regarding your Staff MLOps Engineer application

David Chen

david.chen@apptronik.com

刚刚

Hi, Thank you for your interest in the Staff MLOps Engineer role at Apptronik. We appreciate the time you put into your application and the context you shared through your resume and answers. The strongest signal we saw was 您已有模型应用到产品部署的闭环，不是只有实验记录. At the same time, this search needs clearer evidence around 尚无完整 MLOps 平台持续负责经历的明确证据, and that gap made it difficult to move forward for this specific opening. We have decided to continue with candidates whose recent experience more directly matches the current needs of the team. This is a role-specific decision, not a broader judgment on your overall potential. We appreciate your interest in Apptronik and hope you will consider future roles that align more closely with your experience. Best, Apptronik Recruiting Team

每个招聘阶段关注的证据不同。

查看各招聘阶段关注的优势与疑虑。

成果清楚，平台职级证据仍需补齐

前 30 秒可以看到 Nkia 的 ML Engineer 经历、AI Assistant 的 94% 准确率和 제품 매뉴얼 검색시스템 개발 的性能改善，应用交付信号清楚。建议把真实职责范围与经验路径提前到工作经历开头，同时补充 Austin 现场办公答案，降低因信息缺失而停留在初筛的风险。

“Agent 파이프라인 전체 로직 설계, 프롬프트 관리 및 평가 도구 자체 개발”

“Nkia 这段看得出他能把 AI Assistant 做到本地部署，1500 个场景下 94% 的准确率也值得继续问，가짜연구소 FinAgent-Lab 还有代码评审经历。只是 Apptronik 的 Staff MLOps Engineer 要负责共享平台，我还需要知道他究竟拥有过哪些生命周期环节，以及这些责任持续了多久，不能仅凭 ML Engineer 的任职年限就放行。”

与相似申请者的对比基准

招聘人员初筛

结果不明

Nkia 的连续任职记录和 AI Assistant 的量化成果，让招聘人员能快速识别你的 ML Engineer 背景。此阶段应优先解决**职级表述和 Austin 现场办公信息**，招聘沟通是否设置及其形式仍需向公司确认。

招聘经理审阅

可能止步

负责招人的经理更可能追问，你是否能承担 Apptronik 在 Autonomy、Data Platform 和 TeleOp 之间的平台契约责任。此阶段的主要风险是**日常所有权范围不足以核验**，而非应用项目本身缺乏价值；实际面谈安排未获确认。

技术面试

可能止步

若进入技术评估，AI Assistant 的 94% 准确率和 Int4 Qwen2.5-7B 会成为追问评估独立性、量化取舍及失败模式的入口。技术准备应围绕**真实实现的可复现推演**展开，并将机器人延伸设计标为假设；具体题型、轮数和时长均未确认。

💭

招聘经理真正的想法

毫不避讳

我先看您把模型交付到产品的实绩，再追问平台负责范围，最后决定是否值得推进面试。

🤔

扫读履历

嗯，您在 Nkia 做 ML Engineer，重点是 RAG 和 AI Assistant，产品落地路线很清楚。我为 Apptronik 招的是 Staff MLOps Engineer，得继续找整个平台由您负责的证据。

🚫

不予推进 — 缺少完整平台持续负责经历及资深技术领导范围的明确证据

我将这份申请归档，不安排本轮面试，并记录应用交付与评估工具是优势。若您之后补充实际负责过的平台全链路和跨团队标准落地证据，我再重新评估。

不只看总分，也看每项依据。

查看报告14个评估维度中4项的评分与依据。

维度	分数	说明
证据·可信度	84 总分	产品手册搜索项目在明确项目期间内列出 Recall@5、答案准确率和响应时间的前后值，AI Assistant 又给出1500个场景的评估规模，形成了多项可核查指标。这些数字与所述工作范围没有明显矛盾，但功能新增耗时下降30%的统计口径、评估集划分及重复测试条件尚未展开；补上测量方法与责任边界，能让可信的项目成果进一步支撑平台岗位所需的可复现性讨论。
招聘者可读性	76 总分	工作、教育、技能和项目区分清楚，量化成果可快速定位，产品手册搜索项目也有明确起止时间。AI Assistant 条目把功能规划、架构、专利和指标集中在同一区块，且“문제 해결 및 성과”与后续项目符号相连，影响快速扫读；建议按架构决策、评估结果、部署责任重新排序，将最贴近目标岗位的证据提前，并减少与平台职责关联较弱的背景描述。
技术深度	73 总分	Int4 量化、LangGraph 迁移、复杂表格解析和 hard negative mining 让技术描述具有具体实现抓手，并非只有结果数字。当前仍以采用了什么技术为主，缺少为什么这样选择的论证，例如量化后的质量边界、模块接口如何划分，以及其他方案为何被放弃；补充这些真实取舍，比继续列工具更有助于审阅者判断您是否准备好承担平台架构决策。
职位匹配度	56 总分	您在 Nkia 的 AI Assistant 交付经历覆盖模块化架构、自建评估、Python 与 Docker 部署，与岗位的平台工程工作存在实际连接；프롬프트 관리 서비스 개발 也提供了版本管理和测试自动化的邻近证据。主要缺口是完整模型生命周期的负责范围：现有材料没有说明数据血缘、实验追踪、模型注册与审批如何共同运行，也没有证明四年以上直接负责生产 MLOps 平台，因此需要明显的平台领域补足。

区分加分依据与失分原因。

对比得分最高与最低项目的评估依据。

为什么会是这个分数

这里会一起说明拉高这个分数的因素，以及还没能进入更高梯队的原因。

最强优势

最弱环节

证据·可信度

产品手册搜索项目在明确项目期间内列出 Recall@5、答案准确率和响应时间的前后值，AI Assistant 又给出1500个场景的评估规模，形成了多项可核查指标。这些数字与所述工作范围没有明显矛盾，但功能新增耗时下降30%的统计口径、评估集划分及重复测试条件尚未展开；补上测量方法与责任边界，能让可信的项目成果进一步支撑平台岗位所需的可复现性讨论。

+6 对比同类申请者

回答质量

已保存回答为空，因此本轮没有可评分的深度回答证据，也没有新增背景帮助解释量化、评估或部署中的取舍。低分只反映提交材料缺少这一部分，不代表您的实际表达能力，也不能据此认定回答模板化；补充时应围绕真实决策与失败边界展开，以 Nkia 的一个项目说明问题、个人决定、验证方法和结果，并明确机器人平台相关内容哪些仅属于设计设想。

+5 对比同类申请者

主导性·决策力

功能规划、Agent 流水线整体逻辑、自建提示词与评估工具，以及 Trading 团队的策略和代码审查，都能定位到明确的个人负责事项，不能因为没有反复使用第一人称就忽略这些证据。下一步应补充决策权限与结果责任，说明哪些方案由您提出、谁参与评审、上线后由谁维护；这会帮助面试准备从“完成项目”推进到“持续负责平台决策”，但不应把已有领导经历扩大成未证实的跨组织权威。

+10 对比同类申请者

申请完整度

工作、教育、技能与项目材料基本齐全，但申请回答尚未提供，按本报告的问答完整度标准，关键补充材料仍然缺失。题目原文和回答类型也没有给出，因此不能断言您跳过了某一道已知问题；此外，现场工作意愿和相关安排没有可用答案，正式投递前应补齐真实回答与岗位条件确认，避免把一般公司资料中的混合办公描述当作这份明确现场岗位的安排。

+10 对比同类申请者

干系人·影响意识

自动化产品数据与手册查询、减少 QA 时间，以及通过 Web UI 方便团队测试，明确指出了用户和内部协作者的收益。这些证据适合连接到 Apptronik 希望研究人员采用标准平台的需求，但还没有描述 Autonomy、Data Platform 与 TeleOp 这类不同职责团队之间的冲突处理；可用已有项目补充需求优先级和接口协商实例，说明您如何在使用便利、验证成本与工程维护之间作出实际选择。

+13 对比同类申请者

岗位范围匹配

您已经负责 AI Assistant 的整体流水线设计，并在 가짜연구소 FinAgent-Lab 担任 Trading Team Leader，具有项目级技术领导证据。Apptronik 的 Staff MLOps Engineer 还要协调 Autonomy、Data Platform 与 TeleOp，制定跨团队契约并指导中高级工程师，目前材料尚未建立这样的持续职责；约4.8年工程经历也不能替代直接平台负责年限，因此差距主要在组织范围与平台责任层级。

+14 对比同类申请者

找到值得放在前面的经历。

找出简历与自我介绍中值得优先呈现的经历。

亮点

以下是从简历中提炼出的核心亮点，可作为自我介绍或面试时重点强调的优势参考。

Nkia 的评估与部署闭环，为平台岗位提供了可迁移的交付基础。

提示词版本管理经验，是建立模型生命周期工具的邻近能力证据。

把职位用语与自己的经历连接起来。

查看连接职位要求与你的经历的关键词。

主要 ATS 关键词匹配结果

这些是与岗位紧密相关的关键词。建议在面试或自我介绍中自然嵌入，突出重点。

python

docker

fastapi

gitlab ci

保留已经有效的优势。

对照需要保留的优势与需要补充的弱点。

优势

您已有模型应用到产品部署的闭环，不是只有实验记录。

多组前后对照指标提供了可核查的质量改进证据。

待改进

尚无完整 MLOps 平台持续负责经历的明确证据。

数据血缘、实验追踪与模型审批之间缺少贯通链路说明。

了解与相近申请的差异。

通过基准比较查看优势与证据缺口，并非真实申请者排名。

你的相对位置

相比只有模型调用或框架使用记录的相似申请，你在 Nkia 的 AI Assistant 本地交付和 제품 매뉴얼 검색시스템 개발 指标更能说明工程成果。按照相似申请者、相邻岗位的被录用者、相似角色的在职者构成的基准范围，你处于前 74-86%，即高于基准范围的中间水平。最能推动位置上升的一项修改，是把真实存在的共享工具采用与发布决策案例补成可核验的端到端责任说明，而不是扩充工具关键词。

你已经具备的

Nkia 的 AI Assistant 已包含设计、评估和本地部署，可以支撑你对生产应用交付的熟悉程度。1500 个场景下 94% 的准确率让这段经历具有可追问的验证入口。

🎯

最接近的成功画像

你与该画像都以生产应用交付为起点，Nkia 的 Docker、FastAPI 本地部署是直接证据。它能支持服务落地讨论，但不自动覆盖机器人现场运行。

🚀

更强申请者常见的信号

更有竞争力的材料会把数据版本、实验记录、模型产物和发布状态连接成可审计链路。你的 프롬프트 관리 서비스 개발 目前只证明其中部分工具能力，尚未呈现这条责任链。

🏆

相邻录用画像常见的信号

若以岗位要求构建成功画像，应能证明持续负责生产 MLOps 平台，而不是仅满足总工作年限。你在 Nkia 的应用交付相关，但现有资料不足以验证四年以上完整平台所有权；这里不指称任何已核实的 Apptronik 员工。

📈

资历

展示这份申请目前在级别维度上大致被读成什么水平，以及在技术表达再打磨一点后最接近的下一个级别。

Junior

Mid

Senior

Staff

Principal

当前 · Mid

你在 Nkia 负责 AI Assistant 的整体管线逻辑、LangGraph 模块化迁移及 Docker、FastAPI 本地部署，已有超出单一算法实现的交付范围。现有描述主要围绕一个应用及配套工具，尚未说明你对多个团队共享平台的长期技术方向承担最终责任。

下一级 · Senior

프롬프트 관리 서비스 개발 已有可复用工具的起点，但缺少谁采用、旧流程如何退出、标准由谁批准以及采用后维护责任如何分配的说明。下一层级需要证明你让其他工程师改变了工作方式，而不仅是把服务功能开发完成。

相似申请者多数停留在 Mid 级别 · 只有前 74-86% 能达到 Senior

找出评审者可能产生疑问的地方。

找出模糊成果与缺失背景等可能引起疑问的内容。

建议复核的要点

简历中发现的潜在风险信号。投递前重新审视，有助于提升可信度与说服力。

中风险

细节不足

AI Assistant 已有量化模型和模块化迁移的具体选择，但尚未解释架构取舍与运行边界，例如质量损失如何判断、模块之间如何约定输入输出，以及失败如何恢复。Apptronik 要求负责人为生产平台的技术决策辩护，建议补充一个真实方案比较与验证过程，让审阅者看见选择依据，而不是根据工具名称推断平台能力。

"• Int4 양자화 Qwen2.5-7B 모델 도입, LangGraph 기반 모듈형 아키텍처로 코드 마이그레이션"

细节不足

提示词服务包含版本与自动评估功能，是相关证据，但版本对象和审批边界没有展开，无法判断是否记录了数据、代码和模型之间的关联。目标岗位要求模型从训练完成到资格确认再到机器人部署的可追溯路径；应说明现有服务实际管理了什么、自动代码反映功能如何受控，并把没有实施的模型注册功能明确列为缺口。

"• 프롬프트 등록/제거, 전체 조회, 체인/Tool별 버전 관리 및 활성화, 평가 데이터 업로드 및 평가 자동화, 점수 기반 자동 코드 반영 기능 개발"

让主张具体，精简无关内容。

结合修改建议，查看需要补充依据的主张与可删减的句子。

⚠️

有风险的表述

提示词版本管理不等于完整模型注册

Ownership

프롬프트 관리 서비스 개발 包含版本管理、评估自动化和评分驱动代码更新，容易被写成覆盖整个模型生命周期的平台。Apptronik 的面试官会追问模型产物、数据血缘、审批和部署状态，若回答仍停留在提示词操作，职责范围被扩大的印象会削弱可信度。

→

将该条目限定为提示词版本管理与自动评估服务，逐项列出现有功能及本人责任。若没有模型注册与审批实绩，明确保留为空白，并用单独的假设设计讨论未来扩展。

✂️

建议删掉的句子

删去产品偏好的抽象自我描述

Gap

제품관점에서 알고리즘 개발 선호

→

改为：主导 AI Assistant 的功能定义与管线设计，采用 Docker、FastAPI 完成本地部署。接着保留功能新增耗时缩短 30% 的结果，让产品取向通过实际工作呈现。

把职位差距转化为准备事项。

查看尚未满足的要求及短期、长期的补充准备。

프롬프트 관리 서비스 개발 已涉及版本与评估，但尚未证明 Apptronik 所需的数据、实验、模型制品与审批之间的完整可追溯链路。

短期弥合

把 프롬프트 관리 서비스 개발 已有的版本、激活和评估上传功能逐项映射到 Apptronik 的模型注册职责，明确已完成与未提供证据的边界，交付一张包含来源条目和验证方式的生命周期覆盖矩阵。

长期提升

在获得 Nkia 项目范围许可后，为 AI Assistant 推进提示词、评估集和代码版本关联的维护责任划分，对齐 Apptronik 的平台契约要求，形成含负责人、变更规则和验收条件的正式 RFC。

Nkia 的 Docker 与 FastAPI 部署可以迁移，但尚无 Apptronik 要求的 Kubernetes 平台运行、系统级语言以及 Apollo 设备部署证据。

短期弥合

整理 Nkia 的 AI Assistant 已知部署组成，对照 Apptronik 的平台与底层计算契约标注服务边界、外部依赖和未知运行条件，交付一张不补造基础设施细节的部署责任图。

长期提升

以 Nkia 的 Docker 部署经验为基础实现 C++ 制品校验工具，针对 Apptronik 的系统级语言与设备模型版本一致性要求校验清单和校验和，交付含损坏制品及版本不符测试的构建包。

预判面试可能深入追问的部分。

预判围绕个人职责与决策依据的深入追问。

技术负责人会追问 AI Assistant 准确率背后的发布判断

Technical

→ 用 Nkia 的 AI Assistant 准备一段三分钟演练，依次说明问题、实际考虑过的方案、选择依据和测量结果，不要先讲框架清单。先把 1500 个场景的真实评分口径写清，再用现有记录挑出一个失败类别，解释它对结果和交付判断的影响；没有记录的门禁措施应明确说尚未建立。准备可脱敏的评估脚本、样例或结果表，若只能事后整理，就标注为依据现有材料重建的说明。最后单独讨论面向 Apollo 还需要增加哪些证据，并把这部分明确称为假设设计，不混入已完成经历。

用经历故事准备可能的问题。

查看面试官关注点、可能的问题及可用于回答的经历。

预计面试官与面试安排

招聘人员

招聘沟通（推测，待确认）

45 min

会被验证的点

此席位对应推测的招聘沟通，重点是“岗位范围、Staff 级别预期，以及候选人相关经历与团队需求的匹配”。对 Apptronik 的 Staff MLOps Engineer，会需要核对 Nkia 经历能否对应平台经验路径，以及 Austin 现场办公条件；并无已核实的固定筛选规则。

回答方向

先用 Nkia 的 AI Assistant 本地部署和 1500 个场景下 94% 准确率解释你的生产应用背景，再用 가짜연구소 FinAgent-Lab 的 Trading Team Leader 经历补充组织责任。明确这是项目与应用层领导证据，不能代替 Apptronik 所要求的四年以上完整平台所有权，并准备本人确认后的现场办公答案。

技术负责人或资深工程师

技术评估（推测，待确认）

45 min

会被验证的点

此席位对应推测的技术评估，可围绕“训练平台、数据与模型版本管理、可复现性、可靠性及资源成本之间的取舍”准备。结合 Apollo 业务，重点应放在版本证据如何支持评估和部署，而不是把具体编程平台、题型或系统设计轮当作已确认安排。

回答方向

用 프롬프트 관리 서비스 개발 画出提示词版本、评估数据上传和评分驱动代码更新的真实链路，再用 AI Assistant 的 Int4 Qwen2.5-7B 解释已知资源约束。面对 Apollo 的模型产物血缘、包装或回滚追问，先指出现有工具未覆盖的边界，再展开假设方案，避免把提示词版本管理冒充完整模型注册。

💬

预测问题

AI Assistant 使用 Int4 Qwen2.5-7B 时，你如何在内存、延迟和质量之间选择量化方案，什么失败类型会让你放弃它？面向 Apollo 的假设部署中，94% 为什么不足以单独构成发布门槛？

제품 매뉴얼 검색시스템 개발 的 Recall@5 81%→87%，如何区分文档结构化与 hard negative mining 的贡献？若只能固定一个实验变量，你会保留哪项，如何防止评估泄漏影响 Apollo 类高回归成本系统的准入判断？

📖

面试故事包

AI Assistant：从模块化架构到本地交付

适合回答 Apptronik 关于生产约束、系统边界和评估取舍的技术问题。它能证明应用交付能力，但必须将已有结果与面向 Apollo 的机器人设计推演分开。

从 Nkia 需要在本地环境提供轻量 AI Assistant 的约束切入，说明功能定义和数据、手册查询自动化的目标。

展开 Int4 Qwen2.5-7B、LangGraph 模块化迁移及 Docker、FastAPI 部署的实际选择，只讨论真实考虑过的替代方案。

🔁

你应该反问的问题

好问题能让你像同事而不是应聘者。挑一个最自然贴合这位面试官的就好。

针对 Apptronik 的 Staff MLOps Engineer，能否用一个现有或计划中的 Apollo 发布说明：数据完整性、离线指标与交付时间冲突时，谁能阻止晋级，哪些证据可以推翻这个决定？

原因

这个问题把你在 AI Assistant 评估中的经验连接到发布决策权，而不是只询问评分工具。答案会帮助你判断 Apptronik 需要的是门禁实现者还是准入标准负责人，以及你现有评估经历能覆盖哪一部分。

确定先修改什么。

先看2项优先改进内容及修改方向。

正式申请前优先补强的点

这些是正式投递前最值得先修的高杠杆项。

重写 Nkia 的 AI Assistant 架构条目，先陈述已发生的 Int4 量化与 LangGraph 迁移，再用经您确认的事实交代资源限制、模块边界和验证方法，将技术清单改成一个可追问的决策案例。保留94%准确率与1500个场景的范围，但不要暗示该数字已经验证量化前后等价；对 Apptronik 的 Staff MLOps Engineer，最有价值的补充是选择依据与失败处理，未记录的替代方案、内存数据或回滚机制应作为待确认问题，不能直接写成经历。

请仅根据 Nkia 的 AI Assistant 架构条目和已有成果，输出三条中文简历要点，分别描述量化部署、LangGraph 模块化及评估结果，保留所有技术名称和原始数字。另列最多四个待确认问题，集中询问资源约束、方案取舍、接口边界和失败恢复；不要把1500个场景上的94%准确率写成量化无损证明，也不要补造 Kubernetes 或机器人部署经验。

将 프롬프트 관리 서비스 개발 的长功能列表改成“管理对象、评估流程、协作收益”三个层次，明确已经实现的是提示词和链／工具版本、评估数据上传、自动测试及分数驱动的代码反映。随后用待核实清单检查是否真实记录代码版本、数据标识、审批和恢复动作，这能帮助 Apptronik 看见您向模型注册平台迁移的基础；关键是建立已完成与尚未覆盖的边界，不要把提示词服务改名成完整模型注册系统。

请把 프롬프트 관리 서비스 개발 改写为三条中文项目要点，依次突出版本对象、自动评估流程和团队协作界面，保留项目名称。再输出一张两列表格，列出 Apptronik 模型生命周期职责与现有证据；没有数据血缘、模型制品审批或回滚证据的项目统一写“未提供”，不得依据提示词版本管理推断已经实现模型注册。

安排投递前30分钟的准备。

从报告的30分钟准备计划中选择可立即开始的任务。

前十分钟重排 Nkia 核心证据

把 Nkia 的 AI Assistant 开头改成职责范围、架构决定、部署方式和结果四个要点，保留 Int4 Qwen2.5-7B、LangGraph、Docker 和 FastAPI。将 1500 个场景下 94% 准确率与功能新增耗时缩短 30% 放在同一段，并避免将没有比例的 QA 时间减少写成量化成果。

中间十分钟写清服务所有权边界

在 프롬프트 관리 서비스 개발 下标出已实现的提示词版本、评估上传、自动测试及评分驱动代码更新功能。补充本人实际负责的设计与维护事项；模型注册、数据血缘和机器人发布没有事实支撑时，不加入完成清单。

把分散的经历串成职业故事。

梳理经历中的共同优势与下一份工作的衔接。

职业故事

您在完成数学本科和统计学硕士学习后，于2021年加入 Nkia，任职 ML Engineer。此后最清晰的主线是将 AI Assistant 从功能设计推进到本地部署，其中包含轻量模型、模块化 Agent 和自建评估工具。下一步先盘点 프롬프트 관리 서비스 개발 已保存的版本与评估信息，形成一份事实清楚、缺口明确的生命周期覆盖矩阵。