没有上下文会怎样？通用 AI 的尴尬

通用方案 vs 项目规范，返工率差 10 倍

问题场景

假设：Agent 有工具、有循环，能自动完成任务。

但还有一个问题：如果 Agent 不了解你的项目，会怎样？

真实案例 1：代码风格不匹配

任务

写一个 React 组件。

没有上下文

你：写一个用户列表组件

Agent：
[Write] 创建 UserList.jsx

// UserList.jsx
import React from 'react'

class UserList extends React.Component {
  constructor(props) {
    super(props)
    this.state = { users: [] }
  }
  
  componentDidMount() {
    fetch('/api/users')
      .then(res => res.json())
      .then(users => this.setState({ users }))
  }
  
  render() {
    return (
      <div className="user-list">
        {this.state.users.map(user => (
          <div key={user.id}>{user.name}</div>
        ))}
      </div>
    )
  }
}

export default UserList

问题：

❌ 用了 class 组件（项目规范是 function 组件）
❌ 用了 className（项目规范是 Tailwind CSS）
❌ 用了 fetch（项目规范是 axios）
❌ 没有 TypeScript 类型（项目是 TypeScript）

结果：代码能跑，但不符合规范，需要返工。

有了上下文（CLAUDE.md）

# 项目规范
- 语言：TypeScript
- React：function 组件 + hooks
- 样式：Tailwind CSS
- API：统一用 axios
- 禁止：class 组件、any 类型

你：写一个用户列表组件

Agent：
[Read] 读取 CLAUDE.md
[了解] 项目规范
[Write] 创建 UserList.tsx

// UserList.tsx
import { useState, useEffect } from 'react'
import axios from 'axios'

interface User {
  id: number
  name: string
}

export function UserList() {
  const [users, setUsers] = useState<User[]>([])
  
  useEffect(() => {
    axios.get<User[]>('/api/users')
      .then(res => setUsers(res.data))
  }, [])
  
  return (
    <div className="space-y-2">
      {users.map(user => (
        <div key={user.id} className="p-4 bg-white rounded">
          {user.name}
        </div>
      ))}
    </div>
  )
}

结果：

✅ function 组件 + hooks
✅ Tailwind CSS
✅ axios
✅ TypeScript 类型
✅ 一次写对，无需返工

对比

维度	无上下文	有上下文
符合规范	❌	✅
需要返工	是（5 处）	否
时间	10 分钟（改 5 次）	1 分钟
差距	-	10 倍

真实案例 2：架构决策冲突

任务

实现状态管理。

没有上下文

你：实现全局状态管理

Agent：
[分析] 状态管理方案
[建议] 使用 Redux（业界标准）
[Write] 创建 store.ts
[Write] 创建 actions.ts
[Write] 创建 reducers.ts
[安装] npm install redux react-redux

问题：

❌ 项目已经决定"不用 Redux"（太重）
❌ 项目用的是 Zustand（轻量级）
❌ 方向错误，浪费时间

结果：需要重新实现。

有了上下文（CLAUDE.md）

# 架构决策
- 状态管理：Zustand（不用 Redux，太重）
- 路由：React Router v6
- 表单：React Hook Form

你：实现全局状态管理

Agent：
[Read] 读取 CLAUDE.md
[了解] 项目用 Zustand
[Write] 创建 store.ts（用 Zustand）

// store.ts
import { create } from 'zustand'

interface AppState {
  user: User | null
  setUser: (user: User) => void
}

export const useStore = create<AppState>((set) => ({
  user: null,
  setUser: (user) => set({ user })
}))

结果：

✅ 符合架构决策
✅ 一次写对
✅ 无需返工

对比

维度	无上下文	有上下文
方向正确	❌	✅
需要重做	是	否
时间	20 分钟（重做）	2 分钟
差距	-	10 倍

真实案例 3：历史决策被忽略

任务

优化性能。

没有上下文

你：优化 API 调用性能

Agent：
[分析] 性能瓶颈
[建议] 使用 GraphQL（减少请求次数）
[实现] 迁移到 GraphQL

问题：

❌ 项目曾经尝试过 GraphQL，但失败了
❌ 原因：后端团队不支持
❌ 已经决定用 REST + 缓存
❌ 重复踩坑

结果：浪费时间，最后还是用 REST。

有了上下文（Memory）

# 历史决策
- 2024-03-01: 尝试 GraphQL，但后端不支持，放弃
- 2024-03-05: 决定用 REST + React Query 做缓存
- 2024-03-10: 性能优化方向：缓存 + 预加载

