写在文章开头

笔者认为，在AI时代下，具备编程思维和开发基础的软件开发工程师应学会提升自己对于软件系统抽象的认知，学会从繁琐的编码工作中解放,即做到:

1. 减少人工编码时间的占比，将繁琐的基础编码工作转交给AI执行
2. 增加对于复杂系统工程架构和数据流整理与设计，再通过正确的提示词将大语言模型出众的能力应用到系统工程中

而这就是这篇文章所要介绍的提示词工程的基本原理和实践，整体来说文章的结构如下：

1. 提示词工程基本介绍：对提示词本质、KITE提示词框架、提示词调试技巧进行详尽解释与说明
2. 提示词功能落地实践：基于一个redis签到功能的示例，构建出一份规范的提示词让Trae自动完成功能落地和调测

你好，我是 SharkChili ，禅与计算机程序设计艺术布道者，希望我的理念对您有所启发。

📝 我的公众号：写代码的SharkChili
在这里，我会分享技术干货、编程思考与开源项目实践。

🚀 我的开源项目：mini-redis
一个用于教学理解的 Redis 精简实现，欢迎 Star & Contribute：
https://github.com/shark-ctrl/mini-redis

👥 欢迎加入读者群
关注公众号，回复 【加群】 即可获取联系方式，期待与你交流技术、共同成长！

详解提示词工程

提示词工程的本质

从语义来来说提示词本质的作用是对大模型的提示，即通过一段文字描述让大语言模型回忆预训练时的知识，然后根据用户输入的文本的描述进行针对性的回复，而提示词工程则是专注于提示词的编写和优化、确保我们可以正确有效的和大语言模型进行交互的系统学科。

大语言模型是一种在训练时利用大量无标注的语言，通过自监督学习的方式使之获得一种基于前序文本推理出下一个文字符号的文本预测能力，也可以理解为一种概率模型。也就是说它会根据输入的文本，然后如下步骤完成推理和输出：

1. 基于预输入文本推导出所有可能的结果，然后选择概率最大的词作为输出
2. 以上一步的输出结果和输入文本拼接再次作为输入，再次推导出下一个输出
3. 循环上述两步，直到所有完成完整结果输出

例如：我们对大模型输入下面这段话：

java面向对象三大特性为：

按照大语言模型的工作机制，就是不断推导下一个可能输出的结果然后选择概率最大的结果输出，作为下一次推理的输入循环往复，如下图所示，基于我们输入的问题，大语言模型不断推导下一个输出文本，然后循环推导构建出一个完整的输出结果：

总体而言，大语言模型在训练过程中接触到了海量数据，这使得它汲取到了大量的有效的知识，成为一个具备丰富知识的文本预测工具，因此要想让大模型给出我们预期的正确结果，本质上就是要提升大语言模型推导的正确性，即语言给定的上下文能够界定大语言模型，干预它后续生成文本的概率和方向，这一技术的核心指导思想为上下文学习。

提示词是与大语言模型沟通的媒介，提示词的绝对质量直接决定了大语言模型输出的结果质量，笔者认为,一份优秀的提示词应该要像编码程序的函数一样，一个相同的输入就需要有一个正确的、一致的输出，并且符合结构化标准。而这一理念的核心特性在于，无论输入参数如何变化，函数的输出总是要保持一定的格式、数量和类型，对于相同的输入，生成的输出应该是相同或者说类似，而非随机不可预测：

上图笔者给出一个类似于函数化的提示词设计，可以看到笔者将用户输入的提示词作为，完整提示词的入参，这就涉及到的提示词工程中的一个重要的概念：普通用户不具备编写专业提示词的能力，开发者要学会在用户提示词之外，补充任务描述、任务要求等信息，确保大语言能够输出更加符合专业领域且符合用户预期的输出结果。

已上图为例，用户仅仅是输入的并发编程的任务或者要处理的数据流信息，笔者通过完整提示词界定了用户涉及的专业背景和知识，用户只需输入几句简单的文本就可以得到符合预期的代码。

