企业官网建设流程全解析

WorkBuddy 这名字，最近在 AI 编程助手圈子里有点火。我一开始以为它只是 CodeBuddy 换了个皮肤，结果实际用下来发现，它真正拉开差距的地方在于两点：一是对 Skill（技能）机制的深度打磨，二是对 MCP（模型上下文协议）的完整支持。这俩能力叠在一起，WorkBuddy 就不光是个聊天生成代码的工具，而是一个能按你的工作流定制的自动化执行框架。

这篇文章我不打算写官方文档那种面面俱到的说明，而是直接从这三件最硬核的事情入手：怎么把它顺利装到你能长期用的环境里；怎么从零写一个真正能干活的自定义 Skill；以及怎么开发、调试一个接入 WorkBuddy 的 MCP Server。顺便会把我在 Linux 服务器上踩过的坑、接口联调时的坑、以及 Skill 调试时那些文档里不会明说的细节一并交代清楚。

1. 安装与本地部署：别急着双击安装包

1.1 跨平台安装的“真实面貌”

WorkBuddy 官方宣传支持 macOS、Windows 和 Linux，但这里有个实际体会：桌面端和纯命令行端是完全两种体验。如果你主要做前端调试、需要可视化看板，那么 macOS 或 Windows 客户端会更顺手；如果目标是部署在服务器上做无人值守的自动化任务，那么建议直接用它的命令行模式或本地服务模式。

我在一台 Ubuntu 20.04 的服务器上实测过，流程大致是：

# 拉取安装脚本，这里注意别用 sudo 直接跑 curl -fsSL https://workbuddy.example.com/install.sh -o install_workbuddy.sh bash install_workbuddy.sh --local # 验证安装，启动后能看到 CLI 交互界面 workbuddy --version

这里有个很关键的细节：安装脚本默认会往全局目录写入，但如果你是在共享服务器上，建议加--local参数，否则很容易碰到权限问题，而且未来升级时会污染公共环境。我遇到过的情况是，用 root 装完后，普通用户执行workbuddy直接提示command not found，排查半天发现 PATH 没刷新。解决办法是重新登录会话，或者手动把安装目录追加到~/.bashrc里。

Windows 端的安装相对傻瓜一些，但要注意一点：WorkBuddy 的 Skill 执行引擎核心是 Node.js 和 Python 混合的，所以提前装好 Python 3.10+ 和 Node.js 18+ 是必须的。如果电脑上已经装了 Anaconda，记得把环境变量理顺，否则 WorkBuddy 会莫名其妙地选错 Python 解释器。

1.2 本地服务模式的配置细节

日常用桌面客户端当然直观，但如果你的场景是需要通过 API 调用的（比如在 Jenkins 流水线里跑代码审查），那就要把 WorkBuddy 作为本地服务跑起来：

workbuddy serve --port 8080 --host 0.0.0.0

然后通过 HTTP 请求就可以交互了：

curl -X POST http://localhost:8080/v1/chat \ -H "Content-Type: application/json" \ -d '{"message": "帮我看下这个项目里的 TODO 注释"}'

这种模式的好处是你将获得一个稳定的后端能力入口，前端可以随便换。在实际项目中，我甚至用 Python 的requests库封装了一个简单的调度器，定时把 GitHub Issue 拉下来丢给 WorkBuddy 做分类，再自动打标签。效果很理想，而且完全不需要打开一个 GUI 窗口。

注意：如果要在公网服务器上开启0.0.0.0监听，一定要在防火墙层面限制来源 IP，或者用 API Key 做鉴权。WorkBuddy 默认是没有鉴权机制的，裸奔在公网等于给黑客留后门。这一步极容易踩坑。

1.3 关于“WorkBuddy 使用教程那么多，为什么还是装不上”的共性原因

热搜词里有一大堆“WorkBuddy 安装教程”“WorkBuddy 怎么使用”，这说明安装确实拦住了不少人。结合我自己的经验，安装失败的场景大概可以归为以下几类，贴在下面给各位当速查表：

排查思路其实很简单：先用workbuddy doctor查看环境诊断报告，再逐项对照处理。很多时候不是安装包坏了，而是和已有环境打架。

2. 核心概念梳理：Skill 和 MCP 到底是什么

2.1 用“点菜”和“厨师”来理解 Skill

