另一段实习与行为面

地质大队实习对应代码暂未定位。本章以简历中的“多阶段会话状态机、快照与增量恢复、Vue 3 与 Python 联调”为边界。技术答案描述合理设计，不把未核实的数据库、消息队列、用户规模或并发机制写成你的既有成果。

行为面和 HR 面没有唯一正确话术。下面给出诚实、可核验的回答结构；方括号内容需要你补充，不能照着空白模板背诵。

1 追问树

I1 地质大队实习具体做什么
├─ I1.1 为什么要用状态机
│  └─ I1.1.1 工具确认能否被旧页面重复提交
└─ I1.2 快照和 Chunk 各包含什么
   ├─ I1.2.1 恢复时出现重复或缺口怎么办
   │  └─ I1.2.1.1 前端重放能否再次执行工具
   └─ I1.2.2 页面状态与后台状态怎样分工
I2 Vue 与 Python 联调最容易错在哪里
├─ I2.1 一次连接中断怎样定位
└─ I2.2 如果当时方案很简单怎么回答
B1 说一次你遇到的困难
├─ B1.1 你如何证明根因而不是猜测
│  └─ B1.1.1 最终没有解决可以讲吗
└─ B1.2 你做出的结果如何核验
B2 说一次团队意见分歧
├─ B2.1 对方坚持自己的方案怎么办
└─ B2.2 最后证明你错了怎么办
B3 多个项目和学业如何安排
├─ B3.1 哪些项目有真实用户
└─ B3.2 为什么没有继续堆功能
C1 为什么投这个岗位
├─ C1.1 Go 岗位需要其他语言能接受吗
└─ C1.2 城市 到岗 实习期限 毕业信息
C2 薪资与其他面试进展
├─ C2.1 目前有没有 offer
└─ C2.2 你的短板是什么
Q1 你有什么想问面试官
├─ Q1.1 对方回答岗位范围很广
└─ Q1.2 对方回答新人会独立负责模块

2 地质大队实习

I1 这段实习具体解决什么问题

参考表达：“这段经历主要涉及 Agent 交互模块。多阶段运行会经历生成、等待工具确认、执行和结果返回，前端需要展示当前阶段，也需要在连接中断后恢复已有内容。我参与了会话状态流转、快照与增量事件的恢复，以及 Vue 3 和 Python 之间的联调。”

这段来自简历，可以作为起点。接着必须补充真实业务对象和职责，例如为哪类内部工作提供交互界面、个人负责前端还是后端哪些部分、是否由指导人员验收。无法回忆时不要临时编一个地质业务流程。

I1.1 为什么需要状态机 多几个布尔值不行吗

**触发：**简历声称“以状态机抽象多阶段会话”。

**参考回答：**互相关联的布尔值容易组成不合法状态，例如同时“已完成”和“等待工具确认”。状态机把可处于的阶段和允许发生的转移写清楚，事件驱动转移，并让非法或迟到事件有明确处理方式。简单项目用枚举加转移函数就足够，不需要引入复杂工作流框架。

可以画出示意：生成中 → 等待确认 → 执行中 → 完成/失败/取消。这是讲解模型，实际状态名称和是否允许重试应按原实现回忆，不要说原项目一定一字不差。

I1.1.1 用户开两个页面 两次点击确认会不会执行两次工具

**触发：**候选人讲到等待确认。

**参考回答：**按钮禁用只防当前页面误点，不是服务器正确性保证。合理方案是为一次待确认操作分配稳定 command/toolCall ID，服务端原子地把“待确认”变成“已认领”，重复确认返回现有状态；取消与确认也必须竞争同一状态条件。若原实现只有前端禁用，应直说它未覆盖多标签页并发，不能事后把数据库 CAS 当成已做成果。

I1.2 会话快照和增量 Chunk 分别是什么

**触发：**候选人提到断线恢复。

**参考回答：**快照表示某一时刻的完整可展示状态，增量只描述之后的变化。若要无缝衔接，快照应带版本或最后事件序号，恢复时只应用大于该位置的增量。这样不用每次把完整历史重新渲染，也能避免把已经进入快照的内容再追加一次。事件至少需要会话/轮次标识、事件身份或序号、类型和载荷。

这不自动意味着当时使用了 Event Sourcing、Redis Stream 或持久日志；先解释逻辑结构，再说实际存储。

I1.2.1 先取快照再订阅 不会漏掉中间一条吗

**触发：**面试官追问恢复竞态。

**参考回答：**会有窗口。可由服务端以快照版本提供后续可重放事件，或先建立订阅并缓冲，再读快照、丢弃不大于快照版本的事件。消费端要去重、检测缺口，无法补齐时重新拉取快照。若当时系统只有单进程内存恢复，就应限定为进程存续期间的重连，而不是进程崩溃后的恢复。

I1.2.1.1 历史事件里有 tool_call 重放会不会再次调用工具

**触发：**候选人说所有事件都会重新应用。

