从大模型原理到前端 AI Coding 工程化实践

AI 编程工具正在从"代码补全"和"聊天问答"演进为可以读取仓库、调用工具、修改文件、运行验证并持续推进任务的工程代理。对前端工程师而言，真正需要掌握的不是某一个工具的按钮用法，而是理解大模型如何工作、上下文如何影响结果、工具调用如何扩展模型能力，以及如何通过 MCP、Agent、Skill、Memory、Hook 等机制把 AI 编程纳入真实开发流程。

本文结合大模型基础概念和 Claude Code 工程化实践，系统梳理 LLM、Token、Context、Prompt、RAG、Tool、MCP、Agent、Skill 等核心概念，并进一步讨论它们在前端业务开发中的落地方式，包括接口驱动开发、UI 改造、代码审查、项目规则沉淀和团队协作提效。

关键词

大模型、Token、Context、Prompt、RAG、Tool、MCP、Agent、Skill、Claude Code、AI Coding、前端工程化

1. 背景：AI 编程不是更聪明的聊天框

很多人第一次使用 AI 编程工具时，会把它当成一个"更聪明的聊天框"：问一个问题，等一段答案；让它写一段代码，再手动复制进项目。这种方式能解决局部问题，但很难真正进入工程流程。

以 Claude Code、Codex 这类工具为代表的新一代 AI 编程工具，已经不只是回答问题。它们可以运行在代码仓库中，读取项目文件，理解上下文，修改代码，执行命令，接入外部工具，并在一个任务中持续推进。

它们的典型工作循环可以概括为：

rust 复制代码

读取上下文 -> 判断任务边界 -> 修改文件 -> 运行验证 -> 汇报结果

因此，学习 AI 编程的重点不是"怎么问得更漂亮"，而是理解如何把 AI 放进工程流程：什么时候让它读代码，什么时候让它调用工具，什么时候让它执行修改，什么时候必须由工程师做判断和验收。

对前端团队来说，AI Coding 的核心价值也不是少写几行代码，而是减少上下文切换，降低重复劳动，提升接口对齐、页面开发、代码审查和文档沉淀的效率。

2. 大模型的本质：基于上下文预测下一个 Token

大模型看起来像是在理解人类语言，但从生成机制上看，它更像一个复杂的文本预测系统。

当用户向模型提问时，模型并不是一次性生成完整答案，而是根据当前输入预测下一个最可能出现的 Token。生成一个 Token 后，它会把这个 Token 接回上下文，再继续预测下一个 Token。这个过程不断重复，直到输出结束标记。

rust 复制代码

用户输入 -> 预测下一个 Token -> 接回上下文 -> 继续预测 -> 输出结束

这也是为什么 AI 的回答通常是逐步生成的。它并不是简单的界面动画，而是模型生成机制本身决定的。

这个机制带来一个非常重要的工程结论：模型不是天然知道正确答案，它是在当前上下文中生成概率上最合理的内容。当上下文不足、任务边界模糊或资料不可靠时，模型可能会补全、猜测，甚至自信地产生错误。

所以 AI 编程的第一原则不是"让模型随便发挥"，而是给它准确、充分、可验证的上下文。

3. Token：模型处理文本的基本单位

模型本质上处理的是数字，不是人类文字。在文字进入模型之前，需要经过 Tokenizer。

Tokenizer 主要做两件事：

把文字切分成 Token。
把 Token 映射成模型可以处理的数字 ID。

可以理解为：

rust 复制代码

文字 -> Tokenizer 切分 -> Token ID -> 模型处理 -> 输出 Token ID -> 解码成文字

Token 不一定等于一个汉字，也不一定等于一个英文单词。它是模型训练过程中形成的一套文本切分单位。对于中文、英文、代码、符号，Tokenizer 的切分方式都可能不同。

Token 对 AI 编程有直接影响。模型的上下文窗口按 Token 计算，因此不能无限制地把所有代码、文档、聊天记录都塞给模型。复制太多无关内容，不仅浪费上下文空间，还可能干扰模型判断。