Skill 直译过来是技能，但它在 WorkBuddy 里的定位其实更像一套可复用的预设行为模板。打个比方：你到一个餐厅，直接跟厨师说“按我上次的口味做一桌菜”，厨师需要回忆你上次吃了什么；如果你直接递给他一张菜单卡片，上面写着“少辣、多蒜、不要香菜”，他看一眼就能执行，效率完全不同。WorkBuddy 的 Skill 就是这张菜单卡片。

从实现角度来说，一个 Skill 通常包含三部分：一个描述文件（用来告诉 WorkBuddy 这个技能是什么、何时触发），一组脚本或提示词（真正的执行逻辑），以及可选的依赖资源（比如数据文件、模板等）。这套设计让“告诉 AI 做什么”变成“告诉 AI 按什么标准做”，后者在复杂任务里效果稳定得多。

我在实际项目里用到一个很典型的例子：代码审查 Skill。它会在 WorkBuddy 收到 PR 描述时自动触发，按“安全性、性能、可读性、潜在 Bug”四个维度输出检查结论，并且每个维度附上代码引用。相比直接用聊天框丢一句“帮我 review 一下”，Skill 让输出质量相当稳定。

2.2 MCP 不是“又一个插件系统”

MCP，全称 Model Context Protocol，中文翻译成模型上下文协议。这个词最近搜索量飙升，因为它试图解决一个根本问题：怎么让 AI 模型安全、受控地获取外部数据或操作外部工具。

过去我们想给 AI 加工具，通常是写插件，这个过程很依赖平台自身定义的接口；换一个平台，插件就废了。MCP 的思路则是在模型和工具之间加一层“标准 USB 接口”——只要工具实现了 MCP 协议，那么任何支持 MCP 的客户端就都能直接调用它。WorkBuddy 把 MCP 作为头等公民支持，这让它的生态兼容性比很多封闭式助手要高很多。

用生活场景类比：以前的插件就像各种不同形状的充电头，每个设备都得配一个专属线；MCP 则是统一了 Type-C 接口，出门只需要带一根线。开发者只需要按照 MCP 规范去写一个 Server，接入过程就是标准的握手与调用，省去了大量适配工作。

2.3 Computer Use 与 MCP 的边界

热词里有人搜“computer use 和 mcp 的区别”，这个问题我一度也很困惑。后来在实际使用中理清了：Computer Use 强调的是 AI 直接操作屏幕上的元素（模拟鼠标键盘、截图、看界面上有什么），它更偏向“视觉+操作”；而 MCP 强调的是通过结构化接口去读写数据（查数据库、调 API），它更偏向“逻辑+数据”。

两者其实是互补关系。WorkBuddy 对 Computer Use 的支持主要用于 UI 自动化测试场景，比如自动打开浏览器、定位按钮、点击并验证跳转；而 MCP 则承担了更底层的工具调用。理解了这个边界，你就知道在什么场景下该用哪种方案了——如果需要驱动界面就找 Computer Use，如果是获取数据、执行复杂逻辑，MCP 是优先级更高的选择。

3. 自定义 Skill 开发：从闲聊式 AI 到流程化执行

3.1 Skill 目录结构与最小可运行示例

WorkBuddy 的 Skill 本质上是一堆文件放在一个目录里。官方推荐的目录结构大概是这样的：

my-first-skill/ ├── SKILL.md ├── scripts/ │ └── run.py └── assets/ └── template.json

最小的可运行 Skill 其实只需要一个SKILL.md。这个文件是技能的核心描述，WorkBuddy 会在运行技能时读取它，理解你要干什么。来看一个我实际用过的例子：

--- name: todo_extractor description: 从任意文本中提取待办事项并生成结构化清单 version: 0.1.0 author: your_name trigger: 包含“生成待办”或“提取 todo”等指令时触发 --- # 任务目标 将用户输入文本中的所有待办事项提取出来，输出为 markdown 格式的 checkbox 列表。 # 执行步骤 1. 提取文本中所有含“需要”“必须”“记得”等关键词的句子。 2. 对每个候选句子去重并规范化表达。 3. 按优先级分为“高、中、低”三档。 4. 输出为 markdown 格式。 # 输出格式 - [ ] [高] 待办事项描述 - [ ] [中] 待办事项描述