**参考回答：**展示状态的重放与业务命令执行必须分开。Reducer 重建“这个工具已执行并返回结果”的界面事实，不应因为收到历史 tool_call 再产生外部动作。命令只有在服务端验证当前状态、授权和幂等条件后执行。否则断线恢复会从 UI 功能变成重复副作用来源。

I1.2.2 前端是不是只要照着后台状态画页面

**触发：**面试官考察联调边界。

**参考回答：**领域状态应由后台权威确认，例如工具是否被执行、会话是否终止；前端可以有“正在连接”“本地输入未发送”等展示状态。请求超时应显示结果未知或可恢复状态，不应直接推断后台失败。重连后以权威快照校正，保留必要的本地输入，避免旧请求响应覆盖新会话。

I2 Vue 与 Python 联调中最容易出什么错

**参考回答：**事件字段和枚举不一致、把字节片段当完整消息、重复事件重复追加、组件卸载后连接没清理，以及旧会话事件写到新页面。我的具体经历需要选其中真实遇到的一种说明；不能把这些可能性都说成处理过的事故。

I2.1 页面断线了 你怎么确定问题在前端还是后端

**触发：**候选人提到连接故障。

**参考回答：**先看浏览器是否真正发出请求、HTTP 状态和响应类型，再核对后台是否收到、事件是否生成及写出。若网络有数据而页面不更新，检查解析缓冲、事件过滤和状态更新；若服务端已经结束但连接不退，检查终态处理和关闭。按会话 ID 与序号关联，不通过记录整段敏感对话定位问题。

I2.2 这个模块比较简单 会不会没有含金量

**触发：**面试官询问技术复杂度，或你担心项目不够大。

参考回答：“这个模块的规模确实不大，我不会把它包装成分布式平台。它的价值是让我把多阶段状态、异步事件、断线恢复和前后端契约串起来，并完成【真实验收】。对于当时需求，【当时的简单方案】已经足够；如果要跨实例或进程恢复，需要补【确实缺失的持久化与协调】。”

这是合理答案。校招的团队交付和准确表达同样重要，不需要每段实习都堆 Outbox、MQ 和分布式锁。

3 行为面

B1 说一件你遇到的最困难的问题

**参考结构：**情境只用两三句；说明当时目标与限制；重点讲本人如何收集证据、比较方案和执行；最后给结果与仍有的限制。

**可用但需确认亲身参与的素材：**libuv 基线与候选都能编译，却因测试失败集合漂移而 REJECTED。这里有价值的反思是区分“重构破坏行为”和“环境让比较不可信”，并保持程序化验收原则，而不是强行让结果变绿。具体运行信息参见 Agent 实习章节。

如果你未亲自负责这次排查，改用自己真正完成的故事。看到代码或报告不等于参与过排障。

B1.1 你怎么证明根因 而不是换配置后碰巧好了

**触发：**候选人说“发现是某某原因”。

**参考回答：**保留最小复现与失败日志，提出可证伪假设，修改一个相关变量后比较结果，并说明替代解释是否排除。重复试错两次仍无新证据时应增加观测，而不是扩大改动。对不稳定问题需要重复样本和环境记录，单次成功不能证明根因已经消失。

B1.1.1 最后没解决 能拿来讲吗

**触发：**候选人担心结果必须成功。

**参考回答：**可以，但要说清完成了哪些定位、采取了什么控制措施、阻碍是什么以及下一步如何验证。比如证明验证环境不可信后保持拒绝，并交付可复现记录，也是有意义的工程结果。不能把“暂时绕过”表述为“根因修复”。

B1.2 你说效率提升 怎么衡量

**触发：**候选人使用“明显提升”“稳定了”等词。

**参考回答：**需要相同工作量、环境和观察窗口，说明指标来源及样本数。如果没有前后测量，我会改说“消除了某类手工步骤”或“通过某个已定义场景”，不编造提升比例。Agent 总耗时还要区分模型等待、工具执行、编译和重试，否则优化结论无法定位到实际环节。

B2 说一次与同事或同学的设计分歧

参考模板：“我们对【具体方案】有分歧，我关注【风险】，对方关注【成本/进度】。我们用【共同目标】比较方案，并通过【原型/数据/评审】达成【实际决策】。我负责【动作】，结果是【真实结果】。”

不要把对方描述成完全不懂技术的人，也不要虚构冲突。没有尖锐冲突，可以讲一次范围、接口或实现方式的正常协商。

B2.1 对方坚持更简单的实现 你觉得不可靠怎么办

**触发：**候选人强调自己重视设计。

**参考回答：**先明确实际故障概率和后果，给一个最小反例，再比较修复成本。能够在当前范围内用唯一约束或条件更新解决，就不应上复杂平台。如果风险需要取舍，明确限制和后续触发条件，让决策者知情；不是无限阻止交付。

B2.2 最后证明你提出的复杂方案没有必要呢

**触发：**面试官测试可合作性。

**参考回答：**承认假设不成立，简化方案，并保留将来改变的合理边界。技术观点是帮助团队做决定的工具，不是个人身份。回答时最好讲自己确实做过的调整；如果没有实际案例，不把这种原则包装成历史事件。

