程序员的AI五步提示词大法

AI大模型如火如荼，你有没有陷入过AI终将代替人类的终极焦虑？

​ 使用AI大模型，提示词的重要性毋庸置疑。不管是向AI大模型问问题，还是围绕AI大模型构建应用，设计高效的提示词都是其中最重要的一个环节。尤其当你想要在一些具体的业务场景下使用AI大模型时，你不可能真的像聊天一样，慢慢跟大模型软磨硬泡，这时一个高效的提示词就显得尤为重要了。即便像LangChain4j，SpringAI这些纯面向程序员的AI大模型框架，其各种工具的背后，也是通过定制各种各样的提示词，从而让AI大模型帮助实现某种功能。

​ 如何构建好的提示词呢？最好的方式，当然是具体情况具体分析。比如这个网站： https://www.promptingguide.ai/zh 上面分享了非常多针对不同场景的提示词设计思想和样例。还有阿里云百炼，提供了专门优化Prompt的应用插件：https://bailian.console.aliyun.com/#/prompt-manage。这么多场景，这么多模板，给你组个899的提示词工程课，不过分把？但是，如此复杂的提示词工程，只怕还没开始问AI，自己已经先头晕了。

​ 那么有没有一套简单有效的提示词设计模板，能够应付大部分的应用场景，提升与AI交互的质量呢？这次，楼兰就以SQL智能助手场景为例，给你分享一套简单有效的提示词设计模板。

​ 现在数据库中有几张表：

create table Authors (
                         id int not null auto_increment,
                         firstName varchar(255) not null,
                         lastName varchar(255) not null,
                         primary key (id)
);
create table Publishers (
                            id int not null auto_increment,
                            name varchar(255) not null,
                            primary key (id)
);
create table Books (
                       id int not null auto_increment,
                       isbn varchar(255) not null,
                       title varchar(255) not null,
                       author_ref int not null,
                       publisher_ref int not null,
                       primary key (id),
                       foreign key (author_ref) references Authors(id),
                       foreign key (publisher_ref) references Publishers(id)
);

​ 我想要AI大模型帮我写一些SQL语句，例如”统计在同一个出版社中，出版书籍最多的作者“。应该要怎么设计一套向AI有效提问的提示词模板呢？

一、五步提示词大法

1、指定AI角色

​ 其实以AI的超强理解力，我们完全可以把他当成一个身边的专家来使用。而当你想要向一个专家进行咨询时，最类似的生活场景就是你去医院看病，要医生给你专业的治疗。

​ 去医院看病之前，首先要找准科室和医生。这样才能保证医生有足够的专业知识能够看准你的病因。要是你肚子疼，结果跑去了口腔科，那结果只能是闹个笑话。

​ 与此类似，当你有问题要咨询AI时，就要先想清楚你是想要跟谁咨询。这时候，给AI一个明确且特色鲜明的角色定位，可以让AI更好的理解你的需求，从而提供更专业的帮助。例如，你可以这样指定：”你是一位经验丰富的数据库管理员，擅长编写高效、准确的SQL查询语句“。

2、说明问题症状

​ 见了医生后，你不能一上来就要医生开药，当然需要先跟医生描述清楚你面临的问题。比如”我最近感觉胸闷，偶尔感觉喘不上气“。但是这一步也是很多人难以把握的，因为你当然是知道很多你自己相关的信息，但是这时的根本目的是需要考虑医生需要知道哪些信息，才能有助于确定你的症状。这时你就还需要提供一些必要的上下文信息，比如持续时间、严重程度等，这样医生才能有足够的信息帮你确定症状。

​ 与AI交互时也同样。你需要明确告诉AI，你有些什么信息，需要解决什么样的问题。例如，你需要告诉AI：”我现在有三张表，Authors作者表，表结构xxxx，Publishers出版社表，表结构xxx，Books书籍表，表结构xxx。我要根据这三张表查询在某一个出版社，初版书籍最多的作者”。

