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 的核心原则：

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

让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（十亿）的缩写，指的是模型的参数数量。简单理解：参数越多，模型越"聪明"，但也越慢、越贵。

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

对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 是本教程推荐的主力模型，由 Anthropic 公司开发。

核心优势：

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