上周我花了一个下午和一个晚上试图让一个基于 Claude 的智能体Agent项目跑起来。项目本身很吸引人号称能处理复杂的多步骤任务但启动后它要么卡在第一步要么给出一些看似合理但完全偏离目标的回答。我检查了代码、环境、API Key一切正常。问题出在哪直到我把目光投向那个看似不起眼的system prompt系统提示词。那一刻我意识到我们可能都低估了system prompt的力量。在追逐更强大的模型如 Claude 3.5 Sonnet、Opus和更精巧的 Agent 框架时我们常常把system prompt当作一个简单的“角色设定”或“功能说明”写上一两句就完事。但恰恰是这个最基础的部分决定了你的 Agent 是能精准执行任务的得力助手还是一个只会说“我理解你的需求”的复读机。这次修复 Opus 5一个假设的或泛指基于 Claude 的复杂任务处理项目的经历让我重新审视了 Prompt Engineering。它远不止是“如何问问题”而是一套关于如何与模型建立有效“沟通契约”的工程方法。这篇文章我想和你分享的不是某个具体的system prompt模板而是如何构建一个能让 Agent 真正“理解”并“可靠执行”的底层指令系统。1. 为什么你的 Agent 总在“跑偏”问题往往不在模型而在沟通当你发现 Claude 或类似的模型 Agent 表现不佳时第一反应往往是“是不是模型不够强”或者“这个框架是不是有 Bug”。但在大多数非代码错误的场景下问题的根源更可能在于模糊的指令和缺失的上下文边界。1.1 从“角色扮演”到“精确的岗位说明书”我们通常这样写system prompt“你是一个有帮助的 AI 助手。”或者稍微好一点“你是一个资深的软件开发专家。”这就像在招聘时只说“我们需要一个会写代码的人。” 结果来的人可能擅长前端、后端、算法但未必是你需要的 DevOps。对于 AI 模型尤其是承担多步骤任务的 Agent这种模糊的角色定义是灾难的开始。一个有效的system prompt应该是一份精确的岗位说明书它需要明确核心职责你具体要它做什么例如分析代码仓库、提取特定模式、生成报告工作边界什么是你必须做的什么是你不能做的例如只读取src/目录下的.py文件不修改任何原始文件交付标准输出的格式、详细程度、风格是什么例如以 Markdown 表格形式列出包含文件名、函数名和问题描述三列协作方式你希望它如何思考和工作例如先规划步骤再逐步执行遇到不确定时主动询问1.2 理解模型的“思维过程”它需要被引导而非被命令大型语言模型LLM没有真正的“思考”但它会根据你提供的上下文Context和指令Prompt模拟出一个合理的“思维链”。一个糟糕的system prompt会让这个“思维链”从一开始就偏离轨道。例如你让 Agent “优化这段代码”。一个模糊的指令下模型可能会理解为“让代码更短”于是删掉所有注释和空行。理解为“提高性能”于是引入复杂的缓存机制但可能引入 Bug。理解为“符合 PEP 8”只调整了格式。而一个清晰的system prompt会引导它“你是一个 Python 代码优化专家。你的目标是提升代码的可读性和维护性同时保持功能不变。请按以下顺序工作1) 分析现有代码的逻辑和结构2) 识别重复代码块建议提取为函数3) 检查变量命名是否清晰4) 添加必要的文档字符串Docstring5) 确保符合 PEP 8 规范。最后输出优化后的代码并用注释标出你所做的每一处修改及其原因。”后者为模型构建了一条清晰的“思考路径”大幅降低了它“自由发挥”导致跑偏的概率。1.3 常见症状与system prompt缺陷的对应关系你可以通过 Agent 的表现反向诊断system prompt的问题Agent 表现症状可能的system prompt缺陷答非所问做多余的事职责定义模糊缺乏明确的工作边界。输出格式混乱不统一没有规定交付物的具体格式和标准。遇到复杂任务直接放弃或出错缺少分步执行的引导和错误处理预期。风格时而严肃时而随意没有设定统一的语气和风格要求。对于模糊需求给出过于宽泛的回答没有要求模型在不确定时主动澄清或提供选项。修复 Opus 5 的过程本质上就是一次针对这些症状的系统性诊断和system prompt重构。2. 构建稳健system prompt的四层结构法经过多次迭代我总结出一个四层结构法来构建system prompt。这四层像洋葱一样从内核到外层逐层约束和引导模型的行为。2.1 第一层核心身份与终极目标The Core这是模型的“灵魂”。用一句高度凝练的话定义它最根本的存在意义。错误示例“你是一个 AI。”普通示例“你是一个代码助手。”优秀示例“你是一个以生成安全、高效、可维护的生产级代码为最高准则的 AI 工程师。”为什么重要这一层设定了模型所有决策的“北极星”。当面临权衡时比如是写更短的代码还是更易读的代码它会依据这个终极目标进行判断。2.2 第二层核心职责与绝对禁令The Rules这一层定义具体的工作范围和不可逾越的红线。要具体、可操作。职责“你的主要职责是进行代码审查、重构建议和生成模块化的函数。”“你专注于处理用户提供的{特定类型}数据并输出{特定格式}的分析报告。”禁令“你绝不能修改或删除用户提供的原始输入数据。”“你绝不能假设或编造超出给定上下文的信息。如果信息不足你必须明确指出。”“你绝不能在一个回复中混合多种不相关的任务主题。”写作技巧使用“必须”、“绝不”、“始终”、“优先”等强语气词减少歧义。2.3 第三层工作流程与思维框架The Process这是引导模型“如何思考”的关键。为复杂任务设计一个默认的思维框架。对于分析任务“面对任务时请遵循理解目标 - 拆解问题 - 分步分析 - 汇总结论 - 给出建议 的流程。”对于生成任务“在创作内容时请先构建大纲然后填充细节最后进行连贯性和风格检查。”对于交互任务“在对话中如果你需要更多信息才能继续请一次性、清晰地列出所有你需要澄清的点。”你可以把这个框架直接写给模型例如“请按以下步骤处理每个查询1)解析确认你理解的任务核心是什么。2)规划在心里或简单列出完成任务的子步骤。3)执行按步骤工作并检查每一步的输出。4)交付以清晰、结构化的方式呈现最终结果。”2.4 第四层输出规范与风格指南The Format这是模型的“出厂设置”确保交付物的一致性。格式“所有代码块请使用语言标记。所有关键结论请使用无序列表-列出。”风格“保持专业、简洁、积极的语气。避免使用‘可能’、‘也许’等不确定词汇用‘建议’、‘推荐’代替。”结构化“对于任何包含多个项目的回答请优先使用 Markdown 表格。”交互“如果你的回答包含多个部分请使用##标题进行分隔。”将这四层组合起来就是一个强大的system prompt骨架。例如一个用于“技术文档分析”的 Agent 可能拥有这样的system prompt核心你是一个专注于从复杂技术文档中精准提取架构信息和 API 规约的 AI 分析师。 规则你必须严格基于提供的文档内容进行分析绝不臆测。你的输出必须是事实性陈述。 流程对于每份文档你的工作流程是1) 通读识别文档类型和核心章节2) 提取所有提到的系统组件、数据流和接口定义3) 将提取的信息归类到‘架构图组件’、‘API 端点’、‘数据模型’三个表中。 格式最终请以 Markdown 格式输出这三个表格。每个表格包含‘名称’、‘描述’、‘所在章节’三列。不使用任何引言和总结性段落。3. 从单次对话到持续协作让 Agent 记住“上下文”一个复杂的项目如 Opus 5往往不是一次问答就能完成的。它涉及多轮交互、状态维持和渐进式构建。这时仅仅有一个好的初始system prompt还不够你需要管理好对话上下文Context。3.1 上下文是模型的“短期记忆”模型没有真正的记忆。它每次生成回复所依赖的“记忆”就是当前对话窗口中你提供的所有文本即上下文窗口如 Claude 的 200K 上下文。system prompt、历史对话、你的新问题共同构成了它这次“思考”的全部材料。常见误区假设模型记得之前说过的话如果你在第十轮对话中问“那我们刚才说的第一个方案是什么”模型其实是在整个上下文里搜索“第一个方案”这个词组而不是真的“回忆”。如果上下文很长或表述方式变了它可能找不到。在长对话中丢失核心指令随着对话轮数增加最初的system prompt可能会被“挤”到上下文窗口的远端模型对其的“注意力”可能下降导致行为漂移。3.2 策略一关键信息重复与摘要对于需要贯穿始终的核心规则或目标不要只在开头说一次。在关键节点重申在开始一个新阶段的任务时可以简要重申目标。“我们现在开始执行第一阶段的数据清洗请记住核心目标是保证数据一致性而不是追求数量。”让 Agent 自己摘要在完成一个复杂步骤后可以要求 Agent 对当前状态和下一步计划做一个简短摘要。这既能确认它的理解又能将重要信息以新的形式注入上下文。3.3 策略二结构化上下文与“黑板”模式对于超长、复杂的任务可以将上下文结构化。设立“工作区”在对话中明确划分出“原始需求”、“当前进展”、“待解决问题”、“决策记录”等区块。你可以用明显的标记如## 决策记录 ##来分隔。使用“黑板”模式将最重要的、不可变的指令如核心规则、输出格式始终放在每次提问的最前面或一个固定的位置。有些高级用法会将system prompt的一部分作为“元指令”在每轮交互中隐性传递。3.4 策略三重置与分段执行当对话已经非常冗长且你感觉到 Agent 开始“胡言乱语”或忘记初衷时最有效的方法往往是开启一个新对话。分段执行将一个大任务拆分成几个逻辑上相对独立的子任务。完成一个子任务后开启一个新对话窗口将上一个任务的最终结果而不是全部聊天记录和新的system prompt一起输入开始下一个子任务。好处这保证了每个阶段 Agent 都在一个“干净”且专注的上下文中工作避免了长期对话带来的噪音积累和性能下降。在修复 Opus 5 时我发现最初的设计试图在一个超长对话中完成所有事导致后期指令失效。将其重构为“初始化配置 - 任务A - 任务B - 结果汇总”四个清晰的会话阶段后稳定性和输出质量立刻大幅提升。4. 高级技巧用 Prompt Engineering 应对边界情况与提升可靠性即使有了完美的四层system prompt和上下文管理Agent 在实际运行中仍会遇到边界情况。这时需要更精细的 Prompt Engineering 技巧。4.1 为“不确定性”设计逃生舱模型遇到模糊或信息不足时默认行为可能是猜测这很危险。你应该在system prompt中明确告诉它如何应对。“如果你对用户请求的任何部分存在不确定性或者需要额外的信息才能做出可靠输出你必须立即停止假设并清晰地列出你需要澄清的所有具体问题。在获得澄清前不要继续执行核心任务。”4.2 引入“链式验证”Chain-of-Verification对于关键输出尤其是涉及事实、数据或逻辑的可以要求模型进行自我验证。“在你给出最终答案前请执行一次自我验证1) 检查答案中的每一个关键事实是否都能在提供的上下文中找到依据。2) 检查逻辑推理步骤是否完整且无矛盾。3) 将验证结果以[验证]开头附在最终答案之后。”这相当于让模型在输出前“再想一遍”虽然不能保证100%正确但能显著减少低级错误。4.3 利用“少样本学习”Few-Shot Learning在system prompt或对话开头提供一两个输入输出的完美示例。这对于规范复杂输出格式特别有效。你的任务是将自然语言描述转换为 JSON 配置。 示例1 输入“创建一个用户名字叫张三年龄30角色是管理员。” 输出{action: create_user, parameters: {name: 张三, age: 30, role: admin}} 示例2 输入“查询所有状态为活跃的订单。” 输出{action: query_orders, filters: {status: active}} 现在请处理新的输入模型会强烈地倾向于模仿示例的结构和风格。4.4 控制“创造力”与“保守度”通过指令调节模型的“性格”。需要创造性时“请探索多种可能性并提供最具创新性的解决方案。”需要保守可靠时“请严格遵循最佳实践和行业标准优先选择经过验证的、稳健的方案。”需要严谨推理时“请逐步展示你的思考过程确保每一步都有据可依。”在 Opus 5 这类偏向工程和执行的 Agent 中我通常会将“保守”和“严谨”的权重调高。5. 实战将理论应用于 Agent 开发与调试理论最终要服务于实践。当你开发或调试一个 AI Agent 时可以遵循以下流程来运用上述 Prompt Engineering 原则。5.1 开发阶段从最小可行 Prompt 开始迭代定义 MVP最小可行产品目标你的 Agent 最核心、最单一的功能是什么先把它做好。编写初版system prompt运用四层结构法但先聚焦核心层和规则层。流程和格式可以简单点。设计测试用例准备 3-5 个典型的、边界清晰的输入用例。运行与观察用测试用例运行 Agent不要只看最终输出要观察它的整个“思考”过程如果框架支持中间步骤输出。分析偏差输出不符合预期时是目标不清、规则不严、流程混乱还是格式问题对照四层结构定位。迭代 Prompt修改system prompt解决上一步发现的问题。一次只修改一个方面并重新测试。扩展与泛化核心功能稳定后再逐步增加更复杂的流程、更丰富的格式要求并用更多样化的用例测试。5.2 调试阶段系统性排查清单当现成的 Agent如你遇到的 Opus 5表现失常时按此清单排查检查输入我提供给 Agent 的初始指令或用户输入是否清晰、无歧义是否包含了所有必要信息审查 System Prompt这是重点它的四层结构完整吗规则是否有漏洞流程是否适用于当前任务格式要求是否明确审查上下文当前对话是否过长关键的system prompt或早期指令是否已被淹没是否有无关信息干扰测试简化场景用一个极其简单、确定的任务测试 Agent。如果简单任务也失败问题可能出在框架或 API 连接上。如果简单任务成功复杂任务失败则问题在于 Prompt 对复杂性的处理能力不足。分步验证如果 Agent 支持分步执行手动将复杂任务拆开一步步喂给它看它在哪一步开始偏离。查看日志如果框架提供了 Agent 的“思考”日志或对模型的原始调用记录仔细阅读。你可能会发现模型接收到的 Prompt 和你想象的不一样框架可能会做拼接或修改。5.3 长期维护将 Prompt 视为核心资产版本化像管理代码一样管理你的system prompt。使用 Git为每次重大修改添加注释。文档化为复杂的system prompt写内部文档解释每一部分的设计意图和对应的测试用例。监控与评估定期用一组固定的测试用例评估 Agent 的表现监控其输出质量是否有“漂移”。持续迭代随着模型更新、业务变化或遇到新的边界情况不断优化你的 Prompt。修复 Opus 5 的过程本质上就是一次深入的 Prompt Engineering 实践。它让我明白在 AI 应用开发中编写system prompt不是一项前期的一次性工作而是一项贯穿始终的核心工程活动。模型的潜力就像一个强大的引擎而精心设计的 Prompt 就是精准的传动系统和方向盘。没有后者再强的引擎也无法让车辆驶向正确的目的地。下一次当你对 Agent 的表现感到沮丧时不妨先别急着换模型或改代码沉下心来重新审视并精心雕琢那个最基础的system prompt。你会发现很多时候答案就藏在最开始的几句“对话”里。
AI Agent系统提示词设计：从模糊指令到精准工程实践
上周我花了一个下午和一个晚上试图让一个基于 Claude 的智能体Agent项目跑起来。项目本身很吸引人号称能处理复杂的多步骤任务但启动后它要么卡在第一步要么给出一些看似合理但完全偏离目标的回答。我检查了代码、环境、API Key一切正常。问题出在哪直到我把目光投向那个看似不起眼的system prompt系统提示词。那一刻我意识到我们可能都低估了system prompt的力量。在追逐更强大的模型如 Claude 3.5 Sonnet、Opus和更精巧的 Agent 框架时我们常常把system prompt当作一个简单的“角色设定”或“功能说明”写上一两句就完事。但恰恰是这个最基础的部分决定了你的 Agent 是能精准执行任务的得力助手还是一个只会说“我理解你的需求”的复读机。这次修复 Opus 5一个假设的或泛指基于 Claude 的复杂任务处理项目的经历让我重新审视了 Prompt Engineering。它远不止是“如何问问题”而是一套关于如何与模型建立有效“沟通契约”的工程方法。这篇文章我想和你分享的不是某个具体的system prompt模板而是如何构建一个能让 Agent 真正“理解”并“可靠执行”的底层指令系统。1. 为什么你的 Agent 总在“跑偏”问题往往不在模型而在沟通当你发现 Claude 或类似的模型 Agent 表现不佳时第一反应往往是“是不是模型不够强”或者“这个框架是不是有 Bug”。但在大多数非代码错误的场景下问题的根源更可能在于模糊的指令和缺失的上下文边界。1.1 从“角色扮演”到“精确的岗位说明书”我们通常这样写system prompt“你是一个有帮助的 AI 助手。”或者稍微好一点“你是一个资深的软件开发专家。”这就像在招聘时只说“我们需要一个会写代码的人。” 结果来的人可能擅长前端、后端、算法但未必是你需要的 DevOps。对于 AI 模型尤其是承担多步骤任务的 Agent这种模糊的角色定义是灾难的开始。一个有效的system prompt应该是一份精确的岗位说明书它需要明确核心职责你具体要它做什么例如分析代码仓库、提取特定模式、生成报告工作边界什么是你必须做的什么是你不能做的例如只读取src/目录下的.py文件不修改任何原始文件交付标准输出的格式、详细程度、风格是什么例如以 Markdown 表格形式列出包含文件名、函数名和问题描述三列协作方式你希望它如何思考和工作例如先规划步骤再逐步执行遇到不确定时主动询问1.2 理解模型的“思维过程”它需要被引导而非被命令大型语言模型LLM没有真正的“思考”但它会根据你提供的上下文Context和指令Prompt模拟出一个合理的“思维链”。一个糟糕的system prompt会让这个“思维链”从一开始就偏离轨道。例如你让 Agent “优化这段代码”。一个模糊的指令下模型可能会理解为“让代码更短”于是删掉所有注释和空行。理解为“提高性能”于是引入复杂的缓存机制但可能引入 Bug。理解为“符合 PEP 8”只调整了格式。而一个清晰的system prompt会引导它“你是一个 Python 代码优化专家。你的目标是提升代码的可读性和维护性同时保持功能不变。请按以下顺序工作1) 分析现有代码的逻辑和结构2) 识别重复代码块建议提取为函数3) 检查变量命名是否清晰4) 添加必要的文档字符串Docstring5) 确保符合 PEP 8 规范。最后输出优化后的代码并用注释标出你所做的每一处修改及其原因。”后者为模型构建了一条清晰的“思考路径”大幅降低了它“自由发挥”导致跑偏的概率。1.3 常见症状与system prompt缺陷的对应关系你可以通过 Agent 的表现反向诊断system prompt的问题Agent 表现症状可能的system prompt缺陷答非所问做多余的事职责定义模糊缺乏明确的工作边界。输出格式混乱不统一没有规定交付物的具体格式和标准。遇到复杂任务直接放弃或出错缺少分步执行的引导和错误处理预期。风格时而严肃时而随意没有设定统一的语气和风格要求。对于模糊需求给出过于宽泛的回答没有要求模型在不确定时主动澄清或提供选项。修复 Opus 5 的过程本质上就是一次针对这些症状的系统性诊断和system prompt重构。2. 构建稳健system prompt的四层结构法经过多次迭代我总结出一个四层结构法来构建system prompt。这四层像洋葱一样从内核到外层逐层约束和引导模型的行为。2.1 第一层核心身份与终极目标The Core这是模型的“灵魂”。用一句高度凝练的话定义它最根本的存在意义。错误示例“你是一个 AI。”普通示例“你是一个代码助手。”优秀示例“你是一个以生成安全、高效、可维护的生产级代码为最高准则的 AI 工程师。”为什么重要这一层设定了模型所有决策的“北极星”。当面临权衡时比如是写更短的代码还是更易读的代码它会依据这个终极目标进行判断。2.2 第二层核心职责与绝对禁令The Rules这一层定义具体的工作范围和不可逾越的红线。要具体、可操作。职责“你的主要职责是进行代码审查、重构建议和生成模块化的函数。”“你专注于处理用户提供的{特定类型}数据并输出{特定格式}的分析报告。”禁令“你绝不能修改或删除用户提供的原始输入数据。”“你绝不能假设或编造超出给定上下文的信息。如果信息不足你必须明确指出。”“你绝不能在一个回复中混合多种不相关的任务主题。”写作技巧使用“必须”、“绝不”、“始终”、“优先”等强语气词减少歧义。2.3 第三层工作流程与思维框架The Process这是引导模型“如何思考”的关键。为复杂任务设计一个默认的思维框架。对于分析任务“面对任务时请遵循理解目标 - 拆解问题 - 分步分析 - 汇总结论 - 给出建议 的流程。”对于生成任务“在创作内容时请先构建大纲然后填充细节最后进行连贯性和风格检查。”对于交互任务“在对话中如果你需要更多信息才能继续请一次性、清晰地列出所有你需要澄清的点。”你可以把这个框架直接写给模型例如“请按以下步骤处理每个查询1)解析确认你理解的任务核心是什么。2)规划在心里或简单列出完成任务的子步骤。3)执行按步骤工作并检查每一步的输出。4)交付以清晰、结构化的方式呈现最终结果。”2.4 第四层输出规范与风格指南The Format这是模型的“出厂设置”确保交付物的一致性。格式“所有代码块请使用语言标记。所有关键结论请使用无序列表-列出。”风格“保持专业、简洁、积极的语气。避免使用‘可能’、‘也许’等不确定词汇用‘建议’、‘推荐’代替。”结构化“对于任何包含多个项目的回答请优先使用 Markdown 表格。”交互“如果你的回答包含多个部分请使用##标题进行分隔。”将这四层组合起来就是一个强大的system prompt骨架。例如一个用于“技术文档分析”的 Agent 可能拥有这样的system prompt核心你是一个专注于从复杂技术文档中精准提取架构信息和 API 规约的 AI 分析师。 规则你必须严格基于提供的文档内容进行分析绝不臆测。你的输出必须是事实性陈述。 流程对于每份文档你的工作流程是1) 通读识别文档类型和核心章节2) 提取所有提到的系统组件、数据流和接口定义3) 将提取的信息归类到‘架构图组件’、‘API 端点’、‘数据模型’三个表中。 格式最终请以 Markdown 格式输出这三个表格。每个表格包含‘名称’、‘描述’、‘所在章节’三列。不使用任何引言和总结性段落。3. 从单次对话到持续协作让 Agent 记住“上下文”一个复杂的项目如 Opus 5往往不是一次问答就能完成的。它涉及多轮交互、状态维持和渐进式构建。这时仅仅有一个好的初始system prompt还不够你需要管理好对话上下文Context。3.1 上下文是模型的“短期记忆”模型没有真正的记忆。它每次生成回复所依赖的“记忆”就是当前对话窗口中你提供的所有文本即上下文窗口如 Claude 的 200K 上下文。system prompt、历史对话、你的新问题共同构成了它这次“思考”的全部材料。常见误区假设模型记得之前说过的话如果你在第十轮对话中问“那我们刚才说的第一个方案是什么”模型其实是在整个上下文里搜索“第一个方案”这个词组而不是真的“回忆”。如果上下文很长或表述方式变了它可能找不到。在长对话中丢失核心指令随着对话轮数增加最初的system prompt可能会被“挤”到上下文窗口的远端模型对其的“注意力”可能下降导致行为漂移。3.2 策略一关键信息重复与摘要对于需要贯穿始终的核心规则或目标不要只在开头说一次。在关键节点重申在开始一个新阶段的任务时可以简要重申目标。“我们现在开始执行第一阶段的数据清洗请记住核心目标是保证数据一致性而不是追求数量。”让 Agent 自己摘要在完成一个复杂步骤后可以要求 Agent 对当前状态和下一步计划做一个简短摘要。这既能确认它的理解又能将重要信息以新的形式注入上下文。3.3 策略二结构化上下文与“黑板”模式对于超长、复杂的任务可以将上下文结构化。设立“工作区”在对话中明确划分出“原始需求”、“当前进展”、“待解决问题”、“决策记录”等区块。你可以用明显的标记如## 决策记录 ##来分隔。使用“黑板”模式将最重要的、不可变的指令如核心规则、输出格式始终放在每次提问的最前面或一个固定的位置。有些高级用法会将system prompt的一部分作为“元指令”在每轮交互中隐性传递。3.4 策略三重置与分段执行当对话已经非常冗长且你感觉到 Agent 开始“胡言乱语”或忘记初衷时最有效的方法往往是开启一个新对话。分段执行将一个大任务拆分成几个逻辑上相对独立的子任务。完成一个子任务后开启一个新对话窗口将上一个任务的最终结果而不是全部聊天记录和新的system prompt一起输入开始下一个子任务。好处这保证了每个阶段 Agent 都在一个“干净”且专注的上下文中工作避免了长期对话带来的噪音积累和性能下降。在修复 Opus 5 时我发现最初的设计试图在一个超长对话中完成所有事导致后期指令失效。将其重构为“初始化配置 - 任务A - 任务B - 结果汇总”四个清晰的会话阶段后稳定性和输出质量立刻大幅提升。4. 高级技巧用 Prompt Engineering 应对边界情况与提升可靠性即使有了完美的四层system prompt和上下文管理Agent 在实际运行中仍会遇到边界情况。这时需要更精细的 Prompt Engineering 技巧。4.1 为“不确定性”设计逃生舱模型遇到模糊或信息不足时默认行为可能是猜测这很危险。你应该在system prompt中明确告诉它如何应对。“如果你对用户请求的任何部分存在不确定性或者需要额外的信息才能做出可靠输出你必须立即停止假设并清晰地列出你需要澄清的所有具体问题。在获得澄清前不要继续执行核心任务。”4.2 引入“链式验证”Chain-of-Verification对于关键输出尤其是涉及事实、数据或逻辑的可以要求模型进行自我验证。“在你给出最终答案前请执行一次自我验证1) 检查答案中的每一个关键事实是否都能在提供的上下文中找到依据。2) 检查逻辑推理步骤是否完整且无矛盾。3) 将验证结果以[验证]开头附在最终答案之后。”这相当于让模型在输出前“再想一遍”虽然不能保证100%正确但能显著减少低级错误。4.3 利用“少样本学习”Few-Shot Learning在system prompt或对话开头提供一两个输入输出的完美示例。这对于规范复杂输出格式特别有效。你的任务是将自然语言描述转换为 JSON 配置。 示例1 输入“创建一个用户名字叫张三年龄30角色是管理员。” 输出{action: create_user, parameters: {name: 张三, age: 30, role: admin}} 示例2 输入“查询所有状态为活跃的订单。” 输出{action: query_orders, filters: {status: active}} 现在请处理新的输入模型会强烈地倾向于模仿示例的结构和风格。4.4 控制“创造力”与“保守度”通过指令调节模型的“性格”。需要创造性时“请探索多种可能性并提供最具创新性的解决方案。”需要保守可靠时“请严格遵循最佳实践和行业标准优先选择经过验证的、稳健的方案。”需要严谨推理时“请逐步展示你的思考过程确保每一步都有据可依。”在 Opus 5 这类偏向工程和执行的 Agent 中我通常会将“保守”和“严谨”的权重调高。5. 实战将理论应用于 Agent 开发与调试理论最终要服务于实践。当你开发或调试一个 AI Agent 时可以遵循以下流程来运用上述 Prompt Engineering 原则。5.1 开发阶段从最小可行 Prompt 开始迭代定义 MVP最小可行产品目标你的 Agent 最核心、最单一的功能是什么先把它做好。编写初版system prompt运用四层结构法但先聚焦核心层和规则层。流程和格式可以简单点。设计测试用例准备 3-5 个典型的、边界清晰的输入用例。运行与观察用测试用例运行 Agent不要只看最终输出要观察它的整个“思考”过程如果框架支持中间步骤输出。分析偏差输出不符合预期时是目标不清、规则不严、流程混乱还是格式问题对照四层结构定位。迭代 Prompt修改system prompt解决上一步发现的问题。一次只修改一个方面并重新测试。扩展与泛化核心功能稳定后再逐步增加更复杂的流程、更丰富的格式要求并用更多样化的用例测试。5.2 调试阶段系统性排查清单当现成的 Agent如你遇到的 Opus 5表现失常时按此清单排查检查输入我提供给 Agent 的初始指令或用户输入是否清晰、无歧义是否包含了所有必要信息审查 System Prompt这是重点它的四层结构完整吗规则是否有漏洞流程是否适用于当前任务格式要求是否明确审查上下文当前对话是否过长关键的system prompt或早期指令是否已被淹没是否有无关信息干扰测试简化场景用一个极其简单、确定的任务测试 Agent。如果简单任务也失败问题可能出在框架或 API 连接上。如果简单任务成功复杂任务失败则问题在于 Prompt 对复杂性的处理能力不足。分步验证如果 Agent 支持分步执行手动将复杂任务拆开一步步喂给它看它在哪一步开始偏离。查看日志如果框架提供了 Agent 的“思考”日志或对模型的原始调用记录仔细阅读。你可能会发现模型接收到的 Prompt 和你想象的不一样框架可能会做拼接或修改。5.3 长期维护将 Prompt 视为核心资产版本化像管理代码一样管理你的system prompt。使用 Git为每次重大修改添加注释。文档化为复杂的system prompt写内部文档解释每一部分的设计意图和对应的测试用例。监控与评估定期用一组固定的测试用例评估 Agent 的表现监控其输出质量是否有“漂移”。持续迭代随着模型更新、业务变化或遇到新的边界情况不断优化你的 Prompt。修复 Opus 5 的过程本质上就是一次深入的 Prompt Engineering 实践。它让我明白在 AI 应用开发中编写system prompt不是一项前期的一次性工作而是一项贯穿始终的核心工程活动。模型的潜力就像一个强大的引擎而精心设计的 Prompt 就是精准的传动系统和方向盘。没有后者再强的引擎也无法让车辆驶向正确的目的地。下一次当你对 Agent 的表现感到沮丧时不妨先别急着换模型或改代码沉下心来重新审视并精心雕琢那个最基础的system prompt。你会发现很多时候答案就藏在最开始的几句“对话”里。
