输入框不该是一面空白墙
大多数 AI 工具只给你一个空白文本框，然后让你自己记住助手具备哪些能力。它能浏览网页吗？能安排定时工作吗？能记住项目事实吗？能绘制图表吗？能调用 MCP 服务器吗？答案往往都是能，但界面把这些能力藏在口口相传的经验和少数人才知道的快捷键背后。
Onevium 选择了相反的做法。在输入框键入 @，可用的工作界面就会作为一份简单的工具菜单出现：Widget、Browser、Schedule、Channel、Skill、Memory、Agent、MCP、Plugin 和 Files。这不是为了装饰，而是要在你编写任务的那一刻，让每项能力都能被发现。
这一点很重要，因为真实工作很少止于一段模型回复。产品经理需要图表和发布文案，开发者需要浏览器冒烟测试和代码补丁，创始人希望每天早上把定时竞品扫描发送到团队渠道。@ 菜单把这些变成可以组合的工作模块，而不是一组彼此割裂的应用。
用直白的话解释每一种工具
这份菜单刻意使用用户语言，而不是实现术语。每一行都在回答用户写提示时自然会有的问题：我希望 Onevium 完成的是哪一种工作？
- Widget — 创建图表、界面稿、SVG 图形、流程图、类似 draw.io 的图示和小型应用。当答案应该可视、可检查或可复用时使用。
- Browser — 打开、检查、点击和自动操作网页。适用于 QA、竞品研究、数据看板、表单、文档，以及任何只存在于真实浏览器会话中的内容。
- Schedule — 创建定时任务、提醒、周期检查和报告。适用于希望稍后执行或重复执行，而无需再次打开会话的工作。
- Channel — 连接钉钉、飞书或 Discord 机器人。当结果应进入团队讨论，而不是埋在本地聊天记录里时使用。
- Skill — 创建可复用的项目工作流与指令。当你厌倦了反复解释同一套流程时使用。
- Memory — 保存长期有效的上下文、决策、偏好和项目事实。当助手需要把经验延续到后续会话时使用。
- Agent — 为委派工作创建专注的子 Agent。当一条长任务应该拆给多个专门角色时使用。
- MCP — 连接工具、API、文件和数据源。当 Onevium 需要桌面内置功能之外的能力时使用。
- Plugin — 安装包含 Skill、工具和工作流的功能包。当你希望获得一整套新能力，而不想逐项手动搭建时使用。
- Files — 搜索并附加项目文件。当所需上下文已经在仓库里，助手需要先阅读再行动时使用。
为什么菜单要放在输入框里
单独做一页工具中心更容易开发，却更难使用。你真正需要工具的时刻，正是你在组织请求的时候。把菜单留在输入框里，才能从意图直接进入执行，而不会打断思路。
这也改变了用户学习产品的方式。你不必先读完手册才能安排一套工作流，只需输入 @、扫一眼这些动作，再选择工作形态。界面会在你已经开始做事时，自然地教会你有哪些能力。
对团队而言，这能减少“只有老手才知道”的隐性门槛。新成员可以在同一个入口发现定时运行、渠道机器人、记忆、浏览器自动化和 MCP 连接；熟练用户也从这里调用它们。能力依然强大，却不再躲在配置页面深处。
使用 @ 菜单的一天
假设你正在准备一次发版。先用 @Files 附上 changelog 和发布说明，请 Onevium 起草公开公告；再用 @Widget 把功能列表整理成对比图；用 @Browser 打开预发布站点并走完新手引导；用 @Schedule 创建一条第二天早上检查下载链接的提醒；最后通过 @Channel 把最终摘要发到发布群。
这套流程并非科幻，而是人们已经在浏览器、笔记应用、设计工具、日历和团队聊天之间手动完成的同一组动作。不同之处在于，Onevium 把工作保留在一个可见界面中，并让模型在你选择的权限模式下操作合适的工具。
@ 菜单是思考与执行之间的交接点。你仍然用自然语言写指令，但指令不再被困在一个只能聊天的世界里。
为什么它关系到信任
只有当用户能看见接下来会发生哪类操作时，自治工具才真正好用。隐藏的工具调用会让人意外，主动选择 @ 工具则意味着明确意图。选择 Browser、Schedule、Channel 或 MCP 时，你在模型开始行动前就已经为任务规定了形态。
因此，这份菜单与 Onevium 的权限模式选择器天然配合。可信的本地工作可以使用完全访问；敏感任务可以切换到更严格的批准方式；涉及外部系统时，则采用更审慎的设置。模型获得能力，用户保有控制。
这正是 Onevium 的产品理念：给 AI 真正的工具，让工具始终可见，同时让用户离执行过程足够近，随时理解正在发生什么。