AI Native 面试题库

2026-05-09

Question

假设你要在团队里落地一个 AI Coding Assistant / Coding Agent，它可以阅读代码仓库、回答代码问题、生成修改方案，并在必要时自动改代码、运行测试、提交 PR。

请你从程序员视角回答：

一个可用于生产环境的 AI Coding 系统，和一个简单的“代码补全 / ChatGPT 问答”相比，核心差异是什么？你会如何设计它的整体工作流？

你可以重点展开这几个方面：

  1. 它如何理解代码仓库上下文？
  2. 它如何决定什么时候只是回答，什么时候需要修改代码？
  3. 它如何安全地执行命令、运行测试、提交变更？
  4. 你会如何评估它是否真的提升了开发效率，而不是制造更多风险？

Your Answer

首先作为一个 agent 需要有完整的项目视角，熟悉项目的整体架构、技术栈，这些通过 README、package.json、编译配置等关键信息入手。对于用户的问题，要先明确意图，明确目标是回答问题还是进行开发，可以通过提供 chat agent 和 builder agent 来让用户主动选择。对于代码修改、命令行工具调用，都要请求用户的确认，命令执行需要在沙箱中完成，避免误伤重要系统内核。如果有代码修改，需要进行编译和lint检查，确保没有引入新的问题。对于 agent 的评估，主要通过 agent 输出采纳情况来统计，同时可以统计开发者的代码量变化，以及代码量中 agent 编写的比例，从而评估是否真正实现了提效

Review

你的回答方向是对的：抓住了 项目上下文、意图识别、安全执行、质量校验、效果评估 这几条主线。

主要有 4 点可以加强：

  1. “仓库理解”还偏静态

    • 你提到了 README、package.json、编译配置，这是入口没问题。
    • 但生产级 AI Coding 还需要理解：代码依赖图、调用链、测试结构、历史提交、已有设计约定、模块边界，而不只是读几个配置文件。

  2. “回答 vs 修改”可以更工程化

    • 你提到 chat agent / builder agent 让用户选择，这是一个产品交互方案。
    • 但系统内部还需要判断机制：任务类型、风险等级、是否需要写文件、是否需要运行命令、是否需要 human approval。

  3. 安全机制可以更细

    • “用户确认 + 沙箱执行”是核心，但还可以补充：
      • 权限分级
      • 命令 allowlist / denylist
      • 文件写入范围限制
      • secret 防泄漏
      • destructive command 拦截
      • PR 前 diff review

  4. 评估指标不应只看代码量

    • 采纳率有价值。
    • 但代码量变化、AI 代码占比不一定等于提效，甚至可能鼓励生成冗余代码。
    • 更好的指标应包括：任务完成时间、PR 返工率、测试通过率、bug 引入率、review comment 数、开发者满意度等。

Improved Answer

一个生产级 AI Coding 系统 和简单代码补全 / ChatGPT 问答的核心差异在于：
它不是单次生成代码，而是一个围绕真实代码仓库运行的受控工程工作流系统。

它需要具备四类能力：上下文理解、任务决策、安全执行、持续评估。

1. 上下文理解：从“读片段”变成“理解仓库”

简单问答通常只依赖用户粘贴的代码片段，而 AI Coding Agent 需要建立完整的项目视角。

它应该从这些信息入手：

  • README / docs：理解项目目标和使用方式
  • package.json / pyproject.toml / go.mod：理解技术栈和依赖
  • 构建配置、CI 配置、lint 配置：理解工程规范
  • 目录结构：识别核心模块、测试目录、脚本目录
  • 代码引用关系：理解函数、类、模块之间的依赖
  • Git history / PR 记录：理解近期改动和代码演进

更进一步，它不能把整个仓库一次性塞进 context window，而应该结合：

  • 文件检索
  • symbol search
  • AST / LSP
  • embedding-based code retrieval
  • dependency graph
  • incremental context loading

让模型在需要时拿到相关上下文，而不是盲目读取全部代码。

2. 任务决策：区分回答、规划、修改与执行

AI Coding 系统需要先判断用户意图，而不是一上来就改代码。

一般可以分成几类：

  • 问答类：解释代码逻辑、定位某个模块职责
  • 诊断类：分析报错、找可能原因
  • 规划类：给出修改方案，但暂不动代码
  • 执行类：修改代码、运行测试、提交 PR

系统可以通过 chat agent / builder agent 让用户显式选择，也可以由 agent 自动判断任务风险。

关键是要有状态机式工作流：

  1. 理解任务
  2. 收集上下文
  3. 生成计划
  4. 请求用户确认
  5. 修改代码
  6. 运行检查
  7. 展示 diff
  8. 请求最终确认
  9. 创建 commit / PR

这样可以避免模型直接“拍脑袋改代码”。

3. 安全执行：所有副作用都要受控

生产环境里的 AI Coding Agent 最大风险不是答错，而是 错误地执行了有副作用的操作。

因此需要安全边界：

  • 命令在 sandbox / container 中执行
  • 文件写入限制在当前 repo 内
  • 对危险命令做 denylist，例如 rm -rf /、修改系统目录、访问敏感路径
  • 对网络请求、包安装、数据库操作做权限控制
  • 对 secret、环境变量、token 做脱敏和隔离
  • 修改代码前先展示计划
  • 修改代码后展示 diff
  • commit / push / PR 必须人工确认

对于代码质量，也要强制执行工程检查：

  • format
  • lint
  • type check
  • unit test
  • integration test
  • build
  • security scan，视项目需要而定

也就是说，AI 不能只负责“写代码”，还要进入正常软件工程质量门禁。

4. 评估体系：不能只看生成了多少代码

AI Coding 是否有效，不能只看 AI 写了多少代码。代码量甚至可能是负指标。

更合理的评估维度包括：

  • 效率指标

    • issue 从开始到完成的时间是否降低
    • 开发者查找代码、理解代码的时间是否减少
    • PR 周期是否缩短

  • 质量指标

    • 测试通过率
    • bug 引入率
    • 线上回滚率
    • review comment 数量和严重程度
    • AI 生成代码的返工率

  • 采纳指标

    • 建议采纳率
    • diff 接受率
    • PR merge 率
    • 开发者主动使用频次

  • 成本与风险指标

    • token cost
    • 执行耗时
    • 错误命令拦截次数
    • 权限越界尝试次数
    • 人工确认介入比例

最终判断标准不是“AI 写了多少代码”，而是：
它是否让开发者更快、更安全、更低成本地完成真实工程任务。

所以，一个生产级 AI Coding Agent 的本质不是代码生成器，而是：

一个具备仓库理解能力、任务规划能力、受控执行能力和工程质量闭环的开发工作流系统。

它和普通 ChatGPT 问答的差异在于：
普通问答只生成建议；生产级 AI Coding Agent 要能在真实代码仓库中，以可追踪、可回滚、可评估的方式完成开发任务。

ON THIS PAGE