KITE提示词框架

按照现主流的实践，提示词的编写应该遵循KITE原则，该框架包含如下4个核心部分：

1. 注入知识(knowledge)：告知AI当前任务的领域主题或者基础知识，确保其对任务的背景有清晰的理解。
2. 明确指令(instruction)：编写正确、清晰的任务，让大模型明确了解本次任务是明确且可执行的。
3. 设定目标(target)：明确大语言模型生成内容的验收标准，即明确的预期目标、标准、效果，为生成的内容提供明确的方向。
4. 确定边界(edge): 界定本次任务需要注意的条件，明确大语言模型生成内容时应该遵守的规则和限制，确保内容和合规性和边界性。

KITE框架有助于我们更好的组织思路，确保提示信息的完整性和一致性，我们先来说明一下注入知识的几种编写策略，为了让大语言模型能够生成更符合预期的内容，我们需要的该阶段注入大语言模型应该掌握的必要信息，提升其内容的专业性和准确性。

从软件开发的角度出发，认知说明最好的方式就是背景陈述或角色暗示，背景说明则是详尽告知AI本次任务的工作背景，让AI界定本次任务的本质和要求，例如：

当前这个query接口原本是通过查询mysql数据库完成信息查询用户签到情况，现有用户签到功能的做法是每次用户点击签到后将用户信息和签到时间插入到mysql数据表中，然后通过时间范围查询的方式获取用户本月签到情况，目前表数据量为千万级，接口查询平均耗时差不多需要300ms，我需要你帮我完成接口优化，提升接口响应速度。

同理，角色暗示也是比较实用的手段，这也是笔者最爱用的一种方式，即指定大语言模型角色来注入该角色的先验知识，让它能够从预训练的语料中界定自己的知识范围，提升生成内容的专业性和准确性，避免大语言模型混乱。我们还是以上面那个接口优化的需求为例，角色说明的提示词则是：

你是一位具有5年工作经验的java开发工程师，精通spring boot源码、mysql数据表调优以及redis中间件底层原理，我现在有个用户签到功能查询接口平均耗时大约300ms，成为整个系统性能瓶颈所在，我现在需要你结合redis中间件完成签到功能的优化。

为保证大语言模型能够精准且高效的执行任务，清晰而具体的指令则是尤为重要的，虽任务都具有相应的独特性，但遵循如下几条普适的知道原则将有助于更好的构建执行指令：

1. 准确性：明确任务主题，随后阐述任务的具体内容和要求。
2. 完整性：构建指令时，务必给出完整的关键信息
3. 易读性：避免冗长复杂的句子结构，如果任务设计多个步骤，建议分点清晰的陈列出步骤

以签到功能的指令说明为例，对应任务说明的指令描述为：

对应签到和签到查询代码位于xxxx，请你按照如下要求完成基于redis非关系型数据库的用户签到功能开发：
1. 添加用户签到接口，通过jedis客户端setbit指令维护用户签到信息，对应key为用户名:年份，例如:user-0在2026.1.1号签到，对应指令则是setbit user-0:2026 0 1
2. 签到功能的索引计算:为签到年份的所处的天数，计算从0开始，例如1.1则是0，1.10则是9，以此类推......
3. 用户签到查询记录查询：入参用户名和签到范围查询的开始日期和结束日期，返回用户签到次数，例如：获取user-0用户 1月份的签到情况，对应入参就是user-0,2025.1.1，2025.1.31，若该用户本月签到10次则返回10
4. 签到记录查询实现方式:以用户名：年份作为key，计算日期区间对应bit位调用getbit获取当前日期标志位数值，若为1则说明当天用户存在签到操作，循环遍历该操作累加计算用户签到记录

给定需要完成的任务之后，我们就需要设定预期目标，让AI明白开发任务的验收标准，确保AI完成任务后可以自检和验收，提升任务完成准确性，所以设定目标的提示词应遵守如下几个标准：

