1. 先搞清楚“大模型技术全景”到底在讲什么

看到“大模型技术全景”这种标题，很多人第一反应是又要看一篇堆砌概念和架构图的综述。但如果你真的在考虑把大模型用起来，不管是做应用开发、系统集成，还是想理解背后的技术栈，最需要知道的不是那些花哨的名词，而是从核心原理到落地存储，整个链条里哪些环节是决定性的，哪些是你可以跳过的。

这篇文章不会从“人工智能简史”开始。我会直接从一个最实际的场景切入：你训练或微调了一个模型，它能够处理文本、生成内容，或者完成某种分类、问答任务。接下来，你想把它变成一个可以稳定服务、能记录状态、能管理历史对话或任务数据的应用。这时，Transformer是你的发动机，而PostgreSQL这类数据库，就是你的底盘和货舱。发动机的原理决定了车能跑多快、多稳，而底盘和货舱的设计决定了这辆车能拉多少货、跑多远、数据会不会丢。

所以，这个“全景”的核心是两条线：一是理解Transformer为何成为大模型的基石，特别是Attention机制和如今关键的Flash Attention等优化技术；二是掌握如何用PostgreSQL这样的生产级数据库，来承接大模型应用产生的数据流，完成从演示原型到可运营服务的跨越。无论你是开发者、算法工程师还是系统架构师，抓住这两点，就能把散落的技术点串联成一个可操作的路线图。

2. Transformer：不只是“注意力”，更是可并行化的计算范式

几乎所有现代大模型都基于 Transformer 架构。但初学者常有的误解是，把 Transformer 等同于“注意力机制（Attention）”。Attention 确实是灵魂，但 Transformer 的颠覆性在于它用纯注意力机制完全取代了 RNN、LSTM 的序列递归计算，从而实现了前所未有的并行训练能力。

2.1 Attention 机制：从 Seq2Seq 到 Self-Attention

最初的 Attention 是为 Seq2Seq（如机器翻译）模型设计的。在经典的编码器-解码器结构中，解码器在生成每一个词时，会“注意”编码器输出的所有隐藏状态，并给它们分配不同的权重。这解决了长序列信息遗忘的问题。

Transformer 的核心创新是Self-Attention。它让序列中的每一个元素（例如句子中的每一个词）都去和序列中的所有其他元素计算关联度。通过计算 Query、Key、Value 三组向量，模型能动态地捕捉到“我”与上下文中所有词的关系。比如在“苹果公司发布了新款手机”这句话里，“苹果”这个词通过 Self-Attention，能同时关联到“公司”、“发布”、“手机”，从而明确它指的是品牌而非水果。

用代码理解这个计算过程会更直观。虽然你不会从头实现，但看懂这个流程对调参和排查问题有帮助：

# 简化的 Self-Attention 计算示意 (非完整可运行代码) import torch import torch.nn.functional as F def scaled_dot_product_attention(query, key, value, mask=None): """ query, key, value: [batch_size, seq_len, d_model] """ d_k = query.size(-1) # 1. 计算 Q 和 K 的点积，得到注意力分数 scores = torch.matmul(query, key.transpose(-2, -1)) / math.sqrt(d_k) # 2. 可选：应用掩码（如遮挡未来词） if mask is not None: scores = scores.masked_fill(mask == 0, -1e9) # 3. 对分数做 Softmax，得到注意力权重 attention_weights = F.softmax(scores, dim=-1) # 4. 用权重对 Value 加权求和，得到输出 output = torch.matmul(attention_weights, value) return output, attention_weights

这个过程中，d_k（Key的维度）的平方根缩放是为了防止点积结果过大导致 Softmax 梯度消失。多头注意力（Multi-Head Attention）则是将这个过程复制多份，每份用不同的线性变换投影到不同的子空间，最后把结果拼接起来。这相当于让模型从多个角度（例如语法、语义、指代）同时理解关系。

2.2 从 Transformer 到大模型：架构的堆叠与缩放

原始的 Transformer 包含编码器（Encoder）和解码器（Decoder）堆叠。像 BERT 这类模型只用了编码器，适合理解任务（如文本分类、问答）；GPT 系列只用了解码器（带掩码的自注意力），适合生成任务。