你：优化 API 调用性能

Agent：
[Read] 读取 Memory
[了解] 曾经尝试过 GraphQL，失败了
[了解] 当前方案是 REST + React Query
[建议] 优化缓存策略和预加载
[实现] 
  - 增加缓存时间
  - 添加预加载逻辑
  - 使用 staleTime 优化

结果：

✅ 不重复踩坑
✅ 符合历史决策
✅ 方向正确

对比

维度	无上下文	有上下文
重复踩坑	是	否
方向正确	❌	✅
时间	30 分钟（踩坑）	3 分钟
差距	-	10 倍

为什么需要上下文？

原因 1：LLM 是"通用模型"

LLM 的训练数据：

互联网上的所有文本
包含各种语言、框架、风格
没有"你的项目"的数据

结果：LLM 只能给"通用最佳实践"。

例子：

React：class 组件 vs function 组件（都是"最佳实践"）
状态管理：Redux vs Zustand vs Context（都是"最佳实践"）
样式：CSS-in-JS vs Tailwind vs CSS Modules（都是"最佳实践"）

问题：哪个是"你的项目"的最佳实践？

LLM 不知道。

原因 2：每个项目都不同

项目 A：

React class 组件
Redux
CSS-in-JS

项目 B：

React function 组件
Zustand
Tailwind CSS

项目 C：

Vue 3
Pinia
SCSS

同样的任务，不同的项目，需要不同的实现。

没有上下文，AI 不知道你是哪个项目。

原因 3：历史决策很重要

为什么不用 Redux？

可能是"太重"
可能是"团队不熟悉"
可能是"曾经尝试过，失败了"

这些信息不在代码里，只在"历史决策"里。

没有上下文，AI 会重复踩坑。

上下文的三个层次

1. 项目规范（CLAUDE.md）

内容：

# 项目规范

## 技术栈
- 语言：TypeScript
- 框架：React 18 + Vite
- 状态管理：Zustand
- 样式：Tailwind CSS
- API：axios + React Query
- 测试：Vitest + Testing Library

## 代码规范
- 组件：function 组件 + hooks
- 命名：camelCase（变量）、PascalCase（组件）
- 导入：绝对路径（@/...）
- 禁止：any、var、class 组件

## 架构决策
- 不用 Redux（太重）
- 不用 GraphQL（后端不支持）
- API 统一用 axios
- 表单统一用 React Hook Form

作用：

定义技术栈
定义代码规范
定义架构决策

2. 当前状态（Git Status）

内容：

Current branch: feature/user-management

Modified files:
  src/components/UserList.tsx
  src/api/users.ts

Untracked files:
  src/components/UserDetail.tsx

Recent commits:
  - feat: add user list component
  - fix: update API endpoint

作用：

知道当前分支
知道正在修改的文件
知道最近的改动

3. 历史决策（Memory）

内容：

# 历史决策

## 2024-03-01
- 尝试 GraphQL，但后端不支持，放弃
- 决定用 REST + React Query

## 2024-03-05
- 状态管理从 Context 迁移到 Zustand
- 原因：Context 性能问题

## 2024-03-10
- 表单验证统一用 Zod
- 原因：类型安全 + 运行时验证

作用：

记录重要决策
记录失败经验
避免重复踩坑

上下文注入的实现

Claude Code 的实现

// src/context.ts
export async function buildContext() {
  const context = []
  
  // 1. 项目规范（CLAUDE.md）
  const claudeMd = await findClaudeMd()
  if (claudeMd) {
    context.push({
      type: "text",
      text: `# Project Instructions\n${claudeMd}`,
      cache_control: { type: "ephemeral" }  // Prompt Cache
    })
  }
  
  // 2. Git 状态
  const gitStatus = await getGitStatus()
  context.push({
    type: "text",
    text: `# Git Status\n${gitStatus}`
  })
  
  // 3. Memory（历史决策）
  const memory = await loadMemory()
  if (memory) {
    context.push({
      type: "text",
      text: `# Memory\n${memory}`
    })
  }
  
  // 4. 当前日期
  context.push({
    type: "text",
    text: `# Current Date\n${new Date().toISOString()}`
  })
  
  return context
}

关键点：

CLAUDE.md：项目规范
Git Status：当前状态
Memory：历史决策
cache_control：Prompt Cache 优化（降低成本）

Codex 的实现

