Guessor 项目设计报告 PUBLIC EDITION // BETA 1

文档说明

文档版本：Beta 1（公开精简版）
最后更新：2026 年 9 月
品牌归属：Nexabox 旗下 AI 品牌，与牵引力工作室合作（官网 nexabox.de，QQ 群 621482061）
说明：本文由内部完整设计报告精简而成。为保证可读性与信息节奏，完整版中仍在验证与打磨的部分没有收录在公开版本中； 已公开的内容也会随版本迭代调整，均不构成对外承诺。

精简范围

未被收录不代表不存在。它们属于产品正在打磨的部分，会在能力稳定、表达清晰之后再进入公开文档。

一、项目概述

1.1 一句话定义

Guessor 是 Nexabox 旗下的 AI 品牌，与 牵引力工作室合作 推出的 面向普通消费者的桌面 Agent 软件：用户通过 模板 把可复用的能力交给 Agent， 通过 应用空间 让它长期管理一个项目，通过 工作台 让它直接操作电脑完成即时任务。

1.2 三个核心模块

模板     = 给 Agent 能力
应用空间 = 给 Agent 长期项目
工作台   = 给 Agent 一双手

1.3 明确不做什么（反模式清单）

以下内容在产品中不出现，也不在后续开发中引入：

• 不新增与「模板 / 应用空间 / 工作台」并列的第四个核心模块。
• 不做 Agent 开发平台：不暴露编排、节点连线、多角色协作配置。
• 不做可视化工作流编辑器：用户不需要画流程图来让 Agent 干活。
• 不做多智能体平台：用户视角始终只有「一个 Agent 在帮自己」。
• 不做 Skill 管理器：产品层面不出现 Skill、Prompt、Tool 等术语。
• 不做企业级 Agent 管理：不做组织 / 审批流 / 权限矩阵后台。
• 不做通用渲染框架：动态应用固定一条路线，报告固定一条路线。

以上限制只针对用户界面与用户认知层。底层实现中的技术概念只出现在代码、日志与内部文档中。

1.4 支撑功能（不是核心模块）

设置、模型配置、更新、帮助、日志查看属于支撑功能，在导航中放在次级位置， 不作为与三大模块并列的入口，避免用户在认知上把它们当成第四个模块。

二、产品背景与目标

2.1 背景问题

现有 AI 产品对普通消费者存在四类明显断点：

2.2 产品目标

主目标：让没有技术背景的用户，可以在 5 分钟内让 Agent 具备一项可复用能力， 并在一个长期项目里持续协作，最终拿到一个能展示、能运行、能交付的成果。

• 能力可复用：创建或导入模板后，后续任务中 Agent 的表现明显稳定且符合预期。
• 项目可延续：第二天打开应用空间，Agent 依然知道项目是什么、做到哪一步、下一步做什么。
• 操作可执行：Agent 能在用户授权下真实创建、修改、运行本机文件与程序。
• 成果可交付：项目能一键生成可运行的动态应用或可分享的报告。

2.3 成功指标

2.4 设计边界（非目标）

• 不追求「什么都能做」的通用 Agent 平台。
• 不追求多人协作、团队空间、云端同步（Beta 1 为单机本地）。
• 不追求覆盖全部操作系统能力，只覆盖普通消费者高频场景：文件、Python、程序运行、浏览器、文档处理。

三、产品定位

3.1 定位公式

Guessor = 可复用的 Agent 能力（模板）
        + 长期存在的项目环境（应用空间）
        + 真实操作电脑的执行能力（工作台）

3.2 与相邻产品形态的区别

3.3 用户价值链条

拥有能力（模板）
   ↓
进入项目（应用空间）
   ↓
持续工作（对话 + 文件 + 记忆）
   ↓
直接执行（工作台 + 工具）
   ↓
生成成果（动态应用 / 报告）

产品所有界面、文案、流程都必须服务于这条价值链条，任何偏离这条链条的功能都应被削减。

四、核心设计理念

4.1 用户语言优先

