English

四哥还会聊AI

80后突围：当程序员不再是第一个梦想，AI成了第四个梦想

第5篇-大模型的致命缺点健忘，考验架构功底

by 四哥

大模型的致命缺陷：健忘症考验架构功底

🧠 AI最大的谎言：我什么都记得

大语言模型最可怕的不是智商问题，而是记忆力问题。它们就像得了"数字健忘症"的天才，上一秒还侃侃而谈，下一秒就忘记自己说过什么。

在希语低喃心绪笔记开发中，我发现上下文污染和记忆衰减是AI编程中最隐蔽的陷阱。今天我就告诉你如何通过架构设计来对抗AI的健忘症。

🎯 问题1：Token限制下的记忆断层

AI的记忆原理：残酷的物理限制

大模型的记忆机制：

  • 短期记忆：当前的对话上下文，通常只有几千到几万个token
  • 长期记忆：训练数据中的知识，但无法记住具体对话内容
  • 记忆衰减：随着对话长度增加，早期内容逐渐被"遗忘"

现实有多残酷？

假设一个2000行代码文件：
- 每行平均50个字符 = 100,000字符
- 中文1字符≈1.5token，代码1字符≈0.7token
- 总token数：约80,000-120,000个token
- GPT-4上下文窗口：128,000个token
- 结论：一个2000行文件几乎占满全部上下文！

健忘症的具体表现

1. 渐进性遗忘

// 文件开头定义的全局配置
const API_CONFIG = {
  baseUrl: "https://api.example.com",
  timeout: 5000,
  retries: 3
}

// 500行后，AI可能忘记这个配置的存在
async function callAPI(endpoint: string) {
  // AI可能会重新定义相似的配置，而不是使用已定义的
  const config = {
    url: "https://api.example.com" + endpoint, // 重复定义！
    timeout: 3000 // 不一致的配置！
  }
}

2. 上下文污染

// 文件前面的错误示例
function BadExample() {
  const user = { name: "John", age: 25 }
  return user.name
}

// 1000行后，AI可能被这个错误示例影响
function createUser() {
  // AI可能模仿错误的结构，而不是最佳实践
  const newUser = { name: "Alice", age: 30 }
  // 忘记了类型定义、验证、错误处理等
  return newUser
}

3. 约束条件丢失

// 项目开头的约束条件
/*
项目原则：
- 所有函数都要有错误处理
- 使用TypeScript严格模式
- 单函数不超过50行
- 禁止使用any类型
*/

// 800行后，AI生成的代码可能违反这些约束
function processUserData(data: any) { // 违反：禁止any
  // 没有错误处理 - 违反错误处理原则
  // 函数过长 - 违反50行限制
  // 数据处理逻辑复杂，但没有类型安全
}

🏗️ 解决方案1：文件大小控制的架构艺术

为什么是1000行？科学依据

认知负荷理论：

  • 7±2法则：人类工作记忆能处理7±2个信息块
  • 认知chunk：代码中的函数、类、模块都是信息块
  • 上下文切换成本：文件越大，找到相关信息的成本越高

AI上下文效率：

  • 注意力机制：AI需要"关注"所有相关内容
  • 信息密度：1000行文件的信息密度刚好适合AI处理
  • 检索效率：AI能在合理范围内找到相关信息

1000行文件的设计原则

1. 单一职责文件

// ✅ 用户相关逻辑 - users.service.ts
import { userRepository } from '@/repositories'
import { logger } from '@/utils'
import type { User, CreateUserInput } from '@/types'

export class UserService {
  async create(userData: CreateUserInput): Promise<User> {
    try {
      const user = await userRepository.create(userData)
      logger.info(`User created: ${user.id}`)
      return user
    } catch (error) {
      logger.exception('Failed to create user', error)
      throw error
    }
  }

  async findById(id: string): Promise<User> {
    const user = await userRepository.findById(id)
    if (!user) {
      throw new Error(`User not found: ${id}`)
    }
    return user
  }

