1. AI编程工具的未来是什么？程序员会被替代吗？
1分钟面试背诵稿
我认为 AI 编程工具的未来，不只是代码补全，而是逐步演进成能够参与完整研发流程的工程代理。它会从写代码，扩展到理解需求、拆解任务、修改代码、运行测试、修复问题，甚至参与文档和交付流程。
但程序员不会被完全替代，真正会被替代的，是只做重复性编码、缺少技术判断的人。因为软件开发最难的部分并不只是写代码，而是理解业务、做技术取舍、保障系统质量，以及对最终结果负责。
从趋势上看，AI 会大幅提升开发效率，尤其是在模板化开发、样板代码、测试生成这些场景里。但越往上走，越需要工程师具备架构设计、问题拆解、代码评审、性能优化和风险控制能力。
所以我更认同一句话，不是 AI 替代程序员，而是会使用 AI 的程序员替代不会使用 AI 的程序员。未来工程师的核心竞争力，会从“手写代码的速度”，转向“定义问题、驾驭 AI、验证结果和完成交付”的能力。
2. 代码Review能用AI做吗？怎么自动提PR建议？
1分钟面试背诵稿
我认为代码 Review 非常适合用 AI 做增强，但不适合完全替代人工。因为 AI 很擅长做大规模、标准化、重复性的检查，比如代码风格、命名规范、空指针风险、低级 bug、重复逻辑、测试缺失、类型不一致，或者根据 diff 快速总结这次改动的风险点。
但 AI 的边界也很明显，它未必真正理解业务上下文、历史设计决策和线上约束，所以更适合做第一层自动审查，而不是最终审批人。真正高质量的 Review，还是需要工程师来判断架构合理性、业务正确性、兼容性和发布风险。
如果要自动给 PR 提建议，典型做法是把 AI 接到 CI 流水线里。比如在 GitHub Actions 或 GitLab CI 里，拿到 PR 的 diff、相关文件和项目规则，然后把这些上下文交给模型，让它输出结构化的 review 建议，再通过 bot 以评论或者 summary 的方式回写到 PR 里。
我觉得关键不是“让 AI 代替人审代码”，而是“让 AI 先做一轮高覆盖、低成本的预审”，帮团队减少机械性 review，把人力集中在真正重要的设计和风险判断上。
3. 代码模型的上下文怎么构建？Repo-level理解怎么做？
1分钟面试背诵稿
我理解代码模型的上下文构建，核心不是把整个仓库一次性塞给模型，而是围绕当前任务，动态提供最相关、最必要的上下文。因为仓库级代码通常很大，直接全量输入既不经济，也会稀释有效信息，导致模型抓不住重点。
一般来说，上下文可以分成几层。第一层是任务上下文，比如用户需求、报错信息、当前 diff 和目标文件。第二层是局部代码上下文，比如当前函数、调用链、相关类型定义、依赖模块和测试文件。第三层是仓库级上下文，比如项目目录结构、技术栈、核心模块关系、代码规范、公共组件、基础设施约束，以及 README、架构文档、lint 和 CI 规则。
Repo-level 理解本质上不是一次性读完整个仓库，而是先做仓库索引和结构化建模。比如预先抽取文件树、模块依赖、符号定义、调用关系、配置文件和文档，再结合 embedding 检索、关键词搜索和静态分析，在任务发生时按需召回相关内容。这样模型看到的不是“整个仓库”，而是“和当前问题最相关的仓库切片”。
所以我认为，代码 Agent 的关键能力不是单次生成代码，而是能不能建立一套稳定的上下文工程：先理解任务，再检索仓库，再补充约束，最后生成和验证。真正高质量的 Repo-level 理解，靠的是索引、检索、结构化信息和工具链配合，而不只是更长的上下文窗口。
4. 什么是 Repo-level？
1分钟面试背诵稿
Repo-level 可以理解成“仓库级别”的理解能力。它不是只看当前这一个文件、这一个函数，而是站在整个代码仓库的视角去理解问题。
比如你改一个前端页面，如果只是 file-level 理解，模型可能只知道这个页面文件里写了什么；但如果是 Repo-level 理解，它还会知道这个页面依赖了哪些公共组件、状态管理怎么做、接口层在哪、路由怎么配、测试怎么写、项目里有什么统一规范，甚至这段逻辑在别的模块里有没有类似实现。
所以 Repo-level 的重点，是“跨文件、跨模块、跨目录”地理解整个项目的结构和约束。它关注的不只是单点代码，而是这段代码在整个仓库里的位置、上下游依赖和工程规则。
从 Agent 工程角度看，Repo-level 理解通常要靠文件树分析、符号索引、依赖关系、代码搜索、文档检索和配置解析来实现。简单说，就是让模型知道“这个仓库整体是怎么组织和运行的”，而不是只会盯着眼前这一小段代码。
5. AI编程工具的提示词怎么写？怎么让 Copilot 生成更符合需求的代码？
1分钟面试背诵稿
我觉得给 AI 编程工具写提示词，本质上是在做需求表达和上下文约束。提示词写得越具体，生成结果通常越稳定。最差的写法就是只说一句“帮我写一个功能”，因为模型不知道你的技术栈、代码风格、边界条件和输出要求。
更有效的提示词，一般要包含几部分。第一是目标，要明确你想实现什么功能。第二是上下文，比如当前项目用的是 React、TypeScript、哪套状态管理、已有接口和组件在哪里。第三是约束，比如要不要兼容旧代码、是否遵循现有目录结构、是否补测试、是否禁止引入新依赖。第四是输出形式，比如只修改当前文件、分步骤输出、先给方案再给代码，或者直接生成可运行代码。
如果想让 Copilot 生成更符合需求的代码，关键不是一味加长 prompt，而是把相关代码、类型定义、接口契约、已有示例和注释放到它能感知到的位置。因为 Copilot 很依赖当前编辑区附近的上下文，你给它越清晰的函数签名、注释、示例和相邻代码，它就越容易沿着正确模式补全。
所以我的经验是，先把需求拆小，再把上下文喂准，再把约束说清。不要只让它“写代码”，而要告诉它“在什么项目里、按什么规范、基于什么已有实现、产出什么结果”。这样生成的代码才更接近真实工程需求。
6. 代码的重构建议怎么生成？什么时候该提取函数，什么时候该合并代码？
1分钟面试背诵稿
我理解代码重构建议的生成，核心不是机械地把代码拆得更碎，而是判断当前代码是否真的影响了可读性、复用性和维护成本。AI 可以辅助发现一些典型信号，比如函数过长、嵌套太深、重复逻辑过多、命名不清、职责混杂、条件分支复杂，或者同一段逻辑在多个地方反复出现。
什么时候该提取函数，通常有几个判断标准。第一，这段逻辑有明确语义，值得被命名。第二，它在多个地方会复用。第三，当前函数职责太多，拆出来以后主流程会更清晰。第四，拆出来后更容易单测和复用。也就是说，提取函数的前提是“抽出来以后更好理解”，而不是单纯为了让函数变短。
什么时候该合并代码，一般是在发现过度抽象的时候。比如两个函数几乎只差一个变量名，拆分后反而要来回跳转才能理解；或者本来是一段连续业务流程，被拆成很多很薄的包装函数，导致阅读成本更高。这时候合并反而更好，因为它能减少无意义抽象，让逻辑更直接。
所以我的判断标准一直是：看抽象之后，代码是不是更容易理解、更容易修改、更容易测试。如果提取函数能强化语义边界，就拆；如果抽象只是增加跳转和心智负担，就合。重构的目标不是形式上的“更优雅”，而是工程上的“更可维护”。
7. Cursor、Windsurf这些AI IDE有什么特点？和传统IDE有什么区别？
1分钟面试背诵稿
我觉得 Cursor、Windsurf 这类 AI IDE 的核心特点，是把大模型能力直接嵌进了开发环境，不只是做代码补全，而是让 IDE 从“被动工具”变成“可以协作的智能助手”。它们通常支持自然语言改代码、跨文件理解、基于整个仓库生成或修改代码、自动解释报错、生成测试、批量重构，甚至可以直接执行一部分工程任务。
和传统 IDE 相比，最大的区别不是界面，而是交互方式变了。传统 IDE 主要依赖人手动搜索、跳转、编写、调试，IDE 负责提供编辑、诊断、插件和调试能力；而 AI IDE 会在这个基础上增加一层“意图驱动”的交互，也就是你可以直接告诉它要实现什么、修什么、重构什么，它再去理解上下文并协助完成。
第二个区别是上下文处理能力。传统 IDE 更像是代码浏览和编辑工具，理解主要靠程序员自己；AI IDE 会主动利用当前文件、相邻代码、项目结构甚至仓库级上下文，去生成更贴合项目风格的结果。它本质上是在 IDE 里加入了一个代码 Agent。
但我认为 AI IDE 并不是替代传统 IDE，而是在其基础上升级工作方式。传统 IDE 的语法分析、调试、断点、插件生态依然非常重要；AI IDE 的价值是在这些能力之上，进一步提升理解、生成和自动化执行效率。所以本质上看，传统 IDE 是“工具平台”，AI IDE 更像是“工具平台加一个能协作的工程代理”。
8. 程序修复（Program Repair）怎么做？怎么自动修Bug？
1分钟面试背诵稿
我理解 Program Repair，本质上是让系统自动完成“发现问题、定位原因、生成修复方案、验证修复结果”这一整套闭环，而不是简单让模型改一段代码。因为真正难的不是生成 patch，而是确保这个 patch 真的修好了问题，而且没有引入新的回归。
一个比较完整的自动修 Bug 流程，通常分成几步。第一步是问题定位，比如拿到报错日志、异常堆栈、失败测试、监控告警或者用户反馈，先缩小到相关模块和可疑代码。第二步是构建修复上下文，包括相关函数、调用链、类型定义、配置、最近变更和已有测试。第三步是生成候选修复方案，可能是一条也可能是多条。第四步是自动验证，比如跑单测、集成测试、lint、类型检查，必要时再做回归测试。
所以自动修 Bug 的关键，不是让 AI 直接“猜答案”，而是给它足够的问题上下文和验证机制。比如用 failing test 作为修复目标，就是非常经典的做法：只要生成的代码能让失败测试通过，同时不破坏其他测试，就说明修复质量更可信。
从工程角度看，真正可落地的 Program Repair 一定是“生成加验证”的模式。AI 负责提出修复候选，人和工具链负责筛选和确认。也就是说，自动修复不是一次性替代工程师，而是把修 Bug 变成一个可搜索、可评估、可回滚的自动化过程。
9. LangGraph是什么？
1分钟面试背诵稿
LangGraph 可以理解成一个专门用来构建 AI Agent 的底层编排框架。它不是单纯帮你调一个大模型接口，而是把 Agent 的执行过程抽象成一个有状态的图，也就是用节点表示步骤，用边表示流转，让模型调用、工具调用、条件分支、循环、多 Agent 协作这些流程都能被显式控制。
它的核心价值，在于特别适合做复杂、长流程、可恢复的 Agent 系统。比如一个任务要经历检索、推理、调用工具、人工确认、再继续执行，这种流程如果只靠普通 prompt 很难稳定管理，但用 LangGraph 可以把状态、节点和转移关系明确建模。
从工程角度看，LangGraph 重点解决的是 Agent orchestration，也就是 Agent 编排问题。它强调几个能力：有状态执行、持久化、checkpoint、human-in-the-loop、流式输出，以及长任务的可靠运行。所以它更像 Agent 的工作流引擎，而不是单纯的对话封装库。
如果做类比的话，LangChain 更偏组件和高层封装，LangGraph 更偏底层运行时和流程控制。简单说，LangGraph 就是当你不满足于“问一句答一句”的简单调用，而是想真正搭建可控、可追踪、可恢复的 Agent 系统时，会用到的那一层框架。