比亚迪员工：工作4年，年薪19万左右，30岁，211本，F3等级，明年后半年，跳槽能涨多少？（附Agent面试题）

看到比亚迪员工这样一则分享。

工作4年，年薪19万左右，30岁，211本，F3等级，明年后半年，跳槽能涨多少？

我认为涨薪有两个关键因素，第一是行业经验，第二个是运气人缘。

在 AI 时代，比亚迪有几个核心业务一定很吃香。

①、天神之眼系统​​：这是比亚迪的高阶智能驾驶辅助系统，支持无图城市 NOA（自动导航辅助驾驶）、高快领航和代客泊车等功能。

②、智能座舱：在 2026 年的智能化战略发布会上，比亚迪发布了专属 AI 智能体“迪迪虾”，主打更拟人、更懂车主的生活秘书体验。

③、AI 基础设施与机器人​​，除了车端，比亚迪还布局了企业级 AI 服务器（液冷散热技术）、自主移动机器人（AMR）以及人形机器人原型机，AI 技术已渗透到研发、制造和物流全场景。

车企绝对是AI落地的一个巨大且典型的场景，并且需求量很大。

为什么？

车载专用 AI 不再只是单纯地优化语音交互，而是基于 Agentic AI 架构的深度联动整车，要打通车控、导航与智驾。

除此之外，工业生产方面还有人形机器人、智能排产调度、AI 视觉质检等。

为了提高研发效率，还要借助 AI Coding 来完善工艺流程。

所以，大家完全可以把自己的野心放大，你能做的，远比你看到的要多。

如果你是一位愿意相信努力、相信过程、相信一步一个脚印、相信自己能在 AI 时代分一杯羹的人，那接下来这份硬核的面经，希望你能认真读一读。

（全文比较肝，保证大家能学到很多很多，系好安全带，我们粗粗粗粗发～）

content

PS：PaiCLI 是一个类 Claude Code 的终端 Agent，已开源。如果想拥有一个 Agent 项目经验，可以参考。

GitHub: https://github.com/itwanger/PaiCLI-Python

01、工具调用失败处理策略？

会议室的空调开得有点猛，老王进来的时候还捏着一杯热茶，杯壁上印着“技术部 2023 团建”几个字，磨得只剩一半了。

他扫了一眼简历上半页，手指点了点第一个项目名，问道：“工具调用失败了你们怎么处理的？”

“分三种情况。”

“第一种是拒绝策略。工具在执行前就被安全拦截，比如路径守卫检测到文件路径越界，或者命令守卫拦截了 rm -rf 这种危险操作，直接返回拒绝原因，不走执行环节。”

“第二种是执行异常。工具跑了，但报错了——网络超时、API 返回 500、文件不存在，这些都算。”

“第三种是超时。我们设了多层超时——单个命令 60 秒，批量并行 90 秒，搜索类操作 8 秒。超时直接强制终止进程，返回超时提示。”

“三种情况的处理方式是一样的：错误信息格式化成一段文字，作为工具返回结果回传给 LLM。模型拿到错误信息后自己判断下一步——换个参数重试、换一个工具、还是告诉用户做不了。”

为什么不在工具层自动重试？

“因为工具失败的原因千差万别。参数写错了重试一百遍还是错，应该换参数；API 限流了可以等一等再试；文件找不到可能路径拼错了，得先搜一下确认路径。模型拿到具体错误信息，比重试策略判断得更准。”

“LLM 请求本身是有自动重试的——3 次机会，指数退避，500 毫秒起步，最大延迟 30 秒，还加了 ±20% 的随机抖动防止多个请求撞到同一时间窗口。网络波动场景单一，适合自动重试。”

02、你怎么做的模型意图优化？

“两个方向。”

“第一个方向是 Prompt 分层组装。系统提示词一共 9 层，前 4 层是静态的——身份定义、工具定义、安全策略、人格层、模式层、审批层，整个会话期间不变。后 5 层是动态的，运行时上下文、项目记忆、Skills 索引，每轮都会更新。”

“静态层排在最前面有个好处：Prompt Caching 按最长公共前缀命中，前缀越稳定，缓存命中率越高。”

“第二个方向是把意图判断交给 LLM 自己做。每一轮把历史对话和当前输入一起给模型，模型自己判断该检索新内容、基于已有上下文直接回答、还是要求用户澄清。”

为什么不用传统的意图分类器？

“维护成本太高了。每增加一种意图，就得标注一批数据、训练一个分类器、部署上线。Agent 的使用场景变化很快，今天加了新工具明天就有新意图，分类器跟不上迭代速度。”

“LLM 本身就有很强的意图理解能力，直接用它做意图判断，灵活度高得多。遇到判断不准的情况，改 Prompt 就行，不用重新训练模型。”

