我们真正想做的不是另一个聊天窗口

今天很多 AI 编程产品的核心体验仍然停留在对话：用户描述目标，AI 在后台执行一串命令，然后把结果用文字解释出来。这对一次性问题足够，但对真实工作流来说还不够。真实工作流里有项目上下文、运行时状态、权限边界、版本更新、设计规范、截图验证和一堆需要反复执行的本地动作。

One Works 的目标，是把这些动作从“每次都靠对话重新解释”变成“可以被 AI 使用、组合、复用和展示的工具”。AI 不应该永远只是在命令行里跑脚本，它应该能在需要的时候为自己做一个插件，为用户提供一个页面、一个按钮、一个表单、一个预览或一个可追踪的执行流程。

所以我们关心的不是把界面做得更热闹，而是建立一套让 AI 可以稳定工作的产品结构：插件系统负责能力扩展，标准化 design 负责交互一致性，运行时和配置系统负责让这些能力在本地安全地落地。

插件系统是 AI 工具的承载层

插件不是简单的菜单入口。对 One Works 来说，插件是一种把能力交给 AI 和用户共同使用的封装方式。一个插件可以包含前端入口、服务端命令、本地文件操作、外部 API、运行状态、配置项和权限声明。它既可以被用户点击，也可以被 AI 在任务中调用。

当某个流程开始反复出现时，AI 就不应该每次都重新拼命令。它应该能把流程沉淀成插件：比如检查模块更新、展示 changelog、生成本地预览、整理项目资产、驱动某个 adapter，或者把某个业务数据做成一个可交互页面。

插件系统的价值在于它给 AI 一个稳定的“工具货架”。AI 不是临时发明动作，而是在明确的 manifest、API、权限和 UI 容器里工作。用户也不用相信一段不可见的后台操作，而是能看到插件暴露出来的界面、状态和结果。

标准化 design 是人和 AI 的协作协议

如果 AI 每次生成界面都自由发挥，最后会得到很多风格割裂、交互不一致、难以维护的页面。One Works 需要的是一套标准化 design：按钮什么时候只用图标，什么时候显示 tooltip；列表如何组织；header actions 放在哪里；更新前怎么确认；进度、错误、空状态和详情页如何呈现。

这套 design 不是为了限制创造力，而是为了让 AI 生成的工具可以被用户立刻理解。统一的布局、间距、图标、状态和信息层级，会让“AI 做出来的工具”看起来像产品的一部分，而不是临时拼出来的调试面板。

对 AI 来说，design 规范也是一种可执行的约束。它减少决策噪音，让 AI 在实现功能时不用重新猜测页面骨架；对用户来说，它让新工具拥有稳定的预期：在哪里检查状态、在哪里确认动作、在哪里查看详情、哪里可以取消或回退。

AI 给自己做工具，而不是只给用户生成代码

我们希望 AI 能逐步具备“发现工具缺口”的能力。比如它在排查问题时发现某个日志每次都要手动过滤，下一次就可以生成一个日志面板；它在做 release 时发现版本、tag、changelog 和截图总是重复检查，就可以生成一个 release helper；它在管理模块更新时发现用户需要先看变更内容，就可以生成一个更新确认页。

这和传统插件市场不完全一样。传统插件通常由人提前规划和发布，而 One Works 希望让 AI 在具体工作流中发现真实需求，再把它沉淀为可复用的工具。这个工具可以先服务当前任务，后续再变成团队共享的能力。

这要求插件既要容易创建，也要容易验证。AI 生成工具后，应该能启动本地服务、打开页面、截图验证、补充 changelog，并把关键行为写进文档或规则里。这样工具不是一次性产物，而是可以继续演进的工程资产。

展示给用户的应该是交互，不只是日志

很多自动化失败不是因为 AI 不会执行，而是因为用户看不懂它正在执行什么。下载新版本应该有进度，更新模块前应该能看到 changelog，涉及界面变化应该能看到截图，配置变更应该能知道写到了全局还是 workspace。

One Works 的产品方向是把这些中间过程变成可视化交互。AI 可以在后台调用工具，但用户应该在前台看到清楚的状态：可用更新、受影响模块、变更摘要、确认按钮、失败原因、重试入口和最终结果。

这也是为什么我们把更新确认、模块管理、下载详情、博客文章和文档入口都当成产品界面来做。它们不是装饰，而是 AI 和用户之间的协议层。AI 负责推进任务，界面负责让用户能理解、确认和接管。

边界必须清楚

让 AI 给自己做工具，并不意味着让 AI 绕过用户控制。相反，越是自动化，边界越要清楚。插件需要声明能力，配置需要有层级，危险动作需要确认，发布和更新需要可追踪的 changelog，涉及界面变化需要截图，涉及本地执行需要明确权限。

我们希望 AI 能主动把这些边界做进工具里：不是偷偷修改配置，而是在合适的页面展示；不是直接安装更新，而是先展示变更内容；不是把失败写进一串日志，而是把失败转成用户能理解的状态。

这让 One Works 更像一个本地工作台，而不是一个远端黑盒。用户保留最终控制权，AI 则负责把重复劳动、信息整理和工具构建尽量自动化。

接下来要建立的基础能力

这些基础能力都指向同一个目标：让 AI 不只是写代码，而是能在一个受控、可见、可维护的环境里，为自己和用户持续构建工具。

• 让插件的 manifest、前端入口、服务端命令和配置项更容易由 AI 生成和验证。
• 把页面设计规范沉淀成稳定组件和规则，减少每次新增页面时的样式偏差。
• 让工具生成后自动补齐使用说明、changelog、截图和基础验证结果。
• 让模块更新、adapter、runtime、桌面端和 Web 入口共享同一套状态展示方式。
• 让用户可以在界面里管理 AI 生成的工具：启用、禁用、更新、查看权限和回滚。