当前位置：首页 > news >正文

Vibe Coding--初识AI编程

news 2026/6/16 19:08:06

走进AI编程

AI是如何理解和生成代码的？

token化：AI不像人一样一个字一个字的读代码，而是把文本切成一个个小块，叫做token。

例如，Hello World 会被切成 Hello 和 World 两个 Token。中文的 你好世界 可能被切成 你好 和 世界 两个 Token，也可能被切成更多个。

为什么这个概念重要？因为AI的计费和能力限制都以 Token 为单位。你发送的内容越长，消耗的 Token 越多，费用越高。

提示：简单记住这个换算关系 —— 1 个 Token ≈ 4 个英文字符 ≈ 1-2 个中文字符。一篇 1000 字的中文文章大约是 500-1000 个 Token。

上下文窗口：AI的"工作记忆"

上下文窗口是AI一次能"记住"的内容量。这就像你的办公桌大小 —— 桌子越大，能同时摊开的文件越多。

对于AI编程来说，上下文窗口越大越好 —— 因为AI需要同时"看到"更多项目代码才能做出合理的修改。Claude、Gemini、GPT 等主流模型都在持续扩大上下文窗口。

概率生成：为什么AI有时会"胡说八道"

AI生成内容的本质是预测概率最高的下一个词。大多数时候它预测得很准，但有时候它会"一本正经地胡说八道" —— 这被称为"幻觉"（Hallucination）。

Vibe Coding：感觉驱动的编程新范式

Vibe Coding就是不要纠结代码的每一个细节，跟着感觉走，让AI帮你实现想法。

Vibe Coding 的核心原则：

意图优先：先描述你想要什么效果，而不是告诉AI怎么写代码
快速迭代：不追求一次完美，拥抱"生成 → 测试 → 修正"的循环
信任但验证：相信AI的能力，但始终检查关键逻辑
上下文经营：持续维护和优化提供给AI的背景信息

Vibe Coding 适用场景：

原型开发、概念验证（快速把想法变成可运行的东西）
个人项目、学习项目（试错成本低）
探索性编程（不确定最终效果，边做边看）
UI/前端开发（可视化反馈快，容易判断好不好）

Vibe Coding 需谨慎的场景：

注意：生产环境的核心系统（银行、医疗等）
注意：安全敏感代码（认证、加密等）
注意：性能极致要求的场景

Agentic Engineering：工程化升级范式

为什么纯 Vibe Coding 在大项目中不够用

Vibe Coding 对于做小项目、快速原型非常好用，但当项目变大变复杂时，纯粹的"跟着感觉走"会遇到麻烦：

代码质量不可控：AI可能写出能跑但很乱的代码，积累成"技术债务"
前后矛盾：AI在不同对话中可能给出相互冲突的实现方式
缺乏全局视角：AI可能只关注当前的小任务，忽略对整体架构的影响
难以协作：没有统一规范时，多个人（或多次会话）的代码风格各异

什么是智能体（Agent）

智能体（Agent）是一个能够自主完成任务的AI系统。

智能体的工作循环是 感知（读取项目代码、理解需求） → 推理（分析问题，制定计划） → 行动（修改文件、运行命令、安装依赖）→ 反馈（检查结果、发现新问题）：

Claude Code 就是一个典型的编程智能体 —— 你告诉它"帮我添加一个用户注册功能"，它会自己读懂项目代码，自己创建文件，自己写代码并运行测试。

智能体协作模式

当一个智能体不够用时（比如项目特别复杂），可以让多个智能体协作，各司其职。

领导者-执行者模式（Leader-Worker）

一个"老板"Agent负责拆分任务和协调，多个"员工"Agent负责执行具体任务。

Qoder 就是这种模式的典型代表 —— 有 Leader（指挥官）、Coding（开发者）、Research（研究员）、Verify（测试员）等多个 Agent 角色。

管道式协作（Pipeline）

Agent按顺序接力，就像工厂流水线：

需求分析Agent → 架构设计Agent → 代码实现Agent → 测试Agent → 部署Agent

对等协作（Peer-to-Peer）

多个Agent平等地互相审查，就像同事之间互相Code Review。

