AI 工具与框架
Q：用过哪些 Code Agent？有什么优缺点？
来源：腾讯 AI 应用开发 【淘天Agent开发追问：AI辅助编程工作流拆解 + 提示词策略与人工审核介入点】【字节火山引擎 Managed Agent 一面追问：如何用 Coding Agent 完成项目开发】
新手答：“用过 Copilot，挺好用的。”
高手答：
目前 Code Agent 工具分两类：IDE 集成型和终端独立型，工程定位不同。
| 类型 | 代表工具 | 优点 | 缺点 |
|---|---|---|---|
| IDE 集成型 | Cursor / Windsurf / Copilot | 感知项目上下文（目录、类型、导入），补全即时、改完直接看 diff | 对大规模跨文件重构支持有限 |
| 终端独立型 | Claude Code / Codex CLI / Aider | 能执行 shell 验证代码、跑测试、做 git 操作；全局视角 | 没有实时补全体验，需要更多上下文描述 |
实际使用策略——两类互补而非互斥：
- 写新功能、局部修改 → IDE 集成型（实时补全 + 即时预览）
- 跨文件重构、项目搭建、调试排查 → 终端型（能执行验证 + 全局操作）
- 两类工具都受益于项目级规则约束（CLAUDE.md / .cursorrules），定义编码规范和技术栈约束后输出质量显著提升
核心认知：Code Agent 的瓶颈通常不是模型能力，而是上下文不足和约束不够——给足项目规则和相关代码上下文，输出质量有质的飞跃。
日常 AI Coding 的实战工作流：
“平时怎么用 AI Coding”是近期高频面试题，面试官想听的不是”用 Cursor 写代码”，而是你的工作流和方法论：
高效使用的三层模式：
| 模式 | 场景 | 具体做法 | 效率提升 |
|---|---|---|---|
| 自动驾驶 | 重复性任务（CRUD、测试用例、类型定义） | 给 Agent 明确指令 + 格式要求，让它一次性生成 | 5-10x |
| 副驾模式 | 中等复杂度任务（重构、Bug 修复） | 自己做设计决策，让 AI 执行具体代码变更 | 2-3x |
| 导航模式 | 探索性任务（学新框架、理解陌生代码） | 让 AI 解释代码、提供方案对比，自己做最终判断 | 1.5-2x |
关键实践原则：
- 先给上下文再给指令：不是直接说”帮我写个排序”，而是先让 AI 读懂项目结构、了解编码规范，再给具体任务
- 小步验证：不要让 AI 一次改 20 个文件，而是分步执行、每步验证。一次大改出错了很难定位
- AI 生成 → 人类审查 → AI 修正：不盲信 AI 输出，但也不逐行手改——用 AI 的速度生成，用人的判断审核
- 知道什么时候不用 AI：涉及核心业务逻辑的架构决策、安全敏感代码、需要深度理解上下文的 Debug——这些场景人工效率更高
差距在哪：新手只评价了”好不好用”。高手按工具类型做了系统对比，且给出了互补使用策略和提升质量的方法论。面试官考的是你对 AI Coding 工具的实际使用深度。
追问：公司里有几十个应用，改一个需求要动多个系统，AI Coding 怎么处理？
来源：蚂蚁 Agent 开发一面
这道题考的是当前 AI Coding 的能力边界——大部分候选人只在单 repo 里用过 AI Coding，面试官想知道你对企业级多系统场景的认知。
核心矛盾：当前 AI Coding 工具以单项目为粒度工作，但企业需求往往跨多个仓库（前端、BFF、后端、基础设施）。一个需求改三个系统，AI 只能看到一个。
分层解决思路：
| 层级 | 方案 | 适用场景 |
|---|---|---|
| 人工拆解 + AI 执行 | 人工把跨系统需求拆成每个系统的独立任务，每个任务用 AI 完成 | 当前最实际的方案 |
| 共享接口契约 | 把接口定义（OpenAPI/Proto/GraphQL Schema）作为上下文注入到每个系统的 AI 会话中 | 保证跨系统一致性 |
| 多 Worktree / 多 Session | 每个系统开独立 session，通过 CLAUDE.md 注入全局需求背景和接口约定 | Claude Code 已原生支持 worktree |
| 编排层协调 | 用一个 orchestrator Agent 分解需求、分发子任务、校验接口一致性 | 未来方向，当前不成熟 |
当前最佳实践：
1. 人工做需求拆解和接口设计（AI 最弱的环节）
2. 把接口契约写成文档，作为每个系统 AI 会话的上下文
3. 每个系统用 AI 独立实现，实现完跑集成测试
4. 接口变更时手动同步到其他系统的 AI 上下文诚实回答：这个场景是当前 AI Coding 的硬伤——跨系统状态同步、接口一致性保障、变更顺序依赖这些问题，AI 暂时没法自主解决。但人工拆解 + AI 分系统执行 + 契约共享，已经比纯人工效率高很多。
Q：平时写的代码有多少是 AI 生成的？怎么保证质量？
来源：腾讯 Agent 应用开发一面
新手答：“大概 50%，然后自己改改。”
高手答：
比例因任务类型而异：
- 样板代码（CRUD、配置、测试骨架）：80%+ 由 AI 生成，人工只做审查和微调
- 核心业务逻辑（算法、状态机、并发控制）：AI 生成初版，人工大幅修改，实际保留 30-40%
- 架构设计和技术选型：AI 提供选项和分析，但决策完全由人做
保证质量的方法不是“自己改改”，而是流程化的质量门禁：
- 生成前约束：给足上下文（类型定义、接口规范、项目规则文件），让 AI 一次生成质量更高的代码
- 生成后审查：AI 生成的代码必须过 Code Review，重点看边界条件、安全漏洞、和已有代码的一致性
- 自动化验证：类型检查（TypeScript）、lint、单元测试必须通过。AI 容易写出“看起来对但类型不安全”的代码
核心原则：AI 生成的比例不重要，重要的是每行代码都经过了验证。
怎么回答“占比多少”这类问题：
面试官问这道题不是想听一个数字，而是考察你对 AI 辅助开发的认知成熟度。回答时避免两个极端：说“90% AI 写的”会让面试官觉得你不审代码；说“很少用”会让面试官觉得你效率低。正确的回答结构是：按任务类型分层 → 每层给一个合理比例 → 重点讲质量保障流程。数字本身不重要，展示你对“人机协作边界”的清晰认知才重要。
差距在哪：新手只给了一个比例。高手按任务类型分了不同比例，且给出了系统化的质量保障方法。面试官考的是你对 AI 辅助开发的成熟度。
Q：平时用过哪些 AI Agent 工具？
来源：腾讯 Agent 应用开发一面
新手答：“用过 ChatGPT。”
高手答：
AI Agent 工具按用途分三类：
| 类别 | 代表工具 | 特点 |
|---|---|---|
| 通用对话型 | ChatGPT、Claude、Kimi | 单轮/多轮问答，不主动执行操作 |
| 开发框架型 | LangChain、LangGraph、Dify、Coze | 提供编排、工具调用、记忆等基础设施，开发者搭建 Agent |
| AI Coding 型 | Cursor、Claude Code、GitHub Copilot | 直接辅助写代码，有项目上下文感知 |
关键认知：这三类工具解决的问题不同——通用型解决“问答”，框架型解决“编排”，Coding 型解决“开发效率”。实际做 Agent 开发时，框架型和 Coding 型通常同时使用：用 Coding 工具写代码，用框架搭 Agent 流程。
选工具的标准不是“哪个最热”，而是你的任务需要什么级别的控制力：简单任务用 Dify/Coze 拖拽搞定；需要自定义编排的用 LangGraph；需要最大灵活性的直接用 SDK + 自建。
差距在哪：新手只列了名字。高手按用途做了分类，且说清了选型标准。面试官考的是你对 Agent 工具生态的全局认知。
Q：你熟悉的 Agent 框架，在架构设计上有什么优势？
来源：腾讯 Agent 应用开发一面
新手答：“它用了 LLM，很智能。”
高手答：
以 OpenClaw 为例，它的架构优势体现在三个层面：
- 编排层和能力层分离：编排层（状态机/DAG）负责“做什么、按什么顺序做”，能力层（LLM 调用、工具执行）负责“具体怎么做”。分离后编排逻辑可以独立测试和复用，不和模型调用耦合
- 工具即插件：工具通过标准化接口（类似 MCP 的 tool schema）注册，新增工具不需要改编排代码。这让工具生态可以独立演化
- 上下文管理可配置：不是硬编码“保留最近 N 轮”，而是提供多种上下文策略（滚动窗口、摘要压缩、按需召回），开发者根据场景组合
这三个优势的共性是关注点分离——编排、能力、工具、上下文各自独立演化，互不干扰。这和微服务架构的设计哲学是一致的。
差距在哪：新手用“智能”概括一切。高手从编排/能力分离、工具插件化、上下文可配置三个架构决策分析优势。面试官考的是你对框架的理解是“会用”还是“理解设计”。
Q：自己做 Agent 时，踩过最大的坑是什么？
来源：腾讯 Agent 应用开发一面
新手答：“模型输出不稳定。”
高手答：
最大的坑是过度信任模型的“理解力”，导致状态管理全靠上下文承载。
早期做 Agent 时，觉得模型能“记住”之前的对话，所以把关键参数（用户偏好、任务进度、中间结果）全放在对话历史里。结果上下文一长，模型就开始丢信息、乱推理——用户在第 3 轮说的约束条件，到第 10 轮完全被忽略。
系统性修复：把“模型记住”改成“系统记住”——
- 关键参数实时提取到独立的状态存储（Redis / 数据库），不依赖上下文
- 每轮调用前把当前约束条件作为 System Prompt 的固定部分强制注入
- 中间结果落库，上下文里只留一句摘要
这个坑的本质是：Agent 的上下文窗口是“工作台”，不是“仓库”。工作台上只放当前步骤需要的东西，其他全放仓库里按需取。
差距在哪：新手说“不稳定”是表象。高手指出了根因（过度依赖上下文承载状态）和系统性解法（状态外置 + 强制注入 + 落库）。面试官考的是你踩坑后有没有做过根因分析和系统性修复。