Claude Opus 5.5 用于电商：文案撰写与客服回复

claude-opus-5-5 在 hiapi 自己的模型卡上显示，输入和输出模态都列为 text —— 没有图像生成，也没有提到图像输入。所以当需求里出现“商品图片”时，诚实的答案和面对任何纯文本 LLM 时一样：用错了工具。它在网店场景里真正擅长的是写作：商品描述、商品页面文案和客服回复。它还有一个大多数人从未碰过的 reasoning 参数，而这个参数有一个真实的、会计费的副作用，值得在你把它接入生产流水线之前了解。下面是针对 hiapi API 的四次真实调用，包含真实输出、真实 token 计数，以及一个花了真金白银才发现的坑。

reasoning.effort 参数，以及它到底给你带来了什么

claude-opus-5-5 的模型卡列出了五档 reasoning effort：low、medium、high、xhigh、max。请求结构如下：

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 500,
    "reasoning": {"effort": "high"},
    "messages": [
      {"role": "system", "content": "You are an e-commerce copywriter. Write a 60-word product description. No superlatives."},
      {"role": "user", "content": "Product: insulated water bottle. 750ml, stainless steel, double-wall vacuum insulation, leak-proof lid, matte finish. Keeps drinks cold 24h, hot 12h."}
    ]
  }'

另外两种请求结构看起来也合理，但都会失败：顶层字段 reasoning_effort 和 Anthropic 原生的 thinking: {"type": "enabled", "budget_tokens": ...} 块都会返回 invalid_request。在这条路由上，唯一有效的结构是 reasoning: {"effort": "..."}。

最初的假设是：更高的 effort 级别会花费更多 token，以换取更深入思考的答案。用完全相同的 60 词描述提示词，在 max_tokens: 500 下分别以 minimal（未文档化，详见下文）、low、medium、high 和 max 发送，结果却并非如此：

effort	prompt_tokens	completion_tokens	finish_reason
minimal	130	499	stop
low	130	499	stop
medium	130	499	stop
high	130	499	stop
max	130	499	stop

每个级别都为同一提示词计费了恰好 499 个 completion token。不是接近——是完全相同。真正变化的是写作内容：

minimal： 无论身在何处，都用这款 750ml 不锈钢水瓶保持水分。双层保温让饮品保冷 24 小时、保温 12 小时，所以从山径到健身房，你的水始终清爽。防漏盖在背包里密封严实，哑光表面抗刮擦，握在手里也很稳。不含 BPA，耐用，适合每一次锻炼和户外探险。

high： 不锈钢保温水瓶，750ml。 为长途山径和更长的锻炼而打造。双层不锈钢保温让饮品保冷 24 小时或保温 12 小时，所以你的水直到最后一口都新鲜。防漏盖在背包或健身包里密封严实。哑光表面抗磨损，也不怕出汗的手。750ml 足够一整趟骑行，又不会让你负重过多。

high 增加了一行加粗标题，并重新组织了卖点顺序；minimal 则直接进入卖点。两者都落在 60 词，都遵守了“不用最高级形容词”的规则，成本也相同。low 和 medium 则介于两者之间，结构依次减少。注意，minimal 实际上并不在文档列出的五档列表中——它没有被拒绝，但应把未文档化的值视为不受支持，而不是在生产中依赖它；请使用列出的五档之一（low/medium/high/xhigh/max）。

真正的教训：reasoning.effort 改变的是风格，不是价格。 在固定的 max_tokens 下，成本取决于你设置的上限，而不是 effort 字符串。如果你按 effort 级别来为文案流水线做预算，以为 low 是便宜档，那并不是——max_tokens 才是唯一能改变账单的杠杆。

坑：reasoning 会悄悄吃掉你的 max_tokens 预算

“成本取决于 max_tokens”这个发现有一个尖锐的副作用。claude-opus-5-5 在写出可见回复之前会进行内部推理，而这种内部推理与答案本身共用同一个 max_tokens 上限。如果不提高上限就把 effort 调高，模型可能会在答案写到一半时耗尽预算——或者在写出任何可见内容之前就耗尽。

第一个案例：在一个普通文案提示词上使用 effort: xhigh 和 max_tokens: 500：

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 500,
    "reasoning": {"effort": "xhigh"},
    "messages": [
      {"role": "system", "content": "You are an e-commerce copywriter. Given a product spec, write a title (max 70 characters), 3 bullet features, and a 2-3 sentence description. No superlatives, no exclamation marks."},
      {"role": "user", "content": "Product: insulated travel mug. Material: 18/8 stainless steel, double-wall vacuum insulation. Capacity: 16oz. Lid: leak-proof slide lock. Keeps drinks hot 6 hours, cold 12 hours."}
    ]
  }'

实际响应，未经编辑——它在句子中间截断了：

标题： 16oz 不锈钢保温旅行杯，防漏滑锁盖

特点：

• 保温保冷： 双层真空保温让饮品保温 6 小时、保冷 12 小时。
• 耐用结构： 采用 18/8 不锈钢制成，防锈且不残留异味。
• 防漏盖： 滑锁密封开口，你可以把杯子扔进包里，不必担心洒漏。

描述： 这款 16oz 旅行杯采用双层真空保温，让你的咖啡整个上午都保持热度，或者你的

finish_reason: "length"，计费 500 个 completion token，而描述从句就在“或者你的”处戛然而止——没有结束标点，没有错误，没有警告字段。一个只检查 HTTP 200 的流水线会把那半句话直接发布到商品页面。

第二个案例更糟：一个客服回复提示词在 max_tokens: 300 下使用默认 reasoning，返回了完全空白。

