在处理过长提示词时，Firefly API 的单次请求长度限制常常成为障碍。如果直接提交超出限制的文本，很容易触发截断，导致生成内容偏离主题，甚至后半部分完全偏离原意。解决这一问题的核心思路是：先依据语义单元进行切分，再并发提交多个请求，最后将返回的结果按原始顺序拼接起来。这个流程看似简单，但每个环节都有值得注意的技巧。

首先是最关键的步骤——切分。不能简单地按字符数一刀切，必须在完整的语义节点处进行分割。例如句号、换行符或自然段落结束的位置都是理想的分割点。最忌讳的是在名词短语中间强行拆分，比如“高性能GPU加速的实时渲染管线”这个完整术语，如果被拆成“高性能GPU加速的/实时渲染管线”，并发提交后模型将无法识别其整体含义。每个分片的建议长度控制在800字符以内，并保存为独立的 UTF-8 无 BOM 文本文件，命名方式如 prompt_01.txt、prompt_02.txt 即可——Firefly API 对含 BOM 的文件可能出现解析失败的情况，务必留意。

准备提示词分片：拆得巧妙，才能合得顺畅

将原始长文本按逻辑单元切分完成后，每个分片都需要独立保存。这一步虽然技术门槛不高，却决定了下游所有环节的成败。

构造并发请求体：两套方案，各有优劣

有了分片文件，下一步就是并发提交。这里有两种常用的做法。

方法一：curl 批量发送

如果你偏爱命令行操作，可以逐个构建 JSON 请求体。每个请求体中必须包含 model 字段（例如 "firefly-v2"）和 input 字段（对应分片的文本内容）。注意，缺少 model 字段会导致 400 错误，并且 API 不会给出明确提示，排查起来相当棘手。将所有请求体存入 requests.jsonl 文件，每行一个合法的 JSON 对象，不需要逗号，也不要包成数组。

方法二：Python 脚本调用 requests 库

这种方式更加灵活，适合需要频繁调试的场景。使用 for 循环遍历分片列表，对每个分片单独调用 requests.post()。headers 需要设置为 {"Authorization": "Bearer YOUR_TOKEN", "Content-Type": "application/json"}。一个容易被忽略的细节是超时时间：默认的 5 秒在网络抖动时很容易导致请求中断，建议设置为 30 秒以上。

合并返回结果：顺序不能乱，清洗不可少

所有并发请求返回后，就进入了组装阶段。步骤很清晰：首先，逐个检查每个响应的 status_code，确保全部为 200；其次，从每个 response.json()["output"]["text"] 中提取返回的文本片段；然后，严格按原始分片的顺序拼接这些文本，中间用一个空行作为天然分隔；最后，使用正则表达式重新清洗合并后的文本，例如用 re.sub(r'\n{2,}', '\n\n', merged_text) 去掉多余的空行。Firefly 在段尾补全文字时偶尔会多输出几个换行，如果不清理，最终内容的段落间距会显得很不自然。