  // 总计：约150行
}

// ❌ 避免：多功能混合文件
// user-manager.service.ts - 2000行
// - 用户管理 (500行)
// - 权限控制 (400行)
// - 会话管理 (600行)
// - 数据统计 (500行)

2. 模块化分层设计

// ✅ 分层架构，每层文件大小可控
backend/src/
├── routes/          # 每个文件100-200行
│   ├── users.routes.ts
│   ├── sessions.routes.ts
│   └── messages.routes.ts
├── services/        # 每个文件200-400行
│   ├── users.service.ts
│   ├── sessions.service.ts
│   └── llm.service.ts
├── repositories/    # 每个文件100-300行
│   ├── users.repository.ts
│   └── sessions.repository.ts
└── types/          # 每个文件50-150行
    ├── users.types.ts
    └── sessions.types.ts

3. 接口定义分离

// ✅ types/user.types.ts - 专门的类型定义文件
export interface User {
  id: string
  name: string
  email: string
  createdAt: Date
  updatedAt: Date
}

export interface CreateUserInput {
  name: string
  email: string
}

export interface UserQuery {
  page?: number
  limit?: number
  search?: string
}

// 这样services文件夹中的文件就不会被类型定义占据过多空间

🧩 解决方案2：上下文污染的防护策略

污染源的识别与隔离

1. 错误示例的隔离

// ❌ 错误做法：在正常代码中混入错误示例
export class UserService {
  // 不要在这里写错误的示例代码！
  // badExample() { ... } // 污染AI的学习

  async createUser(userData: CreateUserInput): Promise<User> {
    // 正确的实现
  }
}

// ✅ 正确做法：独立的示例文件
docs/examples/common-mistakes.ts
export const badExamples = {
  // 错误示例集中在这里
  badUserCreation: `function createUser(data: any) { ... }`
}

2. 注释和文档的优化

// ❌ 过度详细的注释反而造成污染
/*
这个函数用于创建用户，它的原理是...
历史背景：最初的设计是为了解决...
在版本1.2中我们修复了某个bug...
未来的扩展计划包括...
可能的替代方案...
性能考虑...
安全考虑...
*/
async function createUser(data: CreateUserInput): Promise<User> {
  // 实际代码
}

// ✅ 简洁有效的注释
// 创建新用户，输入验证在service层完成
async function createUser(data: CreateUserInput): Promise<User> {
  // 实现
}

3. 版本历史的清理

// ❌ 保留废弃代码造成污染
// async function createUserV1(data: any): Promise<any> { ... } // 废弃
// async function createUserV2(data: UserInput): Promise<UserData> { ... } // 废弃

// ✅ 立即删除废弃代码
async function createUser(data: CreateUserInput): Promise<User> {
  // 当前版本
}

上下文优化技巧

1. 代码密度优化

// ❌ 低密度代码，占用过多上下文
export class UserService {
  // 大量空行
  // 过度详细的注释


  async createUser(userData: CreateUserInput): Promise<User> {
    // 冗长的变量名
    const theUserThatWeWantToCreateInDatabase = userData

    // 过度拆分的简单逻辑
    const isValid = this.validateUserData(theUserThatWeWantToCreateInDatabase)
    if (isValid) {
      const createdUser = await userRepository.create(theUserThatWeWantToCreateInDatabase)
      return createdUser
    }
    return null
  }
}

// ✅ 高密度代码，节省上下文
export class UserService {
  async createUser(userData: CreateUserInput): Promise<User> {
    this.validate(userData)
    return await userRepository.create(userData)
  }

  private validate(userData: CreateUserInput): void {
    if (!userData.email) throw new Error('Email required')
  }
}

2. 导入优化

// ❌ 过度导入造成上下文污染
import {
  UserService,
  MessageService,
  AuthService,
  UserServiceV1, // 废弃但未删除
  UserTypes,
  MessageTypes,
  HelperFunctions1,
  HelperFunctions2,
  // 20个其他导入...
} from '@/services'

