写在文章开头

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

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

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

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

最近笔者也准备了一个免费赠送Claude Code实战书籍的活动，感兴趣的读者可以移步如下链接到评论区踊跃参与：

本本爆款的咖哥，带着首本Claude Code实战书来了！ (opens new window)

SharkChili · 计算机路上的禅修者

开源贡献

• mini-redis：教学级 Redis 精简实现 · https://github.com/shark-ctrl/mini-redis
• Nightingale：深度源码研究

关注公众号，回复 【加群】 加入技术社群

详解提示词工程

提示词工程的本质

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

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

1. 基于预输入文本推导出所有可能的结果及其概率分布，然后通过解码策略（如贪心解码、Top-K 采样、Top-P 采样等）选择下一个词作为输出
2. 以上一步的输出结果和输入文本拼接再次作为输入，再次推导出下一个输出
3. 循环上述两步，直到完成完整结果输出

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

java面向对象三大特性为：

按照大语言模型的工作机制，就是不断推导下一个可能输出的结果然后基于解码策略选择输出，作为下一次推理的输入循环往复。

如下图所示，基于我们输入的问题，大语言模型不断推导下一个输出文本，然后循环推导构建出一个完整的输出结果：

大语言模型在训练过程中接触到了海量数据，这使得它汲取到了大量的有效的知识，成为一个具备丰富知识的文本预测工具，注意笔者的说法，是预测文本工具，它的输出本质是一种推理预测，并非计算，这就是为什么在某些情况下，大语言模型对于一些计算型的任务会出错的原因。

因此要想让大模型给出我们预期的正确结果，就需要提升大语言模型推导的正确性，即给定的提示词能够准确界定出正确的上下文，干预它后续生成文本的概率和方向，这一技术的核心指导思想为上下文学习。

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

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

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

KITE提示词框架

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

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

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

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

当前这个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则说明当天用户存在签到操作，循环遍历该操作累加计算用户签到记录

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

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

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

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

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

## 约束条件


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

提示词的调试技巧

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

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

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

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

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

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

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

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

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

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

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

提示词工程实践演示

案例说明

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

结合需求说明同时考虑到案例的理解成本，笔者这里抹去一些抽象和健壮性的设计，整理出需要明确落地的4个接口：

1. 签到接口：对外提供id入参，通过id和系统当前时间维护用户当天签到
2. 签到记录查询通用接口：传入用户id和日期范围，返回签到天数
3. 用户连续签到查询：传入用户id和起止日期，若开始时间和结束时间内都有签到则返回true
4. 用户年度签到查询：传入用户id和年份，返回签到次数

提示词构建

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

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

当然，对于日常开发我们也无需花费大量时间用于调整自己的提示词结构，上述只是一个基本示例。对于日常研发工作的提示词，我们完全可以提出自己的想法让大语言模型逐步完成优化和澄清：

这也是提示词工程中一种常用的技巧，即先思考再行动，对于提示词编写也是一样，先和大语言模型进行沟通澄清，确保提示词语料没有问题后，再将提示词提交给 LLM：

结合最新的AI实践，也就是spec规格驱动开发，也就是笔者一再强调的先思考再行动的AI编程规范。笔者在提示词工程基础之上，再次使用superpowers插件安装到claude code上。保证LLM通过这套思维框架完成提示词的澄清，提升编码的准确性：

可以看到基于既有的superpowers思考技能框架，claude code会针对提示词功能中不够清晰的点进行进一步的澄清，主动提问确保方案设计的准确性：

经过多轮澄清交互后，基于我们既定的提示词，LLM非常准确的将知识语料聚焦于java技术栈，并严格java开发规范给出既定签到功能的方案落地：

代码验收

经过提示词的有效注入和思考技能框架的准确澄清，LLM 落地的编码准确性基本可以达到90%，笔者本次的测试功能为例，在验收阶段，也仅仅针对落地的代码给出构建注释的要求。确保开发者能够结合自然语言快速结合语义完成编码逻辑验收：

针对service部分补充必要的注释,确保我们能快速理解需求

因为本文着重于提示词工程和介绍，所以对于编码部分笔者也就简单说明一下。如下，结合大语言模型预训练的语料，通过准确界定范围的上下文，大语言模型能够正确的理解需求，并准确的推理分析出 Jedis bit 指令的特性（从0开始），准确的处理好编码的边界和业务语义的响应：

小结

本文介绍了提示词工程的核心原理与实践技巧，详尽介绍了：

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

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

• 以角色背景和技术栈完成知识注入
• 明确集成环境和功能架构以及落地步骤构建指令
• 通过测试单元明确设定目标

本文到此结束，希望我的一些实践对你有所帮助。

最近笔者也准备了一个免费赠送Claude Code实战书籍的活动，感兴趣的读者可以移步如下链接到评论区踊跃参与：

本本爆款的咖哥，带着首本Claude Code实战书来了！ (opens new window)

SharkChili · 计算机路上的禅修者

开源贡献

• mini-redis：教学级 Redis 精简实现 · https://github.com/shark-ctrl/mini-redis
• Nightingale：深度源码研究

关注公众号，回复 【加群】 加入技术社群

参考

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

《Redis 应用实例》