SpringAI Prompt提示词

基本概念

Prompts提示词

❝

提示词的是引导AI模型输出的输入，提示词的正确性直接影响模型输出的。

Message消息

Message 接口封装了 Prompt 文本内容、一组元数据属性以及称为 MessageType 的分类。Spring AI消息API：

其中最重要的就是角色：

• System Role: 系统角色

• User Role:  用户角色

• Assistant Role: 辅助角色

• Tool/Function Role:工具/函数角色：工具/函数角色专注于在响应工具调用助手消息时返回额外信息。

PromptTemplate提示词模板

❝

Spring AI 中用于提示模板的关键组件是 PromptTemplate 类，该类旨在简化结构化提示的创建，然后将其发送到 AI 模型进行处理。

eg:

PromptTemplate promptTemplate = new PromptTemplate("Tell me a {adjective} joke about {topic}");

Prompt prompt = promptTemplate.create(Map.of("adjective", adjective, "topic", topic));

return chatModel.call(prompt).getResult();

创建有效的提示

未定义角色的测试

定义模型角色

@Configuration
public class CustomAIConfig {
    @Bean
    public ChatClient chatClient(ChatClient.Builder builder) {
        return builder.defaultSystem("你是资深的Java架构师，你精通Java开发，Spring全家桶" +
                "你的名字JavaBoy。你需要专业的回答用户提出的java方面的问题！").build();
    }
}

具体问题：

提示词模板

❝

推荐一个比较常用的提示词模板

• 角色+任务+输出：

系统角色： AI是一个资深Java架构师，精通Java技术.

用户角色：我是一名刚入门Java的开发工程师.任务或者请求：加锁和加事务的先后顺序和不同顺序可能会产生的影响。

输出： 输出一个实际开发加锁和加事务的例子说明影响

❝

加锁与事务的基本概念 1. 锁(Lock): 用于控制对共享资源的并发访问 2. 事务(Transaction): 保证一组操作要么全部成功，要么全部失败 ## 顺序影响分析

情况1：先加锁后加事务

// 伪代码示例 
lock.lock(); 
// 先获取锁 
try { @Transactional 
// 后开启事务 
public void method() { 
// 业务逻辑 } } 
finally {
lock.unlock(); 
}

问题: - 锁的范围大于事务范围 - 事务提交前锁可能已经释放，导致其他线程看到中间状态 - 可能导致死锁，因为事务持有锁的时间过长

情况2：先加事务后加锁

// 伪代码示例 
@Transactional 
// 先开启事务 
public void method() { 
lock.lock(); 
// 后获取锁 try { 
// 业务逻辑 
} finally {
lock.unlock(); 
} 
}

优点: - 锁的范围在事务范围内 - 事务提交前锁不会释放，保证一致性 - 更符合ACID原则 ## 实际开发示例 假设我们有一个银行转账场景：

@Service 
publicclass BankService {
privatefinal Map accounts = new ConcurrentHashMap<>(); 
privatefinal ReentrantLock transferLock = new ReentrantLock();
// 正确的做法：事务内加锁 
@Transactional
public void transferMoney(String fromId, String toId, BigDecimal amount) { 
transferLock.lock(); 
try { 
  Account fromAccount = accounts.get(fromId); 
  Account toAccount = accounts.get(toId);
    if (fromAccount.getBalance().compareTo(amount) < 0) { 
    thrownew InsufficientFundsException(); } fromAccount.setBalance(fromAccount.getBalance().subtract(amount));
    toAccount.setBalance(toAccount.getBalance().add(amount)); 
    } finally { 
    transferLock.unlock(); 
    } 
    } 
    // 错误的做法：锁内加事务 
    public void transferMoneyWrong(String fromId, String toId, BigDecimal amount) { transferLock.lock(); 
    try { 
       // 事务范围在锁内 
       doTransfer(fromId, toId, amount);     }finally { 
       transferLock.unlock(); 
       } 
    } 
    @Transactional
    private void doTransfer(String fromId, String toId, BigDecimal amount) { 
    // 转账逻辑 
    } 
  }

最佳实践建议 1. 推荐顺序: 先开启事务，再获取锁 2. 锁的范围: 尽量缩小锁的范围，只锁必要的代码块 3. 锁的类型选择: - 读多写少: 考虑读写锁(ReentrantReadWriteLock) - 高竞争: 考虑乐观锁(版本号机制) 4. 事务隔离级别: 根据业务需求选择合适的隔离级别 记住，锁和事务的正确使用对系统性能和一致性至关重要。在复杂场景下，可能需要结合分布式锁和分布式事务来处理跨服务的问题。