基于简历逐点推演，涵盖转型动机、产品认知、AI技术、排障能力、自驱学习五大模块
开场必问 · 决定面试官对你的第一印象
回答框架（触发→认知→行动→目标）：
最早接触GPT只是玩玩，要翻墙要付费就没深入。后来用豆包、文心一言，感觉质量差。真正转折点是DeepSeek火的那阵——它把思考过程展示出来了，我发现我能根据推理链去判断回答的可靠性。这个体验让我意识到AI不是黑箱玩具，是能理解、能深入的技术。
加上售后5年做到域名专项，技术深度的天花板已经看到了，但AI产品方向的天花板还看不到顶。所以我选择主动转，而不是等被动淘汰。
短期：AI产品的技术支持——帮用户用好Buddy，解决使用中的问题，把用户反馈翻译成产研能理解的需求。
中期：随着对产品和技术理解加深，逐步参与产品方案设计，成为能和研发对齐、和客户沟通、能出方案的人。
不急着给自己贴标签说"我要做PM"或"我要做技术"，先把事做好，路径自然清晰。
| 维度 | 我的回答 |
|---|---|
| 优势 | 5年一线面对客户——我知道用户真正卡在哪、怎么表达才能让他听懂。很多PM设计功能时不知道用户会怎么犯错，我太知道了。 |
| 短板 | AI原理的系统性——我现在能讲清Token、采样、训练三阶段、幻觉机制，但Transformer内部计算和模型训练的工程细节还在学。我的策略是"学到产品决策够用的深度"，不追求变成算法工程师。 |
核心考察区 · 证明你不只是会用，而是懂产品
最深度的使用是用WorkBuddy搭建了一个个人知识库站点。整个流程：用WorkBuddy生成面试准备文档（8份HTML报告）→ 调用server-ssh skill连接我的广州轻量服务器 → Nginx配置 → SSL证书自动续期 → 部署到buddy.lezequan.online。
这个过程中我体验了Skill的触发和编排、Shell命令执行、文件生成等核心能力。不是简单问答，是把WorkBuddy当成协作工具完成了一整个项目。
触发机制：Skill本质是一个SKILL.md文件，里面定义了触发词（description字段）、可用工具（allowed-tools）、执行逻辑。当用户输入匹配到description中的关键词时，系统自动加载Skill的指令到上下文里，相当于给模型"装上了专业知识"。
配置过的Skill：
| Skill名称 | 功能 |
|---|---|
| domain-diagnostics | 域名全面诊断（DNS/HTTP/SSL/端口） |
| server-ssh | SSH连接广州轻量服务器 |
| buddy-docs-site | 知识库站点内容管理与部署 |
| tencentcloud-ops | 腾讯云运维操作手册 |
| cross-task-sync | 跨任务记忆同步 |
遇到的坑：
1. Skill不触发——排查发现description写得不够精准，关键词没覆盖用户的表述。解决：增加同义词覆盖。
2. Skill之间职责重叠——触发了错误的Skill。解决：明确每个Skill的边界，调整description使其互斥。
3. allowed-tools限制导致Skill内无法执行某些操作——需要在SKILL.md中正确声明所需工具列表。
用过的：腾讯文档MCP连接器，在对话中直接创建文档、读取内容、上传图片。
MCP解决的核心问题：让AI模型能安全地调用外部服务。
和传统API的关键区别：
| 维度 | 传统API | MCP协议 |
|---|---|---|
| 调用者 | 代码调代码（程序员写逻辑） | 模型调工具（AI自己决定何时调什么） |
| 接入方式 | 写代码集成 | 配置文件（mcp.json）声明式接入 |
| 安全机制 | 靠代码逻辑控制 | 协议层内置权限+confirm确认机制 |
| 通用性 | 每个API自己一套格式 | 统一协议，一个标准适配所有服务 |
核心问题：AI对话是无状态的——每次新对话模型什么都不记得。Memory让跨会话的信息能持久化。
WorkBuddy的实现：以Markdown文件存储，分为日志型（按日期记录当天做了什么）和长期型（MEMORY.md汇总用户偏好、项目约定等）。每次新对话启动时读取Memory文件恢复上下文。
如果让我设计，三层架构：
| 层级 | 内容 | 更新频率 |
|---|---|---|
| 事实层 | 用户固定信息（名字、城市、偏好） | 几乎不变 |
| 工作层 | 当前在做什么、进度到哪 | 频繁更新 |
| 历史层 | 重要结论和决策 | 按时间归档，定期蒸馏压缩 |
问题1：对话过长后token爆炸
现象：聊得越久越慢越贵，但用户不知道什么时候该清空。
方案：加"上下文健康度"指示器，快满时主动提醒，清空前自动把关键信息写入Memory。
问题2：Skill触发不符合预期
现象：用户以为说了关键词就会触发，结果没有。
方案：Skill未触发时给一个"你是不是想用XX功能？"的建议提示，降低用户困惑。
问题3：跨任务信息孤岛
现象：A任务里做的决策，B任务不知道。
方案：全局Memory层 + 跨任务同步机制（我实际开发了cross-task-sync skill解决此问题）。
| 维度 | CodeBuddy | WorkBuddy |
|---|---|---|
| 核心用户 | 开发者 | 知识工作者（PM/运营/所有人） |
| 核心场景 | IDE内写代码、调试、代码审查 | 桌面端通用任务（文档/数据/运维/调研） |
| 交互方式 | 嵌入IDE，inline补全+对话 | 独立桌面应用，对话+Agent执行 |
| 本质定位 | 开发者的AI结对编程伙伴 | 通用型桌面AI Agent |
| 共同点 | Buddy体系，共享Skill/MCP/Memory底层能力架构 | |
产研深挖区 · 证明你不是嘴上说学，而是真的懂
幻觉不是bug，是LLM正常工作方式的副产品。
模型的任务是"预测最可能的下一个token"，不是"查事实"。当它遇到不确定的问题时，不会停下来——它会继续生成一个"听起来最合理"的答案。
为什么难以根除：训练数据里很少有"我不知道"这种表述，模型从概率上就不倾向生成这几个字。
连锁效应：一旦编了第一步，后面的推理会基于编的内容继续，形成一套逻辑自洽的谎言——这比随机乱码更危险。
Token是模型处理文本的最小单位，通过BPE（Byte Pair Encoding）算法按字符频率切分。不是字，不是词，是介于两者之间的"子词片段"。
中文消耗多的原因：主流模型用英文语料为主训练BPE词汇表，中文词汇表偏小。同样的意思中文可能多消耗30-50%的token。
产品影响：
1. 成本：API按token计费，中文产品天然成本更高
2. 速度：token越多推理越慢
3. 竞品差异：DeepSeek等国产模型扩大中文词汇表，同等内容消耗更少token——这是竞争优势
4. 对话设计：历史消息累积导致token爆炸，需要压缩/摘要策略
定义：上下文窗口 = 模型一次能"看到"的最大token数。128K窗口约等于一本10万字的书。超出窗口的内容模型直接看不到——不是遗忘，是根本不存在于输入里。
满了的后果：早期的对话内容被截断丢弃，模型"失忆"。
产品层面的应对：
| 方案 | 做法 | 权衡 |
|---|---|---|
| 对话摘要 | 把早期历史压缩成简短总结 | 可能丢失细节 |
| Memory持久化 | 关键信息写入文件，不依赖窗口 | 需要设计什么值得记 |
| 滑动窗口 | 只保留最近N轮对话 | 简单粗暴但可能丢关键上下文 |
| RAG检索 | 需要时实时检索，不全塞进去 | 增加系统复杂度和延迟 |
RAG = Retrieval-Augmented Generation（检索增强生成）
流程：用户问问题 → 先从知识库检索相关文档 → 把文档塞进prompt → 模型基于文档回答。
什么时候需要RAG：
| 需要RAG | 不需要RAG |
|---|---|
| 公司内部文档 | 通用知识问答 |
| 最新资料（训练后的事） | 创意生成/写作 |
| 专有数据/私有知识 | 代码编写 |
| 需要引用来源的场景 | 逻辑推理/数学 |
核心区别：
普通对话 = 你问我答，一个来回结束。
Agent = 你给目标，我自己规划步骤、调用工具、多轮执行、直到完成。
Agent四大核心能力：
| 能力 | 含义 | Buddy中的体现 |
|---|---|---|
| Planning | 把大目标拆成小步骤 | Plan模式、任务分解 |
| Tool Use | 调用外部工具执行操作 | Skill/MCP/Bash/文件操作 |
| Memory | 跨会话记住关键信息 | Memory文件系统 |
| Reflection | 执行后检查结果、纠错 | Agent循环中的观察→调整 |
硬实力验证 · 5年一线经验的体现
排查步骤：
1. 确认Skill文件存在且路径正确（~/.workbuddy/skills/xxx/SKILL.md）
2. 检查SKILL.md的description字段——触发词是否覆盖了用户的表述方式
3. 检查是否有其他Skill的description冲突（优先级抢占）
4. 检查allowed-tools是否限制了需要的工具
5. 看agent_created标记是否正确
具体案例：域名诊断Skill不触发——原因是description里只写了"域名诊断"，但我输入的是"检查一下这个域名"，关键词没命中。加了"检查域名"、"域名健康"、"域名排查"等同义词后解决。
分层排查思路：
1. 配置层：检查mcp.json——command、args、env是否正确填写
2. 状态层：看connector-status——connected还是disconnected
3. 认证层：token/credentials是否过期或缺失
4. 网络层：能否访问目标服务（防火墙/网络策略）
5. 错误层：看具体报错——认证失败 vs 连接超时 vs 参数错误是不同问题
标准分层排查流程：
1. 确认范围：所有人打不开还是只有他？（全局故障 vs 个人网络问题）
2. DNS层：域名解析是否正常？nslookup/dig看解析结果是否指向正确IP
3. 网络层：ping目标IP通不通？traceroute看哪一跳断了
4. 端口层：80/443端口是否开放？telnet测试
5. SSL层：证书是否过期？是否匹配域名？是否被中间设备拦截？
6. 应用层：Nginx/Apache是否在运行？配置是否正确？
7. 反馈：定位到原因后给解决方案 + 预计恢复时间
三面文化匹配 · 证明你值得培养
内容分三类：
| 分类 | 内容 |
|---|---|
| 面试类 | 产品认知/技术理解的深度报告、反问策略 |
| 原理类 | LLM基础/Skill机制/MCP协议学习笔记 |
| 复盘类 | 使用中踩的坑和解决方案 |
为什么搭：
1. "学的东西如果不沉淀就会忘"——对话会清空，但站点一直在
2. 验证自己能用Buddy完成一个从0到部署的完整项目——证明不只是会聊天，还会用它做事
| 程度 | 内容 |
|---|---|
| 懂了能讲 | Token/BPE/采样策略(Temperature/Top-P)/训练三阶段/幻觉本质与产品应对 |
| 概念清晰 | RAG/Agent/Skill/MCP/Memory的定义、用途和互相关系 |
| 在学中 | Transformer内部机制（Attention计算）、Embedding、向量检索 |
| 待学 | 训练工程、模型部署、推理优化的底层实现 |
学习策略："产品决策驱动的深度"——每个知识点学到能判断"这个场景该不该用、用了有什么风险"就够了，不追求自己能训练模型。
用域名专项的真实经历回答：
我从KA大客户一线转域名专项就是这种情况。KA的域名问题占比不到1%，转过去相当于全新领域。
我的做法：
1. 第1周：通读所有内部文档+历史工单，建立问题分类框架
2. 第2周：找域名方向老同事取经，要了"排障口诀"（高频问题快速判断路径）
3. 前2周每个工单记笔记，总结成自己的FAQ
4. 1个月独立处理，3个月成为方向主力
迁移到新模块的策略：先读文档建框架 → 找做过的人取经 → 实操中学 → 沉淀成文档。和学AI的路径完全一致——我现在学AI就是这么做的。