通过阅读了多篇围绕大模型应用、提示词工程等等的文章，结合之前的工程经验，对于如何围绕大模型来进行应用设计有了些新的理解，整理成这篇文章。

看到这里，你一定会觉得所谓“提示词工程师”，不就是写提示词的工程师嘛，可以跟ChatGPT对话，让人工智能解决我的需求，我就是提示词工程师了。 

没那么简单。

提示词往简单了说，就是通过给大模型输入自然语言命令来让大模型做事（可以认为这是一种写代码的方式），我们可以通过DeepLearning的提示词课程[1]来让我们写更好的提示词。

但当需要进行生产环境的部署并给用户稳定的结果输出时，我们就需要对大模型的推理能力有清楚的理解，就需要考虑让大模型能够按照诸如思维链、思维树等方式思考，防止大模型产生幻觉，防止大模型被注入攻击等等问题。进一步，如何对提示词进行测试，确认提示词能够达到生产环境可用，而不仅仅是偶尔能够产出正确答案 ……

这些内容在这个网站[2]进行了广泛讨论，同时可以参考这个网站的论文部分[3]，该领域在学界也正处于研究井喷的时间。

而工程的概念就更加复杂了，未来一定会有很多的大模型服务提供商，提供了不同种类的大模型，也必然会出现层出不穷的开源模型。选择什么模型来给用户提供服务，是否要考虑多种模型同时提供服务以节约成本。

如何对提示词的好坏进行评估；如何搭建提示词的测试流程，上线流程；如何检测用户输入部分的提示词是否安全；如何对提示词的结果进行缓存；如何对整个围绕大模型的使用情况进行日志监控等（这里可以看看这家创业公司[4]和这家创业公司[5]）……

实际上，我认为未来每个公司都会围绕着大模型的应用，提供一系列开发平台，诸如现在已经有的围绕着软件开发的平台一样。大家可以看看这家公司[6]，也是朝着这个方向的一种探索。

• 当我们现在说到AI工程师的时候，很多时候指的是ML工程师，但长期来看，机器学习会进一步基础设施化。因此会出现一个单独的工种，即AI工程师，就像SRE这个工种一样。
• 魔鬼隐藏在细节之中，要开发基于大模型的应用，需要解决上面提出的种种提示词相关问题，工程相关问题，而这会催生产生一个新的工种，即AI工程师。
• AI工程师会采用围绕大模型的种种能力栈来开发未来的应用，作者定义这是软件开发的3.0时代，即基于有推理能力的大模型，来对 [之前不能编码的] 更大的物理世界进行编码。

我有一个视角来看待未来由大模型驱动的应用（或者说是应用的一部分由大模型驱动），即从领域驱动设计（DDD）的角度。

现阶段我们会以DDD的思路进行领域建模，将业务拆分为核心域、支撑域、通用域等等。原则上，我们会用最主要的精力来实现核心域，而对于支撑域和通用域，则倾向于用成熟的组件来实现。

当前做好核心域最重要的事情是对业务进行分析和抽象，进而让各方用统一语言来对核心域的实体、聚合、领域事件等等达成一致，最后通过代码来实现。

但在实践中我们发现，想要做好业务抽象，并非一件容易的事情：有时候很难对复杂的业务进行抽象，有时候很难对快速变化的业务进行及时抽象，更有些时候根本无法对抽象好的业务进行代码实现。

举例来说，一个简单的问题，判断用户的一条留言到底是表扬还是批评，是有意义的还是无意义的，是应该优先展示还是应该屏蔽的，我们能够通过用户的留言提炼出什么有用信息等等问题……对于传统的软件开发来说就不是一件容易的事情，但对于大模型却是一个简单问题。

还有更多的例子可以证明，我们想要对生活中、工作中、物理世界中一些问题进行建模，让计算机协助我们来解决问题，传统的方法很困难甚至不可能，但是大模型却轻而易举，而且会越来越好。

因此从领域设计的角度来说，未来在实现核心域的过程中，一定会采用多种方式：

• 纯粹使用编程语言来实现；

• 纯粹使用提示词工程的方式来实现；

• 结合编程语言和提示词工程的方式来实现；

显然，第三种将会是趋势。

而在DDD概念中的领域，映射到大模型应用的开发中，其实正是Agent的概念。

An agent has access to a suite of tools, and determines which ones to use depending on the user input.   

Agents can use multiple tools, and use the output of one tool as the input to the next. 

注意：映射为DDD中的概念，Agent就是一个核心域，而这些tools其实都是支撑域，Agent根据核心域的逻辑来determine该如何使用各种tools完成任务。

• 围绕领域模型，通过In-Context Learning或者Fine-Tuning的方式让Agent具有领域的专业能力；
• 在接收到任务/请求之后，通过Prompt Engineering，让Agent对问题进行Planning，即进行问题拆解；
• 根据问题拆解的步骤，在需要的时候调用各种tools，来驱动解决问题；
• 在过程中，一定还会用到短期或者长期记忆；

• 从产品的角度来说，很多应用最终是需要提供一个类似PlayGround的功能的，好让用户可以对自己的提示词进行简单的测试；
• 长期来看，大模型应用的成本会一直是一个问题（这里的成本包括API成本、调用耗时等等），解决办法就是通过层层的缓存、本地小模型等方式来解决；
• 应用需要解决围绕着大模型的日志、监控等等问题（这一点在产品上可以参考这家公司[6]的做法）；

• 如何写好提示词，让大模型可以采用链式思考、树状思考甚至未来可能出现的“跳跃思考”方式解决问题，如何让大模型一步一步思考，如何剪枝，如何总结，如何进行思考迭代等等问题。
• 如何根据不同的问题，让大模型采用不同的思考方式，亦或者大模型某一天就可以进化成自己选择最合适的思考方式。
• 如果提示词更新了，要如何验证更新之后的提示词有更好的效果？
• 提示词中需要准备示例，如何知道这些示例是完备的，恰当的？
• ……

• [1]提示词课程：https://www.deeplearning.ai/short-courses/chatgpt-prompt-engineering-for-developers/
• [2]网站：https://www.promptingguide.ai/zh
• [3]论文部分：https://www.promptingguide.ai/papers
  

• [4]https://www.helicone.ai/

• [5]https://promptlayer.com/

• [6]https://dify.ai/

• [7]The Rise of the AI Engineer：https://www.latent.space/p/ai-engineer
• [8]LLM Powered Autonomous Agents：https://lilianweng.github.io/posts/2023-06-23-agent/
• [9]Emerging Architectures for LLM Applications：https://a16z.com/2023/06/20/emerging-architectures-for-llm-applications/
• ReAct (Reason+Act) prompting in OpenAI GPT and LangChain：https://tsmatz.wordpress.com/2023/03/07/react-with-openai-gpt-and-langchain/
• All You Need to Know to Build Your First LLM App：https://towardsdatascience.com/all-you-need-to-know-to-build-your-first-llm-app-eb982c78ffac
• Building LLM applications for production：https://huyenchip.com/2023/04/11/llm-engineering.html
• AI Canon：https://a16z.com/2023/05/25/ai-canon/
• OpenAI CookBook：https://github.com/openai/openai-cookbook/tree/main
• AI Glossary by a16z：https://a16z.com/ai-glossary/
• Prompt Engineering Guide：https://www.promptingguide.ai/
• Understand ReAct and How It Works in Three Minutes：https://generativeai.pub/understand-react-and-how-it-works-in-three-minutes-f5f57a404a82