03、测评的数据是怎么构建的？

老王端起茶杯想喝一口，发现凉了，又放下了。他翻了一页简历，目光在“评测体系”四个字上停了一下：“测评的数据怎么构建的？”

“分三层数据源。”

“第一层是 Golden Set，确定性测试用例。每条用例定义了输入 query、预期命中的文件路径、预期读到的代码片段。目前积累了上百条，跑一遍就知道搜索流程有没有回退。”

“第二层是会话账本。每次对话的完整过程——用户输入、模型推理文本、工具调用参数和返回值——全部以 JSONL 格式追加记录。这份数据不受上下文压缩和历史清理的影响，是真正的原始数据。”

“第三层是审计日志。所有危险工具调用——写文件、执行命令、MCP 工具——都会记一条审计，包含工具名、参数、执行结果（通过/拒绝/报错）、耗时、审批方式。”

“日常使用中发现问题 → 从会话账本里把那次对话的原始数据捞出来 → 人工标注预期结果 → 纳入 Golden Set。每修一个 bug，测试集就多一条用例。”

04、什么样的 prompt 比较好？个人心得？

“四条心得。”

“第一，分层组装。把提示词按关注点拆成独立文件，身份层、模式层、Skill 层各管各的。改 Skill 层的指令不会影响身份层的行为。”

“第二，指令原子化。一条指令只管一件事。'先搜索再读取再总结'拆成三条指令，模型遵循率比一条复合指令高很多。”

“第三，先有评测集再改 Prompt。改之前跑一遍，改之后跑一遍，对比分数。”

05、使用哪些 coding agent？调用量怎么样？

“日常开发 Codex 用得最多，代码生成、重构、review、调试基本都靠它。Claude Code 也会用，主要做架构层面。”

“调用量的话，Codex 高峰的时候一天能用近 10 亿 Token。”

06、你平时 vibe coding 怎么去做交付？

老王把眼镜摘下来，用衬衫下摆擦了擦镜片，又戴回去。

“vibe coding 现在挺火的，你平时怎么拿它做交付？”

“vibe coding 的核心是用自然语言描述需求，让 Agent 生成代码。但 vibe 不等于不验证，交付标准和手写代码一样。”

“我的流程分四步。第一步，需求拆解。把大需求拆成小任务，每个任务的预期输出能用一句话说清楚。任务太大 Agent 容易跑偏。”

“第二步，Agent 生成初版。用 Codex 跑，生成代码和测试。”

“第三步，Claude Code review。重点看三件事：逻辑对不对、有没有安全隐患、和现有代码风格是不是一致。两个 Agent 交叉检查”

“第四步，跑测试。单元测试和集成测试都过了才算交付。测试本身也可以让 Agent 先生成一版，但测试用例的覆盖范围必须人工确认。”

07、memory 模块是你在设计吗？讲一下

老王把简历翻过来看了看背面，又翻回正面，像是在确认什么。他的茶早就凉了，但还是端起来喝了一口——大概是习惯动作，那种坐在工位上写代码写到一半，随手摸杯子的习惯。

“Memory 这块是你设计的？”他放下茶杯的时候手顺便指了一下简历上的项目描述。

“是的，整体是双层记忆架构——短期记忆和长期记忆。上面有一个统一的记忆管理器做入口，不管是读记忆还是写记忆，外部都通过这个管理器来操作，不直接碰底层的短期和长期存储。”

“短期记忆负责当前会话的上下文。数据结构是一个有序 Map，每条消息按时间顺序存进去，包括用户输入、模型回复、工具调用结果。有 token 预算限制，超了就按 FIFO 淘汰最旧的条目。”

“长期记忆负责跨会话持久化。用户说'记住这个'或者'记一下'的时候，通过工具把信息存下来，持久化成 JSON 文件。每条记忆有类型、作用域（项目级或全局）、时间戳。”

“每轮 LLM 调用前，记忆管理器会根据用户当前说的话，去长期记忆里找有没有相关的内容，找到了就注入到系统提示词里。检索方式是关键词匹配——先用 Jieba 把用户的输入切成一个个词，然后看每条记忆的内容里有没有包含这些词，包含得越多，相关度越高。没用向量检索。”

为什么不用 Embedding 做语义检索？

“因为长期记忆的量级不大。一个用户积累下来，可能也就几十条到几百条记忆。这个数据量用关键词匹配就够了，准确率也不低。”

“上 Embedding 意味着多一个向量数据库的依赖，每次存取都要跑一次 Embedding 模型。对于一个终端工具来说，部署复杂度和响应延迟都会明显增加，收益和成本不成比例。”