写完这个文件后，把它放到~/.workbuddy/skills/todo_extractor/目录下，重启 WorkBuddy，新 Skill 就会被自动识别。你可以直接在对话里说“帮我从这段会议纪要里生成待办”，WorkBuddy 就会按SKILL.md里的步骤执行。

这里有一个很重要的心得：Skill 的核心不是脚本，而是“对执行路径的约束”。脚本只是实现方式，真正让 AI 回到稳定输出的，是你把步骤明确写进了描述文件里。

3.2 用脚本增强 Skill 的执行能力

纯文本的 Skill 只能靠大模型的推理能力“临场发挥”，但如果任务涉及精确计算、文件操作或者访问外部 API，就应该挂载一个可执行脚本。WorkBuddy 支持在 SKILL.md 中声明脚本调用方式，然后在任务执行时自动调起。

举个例子，我写过一个处理日志文件的 Skill，它需要从一堆 Nginx 日志中统计状态码分布。这种任务如果靠大模型逐行读文本，又慢又费 token。我的做法是写一个 Python 脚本来做统计，Skill 只负责把文件路径传给它。

# scripts/analyze_log.py import sys import collections from pathlib import Path def analyze(file_path: str): counter = collections.Counter() with open(file_path, "r", encoding="utf-8") as f: for line in f: # 典型的 nginx 日志格式: IP - - [time] "METHOD url HTTP/x" status size parts = line.split() if len(parts) >= 9: status = parts[8] counter[status] += 1 return dict(counter) if __name__ == "__main__": file_path = sys.argv[1] result = analyze(file_path) for status, count in sorted(result.items()): print(f"{status} {count}")

然后在 SKILL.md 里加上：

# 执行方式 当用户提供日志文件路径时，运行以下命令并解析输出： python3 scripts/analyze_log.py {user_file_path}

这样做的好处很明显：统计过程零幻觉，结果 100% 可复现。我在多次实战中体会到，一个“文本约束 + 脚本兜底”的 Skill，远比纯粹靠 AI 推理的 Skill 可靠。

3.3 调试 Skill 的实战技巧

Skill 调试在 WorkBuddy 里往往被新手忽略，因为它的报错信息不算友好。我的经验是：先用 WorkBuddy 单独跑“解析 SKILL.md”的流程，判断描述文件有没有语法问题；再针对脚本部分单独在终端里执行，确认脚本本身没问题；最后才让两者联调。

日志查看也是关键。WorkBuddy 的日志文件一般位于：

~/.workbuddy/logs/

如果 Skill 跑挂了，去这里翻日志是最靠谱的定位方式。最常见的问题是脚本权限不足，或者引用的相对路径不对。WorkBuddy 执行 Skill 时的工作目录和你的项目目录往往不一致，所以写脚本时建议统一用绝对路径，或者基于环境变量动态拼接。

还有一个非常容易被坑到的地方：SKILL.md 里如果用了相对路径引用脚本，一定要加上scripts/前缀，并且确保你的脚本有可执行权限。

chmod +x scripts/run.py

不然 WorkBuddy 会一直报“无法执行脚本”，而你又检查不出语法问题。

3.4 让 Skill 支持多轮交互

优秀的 Skill 不是“一次性问答”，它应该能支持多轮上下文。WorkBuddy 允许在 SKILL.md 中定义状态变量，让技能在多次对话之间保持记忆。

比如我写过一个“周报生成器” Skill，它会先问用户本周做了哪几类工作，然后记录到一个临时状态文件里，下一轮再问“各项具体产出是什么”，最后统一汇总成周报。逐步收集信息的方式，可以让复杂任务拆解得更自然，用户也不会面对一个空泛的“请描述你本周所有工作”而发呆。实现上其实只是在 SKILL.md 里声明了state_file字段，然后在脚本中读写 JSON 状态文件。这个设计让我对 Skill 的认知又上了一个台阶：它不只是一个命令，更像一个“有记忆的小助手”。

3.5 Skill 创作的高级思路：从“能跑”到“好用”

从“能跑”到“好用”，关键区别在于 Skill 的设计思路。我见过很多人写的 Skill 本质上就是把一段提示词塞进 SKILL.md，然后告诉 WorkBuddy“执行”。这种 Skill 可用，但效果不稳定。

