AI 基础

目录

• AI 基础
• 目录
• 人工智能的概念
• AI 模型工作原理
  • 确定性 vs 概率性
  • 模型局限性
  • 为什么模型会产生幻觉？
  • 其他模型的局限
• Token 与成本
  • Token 概念
  • 计费方式
  • 流式响应
  • 优化策略
• 其它核心概念
• 上下文管理
  • 什么是上下文？
  • 上下文的工作方式
  • 上下文限制
• 工具与代理
  • 工具调用
  • 工作原理
  • 为什么对编码很重要
  • 工具定义
  • 工具成本
  • MCP（Model Context Protocol）
  • 代理（Agent）
  • 工作原理
  • 适合委托给代理的任务
  • 代理的局限性
  • 如何高效使用代理
  • Agent Skills（代理技能）
  • 什么是 Agent Skills
  • 核心特性
  • 使用方法
  • Subagents（子代理）
  • 什么是 Subagents
  • 激活方式
  • 使用场景
• 实践应用
  • 消息类型
  • 示例场景
  • Prompt 编写原则
  • 原则一：编写清晰、具体的指令
    • 1. 使用分隔符区分指令和上下文
    • 2. 提供少量示例，明确输出格式
  • 原则二：给模型时间去思考
    • 拆解任务步骤，引导模型思考
• 相关资源

---

人工智能的概念

• 机器学习：一种人工智能的实现方法，通过数据训练模型来完成任务。
• 深度学习：一种机器学习方法，使用多层神经网络来学习数据的表示和抽象。
• 深度学习模型：有多种不同的模型架构，目前最热门的是：
• Transformer 模型：基于自注意力机制（Self-Attention Mechanism）的神经网络架构
  • 示例：GPT（Generative Pre-trained Transformer）是基于 Transformer 的生成式预训练模型

---

AI 模型工作原理

确定性 vs 概率性

传统软件是确定性的：相同输入总是产生相同输出
AI 模型是概率性的：相同输入可能产生不同输出

构建你的 AI 心智模型的第一点：不要假设每次都会得到相同答案。
模型基于训练信息和用户输入（提示词）来预测下一个词。需要注意两点：
– 相同模型和提示词可能产生不同响应
– 模型可能不严格遵循指令

模型局限性

为什么模型会产生幻觉？

模型基于学到的模式预测下一个 token，有时会被模式带偏。当模型不知道某件事时，它不会说”不知道”，而是基于见过的模式生成看似合理的内容。

编程中的表现：
– 编造不存在的 API 方法
– 混淆不同库或框架的语法
– 捏造不真实的配置项

知识截止日期（Knowledge Cutoff）：模型训练数据截止到某个日期，询问该日期之后出现的内容可能得到错误答案。

其他模型的局限

• 自信的错误答案：模型可能自信地给出错误答案，甚至表示”你说得完全对”
• 确定性任务表现不佳：在生成随机数字、统计字符等确定性任务上表现不佳

---

Token 与成本

Token 概念

Token 是 AI 模型实际处理的基本单位，可以理解为模型处理的”词”，但不完全等同于日常词语：
– 模型将文本拆分为更小的片段（tokens）
– 例如：”hello”可能是一个 token，”understanding”可能被拆分为”under”、”stand”、”ing”等多个 tokens
– 词的部分、标点或空格也可能单独成为 token

计费方式

AI 模型基于两类 token 收费：
– 输入 token：包括发送给模型的所有内容（提示词、对话历史等）
– 输出 token：包括模型返回的所有生成内容
– 价格差异：输出 token 通常比输入 token 贵 2–4 倍（生成新内容需要更多计算）

重要性：
– 计费方式：按 token 计费，而不是按单词或字符
– 速度指标：更快的模型具有更高的 TPS（每秒 token 数）

流式响应

AI 模型按顺序逐个生成 token，因此会看到回复逐词出现：

• 工作原理：模型先预测下一个 token，再用该预测帮助预测后续 token
• 优势：无需等待完整回复，可以实时查看生成过程，并可随时中断

优化策略