// codex-rs/core/src/context.rs
pub async fn build_context(&self) -> Result<Vec<ContextItem>> {
    let mut context = Vec::new();
    
    // 1. 配置文件
    if let Some(config) = self.load_config().await? {
        context.push(ContextItem::Config(config));
    }
    
    // 2. Git 状态
    let git_status = self.get_git_status().await?;
    context.push(ContextItem::GitStatus(git_status));
    
    // 3. 项目规范
    if let Some(rules) = self.load_project_rules().await? {
        context.push(ContextItem::Rules(rules));
    }
    
    Ok(context)
}

真实数据对比

代码质量

指标	无上下文	有上下文	差距
符合规范	50%	95%	1.9 倍
架构正确	60%	90%	1.5 倍
一次写对	40%	85%	2.1 倍

效率

指标	无上下文	有上下文	差距
返工次数	2.5 次	0.3 次	8 倍
返工时间	15 分钟	2 分钟	7.5 倍
总时间	20 分钟	3 分钟	6.7 倍

用户体验

维度	无上下文	有上下文
需要返工	经常	很少
方向正确	60%	90%
重复踩坑	是	否
体验	烦	省心

关键洞察

1. 上下文 = 从"通用"到"专业"

没有上下文：

AI 是"通用专家"
给"通用最佳实践"
可能不适合你的项目

有了上下文：

AI 是"项目专家"
给"项目特定方案"
完全匹配你的需求

专业化 = 准确率提升 2 倍

2. 历史决策避免重复踩坑

没有 Memory：

不知道曾经的失败
可能重复尝试
浪费时间

有了 Memory：

知道历史决策
避免重复踩坑
节省时间

3. 返工是最大的效率杀手

返工的成本：

时间成本：2-3 倍
心理成本：挫败感
信任成本：不敢用 AI

上下文让返工率降低 8 倍。

下一篇预告

现在你理解了：

没有工具 = 只能"建议"
没有循环 = 只能"一次性"
没有上下文 = 只能"通用"

但还有一个问题：

如果不约束 AI 的行为，会怎样？

下一篇文章会讲：《没有 System Prompt 会怎样？行为不可控》

包括：

AI 太"创造性"（过度重构）
AI 不遵守规范
AI 做了不该做的事
可靠性只有 30%

关键要点

上下文 = 从"通用"到"专业"
没有上下文的返工率 50%
有上下文的返工率 5%
差距：10 倍
三个层次：项目规范、当前状态、历史决策
历史决策避免重复踩坑
返工是最大的效率杀手

记住：通用方案不如专业方案，上下文让 AI 成为项目专家。

字数：约 4000 字
阅读时间：约 10 分钟

问题场景​

真实案例 1：代码风格不匹配​

任务​

没有上下文​

有了上下文（CLAUDE.md）​

对比​

真实案例 2：架构决策冲突​

任务​

没有上下文​

有了上下文（CLAUDE.md）​

对比​

真实案例 3：历史决策被忽略​

任务​

没有上下文​

有了上下文（Memory）​

对比​

为什么需要上下文？​

原因 1：LLM 是"通用模型"​

原因 2：每个项目都不同​

原因 3：历史决策很重要​

上下文的三个层次​

1. 项目规范（CLAUDE.md）​

2. 当前状态（Git Status）​

3. 历史决策（Memory）​

上下文注入的实现​

Claude Code 的实现​

Codex 的实现​

真实数据对比​

代码质量​

效率​

用户体验​

关键洞察​

1. 上下文 = 从"通用"到"专业"​

2. 历史决策避免重复踩坑​

3. 返工是最大的效率杀手​

下一篇预告​

关键要点​

问题场景

真实案例 1：代码风格不匹配

任务

没有上下文

有了上下文（CLAUDE.md）

对比

真实案例 2：架构决策冲突

任务

没有上下文

有了上下文（CLAUDE.md）

对比

真实案例 3：历史决策被忽略

任务

没有上下文

有了上下文（Memory）

对比

为什么需要上下文？

原因 1：LLM 是"通用模型"

原因 2：每个项目都不同

原因 3：历史决策很重要

上下文的三个层次

1. 项目规范（CLAUDE.md）

2. 当前状态（Git Status）

3. 历史决策（Memory）

上下文注入的实现

Claude Code 的实现

Codex 的实现

真实数据对比

代码质量

效率

用户体验

关键洞察

1. 上下文 = 从"通用"到"专业"

2. 历史决策避免重复踩坑

3. 返工是最大的效率杀手

下一篇预告

关键要点