企业官网建设流程全解析

1. 从文献卡片到回归结果：WorkBuddy 接上 Stata MCP 到底解决什么问题

如果你正在做实证研究，大概率经历过这个循环：让 AI 生成一段 Stata 代码，复制到 do-file，切回 Stata 窗口运行，报错，再把日志贴回对话框，等 AI 改完，再复制回去。单次调试还能忍，一旦涉及几十篇文献的变量提取、多轮稳健性检验，这个循环就会把整块时间切碎。WorkBuddy 接入 Stata MCP 的价值，不是让 AI 替你写论文，而是把「生成代码—调用 Stata—读取日志—返回结果」这条链路交给 Agent 自动跑通，你只需要在关键节点做判断。

WorkBuddy 是腾讯推出的全场景 AI 智能体桌面工作台，可以在授权范围内读取本地文件、执行任务并交付文档、表格和代码。Stata MCP 则是基于 Model Context Protocol 的一套标准接口，让 Agent 能调用本地 Stata 执行 do-file 并回读日志。两者接上之后，文献整理阶段提取的变量清单，可以直接变成回归脚本的输入，中间不需要人工搬运。

这篇文章面向两类人：一类是经济学、社会学、公共管理等方向的实证研究者，手里有 Stata 17 以上版本，想让 AI 帮忙跑通从文献到回归的流程；另一类是 AI Agent 开发者，想了解 MCP 在本地统计软件上的落地方式。全文按真实论文工作顺序展开，先讲文献卡片怎么建，再讲数据诊断，然后给出可复制的 MCP 配置骨架，最后用一次回归验证端到端链路。配置部分需要少量命令行操作，但每一步都有完整命令和参数说明，照着做就能复现。

需要提前说明的是，WorkBuddy 的基础操作以中文图形界面和自然语言为主，但接入 Stata MCP、配置工作目录和排查环境错误，仍然需要理解路径和权限设置。所谓低门槛，不等于完全不需要碰命令行。下面从文献整理开始，一步步走到回归执行。

2. 前置准备：WorkBuddy、Stata 与 uv 的环境确认

在动 MCP 配置之前，先把三样东西确认到位，否则后面报错会很难定位。

第一，Stata 版本。MCP-for-Stata 当前要求 Stata 17 或更高版本，并且已经取得有效许可。你可以在 Stata 命令行输入about查看版本号。如果是 Stata 16 或更早，MCP 调用会失败，这一点没有绕过的办法。

第二，uv 工具。uv 是一个 Python 包管理和运行工具，MCP-for-Stata 通过uvx命令启动。如果你还没装，在 PowerShell 或命令提示符里执行：

pip install uv

装完后验证一下：

uvx --version

能输出版本号就说明可用。如果提示uvx不是内部或外部命令，检查 Python 的 Scripts 目录是否在 PATH 里。

第三，WorkBuddy 的项目目录权限。WorkBuddy 需要在授权范围内读取本地文件，所以你要提前确定一个研究项目目录，比如D:\my_research_project，并确保 WorkBuddy 有该目录的读写权限。后面配置里的STATA_MCP__CWD就指向这个目录。

关于 TaoToken 的接入，如果你打算用 API 方式调用模型对话或 Coding Plan 来辅助生成 Stata 脚本，可以先去官网了解接入方式。TaoToken 提供模型对话、Coding Plan、控制台和 API Keys 等入口，适合需要长期跑 Agent 任务的场景。具体地址在文末 CTA 部分给出，这里先聚焦 Stata MCP 本身的配置。

环境确认清单可以对照下面这张表：

3. 可复制配置：uv 启动命令与 settings.json 片段

这一节是全文的核心，给出从诊断到 MCP 服务器注册的完整步骤。我试过在 Windows 环境下走一遍，下面命令和配置可以直接复制，路径按你自己的实际情况改。

3.1 运行环境诊断

先跑一次诊断，确认 Python、uv、Stata 可执行文件、工作目录和运行权限都没问题：

uvx stata-mcp doctor

诊断结果会逐项列出检查状态。如果提示找不到 Stata，进入下一步显式指定路径。注意，原有的--usable参数已经弃用，不要再用它作为安装命令。

3.2 指定 Stata 可执行文件路径

如果诊断报告提示找不到 Stata，用config set写入路径：

uvx stata-mcp config set cli "C:\Program Files\Stata19\StataMP-64.exe" uvx stata-mcp doctor

上面的路径只是 Windows 示例，你要根据自己实际安装的版本和位置调整。当前使用的环境变量名称是STATA_CLI，不是STATA_PATH，写错会导致 MCP 启动时找不到 Stata。

3.3 在 WorkBuddy 中注册 MCP 服务器

进入 WorkBuddy 侧边栏的「插件」→「MCP 服务器」→「配置 MCP」，粘贴以下 JSON：

{ "mcpServers": { "stata-mcp": { "command": "uvx", "args": ["stata-mcp"], "env": { "STATA_CLI": "C:\\Program Files\\Stata19\\StataMP-64.exe", "STATA_MCP__CWD": "D:\\my_research_project" } } } }

这里有两个关键字段。STATA_CLI指向 Stata 可执行文件，STATA_MCP__CWD指向允许 MCP-for-Stata 工作的项目目录。JSON 里的反斜杠要转义成双反斜杠，这是 Windows 路径在 JSON 中的写法，漏掉转义会导致解析失败。

用户级配置保存在~/.workbuddy/mcp.json，项目级配置可以放在<项目目录>/.workbuddy/mcp.json。如果你希望不同研究项目用不同的工作目录，用项目级配置更合适。

3.4 重启并检查连接状态

