Skip to main content
编码工具这块我关心的是边界:它能做什么、在哪一步容易出错、我该怎么验证。只说”AI 提效”说明不了问题。

Q1: AI 代码生成是如何演进的?它解决了什么问题?

1

2010s: IDE 关键字补全时代

早期的代码补全完全基于静态分析——IDE 解析 AST(抽象语法树),根据变量类型和方法签名提供建议。Visual Studio 的 IntelliSense、Eclipse 的 Content Assist 都属于这一阶段。补全范围局限于当前文件的已知符号,无法理解上下文语义。
2

2021: GitHub Copilot 开启 LLM 代码补全

GitHub 联合 OpenAI 发布 Copilot,基于 Codex 模型(GPT-3 的代码微调版本)。它不再局限于 AST 符号,而是根据当前文件内容和光标位置预测下一行甚至整个函数。这是第一次 LLM 大规模应用于代码生成,开发者首次体验到”AI 写代码”的可能性。
3

2023: 上下文感知的多文件理解

Cursor、Codeium(后来的 Windsurf)等工具出现,核心突破是跨文件上下文理解。它们不只看当前文件,还会索引整个项目的文件树、依赖关系、TypeScript 类型定义,甚至 Git 历史。模型也从 Codex 升级到 GPT-4、Claude,推理能力大幅提升。
4

2024: MCP 标准化与 Agent 模式兴起

Anthropic 推出 MCP(Model Context Protocol),标准化了 AI 与外部工具的通信协议。Cursor 的 Composer 模式、Claude Code 的终端 Agent 模式,让 AI 从”补全代码”进化到”理解任务 → 规划步骤 → 执行修改 → 运行测试”的完整工作流。
5

2025: 自主编码代理成为主流

Claude Code、GitHub Copilot Workspace、Windsurf Cascade 等自主编码代理(Autonomous Coding Agent)进入生产环境。它们能独立完成从需求分析到代码提交的完整流程——搜索代码库、规划实现方案、跨多文件修改、运行测试、修复 lint 错误、提交 Git。Andrej Karpathy 将此趋势称为”vibe coding”——开发者用自然语言描述意图,AI 负责实现。[1]

AI 代码生成解决的核心问题

AI 代码生成的本质是把开发者的角色从”写代码”转变为”审查和引导代码”——从体力劳动转向脑力决策。

没有 AI 代码生成

开发者需要手动编写每一行样板代码:组件骨架、API 请求、类型定义、单元测试。一个中等复杂度的 React 组件可能需要一两个小时,其中相当一部分时间花在重复性代码上。

引入 AI 代码生成

开发者用自然语言描述需求(“创建一个带搜索和分页的用户列表组件”),AI 生成完整代码骨架。开发者只需审查逻辑正确性、调整样式细节、补充边界处理。同样的组件十几分钟即可完成,效率明显提升。
回答时先说”为什么需要 AI 代码生成”(重复性编码的痛点),再说”它经历了哪些阶段”(从关键字补全到自主代理的演进),最后说”它的核心价值”(角色转变)。想听的是你对技术演进驱动力的理解,而不是背诵产品发布时间线。

Q2: AI 代码生成的原理是什么?它和传统代码补全有什么区别?

AI 代码生成的核心是大语言模型对代码序列的概率预测。与传统 AST 补全的本质区别在于:传统补全理解”语法结构”,LLM 理解”语义意图”。
传统补全和 LLM 补全的底层机制完全不同:
  • 传统补全:解析 AST → 查符号表 → 返回精确匹配。优点是零幻觉,缺点是只能补全已知符号。
  • LLM 补全:将代码转为 token 序列 → Transformer 计算注意力 → 预测概率最高的下一个 token。优点是能生成新代码,缺点是可能产生幻觉(编造不存在的 API)。
  • 关键区别:LLM 不”理解”代码,它是在做统计模式匹配。当训练数据中某种模式出现频率高时,模型倾向于复现该模式——这既是优势(生成常见模式),也是风险(复现常见 bug)。
传统代码补全就像查词典——你输入一个单词,它精确返回定义。你输入 document.get,它返回 getElementById、getElementsByClassName 等已知 API。LLM 代码生成就像请翻译官——你用中文描述意图(“获取页面上所有 class 为 active 的按钮”),翻译官根据语境生成完整表达(document.querySelectorAll('button.active'))。翻译官的优势是能处理模糊表达,风险是偶尔会”翻译错”——生成语法正确但逻辑有误的代码。

