这两条路径的分界不在模型本身，而在控制权放在哪一层：写作路径要你自己管输入怎么切、风格怎么限定；调用路径要你自己管请求怎么发、返回怎么解析。先确定在哪边动手，再准备对应的东西，后面的返工能少很多。

如果只是用对话界面写中文长文，重点是把素材按段落或大纲切分，每段带上风格和字数约束，再逐段接续；如果要把模型接进自己的程序，重点是先把一个不带流式的最小请求跑通，确认返回字段和长度上限，再处理分段与拼接。长文本的瓶颈也不一样：前者多受单次输入长度影响，后者多受超时与分段衔接影响。具体上限需要结合所用模型版本和账号配置确认。

写作路径：先定素材切分与风格约束

在对话界面写长文，最容易被跳过的一步是把素材先切好。一次性把几千字原始素材丢进去，通常会出现两类情况：中间部分被压缩或忽略，后面的要求也照应不上。可以先在本地把素材按段落或按大纲切开，每次只给一段。

• 按大纲切：先让模型只输出一份章节大纲，确认结构后再逐节展开，适合结构本身还不清楚的题材。
• 按原文段落切：素材自带段落结构时直接一段一段给，保留段号，后面拼接时好对照。
• 切分标记建议带序号，例如「第 3/12 段」，复查时能快速定位漏掉的是哪一段。

每段的风格与字数约束，一般在同一段提示里写清楚，不要等生成完再回头改语气。可判定的规则比模糊描述更容易在检查环节对照。

本段为第 3/12 段，主题：……

要求：
- 风格：说明文，少用形容词，不出现第一人称
- 长度：300 字左右，上下浮动不超过 50 字
- 承接：上一段结尾提到……，本段开头不要重复这句话
- 输出：只输出正文，不要小标题

风格栏里写「不出现第一人称」「不用形容词」这类能当场判定的规则，比写「自然一些、正式一些」有用得多。

调用路径：写出一个最小请求骨架

接进程序时，建议先跑通一次不流式、不批量、只发一段的调用，确认能拿到完整返回，再考虑并发和长文本。下面的骨架是通用结构，字段名以你所用的接入方式为准，先对照实际返回调整，不要直接照抄。

POST /v1/chat/completions
Content-Type: application/json
Authorization: Bearer $API_KEY

{
  "model": "按账号可用模型填写",
  "messages": [
    {"role": "system", "content": "你是中文长文写作助手。"},
    {"role": "user", "content": "本段要求：风格说明文，300 字左右……"}
  ],
  "max_tokens": 800,
  "temperature": 0.7,
  "stream": false
}

三个字段先弄清作用：messages 放输入文本和角色，max_tokens 决定单次最多生成多少，stream 决定一次性返回还是逐块返回。第一次调用把 stream 设为 false，返回结构看起来更完整，也好写解析。

返回结果的读取方式，关键是第一步不要直接取字段，而是把整个返回打印出来对照：

resp = session.post(url, headers=headers, json=body, timeout=60)
data = resp.json()
print(data)                                  # 先整体打印，确认字段路径
text = data["choices"][0]["message"]["content"]
finish = data["choices"][0].get("finish_reason")
print(finish)                                # 出现 length 通常说明被长度截断

不同封装的字段路径不完全一样，有的把文本放在 output.text 之类的位置，所以先打印再取值。finish_reason 这类结束标记建议每次都读，看到 length 一类取值，一般意味着这一段要么输入太长，要么 max_tokens 给得太小。

对比两条路径对长文本的处理差异

同一份长素材放哪边更稳，取决于你更怕丢内容，还是更怕等太久。输入变长时，两边要盯的观察点并不相同。

• 写作路径看内容覆盖：是否出现中间段落被跳过、只写了后半部分。验证方式是把分段序号和要求一起贴回去，让模型指出哪几段没有体现。
• 写作路径看风格衰减：多轮对话变长后，最早设定的风格还生不生效。可以让模型复述当前生效的风格规则，再和最初设定比对。
• 调用路径看耗时构成：分段调用时，单段耗时乘以段数就是主要时间来源，先用一段的耗时估算整体。
• 调用路径看超时与截断：超时一般发生在客户端或网关侧，截断一般体现在结束标记或返回文本结尾不完整。

记录方式建议固定成几列：段号、输入字数、输出字数、耗时、结束标记。用一个 CSV 就够，但同一批任务每次都记，才能比较不同切分粒度下的差别。具体阈值需要结合所用模型和网络环境确认，不要照搬别人的数字。

给输出做一致性与完整性检查

分段写完不等于文章成立，拼接处往往是问题最集中的地方。检查顺序建议先做机械项，再做语义项。

• 段号是否连续，中间有没有一段根本没生成。
• 相邻两段的首尾句是否在重复说同一件事。
• 人名、术语、数字在不同段落里的写法是否一致。
• 每段字数是否落在设定范围内，明显偏短的段通常内容不全。
• 全篇的人称、时态、语气是否统一。

机械项过完，再用同一份大纲和同一套段落要求复跑一次，把两次结果按段并排放在一起看。重点不是判断哪次写得更好，而是看两次是否在同一位置出现同样的偏差：每次都漏掉同一段、每次都在同一处跑题，通常说明是切分方式或约束写法的问题，而不是模型偶然的波动。

按任务类型选路径

三种情形对应的选择比较清楚：

• 需要人工反复调整的，走写作路径。边看输出边改提示，改完立刻能看到效果，不用写代码。
• 需要批量跑同一套流程的，走调用路径。把切分、请求、拼接写成脚本，同一份大纲可以稳定复跑，也方便留下上一步那份记录。
• 需要接进已有程序的，走调用路径。先固定返回解析和超时处理，再考虑并发，不要一上来就并行。

还有一类混合情形值得先试：用写作路径把大纲和每段约束打磨到满意，再把这份提示原样搬到调用路径里跑批量。调风格和跑批量各用各顺手的工具，就不必在还没想清楚要写成什么样的时候先写代码。