理想汽车IT全栈交付培养生一面：Coding Agent 与 AI 流水线深挖

《面试题目》

1. 请做一下自我介绍。
2. 你大概是从什么时候开始用 Coding Agent 的？
3. 你在百度提到用 Codex 和 Claude，它们是走订阅还是走 API，具体是什么样的？
4. 实习公司都有内部 AI 工具吗？这些工具提供了哪些额外的功能或能力？
5. 你用 Coding Agent 快一年了，从一开始到现在、不同模型和不同工具，你实际的体感是什么样的？
6. 这些实习经历里你涉及的仓库多吗？哪些项目是你自己完成的，哪些是团队协作开发的？
7. 团队协同开发过程中，你们的共享知识库大概是怎么维护的？Skill 这一类东西又是怎么维护的？
8. 每个公司都有 Skill Hub，那用得好的 Skill 怎么放上去，使用者看到好的 Skill 怎么拉下来用？
9. 当你要维护十几个、二十几个 repo 的时候，不同项目的背景知识怎么做维护和积累、又怎么共享？
10. 怎么让 Agent 后面能做得更好——这些东西怎么沉淀和共享，才能避免每开一个新任务都要跟 AI 说一大堆背景？
11. 你用过一些外部的插件吗？比如知识图谱、RAG 或者 Memory 这一类，这块你有用到过吗？
12. 你用 AI 工具时，人在整个开发过程中主要参与哪些环节？哪些环节还需要比较多的干预？
13. 你说 ai-pipeline 这个流程里人只需要在关键节点做决策，那关键节点怎么定义？它会给你发消息，还是停下来，还是怎么样？这里是怎么设计的？
14. 你的测试和验收环节呢？
15. 你 generate 之后跑的这个测试是单元测试，还是整体的集成测试？
16. 端到端的测试跑一轮一般多长时间？
17. 说一下你一般使用 AI 开发的完整流程？SDD 是怎么用的？
18. 还是依赖人工测试是吗？为什么不让 Agent 去测试？你人工做的事情，AI Agent 为什么不能做？这里有哪些卡点，是什么原因？
19. 你提到的端到端这些需要注意的细节，有没有可能通过什么方式告诉 Agent？
20. 你提到 ai-pipeline 里有一个自洽的功能，发现了代码问题之后要怎么变成新的规则，怎么反哺 ai-pipeline 的自进化？
21. 代码不符合引擎规范，AI 是怎么发现的？它什么时候找到这个问题，还是有什么东西去采集去抓？
22. 你说的这个 ai-pipeline 最后是一个平台，还是一套 Skill，还是什么东西（git submodule 或者一个插件）？
23. 你有用过 Claude 或者 Codex 的插件吗？
24. 你了解它们有哪些类似插件的方式或者说插件机制吗？
25. MCP 和 Skill 有哪些差异？什么时候用 MCP，什么时候用 Skill？
26. 从日常使用来看，二者有哪些区别？它们在上下文方面有什么差异？
27. 你说 Skills 是直接插入上下文的，那整个 Skill 文件一开始就会全部读进去吗？
28. 你在百度那边做的事情，有什么感觉有挑战的地方吗？
29. 一般出一次数大概耗时是什么样的？数据大概是一个什么量级？
30. 你有用到 Temporal 引擎，这个是你引入的还是他们本来就有的？
31. 你具体是怎么用的？Workflow 和 Activity 如何拆分、分别负责什么？大概有多少 Activity？
32. 是根据什么来拆分 Activity 的，为什么？
33. 为什么品牌筛选要分成两步（大品牌粗筛和子品牌细粒度筛选）？
34. 数据查询是从什么平台查的？
35. 你目前的 offer 情况怎么样？
36. 你有什么想问我的？

《参考解析》

Coding Agent 的落地体感：订阅与 API、内部工具、人的位置

订阅还是 API 不是习惯问题而是约束问题：订阅按时间窗口给额度（额度滚动、超了要等），成本固定、开箱即用，适合个人探索；API 按 token 计费、能接自己的网关，才做得了密钥统一管理、调用审计、团队配额和多模型路由，公司内网通常只能走这条。面试里被追问时，把「哪类任务用哪个」讲清楚比报一个价格更有说服力。企业内部 AI 工具相对公开产品的额外价值一般是三块：对整个代码库的索引与检索、私有部署带来的权限与合规、以及把团队做事方式固化成模板或 Skill。至于「人在哪些环节介入」，可复用的分法是：需求澄清、架构与边界决策、跨仓库影响面判断和最终验收留给人，机械改写入、跑测试、按清单自查尽量交给 Agent——被追问「为什么不让 Agent 测试」时，卡点也基本落在这里，而不是模型能力本身。

