无穹玩法 | 用MCP把产品文档自动生成官网工作流改到TaoToken

1. 产品文档自动生成官网的真实痛点

产品文档到官网这条链路，听起来像是"把 PRD 丢给 AI，前端页面就出来了"，但真正动手做过的人都知道，中间卡点特别多。我最近在折腾一个内部工具站，需求文档放在飞书里，每周更新两三次，每次更新都要手动同步到官网的静态页面，改文案、调结构、重新部署，一套流程下来半小时起步。后来想着用 MCP 工作流把这件事自动化，结果第一版跑通之后发现，真正麻烦的不是文档解析，也不是页面生成，而是多个工具之间的 Key 分散管理。

具体来说，这条链路里至少涉及三类调用：文档解析需要飞书开放平台的 App ID 和 App Secret，页面生成需要大模型的 API Key，发布环节可能还要对接静态托管平台的 Token。每个工具各管各的 Key，配置散落在不同的.env、settings.json、mcp.json里，一旦某个 Key 过期或者额度用完，排查起来要翻好几个文件。更头疼的是调用稳定性——有的模型服务在高峰期响应慢，MCP 工具链里一个环节超时，整个工作流就断了，日志里只留下一句local proxy failed或者reading choices之类的报错，根本看不出是哪一层出的问题。

所以这篇文章要解决的核心问题很明确：把产品文档自动生成官网的 MCP 工作流，统一改到 TaoToken 上。TaoToken 提供 OpenAI 兼容的 API 接口，Base URL 是https://taotoken.net/api，意味着你可以在 Cline、Cursor、Claude Code 这些工具里，用同一套 Key 和同一个 Base URL 驱动整个工作流里的模型调用。文档解析、页面生成、内容润色，全部走一个入口，Key 不用再分散到四五个地方，调用稳定性也由统一的服务层来兜底。

适合谁看？如果你正在用 Cline 或者类似的 AI 编码工具做自动化工作流，手里有产品文档需要定期同步到官网，又不想每次手动改配置，那这篇的步骤可以直接跟做。如果你只是想让 AI 帮你把一份 Markdown 文档转成 HTML 页面，前半部分的 MCP 配置和验证流程同样适用。整条链路我会用一次真实的文档更新来验证：改飞书文档里的一个需求描述，触发 MCP 工作流，看官网页面是否自动重建成功。

先说清楚整体架构，避免后面配置的时候迷路。工作流分三层：第一层是文档源，飞书文档通过 Feishu-MCP 暴露给 AI 工具；第二层是生成层，Cline 作为 MCP 客户端，调用大模型把文档内容转成前端代码；第三层是发布层，生成的代码推到静态托管或者本地预览。TaoToken 的作用是替换掉第二层里原本指向其他模型服务的 Base URL，让模型调用统一走https://taotoken.net/api。这样改完之后，你只需要维护一个 API Key，就能覆盖文档解析后的所有模型调用环节。

2. TaoToken 前置准备与 MCP 环境搭建

在改配置之前，先把 TaoToken 这边的准备工作做完。打开官网https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=，注册登录之后进控制台，在 API Keys 页面创建一个新的 Key。这个 Key 后面要填到 Cline 的模型配置和 MCP 服务的环境变量里，所以创建之后先复制出来存好，页面刷新之后就看不到了。

TaoToken 的 API 入口是https://taotoken.net/api，注意这个地址不带任何查询参数，直接作为 Base URL 使用。它兼容 OpenAI 的接口格式，所以 Cline 里选 "OpenAI Compatible" 就能对接。模型 ID 这块，你可以根据自己工作流的需要选，文档解析和页面生成这类任务，用通用的对话模型就够，具体可用的模型列表在控制台的模型对话页面能看到，也可以直接在模型对话里试一下响应速度和输出质量，确认没问题再填到配置里。