大模型本质上就是巨量参数化的 Transformer 堆叠。当参数规模（参数量、层数、注意力头数）和数据规模突破某个阈值后，模型会涌现出小模型不具备的推理、泛化和指令遵循能力。这就是“大”的价值。

但“大”也带来了严峻的工程挑战：巨大的显存占用和极长的训练时间。这就引出了下一个关键点。

2.3 Flash Attention 与 Paged Optimizer：让大模型训练成为可能

如果你自己尝试过用 PyTorch 朴素地跑一个稍大的 Transformer 模型，很快就会遇到CUDA out of memory。这是因为标准的注意力计算需要存储一个[序列长度, 序列长度]的中间矩阵，对于长序列（如 4096 tokens），这个矩阵会轻易耗尽显存。

Flash Attention是解决这个问题的革命性优化。它通过一种名为“平铺（Tiling）”的技术，将大的注意力计算分解成小块，在 GPU 的高速缓存（SRAM）中进行计算，避免在显存（HBM）中存储庞大的中间矩阵。其核心思想是重计算：用额外的计算开销（FLOPs）换取极大的显存节省。对于用户而言，这意味着你可以用同样的 GPU 跑更长的序列或更大的批量大小。

在实际使用中，你通常不需要自己实现 Flash Attention。主流框架如 PyTorch 2.x 之后集成了优化后的注意力算子 (torch.nn.functional.scaled_dot_product_attention)，并会自动在后端选择最有效的实现（包括 Flash Attention）。当你使用 Hugging Face 的Transformers库时，也可以通过设置attn_implementation=”flash_attention_2″来启用（如果硬件和模型支持）。

# 在现代Transformer库中使用优化注意力（示意） from transformers import AutoModelForCausalLM import torch model = AutoModelForCausalLM.from_pretrained( "meta-llama/Llama-2-7b-chat-hf", torch_dtype=torch.bfloat16, attn_implementation="flash_attention_2", # 关键参数 device_map="auto" )

Paged Optimizer（如bitsandbytes库提供的AdamW8bit）则是另一项关键优化。它通过将优化器状态（如动量、方差）以 8 位整数格式进行分页存储和管理，将训练大模型所需的显存减少约 60%。这对于在消费级显卡（如 24GB 显存的 RTX 4090）上进行模型微调至关重要。

注意：启用这些优化通常需要特定的硬件（如 Ampere 架构及以后的 NVIDIA GPU）、软件版本（CUDA, PyTorch）和模型配置。动手前，第一件事是确认你的环境是否满足要求，而不是直接复制命令。

3. 从模型到应用：为什么需要 PostgreSQL 这样的数据库

假设你现在有了一个能跑起来的模型，无论是通过 API 调用云端大模型，还是在本地部署了一个开源模型。你写了一个简单的 Python 脚本，输入问题，得到回答。这只是一个演示。

一旦你想做下面任何一件事，数据库就变得必不可少：

1. 记录历史：保存用户与模型的对话记录，用于后续分析或实现“继续上文”功能。
2. 管理状态：保存任务的处理状态（如“排队中”、“处理中”、“完成”、“失败”）。
3. 存储知识：将外部知识（如产品文档、公司制度）向量化后存入，供模型检索增强（RAG）。
4. 缓存结果：对常见或重复的问题进行缓存，提升响应速度并降低 API 调用成本。
5. 用户与权限管理：在多用户系统中管理账号、会话和访问控制。

这时，一个文本文件或内存字典就完全不够用了。你需要一个可靠、高效、支持复杂查询的数据库。PostgreSQL在这里是一个极佳的选择，甚至比 MySQL 更受青睐于 AI 应用，原因在于：

• 对 JSON 的原生友好支持：大模型的输入输出、中间参数、非结构化的元数据，天然适合用 JSON 存储。PostgreSQL 提供了强大的JSONB数据类型，支持索引和高效查询，你可以像查询普通字段一样查询 JSON 内部的键值。
• 向量扩展（pgvector）：这是杀手级功能。通过pgvector插件，PostgreSQL 可以直接存储和检索向量数据（即 Embedding）。这使得实现 RAG 应用变得异常简单：将知识库文本向量化后存入 PostgreSQL，用户提问时，先将其向量化，然后在数据库中进行相似度搜索（如余弦相似度），找到最相关的知识片段，连同问题一起发给大模型。所有数据都在一个数据库里，简化了架构。
• 可靠性与事务：作为成熟的关系型数据库，PostgreSQL 提供了 ACID 事务保证。这意味着当你同时更新用户余额和记录 API 调用次数时，不会出现数据不一致。
• 丰富的生态：有完善的管理工具（如 pgAdmin）、监控方案和云服务商支持。

