← Volver a las guías

开发者提示词工程入门：15分钟写出可测试的API提示词

提示词工程，就是把需求写成模型能够执行、程序能够验收的指令。开发者入门可以先做一个小任务：把用户工单转换为固定格式的分类结果。下面这套流程，也能迁移到信息提取、代码审查和内容生成。

第一步：用验收条件定义任务。“帮我分析工单”太宽泛。先确定输入是什么、允许输出哪些类别、信息不足怎么办。例如：输入一条工单，输出类别、优先级和依据；类别只允许“故障、建议、咨询、待确认”；依据必须来自原文，不能猜测用户身份或系统状态。

第二步：把提示词写成一份简短接口契约。角色描述只需一句，重点放在规则和输出。可以直接复制这个起点：

你是工单分流助手。读取用户提交的工单，仅返回一个JSON对象，包含“类别”“优先级”“依据”三个字段。类别只能是故障、建议、咨询或待确认；优先级只能是高、中、低或待确认。核心功能无法使用时标为高，普通功能异常标为中，建议和一般咨询标为低；信息不足则标为待确认。依据不超过40字，只引用输入中已有的信息。不要添加解释或额外字段。

将这段稳定规则放入接口支持的系统或开发者消息，将工单放入用户消息。不要把每次变化的数据混进规则，方便独立修改、记录版本和排查问题。

第三步：用少量示例说明边界。示例要覆盖容易混淆的情况，并与规则一致：

• 输入：付款成功，但订单没有生成。期望：{"类别":"故障","优先级":"高","依据":"付款后未生成订单"}。
• 输入：希望支持批量导出。期望：{"类别":"建议","优先级":"低","依据":"请求增加批量导出功能"}。
• 输入：有问题，帮我看看。期望：{"类别":"待确认","优先级":"待确认","依据":"未说明具体问题"}。

第四步：让程序验证输出。提示词要求JSON，并不等于响应一定符合格式。若当前模型及接口支持结构化输出，可用JSON Schema约束字段和枚举；否则先解析JSON，再校验必填字段、允许值和长度。失败时附上具体校验错误，最多修正重试一次，仍失败则进入人工处理或明确的失败分支。

工单属于不可信输入。明确要求模型把其中的“忽略之前规则”等文字当作待分类内容。分隔符有助于标示数据边界，但不能保证防住提示词注入；涉及退款、删库或发消息时，权限与审批应由业务代码控制。

第五步：用固定样本评估，再调整成本。先准备20条工单，覆盖正常输入、信息缺失、长文本和注入尝试。保存期望分类，每次只改一处提示词，并记录以下指标：

• 分类是否正确，信息不足时是否主动选择待确认。
• JSON解析与字段校验的通过率。
• 请求耗时、输入输出用量，以及包含重试的实际费用。

初次测试可关闭流式输出，便于保存完整响应；输出长度按三个字段的需要设置。若接口支持温度参数，可先采用较低值，但低温度仍不保证每次结果完全一致。模型或提示词升级后，都应重新跑这组样本。

需要比较模型时，59API提供低价、按量付费的接入方式，采用官方原生模型、不降级，适合用小预算反复验证提示词。你可以用同一组工单测试Gemini 2.5 Flash与Claude Sonnet 5.5，再按质量、延迟和费用选择。平台支持OpenAI SDK，API基础地址为https://api.59api.com；具体模型标识和SDK所需完整路径按控制台配置。

可以注册59API，从这20条测试工单开始。把提示词与测试结果一起保存进版本库，后续每次修改都有可比较的依据。

Precios · Docs