最近两年圈子里一直在聊 ChatGPT、Claude 这些大语言模型,还有 AutoGPT、BabyAGI 这些智能代理以及“提示词工程”。作为一个技术人,我就在想:这些新技术会不会改变我们写代码的方式?特别是这个”提示词工程”,听起来挺玄乎,到底是个啥?今天咱们就来简单聊聊这个话题。

先说说传统开发是怎么玩的

写了这么多年代码,相信大家对传统开发流程都很熟悉了:先和产品经理掰扯需求,然后开始设计系统,最后才是真刀真枪地写代码。比如说要做个电商系统,基本上逃不开这几个核心功能:

• 加购
• 结算
• 支付
• 退货

传统代码长啥样?

来看看用 TypeScript 怎么实现这些功能。别担心,我写得很简单,主要是让大家有个印象:

class ShoppingCart {   private cartItems: CartItem[] = [];     addProductToCart(product: Product, quantity: number): void {   // 这里是加购逻辑 }     checkout(): Order {   // 结算逻辑     }   }     // 后面还有支付服务、退货服务等等...

那提示词工程又是啥

现在有意思了。用提示词工程,我们是这么写”代码”的:

## Role: 电商小助手 ## 简介 我是你的电商助手,熟悉各种购物场景,随时帮你处理购物相关的问题 ## 我的目标 帮你轻松愉快地购物,遇到问题及时解决 ## 工作方式 1. 先理解你想干啥 2. 根据你的需求选择处理方式:     - 要买东西?走购物流程   - 要付款?走支付流程   - 要退货?走售后流程 3. 给你清晰的反馈和建议

两种方式大PK

1. 写法不一样,但套路差不多传统编程这么写:

class ShoppingCart {   addItem(item: Item) {/* 具体实现 */ }   checkout() {/* 具体实现 */ }   }

提示词工程这么写:

## 我是购物助手 ## 我会:   - 帮你加购商品   - 帮你结算订单

看出来了吗?本质上都是在描述”谁来干什么”,只是语言不一样。

2. 抽象程度不同

传统编程需要事无巨细地告诉计算机每一步该怎么做。比如计算折扣:

function calculateDiscount(price: number, discount: number): number { return price - (price * discount / 100); }

而提示词工程就简单多了:

帮顾客计算折后价格,记得考虑折扣比例。

3. 处理问题的方式不同传统编程很死板:

if (userType === 'VIP') {   applyVIPDiscount(); } else { applyRegularDiscount(); }  

提示词工程就灵活得多:

看看是不是VIP客户,给出合适的折扣方案。

提示词工程有啥特别之处?1. 用人话交流最爽的是可以直接用人话和AI聊天。比如:

用户: L码的白T恤还有货不? AI: 让我查查库存...有的,现在还剩3件。要我帮你加购吗?

你看,多自然。要是用传统方式,得调用好几个API,写一堆代码才能搞定。

2. 懂你说啥

AI真的能理解你在说什么,不是简单的关键词匹配。举个栗子:

用户: 这衣服穿着不舒服,想退 AI: 抱歉给您带来不好的体验。能具体说说是面料问题,还是尺码不合适?这样我好给您更好的建议。

3. 改起来超方便

传统开发改个功能: 改代码 -> 编译 -> 测试 -> 部署,折腾半天。提示词工程呢?改几句话的事:

## 处理退货 1. 先问清楚退货原因 2. 安抚客户情绪 3. 提供解决方案 ↓ ## 处理退货 1. 先提供解决方案 2. 了解退货原因 3. 做好售后服务  

改完立马生效,不用重启服务器。

4. 多语言不是事儿

传统开发做多语言,那叫一个头大。提示词工程?小菜一碟:

用户: How much is this T-shirt? AI: The T-shirt is $29.99. Would you like to add it to your cart? 
用户: この Tシャツはいくらですか? AI: Tシャツは3,000円です。カートに入れましょうか?

一套提示词,多种语言通吃,不用额外开发。

未来展望“提示词IDE”要来了？

目前，大多数提示词的撰写依然处于“手工时代”，依赖个人经验和反复试验。这种模式虽然灵活，但也存在效率低下、学习曲线陡峭的问题。然而，随着提示词的应用范围不断扩大，专门为其设计的集成开发环境（IDE）或将成为趋势。未来的提示词IDE可能具备以下功能：语法检查功能可以帮助用户快速发现和纠正错误；智能提示功能能依据上下文提供优化建议；即时预览功能则可以让用户直观地看到提示词的效果；Debug工具则帮助定位和解决不符合预期的响应问题。这些功能的结合，不仅能提升提示词的撰写效率，也能降低新手入门的门槛。

提示词也会有设计模式？

正如软件工程领域的设计模式为编程提供了结构化的指导，提示词工程也有望形成一套最佳实践。例如，为了达到更好的生成效果，提示词或许需要遵循特定的结构，例如明确的输入要求和期望输出。设计复杂逻辑时，如何分步引导AI得出精确的答案？处理异常情况时，提示词如何兼顾灵活性和稳定性？这些问题的解决，或许会催生出一系列“提示词设计模式”。这些模式不仅是经验的总结，也可能为提示词撰写提供理论基础，使其逐渐从一种“技巧”发展为一种“工程学科”。

提示词工程师：下一代新兴职业

提示词工程师的崛起似乎已经势不可挡。近年来，一些公司已经开始招聘专门的提示词工程师。这个职位不仅需要理解AI的能力，还需要熟悉业务需求，善于撰写高质量的提示词，并懂得性能优化。从某种意义上来说，这个角色很像前些年的“前端工程师”，从曾经的可有可无，变成了今天的不可或缺。提示词工程师的价值在于将AI与业务需求有效结合，通过优化的提示词实现更高效的自动化和智能化解决方案。未来，这一职业的定义或许会更加清晰，并形成标准化的能力模型。

开源社区的新活力

提示词工程的另一个重要推动力是开源社区的蓬勃发展。类似于npm的提示词包管理平台已经开始出现，用户可以在这些平台上分享常用的提示词模板，发布特定领域的专业提示词，甚至进行质量评价和改进。这种共享机制不仅能让更多人从中受益，还将推动提示词质量的整体提升。此外，不同领域的专业人士也能通过开源社区为提示词注入更多领域知识，从而使AI在专业场景中的表现更加精准。开源社区为提示词工程注入的活力，或许会像当年的开源软件运动一样，对整个AI行业产生深远影响。

提示词工程的挑战

当然，提示词工程的未来并非一片坦途。首先，提示词质量参差不齐的问题仍然普遍存在，不同撰写者的能力差异直接影响AI的表现。其次，提示词的性能优化是一项复杂的任务，如何在减少试错的情况下快速优化效果，仍需探索。第三，目前提示词的撰写缺乏统一标准，这不仅导致学习难度大，也增加了协作的复杂性。此外，提示词工程的持续改进需要大量实践和迭代。在某些场景中，可能需要结合传统工程手段与提示词技术，正如Dspy框架尝试的那样，利用代码与提示词的结合来实现高效的AI交互。

结语

提示词工程正处于快速发展的起点。无论是“提示词IDE”、设计模式、开源社区的活跃，还是新职业的出现，这些趋势都昭示着提示词工程将成为AI时代的重要组成部分。然而，只有不断探索并应对挑战，这一领域才能真正实现其潜力，为技术的进步和社会的发展贡献力量。

再多说一嘴

提示词工程只是应用开发（LLM APP开发）的一部分，就像编程语言一样，有了语言，我们还需要一个运行时才能跑的起来；同理在提示词工程中，这个运行时就是AI模型，模型的好坏直接决定了提示词工程的性能。有了提示词，只是给了你脑子做事儿的一些指导原则，具体需要干什么事儿，还是需要你的手脚来执行，这时候就需要RAG、Agent等技术来帮忙了，这些我们可以后续再聊。

写在最后

作为一个技术人,我觉得提示词工程挺有意思的。它不是要取代传统编程,而是提供了一种新的开发方式。就像当年从汇编转到高级语言一样,这可能是我们和AI协作的新方式。不过现在提示词工程还在发展初期,有很多可以探索和改进的地方。与其担心它会不会取代我们的工作,不如主动去学习和尝试,说不定能在这个新领域找到更大的发展空间。毕竟,技术在变,但解决问题的本质是不变的。提示词工程,说到底还是在用新的方式来解决老问题。重要的是理解它的特点,在合适的场景下用好它。