企业官网建设流程全解析

1. 为什么 Cursor 写着写着就「失忆」了

用 Cursor 写代码，最怕的不是它写错，而是它忘了。我试过在一个中型项目里让 Cursor Agent 连续重构，前半小时它记得接口约定、模块划分、依赖顺序，聊到后面 Context 一满，返回值从{data, error}悄悄变成{result, message}，提醒一次改回来，再过几轮又飘回去。更麻烦的是，它的「计划」只活在对话里，窗口一关，规划状态就没了，你没法把这个状态打包发给同事说「你接着跑」。

这就是 Task Master AI 结构化图谱要解决的问题。它把需求文档（PRD）先解析成一份结构化的 JSON 任务图谱，落到硬盘上，再按拓扑顺序一步步执行。计划是一个文件，不是一段对话，可以断点续传、手动编辑、分享给队友。它不替代 Cursor，而是给 Cursor 补上一张「图纸」：Cursor 负责灵活应变，Task Master AI 负责把工序排好。

Task Master AI 是一个基于 AI 的任务管理系统，核心能力是把 PRD 自动拆解成带依赖关系的任务图谱，并通过 MCP 协议嵌入 Cursor、VS Code、Windsurf 这类 AI 编程工具。它适合三类人：用 Cursor 做新项目启动的开发者、需要理清模块依赖再动手的重构场景、以及并行开发时需要清晰任务边界的团队。本文聚焦 Cursor 里的结构化图谱工作流，从需求拆解到任务依赖编排，再到 MCP 工具调用，给出可复制的配置片段和验证步骤，并用一个小型编程任务验证图谱拆解效果。

先说清楚它和普通「任务清单」的区别。普通清单是把文档切成一条条待办，彼此平级；Task Master AI 会分析任务之间的依赖，按拓扑排序告诉你先做什么、后做什么、哪些可以并行。它引入了微软研究院提出的 RPG（Repository Planning Graph，仓库规划图）概念，用图替代自然语言做规划：图里每个节点代表一个功能或模块，边代表依赖关系，AI 沿着拓扑顺序一个节点一个节点实现。自然语言有歧义、会漂移，图不会。这就是为什么它能把「AI 写代码没有图纸」这件事补上。

在 Cursor 里，这套东西通过 MCP 协议暴露成工具，你可以在聊天框直接问「下一个任务是什么」，它会结合项目上下文回答。下面从环境准备开始，一步步把它接进 Cursor。

2. 前置准备：Node 环境、TaoToken 统一 Key 与 MCP 接入

Task Master AI 本身是开源免费的（MIT 协议），但它要调用大模型，所以你需要一个能稳定调用的模型通道。这里我用 TaoToken 做统一 Key/API 通道，好处是一个 Key 管多种模型，主模型、研究模型、备用模型都能在同一个通道里切换，不用为每个模型单独配一套凭证。官网入口是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 基址是 https://taotoken.net/api 。

第一步，确认 Node 版本。Task Master AI 通过 npm 全局安装，Node 建议 18 以上：

node -v npm -v

如果版本太低，先升级 Node。接着全局安装：

npm install -g task-master-ai task-master --version

能打印版本号就说明 CLI 装好了。第二步，去 TaoToken 控制台创建一个 API Key。打开 https://taotoken.net/console ，在 API Keys 页面新建一个 Key，复制出来。这个 Key 后面会同时用在 Task Master AI 的模型配置和 Cursor 的 MCP 配置里。如果你还没决定用哪个模型，可以先去模型对话页面 https://taotoken.net/model-chat 试一下通道是否正常，确认能收到回复再往下走。

第三步，初始化项目。进入你的代码仓库根目录：

cd your-project task-master init

这个命令会生成.taskmaster/目录，里面包含config.json、tasks/等文件。tasks/tasks.json就是任务图谱的落盘位置，所有拆解结果都存在这里。初始化时它会问你用哪种 AI 提供商，你可以先跳过，后面直接改配置文件更清楚。

第四步，配置模型通道。Task Master AI 的模型配置支持主模型（main）、研究模型（research）、备用模型（fallback）。我们用 TaoToken 的 Base URL 统一指向，Key 用刚才创建的那个。具体配置片段在下一节给出，这里先记住三件套：Base URL、API Key、Model ID，缺一不可。

第五步，把 Task Master AI 作为 MCP Server 接进 Cursor。Cursor 的 MCP 配置在~/.cursor/mcp.json（全局）或项目内.cursor/mcp.json（项目级）。项目级配置更适合团队共享，因为可以跟着仓库走。配置内容同样在下一节给出。

这里有个容易踩的坑：很多人只配了 CLI 就以为 Cursor 里能用了，其实 CLI 和 MCP 是两条路径。CLI 负责解析 PRD、生成图谱；MCP 负责让 Cursor 的聊天框能调用这些工具。两者都要配，且共用同一份.taskmaster/config.json。如果你只想要 CLI，可以跳过 MCP；但本文的场景是「在 Cursor 里」，所以两个都配。

