第1729篇：结构化提示词框架对比——CO-STAR、BROKE、RISEN哪个更适合Java工程师

前几年Prompt Engineering这个词刚热起来的时候，社区里涌现出了大量"框架"。什么CRISP、CARER、TRACE……各种缩写框架眼花缭乱，看得人头晕。

其中有三个框架确实有比较广泛的讨论：CO-STAR、BROKE和RISEN。今天把这三个认真对比一遍，主要站在Java工程师的视角——我们不是写营销文案，我们要解决的是系统设计、代码实现、技术决策这类问题。

---

先搞清楚为什么需要框架

很多人一上来就问：我该用哪个框架？这个问题本身就有问题。

结构化框架的价值不在于"神奇地让Prompt变好"，而在于强制检查表。就像写代码前列需求清单，框架帮你在写Prompt之前想清楚：

• 这个任务的背景是什么？
• 对象是谁（模型需要知道什么上下文）？
• 期望的输出形式是什么？
• 有哪些约束条件？

如果你不用框架，很多时候这些问题根本没想清楚就开始写Prompt了，然后发现效果不对，但不知道哪里出了问题。

框架的价值是：让你的Prompt设计过程系统化，让问题暴露得更早。

---

CO-STAR框架详解

CO-STAR出自新加坡政府科技局的一位工程师，是目前知名度最高的结构化Prompt框架之一。

六个要素：

• Context（背景）：提供任务的背景信息
• Objective（目标）：明确说明希望AI完成什么任务
• Style（风格）：指定回答的写作或表达风格
• Tone（语气）：设定回应的情感基调
• Audience（受众）：明确回答是给谁看的
• Response（响应格式）：指定输出的结构和格式

// CO-STAR框架在Java项目中的应用示例
public class CoStarPromptBuilder {
    
    public String buildCodeReviewPrompt(CodeReviewContext context) {
        return """
            [Context（背景）]
            这是一个金融交易系统的核心支付处理模块，运行在生产环境，处理高并发场景，
            每天处理约50万笔交易。系统使用Spring Boot 3.x + MySQL + Redis。
            
            [Objective（目标）]
            对以下Java代码进行深度代码审查，重点关注：
            1. 线程安全问题
            2. 事务边界的正确性
            3. 异常处理的完整性
            4. 性能瓶颈
            
            [Style（风格）]
            使用工程师对工程师的沟通方式，直接指出问题，给出具体的改进代码示例，
            不需要过多解释基础概念。
            
            [Tone（语气）]
            专业严谨，发现严重问题直接说严重，不要为了礼貌而淡化问题的严重性。
            
            [Audience（受众）]
            这份审查报告给高级Java工程师看，对方熟悉JVM、并发、Spring事务机制。
            
            [Response（响应格式）]
            按以下格式输出：
            ## 严重问题（必须修复）
            ## 中等问题（建议修复）
            ## 轻微问题（可选优化）
            ## 整体评价
            
            每个问题包含：问题描述、代码位置、修复建议、修复后代码示例。
            
            待审查代码：
            %s
            """.formatted(context.getCode());
    }
}

CO-STAR的优点是完整性。六个要素基本覆盖了一个Prompt需要考虑的所有维度。

缺点是有些要素对技术场景的适用性有限。Style和Tone这两个要素在写营销文案时非常重要，但在代码审查、架构设计这类技术场景里，往往几句话就能说清楚，过度强调这两个维度反而显得繁琐。

---

BROKE框架详解

BROKE是一个相对小众但在技术圈里颇受欢迎的框架。

五个要素：

• Background（背景）：任务的背景和上下文
• Role（角色）：AI应该扮演的角色
• Objective（目标）：要完成什么任务
• Key Results（关键结果）：明确成功的标准
• Evolution（迭代）：允许根据反馈迭代改进的机制

BROKE和CO-STAR最大的区别在于K（关键结果）和E（迭代）这两个要素。

关键结果要素强制你在写Prompt时就想清楚"什么样的输出算是成功"，这对技术任务来说非常有价值。

迭代要素更有意思——它在提示词里就预留了"如果不对，我会怎么反馈，你应该怎么迭代"的机制：

