相信很多开发者都有过类似经历。
刚开始使用 AI 的时候：
帮我分析一下这个项目架构。
AI 回复非常清晰。
但是聊了一段时间之后：
- 添加需求；
- 修改方案；
- 优化代码；
- 补充业务规则；
几十轮之后，AI 开始出现：
- 忘记之前规则；
- 修改不该修改的内容；
- 编造不存在的模块。
这时候很多人的第一反应通常是：
是不是模型变笨了？
但很多时候，问题并不是模型能力下降。
而是：
你的上下文已经把 AI 撑到了极限。
想真正理解这个现象，需要从 AI 最底层的运行机制开始看。
第一步：先理解 Token。
第一章：Token -- AI 世界里的基本单位
1. AI 真的理解文字吗？
很多人以为 AI 像人一样阅读文字。
实际上，AI 并不是直接理解：
"帮我写一个登录接口"。
它看到的是：
人类语言
↓
Tokenizer（分词器）
↓
Token序列
↓
数字ID
↓
神经网络计算
↓
生成新的Token
↓
转换成人类语言Token 是连接人类语言和 AI 世界之间的桥梁。
2. Token 到底是什么？
Token 可以理解为：
AI 处理文本时的最小信息单位。
它不等于：
- 一个字
- 一个单词
- 一个句子
它是模型根据训练数据定义的一种切分方式。
英文示例
输入：
css
I love programmingTokenizer 可能切分：
css
I
love
program
ming然后映射成数字：
yaml
I → 1045
love → 5321
program → 8821
ming → 2938最终模型看到：
yaml
[
1045,
5321,
8821,
2938
]AI 真正处理的是数字，而不是英文。
3. 中文为什么也需要 Token？
例如：
人工智能正在改变软件开发可能被切分为：
人工
智能
正在
改变
软件
开发也可能：
人工智能
正在改变
软件开发不同模型的 Tokenizer 不同，所以 Token 数量也可能不同。
4. 从文字到数字，到底发生了什么？
例如：
帮我写一个登录接口经过 Tokenizer：
帮我
写
一个
登录
接口然后映射：
帮我 → 12341
写 → 88291
登录 → 53221
接口 → 99281模型最终接收到：
css
[12341,88291,53221,99281]完整过程：
文字
↓
Token
↓
数字ID
↓
神经网络计算这就是 AI 理解语言的基础。在理解了什么是 Token 后，回归到上下文。
第二章：为什么上下文越长，AI 越容易"变傻"？
1. 什么是上下文窗口？
Context Window：
就是：
AI 一次能够看到的信息总量。
例如：
128K Context
代表一次最多处理约 128000 个 Token。
注意：
这里的关键：
一次。
2. AI 并没有真正记住聊天记录
很多人认为：
AI 记住了之前所有聊天。
实际上：
每一次请求，应用都会重新把历史消息发送给模型。
例如：
第一次：
diff
系统提示词
+
用户问题第二次：
diff
系统提示词
+
第一次聊天
+
AI回答
+
第二次问题第三次：
diff
系统提示词
+
之前所有内容
+
当前问题3. 上下文增长过程
新对话
sql
┌───────────────┐
│ System Prompt │
├───────────────┤
│ 用户问题 │
│ 100 Token │
└───────────────┘多轮对话
sql
┌───────────────┐
│ System Prompt │
├───────────────┤
│ 第1轮内容 │
├───────────────┤
│ 第2轮内容 │
├───────────────┤
│ 第3轮内容 │
├───────────────┤
│ 当前问题 │
└───────────────┘长时间开发项目
sql
┌────────────────────┐
│ System Prompt │
├────────────────────┤
│ 项目规则 │
├────────────────────┤
│ 第一轮需求 │
├────────────────────┤
│ 第二轮设计 │
├────────────────────┤
│ 大量历史代码讨论 │
├────────────────────┤
│ 当前问题 │
└────────────────────┘此时：
一次请求可能携带：
50000+
Token4. 为什么上下文越长效果越差？
第一：注意力分散
AI 需要从大量信息中寻找重点。
信息越多，找到正确内容越困难。
第二：旧信息污染
例如：
之前：
不要修改数据库结构后来：
可以调整数据库两个规则同时存在。
AI 需要判断哪个有效。
第三：计算成本增加
上下文越长：
- 速度越慢；
- 成本越高；
- 注意力越分散。
总结：
AI 不是怕信息少，而是怕信息乱。
第三章：AI 到底是怎么工作的？
前面我们花了大量篇幅理解 Token 和上下文。
因为这是理解 AI 的基础。
如果不知道 AI 如何处理信息，那么后面的：
- Prompt
- Tool
- Agent
- MCP
- Skill
都会变成"背概念"。
很多人使用 AI 工具的时候，其实只停留在应用层。
比如：
打开 ChatGPT。
打开 Cursor。
输入一句话。
然后等待结果。
但是在真正理解 AI 之后，你会发现：
这些工具背后其实是一整套分层系统。
一、AI 系统的四层结构
一个完整的 AI 应用，大致可以拆分成：
Application 应用层
↓
Agent / Workflow 智能编排层
↓
Model Service 模型服务层
↓
Raw Model 基础模型层1. Raw Model：真正的大模型
Raw Model 是最底层。
例如：
- GPT
- Claude
- Gemini
- Kimi
- GLM
它负责：
- 理解 Token
- 计算概率
- 生成新的 Token
简单理解：
Raw Model 就像一个超级聪明的大脑。
但是它有一个问题：
它什么都不知道。
它不知道：
- 你的电脑在哪里；
- 你的项目是什么；
- 你的数据库结构；
- 你的业务规则。
它只能根据输入的信息生成答案。
2. Model Service：模型服务层
Raw Model 外面需要一个服务层。
作用类似：
把模型能力包装成可以被调用的服务。
例如：
你的应用
↓
API请求
↓
Model Service
↓
大模型这一层负责：
- 身份认证；
- 请求管理；
- Token 统计；
- 上下文处理；
- 模型选择。
比如：
你调用 AI：
请分析这段代码背后并不是直接连接模型。
而是：
应用发送请求。
服务层处理。
然后调用模型。
3. Application：应用层
我们平时使用的软件：
例如：
- ChatGPT
- Cursor
- Claude Code
都属于应用层。
应用层最大的价值：
不是提供模型。
而是：
给模型增加能力。
例如：
原始模型：
用户问题
↓
模型
↓
回答应用层：
用户问题
↓
Prompt增强
↓
上下文管理
↓
工具调用
↓
模型
↓
结果处理这就是为什么：
同一个模型。
不同产品体验完全不同。
二、一次 AI 请求到底发生了什么？
当用户输入一句：
帮我分析一下这个项目看起来非常简单。
但是背后发生了一系列过程。
完整流程：
用户
↓
Application
↓
组装上下文
↓
加入Prompt
↓
加入Tools
↓
Token化
↓
发送给Model
↓
模型推理
↓
生成Token
↓
返回结果
↓
展示给用户三、Prompt：告诉 AI 应该如何工作
很多人理解 Prompt：
就是一句话。
比如：
帮我写一个登录接口但是实际上：
真正有效的 Prompt 不只是问题。
它包含：
- 身份定义；
- 背景信息；
- 目标；
- 约束；
- 输出格式。
一个普通 Prompt
帮我优化代码问题：
AI 不知道：
- 优化什么？
- 目标是什么？
- 是否允许重构？
- 是否考虑性能？
工程级 Prompt
markdown
你是一名高级后端工程师。
请分析当前订单模块。
目标：
1. 提升查询性能
2. 保持接口兼容
3. 不修改数据库结构
执行前先输出分析方案。区别：
不是让 AI 更聪明。
而是：
让 AI 更明确。
四、Tool：让 AI 拥有手脚
如果说：
大模型是大脑。
那么 Tool 就是手脚。
没有 Tool：
AI 只能回答。
有 Tool：
AI 可以行动。
例如：
用户：
帮我分析项目结构普通模型：
请把项目代码复制给我。Agent：
可以：
arduino
调用 read 工具
↓
读取目录
↓
分析代码
↓
生成报告五、Coding Agent 的核心机制
Coding Agent 本质：
就是：
模型 + 工具 + 循环控制。
结构：
用户
↓
Agent
↓
Model
↓
Tool
↓
执行环境
↓
结果返回Model例如：
用户：
总结一下这个项目Agent 发送：
bash
系统提示：
你是开发Agent。
当前路径：
/project
可用工具：
- read
- write
- command模型判断：
需要查看文件。
返回：
json
{
"tool": "command",
"action": "ls"
}Agent 执行：
bash
ls得到：
css
src
package.json
README.md然后继续发送给模型。
这个过程不断循环。
直到模型认为：
任务完成。
六、Skill：解决上下文爆炸问题
随着 AI 使用深入，一个问题出现：
规则越来越多。
例如：
项目规范：
代码规范
数据库规范
Git规范
接口规范
组件规范
测试规范如果全部塞进 Prompt：
上下文会快速膨胀。
于是出现 Skill。
Skill 的核心思想：
不提前加载全部知识，而是在需要的时候加载。
以前：
启动AI
↓
加载全部规则
↓
消耗大量Token现在：
启动AI
↓
告诉AI有哪些技能
↓
需要时加载详细内容类似：
人类工作：
你不会每天背完整公司的所有制度。
需要的时候查文档。
七、MCP：AI 连接外部世界的标准方式
MCP（Model Context Protocol）解决的问题：
以前：
每个 AI 工具都需要单独开发连接方式。
例如：
连接：
- GitHub
- 数据库
- 飞书
- Jira
每个都要重新开发。
MCP 提供统一协议。
简单理解：
MCP 就是一套 Tool 标准。
结构：
arduino
AI Agent
↓
MCP Client
↓
MCP Server
↓
外部系统例如：
用户：
查询昨天Git提交最多的人AI：
调用 Git MCP。
MCP：
访问 Git 服务。
返回：
makefile
张三:
45 commits
李四:
32 commitsAI 再生成自然语言。
八、如何正确使用 AI？
理解所有原理之后，会发现：
工具其实一直在变化。
但是方法不会变化。
核心永远是：
1. 给 AI 明确目标
不要：
帮我写代码应该：
实现什么功能，解决什么问题，有什么限制。2. 控制上下文质量
不要：
一个会话聊几个月。
应该：
一个任务一个会话。
3. 让 AI 分阶段工作
不要：
直接开发整个系统应该：
分析需求
↓
设计方案
↓
实现
↓
测试
↓
优化九、未来 AI 使用者的核心能力
未来不会是谁：
打字最快。
而是谁：
更懂如何调度 AI。
真正高级的 AI 使用：
不是：
"让 AI 替我写代码"。
而是：
"设计一个系统，让 AI 稳定完成复杂任务"。
第四章：Coding Agent 的真正原理 ------ 为什么 AI 能像程序员一样工作？
前面我们讲了：
- Token 如何进入模型
- 上下文为什么会影响 AI
- Raw Model、Model Service、Application 的分层
但是还有一个关键问题：
为什么现在的 AI 工具，比如：
- Claude Code
- Codex
- Cursor Agent
- OpenCode
可以直接操作代码？
它们到底是怎么做到：
- 阅读项目；
- 修改文件；
- 执行命令；
- 自动修复 Bug；
这些事情的？
答案：Agent
一、什么是 Agent？
很多人把 Agent 理解成：
"更强的聊天机器人"。
其实不准确。
聊天机器人：
用户
↓
模型
↓
回答Agent：
用户
↓
Agent
↓
模型
↓
工具
↓
真实环境
↓
反馈
↓
继续推理最大的区别：
聊天机器人只能回答。
Agent 可以行动。
二、Agent 的核心思想：让模型拥有行动能力
大模型本身：
非常聪明。
但是它没有：
- 文件访问能力；
- 网络访问能力；
- 数据库访问能力；
- 命令执行能力。
它只能生成文字。
例如：
用户：
分析一下当前项目结构普通模型：
请把代码发给我，我才能分析。因为它不知道你的项目。
但是 Agent：
读取目录
↓
查看文件
↓
分析代码
↓
输出报告这就是区别。
三、Agent 的核心组成
一个 Coding Agent 通常包含：
Agent
├── Prompt
├── Context管理
├── Tools
├── Memory
├── Planning
└── Model调用1. Prompt
告诉模型：
你是谁。
你可以做什么。
你应该遵守什么规则。
例如：
bash
你是一名软件开发Agent。
当前项目路径：
/workspace/project
你可以使用：
read
write
command
请先分析，再执行修改。2. Tools
工具是 Agent 能行动的关键。
常见：
arduino
command
read
write
delete对应：
command：
执行命令。
例如：
bash
npm test
git status
lsread：
读取文件。
例如：
bash
src/user/UserService.javawrite：
修改或者创建文件。
delete：
删除文件。
四、Tool Calling：模型如何调用工具？
这里是 Agent 最核心的地方。
很多人以为：
模型直接执行代码。
不是。
实际上：
模型只负责：
产生一个工具调用请求。
例如：
用户：
分析项目结构模型判断：
我需要查看目录。
于是生成：
json
{
"tool": "command",
"arguments": {
"command": "ls"
}
}注意：
模型没有执行。
它只是说：
"我需要调用这个工具。"
然后：
Agent 收到这个 JSON。
执行：
shell
ls得到：
css
src
package.json
README.md然后：
Agent 再把结果发送回模型。
模型继续判断：
下一步需要：
读取 package.json。
于是：
再次调用工具。
这个过程：
不断循环。
五、Agent Loop：智能体为什么可以完成复杂任务？
Agent 的核心循环：
叫：
Agent Loop。
通常：
观察 Observe
↓
思考 Think
↓
行动 Act
↓
反馈 Feedback
↓
继续循环例如：
任务：
帮我增加用户登录功能Agent：
第一步：观察
查看项目结构。
调用：
bash
command ls第二步：理解
读取：
UserController
UserService
Database第三步：规划
决定：
需要增加：
- 登录接口
- JWT 生成
- 用户验证
第四步：行动
修改代码。
第五步：验证
执行：
bash
npm test发现错误。
第六步：修复
继续修改。
直到：
任务完成。
这也是为什么现在的 Coding Agent 很震撼。
因为它不是：
一次性生成代码。
而是在：
不断观察环境，然后调整行为。
第五章：Sub Agent ------ 一个 AI 变成一个团队
未来复杂任务：
一个 Agent 不够。
于是出现：
Sub Agent。
一个主 Agent：
负责：
任务管理。
下面：
多个子 Agent。
例如：
css
Main Agent
├── Planner Agent
│
├── Coding Agent
│
├── Test Agent
│
└── Review AgentPlanner Agent
负责：
分析需求。
拆解任务。
Coding Agent
负责：
写代码。
Test Agent
负责：
测试。
Review Agent
负责：
代码审查。
这就像：
一个软件团队。
区别：
以前：
一个项目需要：
5 个人。
未来：
可能：
1 个人管理 5 个 AI Agent。
第六章：Vibe Coding 到 Spec Coding
AI 编程刚开始：
很多人喜欢：
Vibe Coding。
中文：
氛围编程。
简单理解：
想到什么说什么。
让 AI 帮你生成。
例如：
帮我做一个电商网站AI：
直接开始写。
非常爽。
但是问题也明显：
- 代码质量不稳定；
- 架构不可控；
- 维护困难；
- AI 容易跑偏。
所以未来企业一定会走：
Spec Coding。
也就是：
规范驱动开发。
流程：
需求
↓
Spec设计
↓
AI实现
↓
自动测试
↓
ReviewAI 负责执行。
人负责定义规则。
总结：
AI 最大的价值：
不是帮你生成代码。
而是：
让一个开发者拥有一个开发团队。
但是前提：
你需要理解：
- Token；
- Context；
- Prompt；
- Tool；
- Agent；
- MCP；
- Skill。
因为：
不理解原理的人：
只能使用 AI。
理解原理的人：
才能驾驭 AI。
未来开发者最大的竞争力：
不是：
"我写代码有多快。"
而是：
"我能不能设计一个系统，让 AI 稳定完成复杂的软件工程。"
第七章：如何真正使用 AI 工具提升开发效率？
前面我们花了大量篇幅讲：
- Token
- Context
- Model
- Prompt
- Tool
- Agent
- MCP
- Skill
- Sub Agent
这些内容看起来比较底层。
很多人可能会想：
"知道这些有什么用？"
其实非常有用。
因为理解底层原理之后，你会发现：
AI 工具使用能力，本质不是会不会输入一句 Prompt。
而是：
你有没有能力设计一套人和 AI 协作的工作流。
一. 为什么很多人用了 AI，效率反而下降？
这是一个很有意思的问题。
很多开发者第一次接触 AI：
非常兴奋。
感觉：
"以后代码是不是不用写了？"
但是使用一段时间后发现：
效率并没有明显提升。
甚至：
花更多时间修改 AI 生成的垃圾代码。
为什么？
因为很多人只是把 AI 当搜索引擎。
1. 把 AI 当成代码生成器
例如：
用户：
帮我写一个订单系统AI：
生成几百行代码。
然后：
开发者开始修改。
最后发现：
还不如自己写。
问题在哪里？
不是 AI 不行。
而是任务描述方式错了。
复杂的软件开发，本来就不是：
一句话生成。
而是：
需求分析。
架构设计。
模块拆分。
编码。
测试。
优化。
AI 也一样。
2. 没有给 AI 足够上下文
另一个常见问题：
用户：
帮我优化这个方法然后发送：
java
public void test(){
}AI：
只能猜。
它不知道：
- 业务目的；
- 数据结构；
- 性能要求；
- 代码规范。
所以：
输出自然不稳定。
3. 一个会话塞太多内容
很多人喜欢：
一个聊天窗口用几个月。
里面包含：
- 需求讨论；
- Bug 修复；
- 架构设计；
- 临时代码。
最后：
上下文越来越混乱。
正确方式：
一个任务。
一个会话。
二、正确使用 AI 的核心原则
原则一：先让 AI 思考，再让 AI 执行
很多人：
直接：
帮我修改代码更好的方式：
第一步：
先分析当前代码的问题。
不要修改。
输出方案。第二步：
确认方案。
第三步：
按照方案执行修改。这样稳定性会提高很多。
原则二：让 AI 分阶段完成任务
不要：
帮我开发一个完整电商系统应该：
拆分：
第一阶段：
设计数据库模型。
第二阶段：
实现用户模块。
第三阶段：
实现订单模块。
第四阶段：
增加支付。
第五阶段：
测试优化。AI 最擅长：
明确的小任务。
原则三：给 AI 设定边界
AI 最大的问题：
不是不会。
而是不知道限制。
例如：
错误：
优化这个系统。正确：
markdown
优化查询性能。
限制：
1. 不修改数据库结构。
2. 不改变接口。
3. 保持代码兼容。
4. 输出修改计划后再执行。约束越清晰：
结果越稳定。
三、AI 编程推荐工作流
一个比较成熟的 AI 开发流程：
需求
↓
分析
↓
设计
↓
执行
↓
验证
↓
优化第一步：需求分析
不要直接写代码。
先让 AI 理解：
例如：
markdown
分析这个需求：
增加会员系统。
请输出：
1. 涉及模块。
2. 数据变化。
3. 潜在风险。
4. 推荐实现方案。第二步：生成技术方案
让 AI 充当架构师。
例如：
根据当前项目结构。
设计会员系统实现方案。
不要修改代码。
只输出方案。得到：
- 数据库设计；
- 接口设计；
- 模块调整。
第三步：执行开发
确认方案后：
让 AI 修改。
例如：
markdown
按照确认方案执行。
要求：
1. 保持现有代码风格。
2. 不修改无关文件。
3. 每次修改说明原因。第四步：验证
不要相信 AI。
一定要验证。
例如：
让 AI：
markdown
运行测试。
检查：
1. 编译错误。
2. 单元测试。
3. 潜在问题。第五步：Review
最后：
让 AI 自我检查。
例如：
现在作为代码审查人员。
检查刚才修改。
重点关注：
性能、安全、可维护性。四、企业级 AI 工作流是什么样？
未来企业真正使用 AI：
不会只是：
员工聊天。
而是：
AI 连接企业系统。
例如：
老板问：
分析一下最近项目延期风险。传统方式：
人工：
查看 Jira。
查看 Git。
查看会议记录。
几个小时。
AI 工作流：
用户
↓
AI Agent
↓
Jira MCP
↓
Git MCP
↓
数据库 MCP
↓
分析模型
↓
生成报告输出：
markdown
项目A：
延期风险高。
原因：
1. 后端接口延期5天。
2. Bug数量增加30%。
3. 测试资源不足。
建议：
增加测试人员。
调整发布时间。这才是 AI 真正改变企业效率的地方。
五、未来的软件开发模式
未来开发流程可能变成：
产品经理
↓
需求Spec
↓
AI Planner
↓
AI Developer
↓
AI Tester
↓
AI Reviewer
↓
人类最终确认人负责：
- 目标；
- 规则；
- 判断。
AI 负责：
- 执行；
- 分析；
- 重复劳动。
六、AI 时代开发者能力模型
以前：
优秀程序员：
代码能力强
↓
写代码快
↓
熟悉框架未来：
优秀开发者：
diff
理解业务
+
系统设计能力
+
AI调度能力
+
工程管理能力代码能力依然重要。
但是：
代码只是表达方式。
真正重要的是：
解决问题的能力。
最终总结：AI 时代，最大的竞争力是什么？
AI 不会简单替代程序员。
但是：
会使用 AI 的程序员，
一定会逐渐替代不会使用 AI 的程序员。
未来：
一个优秀开发者可能不再是：
"每天写最多代码的人。"
而是：
"能够设计一个系统，让多个 AI Agent 高效协作的人。"
真正掌握 AI：
不是学会几个工具。
不是记住几个 Prompt。
而是理解：
AI 为什么这样工作。
当你理解：
Token。
Context。
Model。
Agent。
Tool。
MCP。
你就不再是在使用 AI。
你是在构建属于自己的 AI 工作流。
这才是 AI 时代开发者真正应该掌握的能力，这个时代一定是属于有想法的技术人。