1. 从“前端”到“Agent”为什么提示词工程是必经之路如果你和我一样是从前端开发或者更广泛的软件开发领域开始对AI Agent产生兴趣那么“提示词工程”这个词你大概率已经听过无数次了。它听起来像是一门玄学又像是某种魔法咒语似乎只要掌握了它就能让大模型乖乖听话变出你想要的一切。但在我真正投入时间去实践和踩坑之后我发现提示词工程远非简单的“说话的艺术”它更像是一种严谨的、可工程化的、介于人与机器之间的新型编程范式。对于前端开发者而言我们习惯了与浏览器、DOM、API和JSON数据打交道。我们的指令是精确的代码执行结果是确定性的。但与大模型LLM交互就像是在和一个能力超强但思维跳跃、背景知识庞杂的“天才实习生”合作。你不能给他一个模糊的需求说“做个登录页面”他会给你做出一个从UI到后端逻辑的完整方案但可能完全不符合你的技术栈和设计规范。你需要学会如何清晰地、结构化地“管理”这位实习生这就是提示词工程的核心价值。这个系列的第二篇我们就聚焦在应用层的提示词工程。为什么是应用层因为这是将大模型的“潜能”转化为具体“功能”的直接界面。无论你底层用的是GPT-4、Claude 3还是本地部署的Llama、Qwen最终与你开发者和用户交互的都是那一串串精心设计的提示词Prompt。它决定了你的Agent是智能高效还是答非所问。接下来我会结合大量实操经验拆解提示词工程从入门到进阶的核心心法让你能真正将其应用于Agent开发中。2. 提示词工程的核心超越“聊天”走向“工程”很多人对提示词的初体验来自ChatGPT的对话框以为就是“问问题”。但在Agent开发中这种思维是远远不够的。我们需要建立“工程化”的思维。2.1 思维转变从对话到指令编程与模型的交互不应视为一次性的问答而应视为一个持续的、有状态的指令执行过程。每一次调用模型都是一次函数执行而提示词就是调用这个函数时传入的“参数”和“执行上下文”。前端类比想象一下你调用一个fetchAPI去获取数据。你不会只传一个URL你通常会精心构造一个options对象里面包含method,headers,body等。提示词就是这个options对象。headers定义了交互的格式和角色system提示词body则包含了具体的任务描述和上下文user提示词。2.2 提示词的基本结构角色、任务、上下文、格式一个工程化的提示词通常包含以下几个明确的部分系统角色指令这是最重要的部分用于设定模型的“人格”和边界。它定义了Agent的身份、专业领域、行为准则和回答格式。示例一个代码助手Agent你是一个资深的全栈开发专家尤其精通React、TypeScript和Node.js。你的职责是分析用户需求提供简洁、高效、符合最佳实践的代码解决方案。你回答问题时首先用一句话总结核心方案然后分步骤解释关键点最后提供完整的代码块。如果用户需求不明确你会主动提问以澄清。你从不提供未经安全考虑的代码也从不编造不存在的API。为什么有效这一定义将模型从“通用聊天模式”拉入到一个特定的、专业的“上下文”中极大地约束了其输出范围和质量。用户任务描述清晰、无歧义地描述你要模型做什么。应用“SMART”原则具体的、可衡量的、可实现的、相关的、有时限的。差“帮我写个表单。”优“请创建一个React函数组件实现一个用户登录表单。包含邮箱和密码输入框邮箱需做格式验证密码输入时隐藏字符。表单提交时调用一个名为handleLogin的异步函数并传入表单数据。使用TypeScript并包含基本的样式内联或CSS Modules。请确保所有输入框都有合适的label和aria属性以实现无障碍访问。”上下文信息提供模型完成任务所需的所有背景知识。这可以是之前的对话历史、用户资料、知识库片段、当前的系统状态等。关键技巧对于长上下文要善于总结和摘录而不是一股脑全塞进去。模型有上下文窗口限制且无关信息会干扰判断。可以采用“摘要关键引用”的方式。输出格式要求明确指定你希望模型以何种结构返回信息。这对于后续的程序化处理至关重要。示例“请将分析结果以JSON格式输出包含以下字段summary字符串总结、steps字符串数组关键步骤、code字符串核心代码、warnings字符串数组潜在风险。”前端关联这直接决定了你如何解析模型的返回结果。结构化的输出JSON、XML、YAML远比一大段自然语言文本更容易被你的前端或后端代码消费。3. 高级技巧让提示词驱动复杂Agent行为基础提示词能完成简单任务但要构建能处理多步骤、有记忆、能使用工具的智能Agent我们需要更高级的模式。3.1 思维链与分步推理对于复杂问题直接要求结果往往效果不佳。引导模型“展示其思考过程”能显著提升答案的准确性和可靠性。这就是CoT。基础CoT在提示词中加入“让我们一步步思考”。用户“如果一根绳子需要30分钟烧完但绳子不均匀如何测量15分钟”优化提示“我们有一根不均匀燃烧、烧完需30分钟的绳子。目标是测量出15分钟。请逐步推理1. 绳子的特性是什么2. 我们能对绳子进行什么操作3. 如何组合这些操作来得到一半的时间”在Agent中的应用你可以设计一个“规划器”Agent其系统提示词就是要求它对任何复杂任务先进行任务分解输出一个步骤列表。然后由“执行器”Agent根据步骤列表逐步调用工具或生成代码。3.2 少样本学习在提示词中提供1-3个高质量的输入-输出示例能极快地让模型理解你想要的精确格式和逻辑。示例一个数据格式化Agent系统指令你是一个数据清洗助手负责将用户凌乱的文本描述转换为结构化的JSON。 示例1 用户输入“昨天买了苹果花了5块今天买了香蕉3块橙子4块。” 你输出{purchases: [{item: 苹果, amount: 5}, {item: 香蕉, amount: 3}, {item: 橙子, amount: 4}]} 示例2 用户输入“周一会议2小时周三写报告3小时。” 你输出{tasks: [{day: 周一, activity: 会议, duration_hours: 2}, {day: 周三, activity: 写报告, duration_hours: 3}]} 现在请处理新的用户输入“上个月读书两本《AI未来》和《黑客与画家》分别花了10天和7天。”实操心得Few-shot示例的选择至关重要。示例应覆盖常见的边界情况和格式变体。对于Agent你可以为不同的子任务如“解析日期”、“提取实体”、“分类”准备不同的Few-shot提示词模板。3.3 工具使用与函数调用现代Agent的核心能力之一是能使用外部工具API、数据库、计算器、搜索引擎。提示词需要精确地描述工具的能力和调用规范。关键模式在系统提示词中清晰定义工具。示例一个天气查询Agent的工具描述你可以使用以下工具来获取信息 工具名称get_weather描述根据城市名称查询当前天气。 参数city(字符串必需)例如 “北京”。 返回格式JSON包含temperature温度摄氏度、condition天气状况如“晴朗”、humidity湿度百分比。 调用方式当你需要查询天气时请在思考后严格按以下JSON格式输出且不要输出其他任何内容{action: call_tool, tool_name: get_weather, parameters: {city: 城市名}}前端开发者视角这本质上是在定义一套模型与你的应用后端之间的RPC协议。你的后端需要解析模型输出的这个结构化调用请求执行真正的API调用再将结果以约定的格式返回给模型让模型继续推理。流行的Agent框架如LangChain、LlamaIndex帮你封装了这部分复杂的交互逻辑。4. 实战构建一个需求分析Agent的提示词系统让我们以一个具体的场景为例一个帮助产品经理将模糊需求转化为技术用户故事User Story和前端组件树的Agent。4.1 定义Agent的系统和核心提示词模板首先我们定义这个Agent的“人设”和核心任务。系统提示词 (system_prompt):你是一个经验丰富的产品技术分析师擅长沟通和拆解需求。你的核心工作是理解用户通常是产品经理或业务方提出的模糊或高层面需求通过提问进行澄清最终将其转化为清晰、可执行的技术描述。 你必须遵循以下工作流程 1. **需求澄清**首先复述你理解的需求并主动提出最多3个关键问题以明确业务目标、用户角色、核心交互和约束条件如技术栈、 Deadline。 2. **结构化输出**在获得足够信息后输出一份结构化的分析报告格式必须为JSON包含以下字段 - user_story: 一个符合“作为[角色]我希望[功能]以便于[价值]”格式的用户故事数组。 - acceptance_criteria: 对应每个用户故事的验收标准数组Given-When-Then格式。 - frontend_components: 一个数组列出实现该需求可能涉及的前端React组件每个组件包含 name组件名和 responsibility职责描述。 - open_questions: 仍需技术或设计侧进一步确认的问题数组。 你的语气应专业、协作、乐于探究。避免使用过于技术化的黑话确保产品经理能听懂。用户提示词模板 (user_prompt_template):原始需求{user_input} 当前已知上下文 - 技术栈{tech_stack} (例如React 18, TypeScript, Ant Design) - 项目类型{project_type} (例如后台管理系统、C端官网) - 相关历史需求链接{related_links}4.2 实现多轮对话与状态管理一个需求分析不可能一轮完成。我们需要管理对话历史上下文。实现方案将每一轮的system_prompt、user_prompt和模型的assistant_response都保存下来。在下一轮对话时将整个历史记录或最近N轮以节省Token作为新的上下文发送给模型。在user_prompt中明确指出当前轮次的目标例如“这是对你上一轮问题的回答[用户的回答]。请基于我们之前的对话和这些新信息更新你的结构化分析报告。”前端/后端协作点这里的状态管理很像一个聊天应用。前端需要维护会话列表和当前会话的消息历史。后端在调用大模型API前负责组装完整的历史消息数组。需要注意的是长上下文会消耗更多Token和计算资源且可能降低模型对最近信息的关注度因此实现一个智能的“上下文窗口滑动”或“摘要”机制是高级课题。4.3 集成工具调用进阶为了让Agent更强大我们可以让它能调用一些工具来辅助分析。扩展系统提示词...原有系统提示词... 此外你可以使用以下工具查询组件库如果你不确定某个UI交互如何实现或想确认现有组件库中是否有可用组件可以调用此工具。 工具名search_component_lib参数keyword(字符串搜索关键词)估算复杂度对初步拆解出的功能进行粗略的故事点估算仅供内部参考。 工具名estimate_story_points参数complexity(字符串可选值low,medium,high,very_high)交互流程模型在思考过程中可能会输出类似{action: call_tool, tool_name: search_component_lib, parameters: {keyword: data table with filter}}的指令。你的后端程序需要拦截这个输出调用真实的组件库搜索API然后将结果例如{found: true, component_name: ProTable, docs_url: ...}以“工具调用结果”的身份插入对话历史再让模型基于这个结果继续分析。5. 提示词工程的常见陷阱与调优心得在实际开发中你会遇到各种各样的问题。以下是我踩过坑后总结的一些经验。5.1 陷阱一提示词过于冗长或模糊问题把所有的约束、例子、格式都塞进一个提示词导致模型抓不住重点或者上下文被无关信息污染。解决方案遵循“单一职责”原则。为不同的子任务设计不同的、精炼的提示词。使用清晰的章节标题如## 角色、## 任务、## 输出格式来帮助模型解析。将长篇示例或知识库内容通过RAG检索增强生成技术动态注入而非静态写入提示词。5.2 陷阱二忽视模型的“幻觉”问题问题模型可能会自信地编造不存在的API、函数或事实。解决方案在系统提示词中强约束“如果你不确定请明确说明‘根据现有信息无法确定’而不要猜测。”提供参考依据在上下文中提供准确的文档片段、代码示例或数据并要求模型基于此回答。后置校验对于关键输出如代码、命令设计一个简单的校验步骤如语法检查、运行测试或让另一个Agent进行交叉验证。5.3 陷阱三格式输出不稳定问题即使要求输出JSON模型有时也会在JSON前后加上解释性文字破坏解析。解决方案使用分隔符要求模型将输出放在特定的标记之间如json ...。利用模型的高级功能使用OpenAI的function calling或Anthropic Claude的tool use等原生结构化输出功能它们比纯文本提示更稳定。后处理与重试编写健壮的解析器如果第一次解析失败可以提取文本中类似JSON的部分进行修复或者将错误信息和原始提示重新发送给模型要求它纠正。5.4 调优心得迭代与评估提示词工程是一个高度迭代的过程。建立评估集收集一批具有代表性的输入用例Edge Cases很重要。定义评估标准准确度、完整性、格式符合度、有用性。A/B测试对提示词的微小改动如调整措辞、交换示例顺序、增加一个约束条件进行测试观察输出变化。自动化测试对于核心的Agent流程可以编写简单的集成测试用固定的输入断言输出的关键字段确保提示词的修改不会导致回归。从前端视角看调试提示词很像调试一个逻辑复杂但日志不清晰的函数。你需要精心设计“输入用例”仔细观察“输出结果”并不断调整“函数内部逻辑”即提示词直到它在各种边界情况下都能表现稳定。这个过程没有银弹需要的是耐心、实验和大量基于真实反馈的迭代。当你掌握了这些你就真正握住了驱动AI Agent行为的缰绳。