1. 明确：预期目标必须明确具体，而非含糊不清的描述
2. 可行：目标应该基于大语言模型设计能力和训练数据来设定，务必确保在大语言模型的能力范围之内
3. 可衡量：预期结果是可以量化衡量的，只有结果可以量化评估我们才能评估大语言模型实现的效果

按照笔者的个人经验，系统功能落地后的验收标准一般是结合产品给定的验收条件或者业务功能数据流终态的后验单元测试展开，以本次的签到功能为例，笔者一般是会让AI自行编写测试单元进行自检：

完成功能落地后，我希望你编写UserCheckInTest测试单元完成如下用例的验收：
1. 通过签到保存接口完成user-0和user-1用户分别对应2025年1月1号、3号、5号、7号和2025年1月所有日期的签到，测试签到查询接口user-0和user-1在1月1-7到签到次数是否是4和7
4. 测试签到用户查询日期起止区间为空的情况下，是否会抛出非法参数异常
5. 编写一个2000并发的签到操作，传入user-2 2025年10月1号、11月11号的随机签到，查看平均耗时是否在10ms，且2025年全年签到次数为2
6. 编写一个2000并发的查询操作，随机查询生成任务user-*,区间为2025年任意月份时间，查看接口平均耗时是否低于15ms

最后就是确定边界，确定边界主要用于为大语言模型设置一些列规则和限制，涉及长度、格式、编码规范、技术选型等各个方面的要求，避免AI生成任务期间出现与预期不符的动作和过程，以本文签到功能的开发，对应的限定规则可以是：

## 约束条件


1. 功能范围：仅在CheckInService和CheckInController文件进行编码开发工作
2. Redis操作：所有 Redis 相关操作必须使用 Redisson 客户端
3. 依赖管理：工作期间不得添加新的 Maven 依赖或 Java 文件
4. 代码质量：遵循 Effective Java 规范

提示词的调试技巧

传统编码调试都是通过日志打印或者断点调试亦或者堆栈跟踪的方式定位错误，相比于这种传统开发模式，提示词调测更依赖于用户的理解以及提示词的精细调整，正如软件开发中一句至理名言所述：

正确的代码是调试出来的，而不是直接写出来的

按照笔者对于AI IDE的使用经验，一般情况下笔者会花费大量时间先完善提示词，与之对应的迭代过程为：

1. 初始提示：给定初始化提示询问大语言模型，观察其回答质量
2. 观察分析：基于输出结果结合KITE提示词框架，自检提示词背景是否有所欠缺？注入指令是否描述完整？预期目标是否明确可执行和可衡量
3. 修订提示：多轮迭代调整提示词
4. 稳定结果：获取符合预期的提示词，交由agent进行功能落地

同时调试期间，我们也可以通过提示词日志打印的方式判断逻辑准确性，例如我们输入提示词：

用户：输入2、2返回4，请告诉我输入3、3返回什么
ai：输出6

此时我们就可以明确告知AI给出自我解释的调试信息，辅助我们理解大语言模型的内部运作机制，此时它就会告诉我们它的运算步骤：

2+2=4 所以 3+3=6

明确运算符错误后，我们就可以按需调整。

最后一种有效的调整方式则是让AI复述一下任务，有时候大语言模型会忘记用户的意图或者任务的重点，此时我们就可以让AI用自己的语言来复述一下任务，由此来判断大语言模型对于任务的理解程度，例如我们可以在上文的签到功能提示词下方增加：

# redis签到功能提示词......
# ....用bitcount完成.......
请用自己的话简要概括本次需要完成的任务和落地步骤

提示词工程实践演示

案例说明