进阶思路是：先定义输出规范，再设计执行路径。举个例子，一个数学建模类的 Skill（热词里有“数学建模skill”），如果只是告诉 AI“帮我搞定数学建模”，那它输出什么完全不可控；但如果你在 SKILL.md 里规定好了“必须包含问题分析、模型假设、符号说明、模型构建、求解算法、灵敏度分析、结果评价”七个模块，并且明确每个模块的字数和图表要求，那么生成质量就会呈指数级提升。

WorkBuddy 里还有一个概念叫“Impeccable Skill”，你可以把它理解成“经过充分打磨、在多数场景下都能稳定产出高质量结果的 Skill”。这类 Skill 通常具备几个特征：触发条件明确、执行步骤粒度适中、每一步的输出格式有约束、并且预留了错误处理分支。我从实践中得出的结论是：写好一个 Skill 的投入产出比非常高，一次创作，长期受益，团队内还能互相复用。

4. MCP 开发实战：Agent 的“万能插座”

4.1 梳理 MCP 协议的关键流程

MCP 的开发相比 Skill 更偏工程化，它本质上是一个基于 JSON-RPC 的通信协议。理解和开发 MCP Server 需要抓住三大组成部分：

• 客户端（Client）：比如 WorkBuddy，它发起请求、接收结果。
• 服务器（Server）：你实现的外部工具服务，比如数据库查询、文件读取、第三方 API 调用。
• 协议层（Protocol）：规定了双方如何握手、如何请求、如何响应、如何处理错误。

通信流程可以用一个时序逻辑来描述：客户端启动后，先向 Server 发送initialize请求，带上一组客户端能力信息；Server 返回自身支持的协议版本和能力列表；随后双方进入工作状态，客户端通过tools/call等方法来调用 Server 提供的具体工具。

注意：MCP 协议本身是语言无关的，理论上任何语言都能实现。但官方 SDK 对 Python 和 TypeScript 的生态支持最完善，我个人的建议是：如果团队后端偏 Python，优先用 Python 写 MCP Server；如果偏前端，就用 TypeScript。

4.2 从零写一个最小可运行的 MCP Server

下面这个示例是用 Python 实现的一个最小 MCP Server，功能是提供“查询当前时间”工具。虽然功能简单，但结构完整，可以当作模板直接套用：

import asyncio import datetime from mcp.server import Server, StdioServerTransport # 伪代码示例，以实际 SDK 为准 from mcp.types import Tool, TextContent app = Server("time-server") @app.list_tools() async def list_tools(): return [ Tool( name="get_current_time", description="返回服务器当前时间，格式为 ISO 8601", inputSchema={ "type": "object", "properties": { "timezone": { "type": "string", "description": "可选时区，如 Asia/Shanghai", } }, }, ) ] @app.call_tool() async def call_tool(name: str, arguments: dict): if name == "get_current_time": tz = arguments.get("timezone", "UTC") now = datetime.datetime.now(datetime.timezone.utc) return [TextContent(type="text", text=f"{now.isoformat()} ({tz})")] async def main(): transport = StdioServerTransport() await app.connect(transport) await app.wait() if __name__ == "__main__": asyncio.run(main())

这里说明一下，不同版本的 MCP SDK 在装饰器名称和参数形式上可能略有差异，上面的写法是贴近官方 Python SDK 风格的通用模板。实际开发时直接查阅对应版本的 SDK 文档，替换成准确的函数签名即可。

注意 Server 的通信模式：使用StdioServerTransport时，WorkBuddy 会通过标准输入输出和你的 Server 进程通信。这意味着不要在这个进程里随便 print 调试信息，print 的内容会污染协议通道，导致 WorkBuddy 解析失败。调试时请使用日志文件而不是 stdout。

4.3 WorkBuddy 里配置自定义 MCP Server

写好了 Server，下一步就是把它接进 WorkBuddy。在 WorkBuddy 的配置文件里，通常可以这样声明一个 MCP Server：

{ "mcpServers": { "time-server": { "command": "python3", "args": ["/path/to/time_server.py"], "env": {} } } }

加完后重启 WorkBuddy，然后在对话中尝试调用。如果你看到 WorkBuddy 能正常返回当前时间，说明链路已经通了。

这里有一个我在实际接入时反复被折磨的要点：MCP Server 必须保持进程常驻。如果某个 API 调用导致 Server 崩溃，WorkBuddy 会瞬间“断开连接”，之后所有工具调用都会失败。所以 Server 里必须要有完善的异常捕获机制，外部 API 超时要重试，内部逻辑要 try...except 兜底，必要时在主循环里加入重启逻辑。