// ✅ 精确导入
import { UserService } from '@/services/users.service'
import { type CreateUserInput } from '@/types/user.types'

🔧 解决方案3：健忘症的工程化对抗

项目级记忆增强

1. 结构化的Claude.md文档

# 希语低喃心绪笔记 - AI编程项目规范

## 核心架构原则（必须遵循）
1. **文件大小限制**：单个文件不超过1000行
2. **类型安全**：严格使用TypeScript，禁止any
3. **错误处理**：使用logger.exception，Let it Crash原则
4. **依赖注入**：使用Repository模式

## 技术栈约束
- 前端：Taro + React + TypeScript
- 后端：Fastify + TypeScript + Prisma
- 数据库：PostgreSQL
- AI服务：OpenAI API

## 代码模板（参考使用）
```typescript
// Service模板
export class ExampleService {
  async create(data: CreateData): Promise<Example> {
    try {
      const result = await exampleRepository.create(data)
      logger.info(`Example created: ${result.id}`)
      return result
    } catch (error) {
      logger.exception('Failed to create example', error)
      throw error
    }
  }
}

禁止模式（严格避免）

  • 不要使用try-catch掩盖错误
  • 不要在正常代码中保留废弃代码
  • 不要使用any类型
  • 不要创建超过1000行的文件

**2. 自动化检查工具**
```typescript
// scripts/file-size-check.js
const fs = require('fs')
const path = require('path')

function checkFileSize(filePath) {
  const content = fs.readFileSync(filePath, 'utf8')
  const lines = content.split('\n').length

  if (lines > 1000) {
    console.error(`❌ ${filePath}: ${lines} lines (exceeds 1000)`)
    return false
  }

  console.log(`✅ ${filePath}: ${lines} lines`)
  return true
}

// 检查所有TypeScript文件
const srcDir = './src'
const files = getAllTSFiles(srcDir)
let allValid = true

files.forEach(file => {
  if (!checkFileSize(file)) {
    allValid = false
  }
})

process.exit(allValid ? 0 : 1)

3. 分层开发策略

// 第一层：接口定义（始终保持可见）
types/
├── user.types.ts      # 100行
├── session.types.ts   # 80行
└── message.types.ts   # 60行

// 第二层：数据访问（稳定变化少）
repositories/
├── user.repository.ts     # 200行
├── session.repository.ts  # 180行
└── message.repository.ts  # 150行

// 第三层：业务逻辑（变化最多，但保持模块化）
services/
├── users.service.ts      # 400行
├── sessions.service.ts   # 350行
└── llm.service.ts        # 500行

// 每个文件都在AI的最佳记忆范围内

开发流程的健忘症防护

1. 频繁的上下文重置

// 在每个新功能开始前，重新加载关键上下文
/*
# 新功能开发：用户反馈系统

相关文件：
- types/feedback.types.ts (定义数据结构)
- repositories/feedback.repository.ts (数据访问)
- services/feedback.service.ts (业务逻辑)
- routes/feedback.routes.ts (API接口)

约束条件：
- 单文件不超过1000行
- 严格的TypeScript类型检查
- 完整的错误处理
- 遵循Repository模式

当前任务：实现反馈数据的CRUD操作
*/

2. 模块化的开发节奏

// 开发节奏：每个模块独立开发和测试
// 第一阶段：用户模块（500行代码）
// 第二阶段：会话模块（400行代码）
// 第三阶段：消息模块（600行代码）
// 第四阶段：AI分析模块（800行代码）

// 而不是：一个大文件包含所有功能（3000行代码）

3. 持续的代码重构

// 定期检查文件大小，及时拆分
if (file.lines > 800) {
  // 开始考虑拆分
  const newFile = extractRelatedFunctions(file)
  refactorImports(file, newFile)
  updateTests(file, newFile)
}

🎯 实战案例：希语低喃心绪笔记的健忘症防护