08、短期中期长期记忆的设计思路？

“说实话，我们目前做的是两层——短期记忆和长期记忆，没有独立的中期记忆层。”

“短期记忆是会话级的，生命周期跟着会话走。数据存在内存里，有序 Map，按插入顺序排列。每条消息进来会估算 token 数——中文差不多 1.5 个字符一个 token，英文大约 4 个字符一个 token。总 token 数超过预算就触发压缩。”

“压缩不是直接扔掉，是用 LLM 做一轮摘要。算法是 Map-Reduce：先把旧消息按 5 条一组分块，每块单独摘要，最后把所有块摘要合并成一个总摘要。最近 3 轮对话不压缩，保证模型对当前话题有完整记忆。”

“长期记忆是跨会话持久化的。用户说'记住'或者'记一下'的时候触发保存，持久化成 JSON 文件。每条记忆有个 scope 字段，值是 project 或者 global。project 作用域的记忆只在对应项目下可见，global 作用域的记忆在所有项目下都能检索到。”

“你可以把 project 作用域理解成一种'项目级记忆'，但它和 global 记忆共用同一套存储和检索机制，只是可见性不同，本质上还是一层。”

短期到长期怎么流转？

“发生在对话压缩的时候。压缩不只是把旧消息缩成摘要，还会从对话历史里把那些以后还用得上的稳定信息挑出来，写进长期记忆。”

“具体来说，压缩的时候会额外跑一轮事实提取——从对话内容里挑出稳定的事实，过滤掉临时性的信息。带'可能''推测'这类不确定词的内容不要，'用户想做什么''当前正在处理'这种临时性任务描述也不要，只保留确认的、可跨会话复用的事实。”

“写入时自动判断作用域。跟当前项目强相关的信息标记为 project，通用偏好标记为 global。”

09、记忆写入更新策略是怎么样的？

“写入分两种触发方式。”

“第一种是显式触发。用户说'记住''记一下''帮我记下来'，模型调用保存记忆的工具，把信息存进长期记忆。工具设计上刻意做了限制——必须用户明确表达保存意图才触发，不会偷偷记东西。”

“第二种是自动提取。对话压缩的时候，用 LLM 从历史消息里提取稳定事实。提取有过滤规则——带不确定词的内容不要，临时性任务描述不要，只保留确认的、可复用的事实。”

“更新策略的核心是去重。每次写入前，会在同一个领域（类型 + 作用域 + 项目）内做去重检测。去重不是简单的字符串相等——先做 NFKC 归一化、转小写、去标点，但保留有意义的符号（井号、@、百分号、路径分隔符这些），只允许语气词级别的差异通过。”

“效果就是'用户偏好使用 IntelliJ IDEA'和'用户偏好用 IntelliJ IDEA'会被识别为同一条记忆，不会重复存储。但'用户偏好 IntelliJ IDEA'和'用户偏好 VS Code'不会被合并，因为关键信息不同。”

10、三种 memory 的表设计一样吗？字段怎么设计的讲一下？

老王把眼镜推上去看了一眼手表，不是催时间的那种看法，更像是发现聊得比预想的久，自己也觉得有点意外。

“三种 memory 的表结构一样吗？”

“我们目前是两层，短期和长期。两层的数据结构不一样。”

“短期记忆不落表，存在内存里。每条记录有这么几个字段：id 用前缀区分来源，user- 开头的是用户消息，assistant- 开头的是模型回复，tool- 开头的是工具调用结果；content 存文本内容；type 标记类型，分对话、工具结果、摘要三种；再加上 timestamp 和 tokenCount。tokenCount 是估算值，中文按 1.5 字符一个 token，英文按 4 字符一个 token。”

“长期记忆落盘，存成 JSON 文件。每条记录的字段：id 是 fact- 加序号，content 存精炼过的事实文本，type 统一是 FACT，timestamp 用 ISO 8601 格式，加一个 metadata 对象。”

“metadata 里有两个关键字段。scope 标记这条记忆是项目级的还是全局的，值是 project 或 global。project 字段存项目路径，只有 scope 为 project 时才有值。查询的时候靠这两个字段做可见性过滤——全局记忆在所有项目下都能检索到，项目级记忆只在对应项目下可见。”

“如果后续记忆量大到上万条，我会在 metadata 里加 embedding 字段存向量，换成数据库存储，检索从关键词匹配切到近似最近邻检索（ANN）。但当前几百条的量级，JSON 文件加关键词匹配完全够用。”

11、你对 Agent 和 workflow 的看法？

老王往椅背上靠了靠，手里还捏着那杯已经彻底凉透的茶，戒指在日光灯下闪了一下。他换了个坐姿，像是下半场要换个节奏聊了。

