mesalogo
06c1123caa
The Skills catalog exposed nine product-marketing recipes as independent capabilities and enabled every marketing package for every Runtime by default. It now keeps five top-level Skills, loads the nine recipes on demand through the product-marketing package, and leaves the three marketing Skills disabled until users enable them. Existing saved Skill settings remain authoritative. Release note: 内置 Skills 已从 14 个顶层入口精简为 5 个；去 AI 味和长文工具默认启用，产品营销类默认停用，已保存的用户设置保持不变。
324 lines
11 KiB
Markdown
324 lines
11 KiB
Markdown
# 工具执行环境 User Stories
|
|
|
|
## 文档信息
|
|
|
|
| 项目 | 内容 |
|
|
| --- | --- |
|
|
| 状态 | 计划 |
|
|
| 版本 | 0.2 |
|
|
| 日期 | 2026-09-01 |
|
|
| 关联 PRD | [工具执行环境 PRD](./prd.md) |
|
|
| 关联逻辑 | [工具执行环境功能逻辑设计](./logic-design.md) |
|
|
|
|
## 1. 角色
|
|
|
|
### 1.1 普通用户
|
|
|
|
希望直接使用文档、演示文稿或数据处理 SKILL，不理解 Node.js、Python、pip 或 PATH。
|
|
|
|
### 1.2 MCP 使用者
|
|
|
|
希望配置一个本机工具服务，并由 GoodBuddy 解决其基础解释器启动问题。
|
|
|
|
### 1.3 专业开发者
|
|
|
|
已有明确的 Node、Python、虚拟环境或 Conda 环境，希望控制实际版本和绝对路径。
|
|
|
|
### 1.4 内网与离线用户
|
|
|
|
无法稳定访问公网，需要使用选定镜像或离线准备环境，同时不向远程 Host 传播本机配置。
|
|
|
|
## 2. Epic A：普通用户无需预装环境
|
|
|
|
### US-A0 首次看到准确默认状态
|
|
|
|
作为普通用户，我希望第一次打开设置时看到 GoodBuddy 已提供什么、还需要安装什么，以免
|
|
误以为所有工具都已就绪。
|
|
|
|
验收：
|
|
|
|
- 全新安装默认选择 GoodBuddy 托管 Node 和 Python
|
|
- 托管 Node 立即执行真实诊断并显示版本
|
|
- 未安装的托管 Python 显示“尚未安装”和安装入口
|
|
- 检测到的系统解释器只作为自定义候选，不改变默认来源
|
|
- “工具执行环境”Tab 持续说明只对新启动的本机 Runtime 和 stdio MCP 生效
|
|
|
|
### US-A1 直接使用托管 Node
|
|
|
|
作为普通用户，我希望安装 GoodBuddy 后即可使用 Node.js SKILL，以免单独安装 Node.js。
|
|
|
|
验收：
|
|
|
|
- Given 系统 PATH 没有 Node.js
|
|
- When 本机 Execute 请求运行普通 JavaScript SKILL
|
|
- Then `node` 使用 GoodBuddy 托管来源
|
|
- And `npm`、`npx` 与该 Node 来源一致
|
|
- And 设置显示实际 Node 版本
|
|
|
|
### US-A2 按需安装 Python
|
|
|
|
作为普通用户，我希望在设置中安装 Python，以便运行 Python SKILL 而不离开 GoodBuddy。
|
|
|
|
验收：
|
|
|
|
- Given 系统没有 Python 且托管 Python 未安装
|
|
- When 用户点击安装
|
|
- Then 页面显示下载、校验和安装进度
|
|
- And 成功后真实 Python、pip、venv 诊断通过
|
|
- And 失败不会留下半安装目录
|
|
|
|
### US-A3 看懂缺失依赖
|
|
|
|
作为普通用户，我希望区分“没有 Python”和“缺少 python-pptx”，以便采取正确修复操作。
|
|
|
|
验收：
|
|
|
|
- 工具解释器不可用时显示工具环境错误
|
|
- 解释器可用但能力包缺失时显示能力依赖错误
|
|
- 页面不把 `python --version` 成功描述为 SKILL 已完全可用
|
|
- 错误保留原任务和可执行的下一步
|
|
|
|
### US-A4 看懂部分就绪
|
|
|
|
作为用户，我希望知道解释器可用但配套命令损坏，以免把所有失败都理解为没有安装环境。
|
|
|
|
验收：
|
|
|
|
- Node 可用而 npm/npx 失败时显示“部分可用”和具体失败项
|
|
- Python 可用而 pip、venv 或 SSL 失败时显示“部分可用”和具体失败项
|
|
- 不依赖失败项的能力仍可通过实际诊断标记就绪
|
|
- 没有能力专属诊断时显示“依赖未验证”，不推断为就绪
|
|
|
|
## 3. Epic B：本机 MCP 使用一致环境
|
|
|
|
### US-B1 启动 Python MCP
|
|
|
|
作为 MCP 使用者，我希望 `python -m my_mcp_server` 使用设置中的 Python，以免配置第二套
|
|
解释器。
|
|
|
|
验收：
|
|
|
|
- 裸 `python`、`python3` 和 `pip` 解析到当前选择
|
|
- Main 直连工具链和本机 Runtime 使用相同来源
|
|
- 绝对命令路径不被替换
|
|
- MCP 自身包缺失时准确报告依赖错误
|
|
|
|
### US-B2 启动 Node.js MCP
|
|
|
|
作为 MCP 使用者，我希望 `node server.js` 或 `npx package` 使用同一 Node 组合。
|
|
|
|
验收：
|
|
|
|
- `node`、`npm`、`npx` 来源一致
|
|
- npm lifecycle 子进程使用当前 Node
|
|
- 取消或关闭应用后没有遗留 MCP 进程
|
|
|
|
### US-B3 保持网络 MCP 不变
|
|
|
|
作为 MCP 使用者，我希望 HTTP/SSE MCP 不受本机解释器设置影响。
|
|
|
|
验收：
|
|
|
|
- HTTP/SSE 配置不显示本机解释器要求
|
|
- GoodBuddy 不管理远端 MCP 服务端依赖
|
|
- 切换工具执行环境不重建 HTTP/SSE 服务
|
|
|
|
## 4. Epic C：专业用户明确控制环境
|
|
|
|
### US-C1 使用检测到的系统解释器
|
|
|
|
作为专业开发者，我希望从版本和绝对路径列表中选择解释器，以便使用已有工具链。
|
|
|
|
验收：
|
|
|
|
- 候选经过真实版本和架构诊断
|
|
- 相同真实路径不重复显示
|
|
- 保存后状态显示实际生效来源
|
|
- PATH 后续变化不会自动替换选择
|
|
|
|
### US-C2 指定项目虚拟环境
|
|
|
|
作为专业开发者，我希望选择未被自动发现的 Python，以便使用自己的 venv 或 Conda 环境。
|
|
|
|
验收：
|
|
|
|
- 文件选择由 Main 管理
|
|
- 保存前验证 Python 3、版本和架构
|
|
- GoodBuddy 不安装、升级或删除该环境
|
|
- 路径失效时不静默回退
|
|
|
|
### US-C3 返回托管环境
|
|
|
|
作为专业开发者，我希望随时切回 GoodBuddy 托管环境，以便恢复标准组合。
|
|
|
|
验收：
|
|
|
|
- 切换前显示新启动进程才生效
|
|
- 新 Runtime 和 stdio MCP 使用托管来源
|
|
- 已运行进程不中途换环境
|
|
|
|
### US-C4 明确设置何时生效
|
|
|
|
作为专业开发者，我希望知道环境切换何时影响进程，以免一个运行中的任务突然换解释器。
|
|
|
|
验收：
|
|
|
|
- 保存前后都说明只对新启动进程生效
|
|
- 有活动请求的 Runtime 保持启动时环境
|
|
- 空闲 Runtime 在下一次使用前按现有入口重建
|
|
- 已启动 stdio MCP 在关闭、重连或显式测试后使用新环境
|
|
- 活动记录不根据最新设置改写历史解释器来源
|
|
|
|
## 5. Epic D：范围和生命周期可理解
|
|
|
|
### US-D1 不影响远程主机
|
|
|
|
作为远程项目用户，我希望清楚知道本机环境不会上传到 Host，以免错误预期远程脚本可用。
|
|
|
|
验收：
|
|
|
|
- “工具执行环境”Tab 显示范围说明
|
|
- 远程主机设置页显示本机 Skills 和 MCP 不适用
|
|
- Host PATH、Agent 包和 Runtime 包不包含本机选择
|
|
|
|
### US-D2 删除托管 Python
|
|
|
|
作为用户，我希望删除不再使用的托管 Python，以便释放磁盘空间。
|
|
|
|
验收：
|
|
|
|
- 删除前说明受影响的本机 SKILL 和 MCP
|
|
- 只删除 GoodBuddy-owned Python 目录
|
|
- 不删除系统、自定义或工作区文件
|
|
- 使用中的进程先按现有生命周期停止
|
|
|
|
### US-D3 升级后保持既有解释器
|
|
|
|
作为现有用户，我希望升级 GoodBuddy 后已有脚本仍使用原来的系统解释器。
|
|
|
|
验收：
|
|
|
|
- 首次迁移把有效系统解释器保存为自定义绝对路径
|
|
- 无有效解释器时才选择托管来源
|
|
- 迁移结果只写一次
|
|
|
|
### US-D4 取消 Python 安装
|
|
|
|
作为用户，我希望可以取消耗时的 Python 安装，并在之后重试。
|
|
|
|
验收：
|
|
|
|
- 下载、校验、安装和候选诊断阶段都响应取消
|
|
- 取消后清理本次暂存
|
|
- 取消不发布未验证候选
|
|
- 页面回到操作前的未安装状态或健康旧版本
|
|
- 取消不显示为安装失败
|
|
|
|
### US-D5 安全更新托管 Python
|
|
|
|
作为用户，我希望更新托管 Python 失败时仍能使用旧版本，以免现有能力全部中断。
|
|
|
|
验收：
|
|
|
|
- 下载和验证候选期间旧版继续服务已有进程
|
|
- 应用更新前说明需要停止哪些本机 Runtime/MCP
|
|
- 用户确认后才通过现有生命周期停止相关进程
|
|
- 无法停止时不替换当前版本
|
|
- 候选完整诊断成功后才发布
|
|
- 更新失败继续使用健康旧版本
|
|
|
|
### US-D6 安装解释器不扩大 Ask 权限
|
|
|
|
作为 Ask 用户，我希望安装 Node/Python 后仍保持原有只读边界，以免环境准备改变授权范围。
|
|
|
|
验收：
|
|
|
|
- 工具环境不新增 Runtime 工具
|
|
- Ask 是否允许命令仍由当前 Runtime 边界决定
|
|
- Ask 中禁止的写入和执行不会因解释器存在而放行
|
|
- Execute 继续使用用户已授权的本机账号权限
|
|
|
|
## 6. Epic E：受限网络与离线行为明确
|
|
|
|
### US-E1 通过所选官方来源安装 Python
|
|
|
|
作为内网用户，我希望在“工具执行环境”Tab 中选择原生地址或 OSS 镜像，以便符合当前
|
|
网络条件。
|
|
|
|
验收：
|
|
|
|
- 默认使用 Python 工件的固定原生地址
|
|
- 选择 OSS 后，Python 只请求固定 OSS 对象
|
|
- 页面显示本次下载冻结的来源和准确失败原因
|
|
- 同一次安装不在原生地址和 OSS 之间静默切换
|
|
- 失败保留健康旧版本或未安装状态
|
|
|
|
### US-E2 完全离线时使用已有环境
|
|
|
|
作为完全离线用户，我希望清楚知道首期可用路径，以免等待一个无法完成的下载。
|
|
|
|
验收：
|
|
|
|
- 托管 Node 安装后可离线使用
|
|
- 托管 Python 未缓存且来源不可达时明确说明无法下载
|
|
- 首期不展示未实现的 Python 离线导入入口
|
|
- 用户可以选择设备上已经离线安装的自定义 Python
|
|
|
|
### US-E3 所有受管工具工件遵循同一下载通道
|
|
|
|
作为用户，我希望未来新增的受管 Runtime 和工具链遵循同一个下载源选择，以免每种工具
|
|
产生不同规则。
|
|
|
|
验收：
|
|
|
|
- 受管工具目录中的每个外部工件同时声明原生地址和 OSS Target
|
|
- 两个 Target 对应相同字节数和 SHA-256
|
|
- 下载任务开始后冻结来源
|
|
- 所选来源缺少该工件时明确显示不可用
|
|
- pip/npm 依赖、模型、应用更新、Agent 和用户 URL 不受该设置影响
|
|
|
|
## 7. Epic F：统一管理能力与执行环境
|
|
|
|
### US-F1 从一个入口管理相关能力
|
|
|
|
作为用户，我希望从一个设置入口访问 Skills、MCP 和工具执行环境，以便理解能力配置及其
|
|
本机依赖之间的关系。
|
|
|
|
验收：
|
|
|
|
- 设置中心只显示一个“能力与工具”一级分类
|
|
- 第一阶段依次显示 `Skills`、`MCP` 两个水平 Tab
|
|
- 工具执行环境完成后在同一组中追加第三个 `工具执行环境` Tab
|
|
- 未完成前不显示禁用或占位的 `工具执行环境`
|
|
- 首次进入默认打开 `Skills`
|
|
- 每个 Tab 使用独立、可命名的 `tabpanel`
|
|
- 水平 Tab 支持方向键、Home、End 和可见焦点
|
|
- 窄屏时页签保持单行横向滚动，不换成多行或下拉框
|
|
|
|
### US-F2 保持业务数据和编辑状态
|
|
|
|
作为现有用户，我希望合并设置导航后原有 Skills 和 MCP 配置保持不变，并且切换水平 Tab
|
|
不丢失正在编辑的信息。
|
|
|
|
验收：
|
|
|
|
- 原独立 Skills/MCP 左侧分类由一个“能力与工具”分类替代，不保留重复入口
|
|
- 合并导航不修改 Skill 启停、导入、分配或 MCP 配置、凭据和分配数据
|
|
- MCP 原有内部分组页签继续位于 MCP 面板内
|
|
- 切换三个外层 Tab 后返回时保留本次设置面板会话中的编辑状态
|
|
- 关闭并重新打开设置时，普通入口仍默认显示 Skills，不持久化上次外层 Tab
|
|
- 未来新增 Skills/MCP 定向入口时打开对应水平 Tab
|
|
|
|
### US-F3 聚焦默认内置能力
|
|
|
|
作为普通用户，我希望默认只加载通用文档工具，不让低频产品营销说明占用每次会话的上下文。
|
|
|
|
验收：
|
|
|
|
- Skills 列表只把五个具备独立入口或执行器的内置能力显示为顶层 Skill
|
|
- 产品营销的九种文档配方从 `product-marketing` 内部按需读取
|
|
- `deai-writing` 和 `longdoc-docx` 在没有保存状态时默认启用
|
|
- 三个产品营销 Skill 在没有保存状态时默认停用
|
|
- 用户显式保存的启停状态和 Runtime 分配不因版本升级而重置
|
|
- 用户导入的 Skill 继续使用现有默认启用和 Runtime 分配规则
|