代码补全 vs 代码生成

很多人混淆”代码补全”和”代码生成”,但它们是两个不同的层次:

上下文理解的三个层次

AI 代码生成的质量高度依赖上下文的质量。上下文理解分三个层次:
  1. 文件级上下文:当前文件的代码内容、光标位置、编辑历史。这是最基本的层次,所有工具都支持。
  2. 项目级上下文:文件树结构、tsconfig.json 配置、package.json 依赖、TypeScript 类型定义。Cursor 和 Claude Code 在这个层次做得最好——它们会自动索引项目文件,构建依赖图谱。
  3. 语义级上下文:理解业务逻辑、设计模式、团队编码规范。这是最前沿的层次,目前主要通过 CLAUDE.md / AGENT.md 等配置文件实现——开发者在配置文件中描述项目架构、编码规范、禁止行为,AI 读取后遵循执行。

模型选择对代码生成质量的影响


Q3: 主流 AI 编码工具有哪些?它们有什么区别?

基础梳理

专家视角深度剖析

很多人能背诵上面的表格,但实际更在意的是:这些工具的底层架构差异是什么?为什么不同工具对同一个任务的生成质量差异很大? 底层差异在于上下文窗口管理策略。Cursor 使用的是”主动索引 + 智能检索”——它会预先 Embedding 项目的文件内容,当用户提问时,通过向量检索找到最相关的代码片段作为 prompt 的一部分。Claude Code 使用的是”工具调用 + 渐进探索”——它不会预先索引整个项目,而是通过 MCP 工具(read_file、grep、glob)按需探索代码库,像人类开发者一样”先看目录结构,再看相关文件,最后理解代码逻辑”。[2] 这两种策略各有优劣:

各工具的核心差异化特性

GitHub Copilot 的 Agent 模式(2025) Copilot 在 2025 年推出了 Coding Agent——它能直接读取 GitHub Issue,自动创建分支、实现代码、运行测试、提交 PR。核心优势是与 GitHub 生态深度集成,适合团队协作场景。 Cursor 的 Composer 模式 Composer 是 Cursor 的核心差异化功能——它允许 AI 在一次对话中同时修改多个文件,并以 diff 形式展示所有变更。开发者可以逐个审查、接受或拒绝每个文件的修改。这种”全局视图 + 精细控制”的体验是 Cursor 受欢迎的关键原因。 Claude Code 的 CLAUDE.md 配置 Claude Code 独创了 CLAUDE.md 配置文件机制——开发者在项目根目录放置 CLAUDE.md,描述项目架构、编码规范、禁止行为、常用命令。AI 每次启动时读取该文件,将其作为系统级指令遵循。这解决了”AI 不了解项目上下文”的核心痛点。[3] Windsurf 的 Cascade 模式 Windsurf 的 Cascade 是一个自主 AI 流水线——它能自动规划任务步骤、调用终端命令、管理文件操作、运行测试。与 Claude Code 类似,但深度集成在 IDE 中,提供可视化的工作流面板。

Q4: AI 代码生成的最佳实践是什么?

场景 1: Prompt 质量决定生成质量

AI 代码生成的质量80% 取决于 Prompt 的质量。模糊的 prompt 生成模糊的代码,精确的 prompt 生成精确的代码。

场景 2: 上下文不足导致幻觉

当 AI 缺少足够的上下文时,它会”编造”看起来合理但实际不存在的 API 或参数。这是 AI 代码生成最常见的坑。

场景 3: 不验证直接使用

很多开发者直接接受 AI 生成的代码,不验证就提交。这会导致隐蔽的逻辑 bug、安全漏洞和性能问题。 代码对比(Prompt 质量对生成结果的影响):
  1. 明确技术栈:告诉 AI 你用的是 React 还是 Vue、TypeScript 还是 JavaScript、哪个 UI 库。
  2. 描述输入输出:函数接收什么参数、返回什么值、异常情况如何处理。
  3. 给出约束条件:性能要求(“列表需要虚拟滚动”)、兼容性要求(“支持 IE11”)、编码规范(“使用 ESLint Airbnb 配置”)。
  4. 提供示例:如果项目中有类似的组件,告诉 AI “参考 UserTable.tsx 的写法”。
  5. 分步生成:复杂功能不要一次性生成,分步骤引导 AI——先生成数据层,再生成 UI 层,最后生成测试。