接下来是 MCP 环境的搭建。我用的客户端是 Cline，VSCode 里装好扩展之后，点侧边栏的 Cline 图标打开设置面板。这里有个容易踩的坑：Cline 的 Plan 和 Act 功能是独立配置的，MCP 工作流实际执行的时候走的是 Act 通道，所以你要在 Act 的 API 配置区域里改，别改到 Plan 那边去了。API Provider 选 "OpenAI Compatible"，然后填三个关键信息：

• Base URL：https://taotoken.net/api
• API Key：刚才在 TaoToken 控制台创建的那个
• Model ID：你选定的模型标识

填完之后点保存，Cline 会发一个测试请求验证连通性。如果这里就报 401，大概率是 Key 复制的时候带了空格，或者 Base URL 末尾多加了/v1。TaoToken 的 Base URL 就是https://taotoken.net/api，不需要再拼路径。

模型服务配好之后，接着装 Feishu-MCP。这个开源项目的作用是把飞书文档的内容通过 MCP 协议暴露出来，让 Cline 能直接读取文档。安装步骤不复杂，但有几个细节要注意。先克隆仓库：

git clone https://github.com/cso1z/Feishu-MCP.git cd Feishu-MCP

然后用 pnpm 装依赖：

pnpm install

装完之后复制环境变量模板：

cp .env.example .env

打开.env文件，填入飞书应用的凭证。这里需要你先去飞书开放平台创建一个企业自建应用，拿到 App ID 和 App Secret，并且在权限管理里开通云文档相关的读取权限。没有这一步，MCP 服务启动之后调飞书接口会直接返回权限错误。

飞书那边的配置流程是：登录开放平台，进开发者后台，创建应用，填名称和描述，选企业自建应用。创建完成后在凭证与基础信息页面能看到 App ID 和 App Secret，复制出来填到.env里。然后去权限管理，搜索"云文档"，把读取文档内容的权限勾上。如果文档在知识库里，可能还需要额外的知识库权限，这个根据你的实际文档位置来定。

.env填好之后，本地跑一下 MCP 服务确认能启动：

pnpm run dev

看到服务正常监听的日志输出，说明飞书这边的通道打通了。这时候回到 Cline，在 MCP Servers 的配置里加上 Feishu-MCP 的条目。Cline 的 MCP 配置是一个 JSON 文件，路径通常在~/.cline/mcp.json或者项目目录下的.cline/mcp.json，具体看你用的是全局配置还是项目级配置。配置内容长这样：

{ "mcpServers": { "feishu-mcp": { "command": "npx", "args": ["-y", "feishu-mcp", "--stdio"], "env": { "FEISHU_APP_ID": "你的飞书应用ID", "FEISHU_APP_SECRET": "你的飞书应用密钥" } } } }

把FEISHU_APP_ID和FEISHU_APP_SECRET替换成你实际的值。保存之后 Cline 会自动加载这个 MCP Server，你可以在 MCP 面板里看到feishu-mcp的状态变成已连接。如果显示连接失败，先检查npx能不能正常执行，有时候 Node 版本太低会导致npx拉包失败，升级到 Node 18 以上基本能解决。

到这里，TaoToken 的模型服务和 Feishu-MCP 的文档通道都准备好了。下一步是把两者串起来，让 Cline 在执行工作流的时候，模型调用走 TaoToken，文档读取走 Feishu-MCP。

3. 可复制的 MCP 工作流配置片段

这一节给出完整的配置文件，你可以直接复制到自己的环境里，只需要替换几个占位符。整个工作流涉及两个配置文件：一个是 Cline 的 MCP Server 配置，另一个是 Cline 的模型服务配置。两者配合起来，才能让文档解析和页面生成都走 TaoToken。

先看 MCP Server 的配置。这个文件的位置取决于你的 Cline 安装方式，VSCode 扩展版的默认路径是~/.cline/mcp.json，如果你在项目里单独配置过，也可能在项目根目录的.cline/mcp.json。内容如下：