知识库与 Skill 的沉淀：Skill Hub、多仓背景与 MCP/Skill 的分工

Skill Hub 这类内部市场要转起来，靠的是「可发现 + 可版本化 + 有 owner」：好的 Skill 走 PR 进主干、按领域分目录、由使用方评审后合并，消费侧用统一 CLI 或依赖引用安装，而不是人肉复制粘贴——一旦靠复制，几周后各人的版本就分叉了。多仓场景下别把背景知识塞进一个巨型文档：每个 repo 放一份 Agent 规则文件加目录级规则（近处规则优先），跨仓共享的部分抽成独立的规则包或 Skill 包用 submodule / 包管理器引用，再加一份可检索的 knowledge 目录，让 Agent 按需读而不是每次全量灌进上下文。MCP 与 Skill 的分工可以这样讲：MCP 是运行时的能力协议，把外部系统（数据库、内部平台、第三方 API）暴露成可调用工具，解决「够不着」；Skill 是打包好的流程知识与判断标准，解决「不知道怎么做、做成什么样算对」。上下文上的差别也由此而来——MCP 的工具描述常驻、结果按调用返回，Skill 通常是渐进式披露：先加载名称与描述用于路由，命中触发后才读正文，所以「整个 Skill 文件一开始就全读进去」在多数客户端并不成立。

ai-pipeline 的节点设计与测试验收：自洽、规则反哺

「关键节点」最好用两条线定义：可逆性（错了能不能撤）和影响面（影响一个人还是一个系统）。改文档、加日志这类可逆且局部的步骤让它一路跑完；动 schema、动对外接口、要发布上线这类不可逆或大范围的步骤设成 gate——流水线跑到那里停下，产出一份待确认摘要（改了什么、风险点、回滚方式），人回执后再继续，这比「给你发条消息」更可追溯。测试分层要分清：单测在 generate 之后立刻跑，秒级、覆盖函数级行为；集成测需要真实依赖，分钟级；端到端最贵最脆，跑一轮从几分钟到十几分钟都可能，取决于用例数、外部依赖和重试策略，工程上先保住一个稳定的冒烟集，再谈覆盖率。人工测试的卡点通常不是「AI 不会点按钮」，而是环境与数据准备、登录鉴权、没有明确判定标准的验收（视觉、业务语义），以及 e2e 抖动带来的维护成本；能交给 Agent 的是「按 checklist 执行并读日志判断」，交不出去的是「没人写清楚的验收标准」——这也是回答「为什么不让 Agent 测试」的诚实版本。至于自洽与反哺，闭环的关键是规则必须机器可判定：把踩过的坏味道沉淀成 lint 规则、AST 检查或 review checklist 塞回流水线，否则它只是文档，不会在下一次自动拦住问题。

百度实习的 Temporal 链路与品牌两步筛选

Temporal 的拆分原则是「确定性归 Workflow、副作用归 Activity」：Workflow 里只写编排逻辑（分支、重试策略、超时、状态推进），必须可重放，所以不能直接发网络请求或读当前时间；真正的抓数、写库、调用外部服务都放 Activity，由框架负责重试与幂等。Activity 的粒度按「重试与超时边界一致」来切——需要同一套重试和幂等保证的步骤合成一个 Activity，切得太碎会让历史事件膨胀、回放变慢，切得太粗又会让失败重试的代价过大。品牌筛选分两步是典型的先粗后细：粗筛把全量压到可接受规模、可用便宜规则或缓存兜住大部分流量，细粒度匹配只在候选集上做，准确率和成本都能兼顾。出数耗时与数据量级这类问题，面试里报数一定要带口径（全量还是增量、单次调度窗口多长、失败重试算不算在内），没有数字就说清如何度量，比给一个拍脑袋的估值安全。原帖最后是反问环节：一级部门统招、入职后再分方向；也聊到对 AI 发展速度的看法（还 OK、期望更快一点）和「按自己的规划和 AI 多交流」这类发展建议——原帖作者的总结是面试官全程很耐心地在听，体验偏正面，这部分不涉及技术判断。