还在用"帮我写个代码"这种玄学提问？90%的人根本没搞懂：和AI对话不是许愿，是编程！从"随便聊聊"到"精准操控"，一篇让你彻底告别AI"已读乱回"的救命指南。

---

目录

1. 核心认知：提示词不是聊天，是编程
2. 四大支柱：结构化提示词的骨架
3. 常见误区：那些年我们踩过的坑
4. 实战模板：拿来即用的框架
5. 进阶技巧：让AI从"能跑"到"飞起"
6. 场景应用：程序员的日常救星

---

嗨，大家好呀，我是你的老朋友精通代码大仙。接下来我们一起学习 《DeepSeek极简入门与应用》，震撼你的学习轨迹！

---

“Garbage in, garbage out”——垃圾进，垃圾出。

这句老程序员都懂的真理，放在AI时代依然血淋淋地成立。你是不是也这样：对着DeepSeek憋了半天，就打出一句"帮我写个排序算法"，然后看着AI给你一段冒泡排序，心里默默吐槽"这我也会啊，我要的是最优解"；或者干脆复制粘贴一大段报错信息，期待AI能一眼看穿你的bug，结果它开始跟你聊"编程的重要性"？

兄弟，醒醒。2026年了，还在用"许愿式提问"，你就等着被会用结构化提示词的人卷死吧。

今天这篇，咱们把"结构化提示词"这个事儿彻底掰扯清楚。不是那种让你背模板的死记硬背，而是真正理解为什么这样写、怎么写、写成什么样。读完这篇，我保证你再看自己以前的提问，会尴尬得脚趾抠地。

---

一、核心认知：提示词不是聊天，是编程

点题

先扔一个颠覆认知的观点：写提示词，本质上是在用一种新的编程语言编程。

自然语言就是这门语言的语法，AI就是你的运行时环境。你写的每一个提示词，都是在调用一个超级复杂的函数，而这个函数的参数就是你的指令。

看到没？左边是你熟悉的，右边是你正在学的。区别只在于：传统编程追求确定性，提示工程驾驭概率性。

痛点分析

新手最大的误区，就是把AI当成人来聊天。

错误示范：

帮我写个代码，要快的，好看的，谢谢。

这像什么？像你去餐厅说"随便炒个好吃的"。厨师能get到你想吃辣还是清淡？想吃肉还是吃素？预算多少？

更惨的是这种：

为什么我的代码报错了？
[粘贴100行无关紧要的日志]

AI看着这堆日志，和你看着"Segmentation fault"一样懵。没有上下文，没有环境信息，没有复现步骤，它只能瞎猜。

思维误区清单：

• ❌ “AI是万能的，应该懂我”
• ❌ “说越多越详细越好”（信息过载）
• ❌ “一次提问就要拿到最终答案”
• ❌ “不用给例子，AI自己会悟”

解决方案/正确做法

把提示词当成函数调用来写。每个提示词至少包含：你要什么、给谁用、什么条件、什么格式。

修正后的提问：

角色：你是一位有10年经验的算法工程师，擅长Python性能优化。

任务：实现一个对10万条用户记录按"最后登录时间"降序排列的功能。

约束：
- 数据存储在内存中的列表，元素是字典，包含字段：user_id, last_login_timestamp
- 时间复杂度优先，空间复杂度次要
- 需要处理last_login_timestamp可能为None的情况

输出：
- 完整的Python函数，包含类型注解
- 时间/空间复杂度分析
- 3个边界情况的测试用例

看到差距了吗？这不是"聊天"，这是精确的需求文档。AI拿到这个，就像你拿到一份清晰的产品PRD，知道该干嘛、怎么干、干成什么样。

好处立竿见影：

• 输出质量从"能用"变成"好用"
• 减少来回扯皮的轮次
• 你可以批量复制这个模式，建立个人提示词库

小结

提示词的本质是编程，自然语言是语法，清晰结构是算法。忘掉"聊天"，开始"编码"。

---

二、四大支柱：结构化提示词的骨架

点题

所有高质量的结构化提示词，都建立在四个支柱上。我称之为RTCO框架：Role（角色）、Task（任务）、Constraint（约束）、Output（输出）。

这四个不是死板的顺序，而是相互关联的有机整体。

痛点分析

新手常犯的错误是"缺胳膊少腿"。