另外提醒一句：不要把生产数据库连接串、真实密钥这类敏感信息写进 PRD 或任务描述里，Task Master AI 会把它们发给模型。图谱文件是明文 JSON，提交到仓库前检查一下有没有不该进去的内容。

3. 可复制配置：config.json 与 Cursor MCP 三件套

这一节给出可以直接复制的配置片段。先看 Task Master AI 的模型配置，路径是项目根目录下的.taskmaster/config.json。把your-token-key换成你在 TaoToken 控制台创建的真实 Key：

{ "models": { "main": { "provider": "openai-compatible", "modelId": "claude-sonnet-4-20250514", "baseUrl": "https://taotoken.net/api", "apiKey": "your-token-key" }, "research": { "provider": "openai-compatible", "modelId": "claude-sonnet-4-20250514", "baseUrl": "https://taotoken.net/api", "apiKey": "your-token-key" }, "fallback": { "provider": "openai-compatible", "modelId": "gpt-4o-mini", "baseUrl": "https://taotoken.net/api", "apiKey": "your-token-key" } }, "global": { "logLevel": "info", "defaultSubtasks": 5, "defaultPriority": "medium" } }

这里provider用openai-compatible，因为 TaoToken 的 API 兼容 OpenAI 的调用格式，Base URL 填https://taotoken.net/api，注意不要带末尾斜杠。modelId按你实际想用的模型填，主模型建议用能力强的，研究模型可以同款，备用模型用便宜快速的兜底。三个模型共用同一个 Key，这就是统一通道的价值：换模型只改modelId，不用动 Key 和 Base URL。

再看 Cursor 侧的 MCP 配置。项目级路径是.cursor/mcp.json，内容如下：

{ "mcpServers": { "task-master-ai": { "command": "npx", "args": ["-y", "task-master-ai"], "env": { "OPENAI_API_KEY": "your-token-key", "OPENAI_BASE_URL": "https://taotoken.net/api", "TASK_MASTER_MODEL": "claude-sonnet-4-20250514" } } } }

这三件套对应关系要记牢：Base URL 是https://taotoken.net/api，Key 是your-token-key，Model ID 是claude-sonnet-4-20250514（按需替换）。MCP 配置里的环境变量名取决于 Task Master AI 当前版本读取的变量，如果启动后报模型未配置，优先检查这里的环境变量名是否和.taskmaster/config.json里的字段对得上。两个文件里的 Key 和 Base URL 必须一致，否则会出现 CLI 能跑、MCP 报 401 的割裂现象。

配置完成后重启 Cursor，让 MCP 配置生效。重启后在 Cursor 设置里找到 MCP 面板，应该能看到task-master-ai处于已连接状态。如果显示未连接，先看下一节的排障。

关于模型选择，如果你打算长期做编码和 Agent 类任务，可以了解 Coding Plan 这类按周期计费的方案，入口在 https://taotoken.net/coding-plan ，适合高频调用场景；如果只是偶尔验证，用模型对话页面按量试就行。接入文档在 https://taotoken.net/doc ，里面有各语言的调用示例，配 MCP 时遇到字段疑问可以对照。

4. 验证请求：从 PRD 到任务图谱的完整跑通

配置好之后，用一个真实的小任务验证整条链路。我准备了一份极简 PRD，描述一个「命令行待办清单」工具，保存为prd.md：

# 命令行待办清单 ## 功能 - 添加待办事项，支持标题和优先级 - 列出所有待办，按优先级排序 - 标记待办为完成 - 删除待办 ## 结构 - src/cli.js 负责命令行入口 - src/store.js 负责数据读写，依赖本地 JSON 文件 - src/format.js 负责输出格式化，被 cli.js 调用 - 数据文件 data/todos.json ## 依赖 - cli.js 依赖 store.js 和 format.js - store.js 独立，不依赖其他模块 - format.js 独立

第一步，解析 PRD 生成图谱：

task-master parse-prd prd.md --research

--research会让研究模型补充领域知识，比如提醒你考虑并发写入、文件锁等。执行后打开.taskmaster/tasks/tasks.json，你会看到结构化的任务节点，每个节点有id、title、description、dependencies、status等字段。依赖关系被显式写成了数组，比如 cli 相关任务的dependencies里会包含 store 和 format 的任务 id。

第二步，分析复杂度：

task-master analyze-complexity --research

它会标出哪些任务偏复杂、建议进一步拆解。输出里通常带一个复杂度评分，分数高的任务下一步会被展开。

第三步，展开复杂任务：

task-master expand --all --research

这一步把复杂任务拆成子任务，同时保持依赖链完整。展开后再次查看tasks.json，你会看到子任务挂在父任务下，依赖关系没有断。

第四步，在 Cursor 里验证 MCP 调用。打开 Cursor 聊天框，输入：

用 task-master 看一下下一个该做的任务是什么

