开发者提示工程实战：从需求拆解到稳定 API 输出
先把“提问”改成可验收的任务
提示工程不是写一段华丽的自然语言，而是为模型建立可重复执行的接口契约。开始前，先写清楚输入、输出和验收条件。例如要做工单分类，不要只写“帮我分析工单”，而应明确：输入是工单标题和正文；输出是分类、优先级、摘要；分类只能从既定枚举中选择；无法判断时返回“需人工处理”。这样做能减少模型自由发挥，也方便后续自动解析和测试。
一个实用的开发流程是先准备 20 到 50 条真实或脱敏样本，其中包含正常案例、边界案例和故意模糊的案例。为每条样本标注期望结果，再将提示词当作代码一样迭代，而不是只凭单次对话感觉判断效果。
用固定结构编写第一版提示词
建议将提示分成四块：角色、任务、上下文和输出规则。角色用于限定专业视角，例如“你是电商售后工单路由助手”；任务说明需要完成的动作；上下文放入业务规则、字段含义和用户输入；输出规则则规定格式、字段类型与异常处理方式。最重要的是把不允许做什么也写出来，例如“不得编造订单状态”“不要输出解释文字”。
- 角色：说明模型应具备的业务身份和边界。
- 任务：用动词描述动作，如提取、分类、重写、比较或生成。
- 上下文：提供必要事实，并用清晰分隔符包住用户内容，避免指令混淆。
- 输出：要求固定字段、枚举值、长度上限和未知值处理策略。
如果下游程序需要 JSON，不要只说“以 JSON 返回”。应明确字段名、允许值和要求，例如包含 category、priority、summary、needs_review 四个字段，summary 不超过 60 字。还应要求输出纯 JSON，避免模型附带“以下是结果”等文字导致解析失败。
先用少量示例解决业务歧义
当分类标准复杂、术语特殊或语气判断容易偏差时，加入 2 到 5 个高质量示例比不断加长规则更有效。示例应覆盖最易出错的边界：退款但商品未发货、用户同时投诉物流和质量、内容信息不足等。每个示例都要展示输入和期望输出，并保持与生产格式完全一致。不要塞入几十个示例，否则会抬高 token 成本，也可能让模型过度模仿个别措辞。
通过 API 参数控制稳定性与成本
在代码中将系统规则、业务上下文和用户输入分开维护。系统规则适合版本控制，用户输入必须进行长度限制和必要的脱敏。对于分类、抽取和格式化等确定性任务，优先使用较低 temperature；对于标题创作、文案变体等任务，再适度提高随机性。还要设置合理的 max tokens，输出只需 200 字时不必预留数千 token。
59API 的基础地址为 https://api.59api.com，兼容 OpenAI SDK，也可用于 Claude Code 与 Codex 工作流。开发时可以先用速度快、成本更低的模型批量跑评测，再将少数高难度请求路由到更强模型。59API 提供 Claude Opus、Sonnet、Haiku、Fable 及 GPT 模型的按量访问，使用原生官方质量模型而非降级版本，特别适合需要频繁调试提示词的团队控制预算。
建立评测、回退与持续优化闭环
每次修改提示词后，重新运行固定样本集，并记录字段准确率、JSON 解析成功率、平均延迟、平均 token 和单次成本。不要只看“回答看起来不错”；若分类任务的准确率提升但解析失败率上升，生产效果仍可能变差。对于解析失败，可先做一次轻量重试，附加“仅返回合法 JSON”的纠正指令；仍失败时回退到人工队列或规则引擎。
上线后保留匿名失败样本，按周归类为知识不足、指令冲突、上下文过长或格式错误，再针对占比最高的问题更新提示和样本集。提示工程的核心不是一次写对，而是用可测量的反馈持续收敛。若你希望以较低成本开始这套实验流程，可以注册 59API 按量接入，并通过其推荐返利机制进一步降低团队测试支出。