案例1：消息系统的重构

原始问题：

// messages.service.ts - 1800行，包含太多功能
export class MessageService {
  // 消息CRUD (400行)
  // 消息搜索 (300行)
  // 消息统计 (200行)
  // 消息分析 (400行)
  // 消息导出 (200行)
  // AI消息处理 (300行)
}

重构方案：

// messages.service.ts - 400行
export class MessageService {
  // 核心CRUD操作
}

// message-search.service.ts - 300行
export class MessageSearchService {
  // 搜索相关逻辑
}

// message-analytics.service.ts - 400行
export class MessageAnalyticsService {
  // 统计分析逻辑
}

// message-export.service.ts - 200行
export class MessageExportService {
  // 导出功能
}

案例2：AI集成的模块化

AI服务面临的健忘症挑战：

  • LLM提示词管理
  • 对话历史维护
  • 多轮对话状态
  • 错误处理和重试

解决方案：

// llm/
├── prompt-manager.ts      # 200行 - 提示词管理
├── conversation-manager.ts # 300行 - 对话状态
├── response-parser.ts     # 150行 - 响应解析
└── error-handler.ts       # 100行 - 错误处理

// llm.service.ts - 400行，组合使用上述模块
export class LLMService {
  constructor(
    private promptManager: PromptManager,
    private conversationManager: ConversationManager,
    private responseParser: ResponseParser,
    private errorHandler: ErrorHandler
  ) {}
}

案例3：上下文污染的清理

问题识别：

// 问题文件中发现污染
// 1. 废弃的函数未删除
// 2. 错误的示例代码混入
// 3. 过度详细的注释
// 4. 重复的代码片段

清理策略：

// 1. 立即删除废弃代码
git log --name-status # 找到变更记录
git blame file.ts     # 找到污染来源

// 2. 错误示例移到文档目录
mv examples/bad-examples.ts docs/common-mistakes.md

// 3. 精简注释
// 删除历史背景、未来计划等无关信息

// 4. 提取重复代码
const common = extractCommonCode(file.ts)
createUtilityFile(common)

🌟 总结：健忘症时代的架构之道

大模型健忘症的本质

核心问题：

  1. 物理限制：Token上下文窗口的硬性约束
  2. 注意力衰减：距离越远的信息，关注度越低
  3. 模式干扰：错误或废弃代码会污染AI的学习

解决方案的架构思维

1. 拆分思维

  • 按职责拆分文件，而不是按技术分层
  • 每个文件保持单一职责，控制在1000行以内
  • 避免大文件，更避免超大文件

2. 清理思维

  • 及时删除废弃代码，不要为"可能用到"保留
  • 移除错误示例，避免污染AI学习
  • 精简注释，删除无关信息

3. 结构化思维

  • 用清晰的文件结构导航AI理解
  • 用类型定义约束AI行为
  • 用文档模板规范AI输出

实用检查清单

文件健康检查：

  • 文件行数不超过1000行
  • 没有废弃的函数和类
  • 没有错误的示例代码
  • 导入语句精确，没有冗余
  • 注释简洁有效，不包含历史信息

项目架构检查：

  • 每个模块职责单一
  • 类型定义独立且清晰
  • Repository模式一致应用
  • 错误处理统一规范
  • Claude.md文档完整更新

开发流程检查：

  • 每个新功能有明确的上下文范围
  • 定期进行代码重构和清理
  • 使用自动化工具检查文件大小
  • 保持模块化的开发节奏

记住：AI编程不是让AI适应你的代码，而是设计让AI能够高效理解的代码架构。在健忘症成为常态的时代，好的架构就是对抗遗忘的最佳武器。

下一篇预告： 《架构即代码：如何用系统化思维驯服AI》

微信搜索"四哥还会聊AI"，看这些架构原则如何在实际项目中应用

微信搜索"汐屿笔记"，看这些架构原则如何在实际项目中应用

← 返回首页