企业官网建设流程全解析

1. 为什么我选择在 VS Code 里用 kilo-code 写小说

先说清楚这套方案到底在干什么：它把 VS Code 当成一个长文本生产车间，kilo-code 是车间里的 AI Agent，deepseek 是负责出字的模型，AGENTS.md 是贴在墙上的写作规范，TaoToken 则是统一给这些模型调用发钥匙和记账的通道。适合谁？适合已经习惯在编辑器里干活、想用工程化方式写长篇内容的人，尤其是程序员背景的写作者。

我一开始的想法很朴素：既然写代码可以拆模块、定接口、跑测试，那写小说为什么不能拆章节、定人设、做校验？于是我把一部四十章、每章目标五千字的重生网文拆成了流水线。大纲、世界观、人物关系先落成 Markdown 文件，再让 Agent 逐章生成。听起来很顺，实际做起来才发现，长文本的一致性比代码难管得多——代码编译不过会报错，小说写崩了却不会有人拦你。

真正让我决定把这套流程写下来的，是三个反复出现的坑。第一，Agent 写着写着会自己“收工”，明明还有三十章没写，它却觉得任务完成了。第二，字数完全不受控，我要五千字，它给一千多字到六千字都有。第三，前后细节对不上，上一章拿到的道具，下一章功能就变了。这些问题逼着我把配置、约束文件、验证动作全部固化下来，也就是下面你要看到的这套可复制流程。

在动手前，你需要准备三样东西：一个能装插件的 VS Code、一个可用的模型调用通道、一份写清楚规则的 AGENTS.md。模型通道这块我用 TaoToken 统一管理，好处是 Key 和 Base URL 只配一次，后面换模型、加模型都不用改插件里的散落配置。官网在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 入口是 https://taotoken.net/api ，注意 API 地址不带后面那串跟踪参数。

这一节先把场景和问题讲透，下一节再讲怎么把通道和 Key 准备好。你如果只是想先跑通一章，也可以边看边配，不用等全部读完。

2. TaoToken 前置准备：统一 Key 与 API 通道

这一节解决“模型调用怎么管”的问题。很多人写小说写到一半，发现插件里配了五六个模型的 Key，换一个模型就要改一次配置，最后自己都记不清哪个 Key 对应哪个通道。我的做法是用 TaoToken 做统一入口，插件里只认一个 Base URL 和一个 Key，模型名按需切换。

先注册并拿到 Key。打开 https://taotoken.net/api ，进入控制台后创建 API Key。创建时建议按用途命名，比如novel-vscode，这样以后排查调用来源时一眼能认出来。Key 只在创建时完整显示一次，复制后先存到安全的地方，别直接贴在会提交到 Git 的配置文件里。

拿到 Key 之后，你需要记住两个地址。Base URL 用https://taotoken.net/api，注意这里不要加任何跟踪参数，跟踪参数只用于官网跳转统计，写进代码里会导致部分客户端拼接路径出错。模型 ID 按你实际要用的填，比如 deepseek 系列就填对应的模型标识，具体以控制台里列出的为准。

这里有个容易踩的坑：不同客户端对 Base URL 的拼接方式不一样。有的客户端会在你填的地址后面自动补/v1/chat/completions，有的则要求你填到/v1为止。所以配置前先确认你用的插件是哪种拼接逻辑。kilo-code 这类基于 OpenAI 兼容协议的插件，通常填到https://taotoken.net/api就能自动补全路径；如果报 404，就试着补上/v1再试。

为了后面配置方便，我建议你把这几项整理成一张对照表，放在项目根目录的笔记里（不要提交 Key 明文）：

如果你还想在浏览器里直接验证模型是否可用，可以打开模型对话页面 https://taotoken.net/api 对应的对话入口先聊一句，确认通道通了再进 VS Code 配置。这一步能帮你排除掉“到底是通道问题还是插件问题”。

准备阶段还有一件事：把项目目录结构先建好。我用的结构是根目录放AGENTS.md、章节大纲.md、世界观设定.md，然后一个chapters/目录放每章正文，一个scripts/放字数统计脚本。结构清晰，Agent 检索时也更不容易迷路。下一节进入 VS Code 和 kilo-code 的具体配置。

3. 可复制配置：VS Code + kilo-code 接入 deepseek

这一节是整篇的核心操作区，目标是把插件、模型、约束文件三件套配好。先说结论：kilo-code 里必须同时配齐 Base URL、API Key、Model ID 这三样，缺一个都会调用失败。下面按顺序来。

