Prompt 框架：CRISPE

CRISPE 框架概述

CRISPE 是一个强调个性化和深度洞察的 Prompt 框架，特别适合复杂问题分析和创意输出场景。框架名称由五个核心要素组成：

• Capacity and Role（能力和角色）
• Request（请求）
• Insight（洞察）
• Statement（声明）
• Personalization（个性化）
• Experiment（实验）

CRISPE 框架强调理解问题的深层背景和针对性的个性化解决方案。

特点

CRISPE 的优势

✅ 深度洞察 - 强调问题的"为什么"而非"是什么" ✅ 个性化强 - 明确考虑用户的特定需求和背景 ✅ 思考充分 - 不仅要求答案，更强调思考过程 ✅ 适应复杂 - 能处理有歧义或需要创意的问题 ✅ 学习友好 - AI 会解释推理过程，便于学习

CRISPE 的局限

❌ 相对冗长 - 比 BROKE 需要更多的输入 ❌ 不适合快速编码 - 强调思考，不追求速度 ❌ 可能过度分析 - 简单问题用 CRISPE 可能显得繁琐

模板

[Capacity and Role]
你是一名 [职位]，擅长 [能力1]、[能力2]。
你精通 [相关领域]，但不涉及 [边界范围外的领域]。

[Request]
我想请你帮助我 [具体的请求]。

[Insight]
背景和洞察：
- [为什么提出这个问题]
- [当前遇到的具体问题]
- [已有的尝试和结果]
- [关键的约束条件]

[Statement]
基于以上背景，我的核心问题是：[明确的问题陈述]。

[Personalization]
针对我的具体情况：
- [我使用的工具/框架]
- [我的技能水平]
- [我的时间/资源约束]

[Experiment]
请按以下方式回答：
1. [第一部分期望的回答方式]
2. [第二部分期望的回答方式]
3. [验证或进一步改进]

相关框架比较

何时选择 CRISPE？

✅ 问题相对复杂或有多个变量 ✅ 需要 AI 分析思路和推理过程 ✅ 你想深入理解问题的根本原因 ✅ 需要针对你的具体情况定制方案 ✅ 创意输出或探索性问题

应用实践

实践1：生产环境性能问题分析

问题描述：应用响应变慢，需要诊断根本原因

[Capacity and Role]
你是一名资深的 Java 性能优化专家，拥有10年互联网服务经验。
你精通：JVM调优、并发编程、Linux系统诊断。
你不涉及：数据库DBA工作、前端性能。

[Request]
请帮我分析为什么应用在高并发时响应变慢。

[Insight]
我们的支付系统在晚高峰遇到问题：
- 通常 P99 响应时间 100ms，高峰期 5s
- JVM heap 使用率 60%，无明显GC暂停
- CPU 使用率 50%，还有空闲
- 数据库查询时间正常（不是数据库问题）
- 日志显示大量 "lock contention" 警告
- 系统使用 Java 17 + ZGC

[Statement]
我的核心问题：在 JVM heap 充足、CPU 充足、数据库正常的情况下，
为什么应用响应仍然变慢？

[Personalization]
我的环境：
- 使用 Spring Boot 3.2 with Project Reactor
- 线程池大小 200，队列长度 1000
- 使用 Caffeine 本地缓存（10000条）
- 二级缓存使用 Redis

[Experiment]
请按以下顺序回答：
1. 列出最可能的3个原因（按概率排序）
2. 每个原因的诊断方法（给出具体的命令/代码）
3. 针对我的技术栈，推荐的解决方案
4. 预期能提升多少性能

预期输出：详细的分析、诊断命令、优化代码示例

实践2：API 设计决策

问题描述：不确定 API 的设计方案是否合理

[Capacity and Role]
你是一名资深的 API 设计师和系统架构师，
擅长 RESTful 设计、微服务架构和向后兼容性设计。

[Request]
请评审我的 API 设计方案，并给出改进建议。

[Insight]
我需要设计一个订单查询 API，考虑的因素：
- 订单数据量大（日均100万），需要支持分页和筛选
- 多个业务方会调用这个 API，需要考虑向后兼容
- 需要支持订单状态实时更新（延迟 < 1s）
- 现有系统使用微服务架构，数据在多个服务中

[Statement]
我设计的方案是返回完整订单信息（100+ 字段）。
但我担心：
1. 响应体太大，性能会不会有问题？
2. 将来添加新字段时，会不会破坏现有客户端？

[Personalization]
我的约束条件：
- 需要兼容既有的 3 个调用方
- 有 1 个月的时间准备新 API
- 不想做大规模重构

[Experiment]
请回答：
1. 评价我的方案优缺点
2. 给出 2-3 个替代方案
3. 推荐哪一个，为什么
4. 如何平稳迁移到新方案

预期输出：方案对比、具体的 API 设计代码、迁移计划

实践3：编码规范制定

问题描述：需要为团队制定 Java 编码规范

[Capacity and Role]
你是一名资深的技术主管，负责指导团队编码规范。
你擅长：Java 最佳实践、团队协作、代码质量。

[Request]
帮我为10人的 Java 团队制定编码规范。

[Insight]
当前团队的问题：
- 代码风格不一致，PR审查时间长
- 经常为"用Lombok还是手写getter"这样的细节争议
- 没有统一的异常处理方案，导致错误处理混乱
- 新人加入时没有明确的编码标准可参考

[Statement]
我需要一份简洁但有约束力的编码规范，
能够提高团队代码一致性，减少 PR 审查时间。

[Personalization]
我们的技术栈：
- Spring Boot 3.2
- Java 21
- MyBatis-Plus
- 约 50万行代码的项目

[Experiment]
请提供：
1. 10条最重要的编码规范
2. 每条规范的代码示例（正确 vs 错误）
3. 如何通过自动化工具（如 checkstyle）执行
4. 如何融入 CI/CD 流程

预期输出：编码规范文档、示例代码、工具配置

CRISPE 框架最佳实践

✅ 做这些事

1. 详细的 Insight

   • 不仅说问题，更说"为什么"问题存在
   • 包含已有的尝试和结果

2. 明确的 Personalization

   • 告诉 AI 你的约束条件
   • 包含技能水平、时间成本

3. 清晰的 Experiment

   • 指定 AI 如何组织回答
   • 要求中间步骤和推理过程

4. 开放的心态

   • 接受可能不同的观点
   • 追问为什么

❌ 避免这些事

1. 只问结果不问原因

   • ❌ "帮我优化这个SQL"
   • ✅ "分析为什么这个SQL慢，然后优化"

2. 隐瞒真实背景

   • ❌ "我遇到问题"
   • ✅ "我在高并发场景遇到此问题..."

3. 过度简化问题

   • ❌ "能否改进这个设计？"
   • ✅ "这个设计的瓶颈在哪，如何突破？"

4. 不给约束条件

   • ❌ 问方案而不说团队水平、时间预算

常见问题

Q: CRISPE 和 Chain-of-Thought 有什么区别？

A: CRISPE 强调背景洞察和个性化，Chain-of-Thought 强调逐步推理过程。可以组合使用。

Q: 什么时候用 CRISPE 而不用 BROKE？

A: 当问题复杂、需要分析思路时用 CRISPE；当问题明确、只需直接代码时用 BROKE。

Q: 如何确保 AI 给出的分析是正确的？

A: 要求 AI 给出推理过程，自己评估逻辑是否合理。必要时追问。

进一步阅读

• 📚 CRISPE 框架深度指南
• 🎯 框架对比与选择
• 💡 Prompt 工程完全指南