别再只会写“你是专家”，Prompt 要像接口一样设计

一、提示工程不是玄学，是输入契约

很多人写 Prompt，习惯把所有要求堆成一大段。看起来很完整，模型却容易漏。

原因很简单：模型不是在读需求文档，它是在根据当前上下文预测最合适的输出。你给的信息越乱，它越容易猜。

高级提示工程的核心，不是把提示写长，而是把任务拆清楚：角色、目标、上下文、输入边界、处理步骤、输出格式、失败兜底。

二、为什么 Agent 更依赖 Prompt

普通聊天场景，Prompt 写差了，最多回答不准。

Agent 场景不一样。它会调用工具、查询数据库、路由任务、写入系统、触发审批。Prompt 写差了，问题会放大。

在一个 Agent 系统里，Prompt 不是一句话。它是多个节点的执行规则。

• 路由节点：判断用户意图，决定走哪个工具。

• 规划节点：把目标拆成步骤。

• 工具节点：抽取参数，决定是否调用接口。

• 反思节点：检查结果是否合格。

• RAG 节点：判断检索资料够不够。

• 输出节点：把结果变成用户能看懂、系统能记录的格式。

所以，Agent 的 Prompt 应该被当成“业务规则 + 接口协议 + 安全边界”。

三、坏提示的问题：模型只能猜

坏 Prompt 的共同点：目标模糊、输入边界不清、输出格式不固定、失败场景没定义。

这类提示在演示时也许能跑通，但一到生产环境，就会出现格式漂移、工具误调、结果不可解析。

四、提示工程的 5 条底层原则

1. 指令要具体

不要写“分析一下”。要写清楚分析什么、输出什么、按什么标准判断。

2. 输入要有边界

用分隔符把资料、用户问题、示例、系统规则分开。模型才知道哪些是资料，哪些是命令。

3. 输出要可解析

面向工程系统时，尽量输出 JSON、枚举值、固定字段。自由文本适合人看，不适合程序接。

4. 示例要覆盖边界

少样本示例不是越多越好。关键是覆盖容易错的边界：信息不足、类别相似、风险较高、需要转人工。

5. Prompt 要版本化

生产 Prompt 不能散落在聊天框。它要进入代码仓库，有版本号、有评估集、有灰度和回滚。

五、常用提示技术怎么选

提示技术很多，但落地时不必一上来就全用。

简单任务先用零样本。输出不稳，再加示例。格式不稳，再加结构化输出。需要调用工具，再引入 ReAct 或函数调用。需要企业知识，再接 RAG 和上下文工程。

六、工程案例：客服工单分类 Agent

目标很明确：用户提交工单后，Agent 自动判断类型、风险等级和下一步动作。

这个场景不适合让模型自由发挥。因为后面要接路由、审批、工单流转。输出必须稳定。

这个案例的关键点

• 分类范围固定，避免模型创造新类别。

• 输入边界固定，只分析工单内容，不把系统规则当用户信息。

• 输出字段固定，方便后端解析。

• 不确定时返回 need_more_info，而不是胡乱猜。

• 高风险场景标记 risk=high，交给人工或审批流。

七、提示工程和上下文工程的区别

提示工程解决“怎么说”。上下文工程解决“给模型看什么”。

做 Agent 时，只优化一句 Prompt 不够。还要控制进入上下文的资料：用户历史、工具结果、RAG 文档、记忆、系统状态。

一句话：Prompt 是指令，Context 是战场。

上下文越多不一定越好。无关资料会稀释重点，增加成本，也会让模型更容易跑偏。

八、源码级落地逻辑

在工程里，Prompt 不应该是散落的字符串，而应该像配置和代码一样管理。

1. 模板层

把 Prompt 拆成系统指令、任务说明、输入变量、输出格式、示例片段。

2. 渲染层

运行时把用户输入、检索结果、工具结果、会话状态填入模板。

3. 校验层

模型输出后，先做 JSON 解析、Schema 校验、枚举值校验，再交给业务系统。

4. 评估层

每次修改 Prompt，都跑固定测试集。看分类准确率、格式成功率、工具误调用率、人工介入率。

5. 观测层

线上记录 Prompt 版本、输入摘要、输出结构、耗时、模型、失败原因。否则出了问题无法复盘。

九、上线检查清单

十、总结

高级提示工程不是“会写漂亮话”。

它更像接口设计。

你要让模型知道：它是谁，要做什么，基于什么资料，按什么步骤，输出什么结构，不能做什么，失败时怎么处理。

如果 Prompt 只是聊天技巧，系统就很难稳定。

如果 Prompt 被工程化管理，Agent 才能进入生产环境。