意项
39.91M · 2026-03-23
AI时代提示词（Prompt）是人与大型语言模型（LLM）进行沟通的关键。人们通过提示词与大模型对话，大模型按照提示词进行工作。只有掌握AI提示词方法的人才能更好地驾驭人工智能。
好的提示词能够：
随意的提示词往往导致：
结构化框架通过标准化的要素组合，确保你每次都能：
目前流行的 AI 提示框架有很多种，这里列举常见的 7 种，分别适用于不同的场景：
| 框架 | 核心理念 | 适用场景 | 复杂度 | 学习成本 |
|---|---|---|---|---|
| BROKE | 快速直接 | 代码生成、快速需求 | ⭐ 极简 | 5分钟 |
| CRISPE | 深度分析 | 问题诊断、架构分析 | ⭐⭐ 中等 | 20分钟 |
| ROBOTIC | 完整规划 | 系统设计、长期项目 | ⭐⭐⭐ 复杂 | 30分钟 |
| Chain-of-Thought | 逐步推理 | 算法设计、逻辑验证 | ⭐ 极简 | 2分钟 |
| CO-STAR | 创意输出 | 内容创作、营销文案 | ⭐⭐ 中等 | 15分钟 |
| ICIO | 灵活迭代 | 模糊问题、逐步优化 | ⭐ 极简 | 10分钟 |
| RTF | 角色扮演 | 场景模拟、教学演示 | ⭐ 极简 | 5分钟 |
BROKE是什么：
BROKE 框架的核心作用：
最适合：
不适合：
场景：为 Spring Boot 应用生成登录接口
[Role]
你是一名精通 Spring Boot 3 和 Spring Security 的资深 Java 架构师，有10年的企业级开发经验。
[Background]
项目环境：
- Spring Boot 3.2 + Java 21
- MyBatis-Plus 作为 ORM
- MySQL 8.0 数据库
- 使用 Lombok 简化代码
[Objective]
使用 JWT 实现一个完整的用户认证系统，包括登录接口、token 刷新、权限验证。
[Key Constraints]
- 密码使用 BCrypt 加密
- Token 有效期 24 小时，刷新 token 有效期 7 天
- 返回格式为 Result<T> 统一封装
- 包含全局异常处理
- 遵循阿里编码规范
- 必须使用 @Slf4j 记录关键操作日志
[Examples]
输入：POST /auth/login
{ "username": "user1", "password": "123456" }
输出：
{
"code": 200,
"data": {
"token": "eyJhbGc...",
"refreshToken": "eyJ...",
"expiresIn": 86400,
"user": { "id": 1, "username": "user1", "roles": ["USER"] }
},
"message": "登录成功"
}
预期结果：完整的 LoginController、AuthService、JWT 工具类、实体类和配置
不好的 BROKE Prompt：
[Role]
你是一个 Java 专家
[Background]
我要用 Spring Boot 做一个登录功能
[Objective]
给我生成登录代码
[Key Constraints]
- 要好用
- 要安全
[Examples]
没有示例
问题在于：
结果：AI 会做出很多假设，输出可能不符合需求
CRISPE是什么：
CRISPE 框架的核心作用：
最适合：
不适合：
场景：诊断应用在高并发时响应变慢的原因
[Capacity and Role]
你是一名资深的 Java 性能优化专家，拥有15年互联网服务经验。
你精通：JVM 调优、并发编程、Linux 系统诊断、分布式系统。
你不涉及：数据库 DBA 工作、前端性能优化。
[Request]
请帮我诊断为什么应用在高并发时响应变慢，找出根本原因。
[Insight]
我们的支付系统晚高峰遇到性能问题：
- 通常 P99 响应时间 100ms，高峰期升至 5s
- JVM heap 使用率 60%，没有频繁 GC（MaxGCPauseMillis = 200ms）
- CPU 使用率 50%，还有充足的 CPU 资源
- 数据库查询时间正常（平均 10ms），不是数据库问题
- 日志显示大量 "lock contention" 和 "park" 警告
- 系统使用 Java 21 + ZGC，部署在 32 核机器
[Statement]
在 JVM heap 充足、CPU 充足、数据库正常的情况下，
为什么应用响应仍然变慢？
为什么高峰时性能大幅降低？
最可能的原因是什么？
[Personalization]
我的技术环境：
- Spring Boot 3.2 with Project Reactor（响应式编程）
- Tomcat 线程池：core=200，max=200，queue=1000
- 本地缓存：Caffeine（10000条），二级缓存：Redis
- 依赖服务：支付网关（平均 30ms）、库存服务（平均 20ms）
[Experiment]
请按以下顺序回答：
1. 列出最可能的 3-5 个原因（按概率排序，包括为什么）
2. 每个原因的诊断方法（给出具体的 jstack/jstat 命令）
3. 预期能提升多少性能（百分比）
4. 推荐的解决方案（包含代码示例）
预期结果：详细的分析、诊断命令、优化代码、性能预期
不好的 CRISPE Prompt：
[Capacity and Role]
你是一个专家
[Request]
帮我分析为什么系统慢
[Insight]
系统慢了
[Statement]
怎么优化？
[Personalization]
没有
[Experiment]
给我建议
问题：
结果：只能得到泛泛而谈的通用建议
ROBOTIC是什么：
ROBOTIC 框架的核心作用：
最适合：
不适合：
场景：使用 DDD 设计电商订单系统
[Role]
你是一名资深的 Java 架构师，拥有15年互联网经验。
背景：主导过多个百万级日活电商系统的架构设计
擅长：DDD 领域驱动设计、微服务架构、事件驱动设计
[Objective]
要完成的任务：使用 DDD 设计电商订单服务的聚合根和核心领域模型
最终交付物：
1. 领域模型设计文档（UML 类图 + 文字说明）
2. Java 实现代码（Order 聚合根、DomainEvent）
3. 业务规则文档（订单状态机、金额验证规则）
[Background]
项目背景：
- 电商平台，日均处理 100 万订单
- 订单生命周期：创建 → 支付 → 发货 → 收货 → 完成/售后
- 支持多种支付方式、分次支付、分次发货、退款
- 技术栈：Spring Boot 3.2、Java 21、MongoDB（事件溯源）
[Output]
期望的输出包括：
1. Mermaid 格式的 UML 类图
2. Java Record/Class 实现（Java 21 特性，无 setter）
3. 领域事件定义（OrderCreated、OrderPaid、OrderShipped 等）
4. 业务规则说明文档
[Type]
这是一个架构设计任务，需要：
- 深度的领域知识建模
- 严谨的业务规则定义
- 考虑并发和一致性问题
[Iterate]
反馈流程：
- 第1轮：核心聚合根和基本状态机
- 第2轮：支付分次、发货分次的完整设计
- 第3轮：并发控制、事件一致性、性能优化
[Clarify]
在开始前，需要澄清：
1. 订单是否需要支持拆单（1个逻辑订单拆成多个物流订单）？
2. 退款是否只支持原路返回，还是可以退到其他账户？
3. 是否使用完整事件溯源，还是快照+事件混合方案？
预期结果：经过 3 轮迭代的完整架构方案
不好的 ROBOTIC Prompt：
[Role]
你是架构师
[Objective]
设计订单系统
[Background]
电商系统
[Output]
代码
[Type]
设计
[Iterate]
多轮反馈
[Clarify]
没有问题
问题：
Chain-of-Thought（CoT）是什么 ：
要求 AI 一步步展示推理过程，而不是直接给答案。这是一个增强框架，可以与其他框架组合使用。
Chain-of-Thought 的核心作用：
最适合：
不适合：
场景：分析并优化低效的数据库查询代码
你是一名资深的数据库性能优化专家。
问题：为什么以下代码在处理 100 万条数据时很慢？应该怎么优化？
代码：
List<User> users = database.queryAllUsers(); // 100 万条
List<String> activeEmails = new ArrayList<>();
for (User user : users) {
if (user.isActive() && user.getEmail() != null) {
activeEmails.add(user.getEmail());
}
}
要求：请按以下步骤一步步分析和回答：
1. 分析问题：识别代码中的性能瓶颈
2. 评估成本：计算当前方案的时间复杂度和内存成本
3. 列举方案：提出 2-3 个不同的优化方案
4. 对比方案：对比各方案的优缺点
5. 推荐方案：给出最优方案和实现代码
6. 性能预期：预测优化后的性能提升（百分比）
最后给出总结答案。
预期结果：
不好的 Chain-of-Thought 使用：
简单问题：什么是 getter 方法？
要求：请一步步思考，展示完整的推理过程。
问题：
CO-STAR是什么：
CO-STAR 框架的核心作用：
最适合：
不适合：
场景：为新产品发布创作社交媒体文案
[Context]
我们开发了一款新的开源 Java 框架 "FastAPI"，
用于快速构建高性能的 REST API。
核心优势：配置简洁、启动快（500ms）、学习曲线平缓。
竞争对手：Spring Boot（功能全但配置复杂）。
[Objective]
吸引年轻的 Java 开发者尝试使用，获得 GitHub Star 增长。
期望效果：推文转赞数 > 50、分享数 > 20。
[Style]
参考 TensorFlow、Vue.js 等开源项目的文案风格。
特点：简洁有力、强调优势而不贬低竞争对手、包含代码示例。
[Tone]
整体基调：友好、热情、充满信心。
避免：过度吹嘘、复杂术语、枯燥乏味。
[Audience]
目标人群：Java 开发者，1-10 年经验。
他们关心：开发效率、代码简洁度、学习成本。
痛点：Spring Boot 配置复杂、框架学习时间长。
[Response Format]
输出 3 个版本：
1. Twitter 文案（280 字以内，包含 #hashtag）
2. 技术博客摘要（200-300 字，突出核心优势）
3. GitHub README 的"为什么选择 FastAPI"部分（500 字）
预期结果：有吸引力的社交媒体文案、博客摘要、GitHub 文案
不好的 CO-STAR Prompt：
[Context]
新产品 FastAPI
[Objective]
写文案
[Style]
好看
[Tone]
好
[Audience]
开发者
[Response Format]
文案
问题：
ICIO是什么：
ICIO 框架的核心作用：
最适合：
不适合：
场景：设计一个用户查询 API，需要逐步优化
[Init]
初始化问题：
设计一个查询用户列表的 REST API
初步想法：GET /users 返回所有用户
[Clarify - 第1轮]
我需要澄清以下信息：
1. 用户量有多大？是否需要分页？
2. 是否需要筛选功能（按状态、部门、权限等）？
3. 不同的客户端需要不同的字段吗？
4. 性能要求是什么（P99 延迟目标）？
5. 并发量估计是多少（QPS）？
基于你的回答，我会给出改进的 API 设计。
---
假设你的回答：
- 用户量 100 万，需要分页
- 需要按部门、状态筛选
- 不同客户端需要不同字段
- 性能要求 P99 < 200ms
[Iterate - 第2轮]
基于你的需求，我改进的方案：
1. 添加分页参数：page, pageSize
2. 添加筛选参数：department, status
3. 添加字段选择：fields 参数或使用 GraphQL
现在的问题是：
- 字段选择用 fields 参数还是 GraphQL？为什么？
[Iterate - 第3轮]
基于你的选择，最终方案包括：
1. 完整的 API 设计（路径、参数、响应）
2. 缓存策略建议
3. 数据库索引建议
预期结果：经过多轮迭代的最优 API 设计
不好的 ICIO Prompt：
[Init]
帮我设计 API
[Clarify]
（没有具体问题）
[Iterate]
（不提供反馈）
[Outcome]
给我最终方案
问题：
RTF是什么：
RTF 框架的核心作用：
最适合：
不适合：
场景：模拟 Google 的技术面试
[Role]
你是 Google 的一名资深技术面试官
背景：10年的面试经验，面试过 500+ 候选人
特点：友好但严格，会根据回答深层挖掘，启发式提问
专长：算法能力、系统设计、编程实践
[Task]
为我进行一场模拟的算法面试
难度：Medium（LeetCode 难度）
时长：45 分钟
期望的考察点：数据结构、时间复杂度分析、代码质量
[Format]
请按以下流程进行：
1. 提出一个算法问题，给出完整的问题描述
2. 听我的思路和实现方案，给出反馈
3. 如果我卡住，给出提示而不是直接答案
4. 让我写出代码（伪代码或真实代码都可以）
5. 审查代码的质量（命名、逻辑、边界情况）
6. 讨论时间和空间复杂度
7. 最后给出综合评价和改进建议
预期结果：逼真的面试体验
不好的 RTF Prompt：
[Role]
面试官
[Task]
面试
[Format]
对话
问题：
| 维度 | BROKE | CRISPE | ROBOTIC | CoT | CO-STAR | ICIO | RTF |
|---|---|---|---|---|---|---|---|
| 学习成本 | ⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐ | ⭐⭐ | ⭐ | ⭐ |
| 要素数 | 5 | 6 | 7 | 1 | 6 | 4 | 3 |
| 适合代码生成 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐ | ⭐⭐⭐ | ⭐⭐⭐ |
| 适合内容创作 | ⭐⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐ | |
| 适合架构设计 | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | |
| 迭代友好度 | ⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ |
| 一次成功率 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ |
| 完成时间 | 快 | 中 | 慢 | 快 | 中 | 慢 | 快 |
| 适合团队协作 | 弱 | 中 | 强 | 弱 | 中 | 强 | 中 |
问题类型？
├─ 代码生成
│ ├─ 需求明确? → BROKE (推荐) / RTF
│ └─ 需要多轮评审? → ROBOTIC
│
├─ 内容创作
│ ├─ 需要风格可控? → CO-STAR (推荐)
│ └─ 需要逐步优化? → ICIO / CO-STAR
│
├─ 问题分析
│ ├─ 需要深度理解? → CRISPE (推荐)
│ └─ 需要逐步诊断? → ICIO
│
├─ 架构设计
│ ├─ 需要多轮评审? → ROBOTIC (推荐)
│ ├─ 需要快速迭代? → ICIO
│ └─ 需要深度分析? → CRISPE + ROBOTIC
│
├─ 逻辑推理
│ └─ 需要显示过程? → Chain-of-Thought (推荐)
│
└─ 角色扮演
└─ RTF (推荐)
不同框架可以组合使用，产生更强大的效果：
1. BROKE + Chain-of-Thought
2. CRISPE + Chain-of-Thought
3. ROBOTIC + ICIO
4. CO-STAR + Chain-of-Thought
5. RTF + BROKE
场景：正在构建一个微服务架构，需要为所有服务快速实现健康检查端点。
选择框架：BROKE
提示词：
[Role]
你是一名精通 Spring Boot 3 和微服务架构的资深 Java 架构师，拥有12年企业级开发经验。
[Background]
项目环境：
- Spring Boot 3.2 + Java 21
- 使用 Spring Cloud 和 Consul 作为服务注册中心
- 需要集成 Micrometer 进行性能监控
- 部署在 Kubernetes 上，容器健康检查依赖此端点
[Objective]
实现一个标准的微服务健康检查接口，支持 Consul 健康检查和 Kubernetes 就绪/存活探针。
[Key Constraints]
- 应该实现 Spring 的 HealthIndicator 接口
- 检查项包括：数据库连接、Redis 连接、依赖服务可用性
- 响应格式必须符合 Spring Boot 规范
- 健康检查接口应该轻量级，响应时间 < 100ms
- 在服务启动时应该将状态设置为 STARTING（30 秒内升为 UP）
- 详细日志记录每个检查项的结果
[Examples]
输入：GET /actuator/health
输出示例：
{
"status": "UP",
"components": {
"db": { "status": "UP", "details": { "database": "MySQL" } },
"redis": { "status": "UP", "details": { "version": "7.0" } },
"paymentService": { "status": "UP", "details": { "responseTime": "25ms" } }
},
"timestamp": "2024-03-07T10:00:00Z"
}
预期输出：完整的 HealthIndicator 实现、配置类、测试用例
场景：订单系统在并发场景下出现数据不一致，需要诊断根本原因。
选择框架：CRISPE + Chain-of-Thought
提示词：
[Capacity and Role]
你是一名资深的分布式系统专家，拥有15年互联网服务经验。
你精通：分布式事务、消息队列、数据一致性模式、并发控制。
[Request]
请帮我诊断为什么订单系统在高并发时会出现数据不一致，找出根本原因和解决方案。
[Insight]
我们遇到的问题：
- 用户下单时，订单表显示"已支付"，但库存表仍显示未扣减
- 这导致同一件商品被多个用户购买，超过库存
- 问题发生在高峰期（QPS > 1000），日常正常
- 我们使用了本地事务 @Transactional，但跨服务调用没有使用分布式事务
- 系统架构：OrderService → PaymentService → InventoryService
- 目前使用同步 RPC 调用（没有重试机制）
[Statement]
核心问题：在什么样的并发场景下会发生这个问题？根本原因是什么？
[Personalization]
我的技术环境：
- Spring Boot 3.2，MySQL 8.0
- 支付服务调用时间：50-200ms（不稳定）
- 库存扣减是同步调用，没有熔断器
- 未使用消息队列或 Saga 模式
- 团队有 8 人，微服务经验 2 年
[Experiment]
请按以下顺序分析：
1. **第一步**：画出并发场景下的时序图，解释问题是如何发生的
2. **第二步**：分析当前架构的缺陷（同步调用、缺乏隔离等）
3. **第三步**：列出 3-5 个可能的解决方案（优先级排序）
4. **第四步**：针对我的团队规模和经验，推荐最佳方案和实施计划
5. **第五步**：给出改进后的伪代码，展示如何处理各种失败场景
最后，请用一句话总结根本原因。
预期输出：时序图、问题分析、3 个解决方案、推荐方案、改进代码
场景：公司从单体应用迁移到微服务架构，需要完整的架构设计和迁移计划。
选择框架：ROBOTIC + ICIO
提示词第一阶段（ROBOTIC 初稿）：
[Role]
你是一名资深的技术主管和微服务架构师
背景：成功主导过 3 个大型系统从单体到微服务的重构
擅长：微服务拆分策略、分布式事务、团队协调、风险管理
[Objective]
要完成的任务：为现有单体应用制定完整的微服务架构设计和迁移方案
最终交付物：
1. 架构演进路线图（分阶段、时间表）
2. 微服务拆分设计（服务边界、数据模型、通信方式）
3. 实施计划和风险评估
[Background]
项目背景：
- 现有单体 Java 应用，代码量 80 万行，运行 8 年
- 日均处理 5000 万请求，P99 响应时间 300ms
- 核心模块：订单、支付、库存、物流、售后
- 技术栈：Java 8 + Spring MVC + MySQL，单机部署
- 团队规模：30 人（后端 15 人）
- 迁移预期：6-12 个月，不能停服
[Output]
期望的输出包括：
1. 微服务拆分方案（包含 Mermaid 架构图）
2. 服务通信设计（同步/异步、协议选择）
3. 数据一致性方案（分布式事务、Saga 等）
4. 阶段性迁移计划（每阶段的交付物和测试计划）
5. 风险评估和应对措施
[Type]
这是一个战略性的架构设计和规划任务，需要平衡：
- 技术理想 vs 现实约束
- 一次性迁移 vs 渐进式迁移
- 团队能力 vs 技术复杂度
[Iterate]
反馈流程：
- 第1轮：初步的微服务拆分方案和总体时间规划
- 第2轮：基于团队反馈优化拆分边界和通信方式
- 第3轮：细化每个阶段的具体实施步骤和风险应对
[Clarify]
在开始前，需要澄清：
1. 团队中有多少人有微服务经验？是否需要技能升级？
2. 对新技术（如 Kafka、gRPC）的接受度？
3. 数据一致性的要求（强一致 vs 最终一致）？
4. 是否有现成的 DevOps 基础设施（Docker、K8s）？
5. 迁移中关键的业务约束是什么（SLA、停机窗口等）？
第一轮输出后的迭代（ICIO 风格）：
用户反馈："我们的团队主要是单体架构经验，对微服务不太熟。同时，我们已有 K8s 基础设施，但 Kafka 经验不足。数据一致性需要支持最终一致即可。"
[Iterate - 第2轮]
基于你的反馈，我调整的方案：
1. 优先选择相对简单的服务拆分（先拆 3-4 个核心服务）
2. 通信方式建议：优先用同步 RPC（Spring Cloud + Feign），阶段 2 再引入消息队列
3. 分布式事务采用 Saga 模式，但先用编程方式实现，后期再考虑框架
4. 在第 1 阶段安排 2 周的团队培训（微服务基础、Feign、分布式事务）
现在的问题是：
- 在这个约束下，你认为哪 3-4 个服务应该优先拆分？
预期结果：经过 2-3 轮迭代的完整迁移方案
所有框架的详细文档和示例代码可以在以下位置找到：
具体而非笼统
完整而非片段
清晰而非模糊
有示例而非没有
可验证而非虚无
当单一框架无法满足需求时，考虑组合：
最后：
选择合适的提示词框架，就像选择合适的开发工具。好的工具能大大提升效率。利用AI编程最重要的是把需求描述清楚，把业务需求转换为明确的技术需求，并告知AI你要什么——明确表达需求、提供完整信息、清晰的约束条件。掌握这些框架，你就能与 AI 进行更高效的协作。
github.com/microwind/a…
