基础概念

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

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

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

示例：

# .cursorrules（项目根目录，AI 每次回答前都会读）
- 技术栈：React 18 + TypeScript（strict 模式）
- 包管理：pnpm，禁止提交 yarn.lock / package-lock.json
- 样式：Tailwind CSS，禁止内联 style
- 命名：组件 PascalCase，工具函数 camelCase
- 绝对禁止使用 any，实在无法标注时用 unknown 收窄

<!-- prompts/CodeReview.prompt（Cursor / Continue 里的可复用模板） -->

角色：高级前端安全工程师
审查范围：只关注 XSS、内存泄漏、O(n²) 以上的时间复杂度
输出格式：表格列出「文件:行号 | 问题类型 | 修复建议」
约束：不要重复赞美代码，只给可执行的修改方案

调用时直接 /CodeReview @src/components/Form.tsx，比每次重新描述"以安全专家身份审查"快 10 秒，也避免遗漏约束。

Context (上下文)

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

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

示例：

❌ 错误示范：直接问"这个按钮点击没反应"——AI 不知道你说的是哪个按钮、哪个文件，只能瞎猜。
✅ 正确示范：@src/components/SubmitButton.tsx:42 这段 onClick 为什么没触发？ —— 精确锁定文件 + 行号。
"中间遗忘 (Lost in the middle)"：往 128k 上下文中塞 50 个文件，让 AI 总结前 10 个文件的逻辑，它对中间第 25 个文件的描述会变得模糊甚至错误。论文证明：模型对首尾位置的信息记忆最好，中间部分最容易丢。

实战技巧：上下文里显式标注优先级（如 ### 高优先级：用户当前报错堆栈 ### 背景代码 ###），比平铺丢给 AI 效果显著更好。

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

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

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

示例：

开发者向模型注册一个函数描述（Schema）：

{
  "name": "get_weather",
  "description": "查询指定城市的实时天气",
  "parameters": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "城市名，如 '北京'" }
    },
    "required": ["city"]
  }
}

用户问"北京今天多少度？"，模型不会直接回答数字，而是输出结构化调用请求：

{
  "function_call": {
    "name": "get_weather",
    "arguments": "{\"city\": \"北京\"}"
  }
}

代码侧拦截到这个请求，真正去调用天气 API，拿到 {"temp": 28, "humidity": 60%} 后，再回填给模型，让它组织成自然语言："北京今天 28℃，湿度 60%……"。模型从未"知道"天气，它只是"调度"了工具。

Agent (智能体)

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

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

示例：你说"给我加一个深色模式切换按钮，存到 localStorage，下次打开还在"。

Copilot 模式：你手动写 useState useEffect localStorage.setItem 模板代码，AI 只补全其中一两行。
Agent 模式：AI 自己规划执行——
1. SearchCodebase 找到现有的 theme.ts 和 Button.tsx
2. Write 新建 hooks/useDarkMode.ts
3. Edit 修改 App.tsx 挂载按钮
4. RunCommand 跑 pnpm tsc --noEmit 验证
5. 报错后自己读日志，定位到 window 未定义 → 改用 useEffect 包一层
6. 再次跑测试，直到通过

整个过程没人介入，这就是"自主闭环"。

Workflow (工作流)

把原子能力「编排」成可重复的端到端流程。

概念：将多个 Skills、Prompt、判断条件和数据流转，按照预设的顺序组合在一起，形成一条"流水线"。典型代表是 n8n、Coze、Dify、LangGraph、AWS Step Functions、GitHub Actions 等。
特点：
- 确定性高：每一步由谁执行、执行什么、失败后如何流转，都是预先编排好的（比如"构建失败就自动发飞书通知"）。
- 可视化：通常以 DAG（有向无环图）或流程图形式呈现，每个节点就是一次 Skill 调用或一次 LLM 推理。
- 强调复用与标准：一次编排，团队内反复运行；新人按图就能接手复杂任务。

示例（Dify / Coze 节点的简化编排）：

[用户输入需求]
   ↓
[LLM 节点：提取需求关键词]
   ↓
[判断节点：是否包含 "数据库迁移"？]
   ↓ 是                    ↓ 否
[Skill: 跑 SQL 迁移]   [LLM 节点：生成代码]
   ↓                       ↓
[Skill: 跑单元测试]  ←─────┘
   ↓
[飞书 Webhook 通知]

每个节点输入什么、输出什么、失败重试几次、是否走哪个分支，都是预先编排好的 YAML/JSON。
AI 只在标了 "LLM 节点" 的位置参与决策；其余节点都是机械执行。
这就是"剧本式"——稳，但面对计划外场景会卡住。

Workflow vs Skill：核心区别（高频面试题）

面试题：Workflow 和 Skill 的区别是什么？

维度	Skill (技能)	Workflow (工作流)
本质	AI 可调用的单个原子能力（如 `RunCommand`）	把多个 Skills 编排在一起的有序流程
控制权	由 AI 自主决定何时调用、如何组合	由开发者/架构师预先编排执行顺序
粒度	细：一个能力点	粗：端到端完整任务
确定性	低（AI 每次可能调不同 Skill）	高（每次都按相同路径跑）
可视化	通常是函数签名/Schema	流程图 / DAG
典型例子	`Read` / `Write` / `WebSearch` / MCP Tool	发布流水线、Coze Bot 编排、LangGraph 图