如何提供有效上下文

提供上下文的具体方法:
  1. 使用 @ 引用文件(Cursor):在对话中用 @filename 引用相关文件,AI 会自动读取其内容作为上下文。
  2. 编写 CLAUDE.md(Claude Code):在项目根目录创建 CLAUDE.md,描述项目架构、常用命令、编码规范。
  3. 粘贴相关代码:如果某个工具不支持自动索引,手动将相关代码粘贴到 prompt 中。
  4. 描述业务背景:告诉 AI “这是电商后台的订单管理模块”,比单纯说”写一个表格组件”效果好得多。

如何验证 AI 生成的代码

AI 生成的代码必须经过验证,验证分为四个层次:

如何处理 AI 生成的错误

当 AI 生成的代码出错时,不要直接告诉 AI “代码有 bug”,而是提供完整的错误信息和期望行为:

Q5: AI 代码生成有哪些局限性?

表面上的答案

AI 代码生成能大幅提升开发效率,是前端工程师的”超级助手”。

反面的证据

但 AI 生成的代码存在三类核心风险,忽视这些风险可能导致严重的生产事故。 风险一:生成的代码可能有隐蔽 bug AI 生成的代码语法几乎总是正确的,但逻辑不一定正确。斯坦福大学 2023 年的一项对照研究发现,使用 AI 助手的参与者写出的代码安全性更低——因为 AI 会生成”看起来正确”但实际有安全缺陷的代码。[4]
风险二:依赖幻觉——编造不存在的 API LLM 的训练数据有截止日期,且模型可能”记忆错误”。它可能生成调用不存在的 API、使用已废弃的参数、或者引用不存在的 npm 包。
风险三:性能问题——生成的代码可能不优化 AI 倾向于生成”能跑”的代码,但不一定是最优的代码。它可能在循环中创建不必要的渲染、使用低效的数据结构、或者忽略 memoization。

你的判断

AI 代码生成是一把双刃剑——它是”初级开发者”级别的代码生成器,而不是”资深架构师”级别的决策者。正确使用方式是:让 AI 生成初稿,由人类开发者负责审查、优化和架构决策。

升华

从更深层看,AI 代码生成正在重新定义”软件工程师”的角色。正如 Andrej Karpathy 所说,未来工程师的核心能力不再是”写代码”,而是”审查代码、设计架构、定义需求”——从”编码者”转变为”技术决策者”。[1]

Q6: 底层源码——AI 编码工具是如何实现的?

Claude Code 的核心是一个工具调用循环(Tool Use Loop)——它接收用户的自然语言指令,通过多轮工具调用逐步完成任务。每一轮,模型决定调用哪个工具(read_file、write_file、bash、grep 等),执行后将结果反馈给模型,模型再决定下一步操作,直到任务完成。[3]
Cursor 的 Composer 模式核心是Diff-based 多文件编辑——它将多个文件的内容拼接成一个长 prompt,让模型生成完整的修改后文件内容,然后通过 diff 算法计算出变更行,以交互式 diff 视图展示给用户。用户可以逐行审查、接受或拒绝每个变更。 详见 Cursor 官方文档:

Q7: 满分回答 vs 及格回答

问题:“你平时用什么 AI 编码工具?它们的原理和区别是什么?”