只有Task，没有Role：

写一个登录接口。

AI写了个PHP的，你要的是Java的。它写了个简单的，你要的是带JWT+Redis的。

只有Role和Task，没有Constraint：

你是一位Java后端专家。写一个高并发登录接口。

“高并发"是多少QPS？100和10000的实现完全不同。要不要防刷？要不要支持多端登录？AI只能猜，猜错你就骂它"人工智障”。

什么都有，但Output模糊：

[前面写得很好]
给我代码。

然后拿到一段没注释、没异常处理、直接打印到控制板的"能跑就行"代码。

解决方案/正确做法

Role：给AI一个"人设"

不是随便写"你是专家"，要具体到场景：

• ❌ “你是Python专家”
• ✅ “你是一位擅长数据处理的Python工程师，习惯用pandas和polars，注重内存效率”

Task：用动词开头，描述完整动作

• ❌ “登录功能”
• ✅ “设计并实现一个支持手机号+验证码登录的RESTful API，包含发送验证码、校验验证码、生成Token三个端点”

Constraint：列出所有"必须"和"禁止"

必须：
- 使用Spring Boot 3.x
- 验证码有效期5分钟，存储在Redis
- Token使用JWT，有效期2小时

禁止：
- 不允许明文存储任何敏感信息
- 不允许在日志中打印验证码

Output：指定格式，最好给示例

输出格式：
1. 接口设计文档（Markdown表格：URL/方法/请求参数/响应/状态码）
2. 核心代码（Java，含关键注释）
3. 简单的curl测试命令

完整示例：

【角色】
你是一位在金融科技公司工作5年的Java架构师，熟悉高并发系统设计，代码风格严谨，注重安全性。

【任务】
设计一个用户资产查询接口，支持按币种筛选，返回总资产和明细列表。

【约束】
- 技术栈：Spring Boot 3.2 + MyBatis-Plus + MySQL 8.0
- 性能：P99延迟<100ms，支持1000 QPS
- 安全：必须校验用户身份，敏感数据脱敏（银行卡号显示后4位）
- 数据：用户表user(id, name)，资产表asset(user_id, currency, amount, bank_card_no)

【输出】
1. ER关系图（用Mermaid语法）
2. 核心SQL（含索引建议）
3. Java代码（Controller/Service/Mapper三层，含关键注释）
4. 压测建议（工具+关键指标）

小结

RTCO不是填空题，是思维框架。每次写提示词前过一遍这四项，质量保底提升80%。

---

三、常见误区：那些年我们踩过的坑

点题

知道该做什么很重要，知道不该做什么同样重要。这节盘点5个最隐蔽、最致命的误区。

痛点分析

误区1：把AI当搜索引擎

Java怎么读文件？

AI给你一堆方法，FileReader、Files.readString、BufferedReader…但你真正想问的是：“我的代码用Scanner读大文件卡死了，怎么办？”

误区2：信息过载，一次性塞太多

[粘贴200行代码]
[粘贴50行报错]
[粘贴项目结构]
帮我看看。

AI的上下文窗口是有限的（虽然越来越长，但有效注意力有限）。你塞太多，它抓不住重点，开始 hallucinate（幻觉）。

误区3：不给示例，期待AI"悟"

给我写几个测试用例。

什么类型的测试？单元测试还是集成测试？用什么框架？测试风格是BDD还是传统assert？AI只能猜，猜错就翻车。

误区4：缺乏迭代，期待一次到位

[第一次提问]
[拿到结果不满意]
[重新写一个完全不同的提示词]

这是最大的浪费。好的提示词是迭代优化出来的，不是一次性憋出来的。

误区5：角色和任务不匹配

你是一位刚毕业的实习生。设计一个能支撑千万用户的分布式架构。

AI要么真的用"实习生"水平给你写，要么角色设定被忽略。角色要匹配任务难度。

解决方案/正确做法

针对误区1：先描述场景，再问问题

场景：我在处理一个2GB的CSV日志文件，当前用Scanner逐行读取，内存溢出。
目标：找到一种流式读取方案，边读边处理，内存占用稳定。
已尝试：Scanner和Files.readAllLines都OOM。

针对误区2：分层提问，先框架后细节

第一轮：给核心代码 + 核心问题
第二轮：根据回答，补充上下文
第三轮：深入具体模块

