这是《从“模板库”到“工作流”》系列的第 3 篇。 上一篇：进阶模式：推理路径设计
当我们从纯聊天转向工程落地时，提示词的设计逻辑必须从“写作模式”切换为“分析模式”。
附件进场后，不再是“帮我写一写”
当任务对象变成 CSV、PDF、代码文件、简历、讲义或者产品资料时，提示不能再停留在简单的命令层面。它必须围绕三个核心：目标、观察维度、输出形态。
比如处理数据分析任务：
任务：
1. 找出最重要的业务变化；
2. 解释变化背后的可能原因；
3. 区分“数据已支持”和“只是线索”的部分。
约束：
- 不要编造不存在的字段；
- 不要把相关性直接写成因果；
- 发现证据不足时必须明确指出。
同样的逻辑也适用于 Directional Stimulus。相比于“帮我总结”，显式给出观察方向（如“只看财务影响和执行风险”）能极大提升模型的可控性。
RAG：不是“上传文件”，而是“依据管理”
很多人会把 RAG 理解成“上传文件再问问题”，这其实只碰到了表层。RAG 的核心是把参数化记忆和外部可检索记忆结合起来，解决模型幻觉和知识过时的问题。(arXiv)
我们后来给这类任务加了一条硬约束：只根据提供材料回答；没有证据就明确说“资料未提及”。
- 提取关键概念/时间/结论；
- 标出高频术语；
- 列出资料中没有提及的部分。
梳理结束后，我们没有扩充模板库，而是留下了三条原则：
- 先定义任务，再写提示：模型扮演谁？依据什么完成？怎么判断它完成了？
- 先定义交付，再谈质量：你要的是 200 字摘要还是固定字段 JSON？交付形态（Structured Outputs）本身就能提升质量。(OpenAI Developers)
- 凡是依赖资料的任务，都要显式约束依据：禁止猜测，明确缺失，把依据写在明处。
补充：给模型定“负向清单”（Negative Constraints）
比起告诉模型“要做什么”，有时候明确告诉它“不要做什么”对稳定性贡献更大。
- 不要在没有证据时编造事实。
- 不要使用过度煽情的修辞。
- 不要在输出中包含引言或结语，直接给正文。 这类显式的禁令（Negative Constraints）是大幅减少“模型幻觉”和“废话密度”的第一步。(OpenAI Developers)
从辅助创作到代理执行（Agentic Thinking）
当模型不再只是生成文本，而是开始调用工具或执行操作时，提示工程又深了一层：
结构化输出：使用 JSON Schema
在程序对接场景（如 API 提取数据），绝对不要用“请按 JSON 格式返回”这种口头约定，而是要通过 Structured Outputs / JSON Schema 来强制约束。这让模型在生成时就开始按照模式进行语法验证，确保 100% 格式对齐可解析。(OpenAI Developers)
工具调用（Tool Use / Function Calling）
引导模型理解“什么时候该查搜索，什么时候该调计算器”。在提示中给模型权限，让它成为一个有手的助理，这正是向 AI Agent 转变的关键节点。(Anthropic Documentation)
持续变化的边界
技术习惯还在迁移，工具能力也在持续变化。有些今天需要 RAG 的任务，明天可能会被更强的长上下文（如 Gemini 2.5 Pro 或 GPT-5 系列）直接吞掉。(Google AI for Developers)
提示工程不是为了写出一条“终极咒语”，而是给这个概率型系统补足输入契约、执行约束和证据边界。
本系列完结