用户看到的词必须是日常词汇：模板、项目、文件、对话、运行、预览、导出、报告。 禁止出现在界面上的词：Skill、Tool、MCP、Prompt、Embedding、Agent Loop、Context Window、Runtime、Function Calling、Token。

4.2 一切围绕「项目」而不是「对话」

对话是手段，项目是主体。判断一个设计是否合理，用这条标准：

如果用户关掉软件再打开，他能不能一眼看到「我的项目现在是什么状态」？不能满足这条的设计，一律重做。

4.3 能力一次配置，长期复用

模板是能力的载体。用户配置一次，之后所有项目、所有会话都可以调用，不需要重复解释规则。

4.4 能看见的执行

Agent 在做任何实际动作（创建文件、运行命令、启动服务、修改系统）时，界面必须实时展示：

• 正在做什么（动作 + 目标）
• 结果是什么（成功 / 失败 / 摘要）
• 失败了会怎么处理（重试 / 修复 / 请你决定）

用户不应该面对一个「转圈但不知道在干什么」的黑盒。

4.5 渐进披露

• 默认视图只显示最重要的三件事：项目内容、对话、结果。
• 高级信息（执行日志、环境配置、模型选择、文件历史）藏在「详情 / 更多」里。
• 普通用户不需要打开任何高级面板就能完成主流程。

4.6 本地优先与可解释

• 项目文件存放在用户本机，用户能直接打开文件夹查看。
• 模板是纯文本，用户可以自己打开读、自己改、自己备份。
• Agent 的记忆与摘要以 Markdown 形式落盘，用户可以查看和纠正。

4.7 危险操作必须有人在场

默认策略是「读自由、写确认、危险必问」。用户随时可以把某个动作升级为「以后都允许」， 也可以随时撤销授权。

五、用户群体与场景

5.1 用户画像

5.2 用户共同特征

1. 不会（也不愿）学习 Agent 技术概念。
2. 希望用自然语言表达目标，而不是配置参数。
3. 对「能不能直接看到结果」极其敏感。
4. 对「它动了我电脑上的东西」有天然警惕，需要清晰的确认与撤销。

5.3 六个核心场景

场景之间的组合关系是：模板是横切能力，应用空间与工作台是两个不同的工作场地，工作台可以为空间服务。

5.4 非目标用户

• 需要复杂多智能体编排的团队。
• 需要企业级权限、审计、合规后台的组织。
• 希望把本产品当成 Agent 开发框架使用的工程师。

这类用户可以使用底层能力，但产品不为他们的高级诉求扩展界面。

六、三个核心模块

6.1 模板：让 Agent 学会一件事

对用户来说，模板就是「一份事先写好的工作说明书」。把它交给 Agent，它就知道这类事情该怎么做、按什么规则做、输出成什么样。

首发内置示例模板方向：Python 开发、演示文稿制作、写作、数据分析、学习、网站开发。

使用入口：模板列表的「使用」按钮；应用空间输入框上方的模板标签；工作台输入框上方的模板标签。

界面约束：只有「模板」一个词，只有新建、导入、编辑、使用四个操作概念； 不要求用户填写参数、触发条件等技术字段。

没有模板也能使用全部三个模块。模板是增强能力，不是前置条件。

6.2 应用空间：我的项目

应用空间的核心不是「聊天」，而是「长期项目」。用户可以在这里创建一个项目，然后长期与 Agent 协作，直到项目结束。

空间首页要回答的问题

打开项目先看到什么，是产品「不是聊天窗口」的最直接证据：

• 这个项目要做什么（目标）
• 现在做到哪一步（进度与状态）
• 建议的下一步是什么（可直接点击继续）
• 最近改了什么、有哪些文件

空间内页

左到右依次是文件树与内容预览、Agent 对话区，底部是一个横跨全宽的输入框；顶部固定「生成」与设置入口。

项目状态与生命周期

文件与撤销

• 项目文件统一放在空间自己的目录里，用户可以直接用系统文件管理器打开查看。
• 元数据、记忆与历史单独存放，不干扰用户的文件视图。
• 每一轮回复涉及的文件改动合并为一个快照，用于「撤销这一轮做的事」。
• 删除进入回收目录，不做物理删除。