针对误区3：给示例，用Few-shot

请按照以下风格编写测试用例：

示例1：
@Test
void shouldRejectInvalidEmail() {
    // given
    String invalidEmail = "not-an-email";
    
    // when & then
    assertThatThrownBy(() -> validator.validate(invalidEmail))
        .isInstanceOf(InvalidEmailException.class)
        .hasMessageContaining("Invalid email format");
}

现在请为passwordValidator编写类似风格的3个测试用例...

针对误区4：建立对话历史，迭代优化

基于你刚才的实现，我需要调整：
1. 把同步调用改成异步CompletableFuture
2. 增加超时控制，3秒超时降级
3. 保留原有接口签名，内部重构即可

针对误区5：角色-任务-难度三角匹配

任务难度	合适角色	示例
简单CRUD	初级开发者	“你是一位熟悉Spring Boot的Java开发者”
性能优化	资深工程师	“你是一位有5年电商系统优化经验的架构师”
系统设计	架构师/CTO	“你是一位设计过千万级DAU系统的技术负责人”

小结

避开这些坑，你就超过了80%的提示词使用者。剩下的20%，靠持续迭代和积累。

---

四、实战模板：拿来即用的框架

点题

理论讲完，上干货。这里给三个我亲测好用的模板，覆盖不同场景。

痛点分析

很多人收藏了一堆模板，但用的时候不知道选哪个，或者填得生硬。

典型困境：

• 模板A要求写"背景"，但我的需求很简单，没背景可写
• 模板B有8个部分，填完发现太啰嗦
• 模板C是英文的，翻译过来怪怪的

解决方案/正确做法

模板1：RTCO轻量版（适合80%的日常任务）

【角色】{一句话定位}
【任务】{用动词开头的完整描述}
【约束】{必须/禁止，各不超过3条}
【输出】{格式要求，可给示例}

填充示例：

【角色】熟悉Vue3和TypeScript的前端工程师
【任务】封装一个useLocalStorage的组合式函数，支持响应式读写
【约束】
- 必须处理SSR兼容性（Nuxt3环境）
- 必须支持自定义序列化（默认JSON）
【输出】
- 完整TypeScript代码
- 使用示例（3个不同场景）

模板2：CRISPE完整版（适合复杂分析/设计任务）

CRISPE = Capacity and Role（能力与角色）+ Insight（洞察与背景）+ Statement（任务陈述）+ Personality（输出风格）+ Experiment（实验/迭代）

【Capacity and Role】
你是一位{具体领域}的{具体职位}，擅长{具体技能1}、{具体技能2}。

【Insight】
当前背景：{项目阶段/业务场景/技术现状}
核心痛点：{要解决的具体问题}
已尝试方案：{为什么没成功}

【Statement】
请完成：{具体任务}
成功标准：{如何验收}

【Personality】
输出风格：{技术文档风格/口语化讲解/对比分析/步骤指南}
详细程度：{概述/详细/手把手}

【Experiment】
如果涉及不确定方案，请：
1. 列出2-3种可选方案
2. 对比优缺点
3. 推荐并说明理由

填充示例（技术选型）：

【Capacity and Role】
你是一位在物联网领域工作8年的后端架构师，熟悉MQTT、CoAP、LwM2M等协议，有百万设备接入经验。

【Insight】
当前背景：智能家居平台，当前10万设备，预计2年内增长到500万
核心痛点：当前MQTT集群在设备同时上线时（如早晨8点）出现大规模超时
已尝试方案：增加Broker节点（效果有限，主要是单节点连接数瓶颈）

【Statement】
请完成：设计一个新的设备接入架构，解决海量并发连接问题
成功标准：支持100万并发连接，故障转移时间<30秒，消息延迟P99<500ms

【Personality】
输出风格：技术方案文档，含架构图描述
详细程度：详细，需要具体到技术选型和配置参数

【Experiment】
对比MQTT 5.0共享订阅、MQTT over QUIC、以及混合使用MQTT+HTTP/3的方案

模板3：代码专项版（适合代码生成/重构/Review）

【代码上下文】
语言/框架：{ }
相关依赖：{ }
代码位置：{这个类在系统中的角色}