B3 你同时做很多项目 怎么保证不是每个都只做表面

**参考回答：**按时间列出每个项目的起点、阶段和投入，并区分持续维护、短期验证与暂停。选一个自己能完整负责的纵向链路作证明。不能说所有项目一直同时高速推进，也不要把仓库创建时间当成每天开发时间。

B3.1 这些项目到底有没有人使用

**触发：**面试官核验业务价值。

**参考回答：**如实分为本人使用、少量同学/团队使用、公开部署但没有稳定用户、仅本地验证。人数与用途只填自己确知的事实。没有大规模用户时，可以强调通过可复现故障场景学习了可靠性机制，但不能把它称为生产规模验证。

B3.2 为什么不继续补功能而是关注失败恢复

**触发：**面试官询问技术选择。

**参考回答：**因为当前核心链路如果在超时或进程退出时产生丢失或重复，继续堆功能会放大维护成本。但也要承认可靠性工作必须服务真实需求，不能为了简历主动制造复杂度。说明一个当时确实存在或明确要求处理的失败场景，比泛称“追求高可用”更有说服力。

4 岗位与 HR 面

C1 为什么投我们这个岗位

**参考结构：**先核实岗位的真实职责，再把自己的一个能力与之对应，最后说明希望学习的内容。没有看过具体职位时，不编造对方使用 Go、Kubernetes 或某种架构。

可填表达：“岗位说明中提到【真实职责】，我在【项目】里做过【相关工作】，能够从【一项能力】开始贡献。我希望进一步参与【真实期望】，也想了解团队对校招生前几个月的安排。”

C1.1 入职后需要写 Java 或 Python 能接受吗

**触发：**面试官核验语言偏好与适应性。

**参考回答：**按真实意愿回答。技术上可以说明自己重视后端工程能力与已有团队体系，愿意通过一个小模块和代码评审熟悉新语言；同时可以表达 Go 是当前最熟悉的工具。不要为了得到 offer 承诺自己无法接受的工作方式。

C1.2 到岗时间 城市和实习期限有什么限制

**触发：**HR 核验基本条件。

**参考回答：**明确毕业时间、课程/毕设冲突、可连续到岗时长、每周工作天数、城市偏好与实际限制。有不确定项就写预计与确认时间。简历日期只能说明预期毕业，不足以替你回答到岗承诺。

C2 期望薪资和其他面试进展是什么

**参考回答：**薪资依据具体岗位、城市、总包结构和个人底线讨论，不从这份简历推导一个“应得价”。对其他流程说真实阶段与已知决策时间，不虚构 offer 制造议价条件。尚无明确区间时，可以先了解该校招岗位的统一薪酬结构，再表达自己的合理预期。

C2.1 你是不是拿我们练手 有 offer 吗

**触发：**面试官继续确认意愿。

参考回答：“目前进展是【真实阶段】。我比较看重【真实标准】，这个岗位的【已核实特点】是我认真考虑的原因。若收到结果，我会在【能够承诺的时间】内反馈。”不要批评其他公司，也不做无法保证的唯一选择承诺。

C2.2 你觉得自己的短板是什么

**触发：**面试官评估自我认知。

**参考回答：**选择真实且具体的不足，并给正在采取的动作。例如“做过故障场景验证，但还缺少持续生产负载下的容量与运维经验，我准备通过固定环境压测、保留指标和恢复演练补齐”。只有确实开始做了，才说“正在”；否则说计划。避免把“太追求完美”作为包装式短板。

5 结束与反问

Q1 你有什么想问我的

**参考回答：**优先选一到两个与岗位判断直接相关的问题：“这个岗位前六个月最可能负责哪条业务链路？”“团队希望校招生三个月后能独立完成什么？”“代码评审、发布和故障排查通常怎样协作？”

技术面优先向技术面试官了解工作；薪资、合同和到岗流程可交给 HR。根据时间选择，不把清单全部念完。

Q1.1 对方说业务很多 你还会怎么问

**触发：**回答比较宽泛。

可接续提问：“能否举一个最近由新人参与的需求，从需求确定到上线大致涉及哪些工作？”

**合理的理解方式：**关注实际职责与支持资源，而不是只听技术栈名称。对方不便透露业务细节时，可以问工作流程，不追问保密信息。

Q1.2 对方说新人需要独立负责模块 你如何接话

**触发：**回答涉及独立责任。

可接续提问：“独立负责通常包括需求拆解、数据库设计和发布值守中的哪些部分？前期会有哪些评审或指导机制？”

**合理的理解方式：**校招的成长空间与责任边界需要一起看。独立负责不是无人指导的同义词，也不应只因为听到“独立”就判断岗位好坏。

6 面试前需要你亲自补齐的事实

当面试官问到记不清的实现细节，可以回答：“这个具体常量我不确定，我先说明机制和边界，面后可以核对源码。”这比猜一个数值再为它辩护更可信。