6.3 工作台：现在替我做这件事

工作台是 Agent 的即时工作环境：一次任务的场地，而不是长期项目。

一句话区分：应用空间是「把它做完」，工作台是「把它做了」。

能力范围

• 文件操作：读取、整理、转换、批量重命名
• Python 执行：数据处理、脚本、计算
• 程序运行：调用本机命令行工具、运行脚本
• 浏览器操作：打开页面、抓取公开信息、填写表单
• 文件处理：PDF、表格、文档、图片、压缩包
• 自动化操作：批处理与重复性工作
• 系统环境操作：环境变量、进程查看（需要较高权限等级）

三条设计重点

1. 每一环都可见：用户能看到调用的动作、作用的位置、结果如何。
2. 每一环都可中断：用户可以随时停止，已完成的动作保留并记录。
3. 每一环都可追溯：所有执行写入操作记录，能回答「它到底改了哪些文件」。

空状态引导

新用户第一次进入时展示可直接点击的示例任务：整理一个文件夹、把多个文件合并成一份、分析一个表格、查找并整理资料。点击只填入输入框，不自动执行。

七、成果生成

7.1 定位

「生成」不是第四个模块，而是应用空间的一种输出能力： 根据当前项目生成一个可展示、可使用的成果。

动态应用 = 可以运行、可以交互的页面应用
报告     = 完整、可分享的单文件页面

7.2 选择指南

界面上一句话总结：要能操作，选动态应用；要能展示，选报告。

7.3 共同流程

点击生成 → 选择类型（动态应用 / 报告）
  → 分析当前项目（文件、状态、已确认的决定）
  → 给出内容计划（先给用户看，可调整）
  → 用户确认 → 生成文件 → 校验
  → 预览 → 用户可以继续让它修改

「内容计划」是给用户看的中间步骤，而不是让用户配置参数。例如它会说明打算做哪几个页面、数据来自哪里、预计生成多少文件。

7.4 与项目的关系

• 生成物独立存放，不放进用户的项目文件里，避免污染项目内容。
• 生成物可以读取项目文件，但只读引用。
• 每次重新生成产生新版本，用户可以在预览页切换查看。
• 生成能力必须校验后再交付：宁可多花几秒，也不要让用户看到打不开的结果。

八、权限与安全

8.1 权限模型

权限判断同时考虑三件事：目录范围（读 / 写）、能力类型（文件 / Python / 命令 / 浏览器 / 系统）、动作风险等级（低 / 中 / 高）。

8.2 授权粒度

8.3 默认策略

8.4 撤销与恢复

8.5 用户可见的安全表达

安全机制必须用日常语言表达，而不是把技术术语丢给用户：

权限确认只回答三个问题：它想做什么、影响是什么、能不能撤销。

九、版本范围与路线

9.1 Beta 1 目标

用最小功能集合验证核心假设：普通用户能否通过「模板 → 应用空间 → 工作台 → 生成成果」 这条链路，真实完成一件对自己有价值的事？

9.2 Beta 1 主要能力

9.3 Beta 1 暂不包含

• 账号体系与云同步
• 团队协作与权限管理后台
• 模板市场与分享链接
• 插件 / 扩展体系
• 定时与自动化任务
• 多设备协同

9.4 后续规划（概要）

规划原则：任何新功能都必须能归入模板 / 应用空间 / 工作台三者之一，或属于支撑功能。

9.5 一句话的最终产品形态

用户打开 Guessor
  → 让它学会一件事（模板）
  → 建一个项目，长期和它一起做（应用空间）
  → 需要动电脑时让它直接动手（工作台）
  → 最后拿到一个能运行的应用，或一份能分享的报告

十、相关链接

• Nexabox 工作室官网（nexabox.de）
• Guessor 官网页（AI）
• 项目中心
• 文档中心
• GitHub
• 联系我们
• Nexabox 研发群：QQ 群号 621482061（QQ 搜索群号即可加入）