4.4 典型实战场景：把数据库查询能力交给 MCP

MCP 的真实价值在复杂工具接入时最能体现。我团队内部做过一个实验：让 WorkBuddy 通过 MCP Server 直接查询业务数据库。Server 的伪代码逻辑是这样的：

import sqlite3 import json def query_database(sql: str): # 只允许 SELECT 语句，防止注入 sql = sql.strip() if not sql.upper().startswith("SELECT"): raise ValueError("Only SELECT statements are allowed") conn = sqlite3.connect("business.db") cursor = conn.cursor() try: cursor.execute(sql) columns = [desc[0] for desc in cursor.description] rows = cursor.fetchall() return {"columns": columns, "rows": rows} finally: conn.close()

把这类工具挂到 MCP 上后，WorkBuddy 就可以像使用普通工具一样查询数据。用户只需要用自然语言问“上个月销量最高的三个产品是什么”，WorkBuddy 就会自动生成 SQL → 调用 MCP 工具 → 获取结果 → 输出自然语言答案。这个流程省掉了大量人工写 SQL 的时间，同时通过 MCP Server 层做了 SQL 白名单与权限控制，安全性方面也有保证。

4.5 远程设计工具类 MCP 的接法参考

热词里“蓝湖 MCP”“MasterGo MCP”“Figma 插件 open figma MCP”频繁出现，说明设计提效也是一个热门方向。这类 MCP 的典型价值是：让 AI 助手能读取设计稿的元素、节点信息甚至导出标注，而不需要设计师手动贴图。

我尝试过接入一个设计稿解析类的 MCP Server，它的思路很简单：通过设计工具的开放 API 拉取画布 JSON 数据，然后汇总成结构化描述喂给大模型。接入流程与上述方法一致，差别仅在于 Server 内部调用的是设计工具 API。这类 MCP 的核心难点不在协议，而在于设计稿数据量通常很大，动辄几万甚至几十万个节点，如果不做裁剪和摘要，很容易超出模型上下文窗口。我的做法是在 MCP Server 内部预先做一层信息压缩，只返回当前画布中“可见且非隐藏、包含有效文本或组件名”的节点摘要。

这里也顺带回应一下热词里“unity mcp”“blender mcp”“cocoscreator mcp”这类游戏引擎相关需求：基本原理完全一样，MCP 只是通道，真正的功夫花在如何把引擎的复杂对象模型映射成大模型能理解的简洁描述上。这个映射做得好，工具就实用；映射做得敷衍，就会出现“工具能连上，但回答全是废话”的情况。

5. 综合工作流实战：把 Skill 和 MCP 串起来

5.1 设计一个“自动化日报生成”系统

单个 Skill 和单个 MCP 都解决的是单点问题，真正有杀伤力的是把它们组合成一个完整工作流。我举一个自己跑通了很久的例子：自动化日报生成系统。

整个系统的分工是这样设计的：

• 一个定时器每天下午 5 点调用 WorkBuddy API。
• WorkBuddy 先触发一个名为git_activity的 Skill，让它拉取当天 Git 提交记录。
• 提交记录获取过程里，WorkBuddy 通过一个 MCP Server 去访问 Git 仓库的数据（相当于把git log的能力封装成 MCP 工具）。
• 拿到提交记录后，另一个 Skill（summary_writer）按“今日改动模块、关键提交、明日计划”的结构，生成一段日报文本。
• 日报写完后，WorkBuddy 再调用团队内部的通知 API（同样做成 MCP 工具），把日报推送到企微群。

这套链路跑起来后，团队每天的周报和日报效率提升非常明显，而且完全不需要人工介入。

5.2 工作流中参数传递的注意事项

跨 Skill 和 MCP 组合时，最容易被忽略的是参数传递。WorkBuddy 在执行 Skill A 时产生的中间结果，默认是不会自动传给 MCP 工具的；你需要显式地在 Skill 描述里定义“最终输出”，然后在下一个 Skill 或工具调用时引用。

我的经验是把中间结果写到一个固定目录的 JSON 文件里，下一个 Skill 再去读。这个做法的好处是每个环节都能单独排查问题，不会出现“整个链路失败但不知道挂在哪一步”的窘境。

