一篇说明文的几轮便宜草稿和最后一次精修

写一篇产品说明时，第一轮通常不是成稿。你可能先改标题，再调整顺序，删掉一段，最后才发现例子不合适。如果每次尝试都调用高成本模型，预算就会花在大量注定被丢弃的文字上。

一个朴素的安排是：先用低成本模型探索，等内容基本确定，再用高成本模型做最后一轮精修。目的不是让便宜模型包办一切，而是把更贵的调用留给真正值得保留的版本。

§ 先分清探索和交付

探索阶段允许粗糙。你需要的是几个方向、一份提纲，或者能暴露问题的初稿。交付阶段则需要表达准确、结构连贯，并且符合读者的理解能力。两类任务对模型的要求不同，不必从头到尾使用同一种配置。

价格也不等于质量保证。选择前应查看当前输入和输出单价，再用同一小段任务试跑。例如，可以把 DeepSeek V4 Flash 和 Claude Sonnet 5.5 作为候选，观察它们在你的材料上是否适合分别承担起草与精修，而不是仅凭名称分工。

§ 给草稿一个小而明确的任务

不要一开始就要求“写出可以发布的完整文章”。先交代读者、用途、已知事实和长度，再让模型完成一个有限步骤。任务越清楚，越容易判断结果是否值得继续加工。

• 先列提纲，检查是否回答了读者的问题。
• 再写粗稿，允许措辞普通，但不能补造事实。
• 针对问题修改，例如删掉重复内容，或者补上一个已核实的例子。

一条可用的起草指令是：“根据以下材料写一份说明文草稿。读者没有技术背景。只使用给定事实，缺失信息标为待确认，暂时不要润色标题。”这样，第一轮的目标是得到可检查的内容，而不是漂亮的句子。

§ 在升级模型前设置一道检查

低成本调用也会累积。连续要求“再写一版”，却没有指出哪里不对，可能只是生成更多相似文本。每次修改最好解决一个明确问题，并设定停止条件。

进入最后一轮前，检查三件事：事实是否有依据，结构是否已经确定，还有没有未解决的关键问题。如果产品限制仍不清楚，就先核实材料；更昂贵的模型不能替你确认未提供的事实。

§ 最后一轮只带上必要材料

切换模型时，不必复制整个对话。整理一份简短交接材料：当前稿件、确认过的事实、读者要求，以及不能改动的术语。被否决的提纲和旧版本通常不需要继续传入。

精修指令也应限定范围：“请保留事实和结论，改善段落衔接，删除重复表达，检查术语是否一致。不要新增功能承诺；发现疑点请单独列出。”最后一轮是质量检查，不是重新自由创作。完成后仍要由人核对数字、名称和关键承诺。

§ 用统一接口减少切换负担

如果你通过程序调用模型，Vana API 提供统一入口，兼容 OpenAI 接口，也支持 Anthropic Messages 和 Gemini 原生协议。对于使用 OpenAI SDK 的程序，在请求格式兼容的前提下，可以复用调用逻辑，调整模型标识；不同模型支持的参数仍需核对。

Vana API 按实际令牌用量计费，没有月费。你可以创建一个账户，用一篇短文试跑这套流程，并记录每一步的输入量、输出量和费用。先做小测试，比直接迁移整批任务更容易判断收益。

§ 看整篇文章的账，而不是单次价格

令牌是模型计量文本的单位，并不等于汉字数。提示词、附带材料和生成结果都会影响费用，具体取决于模型的计费规则。草稿写得越长、历史记录带得越多，低单价的优势就越可能被重复消耗抵消。

比较时，把所有草稿、重试和最终精修加在一起，也记下人工修改时间。如果文章已经很短，或者本来就只需一次调用，拆成多轮未必划算。这套安排适合需要反复探索、但最终只保留一个版本的任务：便宜地试，明确地收敛，最后再认真打磨。