及格回答(60-70分):
“我用 GitHub Copilot 写代码,它能自动补全代码。也用过 Cursor,它支持多文件编辑。Claude Code 是终端里的 AI 工具,能帮我写代码。”
问题出在:知道工具名字,但不理解底层差异。 满分回答(90-100分):
“AI 编码工具的核心原理是 LLM 对代码序列的概率预测。和传统的 AST 补全不同,LLM 能理解语义意图而不仅仅是语法结构。但不同工具的上下文管理策略差异很大——Cursor 用向量检索预先索引项目文件,响应快但可能漏掉语义相关文件;Claude Code 用工具调用渐进探索代码库,理解更深但延迟更高。[2]”
“我在团队中同时使用 Copilot 和 Claude Code。Copilot 负责日常的实时补全——写样板代码、生成类型定义、补全 import 语句。Claude Code 负责复杂的重构任务——上周我用它完成了一个跨 12 个文件的状态管理重构,它自动读取了所有相关文件、理解了数据流向、生成了完整的修改方案,我只需要审查 diff 和运行测试。[3]”
“但 AI 生成的代码不能盲目信任。我遇到过 AI 编造不存在的 API(Array.prototype.groupBy 并不存在,提案最终改为 Object.groupBy)、生成有 XSS 漏洞的代码(直接用 dangerouslySetInnerHTML 渲染用户输入)、以及生成性能低下的代码(在循环中创建不必要的闭包)。所以我的工作流是:AI 生成 → ESLint 检查 → TypeScript 类型检查 → 单元测试 → 人工审查,五步验证后才提交。[4]“

常见追问