一般一个单智能体就能完成大多数项目了，当项目足够复杂时，再考虑Qoder 等多智能体方案。

自主决策与任务分解

优秀的AI编程智能体不会一股脑地把所有代码写出来，它会像一个经验丰富的程序员一样，先思考再行动：

Plan-Act-Observe-Reflect 循环：

1. Plan（规划）：   "要完成登录功能，我需要做这些事......"
2. Act（行动）：   "先创建数据库用户表......"
3. Observe（观察）："创建成功了，但发现少了一个字段......"
4. Reflect（反思）："我需要修改表结构，加上邮箱字段......"
5. 回到 Plan：     "好的，现在继续下一步......"

任务分解原则 —— MECE：

MECE（Mutually Exclusive, Collectively Exhaustive）是一个管理咨询中常用的概念，意思是"相互独立，完全穷尽"。

举个例子，把"构建一个博客系统"分解为：

构建博客系统
├── 1. 用户系统（注册、登录、个人资料）
├── 2. 文章系统（创建、编辑、删除、列表）
├── 3. 评论系统（发表、删除、回复）
├── 4. 分类标签（创建分类、打标签、按分类筛选）
└── 5. 部署上线（打包、配置服务器、域名）

这5个子任务之间互不重叠（相互独立），合在一起覆盖了博客系统的全部功能（完全穷尽）。

在使用 Claude Code 时，最佳实践是先让AI制定计划，你确认后再执行。而不是一上来就让它开始写代码。这个习惯会大幅减少返工。

规范驱动开发 SDD（Specification-Driven Development）

为什么AI编程需要"规范"？

如果你告诉AI"帮我做一个网站"，它可能做出一个和你期望完全不同的东西。"垃圾进，垃圾出" —— 模糊的需求必然导致不准确的结果。

规范（Specification）就是你和AI之间的"合同"，它明确地写清楚：

要做什么（功能需求）
怎么做（技术方案）
做到什么程度（质量标准）

有了这份"合同"，AI才能精准地理解你的意图。

需求规范：PRD文档

PRD（Product Requirements Document，产品需求文档）描述的是"要做什么"。

用户故事（User Story）格式：

作为一个 [角色]，
我希望 [功能]，
以便 [价值/目的]。

例如：

作为一个博客读者，
我希望能按标签筛选文章，
以便快速找到我感兴趣的内容。

验收标准（Acceptance Criteria）格式：

Given（前提条件）：系统中有20篇文章，其中5篇标记了"Python"标签
When（操作）：用户点击"Python"标签
Then（预期结果）：页面只显示这5篇标记了"Python"标签的文章

用AI辅助生成PRD的Prompt：

你可以让AI帮你把模糊的想法变成结构化的需求文档：

我想做一个个人书签管理工具。请帮我生成一份完整的PRD文档，包含：
1. 项目概述（一句话描述）
2. 目标用户
3. 核心功能列表（按优先级排列：Must Have / Should Have / Nice to Have）
4. 每个功能的用户故事和验收标准
5. 非功能需求（性能、安全、兼容性）请用Markdown格式输出。

技术规范：SPEC文档

SPEC（Technical Specification，技术规范文档）描述的是"怎么做"。

一个完整的SPEC文档包含：

模块	内容	说明
系统架构	整体架构设计图	前后端如何交互
技术选型	使用什么技术和框架	比如 Next.js + Prisma + SQLite
数据模型	数据库表结构设计	有哪些表、每个表有哪些字段
API接口	接口定义	每个API的URL、请求参数、返回格式
目录结构	项目文件组织	代码放在哪个文件夹

让AI从PRD自动生成SPEC的Prompt：

基于以下PRD文档，请生成对应的技术规范文档（SPEC）：[粘贴你的PRD内容]要求：
1. 推荐技术选型并说明理由
2. 设计完整的数据模型（包含字段类型和关系）
3. 列出所有API接口（RESTful风格）
4. 给出建议的项目目录结构

质量规范

质量规范定义了"做到什么程度算合格"：

编码规范：代码风格统一、命名规则、注释要求
测试规范：需要覆盖哪些测试场景
安全规范：输入验证、认证授权、数据保护

规范文件的组织与管理