上文我们详尽介绍提示词工程的本质、实用和调试技巧，接下来我就以一个reidis落地用户每日签到的案例演示一下提示词的编写技巧。我们先来介绍一下这个案例的背景，假设我们现在有一个平台A，每日用户登录后都可以通过签到按钮点击签到，平台管理端可以根据任意时间范围内用户签到次数或者连续签到次数。

结合需求说明同时考虑到案例的理解成本，笔者这里抹去一些抽象和健壮性的设计，整理出需要明确落地的4个接口：
4. 签到接口：对外提供id入参，通过id和系统当前时间维护用户当天签到
5. 签到记录查询通用接口：传入用户id和日期范围，返回签到天数
6. 用户连续签到查询：传入用户id和起止日期，若开始时间和结束时间内都有签到则返回true
7. 用户年度签到查询：传入用户id和年份，返回签到次数

提示词构建

明确梳理的功能要求和验收标准之后，我们就可以构思落地方案完成提示词构建，结合上述KITE提示词框架的标准，笔者构建的提示词着重去明确告知AI技术栈和落地规范即当前项目使用的框架为spring boot以及后续集成中间件时使用的客户端依赖为jedis，让它能够从预训练的语料中获取特定需要的知识，提升后续方案实现的专业度，避免处理混乱：

## 背景说明
你是一位具备5年Java开发经验的高级后端工程师，熟练使用Spring Boot框架并精通Redis所有常用数据结构和使用场景，现需基于Spring Boot和Jedis客户端完成签到功能模块的开发。该模块应实现以下核心功能：用户每日签到记录、连续签到天数统计、开发过程中需合理设计Redis数据结构，确保高并发场景下的性能与数据一致性，同时实现完善的异常处理机制和单元测试。

然后再给出本次具体任务安排和思路，注入指令是提示词工程中最重要的，它决定了AI完成功能落地的完整过程，所以这一块笔者在初步完成任务描述的提示词设计后，都会借住大语言模型进行进一步针对性的优化的梳理，以笔者本次签到功能的实现思路，即用到位图记录用户的签到情况，在压缩内存使用的同时，还能够保证后续统计的准确性，对应算法为：

1. 基于日期的dayOfYear-1定位其所处位图索引，并将其设置为1
2. 计算指定日期签到次数时，通过计算各个日期的dayOfYear-1对应位图索引进行累加(bitcount仅支持面向字节的偏移量汇总，不支持bit位的汇总)
3. 计算全年签到，直接基于用户的key，如下图则是user-0:2025，通过bitcount指令直接汇总

基于上述思路，笔者寻求大语言模型迭代优化后的提示词如下，逻辑非常清晰，整体编写的顺序为：

1. 集成与配置说明
2. 功能结构设计
3. 具体方法定义和实现逻辑

## 任务描述
开发一个功能完整、健壮的用户签到系统，包含签到记录管理和多维度查询接口，具体实现要求如下：

1. Redis集成与配置：
   - 集成Jedis客户端，配置本地Redis连接参数（地址：127.0.0.1，端口：6379，无认证）
   - 实现Redis连接池管理，确保连接的高效复用和资源释放
   - 添加Redis连接状态监控与异常处理机制

2. 模块结构设计：
   - 创建签到模块专用的Controller文件，遵循RESTful API设计规范
   - 合理划分Service、Repository层，实现业务逻辑与数据访问分离
   - 定义清晰的数据模型和DTO对象，确保接口参数和返回值类型安全

3. 用户签到接口实现：
   - 接口路径：/check-in
   - 请求方法：POST
   - 请求参数：用户名(username)、签到日期(date)，需进行非空和格式校验
   - 存储方案：使用Redis位图数据结构存储签到状态，key格式为"checkIn:{username}:{year}"
   - 索引计算：以年度为单位，1月1日为索引0，1月2日为索引1，以此类推（即索引值 = 当天在本年度的天数 - 1）
   - 业务逻辑：设置对应索引位置的bit为1，返回签到成功状态

