大厂前端是不是基本都是react，简历都是vue能过简历吗，需要改一个react项目吗

看了那么多大佬的手撕分享，都是只有题目，练习起来很麻烦，得自己在本地实现函数，创建测试用例，再去运行js，我干脆直接自己做一个类似力扣的核心代码模式的js手撕练习，比力扣还多了代码补全。当前手撕题库中有50多个手撕题，后续会补充更多题目，也希望大家给主包分享题目和用例。（这里我其实不是很理解，代码补全没那么难做，但为啥力扣没做呢）

自我介绍 学前端多久了 用过什么AI cursor的贡献量 var let 变量函数作用域 代码输出var count = 2; a(){ return count + 1; } fn1(){ var count =1; a(); }proptotype原型链，对象 代码输出题 fn(){ this.a=1; return {a=2;b=3} } fn.prototype.a=6; fn.prototype.b=7; fn.prototype.c=8 obj = new fn(); obj的abc？讲讲promiseTS泛型 接口 type区别手写new手写 TS pick手写 JS prom...

在简历中体现你的AI能力：以RAG为例的实战指南简历中写AI项目，很多人会犯“堆砌技术栈”的错误，比如：“使用LangChain、FAISS、GPT实现RAG系统”这会让面试官疑惑：你究竟解决了什么问题？ 以下是让RAG项目脱颖而出的写法。—————🔍 RAG解决的四大核心问题1. 知识时效性：解决“模型知识过时”• 问题：LLM训练数据有截止日期（如GPT-4到2023年4月），无法获取新知识• RAG方案：实时检索外部知识库，注入最新信息• 案例：回答“今天天气”、“最新财报”、“实时股价”2. 知识准确性：解决“模型幻觉”• 问题：LLM会自信地编造事实（“奥巴马生于肯尼亚”）• RAG方案：基于可验证的文档生成，提供引用来源• 效果：幻觉率降低40-60%，答案可追溯3. 知识专有性：解决“私有数据缺失”• 问题：LLM没有企业私有知识（内部文档、代码库、客户数据）• RAG方案：建立私有知识向量库，实现个性化问答• 应用：企业知识库、技术支持、代码文档查询4. 上下文限制：解决“长文本处理瓶颈”• 问题：模型上下文窗口有限（即使128K，也难记住海量信息）• RAG方案：从海量文档中检索相关片段，只输入关键信息• 优势：理论上支持无限知识库，成本可控------📄 简历写法对比❌ 传统写法（模糊）智能问答系统• 使用LangChain框架构建RAG系统• 基于FAISS实现向量检索• 调用GPT-4进行答案生成✅ 进阶写法（量化+难点）企业知识库AI助手（日活5000+，准确率92%）• 从0到1构建多模态RAG系统，支持PDF/PPT/Excel文档解析，检索准确率提升35%• 针对行业术语，采用HyDE + Query Rewriting方案，解决60%的“检索不相关”问题• 设计Agentic RAG架构，让LLM自主判断“是否需要检索”，无效查询降低40%• 引入Rerank模型对Top-20结果重排序，首条命中率从45%提升至78%技术细节：LangChain（编排）｜ Chroma（向量库）｜ BGE-M3（嵌入模型）｜ bge-reranker-v2-m3（重排序）｜ GPT-4（生成）｜ 成本：$0.12/query------🎯 面试官想看到的3个层次1. 基础能力：你懂RAG流程• 解析文档 → 分块 → 向量化 → 检索 → 重排序 → 生成• 加分项：能说出不同分块策略（语义分块、递归分块）的适用场景2. 进阶能力：你解决过真实问题常见问题解决方案可量化结果检索不相关Query Rewriting + HyDE准确率↑30%长文档丢失信息父文档检索 + 摘要嵌入召回率↑25%上下文过长滑动窗口 + 渐进加载Token成本↓40%事实性错误Self-RAG + 引用校验幻觉率↓50%3. 架构思维：你有工程化视角• 成本控制：RAG调用次数 vs. 直接问LLM的平衡点• 缓存策略：对热点Query缓存嵌入结果• 监控体系：准确率、Token使用、延迟的Dashboard------📈 如何量化你的贡献？用“问题→方案→结果”的公式：“发现检索不相关问题（问题）→ 引入BGE重排序模型+Query扩展（方案）→ 首条命中率从50%提升至85%（结果）”可量化的维度：• 性能：准确率/召回率、响应时间、Token消耗• 业务：用户满意度、日活增长、问题解决率• 成本：月度API费用、计算资源节省------🏆 高级进阶：Agentic RAG如果你做过更前沿的，可以突出：自主检索Agent系统• 改造传统RAG为Agent决策模式，让LLM判断“何时检索”、“检索什么”• 基于ReAct框架设计“检索→分析→决策”链，复杂问题解决率提升60%• 实现多轮追问能力，通过历史会话自动优化检索策略------📌 一句话总结“不要告诉面试官你用了什么工具，而是告诉他们你解决了什么问题，以及如何证明你解决得好。”在简历中，每个技术点的背后，都应该对应一个具体的业务问题、一个可量化的改进。这就是你的AI能力最有力的证明。

最近我给一些前端方向的实习生做内推，看了不少简历。投递里常能看出一种预设，找实习只要把前端做熟，页面和接口能啃下来，似乎就踩对了主线。初筛读多了会有另一种感受，当业务和岗位已经大量贴上大模型、RAG 或 Agent 时，纯前端技术栈写得再工整，也很难在一叠写法雷同的简历里单独把人托起来。我想写的不是简历技巧，评审更常问的是，你有没有把智能接进一条可维护、可观测、也能和人协作的链路，还是只在项目名里多写几个关键词。许多项目经历段落，技术名词很全，叙事却薄。写得多的几种模式是：周期很短，却同时堆上 RAG、流式输出、鉴权与复杂治理，读者很难估计真实投入与掌握深度段落像功能清单，缺少场景、难点、个人...