在工程实践中，更合理的方式是让 Agent 按任务需要读取相关文件，而不是人工一次性粘贴大量代码。上下文不是越多越好，而是越相关越好。

4. Context：大模型的临时工作台

Context 是模型本次任务能看到的全部信息。它通常包括用户问题、历史对话、系统提示词、工具列表、读取到的文件内容、工具调用结果以及模型正在生成的内容。

可以把 Context 理解成模型的"临时工作台"。模型没有人类意义上的长期记忆，它能"记住"前面发生过什么，是因为平台把历史信息作为上下文再次传给了它。

在 AI Coding 场景中，Context 质量直接决定输出质量。一个没有读取项目代码的 Agent，只能根据通用经验猜测项目结构；一个读取了路由、组件、接口、store、样式和项目规则的 Agent，才有机会做出符合当前工程的修改。

因此，在真实开发中，不建议一开始就让 AI 直接改代码。更稳的方式是先让它读取上下文：

复制代码

请先不要修改代码。请阅读当前页面相关的路由、组件、接口和样式，说明这个功能的数据流、组件关系和可能影响范围。

这一步看似增加了前置时间，但它能明显减少后续返工。

5. Prompt：不是玄学，而是任务协议

Prompt 不是越长越好，也不是堆一堆"你是资深专家"就一定更强。对 AI 编程来说，好的 Prompt 更像一份任务协议。

一个合格的工程任务描述通常包含五部分：

复制代码

背景：为什么要做。
范围：允许改哪些文件或模块。
目标：最终要达到什么效果。
约束：不能破坏什么。
验收：怎样判断完成。

例如，一个模糊提示是：

复制代码

这个布局不对，帮我改一下。

更适合 Agent 执行的提示是：

css 复制代码

背景：样衣订单详情页 Product 区域列宽不合理。
范围：只修改 sample 商品组件及必要样式。
目标：表头和数据列对齐，最后一列后面不能留下大块空白。
约束：不新增依赖，不改接口结构，不影响 Regular Order 页面。
验收：说明改了哪些文件，并给出手动检查方式。

这类提示的价值在于明确任务边界。Agent 可以持续推进任务，但它不会天然知道哪些文件不能动、哪些模块不能影响、什么结果才算完成。这些边界必须由工程师提供。

6. RAG：让模型查资料，而不是背资料

当外部资料很多时，不能把所有内容都放进模型上下文。例如公司有上千页产品手册，直接全部塞给模型并不现实。

RAG，即检索增强生成，解决的是这个问题。它的基本流程是：

rust 复制代码

用户问题 -> 检索相关文档片段 -> 放入上下文 -> 模型基于片段回答

RAG 的核心不是让模型"记住所有资料"，而是让模型在需要时检索最相关的资料。

在前端开发中，类似资料包括组件库文档、业务规则、接口说明、历史需求、代码规范、设计规范等。如果这些资料能被稳定检索，AI 就不需要依赖用户每次手动复制粘贴上下文。

RAG 更适合知识型资料，而 MCP 更适合工具化和系统化接入。二者可以配合使用：RAG 负责检索文档，MCP 负责调用外部系统。

7. Tool：让模型从问答走向执行

模型本身只能输入文本、输出文本。它不能天然读取文件、运行命令、查询接口或修改代码。这些能力来自 Tool。

常见 Tool 包括：

读取文件。
修改文件。
运行命令。
查询接口平台。
读取设计稿。
读取 GitHub PR。

Tool 是 AI 从"问答"走向"执行"的关键。

没有 Tool，AI 只能告诉你"可能应该怎么改"。有了 Tool，AI 可以进入真实工程循环：

rust 复制代码

读代码 -> 改文件 -> 跑 lint -> 看报错 -> 再修复 -> 汇报结果

这也是 Claude Code、Codex 这类工程代理与普通聊天机器人的本质区别。普通聊天机器人主要输出建议，工程代理可以在仓库里持续操作。