4. 签到记录查询接口实现：
   - 接口路径：/check-in/count
   - 请求方法：GET
   - 请求参数：用户名(username)、开始时间(startDate)、结束时间(endDate)，需验证日期有效性及时间范围合理性
   - 实现逻辑：
     a. 计算日期范围
     b. 对每个年份计算对应的开始索引和结束索引
     c. 调用Redis的GETBIT命令获取每个日期的签到状态
     d. 统计并返回该时间段内的总签到次数

5. 连续签到查询接口实现：
   - 接口路径：/check-in/continuous
   - 请求方法：GET
   - 请求参数：用户名(username)、开始日期(startDate)、结束日期(endDate)、目标连续天数(targetDays)
   - 实现逻辑：
     a. 验证日期范围有效性及目标天数合理性
     b. 计算日期范围内每天对应的位图索引
     c. 通过GETBIT命令获取各日期签到状态
     d. 统计连续签到天数，判断是否达到目标天数
     e. 返回布尔结果(true表示达到目标，false表示未达到)及实际连续签到天数

6. 年度累计签到查询接口实现：
   - 接口路径：/check-in/yearly
   - 请求方法：GET
   - 请求参数：用户名(username)、年份(year)，需验证年份有效性
   - 实现逻辑：
     a. 构建Redis key："checkIn:{username}:{year}"
     b. 调用Redis的BITCOUNT命令计算全年签到总天数
     c. 返回年度累计签到次数及年度总天数占比

7. 系统健壮性保障：
   - 输入参数校验：对所有接口参数进行严格校验，包括格式、范围、必填项等
   - 异常处理机制：
     a. Redis连接异常处理与重试机制
     b. 日期计算异常处理
     c. 业务逻辑异常（如无效日期范围、用户不存在等）
   - 日志记录：记录关键操作日志、错误日志，便于问题排查
   - 接口文档：提供完整的API文档，包括请求参数、返回值、错误码等

随后再给出完成后的功能验收标准也就是设定预期目标，以结果为导向让AI能够结合任务描述完成开发工作自检，对应笔者优化后的提示词如下，整体还是：

1. 列点说明测试用例
2. 逐点拆解单元测试编写步骤和断言规则

## 验收标准
完成功能开发与部署后，请按照以下详细步骤编写并执行单元测试以完成功能验收，确保所有签到功能符合设计要求和性能标准：

1. 创建一个名为UserCheckInTest的单元测试类，确保其包含所有必要的测试方法和前置/后置处理逻辑。

2. 测试签到功能正确性：
   a. 通过签到保存接口为user-0用户执行2025年1月1日、3日、5日、7日的签到操作
   b. 通过签到保存接口为user-1用户执行2025年1月所有日期的签到操作
   c. 调用签到查询接口分别查询user-0和user-1在2025年1月1日至7日期间的签到次数
   d. 验证user-0的签到次数应为4次，user-1的签到次数应为7次

3. 测试参数验证功能：
   a. 调用签到用户查询接口时，传入空的日期起止区间参数
   b. 验证系统是否正确抛出非法参数异常
   c. 确认异常信息准确描述了参数错误原因

4. 测试高并发签到性能：
   a. 设计并执行1000并发的签到操作，目标用户为user-2
   b. 随机为user-2生成2025年10月1日和11月11日的签到请求
   c. 记录并计算所有并发请求的平均响应时间，验证是否控制在100ms以内
   d. 调用签到查询接口，验证user-2在2025年的累计签到次数应为2次

5. 测试年度累计签到功能：
   a. 为user-2执行2025年全年所有日期的签到操作
   b. 调用年度累计签到查询接口，查询user-2在2025年的签到情况
   c. 验证返回的年度累计签到天数是否为365天

6. 测试高并发查询性能：
   a. 设计并执行1000并发的签到查询操作
   b. 随机生成user-*系列用户ID和2025年任意月份的时间区间作为查询参数
   c. 记录并计算所有并发查询请求的平均响应时间，验证是否低于15ms
   d. 确保所有查询结果准确反映对应用户在指定区间内的实际签到情况