保存配置后重启 WorkBuddy，在 MCP 服务器列表里确认stata-mcp显示为已连接。如果显示连接失败，按下面的顺序排查：

先确认uvx在命令行里能直接运行；再检查STATA_CLI路径是否指向真实存在的 exe 文件；然后看 JSON 转义是否完整，特别是路径里的反斜杠；最后确认STATA_MCP__CWD指向的目录存在且有写入权限。这四步能覆盖大部分连接失败的情况。

4. 验证请求：从文献变量到触发 Stata 回归

配置完成后，不要急着跑正式回归，先用一个小任务验证整条链路是否通。验证思路是：让 WorkBuddy 从文献卡片里提取变量清单，生成一个最小 do-file，通过 Stata MCP 执行，然后读取日志确认结果。

4.1 文献卡片与变量提取

先把 PDF 放入papers/literature/文件夹，然后给 WorkBuddy 一个带约束的任务描述：

请处理 papers/literature/ 文件夹中的 PDF，生成可核验的文献索引。 1. 先列出文件清单，无法读取或内容重复的文件单独标记。 2. 每篇生成一张文献卡片，包括研究问题、数据与样本、识别策略、主要结论。 3. 每项判断必须附上来源文件名和页码，找不到依据时写「未定位到原文」。 4. 输出 literature_index.md 和 literature_verification.md。

这套约束的关键是让结论可追溯。文献卡片生成后，你可以从中提取出核心变量，比如被解释变量、核心解释变量和控制变量，作为回归脚本的输入。

4.2 生成最小 do-file 并执行

假设文献卡片里提取出的变量是wage、education、experience，让 WorkBuddy 生成一个最小回归脚本：

* minimal_regression.do use "data/clean/survey_2020.dta", clear reg wage education experience

然后通过 Stata MCP 触发执行。WorkBuddy 会把这段代码写入 do-file，调用本地 Stata 运行，再读取日志。如果链路通了，你会在返回结果里看到回归系数、标准误和样本量。

4.3 成功结果的判断标准

一次成功的端到端验证，应该满足三个条件：do-file 被正确写入项目目录；Stata 日志里出现回归输出表格；WorkBuddy 能把日志内容回读并展示给你。如果只看到代码生成但没有日志返回，说明 MCP 调用环节有问题，回到第 3.4 节排查连接状态。

验证通过后，你就可以把文献整理、数据诊断和回归执行串成一条自动化流程。比如让 WorkBuddy 每晚检查新增文献，更新变量清单，然后跑一轮基准回归。定时任务能否在关机或锁屏时执行，取决于具体版本和运行设置，正式使用前先用一个测试文件确认触发条件。

5. 本篇常见错排查：Stata MCP 连接与执行问题

配置和使用过程中，下面这几类错误出现频率最高，逐个说清楚原因和解决办法。

错误一：uvx: command not found。说明 uv 没装好或者 Scripts 目录不在 PATH 里。重新执行pip install uv，然后检查 Python 安装目录下的 Scripts 文件夹是否加入了系统环境变量。

错误二：MCP 服务器显示已连接但调用 Stata 时报「找不到可执行文件」。这是STATA_CLI路径写错或 JSON 转义不完整导致的。打开mcp.json，确认路径里的反斜杠都是双写，并且指向的 exe 文件真实存在。可以用Test-Path命令验证路径。

错误三：do-file 执行后没有日志返回。先确认STATA_MCP__CWD指向的目录有写入权限，再检查 do-file 里的数据路径是否用了项目相对路径。如果数据文件不在工作目录下，Stata 会报「file not found」，日志里会有明确提示。

错误四：回归结果与手动运行不一致。检查 do-file 里是否显式设置了随机种子，以及样本筛选条件是否与手动操作一致。MCP 执行的是你生成的脚本，脚本逻辑错了，结果自然对不上。

错误五：WorkBuddy 读取文献 PDF 时部分文件标记为无法读取。这通常是 PDF 加密或扫描件没有文字层导致的。把这类文件单独放到一个文件夹，手动处理后再纳入索引。

排查时有一个通用原则：先看日志，再看配置，最后看代码。Stata 的日志会告诉你哪一行出错，MCP 的连接状态会告诉你工具是否可用，代码逻辑则决定结果是否正确。三者分开定位，比盲目改配置高效得多。

6. 把链路固定下来：长期编码与 Agent 任务的接入建议

一次配置成功之后，真正影响效率的是能不能稳定复现。我的建议是把项目级mcp.json纳入版本管理，这样换机器或重装环境时，配置可以直接复用。文献卡片、数据诊断报告和 do-file 都放在项目目录下，用相对路径引用，避免绝对路径带来的迁移问题。

如果你需要长期跑 Agent 任务，比如每晚自动更新文献索引、定期跑稳健性检验，可以考虑用 TaoToken 的 Coding Plan 来支撑模型调用。模型对话入口适合临时验证脚本逻辑，Coding Plan 适合需要持续执行的编码和 Agent 场景。API Keys 和接入文档在控制台里可以找到，配置方式和普通 API 调用一致。

具体入口如下：

• 模型对话：https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=model-chat
• Coding Plan：https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=coding-plan
• 控制台：https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=console
• API Keys：https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=api-keys
• 接入文档：https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=doc
• ClaudeCode Anthropic：https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=claudecode-anthropic

最后提醒一点：AI 可以发现数据问题、执行清洗规则、跑回归，但不能替研究者决定样本口径和识别策略。sample_flow.csv 和日志不是附属品，而是复现「原始样本如何变成分析样本」的必要记录。把这条链路固定下来之后，你省下的是复制粘贴和切换窗口的时间，该做的判断一个都不能少。