8. MCP：统一 AI 和外部系统的连接方式

MCP，全称 Model Context Protocol，是 AI 接入外部工具和数据源的一种标准化协议。

可以简单理解为：

rust 复制代码

AI Agent -> MCP Server -> 外部系统

MCP Server 把外部系统能力包装成 Agent 可以理解和调用的工具。外部系统可以是接口平台、设计稿平台、Git 平台、数据库、内部业务系统等。

如果没有 MCP，不同 AI 平台可能都要分别适配同一个外部系统。同一个接口平台要接 Claude Code、Codex、IDE 插件、内部 Agent，就可能重复开发多套工具接入逻辑。

MCP 的价值是统一接入方式，让工具能力可以被多个 AI 客户端复用。

在前端团队中，最有价值的 MCP 往往不是复杂炫技，而是高频、低歧义、可验证的业务能力：

接口平台 MCP：读取 Swagger、YApi、OpenAPI 字段。
设计稿 MCP：读取 Figma 页面、组件、间距、颜色。
Git MCP：读取 PR、Issue、Commit、Review 评论。
组件库 MCP：查询组件属性、示例和使用规范。
业务配置 MCP：查询枚举、字典、权限、菜单配置。

以前根据接口开发页面，常见流程是：

rust 复制代码

打开接口平台 -> 复制字段 -> 粘给 AI -> 生成类型和页面字段

接入 MCP 后，可以变成：

复制代码

请读取用户列表接口，生成请求类型、响应类型、表格列和查询表单字段。

这节省的不只是复制时间，更重要的是减少字段遗漏、类型错误和上下文过期。

9. Agent：能持续推进任务的工程代理

Agent 是能围绕目标持续推进任务的工程代理。它不是一个简单聊天框，而是具备任务规划、工具调用、结果反馈和持续执行能力的协作者。

一个 Agent 通常具备三类能力：

理解任务目标。
根据当前状态决定下一步。
调用工具执行，并根据结果继续推进。

典型工作循环是：

rust 复制代码

读取上下文 -> 判断任务边界 -> 修改文件 -> 运行验证 -> 汇报结果

前端开发中，Agent 适合处理这些任务：

阅读陌生模块，梳理入口、组件和数据流。
根据接口生成类型、API 方法、表格列和表单字段。
修复局部 UI 问题。
补充 loading、空态、错误态。
做代码审查，检查行为回归和边界条件。
生成模块文档、迁移说明和 PR 描述。

但并不是所有任务都适合直接交给 Agent。涉及密钥、权限、支付、生产数据、上线决策、产品判断的问题，必须由工程师主导。范围极大的跨模块重构，也应该先拆分任务、明确边界，再让 Agent 分阶段执行。

Agent 很强，但工程师仍然负责边界、判断和验收。

10. Skill：把团队经验写成可复用能力

如果每次使用 Agent 都要重复输入同一批规则，例如：

复制代码

不要新增依赖。
不要改公共组件。
可见文案要接 i18n。
Review 时 Findings 放前面。
改完要说明验证方式。

这说明这些内容不应该继续靠手写 Prompt 维护，而应该沉淀成 Skill 或项目规则。

Skill 是可复用能力包。它比普通提示词更工程化，因为它有固定结构、触发描述、操作流程，还可以携带脚本、模板和参考资料。

一个 Skill 通常包含：

objectivec 复制代码

skill-name/
  SKILL.md
  scripts/
  templates/
  references/

其中 SKILL.md 是核心文件，描述这个 Skill 的触发条件、执行步骤、约束和输出要求。

一个代码审查 Skill 可以这样写：

yaml 复制代码

---
name: code-review
description: 当用户要求代码审查、review、检查 diff、排查回归风险时使用。重点发现 bug、行为回归、安全问题和缺失测试。
---

# Code Review Skill

## 工作流程
1. 先读取当前 diff 和相关文件。
2. 优先寻找会导致线上问题的行为回归。
3. 检查边界条件、异常路径和测试缺口。
4. 输出 Findings，按严重程度排序。