​ 这一步，可以说是整个提示词中最为关键的部分。你给出的上下文信息越精准，就越有助于AI理解背景信息，为后续的解决方案打下基础。对于简单的问题，可以依靠你的经验来尽量优化信息。但是，如果你有一些后端编程的能力，那么这一步就是你大展身手的时候了。例如，如果你希望统计到昨天为止的结果，这时AI大模型并不知道昨天是哪一天，你就可以给AI大模型提供一个可以计算日期的本地接口，这样AI大模型可以通过调用本地接口获得昨天的日期。另外，如果问题相关的知识太多，太复杂了。你还可以使用大模型提供的文本向量化模型，去寻找跟用户的问题匹配得更精确的上下文信息。

3、详细描述目标

​ 跟医生说明了病症，接下来就需要医生给你治病了。去看医生，那当然目标明确，是要治好病。大家心知肚明。但是跟AI交互，问题就往往没有那么明确了。在这一步，你就需要明确你的最终目标是什么，让AI清楚的知道你期望的结果。在提目标时，不用担心AI大模型的理解能力，把目标提得越明确，越能减少不必要的歧义。例如，如果你的后端数据库是MySQL，那么你可以明确告诉AI：“帮我写一个能够在MySQL中顺利执行的SQL语句”。

4、指定期望的结果

​ 跟医生说明了目标，那么医生已经可以基本帮你治疗。不过，更加细致的情况是你想怎么治。

​ 比如你自己估计可能没什么大问题，但是医生上来就跟你说，我们打个针，或者动个手术把，你估计是不容易接受的。你可以明确的跟医生说，不，我只接受口服，而且我只接受西药，中药太苦了，我吃不下。

​ 这一步就是你告诉AI，你所希望的结果格式是什么。当然，如果只是要写一个SQL语句，或许没有太多格式上的要求。但是如果是一些答案比较多的问题，比如“帮我写几个不同的SQL语句，并比较他们的执行性能”，那么对格式上就可以做更多的补充了。比如，整理成一个表格。

5、解决边界问题

​ 最后，如果医生动手给你开药了，你会想到一些预防性的要求，比如，你钱包紧张，就需要跟医生说，让医生开便宜一点的药，这样当医生在给你开药房时，自然就会谨慎一点。

​ 对于AI，你也可以尽量规避一些明显不合理的特殊情况。比如最典型的，如果你给了AI大模型足够精确的信息，那么可以明确告诉AI大模型，就用你提供的信息回答问题，而不要用其他莫名其妙的信息。或者，在写SQL这个场景，你可以明确要求AI大模型就写一个Select查询语句，而不要生成update,delete,insert这一类SQL语句。这样，你就可以尽量放心的把AI大模型提供的SQL语句扔到MySQL执行，而不用担心数据被改得乱七八糟了。或者，可以要求他不要是用多层嵌套等等要求。

​ 或者，如果你想不出这些边界问题，那么另外有个最好的办法，就是给出一些案例，让他直接参考你的案例。

二、真实案例实操

​ 按照这套模板，在面临很多实际问题时，你就可以省下很多绞尽脑汁的去设计提示词的功夫，专注于去评估AI大模型给出的结果了。

​ 例如，如果你想要去医院看看心血管科，可以这样问AI大模型

你是一位经验丰富的医疗顾问，擅长提供就医前的准备工作指导。我最近感觉胸闷，偶尔伴有心悸，这种情况已经持续了一个星期。我的目标是尽快预约心血管科的专家，进行详细的检查和诊断。我希望能够在本周内预约到心血管科的专家，最好是在周三上午。此外，我还想知道去医院前需要准备哪些材料和注意事项。如果本周内没有合适的专家号，可以推荐其他时间或医院。另外，如果需要进行特殊检查，如心电图或血液检查，请提前告知我需要空腹或其他准备事项。

​ 如果你想要大模型教你写一个Python脚本，可以这样说：

你是一位高级软件开发工程师，擅长编写Python脚本。我现在需要一个Python脚本来自动备份指定目录下的所有文件。我的目标是每天凌晨1点自动运行脚本，将指定目录下的文件备份到另一台服务器上。我希望脚本能高效运行，确保备份过程不会中断，并且能够处理各种文件类型。请注意，脚本需要能够处理网络连接不稳定的情况，并在备份完成后发送一封确认邮件。