3.1 PostgreSQL 快速上手：安装与基础配置

对于开发和测试，我建议直接用 Docker 运行 PostgreSQL，这是最干净、最避免环境冲突的方式。

# 拉取包含 pgvector 的 PostgreSQL 镜像（以 pgvector/pgvector:pg16 为例） docker pull pgvector/pgvector:pg16 # 运行容器 docker run -d \ --name my-postgres \ -e POSTGRES_PASSWORD=your_strong_password \ -e POSTGRES_DB=ai_app \ -p 5432:5432 \ -v /path/to/your/local/data:/var/lib/postgresql/data \ pgvector/pgvector:pg16

解释一下参数：

• -e POSTGRES_PASSWORD: 设置超级用户 postgres 的密码，务必替换为强密码。
• -e POSTGRES_DB: 容器启动时创建的默认数据库名。
• -p 5432:5432: 将容器的 5432 端口映射到主机，方便用工具连接。
• -v ...: 将数据目录挂载到本地，防止容器删除后数据丢失。

启动后，你可以用任何 PostgreSQL 客户端（如psql命令行、DBeaver、DataGrip）连接。主机为localhost，端口5432，用户名postgres，密码为你设置的密码。

避坑提示：如果连接时报错，首先检查容器是否正常运行 (docker ps)，然后检查防火墙是否开放了 5432 端口。在 Linux 上，有时需要修改pg_hba.conf文件以允许远程连接，但在 Docker 的默认配置下，本地连接通常是允许的。

3.2 设计一个简单的大模型应用数据表

假设我们在构建一个带对话历史的问答应用。表结构可以这样设计：