public String buildArchitectureDesignPrompt(ArchitectureContext context) {
    return """
        [Background（背景）]
        我们是一个日活100万的电商平台，现在的单体架构开始出现性能瓶颈。
        主要问题：商品搜索和大促时的秒杀活动影响了整体系统稳定性。
        技术栈：Java 17, Spring Boot, MySQL, 目前没有消息队列，没有独立缓存服务。
        团队规模：20人，其中后端工程师12人，都是Java背景。
        
        [Role（角色）]
        你是一位有10年以上经验的分布式系统架构师，曾主导过多个百万级日活系统的架构演进。
        你擅长务实的架构设计，注重团队现有能力边界，不追求过度技术化的方案。
        
        [Objective（目标）]
        设计一个从单体向微服务的渐进式演进方案，解决搜索和秒杀的性能问题，
        同时不破坏现有业务的稳定性，且在我们的团队能力范围内可以落地。
        
        [Key Results（关键结果）]
        成功的方案应该满足以下标准：
        - 搜索接口P99延迟降低到500ms以内（当前约2s）
        - 大促时秒杀活动不影响正常购物流程
        - 演进分阶段可实施，每个阶段独立可回滚
        - 不需要引入太多团队不熟悉的技术栈
        - 给出第一阶段（3个月内）的具体实施计划
        
        [Evolution（迭代）]
        如果我觉得某个方案对我们团队来说技术复杂度过高，我会告诉你"太复杂了"，
        请根据这个反馈调整方案，给出更简单的替代选项，并说明简化的代价。
        如果我觉得某个部分还不够详细，我会说"展开讲讲[X]"，请针对性地深化。
        """;
}

BROKE的K要素是它最大的亮点。写Key Results的过程，实际上是逼你把"我要什么"转化成可验证的标准。这在工程里非常重要——一个好的需求，必须是可验证的。

缺点是BROKE没有CO-STAR那么系统，Format/Response要素的缺失，在需要结构化输出的场景里会显得不够。

---

RISEN框架详解

RISEN相对来说更年轻，在生成式AI场景下被专门设计出来。

五个要素：

• Role（角色）：清晰定义AI的角色和专业背景
• Instructions（指令）：详细的任务指令
• Steps（步骤）：如果是复杂任务，分解执行步骤
• End Goal（最终目标）：期望达到的最终结果
• Narrowin（缩小范围）：通过约束条件缩小解答范围

RISEN的独特之处在于Steps要素。很多框架只关注"要做什么"，RISEN要求你显式定义执行步骤，这本质上是在提示词里内嵌了Chain-of-Thought的结构。

public String buildComplexDebuggingPrompt(BugContext context) {
    return """
        [Role（角色）]
        你是一位专精JVM和并发问题的Java专家，对Java内存模型、垃圾回收机制、
        线程调度有深入理解，有丰富的线上问题诊断经验。
        
        [Instructions（指令）]
        分析以下线上故障，找出根本原因，并给出解决方案。
        
        故障现象：
        %s
        
        相关堆栈信息：
        %s
        
        相关代码片段：
        %s
        
        [Steps（步骤）]
        请按以下步骤分析：
        
        Step 1: 初步判断故障类型
        根据错误信息和堆栈，初步判断这是内存问题、并发问题、还是业务逻辑问题？
        
        Step 2: 关键线索提取
        从堆栈中找出最关键的3-5个线索，解释每个线索说明了什么。
        
        Step 3: 根因分析
        基于上述线索，推断出最可能的根本原因，并解释推断逻辑。
        如果有多种可能，列出所有可能性并排序（最可能的在前）。
        
        Step 4: 验证方案
        给出验证这个根因的具体操作步骤，如何在不影响生产的情况下收集更多证据。
        
        Step 5: 修复方案
        给出修复方案（包括临时方案和永久方案），以及实施风险评估。
        
        [End Goal（最终目标）]
        给出一份可以直接交给开发团队执行的故障分析报告，内容包括：
        根本原因、影响评估、修复步骤、预防措施。
        
        [Narrowing（缩小范围）]
        - 我们的Java版本是17，不考虑更老版本的特有问题
        - 这是生产环境，修复方案要优先考虑安全性，其次才是彻底性
        - 我们使用G1 GC，不使用CMS
        """.formatted(context.getErrorMessage(), context.getStackTrace(), context.getCodeSnippet());
}

