Typecho MCP Workbench 开发手记 04：localhost 只是原型，真正目标是本地人类工作台

上一篇写到 MCP 工具层：AI 不应该直接拿 SSH 或数据库，而应该通过一组有语义、有策略、有快照、有审计的本地工具来操作博客。

到这里，项目已经有了一条比较清晰的秩序：先预览，再保存；先检查，再发布；先快照，再回滚；先记录，再排查。

这篇想继续往人类端推进一步：当前的 localhost Web UI 能证明方向，但它不是终点。真正的目标，是一个类似 Obsidian 或 Typora 的本地人类工作台。

Typecho MCP Workbench 当前工作台

Typecho MCP Workbench 从 localhost 原型演进为本地桌面写作工作台

localhost 能跑通链路，但不能回答日常使用问题

http://127.0.0.1:4783 对早期开发非常好。

前端可以直接改，后端 API 可以直接接，CLI、MCP、Web UI 都能复用同一套 local-ops。出问题时，打开浏览器、看控制台、看请求日志，很快就能知道链路断在哪里。

但 localhost 页面只能回答一个工程问题：这条链路能不能跑通。

它还没有回答一个更日常的问题：我明天、下周、半年后，愿不愿意每天打开它写东西？

写作不是一次性的调试动作。它有草稿、素材、上下文、窗口布局、快捷键、预览习惯、发布前焦虑，以及出了问题之后必须能快速排查的安全感。长期使用时，人更希望打开的是一个稳定的本地工作空间，而不是“某个还开着的浏览器标签页”。

所以这一步的判断是：Web UI 是很好的 renderer 原型，但产品形态不能停在浏览器里。

这不是普通后台，也不是自动发布按钮

如果只是为了管理文章，Typecho 官方后台已经能做很多事情。这个项目并不是要把官方后台换个皮肤重新做一遍。

普通后台的中心是“人点按钮管理内容”。

Typecho MCP Workbench 的中心是“AI 准备，人类审阅，人类授权，本地记录”。

这两种心智模型差别很大。

普通后台关心 CRUD 页面：新建、编辑、删除、设置、保存。

这个工作台更关心一次操作是否可预览、是否有快照、是否被策略允许、失败后是否可诊断、事后能不能追踪。

普通后台默认远端是主场：登录后台，修改远端状态。

这个项目默认本地控制面是主场：SSH、缓存、审计、快照、策略、Debug Bundle 都留在本地；远端 Typecho 尽量轻，只接受窄而明确的 agent 调用。

所以它更像一台本地写作驾驶舱。AI 可以整理、生成、检查、准备；人类负责判断、取舍、确认和追责。

为什么最终应该像 Obsidian / Typora

写作软件和管理后台的感觉不一样。

Obsidian 或 Typora 给人的感觉是“我的本地工作空间”。它们有稳定的窗口、熟悉的快捷键、文件和草稿的归属感、长期沉淀的布局偏好。你打开它，不是在“登录一个系统”，而是在回到自己的写作现场。

Typecho MCP Workbench 也应该往这个方向靠。

它需要承载的不只是一个编辑框：

  • 本地草稿和远端文章之间的同步状态。
  • AI Agent 准备好的修改建议和发布报告。
  • 保存前的 Diff Preview。
  • 发布前的 Prepare / Review / Confirm。
  • 回滚前的 Snapshot Preview。
  • 媒体、图床、文件床和未来 asset provider。
  • request log、audit log、debug bundle。
  • 多站点 profile、窗口布局、命令面板、系统菜单和快捷键。

这些东西如果都塞进一个后台页面，就会越来越像“按钮堆叠”。但如果按本地工作台设计，它们可以变成稳定的信息架构。

本地桌面工作台布局设想

工作台空间应该怎样组织

我现在更倾向于把界面拆成几个长期稳定的区域。

顶部栏放站点、host、同步状态、命令面板入口和全局状态。

左侧 Activity Bar 不直接堆功能按钮，而是切换工作模式：Content、Review、Media、Operations、Site、Settings。

Sidebar 服务当前模式。写文章时，它是文章列表和筛选器；看媒体时，它是素材来源和资产分组；排查问题时，它是日志和诊断入口。

主区域永远优先给写作和审阅。Markdown editor、Preview、Diff、Snapshot Review 都应该在这里发生。

右侧 Inspector 放 metadata、slug、tags、categories、publish context、snapshot context、policy context。它不应该打断正文，而应该像一个随时可看的上下文抽屉。

底部 Operations Panel 放 request log、diagnostics、audit、cache、debug bundle。这些东西很重要，但不应该抢走写作主场。

底部状态栏则负责低噪音地显示 host、cache freshness、selected post、dirty state、prepare state、last operation ID 和 policy state。