【当前代码】
```【语言】
{粘贴代码}

【目标】
{生成/重构/优化/Debug/解释}

【具体要求】

• 必须保留：{ }
• 必须修改：{ }
• 禁止：{ }

【参考风格】
{可选：粘贴一段你满意的代码，让AI学习风格}

### 小结

模板是脚手架，不是牢笼。从轻量版开始，复杂任务上完整版，特定场景自定义。用熟一个，再扩展。

---

## 五、进阶技巧：让AI从"能跑"到"飞起"

### 点题

掌握了基础结构，再来三个进阶技巧：**链式思考（Chain-of-Thought）**、**少样本学习（Few-shot）**、**自我修正（Self-correction）**。

```mermaid
flowchart TB
    subgraph Basic["基础层"]
        B1["RTCO结构"]
        B2["清晰约束"]
    end
    
    subgraph Advanced["进阶层"]
        A1["链式思考<br/>Step by Step"]
        A2["少样本学习<br/>Give Examples"]
        A3["自我修正<br/>Critique & Refine"]
    end
    
    subgraph Expert["专家层"]
        E1["元提示词<br/>Prompt about Prompt"]
        E2["自动化工作流<br/>Multi-Agent"]
    end
    
    Basic --> Advanced --> Expert
    
    style Basic fill:#e8f4f8
    style Advanced fill:#fff3cd
    style Expert fill:#f8d7da

痛点分析

基础提示词能拿到"及格"答案，但想要"优秀"，需要引导AI更深入地思考。

典型场景：

• 数学题/逻辑题：AI直接给答案，但过程错了
• 代码优化：AI给了一个方案，但可能有更好的
• 复杂设计：AI忽略了某些边界情况

解决方案/正确做法

技巧1：链式思考（Chain-of-Thought）

核心：让AI"出声思考"，一步步来。

请解决以下问题，并展示完整的推理过程：

问题：一个线程池，核心线程数10，最大线程数20，队列长度100。
当前运行状态：15个活跃线程，队列中有80个任务。
问：如果再来30个任务，会发生什么？请逐步分析。

要求：先分析线程池的工作机制，再代入当前状态，最后给出结论。

对比直接问，这种提示能让AI暴露推理过程，你也能发现哪里理解错了。

技巧2：少样本学习（Few-shot）

核心：给例子，让AI模仿。

请按照以下示例的风格，为新的API编写文档：

示例API：GET /api/v1/users/{id}

文档格式：
### 获取用户详情
**接口描述**：根据用户ID查询基本信息，不包含敏感字段。

**请求参数**：
| 参数 | 位置 | 类型 | 必填 | 说明 |
|-----|------|------|------|------|
| id | path | long | 是 | 用户ID，雪花算法生成 |

**响应示例**：
```json
{
  "code": 200,
  "data": {
    "id": 123456789,
    "nickname": "张三",
    "avatarUrl": "https://..."
  }
}

错误码：

• 404：用户不存在
• 429：请求过于频繁

---

现在请为以下API编写相同格式的文档：

新API：POST /api/v1/orders（创建订单）

**技巧3：自我修正（Self-correction）**

核心：让AI先给答案，再批判，再优化。

请完成以下任务，分三步：

第一步：直接给出你的初步方案
[任务：设计一个防止用户重复提交订单的机制]

第二步：以"挑剔的代码审查者"身份，列出这个方案的3个以上潜在问题（如并发安全、性能、用户体验等）

第三步：基于第二步的批评，给出优化后的最终方案，并说明改进了什么

这个技巧特别适合复杂设计，能显著减少遗漏。

**组合技：元提示词（Meta-prompt）**

让AI帮你优化提示词：

我当前的提示词是：
[粘贴你的提示词]

这个提示词的问题是：[输出不稳定/太啰嗦/遗漏约束]

请作为提示工程专家，帮我：

1. 分析当前提示词的3个主要问题
2. 给出优化后的版本
3. 解释每个改动的理由

### 小结

进阶技巧的本质是**增加控制点**：控制思考过程、控制输出风格、控制质量检验。从"给答案"进化到"给好答案"。

---

## 六、场景应用：程序员的日常救星

### 点题

最后，把前面学的应用到程序员最真实的6个场景。

```mermaid
flowchart LR
    subgraph Scenes["高频场景"]
        S1["🐛 Bug诊断"]
        S2["⚡ 代码生成"]
        S3["📚 文档撰写"]
        S4["🏗️ 技术方案"]
        S5["🔍 代码Review"]
        S6["🎓 学习新技术"]
    end
    
    Scenes --> Output["结构化输出"]
    
    style S1 fill:#ff6b6b,color:#fff
    style S2 fill:#4ecdc4,color:#fff
    style S3 fill:#45b7d1,color:#fff
    style S4 fill:#96ceb4,color:#fff
    style S5 fill:#feca57,color:#000
    style S6 fill:#ff9ff3,color:#000

