API提示词是给机器的结构化契约，需精准定义字段、类型、位置及错误码；网页端提示词是给人的自然语言引导，重在激发意图、适配平台能力与输出风格。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
API 接入提示词和网页端写法，本质是两种不同场景下的“指令语言”：前者是给机器看的结构化契约，后者是给人看的自然语言引导。目标不同，写法必须彻底分开。
API 接入提示词：要像合同一样精准
它不负责解释“为什么”，只定义“系统认什么”。所有字段名、类型、取值范围、位置（Header/Query/Body）、签名规则、错误码含义，都必须一一对应真实请求链路。
- 鉴权方式必须单写一行，比如【必须在 Header 中携带 Authorization: Bearer {your_token}】，不能写“支持多种方式”
- 参数表分三层：路径参数（如 /v1/chat/{model_id}）、查询参数（如 temperature=0.8）、请求体（JSON 树形结构，role 只接受 "system"/"user"/"assistant"）
- 响应示例必须用真实字段值，比如 "id": "chat_abc123"，不是 "id": "string"；错误响应也要复制粘贴真实返回，包括 message 字段的每个标点
网页端写法：要像对话一样自然
它面向的是用户，不是服务器。重点是激发模型理解意图、补全上下文、适配平台能力，不需要提字段、签名、HTTP 状态码。
- 可以带语气词和平台特征，比如“请根据这张图写一段适合发在小红书的文案，带emoji和话题标签”
- 能利用网页端特有能力：上传图片后自动识别内容、粘贴 URL 抓取正文、切换“代码模式”或“推理模式”等
- 无需声明输入结构，但需明确输出风格和用途，例如“生成3个不同语气的版本：正式汇报版、内部群聊版、朋友圈轻松版”
关键区别不在字数，而在约束来源
API 提示词的约束来自接口协议本身——改一个字段名、少一个 header、timestamp 超出±300秒，请求就失败；网页端的约束来自用户任务和平台功能——说不清“小红书风格”，结果可能偏微博风，但不会报 400 错误。
- API 提示词里禁用“高效”“灵活”“支持多种”这类模糊词，因为服务器不理解形容词
- 网页端提示词可以写“更活泼一点”“再简洁些”，模型会结合上下文做语义推断
- 网页端可依赖多模态能力（如图+文联合理解），API 调用需显式传 base64 或 url，并指定 model=qwen-vl