比如在日报工作流里，git_activitySkill 会把处理后的提交记录保存为：

~/.workbuddy/tmp/daily_report_git.json

然后summary_writerSkill 开头就读取这个文件。这样每步的产物都是可见的，排查问题也方便很多。

5.3 避坑提醒：Token 消耗与上下文膨胀

组合工作流跑起来后，你会发现 Token 消耗以肉眼可见的速度飙升。根本原因是多轮工具调用会把大量中间结果塞进上下文。我在实践中采用的策略是：禁止让 AI 把原始 JSON 大段复制进回复，而是让脚本预先完成聚合与摘要，AI 只负责最后一步的文字润色和结构组织。

另外，在设计 MCP 工具时，强烈建议给每个工具加上“分页参数”或“limit 参数”，从源头控制返回数据量。例如查询数据库的工具，默认加上LIMIT 50；读取文件列表的工具，默认只返回最近 20 条。这些细节能帮你省下不少成本，而且响应速度明显更快。

6. 常见问题与排查技巧实录

6.1 WorkBuddy 找不到新加的 Skill

这个现象非常普遍：你明明把 Skill 放进了对应目录，重启后 WorkBuddy 还是不认。检查项按优先级排列：第一，目录名称是否使用了中文或特殊符号，WorkBuddy 对 Skill 目录名有规范性要求，最好只用小写字母、数字、下划线；第二，SKILL.md文件是否真的在这个目录最外层，不要嵌套第二层；第三，重启是否完全彻底，有些版本需要退出托盘图标才算完全退出。

6.2 MCP Server 启动失败，WorkBuddy 连不上

首先确认 Server 本身能不能独立运行：在终端里直接执行启动命令，看看会不会报语法错误或者缺少依赖。然后用一个简单的客户端测试工具（官方 SDK 往往自带测试命令）去连接 Server，判断问题出在 Server 还是 WorkBuddy 配置。

其中一个坑来自环境变量：WorkBuddy 启动 MCP Server 时，不一定继承你~/.bashrc里的所有配置。如果你的 Python 路径、Node 路径写在~/.bashrc里，而 WorkBuddy 是 GUI 启动的，就可能出现“终端里能跑，WorkBuddy 里连不上”的现象。稳妥做法是把 MCP Server 的启动命令写成绝对路径，或者在配置里直接传env。

6.3 Skill 脚本报错，但日志没有有效信息

WorkBuddy 默认的日志级别可能是 INFO，不会把 Python 的 traceback 完整记录下来。这个问题可以通过设置环境变量来调高日志级别：

export LOG_LEVEL=DEBUG workbuddy serve --port 8080

此外，在脚本里主动写日志到文件也是好习惯。我习惯在脚本开头加一段日志配置，输出到/tmp/my_skill.log，这样调试时直接tail -f看实时输出，比看 WorkBuddy 的日志高效得多。

6.4 模型输出的“幻觉”问题

即使有 Skill 约束，也不能完全避免大模型在某些开放式任务上“自由发挥”。要缓解这个问题，最直接的办法是把输出格式约束得足够死。比如在SKILL.md里明确写出“最终输出必须包含三个 section，并且每个 section 以 H3 标题开头”，甚至给出一个精确的 Markdown 模板，要求 AI 直接把内容填入。越具体的格式约束，越能压低幻觉发生的概率。

7. 关于 WorkBuddy 生态的几点个人思考

WorkBuddy 目前的状态还处于快速迭代期，Skill 的生态远没有到繁荣的程度，MCP Server 的质量也参差不齐。但我觉得它已经抓住了 AI 编程工具的下一个方向：从“会聊天”到“会干活”，从“单点工具”到“可组合的工作流”。如果你正在观望要不要深入研究，我给的建议是趁早上手。尤其是 MCP 这个协议，哪怕将来你不再用 WorkBuddy，这套开发能力也能平移到其他支持 MCP 的客户端上，属于“一次学习，长期受益”的投资。

最后再分享一个小技巧：写 Skill 和 MCP 的时候，一定要有“给别人用”的心态。Skill 的描述文件里，把触发场景、使用限制、输出规范写得越清楚越好；MCP Server 的代码里，把错误信息写得越具体越好。因为半年后你回头看自己写的工具，大概率会忘了当时的上下文；文档和注释是你唯一能求助的“同事”。