痛点分析

每个场景都有独特的坑：

• Bug诊断：信息给太少，AI瞎猜；给太多，AI抓不到重点
• 代码生成：生成的代码"能跑"但"不敢用"，缺乏边界处理
• 文档撰写：AI写的文档"正确的废话"，没有实用价值
• 技术方案：方案太泛，落不了地；或者太偏，不符合实际
• 代码Review：AI要么"好好好"，要么挑无关紧要的刺
• 学习新技术：AI罗列知识点，但学不会、记不住、用不出

解决方案/正确做法

场景1：Bug诊断

【角色】你是一位擅长Java并发编程的工程师，熟悉常见线程问题诊断。

【问题现象】
生产环境偶现：java.util.concurrent.RejectedExecutionException: Task rejected from pool

【上下文】
- 线程池配置：ThreadPoolExecutor(50, 100, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(1000))
- 触发场景：每天上午9点批量任务启动时
- 当前监控：活跃线程数偶尔飙到100，队列积压

【已排查】
- 确认不是内存问题（堆内存使用<50%）
- 确认任务没有死锁（线程dump正常）

【任务】
1. 分析最可能的3个根本原因
2. 针对每个原因给出验证方法
3. 给出推荐的修复方案（含代码）

场景2：代码生成

【角色】你是一位注重代码质量的Python工程师，习惯写防御式代码。

【任务】实现一个配置加载器，支持YAML和JSON，支持环境变量覆盖。

【约束】
- 必须处理：文件不存在、格式错误、类型不匹配、循环引用
- 必须支持：配置项加密（AES）、热重载
- 使用pydantic进行数据验证

【输出】
1. 核心实现（分多个文件：loader/parser/validator/crypto）
2. 每个函数的复杂度分析（圈复杂度）
3. 单元测试（pytest，覆盖率>90%）

