提示词工程你有什么心得吗

我更推荐把提示词当“任务规格”，别当“咒语”。先举个面试复盘的例子。 只写“你是资深面试官，帮我分析面经，专业一点”，不如写： 任务：根据下面的面试记录，找出候选人最需要补的知识点。 依据：只用记录里的回答判断；没有回答内容的题目标记“无法判断”，不要猜表现。 输出：优先给出三个薄弱点，每个附上原文依据、问题解释和一道练习题。 边界：区分“知识错误”和“表达不完整”，不要把没提到等同于不会。 面试记录：…… 这里有效的不是“资深”这个人设，而是把做什么、依据什么、怎样算做好、信息不够怎么办说清楚。 具体有几个心得。 先定义验收，再润色措辞。“回答准确、有深度”不好检查；“每个判断有原文依据，缺信息就说明”才方便评估。如果你自己都判断不了哪次输出更好，就很容易陷入反复改提示词、凭感觉说变强了。 例子要覆盖边界，不只是展示理想答案。比如模型总把“回答简短”判成“基础差”，就给一组对照：一个回答短但关键点正确，另一个术语很多但因果关系错了。这样的例子比重复强调“务必客观”更有针对性。 规则要去冲突，不是无限叠加。既要求“任何问题都简短”，又要求“技术问题完整解释”，模型就需要猜。更好的写法是明确适用范围：“闲聊简短；技术问题先给例子，再解释原理，保留必要细节。”某次出错后先检查任务、上下文和工具是否有问题，别一律追加一条“绝对禁止”。 做 Agent 时，重点会从提示词扩展到上下文。比如修 bug，优先提供报错、相关代码、运行环境和测试命令，而不是塞完整仓库与全部聊天记录。工具说明也要明确什么时候调用、参数含义、失败后怎么处理。提示词再漂亮，也替代不了缺失的关键信息。 安全约束必须有程序兜底。比如“只有管理员可以执行代码”，不能只写在提示词里；服务端必须核验身份，执行环境必须做隔离与权限限制。提示词负责指导行为，不是安全边界。 最后，用固定案例回归。可以先攒二十条真实问题，包含正常请求、缺信息、歧义、恶意指令，每次修改后用同一套标准比较。这个数量只是起步建议；重点是别只拿刚失败的那一道题验证，否则很容易修好一个、弄坏三个。 Anthropic 的这篇文章也强调了类似方向：指令清晰直接，上下文追求高信号，而不是越长越好。 https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents 一句话概括：把目标写得可验收，把上下文给得恰到好处，再用测试证明修改有效。