“换个方向，Agent 和 workflow 你怎么看？”

“两个东西解决的问题不一样，不能混着比。”

“Agent 的核心能力是自主决策。给它一个目标，它自己判断用什么工具、按什么顺序执行、遇到问题怎么调整。适合开放式任务，比如'帮我调查一下这个 bug'，你不知道要几步才能搞定。”

“Workflow 的核心能力是可控可追溯。流程预先定义好，节点之间的依赖关系是确定的，每一步做什么、数据怎么流转都写死了。适合固定流程的任务，比如'收到用户反馈 → 分类 → 分派 → 处理 → 回复'，每次都是这个顺序。”

“生产中通常混合用。Workflow 做主干，把确定性的流程编排好；Agent 处理主干上那些不确定的环节。”

12、什么样的 Agent 算一个好用的 Agent？

“三个标准：做得对、少打扰、能兜底。”

“做得对是底线。任务完成率要高，给个明确的指令，能把事情做完做对。”

“少打扰是体验。理想的 Agent 在能自主判断的地方自己做决策，只在真正拿不准的时候才问你。如果每一步都弹窗让你确认，那和手动操作没区别。”

“出了错能给你有用的错误信息，能优雅降级，一个工具调用失败不会导致整个任务崩掉。就目前来说，Claude Code 在这三项上做得都很不错，是我用过最稳的终端 Agent。”

13、badcase 分析有什么心得？有做沉淀吗？

老王杯子里的茶已经见了底，他也没再续。看了一眼手表，不是赶时间，倒像是确认一下自己聊了多久——然后嘴角动了一下，大概是对这个时长还算满意。

“最后一个，Badcase 分析这块有什么心得？”

“三步走。”

“第一步是还原现场。Agent 出了问题，你不能凭印象去猜是哪个环节错了，得把那次对话的完整过程重新拉出来看——用户说了什么、模型怎么理解的、调了哪个工具、传了什么参数、工具返回了什么结果。”

“我们有两份数据专门干这个事。一份是会话账本，记录了对话的每一步，包括模型的推理过程和工具调用的细节。另一份是审计日志，专门记录危险操作的执行结果，比如写文件的时候是通过了还是被安全策略拦截了、是用户手动放行的还是自动执行的。两份数据一对，出问题的环节基本就能看出来了。”

“第二步是给每个 Badcase 打一个标签，标记这次失败到底是哪个环节出了问题。比如，是模型理解错了用户的意图，还是工具调用传错了参数，还是工具本身执行的时候报了异常，还是对话太长超出了上下文窗口。一个 Badcase 只打一个主标签——不要同时打两三个，打多了等于没打，你分不清该优先修哪个。”

“第三步是看标签的统计分布。攒够一定数量的 Badcase 之后，哪个类型的失败出现得最多，一目了然，下一轮优化就先集中解决那个类型。同时把这些 Badcase 转成回归测试用例，纳入 Golden Set。每修一个 bug，测试集就多一条用例，保证同样的问题不会再犯。”

PaiCLI 如何写到简历上？

项目名称：PaiCLI — 终端 AI Agent 命令行工具

项目简介：对标 Claude Code 的 Java 版终端 Agent，支持 ReAct、Plan-and-Execute、Multi-Agent Team 三种执行模式，具备多轮对话、工具调用、记忆管理、代码搜索等能力。

核心职责：

• 设计双层记忆系统（短期 + 长期），短期记忆基于 token 预算自动压缩（Map-Reduce 摘要 + 事实提取），长期记忆通过关键词检索注入上下文，支持项目级和全局级作用域隔离
• 实现三级工具调用错误处理机制（策略拦截 → 异常捕获 → 超时终止），错误信息回传 LLM 自主决策重试策略，LLM 请求层支持指数退避重试（3 次，500ms 基础延迟）
• 构建 9 层 Prompt 分层组装器，静态层前置命中 Prompt Caching，动态层按 token 预算裁剪，单次请求 token 成本降低约 35%
• 搭建多层评测体系，维护确定性 Golden Set 回归测试集，结合会话账本原始记录和审计日志，实现 Badcase 全流程溯源和归因打标
• 设计 Skills 渐进式加载体系，采用索引 → 正文 → 参考文档三级按需加载，通过 LRU 缓冲区控制同时激活的 Skill 数量（上限 3 个），避免上下文溢出

ending

有些人觉得AI是洪水猛兽，一直在抵抗。

有些人觉得AI是提效工具，于是不断扩大自己的能力边界。

种一棵树最好的时机是十年前，其次是——

看完这篇内容的这一秒，打开终端，启动 PaiCLI，敲下第一行 prompt。

去跑你的第一个 Agent。

去做你的第一个 Agent。