AI 基础和编程工具

AI 基础和编程工具

目录


人工智能的概念

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

AI 模型工作原理

确定性 vs 概率性

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

构建你的 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_filesearch_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(分步骤指令)

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

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


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 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花了不少时间
prompt
Cursor: 少量的prompt, 正确的实现了要求的功能

结论:模型和工具的选择非常重要,有时差距很大


结论

Rules + OpenSpec + MCP + SubAgents + agent skills

相关资源

留下评论

您的电子邮箱地址不会被公开。 必填项已用 * 标注

Index