第一步，在 VS Code 扩展市场搜索并安装 kilo-code。安装完成后，侧边栏会出现它的图标。打开设置，找到模型提供商配置区域。不同版本界面措辞可能略有差异，但核心字段就三个：API Base URL、API Key、Model。

第二步，填入上一节准备的值。Base URL 填https://taotoken.net/api，API Key 填你创建的那串，Model 填 deepseek 对应的模型标识。如果你用的是支持 JSON 配置的版本，可以直接写一段配置片段，路径和字段名以你本地实际为准：

{ "kilo-code.provider": "openai-compatible", "kilo-code.baseUrl": "https://taotoken.net/api", "kilo-code.apiKey": "sk-你的Key", "kilo-code.model": "deepseek-chat", "kilo-code.codebaseIndexing": true }

注意codebaseIndexing这一项，我把它打开是有原因的。写长篇小说时，Agent 需要能通过自然语言检索前文片段，比如“主角上一章拿到的戒指有什么功能”。开启索引后，它能在项目文件里做语义检索，微观一致性会好很多。索引首次构建会花点时间，章节多了以后更明显，耐心等它跑完。

第三步，写 AGENTS.md。这个文件相当于给 Agent 的项目说明书，放在项目根目录。它会被自动读取，用来约束写作风格和一致性规则。我的模板核心包含这几块：角色定位、核心写作逻辑、检索要求、禁止事项、工作流。下面是一个精简可用的版本，你可以直接改成自己的题材：

# AGENTS.md ## 角色 你是一位擅长快节奏叙事的网文写作助手，同时负责维护剧情一致性。 ## 核心规则 1. 写新章节前，必须先检索前文，确认登场人物的状态、等级、关系。 2. 严禁出现人物复活、等级倒退、名字写错等低级错误。 3. 不确定的细节必须查证，禁止凭空编造。 4. 每章目标字数 5000 字，允许上下浮动 10%。 ## 工作流 1. 读取章节大纲，确认本章目标。 2. 检索涉及人物与伏笔。 3. 输出正文，保持与前文一致。 4. 输出后自查字数与一致性。

第四步，把章节大纲和世界观设定也写成 Markdown 文件。大纲里至少要有每章的标题和一句话剧情，世界观里写清等级体系、势力关系、主角金手指规则。这些文件是宏观一致性的锚点，Agent 每次写作都会参考。

配置完成后，建议先做一次最小验证：新建一个测试文件，让 Agent 写一段两百字的开场，看它是否能正常返回。如果这一步通了，再进入正式章节生成。下一节讲怎么验证请求成功，以及成功结果长什么样。

4. 验证请求与逐章生成：从大纲到章节

配置好之后，别急着让它一口气写四十章。我的经验是，先跑通单章，再考虑批量。这一节给你一套可复制的验证动作和逐章生成流程。

先做连通性验证。在 VS Code 里打开 kilo-code 的对话面板，输入一句最简单的指令，比如“用一句话介绍你自己”。如果返回正常，说明 Base URL、Key、Model 三件套没问题。如果报错，先看错误类型，下一节会专门讲排查。

连通之后，做一次单章生成验证。打开章节大纲.md，把第一章的标题和剧情复制到对话里，再补一句“请根据 AGENTS.md 的规则写第一章，目标 5000 字”。观察它的行为：理想情况下，它会先检索前文（此时还没有前文，可能跳过），然后输出正文。生成完成后，检查三件事：字数是否接近目标、是否遵循了大纲、有没有出现真实人名或公司名。

单章通过后，进入逐章循环。我的做法是每写完一章就人工过一遍，确认无误再写下一章。具体指令可以固定成模板，减少每次输入成本：

请阅读 AGENTS.md 和 章节大纲.md，写第 N 章。 要求： 1. 先检索前文，确认人物状态与伏笔。 2. 目标字数 5000 字。 3. 输出后自查一致性，列出本章涉及的人物和道具。

生成结果会保存到chapters/目录下，命名成第N章-标题.md。每章写完后，跑一次字数统计脚本。我用的是一个简单的 Python 脚本，统计中文字符数：

import re import sys def count_chinese(path): with open(path, encoding="utf-8") as f: text = f.read() return len(re.findall(r"[\u4e00-\u9fff]", text)) if __name__ == "__main__": print(count_chinese(sys.argv[1]))

字数不达标的章节，直接让 Agent 重写或扩写。这里有个技巧：不要只说“字数不够”，要告诉它“当前 3200 字，请扩写到 5000 字，补充场景描写和对话，不要改变剧情走向”。指令越具体，返工越少。