{
  "finish_reason": "length",
  "usage": {"prompt_tokens": 157, "completion_tokens": 300, "total_tokens": 457},
  "message": {"content": "", "reasoning_details": [{"text": "", "type": "reasoning.text"}]}
}

content 是空字符串。reasoning_details 字段确认了原因：模型把全部 300 token 预算都花在了内部推理上（"text": ""——甚至推理轨迹也没有暴露，只有一个不透明的加密 signature 块），没有剩余空间来写实际回复。hiapi 仍然为那次调用计费了全部 300 个 completion token——无论是否产生可见答案，你都要为思考付费。

两种情况的修复方法相同：设置 max_tokens 时，要在可见答案所需之上留出真实余量，尤其是在 high/xhigh/max effort 下。也不要相信 finish_reason: "stop" 就是好答案的证明——在写入数据库之前，要检查 content 既非空，又确实把意思表达完整。

用例：客服回复起草

把你们的政策和真实客户消息喂给它：

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 400,
    "reasoning": {"effort": "medium"},
    "messages": [
      {
        "role": "system",
        "content": "You are a customer support agent for an online water bottle store. Policy: 30-day return window from delivery. Manufacturing defects reported after the window should be referred to the manufacturer'\''s own warranty. Reply in under 100 words, empathetic but concise, end with a clear next step."
      },
      {
        "role": "user",
        "content": "I bought a water bottle 35 days ago and the seal is already leaking. Can I get a refund or exchange?"
      }
    ]
  }'

实际响应，未经编辑：

很抱歉出现漏水问题。由于已经过去 35 天，订单超出了我们 30 天的退货窗口，所以我无法通过我们这边为您办理退货或换货。许多水瓶品牌对正常使用中的密封缺陷提供保修，因此我建议您直接联系制造商。如果您提供订单号，我可以给您品牌的详细信息，以帮助您提出索赔。

它正确应用了政策中的确切边界情况——35 天超过了 30 天窗口，所以它拒绝了直接退货，并转向制造商保修，而不是只道歉然后仍然提供退款。277 个 completion token，finish_reason: "stop"，答案完整、没有截断。这是同一个模型、同一个账户、与上面文案表格相同的 medium effort——这里的区别是 max_tokens: 400 给了它足够空间来同时推理和回答。

视觉能力可用，尽管模型卡说不行

还有一个经过真实验证的惊喜：claude-opus-5-5 的模型卡列出 Input modalities: text——任何地方都没有提到图像输入。但给它发一张图片仍然有效：

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 150,
    "messages": [{
      "role": "user",
      "content": [
        {"type": "text", "text": "In one sentence, what is in this photo?"},
        {"type": "image_url", "image_url": {"url": "https://example.com/photo.jpg"}}
      ]
    }]
  }'

实际响应，未经编辑（被上文提到的相同 max_tokens 机制截断——150 空间不够）：

这是一张整齐摆放的男士日常配饰平铺图，背景为灰色表面，包括一个黑色拉链钱包、一副飞行员太阳镜、一条粗花呢领结、一个笔记本

它正确读取了照片。模型卡上的“text”模态列示对这条路由来说是错误的，或者至少是不完整的——这与 claude-opus-4-8 文章在其视觉能力声明上遇到的“卡片与现实不一致”模式相同。不要构建依赖已发布模态列表来做限制的流水线；像上面的 reasoning 参数一样，发送真实请求并读取真实响应。

成本说明

九次真实调用，全部按单一 claude-opus-5-5 路由计费（该模型不存在 -aws 或其他定价变体，与 claude-opus-4-8 不同），按 hiapi 定价页的每百万输入 token $2.02、每百万输出 token $10.08 计算：

调用	prompt_tokens	completion_tokens	成本
effort 表格 × 5（minimal/low/medium/high/max）	650	2,495	$0.0264
xhigh 截断坑	185	500	$0.0054
空回复坑	157	300	$0.0033
客服回复	3,590	277	$0.0100
视觉测试	690	150	$0.0029
总计	5,272	3,722	$0.0482

这里没有任何图像生成——claude-opus-5-5 不生成图像，所以上面每一美元都是 token 成本，而两个“坑”行是值得额外预留预算的：它们为被截断或完全空白的输出支付了真实费用。

常见问题

claude-opus-5-5 能生成商品图片吗？ 不能。它的模型卡列出仅文本的输入和输出模态，上面每个响应都是文本。如果任务实际上是生成新的商品摄影图，那需要图像生成模型，而不是这个。

更高的 reasoning.effort 会更贵吗？ 本身不会。在固定 max_tokens 下，上面测试中五个已文档化级别计费的 completion token 数量完全相同——effort 改变的是写作，不是 token 数量。真正更贵的是提高 max_tokens，给更高 effort 级别留出同时推理和回答的空间。

为什么我得到了空响应却没有错误？ max_tokens 对于模型在写作前进行的内部推理来说太低了。这不是 bug——finish_reason 会显示 "length"，你仍会为完整 token 数量付费，但 content 可能返回空白或被截断。始终检查 content 非空且完整，而不只是检查调用返回了 200。

它实际支持图像输入吗？ 支持，已通过在上面的请求中发送真实图片并得到准确描述来确认——尽管模型自己的卡片把 text 列为唯一输入模态。

开始使用

要自己尝试：需要一个 hiapi API 密钥、claude-opus-5-5 模型页（查看当前定价和完整 reasoning-effort 列表），如果你正在为同样的电商文案和客服工作负载比较纯文本模型，claude-opus-4-8 文章在上一代 Opus 上覆盖了相同内容——在切换生产流水线之前，值得检查上面的 max_tokens/reasoning 权衡是否值得升级。