最后通过确定边界限制AI工作范围和开发标准，避免其作出功能以外的改动对项目结构造成破坏，确保项目能够符合团队的开发规范下完成：

## 限定条件
1. 实现完整的签到功能模块，包括但不限于必要的配置文件、Service层业务逻辑和Controller层接口定义，确保各组件间交互正常
2. 签到查询功能设计仅支持单年内日期查询，无需考虑跨年度日期处理逻辑
3. 接口返回值必须严格遵循任务描述中规定的格式标准，禁止自行封装额外的实体类或Map集合作为返回结构
4. Redis数据库交互必须统一使用Jedis客户端实现，不得使用其他Redis客户端库
5. 所有代码必须符合JDK 8语法规范，确保使用JDK 8编译器能够成功编译通过
6. 日期时间处理操作统一采用Hutool工具类，禁止使用Java原生日期API或其他日期处理库
7. 完成编码开发后，必须执行所有相关测试用例并确保全部通过验收，性能压测结果暂不做特殊要求
8. 开发环境已默认启动Redis服务，无需在开发环境内执行Redis的下载、部署及额外配置工作
9. 严格限定开发范围，仅对签到功能相关文件进行修改，禁止擅自修改非相关功能文件
10. 所有开发逻辑必须严格遵循本提示词要求执行，禁止擅自增加任务描述外的设计思路与功能扩展
11. 允许修改项目配置文件（如application.properties/application.yml等）和pom.xml文件，通过Maven管理工具添加必要的依赖包
12. Jedis操作必须严格限制使用SETBIT、GETBIT、BITCOUNT三个命令，禁止使用其他Redis命令

验收

因为笔者的提示词已经明确的给出的验收标准，所以Trae在进行功能落地时会遵循TDD的工作理念，即通过测试单元驱动自己完成功能修复，最终验收代码质量还是非常不错的，因为笔者采用AI编程都是带有TDD意味的风格，所以笔者这里先给出功能落地的验收单元，如下所示，可以看到对应user-0和user-1分别签到4次和7次，预期的校验就是通过queryCheckInCount的返回结果进行断言验收：

 @Test
    public void testCheckInAndQuery() {
        // 测试user-0签到：2025年1月1号、3号、5号、7号
        checkInService.checkIn("user-0", DateUtil.parse("2025-01-01"));
        checkInService.checkIn("user-0", DateUtil.parse("2025-01-03"));
        checkInService.checkIn("user-0", DateUtil.parse("2025-01-05"));
        checkInService.checkIn("user-0", DateUtil.parse("2025-01-07"));
        // 测试签到查询接口
        int user0Count = checkInService.queryCheckInCount("user-0", DateUtil.parse("2025-01-01"), DateUtil.parse("2025-01-07"));
        
        assertEquals(4, user0Count, "user-0在1月1-7日的签到次数应为4");

       
        // 测试user-1签到：2025年1月所有日期
        for (int i = 1; i <= 31; i++) {
            checkInService.checkIn("user-1", DateUtil.parse("2025-01-" + (i < 10 ? "0" + i : i)));
        }
        int user1Count = checkInService.queryCheckInCount("user-1", DateUtil.parse("2025-01-01"), DateUtil.parse("2025-01-07"));
        
        assertEquals(7, user1Count, "user-1在1月1-7日的签到次数应为7");
    }

同理，当接口收到空日期参数时会抛出参数异常，对应AI给出的单元测试也是传入空参数断言异常类型是否符合预期：

@Test
    public void testQueryWithNullParams() {
        // 测试签到用户查询日期起止区间为空的情况
        assertThrows(IllegalArgumentException.class, () -> {
            checkInService.queryCheckInCount("user-0", null, null);
        });
    }

