1. 从大纲到 PDFManus 自动写小说这条链路到底卡在哪Manus 自动完成小说编写并生成最终 PDF 文档这件事听起来像是一个“全自动内容工厂”但真正动手跑一遍你会发现卡点从来不在“让模型写几段文字”而在三个地方任务拆解是否够细、章节之间是否语义连贯、以及最终 PDF 的中文字体与排版是否可控。这篇就围绕 Manus 演示案例把从大纲到成稿再到 PDF 输出的完整链路拆开给出可复制的任务配置、提示词模板和 PDF 生成参数并做一次端到端验证。先说清楚这套流程适合谁。如果你是需要批量产出结构化长文的内容创作者比如连载小说、技术传记、课程讲义或者你是喜欢把重复写作流程自动化的爱好者想用 Manus 这类 Agent 工具把“调研—大纲—分章—整合—导出”串成一条流水线那这套拆解可以直接拿去改。它不依赖某个特定模型核心是把长文任务切成 Agent 能稳定执行的小块再用一个确定性的 PDF 渲染步骤收尾。我试过把 5000 字左右的小说一次性丢给模型结果经常是前两章丰满、后三章开始复读章节标题还会漂移。后来改成“先锁大纲、再逐章生成、最后统一渲染”稳定性明显提升。下面按这个思路展开每一步都给到能直接复制的配置和命令。需要说明的是Manus 负责的是任务编排与内容生成而模型调用、密钥管理这些底层能力我用 TaoToken 来做统一接入这样切换模型、管理额度、排查报错都在一个地方不用在多个平台之间来回跳。后面的配置片段会体现这一点。2. TaoToken 前置准备给 Manus 接上稳定的模型调用在讲具体配置之前先把“模型从哪来”这件事解决掉。Manus 本身是任务编排层它需要调用大模型来完成调研、写大纲、逐章生成这些动作。如果你直接用各家模型的原始接口会遇到几个麻烦密钥分散、额度不透明、换模型要改代码、报错信息看不懂。TaoToken 在这里的角色就是一个统一的模型接入层官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。你需要准备的东西其实就三样一个可用的 API Key、一个 Base URL、一个明确的 Model ID。这三件套是后面所有配置的基础缺一个都会在验证阶段报错。获取 Key 的路径是登录后进入控制台在 API Keys 页面创建地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。创建时建议按用途命名比如manus-novel方便后面排查是哪个任务在消耗额度。Base URL 统一用https://taotoken.net/api注意这个地址后面不加 UTM 参数直接写就行。Model ID 则根据你实际要用的模型填比如做长文写作时选一个上下文窗口大、中文表达稳的模型。如果你不确定选哪个可以先去模型对话页面手动试几轮地址是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 用同一段提示词对比不同模型的输出风格选定后再写进配置。这里有个容易踩的坑很多人把 Base URL 写成带/v1或者带具体路径的形式结果请求 404。正确做法是只写到https://taotoken.net/api具体的路径由 SDK 或工具自己拼接。另外Key 不要硬编码在会提交到 Git 的文件里用环境变量或者本地配置文件后面配置片段会演示。如果你后面要做的是长期编码类或 Agent 类任务比如让 Manus 反复迭代同一部小说、持续跑多轮可以考虑 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 它在长周期、高频调用场景下更省心。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 遇到参数不确定时先查这里。准备好这三件套之后就可以进入 Manus 的任务拆解环节了。记住一个原则模型调用层要稳定、可观测这样当小说生成到第五章突然报错时你能快速判断是模型侧的问题还是任务编排侧的问题。3. 可复制配置Manus 任务拆解 提示词模板 PDF 参数这一节是整篇的核心给到能直接复制的配置。整体思路是把“写一部 5000 字小说并导出 PDF”拆成五个可独立执行的任务节点每个节点有明确的输入输出Manus 按顺序调度。先看任务拆解的 JSON 配置。这个结构可以直接作为 Manus 的任务定义文件路径建议放在项目根目录的manus/tasks/novel.json{ task_name: novel_to_pdf, model_config: { base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY, model_id: your-model-id, temperature: 0.7, max_tokens: 4096 }, steps: [ { id: outline, prompt_template: prompts/outline.md, output: workspace/outline.md }, { id: chapter, prompt_template: prompts/chapter.md, input: workspace/outline.md, output_dir: workspace/chapters, loop_over: chapters }, { id: merge, prompt_template: prompts/merge.md, input_dir: workspace/chapters, output: workspace/final.md }, { id: review, prompt_template: prompts/review.md, input: workspace/final.md, output: workspace/final_reviewed.md }, { id: render_pdf, type: script, script: scripts/render_pdf.py, input: workspace/final_reviewed.md, output: workspace/novel.pdf } ] }注意api_key_env指向环境变量而不是把 Key 写死在文件里。运行前在终端执行export TAOTOKEN_API_KEY你的Key即可。model_id填你在 TaoToken 控制台确认过的模型标识。接下来是提示词模板。大纲模板prompts/outline.md的关键是强制模型输出结构化章节列表避免它自由发挥你是一位长篇小说策划。请根据以下主题生成一份五章大纲。 主题{{topic}} 目标字数{{word_count}} 要求 1. 每章给出标题、核心事件、预计字数。 2. 章节之间要有时间线或逻辑递进。 3. 只输出 Markdown 表格不要额外解释。 输出格式 | 章节 | 标题 | 核心事件 | 预计字数 |逐章生成模板prompts/chapter.md则要带上前后章摘要保证连贯你正在写一部小说的第 {{chapter_index}} 章。 全书大纲 {{outline}} 前一章摘要 {{prev_summary}} 本章标题{{chapter_title}} 本章核心事件{{chapter_event}} 目标字数{{chapter_word_count}} 要求 1. 只写本章正文不要重复标题。 2. 结尾留一个自然的过渡钩子。 3. 中文表达避免翻译腔。合并与审查模板相对简单重点是让模型检查字数缺口和章节标题一致性。审查模板里加一句“如果总字数低于目标 10%指出哪些章节需要扩写”能有效避免前面提到的“字数远低于预期”问题。最后是 PDF 渲染脚本scripts/render_pdf.py。这一步是确定性的不依赖模型用 Python 的 markdown 和 weasyprint 组合即可import markdown from weasyprint import HTML, CSS def render(md_path, pdf_path): with open(md_path, encodingutf-8) as f: text f.read() html markdown.markdown(text, extensions[tables, fenced_code]) css CSS(string page { size: A4; margin: 2cm; } body { font-family: Noto Sans CJK SC, sans-serif; font-size: 12pt; line-height: 1.8; } h1, h2, h3 { font-family: Noto Sans CJK SC, sans-serif; } table { border-collapse: collapse; } td, th { border: 1px solid #ccc; padding: 4px 8px; } ) HTML(stringhtml).write_pdf(pdf_path, stylesheets[css]) if __name__ __main__: render(workspace/final_reviewed.md, workspace/novel.pdf)中文字体是关键。如果服务器上没有Noto Sans CJK SC先安装apt-get install fonts-noto-cjk。字体名要和 CSS 里写的一致否则 PDF 里中文会变成方块。行高设 1.8、字号 12pt 是实测下来阅读体验比较舒服的组合打印和屏幕阅读都合适。这套配置跑起来后Manus 会按 outline → chapter → merge → review → render_pdf 的顺序执行。每一步的产物都落在workspace/下方便中途检查。如果某一步失败你可以只重跑那一步不用从头再来。4. 验证请求确认章节结构与 PDF 排版正确配置写完之后不要直接跑完整流程先做一次最小验证。验证分两层先确认模型调用通再确认 PDF 渲染对。第一层用 curl 直接打一次 TaoToken 的接口确认 Key 和 Base URL 没问题curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: your-model-id, messages: [{role: user, content: 用一句话说明什么是虚拟化技术}], max_tokens: 100 }如果返回里有choices字段和正常的中文内容说明模型侧通了。如果返回 401说明 Key 不对或没带上如果返回local proxy failed之类的错误通常是 Base URL 写错或者网络层有问题检查是不是多写了路径。第二层单独跑 PDF 渲染脚本用一段测试 Markdown 验证中文字体和表格python scripts/render_pdf.py打开生成的workspace/novel.pdf重点看三处中文是否正常显示不是方块、章节标题层级是否正确、表格边框是否完整。如果中文是方块九成是字体没装或字体名不匹配如果标题层级乱检查 Markdown 里是不是用了#一级标题PDF 渲染时建议从##开始。两层都通过后再跑完整的 Manus 任务。跑完后做一次端到端检查我一般会看这几个点总字数是否接近目标用wc -m workspace/final_reviewed.md统计、章节数是否等于大纲里的数量、每章标题是否和大纲一致、PDF 页数是否合理。实测下来5000 字中文小说渲染成 A4、12pt、行高 1.8大概在 8 到 10 页之间如果只有两三页多半是内容被截断了。还有一个验证技巧在审查步骤后加一个字数校验脚本低于目标 90% 就自动触发扩写。这样不用人工盯着Manus 自己就能把字数补齐。校验逻辑很简单读final_reviewed.md统计字符数和配置里的word_count对比不达标就把缺口最大的章节重新生成一次。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth跑这条链路时报错基本集中在四类。下面按真实报错信息对照排查。第一类401 Unauthorized。这个最直接就是 Key 的问题。检查三处环境变量TAOTOKEN_API_KEY是否真的 export 了用echo $TAOTOKEN_API_KEY确认、Key 是否复制完整没有多余空格、请求头里是不是写成了Bearer加空格加 Key。如果 Key 是在控制台刚创建的确认一下有没有被禁用或额度耗尽。第二类local proxy failed。这个报错通常出现在 Base URL 配置错误时。常见原因是把地址写成了https://taotoken.net/api/v1或者带了多余路径。正确写法就是https://taotoken.net/api让 SDK 自己拼/v1/chat/completions。另外检查一下本地有没有设置全局代理环境变量如果有可能会干扰请求临时 unset 掉再试。第三类reading choices相关报错。这个一般出现在解析模型返回时说明返回结构和你代码里取值的路径不一致。比如你按response.choices[0].message.content取但实际返回里choices是空的或者结构不同。排查方法是先把原始返回打印出来确认choices数组存在且有内容。如果choices为空往往是请求被截断或模型侧返回了错误信息这时候看返回里的error字段。第四类OAuth 相关报错。如果你用的是 Claude Code 这类工具接入可能会遇到 OAuth 认证流程的问题。这类工具接入时Base URL、Key、Model ID 三件套要写全缺一个都会在认证阶段失败。Claude Code 的接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 里面有完整的配置示例。如果你用的是 CC Switch 或 Cline MCP同样要确认这三件套都填了尤其是 Model ID 不能留空。除了这四类还有一个非报错但很烦的问题PDF 里中文变方块。这不是接口问题是字体问题。确认服务器装了fonts-noto-cjk并且 CSS 里的font-family和系统里fc-list | grep Noto输出的字体名一致。有时候字体名是Noto Sans CJK SC有时候是Noto Sans CJK SC Regular以fc-list的实际输出为准。排查时养成一个习惯每一步的中间产物都保留outline.md、chapters/、final.md都别删。这样报错时能快速定位是生成阶段的问题还是渲染阶段的问题不用从头重跑。6. 把这条链路用起来从演示到日常内容生产跑通一次演示只是开始真正有价值的是把这条链路变成日常可复用的内容生产流程。我的做法是把manus/tasks/novel.json做成模板每次换主题只改topic和word_count两个参数其余配置不动。这样从选题到拿到 PDF中间只需要人工做一次大纲确认剩下的交给 Manus 自动跑。如果你要批量产出可以把任务配置里的loop_over扩展成多主题循环一次提交多个选题Manus 会依次生成各自的 PDF。这时候模型调用量会上去用 Coding Plan 会比按次调用更划算地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。额度管理在控制台看地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 能清楚看到每个 Key 的消耗。还有一个实用技巧把审查步骤的提示词固定成“检查章节标题一致性、字数缺口、重复段落”三项每次生成后自动输出一份检查报告。这样你不用通读全文看报告就知道哪里需要人工介入。实测下来这套流程能把 5000 字小说的产出时间压缩到一次任务调度的时间人工只需要在大纲和最终审查两个节点做判断。最后提醒一点PDF 渲染脚本里的字体和行高参数建议按你的实际阅读场景调一次就固定下来。A4、12pt、行高 1.8 适合屏幕和打印兼顾如果你主要做电子分发可以改成 11pt、行高 1.6页数会更紧凑。调好之后写进 CSS后面所有任务复用同一套排版输出风格就统一了。
Manus 演示案例：自动完成小说编写并生成最终 PDF 文档
1. 从大纲到 PDFManus 自动写小说这条链路到底卡在哪Manus 自动完成小说编写并生成最终 PDF 文档这件事听起来像是一个“全自动内容工厂”但真正动手跑一遍你会发现卡点从来不在“让模型写几段文字”而在三个地方任务拆解是否够细、章节之间是否语义连贯、以及最终 PDF 的中文字体与排版是否可控。这篇就围绕 Manus 演示案例把从大纲到成稿再到 PDF 输出的完整链路拆开给出可复制的任务配置、提示词模板和 PDF 生成参数并做一次端到端验证。先说清楚这套流程适合谁。如果你是需要批量产出结构化长文的内容创作者比如连载小说、技术传记、课程讲义或者你是喜欢把重复写作流程自动化的爱好者想用 Manus 这类 Agent 工具把“调研—大纲—分章—整合—导出”串成一条流水线那这套拆解可以直接拿去改。它不依赖某个特定模型核心是把长文任务切成 Agent 能稳定执行的小块再用一个确定性的 PDF 渲染步骤收尾。我试过把 5000 字左右的小说一次性丢给模型结果经常是前两章丰满、后三章开始复读章节标题还会漂移。后来改成“先锁大纲、再逐章生成、最后统一渲染”稳定性明显提升。下面按这个思路展开每一步都给到能直接复制的配置和命令。需要说明的是Manus 负责的是任务编排与内容生成而模型调用、密钥管理这些底层能力我用 TaoToken 来做统一接入这样切换模型、管理额度、排查报错都在一个地方不用在多个平台之间来回跳。后面的配置片段会体现这一点。2. TaoToken 前置准备给 Manus 接上稳定的模型调用在讲具体配置之前先把“模型从哪来”这件事解决掉。Manus 本身是任务编排层它需要调用大模型来完成调研、写大纲、逐章生成这些动作。如果你直接用各家模型的原始接口会遇到几个麻烦密钥分散、额度不透明、换模型要改代码、报错信息看不懂。TaoToken 在这里的角色就是一个统一的模型接入层官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。你需要准备的东西其实就三样一个可用的 API Key、一个 Base URL、一个明确的 Model ID。这三件套是后面所有配置的基础缺一个都会在验证阶段报错。获取 Key 的路径是登录后进入控制台在 API Keys 页面创建地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。创建时建议按用途命名比如manus-novel方便后面排查是哪个任务在消耗额度。Base URL 统一用https://taotoken.net/api注意这个地址后面不加 UTM 参数直接写就行。Model ID 则根据你实际要用的模型填比如做长文写作时选一个上下文窗口大、中文表达稳的模型。如果你不确定选哪个可以先去模型对话页面手动试几轮地址是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 用同一段提示词对比不同模型的输出风格选定后再写进配置。这里有个容易踩的坑很多人把 Base URL 写成带/v1或者带具体路径的形式结果请求 404。正确做法是只写到https://taotoken.net/api具体的路径由 SDK 或工具自己拼接。另外Key 不要硬编码在会提交到 Git 的文件里用环境变量或者本地配置文件后面配置片段会演示。如果你后面要做的是长期编码类或 Agent 类任务比如让 Manus 反复迭代同一部小说、持续跑多轮可以考虑 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 它在长周期、高频调用场景下更省心。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 遇到参数不确定时先查这里。准备好这三件套之后就可以进入 Manus 的任务拆解环节了。记住一个原则模型调用层要稳定、可观测这样当小说生成到第五章突然报错时你能快速判断是模型侧的问题还是任务编排侧的问题。3. 可复制配置Manus 任务拆解 提示词模板 PDF 参数这一节是整篇的核心给到能直接复制的配置。整体思路是把“写一部 5000 字小说并导出 PDF”拆成五个可独立执行的任务节点每个节点有明确的输入输出Manus 按顺序调度。先看任务拆解的 JSON 配置。这个结构可以直接作为 Manus 的任务定义文件路径建议放在项目根目录的manus/tasks/novel.json{ task_name: novel_to_pdf, model_config: { base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY, model_id: your-model-id, temperature: 0.7, max_tokens: 4096 }, steps: [ { id: outline, prompt_template: prompts/outline.md, output: workspace/outline.md }, { id: chapter, prompt_template: prompts/chapter.md, input: workspace/outline.md, output_dir: workspace/chapters, loop_over: chapters }, { id: merge, prompt_template: prompts/merge.md, input_dir: workspace/chapters, output: workspace/final.md }, { id: review, prompt_template: prompts/review.md, input: workspace/final.md, output: workspace/final_reviewed.md }, { id: render_pdf, type: script, script: scripts/render_pdf.py, input: workspace/final_reviewed.md, output: workspace/novel.pdf } ] }注意api_key_env指向环境变量而不是把 Key 写死在文件里。运行前在终端执行export TAOTOKEN_API_KEY你的Key即可。model_id填你在 TaoToken 控制台确认过的模型标识。接下来是提示词模板。大纲模板prompts/outline.md的关键是强制模型输出结构化章节列表避免它自由发挥你是一位长篇小说策划。请根据以下主题生成一份五章大纲。 主题{{topic}} 目标字数{{word_count}} 要求 1. 每章给出标题、核心事件、预计字数。 2. 章节之间要有时间线或逻辑递进。 3. 只输出 Markdown 表格不要额外解释。 输出格式 | 章节 | 标题 | 核心事件 | 预计字数 |逐章生成模板prompts/chapter.md则要带上前后章摘要保证连贯你正在写一部小说的第 {{chapter_index}} 章。 全书大纲 {{outline}} 前一章摘要 {{prev_summary}} 本章标题{{chapter_title}} 本章核心事件{{chapter_event}} 目标字数{{chapter_word_count}} 要求 1. 只写本章正文不要重复标题。 2. 结尾留一个自然的过渡钩子。 3. 中文表达避免翻译腔。合并与审查模板相对简单重点是让模型检查字数缺口和章节标题一致性。审查模板里加一句“如果总字数低于目标 10%指出哪些章节需要扩写”能有效避免前面提到的“字数远低于预期”问题。最后是 PDF 渲染脚本scripts/render_pdf.py。这一步是确定性的不依赖模型用 Python 的 markdown 和 weasyprint 组合即可import markdown from weasyprint import HTML, CSS def render(md_path, pdf_path): with open(md_path, encodingutf-8) as f: text f.read() html markdown.markdown(text, extensions[tables, fenced_code]) css CSS(string page { size: A4; margin: 2cm; } body { font-family: Noto Sans CJK SC, sans-serif; font-size: 12pt; line-height: 1.8; } h1, h2, h3 { font-family: Noto Sans CJK SC, sans-serif; } table { border-collapse: collapse; } td, th { border: 1px solid #ccc; padding: 4px 8px; } ) HTML(stringhtml).write_pdf(pdf_path, stylesheets[css]) if __name__ __main__: render(workspace/final_reviewed.md, workspace/novel.pdf)中文字体是关键。如果服务器上没有Noto Sans CJK SC先安装apt-get install fonts-noto-cjk。字体名要和 CSS 里写的一致否则 PDF 里中文会变成方块。行高设 1.8、字号 12pt 是实测下来阅读体验比较舒服的组合打印和屏幕阅读都合适。这套配置跑起来后Manus 会按 outline → chapter → merge → review → render_pdf 的顺序执行。每一步的产物都落在workspace/下方便中途检查。如果某一步失败你可以只重跑那一步不用从头再来。4. 验证请求确认章节结构与 PDF 排版正确配置写完之后不要直接跑完整流程先做一次最小验证。验证分两层先确认模型调用通再确认 PDF 渲染对。第一层用 curl 直接打一次 TaoToken 的接口确认 Key 和 Base URL 没问题curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: your-model-id, messages: [{role: user, content: 用一句话说明什么是虚拟化技术}], max_tokens: 100 }如果返回里有choices字段和正常的中文内容说明模型侧通了。如果返回 401说明 Key 不对或没带上如果返回local proxy failed之类的错误通常是 Base URL 写错或者网络层有问题检查是不是多写了路径。第二层单独跑 PDF 渲染脚本用一段测试 Markdown 验证中文字体和表格python scripts/render_pdf.py打开生成的workspace/novel.pdf重点看三处中文是否正常显示不是方块、章节标题层级是否正确、表格边框是否完整。如果中文是方块九成是字体没装或字体名不匹配如果标题层级乱检查 Markdown 里是不是用了#一级标题PDF 渲染时建议从##开始。两层都通过后再跑完整的 Manus 任务。跑完后做一次端到端检查我一般会看这几个点总字数是否接近目标用wc -m workspace/final_reviewed.md统计、章节数是否等于大纲里的数量、每章标题是否和大纲一致、PDF 页数是否合理。实测下来5000 字中文小说渲染成 A4、12pt、行高 1.8大概在 8 到 10 页之间如果只有两三页多半是内容被截断了。还有一个验证技巧在审查步骤后加一个字数校验脚本低于目标 90% 就自动触发扩写。这样不用人工盯着Manus 自己就能把字数补齐。校验逻辑很简单读final_reviewed.md统计字符数和配置里的word_count对比不达标就把缺口最大的章节重新生成一次。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth跑这条链路时报错基本集中在四类。下面按真实报错信息对照排查。第一类401 Unauthorized。这个最直接就是 Key 的问题。检查三处环境变量TAOTOKEN_API_KEY是否真的 export 了用echo $TAOTOKEN_API_KEY确认、Key 是否复制完整没有多余空格、请求头里是不是写成了Bearer加空格加 Key。如果 Key 是在控制台刚创建的确认一下有没有被禁用或额度耗尽。第二类local proxy failed。这个报错通常出现在 Base URL 配置错误时。常见原因是把地址写成了https://taotoken.net/api/v1或者带了多余路径。正确写法就是https://taotoken.net/api让 SDK 自己拼/v1/chat/completions。另外检查一下本地有没有设置全局代理环境变量如果有可能会干扰请求临时 unset 掉再试。第三类reading choices相关报错。这个一般出现在解析模型返回时说明返回结构和你代码里取值的路径不一致。比如你按response.choices[0].message.content取但实际返回里choices是空的或者结构不同。排查方法是先把原始返回打印出来确认choices数组存在且有内容。如果choices为空往往是请求被截断或模型侧返回了错误信息这时候看返回里的error字段。第四类OAuth 相关报错。如果你用的是 Claude Code 这类工具接入可能会遇到 OAuth 认证流程的问题。这类工具接入时Base URL、Key、Model ID 三件套要写全缺一个都会在认证阶段失败。Claude Code 的接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 里面有完整的配置示例。如果你用的是 CC Switch 或 Cline MCP同样要确认这三件套都填了尤其是 Model ID 不能留空。除了这四类还有一个非报错但很烦的问题PDF 里中文变方块。这不是接口问题是字体问题。确认服务器装了fonts-noto-cjk并且 CSS 里的font-family和系统里fc-list | grep Noto输出的字体名一致。有时候字体名是Noto Sans CJK SC有时候是Noto Sans CJK SC Regular以fc-list的实际输出为准。排查时养成一个习惯每一步的中间产物都保留outline.md、chapters/、final.md都别删。这样报错时能快速定位是生成阶段的问题还是渲染阶段的问题不用从头重跑。6. 把这条链路用起来从演示到日常内容生产跑通一次演示只是开始真正有价值的是把这条链路变成日常可复用的内容生产流程。我的做法是把manus/tasks/novel.json做成模板每次换主题只改topic和word_count两个参数其余配置不动。这样从选题到拿到 PDF中间只需要人工做一次大纲确认剩下的交给 Manus 自动跑。如果你要批量产出可以把任务配置里的loop_over扩展成多主题循环一次提交多个选题Manus 会依次生成各自的 PDF。这时候模型调用量会上去用 Coding Plan 会比按次调用更划算地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。额度管理在控制台看地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 能清楚看到每个 Key 的消耗。还有一个实用技巧把审查步骤的提示词固定成“检查章节标题一致性、字数缺口、重复段落”三项每次生成后自动输出一份检查报告。这样你不用通读全文看报告就知道哪里需要人工介入。实测下来这套流程能把 5000 字小说的产出时间压缩到一次任务调度的时间人工只需要在大纲和最终审查两个节点做判断。最后提醒一点PDF 渲染脚本里的字体和行高参数建议按你的实际阅读场景调一次就固定下来。A4、12pt、行高 1.8 适合屏幕和打印兼顾如果你主要做电子分发可以改成 11pt、行高 1.6页数会更紧凑。调好之后写进 CSS后面所有任务复用同一套排版输出风格就统一了。
， ‘gbk‘ codec can‘t decode byte 0xa3)
