引言:AI应用开发,究竟是开发什么?
谈到AI应用开发,我们首先要意识到一个问题就是大模型本质上是黑盒的,它通过千亿级的参数、海量的数据与巨量的算力训练而成,一旦训练完成,其内部运作机制便如同一个封装好的精密仪器,难以直接窥探与修改。常说的“微调”远非字面意义上的轻松调整,它需要高昂的计算成本与专业的技术门槛,本质上是对模型的一次“重塑”。
既然无法轻易改变这个“黑盒”,那么开发者究竟在开发什么?答案是:通过精心设计“输入”,来精准引导和塑造我们所期望的“输出”。
举一个例子:当我们直接问“今天天气怎么样”模型可能只回答天气概况。但是如果我们在问题给大模型加一些定语:“你是一位资深气象播报员,请用生动、专业且包含出行建议的风格,描述以下地点的天气情况:[北京]”,你将得到一个完全不同的、更具有价值且符合用户所需要的答案。
由此可见,AI应用开发的核心其实是围绕其“输入-输出”机制进行系统性构建,这便引出了AI应用开发的两大基石:Prompt Engineering(提示词工程) 与 Context Engineering(上下文工程)。前者专注于优化单次交互的“提问艺术”,后者则致力于设计和管理多轮对话乃至复杂任务的“系统流程”。
Prompt Engineering
Prompt本质
这个概念简单来说其实就是如何与大模型进行互动,普通人直接通过大模型拿不到自己想要的答案往往是因为他们把大模型当成了一个人,以为简单的问问题就可以拿到我们想要的答案。而我们作为研发者,应该意识到,我们的目标是通过精心设计的输入,将模型庞杂的通用能力,约束和引导至解决特定问题的轨道上。
Prompt的核心结构:工程化的五要素
一个优秀的Prompt不应是随意的提问,而应是一份清晰、无歧义的任务说明书。它可以系统地解构为以下五个关键要素,这确保了AI能明确理解“谁来做、做什么、在什么条件下做以及交付什么”。
| 结构要素 | 核心作用 | 关键设计要点与示例 |
|---|---|---|
| 1. 角色 | 设定模型的“人格”与专业视角,从根本上锁定其回答的知识范围、思维方式和语言风格。 | 要点:越具体,效果越好。 • 弱:“帮我写点文案。” • 强:“你是一位专注于高端护肤品牌的资深社交媒体文案策划,擅长使用优雅、富有感染力的语言,并巧妙融入成分科普。” |
| 2. 任务 | 定义需要完成的具体、可执行的行动。这是Prompt的核心指令,必须清晰、无歧义。 | 要点:使用行动性动词,明确任务边界。 • 模糊:“处理一下这段代码。” • 清晰:“重构以下Python函数,提高其可读性,并添加详细的文档字符串。” |
| 3. 上下文 | 提供任务相关的背景信息和知识。为模型补充其训练数据之外或未明确指明的关键情况,是保证回答相关性和准确性的基础。 | 要点:提供完成任务所必需但模型可能不知道的信息。 • 代码任务:提供相关的类定义、API文档链接。 • 方案设计:提供项目背景、用户画像、技术栈限制。 |
| 4. 约束 | 规定任务执行中必须遵守的规则和限制。用于排除不希望出现的结果,确保输出符合特定标准。 | 要点:明确列出“必须”和“禁止”的事项。 • 格式:“必须使用Markdown表格呈现。” • 风格:“禁止使用任何营销套话。” • 规则:“所有建议必须符合《网络安全法》。” |
| 5. 输出格式 | 定义最终结果的呈现形式。这极大地简化了后续对AI输出结果的处理和集成流程。 | 要点:指定明确、可解析的格式。 • 数据:“输出一个JSON对象,包含‘summary’和‘key_points’两个字段。” • 文档:“以标准的GitHub Flavored Markdown格式输出。” • 可视化:“用Mermaid语法生成一个序列图。” |
为什么这个框架更优
这个五要素框架超越了早期的技巧性总结,体现了 “工程化” 思维:
- 全面性:它涵盖了从身份设定到成果交付的完整闭环。
- 可组装性:每个要素都像一个独立的模块,可以根据任务复杂度进行组合或细化。例如,一个简单的任务可能只需要角色和任务,而一个复杂项目则需要全部五个要素的详细说明。
- 可调试性:当输出不理想时,你可以沿着这五个维度逐一检查,快速定位问题所在(例如,是“角色”不够具体,还是“约束”条件缺失),从而进行针对性优化。
示例
任务: 为一个新的API功能撰写开发文档。
普通提问: “怎么写API文档?”
结构化Prompt(使用五要素框架):
【角色】
你是一位经验丰富的后端技术文档工程师,尤其精通OpenAPI规范。
【任务】
为以下新编写的“用户查询”API端点撰写公开文档。
【上下文】
1. 项目背景:这是一个企业级用户管理系统(UMv2)。
2. 接口定义:
- 端点:`GET /api/v2/users/{id}`
- 认证:需要Bearer Token
- 成功响应(200):`{"id": "string", "name": "string", "email": "string", "created_at": "ISO8601"}`
- 错误响应(404):`{"error": "User not found"}`
【约束】
1. 文档必须遵循“用途 -> 请求 -> 响应 -> 错误码 -> 示例”的逻辑顺序。
2. 语言简洁专业,避免主观评价。
3. 必须包含一个完整的cURL调用示例。
【输出格式】
请输出格式良好的Markdown文档,包含必要的标题、代码块和表格。
Meta Prompt
Meta通过使用一个更高阶的、用于生成Prompt的Prompt来进行Prompt的生成。
可以通过官网的内容来尝试一下:platform.openai.com/docs/guides…
Context Engineering
Context Engineering本质
简单来说就是我们的目标从“回答问题”升级到了“完成任务”。它不再只关注用户当前的一句话,而是统筹管理整个交互环境中的所有信息流。这标志着范式从“单次交互优化”转向了 “系统级智能构建”。
上下文工程为模型搭建了一个强大的“工作台”,其四大支柱共同支撑起复杂的AI智能体:
- 记忆管理:区分短期记忆(对话历史)和长期记忆(跨会话的向量化存储),让模型“记得住事”。
- 知识增强:以检索增强生成技术为核心。当模型知识不足时,实时从外部知识库检索最新信息并融入上下文,从根本上缓解幻觉问题,让答案有据可查。
- 思考框架:将CoT等推理模式与工具调用结合,形成更强大的范式,如ReAct。它让模型学会自主决策:“我现在需要查资料”(思考),然后调用搜索API(行动),最后根据返回结果进行下一步推理。
- 工具调用:为模型赋予“手脚”,使其能执行计算、查询数据库、控制外部设备,能力边界从语言扩展到行动。
与Prompt Engineering对比
| 比较维度 | Prompt Engineering | Context Engineering |
|---|---|---|
| 主要目标 | 获取特定的、一次性的响应 | 确保系统在不同会话和用户间表现一致、可靠 |
| 核心动作 | 创意写作、措辞优化(wordsmithing) | 系统设计、LLM应用软件架构 |
| 范围 | 单个输入-输出对 | 整个信息流,包括记忆、工具、历史记录 |
| 模式 | 制作清晰的指令 | 设计模型的完整思考流程 |
| 扩展性 | 脆弱,难以扩展到多用户和多场景 | 从设计之初就为规模化和可重用性而构建 |
| 所需工具 | 文本编辑器、聊天机器人界面 | RAG系统、向量数据库、API链、记忆模块等等 |
| 调试方法 | 重写措辞、猜测模型意图 | 检查完整的ContextWindow、数据流、Token使用情况 |
架构层面:从思维链到智能体协作
当我们与大型语言模型对话时,得到的答案质量,早已不单单取决于模型本身的能力,更取决于我们如何“引导”它思考。过去几年,AI应用开发的核心战场,正是这场引导艺术的持续革命——从雕琢一句话的技巧,演进为设计一整套思考和工作流程的系统工程。
这场演进的主线,清晰地围绕 “如何让模型更好地思考与行动” 展开。我们可以将其归纳为三大领域的齐头并进与交叉融合:思考框架的深化、工作流与系统集成的成熟,以及智能体范式的升维。
起源: CoT (显化思考“过程”)
早期,我们惊讶地发现,仅仅要求模型 “一步步思考” ,就能显著提升其在数学、推理等复杂任务上的表现。这便是思维链 的开创性启示:将推理过程显式化,能激活模型更深层的逻辑能力。
它是什么
CoT 不是模型的内置功能,而是一种提示技巧。通过在提示词中展示或要求“逐步推理”,我们激活了模型在训练中学到的逻辑关联能力,使其模仿人类解决问题时的内隐思维流。
一个经典对比
- 标准提示: “小明有5个苹果,吃了2个,又买了3个,他现在有几个?”
- 模型可能直接输出: “6个”。(可能对,也可能错,过程不透明)
- CoT提示:“小明有5个苹果,吃了2个,又买了3个,他现在有几个?让我们一步步思考。”
- 模型输出: “首先,小明一开始有5个苹果。然后他吃了2个,所以剩下 5 - 2 = 3 个。接着他又买了3个,所以现在有 3 + 3 = 6 个。因此,小明现在有6个苹果。”
为什么是革命性的
可解释性:推理过程变得可见,用户可以检查逻辑是否正确。
性能跃升:在算术、常识推理、符号推理等任务上,CoT 将大模型的性能(尤其是对大规模模型)提升到了前所未有的高度,甚至在某些基准上追平了人类表现。
启发了新范式:它证明,引导模型的“思考过程”比仅仅询问“思考结果”更有效。这为所有后续的思考框架打开了大门。
发展:ReAct (思考&行动)
CoT 解决了“如何想”的问题,但它的思考完全基于模型固有的知识。如果问题需要外部信息(如实时数据、专业知识)怎么办?ReAct框架应运而生。
它是什么
将 Reasoning(推理)与 Action(行动)交织在一起,形成一个动态循环。模型不仅要“想”,还要知道自己“缺什么”,并通过工具调用去“获取”。
基本模式
思考 -> 行动 -> 观察 -> 再思考…
- 思考:分析当前情况,决定下一步需要做什么或知道什么。
- 行动:执行一个具体动作,如调用搜索引擎、查询数据库、使用计算器。
- 观察:获取行动的结果(如搜索到的信息、查询到的数据)。
- 循环:基于观察到的结果,进行下一轮思考。
一个简单示例:
任务:“截至今天,苹果公司的最新市值是多少?将其换算成欧元。”
ReAct流程:
- 思考:要回答这个问题,我需要先查找苹果公司的最新市值。
- 行动:调用
search_web("Apple Inc. current market cap")。 - 观察:获取结果“约2.6万亿美元”。
- 思考:现在我有了美元市值,需要当前的美元兑欧元汇率。
- 行动:调用
get_exchange_rate("USD", "EUR")。 - 观察:获取结果“1 USD = 0.92 EUR”。
- 思考:计算 2.6万亿 * 0.92 = 2.392万亿欧元。
- 最终答案:苹果公司最新市值约为2.392万亿欧元。
ReAct 将LLM从一个“静态的知识库”升级为一个可以主动利用工具获取信息、解决问题的智能体,标志着AI从“回答问题”迈向“完成任务”。
深化:更细致的规划&执行
在CoT和ReAct的基础上,研究朝着更自主、更可靠的方向发展。
自我反思
为解决模型在推理中可能出现的错误,引入了Self-Refine等框架。模型在生成初始答案后,会基于一套标准(如逻辑一致性、事实正确性)对自己进行批判性审查,发现问题后重新生成答案。这形成了一个生成 -> 批判 -> 修正的内循环,大幅提升了输出的准确性和鲁棒性。
自主研究
这是当前思考框架的前沿,代表是 Deep Research、AutoGPT 等模式。此时,模型面对的已不是一个具体问题,而是一个宏观的开放性目标。
-
目标:“分析量子计算在药物发现领域的最新进展、主要挑战和未来五年的市场前景。”
-
模型行为:
- 自主规划:分解目标为子任务(搜索学术论文、查找行业报告、汇总技术瓶颈、分析投资趋势)。
- 动态执行:在多个工具(学术数据库、搜索引擎、专业网站)间循环执行ReAct流程,收集信息。
- 综合研判:对收集到的、可能相互矛盾的信息进行交叉验证、总结和整合。
- 生成报告:最终产出一份结构化的深度分析报告。
至此,思考框架完成了从“展示步骤”到“调用工具”再到“自主规划与探索”的三级跳。
| 阶段 | 代表性框架 | 核心突破 | AI角色类比 | 关键限制 |
|---|---|---|---|---|
| 展示思考 | 思维链 | 将推理过程显式化,提升复杂任务性能 | 一个展示解题步骤的学生 | 思考基于内部固有知识,无法获取新信息。 |
| 思考与行动 | ReAct | 将推理与工具调用结合,形成感知-行动闭环 | 一个会使用计算器和百科全书的分析师 | 通常需人类预设任务流程,自主规划能力有限。 |
| 自主规划 | Deep Research | 能对开放性目标进行任务分解、动态规划和深度信息整合 | 一个自主领导研究项目的项目经理 | 执行成本高,可能陷入循环或偏离目标,需谨慎监督。 |
能力层面
RAG-知识增强
解决了什么问题
从我们的引言我们可以知道大模型一旦训练出来他就定型了,也就是它的知识储备停留到了训练完成的那一秒。所以,如何让模型在回答时,能动态参考最新、最准确的专有知识?
答案:检索增强生成。它不是一个模型,而是一个将信息检索与文本生成相结合的系统架构。
工作流程
- 索引:将您的专有文档(PDF、数据库、网页)拆分成块,转换为向量嵌入,存入向量数据库。
- 检索:当用户提问时,将问题也转换为向量,在数据库中检索语义最相关的文本块。
- 增强:将检索到的相关文本块,作为“参考依据”插入到提交给大模型的Prompt上下文中。
- 生成:模型基于提供的“参考依据”生成回答,并要求注明出处。
本质与价值
- 本质:为大模型外接了一个“实时、可更新的知识库”。
- 价值:让回答有据可查,极大减少幻觉;使模型能够处理训练数据之外的、私有的、最新的知识。这是企业级AI应用(如智能客服、知识库问答)的基石技术。
记忆系统
解决了什么问题
大模型本质是“无状态的”,每次对话都是独立的。如何让AI记住对话历史、用户偏好和长期目标,实现连续、个性化的交互?
答案:设计分层级的记忆系统。
短期记忆
通常指对话历史。直接将最近的若干轮问答以文本形式保留在上下文窗口内,是最基础的记忆形式。
长期记忆
当对话轮次或信息量超出上下文窗口时,需要将关键信息持久化存储。
- 实现方式:通常使用向量数据库。将对话中的关键实体、事实或用户画像转换为向量存储。在需要时(如新对话开始),通过语义检索,将相关记忆“召回”并注入当前上下文。
- 类比:短期记忆像电脑的运行内存;长期记忆则像硬盘,需要时可加载到内存中。
本质与价值
- 本质:为无状态的模型赋予状态。
- 价值:是构建个性化AI助手、实现多轮复杂任务(如一周内持续规划一个项目)的必备前提。它让AI从“单次应答机”变为“持续协作的伙伴”。
工具调用与集成
解决了什么问题
大模型不会算数、不能查数据库、无法控制外部设备。如何扩展其能力边界,让它不仅能“说”,还能“做”?
答案:为模型提供一套可调用的工具API,并教会它何时及如何使用。
演进路径
- 早期硬编码:开发者手动编写代码,根据关键词判断何时调用哪个工具,流程僵化。
- 函数调用:大模型自身学会了根据用户请求,输出一个符合格式的函数调用请求(如
{"name": "get_weather", "arguments": {"city": "北京"}})。后端收到后执行函数并返回结果,再将结果交给模型生成最终回复。这构成了ReAct框架的核心执行层。 - MCP:模型上下文协议。这是最新的演进方向。它定义了一套工具与模型之间通信的通用标准。任何符合MCP标准的工具(计算器、代码解释器、企业内部API)都能像即插即用的USB设备一样,被模型动态发现和调用,无需为每个工具编写专用代码。
本质与价值
- 本质:为AI装上“手和脚”,连接数字世界与现实世界。
- 价值:将LLM从“语言大脑”升级为能够执行具体任务的 “智能体核心” 。MCP这类协议的出现,使得构建庞大、动态的工具生态成为可能。
总结
回顾Prompt Engineering与Context Engineering的发展历程,本质上是将人类高阶思维模式(分步推理、工具使用、反思规划、社会协作)通过编码赋予大模型的过程。也就是让大模型学会像人类一样思考问题