成本控制：
– 控制初始上下文中的信息量
– 引导模型保持简洁或提供详细内容
– 自动缓存经常复用的提示部分
– 管理每次请求包含的上下文
– 精简提示词，去除冗余信息

---

其它核心概念

• 参数（Parameters）：模型的复杂度和性能指标，参数数量通常决定了模型的能力。
• Temperature（温度）：控制模型输出的创造性和确定性之间的平衡：
• 高 Temperature：生成的文本更多样、更有创造性
• 低 Temperature：生成的文本更确定、更保守
• 多模态（Multimodal）：模型能够处理多种不同类型的数据（文字，图片，音频，视频等），单模态模型只能处理其中一种类型的数据

---

上下文管理

与 AI 模型协作的本质在于管理你提供的上下文，而不仅仅是写更好的提示词。

什么是上下文？

上下文是 AI 模型保留对话工作记忆的长列表，包含：

• 系统提示词（System Prompt）：工具创建者设置的指令、风格和规则，引导输出方向
• 用户消息/提示词：你给模型的任何指令（可以是文本、代码、图片等）
• 对话历史：之前的输入和输出消息
• 附加文件：当前打开的文件、终端输出、linter 错误等（工具自动添加）
• 多模态内容：图片、文档等（模型会将其转换为文本表示纳入上下文）

上下文的工作方式

• 累积性：对话中的每条消息（输入和输出）都会存储在上下文中
• 有限性：上下文容量有限，随着对话增长，早期信息可能被遗忘
• 自动包含：像 Cursor 这样的工具会自动添加相关代码库信息

上下文限制

• 每个 AI 模型的上下文限制各不相同，一旦触及限制，模型将不再接受更多消息
• 应对策略：
• 监控上下文使用量
• 压缩或总结旧对话
• 有选择地包含必要信息

---

工具与代理

工具调用

工具调用让 AI 模型能够动态执行操作并获取信息，而不仅仅是生成文本。模型可以自行调用其他 API，扩展自身能力。

工作原理

开发者可以定义供 AI 模型使用的特定”工具”。工作流程：

sequenceDiagram
    participant User as 用户
    participant AI as AI模型
    participant Tool as 工具系统
    participant API as 外部API/服务

    User->>AI: 发送请求/提示词
    Note over AI: 分析请求，判断是否需要工具
    AI->>AI: 选择合适工具
    AI->>Tool: 调用工具（工具名+参数）
    Tool->>API: 执行工具操作
    API-->>Tool: 返回执行结果
    Tool-->>AI: 返回工具结果
    Note over AI: 基于工具结果生成回复
    AI-->>User: 返回最终回复

常见应用：ChatGPT 生成图片、搜索网页、运行代码等都使用了工具调用。

为什么对编码很重要

工具让 AI 模型能够：

• 读取与写入文件到代码库
• 搜索代码查找相关函数或模式
• 运行 shell 命令测试代码或安装依赖
• 访问文档或在网上搜索最新信息
• 检查错误通过运行 linter 或测试

没有工具时，AI 模型只能使用上下文中明确提供的信息。有了工具，它可以主动探索并与代码库交互。

工具定义

每个工具包含三个主要组成部分：

• 名称：例如 read_file 或 search_web
• 描述：告知模型何时以及如何使用该工具
• 参数：工具运行所需的输入

示例：

{
  "name": "read_file",
  "description": "从代码库中读取文件内容",
  "parameters": {
    "filepath": "要读取的文件路径"
  }
}

模型调用时会生成：

{
  "tool": "read_file",
  "parameters": {
    "filepath": "src/components/Button.tsx"
  }
}

工具成本

调用工具会通过两种方式消耗 token：

• 工具定义：包含在输入上下文中（通常每个工具占用几百个 token）
• 工具结果：添加到输出上下文中（取决于返回内容）

大量使用工具会更快占满上下文窗口并产生更高成本，但通常值得，因为能获取实时信息。

MCP（Model Context Protocol）

MCP 是一个新标准，让 AI 模型在不同应用间使用并集成各类工具。就像 USB 连接设备的标准一样，MCP 旨在成为连接工具到 AI 模型的通用标准。