RISEN的Steps要素对复杂推理任务效果非常好。当你需要模型做多步分析时，显式地把步骤写出来，往往比"帮我分析一下"得到更系统、更有逻辑的回答。

---

三框架横向对比

用一个更直观的表格：

对比维度	CO-STAR	BROKE	RISEN
适合的任务类型	创意/内容生成为主	技术决策/架构设计	复杂分析/多步推理
成功标准的定义	弱（无对应要素）	强（Key Results）	中（End Goal）
迭代机制	无	有（Evolution）	无
推理步骤控制	无	无	有（Steps）
学习曲线	低	低	中
输出格式控制	强（Response）	弱	中

---

哪个更适合Java工程师？

直接说结论：BROKE + RISEN的混合用法，是Java工程师最合适的选择。

具体来说：

做技术决策、架构评审、需求分析时：用BROKE的结构，重点是把Key Results写清楚。这强制你在开始前就定义清楚"什么叫成功"，这是工程思维的核心。

做复杂技术分析、代码调试、原理解析时：用RISEN的结构，重点是把Steps写清楚。这让模型的推理过程可追踪，便于你找出哪一步的推理出了问题。

写代码、生成文档、规范格式的输出时：在BROKE或RISEN的基础上，借鉴CO-STAR的Response要素，明确输出格式。

---

实战：组合框架写一个系统级Prompt

// 混合框架：BROKE + RISEN + CO-STAR(Response) 
// 用于数据库性能优化场景
public class DatabaseOptimizationPromptBuilder {
    
    public String build(SlowQueryContext context) {
        return """
            [Background + Role]
            你是一位专精MySQL性能调优的DBA顾问，拥有8年以上大规模数据库优化经验。
            当前系统：MySQL 8.0，数据量：订单表3亿行，用户表5000万行，
            日均查询量约800万次，读写比约8:2。
            
            [Objective]
            分析提供的慢查询SQL，给出完整的优化方案。
            
            [Steps]
            请按以下步骤分析：
            
            Step 1: SQL语义分析
            理解这个SQL在做什么业务操作，预期返回什么样的数据。
            
            Step 2: 执行计划解读
            分析EXPLAIN的输出，指出关键问题点（全表扫描、Using filesort等）。
            
            Step 3: 索引优化
            判断是否需要新增、修改或删除索引，给出具体的DDL语句。
            
            Step 4: SQL重写
            如果SQL本身可以优化（减少子查询、改写JOIN顺序等），给出优化后的SQL。
            
            Step 5: 风险评估
            评估每个优化操作的实施风险，特别是对生产数据库加索引的影响。
            
            [Key Results]
            优化方案应达到：
            - 慢查询执行时间从当前降低80%以上
            - 不影响现有的查询正确性
            - 加索引的操作有在线执行方案（不锁表）
            
            [Narrowing]
            - 只针对MySQL 8.0优化，不考虑其他数据库
            - 当前不考虑分库分表，只考虑单库内的优化
            - 不引入查询缓存（我们已经用了Redis缓存层）
            
            [Response Format]
            ## 问题诊断
            ## 优化方案
            ### 方案1：索引优化（推荐）
            - 涉及风险：
            - 具体操作：
            - 预期效果：
            ### 方案2：SQL重写（如适用）
            ## 线上执行方案
            ## 效果验证步骤
            
            慢查询信息：
            SQL: %s
            执行时间: %s ms
            EXPLAIN结果: %s
            """.formatted(context.getSql(), context.getExecutionTime(), context.getExplainResult());
    }
}

---

我的最终观点

说实话，使用框架最大的价值不是"按框架填就能得到好Prompt"，而是在你还没养成提示词工程直觉之前，框架帮你检查有没有遗漏关键要素。

当你写了足够多的Prompt，这些框架要素会内化成本能，你不再需要对着框架逐条填写，而是自然地在脑子里把这些要素过一遍。

在这之前，BROKE适合作为技术场景的入门框架，因为它的Key Results要素最贴近工程师的思维习惯。RISEN适合复杂分析场景，CO-STAR适合需要严格格式控制的场景。

选一个开始用，用一段时间你就知道哪个适合你了。