其他类型于全年签到日期校验和并发性能测试单元测试也都编写的非常到位，笔者这里就不多做赘述了，这里也直接给出落地的功能代码段，我们先来看看签到功能，逻辑非常清晰：

1. 基于日期定位日期对应bit索引
2. 调用setbit记录这个用户当日的签到信息

public void checkIn(String username, Date checkInDate) {
        if (username == null || checkInDate == null) {
            throw new IllegalArgumentException("用户名和签到日期不能为空");
        }
        
        Jedis jedis = null;
        try {
            jedis = jedisPool.getResource();

            //定位日期所属bit位
            int dayOfYear = DateUtil.dayOfYear(checkInDate) - 1;
            //创建redis key
            int year = DateUtil.year(checkInDate);
            String key = "checkIn:" + username + ":" + year;
            //设置bit位,完成签到
            jedis.setbit(key, dayOfYear, true);
        } finally {
            if (jedis != null) {
                jedis.close();
            }
        }
    }

同理查询签到次数的逻辑一样，因为redis bitcount指令范围是面向byte而不是面向bit，所以要想明确定位日期签到情况需要用到更精细的bit完成，所以AI明确知晓这一点之后，针对范围签到记录的接口落地过程为：

1. 必要的校验
2. 基于起止日期定位索引范围
3. 基于索引范围调用GETBIT获取数值完成计数累加
4. 释放资源并返回结果

/**
     * 查询签到记录
     *
     * @param username  用户名
     * @param startTime 开始时间
     * @param endTime   结束时间
     * @return 签到次数
     */
    public int queryCheckInCount(String username, Date startTime, Date endTime) {
        //......
        int year = DateUtil.year(startTime);
       
        //定位bit索引范围
        int startDay = DateUtil.dayOfYear(startTime) - 1;
        int endDay = DateUtil.dayOfYear(endTime) - 1;

        String key = "checkIn:" + username + ":" + year;
        int count = 0;

        Jedis jedis = null;
        try {
            jedis = jedisPool.getResource();
            // 循环遍历累加计算签到次数
            for (int i = startDay; i <= endDay; i++) {
                if (jedis.getbit(key, i)) {
                    count++;
                }
            }
        } finally {
            if (jedis != null) {
                jedis.close();
            }
        }
        //返回签到次数
        return count;
    }

最后，查看用户全年签到接口，对应只需通过用户名和年份获取对应的redis key，然后调用bitcount获取bitmap计数之和返回：

public long queryYearlyCheckInCount(String username, int year) {
       //......
        String key = "checkIn:" + username + ":" + year;
        long count = 0;
        
        Jedis jedis = null;
        try {
        //通过bitcount累加用户本年度签到计数和
            jedis = jedisPool.getResource();
            count = jedis.bitcount(key);
        } finally {
            if (jedis != null) {
                jedis.close();
            }
        }
        
        return count;
    }

小结

本文介绍提示词工程的本质的实践技巧，详尽介绍了：

• 大语言模型的内部工作机制
• 提示词最佳实践规范即KITE原则
• 通过迭代、沟通推导或任务复述的方式进行提示词调试

最后基于redis签到功能演示了后端开发提示词编写技巧：

• 以角色背景和技术栈完成知识注入
• 明确集成环境和功能架构以及落地步骤构建指令
• 通过测试单元明确设定目标
• 结合团队规范和文件范围确定边界

你好，我是 SharkChili ，禅与计算机程序设计艺术布道者，希望我的理念对您有所启发。

📝 我的公众号：写代码的SharkChili
在这里，我会分享技术干货、编程思考与开源项目实践。

🚀 我的开源项目：mini-redis
一个用于教学理解的 Redis 精简实现，欢迎 Star & Contribute：
https://github.com/shark-ctrl/mini-redis

👥 欢迎加入读者群
关注公众号，回复 【加群】 即可获取联系方式，期待与你交流技术、共同成长！

参考

《AI原生应用开发：提示工程原理与实战》

《Redis应用实例》