1. 从零搭一个小说自动生成系统为什么第一步是统一 LLM 通道想用大模型写小说很多人第一反应是打开某个网页对话框把主题丢进去等它吐几千字出来。玩一两次可以但只要你打算把它做成一个能反复跑、能扩展、能接自己前端的产品网页对话框这条路很快就走不通了。原因很直接你需要的是程序化调用是能嵌进代码里的 SDK是能控制温度、能重试、能解析结构化输出的稳定通道。我这次要做的是一个最小可跑通的小说自动生成系统。它的目标不是一上来就搞出十万字长篇而是先跑通一个闭环给定主题和章节数让大模型先产出结构化大纲再逐章扩写正文最后把结果落盘。这个闭环里有两个关键角色一个是大模型本身另一个是 Prompt。大模型负责生成Prompt 负责约束它生成什么、以什么格式生成。而把这两者串起来的是一个统一的调用通道。这里就引出一个现实问题市面上的模型太多了。DeepSeek、Moonshot、通义、还有本地跑的 Ollama它们大多提供 OpenAI 兼容接口但 base_url、api_key、模型名各不相同。如果每换一个模型就改一遍代码项目会变得很难维护。所以我选择用 TaoToken 作为统一入口把 Key 和 API 通道收敛到一处代码里只认一套配置。这样后面无论换模型还是加模型改动都集中在配置文件里业务逻辑一行不用动。这篇文章面向的是想快速验证 AI 写作流程的开发者。你不需要有很深的机器学习背景只要会 Python、能看懂 JSON、愿意动手敲命令就行。我会给出可复制的 SDK 初始化配置、Prompt 模板以及一次真实的生成验证动作。跑完之后你手里会有一个能自己扩展的小说生成骨架。先说清楚整体设计。一本小说抽象出来就是标题、主题、全书梗概加上若干章节。每个章节有顺序、标题、本章情节要点、可选线索以及最重要的正文字段。注意这里有个设计取舍规划阶段生成大纲时各章节的正文是空的写作阶段再逐章把正文填进去。所以不需要为「已写完的章节」单独建一个类同一个章节模型正文字段从空到满就行。这个设计让数据流非常干净规划、写作、导出三个阶段共用一套数据结构。环境方面我用的是一台普通开发机Python 3.11包管理用 uv。uv 比 pip 快很多初始化项目、建虚拟环境、装依赖都是一条命令的事。整个项目目录叫 Novel核心代码放在 src 下。下面我会一步步带你把这个骨架搭起来重点放在配置、Prompt 和 LLM 客户端这三块因为它们决定了系统能不能稳定跑通。2. TaoToken 前置准备把 Key 和 API 通道收敛到一处在写任何业务代码之前先把模型接入这层搞定。这一步做扎实了后面调试会省很多事。TaoToken 的作用简单说就是给你一个统一的 OpenAI 兼容端点你用一套 Key 就能调用多种模型不用为每个模型单独申请、单独配置。对于小说生成这种需要反复试不同模型、调不同温度的场景这种统一入口非常实用。先拿到你的 API Key。登录 TaoToken 官网进入控制台在 API Keys 页面创建一个新的 Key。创建时给它起个能认出来的名字比如 novel-dev方便以后区分。Key 只在创建时完整显示一次复制下来存好别直接写死在代码里后面我们会用 .env 文件管理。拿到 Key 之后记下两个地址。API 基础地址是 https://taotoken.net/api这个地址兼容 OpenAI 的接口规范所以任何支持 OpenAI SDK 的代码都能直接对接。模型对话的入口在 https://taotoken.net/api 下的 chat completions 路径SDK 会自动拼接你只需要填 base_url 就行。这里要强调一个概念Base URL、API Key、Model ID 这三件套是接入任何 OpenAI 兼容服务的核心。Base URL 告诉 SDK 请求发到哪里API Key 证明你有权限Model ID 决定用哪个模型。三者缺一不可而且必须匹配。很多人接入失败不是代码写错了而是这三件套里有一个填错了比如 base_url 多写了斜杠或者 model 名拼错了。关于模型选择TaoToken 支持多种模型你可以根据任务特点来挑。大纲规划这种需要结构化输出、逻辑严谨的任务适合用指令遵循能力强的模型正文扩写这种需要文采和创造力的任务可以换一个更擅长写作的模型。因为通道统一了换模型只需要改配置里的一个字符串非常灵活。如果你打算长期做编码和 Agent 类的开发可以了解一下 Coding Plan它针对这类高频调用场景做了优化。不过对于本文这个小说生成的最小闭环按量调用就够了先把流程跑通再说。配置这块我建议在项目根目录建一个 .env 文件把所有敏感信息和可变参数都放进去。这样做有两个好处一是代码里不出现明文 Key二是换模型、调温度不用改代码。下面是我实际用的配置你可以直接复制把 API_KEY 换成你自己的。# LLM 服务配置 # 兼容 OpenAI 及所有 OpenAI 兼容端点 API_KEY你的_TaoToken_Key BASE_URLhttps://taotoken.net/api MODELdeepseek-v4-flash # 生成参数 # 大纲偏稳低一些正文偏活高一些 OUTLINE_TEMPERATURE0.7 CHAPTER_TEMPERATURE0.85 MAX_TOKENS4096 # 重试 MAX_RETRIES3注意 BASE_URL 这里填的是 TaoToken 的 API 地址不是某个具体模型厂商的地址。这就是统一通道的价值你的代码只认这一个地址背后用哪个模型由 MODEL 字段决定。温度参数我分成了两个大纲用 0.7正文用 0.85原因后面讲温度的时候会详细说。装依赖的时候除了 openai 这个 SDK还要装 python-dotenv它负责把 .env 文件里的配置读进环境变量。命令是 uv add openai python-dotenv。装完之后写一个 config.py 把这些配置加载进来供其他模块使用。import os from dotenv import load_dotenv load_dotenv() # 自动加载当前目录下的 .env 文件 api_key: str os.getenv(API_KEY, ) base_url: str os.getenv(BASE_URL, https://taotoken.net/api) model: str os.getenv(MODEL, deepseek-v4-flash) outline_temperature: float float(os.getenv(OUTLINE_TEMPERATURE, 0.7)) chapter_temperature: float float(os.getenv(CHAPTER_TEMPERATURE, 0.85)) max_tokens: int int(os.getenv(MAX_TOKENS, 4096)) max_retries: int int(os.getenv(MAX_RETRIES, 3))这段代码里os.getenv 的第二个参数是默认值。这样即使 .env 文件里漏了某一项程序也不会直接崩而是用一个合理的默认值兜底。对于 base_url我特意把默认值设成了 TaoToken 的地址这样即使配置缺失请求也会发到统一通道而不是某个不确定的地方。到这里前置准备就完成了。你有了 Key有了统一地址有了配置文件加载逻辑。接下来就是写真正调用模型的代码。3. 可复制配置Prompt 模板与 LLM 客户端怎么写这一节是全文的核心我会把 Prompt 模板和 LLM 客户端两块代码完整给出来你复制过去改改就能用。先说 Prompt因为它是决定生成质量的关键。小说生成分两个阶段规划阶段和写作阶段两个阶段的 Prompt 风格完全不同。规划阶段要求模型输出严格的 JSON因为后面代码要解析它、存进数据结构。写作阶段要求模型输出纯正文因为那是给人看的小说内容。这两套 Prompt 我放在一个 prompt.py 文件里集中管理不散落到业务逻辑里方便以后调优。规划阶段的系统提示词核心是约束模型只输出 JSON不要夹带解释、不要包 markdown 代码块。这一点非常重要因为大模型有个习惯喜欢在 JSON 外面加一句「好的这是您要的大纲」之类的话或者用 json 包起来。这些都会导致解析失败。所以提示词里要明确禁止。OUTLINE_SYSTEM 你是一位资深小说策划与编辑。你的任务是根据用户给定的主题生成一份结构清晰、情节连贯的小说大纲。 你必须严格只输出一个 JSON 对象不要输出任何解释、前后缀文字或 markdown 代码块标记不要写 json。 JSON 结构如下 { title: 小说标题, theme: 用户给定的主题, summary: 全书梗概100~200 字交代背景、主线与结局走向, chapters: [ { index: 1, title: 第X章 章节标题, outline: 本章核心事件、出场人物、情节要点3~5 句话, clues: [可选本章埋设或呼应的线索] } ] } 要求 - 章节数量严格等于用户指定数量 - 章节之间情节递进、有因果不能各自孤立 - 每章 outline 要具体到可据此扩写正文不要空泛 def outline_user(theme: str, chapter_count: int) - str: return ( f主题{theme}\n f章节数量{chapter_count}\n\n f请据此生成大纲 JSON。只输出 JSON 本身。 )写作阶段的系统提示词重点转向文笔和连贯性。这里要告诉模型遵循大纲但不要照抄要丰富细节要和全书设定、前情保持一致只输出正文不要复述大纲。字数要求也写进去我设的是不少于 1500 字你可以按需调整。CHAPTER_SYSTEM 你是一位文笔老练的小说家。你的任务是根据给定的大纲章节信息扩写出该章的完整正文。 要求 - 遵循本章大纲的情节要点但不要照抄要丰富细节、对话、场景描写 - 与全书设定、人物性格、前情保持一致不要出现前后矛盾 - 文风统一语言生动 - 只输出小说正文可使用 Markdown 段落不要输出 JSON不要解释不要复述大纲 - 正文字数不少于 1500 字 def chapter_user( book_title: str, book_summary: str, chapter_title: str, chapter_outline: str, chapter_clues: list[str], prev_ending: str , ) - str: clues_text .join(chapter_clues) if chapter_clues else 无 parts [ f【全书标题】{book_title}, f【全书梗概】{book_summary}, f【本章标题】{chapter_title}, f【本章大纲】{chapter_outline}, f【本章线索】{clues_text}, ] if prev_ending: parts.append(f【上一章结尾】……{prev_ending}\n请衔接上一章结尾保持连贯) parts.append(\n请扩写本章正文。) return \n.join(parts)注意 chapter_user 里有个 prev_ending 参数用来把上一章的结尾片段传给模型让它衔接。这是保证长篇连贯性的一个小技巧。首章没有上一章传空字符串就行。Prompt 准备好了接下来是 LLM 客户端。这是全项目唯一和模型打交道的地方其他代码都通过它调模型。它要提供两种调用方式普通对话返回文本要 JSON 的对话返回解析好的字典。后者有个现实问题模型经常把 JSON 包在代码块里或夹带废话所以拿回来要先清洗再解析如果还是失败就把错误回喂给模型让它自己改一次。先定义异常层次区分「调用本身失败」和「JSON 解析失败」这样上层代码能针对性地处理。class LLMError(Exception): 所有 LLM 相关异常的基类。 class LLMConnectionError(LLMError): 调用本身失败网络错误、超时、限流、服务端 5xx 等。 class LLMJSONError(LLMError): LLM 返回了文本但 JSON 解析失败。 def __init__(self, message: str, raw_text: str, parse_error: str): super().__init__(message) self.raw_text raw_text self.parse_error parse_error然后是客户端实例的延迟导入。为什么要延迟导入因为这样即使没装 openai纯逻辑部分比如 JSON 清洗也能单独测试不会因为 import 失败而整个模块挂掉。_client None def _get_client(): global _client if _client is None: from openai import OpenAI _client OpenAI(api_keyconfig.api_key, base_urlconfig.base_url) return _client核心的调用函数带指数退避重试。网络抖动、限流这些情况很常见一失败就崩体验很差。重试策略是 1 秒、2 秒、4 秒这样退避最多重试 config.max_retries 次。判断哪些异常值得重试也有讲究超时和限流值得重试5xx 服务端错误值得重试4xx 客户端错误比如 Key 错了重试也没用直接抛。def _should_retry(exc: Exception) - bool: try: from openai import APIError, APITimeoutError, RateLimitError except ImportError: return False if isinstance(exc, (APITimeoutError, RateLimitError)): return True if isinstance(exc, APIError): status getattr(exc, status_code, 0) or 0 return 500 status 600 return False def _chat_messages(messages: list[dict], temperature: float | None) - str: client _get_client() max_attempts config.max_retries 1 last_exc None for attempt in range(1, max_attempts 1): try: resp client.chat.completions.create( modelconfig.model, messagesmessages, temperaturetemperature, max_tokensconfig.max_tokens, ) return resp.choices[0].message.content or except Exception as e: last_exc e if _should_retry(e) and attempt max_attempts: wait 2 ** (attempt - 1) time.sleep(wait) continue raise LLMConnectionError( fLLM 调用失败尝试 {attempt} 次后放弃: {e} ) from e raise LLMConnectionError( fLLM 调用失败尝试 {max_attempts} 次后放弃: {last_exc} )JSON 清洗函数负责把模型返回的文本里真正的 JSON 抠出来。策略是先去 markdown 代码块标记再找第一个 { 和最后一个 } 之间的内容。这个策略覆盖了绝大多数情况。def _clean_json(raw: str) - str: text re.sub(r(?:json)?\s*, , raw).strip() start text.find({) end text.rfind(}) if start ! -1 and end ! -1 and end start: return text[start : end 1] return textchat_json 是重点。它先调一次解析失败就把错误和原始输出回喂给模型让它自己修正一次。第二次还失败才抛 LLMJSONError。这个自我修正机制在实际使用中能救回不少格式问题。def chat_json(prompt: str, system: str | None None, temperature: float | None None) - dict: messages [] if system is not None: messages.append({role: system, content: system}) messages.append({role: user, content: prompt}) raw _chat_messages(messages, temperature) cleaned _clean_json(raw) try: return json.loads(cleaned) except json.JSONDecodeError as e: first_error str(e) fix_prompt ( 你上次返回的内容不是合法的 JSON。\n f解析错误{first_error}\n\n f你上次返回的原始内容\n{raw}\n\n 请只输出一个合法的 JSON 对象不要包含任何解释、前后缀文字或 markdown 代码块标记。 ) fixed_messages messages [ {role: assistant, content: raw}, {role: user, content: fix_prompt}, ] raw2 _chat_messages(fixed_messages, temperature) cleaned2 _clean_json(raw2) try: return json.loads(cleaned2) except json.JSONDecodeError as e2: raise LLMJSONError( JSON 解析失败自我修正后仍失败, raw_textraw2, parse_errorstr(e2), ) from e2到这里配置、Prompt、客户端三块都齐了。这套代码的优点是换模型只改 .env调温度只改 .env业务逻辑完全不用动。而且异常分得清楚出问题能快速定位是网络问题还是格式问题。4. 验证请求跑通从设定到章节草稿的最小闭环代码写完了得验证它真能跑。这一节我带你把整个闭环跑一遍从主题输入到章节草稿落盘。先确认目录结构应该是这样的Novel/ ├── .env ├── pyproject.toml ├── src/ │ ├── __init__.py │ ├── config.py │ ├── prompt.py │ ├── llm_client.py │ └── schema.pyschema.py 里用 pydantic 定义数据结构。一本小说有标题、主题、全书概括、章节列表每个章节有顺序、标题、情节要点、线索、正文。正文默认空字符串写作阶段再填。from pydantic import BaseModel, Field class Chapter(BaseModel): index: int title: str outline: str clues: list[str] Field(default_factorylist) content: str class Novel(BaseModel): title: str theme: str summary: str chapters: list[Chapter] Field(default_factorylist)现在写一个验证脚本跑一次完整流程。先调大纲再逐章扩写。为了快速验证章节数设成 3正文长度要求可以临时调低。from src import config, prompt from src.llm_client import chat_json, chat from src.schema import Novel, Chapter def generate_outline(theme: str, chapter_count: int) - Novel: data chat_json( promptprompt.outline_user(theme, chapter_count), systemprompt.OUTLINE_SYSTEM, temperatureconfig.outline_temperature, ) return Novel(**data) def write_chapter(novel: Novel, chapter: Chapter, prev_ending: str ) - str: return chat( promptprompt.chapter_user( book_titlenovel.title, book_summarynovel.summary, chapter_titlechapter.title, chapter_outlinechapter.outline, chapter_clueschapter.clues, prev_endingprev_ending, ), systemprompt.CHAPTER_SYSTEM, temperatureconfig.chapter_temperature, ) if __name__ __main__: novel generate_outline(一个关于时间循环的悬疑故事, 3) print(f标题{novel.title}) print(f梗概{novel.summary}) for ch in novel.chapters: print(f {ch.index}. {ch.title} - {ch.outline[:40]}...) prev for ch in novel.chapters: ch.content write_chapter(novel, ch, prev) prev ch.content[-200:] print(f第 {ch.index} 章写完{len(ch.content)} 字)运行这个脚本你会看到类似这样的输出先打印出标题、梗概和章节列表然后逐章打印写完的字数。如果一切正常大纲的 JSON 被正确解析成了 Novel 对象每章正文也生成了。这就是从设定到章节草稿的最小闭环。验证的时候有几个点要留意。第一大纲返回的 JSON 里 chapters 的字段名要和 schema 对上如果模型返回了额外的字段pydantic 默认会忽略但如果缺了必填字段就会报错。第二正文生成时如果模型返回了空字符串可能是 max_tokens 设太小被截断了或者触发了内容过滤。第三如果中途报 LLMJSONError把 raw_text 打出来看看模型到底返回了什么多半是格式问题调整 Prompt 里的约束能解决。跑通之后你可以把生成结果存成文件方便查看和后续处理。比如把每章正文写进单独的 markdown 文件或者把整个 Novel 对象序列化成 JSON 存档。这些扩展都很简单因为数据结构是清晰的。实测下来这套流程在 TaoToken 统一通道上跑得很稳。换模型只需要改 .env 里的 MODEL 字段比如从 deepseek-v4-flash 换成别的写作模型代码一行不用动。这种灵活性对于需要反复试不同模型、调不同参数的创作类项目来说价值很大。5. 本篇常见错排查401、local proxy failed、reading choices 怎么解接入和调试过程中有几类报错特别常见。我把它们整理出来对照着排查能省不少时间。这些报错大多不是代码逻辑问题而是配置或环境问题。第一类是 401 错误提示 authentication failed 或 invalid api key。这几乎总是 Key 的问题。检查三处.env 里的 API_KEY 是不是复制完整了有没有多余的空格或换行这个 Key 在 TaoToken 控制台是不是还有效有没有被删除或过期代码里加载 .env 的路径对不对如果脚本不在项目根目录运行load_dotenv 可能找不到文件。一个快速验证方法是把 Key 打印出来看前几位和后几位确认没被截断。第二类是 local proxy failed 或 connection error。这类报错通常和网络环境有关。先确认 BASE_URL 填的是 https://taotoken.net/api注意是 https 不是 http末尾不要多加斜杠。然后检查本机有没有设置一些奇怪的全局代理有时候系统代理会干扰 SDK 的正常请求。如果你在公司网络里防火墙可能拦了外部请求换个网络环境试试。还有一种情况是 DNS 解析问题可以 ping 一下域名看能不能通。第三类是 reading choices 相关的报错比如 NoneType object has no attribute choices 或者 list index out of range。这说明 resp.choices 是空的或者 None。可能的原因有几个模型返回了内容但被内容过滤拦截了导致 choices 为空max_tokens 设得太小模型还没输出有效内容就结束了请求参数有问题比如 temperature 超出了模型支持的范围。排查方法是把完整的 resp 对象打出来看或者临时把 max_tokens 调大、temperature 调回默认值再试。第四类是 JSON 解析失败抛 LLMJSONError。这个前面讲过模型返回的文本不是合法 JSON。先看 raw_text如果里面夹带了「好的以下是」之类的话说明 Prompt 约束不够强在系统提示词里再强调一遍「只输出 JSON」。如果 JSON 本身格式有问题比如少了逗号、多了尾逗号chat_json 的自我修正机制会尝试救一次救不回来才抛错。如果频繁出现可以考虑换一个指令遵循能力更强的模型来跑大纲阶段。第五类是 OAuth 或权限相关报错。如果你用的是某些需要额外授权的服务可能会遇到 token 过期或 scope 不足的问题。对于 TaoToken 这种用 API Key 的方式一般不会遇到 OAuth 问题但如果你在代码里混用了其他认证方式要确认没有冲突。检查一下有没有环境变量里残留了其他服务的 Key导致 SDK 拿错了凭证。第六类是模型名错误提示 model not found。检查 .env 里的 MODEL 字段拼写大小写要和服务端一致。不同模型的命名规则不一样有的带版本号有的不带最好从 TaoToken 的文档里复制准确的模型 ID。如果换了模型但忘了改配置也会报这个错。排查这类问题的通用思路是先看报错信息里的关键词定位是认证、网络、参数还是格式问题再把关键变量base_url、model、key 前几位打印出来确认最后用最小化的请求单独测试排除业务代码的干扰。大部分问题都能在这三步里找到答案。6. 把通道固定下来让创作逻辑自由生长跑通这个最小闭环之后你会发现真正花时间的不是调用模型而是调 Prompt 和试参数。这时候一个稳定的接入通道就特别重要它让你能把精力集中在创作逻辑上而不是反复折腾配置。我现在的做法是所有模型调用都走 TaoToken 这一条通道Key 和地址固定在 .env 里业务代码只依赖 config 模块暴露的变量。这样无论后面是加大纲润色、人物设定管理还是接一个前端界面底层都不用动。想试新模型改一个字符串就行想调温度改一个数字就行。如果你也想快速验证自己的 AI 写作想法建议就从这套骨架开始。先把大纲和单章扩写跑通再逐步加功能。下一步可以做的方向很多给章节加人物一致性检查、把生成结果做成可编辑的草稿、加一个简单的 Web 界面让非开发者也能用。这些都是在稳定通道之上生长出来的东西。需要 Key 和接入文档的话可以从 API Keys 页面创建接入细节看接入文档。想先感受一下模型对话效果可以直接在模型对话里试。如果打算长期做编码和 Agent 相关的开发Coding Plan 值得了解一下。通道固定下来剩下的就是让创作逻辑自由生长了。
1. 从零搭一个小说自动生成系统为什么第一步是统一 LLM 通道想用大模型写小说很多人第一反应是打开某个网页对话框把主题丢进去等它吐几千字出来。玩一两次可以但只要你打算把它做成一个能反复跑、能扩展、能接自己前端的产品网页对话框这条路很快就走不通了。原因很直接你需要的是程序化调用是能嵌进代码里的 SDK是能控制温度、能重试、能解析结构化输出的稳定通道。我这次要做的是一个最小可跑通的小说自动生成系统。它的目标不是一上来就搞出十万字长篇而是先跑通一个闭环给定主题和章节数让大模型先产出结构化大纲再逐章扩写正文最后把结果落盘。这个闭环里有两个关键角色一个是大模型本身另一个是 Prompt。大模型负责生成Prompt 负责约束它生成什么、以什么格式生成。而把这两者串起来的是一个统一的调用通道。这里就引出一个现实问题市面上的模型太多了。DeepSeek、Moonshot、通义、还有本地跑的 Ollama它们大多提供 OpenAI 兼容接口但 base_url、api_key、模型名各不相同。如果每换一个模型就改一遍代码项目会变得很难维护。所以我选择用 TaoToken 作为统一入口把 Key 和 API 通道收敛到一处代码里只认一套配置。这样后面无论换模型还是加模型改动都集中在配置文件里业务逻辑一行不用动。这篇文章面向的是想快速验证 AI 写作流程的开发者。你不需要有很深的机器学习背景只要会 Python、能看懂 JSON、愿意动手敲命令就行。我会给出可复制的 SDK 初始化配置、Prompt 模板以及一次真实的生成验证动作。跑完之后你手里会有一个能自己扩展的小说生成骨架。先说清楚整体设计。一本小说抽象出来就是标题、主题、全书梗概加上若干章节。每个章节有顺序、标题、本章情节要点、可选线索以及最重要的正文字段。注意这里有个设计取舍规划阶段生成大纲时各章节的正文是空的写作阶段再逐章把正文填进去。所以不需要为「已写完的章节」单独建一个类同一个章节模型正文字段从空到满就行。这个设计让数据流非常干净规划、写作、导出三个阶段共用一套数据结构。环境方面我用的是一台普通开发机Python 3.11包管理用 uv。uv 比 pip 快很多初始化项目、建虚拟环境、装依赖都是一条命令的事。整个项目目录叫 Novel核心代码放在 src 下。下面我会一步步带你把这个骨架搭起来重点放在配置、Prompt 和 LLM 客户端这三块因为它们决定了系统能不能稳定跑通。2. TaoToken 前置准备把 Key 和 API 通道收敛到一处在写任何业务代码之前先把模型接入这层搞定。这一步做扎实了后面调试会省很多事。TaoToken 的作用简单说就是给你一个统一的 OpenAI 兼容端点你用一套 Key 就能调用多种模型不用为每个模型单独申请、单独配置。对于小说生成这种需要反复试不同模型、调不同温度的场景这种统一入口非常实用。先拿到你的 API Key。登录 TaoToken 官网进入控制台在 API Keys 页面创建一个新的 Key。创建时给它起个能认出来的名字比如 novel-dev方便以后区分。Key 只在创建时完整显示一次复制下来存好别直接写死在代码里后面我们会用 .env 文件管理。拿到 Key 之后记下两个地址。API 基础地址是 https://taotoken.net/api这个地址兼容 OpenAI 的接口规范所以任何支持 OpenAI SDK 的代码都能直接对接。模型对话的入口在 https://taotoken.net/api 下的 chat completions 路径SDK 会自动拼接你只需要填 base_url 就行。这里要强调一个概念Base URL、API Key、Model ID 这三件套是接入任何 OpenAI 兼容服务的核心。Base URL 告诉 SDK 请求发到哪里API Key 证明你有权限Model ID 决定用哪个模型。三者缺一不可而且必须匹配。很多人接入失败不是代码写错了而是这三件套里有一个填错了比如 base_url 多写了斜杠或者 model 名拼错了。关于模型选择TaoToken 支持多种模型你可以根据任务特点来挑。大纲规划这种需要结构化输出、逻辑严谨的任务适合用指令遵循能力强的模型正文扩写这种需要文采和创造力的任务可以换一个更擅长写作的模型。因为通道统一了换模型只需要改配置里的一个字符串非常灵活。如果你打算长期做编码和 Agent 类的开发可以了解一下 Coding Plan它针对这类高频调用场景做了优化。不过对于本文这个小说生成的最小闭环按量调用就够了先把流程跑通再说。配置这块我建议在项目根目录建一个 .env 文件把所有敏感信息和可变参数都放进去。这样做有两个好处一是代码里不出现明文 Key二是换模型、调温度不用改代码。下面是我实际用的配置你可以直接复制把 API_KEY 换成你自己的。# LLM 服务配置 # 兼容 OpenAI 及所有 OpenAI 兼容端点 API_KEY你的_TaoToken_Key BASE_URLhttps://taotoken.net/api MODELdeepseek-v4-flash # 生成参数 # 大纲偏稳低一些正文偏活高一些 OUTLINE_TEMPERATURE0.7 CHAPTER_TEMPERATURE0.85 MAX_TOKENS4096 # 重试 MAX_RETRIES3注意 BASE_URL 这里填的是 TaoToken 的 API 地址不是某个具体模型厂商的地址。这就是统一通道的价值你的代码只认这一个地址背后用哪个模型由 MODEL 字段决定。温度参数我分成了两个大纲用 0.7正文用 0.85原因后面讲温度的时候会详细说。装依赖的时候除了 openai 这个 SDK还要装 python-dotenv它负责把 .env 文件里的配置读进环境变量。命令是 uv add openai python-dotenv。装完之后写一个 config.py 把这些配置加载进来供其他模块使用。import os from dotenv import load_dotenv load_dotenv() # 自动加载当前目录下的 .env 文件 api_key: str os.getenv(API_KEY, ) base_url: str os.getenv(BASE_URL, https://taotoken.net/api) model: str os.getenv(MODEL, deepseek-v4-flash) outline_temperature: float float(os.getenv(OUTLINE_TEMPERATURE, 0.7)) chapter_temperature: float float(os.getenv(CHAPTER_TEMPERATURE, 0.85)) max_tokens: int int(os.getenv(MAX_TOKENS, 4096)) max_retries: int int(os.getenv(MAX_RETRIES, 3))这段代码里os.getenv 的第二个参数是默认值。这样即使 .env 文件里漏了某一项程序也不会直接崩而是用一个合理的默认值兜底。对于 base_url我特意把默认值设成了 TaoToken 的地址这样即使配置缺失请求也会发到统一通道而不是某个不确定的地方。到这里前置准备就完成了。你有了 Key有了统一地址有了配置文件加载逻辑。接下来就是写真正调用模型的代码。3. 可复制配置Prompt 模板与 LLM 客户端怎么写这一节是全文的核心我会把 Prompt 模板和 LLM 客户端两块代码完整给出来你复制过去改改就能用。先说 Prompt因为它是决定生成质量的关键。小说生成分两个阶段规划阶段和写作阶段两个阶段的 Prompt 风格完全不同。规划阶段要求模型输出严格的 JSON因为后面代码要解析它、存进数据结构。写作阶段要求模型输出纯正文因为那是给人看的小说内容。这两套 Prompt 我放在一个 prompt.py 文件里集中管理不散落到业务逻辑里方便以后调优。规划阶段的系统提示词核心是约束模型只输出 JSON不要夹带解释、不要包 markdown 代码块。这一点非常重要因为大模型有个习惯喜欢在 JSON 外面加一句「好的这是您要的大纲」之类的话或者用 json 包起来。这些都会导致解析失败。所以提示词里要明确禁止。OUTLINE_SYSTEM 你是一位资深小说策划与编辑。你的任务是根据用户给定的主题生成一份结构清晰、情节连贯的小说大纲。 你必须严格只输出一个 JSON 对象不要输出任何解释、前后缀文字或 markdown 代码块标记不要写 json。 JSON 结构如下 { title: 小说标题, theme: 用户给定的主题, summary: 全书梗概100~200 字交代背景、主线与结局走向, chapters: [ { index: 1, title: 第X章 章节标题, outline: 本章核心事件、出场人物、情节要点3~5 句话, clues: [可选本章埋设或呼应的线索] } ] } 要求 - 章节数量严格等于用户指定数量 - 章节之间情节递进、有因果不能各自孤立 - 每章 outline 要具体到可据此扩写正文不要空泛 def outline_user(theme: str, chapter_count: int) - str: return ( f主题{theme}\n f章节数量{chapter_count}\n\n f请据此生成大纲 JSON。只输出 JSON 本身。 )写作阶段的系统提示词重点转向文笔和连贯性。这里要告诉模型遵循大纲但不要照抄要丰富细节要和全书设定、前情保持一致只输出正文不要复述大纲。字数要求也写进去我设的是不少于 1500 字你可以按需调整。CHAPTER_SYSTEM 你是一位文笔老练的小说家。你的任务是根据给定的大纲章节信息扩写出该章的完整正文。 要求 - 遵循本章大纲的情节要点但不要照抄要丰富细节、对话、场景描写 - 与全书设定、人物性格、前情保持一致不要出现前后矛盾 - 文风统一语言生动 - 只输出小说正文可使用 Markdown 段落不要输出 JSON不要解释不要复述大纲 - 正文字数不少于 1500 字 def chapter_user( book_title: str, book_summary: str, chapter_title: str, chapter_outline: str, chapter_clues: list[str], prev_ending: str , ) - str: clues_text .join(chapter_clues) if chapter_clues else 无 parts [ f【全书标题】{book_title}, f【全书梗概】{book_summary}, f【本章标题】{chapter_title}, f【本章大纲】{chapter_outline}, f【本章线索】{clues_text}, ] if prev_ending: parts.append(f【上一章结尾】……{prev_ending}\n请衔接上一章结尾保持连贯) parts.append(\n请扩写本章正文。) return \n.join(parts)注意 chapter_user 里有个 prev_ending 参数用来把上一章的结尾片段传给模型让它衔接。这是保证长篇连贯性的一个小技巧。首章没有上一章传空字符串就行。Prompt 准备好了接下来是 LLM 客户端。这是全项目唯一和模型打交道的地方其他代码都通过它调模型。它要提供两种调用方式普通对话返回文本要 JSON 的对话返回解析好的字典。后者有个现实问题模型经常把 JSON 包在代码块里或夹带废话所以拿回来要先清洗再解析如果还是失败就把错误回喂给模型让它自己改一次。先定义异常层次区分「调用本身失败」和「JSON 解析失败」这样上层代码能针对性地处理。class LLMError(Exception): 所有 LLM 相关异常的基类。 class LLMConnectionError(LLMError): 调用本身失败网络错误、超时、限流、服务端 5xx 等。 class LLMJSONError(LLMError): LLM 返回了文本但 JSON 解析失败。 def __init__(self, message: str, raw_text: str, parse_error: str): super().__init__(message) self.raw_text raw_text self.parse_error parse_error然后是客户端实例的延迟导入。为什么要延迟导入因为这样即使没装 openai纯逻辑部分比如 JSON 清洗也能单独测试不会因为 import 失败而整个模块挂掉。_client None def _get_client(): global _client if _client is None: from openai import OpenAI _client OpenAI(api_keyconfig.api_key, base_urlconfig.base_url) return _client核心的调用函数带指数退避重试。网络抖动、限流这些情况很常见一失败就崩体验很差。重试策略是 1 秒、2 秒、4 秒这样退避最多重试 config.max_retries 次。判断哪些异常值得重试也有讲究超时和限流值得重试5xx 服务端错误值得重试4xx 客户端错误比如 Key 错了重试也没用直接抛。def _should_retry(exc: Exception) - bool: try: from openai import APIError, APITimeoutError, RateLimitError except ImportError: return False if isinstance(exc, (APITimeoutError, RateLimitError)): return True if isinstance(exc, APIError): status getattr(exc, status_code, 0) or 0 return 500 status 600 return False def _chat_messages(messages: list[dict], temperature: float | None) - str: client _get_client() max_attempts config.max_retries 1 last_exc None for attempt in range(1, max_attempts 1): try: resp client.chat.completions.create( modelconfig.model, messagesmessages, temperaturetemperature, max_tokensconfig.max_tokens, ) return resp.choices[0].message.content or except Exception as e: last_exc e if _should_retry(e) and attempt max_attempts: wait 2 ** (attempt - 1) time.sleep(wait) continue raise LLMConnectionError( fLLM 调用失败尝试 {attempt} 次后放弃: {e} ) from e raise LLMConnectionError( fLLM 调用失败尝试 {max_attempts} 次后放弃: {last_exc} )JSON 清洗函数负责把模型返回的文本里真正的 JSON 抠出来。策略是先去 markdown 代码块标记再找第一个 { 和最后一个 } 之间的内容。这个策略覆盖了绝大多数情况。def _clean_json(raw: str) - str: text re.sub(r(?:json)?\s*, , raw).strip() start text.find({) end text.rfind(}) if start ! -1 and end ! -1 and end start: return text[start : end 1] return textchat_json 是重点。它先调一次解析失败就把错误和原始输出回喂给模型让它自己修正一次。第二次还失败才抛 LLMJSONError。这个自我修正机制在实际使用中能救回不少格式问题。def chat_json(prompt: str, system: str | None None, temperature: float | None None) - dict: messages [] if system is not None: messages.append({role: system, content: system}) messages.append({role: user, content: prompt}) raw _chat_messages(messages, temperature) cleaned _clean_json(raw) try: return json.loads(cleaned) except json.JSONDecodeError as e: first_error str(e) fix_prompt ( 你上次返回的内容不是合法的 JSON。\n f解析错误{first_error}\n\n f你上次返回的原始内容\n{raw}\n\n 请只输出一个合法的 JSON 对象不要包含任何解释、前后缀文字或 markdown 代码块标记。 ) fixed_messages messages [ {role: assistant, content: raw}, {role: user, content: fix_prompt}, ] raw2 _chat_messages(fixed_messages, temperature) cleaned2 _clean_json(raw2) try: return json.loads(cleaned2) except json.JSONDecodeError as e2: raise LLMJSONError( JSON 解析失败自我修正后仍失败, raw_textraw2, parse_errorstr(e2), ) from e2到这里配置、Prompt、客户端三块都齐了。这套代码的优点是换模型只改 .env调温度只改 .env业务逻辑完全不用动。而且异常分得清楚出问题能快速定位是网络问题还是格式问题。4. 验证请求跑通从设定到章节草稿的最小闭环代码写完了得验证它真能跑。这一节我带你把整个闭环跑一遍从主题输入到章节草稿落盘。先确认目录结构应该是这样的Novel/ ├── .env ├── pyproject.toml ├── src/ │ ├── __init__.py │ ├── config.py │ ├── prompt.py │ ├── llm_client.py │ └── schema.pyschema.py 里用 pydantic 定义数据结构。一本小说有标题、主题、全书概括、章节列表每个章节有顺序、标题、情节要点、线索、正文。正文默认空字符串写作阶段再填。from pydantic import BaseModel, Field class Chapter(BaseModel): index: int title: str outline: str clues: list[str] Field(default_factorylist) content: str class Novel(BaseModel): title: str theme: str summary: str chapters: list[Chapter] Field(default_factorylist)现在写一个验证脚本跑一次完整流程。先调大纲再逐章扩写。为了快速验证章节数设成 3正文长度要求可以临时调低。from src import config, prompt from src.llm_client import chat_json, chat from src.schema import Novel, Chapter def generate_outline(theme: str, chapter_count: int) - Novel: data chat_json( promptprompt.outline_user(theme, chapter_count), systemprompt.OUTLINE_SYSTEM, temperatureconfig.outline_temperature, ) return Novel(**data) def write_chapter(novel: Novel, chapter: Chapter, prev_ending: str ) - str: return chat( promptprompt.chapter_user( book_titlenovel.title, book_summarynovel.summary, chapter_titlechapter.title, chapter_outlinechapter.outline, chapter_clueschapter.clues, prev_endingprev_ending, ), systemprompt.CHAPTER_SYSTEM, temperatureconfig.chapter_temperature, ) if __name__ __main__: novel generate_outline(一个关于时间循环的悬疑故事, 3) print(f标题{novel.title}) print(f梗概{novel.summary}) for ch in novel.chapters: print(f {ch.index}. {ch.title} - {ch.outline[:40]}...) prev for ch in novel.chapters: ch.content write_chapter(novel, ch, prev) prev ch.content[-200:] print(f第 {ch.index} 章写完{len(ch.content)} 字)运行这个脚本你会看到类似这样的输出先打印出标题、梗概和章节列表然后逐章打印写完的字数。如果一切正常大纲的 JSON 被正确解析成了 Novel 对象每章正文也生成了。这就是从设定到章节草稿的最小闭环。验证的时候有几个点要留意。第一大纲返回的 JSON 里 chapters 的字段名要和 schema 对上如果模型返回了额外的字段pydantic 默认会忽略但如果缺了必填字段就会报错。第二正文生成时如果模型返回了空字符串可能是 max_tokens 设太小被截断了或者触发了内容过滤。第三如果中途报 LLMJSONError把 raw_text 打出来看看模型到底返回了什么多半是格式问题调整 Prompt 里的约束能解决。跑通之后你可以把生成结果存成文件方便查看和后续处理。比如把每章正文写进单独的 markdown 文件或者把整个 Novel 对象序列化成 JSON 存档。这些扩展都很简单因为数据结构是清晰的。实测下来这套流程在 TaoToken 统一通道上跑得很稳。换模型只需要改 .env 里的 MODEL 字段比如从 deepseek-v4-flash 换成别的写作模型代码一行不用动。这种灵活性对于需要反复试不同模型、调不同参数的创作类项目来说价值很大。5. 本篇常见错排查401、local proxy failed、reading choices 怎么解接入和调试过程中有几类报错特别常见。我把它们整理出来对照着排查能省不少时间。这些报错大多不是代码逻辑问题而是配置或环境问题。第一类是 401 错误提示 authentication failed 或 invalid api key。这几乎总是 Key 的问题。检查三处.env 里的 API_KEY 是不是复制完整了有没有多余的空格或换行这个 Key 在 TaoToken 控制台是不是还有效有没有被删除或过期代码里加载 .env 的路径对不对如果脚本不在项目根目录运行load_dotenv 可能找不到文件。一个快速验证方法是把 Key 打印出来看前几位和后几位确认没被截断。第二类是 local proxy failed 或 connection error。这类报错通常和网络环境有关。先确认 BASE_URL 填的是 https://taotoken.net/api注意是 https 不是 http末尾不要多加斜杠。然后检查本机有没有设置一些奇怪的全局代理有时候系统代理会干扰 SDK 的正常请求。如果你在公司网络里防火墙可能拦了外部请求换个网络环境试试。还有一种情况是 DNS 解析问题可以 ping 一下域名看能不能通。第三类是 reading choices 相关的报错比如 NoneType object has no attribute choices 或者 list index out of range。这说明 resp.choices 是空的或者 None。可能的原因有几个模型返回了内容但被内容过滤拦截了导致 choices 为空max_tokens 设得太小模型还没输出有效内容就结束了请求参数有问题比如 temperature 超出了模型支持的范围。排查方法是把完整的 resp 对象打出来看或者临时把 max_tokens 调大、temperature 调回默认值再试。第四类是 JSON 解析失败抛 LLMJSONError。这个前面讲过模型返回的文本不是合法 JSON。先看 raw_text如果里面夹带了「好的以下是」之类的话说明 Prompt 约束不够强在系统提示词里再强调一遍「只输出 JSON」。如果 JSON 本身格式有问题比如少了逗号、多了尾逗号chat_json 的自我修正机制会尝试救一次救不回来才抛错。如果频繁出现可以考虑换一个指令遵循能力更强的模型来跑大纲阶段。第五类是 OAuth 或权限相关报错。如果你用的是某些需要额外授权的服务可能会遇到 token 过期或 scope 不足的问题。对于 TaoToken 这种用 API Key 的方式一般不会遇到 OAuth 问题但如果你在代码里混用了其他认证方式要确认没有冲突。检查一下有没有环境变量里残留了其他服务的 Key导致 SDK 拿错了凭证。第六类是模型名错误提示 model not found。检查 .env 里的 MODEL 字段拼写大小写要和服务端一致。不同模型的命名规则不一样有的带版本号有的不带最好从 TaoToken 的文档里复制准确的模型 ID。如果换了模型但忘了改配置也会报这个错。排查这类问题的通用思路是先看报错信息里的关键词定位是认证、网络、参数还是格式问题再把关键变量base_url、model、key 前几位打印出来确认最后用最小化的请求单独测试排除业务代码的干扰。大部分问题都能在这三步里找到答案。6. 把通道固定下来让创作逻辑自由生长跑通这个最小闭环之后你会发现真正花时间的不是调用模型而是调 Prompt 和试参数。这时候一个稳定的接入通道就特别重要它让你能把精力集中在创作逻辑上而不是反复折腾配置。我现在的做法是所有模型调用都走 TaoToken 这一条通道Key 和地址固定在 .env 里业务代码只依赖 config 模块暴露的变量。这样无论后面是加大纲润色、人物设定管理还是接一个前端界面底层都不用动。想试新模型改一个字符串就行想调温度改一个数字就行。如果你也想快速验证自己的 AI 写作想法建议就从这套骨架开始。先把大纲和单章扩写跑通再逐步加功能。下一步可以做的方向很多给章节加人物一致性检查、把生成结果做成可编辑的草稿、加一个简单的 Web 界面让非开发者也能用。这些都是在稳定通道之上生长出来的东西。需要 Key 和接入文档的话可以从 API Keys 页面创建接入细节看接入文档。想先感受一下模型对话效果可以直接在模型对话里试。如果打算长期做编码和 Agent 相关的开发Coding Plan 值得了解一下。通道固定下来剩下的就是让创作逻辑自由生长了。