## 输出要求
1. Findings 放在最前面。
2. 每条发现包含文件路径、行号、问题描述和建议。
3. 如果没有发现问题，要说明仍然存在的测试盲区。

Skill 的关键不是"写一段更长的提示词"，而是把团队经验变成稳定流程。它适合沉淀高频、流程明确、输出格式固定、需要项目知识的任务。

前端团队常见的 Skill 包括：

代码审查 Skill。
根据接口生成页面字段 Skill。
Vue 组件改造 Skill。
订单详情页修改 Skill。
国际化检查 Skill。
UI 对齐问题排查 Skill。

11. Memory 与 CLAUDE.md：让项目规则长期生效

CLAUDE.md 是 Claude Code 的项目记忆文件。它不是普通 README，而是给 Claude Code 看的工程协作规则。

适合写进 CLAUDE.md 的内容包括：

技术栈和项目结构。
常用命令。
编码规范。
测试和验证要求。
禁止事项。
项目中特别容易踩坑的规则。

不适合写进去的内容包括一次性需求、很快过期的临时结论、大段无关业务文档、密钥、token、账号密码。

一个项目级 CLAUDE.md 可以这样写：

markdown 复制代码

# Project Instructions

## 技术栈
- Vue 3
- Vite
- Pinia
- Element Plus

## 常用命令
- 安装依赖：npm install
- 本地启动：npm run dev
- 构建：npm run build
- 代码检查：npm run lint

## 编码规则
- Vue 组件优先使用 Composition API。
- 不新增依赖，除非用户明确同意。
- 不直接修改公共组件行为，除非任务明确要求。
- 所有可见文案必须接入 i18n。

## 修改流程
- 修改前先阅读相关组件、路由、mock 和依赖组件。
- 修改时只碰任务范围内的文件。
- 修改后说明变更点和验证方式。

## 安全规则
- 不提交密钥、token、cookie。
- 不运行破坏性命令。
- 不回滚用户未授权的改动。

经验上，当同一条规则被你重复提醒三次以上，就应该写入 CLAUDE.md 或 Skill。

12. Slash Commands、Hooks、Subagents 与 Checkpoints

Claude Code 这类工程代理不只提供 Agent 本体，还会提供一系列工程化能力。

12.1 Slash Commands

Slash Command 更像快捷提示词，适合高频、固定格式的任务。

例如：

bash 复制代码

/review
/summary
/generate-pr

如果任务只是固定提示，不需要脚本、模板和复杂资料，用 Slash Command 就够了。如果任务需要更复杂流程、资料和自动触发能力，更适合做成 Skill。

12.2 Hooks

Hook 是在特定事件自动触发的脚本或检查。

常见使用场景包括：

修改代码后自动 format。
写文件后自动跑 lint。
执行危险命令前拦截。
提交前检查敏感信息。
会话结束前检查是否说明验证方式。

Hook 的价值是把"提醒 AI 要做"变成"系统自动做"。但 Hook 不适合做很慢的全量检查，否则每次小改动都会拖慢流程。

12.3 Subagents

Subagent 是专门处理某类任务的子代理。主代理负责统筹，子代理负责具体子任务。

它适合复杂任务拆分，例如：

css 复制代码

主代理：负责整体方案和最终合并。
代理 A：只负责分析订单详情 Regular 页面布局。
代理 B：只负责分析 Sample 页面布局。
代理 C：只负责检查 mock 数据字段和接口兼容性。

使用 Subagent 的关键是边界清晰，尤其是写文件范围不能冲突。

12.4 Checkpoints

Checkpoint 是会话和文件状态的快照，用于探索式开发中的回退。

例如：

rust 复制代码

先尝试方案 A -> 不满意 -> rewind -> 尝试方案 B

它适合 UI 方案试错、大重构前后对比、改错方向后快速回退等场景。

13. 前端 AI Coding 的推荐工作流

前端开发中，比较稳的 AI Coding 工作流是：

rust 复制代码