建议在项目根目录下创建一个 specs/ 文件夹，统一管理规范文件：

my-project/
├── specs/
│   ├── PRD.md         # 产品需求文档
│   ├── SPEC.md         # 技术规范
│   ├── ARCHITECTURE.md   # 架构设计
│   └── API.md         # API 接口文档
├── src/              # 源代码
├── CLAUDE.md          # 给Claude Code的项目说明（详见第二部分）
└── package.json

规范文件最大的价值之一是 —— 可以直接作为AI工具的上下文输入。当你把 SPEC.md 的内容提供给 Claude Code 时，它就能精准地按照你的技术方案来写代码。

主流模型系列介绍

大语言模型基础知识

参数量：模型的"大脑"大小

你可能听说过"7B模型"、"70B模型"这样的说法。这里的 B 是 Billion（十亿）的缩写，指的是模型的参数数量。简单理解：参数越多，模型越"聪明"，但也越慢、越贵。

参数量级	能力	类比
1-7B	基础对话、简单代码	小学生
7-30B	较好的编程、推理能力	中学生
30-70B	优秀的编程、复杂推理	大学生
70B+	顶级的编程、深度推理	研究生

上下文窗口：再次强调的核心概念

对AI编程来说，上下文窗口直接决定了AI能"看到"你项目中多少代码。窗口越大，AI对项目的理解越全面，生成的代码越准确。

4K Token   ≈ 一个文件      → 只能看到当前文件
32K Token  ≈ 几个文件      → 能看到相关的几个文件
128K Token ≈ 一个小项目    → 能理解整个小项目
200K Token ≈ 一个中型项目   → 许多主力模型的长上下文起点
1M Token   ≈ 一个大型项目   → Claude / Gemini / GPT 等旗舰模型的超长上下文级别

Token 计费：你的"油费"

使用AI模型就像开车需要加油 —— Token 就是你的"油"，用多少付多少。

费用 = 输入Token数 × 输入单价 + 输出Token数 × 输出单价

Temperature：AI的"创造性开关"

Temperature 是一个 0-1 之间的参数，控制AI回复的"随机性"：

Temperature = 0：每次给出几乎相同的答案（最确定性）→ 适合代码生成
Temperature = 1：每次答案都不同（最随机）→ 适合创意写作

提示：编写代码时，通常不需要手动调整 Temperature。Claude Code 默认使用适合编程的低 Temperature 值。

Claude 系列（Anthropic）

Claude 是本教程推荐的主力模型，由 Anthropic 公司开发。

模型	上下文	速度	代码能力	推理能力	费用档位	关键特点
Claude Haiku 4.5	200K	极快	良好	中等	$	轻量任务、批处理、低成本
Claude Sonnet 4.6	1M	快	优秀	强	$$	日常开发主力，性价比高
Claude Opus 4.7	1M	中等	顶级	极强	$$$	复杂规划、架构和疑难问题

核心优势：

超长上下文（200K 到 1M，随模型不同而变化），项目级代码理解能力强
代码生成质量在业界领先
指令遵循能力精确（你说什么，它就做什么）
安全对齐好（不容易生成危险代码）

1.4.3 GPT 系列（OpenAI）

模型	定位	特点	适用场景
GPT-5.5	最新旗舰	推理、编程、多模态综合能力最强	复杂开发、架构设计、疑难调试
GPT-5.x mini / nano	轻量模型	速度快、成本低	简单任务、批量处理
o 系列推理模型	深度推理	强化数学、算法、复杂推理	算法题、复杂约束问题

核心优势：多模态能力强、工具调用生态成熟，和 Codex / ChatGPT / OpenAI API 的集成最完整。

适合场景：将UI截图转换为代码、需要视觉理解的任务。

1.4.4 GLM 系列（智谱AI）

智谱AI的GLM系列（配套 CodeGeex 代码助手），中文能力和代码能力均衡，国内可用。

模型	特点	在 cc 中的角色
GLM-4.7	智谱当前默认主力模型，代码与推理均衡	默认占用 Opus / Sonnet 槽位
GLM-4.5-Air	轻量、高速	默认占用 Haiku 槽位
GLM-5.1	高阶推理模型，能力更强	需手动覆盖三个槽位才会启用，高峰期算 3 倍消耗

