Skip to main content

AI辅助编程

核心概念理解​

Prompt, Prompts (模板) & Rules (系统规则)​

人机交互的最基础层与资产沉淀。

  • Prompt (单次提示词)：你给 AI 下达的即时指令（比如“帮我写一个按钮”），具有随意性和单次性。
  • Prompts (可复用提示词模板)：将高价值的工程流固化为团队资产（例如 IDE 中的 Snippets 或项目里的 .prompt 文件）。比如沉淀一个 CodeReview.prompt，规定好“以安全专家身份审查，只看 XSS 和内存泄漏”，需要时一键调用。这是将 AI 从“聊天工具”转变为“标准化流水线”的关键（即 Prompt as Code）。
  • Rules (全局系统规则)：全局的“底线约束”与“人设”（例如 .cursorrules 或 .windsurfrules）。它潜伏在每次对话的底层，告诉 AI：“在这个项目里，你必须用 React 18，绝对不能用 any”。这是约束 AI 随机性、统一代码风格的第一道防线。

Context (上下文)​

大模型的“短期记忆”与“视界”。

  • 概念：大模型本身是无状态的，你每次问它问题，它之所以能连贯回答，是因为工具把你们之前的对话、你当前打开的文件都作为“上下文”一并打包发给了它。
  • 痛点：上下文窗口（Token 限制）是极其宝贵的资源。给的太少，它会“瞎编”；给的太多，它会“中间遗忘”且浪费钱。

Function Calling (函数调用) & Skills (技能/工具)​

大模型与外部世界交互的“手和脚”。

  • Function Calling：大模型只能输出文本，无法执行操作。开发者预先描述好一些函数，大模型理解意图后输出一段 JSON：“请帮我执行这个函数”。
  • Skills：在 AI 开发框架中，基于 Function Calling 封装好的高阶能力。比如让 AI 具备 RunCommand (跑终端)、WebSearch (联网)、SearchCodebase (检索代码库) 的能力。

Agent (智能体)​

从“副驾驶 (Copilot)”到“自动驾驶 (AutoPilot)”的跃迁。

  • 概念：具备自主规划、决策和执行能力的系统。传统 AI 是你敲代码它补全；Agent 是你给一个目标（如“写个登录页”），它自己去利用 Context 读文档、利用 Skills 跑命令建文件、报错了自己看日志修复，实现真正的闭环。

RAG (检索增强生成) & Embeddings (向量化)​

给大模型外挂的“记忆外脑”与“私有知识库”。

  • 概念：大模型看不懂汉字或代码，只能看懂数字（Embeddings 向量）。语义越相近的内容，在多维空间里的距离就越近。
  • 应用：当项目极大无法全部塞进 Context 时，先去向量数据库里检索 (Retrieve) 出最相关的片段，增强 (Augment) 到 Prompt 里，再让 AI 生成 (Generate) 回答。IDE 里的 @Codebase 底层就是 RAG。

MCP (Model Context Protocol) 与 Skills 的关系​

AI 时代的 USB-C 接口（终极互联标准）。

  • 痛点：以前想让 AI 读取本地数据库、查 Notion 文档，每个 AI 工具都要单独写一遍集成代码。
  • 概念：Anthropic 提出的一种开源标准协议。只要你的数据源提供了一个 MCP Server，任何支持 MCP 的 AI 客户端（如 Cursor、Trae）都能像插 U 盘一样，直接读取你的专属数据并采取行动。
  • 与 Skills 的区别与联系：
    • Skills 是一个广义概念，泛指赋予大模型的“外挂能力”（比如 IDE 内置的 WebSearch 或 RunCommand）。
    • MCP 是目前实现 Skills 的最先进、最标准化的底层协议。你可以把 MCP Server 里面暴露出来的一个个 Tools，就当做是供给 AI 调用的 Skills。用 MCP 来写 Skills 的好处是：你写一次，所有的 AI 工具（Claude Desktop、Cursor、Trae）都能直接兼容使用。

边界认知：AI 不能做什么？​

面试官经常会问：“既然 AI 这么强，那还要程序员干什么？”这就需要你清晰地界定 AI 的能力边界。

  1. 无法理解“没有写在代码里的”隐性业务上下文
    • 很多业务逻辑、历史包袱、甚至“老板的一句话”是口口相传的，没有被文档化。AI 看不到这些，强行让 AI 改代码极容易破坏历史兼容逻辑。
  2. 无法承担技术架构的“主观责任”
    • 技术选型是需要权衡团队技术栈熟练度、服务器成本和交付周期的。AI 可以给出 10 种方案的优缺点，但最终拍板决策并为系统崩溃背锅的只能是人类。
  3. 极难排查跨系统的复杂偶发 Bug
    • 比如一个由 Nginx 配置、后端微服务、前端状态管理和网络抖动共同导致的偶发性 Bug，目前的 AI 缺乏在真实多系统中主动插桩、联调并排查的直觉。

上下文管理实战：每次代码生成都不一样怎么解决？​

面试题：使用 AI 写代码时，经常发现它每次给的方案都不一样，或者上下文丢失乱改代码，你怎么解决？