一句话总结：Skill 是 AI 的"手脚"（单个动作），Workflow 是 AI 的"剧本"（整个流程）。Workflow 里使用 Skill——Workflow 是骨架，Skill 是肉。

联系与演进：

传统 Workflow：所有节点都按预设跑，没有 AI 决策（比如纯 GitHub Actions）。
Agentic Workflow（智能体工作流）：在 Workflow 的关键节点上嵌入 LLM 决策（比如"代码 Review 节点让 AI 评分，低于 80 分就自动打回让 AI 重写"），兼顾稳定性与智能性。这也是目前 LangGraph、Claude Tool Use、Dify Agent 节点的核心卖点。
真正的 Agent 是"无剧本"的——只给目标，AI 自己决定走哪条 Workflow；实际工程中我们往往会用 Workflow 框住 Agent，防止它"放飞自我"乱调 Skill。

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

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

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

示例：

向量空间的几何直觉：Embedding 把文本映射到 N 维空间后，"king" - "man" + "woman" ≈ "queen"（经典词向量代数题）。语义相近的内容在空间里距离近，AI 借此"算"出相关性。
Cursor @Codebase 底层流程：
1. 启动时把整个项目代码切片（每 200~500 行一个 Chunk），用 Embedding 模型转成向量，存入本地向量库（通常是 SQLite + sqlite-vec）。
2. 你问"这个项目的鉴权怎么做？"
3. 把问题也转成向量，在向量库里做近似最近邻搜索 (ANN)，取出相似度 Top-5 的 Chunk，比如：
  - src/middleware/auth.middleware.ts（相似度 0.92）
  - src/utils/jwt.ts（相似度 0.88）
  - src/controllers/login.controller.ts（相似度 0.85）
4. 只把这 5 个片段 + 你的问题打包塞给 LLM，让它基于真实代码回答。
没 RAG 的对照：直接把整个 50MB 仓库塞进 Context，光 token 费就上千美元，且模型会"中间遗忘"。

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）都能直接兼容使用。

示例（Claude Desktop 的 MCP Server 配置）：

// ~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "notion": {
      "command": "npx",
      "args": ["-y", "@notionhq/notion-mcp-server"],
      "env": { "NOTION_TOKEN": "secret_xxx" }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "ghp_xxx" }
    },
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/lucas/Documents"
      ]
    }
  }
}

配好后，AI 客户端里自然语言直接驱动：

"帮我查 Notion 里'2026 OKR'页面的 Q3 目标，然后去 GitHub 仓库 my-app 的 feat/auth 分支上开一个对应的 Issue，并把本地 ~/Documents/notes.md 里我今天写的思路作为 Issue 内容附上去。"

AI 会自动通过 MCP 协议依次调用 Notion、GitHub、Filesystem 三个 Server 完成跨工具操作——你不用再为每个 AI 客户端分别写适配代码。

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

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

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

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

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

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

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

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

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

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

RAG (检索增强) 与向量化裁剪
- 痛点：把整个 50MB 的代码库塞给大模型既昂贵又容易让它抓不住重点。
- 解法：不传全量代码，而是先用 Vector Database (如 Chroma/Milvus) 对代码进行 Embedding 向量化。当提问时，底层只检索出相似度最高的那 5~10 个代码片段（Chunks） 拼接给大模型。这就是 Cursor 等 IDE 能够秒级回答全仓问题的底层基石。
AST (抽象语法树) 提取：只传骨架，不传血肉
- 痛点：如果 AI 只需要知道某个类的 API 怎么调用，它根本不需要看那几千行的具体实现（函数体）。
- 解法：在把上下文喂给 AI 之前，先写一个脚本通过 Babel (前端) 或 TypeScript Compiler 解析 AST，把所有函数的内部实现剔除，只保留 Interface、Type、类名和函数签名。这样能把 Token 消耗降低 90%，让 AI 在极小的上下文里看清整个项目的架构图。
Multi-Agent (多智能体协作) 拆分上下文
- 痛点：一个复杂的全栈需求（改数据库 + 改 Node 接口 + 改 React UI），如果让一个 AI 脑子全记住，很容易顾此失彼。
- 解法：引入多智能体架构。让 Agent A (架构师) 只读文档和架构图，负责拆解任务；Agent B (后端) 只读 Controller 和 Service 代码写接口；Agent C (前端) 只读 React 组件写 UI。每个 Agent 的上下文都极其纯粹和轻量，最后由一个主 Agent 汇总。
总结与状态快照 (Session Checkpointing)
- 痛点：单次长对话达到 Token 上限后，大模型会开始变“蠢”或拒绝回答。
- 解法：不要在一个对话里聊到底。当完成一个里程碑时，让 AI 生成一份 @MEMORY.md（包含当前进度、遗留问题、全局变量状态）。然后果断开启新对话 (New Chat)，把 @MEMORY.md 作为第一条指令发给它。这叫做“上下文接力”。

AI 实践高频面试题与话术

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

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

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

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

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

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

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

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

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

Context (上下文)​

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

Agent (智能体)​

Workflow (工作流)​

Workflow vs Skill：核心区别（高频面试题）​

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

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

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

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

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

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

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

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

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