作者：林霆恩 Elastic Agent Builder Hackathon 三等奖项目完整分享
在 Elastic Agent Builder Hackathon 中，我开发的 SkillGap Radar 获得了三等奖。它想解决的不是一个遥远的问题，而是许多大学生都经历过的困惑：课程学了不少，招聘信息也看了很多，但两者之间究竟差在哪里？接下来应该补什么，往往只能凭感觉判断。
SkillGap Radar 的目标，是把公开的课程信息和岗位需求整理成可以检索、统计和追溯的证据，再借助 Elasticsearch、ES|QL、Kibana 与 Elastic Agent Builder，把 "我该学什么" 变成一个有依据、可复查的问题。
图：项目宣传图
一、产品背景：为什么 "学了什么" 与 "岗位要什么" 很难对上
作为大学生，我经常能接触到两类信息。一类来自培养方案、课程表和课程简介，它们告诉我们未来几年会学习哪些基础知识；另一类来自招聘平台和企业岗位描述，它们告诉我们市场正在使用哪些技术。但真正需要做决定时，这两类信息往往没有被放在同一张图里。
学生可能知道自己学过数据结构、数据库、操作系统和人工智能导论，也看到招聘信息频繁出现 Python、模型部署、RAG、Agent、向量检索等关键词。然而，"学过一门相关课程"是否等于"具备岗位要求的能力"？某个词没有出现在课程名称里，是否就表示完全没有基础？仅靠肉眼浏览，很难得到稳定答案。
这个问题在 AI 应用方向尤其明显。技术栈变化快，岗位描述中的表达也不统一，同一种能力可能被写成不同名称。学生很容易陷入两个极端：要么认为课程与就业完全脱节，要么看到一个热门词就立刻追逐新工具。两种判断都缺少证据，也不利于形成持续的学习路线。
因此，我希望做的不是一份静态"技能清单"，而是一套可以随数据更新、可以回到原文验证、也能解释结论边界的产品原型。
二、信息差并不只是 "资料太少"
在设计产品前，我把信息差拆成了三个更具体的问题。
第一是语言不一致。课程体系通常按知识领域组织，如程序设计、计算机系统、算法与人工智能；岗位则按任务和工具组织，如模型推理服务、RAG 流程、Agent 编排和容器部署。两者存在关联，却很少使用相同术语。
第二是信息碎片化。一条岗位信息只能说明一个团队在某个时间点的需求，多看几条又容易被最醒目的关键词影响。缺少统一结构时，学生很难知道一个技能究竟是普遍出现，还是偶然出现。
第三是建议缺少依据。通用大模型可以快速生成"AI 学习路线"，但如果它不知道具体课程、岗位样本和统计口径，建议往往正确却泛化。用户真正需要的不只是"学 RAG"，而是"为什么现在优先学 RAG、现有课程提供了哪些基础、还缺哪一段实践"。
SkillGap Radar 因而把产品任务概括为三问：岗位需要什么？课程已经覆盖什么？学生下一步补什么？只有这三个问题使用同一套证据，学习建议才有可解释性。
在这个问题上，最直接的做法是做一张人工维护的对照表，但它很难随岗位数据更新，也无法方便地回到证据原文。另一种做法是把材料全部交给通用大模型总结，生成速度很快，却不容易保证每一次统计口径一致。SkillGap Radar 选择了中间路径：让结构化数据和查询负责稳定性，让 Agent 负责交互与解释。
这也形成了产品的三个设计标准。第一，任何关键数字都应该可以重新查询；第二，任何覆盖判断都应该能看到课程或岗位证据；第三，系统给出的建议必须说明样本边界。对我而言，这三个标准比"回答听起来有多聪明"更重要。
如果把它看成一个产品闭环，输入不是一份简历，而是课程证据、岗位证据与统一技能词典；中间过程不是一次自由生成，而是检索、聚合、比较和解释；输出也不是单一分数，而是需求排名、覆盖状态与学习优先级。这样的闭环既适合当前原型，也为以后扩展更多专业、城市和岗位方向留下了清晰接口。
三、目标用户与三个典型使用时刻
SkillGap Radar 首先面向计算机相关专业、准备进入 AI 应用开发方向的学生。它并不替代老师、培养方案或招聘平台，而是在这些信息之间增加一层 "比较与解释"。
第一个使用时刻是选课前。学生可以先查看高频岗位技能，再判断哪些选修课能够强化对应基础。第二个使用时刻是准备项目时。系统可以帮助学生把"想做一个 AI 项目"进一步拆成检索、模型调用、评估、部署等能力。第三个使用时刻是投递前。学生可以根据目标岗位重新检查技能覆盖，优先补齐高需求但课程中只部分覆盖的内容。
图：大学生决策旅程
这三个场景对应的不是三套产品，而是同一条决策链：先理解需求，再识别已有基础，最后安排下一步行动。
四、产品边界：它不评价什么，也不承诺什么
一个面向教育与求职的产品，很容易因为表述过度而误导用户。因此我从一开始就给 SkillGap Radar 设置了边界。
它不评价学校或培养方案的好坏。课程材料只能证明公开文本中是否出现相关内容，不能代表真实课堂效果。它不预测录用概率，也不承诺学习某项技能就能获得工作。它更不会把 20 条岗位证据写成整个北京就业市场的完整画像。
产品使用"当前公开培养方案中未发现明确覆盖"，而不是 "学校没教"；使用 "当前 20 条岗位样本显示"，而不是 "所有岗位都要求"。这些限定语看似保守，却是产品可信度的一部分。
五、把课程语言与岗位语言变成共同的比较尺度
如果直接把课程名称和岗位描述交给大模型，结果会随提示词和上下文变化。为了让结论可以复查，我先定义了一套统一的数据结构。
课程记录保存课程名称、类别、描述和技能标签；岗位记录保存公开证据摘录、城市、岗位标题、招聘类型和技能标签；技能字典把 "Large Language Model"，" 大语言模型"， "LLM" 等表达归一到同一概念；覆盖记录则连接技能、课程证据与岗位证据。
最终共有 37 条课程记录、20 条北京 AI 应用岗位公开证据摘录，以及 18 个统一技能，共 75 个文档写入 Elasticsearch 索引 skillgap-radar-v1。
下面是一个简化的数据结构示例。它不包含公司、姓名或联系方式，只展示记录如何支持后续查询。
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| { "document_type": "coverage", "skill": "RAG", "coverage_status": "partial", "job_count": 10, "job_ratio": 0.50, "course_evidence": "数据库原理与应用", "非关系型数据库", "智能文本处理技术", "job_evidence_ids": "job-001", "job-003", "job-004", "rationale": "数据库和文本处理课程提供检索与数据基础，但当前公开培养方案中未发现 RAG 的明确课程证据" } |
!\[\](https://i-blog.csdnimg.cn/direct/5dd4029dabb04735b75852933260db94.png) 图：证据记录模型
六、系统如何工作：证据入库、可复现查询统计、智能解释
整个流程可以概括为三层。
第一层是数据层。我把课程、岗位和覆盖关系整理为结构化文档，并保留来源字段，让每个标签都能回到原始证据。第二层是分析层，使用 ES|QL 计算技能出现频次、岗位占比和课程覆盖状态。第三层是交互层，Elastic Agent Builder 根据用户问题调用数据，并把统计结果翻译成更容易理解的学习建议；Kibana 则负责把核心结果做成可视化图表。
图：系统架构
这种分层有一个直接好处：数字不由大模型"猜"，而由查询产生；大模型主要承担理解问题、组织证据和解释结果的工作。这样既利用了 Agent 的自然语言能力，也保留了分析的可复现性。
我选择 Elasticsearch，不只是因为它能保存文本，还因为课程、岗位和技能标签可以在同一个索引中被检索与聚合；选择 ES|QL，是因为统计逻辑能够以短查询清晰表达；选择 Kibana，是为了让真实查询结果可视化；选择 Agent Builder，则是为了把这些能力包装成自然语言入口。
七、Query A：用 ES|QL 把岗位需求算清楚
下面是项目中用于统计技能需求 Top 10 的核心查询。它先筛选北京岗位文档，再展开多值技能标签，按技能统计不同岗位数量，最后计算在 20 条样本中的占比。
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| FROM skillgap-radar-v1 | WHERE document_type == "job" AND city == "北京" | MV_EXPAND skill_tags | STATS job_count = COUNT_DISTINCT(job_id) BY skill = skill_tags | EVAL job_ratio = ROUND(job_count / 20.0, 2) | SORT job_count DESC, skill ASC | LIMIT 10 |
这段查询很短，却承担了项目的"统计事实层"。在最终校验样本中，LLM 出现在 20/20 条岗位证据中，Python 与模型部署均为 18/20，深度学习为 14/20，Agent 为 12/20，RAG 为 10/20。它们不是对所有 AI 岗位的普遍断言，而是这 20 条公开样本中可重复得到的结果。
图：Kibana 中的岗位技能 Top 10
图：岗位技能需求统计图
Kibana 截图展示了真实索引上的聚合结果；单独制作的统计图则更适合文章阅读。两张图使用同一组已校验数据，既保留产品实操痕迹，也避免宣传图脱离可验证的查询结果。Linux、机器学习、数据结构和向量检索均出现于 3/20 条岗位证据中；由于查询按 job_count DESC, skill ASC 排序并限制为 10 条，图表按同一规则展示截止位中的 Linux、向量检索和数据结构。
八、Query B 与 Query C：从"需求排名"走向"技能缺口"
只知道哪些技能出现得多还不够。产品还需要回答课程证据覆盖到了哪里。Query B 直接读取经过审核的覆盖记录，并把课程证据与判断依据一并返回。
|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| FROM skillgap-radar-v1 | WHERE document_type == "coverage" | KEEP skill, coverage_status, job_count, job_ratio, course_evidence, rationale | SORT job_count DESC, skill ASC |
Query C 则进一步筛选"岗位中有需求，但课程材料中只部分覆盖或未发现明确覆盖"的技能。它更接近产品最终要解决的决策问题。
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| FROM skillgap-radar-v1 | WHERE document_type == "coverage" | WHERE coverage_status IN ("partial", "not_explicit") AND job_count > 0 | KEEP skill, coverage_status, job_count, job_ratio, course_evidence, job_evidence_ids, rationale | SORT job_count DESC, skill ASC |
三个查询形成一条完整链路：Query A 描述需求，Query B 描述现有覆盖，Query C 找出值得优先关注的差距。它们比一个不透明的"匹配分数"更容易解释，也更方便在数据更新后重新运行。
九、课程覆盖不是简单的"有"或"没有"
如果只按照课程名称做关键词匹配，很容易得到错误结论。例如课程里没有直接出现"RAG"，并不意味着学生完全没有相关基础；数据库、信息检索、机器学习和软件工程都可能提供组成能力。反过来，课程名称里出现"人工智能"，也不代表已经覆盖当前岗位所需的工程实践。
因此项目把覆盖状态分为三类：covered 表示课程证据中有较明确的对应内容；partial 表示具备相关基础，但仍需要项目或工具链补充；not_explicit 表示现有课程材料中没有直接证据。对 18 个技能的最终校验结果为：9 个已覆盖、7 个部分覆盖、2 个未明确覆盖。
图：课程覆盖汇总
这个结果不能被解读为对培养方案质量的评分。它只回答一个更具体的问题：针对当前岗位样本，哪些能力已经有课程证据，哪些能力需要学生通过实践继续补齐。
十、Agent Builder 的价值：把统计结果变成可行动的解释
用户可以直接询问："北京 AI 应用岗位最常见的技能是什么？""课程对这些技能覆盖到什么程度？""如果准备 Agent 开发方向，优先补哪些能力？"Agent 会根据索引中的证据与聚合结果组织回答，而不是只输出一串排名。
为了降低"看起来合理但没有证据"的风险，我在 Agent 指令中加入了几条约束：回答必须明确样本范围；统计数字优先引用 ES|QL 结果；课程覆盖与岗位需求要分开说明；建议应指出依据，不把相关性写成因果关系；证据不足时直接说明限制。
默认回答结构也被固定为五部分：先给结论，再给数据，然后列证据，接着提供最多五项建议，最后说明边界。这种结构让用户既能快速获得方向，也能继续追问"凭什么"。
开发过程中还有一次很有价值的提醒：某次实时 Agent 检索只返回了 17 条岗位，而索引中的已校验集合是 20 条。如果直接使用自然语言回答里的数字，文章就会出现不同口径。最终我把固定 ES|QL 查询和离线校验结果作为统计事实来源，让 Agent 专注解释。这次偏差反而帮助我明确了系统边界：Agent 很适合交互与归纳，但关键计数仍应由可复现的固定查询兜底。
十一、从差距到学习优先级
SkillGap Radar 不试图给出一份适用于所有人的"标准答案"，而是把优先级拆成三个维度：岗位需求强度、课程覆盖程度、技能之间的依赖关系。
例如，Python、深度学习和模型部署在样本中需求较高，也构成进一步学习 LLM 应用的重要基础；RAG 与 Agent 更偏向应用工程，需要把检索、模型调用、评估和系统设计串联起来。对于大学生而言，一条更可执行的路线是：先巩固已有课程中的编程与算法基础，再完成一个可运行的 RAG 小项目，随后加入工具调用、状态管理和评估机制，把它逐步扩展为 Agent 项目。
一次完整的使用流程可以是这样的：用户先选择"AI 应用开发"作为目标方向，查看需求 Top 10；系统再把高频技能与课程覆盖记录对齐，标出已具备基础和仍需补充的部分；最后，Agent 按先修关系把差距组织成若干阶段。用户看到的不只是"缺少 Agent"，而是从 Python 与数据库基础，到检索增强生成，再到工具调用和部署的连续路径。
产品还需要避免把所有人推向同一条路线。已经完成过深度学习项目的学生，与刚学完程序设计的学生，下一步显然不同。当前原型主要验证公共证据层，未来加入个人基础配置后，同一组市场数据可以生成不同的学习起点，同时仍然保留建议依据。
图：学习建议图
这样的建议不是因为某个热门词出现次数高就立即"追热点"，而是同时考虑需求、基础与实践成本。最终输出的不是课程替代方案，而是一张帮助学生安排课外学习和项目实践的导航图。
十二、从原型到可演示产品：我做了哪些取舍
Hackathon 的时间有限，产品必须先证明核心链路。因此我没有一开始就追求大规模抓取、复杂评分模型或完整前端，而是优先完成四件事：建立小而可校验的样本；统一技能词典；让核心结论能够用 ES|QL 重算；准备 Agent 失败时仍能展示的 Kibana Dashboard。
这些取舍让演示不依赖单一路径。如果 Agent 暂时无法完成聚合，可以直接执行预设查询；如果图表生成失败，可以打开已保存的 Dashboard；如果网络中断，还能使用本地截图说明结果。产品的"可演示性"不是额外包装，而是可靠性设计的一部分。
同时，我也放弃了一个看起来很吸引人的功能：把课程和岗位压缩成单一的"技能差距总分"。这个数字虽然便于传播，却会掩盖覆盖证据、样本大小和技能依赖关系。相比一个看似精确但难解释的分数，我更愿意展示可追溯的分项结果。
十三、这次开发带给我的三个认识
第一，数据定义比界面更早决定项目质量。技能字典、样本边界和去重规则如果不稳定，后面的图表和 Agent 回答再漂亮也不可靠。
第二，ES|QL 与 Agent 并不是替代关系。ES|QL 提供可复现的统计事实，Agent Builder 提供自然语言入口与上下文解释，两者组合后才形成完整体验。
第三，好的智能应用需要主动展示限制。20 条岗位证据适合做原型验证和方法展示，但不足以代表市场全貌；课程描述也不能等同于真实教学效果。把这些限制写清楚，不会削弱项目，反而让结论更可信。
十四、下一步计划与结语
后续我希望从三个方向继续完善 SkillGap Radar：扩大岗位样本并按时间、城市与岗位方向分层；为技能标签增加人工复核和版本管理；加入可配置的个人基础信息，使学习建议能够区分"已有基础"和"尚未接触"。如果数据持续更新，还可以利用 Kibana 展示技能需求随时间的变化，帮助用户观察趋势，而不只是查看一次性的排名。
回看这个原型，它首先为学生提供了一种更具体的观察方法：把"岗位需要什么"和"现有课程提供了什么"分开呈现，再把两者之间的差距转化为可以安排先后的实践任务。用户不必只依赖热门词或笼统经验，而能够顺着证据继续追问。
在技术层面，项目验证了 Elasticsearch、ES|QL 与 Agent Builder 的互补关系。结构化索引负责保存证据，固定查询负责形成可复现的统计事实，Agent 则负责理解问题、组织上下文和解释结果。即使智能交互暂时失败，核心结论仍能通过查询和 Dashboard 独立复核。
在产品层面，最重要的设计不是给出更多结论，而是明确每条结论的适用范围。样本量、城市、课程文本和覆盖状态都被保留在结果旁边，使建议既有方向感，也不会越过证据边界。这种"先说明依据，再提供行动"的思路，也可以迁移到其他教育分析与职业规划场景。
从大学生的视角出发，我想做的并不是另一个泛化的职业问答机器人，而是一套能够回答 "依据是什么" 的工具。SkillGap Radar 仍是一个小型原型，但它初步验证了一条可行路径：先让公开材料成为结构化证据，再用 ES|QL 建立可信的事实层，最后让 Agent Builder 把事实转化为可理解、可行动的建议。这也是我在本次 Hackathon 中最重要的收获。