1.4.5 DeepSeek 系列国内推荐

模型	特点	适用场景
deepseek-v4-pro[1m]	DeepSeek 官方 Claude Code 接入示例使用的主力模型	通过 Anthropic 兼容端点接入 Claude Code
deepseek-v4-flash	轻量高速模型	适合 Haiku / Subagent 等轻量槽位

注意：模型名与后续变化请以 DeepSeek 官方文档为准。

核心优势：

极致性价比：价格远低于官方 Claude
代码能力强，接近 Claude Sonnet 水平
国内直连，注册简单
官方为 Claude Code 提供了专用的 Anthropic 兼容端点，适配度高

1.4.6 通义千问系列（阿里云）

模型	特点	适用场景
Qwen-Plus / Qwen-Max	均衡性能、中文优化	中文项目的日常开发
Qwen3-Coder / Qwen-Coder 系列	代码专精	纯编程任务、代码生成

核心优势：中文理解能力出色、国内直连、阿里云生态集成。

1.4.7 其他值得关注的模型

模型	开发者	特点	场景
Gemini Pro 系列	Google	超大上下文、多模态	超长代码库分析
Kimi / Moonshot 系列	月之暗面	长上下文、中文好	中文长文档处理
Llama 系列	Meta	开源旗舰、可本地部署	离线/隐私敏感场景
Mistral 系列	Mistral AI	欧洲开源、代码能力强	本地部署替代方案

1.4.8 模型选型实战指南

1.4.8.1 选型决策树

面对一个编程任务时，按以下流程选择模型：

你的任务是什么？
│
├── 简单任务（代码补全、格式化、小修改）
│   ├── 追求最快速度 → Claude Haiku / GLM-4.5-Air / 本地 Qwen
│   ├── 追求最低成本 → DeepSeek API / 本地 Ollama
│   └── 完全免费 → 本地 Ollama 模型
│
├── 日常开发（功能实现、Bug修复、代码生成）
│   ├── 英文项目 → Claude Sonnet （首选）
│   ├── 中文项目 → Claude Sonnet 或 通义千问 / GLM-4.7
│   └── 预算紧张 → DeepSeek V4 / GLM / Kimi
│
├── 复杂任务（架构设计、算法难题、疑难Bug）
│   ├── 深度推理 → Claude Opus / GPT-5.5 / DeepSeek V4 Pro
│   └── 超长代码库 → Gemini Pro (1M上下文)
│
└── 特殊场景├── 离线/隐私要求 → 本地 Ollama + Llama/Qwen├── 截图→代码 → GPT-5.5 / GPT-4o 系列（多模态）└── 国内直连要求 → DeepSeek / 千问 / GLM

1.4.8.2 成本优化策略

策略一：分层使用

简单任务 ──→ Haiku / GLM-4.5-Air / 本地 Qwen（成本：$）
日常任务 ──→ Sonnet / DeepSeek V4 Pro      （成本：$$）
复杂任务 ──→ Opus / GLM-5.1              （成本：$$$$）

不要所有任务都用最贵的模型，就像不是每次出门都需要打专车。

策略二：Prompt Cache（缓存利用）

Claude 和 GPT 都支持 Prompt Cache —— 如果你发送的上下文中有大量重复内容（如每次都发送同一个 CLAUDE.md），后续请求可以复用缓存，显著降低重复上下文的输入成本。

策略三：本地模型补充

对于简单的代码格式化、注释生成等任务，可以使用 Ollama 部署的本地模型，完全免费。

一个月的费用预估：

使用强度	推荐模型	月费用估算
轻度（每天1-2小时）	DeepSeek API / GLM / Kimi	¥5-30（视模型与套餐）
轻度	Claude Sonnet	$10-30（约¥70-210）
中度（每天3-5小时）	Claude Sonnet	$30-80（约¥210-560）
重度（全天使用）	Claude Sonnet + Haiku	$80-200（约¥560-1400）

1.4.9 安全与隐私考量

方案	数据隐私	适用场景
云端API（Claude/GPT等）	数据经过服务商服务器	一般项目、学习项目
本地部署（Ollama）	数据不出本机	企业敏感代码、隐私要求高