{ "mcpServers": { "feishu-mcp": { "command": "npx", "args": ["-y", "feishu-mcp", "--stdio"], "env": { "FEISHU_APP_ID": "cli_xxxxxxxxxxxx", "FEISHU_APP_SECRET": "xxxxxxxxxxxxxxxxxxxxxxxx", "TAOTOKEN_BASE_URL": "https://taotoken.net/api", "TAOTOKEN_API_KEY": "sk-xxxxxxxxxxxxxxxx" } } } }

这里我把 TaoToken 的 Base URL 和 API Key 也放进了 MCP Server 的环境变量里。虽然 Feishu-MCP 本身不直接调模型，但如果你后续在这个 MCP 服务里扩展了文档摘要或者内容清洗的逻辑，这些环境变量就能直接复用，不用再单独配一遍。FEISHU_APP_ID和FEISHU_APP_SECRET换成你飞书应用的凭证，TAOTOKEN_API_KEY换成你在 TaoToken 控制台创建的 Key。

然后是 Cline 的模型服务配置。这个配置在 Cline 的设置面板里填，但底层存储的是一个 JSON 文件，路径通常在~/.cline/settings.json。如果你习惯直接改文件，可以对照下面的结构：

{ "apiProvider": "openai", "openAiBaseUrl": "https://taotoken.net/api", "openAiApiKey": "sk-xxxxxxxxxxxxxxxx", "openAiModelId": "your-model-id", "openAiLegacyFormat": false }

openAiBaseUrl填https://taotoken.net/api，openAiApiKey填 TaoToken 的 Key，openAiModelId填你在控制台选定的模型标识。openAiLegacyFormat保持false，因为 TaoToken 走的是标准的 OpenAI 兼容接口，不需要旧版格式。

如果你用的是 Claude Code 而不是 Cline，配置方式略有不同。Claude Code 的配置文件在~/.claude/settings.json，里面需要指定 Anthropic 兼容的 Base URL。TaoToken 提供了对应的接入点，配置片段如下：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "sk-xxxxxxxxxxxxxxxx" } }

注意 Claude Code 用的是ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY这两个环境变量名，不要和 OpenAI 的混用。填好之后重启 Claude Code，它就会把模型请求发到 TaoToken。

如果你用的是 Codex，配置文件在~/.codex/auth.json，结构是这样的：

{ "openai_base_url": "https://taotoken.net/api", "openai_api_key": "sk-xxxxxxxxxxxxxxxx" }

Codex 的配置项名称和 Cline 不一样，但核心信息就三个：Base URL、API Key、Model ID。无论你用哪个工具，这三件套填对了，模型调用就能通。

配置改完之后，有一个验证步骤不能跳过。在 Cline 的对话框里输入一句简单的测试指令，比如"列出当前可用的 MCP 工具"，看它能不能正常返回。如果返回了feishu-mcp提供的工具列表，说明 MCP 通道和模型通道都通了。如果报错，先看错误信息里有没有401，有的话检查 Key；如果看到local proxy failed，检查 Base URL 是不是写成了https://taotoken.net/api/v1这种带多余路径的形式。

还有一个细节：Cline 的 MCP 配置和模型配置是分开加载的，改完 MCP 配置之后需要重启 Cline 或者手动重连 MCP Server，改模型配置则通常即时生效。如果你改完发现工作流还是走的老通道，先确认一下是不是 MCP Server 没重连。

4. 端到端验证：文档更新触发官网重建

配置就绪之后，跑一次完整的端到端验证。我用的测试文档是一份产品介绍 PRD，里面有几个模块：产品定位、核心功能、使用场景、定价说明。官网的目标页面是一个单页静态站，用 HTML + Tailwind CSS 写，部署在本地预览。

第一步，在 Cline 的 Act 对话框里输入指令，让它读取飞书文档并生成页面。指令可以这样写：

