AI 基础和编程工具
目录
- AI 基础和编程工具
- 目录
- 人工智能的概念
- AI 模型工作原理
- Token 与成本
- 其它核心概念
- 上下文管理
- 工具与代理
- 实践应用
- AI coding
- 三种模式
- AI 编码方法
- 实践分享
- 结论
- 相关资源
人工智能的概念
- 机器学习:一种人工智能的实现方法,通过数据训练模型来完成任务。
- 深度学习:一种机器学习方法,使用多层神经网络来学习数据的表示和抽象。
- 深度学习模型:有多种不同的模型架构,目前最热门的是:
- 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"
"请使用代码审查子代理检查这段代码"
使用场景
典型应用场景:
- 代码审查流程
code-reviewer:审查代码质量和规范security-auditor:检查安全问题-
performance-analyzer:分析性能问题 -
功能开发流程
architect:设计架构和接口implementer:实现具体功能tester:编写测试用例-
documenter:生成文档 -
Bug 修复流程
bug-analyzer:分析问题根因fix-implementer:实现修复方案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(分步骤指令):
介绍一下腾讯这家公司,先介绍腾讯的核心业务,然后介绍各项核心业务的营收,再介绍各项业务的市场占用率和排名,最后给出腾讯公司股价的合理估值
改进点:通过明确的步骤分解,引导模型按照逻辑顺序思考,输出更结构化的结果。
AI coding
业界已有的AI编程工具按照插件、IDE、独立终端三个维度进行划分:
| 类型 | 工具名称 | 开发商 | 主要功能特点 | 支持的IDE/平台 |
|---|---|---|---|---|
| 插件 | GitHub Copilot | GitHub/Microsoft | 基于GPT-4模型的代码补全,支持多种编程语言,自动生成代码建议 | VS Code, JetBrains, Visual Studio, Neovim |
| 插件 | Codeium | Codeium | 免费AI代码补全工具,支持多种模型,提供代码生成和聊天功能 | VS Code, JetBrains, Vim, Emacs |
| 插件 | Amazon CodeWhisperer | Amazon | AWS官方AI编程助手,支持代码补全、安全扫描和代码建议 | VS Code, JetBrains, Visual Studio |
| 插件 | Tabnine | Tabnine | 企业级AI代码补全,支持私有部署,提供代码预测和自动完成 | VS Code, JetBrains, Vim, Sublime |
| 插件 | Continue | Continue.dev | 开源AI编程助手,支持多种模型,提供代码编辑和聊天功能 | VS Code, JetBrains |
| 插件 | Sourcegraph Cody | Sourcegraph | 基于代码库理解的AI助手,提供代码搜索、解释和生成功能 | VS Code, JetBrains |
| 插件 | Aider | Aider | AI代码编辑助手,支持多文件编辑和代码重构 | VS Code |
| 插件 | CodeBuddy | 腾讯 | 由腾讯混元与DeepSeek双模型驱动,支持跨IDE协作,符合等保三级要求 | VS Code, JetBrains |
| 插件 | Cursor Agent | Cursor | Cursor的VS Code插件版本,提供AI代码生成和编辑功能 | VS Code |
| IDE | Cursor | Cursor团队 | 基于VS Code的AI升级版,深度集成LLM,提供上下文感知的代码生成和调试建议 | 独立应用 |
| IDE | Cline | 开源社区 | AI驱动的代码助手,理解整个代码库,规划复杂变更并执行多步骤任务 | VS Code插件/独立版本 |
| IDE | Continue.dev | Continue.dev | 开源AI IDE,支持多种模型,提供完整的AI编程体验 | 独立应用 |
| IDE | Zed | Zed Industries | 高性能编辑器,内置AI功能,支持代码补全和编辑 | 独立应用 |
| IDE | Trae | 字节跳动 | AI原生IDE,支持中文描述生成项目结构和代码,内置GPT-4o模型 | 独立应用 |
| IDE | Codeium Chat | Codeium | Codeium的独立聊天界面,支持代码生成和问答 | 独立应用 |
| IDE | Windsurf | Codeium | AI驱动的集成开发环境,支持智能代码补全、实时错误检测、自动化调试和多语言支持 | 独立应用 |
| 命令行 | Warp | Warp | AI增强的终端工具,提供命令建议和自动补全 | 独立应用 |
| 命令行 | Aider CLI | Aider | 命令行AI代码编辑工具,支持Git集成和多文件编辑 | 终端 |
| 命令行 | Cline CLI | Cline | Cline的命令行版本,支持终端中的AI代码助手功能 | 终端 |
| 命令行 | GitHub Copilot CLI | GitHub | GitHub Copilot的命令行版本,支持终端中的代码生成 | 终端 |
| 命令行 | Cursor CLI | Cursor | Cursor的命令行工具,支持终端中的AI代码操作 | 终端 |
| 命令行 | Continue CLI | Continue.dev | Continue的命令行版本,提供终端中的AI编程功能 | 终端 |
| 命令行 | CodeBuddy CLI | 腾讯 | CodeBuddy的命令行版本,支持终端中的代码生成和编辑 | 终端 |
| 命令行 | Gemini CLI | Google Gemini的命令行工具,支持代码生成和问答 | 终端 | |
| 命令行 | Codeium CLI | Codeium | Codeium的命令行版本,支持终端中的代码补全和生成 | 终端 |
工具分类说明
插件
- 集成到现有IDE中,无需切换开发环境
- 通常提供代码补全、代码生成、代码解释等功能
- 适合希望增强现有IDE功能的开发者
IDE
- 完整的开发环境,深度集成AI功能
- 提供更丰富的AI交互体验和上下文理解
- 适合希望获得完整AI编程体验的开发者
独立终端
- 轻量级,适合终端工作流
- 通常支持脚本化和自动化
- 适合喜欢命令行操作和需要集成到自动化流程的开发者
主要工具简介
Cline
有免费模式,可选模型和响应速度比较受限
也支持购买的自定义模型

