度小满 AI 全栈研发二面：AI Coding 工作流、长期记忆与多 Agent 闭环

《面试题目》

实习

1. 自我介绍
2. 实习中的 AI Coding 工作流，是部门提供的现成工作流，还是你自己搭建的？
3. 能否拆解一下这个工作流的具体步骤？
4. 在这个工作流中，是否包含了大量人工交互的过程？
5. 有哪些措施可以保证这个工作流运转的顺畅和准确性？
6. 在代码生成阶段，你给 AI 提供了哪些辅助信息，让它能够比较准确地输出你想要的代码？
7. 用于辅助 AI 理解代码架构的文档（TechDoc）是你自己生成的，还是团队的历史积累？
8. 你了解这种文档动态维护的思路或流程吗？
9. 在工作流的测试阶段，怎么保证测试的覆盖度？如何通过测试实现最终的兜底效果？
10. Answer 追问 Query 的「数据埋点」思路是你提出的吗？为什么要设计这三态的逻辑？
11. 对于数据上报，你们有什么措施来保证上报的质量和成功率？
12. 假设基础设施没那么好，需要你额外去设计一套数据上报机制，你会采取哪些举措？
13. 如果设计了重试机制，数据其实已经传上去了，但因为网络问题没收到 ACK 导致了重复上传（数据重复），这个问题你会怎么解决？
14. 多模型切换重答功能，是系统自动切换的，还是用户可选的？
15. 在多模型切换中，你负责搭建的状态机主要起到了什么作用？
16. 切换模型进行重答时，会把上一个模型的上下文也带过去吗？
17. 不同的模型上下文窗口大小不一样，如果从一个大窗口模型切换到一个小窗口模型（上下文不够用），你们是怎么处理的？
18. 长期记忆裁剪具体是指什么？
19. 除了重复对话的精简，从短期记忆提取到长期记忆的逻辑是怎样的？系统是怎么判断哪些内容应该进入长期记忆的？
20. 如果提取新记忆时发现与历史长期记忆有冲突（例如：以前说喜欢某样东西，现在说不喜欢了），有什么解决冲突的逻辑？
21. 项目中是如何通过耗时监控具体定位到性能瓶颈的？请讲一下你的分析思路。
22. 渲染任务中，是不是有些任务实际是可以并行的，但原本被写成了串行？你是如何处理的？
23. 你们的测试框架能够根据当前的需求，动态生成测试 Case 吗？
24. 怎么评估测试 Case 的覆盖度？跑完测试后的结果比对（验证正确性）也是由 AI 来做的吗？
25. 实际去跑测试的 Agent 和负责验证结果正确性的 Agent，是同一个还是相互隔离的？
26. 既然设计了多个 Agent，它们之间有实现协同吗？还是需要人工干预传递数据？
27. 如果最后负责验证的 Agent 发现测试结果不对，它会自动反馈给前面的步骤，让它重新写代码并重新测试吗（是否实现了自动闭环）？

反问

28. 后续还有流程吗？（问 HR）

《参考解析》

1. 「工作流是你搭的还是部门现成的」这类问题，答法决定整场面试的走向：最稳的结构是先给归属（哪部分是团队已有的、哪部分是我做的），再给边界（我负责的是哪几个环节、和谁协作），最后给证据（具体的产出、上线后的使用情况、遇到的问题）。拆解步骤时按「需求理解 → 方案设计 → 代码生成 → 自测 → 评审」分段，每段说清输入是什么、模型负责什么、人卡在哪一步。被追问「有多少人工交互」时不要粉饰——现阶段 AI Coding 一定是人机协作，关键是说清哪些环节必须人确认（接口契约、数据库变更、权限与安全）以及为什么。

2. 保证工作流顺畅与准确，靠的是上下文供给和验证卡点，不是更会写提示词：上下文侧包括把相关代码文件、接口定义、目录结构与既有约定喂给模型，用 TechDoc 这类架构文档补足模型看不到的整体设计；约束侧要求最小改动、明确禁止改动的范围、固定输出模板（问题定位、修改位置、改前改后）；验证侧必须有可执行的卡点——编译、静态检查、单测、集成测试，模型说了不算。TechDoc 的动态维护通常有两种思路：一是随代码评审同步更新（改动涉及架构或接口时必须带文档变更，否则不予合并），二是定期用脚本或 AI 对比代码与文档的差异并生成待确认的更新清单，人工审核后入库。被问到「了解这种思路吗」时，答「文档和代码同源、更新动作挂到已有的流程节点上，而不是靠人自觉」是加分项。