读取飞书文档 https://xxx.feishu.cn/docx/xxxxxxxx 的内容， 根据文档中的产品需求描述，生成一个产品介绍官网的单页 HTML， 使用 Tailwind CSS 做样式，输出到 ./output/index.html

Cline 收到指令后，会先通过 Feishu-MCP 调用飞书文档接口，把文档内容拉下来。这一步的日志里能看到 MCP 工具被调用的记录，类似feishu-mcp.get_document_content这样的条目。文档内容拿到之后，Cline 会把内容作为上下文，发到 TaoToken 的模型接口，让模型生成 HTML 代码。这一步的请求会走你在设置里配的https://taotoken.net/api，可以在 Cline 的请求日志里确认 Base URL 是否正确。

模型返回代码之后，Cline 会把生成的 HTML 写到./output/index.html。打开这个文件，能看到一个包含产品定位、功能列表、场景说明的页面。我实测下来，第一版生成的页面结构基本完整，但样式细节需要微调，比如功能卡片的间距和响应式断点。这属于正常情况，模型生成的是 MVP 版本，后续可以迭代。

第二步，验证文档更新触发重建。回到飞书文档，修改其中一个功能描述，比如把"支持多端同步"改成"支持多端实时同步，延迟低于 200ms"。保存之后，回到 Cline，重新执行刚才的指令。Cline 会再次通过 Feishu-MCP 拉取文档，这次拿到的是更新后的内容。模型重新生成 HTML，覆盖./output/index.html。打开页面，能看到功能描述已经同步更新。

这一步的关键验证点是：整个链路里没有手动改任何 Key 或 Base URL。文档解析走 Feishu-MCP，模型调用走 TaoToken，发布走本地文件写入。三个环节各司其职，但模型调用的入口是统一的。如果你之前用的是其他模型服务，改到 TaoToken 之后，只需要在 Cline 的设置里改一次 Base URL 和 Key，MCP 工作流本身不需要动。

第三步，检查调用日志。在 TaoToken 控制台的 API Keys 页面，能看到刚才两次工作流触发的请求记录，包括请求时间、模型 ID、消耗的 token 数。如果日志里只有一次请求，说明第二次执行的时候 Cline 可能用了缓存，没有重新调模型。这时候可以在指令里加一句"忽略缓存，重新读取文档"，强制走完整流程。

验证过程中如果遇到reading choices报错，通常是模型返回的格式不符合预期。Cline 期望的是标准的 OpenAI 响应结构，如果模型返回了非标准格式，解析就会失败。解决办法是在 Cline 的设置里确认openAiLegacyFormat设为false，并且 Base URL 没有多余路径。如果遇到OAuth相关的报错，检查一下是不是飞书那边的应用凭证过期了，重新生成 App Secret 再填一次。

端到端跑通之后，你可以把这个工作流固化下来。比如在 Cline 里保存一个自定义指令模板，每次文档更新后一键触发。或者更进一步，用定时任务或者 webhook 监听飞书文档的变更事件，自动触发 Cline 执行。不过那是下一步的优化了，先把基础链路跑稳。

5. 常见报错排查与配置对照

工作流跑起来之后，最容易出问题的几个地方我整理了一下，对照着排查能省不少时间。

401 Unauthorized：这个报错最常见，基本就是 Key 的问题。先检查 TaoToken 的 API Key 有没有复制完整，有没有多余的空格。然后确认 Base URL 是不是https://taotoken.net/api，如果写成了https://taotoken.net/api/v1或者带了其他路径，请求会被拒绝。还有一个容易忽略的点：Cline 的 Plan 和 Act 是分开配置的，如果你只改了 Plan 的 Key，Act 通道还是用的旧配置，执行工作流的时候就会报 401。确认你改的是 Act 区域的配置。