这套布局已经在现在的 Web Workbench 里切出了第一版：Activity Bar、Writing/Split/Preview、Inspector、Operations Panel、Status Bar、Publish Review Sheet。它还不完美，但方向已经从“调试页面”转向“桌面工作区”。

写作模式

发布确认面板

发布不是一个按钮，而是一段可解释流程

这一点是工作台区别于普通后台的关键。

发布不应该只是一个蓝色按钮。

它应该是一段可解释的流程：

Prepare
  -> 检查标题、slug、正文、分类、标签、图片链接、当前状态

Review
  -> 展示 blockers、warnings、images、external links、diff、freshness

Confirm
  -> 展示 Operation Policy、risk、host、post、snapshot 行为、audit 行为

Result
  -> 展示 post URL、snapshot ID、operation ID、audit event、rollback 入口

发布流程不是按钮

prepare_publish 是 AI 和人类之间的一次安全握手。

AI 可以把文章准备好，可以告诉你标题是否为空、slug 是否合理、图片链接是否可访问、正文有没有明显问题。但 warning 是否可接受，最终应该由人判断。

同样，rollback 听起来像安全动作，但它也是一次真实写操作。它会把远端文章恢复到某个历史快照。如果没有看清楚当前版本和目标快照之间的差异，回滚本身也可能造成内容丢失。

所以发布和回滚都应该从“一次 confirm”升级成应用内 Review/Confirm。人类在确认之前能看到足够上下文，确认之后能拿到 operation ID、audit event 和回滚入口。

Diff、Snapshot、Policy、Audit、Debug 是同一条信任链

这些能力单独看都不复杂。

Diff Preview 解决“我将要改什么”。

Publish Prepare 解决“这篇文章能不能公开”。

Snapshot Preview 解决“我要恢复成什么”。

Operation Policy 解决“这个动作为什么需要确认”。

Audit Log 解决“事后如何追踪”。

Debug Bundle 解决“失败后如何把上下文交给人或 AI 继续排查”。

但它们合在一起，才是一条完整的信任链。

安全感不是藏在后端代码里的规则，而是每一次危险动作前，人类都能看见足够的上下文。

这也是为什么我越来越不想把这些功能简单地叫作“调试功能”。它们其实是 AI 发布工作台的核心产品能力。

Operations Panel

变宽，但不要变成泛后台

后来我又回头看了一遍 Typecho 官方文档。Typecho 后台当然不只有文章和媒体，还有页面、分类、标签、评论、插件、主题、用户、设置、永久链接等等。

这提醒我：这个项目最终不应该只是“远程写文章工具”。它可以慢慢变成一个更完整的 Typecho 本地控制面。

但节奏必须克制。

Posts 和 Media 是当前核心，因为它们直接服务写作发布。

Pages、Taxonomy、Comments 可以作为下一阶段 read-only inventory 进入工作台：先看清楚远端状态，再决定哪些操作适合加入。

Plugins、Themes、Settings、Users、Permalinks 这类操作风险更高。它们更适合先做诊断和只读摘要，未来如果要支持写操作，也必须走 preview、policy、audit、backup，甚至要考虑 Typecho Hook 兼容性。

Typecho 管理范围地图

一句话：项目可以变宽，但不要退化成普通后台复制品。写作优先、可见性优先、危险写操作延后。

AI 项目里的项目记忆

这次开发还有一个很有意思的变化：我不再只把 AI 当成“写代码的人”。

我们开始把任务拆成不同方向：主线工程、UI 规划、文章素材、官方文档校准、开源项目调研、公开 README 包装。不同 Agent 负责不同部分，而我的主线程更像项目经理，负责路线、边界、合并和纠偏。

这时文档就不再是写完代码后的说明书，而是多个 Agent 能继续工作的项目记忆。

docs/ai-agents/ 记录项目方向、当前状态、安全边界、Roadmap、协作方式；docs/series/ 记录文章素材和开发故事；公开 README 则把项目包装成别人能理解、能试用、能贡献的开源入口。

这其实也很符合这个项目本身的主题：AI 负责加速，人类负责边界。

这一篇之后，入口更清楚了

到第四篇，项目形态更明确了。

MCP 是 AI 的主入口。

CLI 是调试和恢复入口。

local-ops 是安全核心。

Web Workbench 是快速迭代 renderer。

Tauri 桌面应用，才是长期的人类入口。

这不是为了把人类从流程里拿掉。恰恰相反，它是为了让 AI 的连续操作能力，落在一个人类能理解、能审阅、能确认、能追踪的空间里。

下一篇我想写素材和安全模型：Typecho local media、external URL、未来 R2/S3/WebDAV/OpenList provider，以及图床、文件床、凭据、本地策略和审计之间应该怎样组合。