实测下来，连续写三到五章后，Agent 容易主动结束任务，哪怕还有大量章节没写。我的应对是每章单独发起一次请求，不指望它一口气跑完。另外，写到后面它会越来越敷衍，剧情变简略、不遵循设定。这时候把 AGENTS.md 和大纲重新贴进上下文，或者新开一个会话，能明显改善。下一节集中讲这些报错和异常怎么排查。

5. 本篇常见错排查：401、代理失败与一致性崩坏

这一节按真实报错来。你在配置和生成过程中大概率会遇到下面几类问题，我逐个给排查路径。

第一类，401 未授权。表现是调用直接返回 401，提示 Key 无效或未提供。排查顺序：先确认 Key 有没有复制完整，前后有没有多余空格；再确认这个 Key 在控制台里是否被禁用或删除；最后确认 Base URL 有没有写错，比如误填了带跟踪参数的地址。如果 Key 没问题但依然 401，试着重新创建一个 Key 再试，排除复制污染。

第二类，本地代理失败或连接超时。报错里可能出现 local proxy failed、connection refused 这类字样。这通常不是模型通道的问题，而是本地网络或客户端代理设置的问题。检查 VS Code 的网络设置，确认没有配置指向本地的代理端口；如果你所在环境有网络策略限制，按所在组织的合规要求处理，不要自行搭建任何绕过手段。把 Base URL 换成https://taotoken.net/api直连再试一次，很多时候是地址拼接错了。

第三类，读取 choices 字段报错。报错类似 reading 'choices' of undefined，意思是客户端拿到了非预期格式的响应。常见原因是 Base URL 拼接路径不对，比如该补/v1没补，或者多补了一段。对照你插件的拼接逻辑，把地址调整到正确层级。另一个原因是模型 ID 填错，通道返回了错误结构，客户端解析失败。确认 Model 字段和控制台里列出的标识完全一致。

第四类，OAuth 或鉴权流程卡住。如果你用的是需要 OAuth 的客户端，报错可能出现在回调环节。这类问题优先检查回调地址是否和客户端要求一致，以及 Key 是否被用在了不支持的方式上。对于 kilo-code 这类用 API Key 的插件，一般不走 OAuth，如果你遇到 OAuth 报错，先确认是不是装错了插件或选错了鉴权模式。

第五类，一致性问题，也就是“吃书”。表现是人物等级倒退、道具功能变化、名字写错。这不是报错，但比报错更烦。排查思路：先确认 AGENTS.md 是否被正确读取，文件是否在项目根目录；再确认 codebase-indexing 是否开启并完成索引；最后检查你是不是在同一个会话里连续写了太多章，导致上下文被压缩后丢失了早期设定。我的做法是每三到五章新开一次会话，并把关键设定重新贴一遍。

第六类，Agent 主动结束任务。明明还有章节没写，它却说完成了。这通常和任务边界不清有关。把“写完整本书”拆成“写第 N 章”，每次只给一个明确目标，能大幅减少这种情况。如果它写完一章就停，那正是你想要的，继续发下一章指令即可。

第七类，字数不达标。这是模型通病，没有根治办法，只能靠统计脚本加人工重写。把字数要求写进 AGENTS.md，再配合脚本校验，能把返工率降下来。

排查时记住一个原则：先分清是通道问题、插件问题还是内容问题。通道问题看 401 和连接类报错，插件问题看配置字段和路径拼接，内容问题看一致性和字数。分清了，解决起来就快。下一节给出统一的入口和后续动作。

6. 统一入口与后续动作

把上面这套跑通之后，你手里其实就有了一个可复用的长文本生产流程：VS Code 负责编辑和检索，kilo-code 负责调度 Agent，deepseek 负责出字，AGENTS.md 负责约束，TaoToken 负责统一模型调用。换题材、换模型，只需要改大纲和 AGENTS.md，通道和插件配置基本不用动。

如果你卡在排障或接入环节，优先去看 API Keys 和接入文档，地址是 https://taotoken.net/api ，先把 Key 和 Base URL 这两件事确认清楚。如果你只是想先验证模型能不能用、输出风格合不合口味，可以直接进模型对话页面聊几句，成本很低。如果你打算长期做编码类或 Agent 类项目，比如把这套流程扩展成自动跑章节的流水线，那 Coding Plan 会更合适，入口在 https://taotoken.net/api 对应的套餐页面里找。

我自己的下一步优化方向有三个：一是把字数校验和一致性检查做成脚本，每章生成后自动跑；二是把 AGENTS.md 拆成多个小文件，按需加载，减少上下文占用；三是尝试在每章生成前自动注入相关人物卡片，进一步压住微观一致性问题。这套东西不完美，但比纯手工写快得多，也比完全放任 AI 乱写可控得多。你先跑通一章，剩下的就是重复和调优。