如果 MCP 接通，Cursor 会调用 Task Master AI 的工具，返回当前拓扑排序下可执行的任务。你也可以直接问「列出所有没有前置依赖的任务」，它会返回可以并行开工的节点。这一步是验证 MCP 是否真正生效的关键：如果 Cursor 只是用模型自己编了一个答案，而不是调用工具，说明 MCP 没连上。

第五步，执行并更新状态。按返回的任务开始写代码，完成后标记：

task-master set-status --id=1 --status=done

再跑一次task-master next，它会基于更新后的图谱给出下一个可执行任务。整个过程里，图谱文件是唯一事实来源，Cursor 的对话窗口关了也不影响，下次打开继续问就行。

实测下来，这套流程对「先想清楚再动手」的场景帮助明显。PRD 写得越具体，图谱质量越高；PRD 含糊，拆出来的任务也会含糊，这就是垃圾进垃圾出。

5. 常见报错排查：401、local proxy failed 与 reading choices

接入过程中最容易撞上几类报错，逐个说清楚。

第一类，401 Unauthorized。表现是 CLI 或 MCP 调用时返回 401，提示鉴权失败。原因通常是 Key 不对、Key 过期，或者 Base URL 和 Key 不匹配。排查顺序：先确认.taskmaster/config.json和.cursor/mcp.json里的 Key 是同一个，且没有多余空格；再确认 Base URL 是https://taotoken.net/api，没有写成带/v1或其他路径的变体；最后去控制台确认这个 Key 还有效。如果 CLI 能跑、MCP 报 401，基本就是 MCP 配置里的环境变量没读到，检查env字段的变量名。

第二类，local proxy failed 或连接被拒。表现是请求发不出去，提示本地代理失败。这类问题多半出在网络层配置，检查你的系统代理设置是否干扰了对taotoken.net的访问，把该域名加入直连或例外列表。另外确认防火墙没有拦截 Node 进程的出站请求。如果公司网络有统一出口策略，按内部规范处理，不要自行改动网络配置。

第三类，reading choices 相关报错。表现是解析响应时读不到choices字段，报类似Cannot read properties of undefined (reading 'choices')。这通常说明返回的不是标准 OpenAI 格式的响应，可能是 Base URL 指错了端点，或者模型 ID 填了一个通道不支持的模型。排查：确认modelId是通道里真实可用的模型名，确认 Base URL 指向的是兼容 OpenAI 格式的端点。可以先用模型对话页面发一条最简单的请求，确认通道本身正常，再回来查配置。

第四类，OAuth 相关报错。如果你之前用过 Claude Code 或 Codex CLI 的 OAuth 方式，可能会在环境里残留旧的凭证变量，导致 Task Master AI 优先读了旧凭证而不是你配的 Key。排查：检查环境变量里有没有遗留的ANTHROPIC_*、OPENAI_*旧值，清理掉或显式覆盖。Task Master AI 读取配置有优先级，环境变量可能盖过配置文件，这点要留意。

第五类，MCP 显示已连接但工具调不到。表现是 Cursor 里问「下一个任务」，它不调用工具而是自己编。原因可能是 MCP Server 启动失败但状态没刷新，或者工具名不匹配。排查：重启 Cursor，查看 MCP 面板的日志输出；确认npx -y task-master-ai能手动启动不报错；确认 Cursor 版本支持 MCP 工具调用。

把这几类排掉，基本就能稳定跑通。遇到报错时，先分清是 CLI 层还是 MCP 层，两层的配置来源不同，定位会快很多。

6. 把图谱接进日常编码：CTA 与长期用法

跑通之后，Task Master AI 的日常用法可以很轻。新项目启动时，先写一份结构化 PRD，用parse-prd生成图谱，再在 Cursor 里按next的指引逐个实现；重构时，把现有模块依赖写进 PRD，让图谱帮你理清改动顺序；团队协作时，把.taskmaster/tasks/tasks.json提交到仓库，队友拉下来就能接着跑，任务边界清晰。

如果你主要做长期编码和 Agent 类任务，建议把模型通道固定下来，用 Coding Plan 这类方案管理调用，入口在 https://taotoken.net/coding-plan ，避免每次临时找 Key。接入细节和字段说明看文档 https://taotoken.net/doc ，API Key 在控制台 https://taotoken.net/api-keys 管理，需要快速验证模型是否正常就用模型对话 https://taotoken.net/model-chat 。Claude Code 相关的接入说明在 https://taotoken.net/claude-code-anthropic ，如果你同时用 Claude Code，可以参考那里的配置方式保持通道一致。

最后说一个实用技巧：图谱不是一次生成就完事，随着实现推进，任务状态会变，依赖可能调整。养成习惯，每完成一批任务就set-status更新一次，定期analyze-complexity复查有没有新的复杂节点冒出来。图谱文件是活的，维护它比维护一段对话记忆靠谱得多。Cursor 负责灵活，图谱负责不跑偏，两者配合，才是这套工作流真正的价值。