【参考】
类似风格的代码：
```python
def load_config(path: Path) -> AppConfig:
    if not path.exists():
        raise ConfigNotFoundError(f"Config file not found: {path}")
    # ... 省略

**场景3：文档撰写**

【角色】你是一位技术文档工程师，擅长写"能解决问题"的文档而非"正确的废话"。

【任务】为内部RPC框架编写《故障排查手册》

【读者画像】

• 初级后端工程师，熟悉HTTP但不熟悉RPC
• 遇到问题时的典型状态：着急、信息不全、需要快速定位

【内容要求】
每个故障场景包含：

1. 现象描述（用户原话风格）
2. 快速判断（1分钟能做的检查）
3. 根因分析（树状分支，逐步深入）
4. 解决方案（复制即用的命令/配置）
5. 预防措施（如何避免再次发生）

【首批场景】

• 调用超时
• 服务找不到
• 序列化失败
• 负载不均

**场景4：技术方案**

【角色】你是一位在电商领域有10年经验的架构师，经历过多次大促。

【背景】
公司准备做"限时秒杀"活动，预计峰值QPS 10万，库存1000件。

【任务】设计秒杀系统技术方案

【约束】

• 现有系统：Spring Cloud微服务，MySQL主从，Redis集群
• 硬性要求：不能超卖，用户体验流畅（页面不白屏），作弊防控
• 资源限制：新增服务器预算10台以内

【输出结构】

1. 核心挑战分析（3个以内，说透）
2. 架构图（文字描述，Mermaid语法）
3. 关键设计决策（每个决策：选项对比→选择→理由）
4. 风险清单（概率/影响/应对）
5. 分阶段实施计划（MVP→优化→完善）

**场景5：代码Review**

【角色】你是一位严格的代码审查者，关注：安全性、性能、可维护性、符合团队规范。

【代码】

[粘贴代码]

【审查维度】
请按以下优先级检查，每个维度最多3个问题：
P0-安全漏洞（SQL注入、越权、敏感信息泄露等）
P1-性能隐患（N+1查询、大对象、不必要的IO等）
P2-可维护性（命名、复杂度、重复代码等）
P3-规范符合（团队编码规范、注释完整性）

【输出格式】

优先级	位置	问题	建议修改	参考链接

**场景6：学习新技术**

【角色】你是一位擅长技术普及的导师，能用类比和实例让复杂概念变简单。

【目标技术】Rust的所有权系统

【我的背景】

• 5年Java/Python经验，熟悉GC机制
• 没有系统编程经验
• 学习目的：想理解Rust为什么能保证内存安全，以及对我写其他语言有什么启发

【学习路径】
请设计一个"最小必要知识"学习路径，包含：

1. 核心概念（每个配Java/Python的类比）
2. 一个能运行的完整示例（从问题出发，展示所有权如何解决）
3. 3个刻意练习（由浅入深，有答案）
4. 常见误区（Java/Python思维容易犯的错误）

【输出要求】

• 避免一上来就讲生命周期、借用检查器等术语
• 先建立直觉，再引入精确概念

### 小结

场景化的关键是**把通用框架翻译成具体需求**。每个场景都有独特的约束和验收标准，在提示词里明确它们。

---

## 写在最后

咱们今天聊的，表面是"怎么写提示词"，底层是**怎么和AI有效协作**。

编程这么多年，我最大的体会是：技术一直在变，但核心能力不变——**把模糊需求转化为精确指令的能力**。以前这个指令写给编译器，现在写给AI，本质是一样的。

结构化提示词不是什么高不可攀的秘籍，它是一种**思维方式**：先想清楚我要什么、在什么条件下、以什么形式呈现，然后再表达。这种思维方式，放在写代码、写文档、做设计、甚至日常沟通里，都是通用的。

我知道，看完这篇你可能会觉得"以前都白问了"，有点尴尬。但好消息是，**意识到问题就已经解决了一半**。从今天开始，每次打开DeepSeek之前，花30秒想想RTCO，你的输出质量就会不一样。

编程之路不易，但每一步成长都算数。从"随便聊聊"到"精准操控"，你正在跨越的，不只是提示词的门槛，更是**从被动使用工具到主动驾驭工具**的质变。

保持好奇，持续迭代，你也能成为提示工程的高手。毕竟，咱们程序员最擅长的，不就是不断学习新"语法"吗？

加油，下次见！

---

关注私信备注：“资料代找获取”，全网计算机学习资料代找：例如:
《课程：2026 年多模态大模型实战训练营》
《课程：AI 大模型工程师系统课程 (22 章完整版 持续更新)》
《课程：AI 大模型系统实战课第四期 (2026 年开课 持续更新)》
《课程：2026 年 AGI 大模型系统课 23 期》
《课程：2026 年 AGI 大模型系统课 21 期》
《课程：AI 大模型实战课 8 期 (2026 年 2 月最新完结版)》
《课程：AI 大模型系统实战课三期》
《课程：AI 大模型系统课程 (2026 年 2 月开课 持续更新)》
《课程：AI 大模型全阶课程 (2025 年 12 月开课 2026 年 6 月结课)》
《课程：AI 大模型工程师全阶课程 (2025 年 10 月开课 2026 年 4 月结课)》
《课程：2026 年最新大模型 Agent 开发系统课 (持续更新)》
《课程：LLM 多模态视觉大模型系统课》
《课程：大模型 AI 应用开发企业级项目实战课 (2026 年 1 月开课)》
《课程：大模型智能体线上速成班 V2.0》
《课程：Java+AI 大模型智能应用开发全阶课》
《课程：Python+AI 大模型实战视频教程》
《书籍：软件工程 3.0: 大模型驱动的研发新范式.pdf》
《课程：人工智能大模型系统课 (2026 年 1 月底完结版)》
《课程：AI 大模型零基础到商业实战全栈课第五期》
《课程：Vue3.5+Electron + 大模型跨平台 AI 桌面聊天应用实战 (2025)》
《课程：AI 大模型实战训练营 从入门到实战轻松上手》
《课程：2026 年 AI 大模型 RAG 与 Agent 智能体项目实战开发课》
《课程：大模型训练营配套补充资料》