事情是这样的。
我自己在用 AI 写网页、改工具、整理运营思路的时候，经常会遇到一个很烦的小问题。想法在一个窗口里，Prompt 在另一个窗口里，Claude Code 又在命令行里，跑完之后还要再想办法把结论沉淀下来。
单看每一步都不难。
但连起来就很碎。碎到最后，人不是卡在能力上，而是卡在切换上。
所以我做了这个本地工作台。它不是为了证明我搞了一个多大的系统，而是想把一个很真实的工作流先跑顺，写目标，拆任务，生成 Prompt，交给 coding agent，观察 token 负载，再把关键输出留下来。
作品页里展示的是表层能力。真实的本地路径、账号配置、密钥、日志和完整实现细节，我都不会公开。这个边界我觉得挺重要的，工具可以拿来展示能力，但不应该把自己的工作现场整个摊开。
这个作品想证明什么
我想证明的不是我会做一个很炫的页面。
更准确地说，我想证明自己能把一个模糊但真实的痛点，拆成界面、流程和可运行的工具。
AI 工作流不是只有模型能力，还有任务怎么拆，Prompt 怎么递，代码怎么落地，结果怎么复盘，以及 token 怎么别被浪费掉。
操作演示截图
以下截图来自本地演示环境，内容已做脱敏处理，只用于展示产品形态和工作流能力。
核心能力预览
- 多 Agent 工作台，把 Hermes、GPT/ChatGPT、Claude Code 的分工放到同一个操作界面。
- 任务流管理，从一个目标开始，往下拆成拆解、扩展、落地、复盘几个动作。
- Token 意识，展示 prompt 负载、Claude 本地使用量和上下文压缩建议。
- 本地优先，核心控制台跑在本机，更适合个人工具、内部工作流和隐私敏感场景。
- 可持续扩展，后面可以继续接 Obsidian、项目日志、自动日报、截图分析和更多本地 agent。
为什么不直接公开在线试用
坦率地讲，这个工具现在更像一个个人 AI 工作驾驶舱，不是面向所有访客开放的 SaaS 产品。
它依赖本地已经安装好的 CLI、账户权限和个人工作目录。你可以把它理解成一个工作现场的控制台，而不是一个人人点开就能直接使用的公网服务。
所以作品页只展示能力和产品思路。我能把真实工作痛点转成界面、流程和可运行工具。具体接入方式、密钥、日志和个人数据，应该留在本地。
适合证明的能力画像
我能设计并搭建面向真实工作流的 AI 工具，不只是做一个看起来像工具的页面。
我能把 AI、前端界面、本地自动化和运营/内容工作流揉到一个可用产品里。
我适合 AI 工具型产品、Web Coding、运营自动化、AI 工作流助理相关岗位或项目合作。