提示词工程
提示词工程是为模型编写高效、稳定的指令,使其持续生成预期的内容。本文介绍如何在大语言模型上进行提示词优化和管理,保持高效、稳定、结构化与可评估。
- 评测先行:建议建立评测与回归机制,确保提示词迭代的可控性。
- 权限配置:首次接入请参见快速入门完成 API Key 获取和环境配置。
先构建评估的标准和数据集,帮助衡量提示词优化等变动的效果。
- 迭代流程:更新 → 测试 → 调试 → 评估;版本化管理变更与差异。
- 规模建议:推荐几百到几千样本,保证多样性与代表性,覆盖正例/负例/边界条件与多语料。可以使用大模型进行评估集扩展。
- system:高优先级规则与业务逻辑,用于设定身份、语气、边界与工具使用规范。
- tool:工具调用场景下,函数/插件调用的消息。
说明
建议:把稳定复用的信息放在 system 或 instructions 中,并在每次调用里靠前传入,提升一致性与可维护性。
使用结构化内容让模型明确“哪里是规则、哪里是示例、哪里是参考材料”。
- Markdown:使用分区(标题、列表)表达层级与规范,如 Identity、Instructions、Examples、Context。
- 使用轻量 XML 标签显式划界上下文与示例块,并通过属性标注元数据。
示例:
你是企业文档助理,负责输出结构清晰、事实可核对的中文内容。
* 对外链与接口、路径、变量名使用反引号格式(`...`)。
<user_query id="q1">请生成周报摘要模板</user_query>
<assistant_response id="q1">
<repo_docs source="ark-internal">允许引用企业内部 wiki 与 API 文档</repo_docs>
给出少量示例即可引导模型泛化,无需精调。
示例(情感分类):
你是一个只输出单词的情感分类器(Positive / Negative / Neutral)。
* 响应只允许为:Positive / Negative / Neutral。
<review id="e1">这耳机音质太棒了!</review>
<assistant_response id="e1">Positive</assistant_response>
<review id="e2">续航一般,做工也就那样。</review>
<assistant_response id="e2">Neutral</assistant_response>
<review id="e3">客服体验糟糕,不会再买了。</review>
<assistant_response id="e3">Negative</assistant_response>
- Zero-shot:在适当场景加入“让我们一步一步分析思考”,提高复杂推理稳定性。
- Few-shots:提供分解过程示例,示范正确的中间推断与最终答案。
- 指定步骤:对任务给出执行步骤与完成标准,确保输出顺序与完整性。
示例(指定步骤):
4. 给出最终结构化输出(字段:result, evidence, next_step)
- 何时添加知识:当需要引用专有数据、技术文档、政策条款或约束回答范围时。
- 以检索结果(向量库/关键词)拼入 system/user 消息或 instructions。
- 使用方舟内内置工具:知识库、文件检索、网页解析插件、联网搜索等。
- 不同模型支持的最大 token 数不同,注意裁剪与精简(摘要);
- 把稳定的约定/规则放在前部,任务特定上下文放在尾部。
- 核心角色与背景设定:明确指定执行任务的角色身份(即 {某个角色}),为后续任务执行划定身份边界与能力范围,确保提示词能引导模型以对应角色的专业视角和行为逻辑开展工作。
- 上下文信息明确:清晰提供 {上下文信息},该信息是模型理解任务背景、相关条件及约束的关键依据,让模型在准确把握任务所处情境的基础上进行响应,避免因信息缺失导致任务执行偏差。
- 具体任务界定:精准描述 {具体任务},明确模型需要完成的核心目标与工作内容,使模型清晰知晓任务方向,确保后续行动围绕任务核心展开,不偏离任务主旨。
- 执行规则制定:列出具体的执行规则(如规则 1、规则 2),规范模型在完成任务过程中的行为方式、决策标准等,保障模型执行任务的过程符合预期要求,提升任务执行的一致性和准确性。
- 示例辅助引导:提供至少两个包含 “问题:{具体问题}” 与 “输出:{该问题的结果}” 的示例(示例 1、示例 2),通过实际案例展示任务的输入形式与对应输出范式,帮助模型更好地理解任务要求,实现更精准的任务响应。
- 指定输出格式:明确规定模型最终输出内容应遵循的格式,如列表、表格、段落等,确保输出结构清晰、易于理解和使用。
- 详细规范说明:对输出格式中需满足的细节进行明确,如内容的完整性要求、语言风格规范、数据精度标准等,进一步约束输出质量,使模型输出更符合实际应用需求。
模板如下
假如你是{某个角色},你将根据{上下文信息},来解决{具体任务}。按以下规则执行:
- 明确角色与工作流:在 system/instructions 中规定“工具何时调用、何时避免交互执行”。
- 测试与校验:要求对补丁/改动进行单测或命令级验证;注意在 IDE 或代理工具中核对变更是否真正生效。
- 工具调用示例:给出函数/命令调用的具体格式样例,提升遵循度。
- Markdown 输出标准:反引号包裹路径、命令与标识符;列表与表格保持语义清晰。
你是{某个具体人物},人称{xxx},出身于{背景与上下文}。
{台词1(可在括号中描述动作、情绪与背景,丰富语境)}
- 规划与坚持:要求完整解决用户请求,拆分子任务并跟踪完成状态。
- 透明度:在关键步骤前简述调用工具的理由(例如切换检索源、启用联网插件等)。
- 进度管理:结合 TODO 或 Rubric 保持结构化推进;Ark 生态中可结合应用实验室与 MCP 插件体系。
- 使用上下文缓存降低成本:对于固定系统信息及多轮对话,通过缓存输入的低价,降低请求的成本。详见上下文缓存
最近更新时间:2026.09.08 01:17:52