先读代码 -> 明确边界 -> 小步修改 -> 运行验证 -> 汇报风险

13.1 小改动工作流

适合修样式、改文案、小逻辑。

markdown 复制代码

请修改 <文件/模块>，目标是 <具体效果>。

约束：
1. 不新增依赖。
2. 不改接口结构。
3. 不影响其他页面。

改完请说明修改文件和验证方式。

13.2 中型功能工作流

适合新增页面、接接口、多组件联动。

markdown 复制代码

请先阅读相关代码，不要立刻修改。目标是实现 <功能>。

请先输出：
1. 需要修改的文件。
2. 数据流和组件关系。
3. 可能风险。
4. 实现步骤。

如果方案明确，再继续实现。

13.3 大型重构工作流

适合跨模块、跨目录、多文件改造。

rust 复制代码

计划模式 -> 拆子任务 -> 必要时使用 Subagents -> 小步提交 -> 每步验证

大型重构最重要的不是速度，而是控制风险。

14. 前端场景一：接口驱动页面开发

前端开发中，经常需要根据接口生成页面字段，包括 TypeScript 类型、API wrapper、表格列、查询表单和 mock 数据。

如果靠人工复制接口字段，很容易漏字段、错类型、字段名不一致。

没有 MCP 时，流程通常是：

rust 复制代码

打开接口平台 -> 复制字段 -> 粘给 AI -> 生成代码 -> 手动修字段

有 MCP 和 Skill 后，流程可以变成：

rust 复制代码

Agent 调用接口平台 MCP -> 读取接口结构 -> 按 Skill 生成类型和字段 -> 写入项目 -> 运行验证

推荐提示：

markdown 复制代码

请通过接口平台 MCP 读取 <接口名称或 ID>。

目标：
1. 生成请求参数和响应数据 TypeScript 类型。
2. 生成 API 调用函数。
3. 生成表格 columns。
4. 生成查询表单字段。

约束：
1. 字段名必须以接口为准。
2. 可见文案接 i18n。
3. 不新增依赖。
4. 如果接口字段含义不明确，请标注推断。

这个场景中，MCP 负责提供真实接口信息，Skill 负责规定生成方式，Agent 负责读取项目、修改文件、运行验证，工程师负责确认业务含义和最终验收。

15. 前端场景二：复杂页面和 UI 改造

UI 改造最容易出现的问题，是 Agent 没有先理解页面结构，直接局部修改，导致其他页面或业务类型被影响。

例如修复样衣订单详情页 Product 区域布局，可以这样描述：

markdown 复制代码

请修改样衣订单详情页 Product 区域布局。

范围：
1. 优先修改 src/views/order/components/sample/SampleCommodity.vue。
2. 如有必要，可以同步调整 orderDetailsSample.vue 的容器样式。

目标：
1. 表头和数据列严格对齐。
2. Product 列可以更宽，让商品名称尽量单行显示。
3. 最后一列 Remaining to Link 后方不能留下大块空白。
4. 多余宽度平均分配给各列，而不是集中在最右侧。

约束：
1. 不影响 Regular Order 的 Product 布局。
2. 不新增依赖。
3. 不改 mock 数据结构。

验收：
1. 给出修改文件。
2. 说明如何手动检查。
3. 如果没有运行自动验证，要说明原因。

理想执行路径是：

读取 Sample 商品组件。
读取 Regular 商品组件作为参考。
找到表头和行布局的 CSS。
统一 grid-template-columns 或 table layout。
保证数据行和表头使用同一列定义。
检查最后一列宽度和容器自适应。
汇报变更和验证方式。

这类任务的关键不是"让 AI 快点改"，而是先让它读懂影响范围，再做小步修改。

16. 前端场景三：代码审查与排障

Review 是非常适合 AI 辅助的场景，因为它有稳定的关注点和输出格式。

一个基础 Review 提示可以是：

markdown 复制代码

请 review 当前改动，Findings 优先。