3. 数据上报的质量和成功率，以及重复上传，要答成一条完整链路：上报侧做批量合并、本地落盘缓冲（进程崩溃可恢复）、异步发送不阻塞主流程、失败重试加退避与上限、采样与降级（高峰期限流，保证核心事件优先）。成功率要有观测：上报量、失败率、端到端延迟这几个指标，并做对账（服务端收到量与客户端发送量比对）。重复上传是重试机制的必然产物——客户端没收到 ACK 就无法区分「没发出去」还是「发出去但响应丢了」，所以去重只能放在服务端：每条事件带上全局唯一的 eventId（客户端生成 UUID 或业务主键），服务端按 eventId 做幂等写入（唯一索引或 Redis 去重窗口），重复的直接丢弃并正常返回成功。如果业务要求「至少一次」，就接受重复但保证幂等；要求「恰好一次」，就必须有服务端去重加客户端确认位点。

4. 多模型切换的状态机，本质是把「切换中的会话」变成一个明确的状态集合：典型状态有「空闲」「生成中」「已中断」「重答中」「已切换」，事件是用户动作（中断、切换模型、重答）与系统事件（流结束、超时、失败）。状态机的价值有三个：防止非法转移（生成中直接切模型导致两路输出同时写回）、明确资源回收（旧请求要取消、旧连接要释放）、以及给前端一个确定的状态用于渲染按钮可用性。回答时补一条实现细节——状态用 Redis 存、转移用校验后原子更新（Lua 或乐观锁版本号），这样并发的两个操作只会有一个成功。

5. 大窗口模型切到小窗口模型，处理上下文超限的优先级要讲清楚：不能简单截断最早的消息，那会丢掉最初的约束和任务目标。合理的顺序是先固定「永远保留」的部分（system prompt、任务目标与关键约束、最近 N 轮原文），对中间历史做压缩摘要（用模型把多轮对话压成结构化要点），再按需召回长期记忆或检索相关片段填充剩余预算；同时给目标模型留出输出空间（输入预算要按上限减去 max_tokens）。工程上还要在切换前预估 token 数并做校验，超了就降级策略（摘要、丢弃工具返回值的大段原文、只保留结论）。跨模型切换时历史消息格式要重新组装，把上一家的响应对象直接塞给下一家是最常见的翻车点。

6. 长期记忆的提取与冲突消解，是记忆系统的两个核心问题：提取的触发点通常是「会话结束」「话题切换」或「积累到一定轮数」，由模型从对话中抽取候选事实（用户偏好、背景、约定），再按稳定性和可复用性打标签：长期有效的（身份、地域、习惯偏好）入库，一次性的（本次订单号、临时需求）不进。写入前要做去重与置信度判断，低置信度的先挂「待确认」。冲突消解不能只靠覆盖：更稳的做法是给记忆加上时间戳与来源，检测到新事实与旧事实矛盾时按「时间近的优先 + 显式确认优先」更新，同时把旧值标记为失效而不是物理删除，便于回溯；如果矛盾涉及对用户偏好这类主观信息，最好的做法是在对话中主动确认一次（「上次你说喜欢 A，现在改成 B 了吗」）。这里面试官往往想确认你有没有意识到「记忆矛盾不只是数据问题，还是产品体验问题」。

7. 多 Agent 协同与验证闭环，要如实回答成熟度：比较合理的架构是执行与验证分离——执行 Agent 负责改代码、跑测试，验证 Agent 独立判断结果是否符合预期（只看需求与产物，不看执行过程的解释，避免被同一套上下文带偏），两者通过任务状态与结构化产物通信，而不是靠自由文本互相说服。是否自动闭环取决于风险：低风险、可自动验证的任务（单测通过与否）可以自动退回重跑，并设置最大轮次与熔断（同一问题连续失败三次就转人工）；涉及业务语义或线上变更的必须有人确认。回答时把「哪些能自动、哪些必须人工、失败了怎么收敛」讲清楚，比宣称「全自动闭环」更可信。

8. 耗时监控、串行改并行与测试覆盖度，三条都指向同一件事：可观测：定位瓶颈的做法是先分段埋点（请求进入、模型调用、工具调用、渲染、写库各段耗时），用 Trace 把一次请求串起来，看的是 P95/P99 而不是均值，再按维度下钻（哪个工具最慢、哪个模型最慢、哪个租户最慢），最后用火焰图或时间线看串行等待在哪里。发现可并行的任务被串行写死，处理方式是梳理依赖关系，把无依赖的调用改成并发（线程池或 CompletableFuture），同时限定并发度、加超时与降级，避免并行把下游打挂；有依赖的则考虑拆成两阶段或流水线。测试覆盖度不能只看行覆盖率，要按需求点与分支覆盖、异常与边界用例是否齐全来评估，并统计「AI 生成的用例被采纳了多少、补了多少人工用例」这类指标；让 AI 做结果比对是可行的，但要有确定性的断言作为真值，且验证 Agent 与执行 Agent 分离，否则会变成「自己批改自己的卷子」。