把写作工具和本地模型混着用，最常见的坏结果是：大纲在写作工具里已经改到第三版，出稿时模型还在按第一版写；或者反过来，正文写到一半发现人物动机对不上，回头改人物卡又得重写。比较稳的做法是先划一条线——Pagekin 这类结构工具负责决定「写什么」，Ollama 负责把已经决定的东西变成句子，两边只通过一份章节任务单交接。这条线固定下来，换模型、改大纲都不至于让整条链路重来。

适用场景是自己在本机写长篇、不希望把未定稿交给在线服务的人。动作上只有一条硬规矩：章节任务单是唯一交接物，模型不读大纲原文，写作工具不负责生成正文。判断两边是否真的分开，看断网后能不能只凭任务单跑出一章——能跑完，说明结构侧和出稿侧已经解耦；哪一步先断，问题就锁定在那一环。边界也要说清：人物动机、伏笔取舍这类判断仍归人工，模型只承担把约束展开成句子。

把写作流程拆成五步：设定、大纲、章节任务、出稿、修订

五步的分界线不是按工作量划的，是按「要不要做判断」划的。需要取舍的留在人这边，剩下的机械展开交出去。

出稿之所以能整段交出去，是因为它本质上是「把已有约束翻译成句子」的重复劳动，不产生新的剧情决定。反过来，章节任务这一环看起来只是填表，实际决定了本章要不要推进主线，所以必须停在人工确认上，不要图快让工具自动填完直接送模型。

结构侧：大纲、人物卡、章节任务该产出什么形态

判断结构侧产出好不好，只有一个标准：下一环能不能不经二次解释直接用。能直接粘贴进提示词、不需要人再补一句「这里的意思是……」就算合格。下面这三段是形态示例，字段名可以按 Pagekin 的字段体系调整，颗粒度建议照着来。

# 人物卡 char_02.yaml
id: char_02
姓名: 沈砚
身份: 旧书店店主，前档案员
目标: 找回被调包的账册，不愿惊动警方
说话方式: 短句，少用形容词，被追问时先反问一句
已知范围: 只知道第一章至第三章发生的事，不提前知道结局
关系: 对 char_01 有旧交，但不愿承认

# 大纲条目 outline_ch05.yaml
章号: 5
一句话目标: 沈砚发现账册上的笔迹属于自己认识的某个人，决定先瞒下
承上: 接第 4 章末尾的仓库对峙
启下: 为第 7 章的翻脸埋一次没说出口的犹豫

颗粒度上有个容易踩的坑：人物卡写「性格开朗」「城府很深」这类评价词，模型拿不到可执行信息，写出来所有角色说话都一样。要写成能被直接照做的东西——句子长度、口头禅、遇到冲突时的第一个反应、知道什么不知道什么。其中「已知范围」这一项尤其值得单独列，它防的是角色提前说出后面章节才该知道的信息，这是长篇里最难在修订阶段补救的错误。

出稿侧：投给本地模型的固定提示模板与模型选择

模板的作用不是让某一次生成更好，而是让换模型时输入格式不变。骨架按角色、任务、约束、长度四块写，任务单整体作为一个变量塞进去，这样换 7B 还是换更大的模型，改的只是请求里的模型名和参数。

你是一名中文小说代笔，只负责把下面的章节任务单写成正文，不做剧情增删。

【角色】
你熟悉这部长篇的设定，但本章你只掌握任务单里给出的信息。

【任务】
把任务单里「本章目标」写成一个完整场景，从承接点开始，到目标达成为止。

【约束】
- 只写本章，不要写下一章的开头
- 出场人物只能是任务单里列出的人
- 「禁止发生的事件」一条都不能出现
- 不要复述任务单原文，转成对话和动作
- 任务单没写的背景不要自行补充

【长度】
约 {{字数}} 字，允许上下浮动两成。

【章节任务单】
{{TASK_CARD}}

投递时模型名是唯一的替换点。先用 ollama list 确认本机已有的模型名，再原样填进请求，不要凭记忆写。下面这段可以直接在终端里跑，把 model 换掉即可对比不同模型在同一份任务单上的表现。

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "替换成 ollama list 里显示的名字",
  "prompt": "（这里是上面那段完整模板，任务单已代入）",
  "stream": false,
  "options": { "temperature": 0.7, "num_ctx": 8192 }
}'

参数上的取舍：temperature 建议从 0.7 附近试起，太低会让对白变得僵硬，太高则容易脱离任务单自行加戏，具体值要结合你用的模型和章节类型自己调。num_ctx 要大于提示词加任务单的总长度，否则模型看到的是被截断的输入，表现是前半章正常、后半章跑题，这类问题很容易被误判成模型能力不行。选模型的判断标准也更简单：能稳定遵守「禁止发生的事件」和「出场人物范围」这两条约束的模型就够用，不需要它在文风上一步到位，文风留在修订环节处理。

交接物：一份章节任务单要写哪些字段

任务单写细一点，两头来回改的次数就少一点。下面这份字段清单可以直接当成模板用，前四项是必需的，缺一项就容易返工。

# 章节任务单 ch05.task.md
本章目标: 沈砚在账册上认出熟人笔迹，选择隐瞒
出场人物:
  - char_02 沈砚（主视角，本章情绪由怀疑转为戒备）
  - char_01 林知远（只出现在结尾一次对话里）
时间地点: 当晚，旧书店后间
必须发生:
  1. 沈砚看到账册第 12 页的签名
  2. 林知远来访，沈砚没有提这件事
禁止发生:
  1. 不要让两人当场摊牌
  2. 不要出现警方介入
  3. 不要交代账册是谁调包的
承接上一章: 仓库对峙后沈砚带走了账册
留给下一章: 沈砚把账册藏起来的具体位置先不写
篇幅: 约 1800 字

「必须发生」和「禁止发生」这两组要分开写，不要合成一句「本章不要写得太快」。禁止项写得越具体，返工越少——模型的默认倾向是把冲突写到位，你不明确禁止，它就会在第五章就让人物摊牌。「承接上一章」和「留给下一章」两项是给修订用的，出稿时模型未必用得好，但修订时能快速判断这一章有没有跑偏。

验证离线可用：断网后完整跑一章，看哪一步先断

配置看起来对，不代表链路真的不依赖外部服务。验证方式就是物理断网，然后从头跑一章，记录第一个报错出现在哪一环。步骤建议这样走：

1. 联网状态下先确认服务在跑：curl -s http://127.0.0.1:11434/api/tags 能返回模型列表，说明 Ollama 服务监听正常。
2. 确认模型名与配置一致：ollama list 的输出要和请求里的 model 字段逐字对得上。
3. 用一段两百字左右的小输入先跑通一次，排除任务单本身的格式问题。
4. 断开网络（关掉无线或停用网卡，按你的系统选择合适方式），再重复第 1、3 步。
5. 把真实的第五章任务单代入模板，完整跑一次，保存请求体、响应和耗时到日志文件，方便回看。

失败时按服务、模型、配置、输入长度这个顺序排查，不要跳步。服务层看端口是否在监听、进程是否还活着；模型层看名字拼写和是否已经拉取到本地，显存或内存不足导致的加载失败也常在这一层暴露；配置层看客户端指向的地址是不是 127.0.0.1，有没有被环境变量改成外部地址，超时时间是否过短；最后才看输入长度，任务单加上模板超过 num_ctx 时，报错未必明显，更多表现为输出后半段失控。按这个顺序走，多数情况下第一或第二步就能定位，不用反复改提示词。