应用示例：
– 连接 Figma 获取设计文件
– 连接 Linear 查看和管理任务
– 连接数据库直接查询数据
– 创建自定义 MCP 服务器集成内部工具和 API

代理（Agent）

代理是工具在循环中运行：让 AI 模型调用多个工具、自己决定用哪些工具，并从结果中学习。你无需一步步告诉 AI 怎么做，而是给它一个目标，让它自行规划步骤。

工作原理

代理通过一系列工具调用完成任务，并根据每次操作的结果决定下一步：

示例：让代理”在设置页面添加深色模式开关”
1. 搜索代码库定位设置页面
2. 读取相关文件理解结构和样式
3. 自行制定计划（添加状态变量、创建 CSS 类、实现开关组件等）
4. 执行每一步时自检、运行测试、修复错误

适合委托给代理的任务

表现出色的任务（目标清晰、模式成熟）：
– 为现有代码添加测试
– 更新文档
– 在多文件中进行模式化重构
– 修复具有明确报错信息的缺陷

容易遇到困难的任务：
– 需要深入理解系统交互的复杂调试
– 将视觉设计稿精确到像素的还原
– 使用训练数据中未包含的新库

代理的局限性

• 需要监督：容易遗忘，可能陷入循环，反复采用失败的方法
• 成本较高：包含大量工具调用和迭代，消耗的 token 远多于简单问题
• 可能过度修改：缺乏良好约束时，可能做出不打算的更改
• 需要验证：你仍需负责验证代码能否正确运行并符合标准

如何高效使用代理

• 从小任务开始：先委派小而明确的任务，建立信心
• 设置检查点：在过程中设置验证步骤
• 明确约束：在合并更改前要求通过测试等护栏
• 角色定位：你担任架构师和审阅者，代理负责实现细节
• 目标：不是消除人工参与，而是放大你的成效

Agent Skills（代理技能）

Agent Skills 是扩展代理能力的模块化组件，类似于可插拔的工具包，让代理能够执行特定领域的任务。

什么是 Agent Skills

Agent Skills 是一种将专业知识、指令和资源封装成可复用模块的机制。每个技能包含：

• 指令（Instructions）：告诉代理如何使用该技能的具体指导
• 元数据（Metadata）：技能的名称、描述、版本等信息
• 资源（Resources）：可选的脚本、参考文档、示例代码等辅助材料

技能结构如下：

my-skill/
├── sill.md       # 指令 + 元数据
├── scripts       # 脚本  
├── references/   # 文档
└── assets/       # 模版 + 资源

核心特性

1. 渐进式披露机制

为了优化上下文使用，技能采用三阶段按需加载：

• 阶段一：初始化时仅加载元数据（技能名称、描述等）
• 阶段二：AI 判断需要时加载完整指令
• 阶段三：按需访问资源文件（脚本、文档等）

sequenceDiagram
    participant Agent as AI代理
    participant SkillBox as 技能箱
    participant Metadata as 元数据
    participant Instructions as 指令
    participant Resources as 资源文件

    Note over Agent,Resources: 阶段一：初始化加载元数据
    Agent->>SkillBox: 请求可用技能列表
    SkillBox->>Metadata: 加载技能元数据
    Metadata-->>SkillBox: 返回技能名称、描述
    SkillBox-->>Agent: 返回技能列表（仅元数据）

    Note over Agent,Resources: 阶段二：按需加载完整指令
    Agent->>Agent: 分析任务，判断需要技能
    Agent->>SkillBox: 请求加载技能完整指令
    SkillBox->>Instructions: 加载技能指令
    Instructions-->>SkillBox: 返回完整指令内容
    SkillBox-->>Agent: 返回技能指令

    Note over Agent,Resources: 阶段三：按需访问资源
    Agent->>Agent: 执行任务，需要特定资源
    Agent->>SkillBox: 请求访问资源文件
    SkillBox->>Resources: 加载特定资源
    Resources-->>SkillBox: 返回资源内容
    SkillBox-->>Agent: 返回资源文件
    Agent->>Agent: 完成任务