local proxy failed：这个报错通常出现在 MCP 服务启动阶段。Feishu-MCP 通过npx启动，如果本地网络环境导致npx拉包失败，或者 Node 版本太低，就会报这个错。解决办法是先手动执行npx -y feishu-mcp --stdio看能不能正常启动，如果报错就升级 Node 到 18 以上。另外检查.env文件里的飞书凭证有没有填对，App ID 和 App Secret 不匹配也会导致服务启动失败。

reading choices 报错：这个错误说明模型返回的响应结构不符合 OpenAI 标准格式。TaoToken 的接口是兼容 OpenAI 的，正常情况下不会出现这个问题。如果遇到了，先确认 Cline 的openAiLegacyFormat设为false，然后检查 Model ID 是不是填错了。有些模型标识在 TaoToken 控制台里能看到，但填到 Cline 里需要完全一致，大小写和连字符都不能错。

OAuth 相关报错：如果日志里出现 OAuth 字样，大概率是飞书应用的授权问题。飞书自建应用的 App Secret 如果重置过，旧的 Secret 就会失效，需要重新生成并更新到.env和 MCP 配置里。另外检查飞书应用的权限有没有开通云文档读取，权限没开的话，MCP 调接口会返回授权错误。

MCP Server 连接失败：Cline 的 MCP 面板里如果显示feishu-mcp未连接，先看 Cline 的输出日志，里面会有具体的错误信息。常见原因是mcp.json的 JSON 格式写错了，比如多了逗号或者少了引号。可以用 JSON 校验工具检查一下。另外确认npx的路径在 Cline 的运行环境里能访问到，有时候 VSCode 的环境变量和终端不一致，会导致npx找不到。

为了更直观地对照，我把关键配置项和常见错误整理成表格：

排查的时候按这个顺序来：先确认 Key 和 Base URL，再确认 Model ID，最后检查 MCP 配置和飞书凭证。大部分问题在前两步就能定位到。

还有一个隐藏的坑：如果你同时装了多个 MCP Server，Cline 在加载的时候可能会因为某个 Server 启动超时而导致整体加载失败。这时候可以在mcp.json里先只保留feishu-mcp一个，确认它能正常连接之后，再逐个加其他的。这样排查起来目标更明确。

6. 把工作流固化下来：从手动触发到自动同步

基础链路跑通之后，下一步是让它变得省心。我现在的做法是在 Cline 里保存一个指令模板，每次文档更新后，打开 Cline 点一下模板就能触发重建。模板内容就是前面验证时用的那段指令，加上"忽略缓存"和"输出到指定路径"这两个约束。

如果你想让这件事更自动化，可以考虑用飞书的 webhook 监听文档变更事件。飞书开放平台支持文档更新时推送事件到指定的回调地址，你可以写一个简单的服务接收这个事件，然后调用 Cline 的命令行接口触发工作流。不过这一步涉及额外的服务部署，看你的实际需求决定要不要做。

对于大多数场景，手动触发已经够用了。关键是整个链路的配置已经统一到 TaoToken 上，Key 不用再分散管理，模型调用的稳定性也有保障。我实测下来，连续触发十几次工作流，没有出现调用失败的情况，响应速度也稳定。

如果你在配置过程中遇到其他报错，或者想了解 TaoToken 在更多 AI 工具里的接入方式，可以去看接入文档，里面覆盖了 Cline、Cursor、Claude Code 等常见工具的配置示例。模型对话页面可以直接测试不同模型的输出效果，方便你选到适合自己工作流的模型。长期做编码和 Agent 工作流的话，Coding Plan 那边有更详细的方案说明，可以根据自己的使用频率选择合适的配置。

最后留一个实用技巧：在 Cline 的 MCP 配置里，把 TaoToken 的 Base URL 和 Key 写成环境变量引用，而不是硬编码在 JSON 里。这样换 Key 的时候只需要改一个地方，不用翻多个配置文件。具体做法是在系统环境变量里设置TAOTOKEN_API_KEY，然后在mcp.json里用${TAOTOKEN_API_KEY}引用。Cline 支持这种变量替换，配置起来更干净。