这阵子在 DeepSeek Harness 里给自己的博客搭了个发布工作台。博客文章依然保存在 Obsidian 的原目录下，工作台主要负责日常编辑、整理以及发布前的准备。
做着做着发现，要改的细节比最初设想的要多。很多交互如果按照以前那样全挤在一起，写起来就像流水账。梳理下来，核心主要围绕这几个关键功能点来展开：
1. 写作流与原位 AI 辅助
我自己写东西习惯先一气呵成写完正文，再去琢磨标题、摘要和标签。正文还没影就先填一堆字段，总觉得别扭。所以编辑页面把核心位置留给正文，元数据字段全部后置；一时没想好标题，也能先保存为面板草稿。
AI 的介入也完全做成了原位操作：
- 生成元数据：正文写得差不多了，点一下“AI生成Frontmatter”，直接给出一套标题、摘要和标签供我微调。
- 原位改写与撤销：需要润色某段时点“AI改写”，结果直接回填到正文里，还能撤销。省去了以前先弹出会话框、再发一次请求的多余步骤。
- 输入防覆盖保护：等 AI 返回的间隙，人往往会顺手改上两句。如果等待期间手动修改过内容，系统会把 AI 返回的结果另存起来，优先保留眼前刚写下的文字，避免直接回填造成覆盖。
2. 免去起名负担的素材箱
素材箱是中途冒出来的新需求。平时跟 AI 聊天碰撞出一段有用的内容，当下未必打算扩充成整篇文章。
现在可以在 DSH 的 AI 答复旁直接点“存入博客素材”，把这一段和上下文来源一并存下，后续写新文章或给当前正文补充素材时都能随取随用。这样不用为了随手收藏一两句话，硬逼着自己先想个文章标题。划选收藏目前还没做，现阶段先支持明确点选一条答复。
3. 融入 DSH 的编辑态与独立博客预览
界面起初想尽量贴近博客本身的样式，但真正放进 DSH 后割裂感很明显：DSH 已经切到了暗色，面板还亮晃晃的，文字根本看不清。
后来把工作台的编辑界面、主题和字体完全交给 DSH 接管，而博客原生的排版与样式只放到“效果预览”里。这样平时编辑时与其他页面保持一致，想确认实际排版时再切过去看。
预览字体中途还踩过一次坑：同一个标题里的中文看着像混了两套字形。排查发现是嵌入字体缺少部分字符，缺字时回退到了系统默认字体。换成博客现有的完整字体后才显示正常，代价是客户端资源变大了。不过这个预览目前也只是模拟配色与排版，最终效果仍然要看 Astro 的实际构建输出。
4. 正文归属 Obsidian 与管理页面重构
我比较在意文章最终存在哪里。工作台可以配置博客目录和文件名规则，写完明确点击“保存到博客”，才会真正写入 Obsidian 对应的 Markdown 文件。面板自身的自动保存另设草稿区，两者绝不混淆；在外部改过文件，工作台保存时也会做校验，防止静默覆盖。
管理结构也重新理了一遍：
- 功能分区独立：默认进入看板，写博客、博客管理和素材箱各自独立进入，不再把写作和管理塞进弹出的侧面板里，给正文留出更多空间。
- 状态与排序避坑：草稿、已发表文章和回收站分开。页面上的“已发表”目前读取的是本地文件标记，不能代表线上一定已经部署。看板排序早期直接按文件修改时间取最近文章，结果三月的旧文被改动后，居然排到了十月新文前面；现在改成读取文章内的发布日期并显示出来，整体就清晰多了。
5. 单篇 Diff 审核与渐进式发布
发布环节我坚持保留一次明确的人工核对。博客目录里可能还放着其他未写完的草稿，所以发布时必须先准备当前这一篇文章的变更，肉眼确认过 Diff 差异后再执行。一次发布只带上选定的文章以及它确实需要的标签配置变动。保存草稿和发布彻底解耦，生成正文也绝不会顺带提交或推送。
目前发布的核心逻辑已经在本地测试仓库里验证过，也单独做过真实博客副本的构建检查；但推送到真实远端线上这一整条链路，还没有实际验收。图片粘贴上传和部署状态跟踪也都留在后面，现有的图片按钮还只是插入外链。
折腾这样一个面板，很多决定确实得等自己真正打开页面用起来之后才作得出来。按钮该放哪儿、点完后需不需要多走一步、改过的正文会不会丢，这些细节在最初做方案时很难全想周全。现在先把它放在常用的 DSH 里，一边写一边给自己挑毛病，下一篇用着哪里不顺，就接着改哪里。