大模型是无状态且具备随机性 (Temperature) 的。要让其输出稳定、符合预期，核心在于精确的上下文控制：

  1. 强制固定上下文边界 (Explicit Context)
    • 绝不让 AI 自己“漫天寻找”上下文。使用 @Files 或 @Folders 精确指定 AI 只能参考哪几个文件，排除噪音干扰。
  2. 遵守强约束的 Rules (系统提示词)
    • 利用好项目根目录的 .cursorrules 等文件。将团队规范固化，从而在每次对话中自动为 AI 注入底线约束。
  3. 提供 Few-Shot (少样本范例)
    • 不要只说“帮我写一个列表页”，而是说“参考 @UserList.tsx 的代码风格和数据流机制，帮我写一个 OrderList”。“照猫画虎”是约束 AI 发散的最有效手段。
  4. 思维链与渐进式 Prompt (Chain of Thought)
    • 避免用一个 Prompt 提出 10 个要求。应该拆解指令：“第一步，分析数据结构；第二步，写出组件骨架；第三步，填充业务逻辑”。

突破上下文窗口局限：如何解决 AI 读不完整个项目的问题？​

面试题：现在的大模型 Token 窗口虽然越来越大（比如 128k, 200k），但在面对大型企业级项目时依然不够用，或者会出现“中间遗忘 (Lost in the middle)”，你是如何解决这个工程化瓶颈的？

这是一个极其考验高级工程化视野的问题。高级开发者不能只靠“把文件拖进对话框”，而应该掌握以下机制：

  1. RAG (检索增强) 与向量化裁剪

    • 痛点：把整个 50MB 的代码库塞给大模型既昂贵又容易让它抓不住重点。
    • 解法：不传全量代码，而是先用 Vector Database (如 Chroma/Milvus) 对代码进行 Embedding 向量化。当提问时，底层只检索出相似度最高的那 5~10 个代码片段（Chunks） 拼接给大模型。这就是 Cursor 等 IDE 能够秒级回答全仓问题的底层基石。

  2. AST (抽象语法树) 提取：只传骨架，不传血肉

    • 痛点：如果 AI 只需要知道某个类的 API 怎么调用，它根本不需要看那几千行的具体实现（函数体）。
    • 解法：在把上下文喂给 AI 之前，先写一个脚本通过 Babel (前端) 或 TypeScript Compiler 解析 AST，把所有函数的内部实现剔除，只保留 Interface、Type、类名和函数签名。这样能把 Token 消耗降低 90%，让 AI 在极小的上下文里看清整个项目的架构图。

  3. Multi-Agent (多智能体协作) 拆分上下文

    • 痛点：一个复杂的全栈需求（改数据库 + 改 Node 接口 + 改 React UI），如果让一个 AI 脑子全记住，很容易顾此失彼。
    • 解法：引入多智能体架构。让 Agent A (架构师) 只读文档和架构图，负责拆解任务；Agent B (后端) 只读 Controller 和 Service 代码写接口；Agent C (前端) 只读 React 组件写 UI。每个 Agent 的上下文都极其纯粹和轻量，最后由一个主 Agent 汇总。

  4. 总结与状态快照 (Session Checkpointing)

    • 痛点：单次长对话达到 Token 上限后，大模型会开始变“蠢”或拒绝回答。
    • 解法：不要在一个对话里聊到底。当完成一个里程碑时，让 AI 生成一份 @MEMORY.md（包含当前进度、遗留问题、全局变量状态）。然后果断开启新对话 (New Chat)，把 @MEMORY.md 作为第一条指令发给它。这叫做“上下文接力”。

AI 实践高频面试题与话术​

Q1：AI 工具对你们团队的研发效能带来了哪些真实改变？​

回答话术： “最大的改变是将程序员从低价值的重复劳动中解放出来。以前写一个带校验的复杂表单需要 1 小时，现在只要丢给 AI 接口的 JSON 结构，10 秒钟就能生成包含 Zod 校验的骨架代码。我们把节省下来的时间，投入到了架构设计、性能调优和复杂的业务边界逻辑梳理上。这让代码产出的下限变得很高，整体提效在 30% 以上。”

Q2：你有没有遇到过 AI 产生“幻觉”（乱写代码）导致的问题？你是怎么处理的？​

回答话术： “遇到过。尤其是当引入了一些比较冷门或者最新大版本的 npm 包时，AI 往往会捏造一些根本不存在的 API。 处理方式有两点：

  1. 防御性编程：绝对不盲目 Accept 代码，必须像 Review 同事提交的 PR 一样去 Review AI 的代码。
  2. 喂给它最新文档：利用 AI IDE 的 @Docs 或 Web Search 功能，把该库最新的官方文档网页直接抓取喂给 AI 作为上下文，强行纠正它的知识库过期问题。”

Q3：你认为未来前端工程师的核心竞争力是什么？​

回答话术： “过去，前端的核心竞争力可能是‘熟练手写 CSS/DOM API’或者‘精通某个框架的语法细节’。但在 AI 时代，这些‘将逻辑翻译成代码’的纯编码技能正在贬值。 未来的核心竞争力在于：

  1. 系统设计与工程化能力：如何设计出松耦合、易于 AI 介入修改和理解的代码架构。
  2. 精准的需求拆解与 Prompt 能力：能把模糊的业务需求，拆解为 AI 能听懂的结构化任务。
  3. 鉴赏与 Debug 能力：在 AI 生成的成百上千行代码中，一眼看出潜在的性能瓶颈和安全漏洞。”