CodeBuddy
公司内部免费的推荐使用CodeBuddy, 可选各种先进模型包括Cluade, GPT, gemini等
Cursor
基于VS Code的AI升级版IDE,深度集成大型语言模型,提供上下文感知的代码生成、调试建议和自然语言重构功能。
小技巧:Ctrl+M 自动生成提交信息
Gemini CLI
Google Gemini的命令行工具,支持代码生成和问答功能。

三种模式
Ask:聊天模式
Plan:先规划后执行,类似下面介绍的规范驱动开发
Agent: 代理,自动完成编码任务
AI 编码方法
在使用 AI 辅助编程时,有多种不同的方法来指导 AI 生成代码。理解这些方法的区别和适用场景,可以帮助你更高效地与 AI 协作。
Rules(规则驱动)
Rules 是一种通过明确的规则和约束来指导 AI 生成代码的方法。这种方法强调精确性和可预测性。
特点:
– 明确性:通过具体的规则、约束和规范来指导 AI
– 可预测性:相同规则下,AI 生成的代码风格和行为相对一致
– 结构化:规则通常以列表、条件语句等形式组织
适用场景:
– 需要严格遵循代码规范和最佳实践
– 团队协作,需要统一的代码风格
– 有明确的架构约束和设计模式要求
– 需要符合特定框架或库的约定
示例:
规则:
- 使用 TypeScript,启用严格模式
- 所有函数必须有类型注解
- 使用 async/await 处理异步操作
- 错误处理使用 try-catch
- 函数名使用 camelCase,常量使用 UPPER_SNAKE_CASE
优势:
– 生成的代码质量稳定,符合规范
– 便于团队协作和代码审查
– 减少代码风格不一致的问题
局限性:
– 规则过多可能导致 AI 理解困难
– 灵活性相对较低,可能限制创造性
– 需要维护和更新规则文档
Vibe-coding(感觉驱动)
Vibe-coding 是一种通过描述代码的”感觉”、风格或整体印象来指导 AI 的方法,而不是使用严格的规则。
特点:
– 描述性:通过自然语言描述期望的代码风格和感觉
– 灵活性:不依赖严格的规则,允许 AI 有更多发挥空间
– 直观性:更容易表达难以用规则描述的设计意图
适用场景:
– 探索性编程和原型开发
– 需要快速迭代和尝试不同方案
– 代码风格要求不那么严格的项目
– 个人项目或小型项目
示例:
"写一个简洁优雅的 React 组件,感觉要现代、轻量,用 hooks 风格,
代码要易读,不要过度工程化"
优势:
– 表达方式更自然,易于沟通
– 允许 AI 有更多创造性
– 适合快速原型和探索
局限性:
– 结果可能不够一致
– 难以精确控制代码细节
– 可能不适合大型团队项目
Spec-coding(规范驱动)
Spec-coding 是一种通过详细的规范(specifications)来指导 AI 生成代码的方法,介于 Rules 和 Vibe-coding 之间。
特点:
– 详细性:提供完整的功能需求、接口定义、行为描述
– 结构化:使用结构化的方式描述需求(如用户故事、场景、测试用例)
– 完整性:不仅描述”做什么”,还描述”怎么做”和”为什么”
适用场景:
– 复杂功能的实现
– 需要详细文档和测试的项目
– 遵循规范驱动开发(Spec-Driven Development)的项目
– 需要可追溯性和可维护性的项目
示例:
需求:实现用户登录功能
规范:
- 输入:用户名和密码
- 验证:检查用户名格式(邮箱或手机号)
- 安全:密码使用 bcrypt 加密存储
- 响应:成功返回 JWT token,失败返回错误码
- 场景:
- 场景1:有效凭证 → 返回 token
- 场景2:无效凭证 → 返回 401
- 场景3:用户不存在 → 返回 404
优势:
– 生成的代码更符合需求
– 便于测试和验证
– 支持规范驱动的开发流程
– 可追溯性强
局限性:
– 需要编写详细的规范,工作量较大
– 可能过于正式,不适合快速迭代
– 需要维护规范文档
方法选择建议
| 方法 | 适用场景 | 团队规模 | 项目阶段 |
|---|---|---|---|
| Rules | 需要严格规范、团队协作 | 中大型团队 | 生产环境 |
| Vibe-coding | 快速原型、探索性开发 | 个人/小团队 | 早期阶段 |
| Spec-coding | 复杂功能、需要文档化 | 中大型团队 | 设计/开发阶段 |
最佳实践:
– 根据项目阶段和需求灵活选择方法
– 可以组合使用:用 Spec 定义功能,用 Rules 约束实现,用 Vibe 调整风格
– 在团队中建立共识,统一编码方法的使用标准
openspec 使用
// step1: install
npm install -g @fission-ai/openspec@latest
// step2: initialze projec
cd my-project
openspec init
// 按提示交互命令执行
实践分享
个人相册管理
核心功能:
1. 检查文件名称是否包括清晰的年月日信息,如果没有读取文件的信息,并重命名
2. 去重
3. 分类
codebuddy:详细的需求描述和执行步骤,基本实现了要求的功能,但有些实现细节不符合需求描述,修Bug花了不少时间

Cursor: 少量的prompt, 正确的实现了要求的功能
结论:模型和工具的选择非常重要,有时差距很大
结论
Rules + OpenSpec + MCP + SubAgents + agent skills
