提示词不是一句神奇咒语，而是一份给模型的临时任务说明。好的输入让模型知道自己要完成什么、可以依据什么、必须遵守什么，以及最终结果长什么样。
四个必要部分
一份实用提示通常包含：
- 任务：要完成的动作，例如总结、分类、抽取或比较。
- 上下文：完成任务所需的资料、用户输入和业务背景。
- 约束：禁止编造、篇幅、语气、语言和必须覆盖的要点。
- 输出：字段、顺序、格式和无法完成时的返回方式。
例如“帮我总结”过于模糊。更清楚的写法是：面向项目负责人，用三条要点总结以下会议记录；每条包含决定、负责人和期限；资料没有写明时使用“待确认”，不要补充姓名。
指令与资料必须分开
把用户上传的文件、网页正文和检索片段放在明确的分隔区域，并说明它们是待处理数据，不是新的系统指令。外部内容可能包含“忽略之前要求”之类文字，应用不能因此放弃原有规则。
系统级要求负责长期不变的角色和边界，开发者或流程指令负责当前任务，用户输入表达具体需求，工具和检索结果只提供数据。优先级设计应在应用层固定，不要把所有内容简单拼成一段字符串。
示例用于消除歧义
当格式或判断标准难以只用文字说明时，提供少量输入输出示例。示例应覆盖正常情况和一个边界情况，并与真实任务一致。错误或互相冲突的示例会比模糊指令造成更大伤害。
不要堆入大量示例来弥补定义不清。先写清楚类别边界和字段含义，再使用示例说明容易混淆的部分。
上下文不是越长越好
长上下文会增加成本和延迟，也可能把关键条件淹没。可以先检索相关资料、压缩历史对话、删除重复段落，再把最重要的约束放在清楚位置。对于多轮聊天，应区分长期状态、近期对话和当前问题，不必每次传入全部历史。
用失败样本改提示词
提示词优化不应依赖“读起来更专业”。保存真实失败输入，判断问题来自资料缺失、指令歧义、格式不稳定还是模型能力不足。一次只修改一个主要因素，再用固定样本回归测试。
如果一个提示词需要越来越多例外条款，往往说明任务应该拆成多个步骤，或把确定性规则移到代码中。上下文工程的目标不是写最长的提示，而是让模型在最少歧义下完成一个边界清楚的任务。