​ 如果你想要一个旅游攻略，可以跟AI大模型说：

你是一位专业的旅游顾问，擅长提供旅行规划建议。我计划今年国庆假期去云南旅游，主要想参观丽江古城和大理洱海。我的目标是制定一个详细的行程安排，包括交通、住宿和景点门票预订。我希望整个行程既能充分体验当地文化，又能保证舒适度。如果某些景点需要提前预约，请提前告知我相关流程。另外，如果遇到天气变化等特殊情况，提供一些备用方案。

​ 好了，价值899的提示词工程课完结撒花，快点拿去找你感兴趣的大模型试试效果把。

三、SQL智能助手案例实操

​ 当然，如果你是一个严谨的程序员，你希望写一个比较通用的提示词模板，可以对接自己的MySQL，也可以解决前端用户提出的各种问题，那么，当然还需要对提示词进行继续打磨。形成更完整的格式，排除更多异常情况。让你的提示词效果能够更稳定。

​ 例如对于我们这个要求写SQL的场景，把这些技巧快速的整理一遍，就可以形成这样的提示词

你是一位经验丰富的数据库管理员，擅长编写高效、准确的SQL语句。我的数据库中有三张表，建表语句如下：
create table Authors (
                         id int not null auto_increment,
                         firstName varchar(255) not null,
                         lastName varchar(255) not null,
                         primary key (id)
);

create table Publishers (
                            id int not null auto_increment,
                            name varchar(255) not null,
                            primary key (id)
);

create table Books (
                       id int not null auto_increment,
                       isbn varchar(255) not null,
                       title varchar(255) not null,
                       author_ref int not null,
                       publisher_ref int not null,
                       primary key (id),
                       foreign key (author_ref) references Authors(id),
                       foreign key (publisher_ref) references Publishers(id)
);
我的问题是：分别统计每一个出版社中出版书籍最多的用户
你帮我写一个能够在MySQL8.0版本中顺利执行的SQL语句。
这个SQL语句只使用这几张表，并且只写出Select查询语句。如果这些表不足以解决当前的问题，直接告诉我信息不够，无法解决。如果根据用户的问题写出了update、delete、insert这些语句，那么直接告诉我无法解决这样的问题。不要使用WITH窗口函数。

​ 然后，就可以把这个提示词发送给大模型，根据大模型的反馈结果，打磨一下提示词的细节。例如下面是访问阿里通义千问大模型的一次结果：

​ 这个SQL语句虽然优点太过复杂了，但至少能够统计出我们需要的结果：

​ 接下来，你可以把这些具体的参数抽象出来，形成一个提示词模板。

你是一位经验丰富的数据库管理员，擅长编写高效、准确的SQL语句。我的数据库中，建表语句如下：
{schema}
我的问题是：
{question}
你帮我写一个能够在MySQL8.0版本中顺利执行的SQL语句。
这个SQL语句只使用这几张表，并且只写出Select查询语句。如果这些表不足以解决当前的问题，直接告诉我信息不够，无法解决。如果根据用户的问题写出了update、delete、insert这些语句，那么直接告诉我无法解决这样的问题。不要使用WITH窗口函数。

​ 然后，把schema换成你真实的数据库表结构，把question换成客户的问题，你就可以围绕这个提示词模板，去构建一个自己的SQL智能助手了。

​ 接下来，做做前端，接收用户的提问。做做后端，把AI大模型生成的SQL语句扔到数据库里执行，再将执行结果做一些图形化的展示。一个专属于程序员的SQL智能助手就基本成型了。

不知道什么时候开始，整个互联网都开始在鼓吹Java不行了，AI要颠覆打工人了。我很反感这样的所谓流量密码。其实，AI从来只是个工具，而人类从来都是在制造和使用工具的过程中不断进化的。区别只是在于人能不能适应这样的工具。关于AI，你有什么想法吗？大家来评论区讨论讨论。