这种机制可以显著减少上下文消耗，提高效率。

使用方法

1. 安装技能

openskills install anthropics/skills

2. 同步技能

// 同步到AGENTS.md
openskills sync

Subagents（子代理）

Subagents 是一种将复杂任务拆解为多个专精子角色的实践方法，每个子代理在独立的上下文中完成明确的子任务。

什么是 Subagents

在复杂的 AI 编程场景中，单一代理可能难以高效处理所有任务。Subagents 通过以下方式解决这个问题：

• 任务分解：将复杂任务拆解为多个明确的子任务
• 角色专精：每个子代理专注于特定的职责领域
• 上下文隔离：子代理拥有独立的上下文，避免相互干扰
• 结果汇总：将各子代理的结果汇总到主任务中

激活方式

1. 自动委托

平台根据描述和上下文自动匹配并委派任务：

• 适合常见职责（如代码审查、测试生成）
• 减少手动配置工作
• 提高使用便利性

示例：

任务："审查这段代码并生成测试"
→ 自动委托给 code-reviewer 和 test-generator 子代理

2. 显式调用

在提示词中直接指定子代理：

• 适合需要精确控制的场景
• 明确指定使用的子代理
• 提高调用的确定性

示例：

"Use the test-runner subagent to fix failing tests"
"请使用代码审查子代理检查这段代码"

使用场景

典型应用场景：

1. 代码审查流程
2. code-reviewer：审查代码质量和规范
3. security-auditor：检查安全问题

4. performance-analyzer：分析性能问题

5. 功能开发流程

6. architect：设计架构和接口
7. implementer：实现具体功能
8. tester：编写测试用例

9. documenter：生成文档

10. Bug 修复流程

11. bug-analyzer：分析问题根因
12. fix-implementer：实现修复方案
13. test-verifier：验证修复效果

实践应用

消息类型

大语言模型的对话通常包含三种消息类型：

消息类型	说明	作用
System Message	系统消息	设置大语言模型的角色和行为，如：手机导购服务员、理财专家、证券分析师、软件工程师等
User Message	用户消息	用户输入的问题或指令
Assistant Message	助手消息	大语言模型输出的答案

示例场景

场景描述：你是一个证券分析师，请分析腾讯公司股票的合理估值

消息分解：

• System Message：你是一个证券分析师
• User Message：请分析腾讯公司股票的合理估值
• Assistant Message：大语言模型的输出

提示：Prompt 模板主要负责大语言模型角色的定义

Prompt 编写原则

原则一：编写清晰、具体的指令

1. 使用分隔符区分指令和上下文

❌ 优化前：

把下面的文本翻译成英文，总结一下会议纪要

✅ 优化后：

把下面的文本翻译成英文："总结一下会议纪要"

改进点：使用引号分隔符明确区分了指令和需要处理的文本内容。

2. 提供少量示例，明确输出格式

通过示例让模型理解期望的输出格式：

示例 1：时间字符串格式

Python 获取当前时间，并输出当前时间字符串，输出格式例子如下："2025/5/26 11:44:30"

示例 2：JSON 格式（完整时间）

Python 获取当前时间，并按年、月、日、小时、分钟、秒输出 JSON 格式的字符串

示例 3：JSON 格式（日期）

Python 获取当前时间，并按年、月、日输出 JSON 格式的字符串，例子：{"y": 1998, "m": 05, "d": 20}

原则二：给模型时间去思考

拆解任务步骤，引导模型思考

通过明确的任务步骤，帮助模型更好地理解和执行复杂任务。

❌ 示例 1（简单指令）：

介绍一下腾讯这家公司

✅ 示例 2（分步骤指令）：

介绍一下腾讯这家公司，先介绍腾讯的核心业务，然后介绍各项核心业务的营收，再介绍各项业务的市场占用率和排名，最后给出腾讯公司股价的合理估值

改进点：通过明确的步骤分解，引导模型按照逻辑顺序思考，输出更结构化的结果。

相关资源

• OpenAI Prompt Engineering Guide
• LangChain Prompt Templates
• AI 基础
• 面向开发者的LLM入门教程
• agentskills