-- 启用 pgvector 扩展 CREATE EXTENSION IF NOT EXISTS vector; -- 用户表 CREATE TABLE users ( id SERIAL PRIMARY KEY, username VARCHAR(50) UNIQUE NOT NULL, email VARCHAR(100) UNIQUE, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- 对话会话表 CREATE TABLE chat_sessions ( id SERIAL PRIMARY KEY, user_id INTEGER REFERENCES users(id) ON DELETE CASCADE, title VARCHAR(255), -- 可自动生成，如“关于PostgreSQL的讨论” created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- 消息表（核心） CREATE TABLE chat_messages ( id SERIAL PRIMARY KEY, session_id INTEGER REFERENCES chat_sessions(id) ON DELETE CASCADE, role VARCHAR(20) NOT NULL, -- 'user', 'assistant', 'system' content TEXT NOT NULL, -- 消息文本内容 tokens INTEGER, -- 消耗的token数，用于计费或分析 model VARCHAR(100), -- 使用的模型名称，如 'gpt-4', 'claude-3' -- 以下是向量相关字段（用于RAG或语义搜索历史） embedding vector(1536), -- 假设使用 OpenAI text-embedding-3-small 维度为1536 metadata JSONB, -- 存储额外信息，如温度参数、函数调用结果等 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- 为 embedding 字段创建索引以加速相似度搜索 CREATE INDEX ON chat_messages USING ivfflat (embedding vector_cosine_ops);

这个设计体现了几个关键点：

1. 关系建模：users->chat_sessions->chat_messages，结构清晰。
2. 向量就绪：chat_messages表包含了embedding字段和对应的向量索引。当用户提问时，你可以实时计算问题的向量，并在这个表中搜索历史中语义相似的消息，实现“记忆”功能。
3. 灵活性：metadata字段是JSONB类型，可以存储任何非结构化的额外数据，比如调用的外部工具结果、生成图片的 URL 等，无需频繁修改表结构。
4. 可分析：tokens和model字段便于后续做成本分析和用量统计。

4. 实战串联：构建一个带记忆和知识库的问答服务

现在，我们把 Transformer 模型和 PostgreSQL 数据库结合起来，构建一个简单的本地服务。这个服务能回答用户问题，并具备两个能力：1) 检索本地知识库（RAG）；2) 记住当前对话的历史。

4.1 环境与依赖准备

创建一个新的 Python 虚拟环境，并安装必要依赖：

# 创建并激活虚拟环境 python -m venv venv source venv/bin/activate # Linux/macOS # venv\Scripts\activate # Windows # 安装核心依赖 pip install torch transformers sentence-transformers # 用于模型和Embedding pip install psycopg2-binary pgvector # PostgreSQL 连接和向量支持 pip install fastapi uvicorn # 构建API服务 pip install python-dotenv # 管理环境变量

这里我们使用sentence-transformers库来生成文本向量，它封装了高质量的预训练模型，使用简单。生产环境可能会选择专门的 Embedding 服务。

4.2 核心服务代码拆解

我们创建一个app.py文件，逐步实现功能。

第一步：初始化数据库连接和 Embedding 模型

import os from dotenv import load_dotenv import psycopg2 from psycopg2.extras import RealDictCursor from sentence_transformers import SentenceTransformer import torch # 加载环境变量，将数据库密码等敏感信息放在 .env 文件中 load_dotenv() class AIDatabaseService: def __init__(self): # 初始化 Embedding 模型（选择一个小型高效的模型） self.embedding_model = SentenceTransformer('all-MiniLM-L6-v2') # 384维向量，速度快 self.device = 'cuda' if torch.cuda.is_available() else 'cpu' self.embedding_model.to(self.device) print(f"Embedding model loaded on {self.device}") # 初始化数据库连接 self.db_conn = psycopg2.connect( host=os.getenv("DB_HOST", "localhost"), port=os.getenv("DB_PORT", "5432"), dbname=os.getenv("DB_NAME", "ai_app"), user=os.getenv("DB_USER", "postgres"), password=os.getenv("DB_PASSWORD", ""), cursor_factory=RealDictCursor # 返回字典格式的结果 ) print("Database connection established.") def get_embedding(self, text: str): """生成文本的向量表示""" with torch.no_grad(): # 模型返回的是 numpy array，我们转换为 list 以便存入 PostgreSQL embedding = self.embedding_model.encode(text, convert_to_tensor=False) return embedding.tolist()

第二步：实现知识库检索（RAG）

假设我们已经有一个知识库表knowledge_base，其中存储了文档片段及其向量。

def search_knowledge(self, query: str, top_k: int = 3): """在知识库中搜索与问题最相关的文档片段""" query_embedding = self.get_embedding(query) # 使用余弦相似度进行搜索 sql = """ SELECT id, content, metadata, 1 - (embedding <=> %s::vector) as similarity FROM knowledge_base ORDER BY embedding <=> %s::vector LIMIT %s; """ # 注意：pgvector 的 `<=>` 运算符计算余弦距离，距离越小越相似。 # 我们将其转换为相似度：相似度 = 1 - 距离 with self.db_conn.cursor() as cur: cur.execute(sql, (query_embedding, query_embedding, top_k)) results = cur.fetchall() return results

第三步：集成大模型生成（以调用 OpenAI API 为例）

为了简化，这里演示调用 OpenAI 格式的 API（包括本地部署的兼容 OpenAI API 的开源模型，如 Llama 通过ollama或vLLM暴露的接口）。

import openai # 或使用 `requests` 调用兼容接口 # 假设你的大模型服务兼容 OpenAI API client = openai.OpenAI( base_url=os.getenv("LLM_API_BASE", "https://api.openai.com/v1"), api_key=os.getenv("LLM_API_KEY", "your-api-key") ) class ChatService: def __init__(self, db_service: AIDatabaseService): self.db = db_service def generate_response(self, session_id: int, user_message: str): """生成回答的核心逻辑""" # 1. 检索相关知识 relevant_knowledge = self.db.search_knowledge(user_message) context = "\n\n".join([item['content'] for item in relevant_knowledge]) # 2. 获取当前对话历史（例如最近10轮） history = self._get_conversation_history(session_id, limit=10) # 3. 构建 Prompt，将历史、知识和当前问题组合 system_prompt = """你是一个智能助手，请根据以下已知信息回答用户的问题。 如果已知信息不足以回答问题，请直接说明你不知道，不要编造信息。 已知信息： {context} """ messages = [ {"role": "system", "content": system_prompt.format(context=context)} ] messages.extend(history) # 加入历史对话 messages.append({"role": "user", "content": user_message}) # 4. 调用大模型 try: response = client.chat.completions.create( model=os.getenv("LLM_MODEL", "gpt-3.5-turbo"), messages=messages, temperature=0.7, max_tokens=500 ) assistant_reply = response.choices[0].message.content except Exception as e: assistant_reply = f"调用模型时出错：{str(e)}" # 5. 将用户消息和助手回复存入数据库 self._save_message(session_id, "user", user_message) self._save_message(session_id, "assistant", assistant_reply, model=os.getenv("LLM_MODEL")) return assistant_reply def _get_conversation_history(self, session_id: int, limit: int): """从数据库获取指定会话的历史消息""" sql = """ SELECT role, content FROM chat_messages WHERE session_id = %s ORDER BY created_at ASC LIMIT %s; """ with self.db.db_conn.cursor() as cur: cur.execute(sql, (session_id, limit)) rows = cur.fetchall() # 转换为 OpenAI API 需要的格式 return [{"role": row['role'], "content": row['content']} for row in rows] def _save_message(self, session_id: int, role: str, content: str, model=None): """保存消息到数据库，并计算向量""" embedding = self.db.get_embedding(content) if role in ['user', 'assistant'] else None sql = """ INSERT INTO chat_messages (session_id, role, content, embedding, model) VALUES (%s, %s, %s, %s::vector, %s); """ with self.db.db_conn.cursor() as cur: cur.execute(sql, (session_id, role, content, embedding, model)) self.db.db_conn.commit()

第四步：用 FastAPI 包装成 HTTP 服务

from fastapi import FastAPI, HTTPException from pydantic import BaseModel app = FastAPI(title="AI Chat Service with Memory & RAG") # 初始化全局服务 db_service = AIDatabaseService() chat_service = ChatService(db_service) class ChatRequest(BaseModel): session_id: int message: str @app.post("/chat") async def chat_endpoint(request: ChatRequest): """主要的聊天接口""" try: response = chat_service.generate_response(request.session_id, request.message) return {"reply": response} except Exception as e: raise HTTPException(status_code=500, detail=str(e)) @app.get("/health") async def health_check(): return {"status": "healthy"}

运行服务：uvicorn app:app --reload --host 0.0.0.0 --port 8000

现在，你就有了一个具备记忆和知识检索能力的本地大模型服务。它通过 PostgreSQL 管理所有的状态和数据。

5. 生产环境部署与优化考量

上面的代码是一个可运行的演示原型。要用于生产，还需要考虑以下关键点：

5.1 数据库层面

1. 连接池：不要为每个请求创建新的数据库连接。使用psycopg2.pool或像asyncpg（异步）这样的库，或者通过 PgBouncer 中间件来管理连接池。
2. 索引优化：除了向量索引，在session_id,created_at等常用查询字段上也要建立索引。定期使用EXPLAIN ANALYZE分析慢查询。
3. 向量索引参数调优：ivfflat索引在创建时需要指定lists参数，这需要在索引构建速度、查询速度和召回率之间权衡。对于海量数据，考虑使用HNSW索引（pgvector 也支持），它通常有更好的查询性能。
4. 分区与归档：chat_messages表会快速增长。考虑按时间（如每月）进行分区，并将历史冷数据归档到成本更低的存储中。

5.2 大模型服务层面

1. 本地模型部署：如果使用开源模型（如 Llama、Qwen），推荐使用vLLM或TGI(Text Generation Inference) 进行部署。它们提供了高效的推理服务、连续的批处理（Continuous Batching）和 OpenAI 兼容的 API 接口。
2. 异步处理：生成式模型推理耗时较长。使用FastAPI的异步特性，并在可能的情况下将生成任务放入消息队列（如 Redis, RabbitMQ）进行后台处理，通过 WebSocket 或轮询返回结果，避免 HTTP 请求超时。
3. 缓存策略：对高频或重复的问题，可以将(问题embedding, 模型参数)作为键，将生成的回答缓存到 Redis 或 PostgreSQL 的缓存表中，设置合理的 TTL。
4. 限流与熔断：在 API 网关或应用层对用户进行限流（rate limiting），并设置对下游模型服务的熔断机制，防止一个慢请求拖垮整个服务。

5.3 监控与可观测性

1. 日志：结构化记录每个请求的session_id,user_message,model_used,token_usage,response_time,error。这有助于调试和成本分析。
2. 指标：监控数据库连接数、查询延迟、模型服务的 GPU 利用率、显存占用、请求排队长度等。
3. 追踪：对于复杂的链式调用（如 RAG：检索 -> 构造 Prompt -> 生成），使用 OpenTelemetry 等工具进行分布式追踪，快速定位瓶颈。

6. 常见问题与排查清单

当你把这一切组装起来运行时，肯定会遇到各种问题。下面是一个按优先级排序的排查清单：

问题：服务启动失败或连接不上数据库。

• 检查1：数据库服务是否运行？docker ps或systemctl status postgresql。
• 检查2：连接参数是否正确？主机、端口、用户名、密码、数据库名。密码中的特殊字符可能需要转义。
• 检查3：防火墙/网络策略？确认应用服务器能访问数据库的 5432 端口。
• 检查4：pg_hba.conf 配置？确认允许从应用服务器 IP 进行连接。

问题：向量相似度搜索速度慢。

• 检查1：是否创建了向量索引？\d chat_messages查看表结构。
• 检查2：索引类型是否合适？对于千万级以下数据，ivfflat通常足够。确保在创建索引前已有一部分代表性数据，以便索引能更好聚类。CREATE INDEX ... WITH (lists = 100);中的lists参数可以调整。
• 检查3：搜索的 Top K 是否过大？如果不是需要高召回率的场景，top_k=5或10通常足够。
• 检查4：Embedding 模型维度是否过高？all-MiniLM-L6-v2是 384 维，速度和精度平衡较好。如果使用 1536 维的模型，存储和计算成本会高很多。

问题：大模型生成内容质量差或胡言乱语。

• 检查1：Prompt 构造是否正确？将构造好的 messages 列表打印出来，检查 system prompt、context 和 history 的拼接是否符合预期。
• 检查2：检索到的知识是否相关？打印search_knowledge返回的内容和相似度分数，确认检索到的片段确实与问题相关。
• 检查3：模型参数是否合理？temperature过高（>1.0）会导致随机性大，过低（<0.1）会导致重复和枯燥。对于事实性问答，建议在 0.1-0.5 之间。
• 检查4：是否触及模型上下文长度限制？如果历史对话很长，加上检索的知识，可能超过模型的上下文窗口。需要实现历史消息的摘要或选择性遗忘。

问题：服务响应时间过长。

• 检查1：瓶颈在哪？使用计时工具，分别测量数据库检索、Embedding 生成、大模型 API 调用的耗时。
• 检查2：数据库查询慢？对慢查询 SQL 执行EXPLAIN ANALYZE。
• 检查3：Embedding 是瓶颈？考虑将 Embedding 生成也异步化，或使用更快的模型（如all-MiniLM-L6-v2已经很快）。
• 检查4：模型服务排队？检查模型部署服务的监控，看是否有请求堆积。考虑增加模型副本或使用更高性能的推理引擎。

问题：GPU 显存溢出（CUDA Out of Memory）。

• 检查1：是否使用了 Flash Attention 等优化？确认模型加载时启用了相关优化。
• 检查2：批量大小（batch_size）是否过大？在 Embedding 生成或模型推理时，减少批量处理的数量。
• 检查3：是否使用了量化？对于推理，使用 8-bit 或 4-bit 量化可以大幅减少显存占用（如bitsandbytes库）。
• 检查4：是否有内存泄漏？长时间运行后，监控显存占用是否持续增长。确保在不需要时释放 Tensor (del tensor并torch.cuda.empty_cache())。

走通从 Transformer 原理到 PostgreSQL 实战的整个流程，最大的价值不是实现了某个炫酷的功能，而是建立起一个可扩展、可观测、可维护的技术栈框架。在这个框架里，你可以安全地试验新的模型、新的检索算法、新的业务逻辑，而不用担心数据会丢，或者服务会以意想不到的方式崩溃。这才是工程化落地大模型技术最需要的那份“底盘”能力。