题目来源于真实面经(字节/腾讯/阿里前端面试、牛客网、haizlin/fe-interview),按难度递进。每个模块 8 个 Accordion,覆盖 4 个难度层级。
答题要点: 很多人混淆这两个概念,需要从输入、输出、模型规模、上下文范围四个维度对比。高分回答: 代码补全是”续写”——你写了半行代码,AI 预测接下来的几个 token,输出通常是 1-10 行。它基于轻量级模型(如 Codex),延迟在 100ms 以内,上下文局限于当前文件。代码生成是”创作”——你用自然语言描述需求,AI 生成完整函数甚至整个文件。它基于重量级模型(GPT-4、Claude),延迟 1-10 秒,上下文可以覆盖整个项目。简单来说,补全是”你写一半 AI 写一半”,生成是”你说需求 AI 写全部”。在实际工作中,补全用于高频的日常编码(写变量名、调用 API),生成用于低频但高价值的任务(创建新组件、重构模块)。
答题要点: 从 tokenization、注意力机制、上下文窗口三个层次解释。高分回答: AI 理解代码上下文分三步。第一步是 Tokenization——代码被拆分为 token 序列,比如 const user = 被拆为 ["const", " user", " =", ...]。第二步是注意力计算——Transformer 的 Self-Attention 机制让模型能捕捉 token 之间的长距离依赖关系,比如函数开头的 interface User 和第 50 行的 user.name 之间的类型关联。第三步是上下文窗口管理——模型有 token 上限(Claude 支持 200K tokens),工具需要智能选择哪些文件放入上下文。Cursor 用向量检索选择相关文件,Claude Code 用工具调用渐进探索。关键限制是:超出上下文窗口的信息模型完全看不到,所以”提供什么上下文”比”用什么模型”更重要。
答题要点: 从预索引 vs 渐进探索的角度对比,说明各自的适用场景。高分回答: Cursor 用的是”预计算 + 向量检索”策略——项目打开时 Embedding 所有文件,用户提问时通过向量相似度检索最相关的 5-10 个文件。优势是响应快(检索 < 100ms),适合实时补全场景。劣势是向量检索基于关键词相似度,可能漏掉语义相关但用词不同的文件。Claude Code 用的是”工具调用 + 渐进探索”策略——不预先索引,而是通过 read_file、grep、glob 等 MCP 工具按需探索代码库,像人类开发者一样”先看目录 → 再看相关文件 → 最后理解逻辑”。优势是理解更深、更灵活,劣势是延迟更高(多次工具调用)、API 成本更高。选择哪种取决于任务类型:日常编码用 Cursor(快),复杂重构用 Claude Code(深)。
答题要点: 从”AI 不了解项目上下文”的痛点出发,解释配置文件如何作为持久化的系统指令。高分回答: CLAUDE.md 解决的核心问题是:AI 每次启动时都从零开始,不了解你的项目架构、编码规范、禁止行为。CLAUDE.md 是放在项目根目录的 Markdown 配置文件,Claude Code 每次启动时自动读取它,将其内容作为系统级指令注入 prompt。典型内容包括:项目架构描述(“这是一个 Monorepo,使用 pnpm workspace”)、编码规范(“使用函数组件 + Hooks,禁止 class 组件”)、禁止行为(“不要使用 any 类型,不要直接修改 state”)、常用命令(“运行测试用 pnpm test”)。这本质上是一种持久化的 Prompt Engineering——把最佳实践写在配置文件里,让 AI 每次都遵循。类似的机制还有 AGENTS.md(由 OpenAI Codex 提出并捐给 AAIF)和 AGENT.md(Sourcegraph Amp 的约定),行业正在向标准化配置文件格式演进。
答题要点: 必须分场景讨论——XSS、注入、依赖风险、硬编码密钥,每种给出具体代码和防范措施。高分回答: AI 生成的代码有四类安全风险。第一是 XSS——AI 可能用 dangerouslySetInnerHTML 直接渲染用户输入,防范方法是强制使用 React 的自动转义或 DOMPurify。第二是注入攻击——AI 生成的数据库查询可能直接拼接用户输入,防范方法是使用参数化查询。第三是依赖风险——AI 可能推荐已知有漏洞的 npm 包,防范方法是在 npm install 后运行 npm audit。第四是硬编码密钥——AI 可能在代码中直接写入 API Key,防范方法是使用环境变量和 .env 文件。最有效的防线是将 SAST 工具(Semgrep、CodeQL)集成到 CI/CD 流水线,对所有 AI 生成的代码自动扫描。2023 年斯坦福的一项对照研究表明,使用 AI 助手的参与者更容易写出不安全的代码,这说明人工审查不可省略。
答题要点: 从团队协作角度,讨论 prompt 管理、上下文共享、代码审查流程。高分回答: 大型项目中 AI 编码工作流需要三个关键设计。第一是 Prompt 版本管理——把有效的 prompt 模板(如”创建新组件”、“编写单元测试”、“重构 Hook”)写成团队共享的模板文件,存入 Git 仓库,避免每个人重新发明轮子。第二是 CLAUDE.md 团队协作——将项目的编码规范、架构约束、禁止行为写入 CLAUDE.md,提交到仓库,确保团队所有成员使用 AI 时遵循相同标准。第三是 AI 代码审查流程——AI 生成的代码在 PR 中需要标记为”AI-generated”,审查者需要额外关注安全漏洞和性能问题。部分团队还会在 CI 中添加专门的 AI 代码检查步骤,运行更严格的 lint 规则和安全扫描。
答题要点: 解释 Karpathy 提出的概念,分析其适用场景和风险,给出明确判断。高分回答: “Vibe coding” 是 Andrej Karpathy 在 2025 年初提出的概念——开发者用自然语言描述意图,完全信任 AI 的输出,不做深度审查就接受代码。它的核心理念是”让 AI 做主,人只负责描述需求”。适合的场景:个人原型项目、hackathon、一次性脚本、学习新技术时快速实验。不适合的场景:生产环境代码、涉及安全的模块、性能敏感的核心路径、团队协作的共享代码库。我的判断是:vibe coding 在探索阶段有价值,但在工程化阶段必须回归严格的代码审查。它更像是”高级版的 Stack Overflow 复制粘贴”——能快速得到可用代码,但质量和安全性无法保证。正确用法是用 vibe coding 快速验证想法,然后用工程化流程(测试、审查、安全扫描)将代码提升到生产级别。
答题要点: 从技术维度(模型能力、上下文管理、IDE 集成)和组织维度(安全合规、成本、学习曲线)全面评估。高分回答: 评估 AI 编码工具需要考虑六个维度。第一是模型能力——用团队真实的代码任务测试,而不是用 hello world。让 3 个开发者分别用工具完成同一个重构任务,对比生成质量和修改量。第二是上下文管理——测试工具在大型 Monorepo(1000+ 文件)中的表现,它能否正确理解跨模块的依赖关系。第三是安全合规——确认代码是否发送到外部服务器、是否有数据保留政策、是否符合公司的安全审计要求。这是很多企业选择自部署方案的核心原因。第四是成本模型——按座位收费(Copilot $10/月)vs 按 token 收费(Claude Code API),50 人团队的年度成本可能相差 5-10 倍。第五是学习曲线——Cursor 需要学习快捷键和 Composer 模式,Claude Code 需要学习终端操作和 CLAUDE.md 配置。第六是生态集成——是否支持团队的 CI/CD 流程、代码审查工具、项目管理工具。建议先在小范围(3-5 人)试点 2 周,收集效率数据和安全反馈,再决定全团队推广。

延伸阅读与引用参考