重点关注：
1. 行为回归。
2. 边界条件。
3. 缺失测试。
4. 安全风险。
5. 性能问题。

每条问题必须包含文件路径和行号。

更稳定的做法是把 Review 规则沉淀成 Skill，明确检查顺序、输出格式和项目特殊风险点。

高阶版本可以结合 Subagents：

复制代码

主代理：汇总和最终判断。
安全代理：只看安全风险。
测试代理：只看测试缺口。
性能代理：只看性能风险。

在前端项目中，Review 应重点关注权限、订单状态、接口参数、空值、枚举、i18n、响应式、表格宽度、loading 状态、错误态和缺失测试。

17. 常见误区与纠正方式

17.1 只给一句模糊需求

错误：

复制代码

帮我优化一下。

纠正：

css 复制代码

请优化 src/views/order/components/sample/SampleCommodity.vue 的表格布局。目标是表头和数据列对齐，Product 列允许更宽，最后一列后方不能留下大块空白。不新增依赖，不影响 Regular 页面。

17.2 不告诉 Agent 什么不能改

Agent 会尝试完成目标，但如果没有边界，它可能改到你不想改的地方。

纠正方式是每次任务都写约束：

复制代码

不能新增依赖。
不能改接口返回结构。
不能改公共组件。
不能回滚用户已有修改。

17.3 长期规则每次手打

如果规则长期有效，就应该放进 CLAUDE.md 或 Skill。

objectivec 复制代码

请把"所有可见文案必须接 i18n"写入项目 CLAUDE.md，以后默认遵守。

17.4 不验证

改完代码但不运行验证，是最常见风险。

bash 复制代码

改完后请运行可用的 lint/test/build。如果无法运行，请说明原因和人工验证方式。

17.5 复杂任务不拆分

复杂任务直接让 Agent 一口气做完，容易遗漏。

复制代码

请先拆成 3 到 5 个可验证阶段，每阶段说明输入、输出、风险和验证方式。

18. 团队落地路线

团队刚开始引入 AI Coding 时，不建议一开始追求全自动化。更稳的路线是先建立可验证的小闭环。

18.1 写项目规则

先写 CLAUDE.md，沉淀技术栈、目录结构、常用命令、编码规范和禁止事项。

18.2 固定 Prompt 模板

至少准备三类模板：

读代码模板。
实现需求模板。
Review 模板。

18.3 沉淀高频 Skill

优先做这些：

code-review。
swagger-page-fields。
vue-component-refactor。
order-detail-workflow。

18.4 接入 MCP

优先接入只读能力：

接口平台。
设计稿。
组件库文档。
Git PR。

先只读，后写入；先草案，后自动化。

18.5 加验证 Hook

从轻量检查开始：

修改后提示运行 lint。
提交前检查敏感信息。
会话结束前检查是否说明验证方式。

不要一开始就把所有全量检查都塞进 Hook。

19. 总结

大模型的基础能力来自 Token、Context 和概率生成。Tool 让模型能接触外部世界，MCP 让外部系统可以用统一方式接入 AI，Agent 让 AI 从"回答问题"变成"持续执行任务"，Skill 让团队经验可以被复用，Memory 让项目规则长期生效，Hook 让验证和安全检查自动化。

Claude Code、Codex 这类工具真正改变的，不是让开发者少写几行代码，而是让很多原本需要人工切换上下文、查资料、复制字段、写模板、跑检查的环节，进入一个可复用、可验证的工程循环。

对前端工程师来说，最实用的目标不是让 AI 替代开发，而是让 AI 成为稳定的工程协作者：

复制代码

工程师负责判断、边界和验收。
Agent 负责读取、执行和反馈。
MCP 负责提供可靠上下文。
Skill 负责固化团队方法。
Memory 负责沉淀长期规则。
Hook 负责自动化检查。

当团队开始把高频任务写成 Skill，把接口平台接成 MCP，把项目规则写进 Memory，把验证流程接入 Hook，就不再只是"会用 AI 写代码"，而是在建设一套可持续迭代的 AI 工程化能力。