26届硕前端简历求优化

一、个人技能：AI 工程化能力矩阵见下图⬇️------二、项目难点深度阐述（STAR 话术参考）2.1 模型选型：不只是“会用”，而是“会选”技术要点：• 文生图/视频：SDXL（开源可控）、Midjourney（艺术质感）、Sora（长视频逻辑）。选型关键看 Latency（延迟） 与 Cost（成本）。• 多模态：GPT-4V（强推理）、Gemini Pro Vision（性价比）。难点在于视觉问答（VQA）的 prompt 构造。• 编码模型：DeepSeek-Coder（开源首选）、Claude 3.5 Sonnet（代码解释强）。选型依据是 Context Length（上下文长度） 和 Repo 理解能力。2.2 规划：ReAct 编排机制技术原理：ReAct = Thought (推理) → Act (行动) → Observe (观察)。它通过显式生成推理链（“我需要先查A，再查B”），解决了 LLM 的“黑箱决策”问题，让 Agent 具备可解释性 。落地难点：• 循环失控：Agent 容易陷入死循环（如一直搜索不到结果）。• 解决策略：设置 Max Iteration（最大步数） 和 Self-Correction（自我修正） 机制。例如，在 Thought 步骤强制要求“如果失败，下一步策略是什么”。2.3 记忆：从“聊天记录”到“工作记忆”架构设计：• 短期记忆：存储在内存或 Redis 中，仅保留最近 3-5 轮对话，用于维持会话连贯性。• 长期记忆：基于 RAG + 向量数据库（如 Chroma, Milvus），存储项目文档、用户画像，实现跨会话的知识复用 。Agentic RAG 实战难点：1. 上下文过长：采用 “渐进式加载”（Progressive Loading）。先检索摘要，Agent 判断需要详情时再拉取全文，而非一次性灌入所有内容。2. 噪音控制：严禁将工具调用的中间结果（如 raw JSON）直接塞入上下文。必须经过 Extract-Transform 步骤，只保留关键字段，避免干扰 LLM 的注意力 。2.4 工具调用：MCP 底层原理与实战MCP 核心流程：MCP 通过 JSON-RPC 2.0 协议，在 Client（模型端） 和 Server（工具端） 间建立标准化通信 。1. 初始化：Client 向 Server 发送 initialize，协商能力（Tools/Resources）。2. 调用：Client 发送 callTool 请求，Server 执行并返回结构化结果。3. 传输：本地用 stdio（低延迟），云端用 SSE/HTTP（分布式）。自定义 Skills 技巧：• Skill 封装：将“查数据库”封装为 query_database(sql)，而非直接让 LLM 拼接 SQL 字符串。• 权限与安全：在 MCP Server 层做参数校验和权限拦截，防止 LLM 生成恶意指令。—————————1. MCP 是未来：它解决了工具生态碎片化问题。以前每个模型都要写一套插件，现在工具只需实现一次 MCP Server，即可被所有客户端（Claude, Cursor）复用 。2. Agentic RAG > 传统 RAG：传统 RAG 是“检索→回答”的管道，而 Agentic RAG 是“观察→决策→检索→反思→行动”的闭环，具备自主决策能力 。最后建议：在介绍项目时，务必强调你如何解决“Token 成本”和“幻觉控制”这两个工程核心痛点，这比单纯罗列技术栈更有说服力。

PS：就我目前看到的AI项目而言，相信大家的检索能力，一定能找到相类似的，所以我这边就不贴出对应的github仓库链接了。我其实就是用的这两个，不过我对这两个进行了一些综合，把二者合二为一了。1. 本地私有知识库 RAG 助手核心价值：覆盖面试高频考点，完美匹配 “检索增强生成” 技术栈，做完能直接解决学习 / 工作痛点。落地路径：技术栈：Python + LangChain/LlamaIndex + Chroma/FAISS（向量库） + Streamlit（快速网页）核心功能：上传 PDF/Markdown 文档（比如你的技术笔记、行业报告）→ 智能切分（带 100-200token 重叠...

（仅分享最近的收获）：AI能够提升上限：情景- 我之前上学时喜欢用Python。曾说“JAVA是工作，Python是生活”- 虽然但是，没有Python大项目基础，等级可以类似于 JAVAEE水平。太久没写后也忘了差不多辽- 我需要使用python进行快速的自动化落地，从零到一完整写一个新的项目：过程- 一开始古法编程硬写，费时费力没有成果- 过了一段时间选择推倒重来，给出完整的产品设计文档，以及数据库建模，以及需求单.md- 再装配 skill，使用 AI IDE （agent，模型都选国内顶级模型） + Intellij （手动修改，使用 DS的 FIM）结合的模式- 针对需求单做进一步任务拆解，“吃一个，看一个”；在交给AI前，先自己把伪码以及核心方法名创建出来 （最长一次花了2h做这事）- 花费大量时间堆 prompt 质量。只手动圈选必要上下文（最多一次圈了15个文件），并有礼貌的指出问题，指出你要看什么这样这样- 对结果不断优化，能改的直接自己改：结果- 攻克太多之前想都不敢想的难点，东西出来了：舒服的地方- 一筹莫展的境地，有了转圜的余地- 我这种菜鸟写起来肯定是磕磕绊绊，我就疯狂的打TODO让他FIM，速度得到了保证，不会卡心流- 真的能够快速验证，小步快跑，把东西拉出来：不舒服的地方- 平均一次响应要5min以上。很急，等到切回来我的上下文也是要恢复滴- 模型质量不足。连我这个python菜鸡都看不下去了，写的啥啊，应该主要是业务太复杂了罢。。。- prompt与前期准备工作占到了单一需求开发全流程的 60% 以上。不是说不能接受，就是有些别扭，明明有这些时间写文档，自己写也写完了（如果是java的话）：评价- 当然JAVA工作的话，主要还是修修补补为主，不是这种“一口气，一把梭”的情况。。。同时，负责的业务场景很复杂，项目文档建设非常落后，最近commit冲突的量级是以k来统计的 --我没有信心让AI来帮我做这些- 我能够接受这种合作方式，我认为自己不是AI的奴隶，同时暂时很难取代，我上面所述的工作拆解与指挥领导的这一步- 后面我会拥抱 Codex 的生态，然后把项目的文档都补充建设起来- 当然，我也明白，

目前大一下学期，刚开始学黑马点评，但是总是在网上看到学院本路边一条，根本进不了面，反正看到就很难受吧，幻想着努力能进个中厂，难道学院本就要被饿死吗